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

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

Đề hỏi: làm cách nào để chia sẻ dữ liệu over private connections giữa two accounts they own, và within a region.

Ba cụm từ này quyết định đáp án:

• "private connections" — luồng dữ liệu không được đi ra Internet công cộng. Loại ngay mọi cách làm dựa vào endpoint công khai.
• "two accounts" — hai tài khoản AWS khác nhau, chứ không phải hai subnet trong cùng một VPC. Vấn đề nằm ở ranh giới tài khoản, và ranh giới mạng đi kèm là ranh giới VPC.
• "within a region" — cùng một region, nên đây là bài toán nối mạng cơ bản chứ không phải chuyện liên vùng.

Ghép lại: cần một cơ chế nối hai VPC thuộc hai tài khoản để chúng định tuyến tới nhau bằng địa chỉ riêng. Đó chính là VPC peering.

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

C — Create a VPC peering connection.

VPC peering là kết nối mạng giữa hai VPC, cho phép tài nguyên ở hai bên định tuyến tới nhau bằng private IP address, y như thể chúng nằm trong cùng một mạng. Hai VPC đó không bắt buộc phải thuộc cùng một tài khoản — đây đúng là tình huống đề mô tả: công ty sở hữu hai account và muốn chúng trao đổi dữ liệu.

Cách dùng điển hình mà tài liệu AWS nêu ra chính là ví dụ trong đề: có nhiều AWS account thì peer các VPC lại để dựng một mạng chia sẻ tệp, hoặc để VPC bên này truy cập tài nguyên nằm trong VPC bên kia. Lưu lượng đi qua peering không cần Internet gateway, nên thoả mãn ràng buộc "private connections".

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

A — Configure matching CIDR address ranges. Đây là phương án gài bẫy ngược hẳn với thực tế. Đặt cho hai VPC cùng dải địa chỉ không tạo ra đường đi nào giữa chúng — muốn định tuyến thì phải có kết nối và route table, chứ trùng địa chỉ tự nó chẳng nối được gì. Tệ hơn, dải địa chỉ trùng hoặc chồng lấn (overlapping) lại là điều kiện khiến VPC peering không thiết lập được, vì router không thể quyết định một địa chỉ thuộc về bên nào. Nói cách khác, làm đúng theo phương án này là tự chặn mất đáp án C.

B — Create a subnet peering connection. Nghe rất giống C và đó là lý do nó tồn tại trong đề. Nhưng không có khái niệm peering ở mức subnet trong AWS: subnet chỉ là một dải địa chỉ nằm trong một Availability Zone của VPC, nó không phải là đối tượng để thiết lập kết nối ngang hàng. Đơn vị được peer là VPC. Đây là phương án bịa tên dịch vụ — dạng bẫy rất hay gặp, và cách chống là nhớ chính xác tên thật của dịch vụ.

D — Create an internal ELB. Internal ELB (load balancer nội bộ) có địa chỉ riêng, đúng là "private", nên thoạt nhìn có vẻ khớp với chữ "private connections". Nhưng vai trò của nó là phân phối lưu lượng tới các target bên trong VPC của chính nó, không phải mở đường mạng sang một VPC ở tài khoản khác. Nếu chưa có kết nối giữa hai VPC thì tài khoản bên kia đơn giản là không định tuyến tới được địa chỉ riêng của internal ELB đó. ELB giải bài toán cân bằng tải, không giải bài toán liên kết mạng giữa hai account.

📌 Điểm cần nhớ

• VPC peering nối hai VPC bằng private IP, và hai VPC đó có thể thuộc hai AWS account khác nhau. Thấy đề nêu "giữa hai tài khoản" + "private" thì đây gần như luôn là hướng trả lời ở mức Cloud Practitioner.
• CIDR chồng lấn là kẻ thù của peering, không phải điều kiện của peering. Thiết kế nhiều VPC thì phải quy hoạch dải địa chỉ không đè nhau ngay từ đầu.
• Đơn vị được peer là VPC, không phải subnet. Gặp tên dịch vụ nghe hợp lý mà bạn chưa từng thấy trong tài liệu, hãy nghi ngờ đó là phương án bịa.
• Load balancer giải bài toán phân phối lưu lượng, không giải bài toán kết nối mạng. Chữ "internal" chỉ nói lên địa chỉ của nó là riêng, không nói lên rằng ai cũng tới được nó.

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

Đề hỏi: thành phần nào đóng vai trò virtual firewall ở cấp instance EC2, dùng để kiểm soát lưu lượng cho một hoặc nhiều instance.

Cụm từ quyết định là "at the Amazon EC2 instance level" — tức là mức instance, chứ không phải mức subnet hay mức VPC. Trong VPC có hai lớp lọc lưu lượng nghe rất giống nhau (security group và network ACL), nên đề phải nêu rõ level để phân biệt. Cụm thứ hai hỗ trợ thêm là "for one or more instances": cùng một bộ luật gắn được cho nhiều instance khác nhau. Ai đọc lướt qua chữ "firewall" rồi chọn Network ACL sẽ trượt đúng ở chi tiết này.

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

B — Security groups. Security group chính là tường lửa ảo hoạt động ở mức instance: nó gắn trực tiếp vào network interface của EC2 instance và kiểm soát cả lưu lượng đi vào (inbound/ingress) lẫn đi ra (outbound/egress). Bạn tạo rule cho chiều vào và chiều ra, và một security group có thể gắn cho nhiều EC2 instance cùng lúc — khớp chính xác với vế "for one or more instances" trong đề. Đây là ranh giới bảo vệ gần instance nhất trong VPC, nên đúng cả về vị trí lẫn về cách gắn.

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

A — Route table. Đây không phải firewall. Route table là bảng định tuyến, quyết định gói tin đi về đâu (giữa các subnet trong VPC, ra internet gateway, sang virtual private gateway…), chứ không quyết định gói tin có được cho phép hay không. Route table cũng gắn với subnet, không gắn với instance. Nhầm lẫn thường gặp là coi "chặn một route" như chặn traffic — cơ chế và mục đích khác hẳn.

C — Virtual private gateway (VPG). Đây là phía AWS của kết nối AWS Managed VPN, tức đầu nối để mạng on-premises đi vào VPC qua đường hầm VPN. Nó là thành phần kết nối, không phải thành phần lọc, và không hề gắn vào instance. Phương án này chỉ "gần đúng" ở chỗ nó cũng nằm trong mảng networking của VPC.

D — Network Access Control Lists (ACL). Đây là phương án gây nhiễu mạnh nhất, vì network ACL đúng là một firewall trong VPC, cũng có rule allow/deny cho chiều vào và chiều ra. Chỗ nó hỏng nằm đúng ở cụm từ khoá của đề: network ACL hoạt động ở mức subnet, bạn gắn nó vào subnet chứ không gắn vào instance. Nó bảo vệ mọi thứ nằm trong subnet đó theo lô, còn đề đang hỏi thứ kiểm soát traffic cho từng instance cụ thể. Đổi đề thành "subnet level" thì D mới là đáp án.

📌 Điểm cần nhớ

• Security group = mức instance; Network ACL = mức subnet. Đây là cặp đối chiếu bị hỏi đi hỏi lại ở AWS Cloud Practitioner — đọc câu hỏi là tìm ngay chữ instance hay subnet để chọn.
• Security group gắn được cho nhiều instance, và một instance cũng có thể mang nhiều security group; nên cụm "one or more instances" trong đề là dấu hiệu chỉ thẳng vào security group.
• Cả security group lẫn network ACL đều có luật cho cả hai chiều inbound và outbound — đừng dùng "có kiểm soát chiều ra hay không" để phân biệt chúng, hãy dùng cấp gắn kết.
• Route table và virtual private gateway không phải cơ chế bảo mật: một cái lo định tuyến, một cái lo kết nối VPN từ phía AWS. Gặp câu hỏi về "firewall" thì loại hai nhóm này trước cho gọn danh sách.

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

Đề hỏi: "Which AWS technology enables you to group resources that share one or more tags?" — công nghệ nào của AWS cho phép gom nhóm các tài nguyên có chung một hoặc nhiều tag.

Cụm từ quyết định đáp án là "group resources that share one or more tags". Nó nói rõ hai điều:

• Đối tượng được gom là resources (EC2 instance, S3 bucket, RDS database… — tài nguyên hạ tầng), chứ không phải tài khoản, hoá đơn hay bản thân các tag.
• Tiêu chí gom là tag đã gắn lên tài nguyên đó.

Bốn phương án đều có chữ "groups" và nghe rất giống nhau, nên mẹo ở đây thuần tuý là nhận ra tên nào là dịch vụ/tính năng có thật của AWS. Ba trong bốn cái tên là bịa ra cho giống.

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

D — Resource groups là đáp án đúng.

AWS Resource Groups là tính năng cho phép tổ chức các tài nguyên AWS thành từng nhóm dựa trên tag (hoặc dựa trên một CloudFormation stack). Bạn định nghĩa điều kiện kiểu "tất cả tài nguyên có tag Environment = Production" và AWS tự dựng ra một nhóm gồm đúng những tài nguyên khớp điều kiện đó.

Điều này khớp từng chữ với đề bài: "group resources that share one or more tags". Lợi ích thực tế là dễ quản lý và tự động hoá thao tác trên số lượng lớn tài nguyên cùng lúc — xem tình trạng cả nhóm, áp dụng thao tác vận hành cho cả nhóm, thay vì phải mở từng tài nguyên một.

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

A — Consolidation groups: Không phải tên của tính năng nào trong AWS. Cái tên này ăn theo chữ consolidated billing (gộp hoá đơn của nhiều tài khoản trong một organization). Đó là chuyện thanh toán ở cấp tài khoản, không phải chuyện gom tài nguyên theo tag — và dù sao thì "consolidation groups" cũng không tồn tại.

B — Organization groups: Cũng không phải tính năng có thật. Nó dễ bị nhầm với AWS Organizations, nơi đúng là có khái niệm gom nhóm — nhưng thứ được gom là các AWS account, gom vào Organizational Unit (OU), và tiêu chí gom là cấu trúc phân cấp quản trị chứ không phải tag gắn trên tài nguyên. Đây là phương án gần đúng nhất về mặt "có gom nhóm thật", nhưng sai cả về đối tượng (account chứ không phải resource) lẫn về tên gọi.

C — Tag groups: Đây là bẫy nguy hiểm nhất vì đề bài có chữ "tags", nên chọn cái tên chứa chữ "Tag" là phản xạ tự nhiên. Nhưng "Tag groups" không phải là tính năng của AWS. AWS có các công cụ liên quan tới tag như Tag Editor để tìm và sửa tag hàng loạt, song thứ tạo ra nhóm dựa trên tag vẫn mang tên Resource Groups. Tag là tiêu chí, còn nhóm được đặt tên theo thứ được gom — tức là resource.

📌 Điểm cần nhớ

• Resource Groups = gom tài nguyên theo tag (hoặc theo CloudFormation stack), phục vụ quản lý và tự động hoá hàng loạt. Nhớ cặp từ khoá "tag → resource group".
• AWS Organizations gom account vào Organizational Unit, phục vụ quản trị và gộp hoá đơn. Đừng lẫn với việc gom tài nguyên.
• Với dạng câu hỏi mà cả bốn phương án chỉ khác nhau một chữ đứng trước "groups", việc cần làm đầu tiên là loại những tên không tồn tại trong AWS — thường chỉ có đúng một cái là tên dịch vụ thật.
• Cẩn thận với phương án lặp lại đúng từ khoá của đề (ở đây là "Tag"). Đề bài mô tả tiêu chí gom nhóm, còn tên dịch vụ thường đặt theo đối tượng được gom.

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

Đề yêu cầu nêu lợi ích của IAM group — và cụm từ quyết định là "benefits of using IAM groups" kết hợp với "(Select TWO)".

Đây là kiểu câu rất dễ mất điểm vì trong năm phương án có tới ba thứ đều thuộc thế giới AWS Security & Identity, nhưng chỉ hai cái mô tả đúng bản chất của group. Ràng buộc phân biệt nằm ở chỗ: group là vật chứa người dùng để gắn policy hàng loạt, chứ không phải nơi tạo ra policy, không phải công cụ kiểm soát mạng, và không phải cấu trúc phân cấp.

Nói cách khác, phải tự hỏi với từng phương án: "Đây là việc của group, hay là việc của một thành phần khác được nhắc tên nhầm chỗ?"

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

Đáp án đúng theo tệp là C và D.

C — "Enables you to attach IAM permission policies to more than one user at a time": đúng đặc tính cốt lõi của group. Group là một tập hợp user, và policy được gắn vào group sẽ áp cho toàn bộ thành viên. Thay vì gắn cùng một policy vào mười user riêng lẻ, ta gắn một lần vào group.

D — "Groups let you specify permissions for multiple users, which can make it easier to manage the permissions for those users": đây là hệ quả vận hành của C, và cũng là lý do AWS khuyến nghị tổ chức user theo chức năng công việc (developer, admin, kế toán…). Thêm người mới thì bỏ vào group là xong; đổi quyền thì sửa policy của group thay vì sửa từng người, giúp giữ được nguyên tắc least privilege mà không sa lầy vào quản lý thủ công.

C và D nghe khá giống nhau — một cái nói về cơ chế kỹ thuật (gắn policy cho nhiều user cùng lúc), một cái nói về lợi ích quản trị (dễ quản lý hơn). Đề hỏi "benefits", cả hai góc đều là benefit hợp lệ, nên chọn cả hai.

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

A — "Provide the ability to nest groups to create an organizational hierarchy": sai vì IAM không cho lồng group trong group. Đây là phương án gài bẫy nặng nhất, vì ai quen với Active Directory hay LDAP sẽ mặc định rằng group phải lồng được. IAM group là cấu trúc phẳng: nó chứa user, không chứa group khác. Muốn diễn đạt quan hệ phân cấp trong AWS thì đó là chuyện của cấu trúc tài khoản (Organizations/OU), không phải của IAM group.

B — "You can restrict access to the subnets in your VPC": sai vì đây là mô tả của Network ACL — thứ kiểm soát lưu lượng ra vào ở mức subnet trong VPC. IAM làm việc ở tầng danh tính và quyền gọi API AWS, không phải tầng mạng. Hai cơ chế này trả lời hai câu hỏi khác nhau: IAM hỏi "danh tính này được phép làm hành động gì trên tài nguyên nào", còn Network ACL hỏi "gói tin này có được đi vào subnet này không".

E — "Provide the ability to create custom permission policies": gần đúng nhất trong ba phương án sai, nên cần nói rõ nó hỏng ở đâu. Việc tạo policy tuỳ chỉnh (customer managed policy) là khả năng của IAM policy, tồn tại độc lập với group. Bạn tạo policy rồi mới gắn nó vào user, group hoặc role. Group tiêu thụ policy chứ không sinh ra policy — bỏ hết group đi thì bạn vẫn viết được policy tuỳ chỉnh như thường. Vì vậy đây không phải lợi ích của group.

📌 Điểm cần nhớ

• IAM group = tập hợp user để gắn policy hàng loạt. Mọi phương án mô tả chức năng khác (tạo policy, lọc mạng, phân cấp) đều sai dù nghe rất "IAM".
• IAM group không lồng được. Đây là điểm khác biệt thường bị nhầm với Active Directory và xuất hiện lặp lại trong đề thi.
• Phân biệt nơi tạo và nơi gắn: IAM policy là thứ được tạo; user, group, role là nơi policy được gắn vào.
• Câu hỏi về "hạn chế truy cập subnet trong VPC" luôn thuộc về Network ACL / security group, không bao giờ thuộc về IAM — gặp cụm "subnet" trong một câu hỏi IAM là dấu hiệu của phương án gài bẫy.

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

Đề hỏi: dịch vụ hoặc tính năng nào của AWS giúp giới hạn những dịch vụ, tài nguyên và từng API action mà users và roles trong mỗi member account được phép dùng.

Cụm từ quyết định đáp án là "member account" — thuật ngữ này chỉ tồn tại trong ngữ cảnh một tổ chức nhiều tài khoản, tức là AWS Organizations (management account + các member account). Cụm thứ hai đáng chú ý là "individual API actions": thứ cần tìm phải tác động ở mức từng lệnh gọi API, chứ không phải mức mạng hay mức hạ tầng.

Ghép hai cụm lại: câu hỏi đang mô tả một hàng rào quyền hạn áp từ trên xuống cho các tài khoản trong tổ chức. Đó chính là Service Control Policy (SCP) — một loại policy của AWS Organizations.

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

Đáp án đúng là D — AWS Organizations.

AWS Organizations cung cấp các loại policy áp cho tài khoản trong tổ chức, trong đó có:

• Service control policies (SCPs): kiểm soát tập trung mức quyền tối đa mà các account trong tổ chức có thể có.
• Tag policies: chuẩn hoá cách gắn tag cho tài nguyên trên các account.

SCP chính là công cụ dùng để hạn chế quyền truy cập bên trong member account. Ví dụ, có thể tạo một SCP cấm một API action cụ thể — chẳng hạn cấm khởi chạy một loại EC2 instance nào đó. Khi SCP đó có hiệu lực, không ai trong account đó launch được loại instance ấy, kể cả administrator của chính account đó.

Đây là điểm mấu chốt: SCP không cấp quyền, nó đặt trần quyền. Quyền thực tế = giao của (những gì IAM policy cho phép) và (những gì SCP cho phép). Vì vậy nó đúng với cả ba vế mà đề nêu: dịch vụ, tài nguyên, và từng API action.

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

A — AWS Firewall Manager: đây là dịch vụ quản lý tập trung các dịch vụ bảo mật trong AWS. Đây là phương án gần đúng nhất và dễ đánh lừa nhất, vì nó cũng hoạt động xuyên nhiều account trong một tổ chức. Nhưng thứ nó quản lý là quy tắc bảo vệ lưu lượng mạng (các rule bảo mật áp lên tài nguyên), chứ không phải quyền IAM của users và roles. Nó không chặn được một API action mà một người dùng gọi tới AWS.

B — AWS Shield: dịch vụ bảo vệ chống tấn công DDoS. Nó xử lý lưu lượng độc hại từ Internet đổ vào ứng dụng, hoàn toàn nằm ở mặt phẳng mạng. Không liên quan gì tới việc ai được gọi API nào — sai chủ đề, không phải sai chi tiết.

C — Amazon Cognito: dịch vụ cung cấp đăng ký và đăng nhập cho ứng dụng (điển hình là ứng dụng mobile và web). Đây là bẫy dễ vướng nếu chỉ bắt từ khoá "users", vì Cognito đúng là quản lý người dùng. Nhưng đó là người dùng cuối của ứng dụng bạn viết, không phải users và roles trong AWS account. Cognito không đặt được giới hạn quyền lên member account trong một tổ chức.

📌 Điểm cần nhớ

• Thấy chữ "member account", "organization", hay "across all accounts" trong đề về giới hạn quyền → nghĩ ngay tới AWS Organizations / SCP.
• SCP đặt trần quyền, không cấp quyền. Quyền cuối cùng là phần giao giữa IAM policy và SCP; SCP chặn được cả administrator của member account.
• Phân biệt hai nhóm dễ lẫn: Organizations là quyền (API/identity), còn Firewall Manager và Shield là bảo vệ mạng/lưu lượng.
• Cognito quản lý người dùng của ứng dụng, IAM/Organizations quản lý người dùng của AWS account. Đừng để từ khoá "users" kéo sang nhầm nhóm.

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

Đề hỏi: tên gọi của "top-level container" dùng để chứa objects trong Amazon S3 là gì.

Cụm từ quyết định đáp án là "top-level container" — vật chứa ở cấp cao nhất, và "within Amazon S3" — giới hạn phạm vi vào đúng dịch vụ S3. Hai ràng buộc này lọc sạch danh sách:

• "top-level" loại những thứ nằm bên trong vật chứa cấp cao nhất (Folder).
• "within Amazon S3" loại những khái niệm lưu trữ thuộc dịch vụ khác (Instance Store) hoặc thuộc mô hình lưu trữ khác (Directory của filesystem).

Đây là câu kiểm tra thuật ngữ nền tảng: S3 là object storage, không phải block storage cũng không phải file storage, nên từ vựng của nó cũng riêng.

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

Đáp án đúng theo tệp là B — Bucket.

Amazon S3 là hệ thống lưu trữ dựa trên object. Bạn upload object vào bucket, và bucket chính là vật chứa cấp cao nhất trong S3: mọi object đều phải thuộc về một bucket nào đó, không có object nào "trôi nổi" ngoài bucket. Bucket cũng là đơn vị bạn tạo ra đầu tiên trước khi đưa dữ liệu lên, là nơi gắn các thiết lập ở cấp vùng chứa, và là thành phần xuất hiện trong đường dẫn tới object. Đúng chữ "top-level container" mà đề bài hỏi.

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

A — Instance Store. Sai vì đây không thuộc S3 chút nào. Instance Store là dạng lưu trữ block-based, tạm thời (ephemeral) gắn trực tiếp vào EC2 instance; dữ liệu trên đó mất khi instance dừng. Nó vừa sai dịch vụ, vừa sai mô hình lưu trữ (block chứ không phải object), nên bị loại ngay từ vòng đầu.

C — Folder. Đâ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. Folder có tồn tại trong trải nghiệm sử dụng S3: console cho phép nhóm object bằng folder để nhìn cho gọn. Nhưng nó hỏng ở đúng chữ "top-level" — folder luôn nằm bên trong một bucket, không bao giờ đứng trên bucket. Thêm nữa, S3 vốn có cấu trúc phẳng (flat), không phân cấp thật sự; folder chỉ là cách trình bày để gom nhóm object chứ không phải một tầng chứa thực sự như trong filesystem. Chọn C là trả lời đúng "một cách gom nhóm" nhưng sai "cấp cao nhất".

D — Directory. Sai vì directory là từ vựng của filesystem (lưu trữ dạng file, có cây thư mục thật), không phải của hệ thống lưu trữ object như S3. Nó cùng họ nhầm lẫn với C nhưng còn xa hơn: folder ít nhất còn xuất hiện trong giao diện S3, còn directory thì thuộc hẳn mô hình lưu trữ khác.

📌 Điểm cần nhớ

• S3 = object storage; đơn vị chứa cấp cao nhất là bucket. Object luôn nằm trong một bucket, không có ngoại lệ.
• Folder trong S3 chỉ là cách gom nhóm để nhìn cho dễ, nằm bên trong bucket, và không tạo ra cấu trúc phân cấp thật — bản chất S3 là phẳng.
• Directory thuộc từ vựng filesystem, thấy nó trong câu hỏi về S3 thì gần như chắc chắn là mồi nhử.
• Instance Store là block storage tạm thời của EC2, không liên quan tới S3 — nhớ tách bạch ba mô hình: object (S3), block (Instance Store, EBS), file (filesystem).
• Với dạng câu hỏi hỏi thuật ngữ, hãy bám vào định ngữ giới hạn trong đề ("top-level", "within…") — thường chính nó phân biệt phương án đúng với phương án gần đúng.

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

Đề hỏi: cần tạo tài khoản IAM ở đâu cho một tổ chức hoạt động toàn cầu (global organization).

Cụm từ quyết định đáp án nằm ở chữ "Where … need to be created" đặt cạnh "global organization". Cả bốn phương án đều là những cách trả lời "ở đâu" khác nhau: theo khu vực địa lý, theo region, tạo rồi nhân bản, hoặc chỉ tạo một lần. Điều phân biệt chúng không phải là quy mô công ty, mà là bản chất phạm vi (scope) của chính dịch vụ IAM.

Đây là chỗ đề gài bẫy: nhắc tới "global organization" khiến người làm bài nghĩ theo hướng "công ty trải khắp thế giới thì chắc phải làm gì đó ở từng nơi". Nhưng quy mô của tổ chức không liên quan; câu trả lời phụ thuộc vào việc IAM là dịch vụ global hay regional.

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

D — "Just create them once, as IAM is a global service".

IAM là một dịch vụ global, không phải dịch vụ theo region. Tài nguyên IAM — user, group, role, policy — thuộc về tài khoản AWS, chứ không thuộc về một region cụ thể nào. Vì vậy:

• Bạn tạo IAM user một lần duy nhất trong tài khoản.
• User đó dùng được để truy cập tài nguyên ở bất kỳ region nào, miễn là policy gắn cho họ cho phép.
• Không có thao tác "tạo lại ở region khác", và cũng không có khái niệm "IAM user của region eu-west-1".

Chuyện nhân viên ngồi ở đâu trên thế giới không đổi được điều này. Một tổ chức toàn cầu vẫn quản lý cùng một bộ danh tính duy nhất — đó chính là ưu điểm của một dịch vụ global: quản trị tập trung, không phải đồng bộ danh tính giữa các nơi.

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

A — "In each geographical area where the users are located" Sai vì IAM không có khái niệm phạm vi theo khu vực địa lý. "Khu vực địa lý" ở đây thậm chí còn không phải một đơn vị hạ tầng của AWS (AWS chia theo region và Availability Zone). Phương án này chỉ đơn thuần lặp lại trực giác "người ở đâu thì tạo tài khoản ở đó", vốn không phải cách IAM hoạt động.

B — "Create them globally, and then replicate them regionally" Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì nửa đầu của nó ("create them globally") hoàn toàn chính xác. Chỗ hỏng nằm ở nửa sau: không hề có bước replicate nào. Khi một dịch vụ đã là global, danh tính vốn đã dùng được ở mọi nơi — không tồn tại thao tác nhân bản sang region cho người quản trị làm, dù thủ công hay tự động. Phương án này mô tả một quy trình không có thật, và trong đề trắc nghiệm thì thừa một bước sai cũng đủ làm cả phương án sai.

C — "In each region where the users are located" Sai vì đây chính là mô tả của một dịch vụ regional, mà IAM thì không phải. Nếu chọn phương án này, hệ quả sẽ là mỗi region phải có một bộ user riêng — trái ngược hoàn toàn với thực tế rằng IAM user là tài nguyên cấp tài khoản. Ngoài ra, "region nơi người dùng ở" cũng là cách hiểu sai về region: region là nơi đặt tài nguyên và hạ tầng, không phải nơi con người ngồi.

📌 Điểm cần nhớ

• IAM là dịch vụ global: user, group, role, policy thuộc về tài khoản AWS, không thuộc region nào. Tạo một lần, dùng ở mọi nơi.
• Với dịch vụ global, mọi phương án chứa động từ kiểu "replicate", "sync", "create in each region" gần như chắc chắn sai — dịch vụ global không cần bước nhân bản thủ công nào.
• Đừng để chi tiết bối cảnh trong đề (như "global organization", số lượng nhân viên, vị trí địa lý) đánh lạc hướng: câu hỏi thật sự đang kiểm tra phạm vi của dịch vụ, không phải quy mô doanh nghiệp.
• Region là nơi đặt tài nguyên, không phải nơi đặt người dùng. Phương án nào gắn region với vị trí địa lý của nhân viên là dấu hiệu của một phương án gây nhiễu.

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

Đề hỏi: "Which resource should you use to access AWS security and compliance reports?" — tức là bạn cần lấy về các báo cáo tuân thủ và bảo mật của AWS (kiểu SOC, PCI, ISO…) để đưa cho bộ phận kiểm toán hay khách hàng của mình.

Cụm từ quyết định là "access ... reports". Đây là một câu về nơi tải tài liệu, không phải câu về cách cấu hình bảo mật hay cách quản trị tài khoản. Nhiều người đọc thấy chữ "security" là lập tức nghĩ tới IAM, hoặc thấy "compliance" là nghĩ tới Organizations vì nó gắn với governance. Nhưng động từ trong đề là "access reports" — bạn đang đi lấy giấy tờ AWS đã có sẵn, chứ không tạo ra thứ gì trong tài khoản của mình.

Ràng buộc thứ hai, tinh hơn: đề nói "resource" ở dạng số ít và hỏi nơi truy cập — nên đáp án phải là một cổng/dịch vụ, không phải bản thân một tờ giấy tờ.

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

Đáp án đúng theo tệp là A — AWS Artifact.

AWS Artifact là cổng tự phục vụ (self-service) nằm ngay trong AWS Console, cho phép khách hàng truy cập theo yêu cầu (on-demand) vào tài liệu tuân thủ của AWS và các thoả thuận (agreements) với AWS. Đúng nghĩa "audit artifact retrieval portal" — nơi bạn vào tải các báo cáo kiểm toán mà AWS đã được bên thứ ba đánh giá, thay vì phải mở ticket hỏi AWS từng lần.

Nó khớp chính xác cả hai vế của đề: security and compliance (nội dung tài liệu) và access (hành động tải về). Đây là dịch vụ duy nhất trong bốn phương án tồn tại để phát tài liệu.

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

B — AWS Organizations. Đây là dịch vụ quản trị tập trung nhiều tài khoản AWS: tự động tạo account, gom account thành các nhóm (OU) phản ánh cơ cấu doanh nghiệp, và áp policy lên các nhóm đó để kiểm soát. Nó liên quan tới governance, và chính chữ này khiến nhiều người nhầm sang "compliance". Nhưng Organizations thực thi chính sách trong môi trường của bạn — nó không chứa và không phát hành báo cáo kiểm toán nào của AWS.

C — AWS IAM. IAM là dịch vụ tạo và quản lý user, group, role và policy — tức là ai được làm gì trong tài khoản của bạn. Đây là phương án "bẫy từ khoá" điển hình: đề có chữ "security", IAM là dịch vụ security nổi tiếng nhất, nên phản xạ đầu tiên hay chọn nó. Nhưng IAM cấp quyền, không cấp tài liệu. Đọc kỹ đề sẽ thấy không hề có ý nào về phân quyền hay danh tính.

D — AWS Business Associate Addendum (BAA). Đây là phương án gần đúng nhất và cũng nguy hiểm nhất, vì nó thật sự nằm trong chủ đề compliance. BAA là một thoả thuận — cụ thể là phụ lục pháp lý bạn chấp nhận khi khối lượng công việc có liên quan tới dữ liệu y tế. Chỗ hỏng: BAA không phải là "resource để truy cập báo cáo" — nó chính là một trong những tài liệu bạn chấp nhận bên trong AWS Artifact, ở phần Agreements. Nói cách khác, D là nội dung, còn A là cái cổng. Đề hỏi cái cổng. Ngoài ra BAA chỉ là một thoả thuận đơn lẻ, không bao trùm được cả cụm "security and compliance reports" số nhiều trong đề.

📌 Điểm cần nhớ

• AWS Artifact = nơi tải tài liệu tuân thủ và ký các thoả thuận của AWS. Câu nào có "compliance report", "audit document", "download SOC/PCI/ISO", "on-demand access to AWS agreements" thì gần như chắc chắn là Artifact.
• Phân biệt cổng chứa tài liệu (Artifact) với một tài liệu cụ thể trong đó (BAA). Đề hỏi "which resource to access" → chọn cổng; đề hỏi "which agreement do you accept for healthcare data" → mới chọn BAA.
• Chữ "security" trong đề không tự động dẫn tới IAM. IAM trả lời câu hỏi ai được làm gì; nếu đề không nói tới user, role, permission hay policy thì IAM thường là bẫy từ khoá.
• Organizations là governance của môi trường bạn, không phải compliance của AWS. Nó áp policy lên nhiều account; nó không sinh ra bằng chứng kiểm toán để nộp cho auditor.

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

Đề hỏi: "Which of the following are NOT features of AWS IAM? (Select TWO.)" — tức là chọn ra hai thứ KHÔNG PHẢI tính năng của AWS IAM.

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

• "NOT features" — đây là câu hỏi phủ định. Đọc lướt rất dễ chọn nhầm những phương án nghe đúng về IAM, vì bốn trong năm phương án đều là câu mô tả đúng — và chính vì đúng nên chúng sai với câu hỏi này. Gặp chữ "NOT", "EXCEPT", "LEAST" thì phải đảo ngược tiêu chí chấm ngay từ đầu.
• "(Select TWO)" — chốt đúng hai phương án. Nếu bạn thấy ba thứ có vẻ không phải tính năng IAM, nghĩa là bạn đã hiểu sai một phương án nào đó.

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

Đáp án theo tệp: C và E.

C — "Logon using local user accounts": IAM quản lý danh tính bên trong AWS account — IAM user, group, role, policy. Nó không tạo và không quản lý tài khoản người dùng cục bộ trên hệ điều hành của máy (Windows local account, user trong /etc/passwd của Linux). Bạn không dùng IAM để đăng nhập vào một EC2 instance bằng tài khoản local của chính instance đó; việc ấy thuộc về hệ điều hành hoặc một dịch vụ thư mục riêng. Đây không phải tính năng của IAM.

E — "Charged for what you use": IAM là dịch vụ miễn phí — bản thân IAM không phát sinh chi phí. Bạn trả tiền cho các dịch vụ AWS mà IAM cấp quyền truy cập, chứ không trả tiền cho việc tạo user, group, role hay policy. Vì thế "tính tiền theo mức sử dụng" không phải là một đặc điểm của IAM.

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

Ba phương án dưới đây đều là tính năng thật của IAM, nên chúng sai với câu hỏi phủ định này:

A — "Identity federation": IAM hỗ trợ federation thật. Bạn liên kết được với nhà cung cấp danh tính bên ngoài (corporate directory, SAML, hoặc identity provider dạng web) để người dùng đã có tài khoản ở nơi khác lấy được quyền truy cập tạm thời vào AWS mà không cần tạo IAM user riêng. Đây là một trong những khả năng được nhắc tới rõ ràng trong tài liệu giới thiệu IAM. Phương án này dễ nhầm với C vì cả hai đều nói về "đăng nhập bằng danh tính có sẵn ở nơi khác" — nhưng khác nhau ở chỗ: federation là danh tính từ một identity provider được IAM tin cậy, còn C là tài khoản cục bộ trên máy, thứ IAM hoàn toàn không đụng tới.

B — "PCI DSS compliance": IAM nằm trong phạm vi các chương trình tuân thủ của AWS, trong đó có PCI DSS. Nói cách khác, tuân thủ là một đặc điểm được liệt kê của dịch vụ. Phương án này gây phân vân vì compliance nghe giống một chứng nhận cấp tài khoản hơn là một "feature" của riêng IAM — nhưng theo cách câu hỏi này liệt kê thì đó vẫn là điều đúng về IAM, nên không phải thứ cần chọn.

D — "Shared access to your AWS account": Đây chính là công dụng cốt lõi của IAM. Thay vì phát mật khẩu root cho cả nhóm, bạn tạo IAM user hoặc role để nhiều người cùng làm việc trên một AWS account với quyền hạn riêng cho từng người. Đúng hoàn toàn về IAM, nên không chọn.

📌 Điểm cần nhớ

• Câu hỏi phủ định phải đọc kỹ chữ NOT/EXCEPT trước khi xét phương án. Với dạng này, phương án mô tả đúng dịch vụ chính là phương án bạn phải loại; đọc nhanh gần như chắc chắn chọn ngược.
• IAM bản thân nó không tính phí. Bạn trả tiền cho tài nguyên mà IAM cấp quyền, không trả tiền cho user/group/role/policy. Bất kỳ phương án nào gắn chi phí trực tiếp vào IAM đều đáng nghi.
• Ranh giới của IAM dừng ở AWS account. IAM cấp quyền cho các API và tài nguyên AWS; nó không quản lý tài khoản người dùng của hệ điều hành bên trong instance. Phân biệt "danh tính trong AWS" với "danh tính trong OS" là chỗ ra đề rất hay khai thác.
• Federation là tính năng có thật của IAM, dùng cho danh tính đến từ identity provider bên ngoài — đừng nhầm nó với đăng nhập bằng tài khoản local.
• Với dạng "(Select TWO)", hãy dùng chính con số đó làm bước kiểm tra cuối: nếu bạn đánh dấu nhiều hoặc ít hơn hai, chắc chắn có một phương án bạn đang hiểu sai.

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

Đề hỏi: theo AWS Well-Architected Framework, những bước change management (quản lý thay đổi) nào giúp đạt được reliability (độ tin cậy) trên AWS Cloud? Chọn HAI phương án.

Cụm từ quyết định đáp án là "change management steps" đặt cạnh "to achieve reliability". Đây không phải câu hỏi về bảo mật, cũng không phải câu hỏi về giới hạn quyền. Trong Reliability Pillar, change management xoay quanh một ý rất cụ thể: biết được hệ thống của mình đang gồm những gì, và biết được ai đã thay đổi cái gì, lúc nào. Khi sự cố xảy ra, phần lớn nguyên nhân đến từ một thay đổi nào đó — nên muốn tin cậy thì phải theo dõi và ghi nhận được thay đổi, chứ không phải cấm thay đổi.

Cụm thứ hai đáng chú ý là "(Select TWO)": có tới ba phương án nhắc đến việc ghi nhận/kiểm soát, nên phải phân biệt được dịch vụ nào thực sự làm việc ghi nhận thay đổi.

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

Đáp án theo tệp là A và B.

• A — AWS CloudTrail ghi lại các lời gọi API vào log kiểm toán được. CloudTrail trả lời câu hỏi ai đã gọi API nào, trên tài nguyên nào, vào lúc nào. Đúng nghĩa change management: khi một thay đổi làm hệ thống mất ổn định, log CloudTrail là thứ cho phép truy ngược lại chính thay đổi đó.
• B — AWS Config lập bản kiểm kê (inventory) tài nguyên AWS. Config theo dõi trạng thái cấu hình của tài nguyên và cấu hình đó đã thay đổi ra sao theo thời gian. Nó cho bạn bức tranh "hệ thống hiện gồm những gì và trước đó trông thế nào".

Hai cái bổ sung cho nhau và đó là lý do đề chọn cả hai: Config cho biết cái gì đã đổi, CloudTrail cho biết ai đã đổi và bằng lời gọi nào. Có đủ cặp này thì mới xác định được thay đổi nào gây ra vấn đề về reliability.

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

• C — AWS Certificate Manager tạo danh mục dịch vụ được phê duyệt. Sai ở bản chất dịch vụ. ACM dùng để cấp phát và quản lý chứng chỉ SSL/TLS, phục vụ mã hoá đường truyền. Nó hoàn toàn không có khái niệm "catalog of approved services". Đây là phương án dựa vào việc thí sinh chỉ nhớ mang máng chữ "Certificate/Manager" nghe có vẻ liên quan tới quản trị.

• D — Dùng service limits để ngăn người dùng tạo hoặc thay đổi tài nguyên. Đây là phương án gần đúng nhất và cũng là bẫy chính. Service limits (quota) đúng là một cơ chế bảo vệ, nhưng nó chỉ đặt trần số lượng tài nguyên được tạo ra. Nó không ngăn được việc thay đổi tài nguyên đang tồn tại — miễn là không vượt trần thì người dùng vẫn sửa thoải mái. Vì vậy nó không phải công cụ change management. Ngoài ra, hướng "ngăn cấm thay đổi" cũng lệch với tinh thần của pillar: mục tiêu là quan sát và kiểm soát được thay đổi, không phải chặn đứng thay đổi.

• E — Amazon GuardDuty ghi hoạt động API vào một S3 bucket. Sai ở việc gán nhầm vai trò của dịch vụ. GuardDuty là dịch vụ phát hiện mối đe doạ: nó phân tích các nguồn dữ liệu (trong đó có hoạt động API) để cảnh báo hành vi đáng ngờ, chứ bản thân nó không phải nơi ghi lại nhật ký API vào S3 — đó chính là việc của CloudTrail ở phương án A. Thêm nữa, GuardDuty thuộc nhóm security, còn câu hỏi này nằm ở trục reliability. Chọn E thường là do lẫn giữa "dịch vụ dùng log API" và "dịch vụ tạo ra log API".

📌 Điểm cần nhớ

• CloudTrail = ai làm gì (API calls, audit trail); AWS Config = tài nguyên trông thế nào và đã đổi ra sao (configuration history, inventory). Cặp đôi này là câu trả lời mặc định cho mọi câu hỏi dạng "theo dõi thay đổi".
• Trong Well-Architected Reliability Pillar, change management nghĩa là quan sát được thay đổi, không phải cấm thay đổi. Phương án nào có động từ "prevent users from…" thường là bẫy.
• Service limits/quota là cơ chế giới hạn số lượng tạo mới, không phải cơ chế kiểm soát việc sửa đổi tài nguyên đã có.
• Phân biệt dịch vụ sinh ra log với dịch vụ tiêu thụ log để phân tích: CloudTrail sinh log, GuardDuty phân tích để tìm mối đe doạ. Và ACM chỉ làm chứng chỉ TLS — đừng để tên gọi kéo nó sang vai trò quản trị.