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

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

Đề mô tả một volume gp2 dung lượng 8 TB đang chạm trần 10.000 IOPS và gần như dùng hết dung lượng. Câu hỏi là: làm sao tăng hiệu năng mà giữ nguyên mức chi phí?

Cụm từ quyết định đáp án là "while keeping the costs at the same level" — giữ chi phí ở mức cũ. Chính ràng buộc này loại thẳng những phương án đúng về mặt kỹ thuật nhưng đắt hơn. Cụm thứ hai cũng quan trọng: "increase the performance" — mục tiêu là I/O nhanh hơn, không phải an toàn dữ liệu hơn. Hai vế này ghép lại chỉ còn đúng một hướng: vẫn dùng gp2 (giữ giá), vẫn giữ tổng dung lượng 8 TB (giữ giá), nhưng chẻ ra nhiều volume rồi ghép ở tầng phần mềm theo kiểu ưu tiên throughput chứ không ưu tiên dự phòng.

Một chi tiết nữa trong đề: gp2 có trần IOPS cho mỗi volume, và volume trong đề đã chạm đúng trần đó. Nghĩa là không thể vắt thêm gì từ một volume gp2 nữa — muốn vượt trần thì phải có nhiều volume, vì trần được tính trên từng volume.

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

Đáp án đúng theo tệp là C — Create two 4 TB gp2 drives and mount them in RAID 0 on the EC2 instance.

Với Amazon EBS, bạn dùng được mọi cấu hình RAID chuẩn như trên máy chủ vật lý, miễn hệ điều hành của instance hỗ trợ — vì RAID ở đây hoàn toàn là software RAID, làm ở tầng OS bên trong instance chứ không phải tính năng của EBS.

RAID 0 ghép nhiều volume bằng cách striping: dữ liệu được rải đều qua các volume thành viên, nên I/O của ứng dụng được chia ra và chạy song song trên cả hai volume. Kết quả là băng thông và IOPS cộng dồn lại, vượt qua trần của một volume đơn.

Về chi phí: hai volume gp2 4 TB cộng lại vẫn là 8 TB gp2, mà EBS tính tiền theo GB-tháng của dung lượng đã provision. Tổng dung lượng không đổi, loại volume không đổi → hoá đơn về cơ bản giữ nguyên. Đúng cả hai yêu cầu của đề: nhanh hơn, mà không đắt hơn.

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

A — Two 4 TB gp2 drives in RAID 1. Đây là phương án gần đúng nhất và cũng là bẫy chính: nó cũng chẻ 8 TB thành hai volume gp2, cũng giữ nguyên chi phí lưu trữ. Hỏng ở chỗ kiểu RAID. RAID 1 là mirroring — cùng một dữ liệu được ghi sang cả hai volume, phục vụ mục tiêu chịu lỗi chứ không phải hiệu năng. Dùng RAID 1 khi fault tolerance quan trọng hơn I/O; ở đây đề nói rõ mục tiêu là hiệu năng. Tệ hơn nữa, mirroring còn làm bạn mất một nửa dung lượng khả dụng: 8 TB provision nhưng chỉ dùng được 4 TB — trong khi đề nói ổ đĩa đã gần đầy.

B — Convert gp2 sang io1 và tăng PIOPS. Về kỹ thuật thì đúng hướng: io1 cho phép chỉ định số IOPS provisioned và đạt mức cao hơn gp2. Nhưng nó vi phạm thẳng ràng buộc chi phí: giá mỗi GB-tháng của io1 cao hơn gp2, và ngoài tiền dung lượng bạn còn phải trả riêng cho phần PIOPS đã provision. Với 8 TB thì khoản chênh này không hề nhỏ. Đề đã chốt "keeping the costs at the same level", nên phương án này bị loại vì lý do tiền, không phải vì lý do kỹ thuật.

D — Enable burst mode on the gp2 drive. Đây là phương án đánh lừa bằng một khái niệm không tồn tại: gp2 không có công tắc nào để bật/tắt burst. Cơ chế burst credit là hành vi mặc định, luôn sẵn có. Quan trọng hơn, burst chỉ có ý nghĩa với các volume gp2 nhỏ, khi baseline IOPS thấp và cần vọt tạm lên mức cao hơn. Volume trong đề là 8 TB và đã chạm trần IOPS tối đa của gp2 — nó đang ở mức trần rồi, không còn "burst" nào để vượt qua chính trần đó. Cho dù có nút bấm ấy thì cũng không giải quyết được gì.

📌 Điểm cần nhớ

• RAID 0 = performance (striping), RAID 1 = redundancy (mirroring). Đề hỏi "tăng hiệu năng" thì chọn RAID 0; đề hỏi "chịu lỗi / bảo vệ dữ liệu" thì mới là RAID 1. Đây là cặp phương án đối lập xuất hiện lặp đi lặp lại trong nhiều câu.
• RAID trên EBS là software RAID trong instance, không phải tính năng của dịch vụ EBS — nên phụ thuộc vào hệ điều hành hỗ trợ, và bạn tự cấu hình bên trong EC2.
• Trần IOPS của gp2 tính trên từng volume. Một volume đơn đã chạm trần thì không còn cách nào ép thêm; muốn vượt trần bắt buộc phải chia thành nhiều volume và ghép lại.
• Đọc kỹ ràng buộc chi phí trước khi chọn io1/io2. Chuyển sang volume provisioned IOPS gần như luôn là câu trả lời "nhanh hơn", nhưng khi đề gắn thêm điều kiện "chi phí không đổi" thì nó thành phương án sai — cùng tổng dung lượng, cùng loại volume thì hoá đơn mới giữ nguyên.
• Cảnh giác với các nút bấm không có thật. "Enable burst mode" là kiểu distractor mô tả một thao tác mà dịch vụ không hề cung cấp — burst của gp2 luôn bật sẵn theo mặc định.

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

Đề nêu nhu cầu: thiết lập kết nối riêng (private connection) giữa data center của công ty và VPC trên AWS. Nhưng cụm từ quyết định nằm ở hai chỗ, và phải đọc cả hai mới trả lời đúng:

• "software only" — kết nối phải dựng được hoàn toàn bằng cấu hình phần mềm, không đụng tới việc kéo cáp hay đặt thiết bị vật lý.
• "should you NOT use" — đây là câu hỏi phủ định. Ba phương án còn lại đều là thành phần hợp lệ của giải pháp; ta phải chỉ ra cái không thuộc về nó.

Bỏ qua chữ "software only" thì Direct Connect trông rất hợp lý, vì nó đúng là "private connection" giữa on-premises và VPC. Bỏ qua chữ "NOT" thì lại chọn nhầm sang một trong ba thành phần của VPN. Ràng buộc thật sự là: private + software only → đó là mô tả của Site-to-Site VPN, không phải Direct Connect.

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

B — Direct Connect.

AWS Direct Connect là một kết nối vật lý chuyên dụng: nó đòi một đường link thật tại một Direct Connect location, thiết bị router phía khách hàng, và làm việc với đối tác/nhà cung cấp mạng để kéo đường. Vì phải triển khai hạ tầng vật lý, việc thiết lập kéo dài đáng kể — thường tính bằng tuần đến hàng tháng, chứ không phải bật lên là có.

Đúng là Direct Connect cho ra một kết nối private không đi qua public internet, nhưng nó vi phạm ràng buộc "software only" của đề. Đề không hỏi "cái nào là kết nối riêng", mà hỏi "cái nào KHÔNG nên dùng cho kết nối riêng thuần phần mềm". Direct Connect là thành phần duy nhất trong danh sách mang tính vật lý, nên nó là thứ phải loại.

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

Cả ba đều là bộ phận cấu thành của một Site-to-Site VPN — tức là chúng nằm trong giải pháp, không phải thứ bị loại ra. Đó là lý do chúng "sai" trong một câu hỏi phủ định.

• A — Virtual Private Gateway. Đây là đầu VPN nằm ở phía AWS, gắn vào VPC. Không có nó thì VPC không có điểm kết cuối để dựng đường hầm VPN. Đây thuần là một tài nguyên logic do AWS tạo ra, đúng tinh thần "software only" — nên phải dùng, không phải loại.

• C — Customer Gateway. Đây là tài nguyên trong AWS mô tả thiết bị đầu phía data center của bạn (khai báo địa chỉ IP công cộng, thông tin routing/BGP). Điểm dễ nhầm: nghe tên tưởng là "thiết bị phần cứng", nhưng bản thân Customer Gateway trong AWS chỉ là bản khai báo thông tin — nó là nửa còn lại của cấu hình VPN. Đây là phương án gần đúng nhất về mặt gây phân vân, nhưng nó vẫn thuộc về giải pháp VPN chứ không bị loại.

• D — Site-to-Site VPN. Chính là giải pháp mà đề mô tả: nối Virtual Private Gateway với Customer Gateway thành đường hầm mã hoá, rồi cấu hình routing để lưu lượng giữa VPC và mạng on-premises đi qua đó. Mặc định instance trong VPC không nói chuyện được với mạng riêng của bạn; Site-to-Site VPN là cách mở đường đó bằng cấu hình. Nó là câu trả lời cho "software only private connection", nên chọn nó là chọn ngược ý đề.

📌 Điểm cần nhớ

• Với câu hỏi có chữ NOT / EXCEPT, đọc xong nên tự hỏi: "ba cái kia có cùng thuộc về một giải pháp không?" Nếu có, cái lạc nhóm chính là đáp án.
• Phân biệt cốt lõi: Site-to-Site VPN = private connection dựng bằng phần mềm, đi qua internet nhưng được mã hoá, bật gần như ngay lập tức; Direct Connect = đường vật lý chuyên dụng, không qua public internet, cần thời gian triển khai dài và có ràng buộc về vị trí, thiết bị.
• Một Site-to-Site VPN luôn cần đủ hai đầu: Virtual Private Gateway (phía AWS, gắn vào VPC) và Customer Gateway (đại diện thiết bị phía on-premises). Thấy hai tên này trong đáp án thì gần như chắc đề đang nói về VPN.
• Từ khoá trong đề quyết định lựa chọn: "software only" hoặc "quickly / trong vài giờ" → nghiêng về VPN; "dedicated", "consistent bandwidth", "không đi qua public internet" → nghiêng về Direct Connect.

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

Đề mô tả một công ty có tất cả tài nguyên nằm trong một AWS account duy nhất, và muốn chia hóa đơn AWS về đúng từng phòng ban. Câu hỏi yêu cầu cách lấy được báo cáo billing tách theo phòng ban, với chi phí quản trị thấp nhất.

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

• "under one AWS account" — mọi thứ nằm chung một account. Ràng buộc này loại thẳng mọi giải pháp dựa trên việc tách account.
• "get billing reports" — thứ cần không phải là "gắn nhãn cho gọn" mà là số liệu chi phí thực sự xuất hiện trong báo cáo. Đây chính là ràng buộc phân biệt hai phương án gần giống nhau nhất trong đề: Tags và Cost Allocation Tags.

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

Đáp án đúng theo tệp là D — Use Cost Allocation Tags.

Một tag là cặp key–value mà bạn (hoặc AWS) gắn lên tài nguyên; mỗi resource thì mỗi tag key là duy nhất và chỉ mang một giá trị. Nhưng tag chỉ trở thành công cụ tính tiền khi bạn kích hoạt nó làm cost allocation tag trong Billing and Cost Management console.

Sau khi kích hoạt, AWS dùng các tag đó để tổ chức chi phí tài nguyên trong cost allocation report, sinh ra file CSV liệt kê usage và chi phí được nhóm theo các tag đang active. Mỗi tag key được chọn trở thành một cột thêm vào báo cáo, mang giá trị tương ứng của từng line item. Nhờ vậy bạn gắn các tag mang ý nghĩa nghiệp vụ — cost center, tên ứng dụng, chủ sở hữu, hay ở đây là phòng ban — và cắt chi phí theo nhiều service cùng lúc.

Cuối chu kỳ billing, tổng chi phí trên báo cáo cost allocation (cả phần đã gắn tag lẫn phần chưa gắn) khớp với tổng trên trang Bills và các báo cáo billing khác cùng kỳ — nên đây là con số dùng để đối soát được, không phải ước lượng. Với đúng một account, đây là cách rẻ nhất về mặt quản trị: chỉ gắn tag và bật chúng, không phải đụng tới cấu trúc account.

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

A — Use Tags. Đây là phương án gần đúng nhất, và chỗ nó hỏng rất tinh tế: tag key mới thêm qua API hay Management Console mặc định bị loại khỏi cost allocation report. Tag tồn tại trên tài nguyên không có nghĩa nó xuất hiện trong hóa đơn. Sở dĩ AWS làm vậy vì tag còn dùng cho nhiều mục đích khác — bảo mật, vận hành — nên bạn được chọn include hay exclude từng key cho báo cáo. Nói cách khác, "Tags" là bước một; thiếu bước kích hoạt thì gắn tag xong mở báo cáo ra vẫn không thấy cột phòng ban nào. Đáp án D chính là phương án A cộng thêm đúng bước còn thiếu đó.

B — Use AWS Organizations. Organizations quản lý tập trung nhiều AWS account: tự động tạo account, gom account thành nhóm theo nhu cầu kinh doanh, áp policy cho các nhóm, kiểm soát access và compliance, và gộp thanh toán về một phương thức duy nhất. Vấn đề là nó thao tác ở cấp account, trong khi đề nói rõ mọi tài nguyên nằm trong một account. Muốn dùng Organizations để chia theo phòng ban thì phải tách tài nguyên ra thành nhiều account — đúng nghĩa "administrative overhead" lớn nhất có thể, ngược hẳn với yêu cầu của đề.

C — Use EC2 Billing Report. Đây là phương án bịa — không tồn tại thứ gì tên "EC2 Billing Report" trong AWS. Kể cả nếu có, nó cũng chỉ bó hẹp trong EC2, trong khi chi phí một phòng ban trải trên nhiều service khác nhau.

📌 Điểm cần nhớ

• Tag ≠ Cost Allocation Tag. Gắn tag là điều kiện cần; phải kích hoạt tag key trong Billing and Cost Management thì nó mới thành cột trong cost allocation report. Đề nào nhắc tới "billing report" hay "chargeback theo phòng ban" thì chọn bản có chữ "Cost Allocation".
• Đọc kỹ số lượng account. "One AWS account" đẩy bài toán về mức tag; "multiple accounts / consolidated billing" mới là địa hạt của AWS Organizations. Hai đáp án này gần như không bao giờ cùng đúng.
• "Least administrative overhead" luôn ưu tiên giải pháp không phải tái cấu trúc hạ tầng. Tách account để chia hóa đơn là đổi cả kiến trúc chỉ để lấy một báo cáo.
• Cẩn thận với phương án ghép tên service + tên báo cáo nghe hợp lý (kiểu "EC2 Billing Report") — đó là mẫu phương án bịa rất hay gặp trong đề AWS.

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

Đề mô tả một tình huống vận hành: VPC Peering đã được thiết lập giữa VPC A và VPC B, route table của VPC A đã được cập nhật, nhưng các instance vẫn không nói chuyện được với nhau. Câu hỏi là nguyên nhân khả dĩ nhất.

Cụm từ quyết định nằm ở chỗ "the route tables have been updated for VPC A" — đề cố ý chỉ nêu một phía. Peering connection trong AWS là kết nối hai chiều, nhưng việc định tuyến thì không tự động: mỗi VPC phải tự thêm route trỏ dải CIDR của VPC còn lại qua peering connection, trong route table gắn với subnet chứa instance. Đề nói rõ A đã làm, không nói gì về B — đó chính là khoảng trống mà câu hỏi muốn bạn nhìn thấy.

Thêm một dấu hiệu nữa: đề hỏi "most likely issue" chứ không hỏi "những gì cần kiểm tra". Nhiều phương án ở đây đều là những thứ đáng kiểm tra thật, nên phải chọn cái mà tình huống đã ngầm chỉ ra chứ không chọn cái chung chung.

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

D — Check the route tables in VPC B.

Để gửi được lưu lượng private IP từ instance của bạn sang instance ở VPC đối tác, bạn phải thêm route vào route table gắn với subnet chứa instance đó. Chủ của VPC đối tác (ở đây là VPC B) cũng phải làm đúng các bước ấy để định tuyến lưu lượng trả về qua peering connection. Đây thường là nguyên nhân phổ biến nhất khi hai VPC đã peer mà vẫn không liên lạc được.

Về mặt cơ chế: nếu VPC B thiếu route trỏ về CIDR của VPC A, gói tin đi từ A sang B vẫn tới nơi, nhưng gói phản hồi từ B không biết đường quay lại — bảng định tuyến của B sẽ đẩy nó ra default route (internet gateway hoặc không đi đâu cả). Kết quả nhìn từ phía người vận hành là "ping không thông", "connection timeout", đúng như mô tả trong đề. Vì đề đã xác nhận phía A xong rồi, phía B là chỗ còn lại chưa được xác nhận.

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

B — Check the NACL. Đây là phương án gần đúng nhất và hoàn toàn là việc nên làm trong thực tế: network ACL phải có rule ALLOW cho lưu lượng cần thiết, và vì NACL là stateless nên nó chặn cả chiều đi lẫn chiều về, gây ra triệu chứng giống hệt. Nhưng NACL mặc định của một VPC là cho phép toàn bộ traffic vào/ra; nó chỉ thành vấn đề khi ai đó đã sửa nó. Trong khi đó, route table phía B chắc chắn cần thao tác thủ công và đề đã cố ý không nhắc tới. Giữa "thứ mặc định đã mở" và "thứ mặc định chưa có", cái thứ hai là nguyên nhân khả dĩ hơn.

C — Check the instance security groups. Cũng đúng về mặt checklist: security group rules phải cho phép lưu lượng giữa hai VPC đã peer, và security group mặc định không cho phép inbound từ dải CIDR của VPC khác, nên đây là một ứng viên nghiêm túc. Điểm hỏng của nó: security group hoạt động ở tầng instance, chỉ có ý nghĩa khi gói tin đã đến được nơi. Thiếu route thì gói tin còn không rời khỏi/không quay về được tầng mạng, nên lỗi định tuyến "đứng trước" lỗi security group trong thứ tự chẩn đoán. Đề lại đang nói chuyện về route table, nên nó hướng bạn về tầng mạng chứ không phải tầng instance.

A — Check if DNS Resolution is enabled. Sai hẳn về phạm vi. Tính năng DNS Resolution trên peering connection dùng để phân giải public DNS hostname thành private IP khi truy vấn từ VPC đối tác (và hỗ trợ cả peering giữa hai tài khoản khác nhau). Nó ảnh hưởng tới việc phân giải tên, không ảnh hưởng tới việc gói tin có đi được hay không. Nếu instance kết nối bằng private IP trực tiếp thì DNS chẳng liên quan gì; mà kể cả có bật, thiếu route thì vẫn không thông.

📌 Điểm cần nhớ

• VPC Peering không tự sinh route. Sau khi peering connection ở trạng thái active, cả hai VPC đều phải tự thêm route trỏ CIDR của phía kia qua peering connection, trong route table gắn với đúng subnet chứa instance. Đề chỉ nêu một phía đã cấu hình là dấu hiệu gần như chắc chắn về đáp án.
• Thứ tự chẩn đoán kết nối: route table (gói có đường đi không?) → NACL (tầng subnet, stateless, chặn cả hai chiều) → security group (tầng instance, stateful). Câu hỏi tình huống thường muốn bạn chỉ ra tầng thấp nhất còn thiếu.
• Phân biệt "đáng kiểm tra" với "khả dĩ nhất". NACL và security group luôn nằm trong checklist khắc phục sự cố peering, nhưng khi đề đã loại trừ một phía bằng cách nói rõ phía kia đã xong, hãy chọn theo dữ kiện đề cho.
• DNS Resolution trên peering là chuyện phân giải tên, không phải chuyện thông mạng — gặp phương án này trong bài toán "không kết nối được", gần như luôn là mồi nhử, trừ khi đề nói rõ triệu chứng là không resolve được hostname.

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

Đề mô tả một RDS database thỉnh thoảng rơi vào trạng thái unresponsive, trượt health check, và yêu cầu ứng dụng phải fail-over tự động và an toàn, không mất bất kỳ committed transaction nào.

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

• "automatically" — quá trình chuyển đổi phải do chính dịch vụ lo, không phải một cơ chế người dùng tự dựng và tự bảo trì.
• "safely without losing any committed transactions" — đòi hỏi bản sao dự phòng được ghi synchronous. Bản sao kiểu asynchronous luôn có độ trễ, và độ trễ đó chính là chỗ các giao dịch đã commit có thể biến mất khi primary chết.
• "your application to fail-over" — ứng dụng đang trỏ tới một DB endpoint. Nếu sau khi chuyển đổi mà endpoint đổi, ứng dụng vẫn hỏng cho tới khi có người sửa cấu hình. Đây là ràng buộc phân biệt Multi-AZ với mọi phương án dựng bằng read replica.

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

B — Enable RDS Multi-AZ.

Multi-AZ là cơ chế high availability và failover sẵn có của RDS. Khi bật, RDS tự tạo và duy trì một standby replica đồng bộ (synchronous) ở một Availability Zone khác. Vì việc ghi được đồng bộ sang standby, các giao dịch đã commit không bị mất khi RDS chuyển sang standby — đúng yêu cầu "không mất committed transactions".

Quan trọng không kém: DB endpoint không đổi. RDS trỏ lại endpoint sang instance mới, nên ứng dụng chỉ cần kết nối lại chứ không phải đổi cấu hình. Đó là phần "automatically and safely" của đề bài.

Failover xảy ra trong các trường hợp: primary DB instance hỏng, Availability Zone gặp sự cố, đổi loại server của DB instance, hệ điều hành của DB instance đang được vá phần mềm, và khi người vận hành chủ động dùng Reboot with failover.

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

A — Read replica cùng region + Lambda promote khi primary chết. Đây là phương án gần đúng nhất, vì nó thật sự tạo ra một bản sao và thật sự tự động hoá. Nhưng nó hỏng ở hai chỗ. Read replica sinh ra để mở rộng khả năng đọc cho workload đọc nhiều, không phải để làm HA. Khi Lambda promote replica lên làm primary, DB endpoint sẽ thay đổi — ứng dụng vẫn trỏ vào endpoint cũ nên vẫn đứt cho tới khi có người can thiệp, tức là không "transparently switch" như Multi-AZ. Ngoài ra sao chép sang read replica không đảm bảo tính đồng bộ như standby của Multi-AZ, nên yêu cầu "không mất committed transactions" cũng không được bảo chứng.

D — Read replica khác region + Lambda promote. Sai vì đúng lý do với A: replica vẫn là công cụ scale đọc, promote vẫn làm đổi endpoint. Việc đặt ở region khác không chữa được lỗi nào trong hai lỗi đó — nó chỉ đổi phạm vi địa lý của bản sao, còn cơ chế chuyển đổi vẫn là thứ tự dựng và vẫn không trong suốt với ứng dụng.

C — CloudWatch alarm khi RAM vượt 90% rồi reboot database. Đây là dán băng cá nhân lên vết thương. Reboot không xử lý nguyên nhân gốc khiến DB hết RAM, nên vừa lên lại là vấn đề hiệu năng quay về. Thêm nữa, reboot đơn thuần không phải là failover: trong lúc reboot database không phục vụ được, không có bản dự phòng nào nhận việc, và không có gì bảo đảm các giao dịch đang dở được giữ nguyên vẹn. Phương án này không đáp ứng cả "automatically fail-over" lẫn "không mất committed transactions".

📌 Điểm cần nhớ

• Đề nhắc high availability / automatic failover → nghĩ Multi-AZ. Đề nhắc scale đọc / giảm tải cho primary → nghĩ read replica. Đây là cặp phân biệt bị hỏi đi hỏi lại trong kỳ thi.
• Standby của Multi-AZ được ghi synchronous nên bảo toàn committed transactions; read replica thì không có bảo đảm đó — hễ đề nói "không được mất giao dịch đã commit" là read replica bị loại.
• Endpoint có đổi hay không là phép thử nhanh: promote một read replica làm đổi endpoint, còn Multi-AZ failover giữ nguyên endpoint. Phương án nào bắt ứng dụng phải đổi điểm kết nối thì không phải giải pháp HA trong suốt.
• Cảnh giác với các phương án chỉ phản ứng theo triệu chứng (alarm rồi reboot, alarm rồi restart): chúng không xử lý nguyên nhân gốc và không cung cấp khả năng dự phòng, nên gần như luôn sai ở câu hỏi về availability.
• Tự dựng cơ chế failover bằng Lambda thoạt nghe "tự động", nhưng khi dịch vụ đã có sẵn tính năng managed cho đúng việc đó, AWS luôn coi lựa chọn managed là câu trả lời đúng.

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

Bối cảnh: nhiều EC2 instance chậm cập nhật OS patch, và bạn đã quyết định dùng SSM để vá chúng định kỳ. Nghĩa là phần vá lỗi coi như đã xong, không phải thứ câu hỏi đang hỏi.

Cụm từ quyết định đáp án nằm ở vế sau: "provide a report showing that no outstanding known vulnerabilities are left unpatched" — cộng thêm "generated weekly". Ba tín hiệu này gộp lại chỉ về đúng một loại công cụ: một dịch vụ quét đánh giá bảo mật (security assessment) trên chính EC2 instance, so trạng thái phần mềm với danh mục lỗ hổng đã biết (CVE), rồi xuất ra báo cáo dùng được cho hồ sơ compliance.

Chú ý cái bẫy: đề nhắc SSM ngay từ đầu để bạn thấy quen mà chọn luôn. Nhưng SSM ở đây đóng vai nguyên nhân đã có sẵn, không phải câu trả lời. Câu hỏi là "Which service should you use?" cho việc chứng minh đã vá sạch, chứ không phải cho việc vá.

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

Đáp án đúng theo tệp là D — AWS Inspector.

Amazon Inspector là dịch vụ đánh giá bảo mật tự động, kiểm tra khả năng truy cập mạng của EC2 instance và tình trạng bảo mật của ứng dụng chạy trên đó. Đây chính là dịch vụ duy nhất trong bốn phương án nhìn vào bên trong instance để phát hiện lỗ hổng đã biết còn tồn đọng.

Quan trọng hơn với yêu cầu của đề: sau mỗi lần chạy assessment thành công, Inspector sinh ra assessment report — một tài liệu ghi rõ đã kiểm tra những gì và kết quả ra sao. Có hai dạng:

• Findings report: tóm tắt cho lãnh đạo, danh sách instance được nhắm tới, các rules package đã kiểm, những rule sinh ra finding và instance nào trượt.
• Full report: đầy đủ nội dung của findings report, cộng thêm danh sách rule đã kiểm và đạt trên toàn bộ instance.

Chính dạng full report mới trả lời được đúng câu "không còn lỗ hổng nào chưa vá" — vì bằng chứng compliance cần cả phần đã kiểm và pass, chứ một báo cáo chỉ liệt kê lỗi thì không chứng minh được sự vắng mặt của lỗi. Báo cáo này chia sẻ được cho team để xử lý, dùng làm dữ liệu cho audit compliance, hoặc lưu lại tham chiếu sau này — khớp trọn vẹn yêu cầu "yearly compliance report" và nhịp chạy hằng tuần.

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

A — AWS SSM. Đây là phương án gần đúng nhất và là cái bẫy chính. AWS Systems Manager cho bạn khả năng nhìn thấy và điều khiển hạ tầng: gom nhóm tài nguyên (EC2, S3 bucket, RDS instance) theo ứng dụng, xem dữ liệu vận hành, chạy lệnh, quản lý patch, cấu hình server trên AWS lẫn on-premises. Nó hỏng ở chỗ: SSM là công cụ thực thi hành động vá, không phải công cụ đánh giá lỗ hổng. Và đề đã nói rõ bạn đang dùng SSM để vá rồi — nếu SSM tự nó là câu trả lời thì đề đã không cần hỏi tiếp. SSM không tạo ra báo cáo chứng minh rằng không còn lỗ hổng đã biết nào chưa được vá.

B — AWS Shield. Sai hoàn toàn về lớp bảo vệ. Shield là dịch vụ quản lý chống DDoS, bảo vệ ứng dụng chạy trên AWS bằng cơ chế phát hiện luôn bật và giảm thiểu tấn công tự động, giảm downtime và độ trễ mà không cần liên hệ AWS Support. Nó xử lý lưu lượng tấn công ở tầng mạng/ứng dụng, hoàn toàn không nhìn vào trạng thái patch của OS và không sinh báo cáo lỗ hổng.

C — AWS GuardDuty. Đây là phương án gần đúng thứ hai vì cũng là dịch vụ bảo mật. Nhưng GuardDuty là threat detection — nó giám sát hoạt động độc hại và hành vi trái phép để bảo vệ tài khoản AWS, phân tích sự kiện từ CloudTrail (hoạt động user và API), VPC Flow Logs (dữ liệu lưu lượng mạng) và DNS logs (mẫu truy vấn tên miền). Điểm hỏng: GuardDuty làm việc trên log và hành vi, tức là phát hiện "có kẻ đang tấn công / có thứ gì đó bất thường đang xảy ra", chứ không kiểm kê "instance này còn thiếu bản vá nào". Nó không cung cấp báo cáo chứng minh không còn lỗ hổng đã biết nào chưa vá.

📌 Điểm cần nhớ

• Phân biệt ba động từ trong câu hỏi bảo mật AWS: vá → Systems Manager (Patch Manager); đánh giá lỗ hổng và báo cáo → Inspector; phát hiện mối đe dọa đang diễn ra → GuardDuty. Đề nhắc dịch vụ nào ở phần bối cảnh thường không phải đáp án.
• Từ khoá "vulnerability" / "unpatched" / "assessment report" gắn với instance hay ứng dụng thì gần như luôn dẫn tới Inspector.
• GuardDuty ăn log (CloudTrail, VPC Flow Logs, DNS logs) — hễ nguồn dữ liệu trong đề là trạng thái bên trong máy chứ không phải log, thì loại GuardDuty.
• Yêu cầu compliance cần bằng chứng cả phần "đã kiểm và đạt", không chỉ danh sách lỗi — đó là lý do full report của Inspector là thứ dùng cho audit.
• Shield = DDoS, một câu hỏi có chữ "patch" hay "vulnerability" thì Shield luôn là phương án loại đầu tiên.

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

Đề nêu tình huống: bạn có các instance nằm trong private subnet ở AZ us-west-1b, và các instance public ở AZ us-west-1c. Yêu cầu là hai nhóm này nói chuyện được với nhau bằng private IP address, và phải làm theo cách đơn giản nhất có thể.

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

• "using their private IP addresses" — luồng traffic ở đây là nội bộ, không đi ra Internet. Bất kỳ phương án nào chuyên trách việc đưa traffic ra ngoài Internet đều lệch chủ đề.
• "in the simplest possible way" — trong số các cách về mặt kỹ thuật đều chạy được, đề hỏi cách tốn ít thành phần nhất. Đây là ràng buộc tách bạch phương án C khỏi phương án B.

Chi tiết us-west-1b và us-west-1c là hai Availability Zone trong cùng một region, không phải hai region — nên đây không phải bài toán nối mạng liên vùng.

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

C. Create one VPC with two subnets.

Khi tạo một VPC mới, VPC đó tự có sẵn một main route table. Mọi subnet trong VPC bắt buộc phải gắn với một route table; subnet nào không được gắn tường minh vào route table riêng thì mặc nhiên dùng main route table. Một subnet chỉ gắn với một route table tại một thời điểm, nhưng nhiều subnet có thể dùng chung một route table.

Điểm mấu chốt: trong cùng một VPC, các subnet đã định tuyến được cho nhau sẵn qua route local của VPC CIDR — kể cả khi chúng nằm ở hai Availability Zone khác nhau. Với tình huống của đề, VPC có hai subnet thì chính main route table lo phần định tuyến giữa hai subnet đó, không cần dựng thêm thiết bị mạng nào. Đó đúng là "cách đơn giản nhất": chỉ cần đặt hai subnet trong cùng một VPC là xong.

Lưu ý là "private subnet" và "public subnet" khác nhau ở chỗ subnet public có route ra Internet Gateway, chứ không phải chúng bị cô lập với nhau — nên việc chúng nói chuyện nội bộ bằng private IP là hoàn toàn tự nhiên.

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

A. Use a NAT Gateway — NAT Gateway dùng để cho instance trong private subnet kết nối ra Internet hoặc tới các dịch vụ AWS khác, đồng thời chặn không cho Internet chủ động mở kết nối vào những instance đó. Nó giải quyết bài toán "ra ngoài", không phải bài toán "hai subnet trong nội bộ nói chuyện với nhau bằng private IP". Thêm NAT Gateway vào đây là thêm một thành phần không liên quan tới yêu cầu.

B. Create two VPCs with one subnet each, and peer them — Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. VPC peering là kết nối mạng giữa hai VPC, cho phép định tuyến traffic giữa chúng bằng private IPv4/IPv6 address, instance hai bên giao tiếp như thể cùng một mạng; peering còn dùng được giữa các VPC khác account hoặc khác region. Nghĩa là về mặt kết quả, phương án này đạt được yêu cầu "nói chuyện bằng private IP".

Nó sai vì ràng buộc còn lại: "simplest possible way". Bạn phải tạo hai VPC, hai subnet, một peering connection, rồi tự thêm route ở route table của cả hai phía — trong khi chỉ cần một VPC hai subnet là đã có sẵn kết nối mà không phải cấu hình gì thêm. Đó là giải pháp phức tạp hoá cho một tình huống đơn giản.

D. Use a NAT instance — Cùng một sai lầm khái niệm với phương án A, chỉ khác về cách hiện thực: NAT instance là một EC2 instance đặt trong public subnet, cho phép instance ở private subnet khởi tạo traffic IPv4 đi ra Internet hoặc tới dịch vụ AWS khác, và ngăn traffic từ ngoài chủ động vào. Vẫn là bài toán chiều ra Internet, không phải giao tiếp nội bộ. Ngoài ra nó còn kém hơn A ở chỗ bạn phải tự quản lý một instance (vá lỗi, giám sát, khả dụng), càng xa với chữ "simplest".

📌 Điểm cần nhớ

• Các subnet trong cùng một VPC luôn định tuyến được cho nhau bằng private IP, kể cả khác Availability Zone — nhờ route local của VPC CIDR trong main route table. Không cần gateway, peering hay thiết bị trung gian nào.
• "Private subnet" không có nghĩa là bị cô lập. Khác biệt giữa public và private subnet nằm ở việc route table có trỏ ra Internet Gateway hay không, chứ không phải ở khả năng liên lạc nội bộ trong VPC.
• NAT Gateway và NAT instance đều là giải pháp cho chiều đi ra Internet/AWS services, không phải cho traffic đông–tây giữa các subnet. Thấy đề hỏi "private IP, nội bộ" thì loại cả hai ngay.
• VPC peering đúng về kỹ thuật nhưng sai khi đề nhấn "simplest"/"least effort". Chỉ dùng peering khi hai bên buộc phải là hai VPC riêng (khác account, khác region, hoặc đã tách sẵn); nếu bạn được toàn quyền thiết kế thì gộp về một VPC là lời giải.

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

Đề mô tả một môi trường mà toàn bộ hạ tầng được triển khai bằng CloudFormation, trong đó có cả EBS volume. Yêu cầu nghiệp vụ: khi stack bị xoá (CloudFormation stacks are deleted), bắt buộc phải giữ lại một snapshot của EBS volume để phục vụ backup và tuân thủ.

Cụm từ quyết định đáp án nằm ở hai chỗ ghép lại:

• "When the CloudFormation stacks are deleted" — hành động cần xử lý là xoá stack, và stack vẫn được phép xoá. Đây là chi tiết loại thẳng những phương án cố ngăn việc xoá.
• "it is mandatory to keep a snapshot" — thứ cần giữ lại không phải bản thân volume, mà là snapshot của nó, và nó phải là hành vi bắt buộc, tự động, chứ không phải một quy trình thủ công ai đó nhớ thì làm.

Thêm một chi tiết nữa: "How can you achieve this using CloudFormation?" — lời giải phải nằm trong chính template, tức là một thuộc tính CloudFormation hiểu được, chứ không phải một script chạy kèm.

Vậy câu hỏi thực chất là: CloudFormation có cơ chế nào khai báo ngay trong template để tự chụp snapshot tài nguyên tại thời điểm xoá stack?

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

Đáp án đúng là A — Use DeletionPolicy=Snapshot.

DeletionPolicy là một attribute cấp resource của CloudFormation, dùng để quyết định CloudFormation sẽ đối xử thế nào với tài nguyên đó khi stack bị xoá. Với AWS::EC2::Volume, có ba hướng xử lý: xoá volume, giữ lại volume (Retain), hoặc tạo snapshot của volume rồi mới xoá (Snapshot).

Đặt DeletionPolicy: Snapshot khớp chính xác từng chữ trong yêu cầu: stack vẫn xoá được bình thường, volume vẫn được dọn đi, nhưng trước đó CloudFormation tự chụp snapshot — nên yêu cầu backup/compliance được đảm bảo một cách bắt buộc và tự động, khai báo ngay trong template:

NewVolume:
  Type: AWS::EC2::Volume
  Properties:
    Size: 100
    Encrypted: true
    AvailabilityZone: !GetAtt Ec2Instance.AvailabilityZone
  DeletionPolicy: Snapshot

Điểm mạnh của cách này là nó gắn liền với định nghĩa hạ tầng dưới dạng mã: ai deploy stack đó, deploy ở tài khoản nào, xoá bằng console hay CLI, hành vi snapshot vẫn xảy ra như nhau.

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

B — Enable termination protection. Đây là phương án gần đúng nhất về mặt "bảo vệ dữ liệu", nhưng nó giải sai bài toán. Termination protection là cờ ở cấp stack, có tác dụng chặn việc xoá stack: ai đó gọi delete thì thao tác thất bại, stack giữ nguyên trạng thái cũ. Nó bảo vệ khỏi xoá nhầm, chứ không tạo ra snapshot nào cả. Đề bài không nói "ngăn không cho xoá stack" — đề bài giả định stack sẽ bị xoá và hỏi lúc đó làm sao có snapshot. Bật termination protection thì hoặc là không bao giờ xoá được stack, hoặc lúc tắt cờ đi để xoá thì volume vẫn mất trắng cùng dữ liệu.

C — Use cfn helper scripts and Wait Conditions upon stack deletion. Các cfn helper script (cfn-init, cfn-signal, cfn-hup…) và Wait Condition phục vụ giai đoạn tạo/cập nhật tài nguyên: cài gói phần mềm trên EC2 instance, báo hiệu instance đã khởi tạo xong, cho CloudFormation biết có nên tiếp tục hay rollback. Chúng chạy bên trong instance và gắn với luồng provisioning, không phải cơ chế để cưỡng chế một hành động lúc xoá stack. Dùng chúng để bảo đảm "bắt buộc phải có snapshot" là không thực hiện được — mà cả khi có cách lách nào đó thì cũng phụ thuộc vào instance còn sống và script còn chạy đúng, tức là không còn tính bắt buộc mà đề yêu cầu.

D — Reference the EBS volume as a stack output. Section Outputs chỉ dùng để công bố giá trị: xuất ra để stack khác import (cross-stack reference), trả về khi mô tả stack, hoặc hiển thị trên console. Nó không sinh ra snapshot. Đúng là có một tác dụng phụ: giá trị đã export mà đang được stack khác import thì stack gốc không xoá được — nhưng đó lại rơi vào đúng cái bẫy của phương án B, tức là chặn xoá chứ không phải chụp snapshot, và còn là một hiệu ứng gián tiếp, tình cờ, phụ thuộc việc có stack khác import hay không. Chỉ khai volume ra Outputs thì hoàn toàn không ép được yêu cầu backup nào.

📌 Điểm cần nhớ

• DeletionPolicy là chỗ trả lời mọi câu hỏi dạng "khi stack bị xoá thì tài nguyên X phải ra sao", với ba lựa chọn cần thuộc: Delete, Retain, và Snapshot (chỉ áp dụng cho những loại tài nguyên hỗ trợ snapshot, ví dụ EBS volume, RDS DB instance).
• Phân biệt rành mạch "giữ lại dữ liệu khi xoá" (DeletionPolicy) với "không cho xoá" (termination protection). Đề nói stack sẽ bị xoá → chọn DeletionPolicy; đề nói chống xoá nhầm stack → chọn termination protection.
• cfn helper scripts và Wait Conditions thuộc giai đoạn create/update, không phải delete — thấy chúng xuất hiện trong câu hỏi về xoá stack thì gần như chắc chắn là mồi nhử.
• Outputs chỉ để công bố và chia sẻ giá trị giữa các stack, không phải cơ chế kiểm soát vòng đời tài nguyên; hiệu ứng "không xoá được stack đang bị import" là hệ quả phụ, đừng nhầm nó với một chính sách backup.

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

Đề mô tả một website chạy trên T2.micro trong Auto Scaling group, đằng sau một ELB. Lưu lượng tăng mạnh, người dùng than phiền chậm, và câu hỏi là làm sao cải thiện hiệu năng ứng dụng (chọn hai).

Cụm từ quyết định nằm gọn trong một câu: "the CPU is being throttled" — CPU đang bị bóp lại. Đây không phải "CPU bận 100%" theo nghĩa thông thường, mà là hành vi riêng của dòng burstable performance instances (T2/T3): mỗi instance chỉ được một mức CPU nền (baseline), muốn chạy cao hơn thì tiêu CPU credit; hết credit thì bị ép về baseline, tức là throttling.

Cụm thứ hai cũng quan trọng: "the ASG is not scaling". Đây là manh mối phụ củng cố chẩn đoán — khi bị throttle về baseline, CPUUtilization báo cáo thường không vượt được ngưỡng đặt trong scaling policy, nên ASG cứ đứng yên trong khi máy chạy lê lết. Vấn đề nằm ở tầng EC2, không phải tầng load balancer.

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

Theo tệp, đáp án đúng là A và D — đúng hai cách AWS nêu để xử lý CPU throttling trên burstable instance:

A — Hết burst credit, đổi sang T2.large hoặc m4.large. Đây là chẩn đoán đúng nguyên nhân gốc: instance đã cạn credit. Hai hướng khắc phục đều nằm trong phương án này:

• Lên một size lớn hơn trong cùng họ burstable (T2.large): size lớn hơn có baseline cao hơn và tốc độ tích luỹ credit nhanh hơn, nên chịu được tải nặng hơn trước khi cạn.
• Chuyển hẳn sang họ không dùng mô hình credit (m4.large): CPU cố định, không có khái niệm cạn credit, nên hiện tượng throttling biến mất hoàn toàn.

D — Bật T2 Unlimited. Đây là cách sửa mà không đổi instance type: khi bật Unlimited, instance được phép duy trì CPU trên baseline liên tục kể cả khi credit đã hết, phần vượt được tính phí thêm. Nói cách khác, nó gỡ bỏ đúng cái trần đang gây throttling. Đây là cách nhanh nhất, không cần thay máy hay khởi động lại đội instance.

Hai phương án này là hai nhánh của cùng một hướng dẫn AWS: gặp CPU throttling trên T2/T3 thì hoặc bật Unlimited, hoặc đổi instance type.

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

B — Đổi ELB từ Application Load Balancer sang Network Load Balancer. Đây là distractor kinh điển: nó thay đổi tầng load balancer trong khi nút thắt nằm ở CPU của EC2. Đổi ALB thành NLB chỉ đổi tầng xử lý (từ layer 7 sang layer 4) và mất luôn các tính năng định tuyến theo nội dung; request vẫn được chuyển tới đúng đội T2.micro đang bị bóp CPU, nên người dùng vẫn chậm y như cũ. Đề cũng không hề than phiền về độ trễ hay throughput của ELB.

C — Cần pre-warm Load Balancer. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì pre-warming là chuyện có thật. Nhưng nó chỉ áp dụng cho tình huống flash traffic — lưu lượng tăng đột ngột theo bậc thang, hoặc chạy load test không thể tăng dần — khi ấy phải liên hệ AWS để họ cấu hình sẵn dung lượng cho load balancer. Ở đây lưu lượng tăng dần theo độ nổi tiếng của website, và triệu chứng được mô tả rõ ràng là CPU throttling trên EC2, không phải load balancer từ chối hay chậm nhận kết nối. Chữa đúng bệnh của người khác thì vẫn là chữa sai.

E — Tắt ELB stickiness. Sticky session (session affinity) buộc một người dùng luôn về đúng một instance. Về lý thuyết stickiness có thể gây phân bổ tải lệch, nên nghe qua khá hợp lý. Nhưng đề không nói gì tới stickiness đang bật, cũng không mô tả triệu chứng lệch tải kiểu "một máy nóng, các máy khác rảnh". Triệu chứng là mọi instance đều bị throttle vì cạn credit — tắt stickiness chỉ trải request đều hơn lên một đội máy mà máy nào cũng đã cạn credit, không tạo thêm được chút CPU nào.

Cả B, C, E đều chung một lỗi: can thiệp vào tầng ELB trong khi ràng buộc nằm ở tầng EC2.

📌 Điểm cần nhớ

• Thấy chữ "CPU throttled" đi cùng instance họ T2/T3, phản xạ đầu tiên phải là cạn CPU credit, không phải "thiếu máy" hay "load balancer yếu". Hai cách chữa chính thức: bật T2/T3 Unlimited, hoặc đổi instance type (lên size lớn hơn trong họ burstable, hoặc sang họ CPU cố định).
• ASG không scale mà máy vẫn chậm là dấu hiệu đặc trưng của throttling: CPU bị ép về baseline nên không chạm ngưỡng scaling policy. Đừng vội kết luận cấu hình ASG sai.
• Burstable instance hợp với workload tải thấp và có lúc nghỉ để tích credit (dev/test, microservice nhỏ, prototype). Website đã bùng nổ lưu lượng thì mô hình credit không còn phù hợp.
• Kỹ năng làm bài: xác định đúng tầng đang thắt cổ chai trước khi đọc phương án. Câu này cố tình đặt ELB vào đề để mồi ba phương án ở tầng load balancer, trong khi mọi triệu chứng đều chỉ về EC2.

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

Đề mô tả một service provider sinh báo cáo hằng ngày, lưu trong S3, và cần chia sẻ cho hơn 10.000 khách hàng với danh sách thay đổi liên tục. Kiến trúc phía trước đã chốt sẵn: Cognito + API Gateway + Lambda lo phần chứng thực danh tính. Câu hỏi chỉ hỏi đúng một mảnh: phía S3 phải làm gì.

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

• "dynamically changing list of over 10,000 customers" — số lượng lớn và biến động, nên mọi giải pháp đòi tạo/xoá một danh tính hay một bí mật cho từng khách hàng đều gãy về mặt vận hành.
• "on-demand access upon their identity being proven" — quyền truy cập được cấp sau khi Cognito xác thực xong, tức là cấp tại thời điểm chạy, không phải cấu hình tĩnh sẵn trên bucket.
• "You plan to use Cognito, API Gateway and AWS Lambda" — phần chứng thực đã có chủ. Việc còn lại của S3 chỉ là biến kết quả chứng thực đó thành một quyền đọc object có thời hạn.

Ghép ba ràng buộc: cần một cơ chế cấp quyền tạm thời, sinh động, không cần danh tính AWS phía khách hàng.

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

A — Generate pre-signed URLs for your reports.

Mặc định mọi object trong S3 là private, chỉ chủ object mới đọc được. Pre-signed URL là cách chủ object dùng security credentials của chính mình để ký một URL, qua đó trao quyền có giới hạn thời gian cho bất kỳ ai cầm URL đó.

Khi tạo pre-signed URL, bạn khai bucket name, object key, HTTP method (GET để tải về) và thời điểm hết hạn. URL chỉ có hiệu lực trong khoảng thời gian đã khai.

Ghép vào kiến trúc của đề: khách hàng đăng nhập qua Cognito, gọi API Gateway, hàm Lambda kiểm tra danh tính rồi sinh pre-signed URL trỏ đúng báo cáo của người đó và trả về. Bucket vẫn private hoàn toàn, không cần sửa bucket policy mỗi khi danh sách khách hàng thay đổi, và không cần cấp cho ai một AWS identity nào. Đúng nghĩa "on-demand access upon their identity being proven".

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

B — Make the S3 bucket public and password protect each S3 file. Đây là distractor thuần: S3 không có chức năng đặt mật khẩu cho từng file. Không có tính năng nào như vậy để mà dùng. Thêm nữa, mở public bucket rồi trông chờ vào một lớp bảo vệ không tồn tại nghĩa là mọi báo cáo đều bị đọc tự do. Sai cả về tính năng lẫn về bảo mật.

C — Provide each of your customers an AWS user and tell them to use the CLI. Về kỹ thuật thì IAM user có thể đọc S3, nên phương án này nghe có vẻ chạy được — nhưng nó hỏng ở đúng ràng buộc đề nhấn mạnh: hơn 10.000 khách hàng, danh sách thay đổi liên tục. Tạo, xoay khoá và thu hồi từng IAM user cho khách hàng bên ngoài là bất khả thi về vận hành. Ngoài ra nó mâu thuẫn với chính kiến trúc đề đưa ra: đã có Cognito lo danh tính người dùng cuối rồi thì không có lý do gì bắt khách hàng phải có thêm một AWS identity riêng và phải biết dùng CLI.

D — Bucket policy chỉ cho phép truy cập từ CloudFront và force SSL mutual authentication ở đó. Đây là phương án gần đúng nhất và cũng là bẫy chính. Phần đầu hợp lý — khoá bucket để chỉ CloudFront đọc được là mẫu quen thuộc. Nhưng phần sau sai về mặt tính năng: mutual TLS authentication được hỗ trợ ở Amazon API Gateway, không phải ở CloudFront. Cơ chế client-to-server authentication này là một tuỳ chọn authorization của API Gateway, không phải thứ bạn "force" được tại CloudFront. Vậy nên vế quyết định quyền truy cập của phương án này không tồn tại như mô tả, và câu trả lời sụp đổ.

📌 Điểm cần nhớ

• Chia sẻ object S3 private cho người dùng bên ngoài, số lượng lớn, không có AWS identity → pre-signed URL. Đây là mẫu mặc định cho dạng đề "share file với khách hàng sau khi xác thực".
• Pre-signed URL mang quyền của người ký, có hạn dùng. Ai cầm URL cũng truy cập được trong thời gian đó — nên hạn ngắn và chỉ trả URL sau khi đã xác thực xong.
• Thấy "10.000 khách hàng" hoặc "danh sách thay đổi liên tục" là loại ngay phương án tạo IAM user hay chia sẻ credential cho từng người. Ràng buộc quy mô luôn được đặt vào đề để giết đúng loại phương án này.
• Mutual TLS là tính năng của API Gateway, không phải CloudFront — một chi tiết được dùng đi dùng lại để dựng phương án nghe hợp lý mà sai.
• S3 không có "password protect file". Bất kỳ phương án nào nhắc tới việc đặt mật khẩu cho object S3 đều loại được ngay mà không cần đọc tiếp.