Ngân hàng đề — AWS Certified DevOps Engineer Professional

Đáp án

D — Thêm hook BeforeAllowTraffic vào AppSpec để kiểm tra và chờ các thay đổi CSDL hoàn tất trước khi traffic đi vào phiên bản Lambda mới.

Vì sao đúng

Triệu chứng trong đề rất đặc trưng: lỗi kết nối rải rác ngay sau deploy, rồi tự hết. Đó là dấu hiệu kinh điển của việc traffic đi vào bản mới trước khi các phụ thuộc của nó sẵn sàng — ở đây là thay đổi lược đồ hoặc dữ liệu trong NoSQL store chưa lan xong.

CodeDeploy khi deploy Lambda chỉ có bốn lifecycle event:

Start → BeforeAllowTraffic → AllowTraffic → AfterAllowTraffic → End

Chỉ BeforeAllowTraffic và AfterAllowTraffic viết được hook. Muốn chặn traffic cho tới khi CSDL sẵn sàng thì phải đặt ở trước cửa AllowTraffic:

version: 0.0
Resources:
  - HamXuLy:
      Type: AWS::Lambda::Function
      Properties: {Name: xu-ly-don, Alias: prod, CurrentVersion: 1, TargetVersion: 2}
Hooks:
  - BeforeAllowTraffic: kiem-tra-csdl-san-sang

Hàm hook chờ tới khi CSDL sẵn sàng rồi báo Succeeded; hết giờ thì báo Failed và CodeDeploy tự rollback — không client nào chạm vào bản mới.

Vì sao các phương án khác sai

• C. AfterAllowTraffic — quá muộn. Hook này chạy sau khi traffic đã chuyển sang bản mới, tức là lỗi đã xảy ra với người dùng thật. Câu chữ của phương án ("buộc traffic chờ… trước khi cho bản mới phản hồi") cũng mô tả sai điều hook này làm.
• A. ValidateService và B. DownloadBundle — cả hai không tồn tại trong deploy Lambda; chúng thuộc bộ hook của EC2/On-Premises. Khai vào AppSpec của Lambda thì bị bỏ qua hoàn toàn, và bạn có một biện pháp bảo vệ chỉ tồn tại trên giấy. DownloadBundle còn không phải hook viết được ở bất kỳ nền tảng nào — nó là bước CodeDeploy tự thực hiện.

Ghi nhớ

Bộ hook khác nhau theo nền tảng — chi tiết bị hỏi rất nhiều: | Nền tảng | Hook viết được | |---|---| | Lambda | BeforeAllowTraffic, AfterAllowTraffic | | ECS | thêm BeforeInstall, AfterInstall, AfterAllowTestTraffic | | EC2/On-prem | ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart, ValidateService |

Quy tắc nhớ nhanh: cần chặn traffic vì phụ thuộc chưa sẵn sàng ⇒ luôn là hook có chữ Before.

Đáp án

B — Sửa script deploy để tạo tệp /health-check.php ở CUỐI quá trình deploy, và trỏ health check path vào tệp đó.

Vì sao đúng

Vấn đề nằm ở chỗ health check đang hỏi sai câu hỏi. /index.php trả lời "máy chủ web có chạy không", trong khi câu cần hỏi là "quá trình triển khai đã xong chưa". Nginx/Apache khởi động rất sớm, nên /index.php có thể trả 200 trong khi mã ứng dụng còn đang được ghi.

Tạo tệp health check ở bước cuối cùng biến sự tồn tại của nó thành tín hiệu hoàn tất:

# deploy.sh
git pull && composer install --no-dev
php artisan migrate --force
php artisan config:cache
echo '<?php http_response_code(200); echo "OK";' > /var/www/html/health-check.php   # ← BƯỚC CUỐI

Điều này thoả cả hai vế của đề — "lên online sớm nhất có thể, nhưng không sớm hơn lúc sẵn sàng":

• Deploy xong trong 40 giây ⇒ instance vào phục vụ ở giây thứ 40, không phải chờ hết một grace period cố định
• Deploy mất 4 phút ⇒ instance không nhận traffic cho tới lúc đó

Bước dọn dẹp đi kèm: xoá tệp đó ở đầu mỗi lần deploy tiếp theo, để instance tự rút khỏi target group trong lúc đang được cập nhật.

Vì sao các phương án khác sai

• A. Tạo tệp ở ĐẦU quá trình deploy — đây là bẫy đối xứng, và nó tệ hơn cả hiện trạng: instance báo lành ngay khi deploy vừa bắt đầu, tức là nhận traffic trong suốt quá trình cập nhật.
• C. Tăng grace period lên 180 giây và đổi mã kỳ vọng thành 202 — grace period cố định chỉ là đoán mò: quá ngắn thì vẫn lỗi, quá dài thì instance nằm không dù đã sẵn sàng (trái yêu cầu "sớm nhất có thể"). Đổi sang mã 202 thì vô nghĩa — nó không nói lên điều gì về mức độ sẵn sàng.
• D. Tăng grace period lên 300 giây và yêu cầu 3 lần kiểm tra liên tiếp — cùng vấn đề: chọn một con số cố định cho một quá trình có thời lượng thay đổi. Nó có thể che được triệu chứng, nhưng vẫn hỏng khi deploy chậm bất thường, và làm mọi lần deploy chậm hơn cần thiết.

Ghi nhớ

Health check endpoint phải phản ánh mức độ sẵn sàng của ỨNG DỤNG, không phải của máy chủ web. Tăng grace period là che triệu chứng; endpoint riêng do chính quy trình deploy tạo ra ở bước cuối mới là cách chữa đúng — và nó tự thích nghi với thời lượng deploy thay vì bắt bạn đoán.

Đáp án

B — Bật Amazon GuardDuty để phát hiện hoạt động cho thấy EC2 đã bị xâm nhập; tạo EventBridge rule với nguồn aws.guardduty và gửi thông báo.

Vì sao đúng

Từ khoá là "activities that indicate that instances have been compromised" — tức là hành vi đe doạ đang diễn ra, không phải điểm yếu tiềm tàng.

GuardDuty đọc VPC Flow Logs, DNS logs, CloudTrail (và EBS malware scanning nếu bật) để phát hiện đúng loại tín hiệu đó:

• Instance liên lạc với máy chủ điều khiển (C2) đã biết
• Đào tiền mã hoá (CryptoCurrency:EC2/BitcoinTool.B)
• Instance tham gia quét cổng hoặc tấn công máy khác
• Thông tin xác thực của EC2 bị dùng từ ngoài AWS (UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration)

Mỗi phát hiện được đẩy lên EventBridge tự động:

{"source": ["aws.guardduty"], "detail-type": ["GuardDuty Finding"],
 "detail": {"severity": [{"numeric": [">=", 4]}]}}

Rule trỏ thẳng vào SNS topic có email đăng ký — vế thông báo hoàn tất, không cần viết mã.

Vì sao các phương án khác sai

• C. Amazon Inspector — Inspector quét lỗ hổng phần mềm và phơi nhiễm mạng, tức là "chỗ nào có thể bị khai thác". Nó không phát hiện việc đã bị xâm nhập. Đây là cặp bị nhầm nhiều nhất trong toàn bộ chủ đề bảo mật AWS.
• A. CloudTrail + metric filter tuỳ chỉnh — CloudTrail ghi mọi lời gọi API như nhau; nó không phân loại cái nào là dấu hiệu xâm nhập. Muốn có phán xét thì phải tự định nghĩa mọi mẫu — tức là tự viết lại GuardDuty bằng tay, và chắc chắn sót. Ngoài ra CloudTrail không thấy phần lớn tín hiệu quan trọng (lưu lượng mạng ra máy chủ độc hại chẳng hạn).
• D. SSM Agent + "cấu hình Systems Manager cảnh báo khi có hoạt động độc hại" — Systems Manager không có tính năng phát hiện hoạt động độc hại. Nó là công cụ vận hành hạm đội (chạy lệnh, vá, kiểm kê), không phải công cụ bảo mật. Phương án mô tả một khả năng không tồn tại.

Ghi nhớ

Câu hỏi nói "compromised" ⇒ GuardDuty. Nói "vulnerabilities" ⇒ Inspector.

Đáp án

A và E.

• A — Tạo môi trường Elastic Beanstalk có load balancing và auto scaling.
• E — Tạo Amazon RDS độc lập (bên ngoài Beanstalk) trong VPC, bật automatic backup và deletion protection.

Vì sao đúng

Đề nêu bốn yêu cầu và cả bốn đều được thoả bởi cặp này:

Chữ "independent" trong phương án E là điểm quan trọng nhất. RDS tạo bên trong môi trường Beanstalk có vòng đời gắn với môi trường đó: xoá hoặc dựng lại môi trường là mất CSDL. Tạo bên ngoài rồi trỏ vào bằng biến môi trường thì dữ liệu sống độc lập — đúng yêu cầu "protected from accidental deletion".

Deletion protection thêm một lớp nữa: bật rồi thì lệnh DeleteDBInstance bị từ chối cho tới khi có người tắt cờ đó một cách có chủ ý.

Vì sao các phương án khác sai

• B. Nhiều Lambda + Route 53 multivalue record — không phải "môi trường được quản lý cho ứng dụng Node.js" theo nghĩa đề nói; nó là viết lại ứng dụng theo kiến trúc serverless. Multivalue record cũng không phải cơ chế cân bằng tải đúng nghĩa (client tự chọn ngẫu nhiên trong các bản ghi khoẻ mạnh).
• C. ASG của EC2 do Systems Manager quản lý — SSM quản lý cấu hình và vá máy, nhưng bạn vẫn phải tự dựng deploy, tự cấu hình load balancer, tự xử lý phiên bản ứng dụng. Nhiều việc hơn Beanstalk hẳn, trái với "minimize ongoing operational effort".
• D. DynamoDB — đề nói rõ cần CSDL quan hệ ("managed relational database"). DynamoDB là NoSQL khoá/giá trị: không có join, không có SQL, không có giao dịch quan hệ. Sai loại CSDL. (Điều thú vị: mọi thứ khác trong phương án D — backup tự động, deletion protection, đều đúng — chỉ sai đúng loại CSDL.)

Ghi nhớ

Quy tắc vàng của Elastic Beanstalk: không bao giờ tạo CSDL production bên trong môi trường. Luôn tạo RDS độc lập và truyền endpoint qua biến môi trường. Và với mọi CSDL production, bật đủ ba thứ: automatic backup, deletion protection, và Multi-AZ.

Đáp án

D — Lưu tệp cấu hình trong S3 bucket có bật versioning, và nạp lại cấu hình bằng Lambda được EventBridge kích hoạt.

Vì sao đúng

Đề nêu bốn ràng buộc, và chúng cùng loại bỏ Parameter Store:

Giới hạn của Parameter Store là điểm quyết định: mặc định 10.000 tham số standard mỗi tài khoản mỗi Region, và tham số standard tối đa 4 KB. Với 3 KB mỗi tệp thì vừa vặn tới mức nguy hiểm, và nếu số khách hàng tăng "significantly" thì trần 10.000 sẽ tới. Chuyển sang advanced parameter thì được 8 KB và 100.000 tham số, nhưng có phí theo từng tham số mỗi tháng.

Cách hiện tại còn một vấn đề nữa: container chỉ đọc cấu hình lúc khởi động, nên đổi cấu hình là phải khởi động lại task. Đường S3 + sự kiện phá vỡ ràng buộc đó.

Vì sao các phương án khác sai

• A. Giữ nguyên Parameter Store dạng phân cấp, nạp lúc khởi động — không giải quyết được gì: vẫn vướng giới hạn số lượng khi mở rộng, và vẫn phải khởi động lại container để nhận cấu hình mới.
• B. Chuyển sang Secrets Manager — sai mục đích và đắt hơn: Secrets Manager tính tiền theo từng bí mật mỗi tháng, mà đây là cấu hình thường, không phải bí mật. Với hàng nghìn tệp thì chi phí rất lớn, đổi lại chẳng được tính năng nào cần dùng.
• C. Đưa cấu hình vào mã nguồn dạng properties file, khởi động lại container để nạp — tệ nhất: mỗi lần khách hàng mới lên là phải build lại image và deploy lại, và vẫn phải khởi động lại container. Trái thẳng yêu cầu "load on the fly".

Ghi nhớ về chất lượng câu hỏi

Phương án D nói Lambda được kích hoạt bởi "a cron job" — tức là theo lịch. Cách đúng hơn hẳn là bắt sự kiện s3:ObjectCreated:* để nạp lại ngay khi tệp thay đổi; lịch định kỳ luôn để lại một cửa sổ trong đó cấu hình đã cũ. D vẫn là đáp án đúng vì ba phương án còn lại sai ở tầng cơ bản hơn (giới hạn quy mô, sai dịch vụ, phải deploy lại), nhưng phần cơ chế kích hoạt của nó không phải là cách làm tốt nhất.

Ghi chú thêm: AWS AppConfig (một phần của Systems Manager) sinh ra đúng cho bài toán này — nó có phiên bản, có triển khai theo giai đoạn, có tự động rollback theo alarm, và SDK có sẵn cơ chế nạp lại. Nó không nằm trong các phương án, nhưng ngoài đời đó là lựa chọn đáng cân nhắc đầu tiên.

Đáp án

C — CodePipeline đăng ký sự kiện trên EventBridge, kích hoạt SSM Automation document để bật và tắt EC2 cùng RDS trước và sau khi chạy kiểm thử.

Vì sao đúng

Ràng buộc quan trọng nhất: "không thay đổi kiến trúc ứng dụng". Tài nguyên chỉ chạy vài giờ, vài lần mỗi tuần — nên tiền chủ yếu đang chảy vào những giờ không ai dùng.

SSM Automation là công cụ đúng cho việc này: có sẵn document AWS-StartEC2Instance, AWS-StopEC2Instance, AWS-StartRdsInstance, AWS-StopRdsInstance, hoặc gộp thành một document tuỳ chỉnh gọi cả bốn theo thứ tự. Không phải viết Lambda, không phải đổi kiến trúc.

Gắn vào pipeline qua EventBridge thì việc bật/tắt bám đúng theo sự kiện thật — pipeline bắt đầu thì bật, pipeline kết thúc thì tắt — chứ không theo một lịch cố định đoán mò.

Một lưu ý vận hành đáng biết: RDS chỉ dừng được tối đa 7 ngày, sau đó AWS tự khởi động lại. Với chu kỳ vài lần mỗi tuần thì không sao, nhưng nếu có kỳ nghỉ dài thì phải có cơ chế dừng lại.

Vì sao các phương án khác sai

• A. Scheduled scaling cho ASG — chỉ giải quyết EC2, bỏ hẳn RDS (thường là phần đắt nhất trong môi trường staging). Nó cũng đòi đưa instance vào Auto Scaling group, tức là đổi kiến trúc. Ngoài ra scheduled scaling chạy theo lịch cố định, không bám theo lúc pipeline thực sự chạy.
• B. Chuyển sang Aurora Serverless + thêm ALB — thay đổi kiến trúc, vi phạm thẳng ràng buộc. Aurora Serverless là lựa chọn tốt về chi phí cho tải gián đoạn, nhưng đây là cuộc di trú CSDL, không phải một thay đổi tự động hoá.
• D. Spot Instance + RDS Reserved Instance — sai hướng hoàn toàn ở vế RDS: Reserved Instance là cam kết trả tiền 1–3 năm cho một tài nguyên chạy liên tục. Mua RI cho một CSDL chỉ chạy vài giờ mỗi tuần là cách tăng chi phí, không phải giảm. Spot cũng rủi ro cho môi trường đang chạy kiểm thử vì có thể bị thu hồi giữa chừng.

Ghi nhớ

Với môi trường dev/test/staging, khoản tiết kiệm lớn nhất thường không đến từ việc chọn loại instance rẻ hơn, mà đến từ việc tắt chúng khi không dùng. Một môi trường chạy 8 giờ/ngày × 5 ngày/tuần chỉ tốn khoảng 24% so với chạy 24/7.

Đáp án

A — Thêm lifecycle hook vào Auto Scaling group để đưa instance đang bị huỷ vào trạng thái Terminating:Wait.

Vì sao đúng

Vấn đề rất cụ thể: instance hỏng bị ASG huỷ trước khi kịp vào xem, nên không bao giờ điều tra được nguyên nhân của lỗi 502.

Lifecycle hook cho hành động terminate tạm dừng việc huỷ:

InService → Terminating → Terminating:Wait ← DỪNG Ở ĐÂY (mặc định 1 giờ, tối đa 48 giờ)
                                ↓ CompleteLifecycleAction
                          Terminating:Proceed → Terminated

Ở Terminating:Wait, instance vẫn chạy, vẫn giữ nguyên trạng thái lỗi, nhưng đã bị gỡ khỏi load balancer nên không phục vụ ai. Đó chính là điều kiện lý tưởng để gỡ lỗi: vào bằng SSM Session Manager, đọc log ứng dụng, kiểm tra tiến trình, xem cấu hình — tất cả trên đúng máy đang hỏng.

aws autoscaling put-lifecycle-hook --auto-scaling-group-name nhom-web \
  --lifecycle-hook-name giu-de-go-loi \
  --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
  --heartbeat-timeout 3600

Xem xong thì gọi complete-lifecycle-action để thả cho ASG huỷ.

Vì sao các phương án khác sai

• B. Tạm dừng tiến trình AZRebalance — tiến trình này chỉ lo phân bố instance cho đều giữa các AZ. Nó không liên quan gì tới việc huỷ instance do health check hỏng. Muốn chặn hẳn việc huỷ thì phải tạm dừng Terminate hoặc ReplaceUnhealthy — nhưng cách đó ảnh hưởng toàn nhóm, còn hook thì chỉ giữ lại đúng instance đang bị huỷ.
• C. Chụp snapshot EBS rồi tạo instance mới từ đó — được dữ liệu trên đĩa, nhưng mất toàn bộ trạng thái đang chạy: tiến trình nào đang treo, bao nhiêu bộ nhớ đang dùng, kết nối mạng ra sao. Với lỗi 502 (backend không phản hồi đúng), phần lớn manh mối nằm ở trạng thái đang chạy chứ không ở đĩa.
• D. Bật termination protection cho Auto Scaling group — hiểu nhầm phạm vi: termination protection của EC2 chỉ chặn lời gọi TerminateInstances thủ công; nó không ngăn Auto Scaling huỷ instance. ASG có cơ chế riêng gọi là instance scale-in protection, mà cái đó cũng chỉ chặn scale-in chứ không chặn việc thay instance không lành.

Ghi nhớ

Bốn trạng thái lifecycle hook: Pending:Wait, Pending:Proceed (lúc tạo), Terminating:Wait, Terminating:Proceed (lúc huỷ). Mẫu "giữ lại để gỡ lỗi" dùng hook terminate — và nhớ CompleteLifecycleAction khi xong, nếu không instance nằm đó tính tiền tới hết timeout.

Đáp án

B — Dùng Auto Scaling lifecycle hook để xác nhận script bootstrap đã chạy xong trước khi đăng ký instance vào load balancer.

Vì sao đúng

Vấn đề: script bootstrap chạy lâu hơn trước, nên instance được coi là "lành" trong khi ứng dụng chưa sẵn sàng nhận request.

Lifecycle hook cho hành động launch giữ instance ở Pending:Wait. Ở trạng thái đó instance chưa được đăng ký vào load balancer, nên không nhận request nào. Script bootstrap chạy xong thì tự báo:

# Dòng cuối cùng của script bootstrap
aws autoscaling complete-lifecycle-action \
  --lifecycle-hook-name cho-bootstrap \
  --auto-scaling-group-name nhom-web \
  --lifecycle-action-result CONTINUE \
  --instance-id $(curl -s http://169.254.169.254/latest/meta-data/instance-id)

Điểm mạnh so với mọi phương án còn lại: hook chờ đúng bằng thời gian bootstrap thực tế. Bootstrap xong trong 90 giây thì instance vào phục vụ ở giây thứ 90; mất 4 phút thì nó chờ 4 phút. Không phải đoán một con số.

Vì sao các phương án khác sai

• C. Tăng health check timeout lên 120 giây và healthy threshold lên 5 — chỉ làm health check chậm kết luận hơn, không ngăn được việc instance được đăng ký vào ELB ngay từ đầu. Traffic vẫn đi vào máy chưa sẵn sàng trong lúc chờ đủ số lần kiểm tra.
• D. Tăng grace period từ 300 lên 600 giây — hiểu nhầm chức năng. Health check grace period chỉ nói "đừng đánh dấu instance là không lành trong N giây đầu". Nó không ngăn việc instance được đăng ký vào load balancer và không ngăn traffic đi vào. Thực tế nó còn làm tệ hơn: instance hỏng thật cũng được che chắn lâu hơn.
• A. Lambda tạm dừng tiến trình health check — tạm dừng health check nghĩa là ASG ngừng đánh giá sức khoẻ của cả nhóm, làm mù toàn bộ cơ chế tự chữa. Và nó vẫn không ngăn được việc đăng ký vào ELB — muốn thế thì phải tạm dừng AddToLoadBalancer, nhưng cách đó ảnh hưởng mọi instance mới chứ không chờ theo từng máy.

Ghi nhớ

Ba khái niệm rất hay bị lẫn: | Cơ chế | Làm gì | |---|---| | Lifecycle hook | giữ instance lại cho tới khi bạn báo xong | | Health check grace period | hoãn việc đánh giá sức khoẻ | | Tạm dừng AddToLoadBalancer | instance mới không bao giờ tự vào ELB |

Chỉ lifecycle hook cho phép chờ đúng bằng thời gian thực tế của từng instance.

Đáp án

A — Dùng custom metric của CloudWatch và publish dưới dạng statistic set gom các điểm dữ liệu, gửi mỗi 1 phút.

Vì sao đúng

Ràng buộc: script chạy 10 giây một lần, dữ liệu cần ở mức 1 phút, và phải tiết kiệm chi phí.

Statistic set là cơ chế sinh ra đúng cho việc này: thay vì gửi 6 điểm dữ liệu riêng lẻ mỗi phút, bạn gửi một bản ghi tóm tắt:

aws cloudwatch put-metric-data --namespace "UngDung" \
  --metric-name "TinhSanSang" \
  --statistic-values Sum=6,Minimum=0,Maximum=1,SampleCount=6

Ba cái lợi cùng lúc:

• Ít lời gọi API hơn 6 lần — PutMetricData tính tiền theo lời gọi
• Vẫn giữ được min, max, sum, count, nên alarm vẫn hoạt động đầy đủ
• Dùng standard resolution (60 giây), rẻ hơn high resolution

Và điểm quan trọng: đây phải là custom metric, vì đây là số liệu do script của bạn sinh ra. CloudWatch không có sẵn metric nào biết "ứng dụng của bạn có sẵn sàng không".

Vì sao các phương án khác sai

• C. Custom metric high resolution, publish mỗi 10 giây — đáp ứng về kỹ thuật nhưng đắt hơn hẳn: 6 lần số lời gọi API, và high-resolution metric (1 giây) có giá cao hơn standard. Đề nói rõ chỉ cần dữ liệu mỗi 1 phút, nên trả tiền cho độ phân giải giây là lãng phí.
• B. "Default CloudWatch metric với standard resolution, dùng dimension để publish" — sai khái niệm: metric mặc định là metric do chính AWS phát ra (CPUUtilization, NetworkIn…), bạn không ghi dữ liệu của mình vào đó được. Dimension cũng chỉ là nhãn để phân nhóm metric, không phải cơ chế publish.
• D. "Default metric với high resolution, gom điểm dữ liệu" — cùng lỗi với B ở chữ default, cộng thêm việc chọn high resolution không cần thiết.

Ghi nhớ

Và nhớ statistic set: khi nguồn dữ liệu sinh nhanh hơn độ phân giải cần thiết, gom lại rồi gửi một lần — vừa rẻ vừa không mất thông tin thống kê.

Đáp án

A — Auto Scaling group multi-AZ sau ALB; CSDL dùng Amazon Aurora; dùng Amazon Inspector để tự động đánh giá bảo mật.

Vì sao đúng

Đề nêu bốn yêu cầu, và hai trong số đó là điểm phân biệt:

Điểm loại 1 — Aurora hay RDS PostgreSQL. Đề nhấn mạnh lo ngại về hiệu năng CSDL trong đợt bán hàng. Aurora PostgreSQL-compatible cho thông lượng cao hơn hẳn và mở rộng đọc dễ hơn, nên nó thắng B.

Điểm loại 2 — Inspector hay GuardDuty/Macie. Yêu cầu là "continually scanned for vulnerabilities" — đó chính xác là Inspector:

• Inspector: quét CVE của gói phần mềm và phơi nhiễm mạng ⇒ lỗ hổng ✅
• GuardDuty: phát hiện mối đe doạ đang diễn ra ⇒ sai loại
• Macie: tìm dữ liệu nhạy cảm trong S3 ⇒ sai hẳn

Vì sao các phương án khác sai

• B. Chỉ khác A ở chỗ dùng RDS PostgreSQL thay Aurora — thua ở vế hiệu năng cao điểm.
• C. Dùng GuardDuty để "đánh giá bảo mật" — sai công cụ, GuardDuty không quét lỗ hổng.
• D. Dùng Macie — sai xa nhất, Macie chỉ làm việc với dữ liệu trong S3.

Ghi nhớ về chất lượng câu hỏi

Cả bốn phương án đều nói Aurora ở cấu hình "multi-master", và đó là một chi tiết sai. Aurora multi-master chỉ hoạt động trong một Region (không phải cơ chế đa Region), và nó đã bị AWS ngừng cung cấp cho Aurora MySQL, chưa từng có cho Aurora PostgreSQL. Cấu hình đúng cho tính sẵn sàng cao của Aurora là một writer + nhiều reader trải trên các AZ, với failover tự động trong khoảng 30 giây.

Vì cụm từ đó xuất hiện ở cả bốn phương án, nó không phải điểm phân biệt — hai điểm phân biệt thật là Aurora vs RDS và Inspector vs GuardDuty/Macie. Nhưng đừng học thuộc "Aurora multi-master" như một mô hình đúng.