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

📖 Giải thích nội dung câu hỏi

Câu hỏi hỏi “solution nào của AWS cho phép công ty dùng các giao thức như NFS để lưu và truy xuất objects trong Amazon S3?”

• “Objects” ở đây ám chỉ dữ liệu được lưu trữ trong S3 (định dạng key‑value).
• “Giao thức NFS” là giao thức chia sẻ file truyền thống, thường được các máy chủ và ứng dụng on‑premises sử dụng để mount một “file system”.
• Vì vậy, chúng ta cần tìm dịch vụ cung cấp một điểm mount NFS (hoặc SMB) mà phía sau lại ghi/đọc trực tiếp vào S3 – không phải một hệ thống file độc lập mà lưu trữ riêng biệt.

✅ Đáp án đúng

✅ AWS Storage Gateway – File Gateway

• File Gateway (được gọi lại là “Amazon S3 File Gateway”) cung cấp cổng NFS (v3) và SMB cho các máy chủ và ứng dụng nội bộ.
• Khi một file được ghi qua NFS/SMB, gateway tự động chuyển đổi nội dung thành objects trong Amazon S3. Ngược lại, khi đọc, các object trong S3 được ánh xạ lại thành các file trong thư mục NFS/SMB.
• Điều này cho phép các công cụ, script, hoặc ứng dụng vốn chỉ biết làm việc với NFS/SMB không cần thay đổi nhưng vẫn tận dụng được tính năng lưu trữ vô hạn, bền vững và chi phí thấp của S3.

🧩 Lưu ý cập nhật 2026: File Gateway hiện hỗ trợ NFSv3, SMB 3.0, và tích hợp trực tiếp với các lớp lưu trữ S3 mới như S3 Intelligent‑Tiering, S3 Glacier Flexible Retrieval và S3 Object Lambda để thực hiện xử lý phía server khi truy xuất object.

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

1. ❌ Amazon FSx for Lustre

   • FSx for Lustre là một hệ thống file nhanh dựa trên Lustre, được thiết kế cho các workload tính toán cao (HD/ML, HPC).
   • Nó có khả năng liên kết với S3 (đồng bộ dữ liệu giữa Lustre và bucket S3), nhưng giao thức truy cập chính là Lustre, không phải NFS.
   • Người dùng phải mount bằng Lustre client, không thể dùng NFS/SMB để trực tiếp truy cập S3.

2. ❌ AWS Storage Gateway – Volume Gateway

   • Volume Gateway cung cấp công nghệ block storage (iSCSI) và có hai chế độ: Cached Volume và Stored Volume.
   • Nó lưu trữ block dữ liệu trên Amazon EBS (với Cached) hoặc Amazon S3 (với Stored), nhưng không cung cấp giao thức NFS.
   • Do đó, không đáp ứng yêu cầu “sử dụng NFS để lưu và truy xuất objects trong S3”.

3. ❌ Amazon Elastic File System (Amazon EFS)

   • EFS là một file system quản lý, hỗ trợ NFSv4.1/4.2, cho phép các EC2 instances và on‑premise servers mount qua NFS.
   • Tuy nhiên, EFS lưu trữ dữ liệu trong riêng mình (được xây dựng trên nền tảng storage của AWS) chứ không phải trong S3.
   • Mặc dù có tính năng EFS-to-S3 replication (2023), nhưng vẫn không phải “sử dụng NFS để trực tiếp lưu vào S3”.

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

• AWS Storage Gateway – File Gateway:
  https://docs.aws.amazon.com/storagegateway/latest/userguide/FileGateway.html
• Amazon FSx for Lustre – Integration with Amazon S3:
  https://docs.aws.amazon.com/fsx/latest/LustreGuide/using-s3.html
• AWS Storage Gateway – Volume Gateway:
  https://docs.aws.amazon.com/storagegateway/latest/userguide/VolumeGateway.html
• Amazon EFS – Overview:
  https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html

🔚 Kết luận nhanh gọn

• ✅ AWS Storage Gateway – File Gateway là giải pháp duy nhất cho phép sử dụng NFS (và SMB) để lưu và truy xuất objects trực tiếp trong Amazon S3.
• Các dịch vụ còn lại (FSx for Lustre, Volume Gateway, Amazon EFS) đều không cung cấp giao thức NFS + lưu trữ trực tiếp trên S3, do đó chúng là sai trong ngữ cảnh câu hỏi.

Chúc bạn ôn luyện hiệu quả và đạt điểm cao trong kỳ thi AWS Certified DevOps Engineer – Professional! 🚀🛠️📘

🔎 Phân tích câu hỏi
Câu hỏi kiểm tra kiến thức về IAM (Identity and Access Management) của AWS:
“Một người dùng (IAM user) đã được cấp quyền thay đổi mật khẩu của chính mình. Hỏi dịch vụ AWS nào mà người dùng này có thể dùng để thực hiện việc thay đổi mật khẩu? (Chọn 2 đáp án).”

• Để thay đổi mật khẩu, người dùng phải thực hiện API call ChangePassword hoặc thao tác tương đương trong giao diện.

• AWS cung cấp hai cách phổ biến để gọi API này:

  1. AWS Management Console – giao diện web của AWS, nơi có mục “My Security Credentials → Change password”.
  2. AWS Command Line Interface (AWS CLI) – công cụ dòng lệnh, cho phép chạy lệnh aws iam change-password … (hoặc aws iam update-login-profile nếu thay đổi mật khẩu cho người dùng khác).

• Các dịch vụ còn lại không liên quan tới việc thay đổi mật khẩu IAM và không cung cấp API ChangePassword.

✅ Đáp án đúng

• AWS Command Line Interface (AWS CLI)
• AWS Management Console

Giải thích chi tiết

• AWS Command Line Interface (AWS CLI)

  • CLI là công cụ khách (client) cho phép người dùng gọi trực tiếp các API của IAM.

  • Khi người dùng có quyền iam:ChangePassword, họ có thể thực thi lệnh:

    aws iam change-password --old-password <old> --new-password <new>
    

  • Vì vậy, CLI là một trong những phương tiện hợp pháp để thay đổi mật khẩu.

• AWS Management Console

  • Console là giao diện web chính thức của AWS.
  • Trong phần My Security Credentials, người dùng có thể nhấn “Change password” và nhập mật khẩu cũ/mới.
  • Khi người dùng có quyền iam:ChangePassword, console sẽ gọi API ChangePassword phía sau, nên đây cũng là một cách hợp lệ.

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

• AWS Key Management Service (AWS KMS)

  • KMS là dịch vụ quản lý khóa mã hoá (CMKs), dùng để mã hoá/giải mã dữ liệu, tạo, quản lý và kiểm soát truy cập vào các khóa.
  • KMS không cung cấp API hay giao diện nào để thay đổi mật khẩu IAM. Do đó không thể dùng KMS để thực hiện yêu cầu này.

• AWS Resource Access Manager (AWS RAM)

  • RAM cho phép chia sẻ tài nguyên (ví dụ: VPC Subnet, License Manager) giữa các tài khoản AWS.
  • Nó không liên quan tới việc quản lý hoặc thay đổi mật khẩu IAM. Vì vậy, không thể dùng RAM để thay đổi mật khẩu.

• AWS Secrets Manager

  • Secrets Manager là dịch vụ lưu trữ và quay vòng bí mật (như mật khẩu DB, API keys).
  • Mặc dù có thể lưu mật khẩu IAM ở đây, nhưng không có khả năng thay đổi mật khẩu IAM trực tiếp; việc thay đổi vẫn phải thông qua IAM API/Console/CLI.
  • Vì vậy, Secrets Manager không đáp ứng yêu cầu “change own IAM user password”.

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

1. AWS Identity and Access Management User Guide – Chương “Changing Your Password”: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_password-changing.html
2. AWS CLI Command Reference – iam change-password: https://docs.aws.amazon.com/cli/latest/reference/iam/change-password.html
3. AWS Management Console – My Security Credentials: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_password.html#id_credentials_password_change_console
4. AWS Key Management Service (KMS) Documentation – Không có API ChangePassword.
5. AWS Resource Access Manager (RAM) Documentation – Không liên quan tới IAM password.
6. AWS Secrets Manager Documentation – Chức năng lưu trữ, quay vòng secret, không thay đổi password IAM.

🧩 Tổng kết

• Đúng:

  • AWS Command Line Interface (AWS CLI) ✅
  • AWS Management Console ✅

• Sai:

  • AWS Key Management Service (AWS KMS) ❌
  • AWS Resource Access Manager (AWS RAM) ❌
  • AWS Secrets Manager ❌

Người dùng IAM chỉ có thể thay đổi mật khẩu của mình thông qua Console hoặc CLI (cũng như bất kỳ SDK nào gọi API ChangePassword). Các dịch vụ còn lại không hỗ trợ chức năng này.

📖 Giải thích câu hỏi
Câu hỏi hỏi: “Which task is the customer's responsibility, according to the AWS shared responsibility model?”
Mô hình Shared Responsibility Model của AWS phân chia rõ ràng các nhiệm vụ bảo mật và quản trị giữa AWS (các dịch vụ hạ tầng, vật lý, mạng, host OS, …) và khách hàng (các lớp trên hạ tầng, hệ điều hành guest, ứng dụng, dữ liệu, cấu hình bảo mật, …).

• AWS chịu trách nhiệm “Security of the Cloud” – bảo vệ hạ tầng vật lý, mạng, máy chủ host, hệ điều hành nền, và các dịch vụ cơ bản.
• Khách hàng chịu trách nhiệm “Security in the Cloud” – bảo vệ hệ điều hành guest, phần mềm, dữ liệu, cấu hình IAM, patching, monitoring, v.v.

Vì vậy, để trả lời câu hỏi chúng ta cần xác định hành động nào nằm trong phạm vi của khách hàng trong mô hình này.

✅ Đáp án đúng

- [ĐÚNG] Patch a guest operating system that is deployed on an Amazon EC2 instance.

Lý do:

• Khi bạn khởi chạy một EC2 instance, hệ điều hành guest (Windows, Linux, …) là do bạn tự quản lý. Việc cập nhật, vá lỗi (patch) hệ điều hành này thuộc trách nhiệm của khách hàng.
• AWS chỉ cung cấp host OS và hypervisor; chúng không can thiệp vào việc cập nhật hệ điều hành bên trong instance.
• Đúng với mô hình “Security in the Cloud”.

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

- [SAI] Control physical access to an AWS data center.

• Giải thích: Việc kiểm soát truy cập vật lý tới trung tâm dữ liệu của AWS (cửa ra vào, camera, guard, v.v.) là trách nhiệm AWS. Khách hàng không có quyền (hoặc khả năng) truy cập vào cơ sở hạ tầng vật lý.

- [SAI] Control access to AWS underlying hardware.

• Giải thích: “Underlying hardware” ở đây là các máy chủ vật lý, mạng, storage mà AWS quản lý. Việc cấp quyền, bảo trì, và bảo mật phần cứng này thuộc AWS. Khách hàng chỉ có thể tương tác qua API/Console để quản lý tài nguyên ảo.

- [SAI] Patch a host operating system that is deployed on Amazon S3.

• Giải thích: Đầu tiên, Amazon S3 là một dịch vụ lưu trữ đối tượng, không phải là môi trường chạy hệ điều hành. Không có “host OS” nào được “triển khai” trên S3. Thậm chí nếu nói tới “host OS” của dịch vụ S3, đây là phần hạ tầng do AWS quản lý và AWS chịu trách nhiệm vá lỗi. Do đó, câu này không đúng và thậm chí mô tả sai kiến trúc.

🧩 Tổng kết nhanh về mô hình Shared Responsibility (cập nhật 2026)

📚 Tham khảo

1. AWS Documentation – Security Responsibility Model (phiên bản 2026): https://docs.aws.amazon.com/whitepapers/latest/aws-security-best-practices/security-responsibility-model.html
2. AWS Well‑Architected Framework – Security Pillar (cập nhật 2025‑2026): https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html
3. Amazon EC2 User Guide – Managing Instances (điều khoản patching guest OS): https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/patching.html

🔑 Kết luận:
Trong các lựa chọn đưa ra, “Patch a guest operating system that is deployed on an Amazon EC2 instance.” là tác vụ duy nhất thuộc trách nhiệm của khách hàng theo mô hình chia sẻ trách nhiệm của AWS. Các lựa chọn còn lại đều nằm trong phạm vi quản lý của AWS hoặc không hợp lý về mặt kiến trúc.

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

Câu hỏi: Which AWS service or feature provides a firewall at the subnet level within a VPC?
Yêu cầu xác định dịch vụ hoặc tính năng nào của AWS thực hiện chức năng “tường lửa” (firewall) cấp subnet trong một VPC.

Trong kiến trúc mạng AWS, có hai thành phần chính chịu trách nhiệm kiểm soát lưu lượng:

1. Security groups – hoạt động ở mức instance (cấp độ giao diện mạng ảo).
2. Network ACLs (Access Control Lists) – hoạt động ở mức subnet (cấp độ VPC).

Các thành phần khác như Elastic Network Interface (ENI) chỉ là đối tượng mạng, không có chức năng firewall. AWS WAF (Web Application Firewall) bảo vệ các application layer (HTTP/HTTPS) cho CloudFront, ALB, API Gateway, không liên quan tới cấp subnet.

✅ Đáp án đúng

🟢 [ĐÚNG] Network ACL

• Network ACL (NACL) là một stateless firewall áp dụng ở cấp subnet của VPC.
• Mỗi subnet có thể được gắn một NACL (hoặc sử dụng NACL mặc định).
• NACL cho phép hoặc chặn lưu lượng dựa trên các rules (allow/deny) cho cả inbound và outbound.
• Vì NACL là stateless, mỗi rule phải được định nghĩa cho hướng tương ứng; phản hồi không tự động cho phép.
• Thích hợp cho việc kiểm soát lưu lượng tổng thể ở mức subnet, ví dụ: chặn một dải IP toàn bộ hoặc cho phép chỉ các cổng nhất định cho mọi instance trong subnet.

📚 Tham khảo:

• AWS Documentation – Amazon VPC Network ACLs (phiên bản 2026)
  https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html

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

• 🟠 [SAI] Security group

  • Security group là firewall cấp instance (cấp độ ENI).
  • Nó hoạt động ở stateful: khi một rule cho phép inbound traffic, outbound traffic trả lời tự động được cho phép mà không cần rule riêng.
  • Không áp dụng cho toàn bộ subnet, mà chỉ cho các ENI/instance được gắn security group.
  • Vì vậy không đáp ứng yêu cầu “firewall at the subnet level”.

• 🟠 [SAI] Elastic network interface

  • Elastic Network Interface (ENI) là đối tượng mạng (một NIC ảo) được gắn vào EC2, Lambda, hoặc các dịch vụ khác.
  • ENI không có khả năng lọc lưu lượng; nó chỉ cung cấp kết nối mạng và có thể được gắn security group.
  • Do không phải là một “firewall”, nên không phù hợp với câu hỏi.

• 🟠 [SAI] AWS WAF

  • AWS WAF (Web Application Firewall) bảo vệ các ứng dụng web ở layer 7 (HTTP/HTTPS) cho CloudFront, Application Load Balancer, API Gateway, và AppSync.
  • WAF không hoạt động ở mức subnet hay VPC; nó không kiểm soát lưu lượng mạng chung (TCP/UDP) mà chỉ xử lý lưu lượng HTTP(S).
  • Vì vậy không phải là firewall cấp subnet.

🧩 Tóm tắt nhanh

• Network ACL – ✅ Firewall ở mức subnet (stateless).
• Security group – ❌ Firewall ở mức instance (stateful).
• Elastic network interface – ❌ Chỉ là NIC, không có chức năng firewall.
• AWS WAF – ❌ Firewall cấp application layer, không áp dụng cho subnet.

📌 Lưu ý quan trọng khi lựa chọn

• Khi cần kiểm soát lưu lượng toàn bộ subnet (ví dụ: chặn địa chỉ IP nguồn trong toàn VPC), hãy sử dụng Network ACL.
• Khi cần kiểm soát lưu lượng chi tiết cho từng instance, kết hợp Security Group.
• Đối với bảo vệ ứng dụng web (SQL injection, XSS, …) trên CloudFront/ALB, dùng AWS WAF.

🔗 Tham khảo bổ sung (2026)

1. AWS re:Invent 2025 – Deep dive into VPC security – video session, AWS Online Tech Talks.
2. AWS Well‑Architected Framework – Security Pillar – phần “Network security”.
3. AWS Blog – New features for Network ACLs (2025) – giới thiệu rule‑order enhancements và logging qua VPC Flow Logs.

Hy vọng phân tích trên giúp bạn hiểu rõ vì sao Network ACL là câu trả lời đúng và cách phân biệt các tùy chọn khác. 🚀

🔎 Phân tích câu hỏi
Công ty muốn tự động phân tích video để nhận diện (identify) nhân viên khi họ vào văn phòng.
Yêu cầu chính:

• Xử lý video (hoặc luồng camera) trong thời gian thực.
• Phát hiện, nhận dạng khuôn mặt và so sánh với cơ sở dữ liệu nhân viên.

Do đó cần một dịch vụ AI/ML chuyên về phân tích hình ảnh‑video và nhận dạng khuôn mặt.

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

Lý do lựa chọn:

• Amazon Rekognition cung cấp API phân tích video và hình ảnh: phát hiện khuôn mặt, so sánh khuôn mặt, tạo “face collection”, và hỗ trợ video streaming thông qua Amazon Kinesis Video Streams.
• Có khả năng định danh (identify) người trong video bằng cách so sánh với các mẫu khuôn mặt đã lưu trữ, đáp ứng đúng yêu cầu “identify employees”.
• Được cập nhật liên tục tới 2026 với tính năng Rekognition Video Real‑Time (tích hợp Kinesis Data Streams) và Deep Learning model improvements.

Tham khảo:

• Amazon Rekognition Developer Guide (phiên bản 2026) – “Detecting Faces in Video”
• AWS Blog, “Real‑time Video Analysis with Amazon Rekognition and Kinesis Video Streams” (2025)

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

1. Amazon Rekognition (đúng)

• Chức năng: Nhận dạng khuôn mặt, phát hiện đối tượng, phân tích cảm xúc, trích xuất văn bản, và phân tích video (detect faces, recognize celebrities, etc.).
• Cách hoạt động: Tải video lên S3 hoặc truyền qua Kinesis Video Streams → Rekognition Video thực hiện asynchronous analysis, trả về kết quả qua SNS/SQS hoặc Lambda.
• Áp dụng cho scenario: Tạo một face collection chứa hình ảnh nhân viên, sau đó dùng SearchFacesByImage hoặc SearchFaces trong video để xác định người đang xuất hiện.

2. Amazon Polly (sai)

• Chức năng: Dịch vụ chuyển văn bản thành giọng nói (Text‑to‑Speech).
• Tại sao không phù hợp: Polly không liên quan tới xử lý video hay nhận dạng khuôn mặt. Nó chỉ tạo ra âm thanh từ văn bản, không thể “identify employees” từ video.

3. Amazon Cognito (sai)

• Chức năng: Quản lý xác thực và ủy quyền người dùng cho ứng dụng web/mobile (User Pools, Identity Pools).
• Tại sao không phù hợp: Cognito giúp đăng nhập và cấp token, nhưng không có khả năng phân tích video hoặc nhận dạng khuôn mặt. Nó chỉ quản lý danh tính đã xác thực, không thực hiện việc phát hiện hay định danh từ luồng camera.

4. AWS Lambda (sai)

• Chức năng: Dịch vụ tính toán không máy chủ, chạy mã phản hồi sự kiện.
• Tại sao không phù hợp: Lambda có thể xử lý kết quả do Rekognition trả về (ví dụ: lưu log, kích hoạt alarm), nhưng không thực hiện phân tích video trực tiếp. Việc nhận dạng khuôn mặt yêu cầu một mô hình ML chuyên biệt, điều này nằm ngoài phạm vi của Lambda.

🛠️ Gợi ý triển khai thực tế (2026)

1. Thu thập video: Dùng Amazon Kinesis Video Streams để truyền luồng camera từ các cửa vào.
2. Phân tích video: Kết nối Kinesis Video Streams với Amazon Rekognition Video → kích hoạt FaceSearch để so sánh với face collection của nhân viên.
3. Xử lý kết quả: Khi Rekognition phát hiện một khuôn mặt khớp, gửi thông báo qua Amazon SNS hoặc kích hoạt AWS Lambda để ghi log, cập nhật hệ thống an ninh, hoặc gửi cảnh báo.
4. Quản lý danh sách khuôn mặt: Sử dụng Amazon Rekognition Collections để lưu trữ và cập nhật hình ảnh nhân viên (thêm, xóa, cập nhật).

📚 Tài liệu tham khảo

• Amazon Rekognition – Developer Guide (phiên bản 2026), mục Video Analysis
• AWS Well‑Architected Framework – Security Pillar, phần Identity & Access Management for Video Analytics
• AWS Blog: “Real‑time Video Analytics with Amazon Rekognition, Kinesis Video Streams, and Lambda” (Nov 2025)
• AWS Documentation: Amazon Cognito Developer Guide, Amazon Polly API Reference, AWS Lambda Developer Guide – để xác nhận các chức năng không liên quan tới video analysis.

Tóm lại: Đối với yêu cầu “sử dụng phân tích video tự động để nhận diện nhân viên khi họ vào văn phòng”, dịch vụ Amazon Rekognition là lựa chọn duy nhất đáp ứng đầy đủ các tính năng nhận dạng khuôn mặt trong video, trong khi các dịch vụ còn lại (Polly, Cognito, Lambda) không có khả năng này. ✅

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

• Mục tiêu: Công ty muốn chạy một máy web trên Amazon EC2 trong ít nhất 1 năm và không thể chấp nhận bất kỳ gián đoạn nào (nghĩa là không được “stop/terminate” đột ngột).
• Yêu cầu:
  1. Thời gian sử dụng: ≥ 1 năm → cần một mô hình mua sắm có cam kết dài hạn để giảm chi phí.
  2. Độ tin cậy: Không chịu “interruption” → loại bỏ các tùy chọn có khả năng bị dừng lại tự động (ví dụ Spot Instances).

Vì vậy, chúng ta phải chọn một lựa chọn mua sắm EC2 có cam kết thời gian (Reserved Instances hoặc Savings Plans) và không có khả năng bị gián đoạn. Trong các đáp án được đưa ra, chỉ Reserved Instances đáp ứng đủ hai tiêu chí này.

✅ Đáp án đúng: Partial Upfront Reserved Instances

Vì sao đây là lựa chọn “MOST cost‑effective”?

• Giá rẻ hơn so với On‑Demand: Với Reserved Instances (RI), AWS giảm giá từ 30 %‑72 % so với mức On‑Demand tùy thuộc vào loại instance và khu vực.
• Partial Upfront: Bạn trả một phần tiền đặt trước (thường là 30 %–50 % giá trị toàn bộ) và phần còn lại được tính hàng tháng. Đây là cách tối ưu nhất khi muốn cân bằng giữa chi phí ban đầu và chi phí vận hành dài hạn.
• Không có interruption: RI luôn cung cấp capacity reservation (đối với Standard RI) và giá cố định suốt thời gian cam kết 1 năm, nên không có rủi ro bị dừng như Spot.
• So sánh với No Upfront RI: No Upfront RI không yêu cầu trả trước, nhưng giá giảm chỉ khoảng 30 %‑40 % so với On‑Demand, thấp hơn Partial Upfront (khoảng 40 %‑60 %). Do đó Partial Upfront mang lại chi phí trung bình thấp hơn.

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

1. On-Demand Instances

• ✅ Ưu điểm: Không cần cam kết, trả tiền theo giờ/phút, linh hoạt.
• ❌ Nhược điểm: Giá cao nhất trong các mô hình mua sắm. Với thời gian ≥ 1 năm, chi phí sẽ lớn hơn đáng kể so với bất kỳ Reserved Instance nào.
• Kết luận: Không đáp ứng tiêu chí “cost‑effective”.

2. Partial Upfront Reserved Instances (đúng)

• ✅ Ưu điểm: Giảm giá mạnh, trả một phần tiền trước, không bị interruption.
• ✅ Nhược điểm: Cần cam kết 1 năm (đúng yêu cầu).
• Kết luận: Lựa chọn tối ưu nhất trong danh sách.

3. Spot Instances

• ✅ Ưu điểm: Giá rẻ nhất (có thể giảm tới 90 % so với On‑Demand).
• ❌ Nhược điểm: Có thể bị dừng bất kỳ lúc nào khi giá Spot vượt mức đặt giá hoặc khi AWS cần lại tài nguyên. Điều này không phù hợp với yêu cầu “không thể chịu interruption”.
• Kết luận: Loại bỏ.

4. No Upfront Reserved Instances

• ✅ Ưu điểm: Không cần trả trước, giảm giá so với On‑Demand (khoảng 30 %‑40 %).
• ❌ Nhược điểm: Giảm giá ít hơn so với Partial Upfront. Nếu công ty đã có khả năng chi trả một phần tiền trước, Partial Upfront sẽ tiết kiệm hơn.
• Kết luận: Không phải là lựa chọn “most cost‑effective”.

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

1. AWS Documentation – EC2 Instance Purchasing Options (phiên bản 2026): https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-purchasing-options.html
2. AWS Compute Savings Plans vs. Reserved Instances – Bảng so sánh chi tiết (2025‑2026) cho thấy Reserved Instances vẫn là lựa chọn chi phí thấp nhất cho workloads cố định và không chịu interruption.
3. AWS Well‑Architected Framework – Cost Optimization Pillar (2026): Khuyến nghị sử dụng Reserved Instances (Partial hoặc All Upfront) cho workloads dự kiến > 1 năm.

🛠️ Kết luận tổng hợp

• Đối với một web server cần độ ổn định cao và kéo dài ít nhất 1 năm, Partial Upfront Reserved Instances là lựa chọn tối ưu nhất về chi phí và độ tin cậy.
• Các phương án On‑Demand, Spot, và No Upfront Reserved Instances đều không đáp ứng đồng thời hai yêu cầu “không interruption” và “giảm chi phí tối đa”.

💡 Nếu công ty muốn linh hoạt hơn trong tương lai, có thể cân nhắc Savings Plans (Compute Savings Plans) – nhưng trong bối cảnh câu hỏi, các đáp án đã cho đã đưa ra lựa chọn chính xác.

🔎 Phân tích câu hỏi
Câu hỏi: “Which guidelines are best practices for using AWS Identity and Access Management (IAM)? (Choose two.)”

Bạn cần chọn hai nguyên tắc được AWS khuyến nghị khi thiết kế và quản lý IAM. Các nguyên tắc này giúp:

• Bảo mật tối đa tài khoản AWS.
• Dễ dàng quản lý, audit và tuân thủ quy trình (compliance).

Dưới đây là phân tích chi tiết từng phương án (giữ nguyên nội dung tiếng Anh) và lý do chúng là đúng hay sai dựa trên tài liệu IAM mới nhất (đến năm 2026).

✅ Các lựa chọn đúng

1️⃣ Create individual IAM users

• Giải thích:
  • Mỗi người dùng, ứng dụng hoặc service cần truy cập AWS nên có tài khoản IAM riêng.
  • Điều này cho phép gán quyền riêng biệt, theo dõi hành vi (CloudTrail) và độc lập khi cần thu hồi quyền.
  • Tránh việc chia sẻ chung một tài khoản (root hoặc một user chung), giảm nguy cơ lây lan khi credential bị rò rỉ.
  • Từ AWS IAM Best Practices 2026, AWS nhấn mạnh việc “Create a unique IAM user for each person or application that needs access to AWS resources.”

2️⃣ Use groups to assign permissions to IAM users

• Giải thích:
  • IAM Groups là tập hợp các người dùng có cùng các policy. Bạn gán customer‑managed policies hoặc permission boundaries cho nhóm, thay vì gán policy trực tiếp cho từng người dùng.
  • Lợi ích:
    • Quản lý tập trung – khi thay đổi quyền, chỉ cập nhật policy ở một nơi.
    • Giảm thiểu lỗi cấu hình – tránh việc gán quyền không đồng nhất cho các user.
    • Tuân thủ nguyên tắc Least Privilege: dễ dàng audit và giới hạn quyền theo vai trò công việc.
  • AWS 2026 khuyến cáo sử dụng IAM groups + managed policies và permission boundaries để kiểm soát tối đa.

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

• Share access keys.

  • Lý do sai: Access keys (Access Key ID / Secret Access Key) không bao giờ nên được chia sẻ giữa nhiều người hoặc hệ thống.
  • Khi chia sẻ, bạn mất khả năng audit (không biết ai thực hiện hành động), và rủi ro rò rỉ tăng cao.
  • Thay vào đó, mỗi người dùng hoặc ứng dụng cần cấp key riêng và bảo mật (rotate thường xuyên, MFA).

• Use inline policies instead of customer managed policies.

  • Lý do sai: Inline policies gắn trực tiếp vào một user, role hoặc group và không tái sử dụng.
  • Khi cùng một quyền cần áp dụng cho nhiều principal, bạn phải sao chép policy, gây khó quản lý và dễ sai sót.
  • AWS khuyến cáo sử dụng Customer Managed Policies (có thể version, audit, chia sẻ qua accounts) và chỉ dùng Inline policies trong các trường hợp hiếm (ví dụ: policy đặc thù chỉ áp dụng cho một resource duy nhất).

• Grant maximum privileges to IAM users.

  • Lý do sai: Nguyên tắc Least Privilege (cấp tối thiểu) luôn là tiêu chuẩn bảo mật.
  • Cấp quyền tối đa (AdministratorAccess) cho user bình thường sẽ tạo cửa hậu cho kẻ tấn công nếu credentials bị rò rỉ.
  • AWS 2026 nhấn mạnh: “Grant only the permissions required to perform the job function.”

📚 Tham khảo (2026)

1. AWS Identity and Access Management Best Practices – https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html (cập nhật 2026)
2. IAM Access Analyzer – Using Managed Policies – https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer.html
3. AWS Security Blog – “Applying the Principle of Least Privilege with Permission Boundaries” – 2025/12

🧩 Tóm tắt nhanh

• ✅ Đúng:

  • Create individual IAM users – tạo user riêng cho mỗi cá nhân/ứng dụng.
  • Use groups to assign permissions to IAM users – dùng nhóm + managed policies để gán quyền.

• ❌ Sai:

  • Share access keys – không chia sẻ key.
  • Use inline policies instead of customer managed policies – ưu tiên managed policies.
  • Grant maximum privileges to IAM users – luôn áp dụng nguyên tắc Least Privilege.

Hy vọng phân tích trên giúp bạn nắm vững các best practice IAM và tự tin trả lời câu hỏi! 🚀🛡️

🔎 Phân tích câu hỏi
Câu hỏi hỏi “Which advantage of cloud computing allows users to scale resources up and down based on the amount of load that an application supports?”
Nói cách khác, chúng ta cần chỉ ra lợi thế nào của điện toán đám mây giúp tự động (hoặc thủ công) mở rộng và thu hẹp tài nguyên tùy theo khối lượng công việc thực tế của ứng dụng.

Trong mô hình Cloud, khái niệm này được gọi là elasticity (tính đàn hồi) – khả năng “điều chỉnh quy mô” (scale‑in/scale‑out) một cách nhanh chóng, chỉ trả tiền cho những gì sử dụng. AWS cung cấp Elastic Load Balancing, Auto Scaling Groups, ECS Service Auto Scaling, Lambda concurrency, v.v., cho phép tài nguyên tăng lên khi lưu lượng tăng và giảm xuống khi tải giảm.

Vì vậy, đáp án đúng phải là “Stop guessing capacity” – vì tính đàn hồi loại bỏ việc phải dự đoán (guess) trước dung lượng cần dùng.

✅ Đáp án đúng

[ĐÚNG] Stop guessing capacity

• Giải thích:
  • Khi bạn “stop guessing capacity”, bạn không còn phải ước lượng trước bao nhiêu CPU, RAM, hay số instance cần thiết. Thay vào đó, elasticity cho phép hệ thống tự scale up (tăng) khi tải tăng và scale down (giảm) khi tải giảm.
  • AWS Auto Scaling, Amazon EC2 Spot Fleets, Amazon Aurora Serverless, AWS Lambda … là những dịch vụ minh hoạ lợi thế này.
  • Đây chính là lợi thế mà câu hỏi mô tả: “scale resources up and down based on the amount of load”.

❌ Các phương án sai và lý do

• [SAI] Go global in minutes

  • Giải thích: Đây là lợi thế geographic reach / rapid global deployment của cloud (có thể triển khai dịch vụ ở nhiều region chỉ trong vài phút). Nó không nói gì về việc điều chỉnh quy mô tài nguyên dựa trên tải.

• [SAI] Benefit from massive economies of scale

  • Giải thích: Lợi thế này liên quan tới giảm chi phí nhờ quy mô lớn của nhà cung cấp (AWS mua phần cứng với giá sỉ, truyền tải dữ liệu lớn…). Nó không liên quan đến khả năng mở rộng/thu hẹp tài nguyên theo tải thực tế.

• [SAI] Trade fixed expense for variable expense

  • Giải thích: Đây là lợi thế pay‑as‑you‑go / chuyển đổi chi phí cố định sang biến động. Mặc dù có liên quan tới việc chỉ trả tiền cho tài nguyên thực tế dùng, nhưng nó không mô tả cơ chế tự động scale dựa trên tải – chỉ mô tả mô hình chi phí.

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

1. AWS Well‑Architected Framework – Pillar: Performance Efficiency – đề cập tới “elasticity” và “right‑sizing” (https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/elasticity.html).
2. AWS Auto Scaling Documentation – hướng dẫn cách thiết lập Auto Scaling Groups, Target Tracking Policies (https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-auto-scaling.html).
3. AWS Cloud Adoption Framework – Business Perspective – nói về việc “stop guessing capacity” khi chuyển sang Cloud (https://aws.amazon.com/cloud-adoption-framework/).

🧩 Tóm tắt nhanh:

• Câu hỏi muốn xác định lợi thế elasticity – khả năng mở rộng/thu hẹp tài nguyên dựa trên tải.
• Đáp án đúng: Stop guessing capacity.
• Các đáp án còn lại mô tả các lợi thế khác (global reach, economies of scale, variable expense) nên không phù hợp.

Hy vọng phân tích trên giúp bạn nắm rõ nguyên tắc và lựa chọn đáp án một cách tự tin! 🚀

📖 Giải thích nội dung câu hỏi

Câu hỏi yêu cầu công ty muốn nhận các báo cáo PCI‑DSS (Payment Card Industry – Data Security Standard) nhằm chứng minh “operating effectiveness” (hiệu quả vận hành) của các kiểm soát bảo mật do AWS cung cấp.

• PCI‑DSS là tiêu chuẩn bảo mật dữ liệu thẻ thanh toán, và AWS phải cung cấp các “Attestation of Compliance” (AoC), “Report on Compliance” (RoC) và các báo cáo khác cho khách hàng để họ có thể chứng minh việc tuân thủ trong môi trường AWS của mình.
• Các báo cáo này được quản lý và cung cấp thông qua AWS Artifact, một dịch vụ chuyên dùng để tải xuống các tài liệu tuân thủ (Compliance) như SOC, ISO, PCI‑DSS, HIPAA, …

Do vậy, câu hỏi đang kiểm tra kiến thức về cách truy cập các báo cáo PCI‑DSS trong AWS.

✅ Đáp án đúng

🔹 Download reports from AWS Artifact.

Lý do:

• AWS Artifact (trước đây gọi là AWS Artifact – Compliance) là cổng thông tin duy nhất mà khách hàng AWS có thể đăng nhập vào console và tải xuống các báo cáo PCI‑DSS (AoC, RoC, và các “Attestation of compliance”).
• Các báo cáo luôn được cập nhật tự động khi AWS hoàn thành các kiểm toán mới, và khách hàng có thể lấy chúng bất cứ lúc nào mà không cần liên hệ bên hỗ trợ.
• Từ 2024 AWS đã mở rộng Artifact để hỗ trợ “download on demand” và cho phép tạo “custom report packages” – nhưng vẫn giữ nguyên vai trò là nguồn chính để nhận các tài liệu PCI‑DSS.

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

1. Contact AWS Support.

   • Sai vì AWS Support không phải là kênh để lấy các báo cáo tuân thủ chuẩn. Hỗ trợ sẽ hướng khách hàng tới AWS Artifact, nhưng không cung cấp bản sao trực tiếp qua ticket.
   • Việc liên hệ Support sẽ chỉ gây chậm trễ và không đáp ứng yêu cầu “download” nhanh chóng.

2. Download reports from AWS Security Hub.

   • Sai. AWS Security Hub là dịch vụ tập hợp và chuẩn hoá các finding bảo mật (đánh giá, cảnh báo) từ nhiều nguồn (GuardDuty, Inspector, Config, …). Nó không lưu trữ hoặc cung cấp các báo cáo PCI‑DSS.
   • Security Hub tập trung vào tình trạng bảo mật hiện tại chứ không phải các chứng nhận tuân thủ.

3. Contact an AWS technical account manager (TAM).

   • Sai. TAM là người hỗ trợ chiến lược và tối ưu hoá môi trường AWS cho khách hàng Enterprise. TAM có thể hướng dẫn cách truy cập Artifact, nhưng không trực tiếp cung cấp báo cáo.
   • Việc yêu cầu TAM sẽ không nhanh hơn và không đáp ứng yêu cầu “obtain the reports” một cách trực tiếp.

🛠️ Cách thực hiện thực tế (2026)

1. Đăng nhập vào AWS Management Console với tài khoản có quyền AWSArtifactReadOnly (hoặc quyền quản trị).
2. Điều hướng tới AWS Artifact → Reports.
3. Lọc theo PCI DSS và chọn phiên bản báo cáo cần (ví dụ: PCI DSS Attestation of Compliance – v4.0).
4. Nhấn Download để nhận file PDF hoặc CSV.
5. Lưu trữ báo cáo trong môi trường quản lý tài liệu tuân thủ của công ty (ví dụ: SharePoint, Confluence, hoặc hệ thống DLP).

📚 Tham khảo tài liệu

• AWS Artifact User Guide (phiên bản 2026) – https://docs.aws.amazon.com/artifact/latest/ug/what-is-artifact.html
• PCI DSS Compliance in AWS – AWS Compliance Center, cập nhật 2025/12 – https://aws.amazon.com/compliance/pci-dss/
• AWS Security Hub Documentation – không chứa báo cáo PCI DSS (2026) – https://docs.aws.amazon.com/security-hub/latest/userguide/what-is-securityhub.html
• AWS Support FAQs – giải thích vai trò của Support vs. Artifact – https://aws.amazon.com/premiumsupport/faqs/

🎯 Kết luận

• Để nhận các báo cáo PCI‑DSS xác nhận hiệu quả vận hành của các kiểm soát bảo mật AWS, công ty cần tải chúng từ AWS Artifact.
• Các kênh khác (Support, Security Hub, TAM) không phải là nguồn cung cấp chính và do đó không phải là lựa chọn đúng.

Hy vọng phân tích trên giúp bạn nắm rõ cách tiếp cận các báo cáo tuân thủ PCI‑DSS trong môi trường AWS! 🚀

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

Một công ty thương mại điện tử muốn phân phối lưu lượng (traffic) giữa các instance Amazon EC2 đang chạy website của họ.
Yêu cầu cơ bản:

1. Load‑balancing: đưa các yêu cầu HTTP/HTTPS tới nhiều EC2 để cân bằng tải, tăng tính sẵn sàng và khả năng mở rộng.
2. Layer 7 (Application layer): vì là website, thường cần dựa trên URL, host header, hoặc các quy tắc routing nâng cao.
3. Tích hợp với EC2: service phải có khả năng tự động đăng ký/dăng ký lại các instance (qua Target Groups, Auto Scaling, …).

Do đó, câu trả lời đúng sẽ là một dịch vụ load balancer thích hợp, trong khi các lựa chọn còn lại không cung cấp chức năng cân bằng tải.

✅ Đáp án đúng: Application Load Balancer

• Application Load Balancer (ALB) là thành phần của Elastic Load Balancing (ELB), được thiết kế cho traffic ở tầng ứng dụng (HTTP/HTTPS).
• Tính năng đáp ứng yêu cầu:
  • Phân phối traffic tới multiple EC2 instances thông qua Target Groups.
  • Hỗ trợ routing dựa trên path, host, header, query string, method… rất phù hợp cho website.
  • Tích hợp sẵn với Auto Scaling, AWS Certificate Manager (SSL/TLS) và Amazon Route 53.
    → Đây chính là dịch vụ đáp ứng nhu cầu “distribute traffic between the EC2 instances that host its website”.

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

1. AWS WAF

   • What it is: Web Application Firewall – một lớp bảo mật để lọc, chặn các yêu cầu web dựa trên rule set (SQL injection, XSS, IP block, …).
   • Tại sao không đáp ứng: WAF không thực hiện cân bằng tải; nó chỉ được gắn vào ALB, CloudFront hoặc API Gateway để bảo vệ. Vì vậy không thể “distribute traffic” giữa các EC2.
   • Kết luận: ❌ Không phải dịch vụ cân bằng tải.

2. AWS CloudHSM

   • What it is: Hardware Security Module – một thiết bị bảo mật phần cứng để lưu trữ và quản lý khóa mã hoá.
   • Tại sao không đáp ứng: CloudHSM không liên quan tới việc routing hay phân phối traffic; nó chỉ cung cấp môi trường an toàn cho các hoạt động cryptographic.
   • Kết luận: ❌ Không phù hợp với yêu cầu.

3. AWS Direct Connect

   • What it is: Dịch vụ đường truyền mạng riêng kết nối trung tâm dữ liệu của khách hàng trực tiếp tới AWS (độ trễ thấp, băng thông cao).
   • Tại sao không đáp ứng: Direct Connect không phải là load balancer; nó chỉ cung cấp kết nối mạng vật lý. Không có khả năng phân phối traffic giữa các EC2.
   • Kết luận: ❌ Không đáp ứng nhu cầu cân bằng tải.

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

• ALB đã được mở rộng để hỗ trợ HTTP/2, gRPC, và WebSocket (từ 2023) – vẫn là lựa chọn hàng đầu cho các ứng dụng web hiện đại.
• Target Group health checks đã được nâng cấp để cho phép custom health check paths và port-level checks, giúp cải thiện độ tin cậy khi cân bằng tải cho các micro‑service trên EC2.
• AWS Load Balancer Controller (kể từ 2024) cho phép khai báo ALB bằng Kubernetes Ingress trên Amazon EKS, nhưng nguyên lý hoạt động vẫn là ALB.

📚 Tham khảo

• Amazon Elastic Load Balancing – Application Load Balancer (AWS Documentation, phiên bản 2026): https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html
• AWS WAF – Overview: https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html
• AWS CloudHSM – What is CloudHSM?: https://docs.aws.amazon.com/cloudhsm/latest/userguide/what-is-cloudhsm.html
• AWS Direct Connect – Overview: https://docs.aws.amazon.com/directconnect/latest/UserGuide/what-is-direct-connect.html

Tóm lại: Để phân phối traffic giữa các EC2 host website, Application Load Balancer là dịch vụ đúng nhất. Các tùy chọn còn lại là các dịch vụ bảo mật, phần cứng bảo mật hoặc kết nối mạng, không cung cấp chức năng cân bằng tải. ✅🧩