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 sẵn một ứng dụng dựa trên SAML để đăng nhập vào các ứng dụng nghiệp vụ của bên thứ ba (third-party business applications), và muốn chuyển thứ đó lên chạy trên AWS bằng managed services.

Cụm từ quyết định đáp án nằm ở ba chỗ ghép lại:

• "SAML based application" — cần một dịch vụ nói được giao thức SAML 2.0 với vai trò nhà cung cấp danh tính/nhà môi giới danh tính.
• "third-party business applications" — người đăng nhập không phải là người vận hành tài nguyên AWS; đây là đăng nhập vào ứng dụng, không phải vào AWS Console hay API.
• "hosted in AWS using managed services" — không dựng máy chủ danh tính tự quản, phải là dịch vụ AWS lo phần vận hành.

Ràng buộc phân biệt mạnh nhất là đối tượng đăng nhập là người dùng của ứng dụng, không phải principal trong tài khoản AWS. Đó chính là ranh giới tách IAM khỏi phần còn lại.

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

Đáp án theo tệp là B — Amazon Cognito.

Amazon Cognito là dịch vụ được quản lý dùng để thêm đăng ký, đăng nhập và kiểm soát truy cập cho ứng dụng web và ứng dụng di động. Nó không chỉ tự quản lý kho người dùng riêng, mà còn liên kết được với nhà cung cấp danh tính bên ngoài: các social identity provider như Apple, Facebook, Google, Amazon, và các enterprise identity provider thông qua SAML 2.0 và OpenID Connect.

Đúng ba mảnh mà đề yêu cầu:

• Nói được SAML 2.0, nên ứng dụng SAML sẵn có của công ty ghép vào được.
• Phục vụ người dùng của ứng dụng, tức là đúng đối tượng "đăng nhập vào third-party business applications".
• Là managed service, AWS lo hạ tầng, và mở rộng được tới quy mô rất lớn về số người dùng.

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

A — AWS Identity and Access Management (IAM). Đây là phương án gần đúng nhất và cũng là bẫy chính, vì IAM đúng là dịch vụ về danh tính và quyền. Nhưng IAM dùng để cấp quyền cho người dùng bên trong một tài khoản AWS — tức là quyền truy cập vào tài nguyên AWS. Nó không phải dịch vụ danh tính được quản lý để cấp quyền truy cập cho bên thứ ba vào ứng dụng của bạn. Đề hỏi về đăng nhập ứng dụng nghiệp vụ, không phải về quyền trên tài nguyên AWS — nên IAM lệch đối tượng.

C — AWS Single Sign-On. Nghe rất hợp vì tên có "Single Sign-On" và đề đang nói chuyện đăng nhập một lần. Chỗ hỏng là phạm vi người dùng: AWS SSO là nơi bạn tạo hoặc kết nối danh tính của lực lượng nhân sự (workforce identities) rồi quản lý truy cập tập trung trên toàn AWS organization. Nó hướng vào việc nhân viên truy cập các tài khoản trong tổ chức AWS, chứ không phải làm lớp danh tính cho ứng dụng của khách hàng. Theo lời giải gốc, đây không phải phương án dùng SAML mà đề đang tìm.

D — AWS CLI. Đây là công cụ dòng lệnh hợp nhất để quản lý dịch vụ AWS từ terminal trên máy của bạn. Nó là công cụ vận hành, không phải dịch vụ danh tính, và không liên quan gì tới SAML hay xác thực người dùng ứng dụng. Loại thẳng.

📌 Điểm cần nhớ

• Phân biệt theo ai là người đăng nhập: người dùng ứng dụng (web/mobile) → Amazon Cognito; principal thao tác trên tài nguyên trong tài khoản AWS → IAM; nhân sự truy cập nhiều tài khoản trong AWS organization → AWS Single Sign-On.
• Thấy cụm SAML 2.0 / OpenID Connect gắn với ứng dụng web hoặc mobile thì nghĩ ngay tới Amazon Cognito, vì nó liên kết được cả social identity provider lẫn enterprise identity provider.
• Tên dịch vụ nghe giống yêu cầu không có nghĩa là đúng. "Single Sign-On" trùng chữ với "đăng nhập một lần" trong đề nhưng khác phạm vi sử dụng — luôn đọc kỹ đối tượng phục vụ trước khi chọn theo tên.
• Cụm "managed services" trong đề là tín hiệu loại bỏ mọi phương án chỉ là công cụ hoặc thứ phải tự dựng và tự vận hành, ví dụ AWS CLI.

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

Đề mô tả một công ty cần một dịch vụ duy nhất (a single service) gánh được cả ba nhu cầu: backup and restore, data lakes, và archives — tất cả ở cùng một chỗ.

Cụm từ quyết định là "a single service which can manage… all in one place". Đây không phải câu hỏi "dịch vụ nào lưu trữ tốt nhất", mà là "dịch vụ nào phủ được cả ba use case cùng lúc". Ba use case này có đặc điểm chung: dữ liệu ở dạng object (tệp rời rạc, không phụ thuộc hệ điều hành), dung lượng lớn tới rất lớn, truy cập qua API/HTTP chứ không cần gắn vào một máy chủ cụ thể. Ngay khi nhận ra ba nhu cầu đó đều là bài toán object storage, danh sách bốn phương án tự tách làm hai nhóm: một object storage duy nhất, và ba dịch vụ thuộc kiểu lưu trữ khác (block, file).

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

Đáp án đúng theo tệp là C — Amazon Simple Storage Service (Amazon S3).

Amazon S3 là dịch vụ object storage của AWS, và nó là lựa chọn duy nhất trong bốn phương án phủ được trọn cả ba yêu cầu:

• Backup and restore: dữ liệu sao lưu được đẩy lên S3 dưới dạng object, lấy lại bất cứ lúc nào qua API, không phụ thuộc vào một EC2 instance hay một Availability Zone nào đang sống.
• Data lakes: data lake yêu cầu gom dữ liệu thô đủ mọi định dạng vào một kho tập trung, dung lượng gần như không giới hạn, rồi để các công cụ phân tích đọc trực tiếp từ đó. S3 chính là nền tảng lưu trữ mà kiến trúc data lake trên AWS dựng lên.
• Archives: S3 có các storage class dành riêng cho dữ liệu lưu trữ lâu dài, ít truy cập, với chi phí thấp hơn nhiều so với lớp lưu trữ tiêu chuẩn.

Vì S3 là object storage, không gắn với hệ điều hành hay giao thức file/block cụ thể, phổ use case của nó rộng hơn hẳn ba phương án còn lại — đúng như phần giải thích gốc nêu: "S3 is the only service out of the answers which can be used for backup and restore, data lakes and archival solutions."

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

A — Amazon Elastic Block Store (Amazon EBS): EBS là block storage, tức là ổ đĩa ảo (HDD/SSD) gắn vào EC2 instance để làm nơi lưu trữ bền vững cho instance đó. Nó rất bền và mở rộng tốt, nhưng bản chất là một volume phải được attach vào một máy rồi format và mount mới dùng được. Đây không phải nơi để đổ dữ liệu thô của data lake, cũng không phải kho lưu trữ dài hạn giá rẻ, và bản thân EBS chỉ là đối tượng cần được sao lưu chứ không phải kho chứa bản sao lưu.

B — Amazon FSx for Lustre: đây là hệ thống file hiệu năng rất cao, sinh ra cho tính toán hiệu năng cao (HPC), mô phỏng, xử lý dữ liệu cần thông lượng và IOPS cực lớn. Đây là phương án dễ gây phân vân nhất nếu người học chỉ nhớ máy móc rằng "Lustre hay đi cùng data lake" — nhưng chỗ hỏng nằm ở vai trò: FSx for Lustre là lớp truy cập tốc độ cao đặt trước kho dữ liệu, chứ bản thân nó không phải kho lưu trữ bền vững, giá rẻ, dài hạn. Và nó hoàn toàn không phù hợp cho backup/restore hay archive — trả tiền cho hiệu năng cực cao để chứa dữ liệu gần như không bao giờ đọc tới là sai mục đích hoàn toàn.

D — Amazon Elastic File System (Amazon EFS): EFS là dịch vụ file storage được quản lý, cung cấp hệ thống file chia sẻ theo giao thức NFS cho các workload Linux — nhiều EC2 instance cùng mount một thư mục và cùng đọc ghi. Nó giải được bài toán chia sẻ file giữa các máy, nhưng không phải là dịch vụ được thiết kế cho backup/restore, data lake hay lưu trữ dài hạn. Nó gần đúng ở chỗ "nhiều máy dùng chung, dung lượng co giãn", nhưng vẫn là mô hình file system gắn với giao thức NFS, không phải object storage truy cập qua API như ba use case trong đề đòi hỏi.

📌 Điểm cần nhớ

• Ba từ khoá backup and restore, data lake, archive hầu như luôn dẫn về object storage, tức là Amazon S3. Thấy đủ bộ ba này trong đề thì gần như không cần cân nhắc thêm.
• Phân biệt ba kiểu lưu trữ để loại nhanh phương án: block (EBS — ổ đĩa gắn vào một EC2 instance), file (EFS/FSx — hệ thống file chia sẻ, mount qua NFS hoặc giao thức tương ứng), object (S3 — object truy cập qua API, dùng cho dữ liệu phi cấu trúc quy mô lớn).
• Cụm "a single service… all in one place" là ràng buộc yêu cầu độ phủ, không phải hiệu năng. Phương án nào chuyên sâu cho một mục đích hẹp (như FSx for Lustre với HPC) sẽ trượt dù nghe rất mạnh.
• Amazon FSx for Lustre gắn với hiệu năng cao cho HPC, không phải với lưu trữ giá rẻ dài hạn — đừng để chữ "data" trong tình huống HPC kéo bạn về hướng data lake.

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

Đề hỏi: pillar nào của AWS Well-Architected Framework chứa design principle "định nghĩa workload, application và infrastructure dưới dạng code (IaC)".

Cụm từ quyết định đáp án là "design principle" ghép với "defining ... as code". Đây không phải câu hỏi "IaC có lợi ích gì" — nếu hỏi kiểu đó thì nhiều pillar đều có phần liên quan. Đề đang hỏi nguyên văn một design principle được liệt kê trong tài liệu của một pillar cụ thể. Trong Well-Architected Framework, nguyên tắc "Perform operations as code" là design principle đầu tiên của pillar Operational excellence. Nhận ra rằng đề đang truy nguồn gốc của một nguyên tắc có tên sẵn, chứ không đánh giá tác dụng phụ của IaC, là chìa khoá loại bỏ ba phương án còn lại.

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

Đáp án đúng theo tệp là C — Operational excellence.

Pillar Operational excellence có năm design principle, và nguyên tắc mở đầu là "Perform operations as code". Nội dung của nguyên tắc này đúng như đề mô tả: trên cloud, bạn áp dụng cùng kỷ luật kỹ thuật vốn dùng cho application code lên toàn bộ môi trường của mình. Bạn định nghĩa toàn bộ workload — cả application lẫn infrastructure — dưới dạng code, và cập nhật nó bằng code. Xa hơn nữa, bạn viết cả operations procedure thành code rồi tự động chạy chúng khi có event kích hoạt.

Lý do nguyên tắc này thuộc Operational excellence chứ không phải pillar khác nằm ở mục đích của nó: giới hạn lỗi do con người gây ra và tạo ra phản ứng nhất quán trước các sự kiện vận hành. Đó chính là địa hạt của Operational excellence — vận hành và giám sát hệ thống, liên tục cải tiến quy trình và thủ tục.

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

A — Performance efficiency. Sai vì viết infrastructure dưới dạng code không làm application chạy nhanh hơn. Performance efficiency bàn về việc dùng đúng loại tài nguyên tính toán cho nhu cầu, và duy trì hiệu năng đó khi nhu cầu thay đổi. IaC quyết định cách bạn tạo ra tài nguyên, không quyết định tài nguyên đó nhanh hay chậm.

B — Security. Đây là phương án dễ gây phân vân, vì trên thực tế người ta hay nói IaC giúp cấu hình bảo mật nhất quán, review được. Nhưng nó hỏng ở chỗ: bản thân việc dùng IaC không làm hệ thống an toàn hơn. Một template viết sai vẫn triển khai đều đặn một cấu hình mở toang. Và quan trọng hơn với dạng câu hỏi này, "định nghĩa workload dưới dạng code" không nằm trong danh sách design principle của pillar Security — pillar đó có các nguyên tắc riêng như áp dụng bảo mật ở mọi lớp, truy vết được mọi hành động, bảo vệ dữ liệu khi lưu trữ và khi truyền.

D — Reliability. Cũng là phương án gần đúng theo cảm tính: nhiều người lập luận "triển khai bằng code thì ít lỗi tay hơn, nên hệ thống ổn định hơn". Nhưng dùng IaC tự nó không làm tăng độ tin cậy. Reliability bàn về khả năng workload thực hiện đúng chức năng đã định và tự phục hồi khi gặp sự cố — nó có bộ design principle riêng xoay quanh việc tự động khôi phục khỏi lỗi, kiểm thử quy trình recovery và mở rộng theo chiều ngang. Việc "định nghĩa mọi thứ bằng code" không phải một trong số đó.

📌 Điểm cần nhớ

• "Perform operations as code" là design principle số một của Operational excellence. Hễ đề nhắc tới IaC ghép với cụm "design principle" và hỏi thuộc pillar nào, đáp án gần như luôn là Operational excellence.
• Phân biệt "lợi ích phụ" với "design principle được liệt kê". IaC gián tiếp giúp cả Security lẫn Reliability, nhưng câu hỏi dạng này chấm theo tài liệu chính thức của pillar, không chấm theo suy luận về tác dụng lan toả.
• Nhớ địa hạt riêng của từng pillar để loại nhanh: Operational excellence = vận hành, giám sát, cải tiến quy trình; Security = bảo vệ dữ liệu và hệ thống; Reliability = phục hồi sau sự cố; Performance efficiency = dùng đúng tài nguyên cho hiệu năng; Cost optimization = tránh chi phí không cần thiết.
• Từ khoá "as code", "automate", "limit human error", "consistent responses to events" đều là chỉ dấu của Operational excellence trong đề thi AWS.

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

Đề hỏi: dịch vụ AWS nào dùng để theo dõi hoạt động của người dùng (activity of users) trên AWS?

Cụm từ quyết định là "track the activity of users" — tức là ghi lại ai đã làm gì, vào lúc nào, từ đâu. Đây là ngôn ngữ của auditing (kiểm toán, truy vết hành vi), chứ không phải của monitoring (giám sát hiệu năng, mức sử dụng tài nguyên) hay security assessment (quét lỗ hổng).

Đề bài kiểu này thường bẫy ở chỗ trong danh sách phương án có cả một dịch vụ giám sát nổi tiếng. Phải phân biệt rạch ròi hai khái niệm:

• Ai gọi API nào, thao tác gì → dấu vết hành vi người dùng.
• CPU dùng bao nhiêu, có bao nhiêu request, độ trễ ra sao → số đo hiệu năng.

Câu hỏi này thuộc vế thứ nhất.

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

Đáp án đúng: B — AWS CloudTrail.

CloudTrail là dịch vụ phục vụ governance, compliance, operational auditing và risk auditing cho tài khoản AWS. Nó ghi log lại các hành động diễn ra trong hạ tầng AWS của bạn: lời gọi API, thao tác trên AWS Management Console, CLI hay SDK — kèm theo danh tính người thực hiện, thời điểm và các tham số của thao tác đó. Log này có thể được lưu giữ và giám sát liên tục.

Cách nhớ gọn nhất, đúng như tài liệu nguồn diễn đạt: CloudTrail = "ai đã làm gì và khi nào" (auditing); CloudWatch = "tài nguyên được dùng bao nhiêu" (performance monitoring). Đề hỏi "activity of users" nên rơi thẳng vào vế CloudTrail.

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

A. Amazon Inspector — đây là dịch vụ đánh giá bảo mật tự động, giúp cải thiện tính bảo mật và tuân thủ của các ứng dụng được triển khai trên AWS. Nó soi vào tình trạng của workload (điểm yếu, cấu hình rủi ro), chứ không phải vào hành vi của con người. Inspector trả lời "hệ thống của tôi có lỗ hổng nào không", không trả lời "ai vừa xoá cái bucket này". Nghe có vẻ liên quan vì cùng nằm trong nhóm bảo mật, nhưng đối tượng quan sát hoàn toàn khác.

C. AWS Directory Service — dịch vụ cung cấp các lựa chọn để chạy directory service trên AWS và kết nối tới directory service đang có tại on-premises. Nó liên quan tới người dùng ở khía cạnh quản lý danh tính và thư mục (tài khoản, nhóm, xác thực), chứ không phải khía cạnh ghi lại hoạt động. Directory Service cho biết người dùng tồn tại và đăng nhập được; nó không sinh ra nhật ký kiểm toán các thao tác trên tài nguyên AWS.

D. Amazon CloudWatch — đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. CloudWatch dùng cho giám sát hiệu năng: thu thập metric, log ứng dụng, dựng dashboard, đặt alarm. Nó cho bạn biết mức sử dụng tài nguyên và tình trạng vận hành, không phải auditing. Nếu câu hỏi hỏi về mức sử dụng CPU, số lượng request hay cảnh báo khi vượt ngưỡng thì CloudWatch mới là đáp án; còn khi đề nói "activity of users" thì CloudTrail là dịch vụ đúng vai.

📌 Điểm cần nhớ

• Thấy "who did what and when", "user activity", "audit", "governance", "compliance" → nghĩ ngay tới AWS CloudTrail.
• Thấy "metrics", "performance", "resource utilization", "alarm", "dashboard" → nghĩ tới Amazon CloudWatch. Đây là cặp bị nhầm nhiều nhất ở trình độ Cloud Practitioner.
• Amazon Inspector thuộc nhóm bảo mật nhưng quét điểm yếu của ứng dụng/workload, không theo dõi hành vi người dùng.
• AWS Directory Service là chuyện quản lý danh tính/thư mục (kể cả nối với on-premises), không phải chuyện ghi log hành động — đừng chọn nó chỉ vì trong đề có chữ "users".

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

Đề hỏi: dịch vụ AWS nào giúp xây dựng ứng dụng mobile và web an toàn, mở rộng được, với các tính năng như real-time updates và offline functionalities? Chọn HAI.

Cụm từ quyết định là "real-time updates and offline functionalities" đi kèm với "building ... mobile and web applications". Đây là hai ràng buộc chồng lên nhau:

• Dịch vụ phải nằm ở tầng xây dựng ứng dụng client-facing, chứ không phải chỉ là hạ tầng chạy code hay đưa code lên máy.
• Dịch vụ phải tự nó mang sẵn cơ chế đồng bộ dữ liệu thời gian thực và làm việc khi mất mạng, chứ không phải "có thể dùng để tự dựng ra chuyện đó".

Vế thứ hai là chỗ loại được các phương án gần đúng: Lambda và API Gateway đều tham gia vào backend của một ứng dụng web/mobile thật, nhưng cả hai đều không mang sẵn tính năng real-time sync + offline như một đặc tính của dịch vụ.

✅ Vì sao đáp án đúng là đúng (A và D)

A — AWS Amplify. Đây là bộ công cụ và dịch vụ để dựng ứng dụng full-stack chạy trên AWS: thư viện client cho web và mobile, phần backend đi kèm, hosting, xác thực người dùng. Amplify hướng thẳng vào đối tượng mà đề mô tả — lập trình viên mobile/web — và hỗ trợ cả luồng dữ liệu thời gian thực lẫn thao tác khi thiết bị offline.

D — AWS AppSync. Dịch vụ tạo API được quản lý (nổi bật là GraphQL), trong đó real-time updates và offline functionalities là tính năng lõi được nêu tên trực tiếp: client đăng ký nhận dữ liệu thay đổi theo thời gian thực, và dữ liệu ghi lúc mất mạng được đồng bộ lại khi có mạng trở lại. Đúng nguyên văn hai từ khoá trong đề.

Hai dịch vụ này thường đi cặp với nhau trong thực tế: Amplify là lớp công cụ/khung phát triển, AppSync là lớp API phía sau nó.

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

B — AWS CodeDeploy. Đây là dịch vụ triển khai (deployment): tự động đưa phiên bản ứng dụng lên các môi trường tính toán như EC2 hay Lambda. Nó nằm ở giai đoạn sau khi ứng dụng đã được viết xong, không cung cấp bất kỳ khả năng nào cho việc xây dựng ứng dụng, càng không có real-time hay offline. Đây là phương án sai rõ nhất.

C — AWS Lambda. Gần đúng hơn CodeDeploy vì Lambda thật sự là nơi chạy backend cho rất nhiều ứng dụng mobile/web, không cần quản lý máy chủ. Nhưng nó hỏng ở chỗ: Lambda chỉ thực thi hàm backend. Nó không có mô hình đồng bộ dữ liệu, không có subscription thời gian thực cho client, không có kho dữ liệu cục bộ cho lúc offline. Muốn có những thứ đó thì lập trình viên phải tự viết lấy — mà đề đang hỏi dịch vụ nào sẵn có tính năng đó.

E — Amazon API Gateway. Đây là phương án bẫy nhất. API Gateway tạo, xuất bản, giám sát và bảo vệ API ở quy mô lớn, gồm REST, HTTP và cả WebSocket — mà WebSocket thì nghe rất giống "real-time". Nhưng nó hỏng ở hai điểm: WebSocket chỉ là kênh truyền hai chiều, phần logic đồng bộ dữ liệu vẫn phải tự dựng; và API Gateway hoàn toàn không có khái niệm offline — không có cache dữ liệu phía client, không có cơ chế hoà giải thay đổi khi thiết bị nối mạng lại. Đứng một mình, nó không đáp ứng được vế "offline functionalities" của đề.

📌 Điểm cần nhớ

• Khi đề nhắc "real-time updates" đi kèm "offline" cho ứng dụng mobile/web, nghĩ ngay tới AppSync (và Amplify ở tầng công cụ). Đó là cặp từ khoá đặc trưng của hai dịch vụ này.
• Phân biệt theo tầng công việc: Amplify/AppSync = xây dựng ứng dụng; Lambda = chạy code backend; API Gateway = cổng vào API; CodeDeploy = đưa bản build lên môi trường chạy.
• WebSocket của API Gateway ≠ real-time sync. Có kênh truyền không đồng nghĩa với có cơ chế đồng bộ dữ liệu, và chắc chắn không đem lại khả năng offline.
• Câu hỏi dạng "dịch vụ nào facilitate building" thường loại hết các dịch vụ vận hành/triển khai (CodeDeploy, CodePipeline…) ngay từ đầu — chúng phục vụ vòng đời phát hành, không phải quá trình phát triển tính năng.

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

Đề hỏi: "What is a specific benefit of an Enterprise Support plan?" — đâu là quyền lợi riêng có của gói AWS Enterprise Support.

Cụm từ quyết định đáp án là "specific benefit" và "Enterprise Support plan". Chữ "specific" loại ngay những thứ mà các gói support thấp hơn cũng có: nếu một quyền lợi xuất hiện ở Developer hay Business thì nó không còn là điểm phân biệt của Enterprise nữa. Vậy câu hỏi thực chất là: trong bốn cái tên vai trò được liệt kê, cái nào vừa có thật trong danh mục AWS Support, vừa chỉ đi kèm gói Enterprise.

Đây là kiểu câu rất hay gặp ở Cloud Practitioner: bốn phương án đều là những chức danh nghe rất giống nhau ("Solutions Architect", "Technical Account Manager", "Cloud Support Associate", "Technical Support Manager"). Bẫy nằm ở chỗ có phương án là tên bịa, có phương án là tên thật nhưng thuộc gói khác.

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

B — Included Technical Account Manager.

Technical Account Manager (TAM) là một vai trò có thật trong AWS Support và là quyền lợi gắn với gói Enterprise Support. TAM là đầu mối kỹ thuật được chỉ định cho khách hàng: nắm kiến trúc và workload cụ thể của khách, tư vấn chủ động (proactive guidance), rà soát theo AWS Well-Architected, hỗ trợ chuẩn bị cho các sự kiện tải cao, và làm điểm liên lạc khi có sự cố lớn.

Đúng với chữ "specific" trong đề: các gói support thấp hơn không kèm TAM được chỉ định, nên đây chính là điểm phân biệt Enterprise với phần còn lại. Bản giải thích tiếng Anh của đề cũng khẳng định thẳng: "Only the Enterprise Support plan gets a Technical Account Manager (TAM)."

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

A — Included AWS Solutions Architect. Sai vì không gói AWS Support nào kèm sẵn một Solutions Architect. Solutions Architect là vai trò thuộc mảng bán hàng/tư vấn của AWS (hoặc là một chứng chỉ, hoặc là dịch vụ có tính phí riêng như AWS Professional Services), không phải quyền lợi nằm trong gói support. Đây là phương án dễ chọn nhầm nhất vì người học quen với cái tên "Solutions Architect" từ hệ thống chứng chỉ, nhưng quen tên không có nghĩa nó nằm trong bảng so sánh các support plan.

C — Included Cloud Support Associate. Đây là vai trò có thật nhưng gắn với gói Developer, không phải Enterprise. Cloud Support Associate là cấp kỹ sư hỗ trợ mà khách hàng gói Developer tiếp cận được. Phương án này gần đúng ở chỗ nó là tên thật trong hệ thống support, nhưng hỏng đúng ở tiêu chí "specific benefit of Enterprise": chọn nó là chọn quyền lợi của gói thấp hơn. Ghi nhớ nguyên tắc chung: gói càng cao thì cấp kỹ sư hỗ trợ càng cao (Associate → Engineer → Senior Engineer), nên gán một vai trò cấp thấp cho gói cao nhất là ngược logic phân tầng.

D — Included Technical Support Manager. Sai vì "Technical Support Manager" không tồn tại trong bảng quyền lợi các gói AWS Support — đây là tên bịa, cố ý đặt gần giống "Technical Account Manager" để đánh vào người chỉ nhớ mang máng chữ "Technical ... Manager". Chỉ khác một từ giữa "Account" và "Support", nhưng chỉ một trong hai là thuật ngữ AWS thật. Nếu bạn nhớ đúng cụm TAM = Technical Account Manager, phương án này tự loại.

📌 Điểm cần nhớ

• TAM (Technical Account Manager) = dấu hiệu nhận biết gói Enterprise Support. Thấy "Technical Account Manager" trong phương án và đề nhắc Enterprise thì gần như chắc chắn đó là đáp án.
• Cloud Support Associate gắn với gói Developer. Đừng để chữ "Cloud Support" nghe có vẻ cao cấp đánh lừa — "Associate" là cấp thấp nhất trong thang kỹ sư hỗ trợ.
• AWS Support plan không bao giờ kèm sẵn Solutions Architect. Solutions Architect thuộc mảng tư vấn/bán hàng hoặc là tên chứng chỉ, không nằm trong quyền lợi support.
• Cảnh giác với tên vai trò bịa gần giống tên thật ("Technical Support Manager" vs "Technical Account Manager"). Với câu hỏi kiểu liệt kê chức danh, bước đầu tiên là loại những cái tên không tồn tại trong tài liệu AWS, sau đó mới xét cái tên thật nào thuộc đúng gói mà đề hỏi.
• Từ khoá "specific benefit" luôn nghĩa là "chỉ gói này mới có" — quyền lợi nào gói thấp hơn cũng được hưởng thì không phải đáp án.

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

Đề hỏi: theo AWS shared responsibility model, những việc nào thuộc trách nhiệm của AWS? (Chọn HAI.)

Cụm từ quyết định là "the responsibility of AWS" — tức là phần security of the cloud, chứ không phải security in the cloud. Đây là ranh giới duy nhất cần vạch ra để phân loại năm phương án.

Cách đọc nhanh và ít sai nhất: hỏi xem thứ đang được nói tới có phải là hạ tầng do AWS sở hữu và vận hành, mà khách hàng không nhìn thấy cũng không chạm vào được không? Nếu đúng → AWS. Nếu đó là thứ khách hàng bật/tắt, cấu hình, hoặc tự viết ra → khách hàng. Chú ý cái bẫy kinh điển: mã hoá và bảo mật mạng xuất hiện ở cả hai vế, nên không thể phân loại theo từ khoá "encryption" hay "security" — phải nhìn đối tượng của hành động.

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

A — Scanning AWS service endpoints for vulnerabilities. Các service endpoint là tài sản của AWS. Khách hàng không có quyền truy cập, cũng không có bất kỳ tầm nhìn nào vào cách chúng hoạt động bên trong — toàn bộ phần đó được trừu tượng hoá đi. Không thể giao cho khách hàng trách nhiệm quét lỗ hổng trên thứ họ không được phép chạm vào, nên việc này nằm hoàn toàn ở phía AWS.

D — Encrypting traffic on the AWS backbone between global and regional AWS facilities. Đường truyền và hạ tầng mạng nối các cơ sở của AWS do chính AWS sở hữu và vận hành. Bảo vệ lưu lượng chạy trên đó là security of the cloud — khách hàng thậm chí không nhìn thấy tuyến mạng này, chứ đừng nói tới việc bật mã hoá cho nó.

Điểm chung của hai đáp án: cả hai đều nói về hạ tầng của chính AWS, không phải về workload mà khách hàng dựng lên.

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

B — Enforcing application access restrictions. AWS không có tầm nhìn nào vào ứng dụng bạn xây dựng bên trên — AWS chỉ chịu trách nhiệm phần hạ tầng làm nền cho nó chạy. Logic phân quyền, ai được xem màn hình nào, vai trò nào làm được gì là do bạn thiết kế và thực thi. Đây là security in the cloud.

C — Enabling encryption on an Amazon S3 bucket. Đây là phương án gần đúng nhất, và cũng là cái bẫy chính của câu hỏi: nó có chữ "encryption" giống hệt D. Khác biệt nằm ở chỗ ai bật. AWS cung cấp khả năng mã hoá cho S3, nhưng hành động enabling trên một bucket cụ thể là một lựa chọn cấu hình của khách hàng, thực hiện trên tài nguyên của khách hàng. Cấu hình dữ liệu của mình luôn thuộc vế khách hàng — đừng nhầm "AWS làm ra tính năng" với "AWS chịu trách nhiệm bật tính năng đó cho bạn".

E — Configuring security group rules. Cũng là phương án dễ nhầm vì mang chữ "security". Nhưng security group là tài nguyên trong VPC của bạn, và bạn mở cổng nào, cho dải IP nào vào là tuỳ ứng dụng của bạn cần hoạt động ra sao. AWS không biết và không thể quyết định thay. So sánh trực tiếp với D thấy rõ ranh giới: mạng backbone của AWS là của AWS, còn cấu hình mạng quanh workload của bạn là của bạn.

📌 Điểm cần nhớ

• Câu thần chú: AWS lo security of the cloud (phần cứng, cơ sở vật chất, mạng backbone, các endpoint dịch vụ), khách hàng lo security in the cloud (dữ liệu, cấu hình, ứng dụng, quyền truy cập).
• Đừng phân loại theo từ khoá — "encryption" và "security" nằm ở cả hai vế. Hãy hỏi đối tượng của hành động là tài sản của ai: hạ tầng AWS hay tài nguyên trong tài khoản của bạn.
• Động từ "configuring" / "enabling" trên một tài nguyên cụ thể gần như luôn báo hiệu trách nhiệm của khách hàng: AWS làm ra công tắc, bạn là người gạt nó.
• Thứ khách hàng không có quyền truy cập và không nhìn thấy được thì không thể là trách nhiệm của khách hàng — đây là mẹo loại trừ nhanh cho mọi câu về shared responsibility model.

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

Đề mô tả một tổ chức đang cân nhắc triển khai một workload mới lên AWS Cloud, và trước khi làm thì muốn dự trù chi phí.

Cụm từ quyết định là "is considering implementing a new workload" kết hợp với "estimate the cost". Workload này chưa tồn tại, chưa có tài nguyên nào chạy, nên chưa hề phát sinh một dòng dữ liệu chi phí nào trong tài khoản. Câu hỏi vì thế tách bạch hai nhóm công cụ hoàn toàn khác nhau:

• Công cụ lập kế hoạch trước khi xây — làm việc với cấu hình giả định do người dùng nhập vào.
• Công cụ phân tích chi phí đã phát sinh — làm việc với dữ liệu sử dụng thật của tài khoản.

Ba trong bốn phương án thuộc nhóm thứ hai. Chỉ một phương án thuộc nhóm thứ nhất.

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

A. AWS Pricing Calculator là công cụ lập kế hoạch chạy trên web, dùng để tạo bản dự toán cho các use case AWS. Bạn khai báo dịch vụ định dùng, cấu hình và mức sử dụng dự kiến, rồi công cụ tính ra chi phí ước lượng.

Điểm mấu chốt khớp đúng với đề bài: nó cho phép mô hình hoá giải pháp trước khi xây dựng, khảo sát mức giá của từng dịch vụ AWS, và xem lại chính các phép tính đằng sau con số ước lượng. Nhờ vậy tổ chức có thể lên kế hoạch chi tiêu, tìm cơ hội tiết kiệm và ra quyết định có cơ sở — tất cả khi trong tài khoản chưa có gì cả. Đây là công cụ duy nhất trong danh sách không cần dữ liệu sử dụng lịch sử làm đầu vào.

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

D. Cost Explorer — đây là phương án gần đúng nhất và là cái bẫy chính, vì Cost Explorer có chức năng forecast (dự báo), mà đề bài lại dùng đúng từ "forecast costs". Nhưng phần dự báo của Cost Explorer được ngoại suy từ lịch sử chi tiêu thực tế của tài khoản: nó trực quan hoá mức chi hiện tại rồi chiếu tới tương lai. Với một workload mới toanh chưa từng chạy, không có lịch sử nào để ngoại suy, nên nó không thể ước tính số tiền bạn sẽ tiêu khi xây thêm thứ chưa tồn tại. Sai ở chỗ hướng dữ liệu: Cost Explorer nhìn về quá khứ, đề bài cần nhìn về một thứ chưa xảy ra.

C. AWS Billing and Cost Management dashboard — bảng điều khiển tổng hợp tình hình hoá đơn và chi phí của tài khoản: bạn đang nợ bao nhiêu, tiền đi vào những dịch vụ nào. Nó là nơi xem và quản lý thứ đã phát sinh, không tính được bản dự toán cho workload trên cloud ngay trong console. Không phải công cụ lập kế hoạch.

B. AWS Cost and Usage Report (AWS CUR) — là tập dữ liệu chi phí và mức sử dụng chi tiết nhất mà AWS cung cấp, xuất báo cáo billing ra một bucket Amazon S3 do bạn sở hữu để phân tích sâu. Chính vì nó chi tiết nên dễ bị nhầm là "đủ mạnh để làm mọi thứ về chi phí". Nhưng độ chi tiết đó là chi tiết về những gì đã dùng; nó không thể hiện chi phí của workload mới. Sai cùng một kiểu với hai phương án trên, chỉ ở mức dữ liệu thô hơn.

📌 Điểm cần nhớ

• Từ khoá phân loại nhanh: đề nhắc "before building" / "considering" / "new workload" / "estimate" → AWS Pricing Calculator. Đề nhắc chi phí đã phát sinh, phân tích, trực quan hoá xu hướng → Cost Explorer / CUR / Billing dashboard.
• "Forecast" không tự động dẫn tới Cost Explorer. Dự báo của Cost Explorer cần lịch sử sử dụng làm nguyên liệu; không có lịch sử thì không có dự báo.
• Phân biệt ba công cụ hậu kiểm: Billing and Cost Management dashboard = tổng quan hoá đơn trong console; Cost Explorer = biểu đồ và phân tích xu hướng; Cost and Usage Report = dữ liệu thô chi tiết nhất, xuất sang S3.
• AWS Pricing Calculator không chỉ ra con số cuối cùng mà còn cho xem lại phép tính phía sau, nên dùng được để so sánh các phương án kiến trúc trước khi chọn.

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

Đề mô tả một nhu cầu rất cụ thể: người dùng cần cách nhanh chóng để biết liệu có instance Amazon EC2 nào đang mở cổng cho phép truy cập không giới hạn hay không.

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

• "unrestricted access" (truy cập không giới hạn) — đây là cách nói của AWS về một rule trong security group cho phép nguồn 0.0.0.0/0, tức mở cổng ra toàn Internet. Truy cập vào cổng của EC2 instance được điều khiển bằng security group, nên câu hỏi thực chất là: dịch vụ nào rà soát cấu hình security group trong tài khoản?
• "a quick way to determine" (cách nhanh để xác định) — người dùng muốn một câu trả lời có sẵn, dạng kiểm tra tự động, chứ không muốn thu thập log rồi tự phân tích, cũng không muốn tự mở từng security group ra đọc.

Ghép hai ràng buộc lại: cần một dịch vụ kiểm tra cấu hình (configuration check) và trình bày kết quả sẵn, không phải dịch vụ ghi log hay dịch vụ phòng thủ tấn công.

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

D. AWS Trusted Advisor.

Trusted Advisor quét tài khoản AWS và đưa ra khuyến nghị theo nhiều nhóm, trong đó có nhóm bảo mật. Một trong các hạng mục kiểm tra của nó chính là rà soát security group để phát hiện những group cho phép unrestricted access tới các cổng. Kết quả hiện thẳng trong console dưới dạng danh sách cảnh báo, kèm chỉ dẫn để bạn xử lý — tức là sửa lại rule trong security group cho hẹp phạm vi nguồn lại.

Đúng cả hai vế mà đề đòi hỏi: nó nhìn vào cấu hình security group (đúng nơi quyết định cổng nào mở), và nó cho kết quả ngay lập tức, không cần cấu hình thu thập dữ liệu trước — khớp với chữ "quick way".

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

A. AWS CloudWatch Logs — Đây là nơi thu thập và lưu trữ log của ứng dụng và của các dịch vụ AWS. Nó cho bạn biết ứng dụng đã ghi ra những gì, chứ không đọc cấu hình security group. Muốn dùng nó trả lời câu hỏi "cổng nào đang mở", bạn phải tự đẩy dữ liệu vào rồi tự viết truy vấn — vừa không phải chức năng của nó, vừa trái hẳn với yêu cầu "quick way".

B. VPC Flow Logs — Đây là phương án gần đúng nhất và cũng là bẫy chính của câu này, vì nó liên quan trực tiếp tới lưu lượng mạng của EC2. Nhưng Flow Logs ghi lại thông tin về lưu lượng IP đi vào và đi ra các network interface trong VPC — tức là nó cho biết thực tế đã có ai kết nối tới đâu, chứ không cho biết cấu hình cho phép những gì. Khác biệt quan trọng: một cổng mở ra toàn Internet mà chưa ai chạm tới thì Flow Logs không có gì để ghi, và bạn sẽ tưởng là an toàn. Ngoài ra Flow Logs phải bật trước rồi mới có dữ liệu, và sau đó vẫn phải tự phân tích — không đáp ứng được "quick way".

C. AWS Shield — Đây là dịch vụ được quản lý để giảm thiểu tấn công từ chối dịch vụ phân tán (DDoS). Nó bảo vệ khỏi một loại tấn công cụ thể, hoàn toàn không có chức năng kiểm toán hay báo cáo cấu hình security group. Việc một cổng đang mở cho toàn Internet nằm ngoài phạm vi của Shield.

📌 Điểm cần nhớ

• Cổng của EC2 instance do security group điều khiển. Thấy đề nhắc "ports allow unrestricted access" thì hãy dịch ngay trong đầu thành "security group cho phép nguồn 0.0.0.0/0" — từ đó câu hỏi trở thành "dịch vụ nào kiểm tra cấu hình security group".
• Phân biệt "kiểm tra cấu hình" với "ghi lại lưu lượng". Trusted Advisor nhìn vào cấu hình cho phép gì; VPC Flow Logs ghi lại thực tế đã có gì đi qua. Câu hỏi hỏi về khả năng bị truy cập, không hỏi về lưu lượng đã xảy ra.
• Cụm "a quick way to determine" thường loại luôn mọi phương án dạng log. Log đòi bật trước, đợi dữ liệu, rồi tự phân tích; các dịch vụ khuyến nghị/đánh giá thì cho kết quả sẵn.
• Nhớ vai trò gọn của từng dịch vụ trong danh sách: Trusted Advisor = khuyến nghị và kiểm tra tài khoản (có nhóm bảo mật); VPC Flow Logs = lưu lượng IP ở network interface; AWS Shield = chống DDoS; CloudWatch Logs = thu thập log ứng dụng và dịch vụ.

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

Đề bài đặt người học vào vai một security operations engineer cần triển khai "threat detection and monitoring for malicious or unauthorized behavior" — tức là phát hiện mối đe doạ và giám sát liên tục các hành vi độc hại hoặc trái phép.

Cụm từ quyết định là "threat detection … for malicious or unauthorized behavior". Đây gần như là mô tả sản phẩm được viết lại nguyên văn. Hai chi tiết cần chú ý:

• "Detection" chứ không phải "protection" — đề hỏi công cụ nhìn ra chuyện bất thường, không phải công cụ chặn tấn công.
• "Behavior" — đối tượng theo dõi là hành vi (ai gọi API nào, workload nói chuyện với địa chỉ nào), không phải khoá mã hoá hay lưu lượng mạng thô.

Ba phương án còn lại đều là dịch vụ thuộc nhóm Security, Identity & Compliance, nên nếu chỉ nhớ "dịch vụ nào liên quan tới bảo mật" thì cả bốn đều hợp lệ. Phải chia theo chức năng cụ thể mới loại được.

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

A — Amazon GuardDuty.

GuardDuty là dịch vụ threat detection của AWS, làm đúng hai việc đề nêu: phát hiện mối đe doạ và giám sát bảo mật liên tục đối với hành vi độc hại hoặc trái phép, nhằm bảo vệ các AWS account và workload.

Cách nó làm việc khớp với chữ "behavior" trong đề: GuardDuty phân tích các nguồn dữ liệu hoạt động sẵn có trong tài khoản (các bản ghi hoạt động API, log DNS, log luồng mạng của VPC…) rồi đối chiếu với thông tin về mối đe doạ và các mô hình bất thường, để sinh ra findings — cảnh báo có mức độ nghiêm trọng kèm mô tả. Đó là vai trò một security operations engineer cần: một nguồn cảnh báo tập trung để điều tra, chứ không phải một cơ chế chặn.

Điểm mấu chốt ở mức Cloud Practitioner: hễ đề nói "threat detection" hoặc "continuous security monitoring" thì nghĩ ngay tới GuardDuty.

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

B — AWS KMS. AWS Key Management Service cho bạn quyền kiểm soát tập trung các khoá mã hoá dùng để bảo vệ dữ liệu: tạo khoá, phân quyền dùng khoá, quay vòng khoá. Đây là bảo vệ dữ liệu ở trạng thái nghỉ, hoàn toàn khác việc phát hiện hành vi bất thường. KMS có ghi lại việc khoá được dùng khi nào, nhưng bản thân nó không phân tích và không sinh cảnh báo về hành vi độc hại — nó là công cụ quản lý khoá, không phải công cụ giám sát.

C — AWS CloudHSM. CloudHSM là hardware security module trên cloud, cho phép bạn tự sinh và tự dùng khoá mã hoá của mình trong AWS Cloud, với module phần cứng dành riêng. Về mục đích, nó cùng họ với KMS — quản lý khoá và thao tác mật mã — chỉ khác ở chỗ khách hàng nắm quyền kiểm soát phần cứng chặt hơn. Nó không liên quan gì tới threat detection. Chọn C thường là do thấy chữ "security" trong tên dịch vụ.

D — AWS Shield. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi, vì Shield đúng là dịch vụ đối phó với hành vi tấn công. Nhưng Shield là dịch vụ quản lý bảo vệ chống DDoS (Distributed Denial of Service) — nó tập trung vào một loại tấn công duy nhất, và vai trò của nó là giảm thiểu/chống đỡ tấn công đang diễn ra chứ không phải phát hiện diện rộng các hành vi độc hại hoặc trái phép. Đề không hề nhắc tới DDoS, cũng không nói tới chuyện giữ cho ứng dụng sống sót qua tấn công; đề nói tới "detection and monitoring" nói chung. Phạm vi của Shield hẹp hơn hẳn thứ đề yêu cầu, nên nó sai.

📌 Điểm cần nhớ

• GuardDuty = threat detection + continuous security monitoring. Gặp cụm "malicious or unauthorized behavior", "detect threats", "continuously monitor accounts and workloads" thì chọn GuardDuty.
• Phân biệt "detect" với "protect". GuardDuty phát hiện và cảnh báo; Shield chống đỡ DDoS. Đề dùng động từ nào thì theo động từ đó.
• KMS và CloudHSM là nhóm quản lý khoá mã hoá, không phải nhóm giám sát. Chúng xuất hiện chung một câu hỏi thường chỉ để làm nhiễu; nếu đề không nói gì tới encryption key thì loại cả hai ngay từ đầu.
• Đề thi hay xếp bốn dịch vụ cùng thuộc nhóm Security, Identity & Compliance vào một câu. Đừng lọc theo nhóm, hãy lọc theo chức năng cụ thể: phát hiện mối đe doạ, chống DDoS, quản lý khoá, hay module phần cứng mật mã.