Ngân hàng đề — AWS Certified Security Specialty

🧩 Giải thích chi tiết nội dung câu hỏi

Câu hỏi mô tả tình huống một kỹ sư bảo mật nhận thông báo về hoạt động đáng ngờ từ một instance EC2 dựa trên Linux sử dụng lưu trữ Amazon EBS. Instance này đang thực hiện các kết nối outbound (ra ngoài) đến các địa chỉ IP độc hại đã biết (known malicious addresses).

📍 Bối cảnh hạ tầng:

• Instance nằm trong tài khoản development, VPC tại Region us-east-1.
• VPC có Internet Gateway (IGW), subnet tại us-east-1a và us-east-1b.
• Mỗi subnet có route table sử dụng IGW làm default route (0.0.0.0/0 → IGW), cho phép outbound internet.
• Sử dụng default Network ACL (NACL) (allow all inbound/outbound).
• Instance đáng ngờ duy nhất trong subnet us-east-1b.

🎯 Mục tiêu: Tìm hành động ngay lập tức giảm thiểu (mitigate) cuộc tấn công (ngăn instance tiếp tục kết nối ra ngoài) VÀ hỗ trợ điều tra nguyên nhân gốc rễ (root cause), mà không làm gián đoạn quá mức hoặc mất dữ liệu runtime.

🛠️ Kiến thức AWS liên quan (cập nhật 2026):

• Security Groups (SG): Stateful, mặc định allow all outbound. Chỉ hiệu quả inbound; không block outbound dễ dàng.
• Network ACLs (NACL): Stateless, rule-based (numbered, lowest first), apply per subnet (ảnh hưởng tất cả instances trong subnet). Default NACL allow all.
• Instance ở subnet riêng (chỉ 1), nên NACL subnet lý tưởng để block outbound nhanh.
• Không dùng SSM/Fleet Manager ở đây vì cần isolate nhanh.

📘 Tài liệu tham khảo:

• AWS VPC NACL Documentation (quy tắc deny first rule).
• AWS EC2 Security Best Practices (isolate compromised instances).
• AWS Security Incident Response.

✅ Đáp án đúng: Phương án thứ 2 (Đánh dấu [ĐÚNG] trong câu hỏi)

Update the outbound network ACL for the subnet in us-east-1 b to explicitly deny all connections as the first rule. Replace the security group with a new security group that allows connections only from a diagnostics security group. Update the outbound network ACL for the us-east-1 b subnet to remove the deny all rule. Launch a new EC2 instance that has diagnostic tools. Assign the new security group to the new EC2 instance. Use the new EC2 instance to investigate the suspicious instance.

Lý do chọn đáp án này 🏆:

• Mitigate ngay lập tức: Thêm rule deny all outbound (rule #100, ví dụ) làm first rule trong outbound NACL của subnet us-east-1b → Block tất cả traffic ra ngoài từ instance đáng ngờ (duy nhất trong subnet), ngăn C2 communication. NACL stateless nên deny explicit trước allow default.
• Hỗ trợ investigate root cause an toàn:
  • Thay SG của instance đáng ngờ bằng new SG chỉ allow inbound từ diagnostics SG → Chỉ cho phép kết nối từ bastion mới, tránh login trực tiếp (rủi ro).
  • Launch new EC2 (bastion) trong cùng subnet với diagnostics SG → Có thể SSH/scan instance đáng ngờ qua private IP (inbound allowed).
  • Remove deny all NACL sau → New bastion có outbound (nếu cần tools như Wireshark), nhưng instance đáng ngờ vẫn isolate nếu cần (hoặc monitor).
• Hoàn hảo vì subnet chỉ 1 instance ban đầu, không ảnh hưởng others. Tuân thủ least privilege & zero trust.

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

• [SAI] Log in to the suspicious instance and use the netstat command to identify remote connections. Use the IP addresses from these remote connections to create deny rules in the security group of the instance. Install diagnostic tools on the instance for investigation. Update the outbound network ACL for the subnet in us-east-1b to explicitly deny all connections as the first rule during the investigation of the instance. ❌ Sai vì: Không mitigate ngay lập tức – Login trực tiếp vào instance compromised rủi ro cao (có thể kích hoạt malware, exfil data thêm). SG không block outbound hiệu quả (default allow all outbound; chỉ inbound-focused). NACL deny all cuối cùng, không phải first rule → Không block kịp. Quá trình chậm, không isolate trước investigate.

• [ĐÚNG] Update the outbound network ACL for the subnet in us-east-1 b to explicitly deny all connections as the first rule. Replace the security group with a new security group that allows connections only from a diagnostics security group. Update the outbound network ACL for the us-east-1 b subnet to remove the deny all rule. Launch a new EC2 instance that has diagnostic tools. Assign the new security group to the new EC2 instance. Use the new EC2 instance to investigate the suspicious instance. ✅ Đúng (như giải thích trên). Isolate subnet nhanh + investigate gián tiếp qua bastion mới. Lý tưởng cho incident response.

• [SAI] Ensure that the Amazon Elastic Block Store (Amazon EBS) volumes that are attached to the suspicious EC2 instance will not delete upon termination. Terminate the instance. Launch a new EC2 instance in us-east-1a that has diagnostic tools. Mount the EBS volumes from the terminated instance for investigation. ❌ Sai vì: Terminate instance → Mất toàn bộ runtime memory/processes (malware có thể chỉ in RAM), chỉ forensics disk EBS (không đủ root cause như network connections live). Không mitigate ngay – Instance vẫn kết nối độc hại đến khi terminate (có thể exfil data). Mount EBS cross-AZ (1a từ 1b) chậm, không real-time.

• [SAI] Create an AWS WAF web ACL that denies traffic to and from the suspicious instance. Attach the AWS WAF web ACL to the instance to mitigate the attack. Log in to the instance and install diagnostic tools to investigate the instance. ❌ Sai vì: AWS WAF không attach trực tiếp vào EC2 instance (chỉ cho ALB/NLB, API Gateway, CloudFront, AppSync). Không block outbound traffic từ EC2 (WAF chủ yếu web traffic inbound). Login trực tiếp rủi ro, không mitigate isolate. WAF không phù hợp cho non-HTTP suspicious activity.

🔍 Kết luận: Phương án đúng cân bằng mitigate (NACL deny first) + investigate an toàn (SG + bastion), phù hợp AWS best practices 2026! 🚀

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi xoay quanh một công ty truyền thông trực tuyến có ứng dụng phát sự kiện toàn cầu, chạy trên fleet EC2 instances với Amazon Linux 2, quản lý bằng AWS Systems Manager (SSM). Họ đang dùng AWS-AmazonLinux2DefaultPatchBaseline để patch định kỳ.

📌 Yêu cầu chính:

• Triển khai patch NGAY LẬP TỨC (immediately deploy) cho tất cả EC2 instances khi có sự cố bảo mật (security incident hoặc vulnerability).
• Cung cấp bằng chứng tập trung (centralized evidence) rằng patch đã apply thành công.
• Chọn TWO steps kết hợp để đáp ứng.

🛠️ Bối cảnh AWS mới nhất (2026): SSM Patch Manager hỗ trợ Patch Now cho on-demand patching ngoài maintenance window. Patching baseline có thể custom với approval rule "0 days" để auto-approve security patches ngay khi detect. Logs patching lưu centralized vào S3 cho audit. (Không dùng Quick Setup hoặc Automation mới cho patching on-demand).

✅ Đáp án đúng (Chọn TWO)

Hai phương án đúng là phương án 1 và phương án 2, vì chúng kết hợp tạo baseline aggressive (approval 0 days cho security) làm default + sử dụng Patch Now để trigger immediate scan/install, với logs S3 làm evidence.

• Phương án 1: ✅ Create a new patching baseline in Patch Manager. Specify Amazon Linux 2 as the product. Specify Security as the classification. Set the automatic approval for patches to 0 days. Ensure that the new patching baseline is the designated default for Amazon Linux 2.
  🧩 Lý do đúng: Tạo baseline custom chỉ focus Security classification, approval 0 days nghĩa là patch security được auto-approve ngay lập tức khi scan (không delay). Set làm default baseline cho Amazon Linux 2 đảm bảo apply cho tất cả instances managed. Kết hợp với Patch Now sẽ immediate deploy khi incident xảy ra.

• Phương án 2: ✅ Use the Patch Now option with the scan and install operation in the Patch Manager console to apply patches against the baseline to all nodes. Specify an Amazon S3 bucket as the patching log storage option.
  🧩 Lý do đúng: Patch Now là tính năng on-demand (ngoài maintenance window), chạy scan + install ngay lập tức trên tất cả nodes theo baseline. S3 bucket lưu logs patching centralized, cung cấp evidence (compliance reports, timestamps) chứng minh patch apply thành công – đáp ứng hoàn hảo yêu cầu "immediately" và "centralized evidence".

❌ Giải thích tất cả các phương án (Đúng/Sai)

Dưới đây là phân tích từng phương án một, giữ nguyên text gốc tiếng Anh:

• ✅ Create a new patching baseline in Patch Manager. Specify Amazon Linux 2 as the product. Specify Security as the classification. Set the automatic approval for patches to 0 days. Ensure that the new patching baseline is the designated default for Amazon Linux 2.
  Đúng (như trên): Baseline custom aggressive cho security, approval 0 days + default → sẵn sàng immediate khi trigger Patch Now. 🛡️

• ✅ Use the Patch Now option with the scan and install operation in the Patch Manager console to apply patches against the baseline to all nodes. Specify an Amazon S3 bucket as the patching log storage option.
  Đúng (như trên): On-demand patching + S3 logs = immediate + evidence. ⚡📊

• ❌ Use the Clone function of Patch Manager to create a copy of the AWS-AmazonLmux2DefaultPatchBaseline built-in baseline. Set the automatic approval for patches to 1 day.
  Sai: Clone baseline (lưu ý lỗi typo "AmazonLmux2" → AmazonLinux2) nhưng set approval 1 day → delay 1 ngày, KHÔNG immediately khi incident. Default baseline gốc đã có approval rules chậm hơn, clone không giải quyết on-demand. 😴

• ❌ Create a patch policy that patches all managed nodes and sends a patch operation log output to an Amazon S3 bucket. Use a custom scan schedule to set Patch Manager to check every hour for new patches. Assign the baseline to the patch policy.
  Sai: Patch policy + hourly scan chỉ định kỳ (không on-demand), không trigger immediately response incident. S3 logs tốt nhưng thiếu immediate deploy. Không có Patch Now → không phù hợp. ⏰

• ❌ Use Systems Manager Application Manager to inspect the package versions that were installed on the EC2 instances. Additionally use Application Manager to validate that the patches were correctly installed.
  Sai: Application Manager (mới trong SSM) dùng quản lý ứng dụng/packages (như distribute, inventory), KHÔNG phải patching. Không deploy patch immediate, chỉ inspect/validate sau → không đáp ứng deploy + evidence patching. 🚫

📘 Tài liệu tham khảo (AWS cập nhật 2026)

• AWS Systems Manager Patch Manager - Patch Now ⚡: Hướng dẫn on-demand patching.
• Custom Patching Baselines 🛡️: Approval rules 0 days cho security.
• Patch Logging to S3 📊: Centralized evidence.
• AWS DOP-C02 Exam Guide – Chủ đề SSM Patch Manager (Domain 4: Automation).

Kết hợp 1 + 2 là giải pháp tối ưu, nhanh nhất cho incident response! 🚀

🧩 Phân tích chi tiết câu hỏi trắc nghiệm AWS

📖 Nội dung câu hỏi được giải thích rõ ràng:
Câu hỏi mô tả một tình huống thực tế trong môi trường AWS: Một đội DevOps sử dụng IAM để quản lý quyền truy cập. Họ đã tạo EC2 instance profile role gắn với AWS managed policy ReadOnlyAccess. Ứng dụng chạy trên Amazon EC2 cố gắng đọc file từ Amazon S3 bucket được mã hóa (encrypted), nhưng nhận lỗi AccessDenied.

Quản trị viên đã kiểm tra:

• S3 bucket policy cho phép mọi người trong account (Principal: account root) truy cập bucket.
• Không có object ACL gắn với file.

🛠️ Vấn đề cốt lõi: Bucket S3 được mã hóa bằng AWS KMS (Key Management Service) (mặc định hoặc customer-managed key). Policy ReadOnlyAccess chỉ cung cấp quyền read-only cho hầu hết AWS services (bao gồm s3:GetObject), nhưng thiếu quyền kms:Decrypt cần thiết để giải mã object. Do đó, dù có quyền đọc S3, ứng dụng không thể decrypt dữ liệu → lỗi AccessDenied.

(Kiến thức cập nhật 2026: AWS vẫn yêu cầu kms:Decrypt explicit cho S3 SSE-KMS, theo docs mới nhất. ReadOnlyAccess không bao gồm KMS actions đầy đủ cho decrypt encrypted objects).

✅ Đáp án đúng:
Attach an inline policy with kms:Decrypt permissions to the IAM role

Lý do lựa chọn (chi tiết):
🧩 Policy ReadOnlyAccess (AWS managed) cho phép s3:GetObject và read-only các services khác, nhưng không bao gồm kms:Decrypt – quyền bắt buộc để giải mã S3 object encrypted bằng KMS.

• Bucket policy đã allow account-level access → không cần chỉnh bucket policy.
• Giải pháp tối ưu: Gắn inline policy (customer-managed) vào IAM role của EC2 instance profile với kms:Decrypt (và có thể chỉ định Key ARN cụ thể).
• Điều này tuân thủ least privilege principle (nguyên tắc quyền tối thiểu), chỉ thêm quyền cần thiết mà không chỉnh AWS managed policy hay mở rộng S3:* quá mức.
  ✅ Kết quả: EC2 role có đầy đủ quyền → ứng dụng đọc file thành công.

🔍 Giải thích tất cả các phương án (đúng/sai):
Dưới đây là phân tích từng lựa chọn, giữ nguyên nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá với lý do cụ thể dựa trên IAM/S3/KMS best practices (2026).

• Edit the ReadOnlyAccess policy to add kms:Decrypt actions
❌ Sai. AWS managed policies (như ReadOnlyAccess) không thể chỉnh sửa bởi user – chúng được AWS quản lý và cập nhật tự động. Việc cố edit sẽ thất bại. Thay vào đó, phải attach thêm policy riêng (inline hoặc customer-managed).

• Add the EC2 IAM role as the authorized Principal to the S3 bucket policy
❌ Sai. Bucket policy đã allow everyone in the account (Principal: {"AWS": "arn:aws:iam::ACCOUNT-ID:root"}), bao gồm cả EC2 role thuộc account đó. Vấn đề không phải quyền S3 access mà là kms:Decrypt cho encryption – chỉnh bucket policy không giải quyết.

• Attach an inline policy with kms:Decrypt permissions to the IAM role
✅ Đúng. Như giải thích ở trên: Inline policy cho phép thêm kms:Decrypt (ví dụ: "Action": "kms:Decrypt", "Resource": "arn:aws:kms:region:account:key/key-id") trực tiếp vào IAM role của EC2 instance profile. Đây là cách an toàn, least privilege, không ảnh hưởng AWS managed policy.

• Attach an inline policy with S3: permissions to the IAM role*
❌ Sai. S3:* cấp quyền đầy đủ trên S3 (create, delete, etc.), vi phạm least privilege và security best practices. ReadOnlyAccess đã đủ s3:GetObject; chỉ cần bổ sung kms:Decrypt thôi – không cần mở rộng S3 quyền.

📘 Tài liệu tham khảo (AWS docs cập nhật 2026):

• IAM ReadOnlyAccess policy – Xác nhận thiếu KMS decrypt.
• S3 Server-Side Encryption with KMS – Yêu cầu kms:Decrypt cho GetObject.
• IAM Inline Policies – Hướng dẫn attach inline policy.
• Troubleshoot S3 AccessDenied – Phần KMS permissions.

🛠️ Mẹo DevOps: Luôn kiểm tra CloudTrail logs và IAM Policy Simulator để debug IAM issues tương tự!

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào vấn đề giám sát sự kiện Kubernetes (như việc tạo pod) trong môi trường Amazon EKS (Elastic Kubernetes Service) được triển khai trên nhiều tài khoản AWS trong AWS Organizations.

• Bối cảnh: Công ty đã tích hợp EKS với AWS CloudTrail để ghi log các API calls AWS, lưu trữ trong S3 bucket riêng từng account. Tuy nhiên, CloudTrail logs không hiển thị sự kiện tạo pod Kubernetes (Kubernetes pod creation events).
• Vấn đề cốt lõi: CloudTrail chỉ ghi lại các API calls của AWS services (như CreateCluster, UpdateCluster), không ghi Kubernetes API calls nội bộ (như pod creation, deployment updates) diễn ra bên trong EKS cluster. Những sự kiện này thuộc về Kubernetes control plane.
• Mục tiêu: Security engineer muốn xem các sự kiện Kubernetes này từ Amazon CloudWatch (chuyển log Kubernetes sang CloudWatch Logs để query và phân tích).
• Phiên bản AWS cập nhật 2026: EKS hỗ trợ control plane logging với 7 loại log components (API server, audit, authenticator, controller manager, scheduler, kube-proxy, kubelet – mới thêm từ 2023+), gửi trực tiếp đến CloudWatch Logs mà không cần agent bên ngoài.

📘 Tài liệu tham khảo:

• Amazon EKS Control Plane Logging (AWS Docs, cập nhật 2025).
• CloudTrail Limitations with EKS (khẳng định CloudTrail không capture K8s API calls).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Enable Kubernetes API server component logs for each cluster.

Lý do 🛠️:

• Sự kiện tạo pod là Kubernetes API call (gọi đến API server của EKS control plane). Để capture và xem trong CloudWatch, cần enable log cho API server component trong EKS control plane logging.
• Quy trình: Sử dụng AWS CLI (aws eks update-cluster-config --region <region> --name <cluster> --logging '{"clusterLogging":[{"types":["api","audit"],"enabled":true}]}) hoặc Console EKS > Cluster > Logging > Enable API server và Audit logs. Logs sẽ tự động stream đến CloudWatch Logs group /aws/eks//cluster.
• Điều này áp dụng cho mỗi cluster trong multi-account setup (sử dụng AWS Organizations SCPs để enforce policy).
• Kết quả: Có thể query pod creation events (ví dụ: kubectl create pod logs) trực tiếp từ CloudWatch Logs Insights.

📋 Giải thích tất cả các phương án (đúng/sai)

• ❌ Configure the EKS clusters to use private S3 VPC endpoints. Configure the S3 buckets for logging.
  Phân tích sai: Phương án này chỉ giải quyết network access đến S3 (private endpoints tránh public internet), nhưng không liên quan đến việc capture Kubernetes events. CloudTrail logs AWS API calls đã lưu S3 rồi, vấn đề là thiếu K8s pod events (không phải AWS API). VPC endpoints hữu ích cho security nhưng không fix vấn đề gốc.

• ✅ Enable Kubernetes API server component logs for each cluster.
  Phân tích đúng: Như giải thích trên, đây là cách chính xác để stream K8s API server logs (bao gồm pod creation) trực tiếp vào CloudWatch Logs. Audit logs bổ sung để track user actions. Áp dụng multi-account qua AWS Organizations (tạo CloudWatch Logs roles per cluster).

• ❌ Enable cross-origin resource sharing (CORS) in the S3 bucket that is used for logging.
  Phân tích sai: CORS dùng cho web browser access S3 objects (như static website), không liên quan đến CloudTrail/EKS logging hay Kubernetes events. CloudTrail delivers logs via AWS internal, không cần CORS. Đây là nhầm lẫn về S3 features.

• ❌ Configure CloudWatch. View the events in the CloudWatch console.
  Phân tích sai: Vague và không cụ thể. CloudWatch cần source logs trước (từ EKS control plane), chỉ "configure" chung chung không enable API server logs thì vẫn không có K8s events. CloudWatch console chỉ xem nếu logs đã stream; vấn đề là thiếu enable logging ở EKS.

🛡️ Lời khuyên thực tế (DevOps Pro): Sau khi enable, dùng CloudWatch Logs Insights query pattern như fields @timestamp, @message | filter @message like /pod/ | sort @timestamp desc để monitor pod events. Kết hợp Amazon GuardDuty for EKS (2024+) cho threat detection tự động!

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào việc một security engineer cần xây dựng giải pháp tự động và hiệu quả nhất để bật lại AWS CloudTrail ở nhiều AWS Regions nếu nó bị tắt.

• AWS CloudTrail là dịch vụ ghi log các hoạt động API trên AWS, rất quan trọng cho bảo mật và tuân thủ.
• Vấn đề: CloudTrail có thể bị tắt thủ công hoặc do lỗi, cần cơ chế phát hiện và khắc phục tự động (remediation) ở quy mô đa vùng (multi-Region).
• Yêu cầu chính: Giải pháp phải hiệu quả nhất (MOST efficient), nghĩa là đơn giản, tự động, không cần code tùy chỉnh nhiều, và hỗ trợ multi-Region native.

🛠️ Bối cảnh AWS cập nhật 2026: AWS Config hỗ trợ managed rules cho CloudTrail với remediation tự động qua AWS Systems Manager Automation, bao gồm action AWS-EnableCloudTrail để bật logging. Đây là best practice cho compliance as code.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Use AWS Config with a managed rule to initiate the AWS-EnableCloudTrail remediation.

Lý do:

• AWS Config là dịch vụ giám sát cấu hình tài nguyên native, hỗ trợ multi-Region qua aggregator.
• Có managed rule sẵn như cloud-trail-logging-enabled (hoặc tương đương), tự động phát hiện khi CloudTrail trail bị tắt.
• Remediation action: Sử dụng AWS-EnableCloudTrail qua SSM Automation để gọi API StartLogging tự động, không cần Lambda code.
• Hiệu quả nhất: Không code, chi phí thấp, dễ scale, tích hợp compliance dashboard. ✅ Hoàn hảo cho multi-Region vì Config rule deploy global.

📋 Giải thích tất cả các phương án (đúng/sai)

• ✅ Use AWS Config with a managed rule to initiate the AWS-EnableCloudTrail remediation.
  🛠️ Đúng vì: Managed rule của AWS Config (như cloud-trail-logging-enabled) liên tục kiểm tra trạng thái CloudTrail ở tất cả Regions. Khi NON_COMPLIANT, tự trigger remediation AWS-EnableCloudTrail (SSM document) để gọi StartLogging API. Hỗ trợ multi-Region native, không code, tuân thủ AWS Well-Architected Framework (Security Pillar). Đây là giải pháp managed và efficient nhất.

• ❌ Create an Amazon EventBridge event with a cloudtrail.amazonaws.com event source and a StartLogging event name to invoke an AWS Lambda function to call the StartLogging API.
  ❌ Sai vì: EventBridge không có event source cloudtrail.amazonaws.com native cho việc tắt/bật logging (CloudTrail events là data events hoặc management events, không trigger trực tiếp từ StartLogging). Phải custom rule phức tạp, cần Lambda code để parse và gọi API – kém efficient, khó scale multi-Region, và không phát hiện "tắt" một cách chủ động.

• ❌ Create an Amazon CloudWatch alarm with a cloudtrail.amazonaws.com event source and a StopLoggmg event name to invoke an AWS Lambda function to call the StartLogging API.
  ❌ Sai vì: CloudWatch Alarms không hỗ trợ event source cloudtrail.amazonaws.com (lỗi chính tả "StopLoggmg" cũng cho thấy không chính xác). Alarms dùng cho metrics, không phải events như StopLogging (thuộc CloudTrail API). Cần Lambda custom, không detect "tắt" CloudTrail hiệu quả, và không scale multi-Region dễ dàng – tốn công code và kém reliable.

• ❌ Monitor AWS Trusted Advisor to ensure CloudTrail logging is enabled.
  ❌ Sai vì: Trusted Advisor chỉ check và cảnh báo (recommendations) về CloudTrail enabled, không có remediation tự động. Phải manual fix, không hỗ trợ trigger action ở multi-Region, và không phải giải pháp "build" tự động. Chỉ là monitoring thụ động, không efficient cho production security.

📘 Tài liệu tham khảo (AWS cập nhật 2026)

• AWS Config Managed Rules: AWS Config Rules for CloudTrail – Rule cloud-trail-logging-enabled + Remediation AWS-EnableCloudTrail.
• SSM Automation: AWS Systems Manager Automation Documents – Chi tiết AWS-EnableCloudTrail.
• Best Practices: AWS Well-Architected Framework (Security Pillar) – Logging & Monitoring.
• Multi-Region: AWS Config Aggregators docs.

🧩 Kết luận: Giải pháp AWS Config là best practice cho automation compliance, tiết kiệm thời gian và giảm lỗi! 🚀

🧩 Phân tích chi tiết câu hỏi trắc nghiệm AWS

📖 Giải thích nội dung câu hỏi:
Câu hỏi mô tả một công ty thương mại điện tử đang xây dựng kiến trúc mới cho việc triển khai ứng dụng. Họ cần triển khai TLS (Transport Layer Security) cho lưu lượng truy cập đến từ internet, bao gồm cả HTTP (port 80) và HTTPS (port 443). Yêu cầu chính là TLS chỉ áp dụng cho traffic incoming (không cần end-to-end để tránh ảnh hưởng hiệu suất). Load balancer phải xử lý traffic từ internet, hỗ trợ redirect HTTP sang HTTPS, và forward traffic nội bộ mà không cần mã hóa end-to-end. Đây là kịch bản điển hình sử dụng Application Load Balancer (ALB) để offload TLS tại layer 7, giúp đơn giản hóa và tối ưu performance. 🛡️

✅ Đáp án đúng:
Phương án đầu tiên:
Create a public Application Load Balancer. Create two listeners: one listener on port 80 and one listener on port 443. Create one target group. Create a rule to forward traffic from port 80 to the listener on port 443. Provision a public TLS certificate in AWS Certificate Manager (ACM). Attach the certificate to the listener on port 443.

Lý do lựa chọn (bằng tiếng Việt):
✅ Phương án này hoàn hảo vì sử dụng ALB (Application Load Balancer) – loại LB layer 7 hỗ trợ HTTP/HTTPS listeners, rules để redirect traffic từ port 80 (HTTP) sang port 443 (HTTPS) một cách thông minh. Chứng chỉ TLS từ ACM được gắn vào listener 443 để terminate TLS ngay tại ALB, sau đó forward HTTP plain-text đến target group (không end-to-end TLS, phù hợp yêu cầu performance). ALB public xử lý traffic internet trực tiếp. Đây là best practice theo AWS Well-Architected Framework. 🚀

🛠️ Phân tích chi tiết từng phương án (đúng/sai)

• ✅ Phương án ĐÚNG (Phương án 1):
  Create a public Application Load Balancer. Create two listeners: one listener on port 80 and one listener on port 443. Create one target group. Create a rule to forward traffic from port 80 to the listener on port 443. Provision a public TLS certificate in AWS Certificate Manager (ACM). Attach the certificate to the listener on port 443.
  Giải thích: Hoàn toàn chính xác! ALB hỗ trợ listeners riêng biệt cho port 80 (HTTP) và 443 (HTTPS), với target group chung. Rule redirect 80 → 443 listener (sử dụng action "redirect") đảm bảo HTTP tự động chuyển sang HTTPS. ACM cert gắn listener 443 để TLS termination tại LB, traffic nội bộ là HTTP plain giúp tối ưu CPU. Không vi phạm yêu cầu end-to-end. 🏆

• ❌ Phương án SAI (Phương án 2):
  Create a public Application Load Balancer. Create two listeners one listener on port 80 and one listener on port 443. Create one target group. Create a rule to forward traffic from port 80 to the listener on port 443. Provision a public TLS certificate in AWS Certificate Manager (ACM). Attach the certificate to the listener on port 80.
  Giải thích: Gần đúng nhưng sai nghiêm trọng ở việc gắn cert TLS vào listener port 80. Port 80 chỉ hỗ trợ HTTP protocol, không thể gắn TLS cert (sẽ lỗi khi configure). Cert phải gắn listener 443 (HTTPS). Điều này làm ALB không hoạt động đúng cho HTTPS incoming. 🤦‍♂️

• ❌ Phương án SAI (Phương án 3):
  Create a public Network Load Balancer. Create two listeners one listener on port 80 and one listener on port 443. Create one target group. Create a rule to forward traffic from port 80 to the listener on port 443. Set the protocol for the listener on port 443 to TLS.
  Giải thích: Sai vì NLB (Network Load Balancer) là layer 4, chỉ hỗ trợ TCP/UDP/TLS listeners mà không có rules HTTP-level như redirect (không hỗ trợ "forward from 80 to 443 listener"). NLB không parse HTTP, nên không redirect được HTTP → HTTPS. Protocol TLS chỉ áp dụng listener 443, nhưng port 80 sẽ là TCP plain, không xử lý redirect. Không phù hợp cho ứng dụng web cần HTTP handling. 🚫

• ❌ Phương án SAI (Phương án 4):
  Create a public Network Load Balancer. Create a listener on port 443. Create one target group. Create a rule to forward traffic from port 443 to the target group. Set the protocol for the listener on port 443 to TLS.
  Giải thích: Sai hoàn toàn vì chỉ có listener 443, bỏ qua port 80 (HTTP incoming) – traffic HTTP từ internet sẽ bị drop. NLB TLS listener chỉ terminate TLS và forward TCP, không có rule redirect và không handle HTTP. Không đáp ứng yêu cầu hỗ trợ cả HTTP/HTTPS ports. Thiếu linh hoạt cho ứng dụng ecommerce. ⛔

📘 Tài liệu tham khảo (kiến thức cập nhật đến 2026)

• AWS ALB Listeners & Rules: docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html – Xác nhận redirect HTTP → HTTPS và ACM integration (cập nhật 2024+).
• NLB vs ALB Comparison: docs.aws.amazon.com/elasticloadbalancing/latest/userguide/load-balancer-types.html – NLB không hỗ trợ HTTP rules (vẫn đúng đến 2026).
• ACM for ALB: docs.aws.amazon.com/acm/latest/userguide/acm-services.html – Free public certs cho ALB/NLB.
• AWS Well-Architected Security Pillar: Khuyến nghị ALB cho TLS offload để optimize performance. 🌐

Hy vọng phân tích này giúp bạn ôn thi DOP-C02 hiệu quả! Nếu cần thêm ví dụ thực hành, hỏi nhé! 💪

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

Câu hỏi tập trung vào việc bảo vệ dữ liệu quan trọng trong Amazon S3 khỏi bị xóa vĩnh viễn, đồng thời đáp ứng yêu cầu phục hồi thảm họa (disaster recovery - DR) bằng cách replicate dữ liệu từ primary AWS Region sang secondary Region. Cụ thể:

• Dữ liệu lưu trữ trong S3 buckets.
• Phải replicate objects sang secondary Region.
• Quan trọng nhất: Ngay cả users có quyền administrator cũng không thể xóa vĩnh viễn dữ liệu ở secondary Region.

Mục tiêu là tìm giải pháp kết hợp replication và cơ chế bảo vệ mạnh mẽ nhất (không thể bypass bởi admin), phù hợp với các tính năng S3 mới nhất đến năm 2026 như S3 Object Lock và Cross-Region Replication (CRR). 📘 Tài liệu tham khảo: AWS S3 Object Lock, S3 Replication.

✅ Đáp án đúng

Implement S3 Object Lock in compliance mode in the primary Region. Configure S3 replication to replicate the objects to an S3 bucket in the secondary Region.

Lý do lựa chọn:

• S3 Object Lock ở compliance mode khóa objects với retention period cố định, không ai (kể cả root/admin) có thể xóa hoặc sửa trước thời hạn – đây là cơ chế WORM (Write Once, Read Many) mạnh nhất. 🛡️️
• Khi cấu hình S3 Replication (CRR), Object Lock settings (bao gồm compliance mode) sẽ tự động replicate sang bucket đích ở secondary Region nếu bucket đích cũng enable Object Lock.
• Đáp ứng DR: Dữ liệu replicate cross-Region.
• Bảo vệ admin delete: Compliance mode không cho phép bypass, khác với governance mode.
• Cập nhật 2026: Tính năng này ổn định từ 2020 và hỗ trợ đầy đủ metrics/monitoring qua S3 Inventory. 🏆

🛠️ Phân tích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn theo thứ tự. Tôi giữ nguyên văn bản gốc tiếng Anh của phương án, đánh dấu ✅/❌ và giải thích hoàn toàn bằng tiếng Việt lý do đúng/sai dựa trên tính năng AWS mới nhất.

• Configure AWS Backup to perform cross-Region S3 backups. Select a backup vault in the secondary Region. Enable AWS Backup Vault Lock in governance mode for the backups in the secondary Region.
  ❌ Sai vì: AWS Backup chỉ tạo backup/copy chứ không phải replicate objects trực tiếp như yêu cầu DR real-time. Backup Vault Lock ở governance mode có thể bị admin bypass bằng quyền cao hơn, không đảm bảo "không thể xóa vĩnh viễn". Không phù hợp cho S3 objects replication mượt mà. 📉

• Implement S3 Object Lock in compliance mode in the primary Region. Configure S3 replication to replicate the objects to an S3 bucket in the secondary Region.
  ✅ Đúng vì: Như đã giải thích ở trên – compliance mode chặn hoàn toàn delete (kể cả admin), replication giữ nguyên lock settings sang secondary Region. Hoàn hảo cho DR và bảo vệ dữ liệu. Đây là best practice AWS khuyến nghị cho compliance/DR. 🌟
  📘 Nguồn: S3 Object Lock Replication.

• Configure S3 replication to replicate the objects to an S3 bucket in the secondary Region. Create an S3 bucket policy to deny the s3:ReplicateDelete action on the S3 bucket in the secondary Region.
  ❌ Sai vì: s3:ReplicateDelete chỉ ngăn replicate delete markers từ primary, không ngăn delete trực tiếp objects ở secondary Region. Admin vẫn dùng IAM policy hoặc console để xóa vĩnh viễn (qua DeleteObject). Bucket policy không đủ mạnh chống admin quyền cao. 🚫

• Configure S3 replication to replicate the objects to an S3 bucket in the secondary Region. Configure S3 object versioning on the S3 bucket in the secondary Region.
  ❌ Sai vì: Versioning chỉ bảo vệ xóa nhầm bằng cách lưu versions/delete markers, nhưng admin vẫn có thể xóa tất cả versions vĩnh viễn (Permanently Delete). Không chặn được delete có chủ đích từ admin, không đạt yêu cầu "không thể xóa vĩnh viễn". Phổ biến nhưng yếu cho compliance. 🔒

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi xoay quanh một công ty tại Pháp sử dụng Amazon Cognito với Cognito Hosted UI làm identity broker cho quy trình đăng nhập và đăng ký người dùng. Ứng dụng của họ chỉ mong đợi người dùng từ Pháp, nhưng sau khi ra mắt, đội ngũ bảo mật phát hiện nhiều đăng ký giả mạo từ ngoài Pháp (fraudulent sign-ups).

Yêu cầu chính: Cần một giải pháp thực hiện custom validation (kiểm tra tùy chỉnh) tại thời điểm sign-up, dựa trên kết quả để chấp nhận hoặc từ chối yêu cầu đăng ký.

Đây là câu hỏi chọn TWO (hai bước kết hợp) để đáp ứng yêu cầu, tập trung vào việc kiểm soát địa lý (geo-restriction) và validation tùy chỉnh cho Cognito Hosted UI. 📘 Kiến thức AWS cập nhật 2026: Amazon Cognito hỗ trợ các trigger Lambda cho custom logic (pre sign-up), và từ năm 2021, Cognito Hosted UI có thể tích hợp AWS WAF Web ACL để bảo vệ chống tấn công, bao gồm geo-blocking (xem AWS re:Invent 2023+ updates về Cognito Advanced Security).

✅ Đáp án đúng (Chọn TWO)

Hai phương án đúng là sự kết hợp hoàn hảo để thực hiện custom validation tại sign-up và geo-restriction:

1. Create a pre sign-up AWS Lambda trigger. Associate the Amazon Cognito function with the Amazon Cognito user pool.
2. Use a geographic match rule statement to configure an AWS WAF web ACL Associate the web ACL with the Amazon Cognito user pool.

Lý do chọn:

• Pre sign-up Lambda trigger cho phép chạy code tùy chỉnh trước khi hoàn tất sign-up, kiểm tra IP, device, hoặc dữ liệu khác để deny (trả về lỗi) nếu phát hiện fraud từ ngoài Pháp. Đây là cách custom validation chuẩn của Cognito.
• AWS WAF Web ACL với geographic match chặn request từ IP ngoài Pháp ngay từ Hosted UI endpoint, trước khi đến trigger. Kết hợp hai bước này tạo lớp bảo vệ kép: WAF block nhanh (layer 7), Lambda validate sâu hơn. 🛠️ Cách implement: Tạo Lambda trigger trong User Pool > Triggers > Pre sign-up; WAF ACL attach vào User Pool domain (advanced security feature).

📘 Tài liệu tham khảo:

• AWS Cognito Lambda Triggers (updated 2025).
• Protect Cognito Hosted UI with WAF (feature stable từ 2023).

🔍 Giải thích tất cả các phương án (Đúng/Sai)

• ✅ Create a pre sign-up AWS Lambda trigger. Associate the Amazon Cognito function with the Amazon Cognito user pool.
  Đúng: Đây là trigger chuẩn của Cognito, kích hoạt trước sign-up để chạy logic tùy chỉnh (ví dụ: dùng event.request.userAttributes hoặc IP từ event.request.clientMetadata để kiểm tra geo và AutoConfirmUser = false nếu fraud). Hoàn hảo cho custom validation deny registration.

• ✅ Use a geographic match rule statement to configure an AWS WAF web ACL Associate the web ACL with the Amazon Cognito user pool.
  Đúng: AWS WAF hỗ trợ Geo Match rule (dựa trên IP country), attach trực tiếp vào Cognito Hosted UI domain. Chặn request từ ngoài Pháp (ví dụ: block NOT France), giảm tải fraud trước khi đến sign-up process. Kết hợp với trigger tạo bảo vệ toàn diện.

• ❌ Configure an app client for the application's Amazon Cognito user pool. Use the app client ID to validate the requests in the hosted UI.
  Sai: App Client chỉ dùng để authenticate app (client ID/secret cho OAuth), không hỗ trợ geo-validation hoặc custom check cho sign-up. Hosted UI vẫn expose public, không block fraud dựa trên client ID.

• ❌ Update the application’s Amazon Cognito user pool to configure a geographic restriction setting.
  Sai: Cognito User Pool không có built-in geographic restriction (không như API Gateway). Không có setting trực tiếp để limit sign-up theo quốc gia; phải dùng WAF hoặc Lambda trigger.

• ❌ Use Amazon Cognito to configure a social identity provider (IdP) to validate the requests on the hosted UI.
  Sai: Social IdP (như Google, Facebook) dùng cho federated sign-in, không kiểm soát direct sign-up hoặc geo-IP. Không hỗ trợ custom validation cho fraud từ IP lạ; chỉ verify identity từ provider.

🛡️ Lời khuyên DevOps: Kết hợp WAF + Lambda trigger là best practice cho high-security apps. Monitor qua CloudWatch Logs và Cognito Advanced Security để detect anomaly. Test với IP giả lập (AWS IP ranges tool)!

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

Câu hỏi mô tả tình huống một security engineer đang cấu hình AWS Config cho một AWS account mới sử dụng IAM entity mới (có thể là IAM user hoặc role). Khi cố gắng thiết lập AWS Config rules và automatic remediation, xảy ra lỗi. Lỗi cụ thể được ghi trong AWS CloudTrail logs: “Insufficient delivery policy to s3 bucket: DOC-EXAMPLE-BUCKET, unable to write to bucket, provided s3 key prefix is ‘null’.”

📘 Phân tích vấn đề chính:

• AWS Config cần một S3 bucket để lưu trữ configuration snapshots và configuration history (delivery channel).
• Lỗi "Insufficient delivery policy" chỉ ra rằng S3 bucket policy (resource-based policy) không cho phép service principal config.amazonaws.com thực hiện các hành động ghi (như s3:PutObject*) vào bucket.
• "provided s3 key prefix is ‘null’" nghĩa là khi thiết lập AWS Config recorder/delivery channel, không chỉ định prefix (mặc định là null), dẫn đến service không thể ghi dữ liệu.
• Ngoài ra, IAM entity (người thực hiện cấu hình) thiếu quyền cần thiết để verify bucket (như s3:GetBucketAcl), khiến quá trình setup thất bại.
• Giải pháp yêu cầu chọn 2 steps để khắc phục, dựa trên best practices AWS Config (cập nhật đến 2026: vẫn giữ nguyên yêu cầu bucket policy và IAM perms cho setup).

🛠️ Quy trình setup AWS Config điển hình (theo docs AWS mới nhất):

1. Tạo S3 bucket với bucket policy cho phép config.amazonaws.com.
2. Tạo IAM service role cho AWS Config.
3. IAM entity setup cần quyền s3:GetBucketAcl (để kiểm tra bucket) và s3:PutObject* (liên quan đến delivery).
4. Enable recorder qua Console/CLI/API.

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

Hai phương án đúng là:

• Check the Amazon S3 bucket policy. Verify that the policy allows the config amazonaws,com service to write to the target bucket.
• Verify that the IAM entity has the permissions necessary to perform the s3:GetBucketAcl and s3:PutObject operations to write to the target bucket.*

Lý do lựa chọn:

• 🟢 Phương án 1: Bucket policy PHẢI grant quyền cho service principal config.amazonaws.com (không phải IAM entity) để thực hiện s3:PutObject*, s3:GetBucketAcl, s3:PutObjectAcl trên bucket/prefix. Lỗi "Insufficient delivery policy" trực tiếp chỉ vào vấn đề này. Nếu thiếu, service không thể deliver data.
• 🟢 Phương án 2: IAM entity (user/role đang config) cần s3:GetBucketAcl để AWS service verify bucket ACL trước khi setup delivery channel (kiểm tra versioning, ownership). Ngoài ra, s3:PutObject* hỗ trợ write config data nếu prefix null. Đây là yêu cầu bắt buộc theo AWS docs để enable recorder.

📋 Giải thích tất cả các phương án

Dưới đây là phân tích TẤT CẢ lựa chọn (giữ nguyên text gốc), với ✅ đúng hoặc ❌ sai, kèm lý do chi tiết bằng tiếng Việt:

• ✅ Check the Amazon S3 bucket policy. Verify that the policy allows the config amazonaws,com service to write to the target bucket.
  🟢 Đúng: Bucket policy là resource policy phải explicitly allow principal config.amazonaws.com với actions s3:PutObject*, s3:GetBucketAcl, s3:ListBucket. Lỗi CloudTrail trực tiếp match vấn đề "delivery policy". (Lưu ý: text có lỗi typo "amazonaws,com" nhưng ý đúng).

• ✅ Verify that the IAM entity has the permissions necessary to perform the s3:GetBucketAcl and s3:PutObject operations to write to the target bucket.*
  🟢 Đúng: IAM entity setup cần quyền này để gọi API PutConfigRecorder/PutDeliveryChannel. s3:GetBucketAcl verify bucket eligibility; s3:PutObject* hỗ trợ delivery khi prefix null. Thiếu sẽ fail setup.

• ❌ Verify that the Amazon S3 bucket policy has the permissions necessary to perform the s3:GetBucketAcl and s3:PutObject operations to write to the target bucket.*
  🔴 Sai: Bucket policy KHÔNG "has permissions to perform actions" – nó là policy grant quyền CHO principal khác (như service). Bucket policy không tự "perform" actions; nhầm lẫn khái niệm resource policy vs identity policy.

• ❌ Check the policy that is associated with the IAM entity. Verify that the policy allows the config.amazonaws.com service to write to the target bucket.
  🔴 Sai: IAM policy của entity chỉ kiểm soát quyền của entity đó, KHÔNG grant quyền cho service config.amazonaws.com. Service cần bucket policy riêng, không phải IAM policy của entity.

• ❌ Verify that the AWS Config service role has permissions to invoke the BatchGetResourceConfig action instead of the GetResourceConfigHistory action and s3:PutObject operation.*
  🔴 Sai: Service role của AWS Config cần quyền như config:Put*, s3:PutObject, nhưng lỗi KHÔNG liên quan đến Config API actions (BatchGetResourceConfig vs GetResourceConfigHistory – hai API khác nhau, không thay thế). Lỗi là về S3 delivery policy, không phải service role perms.

📚 Tài liệu tham khảo (AWS Docs cập nhật 2026)

• S3 Bucket Policy for AWS Config: https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-policy.html – Chi tiết policy sample cho config.amazonaws.com.
• IAM Permissions for Setup: https://docs.aws.amazon.com/config/latest/developerguide/iamrole-permissions.html – Yêu cầu s3:GetBucketAcl cho principal enable Config.
• Troubleshoot AWS Config: https://docs.aws.amazon.com/config/latest/developerguide/troubleshooting.html – Giải thích lỗi "Insufficient delivery policy".
• CloudTrail Insights: AWS Config events logged với error codes tương tự.

Hy vọng phân tích này giúp bạn ôn thi AWS Certified DevOps Engineer Professional hiệu quả! 🚀 Nếu cần ví dụ policy JSON, hãy hỏi thêm.

🧩 Phân tích nội dung câu hỏi

Câu hỏi tập trung vào tình huống một công ty đang bị tấn công DDoS (Distributed Denial of Service) ở tầng Layer 3 (Network layer - ví dụ: UDP floods, ICMP floods) và Layer 4 (Transport layer - ví dụ: SYN floods) trên các máy chủ web chạy trên AWS.
📌 Mục tiêu: Chọn kết hợp 3 dịch vụ/features AWS để bảo vệ (mitigation) hiệu quả nhất.
🔍 Bối cảnh quan trọng:

• DDoS L3/L4 tấn công trực tiếp vào hạ tầng mạng (IP/TCP/UDP), không phải ứng dụng (L7).
• AWS cung cấp bảo vệ DDoS tự động qua AWS Shield Standard (miễn phí cho tất cả khách hàng), nhưng cần kết hợp các dịch vụ routing và load balancing để tăng cường.
• Kiến thức cập nhật 2026: AWS Shield vẫn là dịch vụ cốt lõi (với Shield Advanced cho pro-active mitigation), tích hợp sâu với Route 53 và NLB để xử lý traffic lớn (hàng Tbps). Không có thay đổi lớn từ 2023-2026, nhưng Shield Response Team (SRT) được nâng cao AI-driven detection.

✅ Đáp án đúng (Chọn 3): Amazon Route 53, AWS Shield, Network Load Balancer

Lý do lựa chọn:
🛡️ AWS Shield là dịch vụ bảo vệ DDoS chính thức, tự động phát hiện và hấp thụ (absorb) tấn công L3/L4 cho tất cả tài nguyên AWS (EC2, ELB, Route 53). Shield Standard miễn phí, kết hợp Shield Advanced cho mitigation nâng cao.
🗺️ Amazon Route 53 cung cấp DDoS protection qua Shield cho DNS queries (L3/L4 floods vào DNS), với global anycast network để phân tán traffic.
⚖️ Network Load Balancer (NLB) xử lý traffic L4 (TCP/UDP), tích hợp Shield để rate limiting và connection reset, giúp web servers không bị overload.
💡 Kết hợp lý tưởng: Shield làm "lá chắn chính" → Route 53 bảo vệ DNS entry point → NLB phân tải L4 traffic, đảm bảo high availability (theo best practice AWS Well-Architected Framework - Reliability pillar).

🛠️ Phân tích chi tiết tất cả các phương án

• ✅ Amazon Route 53
  Đúng: Route 53 sử dụng AWS Global Edge Network và tích hợp AWS Shield để bảo vệ chống DDoS L3/L4 trên DNS resolution. Nó tự động mitigate volumetric attacks (như DNS amplification floods) bằng cách phân tán traffic toàn cầu, giảm latency và downtime. Lý tưởng cho web servers vì hầu hết traffic bắt đầu từ DNS lookup.

• ❌ AWS Certificate Manager (ACM)
  Sai: ACM chỉ quản lý và cấp SSL/TLS certificates cho HTTPS, không có tính năng bảo vệ DDoS. Nó hỗ trợ encryption (Layer 7), không liên quan đến mitigation L3/L4 attacks.

• ❌ Amazon S3
  Sai: S3 là dịch vụ object storage, có DDoS protection qua Shield nhưng chỉ cho bucket static websites. Không phù hợp cho "web servers chạy trên AWS" (thường là EC2/ALB), và S3 không xử lý dynamic traffic L3/L4 trực tiếp.

• ✅ AWS Shield
  Đúng: Dịch vụ cốt lõi cho DDoS protection, luôn-on cho tất cả AWS customers. Shield Standard mitigate L3/L4 tự động (SYN/UDP floods), Shield Advanced thêm visibility, SRT support. Hoàn hảo cho scenario này mà không cần config thêm.

• ✅ Network Load Balancer
  Đúng: NLB hoạt động ở Layer 4 (TCP/UDP), chịu tải cao (1M+ RPS), tích hợp Shield để drop malicious traffic ngay tại edge. Giúp bảo vệ web servers backend bằng cách absorb và reset connections flood, khác với ALB (L7).

• ❌ Amazon GuardDuty
  Sai: GuardDuty là dịch vụ threat detection (phát hiện bằng ML trên logs VPC Flow/CloudTrail), không phải mitigation. Nó alert về DDoS nhưng không block traffic L3/L4 – cần kết hợp Shield/WAF để hành động.

📘 Tài liệu tham khảo (Cập nhật AWS 2026)

• AWS Shield Documentation: docs.aws.amazon.com/waf/latest/developerguide/ddos-overview.html – Chi tiết L3/L4 protection.
• Route 53 DDoS Resiliency: docs.aws.amazon.com/Route53/latest/DeveloperGuide/ddos-resiliency.html.
• NLB & Shield Integration: docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-ddos-protection.html.
• AWS Well-Architected Framework (Reliability): aws.amazon.com/architecture/well-architected – Best practices DDoS mitigation.
• DOP-C02 Exam Guide (2024-2026): AWS Certified DevOps Engineer Professional blueprint nhấn mạnh Shield + NLB/Route53 cho L3/L4.

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 Nếu cần thêm case study, cứ hỏi nhé!