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

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

Đề hỏi: dịch vụ nào cho phép gán một policy vào một group?

Cụm từ quyết định là "assign a policy to a group". Hai chữ policy và group đi cùng nhau là dấu hiệu chỉ thẳng vào mô hình phân quyền của AWS: group ở đây là tập hợp các user trong tài khoản AWS, còn policy là tài liệu JSON mô tả cho phép hay từ chối hành động nào trên tài nguyên nào. Chỉ có đúng một dịch vụ trong danh sách sở hữu cả hai khái niệm này như những đối tượng do chính nó quản lý.

Lưu ý cách đọc đề: câu hỏi không hỏi "làm sao cấp quyền tạm thời", cũng không hỏi "làm sao xác thực người dùng ứng dụng di động", và càng không hỏi về bảo vệ hệ thống trước tấn công. Nó hỏi về thao tác gắn policy lên group — một thao tác quản trị danh tính thuần tuý. Ba phương án còn lại đều liên quan tới bảo mật theo nghĩa rộng, nên chúng trông hợp lý nếu đọc lướt; chỉ có ràng buộc group mới tách bạch được chúng.

(Phương án D trong đề gốc bị gõ nhầm thành "AWSn STS", nhưng ý muốn nói là AWS STS.)

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

A. AWS IAM là đáp án đúng.

IAM (Identity and Access Management) là dịch vụ dùng để kiểm soát an toàn quyền truy cập của từng cá nhân và từng nhóm vào tài nguyên AWS. Trong IAM:

• Group là một tập hợp các IAM user.
• Policy có thể được attach trực tiếp vào group.
• Mọi user thuộc group đó thừa hưởng quyền từ policy đã gắn.

Đây chính là cách làm được khuyến nghị để quản trị quyền ở quy mô lớn: thay vì gán policy cho từng user một, ta gán policy cho group rồi thêm user vào group. Người mới vào chỉ cần cho vào đúng group là có ngay bộ quyền chuẩn; người chuyển việc thì đổi group. Vậy nên IAM là dịch vụ duy nhất trong danh sách trả lời đúng câu hỏi "gán policy cho group".

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

B. AWS Shield — Đây là dịch vụ được quản lý để chống tấn công DDoS (Distributed Denial of Service), bảo vệ các ứng dụng đang chạy trên AWS. Nó làm việc ở tầng lưu lượng mạng và ứng dụng: phát hiện, hấp thụ và giảm nhẹ các đợt tấn công làm nghẽn hệ thống. Shield không có khái niệm user, group hay policy phân quyền — nó không phải là công cụ quản trị danh tính. Đây là phương án dễ loại nhất, chỉ trùng với đề ở chỗ cùng thuộc mảng bảo mật.

C. Amazon Cognito — Đây là phương án gần đúng nhất và dễ gây nhầm nhất, vì Cognito cũng làm việc với "user" và cũng có khái niệm nhóm. Nhưng Cognito phục vụ xác thực người dùng của ứng dụng — đặc biệt là ứng dụng di động và web, tức là khách hàng cuối dùng app của bạn, chứ không phải người vận hành hạ tầng AWS. Đối tượng nó quản lý là danh tính ứng dụng, không phải các IAM principal trong tài khoản AWS. Câu hỏi này đang hỏi về mô hình phân quyền tài nguyên AWS, nên Cognito lệch phạm vi: nó xác thực ai là ai cho tầng ứng dụng, chứ không phải nơi ta gắn policy vào IAM group.

D. AWS STS — Cũng là một phương án gần đúng vì STS nằm ngay trong họ IAM. Security Token Service là dịch vụ cho phép yêu cầu thông tin đăng nhập tạm thời, quyền hạn giới hạn cho IAM user hoặc cho federated user (người dùng được xác thực từ hệ thống bên ngoài). Điểm hỏng của nó: STS cấp phát credential tạm thời, nó không phải nơi ta tạo và gắn policy vào group. STS trả lời câu hỏi "làm sao có credential ngắn hạn", còn IAM trả lời câu hỏi "quyền được định nghĩa và gắn ở đâu". Nếu đề hỏi về credential tạm thời hoặc về assume role, STS mới là đáp án.

📌 Điểm cần nhớ

• Thấy đồng thời hai từ policy và group (hoặc user, role) trong đề AWS thì gần như chắc chắn đáp án là IAM — đó là dịch vụ định nghĩa và gắn quyền cho các principal trong tài khoản AWS.
• Phân biệt IAM và Cognito theo đối tượng được quản lý: IAM dành cho người/dịch vụ truy cập tài nguyên AWS; Cognito dành cho người dùng cuối của ứng dụng web/mobile.
• Phân biệt IAM và STS theo loại credential: IAM quản lý danh tính và policy lâu dài; STS cấp credential tạm thời, quyền hạn giới hạn, kể cả cho federated user.
• AWS Shield thuộc nhóm bảo vệ trước tấn công DDoS, không liên quan gì tới phân quyền — gặp là loại ngay khi đề nói về policy hay quyền truy cập.
• Gắn policy vào group thay vì vào từng user là cách quản trị quyền dễ mở rộng: thêm/bớt người chỉ cần đổi group, không phải sửa quyền từng tài khoản.

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

Đề hỏi: dịch vụ AWS nào cho phép tạo và quản lý các AWS account một cách nhanh chóng và tự động ("a quick and automated way to create and manage AWS accounts").

Cụm từ quyết định ở đây là "create and manage AWS accounts" — đối tượng được thao tác là chính tài khoản AWS, chứ không phải máy chủ, dữ liệu hay khách hàng. Cụm bổ nghĩa "automated" là ràng buộc thứ hai: dịch vụ phải có API để gọi bằng mã, không chỉ làm tay qua Console.

Chỉ cần bám vào hai cụm đó là loại được ba phương án còn lại, vì cả ba đều là dịch vụ giải quyết bài toán bên trong một tài khoản, không phải bài toán quản trị nhiều tài khoản.

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

C. AWS Organizations là dịch vụ gộp nhiều AWS account vào một organization để quản trị tập trung: account và tài nguyên của chúng được quản lý từ một chỗ.

Điểm khớp trực tiếp với đề:

• AWS Organizations có API tạo account mới — nghĩa là việc tạo account có thể viết thành mã và chạy tự động, đúng với chữ "quick and automated" trong đề.
• Sau khi tạo, account nằm sẵn trong organization nên được quản lý tiếp từ đó (tổ chức theo cấu trúc, áp chính sách chung, gộp hoá đơn) — đúng với vế "and manage" của đề.

Đây là dịch vụ duy nhất trong bốn phương án làm việc ở cấp account.

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

A. Amazon Connect — là contact center trên cloud, dạng omnichannel, dùng để doanh nghiệp phục vụ khách hàng (tổng đài, chat) với chi phí thấp hơn. Có chữ "manage" và có liên quan tới "khách hàng", nhưng đối tượng nó quản lý là cuộc liên hệ với khách hàng, không phải AWS account. Đây là bẫy từ ngữ: "account" trong đề là tài khoản AWS, không phải tài khoản khách hàng.

B. Amazon Lightsail — cung cấp máy chủ ảo (instance) dựng nhanh, đóng gói sẵn để người mới dễ bắt đầu. Phương án này bắt đúng chữ "quick" trong đề — Lightsail nổi tiếng vì dựng nhanh, ít lựa chọn cấu hình — nhưng cái nó dựng nhanh là instance, không phải account. Sai ở danh từ chịu tác động, dù tính từ có vẻ khớp.

D. Amazon QuickSight — dịch vụ business intelligence chạy trên cloud, dùng để dựng dashboard và chia sẻ insight cho mọi người trong tổ chức. Phương án này gần đúng theo kiểu khác: chữ "Quick" trùng với "quick" trong đề, và mô tả chính thức của QuickSight cũng có từ "organization". Nhưng "organization" ở đây nghĩa là công ty/tổ chức người dùng đọc báo cáo, hoàn toàn không phải AWS Organizations. QuickSight trực quan hoá dữ liệu, không tạo account.

📌 Điểm cần nhớ

• Câu hỏi nhắc tới tạo và quản lý nhiều AWS account thì gần như luôn trỏ về AWS Organizations — đó là dịch vụ ở cấp account, phía trên các dịch vụ hạ tầng thông thường.
• Đọc kỹ danh từ mà động từ trong đề tác động lên, đừng bám vào tính từ. "Quick" xuất hiện trong tên QuickSight và trong tinh thần của Lightsail, nhưng thứ quyết định là "AWS accounts".
• Từ "account" trong đề thi AWS mặc định là tài khoản AWS, không phải tài khoản khách hàng của doanh nghiệp — đây là chỗ Amazon Connect hay được cài làm mồi.
• "Automated" trong đề thường ám chỉ dịch vụ có API gọi được bằng mã, không chỉ thao tác qua Console; đây là dấu hiệu phân biệt hữu ích khi hai phương án cùng làm được việc bằng tay.

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

Đề hỏi: làm sao triển khai hạ tầng AWS Cloud sang nhiều AWS Region một cách nhanh, tự động và đáng tin cậy?

Cụm từ quyết định đáp án là "deploy AWS Cloud infrastructure to multiple AWS Regions". Có hai chi tiết cần tách bạch:

• "infrastructure" — thứ được triển khai là hạ tầng (VPC, EC2, security group, load balancer…), không phải mã ứng dụng. Ràng buộc này loại ngay những phương án nói về deploy source code hay continuous delivery.
• "multiple AWS Regions… quickly, automatically, and reliably" — cần một thứ mô tả hạ tầng dưới dạng khuôn mẫu tái sử dụng được, đem sang Region khác là dựng lại y hệt. Đây chính là định nghĩa của Infrastructure as Code (IaC).

Ghép hai chi tiết lại, câu hỏi đang tìm dịch vụ IaC của AWS.

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

D. Create and use an AWS CloudFormation template.

AWS CloudFormation là dịch vụ Infrastructure as Code của AWS: bạn khai báo toàn bộ tài nguyên mong muốn trong một template viết bằng JSON hoặc YAML, rồi CloudFormation tự đứng ra tạo và cấu hình chúng theo đúng thứ tự phụ thuộc.

Vì hạ tầng đã nằm gọn trong một tệp văn bản, việc dựng lại nó ở một Region khác chỉ là chạy cùng template đó ở Region mới — không phải bấm tay lại từng bước trong Console:

• Nhanh — một template, một thao tác, thay vì tạo thủ công hàng chục tài nguyên.
• Tự động — CloudFormation lo việc tạo tài nguyên và xử lý thứ tự phụ thuộc giữa chúng.
• Đáng tin cậy — cùng một template cho ra cùng một kết quả, loại bỏ sai lệch do thao tác tay ở Region này khác Region kia.

Đúng như phần giải thích gốc: "With AWS CloudFormation you can easily provision resources in a different Region easily."

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

A. Launch một EC2 AMI chứa source code kèm deployment hooks để khởi chạy các dịch vụ AWS khác

Đây là phương án gần đúng nhất và cũng là cái bẫy chính, vì nó nghe như "đóng gói sẵn rồi bung ra". Nhưng nó hỏng ở đúng chỗ đề hỏi: AMI mang tính Region-specific — một AMI thuộc về Region nơi nó được tạo, muốn dùng ở Region khác phải sao chép nó sang trước. Bản thân AMI không tự có khả năng đa Region. Ngoài ra AMI là ảnh đĩa của một máy chủ, còn thứ đề cần là cả một tập hạ tầng.

B. Dùng AWS CodeStar để dựng continuous delivery toolchain cho việc deploy tự động

AWS CodeStar là dịch vụ phát triển trên nền cloud, gom sẵn công cụ để develop, build và deploy ứng dụng trên AWS. Nó xoay quanh vòng đời mã ứng dụng — nhanh và tự động thật, nhưng đối tượng nó phục vụ là application, không phải infrastructure trải trên nhiều Region. Lệch đúng ở từ khoá "infrastructure" trong đề.

C. Dùng AWS Systems Manager để tự động hoá các tác vụ quản trị như tạo AMI và vá lỗi

Systems Manager đúng là làm được những việc như phương án mô tả: tự động hoá tác vụ quản trị, tạo AMI, áp bản vá. Vấn đề là nó thuộc nhóm vận hành/quản trị các tài nguyên đã tồn tại, chứ không phải công cụ provision hạ tầng mới ra nhiều Region. Đề không hỏi chuyện chăm sóc máy đang chạy, nên phương án này trả lời sai câu hỏi.

📌 Điểm cần nhớ

• Thấy cụm "Infrastructure as Code", "template", "JSON/YAML", hoặc "dựng lại cùng một hạ tầng ở Region/tài khoản khác" → nghĩ tới CloudFormation trước tiên.
• Phân biệt provision hạ tầng (CloudFormation) với deploy mã ứng dụng (CodeStar và các dịch vụ Code*) và với vận hành tài nguyên đang chạy (Systems Manager). Cả ba đều "tự động", nhưng tự động hoá ba việc khác nhau.
• AMI gắn với một Region cụ thể. Bất kỳ phương án nào dựa vào AMI để giải bài toán đa Region đều phải giải thích thêm bước sao chép AMI — không có bước đó thì phương án tự nó không đứng vững.
• Với đề dạng "chọn dịch vụ", hãy bám vào danh từ chỉ đối tượng được xử lý trong câu hỏi (ở đây là infrastructure). Các trạng từ như quickly, automatically, reliably thường đúng với nhiều phương án nên hiếm khi phân biệt được.

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

Đề bài mô tả một công ty cần tiết kiệm chi phí đáng kể cho các workload chạy trên EC2. Câu hỏi yêu cầu chọn pricing model phù hợp — tức là cách trả tiền cho EC2 instance, chứ không phải chọn loại instance hay kiến trúc.

Cụm từ quyết định đáp án là "non-interruptible workloads" — workload không được phép bị gián đoạn. Trong bốn pricing model của EC2, đây chính là ràng buộc loại thẳng Spot Instances ra khỏi cuộc chơi, vì Spot là mô hình duy nhất mà AWS có quyền thu hồi capacity đang chạy.

Cụm từ thứ hai là "significant cost savings" — cần mức giảm giá đáng kể, chứ không phải giảm nhẹ. Kết hợp hai ràng buộc: cần rẻ hơn nhiều so với mặc định, nhưng phải chạy liên tục không bị ngắt. Đó là hai gọng kìm khiến chỉ còn đúng một phương án đứng vững.

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

C — Reserved Instances là đáp án đúng.

Reserved Instances cho phép khách hàng dùng EC2 instance với giá chiết khấu đổi lấy một cam kết sử dụng trong khoảng thời gian định trước. Về bản chất, khách hàng nói với AWS: "tôi chắc chắn sẽ chạy lượng compute này trong suốt kỳ hạn", và AWS đổi lại bằng mức giá thấp hơn đáng kể so với On-Demand.

Điểm mấu chốt: Reserved Instances không thay đổi gì về mặt kỹ thuật so với On-Demand. Instance vẫn chạy y hệt, AWS không có quyền thu hồi nó, không có thông báo ngắt máy. Reserved Instance thuần tuý là một thoả thuận về billing. Vì vậy nó thoả mãn cả hai yêu cầu của đề: vừa cho mức tiết kiệm đáng kể, vừa hoàn toàn phù hợp với workload không được phép gián đoạn.

Đây đúng là kịch bản mẫu mà Reserved Instances sinh ra để phục vụ: workload ổn định, chạy dài hạn, biết trước nhu cầu, và không chịu được việc bị ngắt.

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

A — On-Demand Instances. Đây là mô hình tính tiền mặc định của EC2: trả theo thời gian sử dụng, không cam kết gì, bật tắt tuỳ ý. Về mặt "non-interruptible" thì On-Demand hoàn toàn đạt — AWS không thu hồi instance On-Demand. Nhưng nó hỏng ở vế còn lại của đề: On-Demand là mức giá đắt nhất trong các pricing model, chính là mức chuẩn để các mô hình khác chiết khấu xuống từ đó. Đề yêu cầu "significant cost savings", mà giữ nguyên On-Demand thì không tiết kiệm được gì cả. Đây là phương án chỉ đúng một nửa.

B — Spot Instances. Đây là phương án bẫy nặng nhất, vì nếu chỉ đọc mỗi cụm "significant cost savings" thì Spot trông rất hấp dẫn — Spot cho mức chiết khấu sâu nhất trong các pricing model. Nhưng cơ chế của Spot là tận dụng capacity EC2 đang nhàn rỗi trong cloud của AWS. Khi AWS cần capacity đó trả lại cho khách hàng On-Demand, instance Spot của bạn sẽ bị thu hồi, chỉ được báo trước khoảng hai phút. Nói cách khác, Spot theo định nghĩa là interruptible — nó va thẳng vào ràng buộc "non-interruptible" của đề. Spot chỉ hợp với batch processing, CI/CD, xử lý dữ liệu có thể chạy lại; không hợp với workload không được ngắt.

D — Dedicated Hosts. Đây là tuỳ chọn dành cho trường hợp cần máy chủ vật lý riêng, điển hình là khi phải tuân thủ các license phần mềm gắn với server (server-bound licenses) hoặc yêu cầu compliance đòi hỏi hardware không dùng chung. Đề bài không hề nhắc tới license, compliance hay yêu cầu cách ly phần cứng — nên nhu cầu này không tồn tại trong tình huống. Tệ hơn, Dedicated Hosts là một trong những cách chạy EC2 tốn kém, đi ngược hẳn với mục tiêu tiết kiệm chi phí mà đề đặt ra. Chọn D là vừa thừa tính năng vừa sai hướng chi phí.

📌 Điểm cần nhớ

• Khi đề nói "non-interruptible", "cannot be interrupted" hoặc "critical/steady-state workload" → loại Spot Instances ngay lập tức, dù đề có nhấn mạnh tiết kiệm chi phí đến mấy.
• Khi đề nói "cost savings" cho workload chạy ổn định, dự đoán được và không bị ngắt → hướng tới Reserved Instances (cam kết sử dụng đổi lấy chiết khấu).
• On-Demand là mốc giá chuẩn để so sánh. Bất cứ câu nào yêu cầu tiết kiệm chi phí thì On-Demand gần như chắc chắn sai — nó là thứ ta đang cố tránh.
• Dedicated Hosts giải quyết vấn đề license/compliance, không giải quyết vấn đề chi phí. Chỉ chọn khi đề nhắc rõ tới server-bound license hoặc yêu cầu hardware riêng.
• Kỹ thuật làm bài chung: câu hỏi pricing model thường có hai ràng buộc (chi phí + đặc tính workload). Đọc sót một ràng buộc là rơi vào bẫy Spot hoặc On-Demand.

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

Đề hỏi: khách hàng dùng gói AWS Business Support được truy cập vào thứ nào trong bốn lựa chọn?

Cụm từ quyết định nằm ngay ở tên gói: "Business Support". Cả bốn phương án đều là những thứ có thật trong hệ sinh thái hỗ trợ của AWS, nên câu này không kiểm tra bạn có biết chúng là gì, mà kiểm tra bạn có nhớ thứ nào nằm ở tầng Business, thứ nào chỉ mở từ tầng Enterprise trở lên, và thứ nào hoàn toàn không thuộc gói support. Đọc lướt qua chữ "Business" rồi chọn theo cảm giác "cái nào nghe cao cấp nhất" là cách hỏng phổ biến nhất ở dạng câu này.

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

Đáp án đúng là B — AWS Health API.

AWS Health cung cấp thông tin về các sự kiện có thể ảnh hưởng tới dịch vụ và tài nguyên AWS của chính tài khoản bạn (sự cố, bảo trì theo lịch, thay đổi cần hành động). Phần giao diện Personal Health Dashboard thì ai cũng xem được, nhưng truy cập bằng API — tức là gọi chương trình để tự động lấy sự kiện và nối vào hệ thống giám sát của mình — được mở từ mức Business Support trở lên (Business, Enterprise On-Ramp, Enterprise).

Vì đề chỉ hỏi "Business Support customers có quyền truy cập cái nào", và AWS Health API là mục duy nhất trong danh sách mà tầng Business đã với tới được, B là đáp án đúng.

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

A — AWS Support concierge. Đây là đội hỗ trợ chuyên trách các vấn đề về tài khoản và thanh toán (billing/account), nhưng chỉ dành cho khách hàng Enterprise Support. Khách hàng Business không có. Đây là phương án gây nhầm nhất cùng với D, vì nó thực sự là một quyền lợi đi kèm gói support — chỉ sai ở chỗ sai tầng gói, không sai về bản chất.

C — AWS DDoS Response Team (DRT). Sai ở một điểm khác hẳn: DRT không phải là quyền lợi của bất kỳ gói support nào. Muốn làm việc với DRT thì phải đăng ký dịch vụ AWS Shield Advanced, tức là mua một dịch vụ bảo mật riêng chứ không phải nâng cấp support plan. Dù bạn có ở Enterprise Support mà không có Shield Advanced thì cũng không gọi được DRT. Nhầm lẫn ở đây là gộp "hỗ trợ kỹ thuật" với "dịch vụ chống DDoS" làm một.

D — AWS technical account manager (TAM). TAM là người phụ trách kỹ thuật riêng cho tài khoản của bạn, tư vấn kiến trúc và tối ưu chi phí. Quyền lợi này bắt đầu từ Enterprise On-Ramp (dùng chung một nhóm TAM) và đầy đủ ở Enterprise Support (một TAM chỉ định riêng). Gói Business không có TAM. Phương án này gần đúng theo nghĩa "đúng là quyền lợi của support plan", nhưng hỏng vì nó nằm cao hơn tầng Business ít nhất một bậc.

📌 Điểm cần nhớ

• Với dạng câu "gói support X có gì", hãy phân loại lựa chọn theo ba nhóm trước khi chọn: (1) đúng tầng gói đang hỏi, (2) thuộc gói cao hơn, (3) không thuộc gói support nào cả. Phương án loại (3) — như DRT — thường bị loại nhanh nhất.
• AWS Health API (truy cập theo chương trình) gắn với mức Business trở lên; đừng lẫn nó với việc xem dashboard AWS Health, vốn không đòi gói trả phí.
• TAM và Concierge là dấu hiệu của tầng Enterprise (TAM có thêm dạng dùng chung ở Enterprise On-Ramp). Thấy hai tên này trong đề hỏi về Business/Developer thì gần như chắc chắn là bẫy.
• DRT chỉ đi cùng AWS Shield Advanced, là một dịch vụ mua riêng chứ không phải nấc thang support. Đây là điểm phân biệt "mua dịch vụ" với "nâng gói hỗ trợ".

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

Đề mô tả một tổ chức có hạ tầng on-premises và đang truy cập AWS Cloud qua Internet. Câu hỏi: làm sao tạo được kết nối hybrid cloud riêng tư mà tránh đi qua Internet?

Cụm từ quyết định đáp án là "private... connection that avoids the internet" — tức là đường truyền vật lý phải không đi qua Internet công cộng, chứ không phải chỉ "được mã hoá". Đây chính là chỗ tách bạch các phương án gần giống nhau: cả ba phương án còn lại đều liên quan tới kết nối lai, nhưng chúng hoặc chạy trên nền Internet, hoặc giải quyết một bài toán khác hẳn.

Cụm thứ hai cần chú ý là "on-premises" — điểm đầu của kết nối nằm ngoài AWS. Ràng buộc này loại thẳng những phương án chỉ hoạt động bên trong một VPC.

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

A — AWS Direct Connect. Direct Connect là đường kết nối mạng chuyên dụng, riêng tư, nối trung tâm dữ liệu on-premises của khách hàng tới AWS thông qua một Direct Connect location, không đi qua Internet công cộng. Vì lưu lượng chạy trên hạ tầng riêng nên nó cho độ trễ ổn định hơn và băng thông cao hơn so với đường đi qua Internet — đúng như mô tả trong phần giải thích gốc: "a low-latency, high-bandwidth, private connection to AWS".

Đề hỏi đúng một thứ: hybrid cloud connection mang tính private, tránh Internet. Trong danh sách bốn phương án, chỉ Direct Connect thoả mãn cả hai vế cùng lúc.

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

B — AWS VPN CloudHub. Đây là mô hình dùng Virtual Private Gateway làm trung tâm để nhiều site chi nhánh nối vào và nói chuyện được với nhau (mô hình hub-and-spoke). Nó đúng là kết nối hybrid, và đây là phương án dễ nhầm nhất khi người học chỉ nhớ "VPN = an toàn". Nhưng bản chất mỗi nhánh vẫn là một VPN tunnel chạy trên Internet: lưu lượng được mã hoá chứ đường đi không hề riêng tư. Đề yêu cầu avoids the internet, nên nó hỏng ở đúng chữ "avoids".

C — AWS VPC Endpoint. Đây là PrivateLink: cho phép tài nguyên bên trong một VPC truy cập một dịch vụ AWS mà không cần đi ra Internet gateway. Vấn đề không nằm ở chuyện "riêng tư" — chỗ này nó riêng tư thật — mà ở điểm đầu của kết nối. VPC Endpoint không nối môi trường on-premises vào AWS; nó giải một bài toán khác. Đây là kiểu bẫy hay gặp: phương án đúng về tính chất nhưng sai về phạm vi áp dụng.

D — AWS Managed VPN. Là VPN site-to-site do AWS quản lý, nối on-premises tới VPC. Về mặt kiến trúc thì đúng là kết nối hybrid, và nó cũng "an toàn". Nhưng giống CloudHub, tunnel được thiết lập qua Internet: dữ liệu được mã hoá trong đường hầm IPsec, còn gói tin vẫn đi trên hạ tầng Internet công cộng, kèm theo độ trễ và băng thông phụ thuộc vào chất lượng Internet lúc đó. Nếu đề hỏi "kết nối an toàn, chi phí thấp, dựng nhanh" thì D sẽ là đáp án; nhưng đề hỏi "tránh Internet" nên D trượt.

📌 Điểm cần nhớ

• "Encrypted" khác "private". VPN (Managed VPN, VPN CloudHub) mã hoá dữ liệu trên Internet; Direct Connect thì không dùng Internet ngay từ đầu. Gặp từ khoá avoid/bypass the public internet, dedicated, consistent latency → nghiêng về Direct Connect.
• Gặp từ khoá quick to set up, low cost, encrypted tunnel → nghiêng về Site-to-Site / Managed VPN, vì Direct Connect cần thời gian và hạ tầng vật lý.
• VPN CloudHub được nhận diện bằng bối cảnh "nhiều chi nhánh cần nói chuyện với nhau", không phải bằng chữ "private".
• VPC Endpoint / PrivateLink là chuyện bên trong VPC — truy cập dịch vụ AWS mà không ra Internet gateway. Nó không phải công cụ nối on-premises vào AWS, nên hễ đề bắt đầu bằng "on-premises" thì loại ngay.

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

Đề hỏi: dịch vụ AWS nào được cung cấp ở phạm vi global (toàn cầu) thay vì regional (theo Region)? Chọn HAI phương án.

Cụm từ quyết định là "delivered globally rather than regionally". Đây không phải câu hỏi về việc dịch vụ có phục vụ người dùng khắp thế giới hay không — hầu như dịch vụ nào của AWS cũng làm được điều đó. Nó hỏi về phạm vi (scope) của chính tài nguyên: khi bạn tạo tài nguyên đó, bạn có phải chọn một Region (và thường là cả Availability Zone) hay không.

Cách phân loại cần nhớ trong AWS Global Infrastructure:

• Zonal: tài nguyên nằm trong một Availability Zone cụ thể.
• Regional: tài nguyên trải trên nhiều AZ nhưng vẫn thuộc đúng một Region.
• Global: tài nguyên không gắn với Region nào, cấu hình một lần dùng chung cho cả tài khoản.

Ai đọc lướt rất dễ chọn nhầm vì "toàn cầu" nghe giống "dùng được ở mọi nơi". Đọc đúng phải là "không phải khai báo Region khi tạo".

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

C. Amazon Route 53 — dịch vụ DNS của AWS. DNS về bản chất là hệ thống phân giải tên miền toàn cầu: một hosted zone không thuộc về Region nào, và các name server phục vụ truy vấn từ mạng lưới edge phân tán khắp thế giới. Trong console, Route 53 không có ô chọn Region.

E. Amazon CloudFront — dịch vụ CDN, phân phối nội dung tĩnh và động qua mạng lưới edge location toàn cầu. Một CloudFront distribution cũng là tài nguyên global: bạn tạo nó một lần, nó tự phục vụ từ edge gần người dùng nhất, không bị buộc vào một Region. (Origin phía sau có thể là tài nguyên regional, nhưng bản thân distribution thì không.)

Cả hai đều thuộc nhóm dịch vụ "edge" của AWS — đây chính là dấu hiệu nhận biết nhanh.

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

A. Amazon EC2 — instance được khởi chạy trong một Availability Zone cụ thể, tức là còn hẹp hơn cả regional. Bạn phải chọn Region rồi chọn subnet nằm trong một AZ. Muốn phục vụ toàn cầu thì phải tự nhân bản hạ tầng sang nhiều Region, chứ dịch vụ không tự làm điều đó.

B. Amazon VPC — đây là phương án gần đúng nhất và hay bẫy người học, vì VPC trải rộng trên tất cả các AZ trong Region. Nghe "trải rộng" dễ tưởng là global. Nhưng nó dừng đúng ở ranh giới Region: một VPC không bao giờ vươn sang Region khác. VPC là ví dụ kinh điển của tài nguyên regional, không phải global.

D. Amazon RDS — giống EC2, DB instance được đặt trong một AZ thuộc một Region bạn chọn. Ngay cả cấu hình Multi-AZ cũng chỉ là nhân bản sang AZ khác trong cùng Region, nên nó nâng phạm vi từ zonal lên regional chứ vẫn không thành global.

📌 Điểm cần nhớ

• "Global" trong đề thi AWS nghĩa là tài nguyên không gắn với Region nào, không phải "người dùng khắp thế giới truy cập được".
• Nhóm dịch vụ edge — CloudFront và Route 53 — là câu trả lời quen thuộc cho dạng câu hỏi về dịch vụ global.
• EC2 và RDS là zonal (chọn AZ); VPC là regional (trải hết AZ nhưng không vượt Region). Phân biệt ba mức zonal / regional / global là chìa khoá cho cả nhóm câu hỏi AWS Global Infrastructure.
• Mẹo kiểm tra nhanh: nếu console bắt bạn chọn Region trước khi tạo tài nguyên thì đó không phải dịch vụ global.

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

Đề hỏi: tính năng nào của AWS IAM giúp bạn phát hiện những quyền không cần thiết đã được gán cho user.

Cụm từ quyết định là "identify unnecessary permissions that have been assigned" — tức là tìm ra quyền đã cấp nhưng thực tế không hề được dùng đến. Muốn biết một quyền có thừa hay không, hệ thống phải trả lời được câu hỏi: "user (hoặc role, group, policy) này lần cuối truy cập service đó là khi nào? Có bao giờ truy cập chưa?" Dữ liệu đó trong IAM gọi là service last accessed data.

Chú ý thêm hai chi tiết: đề nói rõ feature of AWS IAM (một tab/tính năng có thật bên trong IAM console, không phải một dịch vụ riêng), và mục tiêu ngầm là tinh chỉnh policy theo nguyên tắc least privilege — cấp đúng mức quyền tối thiểu đủ để làm việc.

Cả bốn phương án đều được đặt tên theo khuôn "<Danh từ> Advisor", nên đây là dạng câu kiểm tra bạn có nhớ đúng tên tính năng hay không, chứ không phải suy luận kiến trúc. Ba cái tên còn lại nghe rất hợp lý nhưng đơn giản là không tồn tại.

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

D. Access Advisor là đáp án đúng.

IAM console ghi lại thông tin về việc IAM user và role lần gần nhất đã thử truy cập các AWS service — đây chính là service last accessed data. Bạn xem dữ liệu này ở tab Access Advisor, có mặt trong trang chi tiết của IAM user, group, role, hoặc managed policy.

Cách dùng thực tế rất trực tiếp: mở tab đó ra, nhìn danh sách service mà một policy đang cho phép, rồi đối chiếu cột thời điểm truy cập gần nhất. Service nào được cấp quyền mà chưa từng được truy cập, hoặc rất lâu rồi không được chạm tới, chính là ứng viên để cắt khỏi policy. Nhờ vậy bạn siết dần permission về đúng mức tối thiểu cần thiết mà không phải đoán mò xem cắt cái gì thì hỏng việc.

Đó đúng là hành động mà đề mô tả: identify unnecessary permissions.

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

A. Group Advisor — Không phải một tính năng của IAM. Cái tên nghe có lý vì IAM thật sự có khái niệm group (nhóm user dùng chung policy), và bạn có thể xem dữ liệu last accessed cho một group. Nhưng chỗ để xem vẫn là tab Access Advisor trong trang chi tiết của group đó, chứ không có thứ nào tên là "Group Advisor". Đây là bẫy ghép một danh từ có thật trong IAM với hậu tố "Advisor".

B. Permissions Advisor — Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì nó mô tả chức năng chính xác hơn cả tên thật: thứ bạn đang xét đúng là permission. Nhưng câu hỏi hỏi tên tính năng, không hỏi mô tả chức năng, và AWS đặt tên là Access Advisor — lấy theo dữ liệu nền tảng của nó (access data: ai đã truy cập gì, lúc nào). "Permissions Advisor" không tồn tại trong IAM console. Nếu bạn chọn B vì thấy nó "mô tả đúng việc đang làm", thì đó chính là kiểu sai mà câu này muốn bắt.

C. Role Advisor — Cũng không tồn tại. Tương tự bẫy ở phương án A: IAM role là khái niệm có thật và role cũng có dữ liệu last accessed, thậm chí đây là đối tượng người ta hay soi nhất khi dọn quyền thừa. Nhưng nơi xem vẫn là tab Access Advisor mở từ trang chi tiết của role. Ngoài ra, tên "Role Advisor" còn hàm ý tính năng chỉ áp dụng cho role — trong khi Access Advisor phủ cả user, group, role và managed policy.

📌 Điểm cần nhớ

• Access Advisor = service last accessed data. Nghe thấy "quyền thừa", "quyền chưa từng dùng", "siết policy theo least privilege" trong đề IAM thì nghĩ ngay tới tính năng này.
• Access Advisor xem được cho cả bốn loại: IAM user, group, role và managed policy — đừng để một phương án gắn với riêng một loại (Role/Group) đánh lừa.
• Least privilege là nguyên tắc: chỉ cấp đúng quyền tối thiểu để hoàn thành một tác vụ cụ thể. Access Advisor là công cụ IAM giúp bạn tiến dần về nguyên tắc đó bằng bằng chứng sử dụng thật, thay vì phỏng đoán.
• Với dạng câu chỉ khác nhau ở một từ trong tên riêng (X Advisor), hãy nhớ tên chính xác chứ đừng chọn phương án "mô tả chức năng nghe hợp lý nhất" — AWS thường đặt tên theo loại dữ liệu mà tính năng hiển thị (ở đây là access), không theo kết quả mà nó giúp bạn đạt được.

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

Đề hỏi: trong các hoạt động liên quan tới bảo mật dưới đây, hoạt động nào thuộc trách nhiệm của khách hàng AWS (chọn HAI).

Cụm từ quyết định là "AWS customers responsible for". Đây là câu kiểm tra thẳng vào AWS Shared Responsibility Model — mô hình chia đôi trách nhiệm:

• AWS chịu trách nhiệm về "security OF the cloud": phần hạ tầng vật lý — data center, phần cứng, thiết bị mạng, tầng ảo hoá, và việc thanh lý ổ đĩa hỏng.
• Khách hàng chịu trách nhiệm về "security IN the cloud": những gì khách hàng tự cấu hình và tự vận hành bên trên hạ tầng đó — IAM, guest OS, dữ liệu, mã hoá, security group.

Ranh giới cần tìm trong từng phương án là: thứ này nằm trong tay khách hàng cấu hình được, hay nằm sau cánh cửa data center mà khách hàng không bao giờ chạm tới? Ba phương án sai đều mô tả những việc chỉ nhân viên AWS mới làm được.

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

B — Implementing IAM password policies. IAM là dịch vụ khách hàng tự quản trị. Chính khách hàng đặt password policy cho account của mình: độ dài tối thiểu, yêu cầu ký tự, thời hạn đổi mật khẩu, cấm dùng lại mật khẩu cũ. AWS cung cấp khả năng cấu hình, còn quyết định cấu hình thế nào là của khách hàng — đó chính là định nghĩa "security in the cloud".

C — Installing patches on Windows operating systems. Với EC2, khách hàng toàn quyền và toàn trách nhiệm với guest OS: vá lỗi hệ điều hành, cập nhật phần mềm chạy trên đó, cấu hình firewall của OS. AWS chỉ vá tầng hypervisor và phần cứng bên dưới. Máy Windows chạy trên EC2 không được vá thì đó là lỗ hổng 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 — Implementing data center access controls. Đây là trách nhiệm của AWS. Khách hàng không biết data center của AWS nằm ở đâu, không được vào, và không có bất kỳ cách nào để cấu hình kiểm soát ra vào ở đó. Việc này thuộc "security of the cloud"; khách hàng chỉ có thể xác minh nó qua các báo cáo kiểm toán mà AWS công bố, chứ không thực hiện nó.

D — Installing patches on network devices. Đây là phương án dễ nhầm nhất, vì nó cũng nói tới "patch" giống phương án C. Điểm khác biệt nằm ở thiết bị được vá: C nói về hệ điều hành khách (guest OS) chạy trên instance của khách hàng, còn D nói về thiết bị mạng vật lý — router, switch trong hạ tầng AWS. Khách hàng không có quyền truy cập vào phần cứng mạng đó. Hãy nhớ: "patch" không tự động nghĩa là việc của khách hàng; phải xem vá cái gì.

E — Secure disposal of faulty disk drives. Việc huỷ ổ đĩa hỏng một cách an toàn diễn ra bên trong data center, trên phần cứng vật lý do AWS sở hữu. Khách hàng chưa bao giờ nhìn thấy ổ đĩa đó. Đây thuần tuý là trách nhiệm của AWS.

📌 Điểm cần nhớ

• Câu hỏi Shared Responsibility Model gần như luôn giải được bằng một câu hỏi duy nhất: khách hàng có console/API/quyền truy cập để tự làm việc này không? Có thì là của khách hàng, không thì là của AWS.
• Bất cứ thứ gì vật lý đều thuộc AWS: data center, phần cứng, thiết bị mạng, ổ đĩa, điện, làm mát, thanh lý thiết bị.
• Guest OS luôn thuộc khách hàng với EC2 — vá lỗi, cấu hình, phần mềm cài thêm. Đừng lẫn với hypervisor và phần cứng bên dưới, vốn là của AWS.
• Cẩn thận với các phương án dùng cùng một động từ nhưng khác đối tượng (patch OS ≠ patch network device). Đề hay đặt cặp này cạnh nhau để phân loại người hiểu thật với người học thuộc từ khoá.

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

Đề hỏi: "Which of the following is a benefit of moving to the AWS Cloud?" — đâu là lợi ích khi chuyển sang AWS Cloud.

Cụm từ quyết định đáp án là "benefit of moving to the AWS Cloud". Đây là dạng câu hỏi khái niệm nền tảng của AWS Certified Cloud Practitioner: nó không hỏi bạn có thể làm gì trên AWS, mà hỏi điều gì là ưu thế của mô hình cloud so với mô hình on-premises truyền thống.

Ràng buộc phân biệt nằm ở chỗ này: ba trong bốn phương án mô tả đặc điểm của mô hình on-premises (mua sắm thiết bị, cam kết dài hạn) hoặc một hiểu lầm phổ biến về cloud (khoán trọn IT cho nhà cung cấp). Chỉ một phương án mô tả đúng cái mà cloud thay đổi về căn bản: cách trả tiền.

Với dạng câu này, mẹo đọc đề là tự hỏi: "Nếu tôi vẫn ở trung tâm dữ liệu của mình thì điều này có đúng không?" Nếu câu trả lời là "có" hoặc "còn đúng hơn", thì đó không phải lợi ích của cloud.

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

Đáp án đúng theo tệp là B — "Pay for what you use" (trả tiền theo mức dùng thực tế).

Đây chính là điểm khác biệt cốt lõi giữa cloud và hạ tầng tự vận hành. Với on-premises, bạn phải mua trước thiết bị đủ để gánh đỉnh tải (peak capacity) — nghĩa là mua dư so với nhu cầu thường ngày, và trả tiền trọn gói ngay từ đầu, rồi phần công suất thừa nằm không trong phần lớn thời gian.

Với AWS, bạn chỉ trả cho tài nguyên thực sự tiêu thụ: chạy EC2 instance bao lâu trả bấy nhiêu, lưu bao nhiêu dữ liệu trên S3 trả bấy nhiêu, tắt đi thì ngừng phát sinh chi phí cho phần tính toán đó. Hệ quả kéo theo là chi phí chuyển từ capital expenditure (đầu tư tài sản) sang operational expenditure (chi phí vận hành) — điều mà giải thích gốc nhấn mạnh là được nhiều CFO ưa chuộng.

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

A — "Capital purchases" (mua sắm tài sản cố định) Đây là đặc trưng của mô hình on-premises, chính là thứ cloud giúp bạn tránh, chứ không phải lợi ích cloud mang lại. Bạn phải bỏ vốn mua máy chủ, thiết bị mạng, tủ rack trước khi có dòng doanh thu nào. Chuyển sang AWS là đi theo hướng ngược lại: giảm capital expenditure, chuyển sang chi phí vận hành theo mức dùng. Phương án này bị đảo chiều so với thực tế.

C — "Long term commitments" (cam kết dài hạn) Đây là phương án gần đúng nhất và dễ gây do dự nhất, vì AWS có các hình thức cam kết 1 năm hoặc 3 năm để đổi lấy giá thấp hơn. Nhưng nó hỏng ở chỗ: cam kết dài hạn là một tuỳ chọn tối ưu chi phí, không phải lợi ích của việc chuyển lên cloud. Lợi ích thật nằm ở chiều ngược lại — bạn không bị buộc phải cam kết dài hạn, có thể dùng theo nhu cầu rồi dừng. Nếu coi "cam kết dài hạn" là ưu điểm thì on-premises (nơi bạn bị khoá vào phần cứng nhiều năm) sẽ là mô hình ưu việt nhất, điều đó vô lý.

D — "Outsource all IT operations" (khoán trọn toàn bộ vận hành IT) Sai ở chữ "all". AWS có nhiều managed service ở tầng cao giúp giảm khối lượng công việc vận hành — bạn không còn phải thay ổ cứng hỏng, không quản lý nguồn điện hay điều hoà cho trung tâm dữ liệu. Nhưng bạn vẫn phải tự lo phần của mình: cấu hình bảo mật, quản lý danh tính và phân quyền, thiết kế kiến trúc, giám sát, tối ưu chi phí, vá lỗi ứng dụng. Cloud giảm gánh nặng vận hành chứ không xoá bỏ nó. Phương án này đúng một nửa nhưng bị từ định lượng tuyệt đối làm cho sai.

📌 Điểm cần nhớ

• "Pay for what you use" là lợi ích kinh điển nhất của cloud trong đề Cloud Practitioner: không mua dư cho đỉnh tải, không trả trước, dùng bao nhiêu trả bấy nhiêu.
• Cloud dịch chuyển chi phí từ capital expenditure sang operational expenditure — thấy phương án nói về "mua sắm tài sản", "đầu tư trước" thì gần như chắc chắn đó là mô tả on-premises.
• Cảnh giác với từ định lượng tuyệt đối như all, every, eliminate, no need to. Trong đề AWS, một mệnh đề đúng một nửa thường bị chính chữ "all" làm cho sai — đây là kiểu bẫy lặp lại rất nhiều lần.
• Cam kết 1 hoặc 3 năm là công cụ giảm giá tuỳ chọn, không phải bản chất hay lợi ích của cloud; lợi ích là tính linh hoạt, không bị ràng buộc.
• Mẹo loại trừ chung: với câu "lợi ích của cloud", hãy thử áp phương án lên mô hình on-premises. Nếu nó vẫn đúng hoặc đúng hơn, phương án đó bị loại.