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

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

📖 Nội dung câu hỏi:
Câu hỏi yêu cầu một giải pháp để ghi log hoạt động ở mức object-level (các hoạt động cụ thể trên từng object như GET, PUT, DELETE trong S3 buckets) và xác thực tính toàn vẹn của file log bằng chữ ký số (digital signature). Đây là nhu cầu phổ biến trong bảo mật và kiểm toán AWS, đặc biệt với S3 – dịch vụ lưu trữ object lớn nhất AWS. Object-level activity không chỉ là management events (như tạo bucket) mà cần data events chi tiết. Log file validation đảm bảo log không bị thay đổi bằng cách sử dụng digest file với chữ ký số từ AWS. Giải pháp phải đáp ứng cả hai yêu cầu này một cách chính xác, dựa trên tính năng native của AWS (cập nhật đến 2026, theo AWS Well-Architected Framework và CloudTrail docs mới nhất).

✅ Đáp án đúng:
Create an AWS CloudTrail trail with log file validation enabled. Enable data events. Specify Amazon S3 as the data event type.

🛠️ Lý do chọn đáp án đúng (bằng tiếng Việt chi tiết):

• AWS CloudTrail là dịch vụ ghi log các API calls và hoạt động AWS, hỗ trợ data events cho S3 để capture object-level activities (như Read/Write trên objects).
• Khi tạo trail, bật log file validation sẽ tạo file digest (.gz) kèm chữ ký số (digital signature) sử dụng RSA SHA-256, cho phép validate tính toàn vẹn log bằng công cụ AWS CLI (aws logs validate-log-file-integrity).
• Chỉ định Amazon S3 as data event type đảm bảo log chỉ object-level, không log thừa. Đây là giải pháp chuẩn theo AWS best practices cho auditing S3 (hỗ trợ multi-Region, Lake formation integration đến 2026).
• Không có chi phí bất ngờ: Data events có phí theo events logged.

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

• ✅ Create an AWS CloudTrail trail with log file validation enabled. Enable data events. Specify Amazon S3 as the data event type.
  Phương án này hoàn toàn đúng vì CloudTrail hỗ trợ data events cho S3 object-level logging và log file validation với digital signature native. Validate bằng digest file, phù hợp 100% yêu cầu. (Không có sai sót nào ở đây).

• ❌ Create a new S3 bucket for S3 server access logs. Configure the existing S3 buckets to send their S3 server access logs to the new S3 bucket.
  Phương án này sai vì S3 Server Access Logs (SAL) chỉ ghi request-level activity (bao gồm object-level như GET/PUT), nhưng không hỗ trợ digital signature hay log file validation. Logs là plain text CSV, dễ bị tamper, và không có digest file. SAL dùng để monitor performance/traffic, không phải auditing bảo mật sâu. Cần bucket riêng để tránh loop logging.

• ❌ Create an Amazon CloudWatch Logs log group. Configure the existing S3 buckets to send their S3 server access logs to the log group.
  Phương án này sai vì CloudWatch Logs không phải nơi native nhận S3 server access logs (S3 SAL chỉ gửi đến S3 bucket khác, không trực tiếp đến CloudWatch). Không có tính năng digital signature validation cho logs này. CloudWatch dùng cho metrics/logs ứng dụng, không thay thế auditing object-level với integrity check.

• ❌ Create a new S3 bucket for S3 server access logs with log file validation enabled. Enable data events. Specify Amazon S3 as the data event type.
  Phương án này sai vì trộn lẫn khái niệm: S3 Server Access Logs không có tùy chọn "log file validation enabled", "enable data events", hay "specify Amazon S3 as data event type" – những tính năng này chỉ thuộc CloudTrail trail, không phải S3 SAL. S3 SAL chỉ config bucket target đơn giản, không validate signature.

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

• CloudTrail Data Events & Log Validation: AWS CloudTrail User Guide - Logging data events & Validating CloudTrail log files.
• S3 Server Access Logging: Amazon S3 Server Access Logging – Xác nhận không có signature.
• Exam Tip (DOP-C02): Chủ đề "Logging and Monitoring" trong AWS Certified DevOps Engineer Professional (phiên bản 2024-2026), ưu tiên CloudTrail cho compliance.

Giải pháp này đảm bảo tuân thủ CIS Benchmarks và SOC compliance cho S3! 🚀

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

Câu hỏi mô tả một công ty có hệ thống quản lý tài khoản web cho game trực tuyến, nơi người chơi đăng nhập bằng username và password duy nhất. Hệ thống sử dụng AWS WAF web ACL với core rule set (CRS) AWS managed rule group trên Application Load Balancer (ALB). Đội ngũ bảo mật phát hiện hệ thống bị tấn công credential stuffing (tấn công nhồi credentials từ các breach khác để thử đăng nhập).

Yêu cầu giải pháp:

• Giảm nguy cơ thành công của credential stuffing trong tương lai.
• Tối thiểu hóa tác động đến người dùng hợp pháp (không làm phiền người dùng thật).
• Chọn TWO actions kết hợp để đáp ứng.

Credential stuffing là tấn công tự động dùng hàng loạt credentials bị lộ từ các vụ hack khác để thử brute-force login. AWS WAF CRS đã có nhưng chưa đủ; cần thêm biện pháp chuyên biệt như rule group chống account takeover. Giải pháp phải thông minh, không block đại trà (ví dụ: không CAPTCHA cho tất cả). Dựa trên kiến thức AWS cập nhật đến 2026, AWS WAF v2 hỗ trợ các managed rule groups tiên tiến như Account Takeover Prevention (ATP) để detect credentials compromised mà không ảnh hưởng legitimate traffic. 📘

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

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

1. Add the account takeover prevention (ATP) AWS managed rule group to the web ACL. Configure the rule group to inspect login requests to the system. Block any requests that have the awswaf:managed:aws:atp:signal:credential_compromised label.
2. Create a custom block response that redirects users to a secure workflow to reset their password inside the system.

Lý do lựa chọn:

• Kết hợp ATP rule group (chuyên detect và block credentials bị compromised từ login requests) với custom block response (redirect nghi ngờ đến reset password thay vì block cứng) sẽ giảm hiệu quả credential stuffing bằng cách chặn tín hiệu nguy hiểm (label credential_compromised) và bảo vệ user thật (redirect an toàn, không mất access hoàn toàn). Đây là best practice AWS cho account takeover mà không impact legitimate users (ví dụ: rate-based không cần thiết vì ATP dùng ML signals). 🛠️

📋 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, giữ nguyên nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm giải thích đầy đủ bằng tiếng Việt dựa trên tính khả thi, hiệu quả và yêu cầu "minimize impact".

• ❌ Create an Amazon CloudWatch custom metric to analyze the number of successful login responses from a single IP address.
  Phương án này chỉ tạo metric CloudWatch để theo dõi số login thành công từ một IP, nhưng không thực hiện hành động block hoặc mitigate tự động. Credential stuffing thường từ nhiều IP (botnets), và metric chỉ là monitoring thụ động – không giảm attack ngay lập tức. Không đáp ứng yêu pháp "reduce the chance of successful attack".

• ✅ Add the account takeover prevention (ATP) AWS managed rule group to the web ACL. Configure the rule group to inspect login requests to the system. Block any requests that have the awswaf:managed:aws:atp:signal:credential_compromised label.
  Hoàn toàn đúng: ATP là AWS managed rule group (ra mắt 2023, cập nhật 2026) chuyên chống account takeover/credential stuffing. Nó inspect login forms, dùng threat intel để gắn label awswaf:managed:aws:atp:signal:credential_compromised cho credentials lộ từ breaches (hàng tỷ records). Block chỉ suspicious requests, không ảnh hưởng legitimate users (vì dựa trên signal thông minh, không IP/rate đơn giản). Kết hợp hoàn hảo với CRS hiện có. 🛡️

• ❌ Configure a default web ACL action that requires all users to solve a CAPTCHA puzzle when they log in.
  Phương án này áp CAPTCHA mặc định cho TẤT CẢ login, vi phạm yêu cầu "minimize impact on legitimate users" vì làm phiền mọi người chơi thật (tăng friction, giảm UX). CAPTCHA không hiệu quả cao với credential stuffing (bots giải CAPTCHA tốt), và không target cụ thể compromised creds.

• ❌ Implement IP-based match rules in the web ACL for any IP addresses that generate many successful login responses. Block any IP addresses that generate many successful logins.
  Không phù hợp: Block IP dựa trên "many successful logins" sẽ block nhầm legitimate users (ví dụ: nhiều user từ cùng NAT IP công ty/VPN). Credential stuffing dùng distributed IPs từ botnets, không tập trung; theo dõi "successful" còn tệ hơn vì punish user thật login nhiều. Không giảm stuffing hiệu quả, vi phạm minimize impact.

• ✅ Create a custom block response that redirects users to a secure workflow to reset their password inside the system.
  Đúng và bổ sung hoàn hảo: Trong AWS WAF, custom response (hỗ trợ từ v2) cho phép redirect HTTP 302 đến workflow reset password thay vì block 403 cứng. Kết hợp với ATP, nó giảm rủi ro (nghi ngờ → reset ngay) mà không khóa user thật (họ có thể verify/reset dễ dàng). Best practice cho user-friendly security. 🔄

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

• AWS WAF Account Takeover Prevention (ATP): docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-account-takeover.html – Chi tiết labels như credential_compromised.
• Custom Responses in WAF: docs.aws.amazon.com/waf/latest/developerguide/waf-custom-response.html – Hỗ trợ redirect.
• WAF Best Practices for Credential Stuffing: AWS Well-Architected Security Pillar & re:Inforce 2025 sessions.
  Giải pháp này align 100% với AWS recommendations cho gaming/high-traffic apps! 🚀

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

Câu hỏi mô tả một công ty đang chạy các workload trên AWS với ba tài khoản riêng biệt: development (dev), testing (test) và production (prod).

• Tất cả developer có quyền truy cập vào tài khoản dev.
• Một phần developer (subset) cần truy cập vào tài khoản test và prod.
  🚨 Vấn đề chính: Quản lý credentials cá nhân cho từng developer qua từng môi trường mất quá nhiều thời gian, không scalable.
  🎯 Yêu cầu giải pháp:
• Scalable hơn, linh hoạt khi developer cần access khác nhau.
• Cho phép truy cập tài nguyên cross-account (qua nhiều account).
• Tối thiểu hóa chia sẻ credentials (tránh share key trực tiếp).

Đây là tình huống phổ biến trong multi-account strategy trên AWS, sử dụng AWS Organizations hoặc IAM để quản lý quyền cross-account an toàn. Giải pháp lý tưởng là IAM Roles với STS AssumeRole để delegate quyền tạm thời, không cần long-term credentials. (Kiến thức cập nhật AWS 2026: IAM Roles vẫn là best practice theo AWS Well-Architected Framework - Security Pillar).

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

• AWS IAM User Guide: Cross-account access with roles
• AWS Security Best Practices: Use IAM roles for workloads

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

Đáp án đúng: Create IAM roles in the testing account and production account. Add a policy that allows the sts:AssumeRole action to the roles. Create IAM roles in the development account for the developers who have access to the testing and production accounts. Add these roles to the trust policy on the new roles in the testing and production accounts.

Lý do:
🛠️ Giải pháp này sử dụng IAM Roles cross-account – best practice AWS để delegate quyền tạm thời qua STS AssumeRole.

• Tạo roles ở test/prod với policy cho phép sts:AssumeRole.
• Tạo roles ở dev account dành cho subset developer (những người cần access test/prod).
• Thêm trust policy ở roles test/prod để trust roles từ dev account.
  ✅ Scalable: Developer chỉ cần assume role từ dev account → switch sang test/prod mà không cần credentials riêng. Không share key, quyền tạm thời (session ~1h, có thể renew). Phù hợp multi-account, minimize credential management. Hoàn toàn tuân thủ principle of least privilege.

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

Dưới đây là phân tích chi tiết từng lựa chọn (A, B, C, D). Văn bản gốc giữ nguyên tiếng Anh, giải thích đúng/sai bằng tiếng Việt:

• Phương án A: Use AWS Identity and Access Management Access Analyzer to identify the permissions that the developers need on each account. Configure IAM Access Analyzer to automatically provision the correct access for each developer.
  ❌ Sai: IAM Access Analyzer chỉ phân tích và xác định unused permissions hoặc risky access (policy findings), không tự động provision access cho developer. Nó không hỗ trợ tạo/provision IAM users/roles tự động cross-account. Giải pháp này không scalable cho credential management và không giải quyết cross-account delegation.

• Phương án B: Create an Amazon Simple Workflow Service (Amazon SWF) workflow. Instruct the developers to use the workflow to request access to other accounts when additional access is necessary.
  ❌ Sai: Amazon SWF (nay ít dùng, thay bằng Step Functions) là dịch vụ orchestrate workflow, không phải công cụ quản lý IAM access. Tạo workflow để "request access" sẽ phức tạp, thủ công, không scalable, và vẫn cần cơ chế provision credentials riêng – không minimize sharing, không cross-account native.

• Phương án C (Đúng): Create IAM roles in the testing account and production account. Add a policy that allows the sts:AssumeRole action to the roles. Create IAM roles in the development account for the developers who have access to the testing and production accounts. Add these roles to the trust policy on the new roles in the testing and production accounts.
  ✅ Đúng: Như giải thích ở trên. 🛠️ Hoàn hảo cho role chaining cross-account: Devs assume role ở dev → assume role ở test/prod qua trust policy. An toàn, scalable, zero long-term creds sharing. (Cập nhật 2026: Hỗ trợ IAM Identity Center cho extended access, nhưng role-based vẫn core).

• Phương án D: Create service accounts in the testing environment and production environment. Give the access keys for the service accounts to developers who require access to the testing account and the production account. Rotate the access keys for the service accounts periodically.
  ❌ Sai: "Service accounts" ở đây ám chỉ IAM users với access keys → share keys cho nhiều devs, vi phạm minimize credential sharing. Rotate keys periodic vẫn thủ công, rủi ro cao (keys lộ), không scalable cho subset devs. AWS khuyến cáo KHÔNG dùng long-term creds cho humans, ưu tiên roles/STS.

🎓 Kết luận: Giải pháp C là AWS-recommended cho multi-account access, giúp công ty tiết kiệm thời gian và tăng security! Nếu triển khai thực tế, kết hợp AWS Organizations + SCPs để governance tốt hơn.

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

Câu hỏi xoay quanh một nền tảng phần mềm mã nguồn mở (open-source software platform) đang đối mặt với internet, nhưng là phần mềm legacy không còn nhận cập nhật bảo mật. Hệ thống hiện sử dụng Amazon Route 53 weighted load balancing để phân phối lưu lượng đến hai instance Amazon EC2, và các EC2 này kết nối với Amazon RDS cluster. Một báo cáo gần đây chỉ ra lỗ hổng SQL injection attacks (có mẫu tấn công cụ thể), và kỹ sư bảo mật cần bảo vệ hệ thống trong vòng 24 giờ, với yêu cầu ít nỗ lực nhất (least amount of effort) và duy trì hoạt động bình thường (maintain normal operations) trong quá trình triển khai.

🛠️ Thách thức chính:

• Lỗ hổng SQL injection xảy ra ở tầng ứng dụng (application layer), không phải cơ sở dữ liệu trực tiếp.
• Cần giải pháp nhanh chóng, không thay đổi code lớn, tận dụng dịch vụ AWS để chặn tấn công mà không gián đoạn dịch vụ.
• Route 53 đang dùng weighted LB (cân bằng tải có trọng số), cần giữ tính năng này hoặc tương đương.

Mục tiêu là bảo vệ bằng AWS WAF (Web Application Firewall) chống SQL injection, nhưng phải tích hợp đúng cách với kiến trúc hiện tại (EC2 + RDS), theo phiên bản AWS mới nhất (2026: AWS WAF v2 hỗ trợ ALB, CloudFront, API Gateway, AppSync với rules SQLi managed rules).

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

Đáp án đúng:
Create an Application Load Balancer with the existing EC2 instances as a target group. Create an AWS WAF web ACL containing rules that protect the application from this attack, then apply it to the ALB. Test to ensure the vulnerability has been mitigated, then redirect the Route 53 records to point to the ALB. Update security groups on the EC2 instances to prevent direct access from the internet.

Lý do lựa chọn 🏆:

• Giải pháp này ít nỗ lực nhất vì tận dụng EC2 hiện có làm target group cho Application Load Balancer (ALB) – ALB hỗ trợ weighted routing tương tự Route 53 (qua target group weights), giữ nguyên hai EC2 và RDS.
• AWS WAF web ACL với rules chống SQL injection (sử dụng AWS Managed Rules for SQLi) được attach trực tiếp vào ALB, chặn tấn công ở edge mà không cần thay đổi code.
• Redirect Route 53 đến ALB đơn giản (DNS record update), test trước đảm bảo không gián đoạn, sau đó update Security Groups (SG) EC2 chặn direct internet access (chỉ allow từ ALB) để tăng bảo mật.
• Hoàn thành trong 24h, zero-downtime vì ALB có thể deploy song song và cutover Route 53 nhanh (TTL thấp).

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

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. Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm giải thích chi tiết bằng tiếng Việt.

• ✅ Create an Application Load Balancer with the existing EC2 instances as a target group. Create an AWS WAF web ACL containing rules that protect the application from this attack, then apply it to the ALB. Test to ensure the vulnerability has been mitigated, then redirect the Route 53 records to point to the ALB. Update security groups on the EC2 instances to prevent direct access from the internet.
  Giải thích: Như trên, đây là giải pháp tối ưu: ALB hỗ trợ WAF natively (từ 2016, cập nhật 2026 với rate-based rules nâng cao), weighted targets giữ cân bằng tải hai EC2, redirect Route 53 seamless, SG lockdown EC2 chỉ allow ALB traffic (port 80/443). Ít effort, no downtime. 🛡️

• ❌ Create an Amazon CloudFront distribution specifying one EC2 instance as an origin. Create an AWS WAF web ACL containing rules that protect the application from this attack, then apply it to the distribution. Test to ensure the vulnerability has been mitigated, then redirect the Route 53 records to point to CloudFront.
  Giải thích: CloudFront hỗ trợ WAF tốt cho static/dynamic content, nhưng chỉ dùng một EC2 làm origin vi phạm yêu cầu hai EC2 với weighted LB (không tận dụng instance thứ hai, mất HA). CloudFront cache có thể ảnh hưởng dynamic app, tăng effort config origins/custom headers. Không maintain normal ops đầy đủ. 🌩️

• ❌ Obtain the latest source code for the platform and make the necessary updates. Test the updated code to ensure that the vulnerability has been mitigated, then deploy the patched version of the platform to the EC2 instances.
  Giải thích: Vì là legacy OSS không còn update, việc lấy source và patch thủ công effort cao nhất (code changes, test, deploy blue-green/rolling), dễ exceed 24h và gián đoạn ops. Không dùng dịch vụ AWS native như WAF để chặn layer 7 attacks. Phá vỡ yêu cầu "least effort". 🔧

• ❌ Update the security group that is attached to the EC2 instances, removing access from the internet to the TCP port used by the SQL database. Create an AWS WAF web ACL containing rules that protect the application from this attack, then apply it to the EC2 instances. Test to ensure the vulnerability has been mitigated, then restore the security group to the original setting.
  Giải thích: AWS WAF không attach trực tiếp vào EC2 instances (chỉ support ALB/NLB, CloudFront, API Gateway, AppSync – theo docs 2026). Update SG chặn SQL port (RDS?) không giải quyết SQLi ở app layer (SQLi qua HTTP POST/GET). Restore SG sau là rủi ro, không secure lâu dài và không maintain ops. 🚫

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

• AWS WAF Documentation: AWS WAF and AWS Shield – Hỗ trợ ALB với SQL Injection Rule Group (Core Rule Set v2.0).
• ALB + WAF Best Practices: Elastic Load Balancing Developer Guide.
• Route 53 Integration: Routing traffic to ALB.
• Security Groups for ALB: Lock down EC2 behind ALB.
• Exam Topic: DOP-C02 (DevOps Pro 2023-2026) – Section: Security & Compliance.

Giải pháp này đảm bảo secure-by-default với ít thay đổi nhất! 🚀 Nếu cần demo Terraform/CloudFormation, 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 bảo mật dữ liệu nhạy cảm (PII - Personally Identifiable Information) trong Amazon CloudWatch Logs. Cụ thể:

• Một ứng dụng gửi logs vào một log group trên CloudWatch Logs, và logs chứa địa chỉ email của người dùng.
• Developers cần truy cập và xem logs trong log group này.
• Yêu cầu bảo mật: Đảm bảo developers KHÔNG THỂ THẤY email addresses khi xem logs, nhưng vẫn cho phép họ truy cập logs bình thường.
• Giải pháp phải tự động mask (che giấu) dữ liệu nhạy cảm tại chỗ (in-place) trong CloudWatch Logs Insights hoặc khi xem logs, mà không ảnh hưởng đến dữ liệu gốc và không làm devs mất quyền truy cập toàn bộ logs.

🛠️ Mục tiêu chính: Sử dụng tính năng Logs Data Protection (cập nhật mới nhất từ AWS năm 2023-2026), cho phép định nghĩa data protection policy để tự động phát hiện và mask các loại dữ liệu như email bằng AWS managed data identifiers, chỉ khi người dùng query hoặc view logs. Logs gốc vẫn giữ nguyên, nhưng nội dung hiển thị bị che (ví dụ: email thành [DATA_PROTECTED]).

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

• AWS Docs: Protecting sensitive data in CloudWatch Logs (phiên bản mới nhất 2026).
• AWS Blog: Introducing data protection in CloudWatch Logs.

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

Đáp án đúng: Configure a data protection policy for the log group. Specify the AWS managed data identifier of EmailAddress for the type of data to mask. Activate data protection for the log group.

Lý do:

• Đây là giải pháp tối ưu, native và tự động của AWS (ra mắt 2023, cập nhật 2026 với nhiều managed identifiers hơn).
• Data protection policy áp dụng trực tiếp lên log group, sử dụng AWS managed data identifier "EmailAddress" để tự động phát hiện và mask email (thay bằng [DATA_PROTECTED]) khi developers query/view logs qua Console, CLI, hoặc Logs Insights.
• Logs gốc KHÔNG thay đổi, devs vẫn xem được logs đầy đủ nhưng email bị che – chính xác khớp yêu cầu.
• Không cần code, không phức tạp, chỉ config policy và activate. Hỗ trợ IAM policy để kiểm soát ai bị mask.

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

• ❌ Phương án SAI: Use Amazon Macie to scan the log group. Configure Macie to use a custom data identifier that uses a regular expression to identify an email address pattern. Activate automated data discovery in Macie.
  Lý do sai: Amazon Macie KHÔNG hỗ trợ scan CloudWatch Logs (chỉ S3, EBS, RDS snapshots). Macie dùng cho data discovery ở storage, không mask realtime trong logs. Automated discovery chỉ detect, không prevent devs xem email.

• ❌ Phương án SAI: Create an AWS Key Management Service (AWS KMS) key. Configure the log group to use the key to encrypt the logs. Configure the key policy to deny access to the IAM role that the developers assume to use CloudWatch Logs.
  Lý do sai: Encryption bằng KMS bảo vệ logs toàn bộ, nhưng deny key access sẽ khiến devs KHÔNG XEM ĐƯỢC BẤT KỲ LOG NÀO, vi phạm yêu cầu "developers cần xem logs". Không mask selective (chỉ email), mà block toàn bộ.

• ❌ Phương án SAI: Create a subscription filter for the log group. Configure the log subscription to send the log data to an AWS Lambda function. Program the Lambda function to parse the log entries and to mask values that are email addresses.
  Lý do sai: Subscription filter + Lambda chỉ mask logs khi stream ra ngoài (ví dụ: gửi Kinesis/Firehose), logs gốc trong CloudWatch vẫn chứa email đầy đủ → devs vẫn thấy email khi query trực tiếp log group. Phức tạp (cần code regex), không native, và không mask in-place khi view.

• ✅ Phương án ĐÚNG: Configure a data protection policy for the log group. Specify the AWS managed data identifier of EmailAddress for the type of data to mask. Activate data protection for the log group.
  Lý do đúng: Như giải thích ở trên – native feature, mask tự động chỉ dữ liệu email khi view/query, logs gốc an toàn, devs xem được nội dung khác. Hoàn hảo cho requirement! 🚀

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

Câu hỏi xoay quanh việc triển khai giải pháp logging an toàn trong môi trường AWS sử dụng AWS CloudTrail. Cụ thể:

• Một kỹ sư bảo mật đã thiết lập CloudTrail trail để ghi logs vào Amazon S3 bucket.
• Logs được chia sẻ với nhà cung cấp dịch vụ bên thứ ba (third-party service provider) qua IAM role được chỉ định, cho phép họ truy cập S3.
• Yêu cầu: Logs phải được mã hóa tại chỗ (encrypted at rest) bằng customer managed key (CMK) từ AWS KMS.
• Kỹ sư tạo CMK và key policy, sau đó cấu hình CloudTrail sử dụng key này để mã hóa trail.
• Vấn đề phát sinh: Sau khi áp dụng, nhà cung cấp dịch vụ không đọc được logs nữa (dù họ có quyền S3).

Nguyên nhân cốt lõi 🛠️:

• CloudTrail logs được mã hóa bằng KMS CMK, nên để đọc (decrypt), cần quyền kms:Decrypt từ KMS.
• Quyền S3 (getObject) chỉ cho phép tải file từ S3, nhưng không tự động decrypt nếu dùng CMK. Phải cấp quyền KMS riêng cho external role (cross-account).
• Đây là tình huống phổ biến khi chia sẻ logs mã hóa cross-account, theo best practices AWS (cập nhật đến 2026: CloudTrail v2.0 hỗ trợ multi-region trails nhưng encryption logic không đổi).

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

Đáp án đúng: Add a statement to the key policy to allow the service provider’s role the kms:Decrypt action for the key.

Lý do 📝:

• Key policy của CMK là tài liệu chính kiểm soát quyền sử dụng key (bao gồm kms:Decrypt).
• Để service provider (external IAM role) decrypt logs cross-account, phải thêm key policy statement grant quyền kms:Decrypt (và có thể kms:DescribeKey để kiểm tra).
• Đây là cách an toàn, granular nhất theo AWS: Chỉ cấp quyền cần thiết cho key cụ thể, tránh over-privilege. CloudTrail cần kms:Encrypt khi ghi, nhưng reader cần kms:Decrypt.
• Sau khi thêm, service provider có thể dùng role credentials để gọi KMS decrypt tự động khi đọc từ S3.

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Tôi đánh dấu ✅ cho đúng, ❌ cho sai, và giải thích rõ ràng bằng tiếng Việt dựa trên kiến thức AWS mới nhất (2026).

• ❌ Ensure that the S3 bucket policy allows access to the service provider’s role to decrypt objects.
  Giải thích sai: S3 bucket policy chỉ kiểm soát quyền S3 actions (như s3:GetObject), không cấp quyền decrypt từ KMS. Decrypt là trách nhiệm của KMS, không phải S3. Bucket policy có thể allow GetObject, nhưng thiếu kms:Decrypt sẽ fail khi đọc encrypted objects. (Lỗi phổ biến: "AccessDenied" từ KMS).

• ✅ Add a statement to the key policy to allow the service provider’s role the kms:Decrypt action for the key.
  Giải thích đúng: Như đã nêu ở phần đáp án. Đây là giải pháp chuẩn: Key policy (hoặc grants) phải explicitly allow external principal (IAM role ARN) với kms:Decrypt. Ví dụ policy statement:

  {
    "Sid": "AllowServiceProviderDecrypt",
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::ACCOUNT-ID:role/ServiceProviderRole"},
    "Action": "kms:Decrypt",
    "Resource": "*"
  }
  

  Áp dụng ngay mà không cần thay đổi role bên kia.

• ❌ Add the AWSKeyManagementServicePowerUser AWS managed policy to the service provider’s role.
  Giải thích sai: Policy AWSKeyManagementServicePowerUser cho phép hầu hết KMS actions trên tất cả keys trong account, quá rộng (over-privileged) và không granular. Hơn nữa, role thuộc account khác (service provider), nên attach policy này yêu cầu quyền cross-account modify role (khó khả thi). Không giải quyết trực tiếp mà vi phạm least privilege principle.

• ❌ Migrate the key to AWS Certificate Manager (ACM) to create a shared endpoint for access to the key.
  Giải thích sai: ACM dùng cho certificates (TLS/SSL), không hỗ trợ symmetric CMK cho encryption at rest như S3/CloudTrail. Không có "shared endpoint" cho KMS keys trong ACM. Đây là nhầm lẫn: ACM Private CA khác KMS hoàn toàn. Di chuyển key sẽ break toàn bộ setup.

📘 Tài liệu tham khảo

• AWS CloudTrail User Guide: Encrypting CloudTrail logs with KMS (cập nhật 2025: Nhấn mạnh key policy cho cross-account).
• AWS KMS Developer Guide: Allowing external accounts to use KMS keys (Ví dụ key policy cho kms:Decrypt).
• AWS Well-Architected Framework - Security Pillar: Logging & encryption best practices (2026 edition).
• Exam tip DOP-C02: Chủ đề CloudTrail + KMS encryption thường kiểm tra key policy vs bucket policy.

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần ví dụ code policy đầy đủ, hỏi thêm nhé!

🧩 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 giám sát liên tục các lỗ hổng phần mềm (software vulnerabilities) trên các instance Amazon EC2, đồng thời hiển thị kết quả trong AWS Security Hub, với yêu cầu không được cài đặt agent trên EC2.

• Yêu cầu chính:
  • Giám sát liên tục (continually monitor), không phải quét một lần.
  • Phát hiện software vulnerabilities cụ thể trên EC2 (như CVE trong OS và ứng dụng).
  • Agentless (không agent trên instance).
  • Tích hợp trực tiếp với Security Hub để hiển thị findings.

🔍 Bối cảnh AWS mới nhất (2026): Amazon Inspector đã cập nhật hỗ trợ agentless vulnerability scanning cho EC2 qua hybrid scanning mode, cho phép quét mà không cần agent, kết hợp với network reachability analysis. Điều này phù hợp hoàn hảo với yêu cầu.

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

Đáp án đúng: Enable Amazon Inspector. Set the scan mode to hybrid scanning. Enable the integration for Amazon Inspector in Security Hub.

Lý do 🛠️:

• Amazon Inspector là dịch vụ chuyên quét software vulnerabilities (CVE) trên EC2 một cách tự động và liên tục (network-reachability và periodic scans).
• Hybrid scanning mode (cập nhật mới nhất từ AWS re:Invent 2023-2025) cho phép agentless scanning bằng cách phân tích AMI, network flows, và runtime behavior mà không cần cài agent trên EC2.
• Tích hợp native với Security Hub để đẩy findings trực tiếp, hỗ trợ CIS Benchmarks và PCI DSS.
• Đáp ứng đầy đủ: liên tục, agentless, EC2-specific, Security Hub integration.

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm lý do chi tiết bằng tiếng Việt.

• Enable Amazon Inspector. Set the scan mode to hybrid scanning. Enable the integration for Amazon Inspector in Security Hub.
  ✅ Đúng hoàn toàn 🏆: Như đã giải thích ở trên, đây là giải pháp chính xác nhất. Hybrid mode đảm bảo agentless, quét liên tục vulnerabilities trên EC2, và tích hợp Security Hub tự động (Findings > Amazon Inspector).

• Use Security Hub to enable the AWS Foundational Security Best Practices standard. Wait for Security Hub to generate the findings.
  ❌ Sai 🚫: AWS Foundational Security Best Practices (FSBP) chỉ kiểm tra cấu hình bảo mật chung (như IAM, VPC), không quét software vulnerabilities cụ thể trên EC2 (không phát hiện CVE). Không agentless hay liên tục cho phần mềm, chỉ là compliance checks tĩnh.

• Enable Amazon GuardDuty. Initiate on-demand malware scans by using GuardDuty Malware Protection. Enable the integration for GuardDuty in Security Hub.
  ❌ Sai 🔍: GuardDuty phát hiện threat intelligence và malware runtime (như EKS pods, S3 objects), không quét software vulnerabilities (CVE) trên EC2. Malware Protection là on-demand (không liên tục), và chủ yếu cho EKS/S3 – không agentless cho EC2 vulnerabilities. Tích hợp Security Hub chỉ cho threats, không phải vulns.

• Use AWS Config managed rules to detect EC2 software vulnerabilities. Ensure that Security Hub has the AWS Config integration enabled.
  ❌ Sai ⚙️: AWS Config theo dõi thay đổi cấu hình (managed rules như ec2-instance-no-public-ip), không quét software vulnerabilities sâu (CVE trong OS/apps). Không có rules chuyên detect EC2 software vulns agentless, chỉ compliance config. Tích hợp Security Hub chỉ đẩy config findings, không phải vulnerability scans.

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

• Amazon Inspector – Agentless Vulnerability Scanning (Hybrid mode chi tiết).
• Security Hub Integrations – Amazon Inspector.
• AWS re:Invent 2025: Inspector Agentless Updates.
• AWS Well-Architected Framework: Security Pillar (Security Hub + Inspector).

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ãy hỏi nhé!

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

Câu hỏi xoay quanh việc triển khai fine-grained authorization (ủy quyền chi tiết, tinh tế) cho tài nguyên trong một ứng dụng game trực tuyến tùy chỉnh. Công ty sử dụng Amazon Cognito để xác thực và ủy quyền người dùng, với user pool (quản lý người dùng cuối) và identity pool (kết nối với AWS services qua IAM) đã được thiết lập sẵn. Kỹ sư bảo mật cần giải pháp sử dụng thuộc tính người dùng (user attributes) từ Cognito để kiểm soát quyền truy cập chi tiết vào tài nguyên ứng dụng.

🔍 Yêu cầu chính:

• Phải dựa trên user attributes có sẵn trong Cognito.
• Không chỉ là ủy quyền cơ bản (như IAM roles), mà cần fine-grained (dựa trên thuộc tính cụ thể như level người chơi, nhóm, v.v.).
• Tích hợp mượt mà với Cognito mà không thay đổi lớn kiến trúc hiện tại.

Đây là chủ đề bảo mật ứng dụng AWS hiện đại, nhấn mạnh vào authorization as a service thay vì tự quản lý policies phức tạp (theo best practices AWS 2024-2026).

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

Đáp án đúng: Create a policy store in Amazon Verified Permissions. Configure Cognito as the identity source. Map Cognito access tokens to the Verified Permissions schema.

Lý do 🛠️:

• Amazon Verified Permissions (AVP) là dịch vụ chuyên biệt cho fine-grained authorization dựa trên Cedar policy language, hỗ trợ trực tiếp Cognito làm identity source từ năm 2023 và cập nhật tích hợp sâu hơn đến 2026.
• Giải pháp này cho phép map Cognito access tokens (JWT chứa user attributes) vào schema của AVP, sử dụng thuộc tính người dùng (như custom attributes trong user pool) để đánh giá policies động, chi tiết (ví dụ: chỉ cho phép người chơi level cao truy cập server VIP).
• Hoàn hảo vì đã có user/identity pool, AVP tích hợp liền mạch mà không cần IAM roles phức tạp, giảm boilerplate code và dễ audit.

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên nội dung gốc bằng tiếng Anh:

• ❌ Create a set of IAM roles and IAM policies. Configure the Cognito identity pool to assign users to the IAM roles.
  Giải thích sai: Phương án này chỉ hỗ trợ role-based access control (RBAC) cơ bản qua Cognito identity pool (map groups/roles), không phải fine-grained dựa trên user attributes động. IAM policies quá thô cho app logic phức tạp như game (ví dụ: không dễ kiểm tra "level > 10"), dẫn đến "role explosion" và khó scale. Không đáp ứng yêu cầu sử dụng attributes chi tiết.

• ✅ Create a policy store in Amazon Verified Permissions. Configure Cognito as the identity source. Map Cognito access tokens to the Verified Permissions schema.
  Giải thích đúng: Như đã nêu ở trên, AVP là giải pháp lý tưởng với policy store lưu trữ Cedar policies, Cognito integration native (qua OIDC/JWT), map attributes trực tiếp vào schema. Hỗ trợ authorization API cho app backend, tuân thủ zero-trust và cập nhật AWS 2026 với Batch Authorization.

• ❌ Create customer managed permissions by using AWS Resource Access Manager (AWS RAM). Configure the Cognito identity pool to assign users to the customer managed permissions.
  Giải thích sai: AWS RAM dùng để chia sẻ resources (như VPC, Transit Gateway) giữa accounts, không phải tạo permissions cho app authorization. Không có khái niệm "customer managed permissions" cho Cognito users, và không map attributes fine-grained. Đây là nhầm lẫn với resource sharing, không liên quan.

• ❌ Create a set of IAM users and IAM policies. Configure the Cognito user pool to assign users to the IAM users.
  Giải thích sai: IAM users dành cho AWS services management, không liên kết trực tiếp với Cognito user pool (Cognito không "assign" IAM users). Tạo hàng triệu IAM users cho game users là anti-pattern (không scale, bảo mật kém). Cognito chỉ federate qua identity pool với roles, không phải users.

📘 Tài liệu tham khảo

• AWS Documentation - Amazon Verified Permissions: Integrating with Amazon Cognito (cập nhật 2025, hướng dẫn map JWT tokens).
• AWS re:Post & Well-Architected Framework - Security Pillar: Nhấn mạnh AVP cho fine-grained auth trong apps (2024-2026).
• Cognito Developer Guide: Identity Pools & IAM Roles (xác nhận hạn chế RBAC).
• AWS Blog: "Build fine-grained authorization with Amazon Verified Permissions and Amazon Cognito" (2023, vẫn valid 2026).

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ụ code, hỏi nhé!

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

Câu hỏi xoay quanh việc tự động hóa báo cáo bảo mật hàng ngày trên AWS. Một công ty có AWS Lambda function được kích hoạt bởi Amazon EventBridge schedule (lịch trình hàng ngày). Lambda này cần thu thập dữ liệu từ các findings của Amazon Inspector được lưu trữ trong AWS Security Hub tại region us-west-2. Tuy nhiên, Lambda đang thất bại khi tạo báo cáo. Nhiệm vụ của security engineer là sửa lỗi và áp dụng least privilege permissions (quyền hạn tối thiểu).

🔍 Vấn đề cốt lõi: Lambda cần quyền đọc (read-only) các findings từ Security Hub (cụ thể là findings từ Amazon Inspector product). Execution role của Lambda thiếu permissions phù hợp, dẫn đến failure. Giải pháp phải tuân thủ nguyên tắc least privilege, tránh quyền thừa.

🛠️ Bối cảnh AWS cập nhật 2026: AWS Security Hub tích hợp Amazon Inspector để lưu findings cross-account/region. Lambda execution role cần IAM policies chuẩn để gọi API Security Hub như GetFindings, ListFindings. Không dùng resource-based policy vì Lambda là caller, không phải resource bị gọi.

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

• AWS Security Hub IAM Permissions (cập nhật 2025).
• AWSSecurityHubReadOnlyAccess Policy (read-only cho findings).
• Lambda Execution Role Best Practices.

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

Attach the AWSSecurityHubReadOnlyAccess AWS managed policy to the Lambda function’s execution role.

Lý do:

• 🟢 Policy này cung cấp chính xác quyền read-only cho Security Hub (bao gồm securityhub:GetFindings, ListFindings, BatchGetFindings, DescribeHub, v.v.), phù hợp để Lambda đọc findings từ Amazon Inspector mà không cần quyền write/modify.
• ✅ Đáp ứng least privilege: Managed policy AWS chính thức, an toàn, không thừa quyền (không cho phép tạo/sửa findings).
• 🛠️ Fix failure trực tiếp vì Lambda role thiếu quyền gọi Security Hub API. EventBridge schedule chỉ trigger Lambda, không liên quan permissions data access.
• Không cần custom policy phức tạp, AWS khuyến nghị dùng managed policy (best practice 2025+).

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

• ❌ Create a resource-based policy that allows Security Hub access to the ARN of the Lambda function.
  Giải thích sai: Resource-based policy trên Lambda chỉ dùng để cho phép service khác invoke Lambda (như EventBridge). Không liên quan đến việc Lambda đọc dữ liệu từ Security Hub. Security Hub không invoke Lambda ở đây; Lambda là initiator gọi API Security Hub. Vi phạm least privilege vì không fix vấn đề gốc.

• ✅ Attach the AWSSecurityHubReadOnlyAccess AWS managed policy to the Lambda function’s execution role.
  Giải thích đúng: Như phần trên, policy này grant read-only permissions chuẩn cho tất cả API cần thiết để truy vấn findings Inspector trong Security Hub (us-west-2). Least privilege hoàn hảo, AWS managed nên dễ audit và cập nhật tự động (phiên bản 2025+ hỗ trợ cross-region findings).

• ❌ Grant the Lambda function’s execution role read-only permissions to access Amazon Inspector and Security Hub.
  Giải thích sai: Phương án quá mơ hồ, không cụ thể (không chỉ rõ policy/action nào). Amazon Inspector findings đã lưu trong Security Hub, Lambda không cần access trực tiếp Inspector (dùng Security Hub API). Không phải giải pháp IAM thực thi, dễ dẫn đến quyền thừa hoặc thiếu, vi phạm least privilege.

• ❌ Create a custom IAM policy that grants the Security Hub Get, List, Batch*, and Describe* permissions on the arn:aws:securityhub:us-west-2::product/aws/inspector/* resource. Attach the policy to the Lambda function’s execution role.**
  Giải thích sai: ARN resource sai cú pháp (::product/aws/inspector/* không chuẩn cho Security Hub findings). Security Hub actions như GetFindings dùng resource arn:aws:securityhub:*:*:* hoặc không require resource cụ thể. Custom policy rủi ro (không full actions cần như DescribeStandards), phức tạp hơn managed policy, không khuyến khích (AWS best practice dùng managed 2026).

🏆 Kết luận: Giải pháp đúng tận dụng AWS managed policy để đảm bảo an toàn, scalable và tuân thủ zero-trust model mới nhất! 🚀

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

Câu hỏi tập trung vào việc lưu trữ bản sao lưu (backup copies) cho Amazon RDS DB instances và Amazon EBS volumes, với yêu cầu đặc biệt là giữ các bản sao này ở các data centers cách nhau hàng trăm miles (tức là cần phân tán địa lý xa để tăng tính sẵn sàng và khả năng phục hồi). Giải pháp phải đạt LEAST operational overhead (ít công sức vận hành nhất), nghĩa là ưu tiên các dịch vụ tự động hóa native của AWS, không cần code custom hay quản lý thủ công phức tạp.

Mục tiêu chính:

• Backup RDS (database snapshots) và EBS (volume snapshots).
• Phân tán backup qua các vị trí xa (cross-Region, vì Availability Zones - AZ chỉ cách nhau khoảng 10-100 miles trong cùng Region).
• Tối ưu overhead: Sử dụng managed service tự động, không cần Lambda hay script.

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

• AWS Backup User Guide (2024-2026): https://docs.aws.amazon.com/aws-backup/latest/devguide/whatis-backup.html
• Cross-Region Copy trong AWS Backup: https://docs.aws.amazon.com/aws-backup/latest/devguide/copy-between-regions.html
• Amazon DLM: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/lifecycle-policies.html

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

Đáp án đúng: Configure AWS Backup to create the backups according to the needed schedule. Create a destination backup vault in a different AWS Region. Configure AWS Backup to copy the backups to the destination backup vault.

Lý do 🛠️:

• AWS Backup là dịch vụ managed hoàn toàn hỗ trợ backup RDS snapshots và EBS snapshots theo lịch tự động (schedule).
• Cross-Region copy vào backup vault ở Region khác là tính năng native, tự động hóa 100% mà không cần code thêm. Các Region AWS cách nhau hàng trăm miles (ví dụ: us-east-1 và us-west-2 cách >2000 miles).
• Least overhead: Chỉ cấu hình plan/vault một lần, AWS lo copy, retention, encryption. Hỗ trợ cả RDS và EBS unified.
• Cập nhật 2026: AWS Backup hỗ trợ continuous backups và audit reports tự động cho compliance.

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

Dưới đây là phân tích từng phương án theo thứ tự trong câu hỏi. Tôi giữ nguyên văn bản gốc bằng tiếng Anh, chỉ giải thích bằng tiếng Việt với emoji đánh dấu.

• Phương án 1: Configure AWS Backup to create the backups according to the needed schedule. In the backup plan, specify multiple Availability Zones as backup destinations.
  ❌ Sai vì: Multiple AZ chỉ trong cùng một Region, khoảng cách chỉ 10-100 miles, không đáp ứng "several hundred miles". AWS Backup vault mặc định là regional, không tự động cross-Region. Overhead thấp nhưng không giải quyết yêu cầu địa lý.

• Phương án 2: Configure Amazon Data Lifecycle Manager to create the backups. Configure the Amazon Data Lifecycle Manager policy to copy the backups to an Amazon S3 bucket. Enable replication on the S3 bucket.
  ❌ Sai vì: DLM chỉ hỗ trợ EBS snapshots (không backup RDS trực tiếp). Copy sang S3 là lưu metadata/tags, không phải full backup copy phục hồi được. S3 replication là intra/inter-Region nhưng không phải backup native cho RDS/EBS (phải restore thủ công). Overhead cao hơn do cần quản lý S3 lifecycle riêng.

• Phương án 3 (Đúng ✅): Configure AWS Backup to create the backups according to the needed schedule. Create a destination backup vault in a different AWS Region. Configure AWS Backup to copy the backups to the destination backup vault.
  ✅ Đúng vì: Như giải thích ở trên – unified backup RDS/EBS, cross-Region copy tự động vào vault (hỗ trợ distance >hundreds miles), zero custom code. Overhead thấp nhất với vault locking và KMS integration (cập nhật 2026).

• Phương án 4: Configure Amazon Data Lifecycle Manager to create the backups. Create an AWS Lambda function to copy the backups to a different AWS Region. Use Amazon EventBridge to invoke the Lambda function on a schedule.
  ❌ Sai vì: DLM chỉ EBS, không RDS. Lambda + EventBridge là custom solution, phải code xử lý snapshot copy (rds:copy-db-snapshot, ec2:copy-snapshot), quản lý permissions/error handling. Overhead cao nhất (dev, test, monitor), không "least operational".

Kết luận 🎯: Phương án 3 là optimal theo best practices AWS Well-Architected Framework (Reliability Pillar). Nếu triển khai, dùng AWS Backup console/CLI để setup plan với CrossRegionCopy enabled!