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

🧩 Phân tích nội dung câu hỏi

Đề bài đặt người quản trị vào tình huống lập báo cáo CloudWatch alarm và bắt gặp metric HTTPCode_ELB_4XX_Count trong namespace AWS/ApplicationELB. Câu hỏi chỉ đơn giản là: metric này đếm cái gì?

Cụm từ quyết định nằm ngay trong tên của chính metric: mảnh _ELB_ đứng giữa HTTPCode và 4XX_Count. Application Load Balancer có hai họ metric mã trạng thái song song nhau:

• HTTPCode_ELB_xxx_Count — mã do load balancer tự sinh ra
• HTTPCode_Target_xxx_Count — mã do target phía sau trả về

Đề bài cố tình đưa vào hai phương án B và D gần như trùng nghĩa ("HTTP 4XX" ở cả hai), khác nhau đúng một chi tiết: lỗi phát sinh từ load balancer hay từ target. Đọc lướt sẽ thấy cả hai đều hợp lý; phân biệt được hay không phụ thuộc hoàn toàn vào việc bạn có để ý chữ ELB trong tên metric hay không.

✅ Vì sao đáp án đúng là đúng

Đáp án B — "The number of HTTP 4XX client error codes that originate from the load balancer" là đáp án đúng theo tệp.

HTTPCode_ELB_4XX_Count đếm số mã lỗi client 4XX do chính load balancer sinh ra, và không bao gồm các mã trạng thái do target trả về. Đây là điểm mấu chốt: hai nguồn sinh mã lỗi được tách thành hai metric riêng biệt, chứ không cộng gộp.

Load balancer sinh 4XX khi request bị malformed hoặc incomplete — sai định dạng, thiếu thành phần, không đúng chuẩn HTTP mà ALB chấp nhận. Những request kiểu này chưa từng đến được target: ALB chặn ngay tại tầng của nó và trả lỗi về client. Ngoại lệ đáng nhớ là mã HTTP 460, mã riêng của ALB, cũng được đếm trong metric này.

Ý nghĩa vận hành: khi lập báo cáo, HTTPCode_ELB_4XX_Count tăng vọt tức là vấn đề nằm ở phía request đi vào hoặc ở cấu hình listener/rule, không phải ở ứng dụng chạy trên target. Đây chính là lý do phân biệt hai metric lại quan trọng khi khoanh vùng sự cố.

❌ Vì sao các phương án còn lại sai

A — "The number of requests where the load balancer chose a new target because it couldn't use an existing sticky session"

Đây là mô tả của metric NonStickyRequestCount, hoàn toàn không liên quan tới mã trạng thái HTTP. Nó đo hành vi của cơ chế session stickiness: khi cookie sticky hết hạn, không hợp lệ, hoặc target cũ không còn khả dụng, ALB phải chọn target mới. Nội dung này không dính dáng gì tới nhóm mã 4XX.

C — "The number of TLS connections initiated by the client that did not establish a session with the load balancer"

Đây là metric ClientTLSNegotiationErrorCount. Nó đếm số kết nối TLS mà client khởi tạo nhưng không thiết lập được phiên với load balancer do lỗi TLS — nguyên nhân thường gặp là không khớp cipher suite hoặc protocol version, hoặc client không xác thực được server certificate rồi tự đóng kết nối. Lưu ý: những sự cố này xảy ra ở tầng TLS handshake, trước cả khi có request HTTP, nên không thể sinh ra mã trạng thái HTTP nào cả.

D — "The number of HTTP 4XX response codes generated by ELB targets"

Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Nó đúng về nhóm mã (4XX) nhưng sai về nguồn sinh mã: mô tả này thuộc về metric HTTPCode_Target_4XX_Count, chứ không phải HTTPCode_ELB_4XX_Count. Đúng như phần giải thích của đáp án B đã nêu, metric trong đề không tính bất kỳ mã trạng thái nào do target sinh ra. Chọn D nghĩa là đọc metric mà bỏ qua đúng mảnh _ELB_ — mảnh duy nhất phân biệt hai phương án.

📌 Điểm cần nhớ

• Trong namespace AWS/ApplicationELB, quy ước đặt tên metric mã trạng thái là HTTPCode_<nguồn>_<nhóm mã>_Count. Đọc phần <nguồn> trước khi đọc phần mã: ELB = do load balancer sinh, Target = do target sinh. Hai metric này loại trừ lẫn nhau, không chồng lấn.
• Request bị ALB trả 4XX thường chưa bao giờ chạm tới target. Vì vậy HTTPCode_ELB_4XX_Count tăng là tín hiệu điều tra phía request/listener/rule, còn HTTPCode_Target_4XX_Count tăng mới là tín hiệu điều tra ứng dụng.
• Mã HTTP 460 là mã đặc thù của ALB và được tính vào nhóm HTTPCode_ELB_4XX_Count — một chi tiết hay được đem ra hỏi.
• Lỗi ở tầng TLS có metric riêng (ClientTLSNegotiationErrorCount), không xuất hiện dưới dạng mã HTTP, vì handshake hỏng thì chưa có request HTTP nào được xử lý. Tương tự, hành vi sticky session có metric riêng (NonStickyRequestCount). Khi phương án mô tả một hiện tượng không phải mã trạng thái, hãy nghi ngờ ngay rằng nó đang mô tả một metric khác.

🧩 Phân tích nội dung câu hỏi

Đề nói một SysOps Administrator đã bật AWS CloudTrail qua AWS Management Console cho một account, và trail đó trải trên nhiều region (spans across multiple regions). Câu hỏi yêu cầu chọn phát biểu mô tả kết quả hợp lệ của hành động này.

Cụm từ quyết định đáp án là "via the AWS Management Console" kết hợp với "spans across multiple regions". Đây không phải câu hỏi về kiến trúc logging mà là câu hỏi kiểm tra bạn có nắm hành vi mặc định của CloudTrail khi tạo trail từ Console hay không: Console mặc định tạo trail ghi sự kiện ở tất cả các region, và toàn bộ log của mọi region được gom về một S3 bucket duy nhất. Ba phương án còn lại đều phủ nhận hoặc bóp méo đúng hai điểm này — hoặc bảo phải có bucket riêng cho từng region, hoặc bảo Console không làm được, hoặc bảo CloudTrail không log đa region.

✅ Vì sao đáp án đúng là đúng

A — CloudTrail can deliver log files from multiple regions to a single Amazon S3 bucket of the AWS account.

Khi tạo trail từ Console, mặc định trail được áp dụng cho tất cả AWS Region. CloudTrail sao chép cấu hình trail sang các region, ghi nhận và xử lý log file ở từng region, rồi giao toàn bộ log file của mọi region về cùng một S3 bucket (và cùng một CloudWatch Logs log group nếu bạn có cấu hình). Nếu bạn khai báo thêm một SNS topic tuỳ chọn, thông báo cho mọi log file cũng đổ về đúng topic đó.

Điểm mấu chốt: bucket đích không bắt buộc phải nằm trong home region của trail. Miễn là CloudTrail có quyền ghi vào bucket (bucket policy cho phép), bucket đặt ở region nào cũng được. Chính vì vậy khi bạn đổi một trail single-region đang có sẵn thành trail all-region, CloudTrail vẫn tiếp tục giao log vào đúng bucket và đúng log group cũ, chỉ khác là nay có thêm sự kiện từ các region còn lại.

❌ Vì sao các phương án còn lại sai

B — CloudTrail can deliver logs to S3 buckets in trail's home region. Configure an Amazon S3 bucket for each region to receive logs from all regions.

Đây là phương án gần đúng nhất và cũng là bẫy chính, vì nó nghe hợp lý với trực giác "dịch vụ regional thì lưu trong region". Nhưng nó hỏng ở chỗ áp đặt một ràng buộc không tồn tại: bucket của multi-region trail không buộc phải ở home region của trail. Hệ quả kéo theo — "dựng một bucket cho mỗi region" — vì thế cũng sai, và còn đi ngược đúng lợi ích lớn nhất của multi-region trail là gom log về một chỗ để dễ phân tích, dễ đặt lifecycle policy, dễ kiểm soát quyền truy cập.

C — It is not possible to enable CloudTrail in all regions of an AWS account from console. This can only be done through CLI.

Sai và sai theo chiều ngược hẳn với thực tế. Console chính là nơi hành vi all-region là mặc định. Trái lại, nếu bạn muốn một trail chỉ ghi một region duy nhất, đó mới là trường hợp phải dùng AWS CLI. Nhớ kỹ chiều này vì đề thi hay đảo ngược nó.

D — CloudTrail cannot log from multiple regions of an AWS account.

Phủ nhận thẳng một năng lực cốt lõi của dịch vụ. Multi-region trail là khuyến nghị thực hành tốt của AWS, và nếu phương án này đúng thì bản thân giả định trong đề ("a trail that spans across multiple regions") đã không tồn tại được. Phương án phủ định tuyệt đối kiểu này gần như luôn là mồi loại nhanh.

📌 Điểm cần nhớ

• Tạo trail từ Console → mặc định all regions; muốn giới hạn về một region duy nhất thì phải dùng CLI. Đây là cặp đối lập rất hay bị hỏi ngược.
• Log của multi-region trail đổ về một S3 bucket duy nhất (kèm một CloudWatch Logs log group và một SNS topic nếu có cấu hình), không phải mỗi region một bucket.
• Bucket đích không cần nằm trong home region của trail; điều kiện thật sự là CloudTrail phải có quyền ghi vào bucket đó.
• Đổi một trail single-region sẵn có thành all-region không làm đổi đích giao log — vẫn cùng bucket, cùng log group, chỉ thêm sự kiện từ các region khác.

🧩 Phân tích nội dung câu hỏi

Đề đưa ra hai stack policy của AWS CloudFormation và hỏi: khi áp mỗi policy này lên một stack thì thao tác nào được phép, thao tác nào bị chặn. Cần lưu ý ngay: stack policy không phải IAM policy — nó không nói ai được gọi API nào, mà nói resource nào trong stack được phép bị cập nhật khi chạy stack update.

Cụm từ quyết định đáp án nằm ở chính cấu trúc hai policy:

• Policy-1 có cặp Deny + Allow chồng nhau: Deny Update:* trên LogicalResourceId/MyDatabase, rồi Allow Update:* trên Resource: "*" — mà * thì bao gồm cả MyDatabase.
• Policy-2 dùng NotResource chứ không dùng Resource: Allow Update:* cho mọi thứ trừ LogicalResourceId/MyDatabase, và không có statement Deny nào cả.

Hai chi tiết cần nắm để phân xử: Deny luôn thắng Allow khi hai statement chồng lấn, và khi một stack policy đã được đặt, CloudFormation từ chối mọi update không được cho phép tường minh (mặc định là deny). Ghép hai luật này lại thì hai policy viết theo hai kiểu khác nhau nhưng cho ra cùng một kết quả.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là D — cả hai policy đều chặn mọi thao tác update lên resource có logical ID MyDatabase, và cho phép mọi thao tác update lên các resource còn lại của stack.

Với Policy-1: statement Allow Update:* trên Resource: "*" mở đường cho toàn bộ stack, nhưng statement Deny đứng trên đã nhắm đúng LogicalResourceId/MyDatabase. Vì Deny luôn đè lên Allow ở phần chồng lấn, MyDatabase bị khoá còn mọi resource khác vẫn update được. Đây là cách bảo vệ tường minh.

Với Policy-2: chỉ có duy nhất một statement Allow, và nó dùng NotResource để loại MyDatabase ra khỏi phạm vi được phép. MyDatabase không nằm trong bất kỳ statement Allow nào, nên rơi vào default denial — đã đặt stack policy thì cái gì không được cho phép tường minh sẽ bị từ chối. Kết quả giống hệt Policy-1, chỉ khác ở chỗ đây là bảo vệ ngầm định.

Nên cả hai đều: cấm update MyDatabase, cho phép update phần còn lại. Đúng như phương án D mô tả.

❌ Vì sao các phương án còn lại sai

A — "Cả hai policy đều cho phép update mọi resource". Sai với cả hai. Ở Policy-1, người đọc dễ chỉ nhìn thấy dòng Allow ... Resource: "*" mà bỏ qua statement Deny phía trên; nhưng thứ tự viết không quyết định gì, Deny vẫn thắng. Ở Policy-2, NotResource đã cắt MyDatabase ra khỏi vùng cho phép nên nó không hề "được phép". Phương án này bỏ qua đúng hai cơ chế mà câu hỏi đang kiểm tra.

B — "Policy-1 chặn update MyDatabase, còn Policy-2 cho phép". Nửa đầu đúng, nửa sau sai — đây là phương án gần đúng nhất và cũng là cái bẫy chính. Nó hỏng ở chỗ hiểu nhầm NotResource: vì Policy-2 không có chữ Deny nào nên trông như "không cấm ai cả". Thực tế NotResource là loại trừ khỏi phạm vi Allow, không phải cấp quyền cho phần bị loại; phần bị loại rơi về default deny của stack policy. Chọn B nghĩa là nghĩ "không viết Deny thì không bị chặn", trong khi stack policy chạy theo hướng ngược lại.

C — "Policy-2 chặn update MyDatabase, còn Policy-1 cho phép". Cũng ngược một nửa. Nửa nói về Policy-2 thì đúng, nhưng nửa nói Policy-1 cho phép update MyDatabase thì sai: đó là hiểu nhầm rằng statement Allow viết sau sẽ ghi đè statement Deny viết trước, kiểu "dòng cuối thắng". Việc phân xử statement không dựa vào thứ tự — hễ có Deny trùng vào resource nào thì resource đó bị chặn.

📌 Điểm cần nhớ

• Stack policy khác IAM policy: nó chỉ kiểm soát việc resource nào trong stack được sửa/thay/xoá trong lúc stack update, không liên quan tới quyền gọi API của người dùng.
• Deny luôn đè Allow, bất kể thứ tự các statement. Muốn chắc chắn bảo vệ một resource thì viết Deny tường minh cho resource đó.
• Đã đặt stack policy thì mặc định là từ chối: update nào không được Allow tường minh sẽ bị chặn. Vì vậy NotResource trong một statement Allow có tác dụng bảo vệ tương đương một statement Deny.
• Gặp dạng câu so sánh hai policy, hãy soi hai thứ trước tiên: có statement Deny chồng lấn không, và Resource hay NotResource — chỉ hai điểm đó thường đủ để loại hết các phương án gần giống nhau.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một ứng dụng dùng nhiều, chạy trên Amazon Aurora DB cluster, kết nối được bảo vệ bằng TLS, và yêu cầu database publicly accessible. Câu hỏi cuối cùng mới là thứ quyết định: "Which of the following steps are needed to connect to an Amazon Aurora DB cluster from outside a VPC?"

Hai cụm từ then chốt:

• "from outside a VPC" — nghĩa là client nằm ngoài VPC, phải phân giải được endpoint thành địa chỉ IP công cộng rồi mới đi tới được instance.
• "Aurora DB cluster" — riêng với Aurora, cách khai báo vị trí mạng cho instance không phải là chọn subnet, mà là chọn DB subnet group. Đây chính là ràng buộc phân biệt hai phương án nghe rất giống nhau: C ("choose a public subnet") và F ("configure a DB subnet group for public subnets").

Chi tiết TLS trong đề chỉ là bối cảnh về mã hoá đường truyền; nó không đổi gì trong ba bước cấu hình mạng được hỏi.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là B, E, F. Để một instance trong cluster Aurora nhận kết nối trực tiếp từ ngoài VPC, cần đủ ba điều kiện:

• E — The Aurora DB instance must have a public IP address: instance chỉ để lộ ra Internet khi nó thực sự được cấp một địa chỉ IP công cộng. Không có IP công cộng thì endpoint chỉ phân giải ra địa chỉ riêng, và client bên ngoài không có đường đi tới.
• F — Configure a DB subnet group for public subnets and create the Aurora DB instance from this subnet group: instance phải chạy trong subnet có khả năng truy cập công khai. Với Aurora, bạn không chỉ định một subnet cụ thể; bạn tạo một DB subnet group gồm các subnet có cấu hình mạng tương đồng (ở đây là các public subnet), rồi tạo instance từ group đó. RDS sẽ tự chọn một subnet trong group khi dựng host bên dưới — nên cả group phải là public thì kết quả mới chắc chắn đúng ý.
• B — Enable the VPC attributes DNS hostnames and DNS resolution: nếu muốn DB instance trong VPC là publicly accessible thì hai thuộc tính này của VPC phải được bật. Chúng là thứ khiến endpoint DNS của cluster phân giải đúng ra địa chỉ công cộng khi truy vấn từ bên ngoài.

Ba bước này bổ trợ nhau: F đặt instance vào đúng vùng mạng, E cho nó địa chỉ để tới được, B làm cho tên endpoint phân giải ra đúng địa chỉ đó.

❌ Vì sao các phương án còn lại sai

• A — Disable the VPC attributes DNS hostnames and DNS resolution: đây là mệnh đề ngược hẳn với B. Tắt hai thuộc tính này thì endpoint không phân giải ra tên/địa chỉ dùng được cho truy cập công khai, đúng phá hỏng thứ mà đề yêu cầu. Phương án dạng "cặp đối lập" như A–B là dấu hiệu rõ rằng một trong hai nằm trong đáp án; chỉ cần nhớ chiều đúng là "enable".

• C — Choose a public subnet while creating the Aurora DB instance for ensuring public access: đây là phương án gần đúng nhất và cũng dễ bẫy nhất — ý tưởng "phải nằm trong public subnet" là đúng về nguyên lý, nhưng cách làm thì sai. Với Amazon Aurora, bạn không chọn được một subnet cụ thể khi tạo instance. Thứ bạn khai là DB subnet group — một tập hợp subnet thuộc VPC — và Amazon RDS chọn ngẫu nhiên một subnet trong group đó khi tạo host bên dưới. Vì thế cách diễn đạt đúng phải là F, không phải C. Chọn C là mô tả một thao tác không tồn tại trong quy trình tạo Aurora.

• D — A publicly accessible Aurora DB instance cannot be launched into the default VPC. Choose a non-default VPC: khẳng định này sai ngay ở mệnh đề đầu. Bạn có thể tạo Aurora DB cluster trong default VPC của tài khoản, hoặc trong một VPC do bạn tự định nghĩa — cả hai đều hợp lệ. Không hề có ràng buộc cấm public access trong default VPC. Phương án này bịa ra một hạn chế không có, và bịa xong lại bắt bạn làm thêm một bước thừa.

📌 Điểm cần nhớ

• Công thức "truy cập Aurora/RDS từ ngoài VPC" gồm ba mảnh: public IP address cho instance, subnet có thể truy cập công khai (khai qua DB subnet group), và DNS hostnames + DNS resolution bật ở mức VPC. Thiếu bất kỳ mảnh nào là kết nối từ bên ngoài không thành.
• Với Aurora/RDS, đơn vị khai báo mạng là DB subnet group, không phải subnet lẻ. Gặp phương án nói "chọn subnet" khi tạo instance thì gần như chắc chắn đó là bẫy.
• Default VPC không hề bị cấm chứa DB instance publicly accessible. Cảnh giác với các phương án dựng lên một giới hạn nghe rất kỹ thuật nhưng không có thật.
• Khi hai phương án là cặp enable/disable của cùng một thuộc tính (như A và B), hãy xác định chiều theo mục tiêu của đề: đề muốn public access thì chiều đúng là enable.
• TLS bảo vệ dữ liệu trên đường truyền, nó là lớp khác với khả năng định tuyến và phân giải tên. Nhắc tới TLS trong đề không thay đổi các bước cấu hình mạng cần làm.

🧩 Phân tích nội dung câu hỏi

Tình huống: dữ liệu của một DynamoDB table nằm ở account A được export ra một S3 bucket thuộc account B. Sau khi export xong, người dùng trong account B không truy cập hay thao tác được với đống dữ liệu đó, dù bucket là của chính họ.

Cụm từ quyết định nằm ở chỗ dữ liệu đi từ account A sang bucket của account B, và câu hỏi là "What should be done to fix this issue?" — tức là sửa lỗi truy cập trên dữ liệu đã export xong, chứ không phải chọn lại cách di chuyển dữ liệu.

Ràng buộc kỹ thuật ẩn phía sau: trong S3, object owner là account đã ghi object lên, không phải account sở hữu bucket. Ở đây tiến trình export chạy dưới danh nghĩa account A, nên account A vẫn là chủ của từng object, còn account B chỉ là chủ cái bucket rỗng bọc quanh chúng. Chủ bucket không tự động đọc được object do account khác ghi vào — đó chính xác là triệu chứng đề mô tả.

✅ Vì sao đáp án đúng là đúng

C — Include the PutObjectAcl permission on all exported objects after the export is complete.

Vì object vẫn thuộc quyền sở hữu của account A, IAM user trong account B mặc định không đọc được. Cách chữa theo đúng hướng dẫn của AWS cho ca migration này là: sau khi export xong, dùng PutObjectAcl trên toàn bộ object đã export để cấp quyền cho bucket owner ở account B. Thao tác này do phía đang có quyền trên object thực hiện, và nó viết lại ACL của từng object để chủ bucket có quyền trên chúng.

Chú ý hai chi tiết khớp đúng với đề: nó là workaround áp lên dữ liệu đã tồn tại (đúng với "fix this issue"), và nó tác động lên từng object — đúng cấp độ mà vấn đề ownership phát sinh.

❌ Vì sao các phương án còn lại sai

A — Configure the export function to write data with ACL bucket-owner-full-control. Đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi. Về nguyên lý, ghi object kèm ACL bucket-owner-full-control đúng là cách chuẩn để chủ bucket có quyền ngay từ lúc object được tạo. Nhưng nó hỏng ở chỗ: chức năng export của DynamoDB không ghi dữ liệu kèm ACL đó, và bạn không có nút để bắt nó làm vậy. Phương án mô tả một hành vi mà dịch vụ không cung cấp — nghe hợp lý về mặt S3 nhưng không thực hiện được ở đây. Thêm nữa, dữ liệu đã export rồi, cấu hình lại lúc ghi không sửa được những object đang nằm sẵn trong bucket.

B — Use AWS Data Pipeline to export account A DynamoDB table to an S3 bucket in account B. Bản thân câu này không sai về mặt kỹ thuật: Data Pipeline là một cách hợp lệ để chuyển DynamoDB table sang account khác, thậm chí còn đơn giản hơn tuy ít tuỳ biến hơn. Nó sai vì trả lời nhầm câu hỏi: đề đang hỏi cách sửa lỗi truy cập trên dữ liệu đã export, không hỏi chọn công cụ migration nào. Làm lại toàn bộ quá trình bằng một công cụ khác là né vấn đề, không phải fix nó.

C — đáp án đúng, đã giải thích ở trên.

D — Use AWS Glue crawler to directly import the data into DynamoDB tables of account B. Sai ở hai tầng. Thứ nhất, cross-account access tới Data Catalog không được hỗ trợ khi dùng AWS Glue crawler, nên chính hướng làm này vướng đúng cái rào cross-account mà đề đang gặp. Thứ hai, crawler làm việc thu thập schema/metadata vào Data Catalog, đó không phải công cụ để "import thẳng dữ liệu vào DynamoDB table" như phương án mô tả — mô tả này sai bản chất của crawler ngay cả khi bỏ qua chuyện cross-account.

📌 Điểm cần nhớ

• Trong S3, quyền sở hữu object thuộc về account đã ghi object lên, không thuộc về chủ bucket. Ghi cross-account vào bucket người khác là công thức quen thuộc dẫn tới "bucket của tôi mà tôi không đọc được".
• Đọc kỹ động từ của câu hỏi: "fix this issue" giới hạn đáp án vào việc xử lý dữ liệu đã tồn tại, nên mọi phương án kiểu "làm lại bằng công cụ khác" (Data Pipeline) đều lệch, dù bản thân công cụ đó hợp lệ.
• bucket-owner-full-control là lời giải đúng về nguyên lý cho ownership, nhưng phải kiểm tra dịch vụ nguồn có thực sự đặt được ACL đó không. Với DynamoDB export thì không — nên cách còn lại là chạy PutObjectAcl trên các object sau khi export.
• AWS Glue crawler dùng để thu thập metadata vào Data Catalog, và không hỗ trợ cross-account access tới Data Catalog; đừng chọn nó làm công cụ chuyển dữ liệu giữa hai account.

🧩 Phân tích nội dung câu hỏi

Đề đặt bối cảnh: bạn là SysOps Administrator, cần tạo một chứng chỉ ACM (AWS Certificate Manager) cho Elastic Load Balancer đứng trước các instance EC2. Câu hỏi thật ra không hỏi về cách cấu hình load balancer, mà hỏi: "What are the key points to consider while creating certificates through ACM? (Select two)" — tức là kiểm tra bạn có nắm giới hạn và phạm vi sử dụng của ACM hay không.

Hai cụm từ quyết định nằm ở chính bối cảnh mà đề dựng lên: chứng chỉ được gắn cho Elastic Load Balancer, chứ không phải cài trực tiếp lên EC2 instance. Đó là ranh giới mà mấy phương án nhiễu xoay quanh: ACM chỉ phục vụ SSL/TLS và chỉ dùng được thông qua các dịch vụ tích hợp (ELB, CloudFront…), chứ không phải là một nơi phát hành chứng chỉ đa mục đích rồi bạn tự tải khoá về dùng ở đâu tuỳ ý. Thêm nữa, "(Select two)" nhắc rằng phải chọn đúng hai phát biểu đúng, và ở đây cả hai đều là phát biểu về giới hạn của ACM.

✅ Vì sao đáp án đúng là đúng

A — ACM provides certificates for SSL/TLS protocols only. ACM lo toàn bộ phần phức tạp của việc tạo, lưu trữ và gia hạn chứng chỉ X.509 công khai lẫn riêng tư, nhưng mục đích của chúng là bảo vệ website và ứng dụng bằng SSL/TLS. ACM không phát hành chứng chỉ cho các mục đích khác ngoài giao thức SSL/TLS. Trong bối cảnh đề bài, đây đúng là thứ bạn cần: chứng chỉ gắn vào listener HTTPS của ELB.

B — You cannot use ACM certificates for email encryption. Đây là hệ quả trực tiếp của A. Mã hoá/ký email dùng chứng chỉ theo chuẩn khác (mục đích sử dụng khác của X.509), và ACM không phục vụ trường hợp đó. Nếu ai đó định lấy chứng chỉ ACM để ký hay mã hoá thư, họ đang dùng sai công cụ.

Hai phát biểu này chính là "key points" mà đề muốn: biết ACM làm gì và biết nó không làm gì.

❌ Vì sao các phương án còn lại sai

C — You can install an ACM certificate on your application running on an Amazon EC2 instance. Đây là phương án gài bẫy nặng nhất, vì đề bài có nhắc tới EC2 nên nó "nghe hợp cảnh". Nhưng bạn không thể cài trực tiếp chứng chỉ ACM lên website/ứng dụng chạy trên EC2. Chứng chỉ ACM chỉ dùng được thông qua các dịch vụ tích hợp như Elastic Load Balancer hay Amazon CloudFront. Chú ý đúng chi tiết này giải thích luôn vì sao đề dựng kiến trúc "ELB đứng trước EC2": TLS kết thúc tại load balancer, chứ không phải tại instance.

D — The private key for an ACM certificate can only be downloaded from an AWS root user account. Sai ở chỗ căn bản: không tải được private key của chứng chỉ ACM, bất kể bạn đăng nhập bằng tài khoản nào. Phương án này khéo ở chỗ nó gợi ý rằng vấn đề chỉ là "thiếu quyền", khiến người đọc nghĩ đây là chuyện phân quyền IAM. Thực tế private key do ACM quản lý và không xuất ra ngoài — đó cũng chính là lý do phải dùng qua dịch vụ tích hợp (phương án C).

E — ACM helps you request certificates for Amazon-owned domain names. Ngược lại mới đúng: bạn không xin được chứng chỉ ACM cho những tên miền do Amazon sở hữu, ví dụ các tên kết thúc bằng amazonaws.com, cloudfront.net hay elasticbeanstalk.com. Những endpoint đó vốn đã có chứng chỉ do AWS cung cấp sẵn; ACM dành cho tên miền bạn sở hữu và chứng minh được quyền kiểm soát. Phương án này nghe xuôi tai vì thực tế các endpoint mặc định vẫn chạy HTTPS được — nhưng đó không phải nhờ chứng chỉ bạn yêu cầu qua ACM.

📌 Điểm cần nhớ

• ACM chỉ dành cho SSL/TLS, không dành cho mã hoá email hay các mục đích chứng chỉ khác — mọi phương án kéo ACM sang mục đích khác đều sai.
• Chứng chỉ ACM dùng qua dịch vụ tích hợp (ELB, CloudFront…), không cài trực tiếp lên EC2. Thấy kiến trúc "ELB đứng trước EC2" trong đề là dấu hiệu tác giả đang kiểm tra đúng điểm này.
• Private key của chứng chỉ ACM không tải xuống được — không có ngoại lệ cho root user. Bất kỳ phương án nào nói "tải khoá riêng về" đều loại ngay.
• Không xin được chứng chỉ ACM cho tên miền do Amazon sở hữu (amazonaws.com, cloudfront.net, elasticbeanstalk.com); ACM chỉ cấp cho tên miền bạn kiểm soát.

🧩 Phân tích nội dung câu hỏi

Đề đưa ra một IAM policy và hỏi: policy này thực sự cho phép làm gì. Đây là dạng câu bẫy đọc hiểu — bốn phương án đều nhắc tới EC2 và RDS, nên phải đọc kỹ chứ không đoán theo từ khoá.

Cụm từ quyết định nằm ngay trong policy, ở statement thứ hai:

• "Action": ["iam:PassRole"] — quyền được cấp là PassRole, không phải quyền của RDS, cũng không phải quyền lên RDS.
• "Resource": "arn:aws:iam:::role/RDS-*" — resource của iam:PassRole là chính cái role được truyền đi, và nó bị giới hạn theo tiền tố tên RDS-.

Còn statement đầu ("Action": "ec2:*", "Resource": "*") mới là phần nói về dịch vụ đích: mọi hành động EC2. Ghép hai mảnh lại: người dùng được thao tác EC2, và được truyền role sang dịch vụ đó — nhưng chỉ những role có tên bắt đầu bằng RDS-.

Điểm dễ sập bẫy: chữ RDS- trong ARN là một chuỗi trong tên role, không có nghĩa là policy này liên quan tới dịch vụ RDS. Đặt tên role là RDS-something không biến nó thành role của RDS.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là C — cho phép gán IAM Role cho EC2 nếu tên role bắt đầu bằng RDS-.

Để cấu hình nhiều dịch vụ AWS, bạn phải truyền (pass) một IAM role cho dịch vụ đó; sau này dịch vụ sẽ assume role ấy để hành động thay bạn. Việc truyền role chỉ làm một lần lúc thiết lập, chứ không phải mỗi lần dịch vụ assume role.

Chính vì thế AWS tách riêng quyền iam:PassRole: người dùng muốn gắn một role vào dịch vụ thì bản thân họ phải có quyền truyền role đó. Cơ chế này để quản trị viên chắc chắn rằng chỉ những người được duyệt mới được cấu hình một dịch vụ với role mang quyền nhất định — nếu không, ai có quyền tạo EC2 cũng có thể gắn cho instance một role quyền cao và leo thang đặc quyền qua đó.

Áp vào policy trong đề:

• Statement EC2 cho toàn quyền hành động EC2.
• Statement Passrole cho phép iam:PassRole, nhưng resource giới hạn ở các role tên RDS-*.

Kết quả tổng hợp đúng như phương án C: thao tác trên EC2, kèm khả năng gán role — chỉ với các role tên bắt đầu bằng RDS-.

❌ Vì sao các phương án còn lại sai

A — "cho RDS toàn quyền lên EC2 instance". Đảo ngược hoàn toàn chiều của quyền. Policy này gắn cho một IAM principal (user/role/group), cho principal đó quyền EC2, chứ không cấp cho dịch vụ RDS quyền gì lên EC2. Trong policy cũng không có bất kỳ action nào thuộc namespace rds:.

B — "cho phép gán role bất kỳ cho EC2 instance". Đây là phương án gần đúng nhất, và nó hỏng đúng ở một chỗ: chữ bất kỳ. Nếu resource của iam:PassRole là "*" thì B mới đúng. Ở đây resource là arn:aws:iam:::role/RDS-*, tức là chỉ những role khớp tiền tố RDS-. Bỏ qua wildcard có tiền tố này là bỏ qua đúng ràng buộc mà câu hỏi muốn kiểm tra.

D — "cho phép gán role bất kỳ cho RDS instance". Sai cả hai vế. Vế "bất kỳ" sai vì lý do giống B. Vế "cho RDS instance" sai vì đọc nhầm RDS- trong tên role thành dịch vụ đích nhận role. Dịch vụ đích ở đây được xác định bởi statement ec2:*, không phải bởi tên role.

📌 Điểm cần nhớ

• Với iam:PassRole, Resource chính là role được truyền đi, không phải dịch vụ nhận role. Muốn biết role đi tới đâu thì nhìn các action dịch vụ khác trong cùng policy.
• Tên role chỉ là một chuỗi ký tự. role/RDS-* là quy ước đặt tên, không mang ngữ nghĩa "role này thuộc về RDS".
• Wildcard có tiền tố (RDS-*) là ràng buộc thật — gặp phương án nói "any role" thì phải kiểm lại resource có phải "*" không trước khi chọn.
• PassRole là điểm chốt chống leo thang đặc quyền: có quyền tạo tài nguyên chưa đủ, còn phải có quyền truyền role thì mới gắn được role vào tài nguyên đó.

🧩 Phân tích nội dung câu hỏi

Đề mô tả dữ liệu khách hàng nhạy cảm nằm trên Amazon S3, và đặt ra hai yêu cầu cùng lúc:

1. Dữ liệu phải được mã hoá at rest.
2. Khoá mã hoá phải được xoay vòng ít nhất mỗi năm một lần.

Nhưng cụm từ quyết định nằm ở câu hỏi cuối: "What is an easy way to implement this requirement?" — cách dễ thực hiện. Cả bốn phương án đều có thể mã hoá được dữ liệu theo nghĩa nào đó; điều phân biệt chúng là ai phải làm việc xoay khoá. Vì vậy câu này thực chất hỏi: giữa các cách mã hoá S3, cách nào có automatic key rotation dựng sẵn, không bắt người vận hành tự viết mã hay tự quản lý vòng đời khoá.

Bám vào hai chữ "easy" và "rotated annually", đáp án phải là dịch vụ vừa lo mã hoá vừa lo xoay khoá hộ mình.

✅ Vì sao đáp án đúng là đúng

C — Use AWS KMS with automatic key rotation.

S3 hỗ trợ server-side encryption với ba lựa chọn loại trừ nhau tuỳ theo cách quản lý khoá: SSE-S3, SSE-KMS (khoá nằm trong AWS Key Management Service), và SSE-C (khách hàng tự cung cấp khoá). Với SSE-KMS, S3 mã hoá object ngay khi ghi xuống đĩa và tự giải mã khi bạn truy cập — phần mã hoá at rest coi như xong mà không phải viết dòng code nào.

Phần còn lại là xoay khoá: KMS có sẵn tính năng automatic key rotation, bật lên là KMS tự thay material của CMK theo chu kỳ hằng năm, áp dụng cho các khoá được sinh ra bên trong KMS HSM. Ứng dụng không cần biết chuyện đó xảy ra — key ID không đổi, dữ liệu cũ vẫn giải mã được bằng material cũ mà KMS giữ lại.

Nếu không chỉ định customer managed CMK, S3 sẽ tự tạo một AWS managed CMK trong tài khoản ở lần đầu ghi object bằng SSE-KMS. Tóm lại: một tính năng bật bằng cấu hình, phủ trọn cả hai yêu cầu của đề — đúng nghĩa "easy way".

❌ Vì sao các phương án còn lại sai

A — Use SSE-C with automatic key rotation on an annual basis. Sai ngay ở giả định. Với SSE-C, bạn quản lý khoá, S3 chỉ dùng khoá bạn gửi kèm mỗi request để mã hoá lúc ghi và giải mã lúc đọc; khoá không được lưu ở bất kỳ đâu trong S3. Vì S3 không giữ khoá, nó không có gì để xoay — SSE-C không có cơ chế automatic key rotation nào cả. Phương án này ghép một tính năng không tồn tại vào một mô hình khoá không cho phép nó tồn tại.

B — Encrypt the data before sending it to Amazon S3. Đây là client-side encryption. Nó có thoả mãn yêu cầu mã hoá at rest, nên nhìn thì hợp lệ — nhưng hỏng ở đúng chữ "easy". Bạn phải tự lo toàn bộ vòng đời khoá: sinh khoá, cất giữ, phân phối cho ứng dụng, và tự cài đặt cơ chế xoay khoá hằng năm. Đó là gánh nặng vận hành lớn nhất trong bốn phương án, ngược hẳn với thứ đề đang tìm.

D — Import a custom key into AWS KMS and automate the key rotation on an annual basis by using a Lambda function. Đây là phương án gần đúng nhất và cũng là cái bẫy chính. Nó hỏng ở hai chỗ. Thứ nhất, imported key material không hỗ trợ automatic key rotation — chính vì thế phương án mới phải tự thêm Lambda vào, và đó là dấu hiệu tự nó thừa nhận cách này không có sẵn cơ chế xoay. Thứ hai, khi import khoá, bạn có trách nhiệm giữ một bản sao của key material trong hạ tầng quản lý khoá của mình để có thể re-import khi cần — thêm một hệ thống nữa phải vận hành và bảo vệ. Cách này chạy được, nhưng cần code, cần lịch, cần giám sát Lambda, và cần một kho khoá bên ngoài; so với việc tick một ô cấu hình ở C thì nó không phải "easy way".

📌 Điểm cần nhớ

• Đề hỏi "easy way" / "least operational overhead" thì hãy tìm tính năng quản lý sẵn (managed) thay vì giải pháp tự dựng bằng Lambda, cron hay script — phương án nào phải viết code để bù một tính năng thiếu thì thường là phương án sai.
• Ba kiểu server-side encryption của S3 khác nhau ở ai giữ khoá: SSE-S3 (AWS giữ), SSE-KMS (KMS giữ, có kiểm soát và audit), SSE-C (bạn giữ và gửi kèm mỗi request).
• Automatic key rotation của KMS chỉ áp dụng cho khoá do KMS sinh ra trong HSM. Khoá imported thì không được xoay tự động — đây là chi tiết ra đề rất hay dùng để dựng phương án nhiễu.
• SSE-C không có xoay khoá tự động, vì S3 không hề lưu khoá của bạn. Thấy cụm "SSE-C + automatic rotation" trong đề là loại được ngay.
• Client-side encryption thoả mãn yêu cầu bảo mật nhưng đẩy toàn bộ việc sinh, giữ và xoay khoá về phía bạn — hiếm khi là đáp án cho câu hỏi ưu tiên sự đơn giản.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một công ty đã bật mã hoá CloudTrail log files bằng SSE-KMS để có "a directly manageable security layer" — tức là muốn tự nắm quyền quản lý khoá. Nhưng họ quan sát thấy digest files lại dùng một cơ chế mã hoá khác, và câu hỏi yêu cầu chỉ ra nguyên nhân gốc.

Cụm từ quyết định nằm ở chỗ đề tách bạch hai loại tệp: log files và digest files. Digest file là tệp mà CloudTrail sinh ra theo giờ khi bật log file integrity validation — nó chứa hash của các log file trong khoảng thời gian trước đó, dùng để chứng minh log không bị sửa. Đề không nói cấu hình sai, không nói bucket sai, không nói region sai — nó chỉ nói "seem to use a different encryption scheme". Ràng buộc phân biệt vì thế là: thao tác bật SSE-KMS trên trail áp dụng lên phạm vi nào? Ai nghĩ SSE-KMS phủ lên toàn bộ những gì CloudTrail ghi vào bucket sẽ chọn sai; ai nhớ rằng nó chỉ phủ lên log file sẽ chọn đúng.

✅ Vì sao đáp án đúng là đúng

A — Digest files are encrypted with Amazon S3-managed encryption keys (SSE-S3).

Mặc định, log file mà CloudTrail giao vào bucket S3 của bạn được mã hoá bằng SSE-S3. Khi bạn muốn một lớp bảo mật tự quản lý được, bạn chuyển sang SSE-KMS cho log file. Điểm mấu chốt: việc bật server-side encryption bằng SSE-KMS chỉ tác động lên log file, không tác động lên digest file. Digest file vẫn tiếp tục được mã hoá bằng SSE-S3.

Đây chính xác là hiện tượng công ty trong đề quan sát được — "cơ chế mã hoá khác" không phải do lỗi cấu hình, mà là hành vi thiết kế sẵn của CloudTrail. Nói cách khác, câu trả lời cho "underlying reason" là: digest file nằm ngoài phạm vi của tuỳ chọn SSE-KMS và giữ nguyên SSE-S3.

❌ Vì sao các phương án còn lại sai

B — The log files are created in a different region from the digest files. Sai về mặt sự thật. Digest file được tạo trong cùng region với log file mà nó tham chiếu. Phương án này cố gán nguyên nhân cho sự khác biệt về địa lý, nhưng khác biệt đó không tồn tại. Ngay cả khi có khác region đi nữa, region không phải là thứ quyết định cơ chế mã hoá của một object trong S3.

C — Per the default configuration, different S3 buckets are used for log and digest files. Đây là phương án gần đúng nhất về mặt "nghe hợp lý", vì nếu hai loại tệp nằm ở hai bucket khác nhau thì cấu hình mã hoá khác nhau là chuyện dễ hiểu. Nhưng tiền đề sai: digest file được giao vào đúng bucket S3 gắn với trail — cùng bucket với log file. Thậm chí khi log file từ nhiều region hoặc nhiều account cùng dồn về một bucket, CloudTrail cũng đưa digest file của các region và account đó vào chính bucket ấy. Phương án hỏng ngay ở giả định "different S3 buckets", nên phần suy luận phía sau không cứu được.

D — AWS KMS–managed key (SSE-KMS) is different for log files and digest files. Phương án này thừa nhận đúng rằng có sự khác biệt, nhưng đặt sai bản chất khác biệt: nó cho rằng cả hai đều dùng SSE-KMS, chỉ khác nhau ở việc dùng hai KMS key khác nhau. Thực tế digest file không dùng SSE-KMS chút nào — nó dùng SSE-S3. Đây là bẫy tinh vi nhất trong bốn phương án: nếu digest file dùng một KMS key khác thì người dùng vẫn có "directly manageable security layer" cho digest file, mâu thuẫn với chính điều đề đang than phiền.

📌 Điểm cần nhớ

• SSE-KMS cho CloudTrail chỉ áp lên log file, không áp lên digest file. Digest file luôn ở lại với SSE-S3 — đây là hành vi mặc định, không phải lỗi cấu hình, và không có nút nào để "sửa".
• Digest file cùng bucket, cùng region với log file. Gặp phương án nào nói chúng nằm ở bucket khác hoặc region khác thì loại ngay.
• Digest file gắn liền với log file integrity validation: mỗi giờ CloudTrail sinh một tệp chứa hash của các log file trong giờ trước, dùng để chứng minh log không bị chỉnh sửa.
• Khi đề tách bạch hai đối tượng (log vs digest, data vs metadata), hãy hỏi phạm vi tác động của thao tác cấu hình trước khi nghĩ tới region, bucket hay key khác nhau — phần lớn bẫy nằm ở chỗ thí sinh mặc định một cài đặt phủ lên toàn bộ.

🧩 Phân tích nội dung câu hỏi

Tình huống: một SysOps Administrator copy AMI từ Region này sang Region khác và nhận thông báo lỗi:

"This AMI was copied from an AMI with a kernel that is unavailable in the destination Region"

Đề hỏi root cause — nguyên nhân gốc rễ — chứ không hỏi cách khắc phục.

Cụm từ quyết định nằm ngay trong chính thông báo lỗi: "a kernel that is unavailable in the destination Region". Chữ kernel ở đây là mấu chốt. Một AMI mà bản thân nó phụ thuộc vào một kernel image riêng (AKI — kernel do AWS quản lý, khai báo tách rời khỏi image) chỉ có thể là AMI dùng kiểu ảo hoá paravirtual (PV). AMI kiểu HVM thì boot bằng chính bootloader nằm trong volume của nó, không tham chiếu tới kernel ngoài, nên không bao giờ sinh ra lỗi dạng này.

Nói cách khác, đề đã tự tố cáo loại virtualization qua từ "kernel", và bốn phương án chỉ khác nhau ở chỗ gán lỗi cho PV, cho HVM, cho việc copy nói chung, hay cho một lỗi provisioning mơ hồ.

✅ Vì sao đáp án đúng là đúng

C — Linux paravirtual (PV) AMIs aren't supported in all AWS Regions and copying these across unsupported Regions results in this error.

Linux AMI dùng một trong hai kiểu ảo hoá: PV hoặc HVM. Khác biệt chính giữa chúng là cách boot và khả năng tận dụng các phần mở rộng phần cứng (CPU, network, storage) để chạy nhanh hơn.

PV là kiểu cũ, boot qua một kernel riêng do AWS cung cấp, và không được hỗ trợ ở mọi Region. Khi copy một PV AMI sang Region đích không có kernel tương ứng, EC2 không tìm được kernel để gắn vào image mới và trả về đúng thông báo trong đề.

Cách xử lý đúng theo hướng dẫn của AWS: tạo một instance HVM mới, gắn EBS volume mới vào nó, rồi chép dữ liệu từ các EBS volume của instance PV cũ sang. Tức là chuyển sang HVM, chứ không có cách "sửa" bản thân PV AMI ở Region đích.

❌ Vì sao các phương án còn lại sai

B — HVM AMIs aren't supported in all AWS Regions. Đây là phương án gần đúng nhất và cũng là bẫy chính: nó đúng về mặt cấu trúc câu, chỉ đảo PV thành HVM. Nhưng mệnh đề bị lật ngược so với thực tế — mọi Region đều hỗ trợ HVM. HVM chính là kiểu ảo hoá hiện đại, mặc định cho các thế hệ instance mới, và là đích đến khi AWS khuyên bạn thoát khỏi PV. Nếu chọn B, bạn còn mâu thuẫn với chính hướng dẫn khắc phục: không ai lại khuyên chuyển sang một kiểu image "không được hỗ trợ ở mọi Region" để chữa lỗi thiếu hỗ trợ Region.

D — Linux AMIs do not support copy across Regions. Sai hoàn toàn ở mức khái niệm. Copy AMI giữa các Region là chức năng bình thường và được hỗ trợ — chính đề bài đã mô tả người quản trị đang làm việc đó, và lỗi nhận về là lỗi về kernel, không phải lỗi "thao tác không được phép". Nếu copy cross-Region không tồn tại thì thông báo lỗi đã phải là dạng unsupported operation, chứ không nhắc gì tới kernel.

A — The error is a general indication of AMI not being provisioned correctly. Đây là distractor thuần tuý: một câu trả lời chung chung, không giải thích được bất cứ chi tiết nào trong thông báo lỗi. Thông báo đã nêu rất cụ thể (kernel + destination Region), nên quy nó về "AMI provision sai" là bỏ qua chính manh mối mà đề đưa cho bạn. Trong đề thi AWS, phương án mơ hồ kiểu "lỗi chung chung" gần như luôn sai khi đề đã cung cấp thông báo lỗi chi tiết.

📌 Điểm cần nhớ

• Linux AMI có hai kiểu virtualization: PV và HVM. PV là kiểu cũ, boot bằng kernel riêng và không có mặt ở mọi Region; HVM boot bằng bootloader trong chính volume và được hỗ trợ ở mọi Region.
• Thấy thông báo lỗi nhắc tới kernel unavailable in destination Region khi copy AMI → nghĩ ngay tới PV AMI, không phải HVM.
• Cách gỡ chuẩn của AWS là migrate sang HVM: dựng instance HVM mới, gắn EBS volume mới, chép dữ liệu từ volume của instance PV cũ sang — chứ không phải tìm cách copy lại PV.
• Khi đề đã cho một thông báo lỗi cụ thể, hãy dùng chính từ khoá trong đó để loại phương án. Các đáp án kiểu "lỗi provisioning nói chung" hoặc "tính năng này không tồn tại" thường là distractor.