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

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

Đề đặt bối cảnh một quản trị viên hệ thống mới vào làm ở công ty dịch vụ y tế, và bộ phận IT đang rà lại checklist các việc liên quan tới AWS Identity and Access Management. Câu hỏi yêu cầu chọn hai best practice nên khuyến nghị.

Cụm từ quyết định đáp án là "best practices ... related to AWS Identity and Access Management" và "(Select two)". Đây không phải câu hỏi tình huống đòi tính toán hay so sánh kiến trúc — nó kiểm tra xem bạn có thuộc bộ khuyến nghị chuẩn của AWS về IAM hay không. Vì vậy cách làm là đọc từng phương án và hỏi: AWS có khuyến nghị điều này, hay AWS khuyến nghị điều ngược lại? Ba phương án trong danh sách phát biểu đúng mặt trái của một khuyến nghị nổi tiếng, nên chúng tự loại.

Chi tiết "healthcare services company" chỉ là màu sắc bối cảnh (gợi ý dữ liệu nhạy cảm, cần audit), không thay đổi đáp án.

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

B — Enable MFA for privileged users. AWS khuyến nghị bật Multi-Factor Authentication cho những người dùng có quyền cao, qua thiết bị di động hỗ trợ MFA hoặc hardware MFA token. Lý do: mật khẩu hoặc access key có thể bị lộ, bị đoán, bị dùng lại từ nơi khác; MFA thêm một yếu tố thứ hai nên chỉ biết mật khẩu là chưa đủ để đăng nhập. Quyền càng lớn thì thiệt hại khi mất credential càng lớn, nên đây chính là nhóm cần MFA nhất.

D — Configure AWS CloudTrail to log all IAM actions. AWS khuyến nghị bật CloudTrail để ghi lại toàn bộ hoạt động của tài khoản, bao gồm các hành động IAM, phục vụ monitoring và audit. Không có bản ghi này thì khi có sự cố bạn không trả lời được ai đã tạo user nào, gắn policy gì, vào lúc nào — đúng thứ mà một công ty y tế cần cho việc tuân thủ.

Hai phương án này bổ sung cho nhau theo hai hướng: B là phòng ngừa (ngăn truy cập trái phép), D là phát hiện và truy vết (biết chuyện gì đã xảy ra).

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

A — Grant maximum privileges to avoid assigning privileges again. Đây là phát biểu ngược hẳn với nguyên tắc least privilege: AWS khuyến nghị chỉ cấp đúng quyền tối thiểu cần để hoàn thành công việc. Cấp quyền dư để "khỏi phải cấp lại sau" là đánh đổi bảo mật lấy sự tiện tay của admin — và quyền dư đó có thể bị lạm dụng, hoặc bị kẻ tấn công tận dụng nếu credential rơi vào tay họ.

C — Use user credentials to provide access specific permissions for Amazon EC2 instances. Đây là phương án gần đúng nhất vì nó đúng ở mục tiêu (cấp quyền cho EC2 instance truy cập các dịch vụ AWS khác) nhưng sai ở cơ chế. AWS khuyến nghị dùng role cho EC2 chứ không nhúng credential của IAM user vào instance. Credential tĩnh nằm trên máy phải được lưu ở đâu đó, dễ lọt vào image, file cấu hình hay source code, và phải xoay vòng thủ công; role thì cấp credential tạm thời và tự động luân chuyển.

E — Create a minimum number of accounts and share these account credentials among employees. Cũng gần đúng ở nửa đầu — nghe như đang "giảm bề mặt tấn công" bằng cách bớt tài khoản — nhưng nửa sau phá hỏng tất cả: AWS khuyến nghị không chia sẻ credential giữa các người dùng. Dùng chung tài khoản làm mất khả năng quy trách nhiệm: CloudTrail vẫn ghi log nhưng mọi hành động đều mang tên một danh tính chung, không biết người thật là ai; và khi một người nghỉ việc thì phải đổi credential cho tất cả những người còn lại.

📌 Điểm cần nhớ

• Câu hỏi dạng "IAM best practices" thường có các phương án sai được viết như mệnh đề đảo của một khuyến nghị chuẩn (maximum privileges ↔ least privilege, share credentials ↔ mỗi người một danh tính, user credentials trên EC2 ↔ dùng role). Nhận ra thế đảo là loại được ngay.
• Least privilege là mặc định: thấy phương án nào nói cấp quyền rộng cho tiện thì loại, bất kể lý do nghe hợp lý tới đâu.
• Workload dùng role, con người dùng user + MFA. Bất cứ khi nào đề nói tới EC2 (hay dịch vụ AWS khác) cần quyền truy cập, đáp án là IAM role với credential tạm thời, không phải access key tĩnh.
• CloudTrail là câu trả lời cho mọi yêu cầu audit / truy vết ai đã làm gì, còn MFA là câu trả lời cho việc bảo vệ tài khoản đặc quyền. Hai thứ này thuộc hai lớp khác nhau (phòng ngừa và phát hiện) nên rất hay cùng xuất hiện trong một câu "select two".
• Danh tính dùng chung phá vỡ tính quy trách nhiệm: log vẫn đầy đủ nhưng vô dụng vì không quy được về người thật.

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

Đề mô tả một công ty dùng CloudFormation template để dựng hạ tầng EC2, VPC và S3. Một stack tên NetworkStack export giá trị subnetId, và câu hỏi là: ở stack khác, phải dùng intrinsic function nào để đọc giá trị đã export đó.

Cụm từ quyết định đáp án nằm gọn ở hai chỗ:

• "cross-stack referencing" và "export the subnetId" — dữ liệu đi qua ranh giới giữa hai stack, chứ không nằm trong cùng một template.
• "To use the exported value in another stack" — vế "in another stack" là ràng buộc phân biệt. Bốn phương án đều là intrinsic function hợp lệ của CloudFormation, nhưng chỉ một cái biết cách với sang stack khác; ba cái còn lại chỉ làm việc trong phạm vi template hiện tại.

Đọc thấy chữ "exported" ở stack nguồn thì phải nghĩ ngay tới hàm đối xứng với nó ở stack đích.

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

Đáp án đúng là B — !ImportValue.

Fn::ImportValue (dạng viết tắt YAML là !ImportValue) trả về giá trị của một output đã được export bởi stack khác. Đây chính là hàm được sinh ra để làm cross-stack reference, và nó là nửa còn lại của cặp cơ chế:

• Stack nguồn (NetworkStack) khai Outputs kèm khối Export.Name để công bố subnetId ra ngoài.
• Stack đích tham chiếu tới đúng cái tên export đó bằng !ImportValue, ví dụ SubnetId: !ImportValue NetworkStack-SubnetId, rồi dùng nó khi tạo EC2 instance.

Không có !ImportValue thì giá trị export kia chỉ nằm im trong tài khoản mà không template nào lấy ra được. Cũng vì cơ chế này, CloudFormation ràng buộc thêm: stack đã export một giá trị đang được import thì không xoá hay đổi giá trị export đó được, cho tới khi bên import thôi dùng — đúng tinh thần "liên kết thật giữa hai stack" mà đề đang mô tả.

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

A — !GetAtt: trả về thuộc tính của một resource khai trong chính template đang chạy, ví dụ !GetAtt MyInstance.PrivateIp. Đây là phương án gần đúng nhất về mặt cảm giác, vì nó cũng "lấy giá trị từ một resource khác". Chỗ nó hỏng: resource đó phải nằm trong cùng template — logical ID mà !GetAtt nhận vào được phân giải trong phạm vi stack hiện tại. Stack đích không hề khai NetworkStack như một resource, nên không có logical ID nào để !GetAtt bám vào.

C — !Ref: trả về giá trị của một parameter hoặc một resource trong template hiện tại. Cũng là phương án dễ nhầm, vì nếu đổi cách thiết kế — bỏ export đi và truyền subnetId vào bằng một Parameter — thì !Ref đúng là hàm để đọc parameter đó. Nhưng đề đã nói rõ là dùng cross-stack referencing với export, không phải truyền tham số bằng tay; và !Ref không biết tới không gian tên export, nên nó không thể lấy giá trị từ NetworkStack.

D — !Sub: thay thế biến trong một chuỗi bằng giá trị bạn cung cấp, ví dụ ghép tên bucket hay dựng một đoạn user data. Bản thân nó là hàm xử lý chuỗi, không phải hàm truy xuất dữ liệu giữa các stack. Nó hay xuất hiện cùng !ImportValue để dựng tên export động (!ImportValue !Sub "${EnvName}-SubnetId"), nhưng vai trò lúc đó chỉ là ghép tên — việc lấy giá trị vẫn do !ImportValue làm. Dùng một mình !Sub thì chỉ ra được một chuỗi, không ra được subnet ID.

📌 Điểm cần nhớ

• Cặp Export ↔ Fn::ImportValue là cơ chế cross-stack chuẩn của CloudFormation: stack nguồn export trong Outputs, stack đích import bằng !ImportValue. Thấy chữ "export/cross-stack" trong đề là gần như chốt được đáp án.
• !Ref và !GetAtt chỉ có tầm nhìn trong template hiện tại: !Ref cho parameter/resource, !GetAtt cho thuộc tính của resource. Cả hai không vượt qua được ranh giới stack.
• !Sub là hàm chuỗi, không phải hàm tra cứu. Nó bổ trợ cho hàm khác chứ không tự lấy được giá trị từ đâu cả.
• Cách đọc đề nhanh cho nhóm câu hỏi intrinsic function: xác định giá trị cần lấy đang nằm ở đâu — cùng template (!Ref, !GetAtt), hay ở stack khác (!ImportValue) — rồi mới chọn hàm.

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

Một công ty truyền thông gom raw video footage (tệp video thô, dung lượng lớn) từ các nhóm phóng viên vào một bucket S3. Sau khi mở rộng sang châu Âu và Úc, các văn phòng ở xa báo cáo "huge delays in uploading large video files" — chậm khi tải tệp lớn lên bucket đích ở xa.

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

• "large video files" — tệp lớn, nên cách chia nhỏ và tải song song có tác dụng trực tiếp.
• "overseas branch offices" — khoảng cách địa lý dài, đường truyền qua Internet công cộng nhiều chặng.
• "MOST cost-effective" — loại thẳng những phương án đòi dựng hạ tầng mạng riêng. Đây là ràng buộc phân biệt A/C với B/E: cả bốn đều "làm mạng nhanh hơn" theo nghĩa nào đó, nhưng chỉ hai cái đầu là tính năng sẵn có của S3, bật lên là dùng.

Thêm một chi tiết: đích đến là S3, không phải ứng dụng chạy trên EC2/ALB/NLB — điều này loại phương án D.

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

A — Multipart upload. Cho phép tải một object lên dưới dạng nhiều part độc lập. Các part được tải song song và theo thứ tự bất kỳ, sau đó S3 ghép lại thành object hoàn chỉnh. Hai lợi ích khớp thẳng với đề: throughput cao hơn nhờ dùng đồng thời nhiều kết nối thay vì một luồng đơn, và nếu một part hỏng giữa chừng thì chỉ cần gửi lại đúng part đó chứ không phải tải lại cả tệp video hàng GB. AWS khuyến nghị cân nhắc multipart khi object đạt cỡ khoảng 100 MB trở lên — đúng khung của raw video footage.

C — S3 Transfer Acceleration. Tận dụng mạng edge location phân tán toàn cầu của CloudFront. Client ở châu Âu hoặc Úc gửi dữ liệu tới edge location gần nhất; từ đó dữ liệu đi tiếp về bucket S3 qua đường mạng backbone đã được tối ưu của AWS thay vì lang thang qua Internet công cộng. Đây chính là tính năng sinh ra để giải quyết bài toán "upload đường dài, tệp lớn" trong đề, và nó chỉ là một công tắc bật trên bucket — không có hạ tầng nào phải dựng.

Hai phương án này bổ trợ nhau: Transfer Acceleration rút ngắn đường đi, multipart upload dùng hết băng thông của đường đi đó.

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

B — Site-to-Site VPN. VPN kết nối an toàn mạng on-premises hoặc văn phòng chi nhánh với VPC qua đường hầm IPSec chạy trên chính Internet công cộng. Vì vẫn đi qua Internet, nó thừa hưởng nguyên độ trễ và độ biến động của Internet — VPN giải quyết bài toán riêng tư và kết nối vào VPC, không giải quyết bài toán tốc độ. Đề hỏi tăng tốc upload, mà VPN không làm gói tin đi nhanh hơn; dựng nhiều đường VPN cho nhiều văn phòng còn thêm chi phí và công vận hành.

D — AWS Global Accelerator. Đây là phương án gần đúng nhất và dễ chọn nhầm, vì nó cũng dùng mạng backbone AWS và cũng đưa traffic vào edge. Nhưng nó hỏng ở chỗ loại endpoint: Global Accelerator cấp địa chỉ IP tĩnh làm điểm vào cố định cho Application Load Balancer, Network Load Balancer, EC2 instance hoặc Elastic IP — tức là endpoint của ứng dụng. S3 bucket không nằm trong danh sách endpoint mà nó hỗ trợ. Đúng nhu cầu "đưa dữ liệu vào S3 nhanh hơn qua edge" thì tên dịch vụ là Transfer Acceleration, không phải Global Accelerator.

E — AWS Direct Connect. Đường mạng vật lý chuyên dụng nối cơ sở của khách hàng tới một Direct Connect location. Nó thật sự cải thiện băng thông và độ ổn định, nên về mặt kỹ thuật không sai — nhưng hỏng ở đúng ràng buộc mà đề nhấn mạnh. Việc kéo cáp và cung cấp đường Direct Connect mất rất nhiều thời gian (tính bằng tháng), chi phí cao và cam kết dài hạn. Dựng nhiều đường như vậy cho các văn phòng chi nhánh chỉ để upload video là overkill, trượt tiêu chí "MOST cost-effective".

📌 Điểm cần nhớ

• Nhìn endpoint để phân biệt Transfer Acceleration với Global Accelerator: đích là S3 bucket → Transfer Acceleration; đích là ALB / NLB / EC2 / Elastic IP → Global Accelerator. Cả hai cùng dùng edge và backbone AWS nên chỉ có endpoint mới tách được chúng.
• Multipart upload là câu trả lời mặc định cho "large file" + "slow upload", kể cả khi không nhắc tới khoảng cách: nó tải song song nhiều part và cho phép gửi lại riêng part hỏng.
• Từ khoá "MOST cost-effective" gần như luôn loại Direct Connect và VPN khi bài toán chỉ là truyền dữ liệu vào S3 — đó là hạ tầng mạng phải dựng, đặt cạnh một tính năng bật-là-dùng thì thua ngay.
• VPN nghĩa là riêng tư, không phải nhanh. Đường hầm IPSec vẫn chạy trên Internet công cộng, nên không giải quyết được vấn đề tốc độ hay độ trễ đường dài.

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

Đề mô tả một IAM user được gắn hai policy cùng lúc:

• Policy thứ nhất: explicitly denied all access to EC2 instances — chặn tường minh mọi quyền trên EC2.
• Policy thứ hai: allowed permission for EC2:Describe — cho phép hành động Describe.

Câu hỏi: khi user gọi Describe qua CLI thì kết quả ra sao?

Cụm từ quyết định đáp án là "explicitly been denied". Đây không phải chuyện thiếu quyền (implicit deny — trạng thái mặc định khi không policy nào nhắc tới hành động đó), mà là một câu Deny được viết ra hẳn hoi trong policy. Trong logic đánh giá policy của IAM, hai loại "không được phép" này có sức nặng khác nhau, và explicit deny là loại mạnh nhất — nó không thể bị bất kỳ Allow nào gỡ bỏ.

Điểm thứ hai cần để ý: cả hai policy đều gắn vào cùng một identity. IAM gom toàn bộ policy áp dụng cho request lại rồi đánh giá một lượt, chứ không chạy tuần tự từng policy như một danh sách rule của firewall.

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

A — The user will be denied access because one of the policies has an explicit deny on it.

Theo tài liệu policy evaluation logic của IAM: khi tập policy áp dụng cho một request chứa cả câu Allow lẫn câu Deny, thì Deny thắng Allow, và request bị từ chối tường minh. Trình tự đánh giá về cơ bản là: mặc định mọi thứ bị từ chối → các câu Allow có thể lật trạng thái đó thành cho phép → nhưng bất kỳ câu Deny nào cũng lật ngược lại và là quyết định cuối cùng.

Ở đây policy thứ nhất deny toàn bộ EC2, mà EC2:Describe nằm trong phạm vi "all access to EC2", nên câu Allow ở policy thứ hai bị vô hiệu. Lệnh CLI sẽ trả về lỗi không đủ quyền (AccessDenied), chứ không trả danh sách instance.

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

B — Thứ tự policy quyết định kết quả. Đây là phương án gần đúng nhất và cũng là bẫy phổ biến nhất, vì nó mượn tư duy từ ACL của network hay rule của firewall — nơi "first match wins" và thứ tự dòng rất quan trọng. IAM không hoạt động như vậy: không có khái niệm thứ tự hay độ ưu tiên giữa các policy gắn vào cùng một principal. Toàn bộ policy áp dụng được gom lại và đánh giá như một tập hợp, kết quả không đổi dù bạn gắn policy nào trước. Nếu thứ tự có ý nghĩa thì việc phân quyền sẽ trở nên không xác định được — đúng điều IAM cố tránh.

C — User được phép vì có explicit allow. Phương án này đảo ngược đúng quy tắc cần nhớ. Explicit allow chỉ thắng được implicit deny (tức là khi không có gì cấm), chứ không thắng nổi explicit deny. Nếu Allow có thể ghi đè Deny, thì mọi rào chắn bảo mật dựng bằng câu Deny — vốn là công cụ chính để đặt giới hạn cứng — đều trở nên vô nghĩa.

D — IAM user rơi vào trạng thái không hợp lệ do policy xung đột. Phát biểu này sai về mặt khái niệm. Có Allow và Deny cùng chạm tới một hành động không phải là lỗi cấu hình — đó là cách dùng bình thường và có chủ đích: cấp quyền rộng rồi khoét ra vài ngoại lệ bị cấm. IAM có quy tắc rõ ràng để xử lý tình huống này nên không hề "xung đột". Tài khoản user cũng không có trạng thái "invalid" nào sinh ra từ nội dung policy; policy sai cú pháp thì bị từ chối ngay lúc lưu, còn ở đây cả hai policy đều hợp lệ.

📌 Điểm cần nhớ

• Thứ tự ưu tiên khi đánh giá policy trong IAM: explicit deny > explicit allow > implicit deny (mặc định). Hễ thấy chữ "explicitly denied" trong đề thì gần như chắc chắn kết quả là bị từ chối.
• Policy trong IAM không có thứ tự. Mọi policy áp dụng cho request được gom lại đánh giá cùng lúc; phương án nào nói "tuỳ policy nào gắn trước" đều là bẫy mượn từ tư duy firewall/ACL.
• Phân biệt implicit deny (không policy nào cho phép — có thể sửa bằng cách thêm Allow) và explicit deny (có câu Deny viết ra — chỉ sửa được bằng cách gỡ chính câu Deny đó).
• Việc một user vừa có Allow vừa có Deny cho cùng hành động là mẫu thiết kế bình thường, không phải trạng thái lỗi — đây chính là cách dựng giới hạn cứng đè lên quyền cấp rộng.

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

Đề hỏi: loại security credential nào CHỈ có thể được tạo bởi AWS Account root user?

Cụm từ quyết định là "can only be generated by the AWS Account root user" — chữ only mới là bản lề. Cả bốn phương án đều là credential hợp lệ và đều tồn tại trong AWS, nên nếu chỉ đọc lướt thành "loại nào root tạo được" thì đáp án nào cũng đúng: root user có toàn quyền, tự nhiên tạo được EC2 key pair, đặt password cho IAM user, hay tạo access key cho IAM user.

Câu hỏi thật sự là: loại nào mà IAM user không thể tạo dù được cấp quyền? Đây là điểm khác biệt quan trọng — hầu hết thao tác trong AWS đều ủy quyền được cho IAM user bằng policy, nhưng có một nhóm nhỏ tác vụ bị khóa cứng ở tài khoản root, không policy nào mở ra được.

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

D — CloudFront Key Pairs.

CloudFront key pair là cặp khóa dùng để ký signed URL (và signed cookie) cho nội dung riêng tư — ví dụ khi bạn phân phối video hay tài liệu mà chỉ người đã trả tiền mới được xem. Trusted signer cầm private key để ký, còn CloudFront giữ public key để xác minh chữ ký trước khi trả nội dung.

Điểm mấu chốt theo đúng nguồn: IAM user không tạo được CloudFront key pair. Việc tạo cặp khóa này gắn với chính AWS account, nên bạn phải đăng nhập bằng root credentials mới làm được. Đây chính là kiểu tác vụ "root-only" mà đề đang nhắm tới — không phải vì thiếu quyền, mà vì cơ chế không cho ủy quyền.

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

A — EC2 Instance Key Pairs. Đây là cặp khóa dùng để truy cập EC2 instance, chẳng hạn SSH vào một Linux instance. Phương án này gần đúng vì cũng mang chữ "key pair", và người ôn thi rất dễ nhầm nó với CloudFront key pair. Nhưng chỗ nó hỏng: EC2 key pair tạo được ngay từ tài khoản IAM user thông thường (miễn có quyền EC2 tương ứng), không cần root. Vậy nó không thỏa chữ only trong đề.

B — IAM User passwords. Password đăng nhập console của IAM user không phải đặc quyền root. Mỗi IAM user đều truy cập được credential của chính mình và tự đổi password khi cần, chưa kể admin IAM cũng đặt lại được cho user khác. Đây là thao tác quản trị danh tính hoàn toàn bình thường, ủy quyền được bằng policy — nên loại.

C — IAM User Access Keys. Access key gồm hai phần: access key ID và secret access key, dùng để ký các request lập trình tới AWS — qua AWS CLI, SDK, hay gọi trực tiếp AWS API. Phương án này cũng gần đúng ở chỗ nó là credential nhạy cảm và người ta hay nghĩ "nhạy cảm thì chắc root mới tạo được". Nhưng thực tế IAM user tự tạo được access key của chính mình, không cần root can thiệp. Sai vì cùng lý do với A và B: không độc quyền cho root.

Tóm lại, ba phương án A, B, C đều trượt ở cùng một chỗ — chúng là những credential mà IAM user hoàn toàn tự xoay xở được.

📌 Điểm cần nhớ

• Với dạng câu có chữ "only", đừng hỏi "root làm được không" (root làm được gần như mọi thứ), mà hỏi "IAM user có làm được không". Nếu IAM user làm được thì phương án đó loại ngay.
• CloudFront key pair là ví dụ kinh điển của tác vụ root-only: dùng để ký signed URL / signed cookie cho nội dung riêng tư trên CloudFront, và IAM user không tạo được.
• Đừng lẫn EC2 instance key pair với CloudFront key pair: cùng chữ "key pair" nhưng khác hẳn mục đích (SSH vào instance so với ký URL phân phối nội dung) và khác hẳn quyền tạo.
• IAM user password và IAM user access key đều thuộc nhóm credential mà chính IAM user quản lý được cho bản thân — access key dùng cho request lập trình (CLI/SDK/API), password dùng cho console.

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

Đề nhắc lại Shared Responsibility Model của AWS rồi hỏi thẳng: việc nào thuộc trách nhiệm của customer?

Cụm từ quyết định nằm ở vế cuối câu dẫn: "the customer is also responsible for securing the resources that he has procured under his AWS account" — tức là mọi thứ nằm bên trong tài nguyên khách hàng thuê, chứ không phải hạ tầng chạy bên dưới. Ranh giới quen thuộc là: AWS lo security of the cloud (phần cứng, mạng vật lý, hypervisor, cơ sở dữ liệu vật lý), còn khách hàng lo security in the cloud (dữ liệu, cấu hình, guest OS nếu có).

Bốn phương án được viết cố ý cho giống nhau, nên phải đọc kỹ hai chi tiết: (1) chủ ngữ là AWS hay customer, và (2) dịch vụ được nhắc tới thuộc nhóm IaaS hay abstracted service. Chỉ cần một trong hai chi tiết lệch là phương án sai.

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

D — For Amazon EC2 service, managing guest operating system (including updates and security patches), application software and Security Groups is the responsibility of the customer.

EC2 được xếp vào nhóm IaaS. AWS chỉ cung cấp lớp hạ tầng và ảo hoá; từ guest OS trở lên là phần khách hàng tự dựng, nên cũng tự chịu trách nhiệm bảo mật. Cụ thể theo đúng cách AWS diễn đạt:

• Guest operating system — cài đặt, cập nhật, vá lỗi bảo mật đều do customer làm.
• Application software / utilities khách hàng tự cài lên instance.
• Security Groups — đây là firewall do AWS cung cấp, nhưng việc cấu hình nó (mở cổng nào, cho nguồn nào) là của customer.

Điểm mấu chốt: AWS cấp công cụ, khách hàng cấu hình công cụ. Cấu hình sai Security Group để mở cổng 22 ra 0.0.0.0/0 là lỗi của khách hàng, không phải của AWS.

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

A — AWS is responsible for training their customers and their employees as part of Customer Specific training. Ở hạng mục Awareness & Training, AWS đào tạo nhân viên của AWS. Mỗi khách hàng phải tự đào tạo nhân viên của mình. Phương án này đảo chủ ngữ, gán cả phần huấn luyện nội bộ của khách hàng sang cho AWS. Ngoài ra nó còn sai về mặt logic của câu hỏi: đề hỏi trách nhiệm của customer, mà phương án lại mô tả trách nhiệm của AWS.

B — AWS is responsible for patching and fixing flaws within the infrastructure, for patching the guest Operating Systems and applications of the customers. Đây là phương án gần đúng nhất và là bẫy chính. Vế đầu hoàn toàn chính xác: AWS đúng là vá lỗi trong lớp hạ tầng. Nhưng vế sau — "patching the guest Operating Systems and applications of the customers" — thì sai. AWS không có quyền và cũng không có nghĩa vụ đụng vào guest OS bên trong EC2 instance của khách hàng; đó chính là phần mà đáp án D nói là của customer. Một mệnh đề đúng ghép với một mệnh đề sai thì cả phương án sai. Và giống A, phương án này mô tả trách nhiệm của AWS chứ không trả lời đúng câu hỏi.

C — For Amazon S3 service, managing the operating system and platform is customer responsibility. Chủ ngữ đã đúng (customer), nhưng chọn nhầm loại dịch vụ. S3 là abstracted service: AWS vận hành cả lớp hạ tầng, cả operating system và platform; khách hàng chỉ tương tác qua endpoint để ghi/đọc dữ liệu. Với S3, phần thuộc về customer là quản lý dữ liệu (bao gồm lựa chọn mã hoá), phân loại tài sản, và dùng IAM để cấp quyền phù hợp — chứ hoàn toàn không có khái niệm "quản lý OS của S3". Đây đúng là điểm đối lập với EC2 mà đề muốn kiểm tra.

📌 Điểm cần nhớ

• AWS: security of the cloud — Customer: security in the cloud. Đọc phương án thì soi chủ ngữ trước: đề hỏi trách nhiệm của customer mà phương án bắt đầu bằng "AWS is responsible…" thì gần như chắc chắn loại.
• Ranh giới trách nhiệm dịch chuyển theo loại dịch vụ. Với IaaS như EC2, khách hàng gánh từ guest OS trở lên. Với abstracted service như S3, AWS gánh luôn OS và platform, khách hàng chỉ còn dữ liệu, mã hoá và IAM.
• Patching bị chia đôi: AWS vá hạ tầng, customer vá guest OS và ứng dụng của mình. Phương án nào gộp cả hai về một phía đều sai.
• Security Group là của khách hàng cấu hình. AWS cung cấp cơ chế firewall, còn luật mở/đóng cổng do customer đặt — sai sót ở đây không được tính là lỗi của AWS. Tương tự với đào tạo: AWS đào tạo người của AWS, khách hàng đào tạo người của khách hàng.

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

Đề mô tả một công ty IT lớn dùng nhiều AWS account cho các mảng kinh doanh khác nhau, và vấn đề lặp đi lặp lại là chia sẻ Customer Master Key (CMK) giữa các account để truy cập tài nguyên nằm rải rác ở nhiều account.

Cụm từ quyết định là "sharing Customer Master Keys (CMKs) across multiple AWS accounts" — tức là cùng một CMK do một account sở hữu, nhưng người dùng ở account khác phải gọi được nó. Chữ Customer Master Key cũng loại ngay những phương án nói tới loại key mà khách hàng không kiểm soát. Ngoài ra chonNhieuDapAn là false: chỉ một phương án đúng, nên phương án nào mô tả đủ cả cơ chế cấp quyền cross-account của KMS sẽ thắng những phương án chỉ mô tả một nửa.

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

Đáp án đúng theo tệp là A: key policy của CMK phải cấp quyền cho external account (hoặc cho các user/role trong account đó) được dùng CMK, và IAM policy trong external account phải uỷ quyền lại (delegate) các quyền đó cho user/role của mình.

Đây chính là mô hình hai lớp mà AWS KMS yêu cầu cho truy cập cross-account:

1. Key policy nằm ở account sở hữu CMK. Với KMS, key policy là nguồn quyền gốc — không có dòng nào trong key policy mở cho account bên ngoài thì mọi IAM policy ở phía bên kia đều vô nghĩa.
2. IAM policy nằm ở external account, cấp cho từng user/role cụ thể quyền gọi các thao tác KMS (kms:Encrypt, kms:Decrypt, kms:GenerateDataKey…) trên ARN của CMK đó.

Quyền hiệu lực là giao của hai lớp: account chủ mở cửa, account khách chỉ định ai được bước qua. Chỉ làm một trong hai vế thì lời gọi vẫn bị từ chối. Phương án A là phương án duy nhất nêu đủ cả hai vế, nên nó đúng.

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

• B — AWS Owned CMK dùng chung được giữa các account: AWS owned CMK là tập khoá do chính dịch vụ AWS sở hữu và quản lý, dùng nội bộ cho nhiều account. Bạn không xem, không quản lý, không theo dõi hay audit được chúng, cũng không gắn key policy của mình vào được. Nó không phải là thứ bạn chủ động "cấu hình rồi chia sẻ". Đề hỏi về CMK của khách hàng cần chia sẻ có kiểm soát — loại khoá này ngược hẳn yêu cầu đó.

• C — Khai key policy cho external account, rồi nhúng key policy vào request đầu tiên của mỗi transaction: vế đầu đúng và đây là phương án gần đúng nhất, nhưng nó hỏng ở vế sau. Key policy là tài nguyên gắn cố định vào CMK, được đánh giá ở phía server mỗi lần gọi API; nó không phải thứ client đính kèm vào request. Ngoài ra phương án này thiếu hẳn vế IAM policy ở external account — mà thiếu vế đó thì user bên kia vẫn không gọi được khoá. Sai cả về cơ chế lẫn về tính đầy đủ.

• D — Dùng AWS KMS service-linked role để chia sẻ quyền giữa các account: service-linked role của KMS là loại IAM role đặc biệt gắn thẳng vào dịch vụ KMS, do chính KMS định nghĩa, chứa các quyền KMS cần để gọi dịch vụ AWS khác thay mặt bạn. Nó phục vụ hoạt động nội bộ của dịch vụ, không phải cơ chế chia sẻ quyền cross-account. Bạn cũng không sửa nó để mở quyền cho account khác.

📌 Điểm cần nhớ

• Truy cập CMK cross-account trong KMS luôn cần hai lớp: key policy ở account sở hữu khoá + IAM policy ở account bên ngoài. Phương án nào chỉ nêu một lớp là phương án thiếu.
• Trong KMS, key policy là nguồn quyền gốc — khác với hầu hết dịch vụ AWS nơi IAM policy đủ để cấp quyền. Không mở trong key policy thì IAM policy ở đâu cũng vô ích.
• Phân biệt các loại CMK: customer managed (bạn tạo, bạn viết key policy, chia sẻ được) so với AWS owned (dịch vụ AWS sở hữu, không xem/không audit/không cấu hình được).
• Service-linked role là để dịch vụ tự hành động thay bạn, không phải công cụ chia sẻ tài nguyên giữa các account. Thấy phương án đề xuất service-linked role cho bài toán cross-account thì gần như chắc chắn sai.

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

Đề cho bối cảnh một nhóm phát triển đang cân nhắc giữa instance store và EBS volumes cho các web application chạy trên Amazon EC2, rồi hỏi: phát biểu nào là đúng về hai loại lưu trữ này — (Select three).

Cụm từ quyết định nằm ở chỗ đây không phải câu chọn kiến trúc mà là câu kiểm tra phát biểu đúng/sai. Không có ràng buộc kiểu "chi phí thấp nhất" hay "độ trễ thấp nhất" để lọc; mỗi phương án phải được xét độc lập theo đúng hành vi thật của EBS và instance store. Ba trục kiến thức bị nhắm tới:

1. Dữ liệu còn hay mất khi stop / hibernate / terminate — trục phân biệt instance store với EBS.
2. Snapshot chụp được cái gì, và truy cập bằng API nào.
3. Các best practice và khả năng của EBS (tách volume hệ điều hành khỏi volume dữ liệu, encryption trên boot volume).

Ba phát biểu đúng theo tệp là B, D, F.

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

B — "EBS snapshots only capture data that has been written to your Amazon EBS volume…" Snapshot chỉ chụp những gì đã thực sự ghi xuống volume. Dữ liệu còn nằm trong cache của ứng dụng hoặc của OS, chưa flush xuống đĩa, sẽ không có trong snapshot. Vì vậy AWS khuyến nghị: muốn snapshot nhất quán thì detach volume một cách sạch sẽ, chụp snapshot, rồi attach lại; với volume đóng vai trò root device thì nên shutdown máy trước khi chụp.

D — "Use separate Amazon EBS volumes for the operating system and your data…" Đây là best practice của AWS, và vế "even though root volume persistence feature is available" chính là điểm mấu chốt: dù ngày nay root volume có thể cấu hình để giữ lại, tách riêng volume dữ liệu vẫn tốt hơn — dữ liệu sống độc lập với vòng đời instance và với mọi sự cố của hệ điều hành, đồng thời dễ snapshot, dễ attach sang instance khác.

F — "By default, data on a non-root EBS volume is preserved even if the instance is shutdown or terminated" Khi attach một EBS volume không phải root vào instance, thuộc tính DeleteOnTermination mặc định là false. Nên mặc định volume đó được giữ lại; sau khi instance terminate bạn vẫn có thể snapshot nó hoặc attach sang instance khác. Hệ quả cần nhớ: volume còn thì vẫn còn tính phí, muốn hết phí phải xoá volume.

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

A — "Snapshots of EBS volumes, stored on Amazon S3, can be accessed using Amazon S3 APIs" Đây là phương án gần đúng và bẫy nhất. Vế đầu không sai về mặt mô tả — snapshot được lưu trên Amazon S3. Nhưng vế sau sai: snapshot nằm trong vùng lưu trữ S3 do AWS quản lý, không xuất hiện trong bucket của bạn, nên không truy cập được bằng S3 API. Chỉ thao tác được qua Amazon EC2 API (và console/CLI tương ứng). Phát biểu đúng một nửa nhưng hỏng ở đúng chỗ câu hỏi muốn kiểm tra.

C — "Data stored in the instance store is preserved when you stop or terminate your instance. However, data is lost when you hibernate the instance…" Sai, và sai ngược hoàn toàn. Dữ liệu trên instance store mất khi bạn stop, hibernate hoặc terminate instance. Phương án này đảo vế: nó nói dữ liệu còn khi stop/terminate và mất khi hibernate. Nửa sau của câu ("hãy dùng EBS volumes hoặc có kế hoạch backup") nghe rất hợp lý và dễ khiến người đọc gật đầu cho cả câu — nhưng phát biểu kỹ thuật ở đầu câu đã sai thì cả phương án sai.

E — "EBS encryption does not support boot volumes" Sai. EBS volume dùng làm root/boot device có thể được mã hoá bình thường. Đây có thể là dấu vết của một giới hạn cũ trong quá khứ, nhưng theo hành vi hiện tại thì mã hoá boot volume không có vấn đề gì.

📌 Điểm cần nhớ

• Instance store là ephemeral: dữ liệu mất khi stop, hibernate và terminate. Chỉ dùng cho cache, scratch, dữ liệu tái tạo được. Gặp phát biểu nào nói instance store "giữ được dữ liệu qua stop/terminate" thì loại ngay.
• Non-root EBS volume mặc định DeleteOnTermination = false (được giữ lại), còn root volume thì mặc định ngược lại. Giữ lại volume nghĩa là vẫn tốn tiền cho tới khi xoá.
• Snapshot chỉ chụp dữ liệu đã ghi xuống volume — cache của OS/ứng dụng không được chụp. Muốn snapshot nhất quán: detach sạch (hoặc shutdown với root volume) rồi mới chụp.
• Snapshot lưu trên S3 nhưng chỉ truy cập được qua EC2 API, không qua S3 API — đây là một trong những cái bẫy chữ nghĩa quen thuộc của đề thi.
• Best practice: tách volume OS và volume dữ liệu; và EBS encryption hỗ trợ cả boot volume.

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

Một công ty y tế đang bị cơ quan quản lý kiểm toán tuân thủ. Họ có hàng trăm IAM user gọi API, và điều họ cần xác định là "who is making KMS API calls" — tức là ai đang thực hiện các lời gọi API tới KMS.

Cụm từ quyết định đáp án là "who is making ... API calls" kết hợp với bối cảnh compliance audit. Đây không phải câu hỏi về hiệu năng, cũng không phải câu hỏi về cấu hình tài nguyên — nó hỏi về danh tính người gọi (identity) đứng sau từng lời gọi API. Cụm "hundreds of IAM users" càng nhấn mạnh: cần lần ra chủ thể IAM nào đã gọi, chứ không phải xem tổng số lời gọi là bao nhiêu.

Trong bộ bốn phương án, ba dịch vụ CloudWatch Metrics, X-Ray và Config đều "quan sát" hệ thống nhưng theo ba trục hoàn toàn khác nhau (số đo hiệu năng, luồng request trong ứng dụng, trạng thái cấu hình tài nguyên). Chỉ có một dịch vụ lấy hoạt động của tài khoản làm đơn vị ghi nhận.

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

Đáp án đúng là B — CloudTrail.

CloudTrail ghi lại, giám sát liên tục và lưu giữ account activity — tức nhật ký các hành động API trên toàn bộ hạ tầng AWS. Mỗi event trong CloudTrail gắn với thông tin về chủ thể đã thực hiện lời gọi, nên nó trả lời được đúng dạng câu hỏi mà đề đưa ra: "Who made an API call to modify this resource?".

Vì KMS là một dịch vụ AWS có API được CloudTrail ghi nhận, các lời gọi KMS sẽ xuất hiện trong event history cùng danh tính người gọi. Đây chính là công cụ phục vụ governance, compliance, operational auditing và risk auditing cho tài khoản AWS — khớp trực tiếp với bối cảnh kiểm toán tuân thủ trong đề.

Cần lưu ý mặt trái được nêu rõ trong lời giải gốc: CloudTrail không dùng để duy trì lịch sử thay đổi cấu hình của tài nguyên. Nó mạnh ở "ai gọi gì", không phải "tài nguyên trông như thế nào tại một thời điểm".

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

A — CloudWatch Metrics. Đây là phương án dễ nhầm nhất, vì CloudWatch cũng thuộc nhóm "monitoring" giống tên miền của câu hỏi (Domain 1: Monitoring, Logging, and Remediation). CloudWatch cung cấp dữ liệu và insight để theo dõi ứng dụng, phản ứng với thay đổi hiệu năng toàn hệ thống, tối ưu mức sử dụng tài nguyên và nhìn tổng thể tình trạng vận hành. Điểm hỏng nằm ở đơn vị dữ liệu: metric là con số tổng hợp theo chiều thời gian, không mang danh tính chủ thể gọi API. Nó có thể cho bạn biết bao nhiêu lời gọi, nhưng không cho biết ai gọi — mà đề hỏi đúng chữ "who". CloudWatch không giúp xác định nguồn phát sinh các KMS API call.

C — X-Ray. X-Ray phục vụ developer phân tích và debug ứng dụng phân tán, hiểu ứng dụng cùng các dịch vụ nền của nó đang hoạt động ra sao để tìm nguyên nhân gốc của vấn đề hiệu năng và lỗi. Đây là công cụ dành cho tracing bên trong ứng dụng do bạn viết, không phải công cụ kiểm toán hoạt động tài khoản AWS. Nó nằm xa nhất so với yêu cầu của đề: một cuộc kiểm toán tuân thủ không quan tâm đường đi của request qua các service của ứng dụng. X-Ray không giúp xác định nguồn của các KMS API call.

D — Config. Đây là phương án gần đúng thứ hai, vì Config cũng nằm hẳn trong địa hạt audit và compliance — đúng từ khoá xuất hiện trong đề. Config cho phép đánh giá, kiểm toán và thẩm định cấu hình của tài nguyên AWS: xem thay đổi cấu hình, quan hệ giữa các tài nguyên, lịch sử cấu hình chi tiết, và mức độ tuân thủ so với quy tắc nội bộ. Chỗ nó hỏng là đối tượng theo dõi: Config trả lời câu "What did my AWS resource look like at xyz point in time?" — trạng thái của tài nguyên, chứ không phải danh tính người gọi API. Với hàng trăm IAM user, Config không cho bạn biết user nào đã gọi KMS.

📌 Điểm cần nhớ

• Quy tắc phân biệt ba dịch vụ hay bị hỏi lẫn nhau: nghĩ tới hiệu năng tài nguyên, event, alert → CloudWatch; nghĩ tới hoạt động của tài khoản và audit → CloudTrail; nghĩ tới lịch sử cấu hình tài nguyên, audit theo cấu hình, compliance → Config.
• Từ khoá "who" đi kèm "API call" gần như luôn dẫn thẳng tới CloudTrail, vì chỉ nó gắn danh tính chủ thể vào từng event.
• "Compliance/audit" xuất hiện trong đề không tự động có nghĩa là Config — phải đọc tiếp xem đang audit hoạt động (CloudTrail) hay audit cấu hình (Config).
• CloudWatch Metrics đo lượng, không đo danh tính; X-Ray soi bên trong ứng dụng phân tán, không soi hoạt động tài khoản AWS.

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

Đề đưa ra một công ty thương mại điện tử chạy database trên EBS loại Provisioned IOPS SSD (io1), rồi hỏi cấu hình nào là INCORRECT — tức là cấu hình không hợp lệ, AWS sẽ từ chối tạo volume.

Có hai cụm từ quyết định:

• "INCORRECT configuration" (viết hoa trong đề): đây là câu hỏi ngược. Ba phương án còn lại đều hợp lệ, chỉ một phương án là cấu hình không tạo được. Đọc lướt thành "cấu hình nào đúng/tốt nhất" là chọn sai ngay.
• "io1" cùng với việc cả bốn phương án đều để 100 GiB: kích thước bị cố định, chỉ số IOPS thay đổi. Đề cố tình ép người học so tỷ lệ IOPS trên mỗi GiB, chứ không so hiệu năng hay giá.

Với io1, IOPS không phải muốn khai bao nhiêu cũng được: AWS ràng buộc tỷ lệ tối đa giữa provisioned IOPS và dung lượng volume (tính bằng GiB) là 50:1. Vậy trần IOPS của volume 100 GiB là 100 × 50 = 5.000 IOPS.

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

B — 100 GiB với 7500 IOPS.

7.500 IOPS trên 100 GiB cho tỷ lệ 75:1, vượt trần 50:1. Muốn có 7.500 IOPS trên io1 thì volume phải lớn hơn: tối thiểu 7500 ÷ 50 = 150 GiB. Vì giữ nguyên 100 GiB, đây là cấu hình không hợp lệ — đúng thứ đề đang tìm ("INCORRECT configuration").

Đây là ràng buộc lúc tạo/sửa volume, không phải giới hạn hiệu năng lúc chạy: AWS đơn giản là không cho khai con số đó, chứ không phải khai xong rồi chạy chậm.

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

Cả ba đều "sai" theo nghĩa của câu hỏi ngược này: chúng là cấu hình hợp lệ, nên không phải thứ đề hỏi.

• A — 100 GiB với 3000 IOPS. Tỷ lệ 30:1, nằm dưới trần 50:1. Tạo được bình thường.
• C — 100 GiB với 5000 IOPS. Đây là phương án bẫy sát nhất, vì nó nằm đúng ngay trên vạch 50:1. Ai nhớ mang máng rằng "5000 là con số giới hạn" rất dễ chọn C vì tưởng chạm trần là vượt trần. Nhưng 50:1 là tỷ lệ tối đa được phép, tức là 5.000 IOPS vẫn nằm trong giới hạn và AWS chấp nhận. Chỉ khi vượt qua mốc này mới bị từ chối — nên C hợp lệ, còn B thì không.
• D — 100 GiB với 1000 IOPS. Tỷ lệ 10:1, thấp hơn trần rất nhiều. Hoàn toàn hợp lệ, chỉ là khai ít IOPS nên trả tiền ít và hiệu năng thấp hơn — nhưng "ít hiệu năng" không đồng nghĩa với "cấu hình sai".

📌 Điểm cần nhớ

• Với io1, luôn kiểm tra tỷ lệ IOPS : GiB ≤ 50:1 trước khi kết luận một cấu hình có tạo được hay không. Phép tính nhanh: nhân dung lượng với 50 để ra trần IOPS, hoặc chia IOPS mong muốn cho 50 để ra dung lượng tối thiểu.
• io1 có dải dung lượng riêng (từ vài GiB tới hàng chục TiB) và cho phép khai IOPS cố định — EBS cam kết giữ mức hiệu năng đã khai gần như toàn thời gian. Đây là lý do chọn io1 cho database thay vì volume không khai IOPS được.
• Gặp từ INCORRECT / NOT / EXCEPT viết hoa trong đề là dấu hiệu câu hỏi ngược: đọc lại xem mình đang tìm ba cái đúng hay một cái sai, vì phương án đúng ở đây lại là phương án mô tả thứ không dùng được.
• Phương án nằm đúng bằng giá trị giới hạn (ở đây là 5.000 IOPS) hầu như luôn được đặt vào để bẫy. Ràng buộc kiểu "tối đa X" bao gồm cả chính X; chỉ vượt qua X mới vi phạm.