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

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

Câu hỏi yêu cầu xác định hai capability (khả năng) thuộc phần “Platform” trong AWS Cloud Adoption Framework (AWS CAF).
AWS CAF chia hành trình chuyển đổi sang đám mây thành 6 perspectives (góc nhìn) : Business, People, Governance, Platform, Security, Operations. Mỗi perspective chứa một tập các capability giúp các tổ chức đánh giá và lập kế hoạch chuyển đổi.

Trong Platform perspective, các capability tập trung vào việc xây dựng, vận hành và tối ưu hoá nền tảng công nghệ (hạ tầng, môi trường runtime, pipeline CI/CD, giám sát, quản lý hiệu năng,…).

✅ Đáp án đúng

• Performance and capacity management
• Continuous integration and continuous delivery (CI/CD)

🟢 Lý do: Cả hai capability này đều nằm trong Platform perspective của AWS CAF.

• Performance and capacity management: Giúp tổ chức đo lường, dự báo và tối ưu tài nguyên để đáp ứng khối lượng công việc. Đây là một trong các capability cốt lõi của Platform perspective.
• Continuous integration and continuous delivery (CI/CD): Định nghĩa quy trình tự động hoá xây dựng, kiểm thử và triển khai phần mềm – một phần quan trọng của nền tảng hiện đại và cũng được xếp vào Platform perspective.

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

• Data engineering

  • 🛑 Sai: Đây là capability thuộc Data perspective (cũng có thể gọi là “Data & Analytics” perspective) trong AWS CAF, không phải Platform. Data engineering tập trung vào việc thu thập, xử lý và chuyển đổi dữ liệu, chứ không phải vào việc xây dựng nền tảng hạ tầng.

• Infrastructure protection

  • 🛑 Sai: Đây là capability của Security perspective. Nó liên quan đến việc bảo vệ tài nguyên (ví dụ: IAM, encryption, network security) chứ không phải các hoạt động nền tảng như triển khai hay tối ưu hoá.

• Change and release management

  • 🛑 Sai: Mặc dù có liên quan tới quy trình triển khai, Change and release management được xếp vào Operations perspective. Nó tập trung vào việc quản lý các thay đổi vận hành, triển khai và hỗ trợ sau khi đưa vào sản xuất, không phải là một capability nền tảng theo định nghĩa của AWS CAF.

📚 Tham khảo nguồn

• AWS Cloud Adoption Framework (CAF) – Platform Perspective (AWS Documentation, cập nhật tới 2024/2025).
  Link: https://docs.aws.amazon.com/whitepapers/latest/aws-cloud-adoption-framework/overview.html#platform-perspective
• AWS CAF v2 – Capability Matrix (được cập nhật thường xuyên, phiên bản 2024).
  Link: https://d1.awsstatic.com/CAF/AWS_Cloud_Adoption_Framework_v2.pdf

📝 Tóm tắt nhanh

• ✅ Performance and capacity management → Platform perspective.
• ✅ Continuous integration and continuous delivery (CI/CD) → Platform perspective.
• ❌ Data engineering → Data perspective.
• ❌ Infrastructure protection → Security perspective.
• ❌ Change and release management → Operations perspective.

Hy vọng phân tích trên giúp bạn nắm rõ cách phân loại các capability trong AWS CAF! 🚀

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

According to the AWS shared responsibility model, the customer is responsible for applying the latest security updates and patches for which of the following?

Câu hỏi đang kiểm tra hiểu biết của bạn về Mô hình Trách nhiệm chia sẻ (Shared Responsibility Model) của AWS – ai (AWS hay khách hàng) chịu trách nhiệm gì về bảo mật và việc cập nhật/patch.

Trong mô hình này:

• AWS chịu trách nhiệm “Security of the Cloud” → hạ tầng vật lý, mạng, thiết bị, các dịch vụ managed (ví dụ RDS, DynamoDB, S3…) được AWS vận hành và cập nhật.
• Khách hàng chịu trách nhiệm “Security in the Cloud” → hệ điều hành, phần mềm ứng dụng, cấu hình, và các bản vá, cập nhật bảo mật cho những thành phần mà khách hàng tự quản lý (ví dụ EC2, on‑premise, container, Lambda code, …).

Vì vậy, câu hỏi muốn bạn chọn dịch vụ mà khách hàng phải tự áp dụng các bản vá bảo mật.

✅ Đáp án đúng

✔️ Amazon EC2 instances

• Lý do: EC2 là dịch vụ Infrastructure as a Service (IaaS). Khi bạn khởi tạo một instance, bạn được cung cấp hệ điều hành và điều khiển toàn bộ stack phần mềm trên máy ảo đó. Do đó, khách hàng phải tự cập nhật, vá lỗi hệ điều hành, các package, driver, và bất kỳ phần mềm nào được cài đặt trên instance. AWS chỉ cung cấp các bản vá cho hypervisor và phần hạ tầng vật lý, không can thiệp vào hệ điều hành bên trong EC2.

❌ Các phương án sai và giải thích

• Amazon DynamoDB

  • DynamoDB là dịch vụ fully managed NoSQL database (PaaS). AWS chịu trách nhiệm toàn bộ việc vận hành, cập nhật phần mềm, vá lỗi, và bảo mật cho các node backend. Khách hàng chỉ cần quan tâm tới cấu hình (ví dụ: encryption, IAM policies) và độ an toàn dữ liệu, không phải cập nhật bản vá.

• Amazon RDS instances

  • RDS là dịch vụ managed relational database. Mặc dù người dùng tạo “instance”, nhưng điều hành hệ quản trị cơ sở dữ liệu (MySQL, PostgreSQL, Oracle, …) và hệ điều hành nền được AWS quản lý. AWS tự động áp dụng các bản vá bảo mật thông qua RDS Maintenance Windows. Khách hàng chỉ cần kích hoạt tự động cập nhật hoặc lên kế hoạch bảo trì, không tự “apply patches”.

• Amazon S3

  • S3 là dịch vụ object storage (fully managed). AWS kiểm soát toàn bộ phần mềm và hạ tầng lưu trữ. Người dùng không có bất kỳ thành phần nào cần vá. Trách nhiệm của khách hàng chỉ là định cấu hình quyền truy cập, bucket policies, encryption, versioning, v.v.

📌 Những điểm quan trọng cần nhớ (đến 2026)

1. Mức độ quản lý dịch vụ

   • IaaS (EC2, EKS nodes, Elastic Beanstalk môi trường EC2) → Khách hàng tự vá.
   • PaaS (RDS, DynamoDB, Lambda, Elastic Beanstalk môi trường managed, API Gateway) → AWS tự cập nhật.

2. Các tính năng hỗ trợ tự động cập nhật

   • EC2 Systems Manager (SSM) Patch Manager giúp tự động triển khai patch cho EC2.
   • AWS Inspector và Amazon GuardDuty cung cấp gợi ý về lỗ hổng, nhưng việc áp dụng patch vẫn do khách hàng thực hiện.

3. Bản vá bảo mật trong môi trường hybrid

   • Khi EC2 kết nối tới on‑premise qua Direct Connect hoặc VPN, khách hàng vẫn phải duy trì đồng nhất các bản vá cho cả hai môi trường.

📚 Tham khảo (đến năm 2026)

• AWS Documentation – Security Responsibility Model (https://docs.aws.amazon.com/general/latest/gr/aws-security.html) – cập nhật 2024, vẫn còn chính xác vào 2026.
• AWS Well‑Architected Framework – Security Pillar (2023 revision) – mô tả chi tiết trách nhiệm cập nhật/patch cho các dịch vụ IaaS vs. PaaS.
• Amazon EC2 User Guide – Patching Instances (phiên bản 2025) – hướng dẫn sử dụng SSM Patch Manager.
• AWS Blog – “Shared Responsibility Model – 2025 Update” – nhấn mạnh việc khách hàng phải tự quản lý bản vá cho EC2, các node EKS và các workload tự quản.

🔚 Kết luận:
Trong mô hình chia sẻ trách nhiệm, khách hàng chịu trách nhiệm áp dụng các bản vá bảo mật cho Amazon EC2 instances. Các dịch vụ khác được liệt kê (DynamoDB, RDS, S3) là các dịch vụ managed mà AWS tự thực hiện cập nhật và vá lỗi, vì vậy chúng không phải là đáp án đúng.

🔎 Giải thích nội dung câu hỏi
Câu hỏi hỏi: “Which Amazon S3 storage class is MOST cost‑effective for unknown access patterns?”
Nghĩa là khi chúng ta không biết trước tần suất truy cập (có thể là thường, ít, hoặc thậm chí không truy cập) thì nên chọn lớp lưu trữ S3 nào để tối ưu chi phí tổng thể (bao gồm chi phí lưu trữ, phí truy xuất và phí chuyển lớp).

✅ Đáp án đúng: S3 Intelligent‑Tiering

Lý do lựa chọn:

• Tự động chuyển lớp: Intelligent‑Tiering theo dõi mức độ truy cập của từng đối tượng và tự động di chuyển chúng giữa hai tầng chính – Frequent Access tier và Infrequent Access tier – mà không cần cấu hình hay dự đoán trước.
• Không phí chuyển lớp: Từ năm 2023 AWS đã loại bỏ phí chuyển lớp giữa các tier trong Intelligent‑Tiering (chỉ còn phí lưu trữ và phí truy xuất tương ứng với tier hiện tại).
• Phí giám sát thấp: Phí giám sát (monitoring) chỉ $0.0025/1,000 objects mỗi tháng, rất nhỏ so với lợi ích giảm chi phí lưu trữ khi đối tượng không được truy cập thường xuyên.
• Chi phí tổng thể thấp nhất khi không biết pattern: Vì lớp này tự động tối ưu, nếu đối tượng thực sự ít truy cập thì chi phí sẽ giảm tới ~ 30‑40 % so với Standard‑IA, còn nếu đối tượng truy cập thường thì chi phí gần tương đương Standard. Do đó, đối với unknown access patterns, Intelligent‑Tiering là lựa chọn tiết kiệm nhất.

🧩 Phân tích các phương án

1. S3 Standard

• Miêu tả: Lớp lưu trữ mặc định, thiết kế cho dữ liệu truy cập thường xuyên với độ bền 99.999999999 % và thời gian phản hồi nhanh.
• Chi phí: Cao nhất trong các lớp “tần suất truy cập” vì phí lưu trữ cao hơn Standard‑IA và One Zone‑IA.
• Kết luận: ❌ Không phù hợp khi không biết tần suất truy cập, vì nếu thực tế ít truy cập sẽ tốn phí lưu trữ không cần thiết.

2. S3 Standard‑Infrequent Access (S3 Standard‑IA)

• Miêu tả: Dành cho dữ liệu ít truy cập nhưng vẫn cần độ bền đa AZ và thời gian truy xuất nhanh. Phí lưu trữ thấp hơn Standard, nhưng có phí truy xuất cao (≈ $0.01 per 1,000 GET).
• Chi phí khi truy cập không xác định: Nếu dữ liệu thực tế được truy cập thường xuyên, phí truy xuất sẽ làm tổng chi phí vượt hơn Standard.
• Kết luận: ❌ Không tối ưu khi không biết pattern, vì có rủi ro phí truy xuất cao nếu dữ liệu bất ngờ trở nên “hot”.

3. S3 One Zone‑Infrequent Access (S3 One Zone‑IA)

• Miêu tả: Giống Standard‑IA về phí lưu trữ và truy xuất, nhưng chỉ lưu trữ trong một AZ (không đa AZ). Thích hợp cho dữ liệu có khả năng tái tạo lại được.
• Rủi ro: Thiếu khả năng chịu lỗi AZ → không đáp ứng được yêu cầu độ bền cao cho đa phần các workloads.
• Kết luận: ❌ Không phù hợp cho hầu hết các trường hợp “unknown access patterns” vì mất độ bền đa AZ và vẫn có phí truy xuất cao.

4. S3 Intelligent‑Tiering (ĐÚNG)

• Miêu tả: Hai tier chính (Frequent và Infrequent) + một Archive tier (từ 2024, có tùy chọn Glacier Flex cho các đối tượng lâu năm).
• Tự động hoá: Không cần dự đoán trước; AWS tự động di chuyển đối tượng sau 30 ngày không truy cập sang tier ít tốn phí.
• Chi phí: Phí lưu trữ trung bình thấp hơn Standard‑IA khi dữ liệu ít truy cập, và gần tương đương Standard khi dữ liệu “hot”. Phí giám sát rất nhỏ.
• Kết luận: ✅ Là lựa chọn tiết kiệm nhất khi không biết trước mẫu truy cập, vì nó luôn “điều chỉnh” chi phí theo thực tế sử dụng.

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

1. Amazon S3 Storage Classes – Official AWS Documentation, cập nhật 2024‑2026.
   https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html
2. Pricing – Amazon S3 – Bảng giá chi tiết các lớp lưu trữ, phí giám sát Intelligent‑Tiering.
   https://aws.amazon.com/s3/pricing/
3. AWS Blog – Introducing S3 Intelligent‑Tiering Enhancements (2024) – Loại bỏ phí chuyển lớp và thêm Glacier Flex tier.
   https://aws.amazon.com/blogs/aws/s3-intelligent-tiering-enhancements/

🛠️ Kết luận nhanh

• Khi không biết trước tần suất truy cập, S3 Intelligent‑Tiering là lớp lưu trữ tiết kiệm chi phí nhất vì tính năng tự động điều chỉnh tier mà không cần dự đoán hay quản lý thủ công.
• Các lớp khác (Standard, Standard‑IA, One Zone‑IA) đều có rủi ro chi phí cao hơn khi pattern truy cập không khớp với thiết kế của chúng.

🚀 Hy vọng phân tích trên giúp bạn nắm rõ lý do tại sao S3 Intelligent‑Tiering là đáp án đúng trong câu hỏi!

📚 Câu hỏi:
Which options are AWS Cloud Adoption Framework (AWS CAF) security perspective capabilities? (Choose two.)

🔎 Phân tích câu hỏi
AWS CAF (Cloud Adoption Framework) chia quá trình chuyển đổi sang đám mây thành 6 “perspectives” (business, people, governance, platform, security, operations). Mỗi perspective lại gồm một tập các capability – các năng lực, chức năng mà tổ chức cần phát triển để đạt được mục tiêu của perspective đó.

Trong Security perspective, AWS liệt kê các capability chính như:

1. Infrastructure protection – bảo vệ môi trường hạ tầng (network, host, containers, …) bằng firewall, security groups, WAF, GuardDuty, IAM policies, v.v.
2. Identity & Access Management – quản lý danh tính, quyền truy cập.
3. Data protection – mã hoá, backup, key management.
4. Incident response – chuẩn bị, phát hiện và xử lý sự cố bảo mật.
5. Security monitoring & detective controls – giám sát liên tục, logging, audit.

Các capability khác như Observability, Incident and problem management, Availability and continuity thuộc các perspective khác (Operations, Reliability, …) chứ không phải Security.

Vì vậy, trong 5 đáp án được đưa ra, chỉ có Incident response và Infrastructure protection là thuộc Security perspective.

✅ Đáp án đúng

• Incident response
• Infrastructure protection

❓ Giải thích từng phương án

• Observability

  • Giải thích: “Observability” (khả năng quan sát) là một capability của Operations perspective, liên quan đến việc thu thập metrics, logs, trace để vận hành hệ thống hiệu quả. Nó không nằm trong danh sách các capability của Security perspective.
  • ✅ Sai.

• Incident and problem management

  • Giải thích: Đây là một capability thuộc Operations perspective, tập trung vào quy trình quản lý sự cố vận hành và các vấn đề (problem) lặp lại. Mặc dù có liên quan đến an ninh, nhưng trong AWS CAF nó không được liệt kê dưới Security perspective.
  • ✅ Sai.

• Incident response

  • Giải thích: Là capability chính của Security perspective. AWS khuyến nghị xây dựng kế hoạch IR (playbooks), sử dụng dịch vụ như AWS GuardDuty, AWS Security Hub, AWS Lambda để tự động hoá phản hồi.
  • ✅ Đúng.

• Infrastructure protection

  • Giải thích: Cũng là một capability của Security perspective. Nó bao gồm bảo vệ mạng, host, container, serverless bằng các công cụ như AWS Network Firewall, AWS WAF, Security Groups, NACLs, và các quy tắc IAM.
  • ✅ Đúng.

• Availability and continuity
  *Giải thích: “Availability and continuity” (độ sẵn sàng & liên tục) là một capability của Reliability / Operations perspective, không phải Security. Nó tập trung vào thiết kế hệ thống chịu lỗi, sao lưu, DR, v.v.

  • ✅ Sai.

📖 Tham khảo

• AWS Cloud Adoption Framework – Security Perspective (AWS Documentation, phiên bản 2024‑2025).
  https://docs.aws.amazon.com/whitepapers/latest/aws-cloud-adoption-framework/security-perspective.html

• AWS Well‑Architected Framework – Security Pillar (cũng mô tả các capability tương tự).
  https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/security-pillar.html

• AWS Incident Response Best Practices – AWS Security Blog, 2023‑2024.
  https://aws.amazon.com/blogs/security/

📝 Tóm lại:
Trong AWS CAF, các capability thuộc Security perspective là Incident response và Infrastructure protection. Các lựa chọn còn lại (Observability, Incident and problem management, Availability and continuity) thuộc các perspective khác, do đó không phải là đáp án đúng. 🚀

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

A company has a managed IAM policy that does not grant the necessary permissions for users to accomplish required tasks. How can this be resolved?

Câu hỏi nói về IAM (Identity and Access Management). Công ty đang sử dụng managed policy (có thể là AWS‑managed policy hoặc Customer‑managed policy) nhưng chính sách này không cung cấp đủ quyền để người dùng thực hiện công việc cần thiết. Yêu cầu là đưa ra cách khắc phục tình huống này.

• Managed policy: là một policy được AWS (AWS‑managed) hoặc người dùng tự tạo và quản lý (Customer‑managed) và được gán trực tiếp vào user, group hoặc role. Khi policy không đủ quyền, người dùng sẽ gặp lỗi “AccessDenied”.
• Giải pháp: Cần cung cấp thêm hoặc chỉnh sửa quyền sao cho đáp ứng yêu cầu công việc, mà không làm mất tính nguyên tắc “least privilege”. Trong AWS, cách thực hiện phổ biến nhất là tạo một custom IAM policy (policy do bạn tự viết) và gán vào user/role hoặc sửa đổi policy hiện tại nếu là Customer‑managed.

Vì vậy, câu trả lời đúng sẽ là tạo một custom IAM policy (hoặc sửa đổi policy hiện có) để bổ sung các quyền cần thiết.

✅ Đáp án đúng

[ĐÚNG] Create a custom IAM policy.

• Lý do: Khi một managed policy không đáp ứng nhu cầu, bạn có thể tự tạo một policy (custom policy) với các hành động, tài nguyên và điều kiện chính xác cần thiết. Policy này có thể gắn vào user, group hoặc role hiện có, hoặc thay thế policy hiện tại. Đây là cách chuẩn được đề xuất trong tài liệu AWS IAM để “grant the necessary permissions”.
• Cập nhật 2026: AWS vẫn khuyến cáo dùng IAM policy simulator và IAM Access Analyzer để kiểm tra và tối ưu custom policy, đồng thời tuân thủ nguyên tắc “least privilege”.

❌ Các phương án sai và giải thích

1. [SAI] Enable AWS Shield Advanced.

   • Giải thích: AWS Shield Advanced là dịch vụ bảo vệ chống lại các cuộc tấn công DDoS cho các tài nguyên như Amazon CloudFront, Elastic Load Balancing, Amazon Route 53, và Global Accelerator. Nó không liên quan tới việc cấp quyền IAM cho người dùng. Kích hoạt Shield Advanced không giải quyết vấn đề thiếu quyền trong policy.
   • 🛑 Vì sao sai: Không cung cấp hoặc thay đổi bất kỳ IAM permission nào; chỉ tăng cường bảo mật mạng.

2. [SAI] Use a third‑party web application firewall (WAF) managed rule from the AWS Marketplace.

   • Giải thích: WAF (Web Application Firewall) là công cụ lọc và bảo vệ các ứng dụng web khỏi các lỗ hổng như SQL injection, XSS, v.v. Sử dụng rule từ Marketplace đều nhằm mục đích bảo vệ tầng ứng dụng, không ảnh hưởng tới IAM permissions.
   • 🛑 Vì sao sai: Không giúp người dùng có thêm quyền thực thi hành động trên AWS; chỉ ảnh hưởng tới lưu lượng HTTP/HTTPS.

3. [SAI] Use AWS Key Management Service (AWS KMS) to create a customer‑managed key.

   • Giải thích: AWS KMS cho phép tạo và quản lý các khóa mã hoá. Tạo một customer‑managed key chỉ cung cấp khả năng mã hoá/giải mã và kiểm soát quyền truy cập vào các tài nguyên được mã hoá. Nó không liên quan tới việc bổ sung hoặc sửa đổi IAM permissions cho người dùng.
   • 🛑 Vì sao sai: Không giải quyết vấn đề “policy không đủ quyền”; KMS là dịch vụ quản lý khóa, không phải công cụ quản lý IAM.

🧩 Tổng hợp các bước thực hiện (nếu chọn đáp án đúng)

1. Xác định quyền thiếu

   • Sử dụng IAM Access Analyzer hoặc IAM Policy Simulator để xác định hành động, tài nguyên và điều kiện đang bị từ chối.

2. Tạo custom IAM policy

   • Vào IAM > Policies > Create policy.
   • Chọn JSON hoặc Visual editor và thêm các Action, Resource, Condition cần thiết.
   • Đảm bảo nguyên tắc least privilege – chỉ cấp quyền thực tế cần thiết.

3. Gán policy

   • Gắn policy mới vào User, Group hoặc Role phù hợp.
   • Nếu cần, detach policy cũ hoặc update version của Customer‑managed policy hiện có.

4. Kiểm tra lại

   • Dùng IAM Policy Simulator để xác nhận rằng người dùng hiện có thể thực hiện các công việc cần thiết mà không gặp lỗi AccessDenied.

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

• AWS Identity and Access Management User Guide – “Creating IAM Policies” (phiên bản 2026).
• AWS IAM Access Analyzer – “Analyzing Permissions and Policy Simulations”.
• AWS Security Best Practices – “Principle of Least Privilege” (cập nhật 2025).
• AWS re:Invent 2025 – Session “IAM Policy Writing Best Practices”.

🔚 Kết luận: Để giải quyết vấn đề “managed IAM policy không đủ quyền”, cách đúng là tạo một custom IAM policy (hoặc sửa đổi policy hiện có) và gán nó cho người dùng/role. Các lựa chọn còn lại liên quan đến bảo mật mạng, WAF, hoặc KMS, không có tác dụng trong việc bổ sung IAM permissions. ✅

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

Who is responsible for managing IAM user access and secret keys according to the AWS shared responsibility model?

Câu hỏi yêu cầu xác định bên chịu trách nhiệm trong mô hình “shared responsibility” (trách nhiệm chia sẻ) của AWS đối với quản lý quyền truy cập IAM và các secret access key của người dùng.

• Mô hình trách nhiệm chia sẻ:
  • AWS: bảo mật “cơ sở hạ tầng” (hardware, network, các dịch vụ cơ bản, physical data centers, hypervisor, …).
  • Khách hàng (Customer): bảo mật “các tài nguyên trong cloud” – bao gồm việc tạo, quản lý, và xoay vòng (rotate) IAM users, policies, password, access keys, và các thông tin chứng thực khác.

Do đó, việc quản lý IAM user access & secret keys thuộc trách nhiệm của khách hàng, không phải của AWS hay bộ phận hỗ trợ.

✅ Đáp án đúng

🔹 [ĐÚNG] The customer is responsible for rotating keys.

• Khách hàng phải tạo, quản lý, xoay vòng (rotate) và hủy bỏ các access key của IAM users.
• AWS chỉ cung cấp công cụ (IAM, AWS Secrets Manager, IAM Access Analyzer, IAM Access Advisor…) để hỗ trợ khách hàng thực hiện các thao tác này, nhưng không thực hiện thay mặt khách hàng.
• Được nêu rõ trong tài liệu AWS Shared Responsibility Model và IAM Best Practices (cập nhật tới 2026).

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

1. [SAI] IAM access and secret keys are static, so there is no need to rotate them.

   • ❌ Sai: Access key không nên được để tĩnh mãi mãi. AWS khuyến nghị xoay vòng ít nhất mỗi 90 ngày hoặc ngay khi nghi ngờ bị lộ. Việc giữ key tĩnh làm tăng rủi ro tấn công “credential leakage”.
   • 📘 Tham khảo: AWS IAM User Guide – “Rotate IAM access keys regularly” (v2026).

2. [SAI] AWS will rotate the keys whenever required.

   • ❌ Sai: AWS không tự động xoay vòng access key cho IAM users. AWS chỉ tự động xoay vòng temporary credentials (STS) khi sử dụng IAM roles, nhưng không áp dụng cho access key lâu dài.
   • 🧩 Chỉ có AWS Managed Policies hoặc Service‑linked roles có thể có credential tự động, nhưng không áp dụng cho IAM user access keys.

3. [SAI] The AWS Support team will rotate keys when requested by the customer.

   • ❌ Sai: Đội ngũ AWS Support không thực hiện việc xoay vòng hoặc quản lý credential cho khách hàng. Họ chỉ cung cấp hướng dẫn, không can thiệp vào tài khoản IAM của khách hàng.
   • 🛠️ Quy trình chuẩn: khách hàng tự thực hiện Create new access key → Update applications → Delete old access key; AWS Support có thể hướng dẫn nhưng không thực hiện thay.

📘 Kiến thức cập nhật (đến năm 2026)

• IAM Access Analyzer (2024‑2026) giúp phát hiện các policy quá rộng và cảnh báo khi access keys được sử dụng ngoài phạm vi cần thiết.
• AWS Secrets Manager & Parameter Store: Khuyến nghị lưu trữ secret key ở đây và tích hợp tự động rotation (có thể cấu hình lịch xoay vòng tự động).
• IAM Roles + STS: Đối với các workload (EC2, Lambda, ECS), nên tránh dùng IAM user access keys; thay vào đó dùng role để nhận temporary credentials tự động hết hạn (độ an toàn cao hơn).
• Best Practice (2025‑2026):
  • Sử dụng MFA cho IAM users.
  • Đặt policy “iam:CreateAccessKey” / “iam:DeleteAccessKey” cho người quản trị chỉ.
  • Giám sát bằng AWS CloudTrail và Amazon GuardDuty để phát hiện việc sử dụng access key bất thường.

📚 Tham khảo

• AWS Shared Responsibility Model – https://docs.aws.amazon.com/general/latest/gr/aws-security.html (phiên bản 2026).
• IAM User Guide – Managing Access Keys – https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html.
• IAM Best Practices – https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html.
• AWS Secrets Manager – Rotating Secrets – https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html.

📝 Tóm tắt

• Đúng: The customer is responsible for rotating keys.
• Sai: Các phương án còn lại đều không phản ánh đúng trách nhiệm trong mô hình chia sẻ của AWS và vi phạm các nguyên tắc bảo mật hiện hành.

Hy vọng phân tích trên giúp bạn nắm rõ trách nhiệm quản lý IAM access key trong môi trường AWS! 🚀

📖 Phân tích câu hỏi
Công ty muốn chạy một tường lửa (firewall) của bên thứ ba đã được cài đặt sẵn trên một instance Amazon EC2.
Yêu cầu ở đây không phải chỉ “bảo vệ” mạng mà là triển khai phần mềm tường lửa đã được đóng gói sẵn, có thể là một AMI (Amazon Machine Image) hoặc một giải pháp phần mềm‑as‑a‑service, và cần được khởi chạy trực tiếp trên EC2. Vì vậy chúng ta cần một cách để tìm, mua và triển khai phần mềm của bên thứ ba trong môi trường AWS.

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

Lý do chọn:

• AWS Marketplace là một “cửa hàng” trực tuyến của AWS, nơi các nhà cung cấp phần mềm (ISV) đăng bán các AMI, container images, SaaS và các giải pháp khác.
• Nhiều nhà cung cấp firewall (ví dụ: Palo Alto Networks VM-Series, Check Point, Fortinet FortiGate, Sophos, etc.) cung cấp các Amazon Machine Images đã được cài đặt sẵn và có thể khởi chạy trực tiếp trên EC2 chỉ với vài cú click.
• Khi mua qua Marketplace, bạn có thể tự động nhận các bản cập nhật bảo mật, licensing và hỗ trợ từ nhà cung cấp.
• Từ 2024‑2026, AWS đã mở rộng Marketplace để hỗ trợ Amazon EC2 Image Builder, SaaS subscriptions, và Marketplace private offers, giúp doanh nghiệp dễ dàng triển khai và quản lý các giải pháp tường lửa ở môi trường đa tài khoản (AWS Organizations).

Do đó, AWS Marketplace đáp ứng hoàn toàn yêu cầu “run a pre‑installed third‑party firewall on an Amazon EC2 instance”.

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

1. Network ACLs

   • Mô tả: Là lớp bảo mật ở mức subnet của Amazon VPC, hoạt động ở tầng OSI Layer 3/4 (IP & TCP/UDP).
   • Tại sao sai: Network ACLs chỉ cung cấp các quy tắc allow/deny dựa trên CIDR, giao thức và cổng. Chúng không phải là phần mềm tường lửa có thể cài đặt trên EC2, không chứa các tính năng deep‑packet inspection, IDS/IPS, hoặc giao diện quản trị của firewall bên thứ ba.

2. Security groups

   • Mô tả: Là tường lửa ảo ở mức instance, áp dụng các quy tắc inbound và outbound.
   • Tại sao sai: Security groups, giống như Network ACLs, chỉ là các quy tắc lọc lưu lượng. Chúng không cung cấp môi trường chạy phần mềm firewall đã được đóng gói, không hỗ trợ các tính năng nâng cao như VPN, threat intelligence, hay logging chi tiết mà các firewall bên thứ ba cung cấp.

3. AWS Trusted Advisor

   • Mô tả: Dịch vụ cung cấp khuyến nghị tối ưu hoá chi phí, độ tin cậy, bảo mật, và hiệu suất cho tài khoản AWS.
   • Tại sao sai: Trusted Advisor không phải là dịch vụ triển khai phần mềm; nó chỉ đưa ra các đề xuất (ví dụ: “Enable VPC flow logs”, “Reduce unused EC2 instances”). Nó không cung cấp bất kỳ AMI hay môi trường chạy firewall nào.

🛠️ Các cách triển khai firewall bên thứ ba trên EC2 (cập nhật 2026)

• AWS Marketplace: Như đã nói, mua AMI firewall, khởi chạy EC2, tùy chỉnh VPC, subnet, route tables, và thiết lập AWS License Manager để quản lý licensing.
• AWS Service Catalog: Tổ chức có thể tạo portfolio chứa các sản phẩm (ví dụ: AMI firewall) được lấy từ Marketplace và phân quyền triển khai cho các nhóm.
• AWS CloudFormation / CDK: Định nghĩa hạ tầng dưới dạng code, bao gồm AWS::EC2::Instance với ImageId trỏ tới AMI firewall từ Marketplace; có thể tự động hoá việc cấu hình các security groups, NACL, và AWS Systems Manager Parameter Store để lưu trữ các secret (key, password) của firewall.
• AWS Launch Wizard (được mở rộng trong 2025) hỗ trợ wizard‑driven deployment cho các giải pháp bảo mật phức tạp, bao gồm firewall của bên thứ ba.

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

1. AWS Marketplace Documentation – “Deploying Third‑Party Software on Amazon EC2” (Version 2026‑03).
2. Amazon VPC User Guide – “Network ACLs” và “Security groups” (last updated 2026‑02).
3. AWS Trusted Advisor Documentation – “What Trusted Advisor Checks Do” (2026‑01).
4. AWS Blog – “New Features in AWS Marketplace 2025‑2026” – giới thiệu Private Offers, AMI versioning, và integration with AWS License Manager.
5. AWS Well‑Architected Framework – Security Pillar (2025 edition) – khuyến nghị sử dụng Marketplace for third‑party security solutions when native AWS controls không đáp ứng yêu cầu tính năng.

🔚 Kết luận

• Đáp án đúng: AWS Marketplace – là dịch vụ duy nhất trong các lựa chọn cho phép cài đặt và chạy firewall của bên thứ ba trên một instance EC2.
• Các lựa chọn còn lại (Network ACLs, Security groups, AWS Trusted Advisor) chỉ cung cấp các cơ chế kiểm soát lưu lượng hoặc khuyến nghị, không phải là nền tảng để triển khai phần mềm firewall đã được đóng gói sẵn.

Hy vọng phần phân tích chi tiết này giúp bạn nắm vững lý do lựa chọn và cách AWS hỗ trợ việc triển khai firewall bên thứ ba! 🚀

🔍 Phân tích câu hỏi
Câu hỏi hỏi: “Which AWS Cloud benefit gives a company the ability to quickly deploy cloud resources to access compute, storage, and database infrastructures in a matter of minutes?”

Nói ngắn gọn, câu hỏi muốn chúng ta chỉ ra đặc tính (benefit) của AWS Cloud mà cho phép doanh nghiệp tạo, cấu hình và đưa vào hoạt động các tài nguyên (EC2, S3, RDS, …) trong vài phút. Đây là khái niệm thường được nhắc tới trong tài liệu AWS “Cloud Benefits” và trong các kỳ thi AWS Certified DevOps Engineer – Professional.

✅ Đáp án đúng

🟢 [ĐÚNG] Agility

Lý do:

• Agility (tính linh hoạt) trong AWS được định nghĩa là khả năng đáp ứng nhanh với thay đổi yêu cầu kinh doanh bằng cách triển khai, sửa đổi và gỡ bỏ hạ tầng IT trong thời gian ngắn (thường là vài phút đến vài giờ).
• AWS cung cấp các dịch vụ “self‑service” (EC2, RDS, DynamoDB, S3, Lambda…) và các công cụ tự động hoá (CloudFormation, CDK, Terraform, CodeDeploy) cho phép provisioning nhanh mà không cần qua quy trình mua sắm phần cứng truyền thống.
• Tài liệu AWS (2026) vẫn nhấn mạnh: “Agility enables organizations to experiment, iterate, and deliver new features faster, often in minutes.”

Vì vậy đáp án Agility là đúng nhất cho mô tả “quickly deploy cloud resources … in a matter of minutes”.

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

• [SAI] Elasticity

  • Elasticity (độ co giãn) đề cập tới khả năng tự động mở rộng hoặc thu hẹp tài nguyên (ví dụ: Auto Scaling, DynamoDB Auto Scaling) dựa trên tải thực tế.
  • Nó không liên quan trực tiếp tới thời gian triển khai ban đầu của tài nguyên, mà là độ linh hoạt trong việc thay đổi quy mô sau khi tài nguyên đã được tạo.

• [SAI] Cost savings

  • Cost savings (tiết kiệm chi phí) là lợi ích tài chính khi sử dụng mô hình trả phí “pay‑as‑you‑go”, Reserved Instances, Savings Plans, hoặc Spot Instances.
  • Mặc dù việc triển khai nhanh có thể gián tiếp giảm chi phí (bằng cách tránh đầu tư phần cứng), khái niệm này không mô tả khả năng triển khai trong vài phút.

• [SAI] Reliability

  • Reliability (độ tin cậy) nói đến độ sẵn sàng, khả năng chịu lỗi và phục hồi của các dịch vụ AWS (ví dụ: Multi‑AZ, Multi‑Region, Service Level Agreements).
  • Đây là khả năng duy trì hoạt động liên tục, không phải khả năng ra mắt nhanh các tài nguyên.

📚 Tham khảo (đến năm 2026)

1. AWS Well‑Architected Framework – Operational Excellence Pillar, phần “Agility”.
2. AWS Documentation – “AWS Cloud Benefits” (cập nhật 2026): https://docs.aws.amazon.com/whitepapers/latest/aws-overview/cloud-benefits.html
3. AWS Certified DevOps Engineer – Professional Exam Guide, mục “Agility & Elasticity”.

🧩 Tóm tắt nhanh

• Agility = khả năng triển khai nhanh (phút) và thay đổi linh hoạt các tài nguyên cloud. ✅
• Elasticity = tự động mở rộng/thu hẹp tài nguyên dựa trên tải. ❌
• Cost savings = giảm chi phí nhờ mô hình trả phí linh hoạt. ❌
• Reliability = độ sẵn sàng và khả năng phục hồi cao. ❌

Hy vọng phần phân tích trên giúp bạn nắm rõ lý do tại sao Agility là đáp án đúng và cách phân biệt các khái niệm liên quan trong AWS. 🚀🛠️

🔎 Phân tích câu hỏi
Câu hỏi: “Which of the following is entirely the responsibility of AWS, according to the AWS shared responsibility model?”

Trong mô hình Shared Responsibility Model của AWS, trách nhiệm bảo mật được chia thành hai lớp chính:

1. AWS chịu trách nhiệm về hạ tầng “các lớp 1‑5” (Physical, Network, Facility, hardware, virtualization, …).
2. Khách hàng chịu trách nhiệm về các lớp 6‑7 (Hệ điều hành, middleware, runtime, ứng dụng, dữ liệu, cấu hình bảo mật, quản lý người dùng, …).

Do vậy, bất kỳ yếu tố nào hoàn toàn nằm trong phạm vi hạ tầng vật lý và môi trường – ví dụ: phòng máy chủ, hệ thống làm mát, nguồn điện, kiểm soát truy cập vật lý – đều là trách nhiệm 100 % của AWS. Các yếu tố còn lại (đào tạo, chính sách mật khẩu IAM, cập nhật OS) đều yêu cầu sự tham gia của khách hàng.

✅ Đáp án đúng

Physical and environmental controls

🔹 Lý do: Đây là các biện pháp bảo vệ cơ sở hạ tầng vật lý (trong đó bao gồm: tường an ninh, camera, kiểm soát ra vào, hệ thống phòng cháy, nguồn điện dự phòng, điều hòa nhiệt độ, …). Theo mô hình chia sẻ trách nhiệm, AWS hoàn toàn chịu trách nhiệm cung cấp và duy trì những kiểm soát này. Khách hàng không có quyền truy cập hay thay đổi chúng.

🧩 Giải thích từng phương án

• [SAI] Security awareness and training

  • 📚 Giải thích: Việc đào tạo nhân viên, nâng cao nhận thức bảo mật là trách nhiệm của khách hàng. AWS chỉ cung cấp tài liệu, best‑practice và các dịch vụ hỗ trợ (ví dụ AWS Well‑Architected Tool), nhưng không thực hiện đào tạo nội bộ cho khách hàng.

• [SAI] Development of an IAM password policy

  • 📚 Giải thích: IAM (Identity and Access Management) là dịch vụ quản lý danh tính do AWS cung cấp, nhưng cách cấu hình chính sách mật khẩu (độ dài, yêu cầu ký tự, thời gian thay đổi, …) do khách hàng quyết định dựa trên yêu cầu bảo mật của mình. Do vậy, đây là một phần trách nhiệm của khách hàng.

• [SAI] Patching of the guest operating system

  • 📚 Giải thích: “Guest OS” là hệ điều hành chạy trên instance EC2 (hoặc container). Khi khách hàng sử dụng EC2, họ tự quản lý, cập nhật, vá lỗi hệ điều hành và phần mềm ứng dụng. Đối với AWS Managed Services (RDS, Elastic Beanstalk, Lambda...), AWS có thể thực hiện patching, nhưng câu hỏi không chỉ rõ dịch vụ được quản lý; trong mô hình chung, vá lỗi hệ điều hành là trách nhiệm của khách hàng.

• [ĐÚNG] Physical and environmental controls

  • 📚 Giải thích: Như đã nêu ở phần đáp án đúng, đây là các biện pháp bảo vệ cơ sở hạ tầng vật lý của trung tâm dữ liệu. AWS chịu toàn bộ trách nhiệm thiết kế, triển khai, giám sát và duy trì các biện pháp này (điều hòa, phòng cháy, an ninh, v.v.).

📘 Tham khảo tài liệu

1. AWS Security Documentation – Shared Responsibility Model (phiên bản 2026)
   • https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response/shared-responsibility-model.html
2. AWS Well‑Architected Framework – Security Pillar
   • https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/security-pillar.html
3. AWS Compliance & Auditing – Physical Security
   • https://aws.amazon.com/compliance/physical-security/

🛠️ Kết luận nhanh

• Hoàn toàn do AWS chịu trách nhiệm: Physical and environmental controls ✅
• Các mục còn lại (đào tạo, IAM password policy, patch OS) phải do khách hàng (hoặc khách hàng + AWS trong một số dịch vụ quản lý) đảm nhận ❌

Hy vọng phần phân tích trên giúp bạn nắm rõ ranh giới trách nhiệm trong mô hình chia sẻ bảo mật của AWS! 🚀

🔍 Phân tích câu hỏi
Câu hỏi: “Which of the following is a characteristic of the AWS account root user?”
Câu hỏi yêu cầu bạn nhận diện đặc điểm (characteristic) đúng của root user – tài khoản gốc được tạo tự động khi một AWS account được khai báo lần đầu. Root user có quyền toàn quyền trên toàn bộ tài khoản, nhưng không phải mọi đặc điểm đều đúng; vì vậy cần phân biệt giữa những quan niệm lầm tưởng và thực tế hiện hành (tính đến tháng 4/2026).

✅ Đáp án đúng

[ĐÚNG] The root user is the first sign‑in identity that is available when an AWS account is created.

🗒️ Giải thích:

• Khi bạn tạo một tài khoản AWS mới (bằng email và mật khẩu), hệ thống tự động tạo root user. Đây là danh tính đầu tiên và duy nhất có thể đăng nhập lần đầu tiên vào AWS Management Console.
• Sau khi đăng nhập lần đầu, bạn có thể (và nên) tạo IAM users, roles, groups, và MFA cho root.
• Tài liệu AWS (AWS Identity and Access Management User Guide – “Root user”) luôn nhắc: “The root user is the first identity you can use to sign in to the AWS Management Console when you open a new AWS account.”

❌ Các lựa chọn sai và lý do

1. [SAI] The root user is the only user that can be configured with multi‑factor authentication (MFA).

   • Thực tế: MFA có thể (và nên) được kích hoạt cho bất kỳ IAM user hoặc role nào có quyền đăng nhập Console hoặc truy cập API, không chỉ riêng root.
   • AWS khuyến cáo đặt MFA cho root user và cho ít nhất một IAM user có quyền quản trị, nhưng không phải là duy nhất.
   • Nguồn: AWS Security Best Practices – “Enable MFA on the root account and on privileged IAM users” (tài liệu AWS Well‑Architected Security Pillar, cập nhật 2024‑2026).

2. [SAI] The root user is the only user that can access the AWS Management Console.

   • Thực tế: Tất cả IAM users (nếu được cấp quyền) có thể truy cập AWS Management Console. Root user chỉ là một trong số các danh tính có quyền truy cập, không phải độc quyền.
   • Khi tạo IAM user và gán console password, người dùng này có thể đăng nhập Console giống như root (với các quyền được gán qua policy).
   • Nguồn: IAM User Guide – “Signing in to the AWS Management Console” (phiên bản 2025).

3. [SAI] The root user has a password that cannot be changed.

   • Thực tế: Root user có mật khẩu và có thể thay đổi bất kỳ lúc nào qua My Security Credentials trong Console. Việc thay đổi mật khẩu là khuyến cáo bảo mật quan trọng.
   • AWS cung cấp tính năng “Change password” cho root, giống như các IAM user.
   • Nguồn: AWS Documentation – “Changing the password for your AWS account root user” (cập nhật 2023‑2026).

🧩 Tổng hợp các điểm quan trọng về root user (cập nhật 2026)

• Quyền tối đa: Root user có quyền unrestricted trên mọi service, resource và billing.
• MFA bắt buộc: AWS yêu cầu kích hoạt MFA cho root user; nếu chưa, Console sẽ hiển thị cảnh báo “Enable MFA on your root account”.
• Sử dụng hạn chế: Nguyên tắc least privilege khuyến cáo chỉ dùng root để thực hiện các tác vụ hiếm gặp (ví dụ: thay đổi thông tin thanh toán, đăng ký các dịch vụ mới).
• Không dùng cho công việc hàng ngày: Thay vào đó tạo IAM users/roles với quyền cụ thể.
• Khôi phục tài khoản: Nếu mất quyền truy cập root, quy trình Account Recovery yêu cầu xác minh đa yếu tố (email, phone, tài liệu pháp lý).

📚 Tham khảo (tài liệu AWS, cập nhật đến 2026)

1. AWS Identity and Access Management User Guide, “Root user”, phiên bản 2025‑2026.
2. AWS Well‑Architected Framework – Security Pillar, “Enable MFA on the root account and privileged IAM users”.
3. AWS Documentation – Changing the password for your AWS account root user, 2024 revision.
4. AWS Security Best Practices, “Root account and IAM best practices”, 2023‑2026.

🔑 Kết luận:

• Đáp án đúng là “The root user is the first sign‑in identity that is available when an AWS account is created.”
• Các đáp án còn lại đều là lầm tưởng phổ biến; root user không phải là người duy nhất có thể dùng MFA, không phải là người duy nhất truy cập Console, và mật khẩu của root có thể thay đổi.

💡 Lưu ý: Khi chuẩn bị cho kỳ thi AWS Certified DevOps Engineer – Professional, hãy luôn nhớ nguyên tắc “use root sparingly” và protect the root credentials bằng MFA, mật khẩu mạnh và bảo quản an toàn.