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

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

Which AWS service or feature allows users to securely store encrypted credentials and retrieve these credentials when required?

Câu hỏi đang hỏi về dịch vụ hoặc tính năng của AWS cho phép:

1. Lưu trữ các thông tin đăng nhập/credential (như mật khẩu, API key, database credentials) được mã hoá an toàn.
2. Truy xuất các thông tin này một cách được kiểm soát (có thể đặt policy, rotation, audit).

Trong môi trường DevOps, nhu cầu này rất phổ biến: các pipeline CI/CD, ứng dụng micro‑service, hoặc Lambda functions đều cần “secret” mà không muốn hard‑code vào mã nguồn.

✅ Đáp án đúng

🔹 AWS Secrets Manager

Lý do chọn:

• Secrets Manager được thiết kế chuyên dụng để lưu trữ, quản lý và tự động quay vòng (rotate) các secrets như database credentials, API keys, OAuth tokens, …
• Secrets được mã hoá bằng AWS KMS (AWS Key Management Service) khi lưu trong Service, và được giải mã khi người dùng/ứng dụng có quyền gọi API GetSecretValue.
• Cung cấp tích hợp sẵn với IAM, cho phép kiểm soát chi tiết ai có thể truy cập, và có audit log qua CloudTrail.
• Có tính năng tự động rotation (với Lambda) và cập nhật tự động cho các dịch vụ như RDS, Redshift, DocumentDB.

Vì các đặc tính trên hoàn toàn đáp ứng yêu cầu “securely store encrypted credentials and retrieve them when required”, nên AWS Secrets Manager là đáp án đúng.

🧩 Giải thích các phương án còn lại (đúng/sai)

• [SAI] AWS Encryption SDK

  • Giải thích: AWS Encryption SDK là thư viện mã hoá (client‑side) cho phép nhà phát triển tự mã hoá và giải mã dữ liệu trong ứng dụng của mình. Nó không phải là một service lưu trữ; bạn phải tự quản lý nơi lưu trữ ciphertext (S3, DynamoDB, …). Do đó không đáp ứng yêu cầu “store and retrieve encrypted credentials” như một dịch vụ quản lý secret.
  • Kết luận: ❌ Không phải là dịch vụ lưu trữ secret.

• [SAI] AWS Security Hub

  • Giải thích: AWS Security Hub là trung tâm tổng hợp bảo mật, thu thập, chuẩn hoá và hiển thị các finding từ nhiều dịch vụ (GuardDuty, Inspector, Macie, …). Nó không cung cấp khả năng lưu trữ hoặc quản lý secret.
  • Kết luận: ❌ Sai, chức năng hoàn toàn khác.

• [ĐÚNG] AWS Secrets Manager

  • (đã giải thích ở mục trên)

• [SAI] AWS Artifact

  • Giải thích: AWS Artifact là cổng thông tin cung cấp tài liệu tuân thủ (compliance reports), chứng chỉ, và thỏa thuận cho khách hàng AWS. Nó không lưu trữ secret; mục tiêu là cung cấp bằng chứng tuân thủ.
  • Kết luận: ❌ Sai, không liên quan tới việc lưu trữ credentials.

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

• AWS Secrets Manager đã được mở rộng vào 2024‑2025 với các tính năng:
  • Cross‑Region Replication cho phép đồng bộ secret qua nhiều region mà không cần viết code.
  • Dynamic Secrets (beta 2025) cho phép tạo secret “on‑the‑fly” mà không cần lưu trữ trạng thái (ví dụ: tạo IAM temporary credentials cho một role). (AWS Blog, 2025 “Introducing Dynamic Secrets in Secrets Manager”)
• Tích hợp IAM Access Analyzer trong Secrets Manager giúp đánh giá chính sách và phát hiện secret bị chia sẻ ra ngoài không mong muốn (ra mắt 2024).
• Chi phí: $0.40 cho mỗi secret mỗi tháng + chi phí các call API GetSecretValue. Việc rotate tự động giúp giảm rủi ro và chi phí audit.

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

1. AWS Documentation – Secrets Manager
   https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html (cập nhật 2026)
2. AWS Blog – “Introducing Dynamic Secrets in Secrets Manager” – 2025
   https://aws.amazon.com/blogs/security/introducing-dynamic-secrets/
3. AWS Whitepaper – “Security Best Practices for Secrets Management” – 2024
   https://d1.awsstatic.com/whitepapers/security/AWS-Secrets-Management-Best-Practices.pdf

🔚 Kết luận:
Trong các lựa chọn đưa ra, AWS Secrets Manager là dịch vụ duy nhất đáp ứng đầy đủ yêu cầu “lưu trữ an toàn, mã hoá credentials và cho phép truy xuất khi cần”. Các lựa chọn khác là các công cụ hoặc dịch vụ không liên quan tới việc quản lý secret. ✅

🔍 Phân tích câu hỏi
Câu hỏi hỏi: “Which pillar of the AWS Well‑Architected Framework aligns with the ability to make frequent, small, and reversible changes to AWS Cloud architecture?”

Trong AWS Well‑Architected Framework hiện tại (cập nhật đến năm 2026) có 6 trụ cột:

1. Operational Excellence
2. Security
3. Reliability
4. Performance Efficiency
5. Cost Optimization
6. Sustainability (được bổ sung năm 2023)

Trong số các trụ cột trên, khả năng thực hiện các thay đổi thường xuyên, quy mô nhỏ và có thể đảo ngược (frequent, small, reversible changes) là một trong những best practice nổi bật của Operational Excellence – đặc biệt là các nguyên tắc “Design for Change” và “Iterative Improvement”.

✅ Đáp án đúng

🟢 Operational excellence

• Lý do: Trụ cột Operational Excellence tập trung vào việc đánh giá, theo dõi và cải tiến liên tục các quy trình, công cụ và kiến trúc. Một trong những khuyến nghị quan trọng là thiết kế hệ thống để có thể thay đổi nhanh, nhỏ gọn và có khả năng rollback khi cần, giúp giảm rủi ro và tăng tốc độ đổi mới. Các kỹ thuật như Infrastructure as Code (IaC), CI/CD pipelines, Blue/Green deployment, Canary releases đều được đưa vào trong phạm vi này.

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

• Security

  • Security tập trung vào bảo vệ dữ liệu, hệ thống và tài sản thông qua kiểm soát truy cập, mã hoá, giám sát và phản hồi sự cố. Mặc dù việc áp dụng các thay đổi an toàn là quan trọng, nhưng khả năng thực hiện thay đổi nhanh, nhỏ và có thể quay lại không phải là mục tiêu chính của trụ cột này.

• Cost optimization

  • Cost optimization hướng tới tối ưu hoá chi phí bằng cách lựa chọn loại tài nguyên phù hợp, sử dụng Reserved Instances, Savings Plans, và tự động tắt các tài nguyên không sử dụng. Việc thay đổi kiến trúc một cách nhanh và lặp lại không liên quan trực tiếp tới giảm chi phí; thay vào đó, đây là vấn đề của việc đánh giá chi phí sau khi thay đổi đã được triển khai.

• Performance efficiency

  • Performance efficiency đề cập đến sử dụng tài nguyên một cách hiệu quả để đạt được hiệu suất mong muốn, bao gồm việc lựa chọn loại instance, tối ưu hoá kiến trúc, và mở rộng/thu hẹp (scale) tài nguyên. Mặc dù việc thực hiện thay đổi nhanh có thể hỗ trợ tối ưu hoá hiệu suất, các nguyên tắc của Performance Efficiency tập trung vào “Scale appropriately”, “Use serverless”, “Choose performant services”, không phải vào tần suất hay khả năng đảo ngược của thay đổi.

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

• AWS Well‑Architected Framework – Pillars (AWS Documentation, phiên bản 2026): https://docs.aws.amazon.com/wellarchitected/latest/framework/pillars.html
• Operational Excellence Pillar – Design for Change (AWS Whitepaper, cập nhật 2025): https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-for-change.html
• AWS Well‑Architected Tool – Best Practices (AWS Management Console, 2026): https://aws.amazon.com/well-architected-tool/

🧩 Tóm tắt nhanh

• Câu hỏi liên quan tới khả năng “frequent, small, reversible changes”.
• Đáp án đúng: Operational excellence (đúng).
• Các đáp án còn lại (Security, Cost optimization, Performance efficiency) không phản ánh mục tiêu này, vì chúng tập trung vào các khía cạnh bảo mật, chi phí và hiệu suất chứ không phải vào cách thức triển khai thay đổi nhanh chóng và có thể rollback.

Hy vọng giải thích chi tiết trên giúp bạn nắm vững lý do lựa chọn đáp án và hiểu sâu hơn về các trụ cột trong AWS Well‑Architected Framework! 🚀

📖 Giải thích câu hỏi
Câu hỏi hỏi: “Which AWS service or resource can a company use to deploy AWS WAF rules?”
Nghĩa là: “Dịch vụ hoặc tài nguyên AWS nào mà công ty có thể gắn AWS WAF để triển khai (deploy) các rule (luật) bảo vệ ứng dụng?”
AWS WAF (Web Application Firewall) là một dịch vụ quản lý quy tắc lọc lưu lượng HTTP/HTTPS. Để đính kèm (attach) WAF, bạn cần một điểm cuối (endpoint) hỗ trợ WAF, chẳng hạn:

• Amazon CloudFront (CDN)
• Amazon API Gateway (REST & HTTP)
• Application Load Balancer (ALB)
• AWS App Runner (từ 2023)
• Amazon Elastic Load Balancing (đối với ALB chứ không phải NLB)

Vì vậy, trong các lựa chọn, chỉ Application Load Balancer đáp ứng được yêu cầu.

✅ Đáp án đúng

Application Load Balancer

Lý do:

• ALB hỗ trợ tích hợp trực tiếp với AWS WAF v2, cho phép bạn đính kèm WAF web ACL (Access Control List) vào listener của ALB.
• Khi WAF được gắn vào ALB, mọi yêu cầu HTTP/HTTPS tới các target group của ALB sẽ được kiểm tra qua các rule WAF (IP block, rate‑based, OWASP‑CoreRuleSet, …).
• Đây là một trong ba tài nguyên “first‑class” được hỗ trợ (cùng với CloudFront và API Gateway).

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

• Amazon EC2

  • EC2 là máy ảo (compute instance). WAF không thể được gắn trực tiếp vào một instance; bạn phải đặt WAF ở trước (ví dụ qua ALB hoặc CloudFront) để lọc lưu lượng tới EC2. Do đó EC2 không phải là tài nguyên để “deploy” WAF rules.

• AWS Trusted Advisor

  • Trusted Advisor là dịch vụ tư vấn tối ưu chi phí, bảo mật, hiệu năng, cung cấp các recommendation. Nó không phải là điểm cuối mạng, cũng không có khả năng gắn web ACL. Vì vậy không thể dùng để triển khai WAF rules.

• Network Load Balancer

  • NLB hoạt động ở lớp 4 (TCP/UDP) và không hỗ trợ xử lý HTTP/HTTPS cấp ứng dụng. AWS WAF chỉ hoạt động ở lớp 7 (HTTP/HTTPS). Do đó NLB không hỗ trợ việc gắn web ACL/WAF rules.

🧩 Tổng hợp nhanh (liệt kê)

• ✅ Application Load Balancer – ✅ Có thể gắn AWS WAF web ACL → Đúng.
• ❌ Amazon EC2 – ❌ Là compute instance, không phải điểm cuối cho WAF.
• ❌ AWS Trusted Advisor – ❌ Dịch vụ tư vấn, không hỗ trợ WAF.
• ❌ Network Load Balancer – ❌ Chỉ lớp 4, không hỗ trợ WAF (lớp 7).

📚 Tham khảo (cập nhật đến năm 2026)

1. AWS WAF Developer Guide – “Associating a web ACL with an Application Load Balancer” (phiên bản 2026).
2. AWS re:Invent 2023 – New integrations for AWS WAF – giới thiệu hỗ trợ ALB, CloudFront, API Gateway, và App Runner.
3. AWS Elastic Load Balancing Documentation – bảng so sánh ALB vs NLB, lưu ý “WAF is supported only with ALB and CloudFront”.

🔚 Hy vọng phần phân tích trên giúp bạn nắm rõ lý do tại sao Application Load Balancer là đáp án duy nhất đúng cho câu hỏi này! 🚀

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

Công ty đang chạy website trên các instance Amazon EC2. Yêu cầu:

1. Đưa nội dung website tới người dùng trên toàn cầu – phải có một lớp phân phối nội dung (content distribution) hoặc DNS routing toàn cầu.
2. Giảm thiểu độ trễ (latency) cho người dùng – nội dung nên được phục vụ từ vị trí gần nhất với khách hàng (edge location) để giảm thời gian truyền tải dữ liệu.

Vì vậy câu hỏi đang hỏi dịch vụ AWS nào giúp “phân phối nội dung” (content delivery) với latency thấp nhất cho người dùng toàn cầu.

✅ Đáp án đúng

✅ Amazon CloudFront

Vì sao Amazon CloudFront là đáp án đúng?

• Mạng lưới Edge (Edge Locations): CloudFront có hơn 400 edge locations và Regional Edge Caches trên toàn thế giới (tính đến 2026). Khi người dùng yêu cầu một tài nguyên, CloudFront trả về bản sao đã được cache gần nhất, giảm RTT (round‑trip time) và thời gian tải trang.
• Tích hợp sẵn với EC2, S3, ALB, và Origin khác: Bạn chỉ cần cấu hình origin là EC2 hoặc Application Load Balancer, CloudFront sẽ tự động lấy dữ liệu, cache và phân phối.
• Tối ưu hoá latency: CloudFront sử dụng thuật toán “latency‑based routing” và “geolocation routing” để chọn edge location tốt nhất.
• Các tính năng bổ trợ: TLS/HTTPS, WAF, Shield, Lambda@Edge, và khả năng tùy chỉnh header/cookies – tất cả hỗ trợ việc cung cấp nội dung an toàn và nhanh chóng.
• Chi phí hợp lý: Bạn trả phí cho dữ liệu truyền ra từ edge và các yêu cầu, không phải trả phí cho mỗi instance EC2.

Nguồn: AWS Documentation – Amazon CloudFront – What is a CDN? (phiên bản 2026) và AWS Global Infrastructure (2026).

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

❌ Amazon Route 53

• Chức năng chính: Dịch vụ DNS quản lý tên miền, hỗ trợ routing dựa trên địa lý, latency‑based routing, failover, và health checking.
• Tại sao không đáp ứng yêu cầu: Route 53 chỉ quyết định địa chỉ IP hoặc CNAME mà người dùng sẽ kết nối tới, nhưng không cache hay phân phối nội dung. Nếu chỉ dùng Route 53, người dùng vẫn phải kết nối trực tiếp tới EC2, dẫn đến latency cao khi họ ở xa vùng EC2.
• Kết luận: Route 53 là công cụ hỗ trợ routing, không phải CDN. Vì vậy không đáp ứng yêu cầu “cung cấp minimum latency” cho nội dung tĩnh/dynamic.

❌ Elastic Load Balancing (ELB)

• Chức năng chính: Phân phối lưu lượng inbound tới các EC2, container, hoặc Lambda trong cùng một region (hoặc multi‑AZ).
• Giới hạn: ELB hoạt động ở mức region, không có edge location toàn cầu. Người dùng vẫn phải tới region chứa ELB; nếu region đó cách xa họ, latency vẫn cao.
• Không phải CDN: ELB không cache nội dung, không có mạng lưới edge, nên không giảm latency cho người dùng toàn cầu.
• Kết luận: ELB thích hợp cho cân bằng tải nội bộ, không phải cho việc đưa website tới khán giả toàn cầu với latency tối thiểu.

❌ AWS Lambda

• Chức năng chính: Compute “server‑less” để chạy code đáp ứng sự kiện.
• Vấn đề: Lambda không có khả năng cache và phân phối nội dung tới người dùng cuối. Bạn có thể dùng Lambda@Edge (được triển khai trong CloudFront) để thực hiện logic tại edge, nhưng Lambda đơn thuần không giải quyết vấn đề latency toàn cầu.
• Kết luận: Lambda không phải là dịch vụ CDN, vì vậy không đáp ứng yêu cầu của câu hỏi.

📚 Tổng kết

• Câu hỏi yêu cầu một dịch vụ phân phối nội dung toàn cầu với độ trễ tối thiểu.
• Amazon CloudFront là dịch vụ CDN của AWS, cung cấp cache tại edge locations, tích hợp dễ dàng với EC2 và các origin khác, và được thiết kế riêng để giảm latency cho người dùng trên toàn thế giới.
• Các lựa chọn còn lại (Route 53, ELB, Lambda) không đáp ứng đầy đủ các tiêu chí CDN → không phù hợp.

📖 Tham khảo

1. Amazon CloudFront Documentation – What is Amazon CloudFront? (phiên bản 2026). https://docs.aws.amazon.com/cloudfront/latest/DeveloperGuide/Introduction.html
2. AWS Global Infrastructure – Edge Locations and Regional Edge Caches (2026). https://aws.amazon.com/about-aws/global-infrastructure/
3. Amazon Route 53 Documentation – How Route 53 Works. https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html
4. Elastic Load Balancing Documentation – ELB Overview. https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-elb.html
5. AWS Lambda Documentation – Lambda@Edge Overview. https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html

💡 Mẹo thực hành: Khi cần đưa website chạy trên EC2 tới người dùng toàn cầu, thường sẽ kết hợp:

• ALB (hoặc NLB) để cân bằng tải trong region,
• CloudFront làm front‑end CDN,
• Route 53 để routing DNS (có thể dùng latency‑based routing tới các CloudFront distributions).

Cách kết hợp này tối ưu chi phí, độ sẵn sàng và latency. 🚀

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

Which AWS design principle emphasizes the reduction of interdependencies between components of an application?

Câu hỏi đang hỏi về nguyên tắc thiết kế trong kiến trúc AWS (và nói chung trong kiến trúc đám mây) mà mục tiêu chính là giảm thiểu sự phụ thuộc lẫn nhau giữa các thành phần của một ứng dụng. Khi các thành phần ít phụ thuộc nhau, chúng có thể phát triển, triển khai, mở rộng và chịu lỗi một cách độc lập – đây là một trong những trụ cột quan trọng của Well‑Architected Framework và của kiến trúc vi mô (micro‑services).

✅ Đáp án đúng

[ĐÚNG] Loose coupling

• Giải thích:
  • Loose coupling (độ liên kết lỏng) nghĩa là các thành phần của hệ thống giao tiếp với nhau qua các giao thức chuẩn (API, event streams, message queues…) và không chia sẻ trạng thái nội bộ. Khi một thành phần thay đổi, các thành phần còn lại không bị ảnh hưởng đáng kể.
  • Trong AWS, các dịch vụ như Amazon SQS, Amazon SNS, EventBridge, AWS Lambda, và API Gateway được thiết kế để hỗ trợ kiến trúc “loose‑coupled”.
  • Nguyên tắc này giúp tăng tính sẵn sàng, độ tin cậy, khả năng mở rộng và đơn giản hoá việc bảo trì – các tiêu chí chính của AWS Well‑Architected Framework (đặc biệt là pillar Reliability và Operational Excellence).

❌ Các phương án còn lại (giải thích vì sao sai)

• [SAI] Scalability

  • Scalability (khả năng mở rộng) là khả năng hệ thống có thể đáp ứng tăng tải bằng cách thêm tài nguyên (vertical) hoặc thêm bản sao (horizontal). Mặc dù scalability thường đi kèm với loose coupling, nhưng nguyên tắc này không tập trung vào việc giảm interdependencies mà chỉ nói tới việc đáp ứng nhu cầu tăng trưởng. Do đó không phải là đáp án đúng cho câu hỏi.

• [SAI] Automation

  • Automation (tự động hoá) đề cập đến việc sử dụng IaC (Infrastructure as Code), CI/CD pipelines, auto‑scaling, v.v., để giảm thiểu công việc thủ công. Mục tiêu chính là tăng tốc độ triển khai và giảm lỗi con người, chứ không phải giảm phụ thuộc giữa các thành phần. Vì vậy, không phù hợp với mô tả của câu hỏi.

• [SAI] Caching

  • Caching (bộ nhớ đệm) là kỹ thuật lưu trữ tạm thời dữ liệu thường truy cập để cải thiện thời gian phản hồi và giảm tải lên nguồn dữ liệu. Đây là một cải tiến hiệu năng, không liên quan tới việc tách rời các thành phần hay giảm độ phụ thuộc lẫn nhau. Vì vậy, đây không phải là nguyên tắc được hỏi.

🧩 Tổng kết các nguyên tắc thiết kế AWS liên quan

• Loose coupling ✅ – Giảm interdependencies → đáp án đúng.
• Scalability ❌ – Tập trung vào mở rộng tài nguyên, không giảm phụ thuộc.
• Automation ❌ – Tự động hoá quy trình, không liên quan tới cấu trúc phụ thuộc.
• Caching ❌ – Tối ưu hoá hiệu năng, không giảm phụ thuộc.

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

1. AWS Well‑Architected Framework – Reliability Pillar (2024 / 2025 cập nhật): mô tả “design for loose coupling” để tăng độ tin cậy.
2. AWS Documentation – Event‑driven architecture (phiên bản 2026): nêu rõ lợi ích của việc sử dụng SQS, SNS, EventBridge để đạt “loose coupling”.
3. AWS Whitepaper – “Architecting for the Cloud: Best Practices” (cập nhật 2025): đề cập đến “loose coupling” như một trong 5 nguyên tắc thiết kế chính.

🛠️ Lời khuyên cho bài thi

• Khi gặp câu hỏi hỏi về giảm interdependencies, luôn nhớ từ khóa “loose coupling”.
• Các khái niệm Scalability, Automation, Caching thường xuất hiện trong các câu hỏi khác (mở rộng, tự động hoá, tối ưu hoá hiệu năng) – không nhầm lẫn với “loose coupling”.
• Đọc kỹ mô tả pillars của AWS Well‑Architected Framework: mỗi pillar có các “design principles” riêng, và “loose coupling” thuộc pillar Reliability và Operational Excellence.

Chúc bạn ôn luyện hiệu quả và đạt điểm cao! 🎉

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

Công ty muốn cho một nhân viên khả năng truy cập Amazon RDS nhưng chỉ thông qua:

• AWS CLI
• AWS SDKs

Không cho phép truy cập qua AWS Management Console. Ngoài ra, công ty phải tuân thủ nguyên tắc “least privilege” (cấp quyền tối thiểu cần thiết). Vì vậy chúng ta cần:

1. Tạo một thực thể (IAM User hoặc IAM Role) có khả năng gọi API – tức là “programmatic access”.
2. Gán một policy chỉ cho phép các hành động cần thiết trên RDS (ví dụ rds:Describe*, rds:Connect, rds:ExecuteStatement … tùy nhu cầu).
3. Không cấp quyền quản trị toàn bộ hay quyền truy cập Console.

✅ Các đáp án đúng (Choose two)

• [ĐÚNG] Create an IAM user and provide programmatic access only.

  • ✅ Tạo IAM User cho nhân viên, bật Programmatic access (có Access key ID & Secret access key) để họ có thể dùng CLI/SDK.
  • ❌ Không bật Console password, vì chúng ta không muốn họ truy cập Management Console.

• [ĐÚNG] Create an IAM policy with Amazon RDS access and attach it to the IAM user.

  • ✅ Policy này chỉ chứa các hành động RDS cần thiết (ví dụ rds:DescribeDBInstances, rds:Connect, rds:ExecuteStatement).
  • ✅ Gắn policy này vào IAM user ở mục trên, đảm bảo quyền được giới hạn đúng vào RDS và không có quyền thừa.

Hai hành động này kết hợp lại đáp ứng yêu cầu: truy cập RDS qua CLI/SDK và đúng nguyên tắc least privilege.

❌ Các đáp án sai và lý do

• [SAI] Create an IAM user and provide AWS Management Console access only.

  • ❌ Người dùng sẽ chỉ có Console password mà không có Access keys, nên không thể dùng CLI/SDK.
  • ❌ Thêm vào đó, việc cho phép Console truy cập vi phạm yêu cầu “chỉ cho phép CLI/SDK”.

• [SAI] Create an IAM role and provide AWS Management Console access only.

  • ❌ IAM Role thường được assume bởi các service hoặc người dùng khác; không phù hợp để cấp trực tiếp cho một nhân viên cá nhân.
  • ❌ Cũng chỉ cho phép Console access, không đáp ứng yêu cầu “programmatic only”.

• [SAI] Create an IAM policy with administrator access and attach it to the IAM user.

  • ❌ Policy AdministratorAccess cấp quyền toàn bộ trên mọi dịch vụ AWS → vi phạm mạnh mẽ nguyên tắc least privilege.
  • ❌ Ngoài ra, dù người dùng có programmatic access, quyền quá rộng sẽ gây rủi ro bảo mật.

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

• IAM Best Practices – https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
• Creating IAM Users – https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html
• Programmatic Access – Access Keys – https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
• Amazon RDS IAM Policy Examples – https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingIAM.html#UsingIAM.ExamplePolicies

🛠️ Tổng kết
Để đáp ứng yêu cầu “truy cập RDS chỉ qua CLI/SDK và tuân thủ least privilege”, công ty cần:

1. Tạo IAM User với Programmatic access (không có mật khẩu Console).
2. Gắn IAM Policy chỉ cho phép các hành động RDS cần thiết vào user đó.

Hai hành động này chính là đáp án đúng. 🚀

📖 Giải thích nội dung câu hỏi
Công ty đang chạy một ứng dụng web báo cáo trên Amazon EC2.

• Ứng dụng chỉ chạy một lần mỗi tuần và lại chạy một lần vào cuối tháng.
• Khi không có công việc, các instance có thể tắt hoàn toàn.

Yêu cầu: Chọn mô hình tính phí (billing model) tiết kiệm chi phí nhất cho cách dùng “thỉnh thoảng, ngắt quãng” này.

✅ Đáp án đúng: On-Demand Instances

Lý do:

• Thanh toán theo giờ/phút thực tế (theo giây kể từ 2020). Khi instance tắt, không có chi phí tính cho compute.
• Đối với một hoặc vài lần chạy mỗi tháng, không có lợi thế nào khi cam kết mua Reserved Instances hay Savings Plans vì bạn sẽ trả tiền cho tài nguyên mà không sử dụng trong phần lớn thời gian.
• On-Demand cho phép khởi tạo, dừng, khởi động lại linh hoạt mà không cần lo về cam kết thời gian hay phí đặt trước.

Vì vậy, trong trường hợp sử dụng rất ít và không liên tục, On‑Demand Instances là lựa chọn tiết kiệm nhất.

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

1️⃣ Standard Reserved Instances

• Mô tả: Giảm giá mạnh (khoảng 30‑70 %) khi cam kết sử dụng 1‑3 năm với một loại instance, khu vực và nền tảng cố định.
• Tại sao không phù hợp:
  • Cam kết dài hạn: Bạn phải trả trước (hoặc trả dần) dù không dùng tài nguyên trong 99 % thời gian.
  • Chi phí “bị khóa”: Khi công việc chỉ chạy vài giờ/tuần, chi phí đặt cọc sẽ vượt quá lợi ích giảm giá.
  • Không linh hoạt: Thay đổi loại instance hoặc khu vực chỉ được thực hiện bằng cách bán lại (có phí).

🔴 Kết luận: Không phải là mô hình tiết kiệm chi phí cho việc sử dụng không thường xuyên.

2️⃣ Convertible Reserved Instances

• Mô tả: Tương tự Reserved Instances nhưng cho phép đổi sang loại instance khác (vừa vặn với nhu cầu thay đổi) trong suốt thời gian cam kết 1‑3 năm.
• Tại sao không phù hợp:
  • Vẫn yêu cầu cam kết thời gian và phải trả phí đặt trước.
  • Chi phí “đóng băng” vẫn cao hơn khi chỉ cần chạy vài lần mỗi tháng.
  • Lợi ích giảm giá không bù đắp được chi phí không dùng.

🔴 Kết luận: Cũng không đáp ứng nhu cầu “tắt máy khi không dùng”.

3️⃣ On-Demand Capacity Reservations

• Mô tả: Đặt đảm bảo khả năng cung cấp (capacity) cho một khu vực và AZ, nhưng chi phí tính riêng cho việc giữ chỗ và cho việc chạy instance On‑Demand.
• Tại sao không phù hợp:
  • Chi phí kép: Bạn trả phí đặt chỗ (capacity reservation fee) cùng với phí On‑Demand khi chạy.
  • Khi sử dụng rất ít, phí đặt chỗ sẽ là gánh nặng không cần thiết.
  • Được dùng khi cần đảm bảo tài nguyên sẵn sàng cho các workload quan trọng, không phải để tiết kiệm chi phí.

🔴 Kết luận: Thêm chi phí không cần thiết, không phải là lựa chọn tiết kiệm.

4️⃣ On-Demand Instances (đáp án đúng)

• Mô tả: Trả tiền theo thời gian thực (giây) cho mỗi instance đang chạy. Không có phí đặt cọc, không cam kết thời gian.
• Ưu điểm cho trường hợp này:
  • Chi phí chỉ tính khi chạy – khi tắt, không còn phí compute.
  • Linh hoạt: có thể khởi động, dừng, thay đổi loại instance bất kỳ lúc nào.
  • Không cần dự báo nhu cầu sử dụng lâu dài.

✅ Vì vậy, On‑Demand Instances là mô hình chi phí tối ưu nhất cho workload chạy “đôi khi, không đều đặn”.

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

1. AWS Documentation – Amazon EC2 Pricing
   https://docs.aws.amazon.com/ec2/pricing/ (cập nhật 2026, bao gồm On‑Demand, Reserved, Convertible, Savings Plans, Spot và Capacity Reservations).

2. AWS Blog – New per‑second billing for EC2 instances (đăng 2020, vẫn áp dụng tới 2026).

3. AWS Well‑Architected Framework – Cost Optimization Pillar
   https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/ – hướng dẫn lựa chọn mô hình thanh toán phù hợp với mức độ sử dụng.

🛠️ Kết luận nhanh

• Đúng: On-Demand Instances – trả phí chỉ khi thực sự sử dụng, không có cam kết lâu dài.
• Sai: Standard Reserved Instances, Convertible Reserved Instances, On-Demand Capacity Reservations – đều gây chi phí “cố định” hoặc “đặt chỗ” không cần thiết cho workload chạy không thường xuyên.

💡 Mẹo thực tiễn: Nếu workload có thể chấp nhận gián đoạn hoặc độ trễ, bạn cũng có thể xem xét EC2 Spot Instances (không có trong danh sách đáp án) hoặc Savings Plans cho các workload dự đoán được, nhưng trong trường hợp hiện tại, On‑Demand là lựa chọn tối ưu nhất.

🔎 Phân tích câu hỏi
Công ty muốn thực hiện 4 bước chính đối với dữ liệu:

1. Discover (khám phá) – tìm hiểu cấu trúc, định dạng và siêu dữ liệu của các nguồn dữ liệu đa dạng.
2. Prepare (chuẩn bị) – làm sạch, biến đổi, chuẩn hoá dữ liệu để đưa vào phân tích/ML.
3. Move (di chuyển) – sao chép hoặc truyền dữ liệu từ nguồn sang khu vực lưu trữ trung tâm (Data Lake, S3, …).
4. Integrate (tích hợp) – kết hợp dữ liệu từ nhiều nguồn thành một bộ dữ liệu thống nhất.

Yêu cầu này mô tả đầy đủ chức năng của AWS Glue, một dịch vụ serverless dành cho ETL (Extract‑Transform‑Load), crawling và cataloguing dữ liệu. Glue cho phép:

• Tự động crawling để phát hiện schema và tạo Data Catalog.
• Viết và chạy jobs ETL không cần quản lý server.
• Di chuyển dữ liệu giữa các nguồn (RDS, DynamoDB, S3, on‑prem, …) và lưu trữ kết quả trên S3 để phục vụ analytics hoặc Machine Learning.

Do đó đáp án đúng là AWS Glue.

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

📖 Lý do lựa chọn

• Serverless: Không cần provision hoặc quản lý cluster EC2.
• Data discovery: Crawlers tự động phát hiện schema và ghi vào Glue Data Catalog.
• Data preparation: Jobs viết bằng Spark (Python/Scala) hoặc sử dụng Glue Studio kéo‑thả để biến đổi dữ liệu.
• Data movement & integration: Hỗ trợ kết nối tới hơn 100 nguồn dữ liệu và chuyển tải dữ liệu sang S3, Redshift, Athena, SageMaker, …
• Tích hợp chặt chẽ với các dịch vụ analytics & ML (Amazon Athena, Amazon Redshift Spectrum, Amazon SageMaker).

Các tài liệu tham khảo (cập nhật tới 2026):

• AWS Glue – Serverless Data Integration – https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html
• AWS Glue – New Features 2025‑2026 (DynamicFrames, Glue DataBrew enhancements, integrated Data Catalog federation).

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

• AWS Data Exchange

  • Mô tả: Dịch vụ cho phép mua, bán và tiêu thụ dữ liệu bên thứ ba hoặc dữ liệu công cộng.
  • Tại sao sai: Không cung cấp khả năng discover, prepare, move, integrate dữ liệu nội bộ. Nó chỉ là nền tảng chia sẻ dữ liệu đã chuẩn bị sẵn.

• Amazon Athena

  • Mô tả: Trình truy vấn SQL serverless cho dữ liệu lưu trữ trong Amazon S3.
  • Tại sao sai: Athena chỉ thực hiện phân tích (query) trên dữ liệu đã có sẵn; không có chức năng crawling, ETL, di chuyển dữ liệu.

• Amazon EMR

  • Mô tả: Dịch vụ managed Hadoop/Spark/Kubernetes cluster cho big data processing.
  • Tại sao sai: EMR yêu cầu provisioning và quản lý cluster, không phải là serverless. Nó tập trung vào xử lý khối lượng lớn, nhưng không cung cấp tính năng tự động discover và catalog như Glue.

🧩 Tóm tắt nhanh (danh sách)

• Câu hỏi: Cần dịch vụ serverless để khám phá, chuẩn bị, di chuyển, tích hợp dữ liệu đa nguồn.
• Đáp án đúng: AWS Glue ✅
• Lý do: Glue cung cấp crawling, Data Catalog, ETL jobs, di chuyển dữ liệu, và tích hợp sẵn với các công cụ analytics & ML.
• Các đáp án sai:
  • AWS Data Exchange – chỉ chia sẻ dữ liệu. ❌
  • Amazon Athena – chỉ query, không ETL. ❌
  • Amazon EMR – không serverless, cần cluster. ❌

💡 Ghi chú cho kỳ thi
Khi gặp các câu hỏi về “serverless data integration” trong AWS, hãy nhớ AWS Glue là đáp án “điểm nóng” vì nó kết hợp crawling, catalog, ETL, và integration trong một dịch vụ duy nhất, không cần quản lý hạ tầng.

📚 Tham khảo

1. AWS Glue Documentation – “What is AWS Glue?” (phiên bản 2026).
2. AWS Big Data Blog – “New Features in AWS Glue 2025‑2026”.
3. AWS Well‑Architected Framework – Data Analytics Pillar (2025).

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

Công ty muốn chuyển các môi trường development và test lên AWS. Các yêu cầu quan trọng:

1. Không phải workload production → có thể chấp nhận mức độ sẵn sàng không cao.
2. Máy chủ không được sử dụng hết công suất → tài nguyên sẽ “rảnh” phần lớn thời gian.
3. Có thể chấp nhận “occasional unavailability” → nếu máy bị dừng chạy một lúc, không ảnh hưởng nghiêm trọng tới công việc.

Vì vậy, mục tiêu là giảm chi phí tối đa đồng thời vẫn đáp ứng được yêu cầu về tính “đủ dùng” (có thể khởi động lại khi cần). Câu hỏi hỏi: Mô hình định giá EC2 nào là “MOST cost‑effective” cho trường hợp này?

✅ Đáp án đúng: Spot Instances

• Spot Instances cho phép bạn đặt giá đấu giá cho công suất chưa dùng trên EC2. Khi nhu cầu của AWS cao hơn giá bạn đặt, instance sẽ bị terminated (hoặc stopped tùy loại).
• Giá Spot thường lớn hơn 70 % so với On‑Demand và lớn hơn 90 % so với Reserved Instances trong nhiều khu vực (AWS 2024‑2026 pricing data).
• Vì workload không phải production và có thể chịu được việc bị tạm dừng, Spot là lựa chọn tối ưu nhất về chi phí. Bạn có thể dùng Spot Fleet hoặc EC2 Auto Scaling groups với “capacity‑rebalancing” để tự động thay thế các instance bị mất, giảm thiểu thời gian gián đoạn.

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

1️⃣ Reserved Instances (đánh dấu [SAI])

• Giải thích: Reserved Instances (RI) yêu cầu bạn cam kết sử dụng một loại instance, một khu vực và một thời gian (1‑hoặc 3‑năm). Bạn trả trước một phần hoặc toàn bộ chi phí để nhận mức giảm ~30‑60 % so với On‑Demand.
• Tại sao sai:
  • Không linh hoạt: Nếu server không được sử dụng hết, bạn vẫn phải trả phí đầy đủ cho toàn bộ thời gian cam kết.
  • Không đáp ứng “occasional unavailability”: RI không cho phép instance bị tạm dừng mà không mất chi phí.
  • Chi phí cao hơn Spot trong trường hợp không sử dụng đầy công suất.

2️⃣ On‑Demand Instances (đánh dấu [SAI])

• Giải thích: Trả tiền theo giờ (hoặc giây) cho mỗi instance, không cam kết dài hạn, linh hoạt khởi tạo và dừng bất cứ lúc nào.
• Tại sao sai:
  • Chi phí trung bình: Dù linh hoạt, giá On‑Demand vẫn cao hơn Spot đáng kể (khoảng 2‑3×).
  • Không tận dụng được “idle capacity”: Khi server không được dùng hết, bạn vẫn trả tiền cho toàn bộ thời gian chạy.
  • Không đáp ứng mục tiêu “most cost‑effective” cho workload không quan trọng.

3️⃣ Spot Instances (đánh dấu [ĐÚNG])

• Giải thích: Mua công suất chưa được dùng tại giá thị trường hiện tại, có thể giảm giá mạnh (70‑90 % so với On‑Demand). Bạn có thể thiết lập “maximum price” hoặc “capacity‑optimized” allocation strategy.
• Lý do đúng:
  • Giá rẻ nhất cho workload có thể chịu “interruption”.
  • Tự động thay thế: Kết hợp với Spot Fleet hoặc Auto Scaling để duy trì số lượng instance mong muốn khi một instance bị thu hồi.
  • Thích hợp cho môi trường dev/test: Các môi trường này thường không yêu cầu SLA 100 % và có thể tái tạo nhanh (AMI, CloudFormation).

4️⃣ Dedicated Hosts (đánh dấu [SAI])

• Giải thích: Bạn thuê một host vật lý (đúng một hoặc nhiều máy) và kiểm soát toàn bộ instance trên host đó. Dùng để đáp ứng yêu cầu về license compliance, BYOL, hoặc quy định pháp lý.
• Tại sao sai:
  • Chi phí cực kỳ cao: Bạn trả phí cho toàn bộ host ngay cả khi không sử dụng hết CPU/RAM.
  • Không phù hợp với “occasional unavailability”: Host luôn luôn tồn tại, không thể “được thu hồi” như Spot.
  • Không cần thiết cho dev/test không có ràng buộc licensing đặc biệt.

📌 Tổng kết

• Mô hình giá tốt nhất cho môi trường development/test không yêu cầu độ sẵn sàng cao và có thể chấp nhận việc instance bị dừng là Spot Instances.
• Các lựa chọn còn lại (Reserved, On‑Demand, Dedicated Hosts) either không đủ linh hoạt hoặc chi phí quá cao so với Spot trong kịch bản này.

📚 Tham khảo (tới năm 2026)

1. Amazon EC2 Pricing – https://aws.amazon.com/ec2/pricing/ (cập nhật giá Spot, On‑Demand, Reserved, Dedicated Hosts).
2. AWS Well‑Architected Framework – Cost Optimization Pillar – https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/ (đề xuất Spot cho workload không quan trọng).
3. Amazon EC2 Spot Instances – Best Practices – https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-batch.html (cách thiết lập Spot Fleet, capacity‑optimized).
4. AWS re:Invent 2024 Session “New Spot Instance Features & Pricing Enhancements” – video và slide (giới thiệu các cải tiến về Spot Capacity‑Optimized Allocation Strategy).

💡 Mẹo thực tiễn: Khi triển khai Spot cho dev/test, hãy tạo Launch Template với InstanceInterruptionBehavior = stop (đối với Amazon Linux, Windows) và cấu hình Auto Scaling group với MixedInstancesPolicy để tự động chuyển sang On‑Demand khi Spot không khả dụng. Điều này giúp duy trì độ ổn định tối thiểu mà vẫn tận dụng được mức giá thấp nhất.

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

Công ty đang chạy ứng dụng trên Amazon EC2.
Ứng dụng đôi khi gặp tăng đột biến về nhu cầu (traffic spikes).
Mục tiêu của họ là đáp ứng nhanh với thay đổi nhu cầu và giảm chi phí tối đa.

Vì vậy câu hỏi đang tìm dịch vụ hoặc khái niệm AWS giúp:

1. Tự động điều chỉnh số lượng tài nguyên tính toán (thêm hoặc bớt EC2) khi tải thay đổi.
2. Chi phí phải trả chỉ cho tài nguyên thực sự cần thiết (không giữ máy ảo thừa khi tải giảm).

✅ Đáp án đúng: AWS Auto Scaling

• AWS Auto Scaling (trong EC2 Auto Scaling và các dịch vụ khác như ECS, DynamoDB, Aurora, …) tự động tăng hoặc giảm số lượng instance dựa trên các scaling policy (ví dụ: CPU utilization, request count, custom CloudWatch metric).
• Khi nhu cầu tăng, nó khởi chạy thêm EC2 ngay lập tức; khi nhu cầu giảm, nó tắt/đặt instance vào trạng thái stopped hoặc terminate để tránh trả tiền thừa.
• Kết hợp với Launch Templates/Launch Configurations và Target Tracking Policies, Auto Scaling giúp đạt chi phí thấp nhất trong khi vẫn duy trì độ sẵn sàng và hiệu suất.
• Tính năng Instance Refresh và Predictive Scaling (được cải tiến liên tục tới năm 2026) cho phép dự đoán xu hướng tải và chuẩn bị tài nguyên trước, giảm độ trễ khi “bùng nổ” nhu cầu.

Do đó, AWS Auto Scaling là giải pháp đáp ứng cả yêu cầu “đáp ứng thay đổi nhu cầu” và “chi phí thấp nhất”.

❌ Giải thích các lựa chọn sai

• AWS Compute Optimizer

  • Compute Optimizer là dịch vụ đề xuất loại instance, kích thước và cấu hình dựa trên phân tích sử dụng hiện tại để tối ưu hoá chi phí và hiệu suất.
  • Nó không tự động mở rộng/thu hẹp số lượng instance khi tải thay đổi; chỉ cung cấp khuyến nghị.
  • Vì vậy không đáp ứng yêu cầu “đáp ứng nhanh với tăng đột biến”.

• AWS Cost Explorer

  • Cost Explorer giúp phân tích, trực quan hoá và dự báo chi phí của các dịch vụ AWS.
  • Nó là công cụ báo cáo tài chính, không có khả năng tự động thay đổi tài nguyên.
  • Không thể “đáp ứng nhu cầu” hay “giảm chi phí” một cách tự động.

• AWS Well-Architected Framework

  • Well-Architected Framework là bộ hướng dẫn và best‑practice để thiết kế, vận hành hệ thống trên AWS an toàn, hiệu quả và có khả năng mở rộng.
  • Nó không phải là một dịch vụ thực thi; chỉ cung cấp đánh giá và khuyến nghị.
  • Vì vậy không phải là giải pháp “công cụ tự động đáp ứng nhu cầu”.

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

1. Amazon EC2 Auto Scaling Documentation – https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html
2. Predictive Scaling – New features 2025‑2026 – https://aws.amazon.com/blogs/aws/predictive-scaling-enhancements/
3. AWS Compute Optimizer – Overview – https://docs.aws.amazon.com/compute-optimizer/latest/guide/what-is.html
4. AWS Cost Explorer – User Guide – https://docs.aws.amazon.com/cost-management/latest/userguide/cost-explorer-what-it-does.html
5. AWS Well‑Architected Framework – https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html

🧩 Kết luận:
Để đáp ứng “tăng đột biến nhu cầu” và “giảm chi phí tối đa”, AWS Auto Scaling là dịch vụ phù hợp nhất. Các tùy chọn còn lại chỉ hỗ trợ phân tích, đề xuất hoặc cung cấp khung kiến trúc, chứ không thực hiện việc tự động mở rộng/thu hẹp tài nguyên theo thời gian thực. 🚀