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

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

Đề hỏi: tên của dịch vụ Docker registry do AWS quản lý (managed) mà Amazon ECS sử dụng là gì.

Cụm từ quyết định đáp án là "AWS managed" — tức là phải chọn một dịch vụ của AWS, không phải một sản phẩm chung chung của Docker. Cụm thứ hai đáng chú ý là "registry": trong thế giới container, registry là nơi lưu trữ và phân phối container image, khác với repository (một kho con bên trong registry, chứa các phiên bản của cùng một image).

Đây là câu kiểm tra trí nhớ về tên chính xác của dịch vụ — cả bốn phương án đều ghép lại từ các từ nghe rất quen (ECS, Docker, Container, Registry, Repository), nên phải nhớ đúng tên thương hiệu chứ không suy luận được bằng logic kiến trúc.

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

Đáp án đúng theo tệp là B — Elastic Container Registry.

Amazon Elastic Container Registry (ECR) là dịch vụ Docker container registry được AWS quản lý hoàn toàn, giúp lập trình viên lưu trữ, quản lý và triển khai các Docker container image. ECR được tích hợp sẵn với Amazon Elastic Container Service (ECS): khi định nghĩa task, bạn trỏ thẳng tới image nằm trong ECR và ECS kéo image đó về để chạy.

Điểm mấu chốt khớp với chữ "managed" trong đề: dùng ECR thì bạn không phải tự vận hành kho chứa container của riêng mình, cũng không phải lo mở rộng hạ tầng bên dưới — AWS lo phần đó. Tên gọi cũng theo đúng quy ước đặt tên của họ container trên AWS: chữ Elastic đứng đầu (giống Elastic Container Service, Elastic Kubernetes Service), rồi tới chức năng.

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

• A. ECS Container Registry — đây là phương án gài bẫy sát nhất, và nhiều người chọn vì đề có nhắc tới ECS ngay trong câu hỏi. Nhưng tên này không tồn tại. Registry không phải là một thành phần con nằm trong ECS; nó là một dịch vụ độc lập, có vòng đời riêng, quyền riêng, và dùng được cho cả những nơi khác ngoài ECS. Vì thế tên nó bắt đầu bằng Elastic chứ không phải ECS. Ý tưởng "registry phục vụ ECS" thì đúng, nhưng cái tên thì sai.
• C. Docker Container Registry — sai vì đây không phải là một registry của AWS. "Docker registry" là khái niệm/phần mềm chung của hệ sinh thái Docker, không phải dịch vụ AWS quản lý, nên không thoả cụm "AWS managed" trong đề. Chọn phương án này là nhầm giữa công nghệ (Docker) và dịch vụ được quản lý (AWS).
• D. Docker Image Repository — sai vì hai lý do chồng nhau. Thứ nhất, giống C, đây cũng không phải một registry của AWS. Thứ hai, chữ repository dùng sai cấp: repository là kho con bên trong một registry, còn đề hỏi tên dịch vụ registry. Đây là mô tả một khái niệm chung chứ không phải tên riêng của sản phẩm nào.

📌 Điểm cần nhớ

• ECR = Elastic Container Registry, dịch vụ Docker registry được AWS quản lý, tích hợp sẵn với ECS. Cặp ECS ↔ ECR là một trong những cặp tên hay bị hỏi ở mức Cloud Practitioner.
• Các dịch vụ container của AWS đều theo khuôn "Elastic ... ": Elastic Container Service (chạy container), Elastic Container Registry (lưu image), Elastic Kubernetes Service. Thấy phương án ghép kiểu "ECS Container ..." thì gần như chắc là tên bịa.
• Phân biệt registry (dịch vụ lưu và phân phối image) với repository (kho con của một image bên trong registry) — đề hay đánh tráo hai từ này.
• Khi đề nhấn chữ "AWS managed", hãy loại ngay những phương án chỉ nêu tên công nghệ chung (Docker) mà không phải tên một dịch vụ AWS: giá trị của bản managed là không phải tự vận hành và tự mở rộng hạ tầng bên dưới.

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

Đề hỏi: "Which AWS program can help an organization to design, build, and manage their workloads on AWS?" — chương trình nào của AWS giúp một tổ chức thiết kế, xây dựng và vận hành workload của họ trên AWS.

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

• "AWS program" — đề hỏi một chương trình, tức một khuôn khổ do AWS lập ra để tập hợp các đối tác hoặc dịch vụ, chứ không hỏi một chức danh cá nhân (một người). Cụm này loại thẳng những phương án là tên chức danh.
• "design, build, and manage their workloads" — đủ cả ba giai đoạn vòng đời, kể cả phần xây dựng và vận hành thay khách hàng. Đây là công việc triển khai thực tế (professional services), không phải công việc tư vấn bán hàng hay hỗ trợ kỹ thuật cho tài khoản.

Ghép hai cụm lại: cần một chương trình đối tác chuyên làm dịch vụ triển khai — đó chính là nhánh Consulting trong AWS Partner Network (APN).

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

D — APN Consulting Partners.

APN Consulting Partners là các công ty dịch vụ chuyên nghiệp (professional services firms) phục vụ khách hàng ở mọi quy mô, làm đúng những việc đề nêu: design, architect, build, migrate và manage workload cùng ứng dụng trên AWS. Nhóm này bao gồm nhiều loại hình:

• System Integrators (SIs)
• Strategic Consultancies
• Agencies
• Managed Service Providers (MSPs)
• Value-Added Resellers (VARs)

Đây là một chương trình thuộc AWS Partner Network — khớp với chữ "program" trong đề — và phạm vi công việc của nó phủ trọn cả ba động từ "design, build, manage".

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

A — AWS Business Development Manager. Đây là chức danh của một nhân viên, không phải một chương trình của AWS. Vai trò business development thiên về phát triển quan hệ kinh doanh và cơ hội thương mại, không phải đơn vị đứng ra thiết kế, xây dựng và vận hành workload thay khách hàng. Trượt ngay ở chữ "program".

B — APN Technology Consultants. Đây là phương án gần đúng nhất và là bẫy chính của câu này. Nó có tiền tố "APN" đúng, có chữ "Consultants" nghe rất giống "Consulting", nên rất dễ chọn nhầm. Nhưng trong AWS Partner Network, nhánh song song với Consulting là APN Technology Partners — những đơn vị cung cấp phần mềm, sản phẩm và giải pháp chạy trên hoặc tích hợp với AWS, chứ không phải đơn vị làm dịch vụ triển khai. Bản thân cụm "APN Technology Consultants" không phải tên chương trình chuẩn của AWS; nó là ghép lai giữa hai nhánh để đánh lừa. Cách phân biệt: Technology = bán sản phẩm/giải pháp, Consulting = làm dịch vụ trên workload của khách. Đề hỏi việc "design, build, manage workloads" nên phải rơi về nhánh Consulting.

C — AWS Technical Account Manager. Đây cũng là chức danh cá nhân, gắn với gói AWS Support ở mức cao (Enterprise). TAM là người hỗ trợ kỹ thuật, tư vấn tối ưu, hướng dẫn best practice và đồng hành cùng tài khoản khách hàng. Nghe khá gần vì cũng "giúp khách hàng về mặt kỹ thuật", nhưng hỏng ở hai chỗ: (1) nó không phải một "program", và (2) TAM hướng dẫn và cố vấn chứ không phải bên đứng ra tự tay xây dựng và vận hành workload thay khách hàng. Đề đòi cả "build" và "manage" — đó là việc của đối tác dịch vụ, không phải của TAM.

📌 Điểm cần nhớ

• Khi đề hỏi "AWS program", hãy loại ngay mọi phương án là tên chức danh con người (Business Development Manager, Technical Account Manager, Solutions Architect…). Chức danh không phải chương trình.
• Trong AWS Partner Network, nhớ chắc hai nhánh: Consulting Partners làm dịch vụ trên workload của khách (design, architect, build, migrate, manage — gồm SI, MSP, VAR, agency, strategic consultancy); Technology Partners cung cấp phần mềm/giải pháp chạy trên AWS. Đề nói tới vòng đời workload → Consulting.
• Phân biệt "làm giúp" và "cố vấn": đối tác Consulting trực tiếp triển khai và vận hành; Technical Account Manager thuộc AWS Support, đóng vai hướng dẫn và tối ưu cho tài khoản.
• Bẫy quen thuộc của dạng câu này là đổi một chữ trong tên chương trình thật ("Consulting" → "Consultants", "Technology" ghép với "Consultants"). Đọc kỹ đúng từng chữ của tên chương trình thay vì lướt qua thấy tiền tố "APN" là chọn.

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

Đề hỏi: dịch vụ nào tạo thành "app-facing services" trong hạ tầng serverless của AWS? (Chọn HAI)

Cụm từ quyết định đáp án là "app-facing" — hướng về phía ứng dụng, tức là lớp mà client/người dùng và mã ứng dụng trực tiếp gọi tới để chạy logic hoặc nhận request. Nếu bỏ qua cụm này, cả năm phương án đều "hợp lệ" theo một nghĩa nào đó: Lambda, Step Functions, DynamoDB, API Gateway đều thuộc nhóm serverless, còn EFS cũng là dịch vụ được quản lý hoàn toàn. Đề không hỏi "dịch vụ nào là serverless" mà hỏi hẹp hơn một bậc: trong bộ serverless đó, cái nào nằm ở lớp mặt tiền của ứng dụng, khác với lớp lưu trữ (backend) và lớp điều phối (orchestration).

Vậy bài toán rút gọn thành: phân loại từng phương án vào ba nhóm — app-facing, backend/storage, orchestration — rồi lấy đúng nhóm đầu tiên.

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

Đáp án đúng theo tệp là A (AWS Lambda) và D (Amazon API Gateway) — đúng như phần giải thích tiếng Anh kèm theo: cả hai là app-facing components của hạ tầng serverless.

• Amazon API Gateway là cửa ngõ nhận request từ bên ngoài: nó công bố endpoint HTTP/REST/WebSocket mà client gọi thẳng vào, lo định tuyến, xác thực, điều tiết lưu lượng. Đây đúng nghĩa là mặt tiền của ứng dụng.
• AWS Lambda là nơi chạy mã ứng dụng để đáp lại request đó. Logic nghiệp vụ của bạn nằm ở Lambda, và nó phản hồi trực tiếp cho lời gọi đến.

Ghép lại, API Gateway + Lambda là cặp kinh điển tạo thành lớp "ứng dụng" trong kiến trúc serverless: một bên nhận request, một bên xử lý request. Đó chính là lý do câu hỏi yêu cầu chọn hai — nó muốn đúng cặp mặt tiền này.

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

• B. AWS Step Functions — đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì Step Functions vừa serverless, vừa gắn rất chặt với Lambda. Nhưng nó là dịch vụ orchestration: việc của nó là ghép nhiều bước (thường là nhiều hàm Lambda) thành một workflow có trạng thái, quyết định bước nào chạy trước, bước nào rẽ nhánh, bước nào thử lại. Nó điều phối các thành phần khác chứ không phải là lớp ứng dụng đối diện với request. Sai ở chỗ phân loại tầng, không phải ở chỗ "không serverless".
• C. Amazon DynamoDB — cũng là dịch vụ serverless thật, nhưng nó là cơ sở dữ liệu, tức là backend. Ứng dụng đọc/ghi dữ liệu vào đó, còn client không gọi thẳng DynamoDB như gọi một endpoint ứng dụng. Nhóm lưu trữ nằm sau lớp app-facing, không phải chính lớp đó.
• E. Amazon EFS — là file system chia sẻ. Cách dùng điển hình của EFS là được mount vào các Amazon EC2 instance như một ổ đĩa mạng. Đây rõ ràng là tầng lưu trữ, và cũng là phương án xa đề nhất trong năm phương án: nó không phải mặt tiền ứng dụng theo bất kỳ cách đọc nào.

📌 Điểm cần nhớ

• Khi đề chèn một tính từ giới hạn như "app-facing", "backend", "orchestration", đó chính là cụm từ lọc phương án. Đừng dừng ở việc kiểm tra "dịch vụ này có serverless không" — cả bốn, năm phương án thường đều thoả điều kiện rộng đó.
• Bộ serverless của AWS nên nhớ theo tầng: mặt tiền ứng dụng (API Gateway, Lambda) — điều phối (Step Functions) — dữ liệu/lưu trữ (DynamoDB, EFS và các dịch vụ lưu trữ khác).
• API Gateway + Lambda là cặp mặc định của kiến trúc serverless: một bên tiếp nhận request, một bên chạy logic. Gặp câu hỏi về "lớp ứng dụng serverless" thì cặp này gần như luôn là đáp án.
• Step Functions là orchestration, không phải nơi chứa logic nghiệp vụ chính — nó gọi các hàm Lambda theo thứ tự chứ không tự đóng vai lớp ứng dụng. Nhớ phân biệt này để không nhầm ở các câu hỏi hỏi về vai trò từng dịch vụ.

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

Đề bài hỏi rất gọn: mối quan hệ giữa subnet và availability zone (AZ) trong một VPC là gì. Đây là câu kiểm tra khái niệm nền tảng về networking trên AWS, không có tình huống hay ràng buộc nghiệp vụ nào.

Cụm từ quyết định nằm ngay ở chính các phương án chứ không ở đề: bốn lựa chọn khác nhau ở chiều chứa nhau và ở số lượng. Cụ thể phải trả lời được hai câu hỏi tách biệt:

1. Ai nằm trong ai? Subnet nằm trong AZ, hay AZ nằm trong subnet?
2. Bao nhiêu? Mỗi AZ được đúng một subnet, hay nhiều subnet?

Trả lời đúng cả hai mới ra được phương án duy nhất. Chỉ nhớ mang máng "subnet gắn với AZ" là sẽ phân vân giữa B và C.

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

Đáp án đúng theo tệp là B — "You can create one or more subnets within each availability zone".

Đúng ở cả hai chiều đã nêu:

• Chiều chứa nhau: subnet là một dải địa chỉ con cắt ra từ CIDR của VPC, và mỗi subnet được gắn vào đúng một AZ khi tạo. VPC thì trải trên toàn bộ các AZ của một region, nhưng subnet thì không — nó nằm trọn trong một AZ. Chính vì thế mà kiến trúc chịu lỗi trên AWS luôn nói "triển khai qua nhiều AZ": bạn phải tạo nhiều subnet, mỗi cái ở một AZ khác nhau, rồi trải tài nguyên ra chúng.
• Số lượng: không có ràng buộc "một subnet mỗi AZ". Trong cùng một AZ bạn hoàn toàn có thể tạo nhiều subnet, và đây là cách làm phổ biến: một public subnet cho load balancer, một private subnet cho application server, một private subnet nữa cho database — tất cả trong cùng một AZ, khác nhau ở route table và ở việc có route ra internet gateway hay không.

Từ "one or more … within each" gói đúng cả hai ý: subnet nằm bên trong AZ, và số lượng không bị giới hạn ở một.

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

• A — "Subnets span across multiple availability zones": sai về chiều chứa nhau. Đây là nhầm lẫn hay gặp nhất vì người học nhớ rằng "VPC trải trên nhiều AZ" rồi áp luôn tính chất đó cho subnet. Thứ trải qua nhiều AZ là VPC, không phải subnet. Một subnet luôn nằm gọn trong một AZ duy nhất, và đó cũng là lý do vì sao khi tạo subnet bạn buộc phải chọn AZ.

• C — "You can create one subnet per availability zone": đây là phương án gần đúng nhất, và cũng là bẫy chính của câu này. Nó đúng chiều chứa nhau (subnet nằm trong AZ) nhưng sai ở số lượng — nó áp đặt giới hạn tối đa một subnet mỗi AZ, giới hạn này không tồn tại. Ai từng dựng kiến trúc nhiều tầng đều biết trong một AZ có ít nhất hai subnet (public và private). Nếu chỉ đọc lướt, C và B trông như cùng một ý; khác biệt duy nhất là "one" so với "one or more".

• D — "Subnets contain one or more availability zones": sai vì đảo ngược quan hệ chứa nhau. AZ là một đơn vị hạ tầng vật lý (một hoặc vài trung tâm dữ liệu tách biệt trong một region), còn subnet chỉ là một dải địa chỉ IP logic. Một cấu trúc địa chỉ không thể "chứa" một trung tâm dữ liệu. Quan hệ đúng luôn đi theo thứ tự: Region → Availability Zone → Subnet, subnet là cấp nhỏ nhất.

📌 Điểm cần nhớ

• Thứ tự lồng nhau cần thuộc lòng: Region chứa nhiều AZ; VPC trải trên các AZ của một region; mỗi subnet nằm trong đúng một AZ. VPC là thứ span qua nhiều AZ, subnet thì không.
• Một AZ chứa được bao nhiêu subnet cũng được. Gặp phương án nào ghi "one subnet per AZ" thì loại — nó đúng một nửa và sai ở nửa còn lại.
• Với những câu hỏi khái niệm kiểu này, hãy tách phương án thành hai trục: chiều chứa nhau và số lượng. Ra đề thường có sẵn một phương án đảo chiều (D), một phương án sai chiều theo kiểu nhầm với VPC (A), và một phương án đúng chiều nhưng siết số lượng (C).
• Hệ quả thực tế đáng nhớ: vì subnet không vượt qua ranh giới AZ, muốn hệ thống chịu được sự cố mất một AZ thì phải tạo nhiều subnet ở nhiều AZ khác nhau rồi trải tài nguyên qua chúng — đây là gốc của yêu cầu "subnet ở ít nhất hai AZ" mà load balancer và các dịch vụ multi-AZ đòi hỏi.

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

Đề hỏi: "What are the primary benefits of using AWS Elastic Load Balancing? (Select TWO.)" — hai lợi ích chính mà Elastic Load Balancing (ELB) mang lại.

Cụm từ quyết định ở đây là "primary benefits" kết hợp với "Elastic Load Balancing". Đây là dạng câu định nghĩa: các phương án đều là những thuật ngữ đẹp đẽ trong điện toán đám mây (caching, elasticity, automation, resilience), nhưng chỉ hai trong số đó là tác dụng trực tiếp của bản thân ELB. Muốn loại được các phương án gần giống nhau, hãy hỏi lại: ELB làm gì? Nó nhận traffic vào và phân phối traffic đó tới nhiều target ở nhiều Availability Zone bên trong một region, đồng thời health check để không gửi request tới target đang hỏng. Mọi lợi ích phải suy ra được từ đúng hành vi đó.

Chi tiết thứ hai đáng chú ý là phạm vi hoạt động: ELB làm việc trong một region, trên các Availability Zone. Ràng buộc này chính là thứ tách phương án D ra khỏi phương án B.

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

B. High availability — ELB tự động phân phối traffic đến nhiều EC2 instance nằm ở nhiều Availability Zone khác nhau trong cùng một region. Nhờ vậy, khi một instance hỏng hoặc thậm chí cả một AZ gặp sự cố, load balancer ngừng gửi request tới các target không còn khoẻ và dồn traffic sang phần còn lại. Ứng dụng vẫn phục vụ được — đó chính là định nghĩa của high availability. Không có ELB thì client trỏ thẳng vào một instance, và instance đó chết là dịch vụ chết theo.

C. Elasticity — ELB có khả năng xử lý được những thay đổi nhanh và đột ngột của lưu lượng mạng. Bản thân load balancer co giãn theo tải mà không cần người vận hành can thiệp, và nó là điểm vào ổn định để lượng target phía sau tăng hay giảm mà client không phải biết. Đây là lý do ELB luôn xuất hiện cùng nhóm chủ đề "elasticity" trong tài liệu AWS.

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

A. Caching — Caching là việc lưu lại nội dung để lần sau trả về mà không phải xử lý lại. ELB không làm chuyện đó: nó chuyển tiếp request tới target rồi trả response về, chứ không giữ lại nội dung để phục vụ cho request sau. Caching không phải là lợi ích của ELB.

D. Regional resilience — Đây là phương án gần đúng nhất và cũng là cái bẫy chính của câu này. Nó nghe rất giống "high availability" nên dễ chọn nhầm. Chỗ hỏng nằm ở phạm vi: một ELB phân phối traffic tới các EC2 instance trong một Availability Zone hoặc nhiều Availability Zone, nhưng không phân phối xuyên qua nhiều region. "Regional resilience" hàm ý chịu được sự cố ở mức cả một region — điều mà bản thân ELB không cung cấp. Nói cách khác: đúng ý tưởng (chịu lỗi), sai đơn vị phạm vi (region thay vì AZ).

E. Automation — Automation nghĩa là tự động hoá việc tạo lập, cấu hình, vận hành hạ tầng. ELB đúng là hoạt động tự động ở phần phân phối traffic và health check, nhưng "automation" không phải là lợi ích chính mà dịch vụ này được đưa ra để giải quyết. Chọn E là mô tả một tính chất phụ thay vì mục đích tồn tại của dịch vụ — dạng sai rất hay gặp trong câu hỏi "primary benefit".

📌 Điểm cần nhớ

• ELB làm việc trong phạm vi một region, trên nhiều Availability Zone — không phải nhiều region. Bất kỳ phương án nào gắn ELB với khả năng chịu lỗi ở mức region đều sai vì lý do phạm vi này.
• Hai lợi ích được AWS gắn với ELB trong tài liệu là high availability và elasticity: phân phối traffic qua nhiều AZ, và hấp thụ được biến động lưu lượng đột ngột.
• Với câu hỏi "primary benefit", hãy chọn thứ chính là lý do dịch vụ tồn tại, đừng chọn tính chất phụ đúng-nhưng-không-cốt-lõi (như automation ở đây).
• Khi hai phương án nghe giống nhau (high availability vs regional resilience), điểm phân biệt thường là đơn vị phạm vi: instance → Availability Zone → region. Xác định đúng dịch vụ hoạt động ở tầng nào là ra đáp án.

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

Đề hỏi: dịch vụ bảo mật nào của AWS đóng vai trò firewall ở mức subnet bên trong một VPC.

Cụm từ quyết định là "at the subnet level within a VPC" — không phải "firewall" nói chung, mà là tầng mà firewall đó gắn vào. Trong VPC, AWS có đúng hai cơ chế lọc gói tin dạng firewall và chúng khác nhau ở chỗ gắn:

• gắn vào subnet → Network ACL
• gắn vào instance / ENI → Security Group

Chỉ cần đọc đúng bốn chữ "subnet level" là loại được phương án gây nhiễu mạnh nhất. Cụm thứ hai đáng chú ý là "within a VPC": nó giới hạn câu trả lời vào các cơ chế network của VPC, nên mọi phương án thuộc nhóm kiểm soát quyền truy cập (IAM, S3) đều nằm ngoài phạm vi câu hỏi ngay từ đầu.

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

A. Network Access Control List (Network ACL) — đây là firewall được gắn trực tiếp vào subnet trong VPC. Mọi gói tin đi vào subnet và đi ra khỏi subnet đều bị Network ACL kiểm tra theo danh sách rule. Vì nó nằm ở biên của subnet chứ không nằm ở từng máy, một Network ACL bảo vệ đồng thời tất cả các resource đặt trong subnet đó — đúng nghĩa "firewall at the subnet level".

Mỗi subnet luôn được liên kết với đúng một Network ACL; nếu không chỉ định gì thì nó dùng Network ACL mặc định của VPC. Đây chính xác là mô tả trong đề, nên A là đáp án.

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

C. Security Group — đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Security Group đúng là một firewall trong VPC, đúng là lọc traffic inbound/outbound, nhưng nó gắn vào instance (chính xác hơn là vào network interface của instance), không gắn vào subnet. Hai instance nằm cùng một subnet có thể mang hai Security Group hoàn toàn khác nhau — điều đó cho thấy phạm vi của nó là từng máy, không phải cả subnet. Nó hỏng đúng ở chữ "subnet level" trong đề; mọi phần còn lại của mô tả đều khớp, nên nếu đọc lướt rất dễ chọn nhầm.

B. IAM Policy — IAM Policy dùng để gán quyền cho user và role: ai được gọi API nào, trên resource nào. Nó hoạt động ở tầng quyền truy cập của AWS API, không xem xét gói tin, không có khái niệm port hay dải IP nguồn/đích trong ngữ cảnh lọc traffic của subnet. Đây không phải firewall và cũng không liên quan tới ranh giới subnet.

D. Bucket Policy — là policy gắn vào một Amazon S3 bucket để kiểm soát ai được truy cập bucket/object đó. Phạm vi của nó là một resource S3 cụ thể, mà S3 lại là dịch vụ nằm ngoài VPC theo nghĩa không có subnet để gắn vào. Cũng là kiểm soát truy cập chứ không phải lọc gói tin, nên sai cả về loại cơ chế lẫn về tầng áp dụng.

📌 Điểm cần nhớ

• Trong VPC, câu hỏi "firewall ở đâu" luôn quy về cặp Network ACL ↔ Security Group: Network ACL gắn vào subnet, Security Group gắn vào instance/ENI. Nhận ra chữ "subnet" hay "instance" trong đề là chọn được đáp án ngay.
• Phân biệt lọc traffic với phân quyền truy cập. Network ACL và Security Group xử lý gói tin; IAM Policy và Bucket Policy quyết định ai được phép gọi/đọc cái gì. Đề nào dùng chữ "firewall", "traffic", "inbound/outbound" thì đáp án nằm ở nhóm đầu.
• Bucket Policy luôn buộc chặt với S3. Thấy nó trong danh sách mà đề không nhắc tới S3 hay object thì đó gần như chắc chắn là phương án nhiễu.
• Một Network ACL bảo vệ toàn bộ resource trong subnet, còn Security Group thì mỗi instance có thể mang một bộ rule riêng — đây là cách nhanh nhất để tự kiểm tra lại lựa chọn của mình khi hai phương án này cùng xuất hiện.

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

Đề mô tả một công ty cần hai thứ cùng lúc cho website của mình:

1. Bảo vệ khỏi tấn công DDoS (distributed denial of service).
2. "Assistance from AWS experts during such events" — được chuyên gia của AWS hỗ trợ trong lúc bị tấn công.

Vế thứ hai chính là cụm từ quyết định. Nếu đề chỉ hỏi "chống DDoS" thì nhiều dịch vụ trong danh sách còn có thể tranh cãi — nhưng khi đề đòi có người của AWS vào cuộc trong sự cố, thì chỉ còn đúng một dịch vụ trong bốn phương án gắn liền với đội hỗ trợ chuyên trách. Ngoài ra, đề còn nhấn "AWS managed service", nghĩa là câu trả lời phải là một dịch vụ do AWS vận hành sẵn, không phải thứ khách hàng tự dựng.

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

Đáp án đúng theo tệp là B — AWS Shield Advanced.

AWS Shield có hai mức. Mức tiêu chuẩn bảo vệ chống các tấn công DDoS phổ biến ở tầng mạng và tầng vận chuyển, bật sẵn cho mọi khách hàng. Shield Advanced là mức trả phí, bổ sung khả năng phát hiện và giảm thiểu tấn công sâu hơn, báo cáo chi tiết về sự cố, và — điểm mấu chốt của câu này — cho phép làm việc trực tiếp với AWS DDoS Response Team (DRT), đội chuyên trách ứng cứu DDoS của AWS, sẵn sàng suốt ngày đêm và có thể được huy động trước, trong và sau một đợt tấn công (quyền truy cập đội này gắn với các gói support ở mức Business/Enterprise).

Ghép hai vế của đề lại: chống DDoS ✔ và có chuyên gia AWS đồng hành trong sự cố ✔ — chỉ Shield Advanced thỏa cả hai.

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

A. Amazon GuardDuty — đây là dịch vụ phát hiện mối đe dọa, liên tục theo dõi tài khoản và tài nguyên AWS, dùng machine learning cùng phát hiện bất thường để cảnh báo các hành vi đáng ngờ. Nó báo cho bạn biết có chuyện bất thường, chứ không chặn lưu lượng tấn công, và cũng không đi kèm đội ứng cứu DDoS. Sai ở cả hai vế của đề.

C. AWS Web Application Firewall (WAF) — đây là phương án gần đúng nhất và dễ chọn nhầm. WAF lọc request HTTP/HTTPS theo luật, bảo vệ web application và API khỏi các kiểu tấn công như SQL injection hay cross-site scripting, và có thể dùng rate-based rule để giảm bớt một số dạng lạm dụng ở tầng ứng dụng. Nhưng nó hỏng ở hai chỗ so với yêu cầu của đề: thứ nhất, WAF không phải dịch vụ chuyên trách chống DDoS — nó không xử lý các đợt tấn công thể tích ở tầng mạng; thứ hai, và quan trọng hơn với câu này, WAF không kèm theo bất kỳ hình thức hỗ trợ nào từ chuyên gia AWS trong lúc bị tấn công. Cụm "assistance from AWS experts" loại WAF ra.

D. AWS Firewall Manager — dịch vụ này là lớp quản trị tập trung, dùng để áp và duy trì cấu hình một cách nhất quán trên nhiều tài khoản và nhiều tài nguyên cho AWS WAF, AWS Shield Advanced và security group của Amazon VPC. Nó quản lý các dịch vụ bảo vệ khác chứ tự nó không chặn tấn công, và cũng không cung cấp đội chuyên gia ứng cứu. Đáng chú ý: Firewall Manager quản lý Shield Advanced — tức là nó nằm phía trên đáp án đúng, chứ không thay thế được đáp án đúng.

📌 Điểm cần nhớ

• Cụm từ "assistance from AWS experts" / "DDoS Response Team" gần như luôn trỏ thẳng tới AWS Shield Advanced. Đây là dấu hiệu nhận dạng nhanh nhất để phân biệt Shield Advanced với Shield tiêu chuẩn và với WAF.
• Phân vai bốn dịch vụ cho gọn: Shield = chống DDoS; WAF = lọc request tầng ứng dụng theo luật; GuardDuty = phát hiện mối đe dọa và cảnh báo; Firewall Manager = quản trị tập trung ba thứ kia trên nhiều tài khoản.
• Phân biệt phát hiện với ngăn chặn: GuardDuty thuộc nhóm phát hiện, Shield và WAF thuộc nhóm bảo vệ. Đề hỏi "protection" thì loại ngay nhóm phát hiện.
• Khi một phương án là dịch vụ quản lý các dịch vụ khác (như Firewall Manager), nó gần như không bao giờ là đáp án cho câu hỏi "dịch vụ nào bảo vệ khỏi X" — trừ khi đề nhấn vào việc áp chính sách nhất quán trên nhiều tài khoản.

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

Đề hỏi: "What are two benefits of using AWS Lambda? (Select TWO.)" — hai lợi ích của việc dùng AWS Lambda.

Cụm từ quyết định ở đây là "benefits of using AWS Lambda" kết hợp với bản chất serverless của dịch vụ. Đây là câu hỏi khái niệm nền tảng: người ra đề muốn kiểm tra xem thí sinh có phân biệt được Lambda với các dịch vụ compute mà bạn phải tự quản lý hạ tầng (EC2) hay không.

Điểm mấu chốt cần nắm: với Lambda, AWS chịu trách nhiệm toàn bộ phần hạ tầng bên dưới — máy chủ, hệ điều hành, vá lỗi, mở rộng quy mô. Bạn chỉ nộp lên đoạn mã (function) và cấu hình bộ nhớ, thời gian chạy tối đa. Bất kỳ phương án nào ngụ ý rằng bạn được chọn hoặc phải quản lý một thành phần hạ tầng nào đó đều mâu thuẫn với mô hình serverless, và vì thế không thể là lợi ích của Lambda.

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

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

B — "No servers to manage": Đây chính là định nghĩa của serverless. Với Lambda bạn không provision instance, không quản lý hệ điều hành, không cài đặt bản vá, không lo dung lượng đĩa hay tuổi thọ máy chủ. AWS lo hết phần đó. Đối chiếu với EC2 — nơi bạn phải chọn instance type, tự vá OS, tự theo dõi tình trạng máy — sự khác biệt này là lý do chính khiến người ta chọn Lambda.

E — "Continuous scaling (scale out)": Lambda tự động mở rộng theo lưu lượng. Điểm quan trọng cần chú ý là chữ scale out chứ không phải scale up: Lambda không làm cho một lần chạy mạnh hơn khi tải tăng, mà chạy song song nhiều lần gọi hàm cùng lúc. Mỗi request đến sẽ được phục vụ bởi một lần thực thi riêng. Bạn không phải cấu hình Auto Scaling group hay đặt ngưỡng CPU — việc mở rộng và thu hẹp diễn ra tự động theo số lượng sự kiện đi vào.

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

A — "Flexible operating system choices": Đây là phương án gần đúng nhất và cũng dễ bẫy nhất, vì Lambda có cho bạn chọn runtime (Python, Node.js, Java, .NET…) nên nhiều người nhầm "chọn runtime" thành "chọn hệ điều hành". Nhưng hai thứ đó khác nhau. Bạn không quản lý và không được chọn hệ điều hành mà hàm chạy trên đó — đây thuộc phần AWS giữ. Hơn nữa, ngay cả khi có, việc "được chọn OS" cũng đi ngược tinh thần serverless: điều bạn muốn ở Lambda là không phải bận tâm tới OS, chứ không phải có thêm quyền lựa chọn.

C — "Open source software": Lambda là dịch vụ độc quyền của AWS, không phải phần mềm mã nguồn mở. Bạn không thể tải mã nguồn Lambda về tự chạy trên hạ tầng riêng. Lưu ý phân biệt: các runtime mà Lambda hỗ trợ (Python, Node.js) là mã nguồn mở, nhưng bản thân nền tảng Lambda thì không. Đây là kiểu bẫy lấy một đặc tính của thành phần con để gán cho cả dịch vụ.

D — "Integrated snapshots": Snapshot là khái niệm gắn với lưu trữ bền vững — bạn chụp ảnh trạng thái một volume để sao lưu hay nhân bản. Lambda không có lưu trữ bền vững gắn với hàm: môi trường thực thi là tạm thời, dữ liệu ghi trong đó biến mất sau khi vòng đời kết thúc. Không có cái gì để chụp snapshot, nên tính năng này đơn giản là không tồn tại với Lambda. Đây là phương án lấy đặc tính của EBS/EC2 đặt nhầm chỗ.

📌 Điểm cần nhớ

• "No servers to manage" là câu trả lời gần như mặc định cho mọi câu hỏi về lợi ích của Lambda. Thấy Lambda trong đề mà có phương án này, hãy ưu tiên chọn.
• Lambda scale out, không scale up. Tải tăng thì số lần gọi chạy song song tăng lên, chứ không phải một lần chạy được cấp thêm sức mạnh. Đề hay dùng chính cặp từ này để phân biệt.
• Phân biệt "chọn runtime" với "chọn hệ điều hành". Lambda cho bạn cái thứ nhất, không cho cái thứ hai. Bất kỳ phương án nào nói bạn quản lý hay chọn hạ tầng đều mâu thuẫn với serverless.
• Lambda không có lưu trữ bền vững gắn liền. Mọi phương án nhắc tới snapshot, volume, hay dữ liệu tồn tại lâu dài trong môi trường thực thi đều sai.
• Lambda là dịch vụ độc quyền của AWS, không phải mã nguồn mở — dù các runtime nó hỗ trợ là mã nguồn mở.

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

Đề bài hỏi: dịch vụ AWS nào cho phép developer và data scientist build, train, and deploy các mô hình machine learning?

Cụm từ quyết định đáp án là "build, train, and deploy machine learning models" — tức là tự mình xây dựng mô hình, chứ không phải dùng một mô hình đã có sẵn. Đây chính là ranh giới phân biệt hai nhóm dịch vụ AI/ML trên AWS mà đề đang cố ý đặt cạnh nhau:

• Nhóm AI service dùng ngay: gọi API, AWS đã huấn luyện mô hình sẵn, người dùng không train gì cả.
• Nhóm ML platform: cung cấp môi trường để bạn tự chuẩn bị dữ liệu, huấn luyện, rồi triển khai mô hình của chính mình.

Chỉ cần nhận ra từ "train" và "deploy models" trong đề là loại được ngay ba phương án còn lại — vì với chúng, người dùng không hề huấn luyện hay triển khai mô hình nào.

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

D — Amazon SageMaker là nền tảng được quản lý hoàn toàn (fully managed), tạo ra đúng để developer và data scientist build, train và deploy mô hình machine learning ở mọi quy mô. Nó phủ trọn vòng đời ML: chuẩn bị dữ liệu, viết và chạy job huấn luyện, rồi đưa mô hình đã huấn luyện lên endpoint để phục vụ dự đoán.

Điểm bán hàng của SageMaker được mô tả trong tài liệu chính là gỡ bỏ những rào cản thường làm chậm developer khi muốn dùng machine learning — hạ tầng huấn luyện, môi trường notebook, việc đóng gói và host mô hình đều do dịch vụ lo. Đó là lý do nó khớp từng chữ với ba động từ trong đề, còn các phương án khác chỉ khớp được phần "machine learning" chung chung.

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

A — Amazon Comprehend. Đây là dịch vụ natural language processing (NLP): nó dùng machine learning để tìm insight và mối quan hệ trong văn bản (thực thể, chủ đề, sắc thái tình cảm…). Phương án này gần đúng ở chỗ nó thật sự là dịch vụ machine learning, nên dễ gây phân vân. Nhưng nó hỏng ở chỗ: người dùng không build và không train mô hình nền — chỉ gửi text vào và nhận kết quả. Nó là người tiêu thụ ML, không phải nền tảng tạo ra ML.

B — Amazon Rekognition. Dịch vụ giúp thêm khả năng phân tích ảnh và video vào ứng dụng (nhận diện vật thể, khuôn mặt, cảnh…). Cùng một kiểu bẫy như Comprehend: đúng là AI service, nhưng thuộc nhóm gọi API dùng ngay. Không có bước huấn luyện mô hình do người dùng thực hiện, cũng không có việc deploy mô hình lên endpoint của riêng mình — nên không đáp ứng vế "build, train, and deploy".

C — Amazon MQ. Phương án này lệch hẳn khỏi chủ đề: đó là managed message broker cho Apache ActiveMQ, dùng để dựng và vận hành message broker trên cloud, phục vụ giao tiếp bất đồng bộ giữa các ứng dụng. Nó không liên quan gì tới machine learning. Đây là loại phương án "gây nhiễu bằng cái tên lạ", loại được ngay khi biết MQ = message queue/broker.

📌 Điểm cần nhớ

• Thấy đủ bộ ba động từ build – train – deploy trong đề thi AWS về machine learning thì gần như chắc chắn câu trả lời là Amazon SageMaker: đó là nền tảng ML, không phải AI service gọi sẵn.
• Phân biệt hai tầng: AI service dùng ngay (Comprehend cho text/NLP, Rekognition cho ảnh và video) — bạn gọi, AWS đã train sẵn; ML platform (SageMaker) — bạn train và deploy mô hình của mình.
• Nhớ mỗi AI service theo loại dữ liệu đầu vào: Comprehend → văn bản; Rekognition → ảnh/video. Cách nhớ theo loại dữ liệu giúp trả lời nhanh cả loạt câu tương tự.
• Đừng để tên viết tắt đánh lừa: Amazon MQ là message broker, thuộc nhóm application integration, hoàn toàn không dính tới machine learning dù xuất hiện trong danh sách phương án của câu hỏi về ML.

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

Đề bài mô tả một công ty giáo dục trực tuyến, cần video courses phát được với độ trễ thấp nhất cho người dùng khắp thế giới.

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

• "video courses play" — đây là việc phân phối nội dung tĩnh, dạng media, theo chiều đọc/tải xuống cho người xem. Không phải ghi dữ liệu, không phải truy vấn quan hệ.
• "minimal latency for their users around the world" — người dùng phân tán toàn cầu, nên vấn đề cốt lõi là khoảng cách vật lý giữa người xem và nơi chứa nội dung.

Ghép lại, câu hỏi đang tìm một dịch vụ đưa nội dung media lại gần người xem — tức mô tả nguyên văn công dụng của một CDN. Mọi phương án còn lại đều là dịch vụ toàn cầu/đa Region, nhưng phục vụ loại dữ liệu hoặc chiều truyền khác. Đó chính là ràng buộc phân biệt: loại dữ liệu (video/media) và chiều truyền (đọc, ra phía người dùng).

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

B. Use Amazon CloudFront to get the content closer to users

Amazon CloudFront là content delivery network (CDN) của AWS. Nó cache nội dung tại các Edge Location phân bố khắp thế giới. Khi một người học ở xa origin mở bài giảng, request được phục vụ từ Edge Location gần họ thay vì phải đi vòng tới Region chứa origin.

Điều này khớp chính xác với hai ràng buộc của đề:

• Nội dung là video — dạng file tĩnh, đọc nhiều lần, rất hợp để cache ở edge.
• Người dùng ở khắp nơi — mạng lưới edge toàn cầu chính là thứ rút ngắn quãng đường mạng, nhờ đó giảm latency và cải thiện trải nghiệm xem.

Đây là use case kinh điển của CloudFront: phân phối media tới khán giả toàn cầu.

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

A. Use Amazon EBS Cross Region Replication to get the content close to the users

Sai ở hai tầng. Thứ nhất, "EBS Cross Region Replication" không tồn tại như một tính năng — thứ có tên đó là S3 Cross Region Replication. Với EBS, bạn có thể copy volume sang Region khác một cách thủ công hoặc bằng script, chứ không có cơ chế replication dựng sẵn theo kiểu này.

Thứ hai, kể cả làm được thì EBS vẫn là lựa chọn tồi để đưa nội dung tới gần người xem: EBS volume phải được mount vào một EC2 instance mới dùng được, nghĩa là bạn phải dựng và trả tiền cho instance ở mỗi Region, rồi tự lo chuyện đồng bộ file giữa các bản sao. EBS là block storage gắn với instance, không phải kênh phân phối nội dung.

C. Use Amazon S3 Transfer Acceleration to speed up downloads

Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi — nó cũng dùng hạ tầng edge của AWS, cũng nói về "tăng tốc". Nhưng nó hỏng ở chiều truyền dữ liệu: S3 Transfer Acceleration được thiết kế để tăng tốc upload lên S3 từ xa, không phải để phục vụ download cho người xem. Đề bài đang nói về việc người học play video — tức chiều đọc ra. Chọn C là đọc đúng chữ "speed up" nhưng đọc sai chữ "play".

Thêm nữa, Transfer Acceleration không cache nội dung ở edge; nó chỉ tối ưu đường đi của một lần truyền tới bucket, nên không có lợi ích dùng lại cho hàng nghìn người xem cùng một bài giảng như CDN.

D. Use Amazon Aurora Global Database

Aurora Global Database đúng là dịch vụ dành cho ứng dụng phân tán toàn cầu, cho phép một database Aurora trải trên nhiều AWS Region — nên nghe qua có vẻ khớp với chữ "around the world". Nhưng nó hỏng ở loại dữ liệu: đây là SQL database quan hệ, dùng cho dữ liệu có cấu trúc và truy vấn. Lưu trữ và phát file media không phải use case của nó. Video course không nằm trong bảng cơ sở dữ liệu.

📌 Điểm cần nhớ

• Đề nói giảm latency khi phân phối nội dung tĩnh/media cho người dùng toàn cầu → gần như luôn là CloudFront, vì nó cache tại Edge Location để đưa nội dung lại gần người xem.
• Phân biệt theo chiều truyền: CloudFront tối ưu phân phối ra (download/xem); S3 Transfer Acceleration tối ưu đưa dữ liệu vào (upload lên S3). Đề nhắc tới việc người dùng xem/tải nội dung là loại luôn Transfer Acceleration.
• Phân biệt theo loại dữ liệu: Aurora Global Database dành cho dữ liệu quan hệ trải nhiều Region, không dùng để chứa hay phát file media — "toàn cầu" không đồng nghĩa với "hợp cho video".
• EBS là block storage gắn vào EC2 instance, không phải cơ chế phân phối nội dung; và cần cảnh giác với những phương án nêu tên tính năng nghe hợp lý nhưng thực ra không tồn tại — "Cross Region Replication" là của S3, không phải của EBS.