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

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

Đề hỏi: "Which services allow you to store files on AWS? (Select TWO.)" — dịch vụ nào cho phép lưu trữ file trên AWS, chọn hai phương án.

Cụm từ quyết định là "store files" kết hợp với "(Select TWO)". Đây là câu phân loại dịch vụ theo nhóm chức năng: danh sách phương án trộn lẫn compute (Lambda, Lightsail), messaging (SQS) và storage (EFS, EBS). Ràng buộc phân biệt không nằm ở chi tiết kỹ thuật sâu, mà ở chỗ bạn có nhận ra dịch vụ nào thuộc nhóm storage hay không. Chữ "files" cũng là một cái bẫy nhẹ: SQS có giữ dữ liệu, nhưng giữ tạm message trong hàng đợi chứ không phải nơi bạn đặt file và đọc lại như một volume.

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

Theo tệp, đáp án đúng là D (Amazon EFS) và E (Amazon EBS) — đúng hai phương án, khớp với "Select TWO".

• Amazon EBS (Elastic Block Store): cung cấp volume dạng block device gắn vào EC2 instance. Sau khi gắn và định dạng file system, instance ghi/đọc file trên đó y như một ổ đĩa. Đây là storage bền vững, tồn tại độc lập với vòng đời của instance.
• Amazon EFS (Elastic File System): là file system đúng nghĩa, mount vào instance qua giao thức NFS. Điểm khác biệt so với EBS: nhiều instance có thể mount cùng một file system và thấy chung dữ liệu, trong khi một EBS volume thông thường phục vụ một instance.

Cả hai đều là dịch vụ lưu trữ trong nhóm AWS Storage, nên cả hai đều thoả "store files".

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

• A. AWS Lambda — dịch vụ compute, chạy code dạng function theo sự kiện. Nó cho bạn không gian tạm trong môi trường thực thi để xử lý dữ liệu trong lúc chạy, nhưng đó không phải mục đích của dịch vụ và không tồn tại lâu dài: hết vòng đời môi trường là mất. Lambda là nơi xử lý file, không phải nơi lưu file.
• B. Amazon Lightsail — cũng là compute, gói dịch vụ đơn giản hoá để chạy instance (kèm cấu hình mạng, DNS) cho người mới. Instance nào cũng có ổ đĩa đi kèm, nên phương án này trông "gần đúng", nhưng bản chất Lightsail được phân loại là dịch vụ chạy máy chủ chứ không phải dịch vụ lưu trữ — nếu chấp nhận nó thì EC2 cũng phải đúng, và câu hỏi sẽ có quá hai đáp án.
• C. Amazon SQS (Simple Queue Service) — message bus, giữ tạm các message trao đổi giữa các thành phần ứng dụng. Đây là phương án gây nhầm nhất vì SQS thật sự có "chứa dữ liệu", nhưng hỏng ở hai chỗ: dữ liệu chỉ nằm trong hàng đợi cho tới khi consumer nhận và xoá (mang tính tạm thời, có thời hạn lưu giữ), và mô hình truy cập là gửi/nhận message theo hàng đợi chứ không phải mở/ghi file theo đường dẫn. Bạn không thể mount SQS như một ổ đĩa.

📌 Điểm cần nhớ

• Khi đề hỏi "dịch vụ nào lưu trữ", bước đầu tiên là phân loại từng phương án theo nhóm dịch vụ (compute / storage / messaging / database). Đa số câu kiểu này giải xong ngay ở bước phân loại.
• EBS = block storage gắn vào một instance như ổ đĩa; EFS = file storage mount qua NFS, nhiều instance dùng chung. Nhớ cặp đối lập này là trả lời được rất nhiều câu AWS Storage.
• Lambda và Lightsail đều là compute. Việc một dịch vụ compute có ổ đĩa đi kèm không biến nó thành dịch vụ lưu trữ.
• SQS lưu tạm message, không lưu file. Gặp SQS trong danh sách phương án của câu hỏi về storage thì gần như chắc chắn nó là mồi nhử.
• Luôn đếm số đáp án đề yêu cầu: "(Select TWO)" là một ràng buộc — nếu bạn thấy ba phương án cùng hợp lý thì cách hiểu của bạn đang quá rộng, phải siết lại tiêu chí.

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

Đề hỏi: "Which of the below is an example of optimizing for cost?" — đâu là ví dụ của việc tối ưu chi phí.

Cụm từ quyết định đáp án là "optimizing for cost". Đây là câu phân loại mục tiêu tối ưu: AWS Well-Architected có nhiều trụ cột khác nhau (chi phí, hiệu năng, vận hành, độ tin cậy), và cả bốn phương án đều là những việc tốt theo một tiêu chí nào đó. Bẫy nằm ở chỗ ba phương án sai đều mô tả những thực hành hợp lý, nhưng chúng phục vụ hiệu năng, khả năng chịu tải, hoặc vận hành — không phải chi phí. Người học phải hỏi lại từng phương án đúng một câu: "việc này có làm giảm số tiền phải trả không?"

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

D — Replace an EC2 compute instance with AWS Lambda.

Với EC2, bạn trả tiền cho thời gian instance chạy, bất kể nó có đang xử lý việc gì hay đang ngồi không. Bạn cũng phải tự quyết định dung lượng: chọn instance type, chọn số lượng, và quyết định đó gần như luôn dư ra một khoảng an toàn.

AWS Lambda là dịch vụ serverless: bạn không phải ra quyết định về capacity, và chỉ trả tiền cho thời gian xử lý thực tế của các lần gọi hàm. Với những workload chạy theo sự kiện, chạy ngắt quãng hoặc có lúc rảnh rỗi, chuyển từ một instance chạy suốt sang mô hình trả theo lần dùng cắt bỏ đúng phần chi phí "chờ không làm gì" — đó chính là định nghĩa của tối ưu chi phí.

Giải thích nguồn còn nói rộng ra: nên thay workload EC2 bằng các managed service không đòi bạn quyết định capacity khi có thể. Cùng nhóm đó còn có ELB, CloudFront, SQS, Kinesis Firehose, SES và CloudSearch.

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

B — Choosing the fastest EC2 instance to ensure performance. Đây là phương án gần đúng nhất về mặt "nghe có vẻ chuyên nghiệp", nhưng nó tối ưu sai trục: mục tiêu ghi rõ trong chính câu chữ là ensure performance, không phải chi phí. Instance nhanh nhất cũng là instance đắt nhất. Việc đúng cho mục tiêu chi phí là right-sizing — chọn instance rẻ nhất còn đáp ứng được yêu cầu của workload, chứ không phải chọn cái mạnh nhất rồi hy vọng tiết kiệm.

C — Provision extra capacity to allow for growth. Đây là thói quen của thời data center truyền thống: mua dư phần cứng vì đặt thêm máy mất hàng tuần tới hàng tháng. Trên cloud, phần dư đó là tiền trả cho tài nguyên không dùng tới, tức là làm chi phí tăng. Cloud cho phép cấu hình ứng dụng, database và hệ thống lưu trữ giãn nở theo nhu cầu, nên việc mua trước để phòng tăng trưởng vừa không cần thiết vừa đi ngược mục tiêu tối ưu chi phí. Nếu phương án này gắn với reliability thì còn bàn được, nhưng đề hỏi cost.

A — Deploy resources with AWS CloudFormation. CloudFormation rất tốt — nó giúp triển khai cấu hình ứng dụng một cách nhất quán từ template, lặp lại được, giảm sai sót thủ công. Nhưng bản thân việc dùng CloudFormation không thay đổi số tiền bạn trả cho tài nguyên: một EC2 instance dựng bằng template hay dựng bằng tay đều tính tiền như nhau. Đây là ví dụ của tối ưu vận hành (operational optimization), không phải tối ưu chi phí. Đó là lý do nó sai dù bản thân thực hành này đáng khuyến khích.

📌 Điểm cần nhớ

• Khi đề hỏi "optimizing for cost", hãy soi từng phương án bằng đúng một câu hỏi: việc này có làm hoá đơn nhỏ đi không? Nhiều phương án sai là thực hành tốt, nhưng thuộc trục performance, reliability hoặc operations.
• Chuyển workload sang dịch vụ không phải quyết định capacity (Lambda, ELB, CloudFront, SQS, Kinesis Firehose, SES, CloudSearch) là mẫu tối ưu chi phí kinh điển: trả theo mức dùng thực tế thay vì trả cho tài nguyên chạy suốt.
• Right-sizing — chọn tài nguyên vừa đủ cho workload — mới là câu trả lời về chi phí. "Chọn cái nhanh nhất" và "mua dư để phòng tăng trưởng" đều là dấu hiệu của phương án sai trong nhóm câu hỏi này.
• Infrastructure as Code (CloudFormation) thuộc về tính nhất quán và tự động hoá vận hành, không phải công cụ giảm giá tài nguyên — đừng nhầm nó sang trụ cột chi phí.

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

Đề hỏi: dịch vụ nào cho phép lập trình viên upload code dưới dạng file ZIP hoặc WAR, và dịch vụ đó tự lo toàn bộ quá trình triển khai tài nguyên (end-to-end deployment of the resources).

Có hai cụm từ quyết định đáp án, và phải đọc cả hai cùng lúc:

• "upload code using a ZIP or WAR file" — đầu vào là một gói mã nguồn đã đóng gói sẵn, không phải một repository, không phải một Docker image.
• "handle the end-to-end deployment of the resources" — dịch vụ phải tự dựng luôn hạ tầng chạy ứng dụng đó, chứ không chỉ đẩy code lên một hạ tầng đã có sẵn.

Vế thứ hai chính là ràng buộc phân biệt các phương án. Nhiều dịch vụ trong danh sách có dính tới việc đưa code lên chạy, nhưng chỉ một dịch vụ tự tạo ra resources (compute, load balancer, auto scaling) từ con số không.

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

Đáp án đúng theo tệp là C — AWS Elastic Beanstalk.

Elastic Beanstalk là dịch vụ triển khai và quản lý ứng dụng trên AWS Cloud. Lập trình viên chỉ cần nộp gói ứng dụng (source bundle) — chấp nhận trực tiếp file ZIP hoặc WAR, ngoài ra còn nhận được cả Git archive — rồi Elastic Beanstalk lo phần còn lại: cấp phát capacity, load balancing, auto scaling và theo dõi tình trạng ứng dụng (application health monitoring).

Đúng cả hai vế của đề: đầu vào là ZIP/WAR, và đầu ra là một môi trường chạy hoàn chỉnh mà người dùng không phải tự dựng. Định dạng WAR còn là một gợi ý rất trực tiếp — đó là gói ứng dụng Java web, và Elastic Beanstalk có sẵn platform để nhận nó.

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

A — Amazon ECS. Đây là dịch vụ quản lý để chạy Docker container. Đầu vào của nó là container image, không phải file ZIP hay WAR. Muốn dùng ECS, lập trình viên phải tự đóng gói ứng dụng thành image, đẩy lên registry, viết task definition rồi định nghĩa service — tức là vẫn phải tự lo phần lớn công việc mà đề đang muốn giao cho dịch vụ. Sai cả ở định dạng đầu vào lẫn ở mức độ "end-to-end".

B — AWS CodeCommit. Đây là dịch vụ quản lý mã nguồn (source control) được quản lý hoàn toàn, lưu trữ các repository Git bảo mật. Nó chỉ là nơi cất code. Nó không build code và cũng không dựng hạ tầng để chạy code đó. Đề hỏi về triển khai, không hỏi về lưu trữ mã nguồn — CodeCommit không chạm tới vế "deployment of the resources" chút nào.

D — AWS CodeDeploy. Đây là phương án gần đúng nhất và là cái dễ nhầm nhất, vì tên nó có chữ "Deploy" và nó đúng là một dịch vụ triển khai được quản lý hoàn toàn. Chỗ nó hỏng: CodeDeploy tự động hoá việc đưa phần mềm lên các compute service đã tồn tại — Amazon EC2, AWS Lambda, hay máy chủ on-premises. Nghĩa là hạ tầng phải có sẵn từ trước, do người khác dựng; CodeDeploy chỉ đẩy phiên bản mới lên đó. Đề yêu cầu dịch vụ tự lo resources, mà đúng phần resources lại là phần CodeDeploy không làm.

📌 Điểm cần nhớ

• Elastic Beanstalk = nộp code, nhận về cả môi trường. Nhận ZIP/WAR (và Git archive), tự lo capacity provisioning, load balancing, auto scaling, health monitoring. Thấy đề nhắc "ZIP or WAR" hoặc "handle everything for you" thì gần như chắc là Elastic Beanstalk.
• Phân biệt "deploy lên hạ tầng có sẵn" và "tạo luôn hạ tầng". CodeDeploy thuộc nhóm đầu (EC2, Lambda, on-premises); Elastic Beanstalk thuộc nhóm sau. Đây là ranh giới hay được dùng để ra đề.
• Đọc kỹ định dạng đầu vào trong đề. ZIP/WAR → gói ứng dụng; Docker image → ECS; Git repository → CodeCommit. Định dạng đầu vào thường đủ để loại bớt phân nửa phương án.
• CodeCommit chỉ là source control, không build và không triển khai. Đừng chọn nó chỉ vì nó nằm trong nhóm dịch vụ dành cho developer.

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

Đề hỏi: dịch vụ nào được dùng để đưa fault tolerance (khả năng chịu lỗi) vào kiến trúc ứng dụng?

Cụm từ quyết định là "introduce ... into an application architecture" — tức là một thành phần mà bạn chủ động thêm vào kiến trúc để hệ thống sống sót khi một phần hạ tầng chết. Đây là chỗ phân biệt tinh tế nhất của câu này: có những dịch vụ bản thân chúng đã chịu lỗi tốt, nhưng thêm chúng vào không làm cho phần còn lại của ứng dụng chịu lỗi hơn. Ràng buộc thứ hai là "fault tolerance" chứ không phải performance hay latency — nhiều phương án ở đây cải thiện tốc độ, không phải khả năng chịu lỗi.

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

D — Amazon Elastic Load Balancing (ELB).

ELB đứng trước một nhóm back-end EC2 instance được cấu hình giống hệt nhau và phân phối kết nối đến từng instance. Hai việc nó làm gắn thẳng vào fault tolerance:

• Phân tán tải qua nhiều instance, và điển hình là qua nhiều Availability Zone — một AZ hoặc một instance gặp sự cố thì phần còn lại vẫn phục vụ được.
• Health check: ELB kiểm tra tình trạng các target và ngừng gửi request tới target không lành mạnh, nên lỗi của một instance không biến thành lỗi mà người dùng nhìn thấy.

Đây đúng nghĩa là thứ bạn thêm vào kiến trúc để loại bỏ single point of failure ở tầng compute — khớp chính xác với cách đề đặt vấn đề.

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

A — Amazon CloudFront. Đây là CDN: cache nội dung ở các edge location và phục vụ nhanh cho người dùng web ở gần. Mục tiêu của nó là giảm độ trễ và giảm tải cho origin, không phải làm cho tầng ứng dụng chịu được lỗi. Nó có thể phục vụ nội dung đã cache, nhưng đó là hiệu ứng phụ của caching chứ không phải cơ chế bạn thêm vào để xử lý instance chết.

B — Amazon DynamoDB. Đây là phương án gần đúng nhất và cũng là cái bẫy chính. DynamoDB bản thân nó có fault tolerance — dữ liệu được replicate và dịch vụ do AWS quản lý. Nhưng nó hỏng ở đúng chữ "introduce ... into an application architecture": bạn không cắm DynamoDB vào một kiến trúc để làm cho application stack chịu lỗi hơn. Nó là một database NoSQL, chọn nó là vì mô hình dữ liệu và nhu cầu lưu trữ, không phải như một biện pháp chịu lỗi cho phần compute. Chịu lỗi sẵn có bên trong một dịch vụ khác với thêm chịu lỗi cho kiến trúc.

C — Amazon ElastiCache. Đây là in-memory cache (Redis/Memcached), đặt trước database để giảm số lần đọc lặp lại. Kết quả nó mang lại là hiệu năng tốt hơn, độ trễ thấp hơn — đúng như bản giải thích gốc nêu — chứ không phải khả năng chịu lỗi. Nếu instance ứng dụng chết, ElastiCache không giúp được gì; nó thậm chí còn là một thành phần nữa cần được thiết kế cho tính sẵn sàng.

📌 Điểm cần nhớ

• Câu hỏi kiểu "thêm cái gì vào kiến trúc để có fault tolerance / high availability" ở mức Cloud Practitioner gần như luôn dẫn tới Elastic Load Balancing (và người anh em của nó là Auto Scaling), vì đó là thành phần loại bỏ single point of failure ở tầng compute.
• Phân biệt rõ ba nhóm mục tiêu khi đọc phương án: fault tolerance (ELB), performance/latency (CloudFront, ElastiCache), lưu trữ dữ liệu (DynamoDB). Chọn đúng nhóm mà đề đang hỏi là xong nửa câu.
• "Dịch vụ X vốn đã chịu lỗi" không đồng nghĩa với "dùng X để tạo fault tolerance cho ứng dụng của bạn" — DynamoDB là ví dụ kinh điển cho khoảng cách này.
• Cơ chế thật sự tạo nên fault tolerance của ELB là health check + phân phối qua nhiều instance/AZ; nhớ hai từ khoá này để nhận ra đáp án trong các câu diễn đạt khác.

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

Đề hỏi: gói support rẻ nhất mà vẫn cho phép mở không giới hạn số case hỗ trợ kỹ thuật là gói nào.

Cụm từ quyết định đáp án là "lowest cost option that allows unlimited cases to be open" — nó gồm hai ràng buộc phải thoả cùng lúc:

1. unlimited cases — gói phải cho mở case hỗ trợ kỹ thuật không giới hạn số lượng;
2. lowest cost — trong số các gói thoả điều kiện 1, phải chọn gói ở bậc thấp nhất về giá.

Đây là kiểu câu "nhiều phương án cùng đúng ở vế 1, chỉ một đúng ở vế 2". Nếu chỉ đọc mỗi chữ "unlimited cases" thì Business và Enterprise cũng thoả, và người học rất dễ chọn nhầm Business. Chính chữ lowest cost mới là thứ loại chúng ra. Ngược lại, nếu chỉ đọc "lowest cost" thì Basic là gói rẻ nhất trong tất cả (không mất phí) — nhưng nó lại rớt ở vế "unlimited cases".

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

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

Gói Developer là bậc trả phí thấp nhất trong các gói AWS Support, và nó đã bao gồm quyền mở không giới hạn số case hỗ trợ kỹ thuật. Số lượng case không phải là thứ AWS dùng để phân tầng giữa Developer, Business và Enterprise — cả ba đều cho mở case không giới hạn. Cái phân tầng chúng là những yếu tố khác: đối tượng người được mở case, kênh liên lạc (chỉ email so với thêm chat/điện thoại), mức độ nghiêm trọng được khai báo, tốc độ phản hồi cam kết, và các dịch vụ đi kèm ở bậc cao.

Vì vậy, khi đề yêu cầu "unlimited cases" với chi phí thấp nhất, Developer là điểm giao nhau đúng: nó là gói đầu tiên tính từ dưới lên thoả điều kiện unlimited cases.

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

A. Business — Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Business thực sự cho mở unlimited cases, nên vế 1 nó thoả hoàn toàn. Nó hỏng ở vế 2: Business nằm trên Developer về giá. Người chọn Business thường vì nhớ rằng Business là gói đầu tiên có hỗ trợ 24/7 qua chat/điện thoại và dùng được cho môi trường production — đúng, nhưng đề không hỏi về kênh liên lạc hay môi trường production, đề chỉ hỏi ngưỡng giá thấp nhất có unlimited cases.

C. Basic — Đây là phương án rẻ nhất (đi kèm mọi tài khoản AWS, không mất thêm phí), nên nó thắng ở vế 2 nhưng rớt hoàn toàn ở vế 1. Với Basic bạn không mở được case hỗ trợ kỹ thuật nào cả: bạn chỉ được tiếp cận tài liệu, whitepaper, diễn đàn cộng đồng, và hỗ trợ cho các vấn đề về billing/tài khoản. "Không giới hạn" và "không được mở" là hai chuyện khác hẳn nhau — Basic thuộc vế sau.

D. Enterprise — Cũng cho unlimited cases, nên thoả vế 1, nhưng đây là bậc cao nhất trong các gói support, tức là đắt nhất. Nó đi kèm những thứ như Technical Account Manager và mức phản hồi nhanh nhất cho các sự cố nghiêm trọng. Đề hỏi lowest cost, nên đây là phương án sai theo hướng ngược lại hoàn toàn với Basic: Enterprise thừa tính năng và thừa chi phí so với yêu cầu.

📌 Điểm cần nhớ

• Basic không cho mở case hỗ trợ kỹ thuật. Đây là ranh giới quan trọng nhất giữa Basic và các gói trả phí: Basic chỉ có tài liệu, diễn đàn và hỗ trợ billing/tài khoản.
• Developer là bậc trả phí thấp nhất, và đã có unlimited technical support cases. Nên với mọi câu dạng "gói rẻ nhất mà vẫn được hỗ trợ kỹ thuật / mở case", đáp án gần như luôn là Developer.
• Số lượng case không phải là tiêu chí phân tầng giữa Developer, Business và Enterprise. Thứ phân tầng chúng là kênh liên lạc, ai được mở case, mức nghiêm trọng, và tốc độ phản hồi cam kết.
• Câu hỏi có hai ràng buộc thì phải lọc theo cả hai. Ở đây là "unlimited cases" (loại Basic) rồi mới "lowest cost" (loại Business và Enterprise). Bỏ sót một vế là rơi đúng vào phương án bẫy tương ứng.

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

Đề hỏi: một Elastic IP Address có thể được gán lại (remap) từ EC2 instance này sang EC2 instance khác qua ranh giới nào?

Cụm từ quyết định là "remapped between EC2 instances across which boundaries" — tức là câu hỏi về phạm vi hoạt động của Elastic IP trong AWS Global Infrastructure. Bốn phương án đưa ra bốn "ranh giới" khác nhau: Region, Availability Zone, Edge Location, DB Subnet. Ràng buộc phân biệt nằm ở hai điểm phải nhớ cùng lúc:

1. Elastic IP là tài nguyên gắn với một Region cụ thể — nó được cấp phát trong một Region và không di chuyển ra khỏi Region đó.
2. Ranh giới cần chọn phải là nơi thực sự chạy được EC2 instance — vì đề nói rõ là remap giữa các EC2 instance.

Hai điều kiện đó cộng lại chỉ còn đúng một đáp án.

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

B — Availability Zones.

Elastic IP chỉ dùng được trong phạm vi một Region, nên trong Region đó bạn có thể tháo địa chỉ ra khỏi instance này và gắn sang instance khác, kể cả khi hai instance nằm ở hai Availability Zone khác nhau. Đây chính là kỹ thuật kinh điển mà AWS mô tả: khi một instance ở AZ này hỏng, bạn nhanh chóng remap Elastic IP sang một instance ở AZ khác, và người dùng bên ngoài vẫn truy cập qua cùng một địa chỉ IP public — sự cố được "che" đi mà không phải chờ DNS cập nhật.

AZ là ranh giới lớn nhất mà Elastic IP vượt qua được: rộng hơn một AZ đơn lẻ, nhưng vẫn nằm gọn trong một Region.

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

• A — Regions. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Nó sai vì Elastic IP là tài nguyên theo Region: địa chỉ được cấp phát trong Region nào thì chỉ gắn được vào instance trong Region đó. Không có thao tác nào "chuyển" một Elastic IP sang Region khác; muốn có IP public ở Region khác, bạn phải cấp phát một Elastic IP mới ở Region đó — và đó là một địa chỉ khác, không phải cùng một địa chỉ được remap. Vì đề hỏi ranh giới mà việc remap vẫn thực hiện được, Region bị loại.

• C — Edge Locations. Edge Location là các điểm hiện diện dùng cho CloudFront (và các dịch vụ biên khác), phục vụ việc cache và phân phối nội dung gần người dùng. Không chạy EC2 instance ở Edge Location, nên khái niệm "remap Elastic IP giữa các EC2 instance qua ranh giới Edge Location" không tồn tại. Phương án này sai ngay từ tiền đề, không phải sai vì giới hạn kỹ thuật.

• D — DB Subnets. DB subnet (chính xác hơn là DB subnet group) là khái niệm của RDS — tập các subnet mà RDS dùng để đặt database instance vào VPC của bạn. Nó không liên quan gì tới EC2 instance, và cũng không phải một "ranh giới hạ tầng" theo kiểu Region/AZ. Đây là phương án nhiễu lấy từ một dịch vụ khác hẳn.

📌 Điểm cần nhớ

• Elastic IP là tài nguyên theo Region. Trong Region đó, nó gắn/tháo tự do giữa các instance, kể cả xuyên qua các Availability Zone — nhưng không bao giờ vượt Region.
• Công dụng kinh điển của Elastic IP trong đề thi: che sự cố của một instance bằng cách remap địa chỉ sang instance dự phòng ở AZ khác, giữ nguyên IP public cho người dùng bên ngoài.
• Phân biệt rõ ba tầng hạ tầng: Region chứa nhiều Availability Zone (nơi chạy EC2); Edge Location là tầng biên của CloudFront, không chạy EC2. Câu nào hỏi về nơi đặt instance mà thấy Edge Location thì loại được ngay.
• Cẩn thận với các phương án nhiễu lấy thuật ngữ từ dịch vụ khác — DB subnet group thuộc RDS, không phải khái niệm của EC2 hay của networking phổ quát.

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

Đề hỏi: lợi ích của việc dùng IAM role cho ứng dụng chạy trên EC2 instance là gì (chọn HAI).

Cụm từ quyết định là "benefits of using IAM roles ... for applications" — nghĩa là phải so sánh IAM role với cách làm thay thế, tức là nhúng access key (access key ID + secret access key) trực tiếp vào ứng dụng hoặc vào EC2 instance. Câu hỏi không hỏi "IAM role hoạt động thế nào", mà hỏi "đổi sang IAM role thì được lợi gì".

Điểm bẫy nằm ở chỗ có tới ba phương án nghe như đều là "ưu điểm": more secure, easier to manage, easier to configure. Chúng gần nhau đến mức phải tách bạch ba khái niệm khác nhau: bảo mật (credential có bị lộ không), quản lý (sửa quyền về sau có dễ không) và cấu hình (dựng lần đầu có ít bước hơn không). Hai phương án còn lại thì sai về mặt sự kiện kỹ thuật chứ không phải sai về sắc thái.

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

A. More secure than storing access keys within applications — Khi ứng dụng dùng IAM role, EC2 instance lấy credential từ instance metadata; credential này là tạm thời và được xoay vòng tự động, không nằm trong mã nguồn, file cấu hình hay image. Nhúng access key vào ứng dụng thì key đó tồn tại vĩnh viễn cho tới khi có người chủ động thu hồi, và nó đi theo mọi bản sao của mã nguồn — lọt vào repository, vào AMI, vào bản backup. Đây chính là lý do bảo mật mà tài liệu AWS nêu ra.

C. It is easier to manage IAM roles — Quản lý ở đây là chuyện sau khi đã dựng xong: muốn đổi quyền cho ứng dụng thì chỉ cần sửa policy gắn với role, mọi instance đang dùng role đó nhận thay đổi mà không phải đụng vào từng máy. Với access key thì phải đi phân phối lại key cho từng nơi, và khi cần xoay vòng key thì phải làm thủ công trên toàn bộ instance.

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

B. Role credentials are permanent — Sai ngược hẳn về bản chất. Credential do role cấp là temporary, có thời hạn và được AWS tự động làm mới. Đây không những không phải lợi ích, mà tính tạm thời mới chính là thứ tạo ra lợi ích ở phương án A.

D. Can apply multiple roles to a single instance — Sai về sự kiện. Một EC2 instance chỉ gắn được một instance profile, tức là chỉ một IAM role tại một thời điểm. Muốn instance có thêm quyền thì phải bổ sung policy vào chính role đó, chứ không gắn thêm role thứ hai. Phương án này nghe hợp lý vì với IAM user thì có thể gắn nhiều policy, nên dễ suy nhầm sang role trên instance.

E. Easier to configure than using storing access keys within the EC2 instance — Đây là phương án gần đúng nhất và là bẫy chính của câu. Nó nghe giống hệt C, nhưng nói về bước cấu hình ban đầu chứ không phải công tác quản lý về sau. Theo lời giải gốc: dùng role không dễ cấu hình hơn, vì có thêm các bước phải làm — tạo role, gắn trust policy, tạo instance profile, gắn vào instance. Nhét một access key vào file cấu hình thì ít thao tác hơn hẳn. Lợi ích của role nằm ở bảo mật và ở việc vận hành lâu dài, không nằm ở chỗ dựng nhanh hơn.

📌 Điểm cần nhớ

• Credential do IAM role cấp cho EC2 luôn là temporary và tự xoay vòng; bất kỳ phương án nào nói credential của role là "permanent" đều sai.
• Một EC2 instance = một IAM role (qua một instance profile). Cần thêm quyền thì thêm policy vào role, không gắn thêm role.
• Phân biệt cho rõ ba từ trong các phương án AWS: secure (rủi ro lộ credential), manage (sửa quyền, xoay vòng về sau), configure (số bước dựng lần đầu). IAM role thắng ở hai cái đầu, thua ở cái thứ ba.
• Nguyên tắc chung khi gặp câu về credential trên AWS: giải pháp đúng gần như luôn là không lưu long-term access key ở đâu cả — giao việc cấp credential cho role.

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

Đề hỏi: "Which tools can you use to manage identities in IAM? (Select TWO.)" — tức là công cụ nào dùng để quản lý identity (user, group, role, policy) trong AWS Identity and Access Management.

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

• "manage identities in IAM" — không phải "giám sát", không phải "cấp máy tính ảo cho nhân viên", mà là thao tác tạo/sửa/xoá các thực thể danh tính của IAM. Bất kỳ phương án nào không có giao diện tác động vào IAM đều loại.
• "tools" kèm "(Select TWO.)" — đề đang liệt kê các kênh truy cập vào IAM. IAM có nhiều kênh: AWS Management Console, AWS Command Line Tools, AWS SDKs và IAM HTTPS API. Trong danh sách phương án chỉ có hai kênh nằm trong nhóm đó, nên số lượng khớp đúng với yêu cầu chọn hai.

Bẫy chính là ba phương án còn lại đều là tên dịch vụ AWS nghe quen tai, nhưng không phương án nào là kênh quản trị của IAM.

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

Theo tệp, đáp án đúng là D và E.

• E — AWS Management Console: đây là giao diện web chính thức để làm việc với AWS. Trong console có mục IAM riêng, nơi bạn tạo user, gán vào group, gắn policy, tạo role. Đây là kênh quản lý identity trực quan nhất và là thứ hầu hết người dùng chạm vào đầu tiên.
• D — AWS Command Line Tools: nhóm công cụ dòng lệnh của AWS (AWS CLI và các công cụ dòng lệnh tương đương) cho phép gọi trực tiếp các thao tác của IAM từ terminal hoặc từ script. Cùng một khả năng như console nhưng ở dạng lệnh, nên tự động hoá được — tạo hàng loạt user, gán policy theo kịch bản, đưa vào pipeline.

Nói ngắn gọn: IAM được quản lý qua Management Console, Command Line Tools, SDKs và IAM HTTPS API. Hai thứ có mặt trong danh sách phương án chính là D và E.

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

• A — Amazon CloudWatch API: CloudWatch là dịch vụ giám sát — thu thập metric, log, đặt alarm về tình trạng tài nguyên AWS. Đây là phương án "gần đúng" nhất vì nó là một API của AWS, và người học dễ nghĩ "API thì gọi gì chẳng được". Chỗ hỏng: mỗi dịch vụ có API riêng với tập thao tác riêng. API dùng để quản lý identity là IAM HTTPS API, không phải CloudWatch API. CloudWatch API không có thao tác nào tạo user hay gắn policy IAM.
• B — EC2 Management Console: cũng là một cái bẫy tinh vi, vì nó có chữ "Management Console" giống hệt đáp án E. Nhưng đề nói AWS Management Console — giao diện chung, trong đó IAM là một mục. Còn "EC2 Management Console" chỉ là phần dành cho EC2: instance, AMI, security group, key pair, EBS volume. Đứng trong phần EC2 thì không tạo được IAM user; bạn phải chuyển sang mục IAM. Sai ở chỗ nó là một phần của console chứ không phải phần quản lý identity.
• C — Amazon WorkSpaces: dịch vụ máy tính để bàn ảo được quản lý, chạy trên AWS cloud — phát cho nhân viên một desktop dùng từ xa. Chữ "user" trong ngữ cảnh WorkSpaces là người dùng được cấp desktop, hoàn toàn khác với IAM identity. Đây là phương án lạc chủ đề rõ nhất trong bốn phương án sai.

📌 Điểm cần nhớ

• IAM được quản lý qua bốn kênh: AWS Management Console, AWS Command Line Tools, AWS SDKs và IAM HTTPS API. Gặp câu hỏi kiểu "công cụ nào dùng với dịch vụ X", hãy đối chiếu với bộ bốn kênh này — mẫu câu hỏi này lặp lại rất nhiều trong đề Cloud Practitioner.
• Phân biệt AWS Management Console (giao diện chung, chứa mọi dịch vụ) với console của một dịch vụ như EC2. Phương án đặt tên dịch vụ ngay trước chữ "Management Console" gần như luôn là bẫy.
• API của dịch vụ nào chỉ làm việc của dịch vụ đó. CloudWatch API để giám sát, IAM API để quản lý identity — không có API "dùng chung" cho mọi thao tác.
• Nhớ đúng một câu định nghĩa cho mỗi dịch vụ hay xuất hiện là đủ loại phần lớn phương án nhiễu: CloudWatch = giám sát metric/log, WorkSpaces = desktop ảo được quản lý, IAM = ai được làm gì trên tài nguyên AWS.

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

Đề hỏi: hai thứ nào phải dùng CÙNG NHAU để truy cập AWS account theo kiểu lập trình (programmatic access), và yêu cầu chọn hai phương án.

Cụm từ quyết định là "programmatic access" — tức là gọi AWS qua AWS CLI, AWS API hoặc AWS SDK, chứ không phải đăng nhập bằng trình duyệt vào AWS Management Console. Đây chính là ranh giới phân biệt các phương án: một cặp thuộc về đường lập trình, còn "user ID" thuộc về đường đăng nhập giao diện. Cụm thứ hai đáng chú ý là "must be used together" — đề không hỏi "thứ nào là credential", mà hỏi hai mảnh nào ghép lại mới thành một bộ xác thực hoàn chỉnh.

Trong AWS, bộ credential dùng cho programmatic access gọi là access key, và nó gồm đúng hai phần.

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

Đáp án đúng theo tệp là C (An access key ID) và E (A secret access key).

Access key là long-term credential gắn với một IAM user (hoặc với AWS account root user). Nó được dùng để ký các request gửi tới AWS CLI hoặc AWS API — trực tiếp hoặc thông qua AWS SDK.

Access key gồm hai phần không thể tách rời:

• Access key ID — phần công khai, dạng AKIAIOSFODNN7EXAMPLE, đóng vai trò như "tên" để AWS biết credential này thuộc về ai.
• Secret access key — phần bí mật, dạng wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY, dùng để ký request và chứng minh bạn thật sự sở hữu access key ID kia.

Cách hiểu dễ nhớ: cặp này hoạt động y như cặp user name và password — có ID mà không có secret thì không ký được request, có secret mà không biết ID thì AWS không biết đối chiếu với ai. Vì vậy phải dùng cả hai cùng nhau, đúng như đề yêu cầu. Và cũng vì vậy, secret access key phải được bảo vệ cẩn thận đúng như bảo vệ mật khẩu.

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

• A — A primary key: "Primary key" không phải là một khái niệm xác thực trong AWS. Thuật ngữ này thuộc về thế giới cơ sở dữ liệu (khoá chính của một bảng, ví dụ partition key trong DynamoDB). Nó không liên quan gì tới việc ký request hay chứng minh danh tính, nên không thể là một nửa của bộ credential.

• B — A secondary key: Tương tự A, đây là thuật ngữ bịa ra cho hợp bộ đôi "primary/secondary" nhằm gài người học chọn theo cặp. AWS không dùng khái niệm "secondary key" trong xác thực. Đây là kiểu mồi nhử rất hay gặp: hai phương án nghe như một cặp tự nhiên, dụ thí sinh chọn A và B vì đề bảo "Select TWO".

• D — A user ID: Đây là phương án gần đúng nhất và cũng nguy hiểm nhất. Nó đúng là một thứ liên quan đến danh tính, và trực giác "user ID + password" khiến người học dễ ghép nó với E. Nhưng nó hỏng ở đúng cụm từ khoá của đề: user ID dùng để đăng nhập vào AWS Management Console, tức là đường giao diện web, không phải đường lập trình. Ở đường programmatic, thứ đóng vai trò "tên đăng nhập" là access key ID chứ không phải user ID. Đề đã chốt "programmatic", nên D bị loại.

📌 Điểm cần nhớ

• Programmatic access (CLI / API / SDK) = access key ID + secret access key. Đây là cặp cố định, học thuộc là trả lời được cả một nhóm câu.
• Console access = user name + password (kèm MFA nếu bật). Hễ đề nhắc tới "Management Console" thì đổi sang bộ này; hễ nhắc "programmatic", "CLI", "SDK", "API" thì dùng access key.
• Access key luôn đi theo cặp — một nửa không dùng được. Secret access key chỉ hiện đúng một lần lúc tạo, nên phải cất giữ như mật khẩu.
• Cảnh giác với các phương án ghép cặp giả như "primary key / secondary key": chúng không tồn tại trong từ vựng xác thực của AWS, chỉ dựa vào việc đề yêu cầu chọn hai đáp án để dụ chọn trọn cặp.

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

Đề bài hỏi: dịch vụ AWS nào cho phép chia sẻ tài nguyên AWS của bạn một cách an toàn giữa các AWS account hoặc trong phạm vi organization, nhờ đó giảm công sức vận hành và quản lý tập trung quyền truy cập vào các tài nguyên được chia sẻ.

Cụm từ quyết định là "securely share your AWS resources across AWS accounts" — trọng tâm là chia sẻ chính tài nguyên (resource sharing), chứ không phải quản lý account, quản lý danh mục dịch vụ hay cấp quyền cho người dùng. Cả bốn phương án đều là dịch vụ quản trị và đều "liên quan tới nhiều account" theo cách nào đó, nên nếu đọc lướt sẽ thấy phương án nào cũng hợp lý. Ràng buộc phân biệt nằm ở đối tượng được chia sẻ là tài nguyên (resource), và ranh giới vượt qua là ranh giới account.

Chú ý thêm cụm "or within your organization": đề chấp nhận cả trường hợp bạn đang dùng AWS Organizations, nhưng đó chỉ là phạm vi chia sẻ, chứ không có nghĩa Organizations là dịch vụ thực hiện việc chia sẻ.

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

C — AWS Resource Access Manager (AWS RAM) đúng vì đây chính là dịch vụ sinh ra để làm đúng việc đề mô tả: chia sẻ tài nguyên AWS bạn sở hữu với AWS account khác, với Organizational Unit (OU), hoặc với toàn bộ organization khi bạn đang dùng AWS Organizations.

Giá trị vận hành của RAM nằm ở chỗ: thay vì mỗi account phải tự tạo và duy trì một bản sao tài nguyên riêng, bạn tạo tài nguyên ở một account rồi chia sẻ ra — các account khác dùng chung tài nguyên đó. Việc quản lý ai được truy cập cái gì cũng gom về một chỗ (resource share), đúng như đề bài nói "reduce operational overhead" và "centrally manage access to the shared resources".

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

A — AWS Service Catalog: dịch vụ này dùng để tạo và quản lý danh mục các dịch vụ CNTT đã được phê duyệt cho phép dùng trên AWS. Nó giúp tổ chức chuẩn hoá những gì nhân viên được phép triển khai, có kiểm soát và có trật tự. Nghe gần đúng vì cũng là "quản lý tập trung", nhưng thứ được phân phát là danh mục sản phẩm để người dùng tự triển khai bản của riêng họ, không phải chia sẻ quyền truy cập vào một tài nguyên đang tồn tại giữa các account như RAM.

B — AWS Identity and Access Management (IAM): đây là phương án gần đúng nhất và dễ chọn nhầm nhất, vì IAM đúng là nơi quản lý truy cập an toàn tới dịch vụ và tài nguyên AWS thông qua user, group, role và policy. Chỗ nó hỏng: IAM tập trung vào cấp quyền cho danh tính, chứ không phải là cơ chế được thiết kế riêng để chia sẻ tài nguyên qua ranh giới account và quản lý tập trung các resource share. Đề hỏi "dịch vụ nào cho phép chia sẻ tài nguyên" — câu trả lời phải là dịch vụ chuyên trách việc đó, và đó là RAM.

D — AWS Organizations: cũng rất dễ chọn nhầm vì đề có nhắc "within your organization". Organizations cho phép gom nhiều AWS account vào một tổ chức để quản lý billing và báo cáo chi phí tập trung, đồng thời kiểm soát truy cập, tuân thủ và bảo mật ở mức tổ chức. Nhưng bản thân nó không thực hiện việc chia sẻ tài nguyên giữa các account — nó dựng ra cái khung tổ chức, còn việc chia sẻ tài nguyên trong khung đó là việc của RAM.

📌 Điểm cần nhớ

• Thấy cụm "share resources across AWS accounts" trong đề AWS → nghĩ ngay tới AWS Resource Access Manager (AWS RAM). Đó là dịch vụ chuyên trách chia sẻ tài nguyên, không phải dịch vụ nào khác.
• Phân biệt rõ vai trò: IAM = cấp quyền cho danh tính; RAM = chia sẻ tài nguyên qua ranh giới account; Organizations = khung tổ chức nhiều account (billing, chính sách tập trung); Service Catalog = danh mục dịch vụ đã phê duyệt để người dùng tự triển khai.
• Từ "organization" xuất hiện trong đề không tự động đồng nghĩa với đáp án AWS Organizations — ở đây nó chỉ mô tả phạm vi chia sẻ. Luôn hỏi lại: đề đang yêu cầu dịch vụ nào thực hiện hành động, chứ không phải dịch vụ nào có mặt trong bối cảnh.
• RAM và Organizations bổ trợ nhau chứ không thay thế nhau: có Organizations thì RAM chia sẻ được tới cả OU hoặc toàn tổ chức thay vì phải liệt kê từng account.