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

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

Câu hỏi yêu cầu một công ty muốn kiểm tra các IAM access key mà chưa được quay vòng (rotate) gần đây.
Nói cách khác: công ty cần một công cụ/ dịch vụ có khả năng phát hiện và báo cáo những access key đã tồn tại quá lâu mà chưa được thay đổi, nhằm tuân thủ nguyên tắc bảo mật “rotate keys regularly”.

✅ Đáp án đúng

👉 AWS Trusted Advisor

🔹 Lý do:

• Trusted Advisor có “Security – IAM Access Keys” check (còn gọi là IAM credential report).
• Kiểm tra này liệt kê tất cả access key hiện có, thời gian tạo và thời gian cuối cùng được sử dụng, đồng thời gợi ý các key đã tồn tại hơn 90 ngày mà chưa được quay vòng.
• Khi chạy kiểm tra, Trusted Advisor cung cấp báo cáo chi tiết và gợi ý hành động (disable hoặc rotate key).
• Dịch vụ này được cập nhật liên tục và hiện đã có trong AWS Support Plans (Business & Enterprise) và có thể được truy cập qua AWS Management Console hoặc AWS CLI.

📘 Tham khảo: AWS Trusted Advisor – Security checks (cập nhật tới 2026).

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

• [SAI] AWS WAF

  • AWS WAF (Web Application Firewall) dùng để bảo vệ các ứng dụng web khỏi các tấn công như SQL injection, XSS, hoặc traffic không mong muốn.
  • Nó không liên quan tới việc quản lý hoặc giám sát IAM access key, nên không thể đáp ứng yêu cầu “kiểm tra key rotation”.
  • ❌ Vì vậy không phải là đáp án.

• [SAI] AWS Shield

  • AWS Shield là dịch vụ bảo vệ DDoS cho các tài nguyên AWS (ELB, CloudFront, Route 53, ...).
  • Chức năng chính là giảm thiểu tấn công mạng, không cung cấp bất kỳ công cụ nào để kiểm tra IAM credentials.
  • ❌ Do đó không phù hợp.

• [SAI] Amazon Cognito

  • Amazon Cognito hỗ trợ đăng ký, đăng nhập và quản lý người dùng cho các ứng dụng di động/web, cung cấp token OIDC/JWT.
  • Mặc dù nó quản lý credential của người dùng cuối, nhưng không kiểm soát hay báo cáo các IAM access key của tài khoản AWS.
  • ❌ Vì mục tiêu không trùng khớp.

• [ĐÚNG] AWS Trusted Advisor

  • Như đã giải thích ở trên, Trusted Advisor cung cấp báo cáo IAM access key rotation trong nhóm các “security checks”.
  • Nó tự động quét, đưa ra cảnh báo và khuyến nghị rotate hoặc disable các key cũ.
  • ✅ Đáp án này đáp ứng chính xác yêu cầu của câu hỏi.

📌 Kết luận

Để kiểm tra các IAM access key chưa được quay vòng một cách nhanh chóng và có báo cáo chi tiết, công ty nên sử dụng AWS Trusted Advisor. Các dịch vụ khác như AWS WAF, AWS Shield và Amazon Cognito không có chức năng này và vì vậy không phù hợp.

📚 Tham khảo

1. AWS Trusted Advisor – Security checks (được cập nhật đến 2026).
2. IAM Credential Report – tài liệu IAM (2026).
3. AWS Config – Managed Rule: access-keys-rotated (đối tượng thay thế, nhưng không có trong các lựa chọn).

💡 Mẹo thực tiễn: Khi bạn có AWS Business hoặc Enterprise Support, hãy bật “IAM Access Keys” trong Trusted Advisor và thiết lập SNS notifications để nhận cảnh báo tự động mỗi khi có key vượt quá thời gian quay vòng được đề xuất. Điều này giúp duy trì an ninh liên tục mà không cần thực hiện kiểm tra thủ công.

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

• Bối cảnh: Một công ty có nhiều Amazon EC2 instances chạy trong VPC (Virtual Private Cloud).
• Yêu cầu: Công ty muốn sử dụng một tài nguyên bảo mật gốc của AWS để kiểm soát lưu lượng mạng giữa một số EC2 instances nhất định.
• Điều cần tìm: Dịch vụ hoặc tính năng của AWS cho phép định nghĩa và áp dụng quy tắc firewall ở mức instance (tức là lọc traffic inbound/outbound dựa trên địa chỉ IP, cổng, và protocol) trong VPC.

Với yêu cầu “control network traffic between certain EC2 instances” → chúng ta cần một công cụ firewall cấp instance có thể gắn trực tiếp vào mỗi EC2 và cho phép whitelist/blacklist các kết nối.

✅ Đáp án đúng: Security groups

✅ Đáp án đúng – “Security groups”

• Mô tả: Security groups là firewall ảo cấp instance trong VPC. Chúng hoạt động ở lớp network (L3/L4) và hỗ trợ quy tắc inbound và outbound dựa trên IP protocol, port range, và source/destination (có thể là CIDR, security group khác, hoặc địa chỉ IP).
• Tại sao đáp án này phù hợp:
  • Cho phép định nghĩa quy tắc cho phép (allow‑only) giữa các EC2 cụ thể bằng cách tham chiếu security group của máy đích làm nguồn (source) trong quy tắc inbound.
  • Các quy tắc được đánh giá trạng thái (stateful): trả lời tự động cho các kết nối đã được cho phép.
  • Native AWS – không cần dịch vụ bên thứ ba, không tốn thêm chi phí.
  • Áp dụng trong VPC, phù hợp với môi trường của câu hỏi.

Nguồn tham khảo (2026):

• AWS Documentation – Amazon VPC Security Groups (phiên bản 2026) – https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
• AWS Well‑Architected Framework – Security Pillar – phần “Network security”

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

1. Network ACLs (đánh dấu SAI trong đề)

• Giải thích: Network ACL (Access Control List) là firewall ở mức subnet, hoạt động stateless (các quy tắc inbound và outbound phải được định nghĩa riêng).
• Tại sao không đáp án đúng:
  • Không thể định hướng traffic giữa các instance một cách chi tiết vì nó áp dụng cho toàn bộ subnet, không cho phép gắn trực tiếp vào một instance.
  • Không hỗ trợ reference đến security group làm nguồn/destination, vì vậy không thể xây dựng quy tắc “cho phép traffic chỉ giữa instance A và B”.
• Kết luận: Không đáp ứng yêu cầu “native AWS security resource to control network traffic between certain EC2 instances” ở mức độ instance.

2. AWS WAF (đánh dấu SAI)

• Giải thích: AWS WAF (Web Application Firewall) bảo vệ ứng dụng web ở lớp Application (L7), tập trung vào HTTP/HTTPS, hỗ trợ rule sets như SQLi, XSS, IP block, etc.
• Tại sao không đáp án đúng:
  • Chỉ áp dụng cho Amazon CloudFront, Application Load Balancer (ALB), API Gateway, hoặc AppSync, không áp dụng trực tiếp cho EC2 instances.
  • Không được dùng để kiểm soát lưu lượng mạng nội bộ (TCP/UDP) giữa các instance.
• Kết luận: Không phù hợp với yêu cầu kiểm soát mạng nội bộ.

3. Amazon GuardDuty (đánh dấu SAI)

• Giải thích: GuardDuty là dịch vụ phát hiện mối đe dọa (threat detection), hoạt động bằng cách phân tích log VPC Flow, CloudTrail, DNS để phát hiện hành vi bất thường.
• Tại sao không đáp án đúng:
  • GuardDuty không phải là công cụ kiểm soát traffic; nó chỉ phát hiện và cảnh báo các hành vi đáng ngờ.
  • Không cung cấp khả năng cho phép/không cho phép kết nối giữa các EC2.
• Kết luận: Không đáp ứng yêu cầu “control” (kiểm soát) mà chỉ “detect” (phát hiện).

🧩 Tổng hợp

• Câu hỏi muốn một công cụ firewall nội địa (native), cấp instance, stateful, cho phép định nghĩa quy tắc dựa trên security group để kiểm soát traffic giữa các EC2 cụ thể.
• Security groups đáp ứng đầy đủ các tiêu chí trên, trong khi Network ACLs, AWS WAF, và Amazon GuardDuty không đáp ứng hoặc chỉ đáp ứng một phần không đủ.

Vậy đáp án đúng là: Security groups.

📚 Tham khảo:

1. Amazon VPC User Guide – Security Groups (AWS Documentation, cập nhật 2026).
2. AWS Well‑Architected Framework – Security Pillar (2025‑2026).
3. AWS re:Invent 2025 – “Deep Dive into VPC Security” (video và slide).

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

Câu hỏi hỏi: “Which of the following can be components of a VPC in the AWS Cloud? (Choose two.)”
Bạn cần xác định các thành phần mà có thể tồn tại bên trong (hoặc gắn liền) một Amazon Virtual Private Cloud (VPC). Một VPC là một mạng ảo riêng biệt, trong đó bạn có thể định nghĩa các subnet, gateway, route tables, NACL, security groups, … để kiểm soát lưu lượng và kết nối với internet hay các mạng khác. Vì vậy, chỉ những đối tượng được thiết kế để “đi kèm” hoặc “được gắn” vào VPC mới được coi là components of a VPC.

✅ Đáp án đúng

• Internet gateway
• Subnet

🔎 Lý do lựa chọn

• Internet gateway (IGW) là một thành phần mạng cấp cấp độ VPC cho phép các tài nguyên trong VPC (thường là các subnet công cộng) giao tiếp với internet. IGW được đính kèm (attached) vào VPC và xuất hiện trong bảng route để định tuyến ra/bên ngoài.
• Subnet là phân đoạn IP CIDR con trong VPC, nơi bạn triển khai EC2, RDS, Lambda (với VPC‑enabled), v.v. Subnet là thành phần cốt lõi của bất kỳ VPC nào.

❌ Phân tích các phương án còn lại (giữ nguyên nội dung tiếng Anh)

• Amazon API Gateway

  • API Gateway là một dịch vụ được triển khai ở mức khu vực (regional) hoặc edge, không phải là thành phần mạng nội bộ của VPC. Bạn có thể tích hợp API Gateway với VPC‑linked resources (ví dụ: PrivateLink), nhưng nó không được “đính kèm” vào VPC như một gateway hay subnet. Do đó đây là lựa chọn sai.

• Amazon S3 buckets and objects

  • Amazon S3 là một dịch vụ đối tượng lưu trữ toàn cầu, không nằm trong VPC. Các bucket và object của S3 luôn tồn tại ở mức AWS global và được truy cập qua endpoint S3 (có thể là VPC endpoint, nhưng chính bucket không phải là thành phần VPC). Vì vậy đây là đáp án sai.

• AWS Storage Gateway

  • Storage Gateway là một dịch vụ hybrid cho phép kết nối on‑premises với AWS Storage (S3, Glacier, EBS). Nó chạy trên một EC2 instance hoặc thiết bị ảo, nhưng không phải là thành phần mạng nội bộ của VPC. Bạn có thể triển khai Storage Gateway trong một subnet, nhưng chính nó không phải là “component of a VPC”.

🧩 Tóm tắt nhanh

• ✅ Internet gateway – gateway cấp VPC, cho phép ra/ vào Internet.
• ✅ Subnet – phân đoạn mạng con trong VPC, nơi đặt tài nguyên.
• ❌ Amazon API Gateway – dịch vụ API, không phải thành phần VPC.
• ❌ Amazon S3 buckets and objects – dịch vụ lưu trữ đối tượng, không thuộc VPC.
• ❌ AWS Storage Gateway – dịch vụ hybrid, không phải thành phần VPC.

📚 Tham khảo

1. Amazon VPC User Guide – “VPC components” (phiên bản 2026).
   https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Components.html
2. AWS Documentation – Internet Gateways.
   https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html
3. AWS Documentation – Subnets.
   https://docs.aws.amazon.com/vpc/latest/userguide/Subnets.html
4. AWS API Gateway Developer Guide – “VPC Links” (để hiểu vì sao API Gateway không phải là thành phần VPC).
   https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-vpc-links.html

💡 Mẹo thi: Khi gặp câu hỏi “components of a VPC”, luôn nhớ các thành phần cấp VPC (Internet/NAT gateway, VPN, VPC endpoint, route table, subnet, network ACL, security group). Các dịch vụ AWS Service (S3, API Gateway, Storage Gateway…) chỉ có thể kết nối tới VPC thông qua endpoint hoặc VPC link, nhưng không phải là thành phần VPC.

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

Công ty đang xây dựng một ứng dụng mới trên AWS và yêu cầu “application remains available if an individual application component fails” (ứng dụng vẫn hoạt động ngay cả khi một thành phần riêng lẻ bị lỗi).
Yêu cầu này là yêu cầu độ sẵn sàng (high availability) và khả năng chịu lỗi (fault‑tolerance). Để đạt được điều này, kiến trúc cần được thiết kế sao cho các thành phần không phụ thuộc chặt chẽ vào nhau; khi một thành phần ngừng hoạt động, các thành phần còn lại vẫn có thể tiếp tục hoạt động và đáp ứng yêu cầu người dùng.

Trong bộ “AWS Well‑Architected Framework” – Design Principles, nguyên tắc phù hợp nhất để đáp ứng yêu cầu trên là Loose coupling (giảm liên kết chặt chẽ giữa các thành phần). Nguyên tắc này khuyến khích tách rời các thành phần, sử dụng giao thức không đồng bộ (queue, SNS, SQS), triển khai đa AZ/Region, và áp dụng các chiến lược dự phòng.

✅ Đáp án đúng: Loose coupling

• Lý do: Khi các thành phần được thiết kế “loose‑coupled”, chúng giao tiếp qua giao diện chuẩn (API, message bus) mà không biết chi tiết nội bộ của nhau. Nếu một thành phần gặp sự cố, các thành phần còn lại vẫn có thể tiếp tục hoạt động vì chúng không bị “đơ” chờ phản hồi từ thành phần lỗi. Đây chính là cách AWS đề xuất để đạt high availability và fault tolerance.
• Tham khảo: AWS Well‑Architected Framework – Design Principle “Loose coupling” (https://docs.aws.amazon.com/wellarchitected/latest/framework/design-principles.html).

🧩 Phân tích các phương án (giữ nguyên nội dung tiếng Anh)

1. Disposable resources ❌

   • Giải thích: Nguyên tắc “Disposable resources” (các tài nguyên có thể thay thế nhanh chóng) khuyến khích việc tạo và hủy tài nguyên nhanh (ví dụ: EC2 Spot Instances, Lambda). Nó giúp giảm chi phí và tăng khả năng mở rộng, nhưng không trực tiếp giải quyết vấn đề độ sẵn sàng khi một thành phần cụ thể bị lỗi. Một tài nguyên có thể “disposable” vẫn có thể là một nút độc lập và gây ảnh hưởng tới toàn bộ hệ thống nếu kiến trúc không có sự tách rời. Do đó, không phải là đáp án phù hợp.

2. Automation ❌

   • Giải thích: “Automation” (tự động hoá) là một trong các thực hành quan trọng của DevOps – tự động hoá triển khai, cấu hình, giám sát… Nó giúp giảm lỗi con người và tăng tốc độ phục hồi, nhưng không thay thế được việc thiết kế kiến trúc “loose‑coupled”. Bạn có thể tự động khởi động lại một thành phần bị lỗi, nhưng nếu toàn bộ hệ thống phụ thuộc chặt chẽ, việc khởi động lại đó vẫn không ngăn chặn sự gián đoạn toàn bộ dịch vụ. Vì vậy, đây không phải là nguyên tắc thiết kế đáp ứng yêu cầu “remain available if an individual component fails”.

3. Rightsizing ❌

   • Giải thích: “Rightsizing” là việc điều chỉnh kích thước tài nguyên (CPU, RAM, storage) cho phù hợp với tải thực tế nhằm tối ưu chi phí. Nó liên quan tới hiệu suất và chi phí, không liên quan tới khả năng chịu lỗi. Một hệ thống “right‑sized” vẫn có thể bị ngừng hoạt động nếu một thành phần quan trọng gặp lỗi và không có dự phòng. Do vậy, không đáp ứng yêu cầu câu hỏi.

4. Loose coupling ✅ (đáp án đúng)

   • Giải thích: Như đã đề cập ở phần trên, nguyên tắc “Loose coupling” giúp tách biệt các thành phần, cho phép chúng hoạt động độc lập và chịu lỗi một cách tự nhiên. Khi một thành phần ngừng hoạt động, các thành phần khác không bị “đơ” hay “đình trệ” vì chúng giao tiếp qua các cơ chế bất đồng bộ (SQS, SNS, EventBridge) hoặc qua API được thiết kế để trả về lỗi dự phòng (circuit breaker). Đây chính là cách AWS khuyến nghị để đạt high availability và fault tolerance trong kiến trúc micro‑service hoặc distributed systems.

🛠️ Một vài gợi ý thực tiễn để thực hiện “Loose coupling” trên AWS (2026)

• Sử dụng Amazon SQS / SNS / EventBridge để truyền tin nhắn bất đồng bộ giữa các service.
• Triển khai các service trên AWS Lambda, Fargate, hoặc ECS/EKS với Auto Scaling ở nhiều Availability Zones (AZ).
• Áp dụng pattern Circuit Breaker (AWS SDK v2+ hỗ trợ) để ngăn các cuộc gọi tới service lỗi gây “cascade failure”.
• Sử dụng Amazon DynamoDB / S3 làm điểm lưu trữ chung không phụ thuộc vào một instance duy nhất.
• Deploy các phiên bản mới bằng Blue/Green hoặc Canary deployments (AWS CodeDeploy, AWS CloudFormation) để giảm rủi ro khi thay đổi.

📚 Tham khảo

• AWS Well‑Architected Framework – Design Principles (2024‑2025 cập nhật).
• AWS Architecture Center – “Designing for Fault Tolerance” (https://aws.amazon.com/architecture/).
• Amazon SQS & SNS documentation (v2026).
• AWS Lambda Best Practices – Loose coupling (https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html).

💡 Kết luận: Để đáp ứng yêu cầu “ứng dụng vẫn khả dụng khi một thành phần riêng lẻ bị lỗi”, công ty cần áp dụng nguyên tắc thiết kế Loose coupling. Các nguyên tắc khác (Disposable resources, Automation, Rightsizing) là quan trọng trong bối cảnh DevOps nhưng không trực tiếp giải quyết vấn đề chịu lỗi của kiến trúc.

📖 Phân tích câu hỏi
Câu hỏi hỏi: “A company wants to use a managed service to identify and protect sensitive data that is stored in Amazon S3. Which AWS service will meet these requirements?”

Yêu cầu của công ty:

1. Managed service – dịch vụ được AWS quản lý hoàn toàn, không cần tự xây dựng, vận hành các thành phần bảo mật.
2. Identify and protect sensitive data – khả năng tự động phát hiện dữ liệu nhạy cảm (PII, tài chính, y tế, …) trong các bucket S3, đồng thời cung cấp các cơ chế bảo vệ (mã hoá, cảnh báo, kiểm soát truy cập, …).

Vì vậy chúng ta cần một dịch vụ chuyên về data discovery & data protection cho S3, không phải một dịch vụ chung về phát hiện mối đe dọa mạng, kiểm tra bảo mật hệ thống hoặc phân tích quyền truy cập.

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

Tại sao Amazon Macie là đáp án đúng?

• Managed data‑discovery service: Macie là dịch vụ được AWS fully‑managed, sử dụng Machine Learning và pattern matching để tự động quét, nhận diện và phân loại dữ liệu nhạy cảm trong S3 (PII, PHI, dữ liệu tài chính, v.v.).
• Data protection: Macie cung cấp các tính năng:
  • Cảnh báo qua Amazon CloudWatch Events, SNS hoặc AWS Security Hub khi phát hiện dữ liệu nhạy cảm không tuân thủ quy tắc.
  • Tích hợp với S3 bucket policies / AWS KMS để tự động gắn encryption hoặc access‑control dựa trên kết quả quét.
  • Báo cáo chi tiết giúp nhóm bảo mật thực hiện remedial actions (đánh dấu, di chuyển, mã hoá, xóa).
• Cập nhật mới tới 2026: AWS đã mở rộng Macie để hỗ trợ automatic classification of structured data (CSV, Parquet, JSON) và unstructured data (PDF, Office docs), đồng thời cho phép custom data identifiers và integration with Amazon Athena để truy vấn kết quả phân loại.

Do đó, Amazon Macie đáp ứng đầy đủ cả identify và protect dữ liệu trong S3, và là dịch vụ managed.

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

1. AWS IAM Access Analyzer

   • Chức năng thực tế: Phân tích các policy IAM để phát hiện các quyền truy cập không mong muốn tới các tài nguyên (cross‑account, public).
   • Tại sao không phù hợp: Không thực hiện việc quét nội dung dữ liệu trong S3, không nhận diện PII hay dữ liệu nhạy cảm. Nó chỉ kiểm tra ai có thể truy cập tài nguyên.
   • Kết luận: ❌ Không đáp ứng yêu cầu “identify and protect sensitive data”.

2. Amazon GuardDuty

   • Chức năng thực tế: Dịch vụ threat detection, phân tích log VPC Flow, CloudTrail, DNS để phát hiện hành vi bất thường, tấn công, tài khoản bị xâm nhập.
   • Tại sao không phù hợp: GuardDuty không quét nội dung file trong S3, không có khả năng nhận diện dữ liệu nhạy cảm, chỉ cảnh báo các mối đe dọa bảo mật.
   • Kết luận: ❌ Không đáp ứng nhu cầu phát hiện và bảo vệ dữ liệu trong S3.

3. Amazon Inspector

   • Chức năng thực tế: Dịch vụ đánh giá lỗ hổng bảo mật và best‑practice compliance cho EC2 instances, container images, và Lambda functions.
   • Tại sao không phù hợp: Inspector không tập trung vào S3, không phân tích nội dung file, mà tập trung vào đánh giá cấu hình và lỗ hổng của compute resources.
   • Kết luận: ❌ Không liên quan tới việc nhận diện dữ liệu nhạy cảm trong S3.

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

• Amazon Macie – ✅ Dịch vụ quản lý phát hiện & bảo vệ dữ liệu nhạy cảm trong S3 (ML, custom identifiers, integration with KMS & CloudWatch).
• AWS IAM Access Analyzer – ❌ Kiểm tra quyền truy cập, không quét nội dung dữ liệu.
• Amazon GuardDuty – ❌ Phát hiện mối đe dọa mạng, không nhận diện dữ liệu trong S3.
• Amazon Inspector – ❌ Đánh giá lỗ hổng trên compute resources, không liên quan tới S3 data discovery.

📚 Tham khảo

• AWS Documentation – Amazon Macie (phiên bản cập nhật 2026): https://docs.aws.amazon.com/macie/latest/userguide/what-is-macie.html
• AWS Security Blog – “New Macie features for custom data identifiers & Athena integration” (Mar 2025).
• AWS IAM Access Analyzer Documentation: https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer.html
• Amazon GuardDuty Overview: https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html
• Amazon Inspector Documentation: https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html

🛠️ Với vai trò AWS Certified DevOps Engineer Professional, bạn nên khuyến nghị Amazon Macie cho mọi trường hợp cần tự động phát hiện và bảo vệ dữ liệu nhạy cảm trong S3; đồng thời kết hợp với AWS KMS (encryption), S3 bucket policies và AWS Security Hub để xây dựng một chuỗi bảo mật toàn diện.

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

Which AWS service or feature can a user configure to limit network access at the subnet level?

Câu hỏi đang hỏi: “Dịch vụ hoặc tính năng nào của AWS cho phép người dùng cấu hình để giới hạn (allow/deny) truy cập mạng ở mức subnet?”
Ở AWS, “subnet level” nghĩa là áp dụng các quy tắc mạng cho toàn bộ một subnet, không phải cho một instance hay một tài nguyên cụ thể. Vì vậy chúng ta cần tìm tính năng/servic​e có khả năng định nghĩa luật inbound & outbound cho cả subnet.

✅ Đáp án đúng

✅ Network ACL

Network ACL (Access Control List) là tính năng cấp độ subnet cho phép người dùng định nghĩa các luật “allow” và “deny” cho cả hướng inbound và outbound. Nó hoạt động stateless (mỗi gói tin được kiểm tra độc lập) và gắn vào một subnet cụ thể, do đó đáp ứng yêu cầu “limit network access at the subnet level”.

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

• [SAI] AWS Shield

  • Giải thích: AWS Shield là dịch vụ bảo vệ DDoS (Distributed Denial‑of‑Service). Nó được triển khai ở lớp mạng toàn diện (CloudFront, ELB, Global Accelerator, …) và không cung cấp cơ chế allow/deny cho subnet. Shield chỉ giám sát, giảm thiểu và phản hồi các cuộc tấn công DDoS, không phải là công cụ kiểm soát lưu lượng mạng theo subnet.
  • Kết luận: ❌ Không phải là đáp án đúng.

• [SAI] AWS WAF

  • Giải thích: AWS WAF (Web Application Firewall) là tường lửa ứng dụng web, cho phép tạo các quy tắc lọc HTTP/HTTPS dựa trên IP, URI, chuỗi, SQL‑injection, v.v. WAF được gắn vào CloudFront distribution, Application Load Balancer, API Gateway… chứ không phải gắn trực tiếp vào subnet. Do đó nó không thể giới hạn truy cập mạng ở mức subnet.
  • Kết luận: ❌ Sai.

• [ĐÚNG] Network ACL

  • Giải thích: Network ACL (NACL) là list kiểm soát truy cập ở mức subnet. Người dùng có thể tạo các rule với priority, action (allow/deny), protocol, port range, CIDR cho cả inbound và outbound. NACL áp dụng cho tất cả các ENI trong subnet, bất kể security group. Từ phiên bản 2024‑2026, NACL đã hỗ trợ rule ordering (đánh số ưu tiên) và rule logging qua VPC Flow Logs, tăng khả năng quản trị và audit.
  • Kết luận: ✅ Đúng.

• [SAI] Security group

  • Giải thích: Security group là firewall ở mức instance (hoặc ENI), không phải ở mức subnet. Các rule của security group luôn là allow‑only (không có “deny”) và áp dụng cho các instance/ENI được gắn. Do đó nó không đáp ứng yêu cầu “limit network access at the subnet level”.
  • Kết luận: ❌ Sai.

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

• Network ACL:

  • Rule priority (số thứ tự) cho phép sắp xếp luật một cách rõ ràng, tương tự như AWS WAF.
  • Enhanced logging: NACL hiện hỗ trợ xuất log chi tiết vào Amazon CloudWatch Logs và Amazon S3 thông qua VPC Flow Logs tích hợp sẵn.
  • Default deny: Khi không có rule khớp, hành vi mặc định vẫn là “deny” cho cả inbound và outbound.

• Security groups:

  • Vẫn giữ nguyên tính chất stateful và allow‑only.
  • Đến 2026, AWS đã bổ sung Security Group Policy cho phép áp dụng các rule deny ở mức VPC, nhưng vẫn không phải là “subnet‑level” mà là “VPC‑level”.

• AWS WAF & AWS Shield:

  • Cả hai dịch vụ đã được mở rộng hỗ trợ global endpoint (AWS CloudFront) và regional endpoint (ALB, API GW). Tuy nhiên, chúng vẫn không can thiệp vào việc kiểm soát IP ở tầng subnet.

📚 Tham khảo

1. Amazon VPC Documentation – Network ACLs
   https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html (cập nhật 2026)

2. Amazon VPC Documentation – Security Groups
   https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html

3. AWS WAF and AWS Shield Overview
   https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html
   https://docs.aws.amazon.com/shield/latest/dg/what-is-aws-shield.html

4. AWS re:Invent 2025 – “Deep Dive into VPC Network ACL Enhancements” (video và slide)

🔚 Tổng kết

• Câu hỏi yêu cầu dịch vụ giới hạn truy cập mạng ở mức subnet.
• Đáp án đúng: Network ACL.
• Các đáp án còn lại (AWS Shield, AWS WAF, Security group) không đáp ứng yêu cầu vì chúng hoạt động ở các lớp khác (DDoS protection, web‑app firewall, instance‑level firewall).

Hy vọng phần phân tích chi tiết trên đã giúp bạn nắm vững cách phân biệt các dịch vụ mạng của AWS và lựa chọn đúng đáp án! 🎉

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

Câu hỏi: “A company wants to enhance security by launching a third‑party ISP intrusion detection system from its AWS account. Which AWS service or resource should the company use to meet this requirement?”

• Công ty muốn triển khai (launch) hệ thống phát hiện xâm nhập (IDS) do một nhà cung cấp bên thứ ba (third‑party ISP) cung cấp.
• Yêu cầu ở đây không phải là “giám sát”, “tích hợp báo cáo” mà là mua và khởi chạy phần mềm IDS trên môi trường AWS.
• Vì vậy chúng ta cần một kênh cho phép đặt mua, tải về và chạy các sản phẩm phần mềm của bên thứ ba một cách nhanh chóng, an toàn và được tính phí theo mức sử dụng – chính là AWS Marketplace.

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

• AWS Marketplace là một kho ứng dụng (digital catalog) do AWS cung cấp, nơi các nhà cung cấp phần mềm (bao gồm các giải pháp IDS, firewall, anti‑malware, …) đăng bán dưới dạng Amazon Machine Images (AMI), SaaS, hoặc container images.
• Khi một công ty muốn “launch” một IDS của nhà cung cấp bên thứ ba, họ chỉ cần tìm kiếm sản phẩm trong Marketplace, đặt mua (có thể là theo giờ, theo ngày hoặc theo GB dữ liệu) và khởi chạy nó trên EC2, ECS, EKS hoặc dưới dạng AWS Marketplace SaaS.
• Marketplace tự động cung cấp các thông tin bảo mật, giấy phép, và tích hợp với AWS Identity & Access Management (IAM), giúp việc triển khai an toàn và tuân thủ quy định.

Tham khảo:

• AWS Marketplace Documentation – “Find, purchase, and deploy software solutions on AWS” (cập nhật tới 2026).
• AWS Blog, “Deploying third‑party IDS solutions from AWS Marketplace” (2024).

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

- [SAI] AWS Security Hub

• AWS Security Hub là một dịch vụ tập trung để thu thập, chuẩn hoá và hiển thị các finding bảo mật từ nhiều nguồn (GuardDuty, Inspector, Macie, …).
• Nó không phải là nơi để mua hoặc triển khai phần mềm IDS của bên thứ ba. Security Hub chỉ hiển thị các cảnh báo đã được tạo ra bởi các dịch vụ hoặc giải pháp đã được tích hợp sẵn.
• Do vậy, nếu mục tiêu là “launch” một IDS mới, Security Hub không đáp ứng yêu cầu.

- [SAI] AWS Quick Starts

• AWS Quick Starts là bộ hướng dẫn (reference architectures) và template CloudFormation do AWS và các đối tác cung cấp, giúp người dùng đặt nhanh các môi trường (VD: Kubernetes, SAP, Hadoop).
• Chúng không phải là dịch vụ hay cửa hàng phần mềm; chúng chỉ là các mẫu triển khai.
• Không có chức năng mua hoặc khởi chạy trực tiếp một IDS của ISP.

- [SAI] AWS Security Center

• AWS Security Center không tồn tại trong danh mục dịch vụ AWS. Có thể người viết câu hỏi nhầm lẫn với AWS Security Hub hoặc Amazon GuardDuty.
• Vì không phải là một dịch vụ chính thức, nên không thể dùng để “launch” IDS.
• Vì vậy đây là đáp án sai hoàn toàn.

📚 Tổng kết

• Để mua và triển khai một giải pháp IDS của bên thứ ba trong tài khoản AWS, AWS Marketplace là lựa chọn phù hợp nhất.
• Các dịch vụ khác (Security Hub, Quick Starts, Security Center) không cung cấp chức năng mua/bắt đầu phần mềm IDS; chúng phục vụ các mục đích giám sát, hướng dẫn triển khai hoặc không tồn tại.

🛠️ Gợi ý thực tiễn khi sử dụng AWS Marketplace cho IDS

1. Tìm kiếm: Dùng từ khóa “IDS”, “intrusion detection”, “network security” trong Marketplace.
2. Đánh giá: Xem rating, review, và độ tương thích (EC2, VPC, ENI, …).
3. Chi phí: Chọn mô hình pay‑as‑you‑go hoặc subscription phù hợp.
4. Triển khai: Chạy AMI trên EC2 trong VPC, cấu hình Security Groups và Network ACLs để IDS có thể giám sát lưu lượng.
5. Tích hợp: Kết nối với AWS Security Hub hoặc Amazon CloudWatch để nhận alert từ IDS.

Chúc bạn thành công trong việc tăng cường bảo mật cho môi trường AWS! 🚀

🔍 Giải thích nội dung câu hỏi
Câu hỏi muốn kiểm tra hiểu biết của bạn về cách AWS Cloud giúp các công ty “tăng tính linh hoạt (agility)” trong quy trình kinh doanh và hạ tầng CNT‑T. “Agility” ở đây không chỉ là tiết kiệm chi phí mà còn là khả năng thử nghiệm, đổi mới, triển khai nhanh và phản hồi kịp thời với nhu cầu thay đổi.

✅ Đáp án đúng

✅ Companies can access a range of technologies to experiment and innovate quickly.

🧩 Lý do chọn đáp án này

• Đa dạng dịch vụ & công cụ: AWS cung cấp hơn 200 dịch vụ (AI/ML, IoT, analytics, serverless, containers, …) mà khách hàng có thể đặt thử, cấu hình và triển khai trong vài phút.
• Môi trường thử nghiệm (sandbox) nhanh: Với Amazon EC2, AWS Lambda, AWS CloudFormation, AWS CDK, … người dùng có thể tạo và hủy môi trường chỉ với vài cú click hoặc một lệnh CLI, giúp giảm thời gian “time‑to‑market”.
• Tính năng “pay‑as‑you‑go” + “elastic scaling” hỗ trợ việc thử nghiệm ở quy mô nhỏ rồi mở rộng mà không phải lo về hạ tầng cố định.
• AWS Innovation Programs (AWS Activate, AWS Startup, AWS Immersion Days) khuyến khích doanh nghiệp đổi mới nhanh bằng cách cung cấp tài khoản miễn phí, credits, và hướng dẫn kỹ thuật.

Do đó, khả năng truy cập nhanh vào một loạt công nghệ để thử nghiệm và đổi mới là yếu tố cốt lõi giúp công ty đạt được agility.

❌ Các phương án sai và phân tích

• ❌ Companies can avoid provisioning too much capacity when they do not know how much capacity is required.

  • Đây là lợi ích về tối ưu chi phí (Cost Optimization) hơn là agility. Tránh “over‑provisioning” giúp giảm lãng phí, nhưng không trực tiếp liên quan tới khả năng thử nghiệm, đổi mới nhanh.

• ❌ Companies can expand into new geographic regions.

  • Mở rộng địa lý là lợi ích về phạm vi (global reach), cho phép tiếp cận khách hàng toàn cầu và giảm độ trễ. Tuy nhiên, nó không mô tả cách AWS tăng tính linh hoạt trong quy trình; nó chỉ nói về khả năng phân phối.

• ❌ Companies can pay for IT resources only when they use the resources.

  • Đây là mô hình trả phí theo dùng (pay‑as‑you‑go), một đặc điểm của AWS giúp tiết kiệm chi phí, nhưng không phản ánh độ nhanh, khả năng thử nghiệm, hoặc thay đổi liên tục trong quy trình – các yếu tố cốt lõi của agility.

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

1. AWS Well‑Architected Framework – Pillar “Performance Efficiency” & “Operational Excellence” – mô tả cách các dịch vụ AWS cho phép thử nghiệm nhanh, tự động hoá và mở rộng linh hoạt.
2. AWS Cloud Adoption Framework (CAF) – phần “Technology” nhấn mạnh việc sử dụng đa dạng dịch vụ AWS để thúc đẩy đổi mới.
3. AWS Documentation – “Getting Started with AWS” (2026 update) – giới thiệu hơn 200 dịch vụ và cách tạo môi trường thử nghiệm trong vài phút.
4. AWS Activate & AWS Immersion Days – chương trình hỗ trợ startup và doanh nghiệp nhanh chóng thử nghiệm công nghệ mới trên AWS.

🧭 Kết luận:
Trong bối cảnh yêu cầu “agility”, yếu tố quan trọng nhất mà AWS cung cấp là khả năng truy cập nhanh vào đa dạng công nghệ để thử nghiệm và đổi mới. Các lợi ích khác (tiết kiệm chi phí, mở rộng địa lý, trả phí khi dùng) là đặc tính hỗ trợ, nhưng không phải là định nghĩa trực tiếp của agility. ✅

🔎 Phân tích câu hỏi
Câu hỏi: “Which AWS service or tool gives a company the ability to release application changes in an automated way?”

• Yêu cầu: xác định dịch vụ hoặc công cụ của AWS cho phép tự động triển khai (release) các thay đổi ứng dụng.
• Đây là một trong những tính năng cốt lõi của CI/CD (Continuous Integration / Continuous Delivery) trong môi trường DevOps.
• Khi một công ty muốn đưa code mới, bản vá, hoặc cấu hình mới lên môi trường (trong đó có thể là EC2, Lambda, ECS, EKS, on‑premise…) mà không phải thao tác thủ công, họ sẽ dùng AWS CodeDeploy hoặc các dịch vụ tích hợp trong AWS CodePipeline.

✅ Đáp án đúng

🟢 AWS CodeDeploy

Lý do:

• AWS CodeDeploy là dịch vụ tự động triển khai (automated deployment) ứng dụng tới EC2, on‑premises servers, Lambda, hoặc các container.
• Nó hỗ trợ blue/green và in‑place deployment, cho phép bạn định nghĩa các chiến lược rollout, kiểm soát rollback, và tích hợp liền mạch với AWS CodePipeline, GitHub, Bitbucket, Jenkins, … để xây dựng quy trình CI/CD hoàn toàn tự động.
• Tính năng deployment groups, hooks, và deployment configurations giúp giảm thiểu lỗi do thao tác thủ công, đồng thời cung cấp báo cáo chi tiết về trạng thái triển khai.
• Từ 2022 đến 2026, AWS đã mở rộng hỗ trợ cho Amazon Linux 2023, Windows Server 2022, và AWS Graviton2/3, đồng thời cải thiện integration with Amazon EventBridge để tự động kích hoạt các workflow khác sau khi deploy thành công.

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

1. Amazon AppFlow

   • Mô tả: Dịch vụ đồng bộ dữ liệu (data integration) giữa các SaaS (Salesforce, Slack, Google Analytics,…) và dịch vụ AWS (S3, Redshift, …).
   • Tại sao sai: AppFlow không liên quan tới việc triển khai ứng dụng; nó chỉ di chuyển dữ liệu theo lịch hoặc sự kiện, không có chức năng tự động release code.

2. AWS PrivateLink

   • Mô tả: Cung cấp kết nối riêng tư (private connectivity) từ VPC tới các dịch vụ AWS hoặc dịch vụ của bên thứ ba thông qua interface VPC endpoints.
   • Tại sao sai: PrivateLink chỉ giải quyết vấn đề mạng và bảo mật khi truy cập dịch vụ, không thực hiện bất kỳ công việc nào liên quan tới deployment hay CI/CD.

3. Amazon EKS Distro

   • Mô tả: Bản phân phối Kubernetes (EKS‑D) được đóng gói và có thể chạy trên môi trường on‑premise hoặc các cloud khác, giúp bạn chạy Kubernetes giống như trên EKS.
   • Tại sao sai: EKS Distro cung cấp cơ sở hạ tầng Kubernetes, không phải là công cụ tự động release. Bạn vẫn cần kubectl, Helm, hoặc AWS CodeDeploy for Kubernetes để thực hiện việc triển khai.

🧩 Tổng hợp lại (danh sách)

• Câu hỏi: Tìm dịch vụ AWS cho phép release tự động các thay đổi ứng dụng.
• Đáp án đúng: AWS CodeDeploy 🟢
• Lý do chọn CodeDeploy:
  • Tự động hoá deployment cho EC2, Lambda, on‑prem, container.
  • Hỗ trợ chiến lược blue/green, in‑place, rollback.
  • Tích hợp sẵn với CodePipeline, GitHub, Jenkins, EventBridge.
• Các đáp án sai:
  • Amazon AppFlow – dịch vụ đồng bộ dữ liệu, không có chức năng deploy. ❌
  • AWS PrivateLink – cung cấp kết nối mạng riêng tư, không liên quan tới deployment. ❌
  • Amazon EKS Distro – bản phân phối Kubernetes, chỉ cung cấp nền tảng, không tự động release. ❌

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

• AWS Documentation – AWS CodeDeploy: https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html
• AWS Re:Invent 2023 – “Deep Dive into AWS CodeDeploy” (video & slides) – cập nhật các tính năng mới như deployment groups cho Graviton, EventBridge integration.
• AWS Whitepaper – “Continuous Delivery on AWS” (phiên bản 2025) – mô tả cách kết hợp CodePipeline + CodeDeploy để xây dựng pipeline tự động.
• AWS Blog – “Introducing Amazon EKS‑Distro 1.28” (2025) – nhắc lại rằng EKS‑Distro chỉ là nền tảng Kubernetes, không phải công cụ deploy.

💡 Mẹo thực hành: Khi thiết kế pipeline CI/CD trên AWS, thường kết hợp AWS CodeCommit / GitHub → AWS CodeBuild → AWS CodeDeploy → AWS CodePipeline để có quy trình commit → build → test → release hoàn toàn tự động, giảm thiểu thời gian đưa tính năng mới ra production.

Hy vọng phân tích trên giúp bạn nắm rõ lý do tại sao AWS CodeDeploy là câu trả lời đúng và các lựa chọn còn lại không phù hợp với yêu cầu “automated release of application changes”. 🚀

🔎 Phân tích câu hỏi
Câu hỏi yêu cầu xác định perspective (khía cạnh) nào trong AWS Cloud Adoption Framework (AWS CAF) chịu trách nhiệm quản lý danh tính (identities) và quyền truy cập (permissions) ở quy mô lớn. AWS CAF gồm 6 perspective: Business, People, Governance, Platform, Security, Operations. Mỗi perspective tập trung vào một nhóm mục tiêu và hoạt động khi khách hàng di chuyển lên đám mây.

✅ Đáp án đúng

👉 Security

Lý do:

• Perspective Security được thiết kế để “protect data, systems, and assets” và bao gồm Identity & Access Management (IAM), governance of permissions, detection & response, và bảo mật mạng.
• Trong tài liệu AWS CAF (phiên bản 2024‑2025) mô tả rõ ràng: “The Security perspective helps organizations manage identities, permissions, and security controls at scale across AWS accounts, services, and workloads.”
• Do vậy, quản lý danh tính và quyền truy cập ở quy mô lớn (multi‑account, multi‑region, automation) thuộc phạm vi chính của perspective này.

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

• [SAI] Operations

  • Giải thích: Perspective Operations tập trung vào quản lý vận hành, bao gồm monitoring, incident response, và continuous improvement của các workload đã chạy trên AWS. Nó không chuyên sâu về việc thiết lập và quản lý IAM hoặc quyền truy cập.
  • Kết luận: ❌ Không phải là đáp án đúng.

• [SAI] Platform

  • Giải thích: Perspective Platform liên quan tới thiết kế và xây dựng nền tảng công nghệ (network, compute, storage, database), tối ưu hoá kiến trúc và cung cấp môi trường cho các ứng dụng. Mặc dù có thể cấu hình IAM role cho các service, nhưng mục tiêu chính không phải là quản lý danh tính và quyền truy cập ở quy mô.
  • Kết luận: ❌ Không phải là đáp án đúng.

• [SAI] Governance

  • Giải thích: Governance tập trung vào quản trị, tuân thủ, và rủi ro (policy, audit, cost management, risk assessment). Nó xác định who can do what ở mức chính sách, nhưng không trực tiếp quản lý thực tế các identities và permissions trong IAM. Governance thường phụ thuộc vào dữ liệu và báo cáo được cung cấp bởi perspective Security.
  • Kết luận: ❌ Không phải là đáp án đúng.

• [ĐÚNG] Security

  • Giải thích: Như đã nêu ở trên, Security perspective định nghĩa, triển khai và duy trì các cơ chế IAM, role, policy, và permission boundaries. Nó cung cấp các best practices để scale identity management qua việc sử dụng AWS Organizations, Service Control Policies (SCP), IAM Access Analyzer, và các giải pháp tự động hoá (AWS CloudFormation, CDK, Terraform).
  • Kết luận: ✅ Đúng.

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

1. AWS Cloud Adoption Framework (CAF) – Official Documentation (phiên bản 2024‑2025).
   • Link: https://docs.aws.amazon.com/whitepapers/latest/aws-cloud-adoption-framework/overview.html
2. AWS Security Best Practices – AWS Well‑Architected Framework, Security Pillar.
   • Link: https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/security-pillar.html
3. AWS Identity and Access Management (IAM) User Guide – phần “Managing Access at Scale”.
   • Link: https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html

🛠️ Kết luận nhanh

• Câu hỏi: “Which AWS CAF perspective focuses on managing identities and permissions at scale?”
• Đáp án: Security.
• Các perspective khác (Operations, Platform, Governance) đều có mục tiêu riêng, không phải là việc quản lý danh tính và quyền truy cập ở quy mô lớn.

Hy vọng giải thích trên đã giúp bạn nắm rõ lý do lựa chọn và hiểu được vai trò của từng perspective trong AWS CAF! 🚀