Ngân hàng đề — AWS Certified Cloud Practitioner

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

Đề mô tả một công ty đang dùng một AWS managed IAM policy để cấp quyền cho users, nhưng bây giờ cần thêm một số quyền nữa. Câu hỏi: làm thế nào để đạt được điều đó?

Cụm từ quyết định đáp án là "AWS managed IAM policy" — không phải customer managed policy, không phải inline policy. Đây là loại policy do chính AWS tạo ra và duy trì (ví dụ AmazonS3ReadOnlyAccess, ReadOnlyAccess). Đặc điểm cốt lõi của chúng: AWS sở hữu, khách hàng không sửa được. Chúng dùng chung cho mọi tài khoản AWS trên thế giới, nên nếu một khách hàng sửa được nội dung thì ý nghĩa của policy đó sẽ khác nhau ở mỗi nơi.

Vế thứ hai cũng quan trọng: "add some permissions" — mục tiêu là cấp thêm quyền, không phải siết bớt quyền. Ràng buộc này loại bỏ những phương án chỉ có tác dụng giới hạn.

Ghép hai ràng buộc lại: cần thêm quyền + không sửa được thứ đang dùng ⇒ phải tạo một policy mới của riêng mình.

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

A. Create a custom IAM policy — đúng.

Vì AWS managed policy không chỉnh sửa được, cách xử lý chuẩn là tự viết một custom IAM policy (customer managed policy) chứa đúng những quyền còn thiếu, rồi gắn nó cho user/group/role đang cần. IAM đánh giá quyền theo kiểu hợp nhất tất cả các policy đang gắn: user vẫn giữ nguyên quyền từ AWS managed policy cũ, cộng thêm quyền từ policy mới. Không phải bỏ policy cũ, không phải chép lại toàn bộ nội dung của nó.

Đây cũng là lý do IAM cho phép gắn nhiều policy lên cùng một identity — để mở rộng quyền theo kiểu cộng dồn thay vì phải sửa một khối duy nhất.

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

B. Edit the AWS managed policy — đây là phương án gần đúng nhất, và cũng là cái bẫy chính. Về mặt ý tưởng thì hợp lý: cần thêm quyền thì sửa policy đang dùng. Nhưng nó hỏng ở chỗ AWS managed policy là read-only đối với khách hàng — bạn xem được nội dung, gắn/gỡ được, nhưng không sửa được nội dung. Chỉ AWS mới cập nhật chúng. Nếu đề nói là customer managed policy thì B mới là đáp án; đổi đúng một chữ trong đề là đảo ngược kết quả.

C. Create a rule in AWS WAF — sai vì nhầm hẳn tầng bảo mật. AWS WAF là web application firewall, lọc HTTP/HTTPS request đi vào các resource như CloudFront, Application Load Balancer, API Gateway để chặn tấn công web (SQL injection, cross-site scripting, request theo IP xấu…). Nó làm việc với traffic từ Internet, hoàn toàn không liên quan tới việc cấp quyền cho IAM user gọi API của AWS.

D. Create a Service Control Policy — sai theo hướng tinh vi hơn, và cần nhớ kỹ. SCP thuộc AWS Organizations, áp lên account hoặc OU. Vấn đề là SCP không bao giờ cấp quyền — nó chỉ đặt trần quyền tối đa (permissions boundary ở cấp tổ chức) cho những gì IAM trong account đó được phép làm. Quyền thực tế = giao của SCP và IAM policy. Vậy nên dù có viết SCP cho phép rộng đến đâu, user vẫn không có thêm quyền nào nếu IAM policy của họ chưa cấp. Đề đang cần thêm quyền, mà SCP chỉ có tác dụng giới hạn — sai đúng chiều tác dụng.

📌 Điểm cần nhớ

• AWS managed policy không sửa được; customer managed policy (custom) và inline policy thì sửa được. Thấy chữ "AWS managed" trong đề là gần như chắc chắn đáp án sẽ là "tạo policy riêng" chứ không phải "sửa policy đó".
• Quyền trong IAM cộng dồn qua các policy được gắn, nên muốn thêm quyền chỉ cần gắn thêm một policy mới, không cần đụng tới cái đang có.
• SCP giới hạn, IAM policy cấp phát. Câu hỏi có động từ "add/grant permissions" thì SCP luôn là phương án sai; câu hỏi có "restrict/prevent across accounts" thì SCP mới vào cuộc.
• Phân biệt tầng: IAM kiểm soát ai được gọi API AWS nào, còn AWS WAF lọc request web đi vào ứng dụng. Hai thứ không thay thế cho nhau trong bất kỳ tình huống nào.

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

Đề hỏi: chạy một instance Amazon EC2 On-Demand, hệ điều hành Linux, trong 4 giờ, 5 phút, 6 giây thì bị tính tiền cho khoảng thời gian nào?

Hai cụm từ trong đề quyết định đáp án:

• "on-demand ... running Linux" — hệ điều hành là chi tiết mấu chốt, không phải câu chữ thừa. Đơn vị tính tiền của EC2 phụ thuộc vào loại OS/phần mềm chạy trên instance. Với Linux, AWS tính tiền theo giây. Nếu đề đổi thành một hệ điều hành hoặc phần mềm thương mại tính phí theo giờ, đơn vị tối thiểu sẽ khác và đáp án cũng khác.
• "4hrs, 5 minutes and 6 seconds" — con số cố tình lẻ ra tận đơn vị giây, để xem người học có tự động làm tròn lên giờ hoặc lên phút hay không.

Đây là câu kiểm tra hiểu biết về mô hình per-second billing của EC2 chứ không phải câu tính toán.

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

Đáp án đúng là C — "4hrs, 5mins, and 6 seconds".

EC2 Linux instances ở cả ba hình thức On-Demand, Reserved và Spot đều được tính tiền theo từng giây sử dụng, với một mức tối thiểu là 1 phút cho mỗi lần chạy. Nghĩa là:

• Nếu instance chỉ chạy vài giây rồi tắt, bạn vẫn bị tính đủ 1 phút.
• Nếu instance chạy vượt qua mốc 1 phút, phần vượt được tính chính xác tới giây, không làm tròn.

Trong câu hỏi này thời gian chạy là 4 giờ 5 phút 6 giây — đã vượt xa ngưỡng tối thiểu 1 phút — nên hoá đơn phản ánh đúng bằng thời lượng thực tế: 4 giờ, 5 phút, 6 giây. Không có bước làm tròn nào được áp dụng.

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

A — "5hrs": Đây là cách tính theo mô hình làm tròn lên giờ (per-hour billing) — chạy dư một giây trong giờ thứ năm thì trả tiền trọn giờ thứ năm. Đó là cách EC2 tính tiền ở thời kỳ đầu, và vẫn còn đúng với một số hệ điều hành/phần mềm thương mại có giấy phép tính theo giờ. Nhưng đề đã nói rõ là Linux, nên mô hình per-second áp dụng, không phải per-hour. Đây là bẫy phổ biến nhất của câu này vì nhiều tài liệu cũ vẫn dạy theo cách làm tròn lên giờ.

B — "4hrs": Đây là cách làm tròn xuống — cắt bỏ phần lẻ 5 phút 6 giây. AWS không bao giờ tính tiền theo hướng làm tròn xuống có lợi cho khách hàng như vậy; tài nguyên đã chạy thì đã tiêu thụ và sẽ được ghi nhận. Phương án này sai cả về nguyên tắc lẫn về con số.

D — "4hrs, 6mins": Đây là phương án gần đúng nhất và cũng nguy hiểm nhất. Nó nhận ra rằng EC2 không làm tròn lên giờ, nhưng lại dừng lại nửa đường: nó giả định đơn vị tính nhỏ nhất là phút rồi làm tròn 5 phút 6 giây thành 6 phút. Chỗ hỏng nằm ở chỗ nhầm giữa hai khái niệm khác nhau — "mức tính tối thiểu là 1 phút" không có nghĩa là "đơn vị tính là phút". Một phút chỉ là sàn áp dụng cho các lần chạy cực ngắn; khi đã vượt sàn thì đơn vị tính quay về giây. Người chọn D đã nhớ đúng con số "1 phút" nhưng hiểu sai vai trò của nó trong công thức.

📌 Điểm cần nhớ

• EC2 Linux tính tiền theo giây, kèm mức tối thiểu 1 phút mỗi lần chạy. Áp dụng cho cả On-Demand, Reserved và Spot — hình thức mua không làm thay đổi đơn vị tính.
• Phân biệt "đơn vị tính" và "mức tối thiểu". Đơn vị tính là giây; mức tối thiểu 1 phút chỉ có tác dụng với những lần chạy ngắn hơn một phút. Đã vượt sàn thì không còn làm tròn nữa.
• Hệ điều hành là từ khoá cần khoanh tròn trong mọi câu hỏi về billing của EC2. Đề nêu Linux thì nghĩ tới per-second; đề nêu hệ điều hành hay phần mềm thương mại có giấy phép riêng thì phải cân nhắc khả năng đơn vị tính là giờ.
• AWS không làm tròn xuống. Bất kỳ phương án nào cắt bớt thời gian đã sử dụng đều loại được ngay mà không cần tính toán gì thêm.

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

Đề hỏi: AWS có dịch vụ hay tính năng nào xác định và tìm kiếm các tài nguyên AWS đang được chia sẻ ra bên ngoài hay không.

Cụm từ quyết định là "externally shared AWS resources" — tài nguyên được chia sẻ với một thực thể nằm ngoài ranh giới tin cậy của bạn (ngoài account, ngoài organization). Đây là bài toán về resource-based policy: policy gắn trên chính tài nguyên (bucket policy của S3, trust policy của IAM role, policy của KMS key, SQS queue…) cho phép một principal lạ truy cập.

Hai chữ cần tách bạch:

• "identify and search" → dịch vụ phải phân tích quyền truy cập, chứ không phải chỉ lưu trữ hay đánh chỉ mục dữ liệu.
• "shared" (chia sẻ) → thuộc phạm vi Identity and Access Management, không phải compute, không phải quản trị tài khoản.

Lĩnh vực của câu này cũng đã nói rõ: AWS Security, Identity, & Compliance. Ba phương án còn lại đều nằm ngoài nhóm đó.

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

A. AWS IAM Access Analyzer đúng theo tệp.

Access Analyzer giúp bạn xác định những tài nguyên trong organization và trong các account của mình — ví dụ Amazon S3 bucket hay IAM role — đang được chia sẻ với một thực thể bên ngoài. Nhờ đó bạn phát hiện được quyền truy cập ngoài ý muốn vào tài nguyên và dữ liệu của mình, vốn là một rủi ro bảo mật.

Cách nó làm việc khớp chính xác với chữ "identify and search" trong đề: bạn khai báo một ranh giới tin cậy (zone of trust — account hoặc organization), Access Analyzer soi các policy gắn trên tài nguyên và báo ra finding cho mỗi trường hợp quyền vượt ra ngoài ranh giới đó. Kết quả là danh sách tra cứu được, không phải một cảnh báo mơ hồ.

Điểm mấu chốt: nó suy luận trên chính nội dung policy, chứ không dựa vào log truy cập thực tế. Nghĩa là một bucket bị mở quyền ra ngoài vẫn bị phát hiện ngay cả khi chưa ai từng truy cập nó.

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

B. AWS Fargate — sai. Fargate là compute engine serverless trả tiền theo mức dùng, cho phép bạn chạy container mà không phải quản lý máy chủ. Đây là dịch vụ chạy ứng dụng, không liên quan gì tới Identity and Access Management, càng không có chức năng rà soát quyền chia sẻ tài nguyên.

C. Amazon OpenSearch Service (Amazon Elasticsearch Service) — sai, và đây là phương án dễ mắc bẫy nhất vì chữ "search" trong đề trùng với chữ "Search" trong tên dịch vụ. Nhưng "search" của OpenSearch là tìm kiếm và phân tích dữ liệu: phân tích log tương tác, giám sát ứng dụng thời gian thực, làm chức năng tìm kiếm cho website. Nó là bộ công cụ tìm kiếm phân tán mã nguồn mở phát triển từ Elasticsearch. Bạn có thể đổ log vào đó rồi tự tìm, nhưng bản thân dịch vụ không có khả năng nhận diện tài nguyên đang được chia sẻ ra ngoài — không có gì đọc và suy luận trên resource policy cả. Trùng tên chứ không trùng việc.

D. AWS Control Tower — sai, và là phương án "gần đúng" theo hướng khác: nó đúng là dịch vụ bảo mật/quản trị, nên nghe có vẻ hợp. Control Tower là cách nhanh nhất để thiết lập và quản trị một môi trường AWS nhiều account an toàn, gọi là landing zone. Nó dựng khung quản trị: tạo account theo chuẩn, áp guardrail, tổ chức OU. Chỗ nó hỏng: đó là dịch vụ governance — dựng và áp chính sách khung cho môi trường — chứ không phải dịch vụ đi soi từng tài nguyên xem cái nào đang lộ ra ngoài. Control Tower đặt ra luật chơi; Access Analyzer mới là thứ chỉ đích danh tài nguyên nào đang vi phạm ranh giới tin cậy.

📌 Điểm cần nhớ

• "Externally shared resources" trong đề thi gần như luôn dẫn tới IAM Access Analyzer. Nhớ cặp từ khoá này như một phản xạ.
• Access Analyzer phân tích resource-based policy (S3 bucket policy, IAM role trust policy…) so với một zone of trust, chứ không phân tích log truy cập — nên nó thấy cả những lỗ hổng chưa ai khai thác.
• Đừng chọn dịch vụ chỉ vì trùng chữ với đề. "Search" trong OpenSearch là tìm kiếm dữ liệu, không phải tìm kiếm cấu hình quyền.
• Phân biệt hai tầng: Control Tower = governance nhiều account (dựng và áp khung), IAM Access Analyzer = phát hiện quyền truy cập ngoài ý muốn ở mức tài nguyên. Còn Fargate là compute, không dính dáng tới bảo mật danh tính.

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

Đề mô tả một nhu cầu rất cụ thể: công ty muốn gọi một workflow của AWS Step Functions mỗi khi trạng thái của một Amazon EC2 instance thay đổi.

Cụm từ quyết định đáp án là "each time an EC2 instance state changes" — tức là cần một thứ lắng nghe sự kiện (event) do EC2 phát ra và tự động kích hoạt mục tiêu khác. Đây chính là mô tả kinh điển của kiến trúc event-driven: có nguồn phát sự kiện (EC2 đổi trạng thái: pending → running → stopping → terminated), có luật định tuyến, và có mục tiêu (Step Functions state machine).

Vì thế câu hỏi không hỏi "dịch vụ nào chạy workload", cũng không hỏi "dịch vụ nào điều phối các bước" (Step Functions đã đảm nhiệm phần đó rồi và đã có sẵn trong đề). Nó chỉ hỏi đúng một mảnh còn thiếu: cái gì đứng giữa EC2 và Step Functions để bắt sự kiện và bấm nút chạy.

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

B – Amazon EventBridge là event bus serverless, sinh ra đúng để làm cầu nối này. Cơ chế của nó gồm ba phần:

• Các dịch vụ AWS (trong đó có EC2) tự động đẩy sự kiện lên default event bus, bao gồm sự kiện EC2 Instance State-change Notification.
• Người dùng tạo rule khớp mẫu sự kiện đó (event pattern), ví dụ lọc theo trạng thái cụ thể hoặc theo instance nhất định.
• Rule khai báo target, và AWS Step Functions state machine là một target được hỗ trợ trực tiếp — không cần viết code trung gian.

Nói cách khác, EventBridge biến "mỗi khi EC2 đổi trạng thái" thành một trigger tự động, không cần polling, không cần máy chủ nào chạy sẵn để canh chừng. Đúng như phần giải thích gốc nêu: EventBridge cho phép đặt luật để hành động xảy ra khi có sự kiện nhất định — instance đổi trạng thái, tệp được tải lên S3 bucket, v.v.

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

A – AWS Fargate. Đây là phương án gần đúng nhất và cũng là cái dễ bẫy nhất. Fargate là compute engine serverless để chạy container (với ECS/EKS), nên nó có thể xuất hiện bên trong một workflow tự động hoá — chẳng hạn Step Functions gọi một task Fargate để xử lý việc gì đó. Nhưng chỗ nó hỏng là: Fargate là nơi thực thi, không phải nơi phát hiện sự kiện. Nó không lắng nghe thay đổi trạng thái EC2 và không có cơ chế nào tự khởi động Step Functions khi có sự kiện. Đặt Fargate vào đây thì vẫn thiếu đúng mảnh mà đề đang hỏi.

C – Amazon SageMaker. Dịch vụ machine learning: xây dựng, huấn luyện và triển khai mô hình ML với hạ tầng được quản lý. Hoàn toàn không liên quan tới việc bắt sự kiện hay tự động hoá workflow. Nó chỉ có mặt trong danh sách như một phương án gây nhiễu theo kiểu "tên dịch vụ AWS quen thuộc".

D – Amazon Connect. Là dịch vụ contact center trên cloud — tổng đài chăm sóc khách hàng, định tuyến cuộc gọi, tương tác với khách. Đúng là nó cũng có khái niệm "flow", nhưng đó là luồng hội thoại với khách hàng, không phải luồng phản ứng với sự kiện hạ tầng. Không liên quan tới trạng thái EC2 hay Step Functions.

📌 Điểm cần nhớ

• Thấy trong đề các chữ "each time…", "whenever…", "when X happens then trigger Y" giữa hai dịch vụ AWS → gần như luôn là Amazon EventBridge. Đó là dấu hiệu nhận diện mạnh nhất ở mức Cloud Practitioner.
• Phân biệt rõ ba vai trong một kiến trúc tự động hoá: EventBridge phát hiện và định tuyến sự kiện, Step Functions điều phối các bước theo thứ tự, Fargate/Lambda thực thi công việc. Đề thường đã cho sẵn hai vai và hỏi vai còn thiếu — hãy xác định vai nào đang trống trước khi chọn.
• Một dịch vụ dùng được trong workflow không có nghĩa là nó khởi động được workflow. Fargate sai chính vì lý do này.
• Loại nhanh những phương án thuộc lĩnh vực khác hẳn (SageMaker – ML, Connect – contact center). Biết mỗi dịch vụ AWS thuộc nhóm nào thường đủ để rút danh sách xuống còn hai lựa chọn thật.

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

Đề mô tả một tổ chức vừa chuyển lên AWS và muốn bật intelligent threat protection cùng continuous monitoring trên toàn bộ các account của họ. Câu hỏi yêu cầu chọn đúng một dịch vụ AWS.

Cụm từ quyết định là "intelligent threat protection and continuous monitoring across all its accounts". Cần tách nó ra làm ba ý, vì cả bốn phương án đều là dịch vụ bảo mật và rất dễ nhầm:

• threat detection — phát hiện hoạt động độc hại, chứ không phải điều tra sau sự cố, không phải chống DDoS, không phải phân loại dữ liệu nhạy cảm.
• continuous monitoring — chạy nền liên tục, tự động, không cần ai bấm nút mỗi lần.
• across all accounts — phạm vi nhiều account, tức là dịch vụ phải có mô hình quản lý tập trung nhiều account.

Ai bám vào ba ý này thì loại được ngay ba phương án còn lại; ai chỉ đọc lướt thấy "security" thì phương án nào cũng thấy hợp lý.

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

Đáp án đúng theo tệp là C – Amazon GuardDuty.

GuardDuty là dịch vụ threat detection của AWS: nó liên tục giám sát các AWS account và workload để tìm hoạt động độc hại hoặc hành vi bất thường, rồi phát ra security findings chi tiết để đội bảo mật nhìn thấy và xử lý. Đúng ba ý của đề:

• Intelligent — GuardDuty phân tích để nhận ra hành vi đáng ngờ chứ không chỉ so khớp một danh sách luật cứng do người dùng khai.
• Continuous monitoring — bật lên là chạy nền liên tục, không phải quét theo yêu cầu từng lần.
• Across all accounts — GuardDuty có mô hình account quản trị/thành viên, cho phép bật và theo dõi tập trung cho nhiều account cùng lúc.

Đây là dịch vụ chủ động phát hiện mối đe doạ, và đó chính là điều đề hỏi.

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

A – Amazon Detective. Đây là phương án gần đúng nhất và cũng là bẫy chính. Detective tự động thu thập log từ các tài nguyên AWS và dùng machine learning, phân tích thống kê cùng lý thuyết đồ thị để dựng một tập dữ liệu liên kết, giúp điều tra sự cố bảo mật nhanh và hiệu quả hơn. Chỗ nó hỏng: Detective không chủ động phát hiện mối đe doạ. Nó là công cụ dùng sau khi đã có một finding — thường là finding do chính GuardDuty sinh ra — để trả lời câu hỏi "chuyện gì đã xảy ra". Đề hỏi cái sinh ra cảnh báo, không phải cái để đào sâu cảnh báo.

B – AWS Shield. Shield là dịch vụ được quản lý dùng để phòng chống và giảm nhẹ tấn công DDoS. Nó chỉ phủ một loại tấn công duy nhất ở tầng mạng/ứng dụng đối với tài nguyên đang phục vụ ngoài Internet, chứ không làm nhiệm vụ phát hiện mối đe doạ thông minh theo từng account như đề mô tả. Người dùng bị hớ ở đây thường vì thấy "protection" trong đề mà quên rằng đề còn đòi continuous monitoring across all accounts.

D – Amazon Macie. Macie là dịch vụ được quản lý hoàn toàn về bảo mật và quyền riêng tư dữ liệu: nó dùng machine learning và so khớp mẫu để phát hiện và bảo vệ dữ liệu nhạy cảm trong AWS. Nó cũng có yếu tố "machine learning" nên trông giống "intelligent", nhưng đối tượng nó soi là nội dung dữ liệu, không phải hành vi độc hại trong account. Hai bài toán khác hẳn nhau — Macie không đứng ở vị trí của GuardDuty.

📌 Điểm cần nhớ

• Nhớ theo động từ chính của từng dịch vụ: GuardDuty detect (phát hiện mối đe doạ), Detective investigate (điều tra sau khi có finding), Shield mitigate DDoS, Macie discover sensitive data. Đề hỏi động từ nào thì chọn dịch vụ ứng với động từ đó.
• Cặp GuardDuty ↔ Detective là bẫy kinh điển và chúng bổ trợ nhau chứ không thay thế nhau: GuardDuty sinh ra finding, Detective giúp đào sâu finding đó. Thấy "detect / continuous monitoring" thì chọn GuardDuty; thấy "investigate / root cause / phân tích sau sự cố" thì chọn Detective.
• Đừng để "machine learning" trong mô tả dẫn dắt — cả Macie và Detective đều dùng ML. Thứ phân biệt là đối tượng được soi: hành vi trong account (GuardDuty) hay nội dung dữ liệu nhạy cảm (Macie).
• Cụm "across all accounts" trong đề thi Cloud Practitioner thường là tín hiệu chỉ tới dịch vụ có mô hình quản lý tập trung nhiều account, và GuardDuty là dịch vụ threat detection nằm ở nhóm đó.

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

Đề hỏi: Amazon EC2 Auto Scaling giúp gì cho tính resiliency (khả năng chịu lỗi, phục hồi)?

Cụm từ quyết định đáp án là "How does ... help with resiliency" — tức là hỏi cơ chế hoạt động cốt lõi của EC2 Auto Scaling, chứ không hỏi "kết quả cuối cùng người dùng nhận được". Đây là dạng câu rất dễ sập bẫy, vì cả bốn phương án đều mô tả những việc có thật trong một kiến trúc AWS có tính sẵn sàng cao — nhưng chỉ một việc do chính EC2 Auto Scaling làm, ba việc còn lại thuộc về dịch vụ khác hoặc là thao tác thủ công.

Chìa khoá thứ hai nằm ở chính cái tên dịch vụ: Auto Scaling làm việc với số lượng instance (scale out / scale in). Bất kỳ phương án nào nói về loại instance, về phân phối kết nối, hay về failover ứng dụng đều đang mô tả một trách nhiệm khác.

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

C — "By launching and terminating instances as needed" là đáp án đúng.

EC2 Auto Scaling theo dõi nhu cầu và tự khởi tạo thêm instance khi tải tăng, tự chấm dứt instance khi tải giảm. Liên quan trực tiếp tới resiliency là cấu hình minimum capacity: Auto Scaling group được đặt số instance tối thiểu, nên khi một instance chết hoặc trượt health check, nhóm sẽ tự thay thế bằng instance mới để luôn giữ đủ số lượng đang chạy. Đó chính là cơ chế "tự lành" (self-healing) — không cần con người can thiệp, ứng dụng vẫn có đủ máy phục vụ.

Nói gọn: Auto Scaling bảo đảm luôn có đúng số lượng EC2 instance khoẻ mạnh cho khối lượng công việc, và đó là cách nó đóng góp cho tính resiliency lẫn high availability.

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

A — "By automating the failover of applications" Auto Scaling không làm failover ở tầng ứng dụng. Failover là việc chuyển hoạt động sang một bản dự phòng đã dựng sẵn (ví dụ một database standby, hay một endpoint khác), và nó giữ nguyên trạng thái/dữ liệu của ứng dụng. Auto Scaling thì chỉ thêm hoặc bớt instance — instance mới khởi tạo là một máy mới tinh, không "tiếp quản" phiên làm việc của instance cũ. Phương án này nghe rất hợp tai vì cả hai đều liên quan tới resiliency, nhưng nó gán cho Auto Scaling một trách nhiệm nó không có.

B — "By changing instance types to increase capacity" Đây là phương án gần đúng nhất và cũng là bẫy chính. Auto Scaling đúng là tăng capacity, nhưng bằng cách tăng số lượng instance (scale ngang), không bằng cách đổi loại instance (scale dọc). Muốn dùng instance type lớn hơn, bạn phải tự tạo launch configuration / launch template mới rồi cập nhật cho Auto Scaling group — đó là thao tác của người vận hành, không phải hành vi tự động của dịch vụ. Phương án này hỏng ở đúng một chữ: "instance types" thay vì "number of instances".

D — "By distributing connections to EC2 instances" Việc phân phối kết nối đến các instance là nhiệm vụ của Elastic Load Balancer (ELB), không phải Auto Scaling. Hai dịch vụ này thường đi cùng nhau và được dạy chung một bài, nên rất dễ lẫn: Auto Scaling quyết định có bao nhiêu instance, ELB quyết định request nào đi vào instance nào. Auto Scaling group có thể được gắn vào một target group của ELB, nhưng bản thân nó không định tuyến traffic.

📌 Điểm cần nhớ

• EC2 Auto Scaling = số lượng instance. Nó launch và terminate instance, không đổi instance type. Scale ngang, không scale dọc.
• Auto Scaling và ELB là cặp đôi nhưng khác việc: Auto Scaling lo bao nhiêu máy, Elastic Load Balancer lo chia traffic cho máy nào. Câu nào nhắc "distributing connections/traffic" thì đáp án là ELB.
• Resiliency của Auto Scaling đến từ minimum capacity: instance hỏng sẽ bị thay thế tự động để nhóm luôn đủ số lượng — đây là self-healing, không phải failover ứng dụng.
• Với câu hỏi kiểu "dịch vụ X giúp gì", hãy loại ngay những phương án mô tả công việc của dịch vụ khác trong cùng kiến trúc; đề thi Cloud Practitioner rất hay ghép các dịch vụ hay đi chung để làm nhiễu.

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

Đề hỏi: IAM entity nào được gắn với một access key ID và secret access key?

Cụm từ quyết định là "access key ID and secret access key" — tức là cặp khoá dùng để ký các request lập trình tới AWS (AWS CLI, SDK, gọi trực tiếp API). Đây là loại thông tin xác thực (credential) dài hạn, được cấp phát và gắn trực tiếp cho một danh tính cụ thể.

Cụm từ thứ hai đáng chú ý là "IAM entity". Trong IAM, không phải thứ gì cũng là một danh tính có thể mang credential: có những thứ chỉ là tài liệu quyền hạn hoặc cách gom nhóm. Vì vậy câu hỏi thực chất là: trong bốn thứ này, thứ nào là một danh tính có thể sở hữu credential dài hạn của riêng nó?

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

Đáp án đúng theo tệp là C — IAM User.

Access key ID và secret access key được tạo ra và gắn cho một IAM user cụ thể. Khi bạn gọi AWS bằng CLI hoặc SDK, cặp khoá này được dùng để ký request, và AWS dựa vào access key ID để biết request đến từ IAM user nào, rồi áp các policy gắn cho user đó (trực tiếp hoặc thừa kế qua group).

Nói cách khác: IAM user là danh tính lâu dài duy nhất trong bốn phương án có thể sở hữu credential riêng — cả mật khẩu đăng nhập console lẫn access key cho truy cập lập trình. Ba phương án còn lại đều không phải là chỗ để đặt một cặp khoá cố định.

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

A — IAM Role. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Role đúng là một IAM entity và đúng là có liên quan tới credential — nhưng credential của role là tạm thời, do STS cấp khi có ai đó assume role, và gồm ba phần: access key ID, secret access key và một session token, kèm thời hạn hết hiệu lực. Bạn không tạo được một cặp access key cố định gắn thẳng vào role như với user. Đề bài chỉ nhắc tới access key ID + secret access key, tức là cặp khoá dài hạn — đó là dấu hiệu của IAM user, không phải role.

B — IAM Policy. Policy hoàn toàn không phải là một danh tính. Nó chỉ là tài liệu JSON mô tả quyền: cho phép hay từ chối hành động nào, trên tài nguyên nào, trong điều kiện nào. Policy được gắn vào user, group hoặc role để trao quyền cho chúng, chứ bản thân nó không đăng nhập, không gọi API, và vì thế không có credential nào để mà mang.

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

D — IAM Group. Group chỉ là cách gom nhiều IAM user lại để quản lý quyền hàng loạt — gắn policy một lần cho group thay vì gắn lặp lại cho từng user. Group không phải là một danh tính có thể xác thực: bạn không thể "đăng nhập với tư cách một group", cũng không thể tạo access key cho group. Credential luôn thuộc về từng user thành viên; group chỉ ảnh hưởng tới việc user đó được phép làm gì sau khi đã xác thực.

📌 Điểm cần nhớ

• Chỉ IAM user mới có credential dài hạn (mật khẩu console và/hoặc access key ID + secret access key). Thấy đề nhắc "access key ID and secret access key" mà không nói gì thêm → nghĩ ngay tới IAM user.
• Role dùng credential tạm thời qua STS, và luôn có thêm session token. Nếu đề nhắc tới session token hoặc từ "temporary" thì đáp án nghiêng về role chứ không phải user.
• Policy là quyền, không phải danh tính. Nó được gắn vào user/group/role, tự nó không xác thực được.
• Group là công cụ quản lý quyền, không phải danh tính xác thực. Không có credential, không assume được, không đăng nhập được.

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

Đề hỏi: thành phần hoặc dịch vụ nào của AWS cho phép lưu lượng đi vào (inbound) từ Internet tiếp cận được một VPC?

Cụm từ quyết định đáp án là "inbound traffic from the internet" — lưu lượng khởi phát từ Internet công cộng đi vào VPC. Hai chi tiết cần tách bạch:

• Hướng của kết nối: đi vào (inbound, do bên ngoài khởi tạo), chứ không phải đi ra (outbound, do instance bên trong khởi tạo).
• Nguồn của lưu lượng: từ Internet, chứ không phải từ mạng riêng của doanh nghiệp qua đường hầm mã hoá.

Cả bốn phương án đều là thành phần mạng gắn với VPC, nên chỉ khi khoá chặt hai chi tiết trên mới loại được các phương án gần giống nhau.

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

A. Internet gateway — đây là thành phần được attach vào VPC và cho phép lưu lượng từ Internet đi vào VPC. Internet gateway là cửa ngõ hai chiều giữa VPC và Internet công cộng: nó chấp nhận lưu lượng inbound hướng tới các tài nguyên có địa chỉ IP công cộng trong VPC, đồng thời cũng đóng vai trò target trong route table cho lưu lượng outbound đi ra Internet.

Đúng theo phần giải thích gốc của đề: chỉ Internet gateway mới mở được đường cho kết nối do bên ngoài khởi tạo đi vào VPC. Một subnet chỉ được coi là public subnet khi route table của nó trỏ đường ra Internet vào Internet gateway.

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

B. Virtual Private Gateway (VGW) — đây là phương án gần đúng nhất về mặt "cho phép truy cập từ ngoài vào VPC", nên dễ mắc bẫy. Điểm hỏng: VGW là đầu phía AWS của một kết nối IPSec VPN (và cũng dùng cho Direct Connect). Lưu lượng đi qua nó đến từ mạng riêng on-premises qua đường hầm mã hoá, không phải từ Internet công cộng theo nghĩa đề đang hỏi. Nói cách khác VGW mở đường cho mạng riêng của bạn, không mở VPC ra cho Internet.

C. VPC Route Table — route table chỉ định tuyến lưu lượng bên trong VPC: nó quyết định gói tin đi tới target nào (local, Internet gateway, NAT gateway…). Bản thân nó không phải là cửa ngõ, không tự tạo ra kết nối tới Internet. Nếu VPC không có Internet gateway thì dù viết route thế nào cũng chẳng có gì để trỏ tới. Route table là thứ chỉ đường, còn Internet gateway mới là cánh cửa.

D. NAT Gateway — sai vì ngược hướng. NAT gateway phục vụ instance nằm trong private subnet cần đi ra Internet (ví dụ tải bản vá, gọi API bên ngoài), và nó cố ý không cho phép kết nối do bên ngoài khởi tạo đi vào. Đây chính là lý do người ta đặt NAT gateway: có outbound mà không lộ instance ra Internet. Ngoài ra chính NAT gateway lại phải đặt trong public subnet và dựa vào Internet gateway để ra được ngoài — nó là khách hàng của Internet gateway, không phải thứ thay thế.

📌 Điểm cần nhớ

• Internet gateway = inbound + outbound với Internet công cộng; NAT gateway = chỉ outbound cho private subnet. Đọc thấy chữ "inbound from the internet" là gần như chốt được Internet gateway.
• Virtual Private Gateway thuộc nhóm kết nối lai (hybrid): VPN IPSec / Direct Connect từ mạng on-premises, không liên quan tới việc mở VPC ra Internet.
• Route table không mở đường, chỉ chỉ đường. Nó cần một target (Internet gateway, NAT gateway, VGW…) mới có tác dụng — bản thân nó không bao giờ là câu trả lời cho câu hỏi "cái gì cho phép truy cập".
• Public subnet không phải một loại subnet riêng: nó chỉ là subnet có route trỏ ra Internet gateway. Đây là mấu chốt phân biệt public/private subnet trong nhiều câu hỏi khác cùng chủ đề.

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

Đề mô tả một công ty đang dùng AWS Direct Connect và muốn thiết lập kết nối across multiple AWS Regions using VPCs — tức là nối các VPC nằm ở nhiều Region khác nhau lại với nhau.

Cụm từ quyết định đáp án là "across multiple AWS Regions" kết hợp với "using VPCs". Hai vế này phải đọc cùng nhau:

• "using VPCs" loại ngay những dịch vụ không làm việc ở tầng kết nối mạng giữa các VPC.
• "across multiple Regions" là ràng buộc phân biệt thật sự — nó loại nốt những dịch vụ có kết nối riêng tư nhưng phạm vi bó trong một Region.

Chi tiết "AWS Direct Connect is used by a company" chỉ là bối cảnh: công ty đã có đường kết nối riêng từ on-premises vào AWS, giờ cần một chỗ trung tâm để đấu nối các VPC ở nhiều Region. Nó không phải là thứ cần chọn, vì Direct Connect không nằm trong danh sách phương án.

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

C — AWS Transit Gateway.

Transit Gateway đóng vai trò central hub nối các VPC và mạng on-premises lại với nhau. Thay vì phải dựng quan hệ peering chằng chịt giữa từng cặp VPC (số kết nối tăng rất nhanh theo số VPC), mỗi mạng chỉ cần đấu một lần vào Transit Gateway — nó hoạt động như một cloud router trong mạng của bạn.

Điểm khớp trực tiếp với đề là inter-Region peering: khi hệ thống mở rộng ra toàn cầu, các Transit Gateway ở những Region khác nhau có thể peering với nhau qua AWS global network. Lưu lượng giữa chúng được mã hoá tự động và không đi qua public internet. Đây đúng là thứ đề yêu cầu: kết nối VPC xuyên nhiều Region, trên nền một công ty đã dùng Direct Connect.

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

A — Amazon Route 53. Đây là dịch vụ DNS có tính sẵn sàng cao và khả năng mở rộng tốt, kèm chức năng đăng ký tên miền. Route 53 phân giải tên thành địa chỉ, tức là giúp client tìm ra endpoint — nó không tạo ra đường mạng giữa các VPC. Có thể có người nhầm vì Route 53 làm việc ở phạm vi toàn cầu và hay xuất hiện trong các kiến trúc multi-Region, nhưng vai trò ở đó là điều hướng lưu lượng theo tên miền, không phải đấu nối VPC.

B — AWS PrivateLink. Đây là phương án gần đúng nhất và là chỗ dễ mất điểm. PrivateLink thật sự cung cấp kết nối riêng tư giữa các VPC, tới AWS services và tới mạng on-premises — nghe rất khớp với vế "using VPCs". Chỗ nó hỏng nằm ở đúng ràng buộc phân biệt của đề: PrivateLink không làm việc này xuyên nhiều Region. Ngoài ra mô hình của PrivateLink là expose một service qua endpoint theo kiểu consumer–provider, chứ không phải nối toàn bộ mạng của các VPC lại với nhau như một router trung tâm. Đề hỏi kết nối mạng đa Region, nên PrivateLink trượt.

D — Amazon Connect. Bẫy tên gọi thuần tuý: chữ "Connect" khiến nó trông như một dịch vụ kết nối mạng. Thực tế Amazon Connect là dịch vụ contact center (tổng đài chăm sóc khách hàng) dạng đám mây — hoàn toàn không liên quan gì tới việc nối VPC.

📌 Điểm cần nhớ

• Thấy từ khoá "multiple VPCs" + "central hub" / "simplify peering" → nghĩ ngay tới AWS Transit Gateway. Thấy thêm "multiple Regions" → là inter-Region peering của Transit Gateway.
• PrivateLink ≠ Transit Gateway. PrivateLink cho truy cập riêng tư tới một dịch vụ, phạm vi không trải qua nhiều Region; Transit Gateway nối mạng với nhau và có peering xuyên Region.
• Route 53 là DNS — phân giải tên, định tuyến theo tên miền. Nó không bao giờ là câu trả lời cho một câu hỏi về kết nối tầng mạng giữa các VPC.
• Cẩn thận với bẫy tên gọi: Amazon Connect là contact center, khác hẳn AWS Direct Connect. Trong đề thi AWS, tiền tố và tên đầy đủ luôn cần đọc kỹ.

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

Đề hỏi: dịch vụ AWS nào giúp tách rời (decouple) các thành phần của ứng dụng để chúng chạy độc lập với nhau?

Cụm từ quyết định đáp án là "decouples application components so that they can run independently". Hai chữ khoá cần tách bạch:

• decouple — thành phần gửi và thành phần nhận không cần biết nhau, không cần cùng online, không cần cùng tốc độ xử lý.
• run independently — bên gửi xong việc là đi tiếp, không đứng chờ bên nhận; bên nhận sập rồi bật lại vẫn lấy được việc còn tồn.

Đây là mô tả kinh điển của message queue: có một chỗ chứa trung gian giữ lại thông điệp cho tới khi bên nhận lấy đi và xử lý xong. Trong bốn phương án, chỉ một dịch vụ là hàng đợi thông điệp. Ba phương án còn lại lần lượt là điều phối luồng công việc, gửi thông báo, và tích hợp dữ liệu — mỗi cái thuộc một họ khác hẳn.

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

A — Amazon Simple Queue Service (Amazon SQS) là dịch vụ hàng đợi thông điệp được quản lý hoàn toàn, sinh ra đúng cho việc decouple và scale microservices, hệ phân tán và ứng dụng serverless.

Cơ chế: thành phần producer đẩy message vào queue rồi trả về ngay; thành phần consumer tự lấy message ra khi nó rảnh. Hệ quả đúng như đề mô tả:

• Producer không cần biết consumer là ai, có bao nhiêu instance, đang chạy hay đang khởi động lại.
• Consumer chậm hơn producer thì message nằm lại trong queue chứ không làm nghẽn producer — queue đóng vai bộ đệm hấp thụ tải đột biến.
• Scale hai bên độc lập: thêm consumer để xử lý nhanh hơn mà không đụng gì tới producer.

SQS còn bỏ đi toàn bộ gánh nặng vận hành message-oriented middleware (dựng máy chủ hàng đợi, vá lỗi, lo độ sẵn sàng) — đó là phần "fully managed" mà bản giải thích gốc nhấn mạnh.

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

B — AWS Glue. Đây là dịch vụ tích hợp dữ liệu serverless: khám phá, chuẩn bị và kết hợp dữ liệu phục vụ analytics, machine learning và phát triển ứng dụng (crawler, data catalog, job ETL). Nó làm việc với dữ liệu, không phải với kiến trúc giao tiếp giữa các thành phần. Glue không hề tách rời các component của ứng dụng — đây là phương án lạc đề rõ nhất trong bốn cái.

C — Amazon Simple Workflow Service (Amazon SWF). Đây là phương án gần đúng nhất và dễ bẫy nhất, vì SWF cũng nằm trong nhóm application integration và cũng có "task" chuyển qua lại giữa các thành phần. Nhưng vai trò của SWF là điều phối (coordinate) và theo dõi trạng thái của các background job có nhiều bước tuần tự hoặc song song — nó là state tracker và task coordinator, tức là nó biết và nắm giữ toàn bộ trình tự công việc. Đó là quan hệ ngược với decouple: SWF gắn các bước lại thành một quy trình có thứ tự, có trạng thái, chứ không phải để mỗi thành phần chạy độc lập không biết gì về nhau. Khi đề nhấn "run independently" mà không nói gì tới trình tự, nhiều bước, hay theo dõi trạng thái, thì SWF là đáp án sai.

D — Amazon Simple Notification Service (Amazon SNS). Cũng rất dễ nhầm vì SNS là dịch vụ messaging và cũng theo mô hình pub/sub. Nhưng SNS là dịch vụ thông báo cho cả giao tiếp application-to-application (A2A) lẫn application-to-person (A2P — email, SMS, push). Điểm hỏng khi so với đề: SNS đẩy (push) thông điệp tới subscriber tại thời điểm phát; nó không phải nơi giữ lại việc cho consumer tự lấy khi rảnh. Không có lớp đệm giữ việc thì bên nhận vẫn phụ thuộc vào nhịp của bên gửi — nên theo bản giải thích gốc, SNS không trực tiếp decouple các thành phần ứng dụng như SQS.

📌 Điểm cần nhớ

• Thấy từ khoá "decouple" trong đề thi Cloud Practitioner, phản xạ đầu tiên là Amazon SQS — hàng đợi giữ message lại chính là thứ cắt đứt ràng buộc thời gian giữa producer và consumer.
• Phân biệt ba dịch vụ hay đứng chung một câu: SQS = hàng đợi, bên nhận kéo việc về, có bộ đệm; SNS = thông báo, đẩy tới subscriber (gồm cả người dùng qua email/SMS); SWF = điều phối quy trình nhiều bước và theo dõi trạng thái.
• Dịch vụ nào nắm giữ trình tự công việc (như SWF) thì làm ngược lại mục tiêu decouple — decouple nghĩa là các thành phần không cần biết về nhau.
• AWS Glue thuộc họ dữ liệu/ETL, không thuộc họ application integration; nó xuất hiện trong câu này chỉ để làm nhiễu.