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

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

Đề mô tả một startup dùng Amazon S3 để lưu dữ liệu khách hàng, đặt các retention period khác nhau cho từng object theo yêu cầu tuân thủ, nhưng "the retention rules do not seem to work as expected". Câu hỏi thực chất không đòi bạn debug hệ thống của họ, mà hỏi: những điểm nào cần nhớ khi cấu hình retention period cho object trong S3 — chọn hai.

Cụm từ quyết định nằm ở chỗ "different retention periods for different objects" và ở chính cơ chế S3 Object Lock: retention áp lên object version, chứ không áp lên "object" như một thực thể duy nhất. Thêm một trục phân biệt thứ hai xuyên suốt cả năm phương án: sự khác nhau giữa explicit retention (đặt trực tiếp lên một version) và bucket default setting. Hai cơ chế này khai báo thời hạn theo hai kiểu khác nhau, và có thứ tự ưu tiên rõ ràng. Phương án nào nói ngược hai điều đó là sai.

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

A — Different versions of a single object can have different retention modes and periods. Giống mọi thiết lập Object Lock khác, retention period gắn vào từng object version riêng lẻ. Ví dụ trong tài liệu AWS: một version đã đi được 15 ngày trong retention period 30 ngày; bạn PUT một object cùng tên với retention period 60 ngày. Lệnh PUT thành công, S3 tạo version mới với retention 60 ngày, còn version cũ giữ nguyên thời hạn gốc và sẽ xoá được sau 15 ngày nữa. Đây chính là điểm hay làm người vận hành tưởng "retention không hoạt động".

E — When you apply a retention period to an object version explicitly, you specify a Retain Until Date. Với cách đặt explicit, bạn khai một mốc thời gian cụ thể. S3 lưu Retain Until Date trong metadata của object version và bảo vệ version đó cho tới khi mốc này qua đi.

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

B — When you use bucket default settings, you specify a Retain Until Date for the object version. Đây là phương án gần đúng nhất và là bẫy chính: nó lấy đúng câu chữ của E rồi gán nhầm sang cơ chế kia. Với bucket default settings, bạn không khai Retain Until Date, mà khai một khoảng thời lượng (duration) tính bằng ngày hoặc năm, áp cho mọi object version được đưa vào bucket. Mốc ngày cụ thể là chuyện của explicit retention.

C — The bucket default settings will override any explicit retention mode or period. Ngược chiều ưu tiên. Nếu request đưa object version vào bucket có kèm retention mode và period explicit, thì chính các thiết lập explicit đó đè lên bucket default cho version ấy. Default chỉ là giá trị áp dụng khi request không nói gì.

D — You cannot place a retention period on an object version through a bucket default setting. Sai ở mệnh đề phủ định. S3 cho phép đặt retention period lên object version theo cả hai đường: explicit hoặc qua bucket default setting. Phương án này phủ nhận đúng một nửa cơ chế mà B và C đang bàn tới.

📌 Điểm cần nhớ

• Object Lock retention áp lên object version, không phải lên "object". Nhiều version của cùng một tên object có thể mang mode và period khác nhau; PUT một version mới không ghi đè hay rút ngắn retention của version cũ.
• Hai cách đặt retention, hai kiểu khai báo: explicit → Retain Until Date (mốc thời gian), bucket default → duration (số ngày/năm). Gặp phương án đảo hai vế này là bẫy quen thuộc.
• Thứ tự ưu tiên: explicit đè lên bucket default, không bao giờ ngược lại. Bucket default chỉ lấp chỗ trống khi request không khai retention.
• Khi retention "không như mong đợi", nghi ngờ đầu tiên nên là version cũ vẫn giữ thời hạn cũ, hoặc explicit setting trong request đang lặng lẽ đè lên default của bucket.

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

Đề bài dựng bối cảnh một nhóm phát triển đang dùng Amazon RDS for MySQL, và một quản trị viên hệ thống mới muốn hiểu khả năng replication của Multi-AZ so với Read Replica. Câu hỏi yêu cầu chọn phương án tóm tắt đúng hai cơ chế này.

Đây là dạng câu "so sánh hai khái niệm", nên đề bài không có ràng buộc nghiệp vụ kiểu "chi phí thấp nhất" hay "downtime tối thiểu". Thay vào đó, cụm từ quyết định nằm ngay trong thân của bốn phương án, và mỗi phương án là một tổ hợp của ba biến số:

1. Multi-AZ dùng synchronous hay asynchronous replication?
2. Multi-AZ trải trên một hay ít nhất hai Availability Zone trong cùng một region?
3. Read replica dùng synchronous hay asynchronous replication?

Chỉ cần nắm chắc rằng Multi-AZ là cơ chế đồng bộ phục vụ tính sẵn sàng, còn Read Replica là cơ chế bất đồng bộ phục vụ khả năng mở rộng đọc, là loại được ba phương án sai. Phần "within an Availability Zone, Cross-AZ, or Cross-Region" của Read Replica giống hệt nhau ở cả bốn phương án nên nó không phải điểm phân biệt — đừng mất thời gian ở đó.

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

Đáp án D: Multi-AZ follows synchronous replication and spans at least two Availability Zones within a single region. Read replicas follow asynchronous replication and can be within an Availability Zone, Cross-AZ, or Cross-Region.

Khi bạn tạo một Multi-AZ DB instance, Amazon RDS tự dựng một primary DB instance và sao chép dữ liệu đồng bộ sang một standby instance nằm ở Availability Zone khác. Đồng bộ ở đây nghĩa là giao dịch chỉ được xem là commit khi cả hai bản đã ghi xong — đó chính là lý do Multi-AZ được dùng cho workload production: nó nhắm tới tính sẵn sàng và độ bền dữ liệu, không nhắm tới hiệu năng. Và vì standby luôn ở AZ khác, Multi-AZ theo định nghĩa trải ít nhất hai AZ trong cùng một region.

Read Replica thì ngược lại về mục tiêu: nó sinh ra để mở rộng năng lực đọc vượt qua giới hạn của một DB instance đơn với workload nặng về đọc. Với các engine MySQL, MariaDB, PostgreSQL, Oracle và SQL Server, RDS tạo instance thứ hai từ một snapshot của instance nguồn, rồi dùng cơ chế replication bất đồng bộ có sẵn của chính engine để cập nhật replica mỗi khi nguồn thay đổi. Bất đồng bộ nên replica có thể trễ so với nguồn (replication lag) — cái giá phải trả để không làm chậm giao dịch ghi ở primary. Read replica đặt được trong cùng AZ, khác AZ, hoặc khác region.

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

• Phương án A — Multi-AZ asynchronous, ít nhất hai AZ; Read replica asynchronous. Đây là phương án gần đúng nhất và cũng là bẫy chính: nó nói đúng cả về phạm vi AZ của Multi-AZ lẫn tính bất đồng bộ của Read Replica. Nó hỏng ở đúng một chữ: Multi-AZ là synchronous, không phải asynchronous. Nếu Multi-AZ mà bất đồng bộ thì khi failover sang standby sẽ có nguy cơ mất giao dịch vừa commit — mâu thuẫn với chính mục đích "enhanced availability and durability" của nó.

• Phương án B — Multi-AZ asynchronous, ít nhất hai AZ; Read replica synchronous. Sai cả hai vế replication: nó đảo ngược đúng bản chất của hai cơ chế. Read replica mà đồng bộ thì mỗi lượt ghi ở primary phải chờ mọi replica xác nhận, kể cả replica đặt ở region khác — điều đó biến tính năng "mở rộng đọc" thành gánh nặng cho đường ghi. Chỉ có phần phạm vi AZ của Multi-AZ là đúng.

• Phương án C — Sai nhiều nhất, hỏng ở cả ba biến số. Ngoài việc đảo ngược cả hai kiểu replication như phương án B, nó còn nói Multi-AZ chỉ trải một Availability Zone. Nếu primary và standby cùng nằm trong một AZ thì sự cố ở AZ đó hạ luôn cả hai bản — mất sạch ý nghĩa của cái tên "Multi-AZ".

📌 Điểm cần nhớ

• Multi-AZ = synchronous + high availability; Read Replica = asynchronous + read scaling. Nhớ cặp đối lập này là xử lý được gần như mọi câu so sánh hai tính năng RDS.
• Multi-AZ luôn nằm trong một region nhưng trải ít nhất hai AZ; standby không phục vụ đọc mà chỉ chờ failover.
• Read Replica linh hoạt về vị trí: same-AZ, Cross-AZ, hoặc Cross-Region — và vì bất đồng bộ nên luôn phải tính tới replication lag khi ứng dụng đọc từ replica.
• Với dạng câu "tổ hợp nhiều mệnh đề" như thế này, hãy tách phương án thành từng biến số rồi loại theo từng biến, thay vì đọc cả câu dài và so cảm tính — các phương án được viết cố ý chỉ khác nhau một hai chữ.

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

Đề mô tả một công ty chạy nhiều VPC khác nhau cho từng ứng dụng. Người quản trị muốn cấu hình Network ACL và Security Group của VPC1 sao cho tài nguyên bên VPC2 truy cập được vào VPC1. Câu hỏi: cách cấu hình nào là đúng nhất?

Cụm từ quyết định nằm ở chỗ đề bắt bạn nói về cả hai lớp bảo vệ cùng lúc — "configure the Network ACL and Security Group". Bốn phương án thực chất là bốn phát biểu về mối quan hệ giữa Security Group và Network ACL, nên đây không phải câu hỏi thao tác mà là câu kiểm tra bạn có nắm ba tính chất nền tảng không:

• Security Group hoạt động ở mức instance, Network ACL ở mức subnet — hai lớp độc lập, không kế thừa nhau.
• Security Group chỉ có allow rule, không có deny rule; Network ACL có cả allow lẫn deny.
• Default Network ACL cho phép toàn bộ traffic vào ra, còn Security Group mặc định chặn hết inbound.

Ai nắm ba điều này thì loại được ba phương án sai chỉ bằng cách đọc câu chữ.

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

Đáp án đúng theo tệp là D: cấu hình Security Group của các instance trong VPC1 để cho phép inbound traffic từ tài nguyên bên VPC2; còn Network ACL mặc định của VPC1 vốn đã cho phép mọi inbound và outbound nên không cần sửa gì.

Phát biểu này khớp đúng hành vi mặc định của VPC. Security Group là virtual firewall gắn ở mức instance: mặc định nó không cho inbound nào đi vào, nên muốn VPC2 gọi sang thì bắt buộc phải thêm inbound rule cho nguồn đó. Ngược lại, default Network ACL đi kèm VPC cho phép toàn bộ traffic cả hai chiều — nó là lớp bảo vệ tuỳ chọn, chỉ cần đụng tới khi bạn muốn siết thêm ở mức subnet. Vậy công việc thực sự phải làm chỉ nằm ở một chỗ: Security Group.

Chi tiết đáng nhớ đi kèm: Security Group stateful — traffic phản hồi cho một request đã được cho phép sẽ tự đi ngược lại bất kể outbound rule. Network ACL thì stateless — chiều đi và chiều về được xét bằng hai bộ rule riêng biệt. Đây chính là lý do khi siết Network ACL người ta hay quên mở dải ephemeral port cho chiều về.

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

A — "Network ACL và Security Group có quan hệ cha–con, cấp quyền ở NACL thì SG tự có theo": sai ngay ở tiền đề. Hai thứ này nằm ở hai tầng khác nhau (subnet và instance), là hai lớp bảo vệ độc lập chứ không tạo thành hệ thống phân cấp. Mở Network ACL không hề nới lỏng Security Group; traffic phải qua được cả hai mới tới được instance.

B — "Dựa vào cấu hình NACL để tạo deny rule tương ứng trên Security Group, chặn mọi thứ trừ VPC2": hỏng ở hai chỗ. Thứ nhất, hai lớp không chia sẻ quyền cho nhau nên chuyện "dựa vào cấu hình bên này để soi sang bên kia" là vô nghĩa. Thứ hai, và quan trọng hơn: Security Group chỉ hỗ trợ allow rule, không có deny rule. Muốn deny tường minh thì phải dùng Network ACL. Đây là điểm phân biệt kinh điển giữa hai lớp, và cũng là điểm mà phương án B tự tố cáo mình.

C — Đây là phương án gần đúng nhất, dễ mắc bẫy. Nửa đầu hoàn toàn chính xác: Security Group mặc định cho phép outbound, nên chỉ cần chỉnh inbound để nhận request từ VPC2 — giống hệt ý của đáp án D. Nó chết ở mệnh đề cuối: "nếu subnet không được gắn với Network ACL nào thì không cần chỉnh gì". Tình huống đó không tồn tại. Mỗi subnet trong VPC luôn phải gắn với một network ACL; không gắn tường minh thì AWS tự gắn default network ACL. Câu chữ đúng phải là "Network ACL mặc định cho phép mọi traffic nên không cần chỉnh", tức là chính cách D diễn đạt. C nói đúng kết luận nhưng bằng một lý do không có thật.

So D với C: cả hai cùng bảo "chỉ cần sửa Security Group", nhưng chỉ D mô tả đúng lý do — không phải vì subnet thiếu Network ACL, mà vì Network ACL mặc định vốn đã mở.

📌 Điểm cần nhớ

• Security Group ở mức instance, Network ACL ở mức subnet, hoàn toàn độc lập. Không có quan hệ cha–con; traffic phải qua cả hai lớp.
• Security Group chỉ có allow rule; Network ACL có cả allow và deny. Phương án nào nhắc tới "deny rule trên Security Group" là sai không cần đọc tiếp.
• Mặc định: Security Group chặn hết inbound / mở hết outbound; default Network ACL mở cả hai chiều. Vì vậy công việc mở đường cho traffic mới gần như luôn nằm ở Security Group.
• Mọi subnet đều có một Network ACL — không gắn tay thì nhận default network ACL. Đừng tin phương án nào dựng lên tình huống "subnet không có NACL".
• Stateful vs stateless: SG tự cho traffic phản hồi đi về; NACL xét chiều về bằng rule riêng, nên siết NACL phải tính tới ephemeral port.

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

Đề mô tả một công ty streaming video muốn dùng CloudFront để phân phối nội dung chỉ cho những người đã đăng ký thuê bao (service subscribers). Câu hỏi yêu cầu chọn hai giải pháp để phân phối "restricted content".

Cụm từ quyết định đáp án là "distribute its content only to its service subscribers" và "deliver restricted content". Đây là bài toán kiểm soát ai được xem — tức là ủy quyền (authorization) ở tầng phân phối.

Điểm bẫy nằm ở chỗ ba phương án còn lại đều nói về HTTPS. HTTPS trả lời câu hỏi "dữ liệu có bị nghe lén trên đường truyền không" — đó là mã hóa đường truyền giữa CloudFront và origin. Nó hoàn toàn không trả lời câu hỏi "người đang gọi request này có phải thuê bao không". Nhận ra khác biệt giữa encryption in transit và access control là chìa khóa giải câu này.

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

Theo tệp, đáp án đúng là A và D.

D — CloudFront signed URLs. Đây là cơ chế CloudFront dành riêng cho private content. Bạn tạo một URL có kèm chữ ký cùng một policy, trong đó có thể đặt thời điểm hết hạn và các ràng buộc truy cập khác. Chỉ người cầm đúng URL đã ký mới lấy được nội dung; URL hết hạn thì không dùng lại được nữa. Với mô hình thuê bao, ứng dụng chỉ phát signed URL sau khi đã xác thực người dùng là thuê bao hợp lệ.

A — CloudFront signed cookies. Cùng họ cơ chế private content, nhưng thay vì ký từng URL thì ký một cookie đặt vào trình duyệt. Điểm mạnh đúng với tình huống trong đề: khi bạn không muốn đổi các URL hiện có, hoặc khi cần cấp quyền cho nhiều tệp cùng lúc — chẳng hạn toàn bộ khu vực dành cho thuê bao trên website. Một luồng video thường gồm rất nhiều segment và file manifest, ký riêng từng URL là bất tiện; signed cookies cấp quyền cho cả nhóm nội dung trong một lần.

Hai phương án này là hai mặt của cùng một tính năng CloudFront (restricting access to content), nên chúng đi thành cặp.

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

C — Require HTTPS for communication between CloudFront and your custom origin. Đây là cấu hình có thật và nên bật, nhưng nó chỉ đảm bảo chặng CloudFront → custom origin được mã hóa. Nó không hề phân biệt được người xem là thuê bao hay khách vãng lai: sau khi bật, một người chưa đăng ký vẫn gọi được distribution và vẫn nhận được nội dung. Đây là phương án gần đúng nhất về mặt "nghe có vẻ bảo mật", nhưng nó nhắm sai lớp — bảo vệ đường truyền, không phải kiểm soát truy cập.

E — Require HTTPS for communication between CloudFront and your S3 origin. Hỏng đúng như C, chỉ đổi loại origin từ custom sang S3. Mã hóa chặng về origin không hề tạo ra khái niệm "thuê bao". Việc đề đưa cả C lẫn E vào cho thấy chúng là cặp phân tán sự chú ý: nếu HTTPS là câu trả lời thì đã có hai đáp án đúng nhưng lại không hề đụng tới yêu cầu "only to its service subscribers".

B — Forward HTTPS requests to the origin server by using the ECDSA or RSA ciphers. Đây là phương án gây nhiễu thuần túy. Nó nói về bộ cipher dùng khi bắt tay TLS — tức chi tiết kỹ thuật bên trong chuyện mã hóa đường truyền, còn xa yêu cầu của đề hơn cả C và E. Nhắc tới ECDSA/RSA dễ khiến người học liên tưởng tới key pair dùng để ký signed URL, nhưng hai chuyện hoàn toàn khác nhau: một bên là thuật toán bắt tay TLS ở chặng về origin, một bên là ký policy để chặn người không có quyền.

📌 Điểm cần nhớ

• Đề hỏi ai được xem (restricted content, subscribers, paid users) thì đáp án là signed URLs hoặc signed cookies; đề hỏi dữ liệu có được mã hóa trên đường đi thì mới tới HTTPS/viewer protocol policy. Đọc đề, phân loại vào một trong hai nhóm trước khi nhìn phương án.
• Phân biệt signed URL và signed cookie: signed URL hợp với từng tệp riêng lẻ và khi bạn kiểm soát được việc sinh link; signed cookie hợp khi không muốn đổi URL hiện có hoặc cần cấp quyền cho nhiều tệp trong một khu vực.
• Signed URL/cookie mang theo policy có thời hạn, nên quyền truy cập tự hết hiệu lực — phù hợp với mô hình thuê bao có thể ngưng gia hạn.
• Cấu hình HTTPS về origin (S3 hay custom) là thực hành tốt nhưng không bao giờ là câu trả lời cho bài toán giới hạn người xem; gặp phương án dạng này trong câu hỏi về private content thì loại ngay.

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

Một công ty thương mại điện tử chạy hạ tầng trên AWS Elastic Beanstalk và sắp triển khai phiên bản mới của ứng dụng. Đề yêu cầu chọn cách triển khai thoả đồng thời hai điều kiện:

• MINIMUM application downtime — thời gian ứng dụng không phục vụ được phải ít nhất có thể;
• the ability to rollback quickly in case the deployment goes wrong — quay lui phải nhanh khi bản mới có vấn đề.

Cụm từ quyết định là "rollback quickly". Đây chính là ràng buộc tách bạch các phương án gần giống nhau. Nếu đề chỉ hỏi "không downtime" thì cả Rolling, Rolling with additional batch lẫn Blue/Green đều là câu trả lời hợp lệ, và câu hỏi sẽ không có đáp án duy nhất. Chính yêu cầu quay lui nhanh mới loại được ba deployment policy in-place, vì với chúng, muốn trở về bản cũ thì phải triển khai lại (manual redeploy) — tức là chịu thêm một chu kỳ deploy nữa, đúng lúc production đang hỏng.

Chi tiết thứ hai đáng chú ý: các policy All at once, Rolling, Rolling with additional batch đều là in-place update — Elastic Beanstalk cập nhật ngay trên các instance của environment hiện tại. Phương án B thì ngược lại, dựng environment riêng biệt.

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

Đáp án đúng là B — Blue/Green Deployment sang một environment riêng, rồi hoán đổi bản ghi Route 53 để chuyển traffic sang phiên bản mới.

Cách làm này triển khai phiên bản mới lên một environment hoàn toàn tách rời với environment đang phục vụ khách. Bản mới được dựng xong, kiểm tra xong, chỉ khi ổn mới đưa vào phục vụ — và việc "đưa vào phục vụ" chỉ là hoán đổi CNAME/bản ghi Route 53 giữa hai environment. Vì môi trường mới đã sẵn sàng từ trước, thao tác chuyển traffic diễn ra gần như tức thì, nên downtime ở mức tối thiểu.

Quan trọng hơn với đề bài: rollback cũng chỉ là hoán đổi URL ngược lại. Environment cũ vẫn còn nguyên đó, vẫn chạy phiên bản cũ, không bị đụng tới trong suốt quá trình. Không cần build lại, không cần redeploy, không phải chờ instance khởi động lại — đó là lý do đây là phương án duy nhất đáp ứng được "rollback quickly".

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

A. Rolling deployment policy — Đây là phương án gần đúng, và cần nói rõ nó hỏng ở đâu. Rolling cập nhật ứng dụng theo từng batch instance, nên tránh được downtime và chỉ làm giảm năng lực phục vụ tạm thời (vì trong lúc một batch đang cập nhật, số instance phục vụ bị hụt đi). Vế "minimum downtime" thì nó qua được. Nhưng nó là in-place update: khi bản mới lỗi, muốn về bản cũ phải redeploy thủ công phiên bản trước, lại đi qua đúng quy trình rolling lần nữa. Vế "rollback quickly" trượt.

C. Rolling with additional batch — Cũng gần đúng, thậm chí tốt hơn Rolling ở khía cạnh khả dụng: nó dựng thêm một batch instance mới trước khi cập nhật, nên giữ nguyên được năng lực phục vụ trong suốt quá trình, hợp với trường hợp bắt buộc duy trì đủ bandwidth. Đổi lại, thời gian deploy còn dài hơn Rolling. Điểm chí mạng vẫn giống A: đây vẫn là in-place update trên environment hiện tại, rollback vẫn phải redeploy thủ công, không hề nhanh. Nói cách khác, C giải quyết tốt hơn vế thứ nhất của đề nhưng không chạm được vế thứ hai — mà vế thứ hai mới là cái đề dùng để phân loại.

D. All at once — Cập nhật toàn bộ instance cùng lúc. Đây là cách nhanh nhất về thời gian deploy, nhưng đổi lại ứng dụng có thể không phục vụ được (hoặc khả dụng rất thấp) trong một khoảng ngắn vì tất cả instance cùng đổi phiên bản. Nó vi phạm ngay vế "MINIMUM downtime" — tức là trượt ngay ở điều kiện đầu tiên, chưa cần bàn đến rollback (mà rollback cũng vẫn là redeploy thủ công).

📌 Điểm cần nhớ

• Trong Elastic Beanstalk, thấy đề đòi "rollback nhanh" thì gần như luôn là Blue/Green chứ không phải một deployment policy nào. Ba policy in-place chỉ khác nhau ở downtime và thời gian deploy, còn cách quay lui thì đều là redeploy thủ công.
• Phân biệt hai khái niệm dễ lẫn: deployment policy (All at once, Rolling, Rolling with additional batch) cập nhật tại chỗ trên environment đang chạy; Blue/Green dựng environment thứ hai rồi hoán đổi CNAME qua Route 53.
• Thang đo giữa các policy in-place: All at once nhanh nhất nhưng có downtime → Rolling không downtime, chấp nhận giảm khả dụng tạm thời, deploy lâu hơn → Rolling with additional batch giữ nguyên khả dụng, deploy lâu hơn nữa.
• Khi hai phương án cùng thoả một điều kiện của đề, hãy tìm điều kiện thứ hai — ở đây "minimum downtime" không loại được A và C, chỉ "rollback quickly" mới loại được.

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

Đề mô tả một Systems Administrator đang cấu hình Application Load Balancer (ALB) đặt trước các EC2 instance, rồi hỏi hai phát biểu nào đúng về cách cấu hình ALB. Đây là dạng câu kiểm tra kiến thức nền: bạn có nắm được ba thành phần cơ bản của ALB — listener, rule, target group — và quan hệ giữa chúng hay không.

Cụm từ quyết định nằm ở chỗ mỗi phương án khẳng định một ràng buộc rất cụ thể: "must add one or more listeners", "attaching them to the listeners", "same Availability Zone", "default rule" có conditions hay không, và "only one target group at any given time". Ba phương án sai đều sai vì áp đặt một giới hạn mà ALB không có (hoặc gán sai đặc tính cho default rule). Cách đọc đúng là truy theo chuỗi: client → listener (protocol + port) → rule (priority + conditions + actions) → target group → targets.

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

A — "Before you start using your Application Load Balancer, you must add one or more listeners" Listener là cửa vào của load balancer: nó lắng nghe yêu cầu kết nối từ client theo đúng protocol và port mà bạn khai báo. Không có listener thì ALB không có chỗ nào nhận traffic, nên nó chưa phục vụ được gì. Vì vậy thêm ít nhất một listener là bước bắt buộc trước khi đưa ALB vào sử dụng.

B — "You configure target groups of an ALB by attaching them to the listeners" Target group là nơi gom các target (ví dụ EC2 instance) và định tuyến request tới chúng. Target group được nối vào luồng xử lý thông qua rule của listener: khi tạo listener rule, bạn chỉ định conditions và target group tương ứng; condition khớp thì traffic được forward sang target group đó. Nhờ vậy bạn tạo được nhiều target group cho nhiều loại request khác nhau trên cùng một ALB.

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

C — "The targets of a target group in an ALB should all belong to the same Availability Zone" Ngược hẳn với mục đích tồn tại của load balancer. ALB đóng vai trò điểm tiếp xúc duy nhất cho client và phân phối traffic tới nhiều target nằm ở nhiều Availability Zone. Chính việc trải target qua nhiều AZ mới làm tăng tính sẵn sàng của ứng dụng; ép tất cả về một AZ là tự tạo ra single point of failure.

D — "When you create a listener, you define actions and conditions for the default rule" Đây là phương án gài bẫy sát nhất, vì vế "actions" thì đúng. Khi tạo listener bạn có định nghĩa action cho default rule. Chỗ hỏng là chữ "conditions": default rule không được phép có conditions. Nó chính là nhánh dự phòng — khi không rule nào của listener có condition khớp, action của default rule mới được thực thi. Rule thường mới gồm priority + một hoặc nhiều condition + một hoặc nhiều action.

E — "A target can be registered with only one target group at any given time" Sai ở chữ "only one". Một target (ví dụ một EC2 instance) có thể được đăng ký vào nhiều target group cùng lúc — mỗi target group định tuyến tới target theo protocol và port mà bạn chỉ định, nên cùng một instance có thể phục vụ nhiều target group khác nhau. Không có ràng buộc độc quyền như phương án này khẳng định.

📌 Điểm cần nhớ

• Trật tự thành phần của ALB cần thuộc lòng: listener (protocol + port) → rule (priority, conditions, actions) → target group → targets. Target group không "gắn trực tiếp" vào load balancer mà đi vào qua rule của listener.
• Default rule chỉ có action, không có condition. Nó là nhánh chạy khi mọi rule khác trượt condition. Câu nào ghép "default rule" với "conditions" gần như chắc chắn là phương án sai.
• Phát biểu nào ép target của một target group phải cùng một Availability Zone thì đọc là sai — ALB sinh ra để trải traffic qua nhiều AZ nhằm tăng availability.
• Một target đăng ký được vào nhiều target group; hãy cảnh giác với các phương án chứa từ tuyệt đối như "only one", "at any given time", "must all belong to" — chúng thường là ràng buộc bịa thêm.

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

Đề mô tả một công ty bán lẻ bật VPC flow logs cho một VPC, nhưng không thấy log nào chảy về. Đội quản trị đã lần ra được thông báo: trạng thái flow log là Access error. Và câu quan trọng nhất nằm ở cuối đoạn: quản trị viên muốn đổi IAM Role đã khai trong định nghĩa flow log.

Cụm từ quyết định chính là "wants to change the IAM Role defined in the flow log definition". Câu này không hỏi "nguyên nhân của Access error là gì" — nguyên nhân thì đã rõ là chuyện quyền/IAM. Nó hỏi cách đúng để thực hiện việc thay IAM Role đó. Đây mới là chỗ phân biệt A với C: cả hai đều thừa nhận vấn đề nằm ở IAM, nhưng chỉ một trong hai nói đúng về cách sửa.

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

Đáp án đúng là A: lỗi cho thấy IAM role chưa được cấu hình đúng, và sau khi flow log đã được tạo thì không sửa được cấu hình của nó nữa — muốn đổi thì phải xoá flow log cũ và tạo lại một cái mới với cấu hình mong muốn.

Đây là một đặc tính cố hữu của VPC flow logs: định nghĩa flow log là bất biến sau khi tạo. Không gắn được IAM role khác vào flow log đang tồn tại, cũng không thêm/bớt được trường trong định dạng bản ghi (flow log record format). Vòng đời của nó chỉ có tạo và xoá, không có "sửa".

Về bản thân Access error, tài liệu nêu ba nguyên nhân thường gặp, tất cả đều xoay quanh IAM role gắn với flow log:

1. IAM role không đủ quyền để ghi bản ghi flow log vào CloudWatch log group.
2. IAM role không có trust relationship với dịch vụ flow logs.
3. Trust relationship có tồn tại nhưng không khai dịch vụ flow logs làm principal.

Điểm cần thấy: dù nguyên nhân là cái nào trong ba cái đó, cách xử lý khi muốn đổi sang một role khác vẫn là xoá và tạo lại — đúng như A mô tả.

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

B — "Lỗi nội bộ của dịch vụ flow logs, hãy mở service request với AWS". Đây là phương án bịa hoàn toàn, dựng lên để gây nhiễu. Access error là trạng thái có ý nghĩa xác định và trỏ thẳng vào cấu hình IAM phía khách hàng, không phải sự cố nội bộ của dịch vụ. Mở ticket ở đây chỉ tốn thời gian trong khi vấn đề nằm hoàn toàn trong tay người quản trị.

C — "IAM role thiếu trust relationship với dịch vụ flow logs, hãy đổi trust relationship từ cấu hình flow log". Đây là phương án gần đúng nhất và cũng là cái bẫy chính. Nửa đầu của nó hợp lệ: thiếu trust relationship đúng là một trong những nguyên nhân sinh ra Access error. Nó hỏng ở nửa sau: không có cách nào "đổi trust relationship từ cấu hình flow log", vì cấu hình flow log không sửa được sau khi tạo. Trust policy là thuộc tính của chính IAM role bên IAM, còn việc gắn role nào vào flow log thì đã đóng băng. Thêm nữa, đề nói rõ quản trị viên muốn đổi sang IAM Role khác — chứ không phải vá lại role hiện tại — nên hướng đi của C càng lệch. Chọn C là dấu hiệu người học đọc đúng triệu chứng nhưng bỏ qua ràng buộc bất biến của flow log.

D — "Flow log vẫn đang trong quá trình tạo, đôi khi mất tới 10 phút mới có log". Tình huống này có thật ở khía cạnh khác: sau khi vừa bật flow logs, bản ghi đầu tiên không xuất hiện tức thì, cần một khoảng thời gian mới thấy dữ liệu. Nhưng D bị loại bởi chính dữ kiện trong đề: trạng thái đang là lỗi. Flow log còn đang khởi tạo bình thường sẽ không nằm ở trạng thái error. Chờ thêm bao lâu cũng không làm Access error tự biến mất.

📌 Điểm cần nhớ

• Cấu hình VPC flow log là bất biến. Không đổi được IAM role, không đổi được flow log record format sau khi tạo. Muốn thay đổi bất cứ thứ gì: xoá rồi tạo lại. Gặp bất kỳ phương án nào có chữ "modify/change the flow log configuration", hãy nghi ngờ ngay.
• Access error = vấn đề IAM role của flow log, gồm ba khả năng: thiếu quyền ghi vào CloudWatch log group, thiếu trust relationship với dịch vụ flow logs, hoặc trust relationship không khai flow logs làm principal.
• Phân biệt "chưa có log" với "log ở trạng thái lỗi". Chưa thấy bản ghi ngay sau khi bật là bình thường và sẽ tự hết; còn trạng thái error thì phải can thiệp, chờ đợi không giải quyết được gì.
• Đọc kỹ đề hỏi nguyên nhân hay hỏi cách sửa. Nhiều phương án nhiễu mô tả đúng nguyên nhân nhưng đề xuất một thao tác không tồn tại — nửa đầu đúng không cứu được nửa sau sai.

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

Tình huống: một developer truy cập S3 bucket chứa ảnh cho web application. Bucket đã bật public read access, nhưng khi truy cập lại nhận 403 Access Denied. Câu hỏi đặt ra dưới góc nhìn SysOps Administrator: "how will you troubleshoot this issue?"

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

• "public read access enabled" — đối tượng cần đọc là public object, không phải object riêng tư. Đây chính là phạm vi mà công cụ chẩn đoán của AWS được thiết kế để xử lý.
• "how will you troubleshoot" — đề hỏi cách chẩn đoán, tức là quy trình tìm ra nguyên nhân, chứ không hỏi "nguyên nhân là gì". Đây là ràng buộc phân biệt quan trọng nhất: các phương án B và D đều nêu một nguyên nhân có thể có, còn phương án A nêu một phương pháp để tìm ra nguyên nhân nào trong số đó là thật.

Với một lỗi 403 trên S3, có rất nhiều lớp quyền chồng lên nhau cùng có thể gây ra: bucket policy, object ACL, Block Public Access, quyền của IAM principal, SCP ở cấp AWS Organizations, quyền sở hữu object. Đề không cho thêm dữ kiện nào để loại trừ, nên đoán mò một lớp cụ thể là sai phương pháp.

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

Phương án A — chạy automation document AWSSupport-TroubleshootS3PublicRead trên AWS Systems Manager.

Đây là document chẩn đoán do AWS Support cung cấp sẵn, chạy qua Systems Manager Automation, sinh ra đúng để phân tích lỗi 403 trên object có thể đọc công khai. Nó rà soát hàng loạt thiết lập quyền cùng ảnh hưởng tới bucket và object — bucket policy, object ACL, cùng các thiết lập liên quan khác — rồi trả về báo cáo chỉ ra chỗ đang chặn.

Nó khớp cả hai ràng buộc trong đề:

• Đối tượng là public object — đúng phạm vi document này hỗ trợ. Lưu ý ngược lại: document không đánh giá quyền cho private object, nên nếu đề mô tả bucket riêng tư thì phương án này sẽ hết đúng.
• Nó là quy trình troubleshooting, trả lời đúng câu "how will you troubleshoot", thay vì đoán trước kết luận.

Nói cách khác, A không mâu thuẫn với B và D — nó bao trùm chúng: chạy document xong thì mới biết thủ phạm là bucket policy, là ACL, hay là thứ khác.

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

B — "Explicit deny trong bucket policy gây lỗi forbidden, hãy kiểm tra bucket policy".

Đây là phương án gần đúng nhất và về mặt kỹ thuật thì không sai: một explicit deny trong bucket policy thắng mọi allow và đúng là gây 403. Chỗ nó hỏng: đề không đưa dữ kiện nào cho thấy bucket policy là nguyên nhân, mà đây chỉ là một trong nhiều khả năng. Chọn B là nhảy thẳng tới một giả thuyết và bỏ qua các lớp quyền còn lại; nếu đoán trượt thì developer vẫn 403 mà đã mất một vòng kiểm tra. Đề hỏi cách chẩn đoán, B đưa ra một phỏng đoán.

D — "SCP của AWS Organizations chặn truy cập, phải sửa service control policy".

Cũng cùng lỗi logic như B, và còn yếu hơn: SCP chỉ tồn tại khi account nằm trong một Organization, mà đề không hề nhắc tới Organizations, OU hay account cấu trúc nhiều tài khoản. Ngoài ra D không dừng ở "kiểm tra" mà nhảy luôn sang hành động sửa ("service policy needs to be changed") — sửa SCP khi chưa xác nhận nó là nguyên nhân là nới quyền ở cấp tổ chức một cách vô căn cứ, ảnh hưởng tới toàn bộ account bên dưới.

C — "Resource owner là account tạo bucket đã có quyền; đây là lỗi lúc tạo, hãy xoá bucket và tạo lại".

Sai cả tiền đề lẫn hành động. Về tiền đề: đề không nói người đang truy cập là resource owner hay là principal ở account khác, nên lập luận "chủ sở hữu vốn có quyền" không áp dụng được vào tình huống này. Về hành động: xoá và tạo lại bucket là thao tác phá huỷ — mất toàn bộ ảnh của web application, và tên bucket vừa giải phóng có thể không lấy lại được. 403 là lỗi quyền, không phải lỗi hỏng tài nguyên; xoá đi tạo lại không chữa vấn đề quyền mà chỉ tạo thêm sự cố.

📌 Điểm cần nhớ

• Khi đề hỏi "how will you troubleshoot" chứ không phải "what is the cause", phương án đúng thường là công cụ/quy trình chẩn đoán, không phải một nguyên nhân cụ thể được nêu ra khi đề chưa đủ dữ kiện để loại trừ.
• AWSSupport-TroubleshootS3PublicRead là automation document trên AWS Systems Manager, dùng cho lỗi 403 trên object public; nó rà bucket policy và object ACL cùng các thiết lập quyền liên quan. Nó không dùng để chẩn đoán object riêng tư — chi tiết "public read access enabled" trong đề chính là điều kiện kích hoạt phương án này.
• 403 trên S3 có nhiều lớp quyền chồng nhau cùng có thể gây ra (bucket policy, object ACL, Block Public Access, IAM, SCP). Trong bài thi, một phương án nêu đúng một lớp mà đề không xác nhận thì thường là mồi nhử, kể cả khi nội dung kỹ thuật của nó hoàn toàn chính xác.
• Loại ngay các phương án đề xuất hành động phá huỷ hoặc nới quyền diện rộng (xoá và tạo lại tài nguyên, sửa SCP cấp Organizations) khi nguyên nhân còn chưa được xác nhận.

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

Một công ty bán lẻ có nhiều chi nhánh, đội phát triển đã dựng Application Load Balancer (ALB) với các target trải trên nhiều Availability Zone. Đề hỏi: tính năng nào của Load Balancer dùng để thu thập thông tin cần thiết?

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

1. "analyze the incoming requests" — đối tượng quan tâm là từng request đi vào, tức dữ liệu ở mức chi tiết theo request, không phải số liệu tổng hợp.
2. "latencies and the client's IP address patterns" — cần đồng thời độ trễ và địa chỉ IP của client. Muốn nhìn ra "pattern" theo IP thì phải có từng dòng bản ghi kèm IP nguồn, rồi mới gom nhóm được.

Thêm một ràng buộc phụ: đề nói rõ "feature of the Load Balancer", nghĩa là phương án phải là tính năng thuộc về chính ELB/ALB.

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

B — ALB access logs.

Elastic Load Balancing cung cấp access logs ghi lại thông tin chi tiết về các request gửi tới load balancer. Mỗi bản ghi chứa những trường như: thời điểm nhận request, địa chỉ IP của client, các mốc latency, đường dẫn request, và mã phản hồi từ server. Đây đúng là hai thứ đề bài cần, nằm trong cùng một nguồn dữ liệu, ở mức từng request — nên phân tích được cả phân bố độ trễ lẫn pattern truy cập theo IP.

Một điểm đáng nhớ về vận hành: access logging là tính năng tuỳ chọn và mặc định tắt của Elastic Load Balancing. Muốn có dữ liệu thì phải bật, và log được ghi ra S3. Câu hỏi kiểu này trên đề thi thường ngầm kiểm tra xem thí sinh có biết chi tiết đó không.

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

A — CloudTrail logs. ELB có tích hợp với AWS CloudTrail, nhưng CloudTrail ghi lại API call — tức hành động của user, role hay dịch vụ AWS tác động lên Elastic Load Balancing (ai tạo load balancer, ai đổi listener, gọi lúc nào, từ IP nào). Đây là log của mặt phẳng điều khiển, không phải log lưu lượng người dùng đi qua load balancer. IP xuất hiện trong CloudTrail là IP của người gọi API, không phải IP của khách hàng truy cập ứng dụng, và CloudTrail hoàn toàn không có dữ liệu latency của request HTTP.

C — ALB request tracing. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì nó đúng là một tính năng của ALB và đúng là làm việc ở mức từng request HTTP. Cơ chế của nó: load balancer chèn thêm một header chứa trace identifier vào mỗi request nhận được, để bạn lần theo một request cụ thể qua các thành phần phía sau. Chỗ nó hỏng so với yêu cầu đề: request tracing chỉ gắn định danh, bản thân nó không sinh ra tập dữ liệu về độ trễ để phân tích. Nó phục vụ việc truy vết một request, không phục vụ việc phân tích latency trên diện rộng.

D — CloudWatch metrics. Elastic Load Balancing có publish data point sang Amazon CloudWatch cho load balancer và cho target, và bạn lấy được thống kê dạng chuỗi thời gian. Đây là lựa chọn đúng khi bạn muốn theo dõi một metric để xác nhận hệ thống chạy đúng như mong đợi. Nhưng metric là dữ liệu đã tổng hợp theo thời gian, mất hết chiều thông tin của từng request riêng lẻ. Cụ thể ở câu này: metric không mang địa chỉ IP của client, nên yêu cầu "phân tích pattern IP của client" là không thể đáp ứng — chỉ mất một nửa yêu cầu là phương án đã sai.

📌 Điểm cần nhớ

• Metrics kể chuyện tổng thể, logs kể chuyện từng request. Hễ đề hỏi tới thuộc tính của từng request — client IP, URL, user agent, mã trạng thái cụ thể — thì hướng đi là access logs, không phải CloudWatch metrics.
• Phân biệt "log về API" và "log về traffic". CloudTrail = ai đã gọi API nào lên dịch vụ; access logs = ai đã truy cập ứng dụng qua load balancer. Hai loại này không thay thế được cho nhau.
• Request tracing của ALB là công cụ truy vết, không phải công cụ đo lường. Nó gắn trace identifier vào header để lần theo một request, chứ không sinh dữ liệu latency để phân tích.
• ALB access logs mặc định tắt. Nếu tình huống trong đề than phiền "không có dữ liệu để điều tra sự cố đã xảy ra", hãy nhớ rằng log chỉ có từ thời điểm bật trở đi.

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

Đề mô tả một công ty streaming nhạc muốn: người dùng ở Úc được phục vụ bởi server đặt tại Úc, và người dùng ở các nơi khác trên thế giới không được truy cập tới những server đó qua truy vấn DNS.

Cụm từ quyết định là "Other users around the globe should not be able to access the servers through DNS queries" — đây là yêu cầu giới hạn theo vị trí địa lý của người truy vấn, tức là chặn/không trả lời dựa trên nơi truy vấn DNS xuất phát. Cụm phụ trợ "their Australian users" cho biết tiêu chí phân luồng là vị trí địa lý, chứ không phải sức khoẻ của resource, độ trễ đo được, hay tỷ lệ phân chia.

Chi tiết quan trọng: yêu cầu ở đây không phải "cho người dùng Úc trải nghiệm nhanh hơn" mà là kiểm soát ai được nhận câu trả lời DNS — nghĩa là một dạng hạn chế phân phối nội dung theo khu vực. Chỉ đúng một routing policy của Route 53 làm việc theo tiêu chí "truy vấn đến từ đâu".

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

C. Geolocation — Geolocation routing cho phép chọn resource phục vụ traffic dựa trên vị trí địa lý của người dùng, cụ thể là nơi truy vấn DNS xuất phát. Bạn tạo record geolocation gắn với Australia trỏ về server ở Úc, và Route 53 chỉ trả về record đó cho các truy vấn đến từ Úc.

Phần thứ hai của yêu cầu — người dùng nơi khác không truy cập được — được thoả mãn nhờ một đặc điểm của chính policy này: bạn có thể tạo một default record để xử lý những truy vấn từ IP không ánh xạ được vào vị trí nào, và từ những vị trí bạn chưa tạo record. Nếu không tạo default record, Route 53 trả về "no answer" cho các truy vấn từ những vị trí đó. Đúng theo tài liệu AWS, đây chính là cách dùng geolocation routing để hạn chế phân phối nội dung chỉ cho những khu vực mà bạn có quyền phân phối — mô tả khớp gần như từng chữ với tình huống trong đề.

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

A. Failover — Failover routing định tuyến traffic tới một resource khi resource đó healthy, và chuyển sang resource khác khi cái đầu unhealthy. Tiêu chí ở đây là tình trạng sức khoẻ (health check), hoàn toàn không liên quan tới vị trí người truy vấn. Dùng failover thì người dùng ở bất kỳ đâu cũng nhận được cùng một câu trả lời — không chặn được ai cả.

B. Latency — Đây là phương án gần đúng nhất và dễ mắc bẫy nhất. Latency routing phục vụ request từ AWS Region cho độ trễ thấp nhất với người dùng, nên trên thực tế phần lớn người dùng Úc sẽ được đưa về Region gần Úc — vế đầu của đề có vẻ được đáp ứng. Nhưng nó hỏng ở vế thứ hai: latency routing luôn trả về một resource nào đó cho mọi truy vấn, chỉ là chọn cái nhanh nhất. Nó không có khái niệm "không trả lời". Người dùng ngoài Úc vẫn nhận được bản ghi DNS, và nếu server Úc tình cờ là endpoint có độ trễ thấp nhất với họ thì họ được trỏ thẳng vào đó. Latency là công cụ tối ưu hiệu năng, không phải công cụ kiểm soát truy cập theo khu vực.

D. Weighted — Weighted routing chia traffic tới nhiều resource theo tỷ lệ bạn chỉ định. Tiêu chí là con số trọng số, không phải vị trí. Đặt trọng số 100% cho server Úc thì mọi người trên thế giới đều bị đưa về đó; đặt tỷ lệ khác thì người Úc cũng có thể bị đẩy sang server khác. Không cách nào diễn đạt được điều kiện "chỉ người ở Úc".

📌 Điểm cần nhớ

• Bắt gặp từ khoá về quốc gia / khu vực / quyền phân phối nội dung theo lãnh thổ trong câu hỏi Route 53 → nghĩ tới Geolocation routing, vì nó là policy duy nhất trong nhóm này quyết định dựa trên nơi truy vấn DNS xuất phát.
• Phân biệt Geolocation với Latency: Geolocation trả lời câu "người dùng ở đâu", Latency trả lời câu "đường nào nhanh nhất". Đề nhấn mạnh tuân thủ/giới hạn khu vực → Geolocation; đề nhấn mạnh hiệu năng, giảm độ trễ → Latency.
• Default record là chi tiết đáng nhớ của Geolocation: không tạo default record thì truy vấn từ vị trí chưa được khai sẽ nhận "no answer". Chính hành vi này biến routing policy thành cơ chế hạn chế truy cập ở tầng DNS.
• Mỗi routing policy gắn với đúng một tiêu chí quyết định: Failover → health check, Latency → độ trễ, Weighted → tỷ lệ do bạn đặt, Geolocation → vị trí người truy vấn. Đọc đề, tìm xem đề đang lấy tiêu chí nào làm căn cứ, rồi khớp thẳng — cách này loại nhanh được các phương án gây nhiễu.