Ngân hàng đề — AWS Certified Developer Associate

Đáp án

A — Dùng IAM Instance Role (instance profile).

Vì sao đúng

Đội bảo mật yêu cầu bỏ khoá ghi cứng và dùng thông tin xác thực tạm thời — đó chính xác là điều instance role cung cấp.

Khi gắn instance profile vào EC2, AWS SDK tự động lấy thông tin xác thực từ metadata service, không cần một dòng cấu hình nào trong mã:

// Không có khoá nào trong mã cả
$s3 = new Aws\S3\S3Client([
    'version' => 'latest',
    'region'  => 'ap-southeast-1'
]);
$s3->getObject(['Bucket' => 'du-lieu', 'Key' => 'tep.json']);

So sánh trực tiếp:

Nên bật thêm IMDSv2 (yêu cầu token) để chống tấn công SSRF lấy thông tin xác thực từ metadata:

aws ec2 modify-instance-metadata-options --instance-id i-xxx \
  --http-tokens required --http-endpoint enabled

Vì sao các phương án khác sai

• C. Ghi cứng thông tin xác thực trong mã — chính là vấn đề đội bảo mật vừa phát hiện.
• B. Dùng biến môi trường — khá hơn ghi cứng một chút (mã sạch hơn), nhưng vẫn là khoá tĩnh dài hạn: không tự hết hạn, phải xoay vòng thủ công, và bất kỳ tiến trình nào trên máy cũng đọc được. Đề đòi thông tin xác thực tạm thời.
• D. Dùng SSM Parameter Store — nơi lưu bí mật tốt, nhưng không giải quyết vấn đề gốc: bạn vẫn cần thông tin xác thực để gọi được Parameter Store. Và nếu đã có instance role để gọi SSM thì role đó cũng gọi S3 luôn được — bước Parameter Store trở nên thừa.

Ghi nhớ

Mỗi loại compute có cơ chế role riêng — không loại nào cần access key: | Compute | Cơ chế | |---|---| | EC2 | instance profile | | Lambda | execution role | | ECS | task role | | EKS | IRSA / Pod Identity | | CodeBuild | service role | | On-premises | SSM hybrid activation |

Mẹo làm bài: thấy "access key" hoặc "hardcoded credentials" trong ngữ cảnh dịch vụ AWS gọi dịch vụ AWS ⇒ gần như chắc chắn loại được phương án đó.

Đáp án

A và B.

• A — Mọi node trong một Redis cluster phải nằm trong cùng một Region.
• B — Với cluster mode bật, bạn không thể tự tay promote replica lên làm primary.

Vì sao đúng

A — giới hạn Region. ElastiCache là dịch vụ theo Region: mọi node của một cluster nằm trong cùng một Region, dù có thể trải trên nhiều AZ để chịu lỗi.

Muốn có mặt ở nhiều Region thì phải dùng Global Datastore — một cơ chế riêng, sao chép sang tối đa hai Region phụ với độ trễ dưới một giây. Nhưng đó là nhiều cluster liên kết với nhau, không phải một cluster trải nhiều Region.

B — không promote thủ công khi cluster mode bật. Đây là khác biệt quan trọng giữa hai chế độ:

Với cluster mode bật, dữ liệu được chia trên nhiều shard và ElastiCache tự quản lý việc failover trong từng shard. Việc promote thủ công bị chặn để tránh làm hỏng tính nhất quán của toàn cluster.

Vì sao các phương án khác sai

• C. "Cluster mode bật thì sao chép bất đồng bộ; cluster mode tắt thì…" — sai ở chỗ ngụ ý hai chế độ dùng cơ chế khác nhau. Redis luôn sao chép bất đồng bộ trong cả hai chế độ. Không có chế độ nào dùng sao chép đồng bộ.
• D. "Không có replica mà node hỏng thì không mất dữ liệu, khi cluster mode bật" — sai hoàn toàn. Không có replica thì node hỏng là mất dữ liệu trên shard đó, bất kể chế độ nào. Cluster mode chia dữ liệu ra nhiều shard, nên bạn mất một phần thay vì tất cả — nhưng vẫn là mất.
• E. "Mở rộng khả năng GHI bằng cách thêm replica" — sai chiều. Replica chỉ phục vụ ĐỌC; mọi lệnh ghi đều đi tới node primary. Muốn mở rộng ghi thì phải thêm shard (chỉ làm được khi cluster mode bật).

Ghi nhớ

Và nhớ ba bậc lưu trữ trong bộ nhớ của AWS: | Dịch vụ | Bền vững | |---|---| | ElastiCache Memcached | ❌ không có replica, không snapshot | | ElastiCache Redis | ⚠️ snapshot + replica bất đồng bộ | | MemoryDB for Redis | ✅ transaction log đa AZ, nhất quán mạnh |

Đáp án

D — SSE-C (Server-Side Encryption with Customer-Provided Keys).

Vì sao đúng

SSE-C là cơ chế duy nhất trong bốn phương án mà S3 BẮT BUỘC dùng HTTPS — request qua HTTP bị từ chối thẳng.

Lý do rất trực tiếp: với SSE-C, bạn gửi khoá mã hoá kèm mỗi request:

aws s3api put-object --bucket kho --key tep.dat --body tep.dat \
  --sse-customer-algorithm AES256 \
  --sse-customer-key <khoa-base64> \
  --sse-customer-key-md5 <md5-cua-khoa>

Khoá đi trong header x-amz-server-side-encryption-customer-key. Nếu cho phép HTTP, khoá mã hoá sẽ đi qua mạng ở dạng bản rõ — vô hiệu hoá hoàn toàn mục đích của việc mã hoá. Nên S3 đơn giản là không cho phép:

400 Bad Request
InvalidRequest: Requests specifying Server Side Encryption with
Customer provided keys must be made over a secure connection.

Vì sao các phương án khác sai

• B. SSE-S3 và C. SSE-KMS — với hai cơ chế này, khoá không bao giờ rời khỏi AWS: S3 và KMS tự quản lý. Không có bí mật nào đi trên đường truyền, nên HTTP không bị chặn (dù dĩ nhiên vẫn nên dùng HTTPS).
• A. Client-side encryption — dữ liệu đã được mã hoá trước khi rời khỏi máy bạn, nên S3 chỉ nhận một khối byte vô nghĩa. Không có yêu cầu HTTPS đặc biệt nào.

Ghi nhớ

Và cách bắt buộc HTTPS cho toàn bộ bucket, bất kể dùng cơ chế mã hoá nào:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::kho", "arn:aws:s3:::kho/*"],
  "Condition": {"Bool": {"aws:SecureTransport": "false"}}
}

Điều kiện aws:SecureTransport là cách chuẩn để đáp ứng yêu cầu "mọi liên lạc phải mã hoá" mà đề nêu — và nó áp cho mọi request, không chỉ request có mã hoá.

Đáp án

B — Cấp cho AWS CodeBuild quyền tải kết quả build lên bucket S3 của bạn.

Vì sao đúng

ProjectArtifacts là phần khai nơi CodeBuild ghi kết quả build ra. Và điều quan trọng: chính CodeBuild là bên thực hiện việc ghi, nên service role của CodeBuild phải có quyền S3.

{
  "Effect": "Allow",
  "Action": ["s3:PutObject", "s3:GetObject", "s3:GetObjectVersion",
             "s3:GetBucketAcl", "s3:GetBucketLocation"],
  "Resource": ["arn:aws:s3:::kho-artifact", "arn:aws:s3:::kho-artifact/*"]
}

Cần phân biệt hai chỗ dễ lẫn trong một pipeline:

Khi bạn khai ProjectArtifacts trỏ vào bucket của riêng bạn (không phải artifact store mặc định của pipeline), CodePipeline không tự cấp quyền — bạn phải thêm vào role của CodeBuild.

Nếu thiếu, build chạy xong nhưng thất bại ở bước cuối với lỗi AccessDenied khi tải artifact lên.

Vì sao các phương án khác sai

• C. Cấp quyền cho CodeCommit ghi lên S3 — CodeCommit là nơi lưu mã nguồn; nó chỉ được đọc bởi pipeline. Nó không tham gia vào việc ghi kết quả build.
• D. Cấu hình CodeBuild lưu artifact trên EC2 — không làm được. ProjectArtifacts chỉ nhận S3 hoặc NO_ARTIFACTS (và CODEPIPELINE khi chạy trong pipeline). EC2 không phải đích hợp lệ.
• A. Liên hệ AWS Support — đây là vấn đề cấu hình IAM thông thường, hoàn toàn tự giải quyết được.

Ghi nhớ

Các loại artifacts trong CodeBuild: | Type | Nghĩa | |---|---| | CODEPIPELINE | dùng artifact store của pipeline — quyền do pipeline lo | | S3 | ghi vào bucket của bạn — phải tự cấp quyền cho CodeBuild role | | NO_ARTIFACTS | không xuất gì (ví dụ chỉ chạy test) |

Và quyền tối thiểu mà mọi CodeBuild project cần:

• CloudWatch Logs: CreateLogGroup, CreateLogStream, PutLogEvents
• S3: đọc mã nguồn và ghi artifact
• Thêm quyền cho bất cứ dịch vụ nào buildspec gọi tới (ECR, Parameter Store…)

Đáp án

D — Repository được mã hoá tự động lúc lưu.

Vì sao đúng

CodeCommit mã hoá dữ liệu ở cả hai chiều, hoàn toàn tự động, không cần cấu hình gì:

Điểm mấu chốt cho vế "in transit": CodeCommit không hỗ trợ giao thức nào không mã hoá. Bạn chỉ clone/push được qua:

# HTTPS
git clone https://git-codecommit.ap-southeast-1.amazonaws.com/v1/repos/du-an
# SSH
git clone ssh://git-codecommit.ap-southeast-1.amazonaws.com/v1/repos/du-an

Không có git:// hay http://. Nên yêu cầu của đội tuân thủ đã được đáp ứng sẵn — không cần làm gì cả.

Về mã hoá lúc lưu: CodeCommit dùng AWS managed key aws/codecommit theo mặc định. Từ 2024 còn cho phép chỉ định customer-managed key nếu cần kiểm soát và kiểm toán chi tiết hơn.

Vì sao các phương án khác sai

• A. "Bật KMS encryption" — không có nút nào để bật, vì nó đã bật sẵn và không tắt được. Câu này ngụ ý mã hoá là tuỳ chọn, trong khi thực tế nó là mặc định bắt buộc.
• C. Dùng git hook mã hoá phía client — mã hoá mã nguồn trước khi push nghe có vẻ an toàn hơn, nhưng nó phá huỷ toàn bộ giá trị của một hệ quản lý phiên bản: không diff được, không merge được, không xem lịch sử được, không review được. Và nó thừa, vì CodeCommit đã mã hoá rồi.
• B. Dùng Lambda làm hook mã hoá mã đã push — CodeCommit không có server-side hook kiểu chạy mã tuỳ ý trước khi commit được nhận. Nó có phát sự kiện lên EventBridge, nhưng đó là sau khi commit đã được lưu — quá muộn để mã hoá, và cũng không cần.

Ghi nhớ

Nhiều dịch vụ AWS mã hoá mặc định, không tắt được — biết để không đi tìm nút bật: | Dịch vụ | Mã hoá at rest | |---|---| | CodeCommit | luôn bật (KMS) | | S3 | luôn bật từ 2023 (SSE-S3 tối thiểu) | | DynamoDB | luôn bật | | CodeBuild artifact, CodePipeline artifact | luôn bật | | EBS, RDS, EFS | tuỳ chọn — phải bật |

Ghi chú thời sự: AWS đã ngừng nhận khách hàng mới cho CodeCommit từ giữa 2024; tài khoản đang dùng vẫn hoạt động bình thường.

Đáp án

B — Policy cho phép PutObject và GetObject trên mọi object trong bucket EXAMPLE-BUCKET, trừ những object có tên bắt đầu bằng private.

Vì sao đúng

Policy có hai statement, và thứ tự viết không quan trọng — điều quan trọng là loại effect:

{"Effect": "Deny",  "Action": "s3:*",
 "Resource": "arn:aws:s3:::EXAMPLE-BUCKET/private*"}        ← chặn nhánh private

{"Effect": "Allow", "Action": ["s3:PutObject", "s3:GetObject"],
 "Resource": "arn:aws:s3:::EXAMPLE-BUCKET/*"}               ← cho phép mọi object

Quy trình đánh giá của IAM:

1. Có Deny tường minh không?  → CÓ với object bắt đầu bằng "private"  → TỪ CHỐI
                              → KHÔNG với các object khác             ↓
2. Có Allow tường minh không? → CÓ (PutObject, GetObject)             → CHO PHÉP

Kết quả cụ thể: | Object | Kết quả | |---|---| | EXAMPLE-BUCKET/anh.jpg | ✅ đọc/ghi được | | EXAMPLE-BUCKET/tai-lieu/bao-cao.pdf | ✅ đọc/ghi được | | EXAMPLE-BUCKET/private-luong.csv | ❌ bị từ chối | | EXAMPLE-BUCKET/private/hop-dong.pdf | ❌ bị từ chối |

Lưu ý mẫu private* không có dấu gạch chéo, nên nó khớp cả tệp lẫn thư mục bắt đầu bằng chữ đó.

Vì sao các phương án khác sai

• A. "…cũng cho phép mọi s3 action trên object bắt đầu bằng private" — đảo ngược ý nghĩa của statement Deny. Đó là statement chặn, không phải cho phép.
• C và D. Nói về "mọi bucket trừ bucket EXAMPLE-BUCKET/private" — sai phạm vi. Cả hai statement đều nhắm vào duy nhất bucket EXAMPLE-BUCKET; policy này không cấp quyền gì trên bucket khác. Và EXAMPLE-BUCKET/private là một prefix object, không phải một bucket riêng.

Ghi nhớ

Ba quy tắc đánh giá IAM cần thuộc:

1. Mặc định là từ chối — không có Allow thì không được phép
2. Allow tường minh cho phép hành động
3. Deny tường minh luôn thắng — bất kể policy nào, bất kể thứ tự

Và nhớ: IAM policy không có thứ tự. Mọi policy áp cho một principal được hợp nhất và đánh giá cùng lúc — khác hẳn NACL (theo số thứ tự) và WAF rule (theo priority).

Mẫu Allow rộng + Deny hẹp như trong câu này là thực hành tốt và rất phổ biến: cấp quyền thoải mái rồi khoanh vùng cấm những chỗ nhạy cảm.

Đáp án

B — Dùng header Cache-Control: max-age=0.

Vì sao đúng

API Gateway cho phép client chủ động bỏ qua cache bằng header HTTP chuẩn:

curl -H "Cache-Control: max-age=0" https://abc123.execute-api.ap-southeast-1.amazonaws.com/prod/don-hang

Khi nhận header này, API Gateway bỏ qua cache, gọi thẳng backend, và cập nhật lại cache bằng phản hồi mới. Rất tiện cho kiểm thử: bạn thấy được dữ liệu mới nhất mà không phải tắt cache hay chờ TTL.

Nhưng có một điều kiện bắt buộc, và nó là chi tiết hay bị bỏ sót: client phải có quyền IAM execute-api:InvalidateCache:

{
  "Effect": "Allow",
  "Action": "execute-api:InvalidateCache",
  "Resource": "arn:aws:execute-api:ap-southeast-1:123456789012:abc123/prod/GET/don-hang"
}

Không có quyền này, hành vi phụ thuộc vào cấu hình "Require authorization" của stage: hoặc trả về 403, hoặc lặng lẽ bỏ qua header và vẫn trả dữ liệu từ cache.

Vì sao các phương án khác sai

• A. Tham số truy vấn ?cache-control-max-age=0 — nhầm chỗ: đây là cơ chế header, không phải query string. Ngoài ra, thêm một query parameter lạ thực ra sẽ tạo một khoá cache mới (nếu parameter đó nằm trong cache key), nên bạn nhận dữ liệu mới nhưng vì lý do hoàn toàn khác — và làm phình cache.
• C. Header Bypass-Cache=1 và D. Tham số ?bypass_cache=1 — cả hai đều không tồn tại. API Gateway chỉ hiểu header HTTP chuẩn Cache-Control.

Ghi nhớ

Ba cách làm mới cache của API Gateway: | Cách | Phạm vi | Ai làm | |---|---|---| | Header Cache-Control: max-age=0 | một request | client (cần quyền InvalidateCache) | | FlushStageCache API | toàn bộ stage | quản trị viên | | Chờ hết TTL | tự động | — |

# Xoá sạch cache của cả stage
aws apigateway flush-stage-cache --rest-api-id abc123 --stage-name prod

Và nhớ đặc điểm chi phí: cache của API Gateway tính tiền theo GIỜ, không theo request — nên nó chỉ đáng khi lưu lượng đủ lớn, và nên tắt ở môi trường dev/test.

Đáp án

C — Dùng ElastiCache để lưu phiên người dùng.

Vì sao đúng

Nguyên nhân gốc: ứng dụng lưu dữ liệu phiên trên chính instance. Với blue/green deployment, mỗi lần phát hành là dựng một fleet EC2 hoàn toàn mới — fleet cũ bị huỷ, và mọi phiên nằm trên đó biến mất theo.

Trước deploy:  Fleet xanh lam [phiên 1..1000]
Sau deploy  :  Fleet xanh lá  [rỗng]           ← 1000 người dùng bị đăng xuất

Cách chữa đúng là tách trạng thái ra khỏi máy tính toán:

Instance A ─┐
Instance B ─┼─→ ElastiCache [mọi phiên]     ← instance đến và đi tuỳ ý
Instance C ─┘

ElastiCache hợp cho dữ liệu phiên vì ba lý do: độ trễ dưới mili giây (phiên phải đọc ở mỗi request), TTL sẵn có để phiên tự hết hạn, và với Redis thì có replica đa AZ để bản thân tầng lưu phiên cũng không thành điểm hỏng.

Đây cũng là nguyên tắc lớn hơn: hạ tầng bất biến đòi ứng dụng không trạng thái.

Vì sao các phương án khác sai

• B. Bật sticky session trên ALB — đây là bẫy chính, và nó không giải quyết được vấn đề này. Sticky session ghim client vào cùng một target, nhưng với blue/green thì toàn bộ target đều bị thay — không còn gì để quay lại. (Sticky session chỉ cứu được trường hợp load balancer luân phiên giữa các instance đang sống, không cứu được deploy kiểu thay fleet.)
• D. Dùng rolling update thay blue/green — hạ thấp chiến lược triển khai để né vấn đề. Rolling cũng thay instance, chỉ là thay từng lô — nên vẫn mất phiên, chỉ mất dần thay vì mất một lúc. Và nó bỏ mất ưu điểm rollback tức thì của blue/green.
• A. Dùng multicast để sao chép thông tin phiên — AWS VPC không hỗ trợ multicast (trừ qua Transit Gateway multicast cho một số trường hợp rất hẹp). Cách này cũng phức tạp và mong manh ngay cả ở môi trường on-premises.

Ghi nhớ

Câu hỏi này và #5192 cùng một chủ đề nhưng khác nguyên nhân: ở đó là load balancer luân phiên giữa các instance (sticky session cứu được), ở đây là instance bị thay hoàn toàn (chỉ tách trạng thái mới cứu được).

Đáp án

B — Cognito Identity Pools.

Vì sao đúng

Đề nêu hai yêu cầu, và cả hai đều là mô tả chính xác của identity pool:

1. Không lưu access key và secret key trên thiết bị di động
2. Mỗi thiết bị gọi DynamoDB bằng một danh tính khác nhau

Identity pool đổi một danh tính (đã xác thực hoặc chưa xác thực) lấy thông tin xác thực AWS tạm thời qua STS:

Thiết bị → Cognito identity pool → STS AssumeRoleWithWebIdentity
        → access key TẠM THỜI (hết hạn sau ~1 giờ)
        → gọi DynamoDB trực tiếp

Vế "danh tính khác nhau cho từng thiết bị" rất quan trọng, vì nó cho phép phân quyền tới từng người dùng bằng policy variable:

{
  "Effect": "Allow",
  "Action": ["dynamodb:GetItem", "dynamodb:PutItem"],
  "Resource": "arn:aws:dynamodb:*:*:table/DuLieuNguoiDung",
  "Condition": {
    "ForAllValues:StringEquals": {
      "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
    }
  }
}

Điều kiện dynamodb:LeadingKeys giới hạn mỗi thiết bị chỉ đụng được vào item có partition key bằng chính identity ID của nó — cách ly hoàn hảo, thực thi ở tầng IAM nên không lách được.

Vì sao các phương án khác sai

• C. Cognito User Pools — là thư mục người dùng: đăng ký, đăng nhập, MFA, phát JWT. Nhưng JWT không phải thông tin xác thực AWS — bạn không gọi DynamoDB bằng JWT được. Cần identity pool để đổi.
• D. IAM — tạo IAM user cho từng thiết bị là bất khả thi: giới hạn cứng 5.000 IAM user mỗi tài khoản, và mỗi user có access key dài hạn — đúng thứ đề yêu cầu tránh.
• A. Cognito Sync — dịch vụ đồng bộ dữ liệu người dùng giữa các thiết bị, và đã lỗi thời (AWS khuyến nghị AppSync). Nó không cấp quyền truy cập AWS.

Ghi nhớ

Identity pool còn hỗ trợ unauthenticated identity — cấp quyền hạn chế cho người dùng chưa đăng nhập, hữu ích cho tính năng dùng thử.

Câu thần chú: "truy cập tài nguyên AWS trực tiếp từ thiết bị" ⇒ Identity Pool.

Đáp án

B — Sửa IAM permission của EC2 instance role.

Vì sao đúng

Manh mối khoanh vùng rất chặt: deploy THÀNH CÔNG, nhưng ứng dụng gặp authorization exception khi gọi S3.

Vế thứ nhất chứng minh CodeDeploy đã làm xong việc của nó. Vế thứ hai chỉ thẳng vào ứng dụng đang chạy, mà ứng dụng chạy trên EC2 thì dùng instance profile để gọi AWS.

Cần phân biệt hai role hoàn toàn khác nhau trong một lần deploy:

Policy cần thêm vào instance role:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::kho-du-lieu/*"
}

Nơi tìm bằng chứng: log ứng dụng sẽ có AccessDenied kèm ARN của role — cho biết chính xác role nào đang thiếu quyền gì.

Vì sao các phương án khác sai

• C. Sửa quyền của CodeDeploy service role — role này chỉ dùng trong quá trình deploy, và deploy đã thành công. Sau khi deploy xong, nó không tham gia gì vào việc ứng dụng chạy.
• A. Mở bucket S3 công khai — "chữa" bằng cách tạo ra một lỗ hổng bảo mật nghiêm trọng. Vấn đề là thiếu quyền cho một danh tính cụ thể, không phải cần mở cho cả thế giới.
• D. "Bật CodeDeploy Proxy" — không tồn tại. CodeDeploy agent có cấu hình :proxy_uri: cho môi trường phải đi qua proxy để ra Internet, nhưng đó là chuyện mạng, không liên quan tới lỗi phân quyền.

Ghi nhớ

Chẩn đoán theo thời điểm lỗi xảy ra: | Lỗi xảy ra khi | Nghi ngờ | |---|---| | Deploy thất bại ở DownloadBundle | instance role thiếu quyền S3 đọc bundle | | Deploy thất bại ở tầng điều phối | CodeDeploy service role | | Deploy thành công nhưng ứng dụng lỗi | instance role thiếu quyền cho lời gọi của ứng dụng |

Nguyên tắc chung: ứng dụng chạy trên EC2 luôn dùng instance profile để gọi AWS — không bao giờ dùng access key. Và khi gặp AccessDenied, hãy đọc ARN trong thông báo lỗi để biết chính xác danh tính nào đang bị chặn.