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

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

Một SysOps Administrator quản lý một đội EC2 instances rất lớn, sắp có sự kiện quan trọng, và cần biết instance nào của mình sẽ bị ảnh hưởng bởi đợt bảo trì phần cứng sắp tới.

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

• "upcoming hardware maintenance" — thông tin cần là bảo trì đã được lên lịch trong tương lai, không phải trạng thái hiện tại và cũng không phải sự cố đã xảy ra rồi.
• "any instances will be affected" — cần biết tài nguyên cụ thể của tài khoản này bị ảnh hưởng, tức là thông tin mang tính cá nhân hoá theo account, không phải bản tin chung của toàn dịch vụ.
• "LEAST administrative overhead" — loại thẳng mọi phương án đòi cài đặt, triển khai hay tự dựng cơ chế theo dõi trên hàng loạt máy.

Ba ràng buộc này ghép lại chỉ khớp với một thứ: bảng điều khiển sức khoẻ theo tài khoản, có mục sự kiện đã lên lịch.

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

C — Review the Personal Health Dashboard for any scheduled maintenance.

Personal Health Dashboard (AWS Health) đưa ra cảnh báo và hướng dẫn xử lý cho những sự kiện AWS có ảnh hưởng trực tiếp tới bạn. Khác với bản tin chung, nó cho một góc nhìn được cá nhân hoá về tình trạng và khả năng sẵn sàng của các dịch vụ AWS nằm dưới chính các tài nguyên trong tài khoản bạn.

Đúng với ba ràng buộc của đề:

• Nó hiển thị các hoạt động đã được lên lịch (scheduled activities) và gửi thông báo mang tính chủ động (proactive) để bạn kịp lên kế hoạch — đúng thứ "upcoming hardware maintenance" mà đề hỏi.
• Cảnh báo được kích hoạt bởi thay đổi sức khoẻ của chính tài nguyên AWS của bạn, nên Administrator biết được instance nào trong đội của mình dính bảo trì.
• Đây là thứ có sẵn, chỉ cần mở ra xem — không phải cài agent, không phải viết pipeline, không phải quản trị thêm gì. Đó chính là "LEAST administrative overhead".

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

A — View any planned maintenance in the AWS Service Health Dashboard. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi, vì tên gọi rất giống đáp án đúng. Nhưng Service Health Dashboard là bản tin chung cho toàn bộ khách hàng, phản ánh tình trạng hiện tại của các dịch vụ AWS theo region — nó không trình bày các hoạt động bảo trì đã lên lịch, và quan trọng hơn, nó không biết bạn có tài nguyên nào. Dù có đọc, Administrator vẫn không trả lời được câu hỏi "instance nào của tôi bị ảnh hưởng". Hỏng ở cả hai điểm: sai loại thông tin (hiện tại thay vì đã lên lịch) và sai phạm vi (chung thay vì cá nhân hoá).

B — Deploy the CloudWatch agent on all instances and monitor availability. Sai ở cả hai ràng buộc còn lại. CloudWatch agent thu thập metric và log từ bên trong hệ điều hành; nó hoàn toàn không có cách nào biết được AWS dự định bảo trì phần cứng gì. Cùng lắm nó cho biết máy đã ngừng phục vụ — tức là báo sau khi sự cố xảy ra, trong khi đề cần biết trước để chuẩn bị cho sự kiện. Thêm nữa, "deploy trên tất cả instances" của một đội lớn là administrative overhead cao nhất trong cả bốn phương án, đi ngược đúng từ khoá "LEAST" của đề.

D — Monitor AWS CloudTrail for any StopInstances API calls that are issued. CloudTrail ghi lại lời gọi API đã xảy ra, bản chất là nhật ký kiểm toán nhìn về quá khứ. Theo dõi StopInstances chỉ cho biết máy đã bị tắt vào lúc nào và do ai/cái gì gọi — hoàn toàn phản ứng chứ không dự báo. Nó không giúp gì cho việc lên kế hoạch trước cho sự kiện quan trọng sắp tới, mà lập cả cơ chế theo dõi log liên tục cũng tốn công hơn việc mở một dashboard có sẵn.

📌 Điểm cần nhớ

• Phân biệt hai dashboard bằng chữ "Personal": Service Health Dashboard = tình trạng chung, hiện tại của dịch vụ AWS; Personal Health Dashboard = sự kiện ảnh hưởng tới chính tài nguyên trong tài khoản bạn, gồm cả bảo trì đã lên lịch. Đề nào có chữ "my resources", "affect my instances", "scheduled maintenance" thì chọn Personal.
• Nhìn hướng thời gian của công cụ: CloudTrail và CloudWatch đều nhìn về sau/hiện tại (đã gọi API, đang chạy thế nào). Câu hỏi về việc chuẩn bị trước cho sự kiện tương lai thì cả hai đều trượt, dù chúng nghe rất "monitoring".
• "LEAST administrative overhead" là bộ lọc mạnh: phương án nào bắt đầu bằng "Deploy… on all instances" hay đòi dựng cơ chế thu thập riêng thường bị loại ngay, ngay cả khi về lý thuyết nó có thể ra kết quả.
• CloudWatch agent chỉ thấy từ trong OS ra, không thấy gì về kế hoạch vận hành hạ tầng vật lý của AWS — đừng chọn nó cho các câu hỏi về maintenance, retirement hay sự kiện phía nền tảng.

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

Đề mô tả một tình huống vận hành rất cụ thể: một Amazon Aurora DB instance chuyển sang trạng thái inaccessible-encryption-credentials và không truy cập được nữa. Câu hỏi không hỏi "phải làm gì" mà hỏi nguyên nhân của trạng thái đó.

Cụm từ quyết định đáp án nằm ngay trong chính tên trạng thái: encryption-credentials. Đây không phải mô tả do người ra đề nghĩ ra — nó là một giá trị DBInstanceStatus có thật của RDS/Aurora, và mỗi giá trị trạng thái ánh xạ tới đúng một loại sự kiện. Hai chữ encryption credentials nghĩa là "thông tin dùng để mã hoá/giải mã", tức là KMS key gắn với DB instance đã mã hoá. Còn inaccessible nghĩa là RDS không gọi được tới key đó.

Đây chính là mẹo phân biệt: cả bốn phương án đều nói về những sự kiện có thật trên RDS, nhưng mỗi sự kiện lại tạo ra một status khác nhau. Ai đọc tên status theo nghĩa đen sẽ chọn đúng ngay; ai chỉ nhớ "instance không truy cập được" thì bốn phương án đều hợp lý như nhau.

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

A — "The AWS KMS key used to encrypt or decrypt the DB instance can't be accessed" là đáp án đúng.

Với một DB instance được mã hoá, RDS phải gọi được KMS key để giải mã dữ liệu ở tầng lưu trữ. Khi key đó không dùng được nữa — bị disable, bị lên lịch xoá, key policy hoặc quyền của RDS bị sửa mất, hay key thuộc tài khoản khác và quyền chia sẻ bị thu hồi — RDS mất khả năng thao tác trên volume đã mã hoá và đặt instance vào trạng thái inaccessible-encryption-credentials.

Lỗi thường lộ ra vào những thời điểm RDS cần chạm lại vào dữ liệu mã hoá: host EC2 bên dưới thay đổi vì bất kỳ lý do gì, RDS ghi log để phục vụ point-in-time restore về sau, hoặc automated backups đang bật. Nghĩa là key có thể đã hỏng từ trước mà instance vẫn chạy, đến khi có sự kiện nói trên mới sập.

Cách hồi phục là restore từ backup hoặc point-in-time restore — nhưng bản thân thao tác restore vẫn cần chính KMS key gốc còn dùng được. Đây là điểm khiến lỗi này nguy hiểm: nếu key đã bị xoá hẳn (qua hết thời gian chờ), dữ liệu không lấy lại được.

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

B — "Enhanced Monitoring is being enabled or disabled for this DB instance"
Bật/tắt Enhanced Monitoring là một thay đổi cấu hình có thật và instance đúng là chuyển trạng thái trong lúc đó, nhưng trạng thái tương ứng là configuring-enhanced-monitoring, không phải inaccessible-encryption-credentials. Đây là trạng thái tạm thời của một thao tác đang chạy, tự hết khi xong — khác hẳn một trạng thái lỗi khiến DB không truy cập được. Phương án này chẳng liên quan gì tới mã hoá.

C — "AWS IAM database authentication is being enabled or disabled for this DB instance"
Đây là phương án gần đúng nhất và dễ bẫy nhất, vì IAM database authentication có dính tới "credentials" — nó cho phép đăng nhập database bằng token IAM thay vì mật khẩu. Nhưng "credentials" ở đây là thông tin đăng nhập của người/ứng dụng, còn encryption-credentials trong đề là khoá mã hoá dữ liệu. Hai thứ hoàn toàn khác nhau. Việc bật/tắt IAM database authentication tạo ra status configuring-iam-database-auth, và cũng chỉ là trạng thái quá độ.

D — "The DB instance has reached its storage capacity allocation"
Hết dung lượng lưu trữ đúng là làm database ngừng phục vụ được, nên nghe rất hợp với vế "đã trở nên không truy cập được" trong đề. Nhưng RDS có status riêng cho nó: storage-full. Ngoài ra nguyên nhân này không dính gì tới mã hoá, nên không giải thích được chữ encryption-credentials. Đây là kiểu phương án đúng triệu chứng nhưng sai chẩn đoán.

📌 Điểm cần nhớ

• Tên DBInstanceStatus của RDS/Aurora tự nó là câu trả lời. Các trạng thái được đặt tên theo đúng nguyên nhân: storage-full, configuring-enhanced-monitoring, configuring-iam-database-auth, inaccessible-encryption-credentials. Gặp câu hỏi dạng "status X nghĩa là gì", hãy dịch nghĩa đen tên status trước khi suy luận.
• Phân biệt trạng thái quá độ với trạng thái lỗi. Những status bắt đầu bằng configuring- là thao tác đang chạy và sẽ tự kết thúc; inaccessible-encryption-credentials là lỗi thật, DB không phục vụ được cho tới khi có can thiệp.
• "Credentials" trong AWS có hai nghĩa hoàn toàn khác nhau: khoá mã hoá dữ liệu (KMS) và thông tin đăng nhập (IAM database authentication). Đề đánh vào đúng chỗ mập mờ này.
• Vòng đời KMS key quyết định vòng đời của DB instance đã mã hoá. Disable, lên lịch xoá, hay sửa key policy làm mất quyền của RDS đều đủ để khoá cả database — và việc restore để cứu vẫn cần chính key gốc đó còn dùng được. Trước khi đụng vào một KMS key, phải biết những resource nào đang phụ thuộc vào nó.

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

Đề mô tả một portfolio của AWS Service Catalog được chủ sở hữu (owner) chia sẻ sang một tài khoản AWS thứ hai, và tài khoản thứ hai do một SysOps Administrator khác quản lý. Câu hỏi: người quản trị của tài khoản nhận (recipient) làm được việc gì?

Cụm từ quyết định nằm ở chữ "shared" và "the owner of the portfolio". Trong Service Catalog, chia sẻ portfolio không phải là sao chép — portfolio bên tài khoản nhận là một bản imported, và quyền sở hữu vẫn thuộc về tài khoản gốc. Từ đó suy ra ranh giới quyền: recipient chỉ được tiêu thụ và tham chiếu, còn mọi thao tác thay đổi cấu trúc hay ràng buộc của portfolio gốc đều thuộc về owner. Bốn phương án được viết ra đúng để thử xem người học có phân biệt được ranh giới đó không: ba phương án là hành vi sửa đổi imported portfolio, một phương án là hành vi tham chiếu sang portfolio riêng.

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

Đáp án đúng theo tệp là C — "Add a product from the imported portfolio to a local portfolio".

Administrator của tài khoản nhận được phép lấy một product từ imported portfolio và đưa nó vào local portfolio của chính mình. Đây là thao tác nằm hoàn toàn trong phạm vi tài khoản nhận: họ đang tạo/sửa portfolio của họ, chứ không đụng vào portfolio được chia sẻ. Nhờ vậy recipient có thể tự tổ chức lại danh mục, gán tag, gán quyền cho người dùng nội bộ theo cách riêng của mình.

Điểm quan trọng mà phần giải thích gốc nhấn mạnh: product được thêm vào local portfolio vẫn đồng bộ (stay in sync) với portfolio chia sẻ. Nghĩa là khi owner cập nhật product, thay đổi lan sang; recipient không nhận được một bản sao độc lập để tự ý sửa. Đây chính là mô hình "phân phối tập trung, tiêu thụ phân tán" của Service Catalog.

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

A — Add new products to the imported portfolio. Sai. Imported portfolio thuộc quyền sở hữu của tài khoản gốc, recipient không được upload hay thêm product vào đó. Đây là phương án dễ nhầm nhất với C, vì cả hai đều là "thêm product". Khác biệt nằm ở đích đến: thêm vào local portfolio thì được, thêm vào imported portfolio thì không. Đọc lướt qua chữ "add" mà bỏ qua danh từ đứng sau là mất điểm.

B — Change the launch role for the products contained in the imported portfolio. Sai. Launch role được áp qua launch constraint, và constraint là một phần cấu hình của portfolio gốc. Recipient administrator không thể thêm hoặc gỡ launch constraint trên imported portfolio. Điều này cũng hợp lý về mặt bảo mật: nếu recipient tự đổi được launch role, họ sẽ tự nâng quyền cho các resource mà owner đã cố ý giới hạn — đúng thứ mà mô hình chia sẻ phải chặn.

D — Remove products from the imported portfolio. Sai, và sai theo cùng lý do với A nhưng ở chiều ngược lại. Recipient không được xoá product khỏi imported portfolio. Họ chỉ có thể ngừng dùng, hoặc không đưa product đó vào local portfolio của mình — nhưng nội dung của portfolio chia sẻ thì do owner quyết định.

📌 Điểm cần nhớ

• Chia sẻ portfolio trong Service Catalog không chuyển quyền sở hữu: tài khoản nhận có bản imported, mọi thay đổi cấu trúc (thêm/xoá product, sửa constraint) vẫn nằm ở tài khoản owner.
• Recipient administrator chỉ được làm việc trong phạm vi tài khoản mình: thêm product từ imported portfolio vào local portfolio, rồi phân quyền cho người dùng nội bộ.
• Product đã thêm vào local portfolio vẫn đồng bộ với bản gốc — đây là cơ chế cố ý, để owner giữ được quyền kiểm soát phiên bản chuẩn.
• Launch constraint / launch role thuộc về owner. Gặp phương án nào cho phép recipient đổi launch role trên portfolio được chia sẻ thì loại ngay — nó phá vỡ chính mục đích bảo mật của việc chia sẻ.
• Với dạng câu này, hãy đọc kỹ danh từ đứng sau động từ: "add to imported portfolio" và "add to local portfolio" là hai quyền hoàn toàn khác nhau.

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

Đề mô tả một hệ thống chạy phân tích dữ liệu tài chính vài giờ mỗi đêm, 5 ngày/tuần, kéo dài tối thiểu 1 năm, và nhấn mạnh rằng công việc "cannot be interrupted once it is started".

Nhưng cụm từ quyết định nằm ở chính câu hỏi: "What should a sysops administrator configure to ensure the EC2 instances are available when they are needed?"

Từ khoá là available — tức là đảm bảo có capacity để khởi chạy instance vào đúng khung giờ cần, chứ không phải "giảm chi phí" hay "tối ưu hoá giá". Đây chính là ranh giới phân biệt bốn phương án: ba trong số đó là mô hình thanh toán / chiết khấu giá, chỉ một là cơ chế giữ chỗ capacity thật sự. Chi tiết "tối thiểu 1 năm" là mồi nhử kéo người học về phía cam kết 1 năm của Reserved Instances hoặc Savings Plans.

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

Đáp án đúng theo tệp là C — On-Demand Capacity Reservations.

On-Demand Capacity Reservations cho phép đặt trước capacity tính toán cho EC2 trong một Availability Zone cụ thể, với thời lượng tuỳ ý. Đây là cơ chế duy nhất trong danh sách thực sự giữ phần cứng lại cho bạn: khi tới giờ chạy phân tích ban đêm, instance chắc chắn khởi chạy được vì capacity đã được dành sẵn, không phải cạnh tranh với các khách hàng khác trong AZ đó.

Hai đặc điểm khác cũng khớp với đề:

• Capacity Reservation tạo và huỷ được bất kỳ lúc nào, không đòi cam kết theo kỳ hạn 1 hay 3 năm, và capacity có hiệu lực gần như ngay lập tức — phù hợp với mô hình chạy theo cửa sổ thời gian cố định hằng đêm.
• Nó độc lập với phần chiết khấu giá: có thể dùng riêng, hoặc kết hợp với Savings Plans / Regional Reserved Instances để vừa có capacity vừa có giá tốt. Nói cách khác, nó giải đúng bài toán "available", còn chuyện tiền là chuyện khác.

Vì công việc không được phép gián đoạn, việc đảm bảo instance khởi chạy được ngay từ đầu và không bị thiếu capacity là yêu cầu cốt lõi — và đó chính xác là thứ Capacity Reservations cung cấp.

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

A — Regional Reserved Instances. Đây là phương án gần đúng nhất và cũng là bẫy nặng nhất, vì chữ "Reserved" nghe như đang giữ chỗ. Thực tế Reserved Instances ở phạm vi Region chỉ mang lại chiết khấu thanh toán khi đổi lấy cam kết sử dụng dài hạn; nó không reserve capacity. Chi tiết "tối thiểu 1 năm" trong đề càng làm phương án này hấp dẫn, nhưng câu hỏi hỏi về tính sẵn sàng chứ không hỏi về giá. (Cần phân biệt: chỉ loại Reserved Instance gắn với một Availability Zone cụ thể mới đi kèm capacity reservation — bản Regional thì không, và đề ghi rõ "Regional".)

B — On-Demand Instances. Đây là hành vi mặc định: bạn xin instance lúc nào thì AWS cấp lúc đó nếu còn capacity. Không có bất kỳ sự đảm bảo nào trước. Đúng vào khung giờ cao điểm mà AZ hết capacity, lệnh khởi chạy sẽ thất bại (InsufficientInstanceCapacity) và công việc phân tích ban đêm không chạy được. Chọn phương án này là bỏ trống hẳn yêu cầu của đề.

C — On-Demand Capacity Reservations. Đáp án đúng, đã giải thích ở trên.

D — Savings Plans. Cũng là một mô hình giảm giá thuần tuý: bạn cam kết một mức chi tiêu tính theo giờ trong 1 hoặc 3 năm để đổi lấy đơn giá thấp hơn. Savings Plans linh hoạt hơn Reserved Instances về loại instance và Region, nhưng linh hoạt về giá, không phải về capacity — nó không giữ chỗ gì cả. Instance của bạn vẫn khởi chạy theo cơ chế On-Demand thông thường và vẫn có thể gặp cảnh không còn capacity.

📌 Điểm cần nhớ

• Phân biệt rạch ròi hai nhóm khái niệm trong EC2: cơ chế chiết khấu giá (Regional Reserved Instances, Savings Plans) và cơ chế đảm bảo capacity (On-Demand Capacity Reservations, Zonal Reserved Instances). Trong đề thi, hai nhóm này gần như luôn được trộn chung để làm nhiễu.
• Đọc kỹ động từ mục tiêu của câu hỏi: "ensure availability / guarantee capacity" → chọn Capacity Reservation; "reduce cost / lowest cost" → chọn Savings Plans hoặc Reserved Instances.
• Chữ "Reserved" trong Regional Reserved Instances không có nghĩa là giữ chỗ phần cứng — chỉ bản gắn với một AZ cụ thể mới đi kèm capacity.
• On-Demand Capacity Reservations không đòi cam kết kỳ hạn và kết hợp được với Savings Plans hay Reserved Instances, nên khi đề vừa cần đảm bảo capacity vừa nhắc tới cam kết dài hạn, hai thứ đó không loại trừ nhau.

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

Đề mô tả một hệ thống production chạy Amazon RDS for MySQL (db.m6g.xlarge, Multi-AZ) và người dùng liên tục gặp lỗi "too many connections" — tức số kết nối đồng thời tới database đã chạm trần mà instance cho phép. Câu hỏi yêu cầu chọn giải pháp quản lý kết nối.

Cụm từ quyết định đáp án nằm ở câu thứ hai: "while keeping code changes to a minimum and optimizing cost" — tối thiểu thay đổi mã nguồn và tối ưu chi phí. Đây chính là ràng buộc phân biệt bốn phương án, vì cả bốn đều "có lý" ở mức độ nào đó nếu chỉ nhìn riêng vấn đề kỹ thuật:

• Có phương án giải quyết được kết nối nhưng phải sửa mã nhiều (C).
• Có phương án không sửa mã nhưng tốn tiền và không chạm vào gốc vấn đề (A, D).

Thêm một chi tiết nữa: lỗi là "too many connections", tức vấn đề nằm ở số lượng kết nối, không phải ở CPU, RAM hay throughput đọc. Phương án nào không làm giảm số kết nối thực tế đi tới DB instance thì không giải quyết đúng triệu chứng đề nêu.

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

Đáp án đúng là B — Implement an RDS Proxy.

RDS Proxy là dịch vụ proxy database do AWS quản lý hoàn toàn, đứng giữa ứng dụng và RDS instance. Nó duy trì một connection pool dùng chung: nhiều kết nối từ phía ứng dụng được gom lại và tái sử dụng trên một số lượng nhỏ hơn nhiều các kết nối thật tới database. Nhờ đó, tổng số kết nối mà RDS for MySQL phải chịu giảm xuống, và lỗi "too many connections" được giải quyết đúng ở gốc.

Về ràng buộc trong đề:

• Ít thay đổi mã: ứng dụng chỉ cần trỏ chuỗi kết nối sang RDS Proxy endpoint thay vì endpoint của DB instance. Đây là thay đổi ở file cấu hình, không phải viết lại logic quản lý kết nối trong mã.
• Tối ưu chi phí: không phải nâng cấp instance lên cỡ lớn hơn, cũng không phải dựng thêm các instance read replica.

Ngoài ra RDS Proxy là managed service nên phần vận hành pool (theo dõi, xử lý kết nối chết, failover) do AWS lo, không phải công việc của đội vận hành.

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

A — Nâng instance lên cỡ lớn hơn (nhiều CPU và memory hơn). Đây là phương án gần đúng nhất về mặt trực giác, vì trên MySQL trong RDS giới hạn kết nối tối đa thường được suy ra từ dung lượng bộ nhớ của instance, nên máy to hơn quả thật cho phép nhiều kết nối hơn. Nhưng nó hỏng ở hai chỗ so với đề: (1) nó chỉ nới trần chứ không quản lý kết nối — ứng dụng vẫn mở kết nối vô tội vạ, tải tăng thêm chút nữa là lỗi quay lại; (2) nó đi ngược thẳng yêu cầu "optimizing cost", vì instance lớn hơn tốn tiền thường trực, lại còn nhân đôi do đang chạy Multi-AZ.

C — Tự viết connection pooling ở tầng ứng dụng. Về mặt kỹ thuật đây là hướng đúng bản chất — pooling chính là thứ cần. Nhưng nó vi phạm đúng ràng buộc đề nhấn mạnh: "keeping code changes to a minimum". Cài đặt pooling trong mã nghĩa là sửa lớp truy cập dữ liệu, kiểm thử lại, và làm việc đó ở mọi ứng dụng/instance đang kết nối tới database. Mỗi tiến trình ứng dụng lại giữ pool riêng của nó, nên khi số instance ứng dụng tăng lên thì tổng kết nối tới DB vẫn phình ra — pool cục bộ không nhìn thấy nhau. RDS Proxy thì gom ở một chỗ tập trung.

D — Thêm read replica để chia tải kết nối. Read replica giúp phân tán tải đọc, không phải công cụ quản lý kết nối. Muốn dùng được, ứng dụng phải biết tách truy vấn đọc sang endpoint của replica và ghi vào primary — đó lại là thay đổi mã, đúng thứ đề muốn tránh. Kết nối ghi vẫn dồn hết về primary nên lỗi "too many connections" trên primary không mất đi. Thêm vào đó, mỗi replica là một instance phải trả tiền, nên phương án này vừa tăng chi phí vừa tăng độ phức tạp kiến trúc mà không nhắm vào đúng vấn đề.

📌 Điểm cần nhớ

• Thấy lỗi "too many connections" trên RDS/Aurora, phản xạ đầu tiên là RDS Proxy — nó sinh ra chính để gom và tái sử dụng kết nối.
• Ràng buộc "minimal code changes" thường loại phương án "tự cài pooling trong ứng dụng" và phương án "tách đọc/ghi sang read replica", vì cả hai đều buộc sửa mã; đổi endpoint trong file cấu hình sang RDS Proxy thì không.
• Scale up (instance lớn hơn) chỉ nới trần chứ không sửa hành vi mở kết nối, và luôn xung đột với yêu cầu tối ưu chi phí — càng rõ khi hệ thống chạy Multi-AZ.
• Phân biệt đúng triệu chứng: read replica giải bài toán tải đọc, RDS Proxy giải bài toán số lượng kết nối. Đọc kỹ lỗi đề nêu để chọn đúng công cụ.

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

Một tập đoàn quản lý nhiều tài khoản AWS bằng AWS Organizations. Quy định nội bộ chỉ cho phép lưu trữ và xử lý dữ liệu khách hàng ở một số Region nhất định. Nhiệm vụ của SysOps administrator là ngăn bất kỳ ai trong công ty khởi tạo EC2 instance ở Region không được duyệt.

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

• "manages several AWS accounts using AWS Organizations" — bối cảnh là nhiều tài khoản, có sẵn Organizations. Giải pháp nào phải cấu hình lặp lại "in each AWS account" đều thua về mặt vận hành.
• "is prohibited" — yêu cầu là ngăn chặn, tức là chặn trước khi hành động xảy ra, chứ không phải phát hiện rồi dọn dẹp sau.
• "most efficient operational solution" — không hỏi "cách nào chạy được", mà hỏi cách tốn ít công vận hành nhất. Đây chính là ràng buộc phân biệt các phương án trông na ná nhau.

Ba cụm này gộp lại chỉ về đúng một thứ: một chốt chặn tập trung, phòng ngừa, đặt ở cấp tổ chức.

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

Đáp án đúng theo tệp là D — tạo service control policy (SCP) trong AWS Organizations chặn ec2:RunInstances ở các Region không tuân thủ, rồi gắn SCP đó vào root của organization.

SCP là công cụ đặt trần quyền tối đa (maximum available permissions) cho mọi tài khoản nằm trong AWS Organization. Nó không tự cấp quyền cho ai, mà quy định giới hạn: dù IAM policy trong tài khoản con có cho phép rộng đến đâu, hành động vẫn bị từ chối nếu SCP không cho phép.

Điểm khớp với đề:

• Gắn ở root level nghĩa là áp một lần, có hiệu lực xuống toàn bộ tài khoản trong organization — kể cả tài khoản được thêm vào sau này. Đúng nghĩa "most efficient operational": một lần cấu hình, không phải lặp lại theo từng account.
• Điều kiện Region trong SCP khiến ec2:RunInstances bị từ chối ngay tại thời điểm gọi API ở Region ngoài danh sách. Instance không bao giờ được tạo ra, nên thoả yêu cầu "prohibited" chứ không phải "dọn dẹp sau".

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

A — IAM role có Region condition, gắn vào mọi EC2 instance trong từng account. Đây là phương án gần đúng nhất và cũng là cái bẫy chính. Điều kiện Region trong policy thì đúng là dùng được, nhưng cách triển khai sai ở hai chỗ. Thứ nhất, gắn role vào EC2 instance là gán quyền cho ứng dụng chạy bên trong instance đó — nó không hề ràng buộc con người hay công cụ đang gọi RunInstances để tạo instance ngay từ đầu. Thứ hai, kể cả gắn đúng cho principal, vẫn phải cấu hình lặp lại trong từng AWS account, và một quản trị viên có quyền IAM ở tài khoản con có thể tự gỡ ra — SCP thì họ không gỡ được.

B — CloudWatch giám sát mọi Region, SNS topic cho sự kiện ec2:RunInstances, Step Functions terminate instance. Về kỹ thuật thì chạy được, nhưng nó phản ứng chứ không phòng ngừa: instance đã thực sự khởi tạo trong Region cấm rồi mới bị huỷ. Trong khoảng thời gian đó, dữ liệu khách hàng đã có thể được xử lý sai địa điểm — đúng thứ mà quy định muốn tránh. Ngoài ra phải dựng và duy trì hạ tầng giám sát ở mọi Region, trái hẳn với tiêu chí "most efficient operational".

C — bucket policy trên S3 từ chối ec2:RunInstances. Sai hoàn toàn về đối tượng áp dụng. Bucket policy là resource-based policy gắn vào bucket S3, chỉ chi phối các hành động thao tác trên chính bucket đó. Nó không có bất kỳ ảnh hưởng nào lên EC2 API; viết ec2:RunInstances vào bucket policy là câu lệnh vô nghĩa, không chặn được gì.

📌 Điểm cần nhớ

• Khi đề nhắc AWS Organizations cùng yêu cầu áp một quy tắc lên mọi tài khoản, SCP gắn ở root (hoặc ở OU) gần như luôn là đáp án cho "most operationally efficient" — cấu hình một lần, phủ cả tổ chức, kể cả account mới.
• Phân biệt preventive và detective/reactive: đề dùng từ "prevent", "prohibit", "block" thì chọn cơ chế chặn tại API call (SCP, IAM deny). Các mô hình "phát hiện rồi tự động sửa" (CloudWatch/EventBridge + hành động khắc phục) chỉ đúng khi đề chấp nhận hoặc yêu cầu remediation sau sự việc.
• SCP giới hạn quyền chứ không cấp quyền. Quyền thực thi cuối cùng là phần giao giữa SCP và IAM policy — và SCP nằm ngoài tầm sửa đổi của quản trị viên tài khoản con, nên bền hơn IAM policy đặt rải rác.
• IAM role gắn vào EC2 instance chi phối những gì ứng dụng trong instance được làm, không chi phối được ai được phép tạo ra instance. Đọc kỹ chỗ policy được gắn vào đâu, không chỉ đọc nội dung policy.

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

Đề mô tả một đội EC2 instance chạy trong EC2 Auto Scaling group, và yêu cầu: đẩy log nằm sẵn trên máy (local logs) lên CloudWatch, đồng thời minimize operational overhead.

Có hai cụm từ quyết định đáp án, và phải dùng cả hai:

• "send local logs to CloudWatch" — việc cần làm là thu thập log file trong hệ điều hành của instance, chứ không phải thu thập metric, không phải ghi lại thay đổi cấu hình của tài nguyên AWS, cũng không phải quét lỗ hổng. Cụm này loại thẳng những phương án không hề đụng tới log file.
• "minimize operational overhead" — trong số các cách về mặt kỹ thuật vẫn đẩy được log lên, phải chọn cách AWS đã dựng sẵn và duy trì hộ, thay vì cách tự viết rồi tự nuôi. Cụm này là thứ phân biệt phương án đúng với phương án "vẫn chạy được nhưng sai tinh thần đề".

Thêm một chi tiết đáng chú ý: instance nằm trong Auto Scaling group, tức là máy sinh ra và bị huỷ liên tục. Bất cứ giải pháp nào đòi thao tác thủ công trên từng máy đều nhân lên theo số lần scale.

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

D — Install and configure the unified CloudWatch agent.

Unified CloudWatch agent chính là thành phần AWS cung cấp để làm đúng việc đề nêu. Theo tài liệu:

• Thu thập log từ EC2 instance và cả server on-premises, chạy được trên cả Linux lẫn Windows Server.
• Thu thập thêm system-level metrics ở mức trong máy (in-guest metrics), ngoài các metric mà EC2 vốn đã có.
• Nhận custom metrics từ ứng dụng qua giao thức StatsD và collectd.

Agent này được cài và cấu hình bằng một file cấu hình khai báo đường dẫn log cần theo dõi; sau đó nó tự lo phần đọc file, gửi lên CloudWatch Logs, xử lý những chuyện lặt vặt như nhớ vị trí đã đọc tới đâu. Với Auto Scaling group, agent hoàn toàn nằm trong image hoặc trong bước khởi tạo instance, nên máy mới bật lên là log tự chảy về — đúng nghĩa "minimize operational overhead": không có mã tự viết nào để bảo trì, không có gì phải sửa mỗi lần đội máy thay đổi.

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

A — Install and configure the Amazon Inspector agent. Đây là bẫy "cũng là một agent cài lên EC2", nên nhìn thoáng qua rất giống D. Nhưng Amazon Inspector phục vụ mục đích khác hẳn: nó đánh giá tài nguyên AWS theo tiêu chuẩn bảo mật và best practice, rồi báo cáo kết quả đó. Nó không thu thập log file của hệ điều hành và không đẩy chúng vào CloudWatch Logs. Cài đúng agent nhưng sai loại agent thì yêu cầu chính của đề vẫn không được đáp ứng.

B — Configure AWS Config to forward events to CloudWatch. AWS Config theo dõi cấu hình của tài nguyên AWS và thay đổi của cấu hình đó theo thời gian. Thứ nó sinh ra là bản ghi về trạng thái tài nguyên, không phải nội dung log nằm trong đĩa của instance. Đề hỏi local logs — những file do hệ điều hành và ứng dụng ghi ra bên trong máy — mà AWS Config không hề nhìn thấy tầng đó. Phương án này sai ngay ở bản chất dịch vụ, không cứu được bằng cách cấu hình khéo.

C — Create a script that forwards events to CloudWatch. Đây là phương án gần đúng nhất, và cũng là lý do cụm "minimize operational overhead" tồn tại trong đề. Về mặt kỹ thuật, một script tự viết gọi API của CloudWatch vẫn đẩy được log lên thật. Chỗ nó hỏng là ở vế thứ hai của yêu cầu: script phải được viết, kiểm thử, phân phối tới từng instance, rồi bảo trì mãi về sau — thêm đường dẫn log mới, xử lý lỗi mạng, nhớ vị trí đọc dở, cập nhật khi hệ điều hành đổi. Trong một Auto Scaling group thì gánh nặng đó còn nhân lên theo mỗi máy sinh ra. Nói cách khác, C không sai về khả năng, mà sai vì tự viết lại thứ AWS đã làm sẵn và duy trì hộ trong phương án D.

📌 Điểm cần nhớ

• Local log của EC2 → unified CloudWatch agent. Đây là ánh xạ mặc định nên thuộc lòng. Agent này gom được cả log lẫn in-guest metrics, và chạy trên cả Linux, Windows Server lẫn server on-premises.
• Phân biệt các dịch vụ theo "nó nhìn thấy tầng nào". AWS Config nhìn cấu hình tài nguyên AWS; Amazon Inspector nhìn tình trạng tuân thủ và bảo mật; chỉ có CloudWatch agent nhìn được vào bên trong hệ điều hành để đọc file log.
• Cụm "minimize operational overhead" gần như luôn loại phương án tự viết script. Khi đề có cụm này và trong danh sách có cả một dịch vụ/agent quản lý sẵn lẫn một script thủ công, chọn cái được quản lý sẵn.
• Auto Scaling group là tín hiệu ngầm cùng hướng. Máy sinh ra và bị huỷ liên tục, nên mọi thao tác thủ công trên từng máy đều bị nhân lên; giải pháp đúng phải là thứ cài sẵn một lần rồi tự hoạt động với mọi instance mới.

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

Đề nêu tình huống: quản lý một nhóm SysOps muốn bảo đảm rằng các Administrators không vô tình (accidentally) hủy (terminate) một số EC2 instance quan trọng.

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

• "accidentally" — đây là bài toán chống thao tác nhầm, không phải bài toán phân quyền hay chống người dùng có ý đồ xấu. Nếu đề muốn cấm hẳn một nhóm người không được quyền terminate thì đó sẽ là chuyện của IAM policy. Ở đây người thực hiện là Administrators — họ có quyền terminate và vẫn cần giữ quyền đó; thứ cần chặn chỉ là cú bấm nhầm.
• "several critical Amazon EC2 instances" — biện pháp phải áp được ở mức từng instance cụ thể, chỉ cho vài máy quan trọng, chứ không phải một chính sách chung cho cả tài khoản.

Ghép lại: cần một cơ chế bật trực tiếp trên chính EC2 instance, chặn được lệnh terminate ngay tại nguồn, và bật/tắt được cho từng máy riêng lẻ.

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

B — Enable termination protection on the EC2 instances.

EC2 có sẵn thuộc tính termination protection, tương ứng với attribute DisableApiTermination của instance. Khi bật, instance đó không thể bị terminate qua console, CLI hay API — lệnh terminate bị từ chối cho tới khi ai đó cố ý tắt thuộc tính này đi trước.

Đây chính là hình dạng của yêu cầu trong đề:

• Nó tạo ra một bước xác nhận có chủ ý: muốn xóa thật thì phải tắt protection rồi mới terminate được. Cú bấm nhầm một bước sẽ thất bại.
• Nó gắn vào từng instance, nên chỉ cần bật cho mấy máy critical, các instance khác vẫn terminate bình thường.
• Nó không đụng tới quyền IAM của Administrators — họ vẫn là admin, vẫn làm được mọi việc, chỉ là hành động hủy máy quan trọng không còn xảy ra chỉ bằng một thao tác.

Theo tài liệu, mặc định termination protection tắt, và có thể đặt giá trị lúc launch instance, lúc instance đang chạy, hoặc lúc instance đang stopped (với instance dùng EBS-backed root volume). Nghĩa là áp lên các máy critical đang chạy sẵn cũng được, không cần dựng lại gì.

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

A — Use CloudTrail to restrict the terminate-instances API call. Đây là phương án đánh lừa bằng cách gọi đúng tên API cần chặn (TerminateInstances), khiến nó nghe rất sát đề. Nhưng CloudTrail không hề có khả năng chặn bất cứ lời gọi API nào — nó là dịch vụ ghi lại (audit) hoạt động API: ai gọi, gọi cái gì, lúc nào, từ đâu. CloudTrail nằm ở phía sau hành động: khi bản ghi xuất hiện thì instance đã bị hủy rồi. Nó giúp điều tra sau sự cố, không ngăn được sự cố.

C — Use AWS Config to restrict EC2 termination. Phương án gần đúng nhất và đáng nói kỹ. AWS Config là dịch vụ đánh giá tuân thủ cấu hình: nó theo dõi cấu hình tài nguyên và chấm xem có hợp quy tắc hay không. Config có liên quan tới chủ đề này — nó có thể kiểm tra xem termination protection đã được bật hay chưa trên các instance, và báo non-compliant cho máy nào chưa bật. Nhưng chỗ nó hỏng so với đề: Config không tự bật được termination protection và không chặn được lệnh terminate. Nó là lớp giám sát chạy song song, phát hiện lệch chuẩn — còn thứ thật sự chặn cú bấm nhầm vẫn phải là thuộc tính trên chính EC2. Nói cách khác, Config là công cụ bổ trợ cho đáp án B chứ không thay thế được B.

D — Use AWS Systems Manager to restrict EC2 termination. Systems Manager là bộ công cụ vận hành instance: chạy lệnh từ xa (Run Command), quản lý bản vá, Session Manager, quản lý tham số, tự động hóa tác vụ. Không có phần nào trong đó là cơ chế chặn terminate. Thuộc tính chống hủy thuộc về EC2 và phải cấu hình ở EC2 — Systems Manager làm việc bên trong và xung quanh instance, chứ không kiểm soát vòng đời hủy máy theo kiểu này.

📌 Điểm cần nhớ

• Phân biệt ba loại dịch vụ: dịch vụ ngăn chặn (termination protection trên EC2 — chặn ngay tại chỗ), dịch vụ ghi nhận (CloudTrail — audit sau khi việc đã xảy ra), dịch vụ đánh giá tuân thủ (AWS Config — phát hiện cấu hình lệch chuẩn). Đề hỏi "ngăn không cho xảy ra" thì loại ngay hai nhóm sau.
• CloudTrail không bao giờ là câu trả lời cho việc chặn API. Nó chỉ ghi lại. Thấy phương án nào bảo CloudTrail "restrict", "prevent", "block" thì gạt đi, dù tên API trong đó viết đúng.
• AWS Config kiểm tra chứ không thực thi. Nó trả lời "cấu hình này có đúng chuẩn không", không trả lời "hãy chặn hành động này lại". Đây là bẫy hay gặp vì Config đúng là có rule liên quan tới termination protection.
• "Accidentally" là từ khóa hướng về termination protection, không phải IAM. Khi người thực hiện là admin hợp lệ và vẫn cần giữ quyền, giải pháp là thêm một rào cản cần thao tác có chủ ý — chứ không phải cắt quyền của họ. Nếu đề đổi thành "ngăn nhóm người này không được phép terminate" thì bài toán mới chuyển sang IAM policy.
• Termination protection mặc định tắt, bật được ở mức từng instance, và đặt được cả lúc launch lẫn lúc instance đang chạy — nên nó áp dụng được cho hạ tầng đang vận hành sẵn.

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

Đề mô tả một công ty đang chạy ứng dụng trên Amazon EC2, nhưng trong vòng sáu tháng tới sẽ chuyển toàn bộ sang container chạy trên AWS Fargate, rồi dừng hẳn EC2. Câu hỏi yêu cầu chọn hình thức mua (purchasing option) sao cho tận dụng tối đa mức chiết khấu mà không có phần cam kết nào bị bỏ phí.

Có ba cụm từ trong đề quyết định đáp án, và phải đọc đủ cả ba:

• "transition to AWS Fargate ... fully decommission its EC2 instances" — cam kết mua phải áp được cho Fargate, chứ không phải chỉ cho EC2. Cụm này loại thẳng mọi phương án gắn với EC2.
• "ensures no reservations go unused" — không được để phần đã trả tiền nằm không. Vì khối lượng công việc sẽ dịch chuyển từ EC2 sang Fargate ngay trong thời hạn cam kết, chỉ loại cam kết nào đi theo được sự dịch chuyển đó mới thoả.
• "reliable projection of their future Fargate costs" — công ty biết chắc mức chi tiêu Fargate tương lai, nên cam kết 3 năm theo mức chi tiêu là hợp lý; đây là lý do kỳ hạn 3 năm không bị coi là rủi ro.

Điểm phân biệt cốt lõi: Compute Savings Plans cam kết theo mức chi tiêu ($/giờ) trên nhóm dịch vụ compute, còn EC2 Instance Savings Plans và Reserved Instances cam kết theo EC2 với ràng buộc về region và họ instance.

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

Đáp án đúng theo tệp là B — Compute Savings Plans kỳ hạn 3 năm, trả trước kiểu No Upfront.

Compute Savings Plans là loại linh hoạt nhất trong họ Savings Plans: cam kết được áp cho khối lượng compute bất kể region, bất kể họ instance, và quan trọng nhất là áp được cho AWS Fargate chứ không chỉ EC2. Nhờ vậy, trong sáu tháng đầu khi ứng dụng còn nằm trên EC2, cam kết ăn vào chi phí EC2; sau khi chuyển xong, đúng cam kết đó tự động ăn vào chi phí Fargate. Không có giai đoạn nào phần đã cam kết nằm không — thoả đúng yêu cầu "no reservations go unused".

Về kiểu thanh toán, No Upfront vẫn cho mức chiết khấu của kỳ hạn 3 năm mà không phải bỏ vốn ngay từ đầu. Trong bối cảnh công ty đang giữa quá trình dịch chuyển hạ tầng, đây là lựa chọn giữ được dòng tiền và giữ được dư địa nếu mức sử dụng Fargate biến động so với dự tính.

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

A — Compute Savings Plans 3 năm, Partial Upfront. Đây là phương án gần đúng nhất, và nó không sai ở phần loại Savings Plan: Compute Savings Plans đúng là thứ áp được cho Fargate. Chỗ hỏng nằm ở kiểu thanh toán. Partial Upfront buộc công ty bỏ một khoản vốn đáng kể ngay lập tức, trong khi họ đang ở giữa một cuộc di chuyển hạ tầng và giá trị mà đề nhấn mạnh là không lãng phí cam kết chứ không phải ép chiết khấu xuống mức thấp nhất có thể bằng mọi giá. Theo lời giải gốc, khi công ty coi trọng dòng tiền hoặc lường trước mức dùng Fargate còn thay đổi, việc khoá vốn trước là điều họ không muốn.

C — EC2 Instance Savings Plans 3 năm, Full Upfront. Sai ngay ở loại plan. EC2 Instance Savings Plans chỉ giảm giá cho EC2, và còn bị ràng buộc theo họ instance, kích cỡ và region. Công ty sắp bỏ hẳn EC2, nên phần lớn thời gian của cam kết 3 năm sẽ không có EC2 nào để áp — đúng kiểu "reservation bị bỏ phí" mà đề bảo phải tránh. Full Upfront còn làm tình huống tệ hơn: tiền đã trả hết ngay từ đầu cho một thứ sắp không còn dùng đến.

D — EC2 Reserved Instances 3 năm, Partial Upfront. Hỏng cùng một kiểu với C và còn cứng nhắc hơn. Reserved Instances gắn với loại instance và region cụ thể, và không mang lại lợi ích nào cho Fargate. Sau khi EC2 bị dừng, phần cam kết còn lại trở thành tiền chết. Kỳ hạn 3 năm cho một nền tảng chỉ còn sống sáu tháng là mâu thuẫn trực tiếp với đề.

📌 Điểm cần nhớ

• Compute Savings Plans là loại duy nhất trong bốn phương án áp được cho Fargate (và cả Lambda, EC2), không ràng buộc region hay họ instance. Hễ đề nhắc tới Fargate hoặc Lambda trong câu hỏi về cam kết chi phí, các phương án EC2-only bị loại ngay.
• EC2 Instance Savings Plans và Reserved Instances chỉ áp cho EC2 và bị bó theo họ instance/region. Đề mà nói "sẽ bỏ EC2" hay "sẽ đổi loại instance" thì hai thứ này là bẫy.
• Khi đề đã chốt loại plan rồi mới phân biệt bằng kiểu thanh toán, hãy tìm tín hiệu về dòng tiền hoặc mức độ chắc chắn của khối lượng công việc: đang trong giai đoạn chuyển đổi hoặc lo dòng tiền → No Upfront; ổn định và muốn chiết khấu tối đa → All/Partial Upfront.
• Đọc kỹ tiêu chí mà đề thực sự đặt ra. Ở đây tiêu chí là "không để cam kết bị bỏ phí", không phải "chiết khấu tuyệt đối cao nhất" — hai tiêu chí này dẫn tới hai đáp án khác nhau.

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

Đề mô tả một ứng dụng đang chạy trên Amazon RDS Multi-AZ DB instance, và yêu cầu tuân thủ bảo mật mới buộc phải mã hoá cơ sở dữ liệu. Câu hỏi: cách nào làm được việc đó?

Cụm từ quyết định nằm ở chỗ database đã tồn tại và chưa được mã hoá: "An application uses an Amazon RDS Multi-AZ DB instance" cộng với "Due to new security compliance requirements". Nghĩa là instance được tạo ra từ trước, ở trạng thái không mã hoá, và bây giờ mới phát sinh nhu cầu mã hoá.

Ràng buộc kỹ thuật đi kèm cụm từ đó là: encryption at rest của RDS chỉ bật được tại thời điểm tạo DB instance, không bật được cho instance đã có. Toàn bộ bốn phương án chỉ khác nhau ở chỗ chúng có tôn trọng ràng buộc "phải là một instance mới" hay không. Chi tiết "Multi-AZ" ở đây là bối cảnh gây nhiễu — nó dụ người làm bài nghĩ tới việc thao tác trên bản standby.

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

Đáp án đúng là D — Take a snapshot of the RDS instance, copy and encrypt the snapshot, and then restore to the new RDS instance.

Đây là con đường chính thức mà AWS đưa ra để "thêm" mã hoá cho một DB instance chưa mã hoá. Cơ chế của nó dựa trên một điểm mấu chốt: bản thân instance cũ không đổi trạng thái mã hoá, nhưng thao tác copy snapshot cho phép chỉ định KMS key ở bước sao chép, tức là tạo ra một bản sao snapshot đã được mã hoá từ một snapshot chưa mã hoá. Ba bước diễn ra như sau:

1. Chụp snapshot của DB instance hiện tại (snapshot này chưa mã hoá, giống nguồn).
2. Copy snapshot đó và bật encryption cho bản copy, chọn KMS key.
3. Restore từ snapshot đã mã hoá ra một DB instance mới — instance mới này được mã hoá ngay từ lúc tạo, đúng với ràng buộc của RDS.

Sau đó Administrator trỏ ứng dụng sang endpoint mới. Cách này thoả mãn yêu cầu compliance mà không cần export/import dữ liệu thủ công, và vẫn giữ nguyên toàn bộ dữ liệu của database gốc.

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

A — Use the RDS management console to enable encryption for the database. Sai vì đây chính là điều RDS không cho phép. Trong console, ô chọn encryption chỉ xuất hiện ở luồng tạo mới DB instance; khi mở "Modify" trên một instance đang tồn tại thì không có công tắc nào bật encryption at rest. Phương án này hấp dẫn vì nghe đơn giản nhất, nhưng nó phủ nhận đúng cái ràng buộc mà câu hỏi đang kiểm tra.

B — Encrypt the standby replica in the secondary AZ and promote it to the primary instance. Sai ở hai tầng. Thứ nhất, standby của Multi-AZ không phải là một instance riêng để thao tác — nó không có endpoint riêng, không quản lý độc lập được, và người dùng không "promote" nó bằng tay; RDS tự động failover. Thứ hai, kể cả nếu can thiệp được, standby luôn kế thừa trạng thái mã hoá của primary: từ một primary chưa mã hoá thì không tạo ra được standby đã mã hoá. Phương án này ăn theo từ khoá "Multi-AZ" trong đề để trông có liên quan.

C — Create an encrypted read replica and promote the replica to master. Đây là phương án gần đúng nhất và đáng phân tích kỹ. Cơ chế "tạo read replica rồi promote" là một kỹ thuật có thật, thường dùng để nâng cấp hoặc tách tải. Nhưng nó hỏng ở đúng bước đầu tiên: read replica thừa hưởng trạng thái mã hoá từ instance nguồn. Từ một master chưa mã hoá, RDS không cho tạo một replica đã mã hoá — không có chỗ nào để chỉ định KMS key khác trạng thái nguồn. Nói cách khác, bước "encrypted read replica" trong phương án này không thực hiện được, nên toàn bộ chuỗi sụp đổ dù bước promote về sau là hợp lệ. Chỉ có luồng copy snapshot mới là điểm duy nhất trong vòng đời RDS cho phép chuyển từ "chưa mã hoá" sang "đã mã hoá".

📌 Điểm cần nhớ

• RDS encryption at rest chỉ bật được lúc tạo DB instance. Gặp câu hỏi "database đang chạy, giờ cần mã hoá", đáp án luôn kéo theo việc tạo một instance mới, không bao giờ là "modify instance hiện tại".
• Copy snapshot là điểm chuyển trạng thái duy nhất. Đây là thao tác duy nhất cho phép gắn KMS key vào một bản dữ liệu vốn chưa mã hoá; nhớ chuỗi snapshot → copy (bật encryption) → restore.
• Read replica và standby luôn kế thừa trạng thái mã hoá của nguồn. Bất kỳ phương án nào bắt đầu bằng "tạo encrypted replica từ một nguồn chưa mã hoá" đều sai ngay từ bước một.
• Chiều ngược lại cũng cần lưu ý: với instance đã mã hoá thì không thể tắt mã hoá đi; muốn có bản không mã hoá cũng phải đi qua đường dữ liệu mới chứ không sửa tại chỗ.
• Trong Multi-AZ, standby không phải đối tượng để thao tác thủ công — nó không có endpoint riêng và failover do RDS điều khiển. Phương án nào bảo "thao tác trực tiếp lên standby" gần như chắc chắn là bẫy.