CLF-C02 Mock Exam #06 — Solutions & Explanations

Architecture & High Availability | 65 Questions | Theme: HA, scaling, fault tolerance, DR
Solution Format: EN explanation + VN translation | Why wrong answers | Key concept | Knowledge reference

Score Tracker

Your Score: ___/65
Confidence: ___/65
Percentage: ___%
Passing: ≥700/1000 (~70% → 45-46 questions)

By Domain

Domain	Your Score	Total	%
1: Cloud Concepts	__/16	16	__
2: Security & Compliance	__/20	20	__
3: Cloud Tech & Services	__/22	22	__
4: Billing, Pricing, Support	__/7	7	__

Solutions: Domain 1 (Q1–Q16)

Domain 1: Cloud Concepts (Q1–Q16)

Q1.

Which architectural design principle best ensures a system continues to operate when individual components fail?

Bản dịch tiếng Việt: Nguyên tắc thiết kế kiến trúc nào đảm bảo tốt nhất hệ thống tiếp tục hoạt động khi các thành phần riêng lẻ bị lỗi?

A. Tight coupling between all services B. Loose coupling with independent, redundant components C. Centralized single points of failure for efficiency D. Eliminating all backup systems to reduce cost

Correct answer: B Bản dịch đáp án đúng: B. Khớp nối lỏng lẻo với các thành phần độc lập, dự phòng

🇬🇧 Explanation:
Loose coupling is a core Well-Architected principle that prevents single points of failure. When components are loosely coupled (communicate asynchronously via queues/messaging), failure in one component doesn't cascade to others. Tight coupling (Option A) means one failure breaks everything. Single points of failure (Option C) are bad design. Option D ignores reality.

🇻🇳 Giải thích:
Loose coupling là nguyên tắc cốt lõi của Well-Architected. Khi các service giao tiếp không đồng bộ (qua SQS, SNS), lỗi trong một service không lan toả sang service khác. Tight coupling (A) = một lỗi vỡ hết. Single point of failure (C) = thiết kế tệ. Loại trừ backup (D) = nguy hiểm.

❌ Why others are wrong / Vì sao đáp án khác sai:

A (Tight coupling) — creates cascading failures; one component failure breaks entire system / gây lỗi dây chuyền; một component hỏng làm sập cả hệ thống
C (Single points of failure) — violates HA principles; explicit design goal to avoid / vi phạm nguyên tắc HA; là điều cần tránh
D (No backups) — unnecessary cost cutting that increases risk / cắt giảm chi phí không cần thiết, tăng rủi ro

🔑 Key Concept / Khái niệm cốt lõi: Loose coupling via SQS/SNS, redundancy, no SPOF / Loose coupling qua SQS/SNS, dự phòng (redundancy), không có SPOF

Reference: Domain 1 — Well-Architected Reliability Pillar; Domain 3 — SQS/SNS

Q2.

A company wants to scale its application horizontally to handle peak traffic. Which approach is most appropriate?

Bản dịch tiếng Việt: Một công ty muốn mở rộng quy mô ứng dụng của mình theo chiều ngang để xử lý lưu lượng truy cập cao điểm. Cách tiếp cận nào là phù hợp nhất?

A. Replace the existing server with a larger instance type B. Add more instances behind a load balancer to distribute traffic C. Store more data locally on a single server D. Increase the memory allocated to the database

Correct answer: B Bản dịch đáp án đúng: B. Thêm nhiều phiên bản đằng sau bộ cân bằng tải để phân phối lưu lượng

🇬🇧 Explanation:
Horizontal scaling = add more instances (scale out). Vertical scaling = bigger server (scale up). For HA and elasticity, horizontal is standard: add instances behind ALB/NLB, each handles partial load, traffic distributed. Option A is vertical (limited scalability, single SPOF). Options C & D improve single instance but don't scale.

🇻🇳 Giải thích:
Horizontal scaling (scale out) = thêm instance. Vertical scaling (scale up) = instance to lớn hơn. Horizontal là chuẩn: thêm instance phía sau LB, mỗi instance chịu một phần traffic, LB phân phối. A = vertical (giới hạn scalability, SPOF). C, D = tối ưu single server, không scale.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — vertical scaling hits hardware limits; still has SPOF if one bigger instance / vertical scaling chạm giới hạn phần cứng; vẫn là SPOF nếu chỉ một instance lớn
C — storage doesn't scale application compute; adds disk space not processing capacity / storage không scale compute; chỉ thêm dung lượng đĩa, không thêm năng lực xử lý
D — database optimization ≠ application scaling; creates bottleneck / tối ưu database ≠ scale ứng dụng; tạo nút thắt cổ chai

🔑 Key Concept / Khái niệm cốt lõi: Horizontal = add instances + LB | Vertical = bigger server (limited) / Horizontal = thêm instance + LB | Vertical = server lớn hơn (giới hạn)

Reference: Domain 1 — Scalability vs Elasticity | Domain 3 — Auto Scaling, ELB

Q3.

What is the primary difference between High Availability (HA) and Disaster Recovery (DR)?

Bản dịch tiếng Việt: Sự khác biệt chính giữa Tính sẵn sàng cao (HA) và Phục hồi sau thảm họa (DR) là gì?

A. HA minimizes downtime during normal failures; DR recovers from catastrophic events B. HA only applies to databases; DR only applies to applications C. HA is more expensive than DR D. They are interchangeable concepts with no practical difference

Correct answer: A Bản dịch đáp án đúng: A. HA giảm thiểu thời gian ngừng hoạt động khi có sự cố thông thường; DR phục hồi sau các sự kiện thảm khốc

🇬🇧 Explanation:
HA: System stays UP despite component failures (minutes/seconds downtime max). Use redundancy, load balancing across AZs. DR: Plan to RECOVER from catastrophic events (region failure, major data corruption). RTO/RPO measured in hours or days. HA = proactive resilience; DR = reactive recovery. Not same concept (D wrong).

🇻🇳 Giải thích:
HA: Hệ thống SỐNG sót khi component lỗi (tối đa vài phút downtime). Dùng redundancy, LB, multi-AZ. DR: KẾ HOẠCH PHỤC HỒI từ thảm họa toàn vùng (region sập, data bị hỏng lớn). RTO/RPO tính bằng giờ/ngày. HA = tích cực; DR = phản ứng. Không cùng một khái niệm (D sai).

❌ Why others are wrong / Vì sao đáp án khác sai:

B — HA applies to all system types; DR also applies to apps / HA áp dụng cho mọi loại hệ thống; DR cũng áp dụng cho ứng dụng
C — DR can be less expensive than HA if RTO/RPO is lenient / DR có thể rẻ hơn HA nếu RTO/RPO nới lỏng
D — they're complementary but distinct strategies / chúng bổ trợ nhau nhưng là hai chiến lược riêng biệt

🔑 Key Concept / Khái niệm cốt lõi: HA = uptime (minutes) | DR = recovery (hours/days) | RTO/RPO / HA = thời gian sống (phút) | DR = phục hồi (giờ/ngày) | RTO/RPO

Reference: Domain 1 — Architecture principles | Domain 3 — Disaster Recovery strategies

Q4. (Select THREE)

Which of the following are key characteristics of elastic systems in cloud architecture? (Select THREE)

Bản dịch tiếng Việt: Đặc điểm nào sau đây là đặc điểm chính của hệ thống đàn hồi trong kiến trúc đám mây? (Chọn BA)

A. Automatically scale up during high demand B. Automatically scale down when demand decreases C. Require manual intervention to adjust capacity D. Maintain fixed resource allocation regardless of demand E. Reduce costs by paying only for resources actually used

Correct answer: A, B, E Bản dịch đáp án đúng: A. Tự động mở rộng quy mô khi có nhu cầu cao; B. Tự động giảm quy mô khi nhu cầu giảm; E. Giảm chi phí bằng cách chỉ trả tiền cho những tài nguyên thực sự được sử dụng

🇬🇧 Explanation:
Elasticity = auto-scale UP during demand peaks (A) + auto-scale DOWN when demand drops (B) + pay only for what you use (E). Options C & D are NOT elastic; manual intervention (C) and fixed allocation (D) = static capacity, not elastic.

🇻🇳 Giải thích:
Elasticity = auto-scale LÊN khi nhu cầu cao (A) + auto-scale XUỐNG khi nhu cầu giảm (B) + chỉ trả tiền cho tài nguyên dùng (E). C = manual (không elastic). D = cố định (không elastic). Elasticity = co giãn 2 chiều + pay-per-use.

❌ Why others are wrong / Vì sao đáp án khác sai:

C — manual intervention = not automatic scaling = not elastic / can thiệp thủ công = không tự động scale = không elastic
D — fixed allocation = can't adjust = not elastic / cấp phát cố định = không điều chỉnh được = không elastic

🔑 Key Concept / Khái niệm cốt lõi: Elasticity = bi-directional + automatic + pay-per-use / Elasticity = co giãn hai chiều + tự động + trả theo dùng

Reference: Domain 1 — Cloud Computing characteristics (NIST "Rapid Elasticity")

Q5.

A company needs a system that experiences predictable traffic spikes during business hours. Which architectural approach minimizes operational overhead?

Bản dịch tiếng Việt: Một công ty cần một hệ thống có thể dự đoán được lượng truy cập tăng đột biến trong giờ làm việc. Phương pháp kiến trúc nào giảm thiểu chi phí hoạt động?

A. Manually launch new instances each morning and shut them down each evening B. Configure Auto Scaling Group to automatically adjust instance count based on demand C. Purchase Reserved Instances for peak traffic and run them continuously D. Use a single large instance and pay for unused capacity during off-hours

Correct answer: B Bản dịch đáp án đúng: B. Định cấu hình Nhóm tự động chia tỷ lệ để tự động điều chỉnh số lượng phiên bản dựa trên nhu cầu

🇬🇧 Explanation:
Auto Scaling Group (ASG) configured with schedule-based scaling (morning: scale to 50 instances, evening: scale to 5) minimizes overhead. No manual work needed. Option A = manual = high overhead. Option C = pay for peak 24/7 = wasteful. Option D = wrong scale, still manual.

🇻🇳 Giải thích:
Auto Scaling Group với scheduled scaling (sáng: 50 instance, tối: 5 instance) = minimal overhead. Không cần tay chạm. A = manual = overhead cao. C = trả peak cost 24/7 = phí hoá. D = scale sai, vẫn manual.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — manual management = high operational overhead; error-prone / quản lý thủ công = overhead vận hành cao; dễ lỗi
C — wastes money paying for peak capacity during off-hours / lãng phí tiền khi trả cho công suất đỉnh lúc ngoài giờ
D — single large instance = scaling in one direction only; still needs manual scheduling / một instance lớn = chỉ scale một chiều; vẫn cần lên lịch thủ công

🔑 Key Concept / Khái niệm cốt lõi: Auto Scaling Group with schedule-based or metric-based scaling / Auto Scaling Group với scaling theo lịch hoặc theo metric

Reference: Domain 3 — EC2 Auto Scaling | Well-Architected Operational Excellence

Q6.

Which component is most critical for achieving High Availability across multiple Availability Zones?

Bản dịch tiếng Việt: Thành phần nào quan trọng nhất để đạt được High Availability trên nhiều Availability Zone?

A. A single, large compute instance with redundant storage B. Application deployed across multiple AZs with a load balancer distributing traffic C. On-premises backup systems D. A dedicated security appliance between zones

Correct answer: B Bản dịch đáp án đúng: B. Ứng dụng được triển khai trên nhiều AZ với bộ cân bằng tải phân phối lưu lượng

🇬🇧 Explanation:
Load Balancer (ALB/NLB) distributes traffic across EC2 instances in multiple AZs. If one AZ fails, traffic automatically routes to surviving instances in other AZs. Load balancer = HA enabler. Option A = single instance = SPOF. Option C = on-premises = adds latency, doesn't help cloud HA. Option D = security appliance ≠ HA component.

🇻🇳 Giải thích:
Load Balancer phân phối traffic đến EC2 instance ở nhiều AZ. Nếu 1 AZ sập, traffic tự động đi đến AZ còn lại. LB = enabler của HA. A = single instance = SPOF. C = on-premises = lag, không help HA. D = security appliance ≠ HA.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — single large instance = no HA; one failure = total downtime / một instance lớn = không HA; một lỗi = sập toàn bộ
C — on-premises backup doesn't help AWS HA; different infrastructure / backup on-premises không giúp HA trên AWS; hạ tầng khác nhau
D — security appliance = security, not availability / thiết bị bảo mật = bảo mật, không phải availability

🔑 Key Concept / Khái niệm cốt lõi: Load Balancer (ALB/NLB/CLB) + Multi-AZ instances = HA / Load Balancer (ALB/NLB/CLB) + instance Multi-AZ = HA

Reference: Domain 3 — Elastic Load Balancer | Multi-AZ architecture

Q7. (Select TWO)

Which AWS services help implement loose coupling in distributed architectures? (Select TWO)

Bản dịch tiếng Việt: Dịch vụ AWS nào giúp triển khai tính năng ghép nối lỏng lẻo trong kiến trúc phân tán? (Chọn HAI)

A. Amazon SQS (Simple Queue Service) B. Direct EC2-to-EC2 synchronous API calls C. Amazon SNS (Simple Notification Service) D. Tightly integrated monolithic applications E. Single database shared by all services

Correct answer: A, C Bản dịch đáp án đúng: A. Amazon SQS (Dịch vụ xếp hàng đơn giản); C. Amazon SNS (Dịch vụ thông báo đơn giản)

🇬🇧 Explanation:
Amazon SQS (queue) and Amazon SNS (publish-subscribe) enable asynchronous, decoupled communication. Producer sends message to queue; consumer processes independently. Failure in producer doesn't block consumer. Options B, D, E are tight coupling (synchronous APIs, shared database, monolithic design).

🇻🇳 Giải thích:
SQS (queue) và SNS (pub-sub) = giao tiếp không đồng bộ, decoupled. Producer gửi message vào queue; consumer xử lý độc lập. Lỗi producer không block consumer. B, D, E = tight coupling (sync API, shared DB, monolithic).

❌ Why others are wrong / Vì sao đáp án khác sai:

B — direct EC2-to-EC2 calls = synchronous = tight coupling = producer failure blocks consumer / gọi trực tiếp EC2-EC2 = đồng bộ = tight coupling = producer lỗi chặn consumer
D — monolithic = all logic in one process = SPOF / monolithic = mọi logic trong một tiến trình = SPOF
E — shared database = tight coupling via data layer / shared database = tight coupling qua tầng dữ liệu

🔑 Key Concept / Khái niệm cốt lõi: Loose coupling = SQS/SNS for async messaging / Loose coupling = SQS/SNS cho nhắn tin không đồng bộ

Reference: Domain 3 — SQS, SNS | Well-Architected Reliability Pillar

Q8.

What does RTO (Recovery Time Objective) measure in a disaster recovery plan?

Bản dịch tiếng Việt: RTO (Mục tiêu về thời gian phục hồi) đo lường điều gì trong kế hoạch disaster recovery?

A. The maximum amount of data loss acceptable after a failure B. The maximum acceptable downtime before recovery must be complete C. The cost of disaster recovery infrastructure D. The number of backup copies required

Correct answer: B Bản dịch đáp án đúng: B. Thời gian ngừng hoạt động tối đa có thể chấp nhận được trước khi khôi phục phải hoàn tất

🇬🇧 Explanation:
RTO = maximum acceptable downtime (how long system can be offline before business impact is unacceptable). RTO of 4 hours = if disaster happens, system must be back up within 4 hours or business fails. Option A = RPO (data loss tolerance). Option C = cost. Option D = backup count.

🇻🇳 Giải thích:
RTO = tối đa downtime chấp nhận được (hệ thống down bao lâu là khó chịu quá). RTO 4h = nếu thảm họa, phải up trong 4h hoặc business fail. A = RPO. C = cost. D = backup count.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — that's RPO (Recovery Point Objective) = data loss tolerance / đó là RPO = mức chấp nhận mất dữ liệu
C — RTO is time, not cost / RTO là thời gian, không phải chi phí
D — number of backups ≠ recovery time / số lượng backup ≠ thời gian phục hồi

🔑 Key Concept / Khái niệm cốt lõi: RTO = time to recover | RPO = data to recover (in time) / RTO = thời gian phục hồi | RPO = lượng dữ liệu mất (theo thời gian)

Reference: Domain 1 — DR strategies and metrics

Q9.

A website must remain accessible even if an entire AWS Region becomes unavailable. Which architectural pattern is required?

Bản dịch tiếng Việt: Trang web phải vẫn có thể truy cập được ngay cả khi toàn bộ AWS Region không còn khả dụng. Những mô hình kiến trúc nào là bắt buộc?

A. Single-Region deployment with failover within the same AZ B. Multi-Region active-passive deployment with Route 53 failover C. All resources in one Availability Zone for simplified management D. Backup systems running locally on the company's premises

Correct answer: B Bản dịch đáp án đúng: B. Triển khai chủ động-thụ động đa khu vực với chuyển đổi dự phòng Route 53

🇬🇧 Explanation:
Multi-Region deployment with Route 53 failover routing = website stays up even if primary region dies. Route 53 health checks detect region failure, automatically route traffic to secondary region (active-passive). Single region (A, C) = region failure = total downtime. On-premises backup (D) = adds complexity, data sync lag.

🇻🇳 Giải thích:
Multi-Region với Route 53 failover = website sống khi region chính sập. Route 53 health check → detect fail → auto route tới region secondary. Single region (A, C) = sập = total downtime. On-premises (D) = phức tạp, sync lag.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — single-region failover within same region doesn't protect against region failure / failover trong cùng một region không bảo vệ khi cả region sập
C — all in one AZ = if region fails, AZ fails too / tất cả trong một AZ = region sập thì AZ cũng sập
D — on-premises adds latency, sync complexity; doesn't leverage cloud redundancy / on-premises thêm độ trễ, phức tạp đồng bộ; không tận dụng dự phòng cloud

🔑 Key Concept / Khái niệm cốt lõi: Multi-Region + Route 53 health checks + failover routing / Multi-Region + Route 53 health check + định tuyến failover

Reference: Domain 3 — Route 53 | Global architecture

Q10. (Select THREE)

Which of the following design principles improve system reliability according to the Well-Architected Framework's Reliability Pillar? (Select THREE)

Bản dịch tiếng Việt: Nguyên tắc thiết kế nào sau đây cải thiện độ tin cậy của hệ thống theo Trụ cột độ tin cậy của AWS Well-Architected Framework? (Chọn BA)

A. Deploy infrastructure in only one Availability Zone for cost savings B. Implement automatic recovery mechanisms for failed components C. Stop guessing capacity and use metrics to scale automatically D. Manually monitor all systems without automated alerts E. Design systems to withstand component failures without service interruption

Correct answer: B, C, E Bản dịch đáp án đúng: B. Triển khai cơ chế phục hồi tự động cho các thành phần bị lỗi; C. Ngừng đoán công suất và sử dụng số liệu để tự động mở rộng quy mô; E. Thiết kế hệ thống để chống lại các lỗi thành phần mà không bị gián đoạn dịch vụ

🇬🇧 Explanation:
Well-Architected Reliability Pillar pillars: B (auto-recovery) = detect and recover from failures automatically; C (scale dynamically) = don't guess, use metrics to scale; E (withstand failures) = redundancy prevents cascade. Options A & D are anti-patterns: single AZ = no redundancy; manual monitoring = slow, error-prone.

🇻🇳 Giải thích:
Well-Architected Reliability: B (auto-recover) = phát hiện fail tự động. C (scale dynamic) = không đoán, dùng metrics. E (withstand fail) = redundancy = không cascade. A = single AZ = no redundancy. D = manual = slow, error.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — single AZ = if AZ fails, game over; violates redundancy principle / một AZ = AZ sập là hết; vi phạm nguyên tắc dự phòng
D — manual monitoring = slow detection = higher RTO / giám sát thủ công = phát hiện chậm = RTO cao hơn

🔑 Key Concept / Khái niệm cốt lõi: Reliability = auto-recovery + dynamic scaling + withstand failures (redundancy) / Reliability = tự phục hồi + scale động + chịu được lỗi (dự phòng)

Reference: Domain 1 — Well-Architected Framework Reliability Pillar

Q11.

A company wants to decouple a web application from a backend processing system. Which approach is best?

Bản dịch tiếng Việt: Một công ty muốn tách ứng dụng web khỏi hệ thống xử lý phụ trợ. Cách tiếp cận nào là tốt nhất?

A. Connect both systems via a direct synchronous API call B. Use Amazon SQS to queue messages between the web application and backend C. Run both on the same EC2 instance to reduce latency D. Eliminate the backend system and process all requests synchronously

Correct answer: B Bản dịch đáp án đúng: B. Sử dụng Amazon SQS để xếp hàng tin nhắn giữa ứng dụng web và chương trình phụ trợ

🇬🇧 Explanation:
Amazon SQS enables loose coupling: web app sends job to queue, backend polls queue, processes asynchronously. If backend is slow/down, web app still responds (job queued). Synchronous API (A) = if backend fails, web app fails. Same instance (C) = SPOF. No backend (D) = no processing.

🇻🇳 Giải thích:
SQS = loose coupling: web app → queue → backend polls async. Backend slow/down → web app vẫn respond (job queue lại). Sync API (A) = backend fail → web fail. Same instance (C) = SPOF. No backend (D) = fail.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — synchronous = tight coupling = backend failure blocks web app / đồng bộ = tight coupling = backend lỗi chặn web app
C — same instance = SPOF and single resource for both workloads / cùng instance = SPOF và một tài nguyên cho cả hai workload
D — eliminates entire backend functionality / loại bỏ toàn bộ chức năng backend

🔑 Key Concept / Khái niệm cốt lõi: SQS for decoupling = async, fault-tolerant / SQS để decouple = bất đồng bộ, chịu lỗi

Reference: Domain 3 — SQS | Domain 1 — Loose coupling principle

Q12.

What is the primary benefit of Multi-AZ deployment for RDS (Relational Database Service)?

Bản dịch tiếng Việt: Lợi ích chính của việc triển khai Multi-AZ cho RDS (Dịch vụ cơ sở dữ liệu quan hệ) là gì?

A. Increased read throughput and query performance B. Automatic failover to a standby database if the primary fails C. Reduced licensing costs for database software D. Ability to run applications across multiple Regions

Correct answer: B Bản dịch đáp án đúng: B. Tự động chuyển đổi dự phòng sang cơ sở dữ liệu dự phòng nếu lỗi chính

🇬🇧 Explanation:
RDS Multi-AZ = primary database + synchronous standby in different AZ. If primary fails (hardware, AZ failure), AWS automatically fails over to standby (minutes, not manual). Standby isn't accessible for reads during normal operation (standby is "hot" but not active). Option A = Read Replicas (different feature, async). C = not cost savings. D = different use case (multi-region).

🇻🇳 Giải thích:
RDS Multi-AZ = primary DB + sync standby ở AZ khác. Primary fail → AWS tự auto-failover to standby (phút, không manual). Standby không dùng cho reads (chỉ là hot backup). A = Read Replicas (feature khác, async). C = không rẻ. D = multi-region (khác).

❌ Why others are wrong / Vì sao đáp án khác sai:

A — Read Replicas ≠ HA; async, can lag, doesn't auto-failover / Read Replicas ≠ HA; bất đồng bộ, có thể trễ, không tự failover
C — Multi-AZ slightly increases cost (two instances) for HA, not reduces it / Multi-AZ tăng nhẹ chi phí (hai instance) cho HA, không giảm
D — Multi-AZ = same region; multi-region = different regions / Multi-AZ = cùng region; multi-region = khác region

🔑 Key Concept / Khái niệm cốt lõi: Multi-AZ = HA via sync standby + auto-failover | Read Replicas = scaling reads / Multi-AZ = HA qua standby đồng bộ + tự failover | Read Replicas = scale đọc

Reference: Domain 3 — RDS Multi-AZ vs Read Replicas

Q13. (Select THREE)

Which architectural improvements help reduce the Recovery Point Objective (RPO) in a disaster recovery scenario? (Select THREE)

Bản dịch tiếng Việt: Những cải tiến kiến trúc nào giúp giảm Mục tiêu điểm khôi phục (RPO) trong kịch bản disaster recovery? (Chọn BA)

A. Increasing backup frequency B. Storing backups only once per month C. Using real-time replication to a secondary location D. Deleting old backups to save storage costs E. Implementing continuous data synchronization

Correct answer: A, C, E Bản dịch đáp án đúng: A. Tăng tần suất dự phòng; C. Sử dụng sao chép thời gian thực đến vị trí phụ; E. Thực hiện đồng bộ hóa dữ liệu liên tục

🇬🇧 Explanation:
RPO = acceptable data loss (point in time to recover to). Lower RPO = less data lost = more frequent backups or real-time replication. A (more backups) = lower RPO (hourly vs daily). C (real-time replication) = RPO near zero. E (continuous sync) = RPO near zero. Options B & D increase data loss (bad for RPO).

🇻🇳 Giải thích:
RPO = chịu được mất bao nhiêu data (đến thời điểm nào). Lower RPO = mất ít = backup/replicate thường xuyên. A = frequent backup = low RPO. C = real-time replicate = RPO ≈ zero. E = continuous sync = RPO ≈ zero. B, D = lose more data (bad).

❌ Why others are wrong / Vì sao đáp án khác sai:

B — less frequent backups = larger data loss = higher RPO / backup thưa hơn = mất nhiều dữ liệu hơn = RPO cao hơn
D — deleting backups = can't recover lost data = higher RPO / xóa backup = không phục hồi được dữ liệu = RPO cao hơn

🔑 Key Concept / Khái niệm cốt lõi: RPO = data loss tolerance | Lower RPO = frequent backups + real-time replication / RPO = mức chấp nhận mất dữ liệu | RPO thấp = backup thường xuyên + replicate thời gian thực

Reference: Domain 1 — DR strategies (RTO/RPO)

Q14.

A startup experiences variable traffic throughout the day. Which cost-effective scaling approach minimizes idle resource waste?

Bản dịch tiếng Việt: Một công ty khởi nghiệp trải nghiệm lưu lượng truy cập thay đổi trong suốt cả ngày. Phương pháp mở rộng quy mô hiệu quả về mặt chi phí nào giúp giảm thiểu lãng phí tài nguyên nhàn rỗi?

A. Always run 50 instances to handle peak load B. Configure Auto Scaling based on CPU utilization metrics C. Manually adjust instance count based on gut feeling D. Run instances only during business hours and power them off at night

Correct answer: B Bản dịch đáp án đúng: B. Định cấu hình Auto Scaling dựa trên số liệu sử dụng CPU

🇬🇧 Explanation:
Auto Scaling with metric-based policies (CPU %, request count, custom metrics) = instances scale up when load increases, scale down when load drops. Pay only for instances in use. Option A = wasteful (always 50). Option C = manual = slow/errors. Option D = misses off-hours (but what about 8am spike?). B is most automatic + cost-effective.

🇻🇳 Giải thích:
Auto Scaling based on metrics = instance tăng khi load cao, giảm khi load thấp. Trả đúng dùng. A = waste (always 50). C = manual = slow. D = schedule chỉ handle off-hours, không handle daytime spikes. B = auto + efficient.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — always 50 instances = paying for idle capacity during low-traffic periods / luôn 50 instance = trả cho công suất nhàn rỗi lúc ít traffic
C — manual = slow response, human error, not cost-effective / thủ công = phản ứng chậm, lỗi con người, không tối ưu chi phí
D — schedule-based helps off-hours but misses unpredictable daytime spikes / theo lịch giúp lúc ngoài giờ nhưng bỏ lỡ các đợt tăng đột biến ban ngày

🔑 Key Concept / Khái niệm cốt lõi: Metric-based Auto Scaling = pay-per-use + elasticity / Auto Scaling theo metric = trả theo dùng + elasticity

Reference: Domain 3 — EC2 Auto Scaling | Domain 1 — Elasticity

Q15.

Which AWS service enables automatic distribution of traffic across multiple EC2 instances to ensure High Availability?

Bản dịch tiếng Việt: Dịch vụ AWS nào cho phép tự động phân phối lưu lượng trên nhiều phiên bản EC2 để đảm bảo Tính sẵn sàng cao?

A. AWS CloudFormation B. Amazon CloudWatch C. Elastic Load Balancer (ALB/NLB) D. AWS Identity and Access Management (IAM)

Correct answer: C Bản dịch đáp án đúng: C. Elastic Load Balancing (ALB/NLB)

🇬🇧 Explanation:
Elastic Load Balancer (ALB, NLB, CLB) distributes incoming traffic across multiple EC2 instances. If one instance fails, ELB routes traffic to remaining instances (auto-recovery). CloudFormation (A) = template tool. CloudWatch (B) = monitoring. IAM (D) = access control. ELB = the HA enabler.

🇻🇳 Giải thích:
Elastic Load Balancer phân phối traffic vào nhiều EC2 instance. 1 instance fail → LB route tới instance còn lại (auto-recover). CloudFormation (A) = template. CloudWatch (B) = monitor. IAM (D) = access. ELB = HA enabler.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — CloudFormation = IaC tool, doesn't distribute traffic / CloudFormation = công cụ IaC, không phân phối traffic
B — CloudWatch = monitoring/logging, doesn't balance traffic / CloudWatch = giám sát/logging, không cân bằng traffic
D — IAM = identity management, doesn't balance traffic / IAM = quản lý danh tính, không cân bằng traffic

🔑 Key Concept / Khái niệm cốt lõi: ELB (ALB/NLB/CLB) for traffic distribution + HA / ELB (ALB/NLB/CLB) để phân phối traffic + HA

Reference: Domain 3 — Elastic Load Balancer

Q16. (Select THREE)

For a web application requiring 99.99% availability, which architectural components are essential? (Select THREE)

Bản dịch tiếng Việt: Đối với một ứng dụng web yêu cầu độ sẵn sàng 99,99%, thành phần kiến trúc nào là cần thiết? (Chọn BA)

A. Multi-AZ load balancer distributing traffic B. Auto Scaling Group for automatic capacity adjustment C. Single point of failure in the architecture D. Synchronous replication across multiple Regions E. Redundant instances in different Availability Zones

Correct answer: A, B, E Bản dịch đáp án đúng: A. Load balancer Multi-AZ phân phối lưu lượng truy cập; B. Nhóm Auto Scaling để điều chỉnh công suất tự động; E. Các phiên bản dự phòng ở nhiều Availability Zone khác nhau

🇬🇧 Explanation:
99.99% availability = "four nines" = ~52 minutes downtime/year. Requires redundancy + auto-scaling. A (Multi-AZ LB) = handles AZ failure. B (ASG) = auto-scale + replace failed instances. E (redundant instances multi-AZ) = no SPOF. Options C & D violate HA: single point of failure (C) and sync replication across regions (D) is more DR-focused; for 99.99% within region, multi-AZ suffices.

🇻🇳 Giải thích:
99.99% = "four nines" = ~52 phút down/năm. Cần redundancy + auto-scale. A = handle AZ fail. B = auto-scale. E = no SPOF. C = SPOF (bad). D = sync multi-region (overkill, more for 99.999%).

❌ Why others are wrong / Vì sao đáp án khác sai:

C — single point of failure = violates HA principle / điểm lỗi đơn = vi phạm nguyên tắc HA
D — synchronous multi-region replication = overkill for 99.99%; introduces latency; more for 99.999%+ / replicate đồng bộ multi-region = thừa cho 99.99%; thêm độ trễ; phù hợp cho 99.999%+

🔑 Key Concept / Khái niệm cốt lõi: 99.99% HA = Multi-AZ + LB + ASG + redundancy / 99.99% HA = Multi-AZ + LB + ASG + dự phòng

Reference: Domain 1 — HA design principles

Domain 2: Security & Compliance (Q17–Q36)

Q17.

A company must ensure continuous monitoring of API calls and user actions for compliance purposes. Which service provides comprehensive audit logs?

Bản dịch tiếng Việt: Công ty phải đảm bảo giám sát liên tục các lệnh gọi API và hành động của người dùng vì mục đích tuân thủ. Dịch vụ nào cung cấp nhật ký kiểm tra toàn diện?

A. AWS CloudWatch B. AWS CloudTrail C. AWS Config D. AWS GuardDuty

Correct answer: B Bản dịch đáp án đúng: B. Đường mòn đám mây AWS

🇬🇧 Explanation:
AWS CloudTrail logs ALL API calls (who did what, when, from where). Essential for compliance auditing. CloudWatch (A) = metrics/logs from applications. AWS Config (C) = resource configuration changes. GuardDuty (D) = threat detection. CloudTrail = "who, what, when" audit log.

🇻🇳 Giải thích:
CloudTrail log TẤT CẢ API calls (ai, gì, khi nào, từ đâu). Bắt buộc compliance audit. CloudWatch (A) = metrics. Config (C) = resource config changes. GuardDuty (D) = threat. CloudTrail = "who, what, when".

❌ Why others are wrong / Vì sao đáp án khác sai:

A — CloudWatch = application metrics/logs, not API audit / CloudWatch = metrics/log ứng dụng, không phải audit API
C — AWS Config = resource configuration state, not API calls / AWS Config = trạng thái cấu hình tài nguyên, không phải API calls
D — GuardDuty = threat detection, not audit logging / GuardDuty = phát hiện mối đe dọa, không phải audit log

🔑 Key Concept / Khái niệm cốt lõi: CloudTrail = comprehensive API audit log / CloudTrail = nhật ký audit API toàn diện

Reference: Domain 2 — CloudTrail | Compliance requirements

Q18. (Select TWO)

Which of the following support High Availability and reliability in cloud infrastructure? (Select TWO)

Bản dịch tiếng Việt: Điều nào sau đây hỗ trợ Tính sẵn sàng cao và độ tin cậy trong cơ sở hạ tầng đám mây? (Chọn HAI)

A. Restricting network access to single data center B. Implementing redundant systems across multiple AZs C. Centralizing all data in one location D. Using automated failover mechanisms E. Requiring manual intervention for all system changes

Correct answer: B, D Bản dịch đáp án đúng: B. Triển khai các hệ thống dự phòng trên nhiều AZ; D. Sử dụng cơ chế chuyển đổi dự phòng tự động

🇬🇧 Explanation:
B (redundant across AZs) = if one AZ fails, others are up = HA. D (automated failover) = auto-recovery from failures = higher availability. Options A, C, E undermine HA: single datacenter (A) = SPOF. Single location (C) = no redundancy. Manual intervention (E) = slow, error-prone.

🇻🇳 Giải thích:
B (redundant AZ) = 1 AZ fail → còn lại up = HA. D (auto failover) = auto-recover = higher uptime. A = single = SPOF. C = một location = no redundancy. E = manual = slow.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — restricting to single datacenter = removes redundancy = lower HA / giới hạn một datacenter = mất dự phòng = HA thấp hơn
C — single location = all eggs one basket = no failover = lower HA / một vị trí = bỏ hết trứng vào một giỏ = không failover = HA thấp hơn
E — manual intervention = slower recovery time = higher downtime / can thiệp thủ công = phục hồi chậm hơn = downtime cao hơn

🔑 Key Concept / Khái niệm cốt lõi: HA requires redundancy + automated failover / HA cần dự phòng + failover tự động

Reference: Domain 1 — HA design principles

Q19.

An organization wants to implement least privilege access to its resources. Which approach is most secure?

Bản dịch tiếng Việt: Một tổ chức muốn triển khai quyền truy cập đặc quyền tối thiểu vào tài nguyên của mình. Cách tiếp cận nào là an toàn nhất?

A. Grant all users full access to all resources B. Create IAM roles with minimal permissions required for specific tasks C. Use a single shared password for all user accounts D. Disable security group restrictions for operational convenience

Correct answer: B Bản dịch đáp án đúng: B. Tạo vai trò IAM với quyền tối thiểu cần thiết cho các tác vụ cụ thể

🇬🇧 Explanation:
Least privilege = grant minimum permissions needed to do job. Option B: create IAM roles with minimal permissions (e.g., S3ReadOnly for a role that only reads S3, not all of AWS). Option A = too permissive. Options C & D = insecure (shared passwords, open security groups).

🇻🇳 Giải thích:
Least privilege = cấp quyền tối thiểu cần thiết. B: IAM role với minimal permission (e.g., S3ReadOnly). A = quá permissive. C, D = insecure (shared password, open SG).

❌ Why others are wrong / Vì sao đáp án khác sai:

A — full access = too permissive = violates least privilege / full access = quá rộng = vi phạm least privilege
C — shared password = no accountability, no audit trail / mật khẩu dùng chung = không truy vết trách nhiệm, không có audit trail
D — open security groups = allows all traffic = defeats security / security group mở = cho mọi traffic = phá vỡ bảo mật

🔑 Key Concept / Khái niệm cốt lõi: Least privilege via IAM roles with minimal permissions / Least privilege qua IAM role với quyền tối thiểu

Reference: Domain 2 — IAM | Security best practices

Q20.

Which AWS service can automatically detect anomalous behavior and potential security threats across your account?

Bản dịch tiếng Việt: Dịch vụ AWS nào có thể tự động phát hiện hành vi bất thường và các mối đe dọa bảo mật tiềm ẩn trên tài khoản của bạn?

A. AWS Shield B. AWS GuardDuty C. AWS WAF D. AWS KMS

Correct answer: B Bản dịch đáp án đúng: B. Nhiệm vụ bảo vệ AWS

🇬🇧 Explanation:
AWS GuardDuty uses machine learning to analyze CloudTrail logs, VPC Flow Logs, DNS logs → detect threats (unauthorized access attempts, instances mining crypto, etc.). AWS Shield (A) = DDoS protection. AWS WAF (C) = web app firewall. KMS (D) = encryption key management. GuardDuty = threat detection.

🇻🇳 Giải thích:
GuardDuty dùng ML phân tích CloudTrail, VPC Flow Logs, DNS → detect threat (unauthorized access, crypto mining, v.v.). Shield (A) = DDoS. WAF (C) = web firewall. KMS (D) = key mgmt. GuardDuty = threat detect.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — Shield = DDoS protection, not anomaly detection / Shield = chống DDoS, không phát hiện bất thường
C — WAF = web app attacks (SQL injection, XSS), not account-wide threats / WAF = tấn công web app (SQL injection, XSS), không phải mối đe dọa toàn account
D — KMS = encryption keys, not threat detection / KMS = khóa mã hóa, không phát hiện mối đe dọa

🔑 Key Concept / Khái niệm cốt lõi: GuardDuty = ML-based threat detection / GuardDuty = phát hiện mối đe dọa dựa trên ML

Reference: Domain 2 — GuardDuty | Security services

Q21. (Select TWO)

For critical production applications, which security practices are recommended? (Select TWO)

Bản dịch tiếng Việt: Đối với các ứng dụng sản xuất quan trọng, biện pháp bảo mật nào được khuyến nghị? (Chọn HAI)

A. Enable MFA on root account B. Use shared passwords across team members C. Implement resource-level encryption D. Disable automated security patching E. Store access keys in environment variables

Correct answer: A, C Bản dịch đáp án đúng: A. Kích hoạt MFA trên tài khoản root; C. Triển khai mã hóa cấp tài nguyên

🇬🇧 Explanation:
A (MFA on root) = root account is most powerful, must protect with MFA (hardware or virtual). C (resource-level encryption) = encrypt data at rest and in transit, essential for sensitive data. Options B (shared passwords) = no accountability. D (no patching) = leaves vulnerabilities. E (access keys in env vars) = keys can be logged/exposed.

🇻🇳 Giải thích:
A (MFA root) = root mạnh nhất, bắt buộc MFA. C (encrypt) = data at rest/transit, bắt buộc. B = shared password = no audit. D = no patch = vulnerable. E = keys in env = logged/exposed risk.

❌ Why others are wrong / Vì sao đáp án khác sai:

B — shared passwords = no accountability, violates principle of least privilege / mật khẩu dùng chung = không truy vết trách nhiệm, vi phạm least privilege
D — no patching = known vulnerabilities = security risk / không vá lỗi = lỗ hổng đã biết = rủi ro bảo mật
E — access keys in environment variables = can be logged/exposed; use IAM roles instead / access key trong biến môi trường = có thể bị log/lộ; nên dùng IAM role

🔑 Key Concept / Khái niệm cốt lõi: MFA + encryption + no shared credentials / MFA + mã hóa + không dùng chung thông tin xác thực

Reference: Domain 2 — IAM | Security best practices

Q22.

A database contains sensitive customer information. Which encryption approach provides protection even if storage devices are physically accessed?

Bản dịch tiếng Việt: Cơ sở dữ liệu chứa thông tin khách hàng nhạy cảm. Phương pháp mã hóa nào cung cấp sự bảo vệ ngay cả khi các thiết bị lưu trữ được truy cập vật lý?

A. No encryption needed if the database is in a private VPC B. Encryption at rest using AWS KMS C. Encryption only for data in transit D. Password protection on the database user account

Correct answer: B Bản dịch đáp án đúng: B. Mã hóa ở trạng thái lưu trữ bằng AWS KMS

🇬🇧 Explanation:
Encryption at rest (AWS KMS) = data on disk is encrypted. Even if someone steals the hard drive, data is unreadable without decryption keys (stored separately in KMS). Option A (no encryption in VPC) = data plaintext if disk accessed. C (only in transit) = leaves data at rest vulnerable. D (password only) = weak, doesn't encrypt data.

🇻🇳 Giải thích:
Encryption at rest (KMS) = data on disk encrypted. Nếu ai steal disk, data vẫn unreadable (key ở KMS riêng). A = no protection. C = only in transit = at rest vulnerable. D = password weak.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — VPC isolation ≠ protection against physical device theft / cô lập VPC ≠ bảo vệ khi thiết bị bị đánh cắp vật lý
C — encryption in transit only = data at rest is plaintext / chỉ mã hóa khi truyền = dữ liệu lưu trữ vẫn là plaintext
D — password protection ≠ encryption; weak against disk forensics / bảo vệ bằng mật khẩu ≠ mã hóa; yếu trước disk forensics

🔑 Key Concept / Khái niệm cốt lõi: Encryption at rest using AWS KMS for physical security / Mã hóa khi lưu trữ bằng AWS KMS cho an toàn vật lý

Reference: Domain 2 — KMS | Data protection

Q23.

Which service helps prevent unauthorized traffic from reaching your application by filtering DDoS attacks at the AWS network edge?

Bản dịch tiếng Việt: Dịch vụ nào giúp ngăn chặn lưu lượng truy cập trái phép tiếp cận ứng dụng của bạn bằng cách lọc các cuộc tấn công DDoS ở biên mạng AWS?

A. Security Group B. Network ACL C. AWS Shield Standard D. VPC Endpoint

Correct answer: C Bản dịch đáp án đúng: C. Tiêu chuẩn lá chắn AWS

🇬🇧 Explanation:
AWS Shield Standard (free) provides automatic DDoS protection at AWS edge locations (before traffic reaches your resources). Shield Standard protects against Layer 3-4 attacks. Option A (SG) = instance-level firewall (stateful). B (NACL) = subnet-level firewall (stateless). D (VPC Endpoint) = private access to AWS services, not DDoS. Shield Standard = edge filtering.

🇻🇳 Giải thích:
Shield Standard (free) = auto DDoS protection tại AWS edge (trước reach resource). Protect layer 3-4. A (SG) = instance firewall. B (NACL) = subnet firewall. D = private access, not DDoS. Shield = edge filter.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — Security Group = instance-level firewall, not network-edge DDoS filtering / Security Group = firewall mức instance, không lọc DDoS tại edge
B — NACL = subnet-level firewall, not edge-level / NACL = firewall mức subnet, không phải mức edge
D — VPC Endpoint = private service access, doesn't protect against DDoS / VPC Endpoint = truy cập service riêng tư, không chống DDoS

🔑 Key Concept / Khái niệm cốt lõi: Shield Standard for edge DDoS filtering | Shield Advanced for more protection / Shield Standard lọc DDoS tại edge | Shield Advanced bảo vệ nhiều hơn

Reference: Domain 2 — Shield | DDoS protection

Q24. (Select THREE)

Which components of shared responsibility fall under the customer's control in AWS? (Select THREE)

Bản dịch tiếng Việt: Những thành phần trách nhiệm chung nào thuộc quyền kiểm soát của khách hàng trong AWS? (Chọn BA)

A. Physical datacenter security B. Operating system patches for EC2 instances C. Network firewalling (Security Groups) D. AWS hypervisor security E. Encryption of application data

Correct answer: B, C, E Bản dịch đáp án đúng: B. Bản vá hệ điều hành cho phiên bản EC2; C. Tường lửa mạng (Nhóm bảo mật); E. Mã hóa dữ liệu ứng dụng

🇬🇧 Explanation:
Shared Responsibility Model: AWS controls physical (datacenters, hardware, hypervisor). Customer controls: B (OS patches) for EC2 (AWS patches RDS DB engine). C (Security Groups) = firewall rules. E (data encryption) = customer encrypts before storing. Options A & D are AWS responsibility.

🇻🇳 Giải thích:
Shared Responsibility: AWS = physical infrastructure. Customer: B (patch OS) for EC2 (RDS AWS patches). C (SG) = firewall rules. E (encrypt data) = bạn encrypt. A, D = AWS job.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — physical datacenter security = AWS responsibility / an ninh datacenter vật lý = trách nhiệm của AWS
D — hypervisor security = AWS responsibility / bảo mật hypervisor = trách nhiệm của AWS

🔑 Key Concept / Khái niệm cốt lõi: Shared Responsibility: AWS = "Security OF Cloud" (infrastructure) | Customer = "Security IN Cloud" (data, OS, encryption) / Shared Responsibility: AWS lo "Security OF Cloud" (hạ tầng) | Khách hàng lo "Security IN Cloud" (data, OS, mã hóa)

Reference: Domain 1 — Shared Responsibility Model

Q25.

A developer must store API credentials for accessing AWS services from an application. What is the most secure approach?

Bản dịch tiếng Việt: Nhà phát triển phải lưu trữ thông tin xác thực API để truy cập các dịch vụ AWS từ một ứng dụng. Cách tiếp cận an toàn nhất là gì?

A. Hard-code credentials in the application source code B. Store credentials in environment variables or AWS Secrets Manager C. Write credentials in comments within the code D. Use the root AWS account credentials for all access

Correct answer: B Bản dịch đáp án đúng: B. Lưu trữ thông tin xác thực trong các biến môi trường hoặc AWS Secrets Manager

🇬🇧 Explanation:
AWS Secrets Manager or IAM roles = credentials managed centrally, rotated automatically, never in code. Environment variables (B) = safer than hardcoding but should be read from a secrets service, not hardcoded. Options A, C, D = terrible (hardcoded in source/comments = exposed in git, root credentials = too permissive).

🇻🇳 Giải thích:
Secrets Manager hoặc IAM role = credentials managed central, auto-rotate, không in code. Env var (B) = safer than hardcode nhưng nên từ secrets service. A, C, D = terrible (hardcode = expose in git, root = too permissive).

❌ Why others are wrong / Vì sao đáp án khác sai:

A — hardcoded credentials = exposed in source control = security breach / hardcode credentials = lộ trong source control = vi phạm bảo mật
C — credentials in comments = accidentally exposed = security breach / credentials trong comment = vô tình bị lộ = vi phạm bảo mật
D — root credentials = too permissive = violates least privilege / credentials root = quá nhiều quyền = vi phạm least privilege

🔑 Key Concept / Khái niệm cốt lõi: Use IAM roles or AWS Secrets Manager, never hardcode / Dùng IAM role hoặc AWS Secrets Manager, không bao giờ hardcode

Reference: Domain 2 — IAM | Secrets management

Q26.

Which AWS service provides a centralized platform to monitor and remediate security findings across multiple AWS services?

Bản dịch tiếng Việt: Dịch vụ AWS nào cung cấp nền tảng tập trung để giám sát và khắc phục các phát hiện bảo mật trên nhiều dịch vụ AWS?

A. AWS CloudWatch B. AWS Security Hub C. AWS Trusted Advisor D. AWS Config

Correct answer: B Bản dịch đáp án đúng: B. Trung tâm bảo mật AWS

🇬🇧 Explanation:
AWS Security Hub = central dashboard aggregating findings from GuardDuty, Inspector, Macie, CloudTrail, Config → single pane of glass for security. CloudWatch (A) = metrics/logs. Trusted Advisor (C) = best practice checks. Config (D) = config changes. Security Hub = central security findings.

🇻🇳 Giải thích:
Security Hub = central dashboard aggregating findings từ GuardDuty, Inspector, Macie, CloudTrail, Config. CloudWatch (A) = metrics. Trusted Advisor (C) = best practice. Config (D) = config changes. Security Hub = central.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — CloudWatch = metrics/logging, not security findings aggregation / CloudWatch = metrics/logging, không tổng hợp security findings
C — Trusted Advisor = best practices, not security threat findings / Trusted Advisor = best practice, không phải security findings
D — Config = configuration tracking, not security threat aggregation / Config = theo dõi cấu hình, không tổng hợp mối đe dọa

🔑 Key Concept / Khái niệm cốt lõi: Security Hub for centralized security findings / Security Hub để tập trung các security findings

Reference: Domain 2 — Security Hub | Security services

Q27. (Select TWO)

Which architectural patterns help achieve both compliance and high availability? (Select TWO)

Bản dịch tiếng Việt: Những mẫu kiến trúc nào giúp đạt được cả tính tuân thủ và tính sẵn sàng cao? (Chọn HAI)

A. Running all resources in a single Availability Zone B. Implementing multi-AZ redundancy C. Centralizing data without backups D. Regular automated backups to geographically separated locations E. Disabling encryption to improve performance

Correct answer: B, D Bản dịch đáp án đúng: B. Triển khai dự phòng đa AZ; D. Sao lưu tự động thường xuyên đến các vị trí cách nhau về mặt địa lý

🇬🇧 Explanation:
B (multi-AZ redundancy) = meets HA requirement + meets compliance uptime SLAs. D (automated backups to geographically separated locations) = meets both compliance (audit trail, recovery) and DR/HA (backup restores service). Options A, C, E violate both.

🇻🇳 Giải thích:
B (multi-AZ) = HA requirement + compliance uptime. D (geo-backup) = compliance (audit) + DR/HA (recover). A, C, E = violate.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — single AZ = fails HA requirement / một AZ = không đạt yêu cầu HA
C — no backups = fails compliance requirement + disaster recovery / không backup = không đạt compliance + DR
E — no encryption = fails compliance; no recovery = fails HA / không mã hóa = không đạt compliance; không phục hồi = không đạt HA

🔑 Key Concept / Khái niệm cốt lõi: Multi-AZ + geo-redundant backups for compliance + HA / Multi-AZ + backup dự phòng địa lý cho compliance + HA

Reference: Domain 1 — HA | Domain 2 — Compliance

Q28.

A company's security policy requires immediate detection of unauthorized API calls. Which service should be prioritized?

Bản dịch tiếng Việt: Chính sách bảo mật của công ty yêu cầu phát hiện ngay các lệnh gọi API trái phép. Dịch vụ nào nên được ưu tiên?

A. AWS CloudFormation B. AWS CloudTrail C. Amazon S3 versioning D. AWS RDS automated backups

Correct answer: B Bản dịch đáp án đúng: B. Đường mòn đám mây AWS

🇬🇧 Explanation:
AWS CloudTrail logs all API calls in real-time (or within minutes) → detect unauthorized access immediately. CloudFormation (A) = IaC, doesn't detect unauthorized calls. S3 versioning (C) = object history, not API audit. RDS backups (D) = data protection, not API audit. CloudTrail = immediate API detection.

🇻🇳 Giải thích:
CloudTrail log API calls real-time → detect unauthorized ngay. CloudFormation (A) = IaC. S3 version (C) = object history. RDS backup (D) = data protection. CloudTrail = API detect.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — CloudFormation = deployment tool, not API monitoring / CloudFormation = công cụ triển khai, không giám sát API
C — S3 versioning = object version control, not API audit / S3 versioning = quản lý phiên bản object, không phải audit API
D — RDS backups = data protection, not API audit / RDS backup = bảo vệ dữ liệu, không phải audit API

🔑 Key Concept / Khái niệm cốt lõi: CloudTrail for real-time API audit logging / CloudTrail để audit API log thời gian thực

Reference: Domain 2 — CloudTrail | Compliance

Q29.

Which authentication mechanism provides the strongest additional layer of security for AWS account login?

Bản dịch tiếng Việt: Cơ chế xác thực nào cung cấp lớp bảo mật bổ sung mạnh nhất cho việc đăng nhập tài khoản AWS?

A. Using longer passwords B. Multi-Factor Authentication (MFA) C. Storing credentials in plain text D. Using the same password across multiple accounts

Correct answer: B Bản dịch đáp án đúng: B. Xác thực đa yếu tố (MFA)

🇬🇧 Explanation:
Multi-Factor Authentication (MFA) = password + second factor (hardware token, phone app, SMS). Even if password leaked, attacker needs physical device. Options A, C, D = weaker (longer password, plaintext, same password = no 2FA).

🇻🇳 Giải thích:
MFA = password + second factor (hardware token, phone app, SMS). Leak password = attacker vẫn cần device. A = longer password (weaker). C = plaintext (insecure). D = same password = no 2FA.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — longer password = still 1-factor; MFA adds 2nd factor / mật khẩu dài hơn = vẫn 1 yếu tố; MFA thêm yếu tố thứ 2
C — plaintext credentials = completely insecure / credentials plaintext = hoàn toàn không an toàn
D — same password across accounts = if one breached, all breached / dùng cùng mật khẩu cho mọi account = một cái bị lộ là lộ hết

🔑 Key Concept / Khái niệm cốt lõi: MFA (TOTP, hardware key, SMS) for 2-factor authentication / MFA (TOTP, hardware key, SMS) cho xác thực 2 lớp

Reference: Domain 2 — IAM | MFA

Q30. (Select THREE)

For a multi-tier application spanning multiple Availability Zones, which security layers are important? (Select THREE)

Bản dịch tiếng Việt: Đối với một ứng dụng nhiều tầng trải rộng trên nhiều Availability Zone, lớp bảo mật nào là quan trọng? (Chọn BA)

A. Security Groups for stateful firewall rules at instance level B. Network ACLs for stateless filtering at subnet level C. Relying only on perimeter security with no internal controls D. Encryption at rest for all data storage E. Public access to database servers for ease of management

Correct answer: A, B, D Bản dịch đáp án đúng: A. Nhóm bảo mật cho các quy tắc tường lửa có trạng thái ở cấp phiên bản; B. ACL mạng để lọc không trạng thái ở cấp mạng con; D. Mã hóa ở phần còn lại cho tất cả lưu trữ dữ liệu

🇬🇧 Explanation:
A (Security Groups) = stateful firewall per instance (allow specific ports/IPs). B (NACLs) = stateless firewall per subnet (deny malicious traffic before reaching instances). D (encryption at rest) = protects if disks stolen. Options C & E are anti-patterns: no internal controls (C) = if perimeter breached, all exposed. Public DB (E) = unnecessary exposure.

🇻🇳 Giải thích:
A (SG) = stateful firewall per instance. B (NACL) = stateless per subnet. D (encrypt) = protect if disk stolen. C = no internal control = bad. E = public DB = unnecessary expose.

❌ Why others are wrong / Vì sao đáp án khác sai:

C — only perimeter security = defense in depth violated = if perimeter breached, internal exposed / chỉ bảo mật vành đai = vi phạm defense in depth = vỡ vành đai là lộ nội bộ
E — public database = unnecessary exposure; should be private / database public = phơi bày không cần thiết; nên để private

🔑 Key Concept / Khái niệm cốt lõi: Defense in depth: SG + NACL + encryption + private database / Defense in depth: SG + NACL + mã hóa + database private

Reference: Domain 2 — Security Groups, NACLs | Security best practices

Q31.

What is the primary purpose of AWS Config in a security and compliance context?

Bản dịch tiếng Việt: Mục đích chính của AWS Config trong bối cảnh bảo mật và tuân thủ là gì?

A. To encrypt all data at rest B. To track configuration changes of AWS resources for compliance auditing C. To prevent DDoS attacks D. To manage user identity and access

Correct answer: B Bản dịch đáp án đúng: B. Để theo dõi các thay đổi cấu hình của tài nguyên AWS để kiểm tra tuân thủ

🇬🇧 Explanation:
AWS Config tracks configuration state of AWS resources (e.g., "SG allows port 22?", "S3 bucket is public?") + detects drift from desired config → compliance auditing. CloudTrail (different) = API audit log. Encryption (C) = different service. User management (D) = different service. Config = configuration compliance tracking.

🇻🇳 Giải thích:
Config track resource config (SG allow port 22? S3 public?) + detect drift → compliance audit. CloudTrail = API log. Encrypt (C) = khác service. User mgmt (D) = khác. Config = config compliance.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — that's CloudTrail / đó là CloudTrail
C — KMS does encryption, not Config / KMS lo mã hóa, không phải Config
D — IAM manages users, not Config / IAM quản lý người dùng, không phải Config

🔑 Key Concept / Khái niệm cốt lõi: AWS Config for configuration compliance tracking / AWS Config để theo dõi tuân thủ cấu hình

Reference: Domain 2 — AWS Config | Compliance

Q32.

A website must protect against SQL injection and XSS attacks. Which AWS service provides this protection?

Bản dịch tiếng Việt: Một trang web phải bảo vệ chống lại các cuộc tấn công SQL và XSS. Dịch vụ AWS nào cung cấp khả năng bảo vệ này?

A. AWS Shield B. AWS WAF (Web Application Firewall) C. Security Groups D. AWS KMS

Correct answer: B Bản dịch đáp án đúng: B. AWS WAF (Tường lửa ứng dụng web)

🇬🇧 Explanation:
AWS WAF (Web Application Firewall) filters HTTP/HTTPS requests before reaching application → block SQL injection, XSS, CSRF, etc. Shield (A) = DDoS. Security Groups (C) = network firewall (allows/denies ports). KMS (D) = encryption. WAF = app-layer protection.

🇻🇳 Giải thích:
WAF filter HTTP/HTTPS requests → block SQL injection, XSS, CSRF. Shield (A) = DDoS. SG (C) = network firewall. KMS (D) = encrypt. WAF = app-layer.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — Shield = DDoS, not app-layer attacks / Shield = DDoS, không chống tấn công tầng ứng dụng
C — SG = network-layer, not app-layer attacks / SG = tầng network, không chống tấn công tầng ứng dụng
D — KMS = encryption key management, not app protection / KMS = quản lý khóa mã hóa, không bảo vệ ứng dụng

🔑 Key Concept / Khái niệm cốt lõi: WAF for SQL injection, XSS, CSRF, other app-layer attacks / WAF chống SQL injection, XSS, CSRF và các tấn công tầng ứng dụng khác

Reference: Domain 2 — WAF | Web security

Q33. (Select TWO)

Which features help maintain compliance with data protection regulations in cloud deployments? (Select TWO)

Bản dịch tiếng Việt: Những tính năng nào giúp duy trì việc tuân thủ các quy định bảo vệ dữ liệu khi triển khai trên đám mây? (Chọn HAI)

A. Automatic data deletion after 24 hours B. Encryption of sensitive data at rest and in transit C. Regular backup and disaster recovery testing D. Disabling all monitoring to reduce overhead E. Storing all data in the same region regardless of data residency requirements

Correct answer: B, C Bản dịch đáp án đúng: B. Mã hóa dữ liệu nhạy cảm khi nghỉ ngơi và truyền tải; C. Kiểm tra sao lưu và disaster recovery thường xuyên

🇬🇧 Explanation:
B (encryption at rest & in transit) = data protection = compliance (GDPR, HIPAA, PCI). C (backup & DR testing) = meets recovery requirements, audit trail. Options A, D, E are bad: auto-delete (A) = lose audit trail. No monitoring (D) = compliance gap. Same region (E) = data residency violations (GDPR = EU data in EU).

🇻🇳 Giải thích:
B (encrypt) = data protection = compliance. C (backup & test) = recovery + audit. A = auto-delete = lose trail. D = no monitor = gap. E = same region = violate data residency (GDPR).

❌ Why others are wrong / Vì sao đáp án khác sai:

A — auto-delete = audit trail loss = compliance failure / tự xóa = mất audit trail = không đạt compliance
D — no monitoring = can't detect/audit = compliance gap / không giám sát = không phát hiện/audit = thiếu sót compliance
E — same region ignores data residency = GDPR violation (EU data must stay EU) / cùng region bỏ qua data residency = vi phạm GDPR (dữ liệu EU phải ở EU)

🔑 Key Concept / Khái niệm cốt lõi: Encryption + backups + monitoring + data residency for compliance / Mã hóa + backup + giám sát + data residency cho compliance

Reference: Domain 2 — Compliance | Data protection regulations

Q34.

A company stores confidential files in S3 and needs to ensure only authorized users can access them. Which approach is most appropriate?

Bản dịch tiếng Việt: Một công ty lưu trữ các tệp bí mật trong S3 và cần đảm bảo chỉ những người dùng được ủy quyền mới có thể truy cập chúng. Cách tiếp cận nào là phù hợp nhất?

A. Make all S3 objects publicly accessible for convenience B. Configure S3 bucket policies and object ACLs with appropriate IAM permissions C. Enable S3 versioning to prevent unauthorized access D. Store credentials in bucket metadata

Correct answer: B Bản dịch đáp án đúng: B. Định cấu hình các chính sách vùng lưu trữ S3 và ACL đối tượng với các quyền IAM phù hợp

🇬🇧 Explanation:
S3 bucket policies (resource-based) + object ACLs + IAM roles/policies = fine-grained access control. Who can get objects → checked against bucket policy, object ACL, IAM policy (all must allow). Option A = public = anyone. C = versioning = history, not access control. D = credentials in metadata = insecure.

🇻🇳 Giải thích:
S3 bucket policy + ACL + IAM = access control. Who get object → check bucket policy, ACL, IAM (hết allow = no). A = public = ai cũng được. C = version = history, not access. D = cred in metadata = insecure.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — public access = anyone can read = doesn't ensure "only authorized" / public access = ai cũng đọc được = không đảm bảo "chỉ người được phép"
C — versioning = object history, not access control / versioning = lịch sử object, không phải kiểm soát truy cập
D — credentials in metadata = insecure, can be exposed / credentials trong metadata = không an toàn, có thể bị lộ

🔑 Key Concept / Khái niệm cốt lõi: S3 bucket policies + ACLs + IAM for fine-grained access control / Bucket policy S3 + ACL + IAM để kiểm soát truy cập chi tiết

Reference: Domain 2 — S3 security | IAM

Q35.

Which service helps identify and protect against threats by analyzing CloudTrail logs and VPC Flow Logs?

Bản dịch tiếng Việt: Dịch vụ nào giúp xác định và bảo vệ khỏi các mối đe dọa bằng cách phân tích nhật ký CloudTrail và Nhật ký luồng VPC?

A. AWS GuardDuty B. AWS CloudWatch C. AWS Trusted Advisor D. AWS CloudFormation

Correct answer: A Bản dịch đáp án đúng: A. Nhiệm vụ bảo vệ AWS

🇬🇧 Explanation:
AWS GuardDuty analyzes CloudTrail (API calls), VPC Flow Logs (network traffic), and DNS logs → detect anomalies = threat detection. CloudWatch (B) = metrics/logs. Trusted Advisor (C) = best practices. CloudFormation (D) = IaC. GuardDuty = threat analysis & detection.

🇻🇳 Giải thích:
GuardDuty analyze CloudTrail (API), VPC Flow Logs (network), DNS logs → detect anomaly = threat detect. CloudWatch (B) = metrics. Trusted Advisor (C) = best practice. CloudFormation (D) = IaC. GuardDuty = threat analyze.

❌ Why others are wrong / Vì sao đáp án khác sai:

B — CloudWatch = application metrics, not threat analysis / CloudWatch = metrics ứng dụng, không phân tích mối đe dọa
C — Trusted Advisor = best practices, not threat detection / Trusted Advisor = best practice, không phát hiện mối đe dọa
D — CloudFormation = IaC, not threat analysis / CloudFormation = IaC, không phân tích mối đe dọa

🔑 Key Concept / Khái niệm cốt lõi: GuardDuty for ML-based threat detection from logs / GuardDuty phát hiện mối đe dọa dựa trên ML từ log

Reference: Domain 2 — GuardDuty | Threat detection

Q36. (Select TWO)

For a highly available and secure multi-AZ deployment, which components should be included? (Select TWO)

Bản dịch tiếng Việt: Để triển khai nhiều AZ có tính sẵn sàng cao và bảo mật, nên đưa vào những thành phần nào? (Chọn HAI)

A. Single database instance in one AZ B. Load balancer distributing traffic across AZs C. Auto Scaling Group with instances in multiple AZs D. Centralized security group with no segmentation E. Regular automated backups stored in the same region

Correct answer: B, C Bản dịch đáp án đúng: B. Cân bằng tải phân phối lưu lượng truy cập trên các AZ; C. Nhóm Auto Scaling với các phiên bản ở nhiều AZ

🇬🇧 Explanation:
B (LB across AZs) = distributes traffic, handles AZ failure = HA. C (ASG multi-AZ instances) = auto-scale, replace failed instances, span AZs = HA. Options A (single DB) = SPOF, no HA. D (centralized SG) = no segmentation = weak security. E (same region backup) = doesn't help multi-region DR.

🇻🇳 Giải thích:
B (LB AZ) = distribute, handle AZ fail = HA. C (ASG multi-AZ) = auto-scale, replace, multi-AZ = HA. A = single DB = SPOF. D = centralized SG = no segment = weak. E = same region = không multi-region DR.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — single database instance in one AZ = if AZ fails = SPOF / một instance database trong một AZ = AZ sập = SPOF
D — centralized security group = no network segmentation = weak security / security group tập trung = không phân đoạn mạng = bảo mật yếu
E — same-region backup = doesn't help multi-region DR / backup cùng region = không hỗ trợ DR đa region

🔑 Key Concept / Khái niệm cốt lõi: LB + ASG + multi-AZ for HA / LB + ASG + multi-AZ cho HA

Reference: Domain 3 — HA architecture | Multi-AZ deployment

Domain 3: Cloud Technology and Services (Q37–Q58)

Q37.

A company needs to automatically add EC2 instances during traffic spikes and remove them when demand decreases. Which AWS service enables this?

Bản dịch tiếng Việt: Công ty cần tự động thêm phiên bản EC2 khi lưu lượng truy cập tăng đột biến và loại bỏ chúng khi nhu cầu giảm. Dịch vụ AWS nào cho phép điều này?

A. AWS Lambda B. Amazon EC2 Auto Scaling Group (ASG) C. Amazon CloudFront D. AWS Elastic Beanstalk

Correct answer: B Bản dịch đáp án đúng: B. Nhóm tự động thay đổi quy mô Amazon EC2 (ASG)

🇬🇧 Explanation:
Amazon EC2 Auto Scaling Group (ASG) automatically scales instances based on demand metrics (CPU, request count). Launch new instances when target breached, terminate when demand drops. Lambda (A) = serverless, max 15min, not suitable for web servers. CloudFront (C) = CDN caching. Beanstalk (D) = PaaS (includes ASG + LB + monitoring).

🇻🇳 Giải thích:
ASG auto-scale based on metric (CPU, request count). Launch instance khi target breach, terminate khi demand drop. Lambda (A) = serverless, 15min max. CloudFront (C) = CDN. Beanstalk (D) = PaaS (include ASG).

❌ Why others are wrong / Vì sao đáp án khác sai:

A — Lambda = serverless compute, not suitable for persistent web servers; max 15min duration / Lambda = compute serverless, không hợp cho web server chạy lâu; tối đa 15 phút
C — CloudFront = CDN caching, not EC2 scaling / CloudFront = cache CDN, không scale EC2
D — while Beanstalk includes ASG, the direct answer for "ASG" is EC2 Auto Scaling Group itself / Beanstalk có dùng ASG, nhưng đáp án trực tiếp cho "ASG" chính là EC2 Auto Scaling Group

🔑 Key Concept / Khái niệm cốt lõi: Auto Scaling Group for elastic EC2 scaling / Auto Scaling Group để scale EC2 co giãn

Reference: Domain 3 — EC2 Auto Scaling

Q38. (Select TWO)

Which services provide caching to improve application performance and reduce backend load? (Select TWO)

Bản dịch tiếng Việt: Những dịch vụ nào cung cấp bộ nhớ đệm để cải thiện hiệu suất ứng dụng và giảm tải phụ trợ? (Chọn HAI)

A. Amazon CloudFront (CDN) B. Amazon ElastiCache (Redis/Memcached) C. Amazon S3 D. AWS Direct Connect E. Amazon EBS

Correct answer: A, B Bản dịch đáp án đúng: A. Amazon CloudFront (CDN); B. Amazon ElastiCache (Redis/Memcached)

🇬🇧 Explanation:
CloudFront (A) = CDN, cache content at edge locations globally. ElastiCache (B) = in-memory cache (Redis, Memcached), cache database queries. S3 (C) = object storage, not primarily caching. Direct Connect (D) = dedicated network connection. EBS (E) = block storage. CloudFront + ElastiCache = caching services.

🇻🇳 Giải thích:
CloudFront = CDN, cache content tại edge. ElastiCache = in-memory cache (Redis, Memcached), cache DB query. S3 (C) = storage. Direct Connect (D) = network. EBS (E) = block storage. CloudFront + ElastiCache = cache.

❌ Why others are wrong / Vì sao đáp án khác sai:

C — S3 = object storage, not caching (though can use as origin) / S3 = object storage, không phải cache (dù có thể làm origin)
D — Direct Connect = network, not caching / Direct Connect = network, không phải cache
E — EBS = block storage, not caching / EBS = block storage, không phải cache

🔑 Key Concept / Khái niệm cốt lõi: CloudFront (CDN) + ElastiCache (in-memory) for caching / CloudFront (CDN) + ElastiCache (in-memory) để cache

Reference: Domain 3 — CloudFront | ElastiCache

Q39.

A database must remain available even if one Availability Zone fails without manual intervention. Which deployment option is required?

Bản dịch tiếng Việt: Cơ sở dữ liệu phải luôn sẵn sàng ngay cả khi một Availability Zone bị lỗi nếu không có sự can thiệp thủ công. Tùy chọn triển khai nào là bắt buộc?

A. Single-AZ RDS instance B. RDS Multi-AZ with automatic failover C. RDS Read Replica in the same AZ D. Backup to S3 only

Correct answer: B Bản dịch đáp án đúng: B. RDS Multi-AZ với tính năng chuyển đổi dự phòng tự động

🇬🇧 Explanation:
RDS Multi-AZ = primary database + synchronous standby in different AZ. If primary fails, automatic failover to standby (minutes, no manual intervention). Single-AZ (A) = if AZ fails = downtime. Read Replicas (C) = async, not HA (don't auto-failover). Backup (D) = recovery, not HA (requires manual restore).

🇻🇳 Giải thích:
RDS Multi-AZ = primary + sync standby ở AZ khác. Primary fail → auto-failover to standby. Single-AZ (A) = AZ fail = down. Read Replicas (C) = async, không HA. Backup (D) = recovery manual.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — single-AZ = if AZ fails, database is down / single-AZ = AZ sập là database down
C — Read Replicas = async, don't auto-failover; can lag / Read Replicas = bất đồng bộ, không tự failover; có thể trễ
D — backup = manual recovery = requires manual intervention = not automatic / backup = phục hồi thủ công = cần can thiệp tay = không tự động

🔑 Key Concept / Khái niệm cốt lõi: Multi-AZ for automatic HA failover / Multi-AZ cho failover HA tự động

Reference: Domain 3 — RDS Multi-AZ

Q40.

Which AWS service distributes traffic across multiple EC2 instances, automatically removing unhealthy instances from rotation?

Bản dịch tiếng Việt: Dịch vụ AWS nào phân phối lưu lượng trên nhiều phiên bản EC2, tự động loại bỏ các phiên bản không lành mạnh khỏi vòng quay?

A. Amazon Route 53 B. AWS Direct Connect C. Elastic Load Balancer (ALB/NLB/CLB) D. AWS CloudFormation

Correct answer: C Bản dịch đáp án đúng: C. Elastic Load Balancing (ALB/NLB/CLB)

🇬🇧 Explanation:
Elastic Load Balancer (ALB, NLB, CLB) = health checks every 30 sec (default). Unhealthy instance marked out of rotation, traffic rerouted. Route 53 (A) = DNS, not instance-level health checks. Direct Connect (B) = dedicated network connection. CloudFormation (D) = IaC template. ELB = traffic distribution + health checks.

🇻🇳 Giải thích:
ELB = health check every 30s. Unhealthy instance → out rotation, traffic reroute. Route 53 (A) = DNS. Direct Connect (B) = network. CloudFormation (D) = IaC. ELB = distribution + health.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — Route 53 = DNS, not instance health checks + traffic distribution / Route 53 = DNS, không health check instance + phân phối traffic
B — Direct Connect = network connection, not traffic distribution / Direct Connect = kết nối mạng, không phân phối traffic
D — CloudFormation = IaC, not traffic distribution / CloudFormation = IaC, không phân phối traffic

🔑 Key Concept / Khái niệm cốt lõi: ELB for traffic distribution + auto health checks / ELB để phân phối traffic + health check tự động

Reference: Domain 3 — Elastic Load Balancer

Q41. (Select THREE)

For global disaster recovery with minimal data loss, which architectural components should be implemented? (Select THREE)

Bản dịch tiếng Việt: Để disaster recovery toàn cầu với mức độ mất dữ liệu tối thiểu, nên triển khai thành phần kiến trúc nào? (Chọn BA)

A. S3 Cross-Region Replication (CRR) B. Aurora Global Database with multi-region read replicas C. Single RDS instance with backup to same region D. Route 53 health checks and failover routing E. On-premises disaster recovery only

Correct answer: A, B, D Bản dịch đáp án đúng: A. Sao chép liên vùng S3 (CRR); B. Cơ sở dữ liệu toàn cầu Aurora với bản sao đọc đa khu vực; D. Kiểm tra tình trạng tuyến đường 53 và định tuyến chuyển đổi dự phòng

🇬🇧 Explanation:
A (S3 CRR) = real-time replication across regions = RPO near zero for data. B (Aurora Global DB) = multi-region database with automatic failover = RPO ~1 second. D (Route 53 failover) = detects primary region failure, routes traffic to secondary. C (single AZ backup) = doesn't help multi-region DR. E (on-premises only) = doesn't leverage cloud redundancy.

🇻🇳 Giải thích:
A (CRR) = real-time replicate region = RPO ≈ zero. B (Aurora Global DB) = multi-region DB = RPO ~1s. D (Route 53 failover) = detect fail, route traffic. C = single AZ = không help. E = on-premises = không leverage.

❌ Why others are wrong / Vì sao đáp án khác sai:

C — single-AZ backup = doesn't protect against region failure / backup single-AZ = không bảo vệ khi region sập
E — on-premises only = doesn't use cloud multi-region / chỉ on-premises = không dùng multi-region cloud

🔑 Key Concept / Khái niệm cốt lõi: Multi-region CRR + Aurora Global DB + Route 53 failover / CRR đa region + Aurora Global DB + Route 53 failover

Reference: Domain 3 — Disaster Recovery | Multi-region architecture

Q42.

An application requires both HA (High Availability) within a region and DR (Disaster Recovery) across regions. Which RDS feature enables HA across AZs?

Bản dịch tiếng Việt: Một ứng dụng yêu cầu cả HA (Tính sẵn sàng cao) trong một khu vực và DR (Khôi phục thảm họa) trên toàn khu vực. Tính năng RDS nào kích hoạt HA trên các AZ?

A. RDS Read Replicas B. RDS Multi-AZ C. RDS Automated Backups D. RDS Enhanced Monitoring

Correct answer: B Bản dịch đáp án đúng: B. RDS Đa vùng

🇬🇧 Explanation:
RDS Multi-AZ = HA within region (automatic failover across AZs). RDS Read Replicas = scaling reads (async), not HA. Automated Backups (C) = recovery from backups (manual). Enhanced Monitoring (D) = just monitoring. Multi-AZ = HA.

🇻🇳 Giải thích:
Multi-AZ = HA in region (auto-failover AZ). Read Replicas = scaling reads (async), không HA. Backup (C) = recovery manual. Monitor (D) = monitoring only. Multi-AZ = HA.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — Read Replicas = async, don't auto-failover = not HA / Read Replicas = bất đồng bộ, không tự failover = không HA
C — automated backups = recovery tool, not HA / backup tự động = công cụ phục hồi, không phải HA
D — monitoring = observability, not HA / monitoring = quan sát, không phải HA

🔑 Key Concept / Khái niệm cốt lõi: Multi-AZ for HA | CRR/Global DB for DR / Multi-AZ cho HA | CRR/Global DB cho DR

Reference: Domain 3 — RDS Multi-AZ vs Read Replicas

Q43. (Select THREE)

Which AWS services improve availability by replicating data or resources across geographic locations? (Select THREE)

Bản dịch tiếng Việt: Dịch vụ AWS nào cải thiện tính khả dụng bằng cách sao chép dữ liệu hoặc tài nguyên trên khắp các vị trí địa lý? (Chọn BA)

A. Amazon S3 Cross-Region Replication B. Aurora Global Database C. RDS Read Replicas in the same AZ only D. DynamoDB Global Tables E. EBS snapshots to the same region only

Correct answer: A, B, D Bản dịch đáp án đúng: A. Sao chép liên vùng của Amazon S3; B. Cơ sở dữ liệu toàn cầu Aurora; D. Bảng toàn cầu của DynamoDB

🇬🇧 Explanation:
A (S3 CRR) = replicate objects to other region automatically. B (Aurora Global DB) = multi-region database with instant read-only replicas. D (DynamoDB Global Tables) = multi-region NoSQL with <1sec replication. C (RDS Read Replicas same AZ) = doesn't improve geographic availability. E (EBS snapshots same region) = doesn't cross regions.

🇻🇳 Giải thích:
A (CRR) = auto replicate object region khác. B (Aurora Global DB) = multi-region DB. D (DynamoDB Global Tables) = multi-region NoSQL. C = same AZ = không geo. E = same region = không cross-region.

❌ Why others are wrong / Vì sao đáp án khác sai:

C — same-AZ read replicas = doesn't provide geographic redundancy / read replica cùng AZ = không có dự phòng địa lý
E — same-region snapshots = doesn't provide geographic redundancy / snapshot cùng region = không có dự phòng địa lý

🔑 Key Concept / Khái niệm cốt lõi: S3 CRR, Aurora Global DB, DynamoDB Global Tables for geographic replication / S3 CRR, Aurora Global DB, DynamoDB Global Tables để replicate địa lý

Reference: Domain 3 — Replication services | Disaster Recovery

Q44.

A web application experiences variable traffic throughout the week. Which Auto Scaling strategy would be most cost-effective?

Bản dịch tiếng Việt: Một ứng dụng web có lưu lượng truy cập thay đổi trong suốt cả tuần. Chiến lược Auto Scaling nào sẽ tiết kiệm chi phí nhất?

A. Fixed number of instances based on peak load B. Target Tracking based on CPU utilization or custom metrics C. Running all instances 24/7 regardless of demand D. Manually launching instances every morning

Correct answer: B Bản dịch đáp án đúng: B. Theo dõi mục tiêu dựa trên việc sử dụng CPU hoặc số liệu tùy chỉnh

🇬🇧 Explanation:
Target Tracking = Auto Scaling adjusts instances to keep metric (CPU%, request count) at target. Automatically adds instances when metric rises, removes when falls → pays only for load actually needed. Fixed instances (A) = pays for peak 24/7 (wasteful). Manual (D) = slow, human error = not cost-effective. Reserved Instances (C) = not flexible for variable demand.

🇻🇳 Giải thích:
Target Tracking = ASG adjust instance để keep metric (CPU%, request) at target. Auto add when rise, remove when fall → pay chỉ cần thiết. Fixed (A) = pay peak 24/7 (waste). Manual (D) = slow. Reserved (C) = không flexible.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — fixed based on peak = wasteful during low-demand periods / cố định theo đỉnh = lãng phí lúc nhu cầu thấp
C — 1-year Reserved = committed cost; variable demand = waste reserved capacity / Reserved 1 năm = chi phí cam kết; nhu cầu biến động = phí công suất reserved
D — manual = slow scaling, human error, operational overhead / thủ công = scale chậm, lỗi con người, overhead vận hành

🔑 Key Concept / Khái niệm cốt lõi: Target Tracking Auto Scaling for variable workloads / Target Tracking Auto Scaling cho workload biến động

Reference: Domain 3 — Auto Scaling strategies

Q45. (Select THREE)

Which characteristics distinguish Aurora from traditional RDS for high-availability scenarios? (Select THREE)

Bản dịch tiếng Việt: Đặc điểm nào giúp phân biệt Aurora với RDS truyền thống đối với các kịch bản có tính sẵn sàng cao? (Chọn BA)

A. 5x faster performance than standard MySQL/PostgreSQL B. Automatic failover across multiple AZs built-in C. Lower durability than standard RDS D. 6-way replication by default E. Requires manual Multi-AZ configuration like standard RDS

Correct answer: A, B, D Bản dịch đáp án đúng: A. Hiệu suất nhanh hơn gấp 5 lần so với MySQL/PostgreSQL tiêu chuẩn; B. Tự động chuyển đổi dự phòng trên nhiều AZ được tích hợp sẵn; D. Sao chép 6 chiều theo mặc định

🇬🇧 Explanation:
A (5x faster) = Aurora designed for high performance. B (auto-failover across AZs) = built-in Multi-AZ (unlike RDS which requires opt-in). D (6-way replication) = Aurora replicates data across 6 copies (3 AZs, 2 copies each) → high durability & availability. C (lower durability) = false, Aurora has HIGHER durability. E (requires manual config) = false, Aurora has built-in multi-AZ.

🇻🇳 Giải thích:
A (5x faster) = Aurora design high perf. B (auto-failover AZ) = built-in Multi-AZ. D (6-way replicate) = 6 copy across 3 AZ → durability. C = false. E = false.

❌ Why others are wrong / Vì sao đáp án khác sai:

C — Aurora has HIGHER durability (6-way replication vs RDS 3-way) / Aurora có độ bền CAO HƠN (replicate 6 bản vs RDS 3 bản)
E — Aurora multi-AZ is built-in, not manual configuration / multi-AZ của Aurora là tích hợp sẵn, không phải cấu hình tay

🔑 Key Concept / Khái niệm cốt lõi: Aurora = 5x faster + built-in multi-AZ + 6-way replication / Aurora = nhanh hơn 5x + multi-AZ tích hợp sẵn + replicate 6 bản

Reference: Domain 3 — RDS Aurora | HA databases

Q46.

A company wants to serve static content with ultra-low latency to global users. Which service is optimized for this use case?

Bản dịch tiếng Việt: Một công ty muốn cung cấp nội dung tĩnh với độ trễ cực thấp cho người dùng toàn cầu. Dịch vụ nào được tối ưu hóa cho trường hợp sử dụng này?

A. Amazon EC2 B. Amazon S3 with CloudFront CDN C. Amazon RDS D. AWS Lambda

Correct answer: B Bản dịch đáp án đúng: B. Amazon S3 với CloudFront CDN

🇬🇧 Explanation:
Amazon S3 + CloudFront CDN = store objects in S3, CloudFront caches at 200+ edge locations worldwide → users fetch from nearest edge (ultra-low latency). EC2 (A) = compute, not optimal for static. RDS (C) = database. Lambda (D) = compute functions. S3 + CloudFront = static content CDN.

🇻🇳 Giải thích:
S3 + CloudFront = store S3, CloudFront cache 200+ edge → user fetch nearest edge = ultra-low latency. EC2 (A) = compute. RDS (C) = DB. Lambda (D) = function. S3+CloudFront = static CDN.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — EC2 = compute, not optimized for static content caching / EC2 = compute, không tối ưu cho cache nội dung tĩnh
C — RDS = database, not for static content / RDS = database, không dành cho nội dung tĩnh
D — Lambda = compute function, not for static content caching / Lambda = hàm compute, không dành cho cache nội dung tĩnh

🔑 Key Concept / Khái niệm cốt lõi: S3 + CloudFront for global static content delivery / S3 + CloudFront để phân phối nội dung tĩnh toàn cầu

Reference: Domain 3 — CloudFront | Global content delivery

Q47.

Which RDS feature improves read performance by distributing read traffic to replica databases without affecting the primary database?

Bản dịch tiếng Việt: Tính năng RDS nào cải thiện hiệu suất đọc bằng cách phân phối lưu lượng đọc đến cơ sở dữ liệu bản sao mà không ảnh hưởng đến cơ sở dữ liệu chính?

A. Multi-AZ deployment B. Read Replicas C. RDS Proxy D. Enhanced Monitoring

Correct answer: B Bản dịch đáp án đúng: B. Đọc bản sao

🇬🇧 Explanation:
RDS Read Replicas = async replicas of primary database. Application can direct read queries to replicas (reducing load on primary). Replicas can be in same/different region. Multi-AZ (A) = sync standby for HA, not for scaling reads (standby not accessible for reads during normal operation). RDS Proxy (C) = connection pooling. Enhanced Monitoring (D) = just metrics.

🇻🇳 Giải thích:
Read Replicas = async replica of primary. App direct read query tới replica (reduce load primary). Replica same/khác region. Multi-AZ (A) = sync standby, không scale read. Proxy (C) = connection pool. Monitor (D) = metrics.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — Multi-AZ standby ≠ accessible for reads (it's a hot backup, not active) / standby Multi-AZ ≠ dùng được để đọc (là hot backup, không active)
C — RDS Proxy = connection pooling, not read scaling / RDS Proxy = gộp kết nối, không scale đọc
D — Enhanced Monitoring = just observability, not read scaling / Enhanced Monitoring = chỉ quan sát, không scale đọc

🔑 Key Concept / Khái niệm cốt lõi: Read Replicas for read scaling | Multi-AZ for HA / Read Replicas để scale đọc | Multi-AZ cho HA

Reference: Domain 3 — RDS Read Replicas

Q48. (Select THREE)

For an application requiring zero-downtime deployments and automatic scaling, which services should be used together? (Select THREE)

Bản dịch tiếng Việt: Đối với một ứng dụng yêu cầu triển khai không có thời gian ngừng hoạt động và tự động thay đổi quy mô, những dịch vụ nào nên được sử dụng cùng nhau? (Chọn BA)

A. Application Load Balancer (ALB) B. Auto Scaling Group C. RDS Multi-AZ D. AWS Lambda only E. Route 53 health checks

Correct answer: A, B, E Bản dịch đáp án đúng: A. Cân bằng tải ứng dụng (ALB); B. Nhóm tự động chia tỷ lệ; E. Kiểm tra sức khỏe tuyến đường 53

🇬🇧 Explanation:
A (ALB) = distributes traffic across instances, smooth rolling deployments. B (ASG) = auto-scale instances (launch new with new code, terminate old). E (Route 53 health checks) = detects unhealthy instances, routes traffic to healthy ones = zero-downtime failover. Lambda only (D) = not suitable for traditional apps. C (Multi-AZ) = helps but not sufficient alone.

🇻🇳 Giải thích:
A (ALB) = distribute traffic, rolling deployment smooth. B (ASG) = auto-scale instance (launch new code, terminate old). E (Route 53 health) = detect unhealthy, route healthy = zero-downtime. Lambda (D) = không suitable. C = help nhưng chưa đủ.

❌ Why others are wrong / Vì sao đáp án khác sai:

C — Multi-AZ alone ≠ zero-downtime deployments (still needs LB + ASG) / chỉ Multi-AZ ≠ deploy không downtime (vẫn cần LB + ASG)
D — Lambda = serverless, not for traditional web app deployments / Lambda = serverless, không dành cho deploy web app truyền thống

🔑 Key Concept / Khái niệm cốt lõi: ALB + ASG + Route 53 health checks for zero-downtime deployments / ALB + ASG + Route 53 health check để deploy không downtime

Reference: Domain 3 — Deployment patterns | Auto Scaling

Q49.

A company must maintain an exact copy of its production database in another region for disaster recovery. Which approach is best?

Bản dịch tiếng Việt: Một công ty phải duy trì một bản sao chính xác của cơ sở dữ liệu sản xuất của mình ở khu vực khác để disaster recovery. Cách tiếp cận nào là tốt nhất?

A. RDS Read Replicas in the same region B. RDS Cross-Region Read Replicas or Aurora Global Database C. S3 backup once per month D. Manual database export and import monthly

Correct answer: B Bản dịch đáp án đúng: B. Bản sao đọc liên vùng RDS hoặc Cơ sở dữ liệu toàn cầu Aurora

🇬🇧 Explanation:
RDS Cross-Region Read Replicas or Aurora Global Database = maintain exact copy in another region. If primary region fails, promote replica to primary (manual for standard RDS, semi-automatic for Aurora). Same-region replicas (A) = local HA, not DR. Manual export (D) = not continuous, data lag.

🇻🇳 Giải thích:
RDS Cross-Region Read Replica hoặc Aurora Global DB = maintain exact copy region khác. Primary fail → promote replica to primary. Same-region replica (A) = local HA. Manual export (D) = không continuous.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — same-region replicas = local HA, doesn't protect against region failure / replica cùng region = HA cục bộ, không bảo vệ khi region sập
C — monthly backup = can lose 30 days of data; not "exact copy" / backup hàng tháng = có thể mất 30 ngày dữ liệu; không phải "bản sao chính xác"
D — manual export = time-consuming, error-prone, data lag / export thủ công = tốn thời gian, dễ lỗi, trễ dữ liệu

🔑 Key Concept / Khái niệm cốt lõi: Cross-region read replicas or Aurora Global DB for DR / Read replica cross-region hoặc Aurora Global DB cho DR

Reference: Domain 3 — RDS Read Replicas | Aurora Global Database

Q50.

Which load balancer type is recommended for high-performance, ultra-low latency applications requiring extreme throughput?

Bản dịch tiếng Việt: Loại cân bằng tải nào được khuyên dùng cho các ứng dụng có hiệu suất cao, độ trễ cực thấp yêu cầu thông lượng cực cao?

A. Classic Load Balancer (CLB) B. Application Load Balancer (ALB) C. Network Load Balancer (NLB) D. AWS Global Accelerator only

Correct answer: C Bản dịch đáp án đúng: C. Cân bằng tải mạng (NLB)

🇬🇧 Explanation:
Network Load Balancer (NLB) = operates at Layer 4 (transport), handles millions of requests/sec, ultra-low latency (<100 μs). Ideal for gaming, IoT, real-time. CLB (A) = older, less performance. ALB (B) = Layer 7 (application), suitable for web apps but slightly higher latency than NLB. Global Accelerator (D) = multi-region, not single-region LB.

🇻🇳 Giải thích:
NLB = Layer 4 transport, millions req/sec, ultra-low latency. Game, IoT, real-time. CLB (A) = older, less perf. ALB (B) = Layer 7, web app, latency higher. Global Accelerator (D) = multi-region.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — CLB = older generation, lower performance, higher latency / CLB = thế hệ cũ, hiệu năng thấp hơn, độ trễ cao hơn
B — ALB = Layer 7 (application), suitable for web apps; slightly higher latency than NLB / ALB = Layer 7 (ứng dụng), hợp cho web app; độ trễ nhỉnh hơn NLB
D — Global Accelerator = multi-region routing, not single-region LB / Global Accelerator = định tuyến đa region, không phải LB trong một region

🔑 Key Concept / Khái niệm cốt lõi: NLB for ultra-low latency, extreme throughput (millions req/sec) / NLB cho độ trễ cực thấp, throughput cực lớn (triệu req/giây)

Reference: Domain 3 — Elastic Load Balancer types

Q51. (Select TWO)

Which services help implement a pilot light disaster recovery strategy? (Select TWO)

Bản dịch tiếng Việt: Những dịch vụ nào giúp triển khai chiến lược disaster recovery nhẹ thí điểm? (Chọn HAI)

A. Minimal resources running in secondary region B. Aurora Global Database with one-way failover C. Full production-scale systems in secondary region D. Route 53 failover routing policy E. Complete backup storage with no secondary compute

Correct answer: A, D Bản dịch đáp án đúng: A. Tài nguyên tối thiểu chạy ở khu vực thứ cấp; D. Chính sách định tuyến chuyển đổi dự phòng Route 53

🇬🇧 Explanation:
Pilot light = minimal infrastructure running in secondary region (e.g., RDS read replica + small EC2 instance), ready to scale up if primary fails. A (minimal resources in secondary region) = pilot light definition. D (Route 53 failover) = detect primary failure, failover to secondary. B, C, E don't fit: one-way failover (B) = not pilot light (needs scale-up). Production-scale (C) = that's multi-site active-active. No compute (E) = can't run pilot light.

🇻🇳 Giải thích:
Pilot light = minimal resource ở secondary region (RDS replica + small EC2), ready scale up if primary fail. A = definition. D = detect fail, failover. B, C, E = không fit: one-way (B) = không pilot light. Production (C) = multi-site. No compute (E) = không run.

❌ Why others are wrong / Vì sao đáp án khác sai:

B — one-way failover ≠ pilot light strategy (confusing terminology) / one-way failover ≠ chiến lược pilot light (thuật ngữ gây nhầm)
C — production-scale systems = multi-site active-active, not pilot light / hệ thống quy mô production = multi-site active-active, không phải pilot light
E — no compute in secondary = can't run services = not pilot light / không có compute ở secondary = không chạy được service = không phải pilot light

🔑 Key Concept / Khái niệm cốt lõi: Pilot light = minimal secondary region + Route 53 failover / Pilot light = region phụ tối thiểu + Route 53 failover

Reference: Domain 3 — Disaster Recovery strategies

Q52.

An ecommerce platform needs to handle variable traffic with automatic scaling during holiday sales. Which service combination is ideal?

Bản dịch tiếng Việt: Nền tảng thương mại điện tử cần xử lý lưu lượng truy cập thay đổi bằng cách tự động mở rộng quy mô trong thời gian bán hàng vào dịp lễ. Sự kết hợp dịch vụ nào là lý tưởng?

A. Fixed EC2 instance count only B. Auto Scaling Group + Elastic Load Balancer + CloudWatch metrics C. Lambda function for all traffic D. On-premises servers only

Correct answer: B Bản dịch đáp án đúng: B. Nhóm tự động mở rộng quy mô + Elastic Load Balancing + Số liệu CloudWatch

🇬🇧 Explanation:
Auto Scaling Group + ELB + CloudWatch metrics = ASG monitors CloudWatch (CPU%, request count) → scales instances up/down automatically. ELB distributes traffic. Fixed instances (A) = can't handle variable. Lambda (C) = not for traditional ecommerce apps (15min limit). On-premises (D) = no cloud elasticity.

🇻🇳 Giải thích:
ASG + ELB + CloudWatch = ASG monitor CloudWatch (CPU%, request) → scale tự động. ELB distribute. Fixed (A) = không variable. Lambda (C) = 15min limit. On-premises (D) = no elasticity.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — fixed = can't scale = system overloaded during holiday sales / cố định = không scale = quá tải mùa sale
C — Lambda = max 15 min, not suitable for long-running ecommerce transactions / Lambda = tối đa 15 phút, không hợp cho giao dịch ecommerce chạy lâu
D — on-premises = manual scaling = slow response during sudden traffic spikes / on-premises = scale thủ công = phản ứng chậm khi traffic tăng đột ngột

🔑 Key Concept / Khái niệm cốt lõi: ASG + ELB + CloudWatch for elastic scaling / ASG + ELB + CloudWatch để scale co giãn

Reference: Domain 3 — Auto Scaling | Elastic Load Balancer

Q53. (Select THREE)

Which services enable building a multi-region architecture for disaster recovery and high availability? (Select THREE)

Bản dịch tiếng Việt: Những dịch vụ nào cho phép xây dựng kiến trúc đa vùng để disaster recovery và có tính sẵn sàng cao? (Chọn BA)

A. Route 53 with health checks and failover B. S3 with Cross-Region Replication C. Single region deployment with local redundancy only D. Aurora Global Database E. An EBS volume attached to a single EC2 instance in one Availability Zone

Correct answer: A, B, D Bản dịch đáp án đúng: A. Route 53 với kiểm tra tình trạng và chuyển đổi dự phòng; B. S3 với tính năng sao chép xuyên khu vực; D. Cơ sở dữ liệu toàn cầu Aurora

🇬🇧 Explanation:
A (Route 53 health checks) = detect region failure, failover. B (S3 CRR) = replicate data across regions. D (Aurora Global DB) = multi-region DB. C (single region only) = doesn't provide multi-region. E (single EBS volume in one AZ) = scoped to one AZ in one region, so it provides neither multi-region nor cross-AZ redundancy.

🇻🇳 Giải thích:
A (Route 53) = detect fail, failover. B (CRR) = replicate data region. D (Aurora Global DB) = multi-region DB. C = single region only. E = EBS volume single AZ = không multi-region, không cross-AZ.

❌ Why others are wrong / Vì sao đáp án khác sai:

C — single-region deployment = doesn't enable multi-region architecture / triển khai một region = không tạo được kiến trúc multi-region
E — an EBS volume attached to one EC2 instance lives in a single AZ; it does not replicate across regions or AZs / EBS volume gắn vào một EC2 nằm trong một AZ; không replicate qua region hay AZ

🔑 Key Concept / Khái niệm cốt lõi: Route 53 + CRR + Aurora Global DB for multi-region (DynamoDB Global Tables is also valid) / Route 53 + CRR + Aurora Global DB cho multi-region (DynamoDB Global Tables cũng hợp lệ)

Reference: Domain 3 — Multi-region architecture | Disaster Recovery

Q54.

A data warehouse application queries large datasets infrequently but needs to process complex analytical queries. Which database is most appropriate?

Bản dịch tiếng Việt: Ứng dụng kho dữ liệu không thường xuyên truy vấn các tập dữ liệu lớn nhưng cần xử lý các truy vấn phân tích phức tạp. Cơ sở dữ liệu nào là phù hợp nhất?

A. DynamoDB B. Amazon Redshift C. RDS for transactional operations D. ElastiCache

Correct answer: B Bản dịch đáp án đúng: B. Amazon Redshift

🇬🇧 Explanation:
Amazon Redshift = columnar data warehouse, optimized for analytical queries on large datasets. DynamoDB (A) = NoSQL key-value, real-time (not analytical). RDS (C) = relational OLTP (transactional), not analytics. ElastiCache (D) = caching, not data warehouse.

🇻🇳 Giải thích:
Redshift = columnar data warehouse, optimize analytical query large dataset. DynamoDB (A) = NoSQL. RDS (C) = OLTP. ElastiCache (D) = cache.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — DynamoDB = OLTP (transactional), not analytical warehouse / DynamoDB = OLTP (giao dịch), không phải data warehouse phân tích
C — RDS = OLTP for transactional workloads, not data warehouse analytics / RDS = OLTP cho workload giao dịch, không phải phân tích data warehouse
D — ElastiCache = cache layer, not data warehouse / ElastiCache = tầng cache, không phải data warehouse

🔑 Key Concept / Khái niệm cốt lõi: Redshift for data warehouse analytics / Redshift cho phân tích data warehouse

Reference: Domain 3 — Redshift | Database selection

Q55. (Select TWO)

Which disaster recovery strategies minimize RTO (Recovery Time Objective) in AWS? (Select TWO)

Bản dịch tiếng Việt: Chiến lược disaster recovery nào giảm thiểu RTO (Mục tiêu thời gian khôi phục) trong AWS? (Chọn HAI)

A. Backup & Restore (full recovery from backups) B. Pilot Light (minimal resources ready in secondary region) C. Warm Standby (scaled-down secondary environment ready) D. Manual disaster recovery procedures E. Multi-Site Active-Active (fully active in multiple regions)

Correct answer: C, E Bản dịch đáp án đúng: C. Chế độ chờ ấm (sẵn sàng cho môi trường thứ cấp thu nhỏ); E. Multi-Site Active-Active (hoạt động hoàn toàn ở nhiều vùng)

🇬🇧 Explanation:
C (Warm Standby) = scaled-down secondary environment ready (EC2 running, DB warm) → RTO = minutes to hours. E (Multi-Site Active-Active) = fully active in multiple regions → RTO = seconds (traffic immediately routed to working region). Backup & Restore (A) = RTO = hours/days. Pilot Light (B) = RTO = minutes (needs scale-up).

🇻🇳 Giải thích:
C (Warm Standby) = secondary ready (EC2, DB warm) → RTO minute-hour. E (Active-Active) = fully active multi-region → RTO second. Backup (A) = RTO hour/day. Pilot (B) = RTO minute (need scale-up).

❌ Why others are wrong / Vì sao đáp án khác sai:

A — Backup & Restore = slowest, RTO = hours to days / Backup & Restore = chậm nhất, RTO = giờ đến ngày
B — Pilot Light = RTO = minutes (still needs scale-up); slower than warm standby/active-active / Pilot Light = RTO vài phút (vẫn cần scale-up); chậm hơn warm standby/active-active
D — this option doesn't exist in the question / lựa chọn này không có trong đề

🔑 Key Concept / Khái niệm cốt lõi: Warm Standby + Active-Active = lower RTO | Backup & Restore = higher RTO / Warm Standby + Active-Active = RTO thấp hơn | Backup & Restore = RTO cao hơn

Reference: Domain 3 — Disaster Recovery strategies | RTO/RPO

Q56.

A company wants to decouple its order processing system from its payment system to improve reliability. Which service is best for this?

Bản dịch tiếng Việt: Một công ty muốn tách hệ thống xử lý đơn hàng khỏi hệ thống thanh toán để cải thiện độ tin cậy. Dịch vụ nào là tốt nhất cho việc này?

A. Direct synchronous API calls between systems B. Amazon SQS message queue C. Single shared database for both systems D. AWS Lambda for sequential processing

Correct answer: B Bản dịch đáp án đúng: B. Hàng đợi tin nhắn Amazon SQS

🇬🇧 Explanation:
Amazon SQS = message queue decouples producer (order) from consumer (payment). Order system puts message in queue, payment system polls queue asynchronously. If payment system fails, orders queue up = order system still responsive = improved reliability. Direct API (A) = tight coupling = if payment fails, order fails. Shared database (C) = tight coupling via data. Lambda (D) = not decoupling, still synchronous.

🇻🇳 Giải thích:
SQS = message queue decouple producer (order) khỏi consumer (payment). Order → queue, payment poll async. Payment fail → order queue lại = order system vẫn respond = reliability tăng. API (A) = tight coupling. Shared DB (C) = tight coupling. Lambda (D) = sync.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — direct API = synchronous = if payment fails, order processing blocked / API trực tiếp = đồng bộ = payment lỗi thì xử lý order bị chặn
C — shared database = data coupling = if database issues, both systems affected / shared database = coupling dữ liệu = database lỗi là cả hai hệ thống ảnh hưởng
D — Lambda = still synchronous execution = no decoupling benefit / Lambda = vẫn thực thi đồng bộ = không có lợi ích decouple

🔑 Key Concept / Khái niệm cốt lõi: SQS for decoupling, async messaging, fault tolerance / SQS để decouple, nhắn tin bất đồng bộ, chịu lỗi

Reference: Domain 3 — SQS | Domain 1 — Loose coupling principle

Q57. (Select THREE)

For a mission-critical application, which architectural practices ensure business continuity? (Select THREE)

Bản dịch tiếng Việt: Đối với một ứng dụng quan trọng, thực tiễn kiến trúc nào đảm bảo tính liên tục trong kinh doanh? (Chọn BA)

A. Deploy across multiple Availability Zones B. Store critical data only in a single location C. Implement automated backups and restore testing D. Centralize all resources in one region E. Use Route 53 for intelligent traffic routing and failover

Correct answer: A, C, E Bản dịch đáp án đúng: A. Triển khai trên nhiều Availability Zone; C. Thực hiện kiểm tra sao lưu và khôi phục tự động; E. Sử dụng Route 53 để định tuyến và chuyển đổi dự phòng lưu lượng truy cập thông minh

🇬🇧 Explanation:
A (multi-AZ deployment) = if one AZ fails, other AZs handle traffic = continuous operation. C (automated backups + restore testing) = disaster recovery, can restore from backups if catastrophic failure. E (Route 53 failover) = detect failures, automatically failover to healthy region = continuous operation. B & D = consolidation = increased risk = violates business continuity.

🇻🇳 Giải thích:
A (multi-AZ) = 1 AZ fail → AZ khác handle = continuous. C (backup + test) = DR, restore if catastrophic. E (Route 53 failover) = detect, auto-failover = continuous. B, D = consolidate = risk.

❌ Why others are wrong / Vì sao đáp án khác sai:

B — single location = if fails, all fails = no business continuity / một vị trí = lỗi là sập hết = không liên tục kinh doanh
D — all resources one region = if region fails = no continuity / mọi tài nguyên một region = region sập = không liên tục

🔑 Key Concept / Khái niệm cốt lõi: Multi-AZ + backups + Route 53 failover for business continuity / Multi-AZ + backup + Route 53 failover cho liên tục kinh doanh

Reference: Domain 1 — HA/DR principles | Domain 3 — Business continuity architecture

Q58.

Which combination best achieves both High Availability (within region) and Disaster Recovery (across regions)?

Bản dịch tiếng Việt: Sự kết hợp nào đạt được tốt nhất cả Tính sẵn sàng cao (trong khu vực) và Phục hồi sau thảm họa (giữa các khu vực)?

A. Multi-AZ RDS deployment only B. Multi-AZ RDS + Cross-Region Read Replicas + Route 53 failover C. Single-AZ RDS with daily manual backups D. Backup to another AZ only

Correct answer: B Bản dịch đáp án đúng: B. Multi-AZ RDS + Bản sao đọc liên khu vực + Chuyển đổi dự phòng Route 53

🇬🇧 Explanation:
Multi-AZ RDS = HA within region (auto-failover across AZs). Cross-Region Read Replicas = DR across regions (promote to primary if region fails). Route 53 failover = detects region failure, routes to secondary region. Together: HA + DR. Single-AZ (C) = no HA. Same-region backup (D) = no multi-region protection.

🇻🇳 Giải thích:
Multi-AZ RDS = HA in region (auto-failover AZ). Cross-Region Read Replica = DR region (promote if fail). Route 53 failover = detect, route region khác. Together: HA + DR. Single-AZ (C) = no HA. Same-region backup (D) = no multi-region.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — Multi-AZ only = HA, no DR protection for region failure / chỉ Multi-AZ = HA, không có DR khi region sập
C — single-AZ = no HA, no DR (both single point of failure) / single-AZ = không HA, không DR (đều là điểm lỗi đơn)
D — same-region backup = HA maybe, no DR for region failure / backup cùng region = có thể HA, không DR khi region sập

🔑 Key Concept / Khái niệm cốt lõi: Multi-AZ (HA) + Cross-Region Replicas (DR) + Route 53 failover / Multi-AZ (HA) + Cross-Region Replicas (DR) + Route 53 failover

Reference: Domain 3 — HA vs DR | RDS architecture

Domain 4: Billing, Pricing, and Support (Q59–Q65)

Q59.

A company needs 24/7 production support with guaranteed response times and access to a Technical Account Manager. Which AWS Support plan is required?

Bản dịch tiếng Việt: Một công ty cần hỗ trợ sản xuất 24/7 với thời gian phản hồi được đảm bảo và quyền truy cập vào Người quản lý tài khoản kỹ thuật. Cần có gói Hỗ trợ AWS nào?

A. Basic (Free) B. Developer ($29/month) C. Business ($100+/month) D. Enterprise ($15,000+/month)

Correct answer: D Bản dịch đáp án đúng: D. Doanh nghiệp ($15.000+/tháng)

🇬🇧 Explanation:
Only Enterprise plan includes TAM (Technical Account Manager) + 24/7 phone/chat + guaranteed 15min response for business-critical issues. Basic (A) = free, no support. Developer (B) = email only. Business (C) = 24/7 phone but no TAM. Enterprise = TAM (only enterprise feature).

🇻🇳 Giải thích:
Chỉ Enterprise có TAM + 24/7 phone + 15min response. Basic (A) = free. Developer (B) = email. Business (C) = 24/7 nhưng no TAM. Enterprise = TAM.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — Basic = no support, no TAM / Basic = không support, không TAM
B — Developer = email only, no 24/7, no TAM / Developer = chỉ email, không 24/7, không TAM
C — Business = 24/7 but no TAM (Enterprise exclusive) / Business = 24/7 nhưng không TAM (riêng Enterprise)

🔑 Key Concept / Khái niệm cốt lõi: Enterprise plan for TAM + 24/7 guaranteed response / Gói Enterprise cho TAM + phản hồi đảm bảo 24/7

Reference: Domain 4 — AWS Support Plans

Q60.

A startup uses Auto Scaling and wants to predict and control spending. Which billing features help manage cost?

Bản dịch tiếng Việt: Một công ty khởi nghiệp sử dụng Auto Scaling và muốn dự đoán cũng như kiểm soát chi tiêu. Tính năng thanh toán nào giúp quản lý chi phí?

A. AWS Budgets with alerts B. Cost Explorer to track historical spending C. Purchasing Reserved Instances for guaranteed savings D. All of the above

Correct answer: D Bản dịch đáp án đúng: D. Tất cả những điều trên

🇬🇧 Explanation:
All of the above = AWS Budgets (A) alert when spending exceeds limit. Cost Explorer (B) shows historical spend + forecast → predict cost. Reserved Instances (C) for baseline workload = savings. Together: A + B + C maximize cost control.

🇻🇳 Giải thích:
Hết = AWS Budgets (A) alert khi spend vượt. Cost Explorer (B) show history + forecast. Reserved (C) for baseline = save. Together = cost control max.

❌ Why others are wrong / Vì sao đáp án khác sai:

None — all three are cost-management features / Không có — cả ba đều là tính năng quản lý chi phí

🔑 Key Concept / Khái niệm cốt lõi: AWS Budgets + Cost Explorer + Reserved Instances for cost control / AWS Budgets + Cost Explorer + Reserved Instances để kiểm soát chi phí

Reference: Domain 4 — Billing tools

Q61. (Select TWO)

Which AWS Trusted Advisor categories help improve infrastructure reliability and cost? (Select TWO)

Bản dịch tiếng Việt: Danh mục AWS Trusted Advisor nào giúp cải thiện độ tin cậy và chi phí của cơ sở hạ tầng? (Chọn HAI)

A. Security (IAM recommendations) B. Fault Tolerance (High Availability checks) C. Compliance (regulatory checks) D. Performance Efficiency E. Marketing recommendations

Correct answer: B, D Bản dịch đáp án đúng: B. Dung sai lỗi (Kiểm tra tính sẵn sàng cao); D. Hiệu quả hoạt động

🇬🇧 Explanation:
Trusted Advisor checks 5 categories: B (Fault Tolerance) = redundancy, backups, failover checks → improves reliability. D (Performance Efficiency) = right resource types, no idle resources → improves efficiency + cost. A (Security) = security checks. C (Compliance) = compliance checks. E = not real category. B + D directly address "reliability and cost".

🇻🇳 Giải thích:
Trusted Advisor 5 categories: B (Fault Tolerance) = redundancy, backup, failover → reliability. D (Performance Efficiency) = right resource, no idle → efficiency + cost. A = security. C = compliance. E = fake. B + D = reliability + cost.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — Security = security improvements, not directly reliability/cost / Security = cải thiện bảo mật, không trực tiếp về reliability/chi phí
C — Compliance = compliance, not directly reliability/cost / Compliance = tuân thủ, không trực tiếp về reliability/chi phí
E — not a real Trusted Advisor category / không phải category có thật của Trusted Advisor

🔑 Key Concept / Khái niệm cốt lõi: Trusted Advisor Fault Tolerance + Performance Efficiency for HA + cost optimization / Trusted Advisor Fault Tolerance + Performance Efficiency cho HA + tối ưu chi phí

Reference: Domain 4 — Trusted Advisor

Q62.

A business needs continuous support for critical production workloads with 1-hour response time for urgent issues. What is the minimum support plan?

Bản dịch tiếng Việt: Doanh nghiệp cần được hỗ trợ liên tục cho khối lượng công việc sản xuất quan trọng với thời gian phản hồi là 1 giờ cho các vấn đề khẩn cấp. Kế hoạch hỗ trợ tối thiểu là gì?

A. Basic B. Developer C. Business D. Enterprise

Correct answer: C Bản dịch đáp án đúng: C. Việc kinh doanh

🇬🇧 Explanation:
Only Business plan guarantees 1-hour response time for urgent issues. Basic (A) = no response time commitment. Developer (B) = 12+ hours. Enterprise (D) = even faster (15min). For "1-hour", Business is minimum.

🇻🇳 Giải thích:
Chỉ Business guarantee 1-hour response urgent. Basic (A) = no commitment. Developer (B) = 12h. Enterprise (D) = 15min. "1-hour" → Business minimum.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — Basic = no guaranteed response time / Basic = không cam kết thời gian phản hồi
B — Developer = 12-24 hours, not 1-hour / Developer = 12-24 giờ, không phải 1 giờ
D — Enterprise = overkill (also correct, but more expensive than minimum) / Enterprise = thừa (cũng đúng nhưng đắt hơn mức tối thiểu)

🔑 Key Concept / Khái niệm cốt lõi: Business plan for 1-hour response time (production issues) / Gói Business cho thời gian phản hồi 1 giờ (sự cố production)

Reference: Domain 4 — AWS Support Plans

Q63. (Select THREE)

Which pricing strategies help reduce costs for variable workloads with Auto Scaling? (Select THREE)

Bản dịch tiếng Việt: Chiến lược định giá nào giúp giảm chi phí cho khối lượng công việc có thể thay đổi bằng Auto Scaling? (Chọn BA)

A. On-Demand instances that scale up and down automatically B. Always purchasing 1-year Reserved Instances C. Using Spot instances for non-critical fault-tolerant workloads D. Running all instances continuously regardless of demand E. Combination of On-Demand for baseline + Spot for scaling

Correct answer: A, C, E Bản dịch đáp án đúng: A. Các phiên bản theo yêu cầu tự động tăng và giảm quy mô; C. Sử dụng phiên bản Spot cho khối lượng công việc có khả năng chịu lỗi không nghiêm trọng; E. Kết hợp Theo yêu cầu cho đường cơ sở + Điểm để chia tỷ lệ

🇬🇧 Explanation:
A (On-Demand auto-scale) = pay per use, scales down = costs down. C (Spot instances fault-tolerant workloads) = 90% discount for interruptible instances = lower cost. E (On-Demand baseline + Spot scaling) = base with on-demand, spiky with Spot = cost-optimized. B (always reserved) = not flexible. D (always running) = wasteful.

🇻🇳 Giải thích:
A (On-Demand auto-scale) = pay per use, scale down = cost down. C (Spot fault-tolerant) = 90% discount = low cost. E (On-Demand + Spot) = base On-Demand, spiky Spot = optimized. B = always reserved = inflexible. D = always = waste.

❌ Why others are wrong / Vì sao đáp án khác sai:

B — always purchasing Reserved Instances = over-commitment for variable workload = wasted reserved capacity / luôn mua Reserved Instances = cam kết thừa cho workload biến động = phí công suất reserved
D — always running = pays for idle = highest cost / luôn chạy = trả cho nhàn rỗi = chi phí cao nhất

🔑 Key Concept / Khái niệm cốt lõi: On-Demand + Spot for variable workloads = cost-effective / On-Demand + Spot cho workload biến động = tối ưu chi phí

Reference: Domain 4 — EC2 pricing | Cost optimization

Q64.

Which AWS Support feature provides best-practice recommendations to optimize costs and improve reliability?

Bản dịch tiếng Việt: Tính năng Hỗ trợ AWS nào cung cấp các đề xuất phương pháp tốt nhất để tối ưu hóa chi phí và cải thiện độ tin cậy?

A. AWS CloudWatch B. AWS Trusted Advisor C. AWS Cost Explorer D. AWS Budgets

Correct answer: B Bản dịch đáp án đúng: B. Cố vấn đáng tin cậy của AWS

🇬🇧 Explanation:
AWS Trusted Advisor = 5-category checks (Security, Fault Tolerance, Performance Efficiency, Cost Optimization, Service Limits) → recommendations. CloudWatch (A) = monitoring/alerting. Cost Explorer (C) = spending visualization. Budgets (D) = spending limits + alerts. Trusted Advisor = comprehensive best-practice tool.

🇻🇳 Giải thích:
Trusted Advisor = 5-category check → recommendation. CloudWatch (A) = monitoring. Cost Explorer (C) = spending view. Budgets (D) = limit. Trusted Advisor = best-practice.

❌ Why others are wrong / Vì sao đáp án khác sai:

A — CloudWatch = monitoring/alerting, not best-practice recommendations / CloudWatch = giám sát/cảnh báo, không phải khuyến nghị best-practice
C — Cost Explorer = cost visualization, not comprehensive best-practice / Cost Explorer = trực quan chi phí, không phải best-practice toàn diện
D — Budgets = spending alerts, not best-practice recommendations / Budgets = cảnh báo chi tiêu, không phải khuyến nghị best-practice

🔑 Key Concept / Khái niệm cốt lõi: Trusted Advisor for comprehensive best-practice recommendations / Trusted Advisor cho khuyến nghị best-practice toàn diện

Reference: Domain 4 — Trusted Advisor

Q65. (Select THREE)

Which elements should be considered when evaluating TCO (Total Cost of Ownership) for cloud migration? (Select THREE)

Bản dịch tiếng Việt: Những yếu tố nào cần được xem xét khi đánh giá TCO (Tổng chi phí sở hữu) cho việc di chuyển sang đám mây? (Chọn BA)

A. Infrastructure costs eliminated by migrating on-premises systems B. Operational costs of cloud services and staffing C. Reduced capital expenditure from not purchasing hardware D. Marketing budget for the cloud initiative E. The retail price of office furniture for the headquarters building

Correct answer: A, B, C Bản dịch đáp án đúng: A. Chi phí cơ sở hạ tầng được loại bỏ bằng cách di chuyển hệ thống tại chỗ; B. Chi phí vận hành dịch vụ đám mây và nhân sự; C. Giảm chi phí vốn do không mua phần cứng

🇬🇧 Explanation:
A (infrastructure costs eliminated) = on-premises hardware, power, cooling = cost saved. B (operational costs cloud services + staffing) = cloud service fees + reduced admin headcount = net cost. C (reduced CapEx) = no upfront hardware purchase = capital savings. D (marketing budget) = unrelated to TCO. E (retail price of office furniture) = a facilities expense unrelated to cloud vs on-premises IT cost.

🇻🇳 Giải thích:
A (eliminate infra) = on-prem hardware, power, cool = saved. B (cloud operation + staff) = cloud service + reduced staff = net cost. C (reduce CapEx) = no upfront hardware = capital save. D = unrelated. E = giá nội thất văn phòng = chi phí cơ sở vật chất, không liên quan TCO IT.

❌ Why others are wrong / Vì sao đáp án khác sai:

D — marketing budget = unrelated to TCO calculation / ngân sách marketing = không liên quan tính TCO
E — office furniture cost = a facilities expense, not part of cloud-vs-on-premises IT TCO / chi phí nội thất văn phòng = chi phí cơ sở vật chất, không thuộc TCO IT cloud-vs-on-premises

🔑 Key Concept / Khái niệm cốt lõi: TCO = elimination of on-premises infrastructure + cloud operational costs + CapEx savings (licensing savings also count) / TCO = loại bỏ hạ tầng on-premises + chi phí vận hành cloud + tiết kiệm CapEx (tiết kiệm license cũng tính)

Reference: Domain 4 — TCO analysis | Cost optimization

Summary & Key Takeaways

Theme #06 Focus Areas

✅ Well-Architected Reliability Pillar (Domain 1)

Loose coupling (SQS/SNS)
Auto-recovery mechanisms
Dynamic scaling
Redundancy (no SPOF)

✅ Multi-AZ & Multi-Region Architecture (Domain 3)

RDS Multi-AZ for HA
Cross-Region replicas for DR
Route 53 failover routing
S3 CRR, Aurora Global DB, DynamoDB Global Tables

✅ Disaster Recovery Strategies

Backup & Restore (slowest, cheapest)
Pilot Light (minimal secondary, scale on failover)
Warm Standby (scaled-down but ready)
Multi-Site Active-Active (fastest, most expensive)
RTO vs RPO trade-offs

✅ Auto Scaling & Load Balancing

ASG with metric-based or schedule-based scaling
ELB (ALB, NLB, CLB) for traffic distribution
Health checks for auto-recovery

✅ Cost Optimization for Variable Workloads

On-Demand + Spot for elasticity
Reserved Instances for baseline
AWS Budgets + Cost Explorer for visibility

Common Pitfalls to Avoid

❌ Confusing HA vs DR: HA = uptime (minutes), DR = recovery (hours/days) ❌ RTO vs RPO: RTO = time to recover, RPO = data loss tolerance ❌ Multi-AZ vs Multi-Region: Multi-AZ = HA within region, multi-region = DR across regions ❌ Read Replicas vs Multi-AZ: Read Replicas = async, for scaling reads | Multi-AZ = sync standby, for HA failover ❌ Tight vs Loose Coupling: Tight = synchronous API = cascading failures | Loose = SQS/SNS = fault tolerance

Score Calibration

≥ 52/65 (80%) = Exam-ready for HA themes
40–51/65 (60–78%) = Review HA/DR strategies, ASG, Multi-AZ, failover concepts
< 40/65 (< 60%) = Re-study Domain 1 (architecture principles), Domain 3 (services), test Domain 4 again

End of Exam #06 Solutions