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

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

Đề mô tả một công ty lưu khối lượng lớn log file không quan trọng ("non-critical") trong một Amazon S3 bucket, và một EC2 instance xử lý các file đó hằng ngày ("processes files from the bucket on a daily basis"). Câu hỏi: lựa chọn lưu trữ nào tiết kiệm chi phí nhất (MOST cost-effective).

Cụm từ quyết định đáp án là "on a daily basis" — dữ liệu được truy cập thường xuyên, mỗi ngày. Hai chữ "non-critical" và "large volume" trông rất giống mồi nhử để người học nhảy sang lớp lưu trữ rẻ hơn, nhưng chúng nói về tầm quan trọng và kích thước chứ không nói về tần suất truy cập. Trong khi đó, toàn bộ mô hình giá của các storage class trong S3 xoay quanh đúng tần suất truy cập: lớp có giá lưu trữ mỗi GB thấp hơn thì bù lại bằng phí truy xuất (retrieval fee) tính trên mỗi lần đọc. Vì vậy khi đề nói "hằng ngày", ràng buộc phân biệt đã hiện ra: đây là dữ liệu frequently accessed.

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

Đáp án đúng theo tệp là C — Amazon S3 Standard.

S3 Standard là lớp lưu trữ được thiết kế cho dữ liệu truy cập thường xuyên: nó có giá lưu trữ mỗi GB cao nhất trong nhóm S3 nhưng không tính phí truy xuất theo GB và không áp thời gian lưu trữ tối thiểu. Với kịch bản đọc lại toàn bộ khối log mỗi ngày, tổng chi phí thực tế = chi phí lưu trữ + chi phí truy xuất, và phần truy xuất lặp đi lặp lại mỗi ngày sẽ áp đảo khoản tiết kiệm nhỏ trên giá lưu trữ nếu chọn lớp "lạnh" hơn. Nên "rẻ nhất" ở đây không phải lớp có giá lưu trữ thấp nhất, mà là lớp không phạt khi đọc — chính là S3 Standard.

Ngoài ra dữ liệu vẫn phải nằm trong S3 để EC2 lấy về xử lý theo lịch, nên câu trả lời phải là một storage class của S3 chứ không phải một loại storage khác.

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

A — Amazon Instance Store. Đây là ephemeral block storage gắn trực tiếp vào EC2 instance, dữ liệu mất khi instance dừng hoặc bị terminate. Nó cũng không phải object storage, không phải nơi để giữ một kho log lớn dùng chung. Ngoài ra đề nói dữ liệu đang nằm trong S3 bucket và EC2 chỉ xử lý nó; chuyển sang instance store là đổi cả kiến trúc chứ không phải chọn lớp lưu trữ rẻ hơn. Không phù hợp với use case.

B — Amazon S3 Standard-Infrequent Access. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. S3 Standard-IA rẻ hơn Standard ở giá lưu trữ mỗi GB, nên nếu chỉ đọc mỗi chữ "large volume of non-critical log files" thì nó trông rất hợp lý. Chỗ nó hỏng: Standard-IA tính thêm phí truy xuất (retrieval cost) theo lượng dữ liệu đọc ra, và tên lớp đã nói rõ nó dành cho dữ liệu infrequently accessed. Dữ liệu ở đây được đọc mỗi ngày — đúng định nghĩa truy cập thường xuyên — nên phí truy xuất phát sinh liên tục sẽ đẩy tổng chi phí lên cao hơn Standard. Lớp này chỉ có lợi khi dữ liệu nằm yên phần lớn thời gian và thỉnh thoảng mới cần đọc.

D — Amazon Glacier. Đây là lớp dành cho archive — dữ liệu lưu lâu dài và gần như không đụng tới. Giá lưu trữ thấp nhất, nhưng đổi lại đối tượng không đọc trực tiếp được ngay như S3 Standard mà phải qua quá trình restore, kèm phí truy xuất. Với dữ liệu được xử lý hằng ngày thì nó vừa không đáp ứng được nhu cầu vận hành, vừa đắt hơn vì phải restore liên tục. Nói cách khác: dữ liệu đang được dùng hằng ngày thì không phải dữ liệu để archive.

📌 Điểm cần nhớ

• Với câu hỏi chọn S3 storage class, tần suất truy cập mới là ràng buộc quyết định, không phải kích thước dữ liệu hay mức độ "quan trọng". Hãy tìm các cụm như daily, frequently, rarely, archive, long-term retention trong đề.
• "MOST cost-effective" ≠ "giá lưu trữ mỗi GB thấp nhất". Phải cộng cả retrieval cost: các lớp lạnh hơn (Standard-IA, Glacier) đánh đổi giá lưu trữ rẻ lấy phí truy xuất và ràng buộc thời gian lưu tối thiểu.
• Standard-IA dành cho dữ liệu ít khi đọc nhưng cần lấy ngay khi cần; Glacier dành cho archive, phải restore trước khi đọc. Dữ liệu xử lý hằng ngày không thuộc cả hai nhóm.
• Instance store là block storage tạm thời gắn với vòng đời của EC2 instance — không bao giờ là câu trả lời cho việc lưu trữ bền vững một kho dữ liệu, và cũng không thay thế được object storage.

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

Đề mô tả một SysOps administrator cần soi lại lỗi trong quá khứ từ log CloudWatch của 10 Lambda function, log đã được để ở Amazon S3 dưới định dạng JSON. Điểm khó: lỗi không phải lúc nào cũng nằm ở cùng một field, nhưng tất cả đều bắt đầu bằng cùng một chuỗi tiền tố (string prefix).

Cụm từ quyết định đáp án là "most operationally efficient" kết hợp với "logs ... are stored in Amazon S3". Hai chi tiết này ghép lại thành một yêu cầu rất hẹp: cần một cách truy vấn dữ liệu đang nằm sẵn trong S3 mà không phải dựng thêm hạ tầng, không phải chép dữ liệu đi đâu. Chi tiết "JSON" và "prefix giống nhau" chỉ là để nói rằng bài toán này giải được bằng một câu truy vấn có lọc chuỗi, chứ không cần phân tích phức tạp.

Lưu ý là đề nói log đã ở S3 rồi — nên nơi phân tích phải là nơi đọc thẳng được S3.

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

B — Use Amazon Athena to query the logs in S3 directly using standard SQL.

Athena là dịch vụ truy vấn serverless, chạy SQL trực tiếp trên dữ liệu nằm trong S3. Người dùng chỉ cần định nghĩa schema/table trỏ vào prefix S3 chứa log rồi gõ SQL — không phải khởi tạo cluster, không phải nạp dữ liệu vào một kho khác, không phải quản lý máy chủ nào. Đó chính là nghĩa của "operationally efficient" trong đề: khối lượng thao tác vận hành gần như bằng không.

Athena cũng xử lý tốt hai đặc điểm mà đề nêu:

• Log JSON: Athena hỗ trợ đọc dữ liệu JSON, nên các field trong log truy cập được như cột.
• Lỗi rải rác ở nhiều field nhưng cùng prefix: SQL có sẵn các phép so khớp chuỗi (dạng LIKE 'prefix%') và có thể áp lên nhiều cột, hoặc lên chính chuỗi JSON thô. Một câu truy vấn là quét được toàn bộ log của cả 10 function cùng lúc.

Ngoài ra, do log của cả 10 Lambda function nằm chung một nơi trên S3, Athena gom được tất cả vào một bảng và cho kết quả tổng hợp — thay vì phải xem từng function một.

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

A — Download the logs from S3 and use local text editors for log analysis.

Về mặt kỹ thuật thì làm được, và đây là phương án "gần đúng" nhất vì nó thật sự tìm ra lỗi. Nhưng nó hỏng đúng ở tiêu chí đề đặt ra: operational efficiency. Log của 10 Lambda function tích luỹ theo thời gian có thể rất lớn; tải hết về máy tốn băng thông và dung lượng, mở bằng text editor thì thao tác thủ công, không lặp lại được, không tự động hoá được, và mỗi lần muốn soi lại là phải tải lại từ đầu. Đề hỏi cách hiệu quả nhất về vận hành, chứ không hỏi cách nào khả thi.

C — Use AWS CloudTrail to analyze the logs for the specific string prefix.

Sai vì nhầm loại log. CloudTrail ghi lại lời gọi API trong tài khoản AWS — ai gọi, gọi dịch vụ nào, lúc nào, từ đâu. Nó là công cụ audit hoạt động của AWS, không phải công cụ phân tích log ứng dụng. Log lỗi do code trong Lambda function sinh ra không nằm trong phạm vi CloudTrail, và CloudTrail cũng không đóng vai trò công cụ truy vấn tự do trên các file JSON mà người dùng đã tự để trong S3.

D — Set up Amazon GuardDuty to analyze and find the errors in the logs.

Sai vì nhầm mục đích dịch vụ. GuardDuty là dịch vụ phát hiện mối đe doạ (threat detection): nó tìm dấu hiệu hành vi bất thường, dấu hiệu bị xâm nhập, hoạt động đáng ngờ. Nó không phải công cụ để người dùng tự đi tìm một chuỗi ký tự cụ thể trong log ứng dụng của mình. Dù có chạy GuardDuty, nó cũng không trả lời được câu hỏi "các dòng log bắt đầu bằng prefix X là những dòng nào".

📌 Điểm cần nhớ

• "Dữ liệu đã nằm trong S3" + "phân tích/truy vấn" + "operationally efficient" gần như luôn dẫn tới Athena: SQL chạy thẳng trên S3, serverless, không phải dựng hay dời dữ liệu.
• Phân biệt rạch ròi ba dịch vụ hay bị đưa vào làm mồi nhử: CloudTrail = log lời gọi API của AWS, GuardDuty = phát hiện mối đe doạ bảo mật, còn log ứng dụng do code sinh ra là chuyện khác hẳn. Đề nói "application/Lambda logs" thì loại ngay hai cái đầu.
• Phương án thao tác thủ công (tải về, mở bằng editor, xem bằng mắt) hầu như luôn sai khi đề có chữ "operationally efficient", "at scale", hay "least operational overhead" — kể cả khi nó về lý thuyết vẫn ra kết quả.
• Chi tiết định dạng dữ liệu trong đề (ở đây là JSON) thường là gợi ý rằng công cụ được chọn phải đọc được định dạng đó — đọc kỹ nó để loại các phương án chỉ làm việc với dữ liệu có cấu trúc cố định.

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

Đề mô tả một ứng dụng định kỳ đẩy log lên một bucket Amazon S3, và hỏi nên tạo lifecycle rule nào để tiết kiệm chi phí. Có hai cụm từ trong đề quyết định đáp án, và phải thoả cả hai cùng lúc:

• "must be immediately available" — log phải lấy ra được ngay lập tức, không chấp nhận độ trễ khôi phục. Cụm này loại thẳng nhóm storage class kiểu archive.
• "not frequently accessed" — mẫu truy cập đã được biết trước và là hiếm khi đọc. Cụm này vừa chỉ ra storage class phù hợp là loại infrequent access, vừa loại bỏ những giải pháp có nhiệm vụ đi dò tìm mẫu truy cập.

Cụm thứ ba, âm thầm hơn nhưng chính là thứ phân biệt hai phương án A và C: "lifecycle rule". Câu hỏi không hỏi "nên ghi thẳng vào storage class nào", mà hỏi về quy tắc chuyển tầng. Lifecycle transition từ S3 Standard sang S3 Standard-IA có ràng buộc thời gian lưu tối thiểu ở S3 Standard trước khi được phép chuyển — nên "immediately" và "after 30 days" không phải là hai cách diễn đạt cùng một ý, mà là một cái hợp lệ, một cái không.

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

Đáp án đúng theo tệp là A — Transition the objects to S3 Standard-IA after 30 days.

S3 Standard-IA được thiết kế đúng cho dữ liệu hiếm khi đọc nhưng khi cần thì phải có ngay: nó vẫn cho truy cập với độ trễ tương đương S3 Standard (không có bước restore), trong khi giá lưu trữ mỗi GB rẻ hơn. Điều này khớp chính xác với hai ràng buộc của đề: immediately available được giữ nguyên, còn not frequently accessed thì tận dụng được mức giá lưu trữ thấp hơn. Đánh đổi của Standard-IA là phí truy xuất tính theo lượng dữ liệu lấy ra và có mức dung lượng/thời gian lưu tối thiểu tính tiền — nhưng với log ghi rồi để đó, ít khi đọc, đánh đổi này có lợi.

Phần "after 30 days" là điều kiện bắt buộc của lifecycle: theo tài liệu AWS mà giải thích gốc dẫn nguồn, object phải nằm ở S3 Standard đủ 30 ngày rồi mới được lifecycle chuyển sang S3 Standard-IA (hoặc S3 One Zone-IA). Vậy nên A vừa đúng về storage class, vừa hợp lệ về mặt cấu hình rule.

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

B — Transition the objects to S3 Glacier after immediately. Sai vì vi phạm trực tiếp ràng buộc mạnh nhất của đề. Các storage class thuộc họ Glacier là archive: để đọc lại dữ liệu nói chung phải qua bước restore và chờ, chứ không đọc thẳng như S3 Standard. Đề đã nói rõ log must be immediately available, nên dù Glacier rẻ hơn Standard-IA thì nó vẫn không phải phương án hợp lệ — rẻ hơn mà không đáp ứng yêu cầu chức năng thì không tính là "cost-efficiency".

C — Transition the objects to S3 Standard-IA immediately. Đây là phương án gần đúng nhất và là cái bẫy chính của câu. Nó chọn đúng storage class, đúng lý do, chỉ hỏng ở phần thời điểm: lifecycle rule không cho chuyển object từ S3 Standard sang S3 Standard-IA ngay lập tức, phải qua khoảng lưu tối thiểu 30 ngày ở S3 Standard. Nói cách khác, C mô tả một rule không cấu hình được như vậy. (Cần phân biệt: ghi thẳng object vào Standard-IA ngay từ lúc PUT là chuyện làm được — nhưng đó là chọn storage class lúc upload, không phải lifecycle transition, mà đề đang hỏi lifecycle rule.)

D — Transition the objects to S3 Intelligent-Tiering after 30 days. Cũng gần đúng: Intelligent-Tiering giữ được yêu cầu truy cập tức thì ở các access tier thường dùng, nên không vi phạm ràng buộc immediately available. Chỗ hỏng nằm ở mục đích của nó. Intelligent-Tiering sinh ra cho dữ liệu có mẫu truy cập không biết trước hoặc thay đổi: nó theo dõi từng object rồi tự chuyển tầng, và tính thêm phí monitoring/automation cho mỗi object. Ở đây đề đã nói thẳng mẫu truy cập là not frequently accessed — đã biết rồi thì trả thêm tiền để hệ thống đi tự khám phá lại điều mình đã biết là thừa. Với khối lượng nhiều object nhỏ như log, phần phí theo-object này càng bất lợi. Chuyển thẳng sang Standard-IA là lựa chọn rẻ hơn và đúng ý đồ hơn.

📌 Điểm cần nhớ

• Đọc đề S3 theo hai trục tách rời: yêu cầu truy cập (ngay lập tức hay chấp nhận restore) lọc trước, rồi mới tới tần suất truy cập để chọn tầng rẻ. "Immediately available" gần như luôn loại nhóm archive kiểu Glacier.
• Standard-IA khi mẫu truy cập đã biết là ít; Intelligent-Tiering khi mẫu truy cập không biết hoặc thay đổi. Đề nào nói rõ "infrequently accessed" thì Intelligent-Tiering là phương án thừa phí, không phải phương án an toàn.
• Lifecycle transition sang Standard-IA / One Zone-IA đòi object nằm ở S3 Standard tối thiểu 30 ngày. Khi hai phương án chỉ khác nhau ở "immediately" và "after 30 days", đó chính là chỗ ra đề — chọn cái tôn trọng ràng buộc thời gian.
• Phân biệt chọn storage class lúc upload với chuyển tầng bằng lifecycle rule: cùng đích đến nhưng khác luật chơi, và đề hỏi cái nào thì phải trả lời theo cái đó.

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

Đề mô tả một database chạy trên Amazon Aurora đang gặp vấn đề hiệu năng, và người quản trị cần theo dõi memory utilization cùng các OS level metrics.

Cụm từ quyết định nằm ở chính chỗ đó: "OS level metrics" — số liệu ở tầng hệ điều hành, chứ không phải số liệu ở tầng dịch vụ. Đây là ranh giới quan trọng của mọi dịch vụ managed như RDS/Aurora: AWS quản lý hệ điều hành bên dưới, còn khách hàng chỉ thấy database. Vì vậy câu hỏi thực chất là: làm sao lấy được số liệu nằm bên trong lớp mà mình không có quyền đăng nhập?

Cụm thứ hai đáng chú ý là "memory utilization". RDS có publish một số metric liên quan tới bộ nhớ ra CloudWatch (ví dụ FreeableMemory), nhưng đó là góc nhìn từ ngoài vào — không phải bức tranh mức OS với tiến trình, cache, swap, thread. Đề hỏi mức chi tiết OS nên loại luôn nhóm phương án dựa vào metric mặc định.

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

Đáp án đúng theo tệp là B — Enable enhanced monitoring and view the metrics in the RDS console.

Enhanced Monitoring là tính năng dành riêng cho tình huống này: AWS cài sẵn một agent bên trong hệ điều hành của DB instance, thu thập metric ở tầng OS rồi đưa ra ngoài cho bạn xem. Nó cho các chỉ số mà tầng dịch vụ không có: mức sử dụng bộ nhớ chi tiết, hoạt động của tiến trình, thông tin về CPU và I/O nhìn từ phía OS.

Điểm hay của phương án này là nó giải được nghịch lý "tôi không có quyền vào OS": bạn không cần quyền đó, AWS đứng ra làm hộ phần đo đạc. Bật/tắt được qua AWS Management Console, AWS CLI hoặc RDS API. Số liệu xem trực tiếp trong RDS console, đồng thời được đẩy ra Amazon CloudWatch Logs dưới dạng JSON nên có thể đưa sang hệ thống giám sát khác nếu muốn.

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

A — Enable detailed monitoring for the RDS instance to increase metric frequency. Đây là phương án gần đúng nhất về mặt cảm giác, vì chữ "detailed" nghe như "chi tiết hơn". Nhưng detailed monitoring chỉ tăng tần suất thu thập các metric vốn đã có, chứ không sinh ra metric mới. Metric OS không nằm trong bộ metric sẵn có nên lấy nhanh hơn cũng vẫn không có nó. Ngoài ra detailed monitoring là khái niệm của EC2, không phải cách bật giám sát OS cho RDS — đúng tên gọi nhưng sai dịch vụ.

C — Install the unified CloudWatch agent on the RDS instance. Về nguyên tắc thì đúng hướng: unified CloudWatch agent chính là công cụ dùng để lấy memory và OS metric... trên EC2. Nhưng cài agent đòi hỏi quyền truy cập vào hệ điều hành, mà với RDS/Aurora bạn không có quyền đó — không SSH, không cài phần mềm. Phương án này bất khả thi về mặt vận hành. Đáng chú ý: Enhanced Monitoring thực chất làm đúng việc mà phương án này mô tả, chỉ khác là AWS cài agent thay bạn.

D — Use Amazon CloudWatch to view the standard metrics for RDS. Sai vì các metric tiêu chuẩn của RDS trong CloudWatch được thu thập từ hypervisor / tầng dịch vụ, không phải từ bên trong OS. Bộ metric này không bao gồm memory utilization mức OS và các OS level metric mà đề yêu cầu. Người học hay chọn D vì thấy FreeableMemory là metric có sẵn và tưởng đã đủ, nhưng đó là một chỉ số khác với bức tranh bộ nhớ ở tầng hệ điều hành.

📌 Điểm cần nhớ

• Thấy "OS level metrics" hoặc "memory utilization" trên RDS/Aurora → nghĩ ngay tới Enhanced Monitoring. Đây gần như là phản xạ có thể tin cậy trong đề thi.
• Phân biệt ba khái niệm dễ lẫn: standard CloudWatch metrics (tầng dịch vụ, có sẵn), detailed monitoring (khái niệm của EC2, chỉ tăng tần suất), Enhanced Monitoring (agent chạy trong OS của DB instance).
• Với dịch vụ managed, mọi phương án yêu cầu tự cài agent hoặc tự đăng nhập vào máy đều đáng nghi — bạn không có quyền truy cập hệ điều hành bên dưới.
• Enhanced Monitoring không chỉ hiển thị trong RDS console: dữ liệu còn ra CloudWatch Logs dạng JSON, nên tích hợp được với hệ thống giám sát bên ngoài.

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

Đề mô tả một tình huống rất quen: ứng dụng đã có CloudFront distribution đứng trước, tên miền www.mywebapp.com do Route 53 quản lý, và yêu cầu là để người dùng truy cập ứng dụng qua CloudFront bằng chính tên miền tuỳ chỉnh đó.

Về mặt kỹ thuật thuần tuý, có tới hai cách trỏ tên miền vào một CloudFront distribution: CNAME record và Alias record. Cả hai đều chạy được. Vậy nên cụm từ quyết định nằm ở câu hỏi cuối:

What is the MOST cost-effective way to achieve this?

Chữ MOST cost-effective mới là ràng buộc phân biệt. Nó đẩy câu hỏi từ "record nào trỏ được" sang "record nào trỏ được mà không phát sinh chi phí truy vấn DNS". Khi một câu hỏi Route 53 hỏi về chi phí trong khi đích đến là một AWS resource, gần như chắc chắn nó đang kiểm tra kiến thức về Alias record.

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

B — Create an Alias record in Amazon Route 53 that points to the CloudFront distribution URL.

Alias record là loại record đặc thù của Route 53 (không phải chuẩn DNS phổ thông), cho phép trỏ một tên miền thẳng tới một AWS resource — trong đó có CloudFront distribution. Điểm mấu chốt theo đúng lời giải gốc: Route 53 không tính phí cho các truy vấn alias trỏ tới AWS resource, và CloudFront distribution nằm trong nhóm được miễn phí đó.

Vậy nên Alias record vừa đáp ứng yêu cầu chức năng (người dùng gõ www.mywebapp.com và được phục vụ bởi CloudFront), vừa đáp ứng ràng buộc "MOST cost-effective" vì phần truy vấn DNS không sinh cước. Đây là lý do B thắng A dù cả hai đều hoạt động.

Một điểm phụ nhưng đáng nhớ: Alias record còn dùng được ở zone apex (ví dụ mywebapp.com không có www), nơi mà CNAME bị chuẩn DNS cấm. Câu này dùng www nên không chạm tới giới hạn đó, nhưng đây là lý do thứ hai khiến Alias là lựa chọn mặc định khi trỏ vào AWS resource.

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

A — CNAME record trỏ tới CloudFront distribution URL. Đây là phương án gần đúng nhất, và nếu đề bỏ đi hai chữ "cost-effective" thì nó là một câu trả lời chấp nhận được: CNAME hoàn toàn phân giải được www.mywebapp.com về tên miền của distribution. Chỗ nó hỏng là chi phí. Theo lời giải gốc, Route 53 tính phí cho truy vấn CNAME; và khi CNAME trỏ tới tên của một record khác nằm trong hosted zone của Route 53, mỗi truy vấn DNS bị tính thành hai truy vấn. Đề đã cố tình hỏi "MOST cost-effective" chính là để loại phương án này. Bài học: A không sai về kỹ thuật, nó chỉ thua ở đúng tiêu chí mà đề đặt ra.

C — SRV record trỏ tới A record của tên miền tuỳ chỉnh. SRV (service locator) là loại record dùng để công bố host và port của một dịch vụ cụ thể — kiểu như SIP, XMPP, hay các dịch vụ directory. Trình duyệt web không tra SRV để biết phải đi đâu khi người dùng gõ một URL HTTP/HTTPS. Đây đơn giản là sai loại record cho tình huống này; nó không phân giải được lưu lượng web tới CloudFront, nên vấn đề không phải chi phí mà là không chạy được.

D — A record trỏ tới public IP address của web application. Phương án này hỏng ở hai lớp. Thứ nhất, nó đi vòng qua CloudFront: trỏ thẳng tới IP của ứng dụng nghĩa là người dùng gọi trực tiếp origin, đúng thứ mà đề yêu cầu phải tránh ("accessed ... through CloudFront"). Thứ hai, đúng như lời giải gốc chỉ ra, bạn không lấy được public IP của CloudFront — AWS chỉ cấp cho bạn DNS name của distribution, còn các edge location đứng sau nhiều địa chỉ khác nhau và có thể thay đổi. Ghim một A record vào IP tĩnh cho một dịch vụ phân tán như vậy là không khả thi.

📌 Điểm cần nhớ

• Khi trỏ tên miền Route 53 vào một AWS resource (CloudFront, ELB, S3 website endpoint, API Gateway...), Alias record là lựa chọn mặc định: truy vấn alias tới AWS resource không bị tính phí, trong khi CNAME thì có.
• Trong đề thi, các chữ in hoa như MOST cost-effective, MOST secure, LEAST operational overhead là ràng buộc phân biệt — khi hai phương án cùng chạy được, hãy dùng chính ràng buộc đó để chọn, đừng chọn theo "cái nào quen hơn".
• CNAME không đặt được ở zone apex, còn Alias thì được. Đây là lý do thứ hai khiến Alias gần như luôn thắng CNAME trong ngữ cảnh AWS.
• CloudFront chỉ cho bạn DNS name của distribution, không cho public IP — nên mọi phương án dựa trên A record trỏ IP tĩnh vào CloudFront đều loại được ngay lập tức.
• Đọc kỹ ý "phải đi qua CloudFront": phương án nào trỏ thẳng vào origin là đã phá vỡ yêu cầu kiến trúc, bất kể loại record có hợp lệ hay không.

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

Đề mô tả một công ty dùng AWS Organizations với nhiều tài khoản, đã mua Reserved Instances (RIs), và muốn: "each member account only receives discounts associated with RIs they own and not for RIs owned by other accounts".

Cụm từ quyết định là "RIs they own" — mỗi member account chỉ được hưởng ưu đãi của chính RI nó sở hữu. Muốn một member account "sở hữu" RI thì RI phải được mua trong chính member account đó, không phải mua ở management account. Đây là vế thứ nhất, và nó loại ngay một nửa số phương án.

Vế thứ hai là "not for RIs owned by other accounts" — tức phải tắt RI discount sharing. Mấu chốt phân biệt hai phương án còn lại nằm ở chỗ tắt ở đâu: theo mặc định của consolidated billing trong AWS Organizations, toàn bộ tổ chức được tính hoá đơn như một tài khoản duy nhất, nên ưu đãi theo giờ của RI do bất kỳ account nào mua đều lan ra cả tổ chức. Việc bật/tắt chia sẻ ưu đãi này là thiết lập ở cấp tổ chức, nằm trên trang Preferences của Billing and Cost Management console — nơi chỉ management account (payer account) truy cập được.

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

Đáp án đúng theo tệp là B — "Purchase RIs in individual member accounts. Disable RI discount sharing in the management account."

Hai vế khớp đúng hai yêu cầu của đề:

• Mua RI trong từng member account: RI thuộc quyền sở hữu của chính account đó, và account sở hữu luôn được áp ưu đãi trước tiên cho các instance khớp điều kiện của mình. Đây là điều làm cho vế "chỉ hưởng ưu đãi của RI mình sở hữu" trở nên khả thi.
• Tắt RI discount sharing ở management account: thiết lập chia sẻ ưu đãi RI và Savings Plans được điều khiển từ trang Preferences trong Billing and Cost Management của management account. Khi tắt, ưu đãi RI không còn chảy qua lại giữa các account đã bị tắt chia sẻ — mỗi account giữ lại đúng phần ưu đãi từ RI của mình.

Kết hợp lại: RI nằm đúng chỗ (member account) và ưu đãi bị chặn không lan sang account khác (tắt từ management account). Đúng nguyên văn yêu cầu của đề.

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

A — Mua RI trong member account, tắt discount sharing ở member account. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi: vế mua RI đã chuẩn. Chỗ hỏng nằm ở nơi thực hiện việc tắt chia sẻ — cấu hình discount sharing là thiết lập cấp tổ chức, được quản lý từ management account trên trang Preferences, chứ không phải thứ mỗi member account tự bật/tắt cho riêng mình. Chọn A là hiểu sai ranh giới quyền quản lý billing trong AWS Organizations.

C — Mua RI ở management account, tắt discount sharing ở member account. Sai cả hai vế. Mua RI ở management account nghĩa là RI thuộc sở hữu của management account, trái thẳng với yêu cầu "RIs they own" của từng member account. Cộng thêm việc tắt chia sẻ, các member account sẽ không tiếp cận được ưu đãi từ những RI đó nữa — kết quả là RI đã mua bị lãng phí. Vế thứ hai lại sai chỗ cấu hình, giống lỗi của A.

D — Mua RI ở management account, tắt discount sharing ở management account. Vế cấu hình đúng chỗ, nhưng vế mua RI vẫn sai — và chính sự kết hợp này tạo ra tình huống tệ nhất về mặt chi phí. RI nằm ở management account, mà chia sẻ ưu đãi đã bị tắt, nên các member account đang chạy workload thật không nhận được ưu đãi nào. Doanh nghiệp trả tiền cam kết RI mà không ai dùng được ưu đãi đó.

📌 Điểm cần nhớ

• Mặc định của consolidated billing trong AWS Organizations là coi cả tổ chức như một tài khoản để tính tiền, nên ưu đãi RI (và Savings Plans) tự động lan ra mọi account — muốn giới hạn thì phải chủ động tắt, không phải mặc định.
• Account nào mua RI thì account đó sở hữu và được áp ưu đãi trước. Đề nào yêu cầu "mỗi account chỉ hưởng ưu đãi của RI mình sở hữu" thì vế mua RI luôn phải là member account.
• Chỗ cấu hình discount sharing là management account, trên trang Preferences của Billing and Cost Management — đây là mẫu bẫy quen thuộc: hai phương án giống hệt nhau, chỉ khác chữ "management" và "member".
• Cẩn thận với tổ hợp "mua ở management account + tắt chia sẻ": nó không chỉ sai theo đề mà còn khiến ưu đãi RI đã trả tiền không đến được workload nào.

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

Đề đặt ra một nhu cầu bảo mật rất cụ thể: công ty muốn bắt buộc mọi IAM user phải đổi mật khẩu định kỳ. Câu hỏi là nên làm gì để hiện thực hoá điều đó.

Cụm từ quyết định đáp án là "forcing all IAM users to rotate their passwords on a regular basis" — trong đó có hai ràng buộc chồng lên nhau:

• "forcing" — phải là cơ chế cưỡng chế ở tầng nền tảng, hệ thống tự chặn khi người dùng không tuân thủ, chứ không phải nhắc nhở hay khuyến khích.
• "passwords" — đối tượng là mật khẩu đăng nhập AWS Management Console, không phải access key và cũng không phải yếu tố xác thực bổ sung.

Chỉ cần đối chiếu hai ràng buộc này với bốn phương án là ba phương án sai tự rơi ra: một phương án đúng đối tượng nhưng không cưỡng chế, một phương án cưỡng chế nhưng sai đối tượng, một phương án nhắm vào loại credential khác hẳn.

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

B — Set up a password policy to enable password expiration for IAM users.

IAM cho phép đặt một password policy ở cấp AWS account, áp dụng cho toàn bộ IAM user trong account đó. Ngoài các quy định về độ phức tạp (độ dài tối thiểu, yêu cầu chữ hoa/chữ thường/số/ký tự đặc biệt), password policy còn có tuỳ chọn password expiration — đặt số ngày mà một mật khẩu còn hiệu lực. Hết hạn, IAM user buộc phải đặt mật khẩu mới thì mới đăng nhập được vào Console.

Đây chính xác là cơ chế cưỡng chế mà đề yêu cầu: nó do IAM thực thi, không phụ thuộc vào thiện chí của người dùng, và nó tác động đúng lên password chứ không phải loại credential nào khác. Password policy cũng thường đi kèm tuỳ chọn cấm dùng lại mật khẩu cũ, để việc "xoay" mật khẩu là xoay thật chứ không phải đặt lại đúng chuỗi cũ.

Lưu ý một chi tiết vận hành đi kèm: để người dùng tự đổi mật khẩu khi hết hạn, họ cần được cấp quyền đổi mật khẩu của chính mình — có thể mở cho toàn bộ IAM user trong account, hoặc chỉ cấp cho một nhóm được chọn qua IAM policy.

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

A — Configure multi-factor authentication for all IAM users. Đây là phương án gần đúng nhất về mặt "cải thiện bảo mật đăng nhập", và nếu đề chỉ hỏi chung chung "làm sao tăng an toàn cho việc đăng nhập" thì MFA sẽ là câu trả lời rất mạnh. Nhưng nó hỏng ở đúng chỗ đề nhấn mạnh: MFA thêm một yếu tố xác thực thứ hai (mã OTP, security key), nó không hề tác động tới vòng đời của mật khẩu. Bật MFA cho toàn bộ user rồi thì mật khẩu vẫn có thể giữ nguyên nhiều năm. Yêu cầu là rotate passwords, MFA không rotate gì cả.

C — Use Amazon SNS to send regular notifications that passwords must be changed. Phương án này đúng đối tượng (mật khẩu) và đúng nhịp (định kỳ), nên đọc lướt rất dễ chọn. Nó hỏng ở chữ "forcing": SNS chỉ gửi thông báo, tức là khuyên người dùng đổi mật khẩu. Không có gì ngăn một người nhận email rồi phớt lờ, và tài khoản đó vẫn đăng nhập bình thường với mật khẩu cũ. Một cơ chế dựa vào sự tự giác thì không phải là cơ chế cưỡng chế. Ngoài ra bản thân SNS cũng không biết mật khẩu của ai đã cũ tới đâu để mà nhắc đúng người đúng lúc.

D — Set up an access key policy to enable expiration for access keys. Sai ở cả hai vế. Thứ nhất, sai đối tượng: access key là credential dùng cho truy cập lập trình (CLI, SDK, API), hoàn toàn tách biệt với mật khẩu đăng nhập Console — có xoay access key thì mật khẩu vẫn nguyên. Thứ hai, không tồn tại một "access key policy" cho phép đặt hạn hết hiệu lực tự động giống như password expiration trong password policy. Việc xoay access key trong IAM là một quy trình vận hành (tạo key mới, chuyển ứng dụng sang key mới, vô hiệu hoá rồi xoá key cũ) chứ không phải một ô cấu hình bật lên là xong.

📌 Điểm cần nhớ

• Password policy là nơi duy nhất trong IAM cưỡng chế vòng đời mật khẩu — độ phức tạp, hạn sử dụng, cấm dùng lại mật khẩu cũ. Đề nào nhắc tới "password expiration", "password complexity", "prevent password reuse" cho IAM user thì hướng về đây.
• Phân biệt rạch ròi ba loại credential của IAM user: password (đăng nhập Console), access key (truy cập lập trình), MFA device (yếu tố xác thực bổ sung). Đề nhắc loại nào thì đáp án phải tác động đúng loại đó — đây là cách AWS hay dựng phương án nhiễu.
• "Force" / "enforce" / "ensure" luôn loại bỏ các phương án dựa trên thông báo và nhắc nhở. Gửi email, gửi SNS, viết tài liệu hướng dẫn đều là khuyến nghị, không phải cưỡng chế. Cơ chế cưỡng chế phải do nền tảng chặn.
• Đừng chọn MFA theo phản xạ chỉ vì đề nói "improve security". MFA rất mạnh nhưng chỉ giải quyết bài toán xác thực, không giải quyết bài toán xoay vòng credential — phải đọc kỹ động từ chính trong đề.

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

Đề bài dựng một VPC đã gán IPv6 CIDR block, và đặt ra hai yêu cầu đi ngược chiều nhau cho các EC2 instance bên trong:

• "should be able to connect to IPv6 domains on the internet" — phải đi ra được Internet bằng IPv6.
• "connectivity from the internet should be restricted" — Internet không được chủ động mở kết nối vào.

Hai cụm từ quyết định đáp án nằm ở đây. Cụm IPv6 loại bỏ mọi thành phần chỉ phục vụ IPv4, và cụm outbound-only / restricted inbound loại bỏ internet gateway thường (vốn cho phép hai chiều). Ghép lại, đề đang mô tả chính xác định nghĩa của egress-only internet gateway.

Còn một cụm thứ hai, tinh tế hơn, nằm trong bản thân các phương án: target của route là ::/0 hay 0.0.0.0/0. Đây là chỗ đề dùng để tách hai phương án cùng chọn đúng thiết bị.

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

B — Create an egress-only internet gateway and add a route to the route table pointing to the gateway for the target ::/0.

Egress-only internet gateway là thành phần của VPC, được AWS mô tả là horizontally scaled, redundant và highly available. Nó cho phép instance trong VPC gửi lưu lượng IPv6 ra Internet, đồng thời ngăn Internet khởi tạo kết nối IPv6 vào instance — đúng hai vế mà đề yêu cầu, không thừa không thiếu.

Vế thứ hai của phương án cũng phải đúng: chỉ tạo gateway thôi thì lưu lượng vẫn không biết đi đâu, phải thêm một route trong route table trỏ tới gateway đó. Với IPv6, route mặc định "mọi đích trên Internet" viết là ::/0 — đây là bản tương đương IPv6 của 0.0.0.0/0 bên IPv4.

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

A — Internet gateway + route ::/0. Đây là phương án gần đúng nhất về mặt địa chỉ: target ::/0 viết chuẩn cho IPv6. Nhưng thiết bị sai. Internet gateway cho phép lưu lượng đi cả hai chiều, nên Internet có thể chủ động mở kết nối tới instance — vi phạm thẳng ràng buộc "connectivity from the internet should be restricted". Trong bối cảnh IPv6 của đề này, thứ cần dùng là egress-only internet gateway.

D — Egress-only internet gateway + route 0.0.0.0/0. Đây là bẫy đối xứng với A: chọn đúng thiết bị nhưng sai target. 0.0.0.0/0 là route mặc định của IPv4; nó không khớp với bất kỳ đích IPv6 nào, nên lưu lượng IPv6 mà instance phát ra sẽ không tìm được route đi qua egress-only gateway. Muốn IPv6 đi ra thì entry trong route table phải là ::/0. Đây chính là lý do phải đọc kỹ cả hai nửa của mỗi phương án chứ không dừng lại khi thấy tên dịch vụ quen.

C — NAT gateway + route 0.0.0.0/0. Sai ở cả hai nửa. NAT gateway phục vụ IPv4: nó cho instance trong private subnet đi ra Internet bằng IPv4 mà không bị khởi tạo kết nối vào. Về ý đồ thì rất giống với đề bài (outbound có, inbound không), và đó là điều làm phương án này hấp dẫn — nhưng nó thao tác trên IPv4, không xử lý lưu lượng IPv6 của VPC trong đề. Target 0.0.0.0/0 đi kèm cũng khẳng định lại đây là nhánh IPv4.

📌 Điểm cần nhớ

• Thấy IPv6 + chỉ cho đi ra, chặn vào thì câu trả lời là egress-only internet gateway. Đó là bản đối ứng IPv6 của vai trò mà NAT gateway đảm nhiệm bên IPv4.
• Internet gateway là hai chiều. Bất kỳ đề nào nhấn mạnh "restrict inbound from the internet" đều loại nó ra, dù địa chỉ route có viết đúng.
• NAT gateway chỉ làm việc với IPv4. Đừng để sự tương đồng về mục đích (outbound-only) kéo mình chọn nhầm khi đề đang nói về IPv6.
• Tạo gateway là chưa đủ — luôn phải thêm route trong route table, và target phải đúng họ địa chỉ: ::/0 cho IPv6, 0.0.0.0/0 cho IPv4. Nhiều phương án sai chỉ ở đúng chi tiết này.

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

Đề mô tả một ứng dụng chạy trên bốn EC2 instance và đặt ra hai ràng buộc chồng lên nhau:

• "a minimum of four instances must be always running to support application demand" — bốn không phải là con số ban đầu cho vui, mà là mức sàn về năng lực phục vụ. Dưới bốn là ứng dụng không đáp ứng nổi tải.
• "continues to meet these requirements even if one Availability Zone becomes unavailable" — cụm quyết định đáp án nằm ở đây. Yêu cầu không phải là "vẫn còn chạy được", mà là vẫn còn đủ bốn instance sau khi mất trọn một AZ.

Ghép hai vế lại, câu hỏi thực chất là bài toán số học về dự phòng: phải triển khai bao nhiêu instance, trải trên bao nhiêu AZ, để phần còn lại sau sự cố vẫn ≥ 4. Auto Scaling group phân bổ instance đều nhất có thể giữa các AZ đã khai báo, nên mất một AZ nghĩa là mất khoảng tổng số / số AZ instance. Ràng buộc "minimum capacity" cũng cần đọc đúng: đó là mức sàn ASG duy trì, và số instance đang chạy ở trạng thái bình thường chính là con số đó.

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

C — một Auto Scaling group trải trên ba AZ, minimum capacity là sáu instance.

Sáu instance chia đều cho ba AZ ra hai instance mỗi AZ. Khi một AZ sập, mất hai instance, còn lại bốn — đúng bằng mức sàn mà đề yêu cầu. Ứng dụng tiếp tục phục vụ đủ tải trong lúc sự cố diễn ra, và ASG sẽ tự khởi chạy lại phần thiếu ở hai AZ còn khoẻ để quay về sáu.

Đây cũng là cấu hình tiết kiệm nhất trong các lựa chọn thoả mãn được điều kiện: chỉ dư hai instance so với nhu cầu, và dùng một ASG duy nhất nên việc scaling, health check và thay thế instance hỏng do một nơi điều phối.

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

A — ba AZ, minimum capacity bốn instance. Đúng về số AZ nhưng sai về dung lượng. Bốn instance trải trên ba AZ cho phân bổ 2-1-1. Mất AZ có hai instance thì còn hai; mất AZ có một instance thì còn ba. Cả hai trường hợp đều tụt xuống dưới bốn, vi phạm trực tiếp yêu cầu "luôn có tối thiểu bốn". Đây là phương án gài bẫy người chỉ đọc con số 4 trong đề rồi chép thẳng vào minimum capacity — nhưng 4 là mức sàn sau sự cố, không phải mức triển khai.

B — hai AZ, minimum capacity bốn instance. Hỏng nặng hơn A. Hai instance mỗi AZ, mất một AZ là mất một nửa, chỉ còn hai instance — bằng phân nửa nhu cầu. Số AZ ít cũng khiến "thuế dự phòng" đắt hơn: muốn đủ bốn sau sự cố với hai AZ thì phải chạy tám instance, tức gấp đôi nhu cầu, so với chỉ sáu khi dùng ba AZ.

D — hai Auto Scaling group ở hai AZ, mỗi group minimum capacity hai instance. Tổng vẫn là bốn instance trên hai AZ, nên hậu quả khi mất một AZ giống hệt B: chỉ còn hai instance. Việc tách làm hai ASG không thêm được chút khả năng chịu lỗi nào — nó chỉ đổi cách tổ chức, không đổi tổng dung lượng hay số AZ. Ngược lại còn dở hơn: hai ASG là hai bộ cấu hình, hai chính sách scaling phải giữ đồng bộ bằng tay, và mỗi ASG chỉ nhìn thấy AZ của riêng nó nên không thể bù capacity sang AZ còn lại khi một bên chết. Một ASG trải nhiều AZ làm được đúng việc đó một cách tự động.

📌 Điểm cần nhớ

• Khi đề nói "tối thiểu N instance kể cả khi mất một AZ", con số N là mức sàn sau sự cố. Công thức cần dùng: với Z AZ, phải triển khai N × Z / (Z − 1) instance thì mất một AZ vẫn còn N. Với N = 4: hai AZ cần 8, ba AZ cần 6, bốn AZ cần khoảng 6 (làm tròn lên).
• Càng nhiều AZ thì chi phí dự phòng càng rẻ — trải rộng hơn nghĩa là mỗi AZ giữ tỷ lệ nhỏ hơn của tổng dung lượng, nên mất một AZ tổn thất ít hơn.
• Một Auto Scaling group trải nhiều AZ luôn tốt hơn nhiều ASG mỗi cái một AZ: ASG tự cân bằng instance giữa các AZ và tự bù capacity khi một AZ mất, còn nhiều ASG chỉ nhân bản công việc quản lý mà không thêm khả năng chịu lỗi.
• Cảnh giác với phương án chép nguyên con số trong đề vào minimum capacity — đề thi hay đặt sẵn một lựa chọn như vậy để bắt người làm bài quên trừ đi phần mất theo AZ.

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

Đề đặt ra tình huống: một object nằm trong S3 bucket không bật public access, cần chia sẻ cho một nhóm người dùng, và nhóm này không có AWS account. Câu hỏi kết lại bằng "MOST operationally efficient solution".

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

• "does not have public access enabled" — không được mở bucket ra công khai, nên mọi lời giải kiểu "bật public read" bị loại từ đầu.
• "do not have an AWS account" — đây là ràng buộc sắc nhất. Không có AWS account nghĩa là người dùng không có IAM principal nào để gán quyền, cũng không có credentials để ký request hay để sts:AssumeRole. Mọi phương án dựa trên danh tính AWS đều chết ở đây.
• "MOST operationally efficient" — trong hai lời giải cùng chạy được, phải chọn cái ít việc vận hành lặp đi lặp lại nhất: không dựng thêm hệ thống, không phải cập nhật cấu hình thủ công theo thời gian.

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

B — Generate a presigned URL for the object. Share the URL with the users.

Mặc định mọi object trong S3 là private, chỉ chủ sở hữu object mới truy cập được. Nhưng chủ sở hữu có thể tạo presigned URL bằng chính security credentials của mình để cấp quyền tải object có giới hạn thời gian cho người khác.

Cơ chế này khớp chính xác với ràng buộc của đề: quyền nằm trong chữ ký gắn sẵn trong URL, không nằm ở danh tính người tải. Người nhận chỉ cần mở link bằng trình duyệt — không cần AWS account, không cần credentials, không cần cài công cụ gì.

Khi tạo presigned URL, bạn chỉ định bucket name, object key, HTTP method (GET để tải xuống) và thời điểm hết hạn. URL chỉ có hiệu lực trong khoảng thời gian đó, sau đó tự vô hiệu — không cần ai dọn dẹp quyền về sau. Bucket vẫn giữ nguyên trạng thái private, không phải sửa bucket policy, không phải bật public access.

Về mặt vận hành, đây là thao tác một lệnh, một lần: sinh URL rồi gửi đi. Đó là lý do nó thắng ở tiêu chí "MOST operationally efficient".

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

A — Bucket policy chỉ cho phép tải từ IP của người dùng.

Đây là phương án gần đúng nhất về mặt "chạy được": bucket policy có điều kiện theo source IP thì người không có AWS account vẫn tải được object. Nhưng nó hỏng ở đúng tiêu chí đề hỏi — operational efficiency. Địa chỉ IP của người dùng có thể thay đổi (đổi mạng, dùng mạng di động, IP động), và mỗi lần đổi là bạn phải sửa lại bucket policy. Ngoài ra thêm một người dùng mới là thêm một lần chỉnh policy. Đó là gánh nặng vận hành lặp lại vô thời hạn, trong khi presigned URL không đòi hỏi gì thêm sau khi sinh ra.

C — Tạo IAM role có quyền truy cập object, bảo người dùng assume role.

Phương án này va thẳng vào ràng buộc "không có AWS account". Để assume một IAM role, người dùng phải có sẵn một danh tính AWS nào đó để làm điểm xuất phát — mà theo đề thì họ không có. Kể cả trong tình huống có thể xoay xở được, cách này vẫn thêm rất nhiều phức tạp: cấu hình trust policy, hướng dẫn người dùng lấy temporary credentials, rồi họ phải dùng công cụ biết ký request AWS. Xa hẳn tiêu chí "operationally efficient".

D — Viết ứng dụng phát signed cookies, kiểm soát truy cập qua cookie.

Signed cookies là cơ chế của CloudFront, không dùng trực tiếp với Amazon S3. Đề không hề nhắc tới CloudFront, nên nền tảng kỹ thuật cho phương án này không tồn tại trong tình huống đang xét. Thêm nữa, nó bắt bạn xây và duy trì cả một ứng dụng chỉ để chia sẻ một object — đây là phương án tốn công vận hành nhất trong bốn phương án.

📌 Điểm cần nhớ

• "Người dùng không có AWS account" là tín hiệu gần như trực tiếp trỏ tới presigned URL: quyền nằm trong chữ ký của URL, không nằm ở IAM principal của người truy cập.
• Presigned URL cho phép chia sẻ object mà không phải bật public access và tự hết hạn theo thời gian bạn đặt — private vẫn là private, quyền không tồn đọng lại.
• Phân biệt hai cơ chế dễ lẫn: presigned URL dùng trực tiếp với S3; signed URL / signed cookies là của CloudFront. Đề chỉ nói S3 mà đáp án nhắc cookie thì gần như chắc chắn sai.
• Khi đề hỏi "MOST operationally efficient", hãy loại phương án đòi cập nhật cấu hình định kỳ (như danh sách IP thay đổi) hoặc đòi xây thêm ứng dụng/hệ thống — chúng có thể chạy được nhưng luôn thua ở tiêu chí này.
• Bất cứ phương án nào yêu cầu AssumeRole đều ngầm giả định người dùng đã có danh tính AWS; kiểm tra giả định đó trước khi chọn.