Ngân hàng đề — AWS Certified CloudOps Engineer Associate

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

Đề bài đặt ra một yêu cầu vận hành rất quen thuộc: SysOps Administrator muốn nhận email mỗi khi các EC2 instance production quan trọng chạm ngưỡng 80% CPU utilization.

Cụm từ quyết định đáp án là "reach 80% CPU utilization" — tức là một metric vượt ngưỡng (metric threshold breach). Đây không phải là một sự kiện thay đổi trạng thái của tài nguyên (kiểu instance chuyển từ running sang stopped), mà là một con số đo được theo thời gian vượt qua một mức đã định.

Cụm từ thứ hai là "receive an email" — cần một cơ chế gửi thông báo tới người vận hành.

Bốn phương án là tổ hợp của hai trục:

• Trục phát hiện: CloudWatch alarm hay CloudWatch Events rule
• Trục gửi thông báo: Amazon SNS hay Amazon SES

Muốn chọn đúng thì phải trả lời đúng cả hai trục.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là D — Create an Amazon CloudWatch alarm and configure an Amazon SNS notification.

CloudWatch alarm đúng ở trục phát hiện: alarm là thành phần được thiết kế riêng để theo dõi một metric (ở đây là CPUUtilization của EC2), so sánh giá trị của metric đó với một ngưỡng đã đặt (80%) trong một số chu kỳ đánh giá, rồi chuyển sang trạng thái ALARM khi điều kiện thoả mãn. Đúng chính xác cái mà đề mô tả.

Amazon SNS đúng ở trục thông báo: khi alarm đổi trạng thái, hành động (alarm action) mà nó có thể gọi là publish một message vào SNS topic. SNS topic có subscription kiểu email — người quản trị đăng ký địa chỉ email vào topic, xác nhận subscription, và từ đó mọi lần alarm kích hoạt là mail được gửi tới. Đây là cặp ghép nguyên bản mà tài liệu AWS hướng dẫn cho tình huống "cảnh báo metric → gửi mail".

Điểm mấu chốt: CloudWatch alarm không gửi email trực tiếp. Nó chỉ biết publish vào SNS (hoặc gọi vài hành động EC2/Auto Scaling/Systems Manager). SNS mới là lớp chịu trách nhiệm phân phát ra email. Vì vậy cặp "alarm + SNS" là con đường tự nhiên và duy nhất trong danh sách này.

❌ Vì sao các phương án còn lại sai

A — CloudWatch alarm + Amazon SES notification. Đây là phương án gần đúng nhất, vì nó chọn đúng thành phần phát hiện: CloudWatch alarm là thứ theo dõi ngưỡng metric. Nó hỏng ở trục thứ hai. SES là dịch vụ gửi email hàng loạt cho ứng dụng (email giao dịch, email marketing) và được gọi qua API từ code của bạn; nó không phải là một alarm action mà CloudWatch alarm có thể chọn trực tiếp. Không có ô "gửi qua SES" khi cấu hình alarm. Muốn đi qua SES thì phải chèn thêm khâu trung gian (ví dụ alarm → SNS → Lambda → SES) — mà đề không nêu, và đó là kiến trúc phức tạp hoá vô ích khi SNS đã tự gửi email được.

B — CloudWatch Events rule + SNS notification. Phương án này chọn đúng lớp thông báo (SNS gửi được email) nhưng sai lớp phát hiện. CloudWatch Events (nay là EventBridge) phản ứng với sự kiện — các thay đổi trạng thái của tài nguyên: instance chuyển trạng thái, snapshot hoàn tất, một API call được ghi nhận, hoặc một lịch chạy theo cron. Nó không đánh giá metric và không so sánh với ngưỡng phần trăm. Không có cách nào viết một event pattern nói "khi CPUUtilization vượt 80%", vì con số đó không tồn tại dưới dạng sự kiện — nó là dữ liệu metric chuỗi thời gian. Một alarm khi đổi trạng thái có phát ra event mà Events rule bắt được, nhưng khi đó vẫn phải có alarm trước đã — và phương án B không hề có alarm.

C — CloudWatch Events rule + SES notification. Sai cả hai trục cùng lúc: sai ở chỗ dùng Events để bắt một sự vượt ngưỡng metric (lý do giống B), và sai ở chỗ chọn SES làm đích thông báo (lý do giống A). Đây là phương án xa yêu cầu nhất trong bốn phương án.

📌 Điểm cần nhớ

• "Metric vượt ngưỡng" → CloudWatch alarm. "Trạng thái tài nguyên thay đổi" hoặc "chạy theo lịch" → CloudWatch Events / EventBridge rule. Đọc đề thấy con số phần trăm, ngưỡng, hay "vượt quá X" thì nghĩ ngay tới alarm.
• CloudWatch alarm không tự gửi email — nó publish vào SNS topic, và SNS mới phân phát tới email subscriber. Đây là cặp ghép chuẩn xuất hiện lặp đi lặp lại trong đề thi.
• SNS ≠ SES trong ngữ cảnh cảnh báo vận hành. SNS là pub/sub để phát thông báo tới nhiều loại endpoint (email, SMS, HTTP, Lambda, SQS) và tích hợp sẵn với CloudWatch. SES là dịch vụ gửi email cho ứng dụng, gọi qua API, không phải đích đến trực tiếp của một alarm action.
• Với đề dạng tổ hợp hai trục (phát hiện × thông báo), hãy loại theo từng trục thay vì đọc cả bốn câu như bốn giải pháp độc lập — trục nào sai là loại được hai phương án cùng lúc.

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

Đề mô tả một ứng dụng chạy trên nhiều Amazon EC2 instance nằm ở nhiều Availability Zone, các instance này cần truy cập và dùng chung dữ liệu qua file system interface. Dữ liệu hiện còn nhỏ nhưng sẽ tăng mạnh theo thời gian. Câu hỏi yêu cầu giải pháp lưu trữ MOST scalable.

Ba cụm từ trong đề quyết định đáp án, và phải thoả cả ba cùng lúc:

1. "multiple Availability Zones" — loại mọi thứ chỉ hoạt động trong phạm vi một AZ.
2. "file system interfaces" — kho lưu trữ phải cho mount và truy cập theo giao thức file (NFS/SMB), không phải block qua iSCSI, cũng không phải object qua REST API.
3. "expected to increase significantly" + "MOST scalable" — dung lượng phải tự lớn lên, không phải thứ mình khai trước một con số cố định rồi phải đi mở rộng bằng tay.

Cụm phân biệt mạnh nhất là "file system interfaces" đi kèm "multiple Availability Zones" — chỉ cần bám vào hai cụm này là ba phương án còn lại rụng.

✅ Vì sao đáp án đúng là đúng

B. Create an Amazon EFS filesystem and create mount targets in multiple subnets.

Amazon EFS là dịch vụ file system được quản lý, cung cấp đúng giao diện file system qua giao thức NFS — nhiều EC2 instance mount cùng một file system và đọc/ghi chung dữ liệu, đúng nhu cầu "access and share data using file system interfaces" của đề.

EFS là tài nguyên phạm vi region, và việc tạo mount target trong nhiều subnet (mỗi subnet thuộc một AZ) chính là cách để các instance ở các AZ khác nhau cùng nối tới một file system. Đây là lý do phương án nêu rõ chi tiết "mount targets in multiple subnets" — nó trả lời trực tiếp ràng buộc multi-AZ.

Về khả năng mở rộng: EFS tự co giãn dung lượng khi thêm hoặc xoá file, không phải khai trước kích thước và cũng không phải mở rộng thủ công khi dữ liệu phình ra. Với đề nói "dữ liệu nhỏ nhưng sẽ tăng đáng kể", đây đúng là nghĩa của MOST scalable mà câu hỏi tìm.

❌ Vì sao các phương án còn lại sai

A. Use Amazon EBS multi-attach to connect the EC2 instances to a single volume. — Đây là phương án gần đúng nhất và là bẫy chính. EBS Multi-Attach đúng là cho nhiều EC2 instance cùng gắn vào một volume, nên thoạt nhìn có vẻ hợp với "chia sẻ dữ liệu". Nhưng nó hỏng ở hai chỗ. Thứ nhất, một EBS volume nằm trong đúng một AZ, và Multi-Attach chỉ áp dụng cho các instance trong cùng AZ đó — vi phạm thẳng ràng buộc "multiple Availability Zones". Thứ hai, EBS là block storage, không phải file system interface; muốn nhiều instance ghi đồng thời an toàn thì phải tự dựng cluster file system bên trên, chứ bản thân volume không lo việc đó. Thêm nữa, EBS volume có dung lượng khai trước, muốn to hơn phải chủ động thay đổi — kém "scalable" hơn hẳn EFS.

C. Deploy an AWS Storage Gateway cached volume on Amazon EC2. — Storage Gateway là dịch vụ dành cho việc nối môi trường on-premises với storage trên AWS, không phải cách chuẩn để các EC2 instance trong VPC chia sẻ dữ liệu với nhau. Quan trọng hơn, cached volume gateway phục vụ theo giao thức iSCSI, tức là block-based, chứ không phải giao diện file như NFS hay SMB — trượt thẳng ràng buộc "file system interfaces" của đề. Ở đây kiến trúc còn bị lộn ngược: đề không có hệ thống on-premises nào cần cầu nối cả.

D. Create an Amazon S3 bucket and a VPC endpoint, mount the bucket to the instances. — Sai ngay ở động từ "mount". S3 là object storage, truy cập qua REST API, không phải file system; bản thân bucket không phải thứ đem mount vào EC2 như một file system theo cách đề mô tả. VPC endpoint chỉ giải quyết chuyện đường mạng đi tới S3 mà không ra Internet — nó không biến object storage thành file system interface. Đúng là S3 rất scalable và không bị giới hạn AZ, nhưng đề đã chốt sẵn kiểu giao diện truy cập, nên tiêu chí đó không cứu được phương án này.

📌 Điểm cần nhớ

• Đề nêu "file system interface" / "shared file system" + nhiều AZ → gần như luôn là EFS (với workload Linux/NFS). Đây là dấu hiệu nhận dạng mạnh nhất của nhóm câu hỏi này.
• Phân biệt theo kiểu giao diện truy cập, đừng phân biệt theo "cái nào lưu được nhiều": EBS = block, S3 = object qua REST API, EFS = file qua NFS. Chọn sai kiểu giao diện là sai câu, dù dịch vụ đó có scalable đến đâu.
• EBS gắn với một Availability Zone, kể cả khi dùng Multi-Attach. Hễ đề nhấn "multiple Availability Zones" thì EBS bị loại trước tiên.
• AWS Storage Gateway sinh ra cho on-premises. Đề chỉ nói về EC2 trong VPC mà phương án nhắc Storage Gateway thì gần như chắc là mồi nhử — và riêng cached volume còn là block qua iSCSI, không phải file.
• Với từ khoá "MOST scalable" đi cùng "dữ liệu sẽ tăng đáng kể", hãy ưu tiên dịch vụ tự co giãn dung lượng, thay vì dịch vụ phải khai trước kích thước rồi mở rộng thủ công.

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

Đề mô tả một ứng dụng HPC (high performance computing) chạy trên Amazon EC2, và yêu cầu triển khai sao cho đạt được tốc độ mạng tối đa và độ trễ nhỏ nhất giữa các node.

Cụm từ quyết định là "maximum network speed and minimal latency between nodes". Đây là mô tả kinh điển của nhu cầu network performance, không phải nhu cầu availability. Cả bốn phương án đều là placement group, chỉ khác nhau ở hai trục:

• Loại placement group: cluster hay spread — quyết định EC2 đặt các instance gần nhau hay tách xa nhau.
• Phạm vi Availability Zone: một AZ hay nhiều AZ — quyết định gói tin có phải đi qua hạ tầng liên AZ hay không.

Vì đề chỉ nói tới hiệu năng mạng và hoàn toàn không nhắc tới chịu lỗi, chống hỏng đồng thời hay yêu cầu HA, trục thứ nhất phải nghiêng về cluster, và trục thứ hai phải nghiêng về một AZ duy nhất — trao đổi giữa các AZ luôn phải đi xa hơn về mặt vật lý nên độ trễ cao hơn so với trong cùng một AZ.

✅ Vì sao đáp án đúng là đúng

C — Deploy the EC2 instances within a single Availability Zone using a cluster placement group.

Cluster placement group sinh ra đúng cho lớp ứng dụng cần độ trễ mạng thấp, throughput mạng cao, hoặc cả hai. Cách nó hoạt động: EC2 xếp các instance nằm sát nhau bên trong cùng một Availability Zone, để chúng chia sẻ hạ tầng mạng gần nhau nhất có thể. Kết quả là hiệu năng mạng giữa các node đạt mức cao nhất mà EC2 cung cấp — đúng điều một workload HPC cần, khi các node phải trao đổi liên tục với nhau trong quá trình tính toán.

Vế "within a single Availability Zone" trong phương án cũng không thừa: cluster placement group vốn không trải rộng qua nhiều AZ được, nên đây là cách phát biểu đúng bản chất của cấu hình này.

❌ Vì sao các phương án còn lại sai

A — Nhiều AZ + spread placement group. Sai cả hai trục. Spread placement group đặt các instance lên phần cứng tách biệt nhau, mục đích là giảm rủi ro nhiều instance hỏng cùng lúc. Nó không hứa hẹn gì về độ trễ hay throughput — thậm chí việc cố tình phân tán ra phần cứng khác nhau, lại còn qua nhiều AZ, làm hiệu năng mạng giữa các node xấu đi so với gom lại. Đây là lựa chọn cho bài toán độ sẵn sàng, không phải bài toán hiệu năng.

B — Một AZ + spread placement group. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi: nó đã chọn đúng "một AZ", nên nhìn qua tưởng hợp lý. Nhưng nó hỏng ở loại placement group. Spread vẫn tiếp tục làm đúng việc của spread — tách các instance ra các phần cứng khác nhau để cô lập rủi ro. Giới hạn phạm vi về một AZ không biến spread thành cluster; ý đồ của chiến lược đặt máy vẫn ngược hẳn với "đặt gần nhau để giảm latency". Chọn B là chọn đúng nửa sau, sai đúng cái nửa quyết định.

D — Nhiều AZ + cluster placement group. Cũng là bẫy đối xứng với B: chọn đúng "cluster" nhưng sai phạm vi. Vấn đề là cấu hình này không tồn tại — cluster placement group không thể trải qua nhiều Availability Zone, vì toàn bộ giá trị của nó nằm ở chỗ gom các instance sát nhau trong cùng một AZ. Yêu cầu như phương án D mô tả là tự mâu thuẫn với định nghĩa của cluster placement group, nên không triển khai được chứ không chỉ là "kém tối ưu".

📌 Điểm cần nhớ

• Đề nhắc low latency / high throughput giữa các node (HPC, tính toán phân tán, tightly coupled) → nghĩ ngay tới cluster placement group. Đề nhắc giảm rủi ro hỏng đồng thời, cô lập instance → spread placement group. Hai loại này giải hai bài toán ngược nhau.
• Cluster placement group gói gọn trong một Availability Zone. Bất kỳ phương án nào ghép "cluster" với "multiple Availability Zones" đều loại được ngay mà không cần đọc tiếp.
• Đánh đổi cố hữu: gom máy lại thì mạng nhanh nhưng rủi ro tập trung; tách máy ra thì chịu lỗi tốt nhưng mạng không còn tối ưu. Đề bài nghiêng về vế nào thì chọn theo vế đó, đừng cố tìm phương án "vừa nhanh vừa an toàn".
• Với câu hỏi có hai biến (loại placement group × phạm vi AZ), hãy tách riêng từng biến rồi loại dần — các phương án nhiễu thường chỉ đúng một biến để trông hợp lý.

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

Một công ty đang quản lý EC2 instances trải rộng trên nhiều AWS Region. Người quản trị cần đảm bảo mọi instance đều được gắn tag đúng cách, và đề hỏi cách MOST operationally efficient để xác định (identify) instance nào đã có tag, instance nào chưa.

Ba cụm từ trong đề quyết định đáp án:

• "identify tagged and untagged" — việc cần làm chỉ là liệt kê / xem hiện trạng, không phải áp đặt luật, không phải xem chi phí, cũng không phải nhóm tài nguyên lại để quản lý về sau. Kết quả mong muốn là một danh sách trong đó cả instance chưa có tag cũng phải xuất hiện.
• "across several AWS Regions" — công cụ được chọn phải tra cứu được nhiều Region trong một lần, chứ không phải mở từng Region console một.
• "MOST operationally efficient" — giữa nhiều cách cùng cho ra kết quả, chọn cách ít bước dựng dẹp nhất. Bất kỳ phương án nào bắt phải thiết lập hạ tầng quản trị trước khi có được câu trả lời đều thua ở tiêu chí này.

✅ Vì sao đáp án đúng là đúng

C — Use Tag Editor in AWS Resource Groups. Select all Regions and choose a resource type of AWS::EC2::Instance.

Tag Editor trong AWS Resource Groups sinh ra đúng thứ đề cần: chọn phạm vi Region (chọn được tất cả Region), chọn resource type là AWS::EC2::Instance, rồi tìm kiếm. Kết quả trả về là danh sách toàn bộ EC2 instance kèm tag hiện có của chúng — instance chưa có tag vẫn nằm trong danh sách với phần tag trống, nên chỉ cần nhìn vào đó là phân biệt được tagged và untagged.

Đây cũng là cách ít thao tác nhất: không cần bật thêm dịch vụ, không cần tạo cấu trúc tổ chức, không cần chờ dữ liệu billing. Chỉ mở console, đặt bộ lọc, đọc kết quả — và từ chính màn hình đó còn sửa/thêm tag hàng loạt được luôn, đúng tinh thần "operationally efficient".

❌ Vì sao các phương án còn lại sai

A — Enable AWS Organizations và tạo tag policy, rồi dùng Tag Policies để sinh compliance report. Đây là phương án gần đúng nhất, vì compliance report của tag policy thật sự cho biết tài nguyên nào không tuân thủ quy tắc tag. Nhưng nó hỏng ở tiêu chí "operationally efficient": phải bật AWS Organizations, phải định nghĩa tag policy (tức là phải quyết định trước bộ tag chuẩn) rồi mới có báo cáo. Đó là dựng cả một cơ chế quản trị và cưỡng chế tag trong khi đề chỉ yêu cầu xem hiện trạng. Việc tốt để làm về sau, nhưng quá nặng cho câu hỏi đang đặt ra.

B — Cost Explorer, chọn service type EC2-Instances, group by Resource. Cost Explorer là công cụ phân tích chi phí, không phải công cụ kiểm kê tài nguyên. Group by Resource cho ra chi phí bổ theo từng resource, không phải bảng tag. Quan trọng hơn: một instance vừa tạo hoặc chưa phát sinh chi phí đáng kể có thể không hiện lên đúng như một bản kiểm kê, nên đây không phải nguồn dữ liệu tin cậy để khẳng định "đã liệt kê hết instance".

D — Cost and usage report trong Cost Explorer, chọn service type EC2-Instances rồi filter by tag. Sai vì hai lẽ. Thứ nhất, giống B, kết quả là số liệu chi phí, không phải danh sách trạng thái tag. Thứ hai — và đây là lỗi chí mạng — lọc theo tag thì chỉ thấy được thứ có tag. Instance chưa gắn tag chính là thứ ta đang đi tìm, mà bộ lọc theo tag lại đẩy chúng ra khỏi kết quả. Phương án này trả lời ngược với yêu cầu của đề.

E — Tạo tag-based resource group trong AWS Resource Groups với resource type AWS::EC2::Instance. Rất dễ nhầm với C vì cùng nằm trong AWS Resource Groups. Khác biệt nằm ở chỗ: resource group nhóm các tài nguyên thoả một điều kiện tag lại với nhau để thao tác chung về sau. Bản chất của nó là "gom những cái khớp tag" — nên những instance không có tag lại rơi ra ngoài group, đúng những cái cần tìm thì không thấy. Tag Editor mới là công cụ để tra cứu và sửa tag; Resource Group là công cụ để tổ chức tài nguyên đã có tag.

📌 Điểm cần nhớ

• Tag Editor (trong AWS Resource Groups) = tìm và chỉnh sửa tag hàng loạt, xem được cả tài nguyên chưa có tag, chọn nhiều Region và nhiều resource type cùng lúc. Đề hỏi "liệt kê tagged và untagged" thì gần như luôn là Tag Editor.
• Resource Groups = gom tài nguyên đã khớp điều kiện tag để quản lý chung. Nó dựa vào tag, nên không dùng để tìm thứ thiếu tag.
• Tag Policies + AWS Organizations = cưỡng chế và báo cáo tuân thủ chuẩn tag ở quy mô nhiều account. Đúng cho câu hỏi "enforce / prevent non-compliant tags", nhưng thừa cho câu hỏi "identify".
• Cost Explorer / cost and usage report = trả lời câu hỏi về chi phí. Thấy đề hỏi về kiểm kê tài nguyên hay tình trạng cấu hình mà phương án đưa ra công cụ billing thì hầu như luôn loại được.
• Mẹo chung với từ khoá MOST operationally efficient: loại trước những phương án bắt bật thêm dịch vụ hoặc dựng cấu trúc mới chỉ để lấy một báo cáo tra cứu một lần.

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

Đề yêu cầu cấu hình bảo vệ dữ liệu cho một Amazon RDS database, với ba ràng buộc cùng lúc:

1. cost-effective — giải pháp rẻ, không được dựng thêm hạ tầng chạy song song;
2. protect against table corruption — chống hỏng bảng, tức phải khôi phục được về trạng thái trước lúc hỏng;
3. retain backups for 30 days — giữ bản sao lưu 30 ngày.

Cụm quyết định đáp án là "protect against table corruption". Nó loại thẳng mọi cơ chế sao chép dữ liệu (replication/synchronization), vì sao chép sẽ nhân bản luôn cả phần hỏng: một câu DROP TABLE hay một bảng bị corrupt ở logic ứng dụng sẽ được truyền y nguyên sang bản sao. Chỉ có backup theo mốc thời gian mới quay ngược lại được. Cụm thứ hai là "cost-effective", dùng để phân biệt giữa hai hình thức backup của RDS: automated backups và manual snapshots.

✅ Vì sao đáp án đúng là đúng

C — Enabled automated backups và đặt backup retention period 30 ngày.

Amazon RDS tự tạo bản sao lưu của DB instance trong backup window đã khai báo. Đây là snapshot ở mức storage volume, sao lưu toàn bộ DB instance chứ không phải từng database riêng lẻ, và RDS giữ lại các bản đó đúng theo backup retention period mà bạn cấu hình — khoảng cấu hình được của RDS lên tới 35 ngày, nên 30 ngày nằm trọn trong giới hạn, khai đúng con số đề yêu cầu là xong.

Về ba ràng buộc:

• Chống table corruption: automated backups cho phép khôi phục về một thời điểm trong quá khứ, tức là quay lại trạng thái trước khi bảng hỏng.
• Retention 30 ngày: là đúng một tham số cấu hình, không cần script hay công cụ ngoài.
• Cost-effective: automated backups trong phạm vi dung lượng đã cấp phát cho instance được tính vào chi phí của chính instance, nên không phát sinh thêm hạ tầng nào phải trả tiền.

❌ Vì sao các phương án còn lại sai

A — Create a read replica ở Availability Zone khác. Đây là phương án gần đúng nhất và cũng là bẫy chính. Read replica đúng là tăng khả năng chịu lỗi hạ tầng và giảm tải đọc, nhưng dữ liệu được replicate bất đồng bộ từ master: bảng hỏng ở master sẽ được sao y sang replica. Nó bảo vệ trước sự cố hạ tầng, không bảo vệ trước hỏng dữ liệu. Ngoài ra nó không có khái niệm giữ bản sao lưu 30 ngày, và phải trả tiền cho một instance chạy thêm — trượt cả hai ràng buộc còn lại.

B — Chụp snapshot thủ công hằng ngày và lưu trên Amazon S3. Về mặt kỹ thuật thì snapshot có khôi phục được dữ liệu, nhưng phương án này hỏng ở tiêu chí chi phí: automated backups trong phạm vi dung lượng đã cấp phát của instance đã nằm trong giá instance, còn manual snapshot thì không được hưởng phần miễn phí đó, nên tốn hơn. Thêm nữa, nó bắt bạn tự dựng và tự vận hành lịch chụp cùng chính sách xoá bản cũ sau 30 ngày — làm tay cái mà RDS đã có sẵn dưới dạng một tham số cấu hình.

D — Dùng Database Migration Service để đồng bộ dữ liệu với một RDS instance khác. Sai ở cả hai điểm. Về chi phí: phải nuôi thêm một database instance đích đang chạy, đắt hơn hẳn. Về mục đích: DMS làm nhiệm vụ đồng bộ, nên giống trường hợp A, nó chép cả phần dữ liệu hỏng sang bên kia — không hề chống được table corruption. DMS là công cụ di chuyển/đồng bộ dữ liệu, không phải công cụ sao lưu có lịch sử theo thời gian.

📌 Điểm cần nhớ

• Replication ≠ backup. Thấy cụm "corruption", "accidental deletion", "bad data" trong đề thì loại ngay read replica, Multi-AZ và DMS sync — mọi cơ chế sao chép đều nhân bản luôn lỗi dữ liệu. Chỉ backup mới quay ngược thời gian được.
• Ngược lại, thấy "hardware failure", "AZ outage", "high availability" thì mới tới lượt Multi-AZ / read replica; đọc kỹ đề đang chống loại sự cố nào.
• Automated backups và manual snapshots đều khôi phục được, nhưng khác nhau về chi phí và vòng đời: automated backups gắn với instance, có retention tự động (tối đa 35 ngày) và tính trong giá instance; manual snapshot tồn tại tới khi bạn xoá và phải tự quản lý. Đề nói "cost-effective" + "retain N ngày" với N ≤ 35 thì gần như luôn là automated backups.
• Ưu tiên tính năng có sẵn cấu hình bằng một tham số hơn là tự dựng lịch chụp và tự dọn bản cũ — vừa rẻ hơn vừa ít chỗ hỏng hơn.

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

Đề hỏi: một Amazon EBS volume đang ở trạng thái error, SysOps Administrator làm gì để đưa volume trở lại hoạt động?

Cụm từ quyết định là "status of error". Đây không phải một trạng thái chung chung mà là một giá trị cụ thể trong vòng đời status của EBS volume (creating, available, in-use, deleting, deleted, error). Trạng thái error mang nghĩa rất hẹp và rất nặng: phần cứng bên dưới đỡ volume đó đã hỏng, và dữ liệu trên volume không khôi phục được. Volume không thể attach, không thể đọc, không thể snapshot.

Cụm từ thứ hai đáng chú ý là "bring the volume back online" — đề không hỏi "cứu dữ liệu trong volume", mà hỏi làm sao có lại một volume dùng được. Hai câu hỏi đó có đáp án khác nhau, và chính chỗ này phân biệt phương án B với phương án C.

Điểm bẫy: rất dễ nhầm error với impaired — trạng thái mà EBS tự ngắt I/O vì phát hiện dữ liệu có thể không nhất quán. impaired mới là trạng thái có thể can thiệp được; error thì không.

✅ Vì sao đáp án đúng là đúng

Đáp án theo tệp là C — Create a new volume from a recent snapshot.

Vì dữ liệu trên volume lỗi đã mất theo phần cứng, cách duy nhất còn lại là quay về bản sao đã có từ trước. EBS snapshot được lưu tách khỏi phần cứng đỡ volume, nên phần cứng hỏng không kéo snapshot chết theo. Từ một snapshot gần nhất, bạn tạo volume mới, attach vào instance và chạy tiếp.

Đây là lý do việc lên lịch snapshot định kỳ được coi là bắt buộc chứ không phải tuỳ chọn với EBS: RPO của bạn chính bằng khoảng cách giữa hai snapshot. Chữ "recent" trong phương án C nói đúng điều đó — bạn khôi phục về thời điểm snapshot, phần dữ liệu ghi sau snapshot cuối cùng là mất thật.

❌ Vì sao các phương án còn lại sai

A — Enable I/O using the enable-volume-io API. Đây là phương án gần đúng nhất và cũng là bẫy chính. enable-volume-io là thao tác có thật, nhưng nó dành cho volume ở trạng thái impaired: khi EBS nghi ngờ dữ liệu không nhất quán, nó tự chặn I/O và chờ quản trị viên xác nhận "tôi chấp nhận rủi ro, cho ghi tiếp". Với volume ở trạng thái error, không có gì để bật lại cả — phần cứng bên dưới đã hỏng, không phải I/O bị chặn có chủ đích. Gọi API này ở đây không đưa volume trở lại được.

B — Take a snapshot and then create a new volume from the snapshot. Phương án này chỉ khác C ở bước đầu tiên, và chính bước đầu tiên làm nó sai. Muốn chụp snapshot thì phải đọc được dữ liệu trên volume, mà volume error thì không đọc được. Bạn không thể tạo snapshot mới từ một volume đã mất dữ liệu. Vế sau của B ("create a new volume from the snapshot") thì đúng, nhưng nó phụ thuộc vào một bước bất khả thi — nên cả chuỗi hỏng. Khác biệt cốt lõi: C dùng snapshot đã có sẵn từ trước khi hỏng, B đòi tạo snapshot sau khi đã hỏng.

D — Perform a consistency check using the fsck command. fsck là công cụ ở tầng hệ điều hành, kiểm tra tính nhất quán của file system trên một block device đã được attach và đọc được. Ở đây volume còn không attach và mount nổi, nên không có device nào cho fsck chạy lên. Ngoài ra fsck sửa lỗi cấu trúc file system chứ không phục hồi được block đã mất cùng phần cứng — sai cả về tầng lẫn về loại sự cố.

📌 Điểm cần nhớ

• error = phần cứng hỏng, dữ liệu mất, không cứu được. Với trạng thái này, câu trả lời trong đề thi gần như luôn là khôi phục từ snapshot có sẵn.
• Phân biệt error với impaired. impaired mới là trạng thái dùng enable-volume-io để cho phép I/O tiếp tục sau khi chấp nhận rủi ro dữ liệu không nhất quán. Thấy enable-volume-io trong phương án, hãy kiểm lại đề đang nói trạng thái nào.
• Snapshot phải có từ trước. Mọi phương án đòi tạo snapshot từ volume đã hỏng đều sai, vì snapshot cần đọc được dữ liệu nguồn.
• Chú ý tầng của công cụ. fsck làm việc ở tầng file system trên một device đã mount được; sự cố ở tầng block device/phần cứng của EBS nằm ngoài tầm với của nó.

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

Đề mô tả một hệ thống web đang chạy hoàn toàn trong một Region duy nhất là us-east-1: EC2 instances phía sau một ELB, Route 53 lo phần DNS công khai, và toàn bộ hạ tầng đó được dựng bằng một CloudFormation stack. Yêu cầu đặt ra là làm sao để hệ thống đạt tính sẵn sàng cao.

Cụm từ quyết định là "high availability across multiple Regions" — sẵn sàng cao xuyên nhiều Region, chứ không phải sẵn sàng cao trong nội bộ một Region. Đây chính là ràng buộc tách bạch bốn phương án: một phương án chỉ giải quyết mức Availability Zone, một phương án nói về cache biên, một phương án dựa trên tính năng không tồn tại, và chỉ một phương án thực sự dựng được bản sao hạ tầng ở Region khác kèm cơ chế chuyển hướng lưu lượng.

Chi tiết phụ nhưng đắt giá: đề nói rõ hạ tầng đã được mô tả bằng CloudFormation. Đó là gợi ý mạnh rằng việc nhân bản sang Region khác là chuyện triển khai lại chính stack đó, không cần dựng tay.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là B — triển khai CloudFormation stack ở nhiều Region và dùng Failover routing policy trong Route 53.

Cách này giải quyết đủ hai nửa của bài toán multi-Region:

• Nửa hạ tầng: CloudFormation stack là bản mô tả hạ tầng dưới dạng mã. Chạy lại chính stack ấy ở Region thứ hai sẽ dựng ra một bản sao đầy đủ gồm ELB và EC2 instances tại đó. Region thứ hai vì thế có năng lực phục vụ thật, chứ không chỉ là một điểm chuyển tiếp.
• Nửa điều hướng lưu lượng: Route 53 với Failover routing policy cho phép khai báo một endpoint primary và một endpoint secondary, gắn với health check. Khi Region chính không còn khoẻ, Route 53 trả lời truy vấn DNS bằng endpoint của Region dự phòng, nên người dùng được đưa sang bản sao còn sống.

Ghép lại: có bản sao chạy được ở Region khác và có cơ chế tự động chuyển hướng sang đó — đúng định nghĩa high availability ở cấp Region.

❌ Vì sao các phương án còn lại sai

A. Bật Multi-AZ cho EC2 instances và ELB. Đây là phương án gần đúng nhất và cũng là bẫy chính. Trải instances qua nhiều Availability Zone, để ELB phân phối qua các AZ đó là thực hành đúng và có nâng tính sẵn sàng thật. Nhưng nó hỏng ở đúng chỗ đề yêu cầu: AZ nằm trong cùng một Region. Sự cố ở phạm vi toàn Region us-east-1 sẽ kéo theo mọi AZ trong đó, và hệ thống vẫn sập. Phương án này trả lời cho "high availability", không trả lời cho "across multiple Regions".

C. Dựng CloudFront distribution để "trải" web platform ra nhiều Region. Sai ở cách hiểu bản chất dịch vụ. CloudFront là CDN: nó cache và phân phối nội dung từ các edge location, còn phần xử lý vẫn quay về origin. Nó không tạo ra EC2 instances hay ELB ở Region khác. Origin ở đây vẫn chỉ có một, nằm ở us-east-1 — origin chết thì phần động của web platform vẫn chết, dù có bao nhiêu edge location đi nữa.

D. Dùng Cross-Region Replication cho EC2 instances và ELB. Sai ở tiền đề: EC2 instances và ELB không có tính năng cross-region replication. Đây là phương án nghe quen tai vì thuật ngữ này gắn với các dịch vụ lưu trữ/dữ liệu, nhưng gắn vào compute và load balancer thì đó là thứ không tồn tại. Không thể chọn một tính năng không có thật.

📌 Điểm cần nhớ

• Đọc kỹ phạm vi của yêu cầu sẵn sàng: Multi-AZ = chịu lỗi trong một Region; Multi-Region = chịu lỗi cả một Region. Đề nhắc "across multiple Regions" là loại ngay mọi đáp án dừng ở mức AZ.
• Một kiến trúc multi-Region cần đủ hai nửa: bản sao hạ tầng ở Region kia, và cơ chế điều hướng lưu lượng sang đó. Đáp án chỉ có một nửa thì chưa đạt.
• Route 53 Failover routing policy là công cụ điển hình cho mô hình active–passive giữa hai Region, dựa trên health check để quyết định trả về endpoint nào.
• CloudFront là CDN, không phải cơ chế nhân bản hạ tầng — nó không dựng compute ở Region khác và không tự cứu được một origin duy nhất bị sập.
• Cảnh giác với phương án gán một tính năng có thật của dịch vụ này sang một dịch vụ khác (như "cross-region replication" cho EC2/ELB). Đây là kiểu mồi nhử hay gặp trong đề AWS.

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

Đề mô tả một tình huống rất cụ thể: hai AWS account, VPC peering connection đã được cấu hình xong, và các CIDR block không chồng lấn (non-overlapping). Yêu cầu là instance ở private subnet của VPC này ping được instance ở private subnet của VPC kia.

Cụm từ quyết định đáp án là "has configured a VPC peering connection between them" — nghĩa là bước tạo peering đã hoàn tất rồi, câu hỏi không hỏi "làm sao kết nối hai VPC" mà hỏi "còn thiếu bước gì để traffic thật sự chạy". Cụm thứ hai bổ trợ là "non-overlapping CIDR blocks": nó xác nhận điều kiện tiên quyết của peering đã thoả, nên không được đụng vào CIDR nữa.

Đây chính là chỗ phân biệt các phương án: một peering connection ở trạng thái active không tự động tạo route. Bản thân nó chỉ là đường ống; muốn gói tin đi vào ống thì route table của mỗi bên phải có entry trỏ dải IP của bên kia qua peering connection đó.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng là A — Add a route to the VPC route tables of each VPC that points to the IP address range of the other VPC.

VPC peering cho phép định tuyến traffic giữa hai VPC bằng địa chỉ IP private, khiến instance hai bên giao tiếp như thể nằm chung một mạng. Nhưng theo đúng thiết kế của AWS, chủ sở hữu mỗi VPC trong peering connection phải tự tay thêm route vào một hoặc nhiều route table của mình, trỏ tới dải IP của peer VPC. Không có route đó, instance ở private subnet gửi gói tin ra sẽ không biết đường nào dẫn tới dải IP kia và gói bị bỏ.

Chú ý chữ "each VPC" trong phương án: định tuyến phải có ở cả hai chiều. Chỉ thêm route một bên thì gói đi được nhưng gói trả lời không về được, và ping — vốn cần cả echo request lẫn echo reply — sẽ vẫn thất bại.

❌ Vì sao các phương án còn lại sai

B — Modify the CIDR blocks so they are matching. Đây là phương án sai ngược hẳn với nguyên lý. VPC peering không hoạt động khi hai VPC có CIDR chồng lấn; dải không chồng lấn chính là điều kiện bắt buộc, và đề đã nói rõ nó đang thoả. Làm cho hai dải "matching" là tự tay phá vỡ peering hiện có, chứ không phải mở rộng kết nối. Ngoài ra, đổi CIDR của một VPC đang chạy không phải thao tác nhẹ nhàng như câu chữ gợi ý.

C — Create a virtual private gateway within each VPC and then link the VPGs. Đây là phương án gần đúng nhất về mặt "nghe có vẻ mạng riêng", nên cần chỉ rõ chỗ hỏng: virtual private gateway là điểm cuối phía AWS dành cho VPN connection tới data center on-premises (và cho Direct Connect). Nó không phải là thành phần dùng để nối hai VPC với nhau, và cũng không có thao tác "link hai VPG lại". Quan trọng hơn, đề đã có sẵn peering connection — dựng thêm một cơ chế kết nối khác là giải quyết nhầm vấn đề, trong khi thứ đang thiếu chỉ là route.

D — Linked accounts + consolidated billing rồi mới enable VPC peering. Consolidated billing thuần tuý là chuyện thanh toán và tổ chức account, gộp hoá đơn của nhiều account về một payer account. Nó không cấp bất kỳ quyền mạng nào, không tạo "file sharing network", và không phải điều kiện tiên quyết của VPC peering — peering giữa hai account khác nhau chỉ cần bên kia chấp nhận request. Vế cuối "then enable VPC peering" còn mâu thuẫn với đề: peering đã được cấu hình rồi.

📌 Điểm cần nhớ

• VPC peering connection ở trạng thái active không tự sinh route. Luôn có ba việc tách bạch: tạo/chấp nhận peering → thêm route ở cả hai route table → mở security group và network ACL cho phép traffic (với ping là ICMP).
• CIDR không chồng lấn là điều kiện bắt buộc của VPC peering. Thấy phương án nào đề nghị làm cho các dải trùng/khớp nhau để "kết nối tốt hơn" thì loại ngay.
• Virtual private gateway thuộc về VPN/Direct Connect tới on-premises, không dùng để nối VPC với VPC. Đây là bẫy phân biệt kinh điển giữa peering và VPN.
• Consolidated billing chỉ là chuyện hoá đơn, không phải cơ chế mạng hay cơ chế cấp quyền. Peering giữa hai account không đòi hai account phải cùng một tổ chức thanh toán.

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

Công ty muốn giới hạn loại instance mà từng nhóm được phép khởi chạy. Bối cảnh có ba chi tiết quyết định, và cả ba đều nằm ngay trong đề:

• "separate AWS accounts for its development and production teams" — có hai account tách biệt, nên mọi thứ cấp quyền phải nằm trong account của nhóm development, không phải account production.
• "uses federated login with single sign-on (SSO)" — người dùng không phải IAM user cục bộ. Họ đăng nhập từ nguồn định danh bên ngoài rồi assume một IAM role. Đây chính là cụm từ phân biệt hai phương án C và D, vốn giống hệt nhau trừ chữ group và role.
• "AWS accounts are both under one organization in AWS Organizations" — có sẵn Organizations, nên có thể dùng SCP làm hàng rào cứng; và vì production cũng nằm trong cùng organization, chỗ gắn SCP là điều quan trọng.

Câu hỏi chọn HAI đáp án vì lời giải cần hai mảnh khác nhau: một mảnh cấp quyền (IAM) và một mảnh chặn quyền vượt rào (SCP). SCP không bao giờ tự cấp quyền cho ai; nó chỉ đặt trần cho những quyền đã được IAM cấp.

✅ Vì sao đáp án đúng là đúng

D — Tạo IAM role trong account của development, gắn policy cho phép EC2 T2. Vì đăng nhập là federated qua SSO, luồng thực tế kết thúc bằng lời gọi AssumeRole* để lấy thông tin xác thực tạm thời của một IAM role. Quyền hạn của người dùng đến từ permissions policy gắn trên role đó, và role phải nằm trong chính account development thì mới cấp được quyền trên tài nguyên của account đó.

E — Tạo SCP từ chối launch trừ khi instance type là T2, gắn vào OU của developer. SCP là lớp trần quyền ở tầng Organizations: dù IAM policy trong account có bị sửa lỏng ra sau này, lệnh chạy instance không phải T2 vẫn bị chặn. Gắn ở OU của developer nghĩa là ràng buộc chỉ áp lên đúng nhóm account cần giới hạn.

Hai phương án bổ trợ nhau: D cho phép làm được, E đảm bảo không làm gì hơn thế.

❌ Vì sao các phương án còn lại sai

A — IAM group trong account của production team. Sai về vị trí trước cả khi bàn tới group hay role. Quyền tạo trong account production không có tác dụng gì trong account development; đội dev sẽ vẫn không launch nổi instance nào ở account của họ. Đây là phương án sai rõ nhất.

B — SCP deny non-T2 nhưng gắn vào root. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Nội dung policy hoàn toàn đúng, chỉ hỏng ở điểm gắn: root là gốc của cả organization, nên ràng buộc "chỉ được T2" sẽ đổ xuống mọi account, kể cả production. Đề chỉ yêu cầu giới hạn nhóm development; áp lên root là làm hỏng khả năng chạy instance của production. Gắn đúng phạm vi là OU của developer — chính là E.

C — IAM group trong account development, policy cho phép EC2 T2. Cũng gần đúng: đúng account, đúng nội dung quyền. Nhưng IAM group là vật chứa dành cho IAM user, mà ở đây không có IAM user nào — danh tính đến từ nguồn federated và nhận quyền qua AssumeRole*. Không thể "gắn" một danh tính federated vào IAM group, nên policy này sẽ không bao giờ có hiệu lực với người dùng SSO. Đó đúng là chỗ phân biệt C với D.

📌 Điểm cần nhớ

• Federated / SSO ⇒ IAM role, không phải IAM user hay IAM group. Thấy chữ "federated login", "SSO", "identity provider" trong đề thì gạch ngay mọi phương án dùng group hoặc user.
• SCP không cấp quyền, chỉ giới hạn. Câu nào chỉ có SCP mà không có phần IAM cấp quyền thì lời giải chưa đủ — và ngược lại, IAM một mình thì không phải hàng rào cứng.
• Điểm gắn SCP quyết định phạm vi ảnh hưởng: root ⇒ cả organization, OU ⇒ nhóm account trong OU đó, account ⇒ một account. Khi hai phương án SCP có nội dung y hệt nhau, khác biệt luôn nằm ở chỗ gắn.
• Quyền phải được tạo trong đúng account chứa tài nguyên. Cấp quyền ở account khác trong cùng organization không tự động lan sang.

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

Đề đặt ra tình huống: một SysOps Administrator cần audit các request tạo tài khoản AWS mới trong AWS Organizations, và người dùng của công ty đăng nhập vào AWS qua federation. Câu hỏi chốt lại rất hẹp: phải xem ở đâu để biết ai đã thực hiện request đó?

Hai cụm từ trong đề quyết định đáp án:

• "audit requests to AWS Organizations" — thứ cần tra là một lời gọi API tới một dịch vụ AWS (CreateAccount của AWS Organizations), không phải một trace ứng dụng, cũng không phải một sự kiện đăng nhập.
• "authenticate to AWS through federation" — đây là cái bẫy. Nó khiến người học nghĩ rằng danh tính nằm ở phía nhà cung cấp identity, nên phải quay về đó mà tìm. Nhưng câu hỏi không hỏi "ai đã đăng nhập", mà hỏi "ai đã thực hiện request".

Ghép hai ràng buộc lại: cần một nguồn log ghi lại hành động gọi API trong AWS và có kèm danh tính của federated user trong chính bản ghi đó.

✅ Vì sao đáp án đúng là đúng

D. AWS CloudTrail for the federated identity user name.

CloudTrail là dịch vụ ghi lại các lời gọi API trong tài khoản AWS, và AWS Organizations là dịch vụ có tích hợp với CloudTrail — nên hành động tạo tài khoản mới sẽ xuất hiện dưới dạng một event trong CloudTrail.

Điểm mấu chốt cho phần "federation": CloudTrail ghi lại các lời gọi AWS STS dùng để đổi danh tính bên ngoài lấy quyền tạm thời trong AWS, cụ thể là AssumeRoleWithWebIdentity và AssumeRoleWithSAML. Nhờ vậy, danh tính federated user được ghi lại và có thể đối chiếu sang chính event gọi API tới AWS Organizations. Nói cách khác, CloudTrail vừa trả lời được "hành động gì đã xảy ra", vừa trả lời được "danh tính nào đứng sau hành động đó" — đúng cả hai vế mà đề yêu cầu.

❌ Vì sao các phương án còn lại sai

A. AWS IAM Access Analyzer for the federated user name. Access Analyzer phục vụ mục đích khác hẳn: nó giúp phát hiện các tài nguyên trong tổ chức và trong tài khoản — ví dụ S3 bucket hay IAM role — đang được chia sẻ ra một thực thể bên ngoài. Đó là công cụ phân tích quyền truy cập trên tài nguyên, không phải công cụ ghi lại lịch sử ai đã gọi API nào. Nó không có khái niệm "request tạo account" để mà tra.

B. AWS X-Ray traces for the federated identity user name. X-Ray dùng để phân tích và gỡ lỗi các ứng dụng phân tán đang chạy production — theo dõi một request đi qua các thành phần của ứng dụng, tìm chỗ chậm, chỗ lỗi. Nó hoàn toàn không phải công cụ audit hoạt động quản trị tài khoản AWS. Chỉ cần thấy từ "audit" trong đề là có thể loại X-Ray.

C. Federated identity provider logs for the user name. Đây là phương án gần đúng nhất và là chỗ đáng dừng lại. Log của identity provider có ghi tên người dùng thật, nên thoạt nhìn có vẻ hợp lý. Nhưng nó hỏng ở chỗ: identity provider chỉ biết tới sự kiện xác thực — ai đã đăng nhập, lúc nào. Nó không nhìn thấy hành động bên trong AWS, nên không thể cho biết ai đã gọi request tạo tài khoản mới trong AWS Organizations. Ngoài ra, việc quay sang IdP còn là bước thừa: chính CloudTrail đã ghi kèm tên federated user trong bản ghi rồi, nên có đúng một nơi trả lời được cả câu hỏi thay vì phải ghép hai nguồn.

📌 Điểm cần nhớ

• Câu hỏi có dạng "ai đã thực hiện hành động X trong AWS" thì gần như luôn dẫn về CloudTrail — đó là nguồn ghi nhận lời gọi API của tài khoản.
• Federation không đẩy phần audit ra khỏi AWS. CloudTrail ghi các lời gọi STS (AssumeRoleWithSAML, AssumeRoleWithWebIdentity), nên danh tính federated user vẫn truy ngược được từ trong log của AWS.
• Phân biệt rõ ba vai trò dễ lẫn: CloudTrail = ai gọi API gì; IAM Access Analyzer = tài nguyên nào đang chia sẻ ra ngoài; X-Ray = gỡ lỗi hiệu năng ứng dụng phân tán.
• Khi một phương án bắt bạn đi tìm ở hệ thống bên ngoài AWS, hãy tự hỏi hệ thống đó có nhìn thấy hành động bên trong AWS không — log của IdP chỉ biết sự kiện đăng nhập, không biết API nào đã được gọi sau đó.