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

🧩 Phân tích câu hỏi trắc nghiệm AWS về High Availability

Giải thích nội dung câu hỏi một cách chi tiết:
Câu hỏi tập trung vào việc cải thiện tính sẵn sàng cao (High Availability - HA) cho một ứng dụng web nội bộ (internally facing web application). Kiến trúc hiện tại rất đơn giản và không HA:

• Chỉ có một instance EC2 làm web server.
• Một NAT instance duy nhất cung cấp truy cập outbound internet (cho updates và public data).

Vấn đề chính:

• Nếu instance web server hoặc NAT instance fail (do AZ outage, hardware failure), toàn bộ ứng dụng sẽ downtime.
• Để đạt HA trên AWS, cần phân tán tài nguyên qua nhiều Availability Zones (AZs), sử dụng managed services, load balancing và redundancy.
• Yêu cầu chọn TWO adjustments kết hợp để khắc phục.

Mục tiêu: Làm cho web app chịu lỗi AZ, scale load và outbound traffic HA. (Kiến thức cập nhật AWS 2026: Vẫn ưu tiên ALB cho layer 7, NAT Gateway managed thay NAT instance).

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

Dựa trên best practices AWS, hai lựa chọn sau là đúng và bổ trợ lẫn nhau để đạt HA toàn diện:

• Create additional EC2 instances spanning multiple Availability Zones. Add an Application Load Balancer to split the load between them.
  Lý do: Tạo nhiều EC2 web servers qua nhiều AZs, kết hợp Application Load Balancer (ALB) để phân tải và health check. ALB tự động failover nếu AZ fail, đảm bảo web app luôn available.

• Replace the NAT instance with a NAT gateway in each Availability Zone. Update the route tables.
  Lý do: NAT Gateway (NAT GW) là managed service AWS, đặt một GW per AZ để outbound traffic HA. Update route tables (RT) private subnets để route 0.0.0.0/0 qua NAT GW tương ứng AZ, tránh single point of failure.

🛠️ Kết hợp hai cái này: Web tier HA với ALB + Outbound HA với NAT GWs → Full HA architecture!

📋 Phân tích TẤT CẢ các phương án (Đúng/Sai):

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

• ❌ Add the NAT instance to an EC2 Auto Scaling group that spans multiple Availability Zones. Update the route tables.
  Sai vì: NAT instance (EC2-based) trong ASG có thể scale nhưng không tự động HA outbound (cần config phức tạp như disable source/dest check, script failover). AWS khuyến nghị NAT GW managed thay vì tự quản NAT instance (dễ lỗi, không scalable). Update RT chỉ partial fix, không phải best practice.

• ✅ Create additional EC2 instances spanning multiple Availability Zones. Add an Application Load Balancer to split the load between them.
  Đúng vì: Phân tán EC2 web servers qua nhiều AZs + ALB (layer 7 LB) phân tải, health check, sticky sessions. Đảm bảo zero-downtime nếu một AZ fail. Đây là standard HA pattern cho web apps.

• ❌ Configure an Application Load Balancer in front of the EC2 instance. Configure Amazon CloudWatch alarms to recover the EC2 instance upon host failure.
  Sai vì: Vẫn chỉ một EC2 instance (không span AZs), ALB chỉ front-end nhưng không scale/load split thực sự. CloudWatch alarms + recovery chỉ handle host failure (như EC2 Auto Recovery), không chống AZ outage hoặc high load. Không đạt true HA.

• ✅ Replace the NAT instance with a NAT gateway in each Availability Zone. Update the route tables.
  Đúng vì: NAT GW per AZ cung cấp redundancy outbound (highly available, scalable đến 100 Gbps). Update RT để private subnets route traffic qua GW gần nhất → Không downtime nếu AZ fail. NAT GW managed, auto-scale, tốt hơn NAT instance.

• ❌ Replace the NAT instance with a NAT gateway that spans multiple Availability Zones. Update the route tables.
  Sai vì: NAT GW KHÔNG span multiple AZs! Mỗi NAT GW gắn chặt một AZ duy nhất (AWS docs xác nhận). Không thể "spans AZs" → Sai kiến trúc cơ bản. Phải dùng multiple GWs (một per AZ).

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

• AWS Well-Architected Framework - Reliability Pillar: https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html (HA patterns với multi-AZ).
• Elastic Load Balancing (ALB): https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html.
• NAT Gateways: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html (Xác nhận: "NAT gateway resides in a single AZ, deploy multiple for HA").
• Exam DOP-C02 Guide: High Availability cho VPC/EC2/NAT (AWS re:Post & Practice Exams).

💡 Lời khuyên DevOps: Luôn test failover với Chaos Engineering (AWS Fault Injection Simulator) để verify HA! Nếu implement, dùng Terraform/CloudFormation cho IaC. 🚀

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

Câu hỏi tập trung vào việc xây dựng một pipeline đa giai đoạn (multistage pipeline) sử dụng AWS CodePipeline để thực hiện các bước: build (xây dựng), verify (xác thực), stage (chuẩn bị môi trường staging), test (kiểm thử), và deploy (triển khai) ứng dụng. Yêu cầu đặc biệt là cần một giai đoạn phê duyệt thủ công (manual approval stage) giữa giai đoạn test và deploy. Nhóm phát triển sử dụng một công cụ chat tùy chỉnh (custom chat tool) hỗ trợ webhook, và họ cần thông báo gần thời gian thực (near-real-time notifications) cho:

• Cập nhật trạng thái hoạt động pipeline (pipeline activity status updates), như thay đổi trạng thái execution (ví dụ: success, failed).
• Yêu cầu phê duyệt (approval requests) trong giai đoạn manual approval.

DevOps engineer cần cấu hình để tự động post thông báo vào chat tool qua webhook. Mục tiêu chính: Đảm bảo thông báo nhanh chóng, đáng tin cậy, và bao quát cả state changes lẫn approvals mà không can thiệp thủ công vào pipeline code.

📘 Kiến thức AWS cập nhật đến 2026: AWS CodePipeline tích hợp chặt chẽ với Amazon EventBridge (trước đây là CloudWatch Events) để emit events về Pipeline Execution State Change (bao gồm approvals). Đây là cách chuẩn và được khuyến nghị cho notifications real-time (xem AWS Docs: CodePipeline EventBridge Integration).

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

Đáp án đúng: Create an Amazon EventBridge rule that filters on CodePipeline Pipeline Execution State Change. Publish the events to an Amazon Simple Notification Service (Amazon SNS) topic. Create an AWS Lambda function that sends event details to the chat webhook URL. Subscribe the function to the SNS topic.

🛠️ Lý do chi tiết:

• EventBridge rule lọc chính xác events từ CodePipeline với detail-type: CodePipeline Pipeline Execution State Change, bao quát tất cả state changes (InProgress, Succeeded, Superseded, Failed) và approval actions (ví dụ: approval needed).
• Events được publish đến SNS topic để fan-out (phân phối rộng), đảm bảo near-real-time (latency <1 giây).
• Lambda function subscribed vào SNS, nhận event và gửi HTTP POST đến webhook URL của chat tool (Lambda hỗ trợ HTTP requests qua SDK như boto3/requests).
• Ưu điểm: Serverless, scalable, không cần modify pipeline code, hỗ trợ custom logic trong Lambda (parse event, format message). Hoàn hảo cho custom webhook không hỗ trợ SNS subscription trực tiếp.
• Tuân thủ best practices AWS 2026: EventBridge + SNS + Lambda là pattern tiêu chuẩn cho notifications (AWS Well-Architected Framework: Operational Excellence pillar).

📋 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 một cách chi tiết. Giữ nguyên văn bản gốc (bằng tiếng Anh), đánh dấu ✅/❌, và giải thích hoàn toàn bằng tiếng Việt.

• Create an Amazon CloudWatch Logs subscription that filters on CodePipeline Pipeline Execution State Change. Publish subscription events to an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the chat webhook URL to the SNS topic, and complete the subscription validation.
  ❌ Sai vì: CloudWatch Logs subscription dùng cho log streams (nhật ký), nhưng CodePipeline không emit Pipeline Execution State Change trực tiếp vào CloudWatch Logs. Events này chỉ đi qua EventBridge, không phải logs. SNS hỗ trợ HTTP subscription nhưng webhook tùy chỉnh có thể fail validation (challenge-response), và không near-real-time như EventBridge. Không cover approvals đầy đủ.

• Create an AWS Lambda function that is invoked by AWS CloudTrail events. When a CodePipeline Pipeline Execution State Change event is detected, send the event details to the chat webhook URL.
  ❌ Sai vì: CloudTrail ghi lại API calls (management events), không phải state changes real-time của pipeline. CloudTrail là asynchronous (delay 5-15 phút), không đạt near-real-time. Không có event cụ thể "Pipeline Execution State Change" trong CloudTrail; nó chỉ log actions như StartPipelineExecution. Không hiệu quả cho approvals.

• Create an Amazon EventBridge rule that filters on CodePipeline Pipeline Execution State Change. Publish the events to an Amazon Simple Notification Service (Amazon SNS) topic. Create an AWS Lambda function that sends event details to the chat webhook URL. Subscribe the function to the SNS topic.
  ✅ Đúng vì: Như đã giải thích ở phần đáp án. EventBridge capture events real-time từ CodePipeline (bao gồm approvals). SNS + Lambda xử lý fan-out và custom HTTP post đến webhook. Scalable, low-latency, không phụ thuộc pipeline code. Tested pattern trong AWS exam DOP-C02 (2023-2026).

• Modify the pipeline code to send the event details to the chat webhook URL at the end of each stage. Parameterize the URL so that each pipeline can send to a different URL based on the pipeline environment.
  ❌ Sai vì: CodePipeline định nghĩa qua JSON/YAML, nhưng không hỗ trợ action gửi HTTP trực tiếp ở cuối stage (chỉ các actions chuẩn như Invoke Lambda, nhưng phức tạp và không standard). Manual approval không phải stage action có thể "modify" dễ dàng để send notification. Vi phạm immutability (không nên hardcode webhook vào pipeline), không scalable cho multi-pipeline, và miss state changes ngoài stage ends.

🔗 Tài liệu tham khảo

• 📘 AWS CodePipeline EventBridge Events (cập nhật 2025).
• 📘 Integrate CodePipeline with Custom Notifications (blog AWS 2024).
• 📘 AWS DOP-C02 Exam Guide – Domain 3: Automation & Orchestration.

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần demo code Lambda/EventBridge, hãy hỏi thêm.

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

Câu hỏi xoay quanh một tình huống thực tế trong môi trường AWS: 👨‍💻 Nhóm phát triển ứng dụng sử dụng các instance Amazon EC2 chạy Linux làm bastion hosts (máy chủ trung gian để truy cập an toàn vào các tài nguyên nội bộ). Quy tắc inbound SSH (cổng 22) trên security groups liên kết chỉ cho phép từ các IP addresses cụ thể, đảm bảo bảo mật cao. Tuy nhiên, đội ngũ security muốn nhận thông báo ngay lập tức nếu ai đó sửa đổi security group rules để cho phép SSH từ bất kỳ IP nào (0.0.0.0/0) – một lỗ hổng bảo mật nghiêm trọng (unrestricted access).

🛠️ Yêu cầu của DevOps engineer: Triển khai giải pháp tự động hóa giám sát và thông báo (notification) khi vi phạm xảy ra. Giải pháp phải phát hiện thay đổi cấu hình security group liên quan đến SSH và kích hoạt Amazon SNS để gửi thông báo. Đây là bài toán điển hình về compliance monitoring và continuous auditing trong AWS, sử dụng các dịch vụ như AWS Config, CloudTrail, EventBridge để đảm bảo tuân thủ nguyên tắc least privilege.

📘 Kiến thức cập nhật đến 2026: AWS Config managed rules (phiên bản mới nhất) hỗ trợ rule restricted-ssh chuyên kiểm tra SSH unrestricted. AWS khuyến nghị sử dụng AWS Config cho configuration compliance thay vì chỉ event-based detection.

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

Đáp án đúng: Create an AWS Config rule by using the restricted-ssh managed rule to check whether security groups disallow unrestricted incoming SSH traffic. Configure automatic remediation to publish a message to an Amazon Simple Notification Service (Amazon SNS) topic.

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

• AWS Config managed rule "restricted-ssh" (cập nhật mới nhất 2024-2026) chính xác kiểm tra tất cả security groups có chặn SSH (port 22/TCP) từ 0.0.0.0/0 hay không. Nó liên tục đánh giá compliance (mỗi 6 giờ hoặc tùy chỉnh), phát hiện thay đổi ngay lập tức và đánh dấu NON_COMPLIANT nếu vi phạm.
• Automatic remediation với AWS Systems Manager Automation hoặc Lambda có thể tự động publish message đến SNS topic khi phát hiện vấn đề – hoàn hảo cho thông báo real-time đến security team.
• Giải pháp toàn diện, scalable, không miss thay đổi (như revoke rule cũ hoặc add rule mới), và cost-effective cho bastion hosts.

Nguồn tham khảo:

• AWS Config restricted-ssh rule 📘
• AWS Config Remediation with SNS (hỗ trợ SNS target từ 2023+).

📋 Phân tích tất cả các phương án (đúng/sai)

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên tính chính xác, đầy đủ và phù hợp yêu cầu (giám sát thay đổi SG SSH unrestricted + notification).

• ❌ [SAI] Create an Amazon EventBridge rule with a source of aws.cloudtrail and the event name AuthorizeSecurityGroupIngress. Define an Amazon Simple Notification Service (Amazon SNS) topic as the target.
  Giải thích sai: Rule này chỉ bắt sự kiện cụ thể "AuthorizeSecurityGroupIngress" từ CloudTrail (thêm rule inbound mới), bỏ lỡ các thay đổi khác như RevokeSecurityGroupIngress (xóa rule cũ), AuthorizeSecurityGroupEgress, hoặc thay đổi description/IP. Không lọc chính xác SSH từ 0.0.0.0/0, dẫn đến false positive/negative. Không phải giải pháp compliance monitoring toàn diện.

• ❌ [SAI] Enable Amazon GuardDuty and check the findings for security groups in AWS Security Hub. Configure an Amazon EventBridge rule with a custom pattern that matches GuardDuty events with an output of NON_COMPLIANT. Define an Amazon Simple Notification Service (Amazon SNS) topic as the target.
  Giải thích sai: GuardDuty chuyên detect threats/malware (như reconnaissance, crypto-mining), KHÔNG monitor cấu hình SG chi tiết như SSH unrestricted (chỉ có findings chung về exposure). Security Hub tổng hợp findings nhưng custom pattern NON_COMPLIANT không chuẩn cho GuardDuty (GuardDuty dùng severity/finding type). Phức tạp, không reliable cho thay đổi SG real-time.

• ✅ [ĐÚNG] Create an AWS Config rule by using the restricted-ssh managed rule to check whether security groups disallow unrestricted incoming SSH traffic. Configure automatic remediation to publish a message to an Amazon Simple Notification Service (Amazon SNS) topic.
  Giải thích đúng: Như đã phân tích ở trên – managed rule chuyên biệt, continuous evaluation, remediation trực tiếp đến SNS. Hoàn hảo khớp yêu cầu! 🚀

• ❌ [SAI] Enable Amazon Inspector. Include the Common Vulnerabilities and Exposures-1.1 rules package to check the security groups that are associated with the bastion hosts. Configure Amazon Inspector to publish a message to an Amazon Simple Notification Service (Amazon SNS) topic.
  Giải thích sai: Amazon Inspector scan vulnerabilities trên EC2 instances (software/OS level, CVE ruleset), KHÔNG kiểm tra security groups (network config). CVE-1.1 là package cũ cho instance scanning, miss hoàn toàn thay đổi SG rules. Không phù hợp cho configuration compliance.

Kết luận 🎯: Sử dụng AWS Config là best practice DevOps cho infrastructure as code compliance (IaC), giúp security team proactive monitoring mà không cần custom scripting! Nếu triển khai, tag SG của bastion hosts để rule chỉ apply đúng scope.

🧑‍💼 Phân tích từ AWS Certified DevOps Engineer – Professional

Chào bạn! Tôi là chuyên gia AWS Certified DevOps Engineer – Professional với kiến thức cập nhật đến năm 2026 (dựa trên các tính năng mới nhất của AWS như tích hợp sâu hơn giữa API Gateway, X-Ray và CloudWatch Agent hỗ trợ on-premises). Hãy cùng phân tích kỹ câu hỏi này một cách logic và chi tiết nhé! 🚀

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

Câu hỏi mô tả tình huống: Một đội DevOps quản lý API chạy on-premises (trên máy chủ tại chỗ, không phải AWS cloud) làm backend cho Amazon API Gateway. Khách hàng phàn nàn về độ trễ phản hồi cao (high response latencies), và đội ngũ đã xác nhận qua metrics latency của API Gateway trong Amazon CloudWatch.

Mục tiêu: Thu thập dữ liệu liên quan để xác định nguyên nhân (như bottleneck ở backend on-premises) mà KHÔNG giới thiệu thêm độ trễ (without introducing additional latency). Cần chọn HAI hành động phù hợp.

🛠️ Vấn đề cốt lõi: API Gateway chỉ đo lường latency tổng thể (integration latency), nhưng để drill-down vào backend on-premises, cần tracing/logs/metrics từ phía server-side. Giải pháp phải asynchronous (không đồng bộ, không block request) để tránh tăng latency.

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

Hai lựa chọn đúng là:

1. Install the CloudWatch agent server side and configure the agent to upload relevant logs to CloudWatch.
2. Enable AWS X-Ray tracing in API Gateway, modify the application to capture request segments, and use the X-Ray daemon to upload segments to X-Ray.

Lý do lựa chọn:
✅ Cả hai đều sử dụng cơ chế agent/daemon chạy nền (sidecar pattern) để thu thập và upload dữ liệu asynchronously (batch và không đồng bộ), không ảnh hưởng đến luồng request chính. Điều này giúp trace chính xác latency ở backend on-premises mà không thêm overhead. Theo best practices AWS 2026, đây là cách tiêu chuẩn cho hybrid setups (API Gateway + on-premises).

• CloudWatch Agent: Thu thập logs/metrics từ server-side và push lên CloudWatch Logs/Metrics mà không block app.
• X-Ray Daemon: Chạy như process riêng trên on-premises server, nhận segments từ app qua UDP (non-blocking), rồi batch upload lên X-Ray service.

📋 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 một cách đầy đủ. Tôi giữ nguyên văn bản gốc tiếng Anh của phương án, chỉ giải thích bằng tiếng Việt với lý do đúng/sai dựa trên nguyên tắc "không thêm latency".

• Install the CloudWatch agent server side and configure the agent to upload relevant logs to CloudWatch.
  ✅ ĐÚNG. CloudWatch Agent (phiên bản mới nhất 2026 hỗ trợ on-premises/hybrid) được cài trên server backend, chạy như daemon thu thập logs/metrics theo lịch (asynchronous). Nó push dữ liệu lên CloudWatch Logs/Metrics mà không can thiệp vào request flow, giúp phân tích latency chi tiết (ví dụ: CPU, disk I/O). Không thêm latency vì hoạt động nền. 🟢

• Enable AWS X-Ray tracing in API Gateway, modify the application to capture request segments, and upload those segments to X-Ray during each request.
  ❌ SAI. Việc upload segments trực tiếp trong mỗi request (synchronous HTTP call lên X-Ray service) sẽ block luồng xử lý, tăng đáng kể integration latency – vi phạm yêu cầu "không thêm latency". X-Ray docs khuyến cáo tránh cách này cho production vì overhead cao (khoảng 1-5ms/request). Thay vào đó, dùng daemon để async. 🔴

• Enable AWS X-Ray tracing in API Gateway, modify the application to capture request segments, and use the X-Ray daemon to upload segments to X-Ray.
  ✅ ĐÚNG. Kích hoạt tracing ở API Gateway (active tracing mode, cập nhật 2026 hỗ trợ sampling tự động), app capture segments (qua SDK), rồi gửi qua UDP đến X-Ray daemon chạy trên on-premises server. Daemon batch và upload async lên X-Ray, không block request. Đây là cách chuẩn cho backend on-premises, trace end-to-end latency (API Gateway → backend). Hoàn hảo! 🟢

• Modify the on-premises application to send log information back to API Gateway with each request.
  ❌ SAI. Gửi logs qua mỗi request (thêm payload vào response hoặc header) sẽ tăng kích thước response và thời gian xử lý ở API Gateway, trực tiếp làm tăng latency. API Gateway không thiết kế để relay logs on-premises; thay vào đó dùng CloudWatch/X-Ray. Vi phạm nghiêm trọng yêu cầu. 🚫

• Modify the on-premises application to calculate and upload statistical data relevant to the API service requests to CloudWatch metrics.
  ❌ SAI. Việc app tự calculate và upload metrics trong code (qua PutMetricData API) là synchronous, thêm CPU/overhead và network call per request, gây tăng latency. CloudWatch khuyến cáo dùng agent/embedded metric format để async. Không phù hợp cho troubleshooting real-time. 📉

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

• AWS X-Ray cho API Gateway & On-Premises: docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-xray.html & X-Ray Daemon on EC2/On-Prem – Nhấn mạnh UDP non-blocking.
• CloudWatch Agent cho Hybrid: docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html – Hỗ trợ logs/metrics async từ on-premises.
• API Gateway Metrics: docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html – Latency metrics chỉ tổng quát, cần X-Ray để drill-down.
• Best Practices DevOps: AWS Well-Architected Framework – Observability pillar (Reliability & Operational Excellence).

Nếu bạn có câu hỏi khác hoặc cần lab thực hành, cứ hỏi nhé! 💡

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

Câu hỏi tập trung vào tình huống disaster recovery (DR) với Amazon Aurora Multi-AZ DB cluster (tương thích MySQL). Ứng dụng đang sử dụng cluster chính (primary) ở một Region, và đã tạo cross-Region read replica để sao lưu dữ liệu cho mục đích khôi phục thảm họa. Khi primary gặp sự cố (failure), DevOps engineer cần tự động hóa việc promote read replica thành primary mới, đảm bảo ứng dụng chuyển tiếp mượt mà mà không gián đoạn lớn.

🔑 Yêu cầu chính: Giải pháp phải phát hiện failure tự động, promote replica, và cập nhật endpoint để ứng dụng kết nối primary mới. Aurora hỗ trợ manual promotion cross-Region replica (thời gian ~1-2 phút theo docs AWS 2024-2026), nên cần automation qua dịch vụ serverless như Lambda, EventBridge. Không dùng failover tự động vì cross-Region replica không hỗ trợ Aurora Multi-AZ auto-failover (chỉ intra-Region).

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

• Amazon Aurora Cross-Region Replication (AWS cập nhật 2025).
• Aurora Global Database & DR.

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

Đáp án đúng:
Store the Aurora endpoint in AWS Systems Manager Parameter Store. Create an Amazon EventBridge event that detects the database failure and runs an AWS Lambda function to promote the replica instance and update the endpoint URL stored in AWS Systems Manager Parameter Store. Code the application to reload the endpoint from Parameter Store if a database connection fails.

Lý do:

• 🛠️ Phát hiện failure: Amazon EventBridge (trước là CloudWatch Events) hỗ trợ RDS event "RDS-EVENT-0074" (failure) hoặc tích hợp CloudWatch metrics/alarm cho DB instance status.
• 🛠️ Automation: Lambda promote replica (API promote-read-replica), cập nhật SSM Parameter Store (lưu endpoint động, secure với IAM).
• 🛠️ Ứng dụng resilient: App poll/reload endpoint từ SSM khi connection fail → zero-downtime gần nhất, không thay đổi DNS hay template.
• ✅ Tuân thủ best practice DevOps: Serverless, idempotent, scalable (AWS Well-Architected Framework - Reliability pillar, 2026 edition).

❌ 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. Tôi giữ nguyên văn bản gốc tiếng Anh, chỉ giải thích bằng tiếng Việt với lý do đúng/sai dựa trên tính khả thi, best practice AWS mới nhất (2026).

• Phương án 1 (SAI):
  Configure a latency-based Amazon Route 53 CNAME with health checks so it points to both the primary and replica endpoints. Subscribe an Amazon SNS topic to Amazon RDS failure notifications from AWS CloudTrail and use that topic to invoke an AWS Lambda function that will promote the replica instance as the primary.
  ❌ Sai vì: Route 53 latency-based DNS không phù hợp failover DB (chậm ~30-60s, read replica không writable ban đầu). CloudTrail log event chậm (5-15 phút), không real-time như EventBridge/RDS Events. SNS + Lambda promote OK nhưng tổng thể không reliable cho DR (docs: Route 53 không khuyến nghị cho DB endpoints động).

• Phương án 2 (SAI):
  Create an Aurora custom endpoint to point to the primary database instance. Configure the application to use this endpoint. Configure AWS CloudTrail to run an AWS Lambda function to promote the replica instance and modify the custom endpoint to point to the newly promoted instance.
  ❌ Sai vì: Aurora custom endpoint chỉ hỗ trợ cluster endpoints intra-Region (reader/writer endpoints), không cross-Region và không dynamic modify dễ dàng (cần Data API hoặc proxy). CloudTrail chậm như trên, không trigger real-time Lambda. App dùng custom endpoint → downtime cao khi modify.

• Phương án 3 (SAI):
  Create an AWS Lambda function to modify the application's AWS CloudFormation template to promote the replica, apply the template to update the stack, and point the application to the newly promoted instance. Create an Amazon CloudWatch alarm to invoke this Lambda function after the failure event occurs.
  ❌ Sai vì: CloudFormation không promote replica trực tiếp (chỉ tạo mới, không modify existing replica). Update stack chậm (5-10 phút+), gây downtime lớn. CloudWatch alarm OK detect nhưng over-engineered, không idempotent (template modify dễ lỗi).

• Phương án 4 (ĐÚNG):
  Store the Aurora endpoint in AWS Systems Manager Parameter Store. Create an Amazon EventBridge event that detects the database failure and runs an AWS Lambda function to promote the replica instance and update the endpoint URL stored in AWS Systems Manager Parameter Store. Code the application to reload the endpoint from Parameter Store if a database connection fails.
  ✅ Đúng như đã giải thích ở trên: Tối ưu, nhanh, resilient. EventBridge detect instant, SSM secure/centralized config, app self-healing.

🛡️ Lời khuyên DevOps: Sử dụng Aurora Global Database (nếu cần managed failover cross-Region, ra mắt 2024) để thay thế manual promotion. Test với Chaos Engineering (AWS Fault Injection Simulator)!

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

Câu hỏi tập trung vào việc cải thiện khả năng phục hồi (recovery) cho một EC2 instance đang host staging website, sử dụng EBS làm storage. Các vấn đề cần xử lý là network connectivity issues (vấn đề kết nối mạng) hoặc power failures (mất điện) trên instance. Yêu cầu chính: phục hồi nhanh chóng (quick recovery) và mất dữ liệu tối thiểu (minimal data loss).

Những vấn đề này thường xảy ra ở mức hệ thống (system level), như hỏng hardware host, mất kết nối mạng đến host, hoặc mất nguồn điện của physical server. Do đó, giải pháp phải tự động detect vấn đề qua monitoring và thực hiện recovery mà không làm mất dữ liệu trên EBS (vì EBS là block storage bền vững, attached trực tiếp vào instance mới khi recover).

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

Đáp án đúng: Create an Amazon CloudWatch alarm for the StatusCheckFailed System metric and select the EC2 action to recover the instance.

Lý do chi tiết:

• StatusCheckFailed_System metric (từ CloudWatch) detect các vấn đề ở mức underlying host như power failure, network outage của hypervisor AWS → phù hợp hoàn hảo với yêu cầu.
• EC2 recovery action sẽ tự động stop instance, detach EBS volumes, attach vào host mới lành mạnh, và start lại → phục hồi nhanh (thường <5 phút) và minimal data loss (EBS data được giữ nguyên, chỉ mất dữ liệu in-flight nếu có).
• Đây là tính năng chuẩn của AWS EC2 Instance Recovery (cập nhật đến 2026, hỗ trợ đa AZ và EBS encryption). Không ảnh hưởng đến IP public nếu dùng Elastic IP.

📋 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 lựa chọn một cách đầy đủ:

• Add the instance to an EC2 Auto Scaling group with the minimum, maximum, and desired capacity set to 1.
  ❌ Sai vì: ASG với capacity=1 chỉ launch instance mới khi instance cũ terminate hoàn toàn (không tự động recover). Với power failure hoặc network issue, ASG không detect được ngay → thời gian recover lâu (phải health check + launch mới). Data loss cao nếu EBS không được snapshot timely, vì instance mới không tự attach EBS cũ. Không phù hợp cho single staging instance cần minimal downtime.

• Add the instance to an EC2 Auto Scaling group with a lifecycle hook to detach the EBS volume when the EC2 instance shuts down or terminates.
  ❌ Sai vì: Lifecycle hook chỉ trigger khi shutdown/terminate có kế hoạch, không xử lý được power failure đột ngột. Detach EBS chủ động sẽ làm mất khả năng mount nhanh, dẫn đến data loss hoặc phải manual re-attach. ASG vẫn chậm như lựa chọn trên, không meet "quick recovery with minimal data loss".

• Create an Amazon CloudWatch alarm for the StatusCheckFailed System metric and select the EC2 action to recover the instance.
  ✅ Đúng vì: Như giải thích ở phần đáp án trên. Metric StatusCheckFailed_System (bình thường = 0, >0 khi host fail) kết hợp recover action là giải pháp AWS recommend cho host-level failures (network/power). Đảm bảo EBS intact, downtime thấp.

• Create an Amazon CloudWatch alarm for the StatusCheckFailed Instance metric and select the EC2 action to reboot the instance.
  ❌ Sai vì: StatusCheckFailed_Instance chỉ detect vấn đề bên trong guest OS (software crash, kernel panic), không phải network/power failure của host. Reboot action chỉ restart trên cùng host cũ → nếu host vẫn fail, vấn đề tái diễn, không recover. Data có thể loss nếu EBS corrupt trong reboot, không minimal data loss.

🛠️ Khuyến nghị triển khai thực tế

• Kết hợp với Elastic IP để giữ IP public ổn định.
• Test bằng EC2 Instance Recovery Simulator trong AWS console.
• Scale up: Dùng EBS Multi-Attach (nếu cần) hoặc AMI snapshot định kỳ cho staging.

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

• AWS Docs: Monitor your instances using Amazon CloudWatch – Chi tiết StatusCheckFailed metrics.
• AWS Docs: Recover your instance using a CloudWatch alarm – Hướng dẫn recover action.
• AWS Well-Architected Framework: Reliability Pillar – High Availability cho EC2 ( Reliability.pdf, 2024 update).
• Exam prep: AWS DOP-C02 blueprint, section EC2 Resilience.

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

Câu hỏi xoay quanh việc chuyển đổi từ các script bash thủ công sang các công cụ phát triển AWS để triển khai ứng dụng LAMP (Linux, Apache, MySQL, PHP) lên nhóm EC2 instances đứng sau Application Load Balancer (ALB). Các chức năng cần giữ nguyên bao gồm:

• Unit test ứng dụng đã commit.
• Stop và start services (như Apache, MySQL).
• Unregister và re-register instances với ALB để tránh traffic trong lúc deploy.
• Update file permissions (thay đổi quyền file).

Mục tiêu: Sử dụng AWS CodePipeline, CodeBuild, CodeDeploy (và có thể CodeCommit) để thay thế bash scripts, đảm bảo pipeline tự động hóa toàn bộ quy trình mà không mất chức năng cũ. Đây là kịch bản điển hình trong AWS DevOps pipeline cho EC2 deployments với blue-green hoặc in-place strategy, cập nhật theo AWS best practices năm 2026 (CodeDeploy hỗ trợ ALB integration qua lifecycle hooks).

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

Đáp án đúng: D
Use AWS CodePipeline to trigger AWS CodeBuild to test the application. Use bash scripts invoked by AWS CodeDeploy's appspec.yml file to restart services. Unregister and re-register the instances in the AWS CodeDeploy deployment group with the ALB. Update the appspec.yml file to update file permissions without a custom script.

🛠️ Lý do chi tiết:

• CodePipeline làm orchestrator, trigger CodeBuild để unit test (CodeBuild lý tưởng cho build/test phase với buildspec.yml hỗ trợ unit tests cho PHP/LAMP).
• CodeDeploy appspec.yml invoke bash scripts cho restart services (qua lifecycle hooks như AfterInstall).
• Deployment group của CodeDeploy tự động quản lý instances, kết hợp lifecycle hooks (BeforeBlockTraffic/AfterAllowTraffic) để unregister/re-register với ALB một cách tự động/an toàn (không cần manual script ngoài appspec).
• Appspec.yml cập nhật file permissions qua inline commands (như files section hoặc commands với chmod), không cần custom script riêng (chỉ dùng cấu hình YAML chuẩn).
  Điều này khớp hoàn hảo AWS Deployment best practices 2026, đảm bảo zero-downtime deploy cho EC2/ALB.

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

• ❌ Phương án A (SAI):
  Use AWS CodeBuild to test the application. Use bash scripts invoked by AWS CodeDeploy's appspec.yml file to restart services, and deregister and register instances with the ALB. Use the appspec.yml file to update file permissions without a custom script.
  Lý do sai: Không đề cập CodePipeline làm orchestrator (thiếu pipeline flow từ source đến deploy). Việc dùng bash scripts trực tiếp trong appspec cho deregister/register ALB OK nhưng không tận dụng deployment group hooks tự động; thay vào đó, phương án này làm phức tạp hóa bằng script thủ công thay vì lifecycle events chuẩn.

• ❌ Phương án B (SAI):
  Use AWS CodePipeline to move the application from the AWS CodeCommit repository to AWS CodeDeploy. Use CodeDeploy's deployment group to test the application, unregister and re-register instances with the ALand restart services. Use the appspec.yml file to update file permissions without a custom script.
  Lý do sai: CodeDeploy deployment group KHÔNG dùng để unit test (CodeDeploy chỉ deploy, không build/test). "ALand" là lỗi typo (ALB), và thiếu CodeBuild cho test phase. Deployment group chỉ quản lý instances, không tự restart services hay test.

• ❌ Phương án C (SAI):
  Use AWS CodePipeline to move the application source code from the AWS CodeCommit repository to AWS CodeDeploy. Use CodeDeploy to test the application. Use CodeDeploy's appspec.yml file to restart services and update permissions without a custom script. Use AWS CodeBuild to unregister and re-register instances with the ALB.
  Lý do sai: CodeDeploy KHÔNG test ứng dụng (test thuộc CodeBuild). Dùng CodeBuild chỉ cho unregister/register ALB là sai lầm lớn – CodeBuild là build tool, không phải deploy/runtime hook; việc này không tích hợp tốt với deployment group và gây phức tạp không cần thiết.

• ✅ Phương án D (ĐÚNG): (Đã giải thích chi tiết ở trên)
  Hoàn chỉnh, tận dụng đúng vai trò từng service: Pipeline → Build/Test → Deploy với hooks tự động.

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

• 🛠️ AWS CodeDeploy User Guide: AppSpec.yml reference – Chi tiết lifecycle hooks cho ALB integration và permissions.
• 🔄 AWS CodePipeline for EC2/ALB deployments (tương tự EC2).
• 🧪 AWS CodeBuild for testing LAMP/PHP.
• 📖 AWS DevOps Pro Exam Guide DOP-C02 (2026) – Domain 4: Automation of Deployments.
  (Nguồn chính thức AWS, kiểm tra realtime qua console để confirm features mới nhất).

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

Câu hỏi yêu cầu một DevOps engineer chuẩn hóa quy trình patching (vá lỗi hệ thống) cho ứng dụng chạy trên Amazon EC2 (môi trường cloud AWS) và on-premises (máy vật lý tại chỗ của công ty). Yêu cầu chính là chuẩn hóa patching trên cả hai môi trường và tuân thủ chính sách công ty: chỉ thực hiện patching trong giờ không làm việc (non-business hours). Cần chọn 3 hành động kết hợp để đáp ứng yêu cầu này.
🛠️ Công cụ chính liên quan: AWS Systems Manager (SSM) là giải pháp lý tưởng để quản lý patching thống nhất cho cả EC2 và on-premises, với tính năng Maintenance Windows để lên lịch patching vào thời gian cụ thể (như non-business hours). Kiến thức cập nhật đến 2026: SSM Hybrid Activations (nay tích hợp sâu với SSM Agent) cho phép quản lý máy on-premises mà không cần VPN/Direct Connect.

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

• Add the physical machines into AWS Systems Manager using Systems Manager Hybrid Activations.
• Attach an IAM role to the EC2 instances, allowing them to be managed by AWS Systems Manager.
• Use AWS Systems Manager Maintenance Windows to schedule a patch window.

Lý do lựa chọn:
Bộ ba hành động này tạo nền tảng quản lý thống nhất qua SSM:

• Hybrid Activations đưa máy on-premises vào SSM mà không lộ IAM keys (an toàn cao).
• IAM role cho EC2 cho phép SSM quản lý instance mà không cần credentials tĩnh.
• Maintenance Windows lên lịch patching chính xác vào non-business hours, tự động hóa patching qua Patch Manager.
  Kết hợp chúng chuẩn hóa patching, tuân thủ policy, và scalable theo best practices AWS (zero-trust model, không dùng long-lived keys).

🔍 Phân tích chi tiết từng phương án

Dưới đây là giải thích từng lựa chọn (giữ nguyên văn bản gốc), đánh dấu ✅ đúng hoặc ❌ sai, kèm lý do bằng tiếng Việt rõ ràng:

• ✅ Add the physical machines into AWS Systems Manager using Systems Manager Hybrid Activations.
  Phương án này đúng vì Hybrid Activations (tích hợp SSM Agent) cho phép đăng ký máy on-premises vào SSM fleet một cách an toàn, không cần mở port hoặc credentials lâu dài. Máy vật lý sẽ "outbound-only" kết nối SSM, hỗ trợ patching thống nhất với EC2. Đây là cách chuẩn AWS cho hybrid environments (cập nhật 2026: hỗ trợ Windows/Linux/EC2 Mac).

• ✅ Attach an IAM role to the EC2 instances, allowing them to be managed by AWS Systems Manager.
  Phương án này đúng vì EC2 cần IAM role với policy AmazonSSMManagedInstanceCore (hoặc tương tự) để SSM Agent giao tiếp. Không cần IAM users/keys, giảm rủi ro. Role này enable Run Command, State Manager, Patch Manager cho patching tự động.

• ❌ Create IAM access keys for the on-premises machines to interact with AWS Systems Manager.
  Phương án này sai vì IAM access keys (long-lived credentials) không an toàn cho on-premises: dễ leak, khó rotate, vi phạm nguyên tắc least privilege. Thay vào đó, dùng Hybrid Activations với temporary tokens tự động.

• ❌ Run an AWS Systems Manager Automation document to patch the systems every hour.
  Phương án này sai vì chạy Automation mỗi giờ vi phạm policy "chỉ non-business hours" (gây downtime business). Automation là cho ad-hoc tasks, không phải scheduling patching định kỳ; nên dùng Maintenance Windows thay thế.

• ❌ Use Amazon EventBridge scheduled events to schedule a patch window.
  Phương án này sai vì EventBridge (CloudWatch Events) chỉ trigger Lambda/API, không trực tiếp quản lý patching SSM (thiếu integration sâu với Patch Manager/State Manager). Maintenance Windows là tính năng native của SSM, chuyên biệt cho patching hybrid, hỗ trợ baseline/tag-based targeting.

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

• AWS Systems Manager Hybrid Activations – Hướng dẫn on-premises management.
• SSM Maintenance Windows & Patch Manager – Scheduling patching non-business hours.
• IAM Roles for EC2 & SSM – Best practices zero-credentials.
• AWS Well-Architected Framework: Operations Pillar (DevOps DOP-C02 exam guide, 2024-2026 updates).
  🛠️ Lời khuyên: Test lab với SSM Quick Setup để verify hybrid patching!

🧩 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 tập trung vào việc triển khai chiến lược multi-account trên AWS sử dụng AWS Organizations và AWS Control Tower. Một DevOps engineer đã tạo tài khoản mới, tổ chức (organization), cấu trúc Organizational Units (OUs), và thiết lập landing zone qua Control Tower.

Yêu cầu chính là giải pháp tự động nhất (MOST automated) để:

• Khi người dùng tạo tài khoản mới qua AWS Control Tower Account Factory, hệ thống tự động deploy resources.
• Áp dụng AWS CloudFormation templates và Service Control Policies (SCPs) tùy chỉnh theo OU hoặc tài khoản cụ thể.
• Tất cả OUs đều đã đăng ký (enrolled) trong Control Tower.

🛠️ Mục tiêu cốt lõi: Tự động hóa hoàn toàn việc provision resources (bao gồm CFN templates và SCPs) cho mọi tài khoản mới, mà không cần can thiệp thủ công, phù hợp với best practices multi-account và landing zone hiện đại (cập nhật đến 2026 với Control Tower v3+ và tích hợp sâu Organizations).

📌 Đáp án đúng: Deploy the Customizations for AWS Control Tower (CfCT) solution. Use an AWS CodeCommit repository as the source. In the repository, create a custom package that includes the CloudFormation templates and the SCP JSON documents.

✅ Lý do chọn đáp án này (giải thích chi tiết):

• CfCT là giải pháp chính thức và tự động nhất từ AWS, được thiết kế dành riêng cho Control Tower để customize landing zone. Nó tự động phát hiện sự kiện tạo tài khoản mới qua Account Factory, sau đó deploy CloudFormation templates và SCPs tùy chỉnh dựa trên OU hoặc account.
• Sử dụng AWS CodeCommit làm source repository chứa custom package (bao gồm CFN templates + SCP JSON), CfCT sẽ sync và apply tự động mà không cần trigger thủ công.
• Hoàn toàn managed và scalable, hỗ trợ multi-OU, tích hợp EventBridge ngầm, và tuân thủ zero-trust multi-account strategy (cập nhật 2026: CfCT hỗ trợ Lifecycle Policies và Guardrails nâng cao).
• MOST automated vì chỉ cần deploy CfCT một lần ở management account, mọi thứ còn lại là tự động!

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

• AWS Docs: Customizations for AWS Control Tower (v3.5+, 2026).
• AWS Well-Architected Framework: Multi-Account Strategies (Control Tower section).
• AWS re:Post & Blog: "Accelerate AWS Control Tower with CfCT" (2025 updates).

🛡️ Phân tích tất cả các phương án (Đúng/Sai)

• ❌ Phương án SAI: Use AWS Service Catalog with AWS Control Tower. Create portfolios and products in AWS Service Catalog. Grant granular permissions to provision these resources. Deploy SCPs by using the AWS CLI and JSON documents.
  🧩 Giải thích sai: Service Catalog chỉ quản lý portfolios/products cho self-service provisioning, không tự động trigger khi tạo account mới qua Account Factory. Phải grant permissions thủ công và deploy SCPs qua CLI (không automated). Không tích hợp native với Control Tower OUs/SCPs, dẫn đến thiếu tự động hóa toàn diện và rủi ro quản lý permissions.

• ❌ Phương án SAI: Deploy CloudFormation stack sets by using the required templates. Enable automatic deployment. Deploy stack instances to the required accounts. Deploy a CloudFormation stack set to the organization’s management account to deploy SCPs.
  🧩 Giải thích sai: Stack Sets hỗ trợ automatic deployment nhưng không tự động detect sự kiện tạo account mới từ Account Factory. Phải deploy instances thủ công đến accounts cụ thể và stack set riêng cho SCPs ở management account. Không customize theo OU động, thiếu integration sâu với Control Tower (dễ lỗi khi scale multi-account).

• ❌ Phương án SAI: Create an Amazon EventBridge rule to detect the CreateManagedAccount event. Configure AWS Service Catalog as the target to deploy resources to any new accounts. Deploy SCPs by using the AWS CLI and JSON documents.
  🧩 Giải thích sai: EventBridge có thể detect CreateManagedAccount event, nhưng target là Service Catalog chỉ deploy resources self-service (không native cho CFN/SCPs theo OU). SCPs vẫn phải CLI thủ công, không fully automated. Service Catalog không thay thế được CfCT cho landing zone customization, dễ miss guardrails.

• ✅ Phương án ĐÚNG: Deploy the Customizations for AWS Control Tower (CfCT) solution. Use an AWS CodeCommit repository as the source. In the repository, create a custom package that includes the CloudFormation templates and the SCP JSON documents.
  🛠️ Tóm tắt đúng (như đã giải thích trên): Giải pháp native, end-to-end automated của AWS Control Tower, perfect fit cho yêu cầu! 🚀

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

Câu hỏi mô tả một công ty bán lẻ trực tuyến tại Mỹ đang mở rộng sang châu Âu và châu Á trong 6 tháng tới. Hệ thống hiện tại sử dụng Amazon EC2 với Application Load Balancer (ALB), EC2 Auto Scaling group đa Availability Zones (AZ) để đảm bảo tính sẵn sàng cao, và tất cả dữ liệu lưu trữ trên Amazon Aurora (một cơ sở dữ liệu quan hệ tương thích MySQL/PostgreSQL với hiệu suất cao).

Khi triển khai đa vùng (multi-region), yêu cầu chính là:

• Product catalog (danh mục sản phẩm) phải là một catalog duy nhất (single) chia sẻ trên tất cả các vùng để đảm bảo tính nhất quán toàn cầu.
• Customer information và purchases (thông tin khách hàng và giao dịch mua hàng) phải giữ riêng biệt ở từng vùng để tuân thủ quy định pháp lý (compliance), tránh sao chép dữ liệu nhạy cảm giữa các vùng.
• Mục tiêu: Thực hiện với ít thay đổi ứng dụng nhất (LEAST amount of application changes), nghĩa là giữ nguyên logic code hiện tại càng nhiều càng tốt, chỉ điều chỉnh kiến trúc dữ liệu.

🛠️ Thách thức chính: Cân bằng giữa tính nhất quán toàn cầu cho catalog (chủ yếu đọc - read-heavy) và dữ liệu cục bộ cho compliance (viết/đọc cục bộ - regional), đồng thời giảm thiểu migration dữ liệu hoặc thay đổi schema/model từ Aurora hiện tại.

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

Đáp án đúng: Use Aurora with read replicas for the product catalog and additional local Aurora instances in each region for the customer information and purchases.

Lý do:

• Aurora với read replicas (cụ thể là Aurora Global Database - tính năng mới nhất đến 2026) cho phép tạo cross-region read replicas với độ trễ replication thấp (sub-second), đảm bảo product catalog có thể đọc từ replica cục bộ ở mỗi vùng mà vẫn nhất quán từ primary cluster (ví dụ: primary ở US). Writes cho catalog chỉ ở primary, reads ở replicas địa phương → phù hợp read-heavy workload.
• Local Aurora instances riêng ở mỗi vùng cho customer data → dữ liệu nhạy cảm không bị replicate cross-region, tuân thủ compliance (GDPR ở EU, v.v.).
• Ít thay đổi ứng dụng nhất (LEAST changes): Ứng dụng hiện dùng Aurora giữ nguyên connection strings (chỉ switch read traffic sang replicas qua endpoint), không cần thay đổi schema, model dữ liệu hay migrate sang NoSQL. Chỉ cần cấu hình Aurora Global DB và thêm clusters local.

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

• ❌ Use Amazon Redshift for the product catalog and Amazon DynamoDB tables for the customer information and purchases.
  Sai vì: Redshift là data warehouse cho analytics (OLAP), không phù hợp cho transactional catalog (OLTP) cần low-latency reads/writes real-time. Chuyển từ Aurora sang Redshift + DynamoDB yêu cầu thay đổi lớn schema, queries, và code ứng dụng (SQL sang columnar + NoSQL). DynamoDB regional tốt cho customer data nhưng không giải quyết catalog global hiệu quả, tăng chi phí và complexity không cần thiết.

• ❌ Use Amazon DynamoDB global tables for the product catalog and regional tables for the customer information and purchases.
  Sai vì: DynamoDB global tables replicate dữ liệu multi-master (writable ở mọi region), phù hợp cho data cần writes global nhưng không lý tưởng cho read-only catalog (có thể gây conflict và over-replication). Chuyển từ Aurora (SQL) sang DynamoDB (NoSQL) đòi hỏi viết lại toàn bộ data model, queries, indexes → thay đổi ứng dụng lớn. Regional tables cho customer tốt nhưng tổng thể không LEAST changes.

• ✅ Use Aurora with read replicas for the product catalog and additional local Aurora instances in each region for the customer information and purchases.
  Đúng vì: Như giải thích ở trên, tận dụng Aurora Global Database (cross-region replication chỉ cho reads) để catalog global với zero-downtime setup, và local clusters cho compliance. Giữ nguyên Aurora engine, ứng dụng chỉ cần dùng reader endpoints cho catalog reads → thay đổi tối thiểu (chỉ config cluster, không rewrite code).

• ❌ Use Aurora for the product catalog and Amazon DynamoDB global tables for the customer information and purchases.
  Sai vì: Aurora single (không replicas cross-region) không đảm bảo catalog global với low-latency ở châu Âu/Á (latency cao nếu connect về US). DynamoDB global tables replicate customer data cross-region → vi phạm compliance (dữ liệu nhạy cảm bị copy tự động). Kết hợp SQL + NoSQL yêu cầu thay đổi code lớn cho phần customer data.

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

• Aurora Global Database: AWS Documentation - Amazon Aurora Global Database – Hỗ trợ lên đến 16 read replicas cross-region, RPO <1s.
• DynamoDB Global Tables: AWS Documentation - Global Tables – Multi-master replication, không phù hợp read-only.
• Multi-Region Architecture Best Practices: AWS Well-Architected Framework - Reliability Pillar (Operational Excellence cho LEAST changes).
• Exam Prep DOP-C02: AWS Certified DevOps Engineer Professional – Topic: Databases & Storage (Aurora ưu tiên cho relational multi-region).

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần demo CDK/Terraform, hãy hỏi thêm nhé!