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

🔎 Phân tích câu hỏi
Câu hỏi yêu cầu công ty “tổ chức người dùng sao cho có thể cấp quyền cho người dùng theo nhóm”.
Điều này liên quan tới quản lý danh tính, quyền truy cập và việc gán các policy cho tập hợp người dùng trong AWS. Do đó chúng ta cần một dịch vụ cho phép:

1. Tạo nhóm người dùng (user groups).
2. Gán IAM policy (permission) cho nhóm để các thành viên trong nhóm nhận cùng một quyền.
3. Quản lý danh tính (tạo, xóa, thay đổi người dùng, nhóm, role…).

✅ Đáp án đúng: AWS Identity and Access Management (IAM)

IAM cung cấp tính năng IAM Groups – một cách đơn giản để gom lại các IAM Users và gán chính sách (policy) chung. Khi một policy được gán cho nhóm, mọi thành viên trong nhóm đều được thừa hưởng các quyền đó. Đây chính là công cụ phù hợp nhất để đáp ứng yêu cầu “grant permissions to the users as a group”.

📚 Giải thích chi tiết từng phương án

1️⃣ Security groups (Sai)

• Mô tả: Security groups là tường lửa ảo cấp lớp mạng, dùng để kiểm soát lưu lượng inbound/outbound cho EC2, RDS, Lambda VPC, ….
• Vì sao không đúng: Chúng không liên quan tới người dùng hay quyền IAM. Security groups chỉ áp dụng cho tài nguyên mạng, không thể dùng để gán hoặc quản lý permission cho người dùng.
• Kết luận: ❌ Không đáp ứng yêu cầu tổ chức người dùng và cấp quyền nhóm.

2️⃣ AWS Identity and Access Management (IAM) (Đúng)

• Mô tả: Dịch vụ quản lý danh tính và quyền truy cập toàn bộ AWS. Cho phép tạo IAM Users, IAM Groups, IAM Roles và IAM Policies.
• Cách đáp ứng yêu cầu:
  • Tạo IAM Group (ví dụ: Developers, Admins).
  • Gán IAM Policy (ví dụ: AmazonS3ReadOnlyAccess) cho nhóm.
  • Khi người dùng được thêm vào nhóm, họ tự động nhận các quyền được gán.
• Các tính năng liên quan (tính đến 2026):
  • IAM Access Analyzer giúp kiểm tra các quyền không cần thiết.
  • Permission Boundaries và Session Policies để tinh chỉnh quyền.
  • IAM Identity Center (SSO) cho phép đồng bộ với các IdP và quản lý nhóm ở cấp doanh nghiệp.
• Kết luận: ✅ Đáp án đúng, chính là công cụ được thiết kế để nhóm người dùng và cấp quyền.

3️⃣ Resource groups (Sai)

• Mô tả: Tính năng của AWS cho phép gộp các tài nguyên (EC2, RDS, S3, …) dựa trên tags hoặc tiêu chí để thực hiện quản lý, giám sát, hoặc tự động hoá.
• Vì sao không đúng: Resource groups tập trung vào tài nguyên, không phải người dùng. Chúng không có khả năng gán IAM policy cho người dùng hay nhóm người dùng.
• Kết luận: ❌ Không liên quan tới việc cấp quyền cho nhóm người dùng.

4️⃣ AWS Security Hub (Sai)

• Mô tả: Dịch vụ tổng hợp và chuẩn hoá các cảnh báo bảo mật (findings) từ nhiều nguồn (GuardDuty, Inspector, Macie, …) và cung cấp bảng điều khiển an ninh.
• Vì sao không đúng: Security Hub không quản lý danh tính hay quyền truy cập. Nó chỉ thu thập và hiển thị thông tin bảo mật; không cung cấp cơ chế tạo nhóm người dùng hay gán permission.
• Kết luận: ❌ Không đáp ứng yêu cầu.

📌 Tóm tắt nhanh

• 🟢 Đáp án đúng: AWS Identity and Access Management (IAM)
• 🔴 Các đáp án sai: Security groups, Resource groups, AWS Security Hub – vì chúng không cung cấp chức năng “tổ chức người dùng và cấp quyền theo nhóm”.

📚 Tham khảo

• AWS IAM Documentation (2026): https://docs.aws.amazon.com/iam/
• IAM Users, Groups, and Policies: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html
• AWS Security Groups Overview: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
• AWS Resource Groups: https://docs.aws.amazon.com/ARG/latest/userguide/welcome.html
• AWS Security Hub: https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html

🛠️ Lưu ý: Khi thiết kế kiến trúc IAM, nên tuân thủ nguyên tắc tối thiểu nhất (least privilege), sử dụng IAM Access Analyzer và Permission Boundaries để tránh cấp quyền dư thừa cho nhóm người dùng.

🔎 Phân tích câu hỏi
Công ty muốn xây dựng một ứng dụng chạy mã Python trên AWS Lambda.
Trong mô hình Shared Responsibility Model (mô hình trách nhiệm chia sẻ) của AWS, trách nhiệm được chia thành 2 phần:

• AWS chịu trách nhiệm về phần hạ tầng “đám mây” (các server, mạng, vật lý, hệ điều hành, runtime, …).
• Khách hàng chịu trách nhiệm về những gì họ đưa lên và cách họ cấu hình dịch vụ (mã nguồn, logic nghiệp vụ, quyền truy cập, cấu hình bảo mật, …).

Vì vậy, khi dùng Lambda, công ty phải:

1. Viết và duy trì code nghiệp vụ (business logic).
2. Định nghĩa IAM policies/roles để Lambda có quyền truy cập tới các tài nguyên cần thiết.

Các nhiệm vụ còn lại (quản lý hạ tầng, OS, cài đặt runtime) đều nằm trong phạm vi quản lý của AWS.

✅ Đáp án đúng (chọn 2)

• Writing the business logic code.
• Providing AWS Identity and Access Management (IAM) access to the Lambda service.

📚 Giải thích chi tiết từng phương án

1. Management of the underlying infrastructure.
   ❌ Sai – Hạ tầng vật lý, server, mạng, và các thành phần cơ sở của Lambda được AWS quản lý. Khách hàng không cần (và không thể) can thiệp vào EC2, storage, hoặc các thành phần cơ sở này khi sử dụng Lambda.

2. Management of the operating system.
   ❌ Sai – Hệ điều hành cho môi trường Lambda (Amazon Linux 2 hoặc Amazon Linux 2023) được AWS duy trì, cập nhật bản vá bảo mật và nâng cấp. Người dùng chỉ cần tập trung vào code và các dependency thông qua layer hoặc package.

3. Writing the business logic code.
   ✅ Đúng – Đây là trách nhiệm cốt lõi của khách hàng. Bạn phải viết, kiểm thử và triển khai hàm Lambda (Python, Node.js, Java, …). AWS không can thiệp vào nội dung logic nghiệp vụ.

4. Installation of the computer language runtime.
   ❌ Sai – Lambda cung cấp sẵn các runtime (Python 3.9, 3.10, 3.11, …) và các bản cập nhật được AWS thực hiện. Nếu cần thư viện bổ sung, bạn đưa chúng vào deployment package hoặc Lambda Layers, nhưng không tự “cài đặt” runtime.

5. Providing AWS Identity and Access Management (IAM) access to the Lambda service.
   ✅ Đúng – Khách hàng phải tạo IAM role cho hàm Lambda (ví dụ: AWSLambdaBasicExecutionRole) và gán các policy cho phép Lambda truy cập S3, DynamoDB, SNS, … hoặc cho phép người dùng/nhóm gọi hàm Lambda. Quản lý quyền IAM là trách nhiệm của khách hàng.

🛠️ Những lưu ý cập nhật tới năm 2026

• Runtime mới: Từ 2024, AWS đã ra mắt Python 3.12 runtime cho Lambda. Các runtime cũ vẫn được duy trì nhưng sẽ có end‑of‑support theo lịch trình AWS. Khách hàng cần theo dõi thông báo để cập nhật code khi runtime cũ ngừng hỗ trợ.
• Lambda Layers & Container Images: Để đưa các thư viện phụ thuộc hoặc runtime tùy chỉnh, khách hàng có thể sử dụng Layers hoặc container images. Việc này vẫn thuộc trách nhiệm của khách hàng (đóng gói, bảo trì, cập nhật).
• IAM Permissions Boundaries & Policy Simulator: AWS khuyến nghị sử dụng Permissions Boundaries và IAM Access Analyzer để giảm rủi ro over‑privileged. Đây là một phần mở rộng của trách nhiệm “cung cấp IAM access”.
• AWS Well‑Architected – Security Pillar: Khi cấu hình IAM cho Lambda, cần tuân thủ các best‑practice như least privilege, use of resource‑based policies, và enable Lambda insights để giám sát.

📖 Tham khảo

1. AWS Lambda – What you are responsible for (AWS Documentation, phiên bản 2026).
   https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro.html#lambda-responsibilities
2. AWS Shared Responsibility Model – Overview (2026).
   https://aws.amazon.com/compliance/shared-responsibility-model/
3. IAM best practices for Lambda – AWS Security Blog, 2025.
   https://aws.amazon.com/blogs/security/iam-best-practices-for-aws-lambda/
4. AWS Lambda Runtime Support Policy – 2024 update.
   https://aws.amazon.com/lambda/runtime-support-policy/

Tóm lại, trong mô hình chia sẻ trách nhiệm khi dùng AWS Lambda, công ty phải tự viết code nghiệp vụ và tự quản lý quyền IAM cho Lambda; các công việc liên quan tới hạ tầng, hệ điều hành và runtime đều do AWS chịu trách nhiệm. 🎉

🔎 Phân tích câu hỏi

A company needs to identify who accessed an AWS service and what action was performed for a given time period.

Câu hỏi yêu cầu một dịch vụ ghi lại (log) thông tin chi tiết về ai (identity) đã gọi (access) một dịch vụ AWS và hành động nào (API call) đã được thực hiện, trong khoảng thời gian nhất định. Đây là nhu cầu audit / compliance và truy vết (traceability).

AWS cung cấp một số dịch vụ có thể thu thập log, nhưng chỉ AWS CloudTrail chuyên thiết kế để lưu trữ event logs của API (cả management và data events) kèm identity người gọi, thời gian, nguồn IP, v.v.

✅ Đáp án đúng: AWS CloudTrail

• CloudTrail tự động ghi lại mọi API call tới hầu hết các dịch vụ AWS (Management Events) và có thể bật Data Events để ghi lại các hành động trên S3, Lambda, DynamoDB, …
• Log bao gồm UserName / Role ARN / Access Key, source IP, time stamp, request parameters, và response elements.
• Dữ liệu được lưu trữ trong S3, có thể query bằng Amazon Athena, CloudWatch Logs, hoặc EventBridge để phân tích trong một khoảng thời gian tùy ý.
• Từ 2023‑2026, CloudTrail còn hỗ trợ Trail Insights (phát hiện hoạt động bất thường) và Organization‑wide trails (đối với môi trường multi‑account), đáp ứng yêu cầu audit hiện đại.

Vì vậy, CloudTrail là dịch vụ duy nhất đáp ứng đầy đủ yêu cầu “xác định người truy cập và hành động thực hiện trong một khoảng thời gian”.

❌ Giải thích các phương án còn lại

• Amazon CloudWatch

  • 📊 CloudWatch chủ yếu là dịch vụ giám sát (metrics, dashboards, alarms) và log aggregation (CloudWatch Logs).
  • Mặc dù bạn có thể đưa log của CloudTrail vào CloudWatch Logs, CloudWatch không tự tạo log về ai đã gọi API; nó chỉ hiển thị dữ liệu đã được gửi vào.
  • Do vậy, CloudWatch không đáp ứng yêu cầu “identify who accessed” nếu không có nguồn log bên ngoài.

• AWS Security Hub

  • 🛡️ Security Hub là trung tâm tổng hợp các findings bảo mật từ các dịch vụ (GuardDuty, Inspector, Macie, …).
  • Nó không lưu trữ chi tiết các event API hoặc thông tin người dùng thực hiện hành động.
  • Nhiệm vụ của Security Hub là tổng hợp, chuẩn hoá, và ưu tiên các vấn đề bảo mật, không phải audit truy cập.

• Amazon Inspector

  • 🕵️‍♂️ Inspector là dịch vụ đánh giá bảo mật cho vulnerabilities và best‑practice trên EC2, container, và Lambda.
  • Nó không ghi lại ai đã gọi dịch vụ nào, mà chỉ cung cấp báo cáo lỗ hổng và recommendations.
  • Vì vậy, không phù hợp với yêu cầu truy vết hành động.

📚 Tham khảo (đến 2026)

1. AWS CloudTrail Documentation – “What is AWS CloudTrail?”
   https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html
2. AWS CloudTrail Insights – “Detect unusual activity in your AWS account”.
   https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-insights.html
3. AWS Organizations and CloudTrail – “Multi‑account trail management”.
   https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html
4. Amazon CloudWatch Documentation – “Monitoring and observability”.
   https://docs.aws.amazon.com/cloudwatch/
5. AWS Security Hub Documentation – “Security Hub overview”.
   https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html
6. Amazon Inspector Documentation – “Inspector Overview”.
   https://docs.aws.amazon.com/inspector/latest/user/inspector_introduction.html

🧩 Tóm tắt nhanh

• ✅ AWS CloudTrail – Ghi lại who và what cho mọi API call → đáp án đúng.
• ❌ Amazon CloudWatch – Giám sát, không tự tạo log truy cập.
• ❌ AWS Security Hub – Tổng hợp findings bảo mật, không chứa chi tiết audit.
• ❌ Amazon Inspector – Đánh giá lỗ hổng, không cung cấp audit truy cập.

Hy vọng phân tích này giúp bạn nắm vững lý do lựa chọn CloudTrail cho yêu cầu audit truy cập dịch vụ AWS. 🚀

🔎 Phân tích câu hỏi

Công ty muốn “sử dụng một dịch vụ AWS trung tâm để thực thi tuân thủ các tiêu chuẩn kinh doanh của tổ chức” và đồng thời “có thể quản lý và kiểm soát ai được phép triển khai, quản lý và hủy bỏ các tài nguyên AWS”.
Điều này yêu cầu một dịch vụ governance (quản trị) với khả năng:

• Định nghĩa danh mục (catalog) các dịch vụ, kiến trúc, mẫu CloudFormation đã được phê duyệt.
• Giao quyền (permissions) cho người dùng / nhóm thông qua IAM, AWS Organizations, hoặc Service Catalog permissions.
• Kiểm soát vòng đời tài nguyên (provision → update → retire) theo các quy tắc đã thiết lập.

✅ Dịch vụ đáp ứng yêu cầu: AWS Service Catalog.

✅ Đáp án đúng: AWS Service Catalog

Vì sao AWS Service Catalog là lựa chọn đúng? 🧩

1. Catalog & Portfolio – Cho phép tạo “catalog” các sản phẩm (AWS CloudFormation templates, AMI, SaaS, v.v.) mà tổ chức đã kiểm duyệt.
2. Kiểm soát quyền truy cập – Sử dụng IAM policies, Service Catalog permissions và integration với AWS Organizations để quyết định ai có thể provision, update, delete các sản phẩm.
3. Quản lý vòng đời – Hỗ trợ versioning, constraints (ví dụ: chỉ cho phép một số instance type, hoặc chỉ cho phép tag nhất định) giúp ngăn chặn việc triển khai tài nguyên không phù hợp.
4. Audit & compliance – Mọi hành động provision đều được ghi lại trong CloudTrail; các quy tắc tuân thủ có thể được tự động kiểm tra bằng AWS Config Rules hoặc AWS Control Tower.
5. Tích hợp – Có thể kết hợp với AWS Service Management (AWS Systems Manager) và AWS Control Tower để tạo môi trường “landing zone” tuân thủ.

❌ Giải thích các phương án còn lại

• Amazon CloudWatch

  • 📌 Mô tả: Dịch vụ giám sát và thu thập metrics, logs, alarm cho các tài nguyên AWS.
  • ❌ Lý do sai: CloudWatch chỉ cung cấp giám sát và cảnh báo, không có khả năng định nghĩa hoặc kiểm soát quyền triển khai tài nguyên. Nó không phải là công cụ governance hay compliance.

• Amazon GuardDuty

  • 📌 Mô tả: Dịch vụ phát hiện mối đe dọa dựa trên phân tích log (VPC Flow Logs, CloudTrail, DNS).
  • ❌ Lý do sai: GuardDuty tập trung vào phát hiện an ninh, không cho phép kiểm soát ai có thể tạo, thay đổi hay xóa tài nguyên. Nó không cung cấp catalog hoặc policy quản lý triển khai.

• AWS Security Hub

  • 📌 Mô tả: Trung tâm tổng hợp và chuẩn hoá các findings bảo mật từ nhiều dịch vụ (GuardDuty, Inspector, Macie, v.v.).
  • ❌ Lý do sai: Security Hub là trung tâm tổng hợp các kết quả bảo mật, giúp hiển thị trạng thái tuân thủ, nhưng không cung cấp cơ chế kiểm soát quyền triển khai hay cung cấp catalog các tài nguyên được phê duyệt.

📚 Tham khảo tài liệu (đến năm 2026)

1. AWS Service Catalog – User Guide (phiên bản 2026): https://docs.aws.amazon.com/servicecatalog/latest/dg/what-is.html
2. AWS Well‑Architected Framework – Security Pillar (2025): https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/intro.html
3. AWS Control Tower – Landing Zone (2026): https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html (đề cập tới việc tích hợp Service Catalog để enforce compliance).
4. AWS Blog – “New features in AWS Service Catalog 2025‑2026” (đăng 12/2025): https://aws.amazon.com/blogs/aws/aws-service-catalog-new-features/

🛠️ Kết luận: Đối với yêu cầu “định nghĩa, quản lý và kiểm soát việc triển khai tài nguyên” ở mức trung tâm, AWS Service Catalog là dịch vụ thích hợp nhất trong các lựa chọn được đưa ra. Các dịch vụ còn lại (CloudWatch, GuardDuty, Security Hub) chỉ đáp ứng các khía cạnh giám sát, phát hiện hoặc tổng hợp bảo mật, không cung cấp khả năng governance và control như yêu cầu.

🔍 Phân tích câu hỏi
Câu hỏi: “What does ‘security of the cloud’ refer to in the AWS shared responsibility model?”

Trong mô hình Shared Responsibility của AWS, trách nhiệm an ninh được chia làm hai phần chính:

1. Security of the Cloud – AWS chịu trách nhiệm bảo vệ hạ tầng nền tảng (các data center, mạng, phần cứng, phần mềm cơ sở hạ tầng, các dịch vụ AWS).
2. Security in the Cloud – Khách hàng chịu trách nhiệm bảo vệ các tài nguyên, dữ liệu, cấu hình và ứng dụng mà họ triển khai trên AWS.

Câu hỏi đang hỏi “security of the cloud” – đây là phần mà AWS chịu trách nhiệm, không phải khách hàng.

✅ Đáp án đúng

[ĐÚNG] Security of the cloud infrastructure that runs all the AWS services

• Đây là mô tả chính xác nhất của “security of the cloud” trong mô hình chia sẻ trách nhiệm. AWS bảo vệ hạ tầng vật lý, mạng, máy chủ, hệ điều hành cơ sở, và các dịch vụ quản lý (ví dụ: bảo mật vật lý tại các data center, bảo mật mạng nội bộ, cập nhật bản vá cho phần mềm hệ thống, v.v.).
• Năm 2024‑2026, AWS tiếp tục mở rộng các chương trình AWS Nitro System, AWS Nitro Enclaves, và AWS Supply Chain Security để củng cố bảo mật hạ tầng. Tất cả những yếu tố này nằm trong “security of the cloud”.

❌ Giải thích các phương án sai

• [SAI] Availability of AWS services such as Amazon EC2

  • Giải thích: “Availability” (khả năng sẵn sàng) là một phần của Service Level Agreement (SLA) và operational resilience mà AWS cam kết, nhưng không phải là “security”. Độ sẵn sàng đo lường khả năng dịch vụ hoạt động liên tục, không liên quan trực tiếp tới các biện pháp bảo mật (ví dụ: firewall, patching). Vì vậy, đây không phải là định nghĩa của “security of the cloud”.

• [SAI] Implementation of password policies for IAM users

  • Giải thích: Việc thiết lập password policy là trách nhiệm của khách hàng (Security in the Cloud). AWS cung cấp tính năng IAM, nhưng khách hàng phải quyết định và cấu hình các chính sách mật khẩu, MFA, và các biện pháp truy cập. Do đó, mục này không thuộc “security of the cloud”.

• [SAI] Security of customer environments by using AWS Network Firewall partners

  • Giải thích: Đây là ví dụ về Security in the Cloud – khách hàng tự triển khai các giải pháp bảo mật (ví dụ: AWS Network Firewall hoặc các đối tác bên thứ ba) để bảo vệ môi trường của mình. AWS chỉ cung cấp nền tảng và dịch vụ, còn việc cấu hình, quản lý và vận hành firewall thuộc trách nhiệm của khách hàng.

📚 Tham khảo nguồn tài liệu (cập nhật tới 2026)

1. AWS Documentation – Security – Shared Responsibility Model
   • https://docs.aws.amazon.com/whitepapers/latest/aws-security-best-practices/shared-responsibility-model.html
2. AWS Well‑Architected Framework – Security Pillar (2025 revision)
   • https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/intro.html
3. AWS Nitro System Overview (2024‑2026 updates)
   • https://aws.amazon.com/ec2/nitro/
4. AWS Blog – “Continuously strengthening the security of our global infrastructure” (2025)
   • https://aws.amazon.com/blogs/security/strengthening-aws-infrastructure-security/

🧩 Tóm tắt nhanh

• Security of the cloud = AWS bảo vệ hạ tầng nền tảng (data center, mạng, phần cứng, phần mềm hệ thống).
• Các lựa chọn còn lại (availability, IAM password policies, firewall partners) đều thuộc Security in the Cloud hoặc các khía cạnh không liên quan tới bảo mật hạ tầng.

Vậy đáp án duy nhất đúng là “Security of the cloud infrastructure that runs all the AWS services”. 🎉

🔎 Phân tích câu hỏi
Công ty có một ứng dụng tạo ra dữ liệu không có cấu trúc (unstructured data) liên tục. Yêu cầu:

1. Lưu trữ bền vững (durable) – dữ liệu phải được sao lưu, khả năng chịu lỗi cao, không mất mát.
2. Dễ dàng truy vấn (easy to query) – người dùng cần có cách nhanh chóng, linh hoạt để lấy dữ liệu mà không phải viết mã phức tạp hay di chuyển dữ liệu sang hệ thống khác.

Câu hỏi muốn chúng ta lựa chọn dịch vụ AWS đáp ứng cả hai tiêu chí trên cho dữ liệu phi cấu trúc (ví dụ: log, JSON, file văn bản, ảnh, video,…).

✅ Đáp án đúng: Amazon DynamoDB

Lý do chọn:

• DynamoDB là dịch vụ NoSQL key‑value và document được quản lý hoàn toàn, cung cấp độ bền 99.999999999% (11 nines) trong nhiều vùng AZ, nên đáp ứng tiêu chí “durable”.
• Nó hỗ trợ lưu trữ dữ liệu phi cấu trúc (JSON, binary, string, list, map…) mà không cần schema cố định.
• Truy vấn:
  • Primary key và secondary indexes (GSI/LSI) cho phép tìm kiếm nhanh theo giá trị bất kỳ.
  • PartiQL (được giới thiệu 2020, vẫn còn mạnh mẽ tới 2026) cho phép viết câu lệnh SQL‑like trên dữ liệu DynamoDB, giúp người dùng “dễ dàng truy vấn” hơn so với việc phải viết code SDK.
• Scalability: DynamoDB tự động mở rộng throughput và lưu trữ, phù hợp với khối lượng dữ liệu “liên tục” và không giới hạn về kích thước bảng.
• Tích hợp: Có thể kết hợp với AWS Lambda, Kinesis Data Streams, Amazon S3 để ingest dữ liệu liên tục và DynamoDB Streams để đồng bộ ra các hệ thống phân tích nếu cần.

Vì vậy, trong 4 lựa chọn được đưa ra, Amazon DynamoDB là dịch vụ duy nhất vừa đáp ứng độ bền, vừa hỗ trợ truy vấn dữ liệu phi cấu trúc một cách linh hoạt.

🧩 Giải thích các phương án khác

• [SAI] Amazon RDS

  • RDS là dịch vụ Cơ sở dữ liệu quan hệ (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB). Nó yêu cầu schema cố định, không phù hợp cho dữ liệu không có cấu trúc.
  • Mặc dù RDS cung cấp độ bền cao (Multi‑AZ), việc lưu trữ và truy vấn dữ liệu phi cấu trúc sẽ gặp khó khăn, cần chuyển đổi sang dạng bảng hoặc dùng kiểu dữ liệu JSON/XML nhưng vẫn giới hạn so với NoSQL.
  • Do đó không phải là lựa chọn tối ưu cho yêu cầu “unstructured data”.

• [SAI] Amazon Aurora

  • Aurora là phiên bản cải tiến của MySQL/PostgreSQL được tối ưu cho hiệu năng và độ bền. Tương tự RDS, nó là cơ sở dữ liệu quan hệ và yêu cầu schema.
  • Mặc dù Aurora Serverless v2 hỗ trợ tự động scaling, nó vẫn không thích hợp cho dữ liệu phi cấu trúc liên tục mà không có mô hình quan hệ rõ ràng.
  • Vì vậy không đáp ứng nhu cầu của câu hỏi.

• [SAI] Amazon QuickSight

  • QuickSight là dịch vụ Business Intelligence / Visualization, không phải là nơi lưu trữ dữ liệu. Nó kết nối tới các nguồn dữ liệu (S3, Redshift, RDS, Athena…) để tạo báo cáo và dashboard.
  • Do không cung cấp khả năng lưu trữ hay độ bền cho dữ liệu, nên không thể đáp ứng yêu cầu của câu hỏi.

📚 Tham khảo tài liệu (2026)

1. Amazon DynamoDB – Documentation (được cập nhật liên tục, phiên bản 2026):
   • https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WhatIsDynamoDB.html
2. DynamoDB Durability and Availability – AWS Well‑Architected Framework (2025 edition).
   • https://d1.awsstatic.com/whitepapers/architecture/AWS_Well-Architected_Framework.pdf
3. PartiQL for DynamoDB – Giới thiệu và hướng dẫn sử dụng (2023‑2026).
   • https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PartiQL.html
4. AWS RDS vs DynamoDB – Choosing the Right Database – AWS Blog (2024).
   • https://aws.amazon.com/blogs/database/rds-vs-dynamodb/

Tóm tắt:
✅ Amazon DynamoDB là đáp án đúng vì nó cung cấp độ bền cao, hỗ trợ lưu trữ dữ liệu phi cấu trúc và cho phép truy vấn linh hoạt thông qua key, index và PartiQL. Các dịch vụ còn lại (RDS, Aurora, QuickSight) không đáp ứng đồng thời cả hai yêu cầu “durable” và “easy to query” cho dữ liệu không có cấu trúc. 🚀

🔎 Phân tích câu hỏi
Câu hỏi: “Which options are AWS Cloud Adoption Framework (AWS CAF) perspectives? (Choose two.)”
AWS CAF được thiết kế để giúp các tổ chức hiểu và lập kế hoạch chuyển đổi sang đám mây một cách toàn diện. Nó gồm sáu góc nhìn (perspectives), mỗi góc nhìn mô tả một nhóm năng lực và quy trình cần chuẩn bị:

1. Business
2. People
3. Governance
4. Platform
5. Security
6. Operations

Do vậy, khi hỏi “đâu là các perspective của AWS CAF”, chúng ta chỉ cần chọn các mục nằm trong danh sách trên.

✅ Đáp án đúng

• Security
• Business

Giải thích vì sao Security và Business là đáp án đúng

• Security 📌: Là một trong sáu perspective chính của AWS CAF. Nó tập trung vào việc xây dựng mô hình bảo mật, quản lý rủi ro, tuân thủ quy chuẩn và bảo vệ dữ liệu trên môi trường AWS.
• Business 📌: Cũng là một perspective quan trọng, giúp liên kết mục tiêu kinh doanh với chiến lược đám mây, đo lường lợi ích tài chính và định hình các KPI cho dự án chuyển đổi.

❌ Giải thích các phương án sai

• Cloud fluency

  • Giải thích: “Cloud fluency” không phải là một perspective trong AWS CAF. Đây là một kỹ năng / năng lực mà cá nhân và tổ chức cần đạt được để hiểu và sử dụng dịch vụ đám mây một cách hiệu quả. Nó thường được nhắc đến trong phần “People” (kỹ năng con người), nhưng không phải một perspective độc lập.

• Change acceleration

  • Giải thích: “Change acceleration” không xuất hiện trong danh sách sáu perspective của AWS CAF. Thuật ngữ này thường liên quan tới phương pháp quản lý thay đổi (change management) trong quá trình chuyển đổi, nhưng nó nằm dưới góc nhìn People hoặc Governance, chứ không phải một perspective riêng.

• Architecture

  • Giải thích: “Architecture” không phải là perspective của AWS CAF. Thiết kế kiến trúc (architecture) được bao phủ trong perspective Platform và Security, nhưng không tồn tại như một perspective độc lập trong khung CAF.

🛠️ Kiến thức cập nhật đến năm 2026

• Tính đến 2026, AWS vẫn duy trì cấu trúc sáu perspective trên (Business, People, Governance, Platform, Security, Operations) trong tài liệu AWS Cloud Adoption Framework (phiên bản mới nhất: v3.2 – November 2025).
• Các thuật ngữ như “Cloud fluency” và “Change acceleration” được dùng trong các bài học đào tạo và AWS Well‑Architected Lens, nhưng chúng không được liệt kê là perspective của CAF.

📚 Tham khảo

• AWS Cloud Adoption Framework (CAF) – Official Whitepaper, phiên bản mới nhất (v3.2, 2025).
• AWS Documentation – Cloud Adoption Framework, mục “CAF Perspectives”.
• AWS Well‑Architected Framework, phần “Operational Excellence” và “Security” (để hiểu mối quan hệ giữa perspective và các lĩnh vực chuyên môn).

Tóm lại: Trong các lựa chọn được đưa ra, chỉ có Security và Business là hai perspective hợp lệ của AWS CAF. Các mục còn lại (Cloud fluency, Change acceleration, Architecture) là các khái niệm liên quan nhưng không phải perspective trong mô hình CAF. 🚀

🔎 Phân tích câu hỏi

Công ty muốn chuyển cơ sở hạ tầng container hiện đang chạy trên máy chủ tại chỗ (on‑premises) lên AWS Cloud. Yêu cầu quan trọng:

1. Ngăn ngừa chi phí quản trị và vận hành không dự đoán được → cần một dịch vụ “serverless”, nơi AWS tự động quản lý tài nguyên, scaling, patching, …
2. Áp dụng kiến trúc serverless cho các container → không cần quản lý máy ảo, cluster, node.

Vậy câu hỏi đang hỏi: dịch vụ AWS nào cho phép chạy container mà không cần quản lý máy chủ, đồng thời giảm thiểu chi phí vận hành không mong muốn?

✅ Đáp án đúng: AWS Fargate

• AWS Fargate là dịch vụ compute “serverless” cho Amazon ECS và Amazon EKS.
• Khi sử dụng Fargate, bạn chỉ định CPU và memory cho mỗi task/pod; AWS tự động provisioning, scaling, patching và quản lý underlying EC2 instances.
• Không cần provision, configure, hoặc quản lý cluster EC2 → giảm chi phí hành chính và vận hành không dự đoán.
• Bạn trả tiền theo giây dựa trên tài nguyên thực tế được sử dụng, giúp tránh chi phí thừa.
• Đáp ứng yêu cầu “migrate container workloads” và “adopt serverless architecture”.

Nguồn: AWS Documentation – AWS Fargate (https://docs.aws.amazon.com/fargate/latest/userguide/what-is-fargate.html) – cập nhật tới 2026, bao gồm tính năng Fargate Spot, resource auto‑scaling, và per‑second billing.

🧩 Giải thích các phương án (giữ nguyên nội dung tiếng Anh)

- [SAI] Amazon Connect

• ❌ Lý do sai: Amazon Connect là dịch vụ contact‑center (call center) dựa trên đám mây, cung cấp giao diện thoại, chatbot, và phân tích tương tác khách hàng. Nó không phải là nền tảng để chạy container, vì vậy không đáp ứng yêu cầu di chuyển workload container hay kiến trúc serverless cho container.

- [ĐÚNG] AWS Fargate

• ✅ Lý do đúng: Như đã phân tích ở trên, Fargate cho phép chạy container không cần quản lý máy chủ, tự động scaling và tính phí dựa trên việc sử dụng thực tế – hoàn toàn phù hợp với mục tiêu “ngăn ngừa chi phí vận hành không dự đoán” và “serverless”.

- [SAI] Amazon Lightsail

• ❌ Lý do sai: Lightsail cung cấp máy ảo, container service, và database đơn giản, nhưng vẫn dựa trên instance (máy ảo) được quản lý bởi người dùng. Khi dùng Lightsail Container Service, bạn vẫn phải định nghĩa và quản lý node (mặc dù có auto‑scale, nhưng vẫn là một lớp máy ảo). Do vậy, không thực sự “serverless” và không loại bỏ chi phí quản trị như yêu cầu.

- [SAI] Amazon EC2

• ❌ Lý do sai: EC2 là dịch vụ máy ảo truyền thống. Để chạy container trên EC2, bạn cần cài đặt, cấu hình, patch, và quản lý các instance, cluster, và scaling. Điều này tạo ra chi phí quản trị và vận hành không dự đoán được, trái ngược với yêu cầu “serverless”.

📌 Kết luận

• AWS Fargate là lựa chọn duy nhất đáp ứng đầy đủ các tiêu chí: chuyển đổi container, loại bỏ quản trị hạ tầng, và hoạt động theo mô hình serverless.
• Các dịch vụ còn lại (Amazon Connect, Lightsail, EC2) không phục vụ mục đích chạy container theo cách serverless và do đó không phù hợp.

🔗 Tham khảo

1. AWS Documentation – What Is AWS Fargate? (phiên bản 2026).
2. AWS Blog – “Serverless Containers with AWS Fargate” (cập nhật tính năng Fargate Spot, per‑second billing).
3. AWS Well‑Architected Framework – Cost Optimisation Pillar (giải thích cách giảm chi phí không dự đoán bằng các dịch vụ serverless).

📖 Phân tích câu hỏi

Công ty muốn các Amazon EC2 instances được đặt ở các vị trí khác nhau nhưng vẫn cùng trong một khu vực địa lý (same geographic area).
Ngoài ra, công ty muốn:

• Sử dụng nhiều lưới điện (power grids) độc lập – tức là các trung tâm dữ liệu (data center) được cung cấp điện từ các nguồn riêng biệt, để giảm thiểu nguy cơ mất điện toàn bộ.
• Sử dụng các kết nối mạng độc lập – các mạng nội bộ và đường truyền mạng được tách biệt, giúp tăng tính chịu lỗi (fault‑tolerance) và khả năng chịu sự cố mạng.

Trong AWS, những tiêu chí này mô tả Availability Zones (AZs):

• Mỗi AZ là một cụm data center độc lập về nguồn điện, làm mát và mạng, nhưng nằm trong cùng một Region (vùng địa lý).
• Các AZ được thiết kế để có độ trễ thấp khi giao tiếp với nhau, cho phép triển khai các kiến trúc đa AZ nhằm đạt tính sẵn sàng cao và khả năng chịu lỗi.

Do đó, đáp án đúng phải là “Use EC2 instances in multiple Availability Zones in the same AWS Region.”

✅ Đáp án đúng

[ĐÚNG] Use EC2 instances in multiple Availability Zones in the same AWS Region.

Giải thích:

• AZs cung cấp điện độc lập và kết nối mạng riêng biệt.
• Các AZ đều thuộc cùng một Region, nên các instance vẫn “cùng trong một khu vực địa lý”.
• Khi triển khai EC2 trên nhiều AZ, bạn đạt được high availability, fault tolerance, và low‑latency inter‑AZ traffic (độ trễ thấp giữa các AZ).

Tham khảo:

• AWS Documentation – “Regions and Availability Zones” (https://docs.aws.amazon.com/general/latest/gr/rande.html)
• AWS Well‑Architected Framework – “Reliability Pillar” (https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/overview.html)

❌ Giải thích các phương án sai

• [SAI] Use EC2 instances in multiple edge locations in the same AWS Region.
  Edge locations là các điểm hiện diện của Amazon CloudFront và AWS Global Accelerator; chúng không phải là nơi bạn có thể khởi chạy EC2 instances. Edge locations chỉ phục vụ việc cache nội dung và giảm độ trễ cho người dùng cuối, không cung cấp hạ tầng điện và mạng độc lập như AZ.

• [SAI] Use EC2 instances in multiple Amazon Connect locations in the same AWS Region.
  Amazon Connect là dịch vụ contact‑center (trung tâm cuộc gọi). “Connect locations” là các điểm triển khai cho trung tâm cuộc gọi, không phải là môi trường tính toán để chạy EC2. Do đó, không đáp ứng yêu cầu về việc đặt EC2 ở các vị trí khác nhau.

• [SAI] Use EC2 instances in multiple AWS Artifact locations in the same AWS Region.
  AWS Artifact là cổng thông tin tài liệu tuân thủ và an ninh, không có “locations” thực tế để triển khai tài nguyên tính toán. Vì vậy, không thể dùng Artifact để đặt EC2.

🧩 Tóm tắt các điểm quan trọng

• Availability Zone (AZ) = Data center độc lập (điện, làm mát, mạng) → đáp ứng yêu cầu “multiple power grids and independent networking”.
• Region = Khu vực địa lý (ví dụ: us-east-1, ap-southeast-2). Các AZ trong cùng Region vẫn “cùng khu vực địa lý”.
• Edge location, Amazon Connect location, AWS Artifact location → không phải là nơi chạy EC2, vì vậy không phù hợp.

🔧 Lời khuyên thực tiễn (2026)

Khi thiết kế kiến trúc đa AZ cho EC2:

1. Sử dụng Auto Scaling Group với subnet ở mỗi AZ để tự động cân bằng tải.
2. Kích hoạt Elastic Load Balancer (ELB) kiểu Application Load Balancer (ALB) hoặc Network Load Balancer (NLB) để phân phối lưu lượng giữa các AZ.
3. Kích hoạt Multi‑AZ RDS hoặc Aurora để đồng bộ dữ liệu.
4. Sử dụng VPC peering hoặc Transit Gateway nếu cần kết nối giữa VPC trong các AZ khác nhau.

Những biện pháp này giúp tận dụng tối đa tính năng độc lập về điện và mạng của AZ, đồng thời duy trì độ trễ thấp và khả năng chịu lỗi.

📚 Tham khảo bổ sung (2026)

• “AWS Global Infrastructure – Regions, Availability Zones, and Edge Locations” (https://aws.amazon.com/about-aws/global-infrastructure/)
• “Best Practices for Designing Multi‑AZ Deployments” – AWS Architecture Blog (2025)
• “Amazon EC2 User Guide – Placement Groups” (đối với nhu cầu kiểm soát vị trí chi tiết hơn).

🔎 Phân tích câu hỏi

Công ty thương mại điện tử đã triển khai một ứng dụng web trên Amazon EC2 và muốn phân phối đều lưu lượng HTTP tới tất cả các instance đang chạy.
Yêu cầu chính:

1. Lưu lượng HTTP (layer 7) → cần có khả năng hiểu và xử lý các header, cookie, URL path, …
2. Phân phối cân bằng (evenly) → cần một cơ chế “round‑robin”, “least‑connections” hoặc dựa trên trọng số.
3. Áp dụng cho các EC2 đang chạy → không yêu cầu tự động tạo hay xóa instance, chỉ cần “điểm cuối” (endpoint) để các client gửi yêu cầu.

Vì vậy câu hỏi đang hỏi dịch vụ hoặc tài nguyên nào của AWS đáp ứng nhu cầu cân bằng tải HTTP cho các EC2.

✅ Đáp án đúng

Application Load Balancer

• Là Elastic Load Balancing (ELB) loại layer 7 (HTTP/HTTPS).
• Hỗ trợ routing dựa trên URL, host header, cookie, query string và có sticky sessions nếu cần.
• Thực hiện phân phối lưu lượng đều (round‑robin mặc định, hoặc dựa trên trọng số khi dùng target groups).
• Có thể đăng ký (register) các EC2 instance (hoặc IP) vào target groups và tự động kiểm tra (health check) để chỉ gửi traffic tới các instance khỏe mạnh.
• Tích hợp sẵn với Auto Scaling (nếu muốn mở rộng/thu hẹp tự động) nhưng không bắt buộc.

Do đó Application Load Balancer là dịch vụ đáp ứng đúng yêu cầu “phân phối đều lưu lượng HTTP tới các EC2”.

❌ Giải thích các phương án sai

• Amazon EC2 Auto Scaling

  • Mô tả: Dịch vụ tự động tạo, xóa, và thay đổi quy mô các EC2 instance dựa trên các metric (CPU, network, …).
  • Tại sao không đáp ứng: Auto Scaling không thực hiện cân bằng tải; nó chỉ quản lý số lượng instance. Để phân phối lưu lượng, bạn vẫn cần một Load Balancer (ALB, NLB, …) hoặc DNS round‑robin. Vì câu hỏi chỉ yêu cầu “phân phối đều lưu lượng HTTP”, Auto Scaling không phải là đáp án đúng.

• Gateway Load Balancer

  • Mô tả: Dịch vụ layer 3/4 được thiết kế để triển khai appliance mạng (ví dụ: firewall, IDS/IPS) ở dạng “transparent” và cho phép traffic forwarding tới các appliance.
  • Tại sao không đáp ứng: GWLB không phân tích HTTP ở layer 7, không hỗ trợ routing dựa trên URL hay host header, và mục tiêu chính là đưa traffic tới các network appliances, không phải tới các EC2 web server.

• Network Load Balancer

  • Mô tả: Load balancer layer 4 (TCP, UDP) với khả năng xử lý hàng triệu kết nối/giây, thích hợp cho các ứng dụng yêu cầu độ trễ cực thấp.
  • Tại sao không đáp ứng: Mặc dù NLB có thể cân bằng traffic tới EC2, nó không hiểu HTTP; không hỗ trợ các tính năng như host‑based routing, path‑based routing, hoặc cookie‑based stickiness. Khi yêu cầu là “HTTP”, ALB (layer 7) luôn là lựa chọn ưu tiên.

🛠️ Khi nào có thể dùng các dịch vụ khác (thêm kiến thức bổ trợ)

📚 Tham khảo tài liệu (đến năm 2026)

1. AWS Elastic Load Balancing – Application Load Balancer – AWS Documentation, phiên bản cập nhật 2026.
   https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html
2. Amazon EC2 Auto Scaling – AWS Documentation, 2026.
   https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html
3. Gateway Load Balancer – AWS Documentation, 2026.
   https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html
4. Network Load Balancer – AWS Documentation, 2026.
   https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html

🧩 Tóm tắt nhanh

• ✅ Đáp án đúng: Application Load Balancer – vì nó là load balancer layer 7 chuyên xử lý HTTP/HTTPS và có cơ chế phân phối cân bằng.
• ❌ Các đáp án còn lại chỉ đáp ứng một phần nhu cầu (quản lý quy mô, layer 4, hoặc cho appliance) và không phù hợp với yêu cầu “phân phối đều lưu lượng HTTP”.

Hy vọng phân tích trên giúp bạn nắm rõ lý do lựa chọn đúng và hiểu được sự khác nhau giữa các dịch vụ cân bằng tải của AWS! 🚀