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

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

Đề mô tả một stack LAMP internal được provisioning bằng CloudFormation, EC2 instance tự cấu hình qua các cfn helper script (cfn-init, cfn-signal). Stack creation thất bại vì CloudFormation không nhận được signal từ EC2 instance. Câu hỏi yêu cầu chọn hai nguyên nhân khả dĩ.

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

• "internal full LAMP stack" — chữ internal ngụ ý instance nằm trong private subnet. Đây là gợi ý cho nhánh nguyên nhân về đường mạng.
• "CloudFormation fails to receive a signal" — điểm hỏng nằm ở khâu gửi và nhận signal, chứ không phải ở khâu tạo instance. Instance rõ ràng đã được tạo (nếu không thì stack sẽ fail vì lý do khác hẳn). Vậy mọi phương án nói về việc instance không ra đời được đều lệch trọng tâm.

cfn-signal là một script chạy trên instance, gọi ra CloudFormation service endpoint qua mạng. Nó chỉ thành công khi hai điều kiện đồng thời đúng: (1) có đường mạng ra tới endpoint đó, và (2) nó thực sự chạy và tới nơi trước khi wait condition hết hạn. Hai đáp án đúng ứng với đúng hai điều kiện này.

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

A — Subnet không có route tới CloudFormation service qua NAT Gateway hoặc Internet Gateway. Vì đây là stack internal, instance nằm ở private subnet. CloudFormation endpoint là một dịch vụ AWS nằm ngoài VPC, nên cfn-signal cần một đường đi ra: private subnet thì dùng NAT Gateway (cho phép instance khởi tạo kết nối ra ngoài nhưng chặn chiều ngược lại), public subnet thì dùng Internet Gateway kèm entry tương ứng trong route table. Thiếu route, lệnh cfn-signal chạy nhưng không tới được đích — CloudFormation ngồi chờ tới lúc hết hạn rồi fail.

D — cfn-signal không kịp chạy trước khi wait condition timeout. Thuộc tính Timeout của wait condition quy định CloudFormation chờ đủ số signal thành công trong bao lâu. Đây là ràng buộc cận dưới: timeout xảy ra không sớm hơn mốc đã đặt, nhưng có thể trễ hơn chút. Nếu đặt Timeout quá ngắn so với thời gian thật mà cfn-init cần để cài Apache, MySQL, PHP, thì signal đến sau khi cửa đã đóng — stack fail dù mọi thứ trên instance rồi cũng chạy được.

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

B — AWS thiếu capacity cho instance type đã yêu cầu. Đây là phương án gần đúng ở chỗ nó cũng làm stack fail thật, nhưng hỏng ở thời điểm: khi Insufficient Capacity xảy ra, instance không bao giờ được tạo. Stack chết ngay ở bước launch EC2 với thông báo lỗi tương ứng, chứ không đi tới giai đoạn chờ signal. Triệu chứng trong đề — "fails to receive a signal" — đòi hỏi instance đã tồn tại và đang chạy.

C — EC2 instance thiếu IAM role để signal thành công về CloudFormation. Đây là phương án gài bẫy nặng nhất, vì phản xạ tự nhiên khi thấy "gọi một AWS service" là nghĩ tới IAM permission. Nhưng cfn-signal không cần IAM role: nó xác thực bằng chính unique signed URL / logical resource id được nhúng vào lúc CloudFormation dựng resource, chứ không dùng credential của instance profile. Thiếu role không phải nguyên nhân làm signal không tới.

E — Script cfn-init thất bại. Cũng gần đúng theo trực giác "cài đặt hỏng thì stack hỏng", nhưng nó hỏng ở logic chuỗi lệnh. cfn-init fail không đồng nghĩa với việc cfn-signal không chạy — trong UserData, cfn-signal thường được đặt chạy sau và truyền exit code của cfn-init vào (-e $?). Khi đó CloudFormation vẫn nhận được signal, chỉ là signal báo failure. Stack vẫn fail, nhưng thông báo sẽ là "received FAILURE signal", khác hẳn với "failed to receive a signal" trong đề.

📌 Điểm cần nhớ

• Phân biệt ba kiểu fail khác nhau của CloudFormation: không nhận được signal (mạng bị chặn hoặc timeout), nhận signal báo failure (cfn-init hỏng), và resource không tạo được (capacity, quota, tham số sai). Đề bài luôn ám chỉ đúng một trong ba.
• cfn-signal cần đường mạng ra tới CloudFormation endpoint. Private subnet phải có NAT Gateway; public subnet phải có Internet Gateway kèm route. Từ khoá "internal" hay "private subnet" trong đề gần như luôn kéo theo nhánh nguyên nhân này.
• cfn-signal không cần IAM role — nó dùng URL/token đã được nhúng sẵn, không dùng instance profile credential. Đừng để phản xạ "AWS service = IAM" dẫn đi lạc.
• Thuộc tính Timeout của wait condition là cận dưới: phải đặt đủ rộng cho toàn bộ thời gian bootstrap thật (cài package, cấu hình service), không phải cho trường hợp lý tưởng.

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

Đề mô tả một chuỗi thao tác rất cụ thể: một SysOps Administrator share AMI từ account A sang account B, rồi vài ngày sau de-register AMI đó (thao tác de-register diễn ra ở account A — nơi sở hữu AMI). Câu hỏi: hậu quả là gì? (Chọn hai)

Cụm từ quyết định là "de-registered the AMI" kết hợp với "has shared". Hai chi tiết này phải đọc cùng nhau:

• Share AMI không tạo ra một bản sao trong account B. AMI vẫn là một tài nguyên duy nhất thuộc account A; account B chỉ được cấp quyền dùng nó. Không có "AMI của account B" tồn tại độc lập.
• De-register là thao tác gỡ AMI khỏi trạng thái dùng được để launch instance. Nó tác động lên thời điểm khởi tạo instance mới, chứ không tác động lên các instance đã đang chạy.

Ai đọc lướt sẽ tưởng "share sang B là B có bản riêng" (dẫn tới chọn A), hoặc tưởng "de-register kéo theo instance chết" (dẫn tới chọn B). Cả hai đều hiểu sai bản chất của việc share.

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

D — "You can't launch new instances from the AMI in account A or in account B"

AMI chỉ tồn tại ở account A. Khi account A de-register nó, AMI không còn dùng để launch được ở bất kỳ đâu — kể cả account B, vì quyền được share chỉ trỏ về đúng cái AMI vừa bị gỡ. Không có ngoại lệ nào cho account nhận share.

C — "The instances already launched from the shared AMI in account B, are not impacted by this de-registration"

Instance đã launch xong thì không còn phụ thuộc vào AMI để tiếp tục chạy. De-register AMI ở account gốc không đụng tới chúng: chúng vẫn chạy bình thường. Nếu account B cần launch thêm instance sau khi AMI đã bị de-register, cách xử lý là tạo AMI mới từ một trong các instance đang chạy đó.

Hai đáp án này ghép lại thành một bức tranh nhất quán: mất khả năng tạo mới, giữ nguyên cái đang có.

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

A — "You can launch new instances from the de-registered AMI from account B alone. The AMI is invalid in account A"

Đây là phương án gần đúng nhất và cũng là bẫy chính: nó đúng một nửa (AMI không dùng được ở A) nhưng sai ở nửa còn lại. Nó giả định account B giữ một bản độc lập nên "sống sót" sau khi A de-register. Thực tế share chỉ là cấp quyền, không nhân bản — AMI đã de-register thì không launch được ở cả hai account.

B — "Instances launched using the shared AMI in account B are de-registered"

Sai vì lẫn lộn hai đối tượng khác nhau: de-register áp lên AMI, không áp lên instance. Instance đang chạy không bị ảnh hưởng bởi thay đổi trên AMI đã tạo ra chúng. Phương án này còn mâu thuẫn trực tiếp với C.

E — "Copy the AMI to a different Region in account B and create instances from this AMI"

Bản thân việc copy AMI sang Region khác là thao tác hợp lệ, nhưng nó phải làm trước khi account A de-register. Đề đã nói rõ AMI đã bị de-register rồi, nên tại thời điểm câu hỏi đặt ra, không còn gì để copy. Ngoài ra E mô tả một hành động khắc phục chứ không phải outcome của việc de-register — không trả lời đúng cái đề hỏi.

📌 Điểm cần nhớ

• Share AMI = cấp quyền, không phải nhân bản. AMI vẫn thuộc account gốc; account nhận không có bản riêng nào tồn tại độc lập.
• De-register tác động lên khả năng launch mới, không tác động lên instance đang chạy. Instance đã tạo vẫn hoạt động bình thường.
• Muốn account B giữ quyền tự chủ lâu dài thì phải hành động TRƯỚC khi AMI bị de-register — copy AMI sang account/Region của mình, hoặc tạo AMI mới từ một instance đang chạy.
• Với câu hỏi kiểu "outcome of this action", loại ngay những phương án mô tả việc nên làm thay vì hệ quả đã xảy ra — như E ở đây.

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

Đề mô tả một công ty đang giữ toàn bộ dữ liệu on-premises để ứng dụng tại chỗ truy cập với độ trễ thấp. Vấn đề: chi phí hạ tầng tăng và phương án khôi phục thảm hoạ (disaster recovery) không đáng tin. Công ty muốn đưa dữ liệu lên AWS Cloud nhưng vẫn giữ nguyên độ trễ thấp cho ứng dụng on-premises.

Cụm từ quyết định nằm ở câu hỏi cuối: "on-premises iSCSI block devices data". Đây là ràng buộc phân biệt duy nhất, và nó gồm hai phần:

• iSCSI — giao thức mà ứng dụng đang dùng để nói chuyện với thiết bị lưu trữ. Giải pháp thay thế phải trình ra đúng giao thức này, nếu không thì ứng dụng phải viết lại.
• block devices — dữ liệu ở dạng khối, không phải file, không phải object.

Thêm một ràng buộc phụ: "still maintaining the current low latency access" — nghĩa là giải pháp phải có cơ chế cache tại chỗ hoặc giữ bản chính tại chỗ, chứ không phải mỗi lần đọc đều đi ra Internet.

Vậy câu hỏi rút gọn thành: dịch vụ nào trình ra iSCSI block volume cho ứng dụng on-premises trong khi lưu dữ liệu trên AWS?

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

C — Use Volume Gateway of AWS Storage Gateway service.

AWS Storage Gateway là bộ dịch vụ hybrid cloud, cho hệ thống on-premises truy cập kho lưu trữ trên cloud. Trong đó, Volume Gateway trình ra chính xác các volume block dạng iSCSI cho ứng dụng on-premises, còn dữ liệu thì được lưu và quản lý trên Amazon S3 thay cho khách hàng. Đây là điểm khớp một-đối-một với cụm "iSCSI block devices" trong đề.

Volume Gateway chạy ở hai chế độ, và cả hai đều thoả yêu cầu độ trễ thấp:

• Cached mode: dữ liệu chính nằm trên S3, phần dữ liệu truy cập thường xuyên được giữ lại trong cache tại chỗ để đọc nhanh. Đây là chế độ phục vụ đúng mục tiêu "giảm chi phí hạ tầng on-premises" của đề.
• Stored mode: dữ liệu chính vẫn nằm tại chỗ nên toàn bộ dataset đọc được với độ trễ thấp, đồng thời được sao lưu bất đồng bộ lên S3.

Phần disaster recovery cũng được giải quyết: ở cả hai chế độ, bạn có thể tạo bản sao point-in-time của volume bằng AWS Backup, lưu trên AWS dưới dạng Amazon EBS snapshot. Đó chính là phương án khôi phục đáng tin cậy mà đề nói đang thiếu.

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

D — File Gateway of AWS Storage Gateway service. Đây là phương án gần đúng nhất và là cái bẫy chính của câu này: cùng họ Storage Gateway, cũng lưu dữ liệu lên S3, cũng có local caching nên cũng cho độ trễ thấp. Nó hỏng đúng một chỗ: giao thức. Amazon S3 File Gateway trình ra dữ liệu qua SMB hoặc NFS — tức là truy cập theo kiểu file, dành cho ứng dụng cần file protocol access tới S3 object storage. Đề yêu cầu iSCSI block devices, mà File Gateway không nói iSCSI. Chọn D là ép ứng dụng đang dùng block phải chuyển sang giao diện file.

B — Amazon EFS. EFS là dịch vụ file storage, chia sẻ dữ liệu qua giao thức NFSv4 với mô hình phân quyền file truyền thống và cấu trúc thư mục phân cấp. Nó sai ở hai điểm: (1) là file chứ không phải block iSCSI; (2) cụm "low latency for hundreds of compute instances" trong chính phương án nói về compute instances trên AWS, không phải về ứng dụng on-premises — nó không phải là dịch vụ hybrid có cache tại chỗ như Storage Gateway.

A — Amazon S3 web service interface. S3 là object storage, truy cập bằng API đơn giản. Nó hợp với ứng dụng không cần cấu trúc file system và được thiết kế sẵn để làm việc với object storage. Ứng dụng on-premises trong đề đang nói chuyện bằng iSCSI với thiết bị block — muốn dùng thẳng S3 thì phải viết lại ứng dụng theo API object, và cũng không có cơ chế cache tại chỗ nào để giữ độ trễ thấp.

📌 Điểm cần nhớ

• Đọc giao thức trước, đọc dịch vụ sau. Trong nhóm câu hỏi lưu trữ hybrid, từ khoá giao thức là thứ chốt đáp án: iSCSI → Volume Gateway, SMB/NFS → File Gateway, NFSv4 (trên AWS) → EFS, API object → S3.
• Phân biệt block – file – object. Đây là trục chia ba mà đề rất hay dùng để tạo các phương án gần giống nhau. "Block devices" loại thẳng mọi phương án file và object.
• "Vẫn giữ độ trễ thấp cho ứng dụng on-premises" là tín hiệu của hybrid storage có cache tại chỗ, chứ không phải của một dịch vụ lưu trữ thuần cloud.
• Volume Gateway có hai chế độ, đừng nhầm. Cached mode giữ dữ liệu chính trên S3 và cache phần nóng tại chỗ; stored mode giữ nguyên dữ liệu chính tại chỗ và sao lưu bất đồng bộ lên S3. Đề nhấn mạnh giảm chi phí hạ tầng on-premises thì nghiêng về cached mode.

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

Đề mô tả một hệ thống cố tình áp dụng chaos testing kiểu Netflix: EC2 instance trong production có thể bị terminate bất cứ lúc nào. Website đứng sau một load balancer đang trả về nhiều lỗi 4XX, và người vận hành muốn tìm danh sách các HTTP request đã gây ra lỗi đó.

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

• "you cannot SSH into the instances ... as they have been terminated" — mọi phương án dựa vào việc lấy log từ bên trong instance đều chết ngay từ đầu. Instance đã terminate thì không còn ổ đĩa gốc, không còn quyền truy cập, không có gì để đọc.
• "logs files that describe the list of HTTP requests" — thứ cần là log ở tầng request HTTP, tức là nơi nhìn thấy đường dẫn, mã trả về, IP client. Trong danh sách phương án, chỉ có một thành phần sống sót qua việc instance bị giết mà vẫn thấy được request: chính load balancer.

Ghép hai ràng buộc lại: cần một nguồn log nằm ngoài vòng đời của EC2 instance nhưng vẫn ghi được từng HTTP request.

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

D — Enable the ELB access logs and query them using Athena.

ELB access logs là tính năng tuỳ chọn của Elastic Load Balancing, mặc định tắt, ghi lại thông tin chi tiết về từng request gửi tới load balancer: thời điểm nhận request, IP client, độ trễ, đường dẫn request, và mã phản hồi của server. Đây đúng là "danh sách HTTP request" mà đề hỏi.

Điểm mấu chốt: log này do load balancer ghi và được đưa thẳng vào một S3 bucket, không nằm trên EC2 instance. Instance bị chaos test giết sạch cũng không ảnh hưởng gì tới log đã lưu — dữ liệu vẫn còn nguyên trong S3. Mỗi tệp log được mã hoá bằng SSE-S3 khi lưu và tự giải mã khi đọc, người dùng không phải làm gì thêm.

Phần còn lại là cách phân tích: Amazon Athena cho phép truy vấn dữ liệu nằm sẵn trong S3 bằng SQL chuẩn. Athena là serverless — không phải dựng hay quản lý hạ tầng, chỉ trả tiền theo truy vấn chạy. Với tình huống này, ta bật ELB access logs rồi dùng Athena lọc ra các bản ghi có mã 4XX để xem request nào gây lỗi.

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

A — Contact AWS Support to recover the instances. Sai dứt khoát: EC2 instance đã terminate thì không khôi phục lại được, kể cả qua AWS Support. Terminate không phải stop — nó là trạng thái cuối, không có đường quay lại. Đây cũng là phương án dễ loại nhất.

B — Look at the EC2 default logs in CloudWatch Logs. Đây là phương án gài bẫy dựa trên một hiểu nhầm rất phổ biến: EC2 không có "default logs" trong CloudWatch Logs. CloudWatch tự thu thập metric ở mức hypervisor (CPU, network, disk I/O), nhưng log bên trong hệ điều hành thì không. Muốn đẩy log từ EC2 lên CloudWatch Logs, bạn phải chủ động cài và cấu hình CloudWatch Agent trên từng instance (Linux hoặc Windows Server). Đề không hề nói agent đã được cài, nên không có log nào để xem. Và kể cả nếu có, đó vẫn là log ứng dụng chứ không phải bản ghi request ở tầng load balancer.

C — Use EC2 Rescue and bring back the log files from the wiped EBS volumes. Đây là phương án gần đúng nhất và cũng nguy hiểm nhất, vì EC2Rescue là công cụ có thật và đúng là dùng để lấy log. EC2Rescue for Linux là công cụ mã nguồn mở chạy trên một EC2 Linux instance để chẩn đoán sự cố qua thư viện hơn 100 module: thu thập syslog và log của package manager, gom số liệu sử dụng tài nguyên, xử lý tham số kernel có vấn đề hay lỗi OpenSSH thường gặp.

Nó hỏng ở chỗ: EC2Rescue cần một instance đang chạy và một volume còn tồn tại để làm việc. Đề đã nói rõ instance đã bị terminate, và chính phương án cũng tự thừa nhận volume đã "wiped". Không có đĩa thì không có gì để cứu — công cụ này không dùng được cho tình huống đang xét. Ngoài ra, ngay cả khi lấy được, đó là log hệ thống của instance chứ chưa chắc là bản ghi đầy đủ mọi HTTP request đi qua load balancer.

📌 Điểm cần nhớ

• Instance sống ngắn thì log phải nằm ngoài instance. Với chaos testing, auto scaling, hay spot instance, mọi thứ ghi trên đĩa cục bộ đều có thể biến mất — hãy chọn nguồn log do dịch vụ quản lý ghi ra ngoài (ELB access logs → S3) thay vì log trong máy.
• Lỗi 4XX/5XX ở tầng HTTP thì hỏi load balancer trước. ELB access logs cho IP client, đường dẫn, độ trễ và mã phản hồi của từng request — đúng thứ cần để truy nguyên request gây lỗi.
• ELB access logs mặc định tắt. Đề thi rất hay xoáy vào chi tiết này; phải bật thì mới có dữ liệu, và log đổ vào S3 bucket do bạn chỉ định.
• EC2 không tự đẩy log lên CloudWatch Logs — phải cài CloudWatch Agent. Thấy phương án nào nói "default logs của EC2 trong CloudWatch Logs" thì loại ngay.
• Log đã nằm trong S3 thì Athena là cách phân tích rẻ và nhanh nhất: serverless, truy vấn bằng SQL chuẩn, trả tiền theo truy vấn, không phải dựng hạ tầng.
• Terminate là không thể hoàn tác — không có chuyện AWS Support khôi phục instance đã terminate.

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

Tình huống: một web application chạy sau load balancer và auto scaling group, phía sau là Aurora database cũng được auto scale (thêm/bớt Aurora Read Replica) theo CloudWatch alarm. Chuỗi kết nối tới database được lưu trong SSM Parameter Store. Sau vài lần scale out và scale in, ứng dụng mất hoàn toàn kết nối tới database, và URL trong SSM Parameter Store không còn ứng với bất kỳ Aurora read replica nào — dù trước đó nó từng đúng.

Cụm từ quyết định nằm ở hai chỗ:

• "it does not correspond to any of the Aurora read replicas, although it used to" — nguyên nhân đã được chỉ đích danh: ứng dụng đang trỏ tới endpoint của một instance cụ thể. Instance đó bị xoá trong một lần scale in, và endpoint chết theo. Đây là bài toán "đừng hardcode một node trong cụm co giãn".
• "fix that problem easily in the long term while allowing your application to remain elastic" — hai ràng buộc cùng lúc: cách chữa phải đơn giản, lâu dài (không thêm thành phần phải tự bảo trì) và phải giữ được tính co giãn (không được chữa bằng cách tắt scaling đi).

Bất kỳ phương án nào hy sinh một trong hai vế đó đều bị loại.

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

B — Use the Aurora Reader Endpoint.

Mỗi Aurora DB cluster có sẵn một reader endpoint dành riêng cho kết nối chỉ đọc. Ứng dụng chỉ cần trỏ tới đúng một tên DNS cố định đó, còn Aurora tự lo phần phân tải các kết nối tới những Aurora Replica đang có trong cluster. Khi Aurora Auto Scaling thêm replica, replica mới tự động nằm trong tập đích của reader endpoint; khi scale in bớt replica, endpoint vẫn còn nguyên vì nó thuộc về cluster chứ không thuộc về một instance nào.

Đây chính là cơ chế Aurora dựng ra để bạn không phải hardcode hostname của từng instance và không phải tự viết logic phân tải hay định tuyến lại khi một DB instance biến mất. Đặt reader endpoint vào SSM Parameter Store một lần là xong: giá trị đó không bao giờ cần cập nhật lại, mà cụm vẫn co giãn thoải mái — thoả cả "easily in the long term" lẫn "remain elastic". Kèm theo đó, việc dồn các câu SELECT sang replica còn giảm tải cho primary instance, và khả năng phục vụ truy vấn đọc đồng thời tăng theo số replica trong cluster.

Lưu ý dùng: trong phiên nối qua reader endpoint bạn chỉ chạy được câu lệnh chỉ đọc; ghi dữ liệu phải đi qua cluster endpoint (writer).

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

A — Disable Aurora Auto Scaling. Đây là phương án mồi. Ngoài chuyện nó đi ngược yêu cầu "remain elastic" — bỏ scaling để tránh lỗi là chữa bệnh bằng cách cắt bỏ chính năng lực mình cần — thì bản thân việc "tắt Aurora Auto Scaling" cũng không phải một cái công tắc bạn gạt được như thế. Và kể cả có tắt, gốc rễ vẫn còn: ứng dụng vẫn trỏ vào endpoint của một instance riêng lẻ, chỉ cần instance đó gặp sự cố hoặc bị thay thế là lại đứt.

C — Create a target group made up of the Aurora Read Replicas and set up a Network Load Balancer. Đây là phương án gần đúng nhất về mặt ý tưởng: nó đúng ở chỗ nhận ra cần một điểm vào ổn định có phân tải. Nhưng nó hỏng ở hai điểm. Thứ nhất, Elastic Load Balancer không dùng để cân tải cho RDS/Aurora database — Aurora đã có sẵn cơ chế endpoint làm đúng việc này. Thứ hai, ngay cả khi dựng được, target group vẫn phải theo kịp việc replica sinh ra và mất đi liên tục, nghĩa là bạn tự dựng lại một thứ đã có sẵn miễn phí, thêm một tầng hạ tầng phải trả tiền và phải bảo trì — trái hẳn với chữ "easily" trong đề.

D — Create an AWS Lambda function CRON job that updates SSM with the latest connection string from all the alive Aurora Read Replicas. Về mặt kỹ thuật thì chạy được: Lambda có thể liệt kê replica đang sống và ghi đè giá trị trong SSM Parameter Store. Nhưng nó không đơn giản mà cũng không hiệu quả. Bạn phải viết và bảo trì code, và vì CRON chạy theo chu kỳ nên luôn tồn tại khoảng trễ giữa lúc replica biến mất và lúc SSM được cập nhật — chính khoảng trễ đó là lúc ứng dụng đứt kết nối, đúng triệu chứng đề đang mô tả. Thêm nữa, ghi được "connection string from all the alive replicas" vào một tham số cũng chưa giải quyết chuyện ứng dụng chọn replica nào và phân tải ra sao. Đây là tự viết lại reader endpoint bằng tay, kém hơn bản gốc ở mọi mặt.

📌 Điểm cần nhớ

• Trong một cụm co giãn, đừng lưu endpoint của instance cụ thể vào cấu hình (SSM Parameter Store, biến môi trường, file config). Hãy lưu endpoint cấp cluster — thứ tồn tại độc lập với vòng đời từng instance.
• Aurora phân biệt rõ: cluster (writer) endpoint cho ghi, reader endpoint cho đọc và tự phân tải giữa các Aurora Replica. Đề nhắc tới truy vấn đọc và read replica là dấu hiệu trỏ thẳng tới reader endpoint.
• Load balancer (ALB/NLB) không dùng để cân tải database RDS/Aurora. Thấy phương án đề nghị dựng target group từ các DB instance thì gần như chắc chắn là mồi.
• Khi đề nhấn mạnh "easily" hoặc "long term", hãy ưu tiên tính năng có sẵn của dịch vụ hơn là giải pháp tự dựng bằng Lambda + CRON — code tự viết luôn kèm khoảng trễ đồng bộ và chi phí bảo trì.

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

Đề mô tả một chiến dịch marketing chốt sẵn ngày cao điểm là 22/02, và dự báo traffic tăng gấp 10 lần đúng vào ngày đó. Hạ tầng hiện tại chạy trên Elastic Beanstalk, và Beanstalk đã dựng sẵn một ASG cùng một ELB.

Cụm từ quyết định đáp án là "traffic to increase by 10x" trên một ngày đã biết trước, cộng với "Select two". Đây là kiểu tải đột biến (flash traffic) chứ không phải tăng dần: nó ập đến trong thời gian ngắn, ở mức gấp nhiều lần bình thường.

Điểm mấu chốt thứ hai: đề nói rõ hạ tầng đã có sẵn ASG và ELB rồi. Nghĩa là câu hỏi không hỏi "kiến trúc nào chịu tải tốt", mà hỏi hai thành phần sẵn có kia có thể vướng gì khi tải nhân lên 10 lần. Trả lời được câu đó là chọn đúng: một là giới hạn quota số EC2 instance khiến ASG không scale-out nổi, hai là khả năng đáp ứng tức thời của load balancer trước cú sốc traffic. Mọi phương án không chạm vào hai điểm nghẽn này đều lạc đề, dù bản thân chúng là kỹ thuật hợp lệ.

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

B — Open a support request with AWS to pre-warm the load balancer

ELB xử lý được phần lớn tình huống mà không cần can thiệp gì, nhưng nó có cơ chế tự điều chỉnh dung lượng theo tải quan sát được. Với flash traffic — tải nhảy vọt đột ngột, hoặc bài kiểm thử tải không thể tăng dần — AWS khuyến nghị mở support request để "pre-warm" load balancer, tức cấu hình trước cho nó mức dung lượng phù hợp với lượng traffic bạn dự báo. Khi làm việc này, AWS cần biết ngày bắt đầu và kết thúc đợt cao điểm, tốc độ request mỗi giây dự kiến, và kích thước điển hình của request/response. Đề bài cho đủ cả: ngày cụ thể (22/02) và mức tăng cụ thể (10x) — đúng kịch bản mà pre-warming sinh ra để giải quyết.

C — Open a support request to increase the upper limit on the number of the EC2 instance types you're using

Mỗi tài khoản AWS có quota mặc định theo từng Region cho số EC2 instance được chạy. Vượt quá thì lệnh khởi chạy instance mới (hoặc khởi động lại instance đã stop) trả về lỗi InstanceLimitExceeded. Đây chính là cái bẫy: ASG có chính sách scale-out, nhưng khi nó cố khởi chạy thêm instance để gánh 10x traffic mà quota chặn lại thì việc scale thất bại ở tầng API, không phải ở tầng cấu hình. Vì vậy phải mở support request nâng trần số instance lên mức đủ cho ASG mở rộng tới quy mô cần thiết — và phải làm trước ngày cao điểm, vì đây là quy trình cần AWS xử lý chứ không phải công tắc bật tức thì.

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

A — Enable Blue/Green Beanstalk Deployment

Đây là phương án dễ chọn nhầm nhất, vì nó là kỹ thuật Beanstalk thật và đề có nhắc Beanstalk. Nhưng blue/green giải quyết một vấn đề khác hẳn: Beanstalk mặc định cập nhật tại chỗ (in-place update) nên ứng dụng có thể gián đoạn ngắn khi triển khai phiên bản mới. Blue/green tránh chuyện đó bằng cách deploy bản mới sang một environment riêng rồi swap CNAME giữa hai environment để chuyển traffic tức thì. Nó là kỹ thuật giảm downtime khi deploy, hoàn toàn không làm tăng năng lực chịu tải — ngày 22/02 bạn có deploy gì đâu, bạn cần phục vụ nhiều người hơn. Nó hỏng ở chỗ đó: đúng công cụ, sai bài toán.

D — Open a support request with AWS to request a penetration testing authorization

Phương án này ăn theo hình thức "mở support request" của hai đáp án đúng nên trông có vẻ cùng họ. Nhưng nội dung thì không liên quan: AWS cho phép khách hàng tự thực hiện đánh giá bảo mật hoặc penetration testing trên hạ tầng của mình đối với các dịch vụ được phép, không cần xin duyệt trước. Quan trọng hơn, penetration testing là hoạt động kiểm thử bảo mật, nó không tạo thêm một chút năng lực phục vụ traffic nào cho ASG hay ELB.

E — Use a weighted policy record in Route 53

Weighted routing cho phép gắn nhiều resource vào cùng một tên miền hoặc subdomain và chọn tỷ lệ traffic đi về từng resource — hữu ích khi phân bổ tải giữa các endpoint đã có sẵn, hoặc khi thử nghiệm phiên bản phần mềm mới. Chỗ nó hỏng: weighted record chỉ chia lượng traffic hiện có theo tỷ lệ, nó không tạo thêm dung lượng. Ở đây bạn chỉ có một environment Beanstalk duy nhất, nên không có resource thứ hai để san tải sang; và kể cả có, tổng năng lực vẫn bị chặn bởi đúng hai giới hạn ở B và C.

📌 Điểm cần nhớ

• Khi đề nêu traffic tăng đột biến vào một mốc thời gian biết trước (flash traffic, ngày sale, sự kiện), hãy nghĩ tới pre-warming ELB qua support request — dấu hiệu nhận biết là tải không tăng dần mà nhảy vọt.
• ASG có chính sách scale-out không đồng nghĩa với việc nó scale được. Quota EC2 instance theo Region là trần cứng; chạm trần thì nhận InstanceLimitExceeded và việc mở rộng đứng lại. Chuẩn bị cho cao điểm luôn phải soát quota trước.
• Phân biệt rành mạch ba nhóm kỹ thuật thường bị trộn lẫn trong cùng một câu: deployment (blue/green — giảm downtime khi ra bản mới), routing (Route 53 weighted — chia traffic giữa các resource đã có), và capacity (pre-warm, nâng quota — tăng năng lực phục vụ). Câu hỏi về chịu tải chỉ chọn nhóm thứ ba.
• Đừng bị "Open a support request..." đánh lừa: cùng một hình thức hành động nhưng nội dung yêu cầu mới là thứ quyết định đúng/sai — pentest authorization không mua thêm được năng lực nào.

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

Bối cảnh: công ty muốn chọn ra những "AWS champion" trong nội bộ để dẫn dắt việc áp dụng cloud, và cần phân tích xem ai là người dùng AWS hoạt động tích cực nhất.

Cụm từ quyết định là "most active AWS users" — chú ý hai chữ users. Đề không hỏi lưu lượng mạng nhiều nhất, không hỏi tài nguyên nào tốn kém nhất, cũng không hỏi hành vi nào đáng ngờ. Nó hỏi về con người / danh tính (IAM identity) và mức độ họ thao tác trên tài khoản AWS.

Từ đó suy ra thứ ta cần là một nguồn dữ liệu ghi lại ai đã gọi API nào, lúc nào — tức là bản ghi hoạt động theo danh tính. Vế thứ hai của mọi phương án đều là Athena, nên Athena không phải chỗ phân biệt; điểm khác biệt duy nhất nằm ở nguồn log đứng trước nó. Cả bốn phương án chỉ khác nhau ở chỗ đó.

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

B — Use CloudTrail and Athena.

CloudTrail là dịch vụ phục vụ governance, compliance và auditing cho tài khoản AWS. Nó ghi lại lịch sử sự kiện (event history) của mọi hành động trong tài khoản, bất kể hành động đó đến từ AWS Management Console, AWS SDK, command-line tools hay từ dịch vụ AWS khác. Mỗi bản ghi gắn với danh tính đã thực hiện lời gọi, nên đây chính là nguồn duy nhất trả lời được câu hỏi "ai hoạt động nhiều nhất".

Để có bản ghi liên tục — bao gồm cả sự kiện của IAM và AWS STS — bạn tạo một trail. Trail cho phép CloudTrail đẩy log file vào một S3 bucket. Khi tạo trail trong console, mặc định trail áp dụng cho tất cả các Region trong partition và gom log về đúng bucket bạn chỉ định — nghĩa là dữ liệu hoạt động của toàn tổ chức nằm gọn một chỗ.

Athena là dịch vụ truy vấn tương tác, cho phép dùng SQL chuẩn để phân tích dữ liệu trực tiếp trên S3. Athena serverless, không phải dựng hay quản lý hạ tầng, và chỉ trả tiền theo truy vấn đã chạy. Nó rất hợp cho việc xử lý log và chạy phân tích ad-hoc.

Ghép lại: CloudTrail đổ log hoạt động (kèm danh tính) vào S3 → Athena chạy SQL trên đống log đó, nhóm theo user và đếm số sự kiện → ra danh sách người dùng tích cực nhất. Đây đúng là mô hình "log vào S3, query bằng SQL" mà đề nhắm tới.

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

A — Use VPC Flow Logs and Athena. Đây là phương án gần đúng về mặt kiến trúc: VPC Flow Logs cũng publish được sang Amazon S3 (hoặc CloudWatch Logs), và cũng query được bằng Athena. Chỗ hỏng nằm ở nội dung dữ liệu: Flow Logs ghi thông tin lưu lượng IP đi vào và đi ra các network interface trong VPC, dùng để phân tích dấu vết mạng và hỗ trợ network security. Nó nói về địa chỉ IP và gói tin, không nói về IAM identity nào đã gọi API nào. Bạn không lấy được thông tin "người dùng AWS tích cực nhất" từ Flow Logs.

C — Use GuardDuty and Athena. GuardDuty là dịch vụ threat detection: nó theo dõi hoạt động độc hại và hành vi trái phép để bảo vệ tài khoản AWS. Điểm dễ nhầm là GuardDuty có phân tích lượng lớn sự kiện từ chính 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) — nên nghe qua tưởng nó "biết hết". Nhưng đầu ra của GuardDuty là finding về mối đe doạ, không phải bảng thống kê mức độ hoạt động theo người dùng. Nó lọc ra cái bất thường, chứ không xếp hạng cái bình thường. Sai mục đích, không phải sai công cụ phân tích.

D — Use IAM usage report and Athena. Phương án này không tồn tại — không có thứ gì gọi là "IAM usage report" trong AWS. Đây là tên bịa ra nghe rất hợp lý vì đề đang hỏi về user, và "IAM" đúng là nơi quản lý danh tính. Gặp phương án nghe đúng ý đồ nhưng lạ tên như vậy thì phải cảnh giác.

📌 Điểm cần nhớ

• Câu hỏi kiểu "ai đã làm gì trên tài khoản AWS" — audit, governance, compliance, truy vết hành động theo danh tính — gần như luôn là CloudTrail.
• Phân biệt ba nguồn log hay bị trộn lẫn: CloudTrail = lời gọi API theo danh tính; VPC Flow Logs = lưu lượng IP ở network interface; GuardDuty = phát hiện mối đe doạ dựa trên chính hai nguồn kia cộng DNS Logs.
• CloudTrail + S3 + Athena là combo kinh điển: trail đổ log vào S3, Athena chạy SQL serverless trực tiếp trên S3 để phân tích ad-hoc. Thấy đề nói "phân tích log" mà có Athena thì hãy tìm xem log nào chứa đúng thông tin cần.
• Khi cả bốn phương án chia sẻ chung một thành phần (ở đây là Athena), thành phần đó không phải chỗ phân biệt — hãy so phần còn lại. Và luôn nghi ngờ tên dịch vụ/tính năng nghe hợp lý nhưng bạn chưa từng gặp trong tài liệu.

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

Đề mô tả một daily job tính toán các chỉ số từ toàn bộ tài nguyên đang chạy trong account, rồi đẩy số liệu sang Tableau dashboard. Câu hỏi cuối cùng rất hẹp: chọn loại EC2 instance nào để giữ chi phí thấp.

Cụm từ quyết định nằm ngay trước câu hỏi: "That job is fault-tolerant and can be resumed at any time" — job chịu được gián đoạn và chạy lại được bất cứ lúc nào. Cộng thêm hai chi tiết phụ trợ: job chạy theo ngày, tức chỉ chiếm máy trong một khoảng thời gian ngắn mỗi ngày, và mục tiêu tối ưu là cost, không phải latency hay throughput.

Ba dữ kiện đó gộp lại vẽ ra đúng chân dung workload mà mô hình giá rẻ nhất của EC2 nhắm tới: chạy ngắt quãng được, không cam kết dài hạn, không cần chạy liên tục. Ai bỏ qua vế "fault-tolerant" sẽ thấy bốn phương án đều "hợp lý" ở mức nào đó — chính vế đó mới là bộ lọc.

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

A – EC2 Spot Instances. Spot Instance là phần dung lượng EC2 đang không dùng đến, được bán lại với giá thấp hơn hẳn On-Demand — đây là mô hình rẻ nhất trong các lựa chọn ở đề. Giá Spot của mỗi instance type trong mỗi Availability Zone do EC2 đặt và điều chỉnh dần theo cung – cầu dài hạn; instance của bạn chạy khi còn capacity và mức giá tối đa bạn đặt vượt Spot price hiện hành.

Cái giá phải trả cho mức chiết khấu đó là instance có thể bị thu hồi khi capacity cạn hoặc giá vượt ngưỡng. Với hầu hết workload đó là rủi ro không chấp nhận được — nhưng đề đã nói thẳng job này fault-tolerant và resume được bất cứ lúc nào, nên gián đoạn không gây mất mát gì. Đúng điều kiện Spot đòi hỏi, nên Spot là lựa chọn chi phí thấp nhất khả thi ở đây.

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

C – EC2 On-Demand. Đây là phương án gần đúng nhất, và cũng là bẫy hay dính. On-Demand tính tiền theo giây, không cam kết dài hạn, bạn toàn quyền launch/stop/terminate — rất hợp với công việc chạy ngắn, không đều. AWS khuyến nghị On-Demand cho workload ngắn hạn, thất thường và không được phép bị gián đoạn. Vế cuối chính là chỗ nó thua: job trong đề chịu được gián đoạn, nên trả giá On-Demand là mua một sự đảm bảo mình không cần. So với Spot cho cùng use-case này, On-Demand đắt hơn.

D – EC2 Reserved Instances. RI giảm giá bằng cách bạn cam kết một cấu hình instance cố định (instance type, Region) trong kỳ hạn 1 hoặc 3 năm. Mô hình này chỉ có lợi khi máy chạy gần như liên tục suốt kỳ hạn. Job ở đây chỉ chạy một lát mỗi ngày, nên phần lớn thời gian bạn trả tiền cho capacity nằm không — cam kết cả năm là không phù hợp, và tiết kiệm thu về không bù được.

B – EC2 Placement Groups – Cluster. Sai ở chỗ cơ bản hơn: đây không phải một kiểu giá, mà là cách bố trí vị trí instance trên hạ tầng bên dưới. Cluster gom các instance sát nhau trong một Availability Zone để đạt độ trễ mạng thấp, phục vụ giao tiếp node-to-node chặt chẽ kiểu HPC. Các chiến lược khác: Partition tách instance sang các phân vùng không dùng chung phần cứng (Hadoop, Cassandra, Kafka), Spread trải một nhóm nhỏ instance lên phần cứng riêng biệt để giảm hỏng hàng loạt. Không chiến lược nào ảnh hưởng tới hoá đơn — đây thuần tuý là distractor.

📌 Điểm cần nhớ

• Thấy "fault-tolerant", "có thể bị gián đoạn", "resume được", "flexible start/end time" đi kèm yêu cầu giảm chi phí → gần như luôn là Spot Instances. Đó là cụm từ khoá gần như duy nhất mở khoá phương án này.
• On-Demand dành cho workload ngắn hạn/thất thường không chịu được gián đoạn; Reserved Instances dành cho workload chạy đều, ổn định, đủ dài để bõ cam kết 1–3 năm. Hỏi "job chạy bao lâu và có bị ngắt được không?" là phân biệt xong hai cái.
• Placement Groups (Cluster / Partition / Spread) là bài toán vị trí và độ trễ / khả năng chịu lỗi phần cứng, không phải bài toán giá. Gặp nó trong câu hỏi về cost thì gạt ngay.
• Cẩn thận phương án "hợp lý nhưng chưa tối ưu": On-Demand chạy được job này, chỉ là đắt hơn. Câu hỏi hỏi keep costs low, nên tiêu chí chấm là rẻ nhất trong số phương án vẫn đáp ứng yêu cầu, chứ không phải phương án an toàn nhất.

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

Đề mô tả một tình huống điều tra nội bộ: bạn nghi ngờ một số nhân viên đang cố truy cập các tệp trong S3 mà họ không có quyền, và bạn muốn xác minh điều đó.

Cụm từ quyết định đáp án nằm ở vế cuối: "without them noticing" — không được để họ phát hiện. Đây là ràng buộc phân biệt được các phương án gần giống nhau, vì nó loại thẳng mọi hành động làm thay đổi trải nghiệm truy cập của người dùng (siết quyền, đổi bucket policy). Cụm thứ hai đáng chú ý là "verify this is indeed the case" — nhiệm vụ ở đây là quan sát và chứng minh, không phải ngăn chặn hay đánh giá cấu hình. Nói cách khác: đề hỏi một cơ chế ghi nhận và phân tích request truy cập đối tượng trong S3 một cách thụ động.

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

B — Enable S3 Access Logs and analyze them using Athena.

S3 server access logging mặc định không bật. Khi bật, S3 ghi nhật ký các request gửi tới bucket nguồn rồi giao sang một bucket đích do bạn chọn (bucket đích phải nằm cùng AWS Region với bucket nguồn và không được đặt default retention period).

Mỗi bản ghi trong server access log mô tả một request truy cập, kèm những trường trực tiếp trả lời câu hỏi của đề: ai gửi request (requester), tên bucket, thời điểm, hành động được yêu cầu, trạng thái phản hồi và mã lỗi nếu có. Chính cặp "response status + error code" là thứ cho phép bạn lọc ra những lần truy cập bị từ chối — tức bằng chứng cho việc nhân viên cố chạm vào tệp họ không có quyền.

Amazon Athena là dịch vụ truy vấn tương tác, cho phép chạy SQL chuẩn thẳng trên dữ liệu nằm trong S3. Athena serverless nên không phải dựng hay quản lý hạ tầng, và chỉ trả tiền theo truy vấn chạy. Vì access log vốn đã nằm sẵn trong một bucket S3, việc dùng Athena để lọc theo requester, theo mã lỗi, theo khoảng thời gian là chuyện làm ngay được.

Quan trọng nhất với ràng buộc của đề: bật logging và chạy truy vấn phân tích đều là hành động hoàn toàn ở phía sau, không đụng vào quyền hạn hay hành vi mà nhân viên nhìn thấy — nên họ không nhận ra mình đang bị theo dõi.

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

A — Restrict their IAM policies and look at CloudTrail logs. Đây là phương án gần đúng nhất và cũng là cái bẫy chính, vì nửa sau của nó (xem log) đúng hướng. Chỗ hỏng nằm ở nửa đầu: siết IAM policy là từ chối quyền truy cập S3 của họ, đúng thứ mà đề yêu cầu tránh. Người dùng sẽ lập tức thấy mình mất quyền, tức là "họ nhận ra" — vi phạm trực tiếp ràng buộc without them noticing. Một hành động thay đổi trạng thái quyền không bao giờ là cách quan sát thụ động.

C — Use AWS Config to define compliance rules on these users. AWS Config là dịch vụ để đánh giá, kiểm toán và thẩm định cấu hình của các tài nguyên AWS. Với Config, bạn xem được các thay đổi cấu hình, quan hệ giữa các tài nguyên, lịch sử cấu hình chi tiết, và mức độ tuân thủ so với quy định nội bộ — nó trả lời kiểu câu hỏi "tài nguyên này trông như thế nào tại thời điểm xyz?". Nhưng đó là góc nhìn cấu hình tài nguyên, không phải góc nhìn hành vi truy cập. Không thể dùng AWS Config để ghi lại thông tin ai đã truy cập vào S3.

D — Use a bucket policy. Bucket policy là công cụ cấp hoặc từ chối quyền ở mức bucket — nó điều khiển truy cập, chứ không ghi nhật ký truy cập. Không thể dùng bucket policy để log thông tin truy cập S3. Ngoài ra, nếu dùng nó theo hướng chặn thì lại rơi đúng vào lỗi của phương án A: người dùng thấy ngay sự thay đổi.

📌 Điểm cần nhớ

• Đọc kỹ ràng buộc dạng "without them noticing" hay "without disrupting users" — nó loại bỏ mọi phương án làm thay đổi quyền hoặc policy, và chỉ chừa lại các phương án quan sát.
• Phân biệt ba nhóm dịch vụ theo đúng vai trò: S3 server access logs ghi lại từng request tới object (requester, action, response status, error code); AWS Config theo dõi cấu hình và lịch sử cấu hình tài nguyên; IAM policy / bucket policy cấp hoặc từ chối quyền.
• Log của S3 nằm sẵn trong S3, nên Athena là cặp đôi tự nhiên để phân tích: SQL chuẩn, serverless, trả tiền theo truy vấn, hợp cho phân tích ad-hoc và điều tra bảo mật.
• S3 server access logging không bật mặc định; khi bật, bucket đích phải cùng Region với bucket nguồn. Câu hỏi kiểu "tôi muốn xem ai đã truy cập gì" luôn bắt đầu bằng việc bật logging trước, không có log thì không có gì để phân tích.

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

Đề mô tả một tình huống hybrid: đang có ổ NFS v3 tại on-premise, muốn thay nó bằng thứ tận dụng được dung lượng khổng lồ của Amazon S3, và muốn các tệp hay dùng được cache tại chỗ (locally cached on-premises).

Ba cụm từ quyết định đáp án, phải đọc đủ cả ba:

• "NFS v3" — giao thức truy cập là file protocol, không phải block. Cụm này loại ngay mọi phương án chỉ nói chuyện block/iSCSI.
• "leverage the huge capacity of Amazon S3" — kho lưu trữ đích bắt buộc là object storage trên S3, chứ không phải một dịch vụ lưu trữ khác của AWS.
• "locally cached on-premises" — thiết bị phải nằm tại chỗ và giữ bản sao cục bộ của tệp nóng, tức là phải có một gateway chạy on-premise, không phải một dịch vụ thuần trong cloud.

Chỉ phương án nào thoả đồng thời cả ba ràng buộc — giao thức file, backend là S3, có cache tại chỗ — mới đúng.

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

Đáp án là C — File Gateway.

File Gateway là một chế độ của AWS Storage Gateway, triển khai tại on-premise dưới dạng máy ảo hoặc thiết bị phần cứng. Nó xuất ra cho hệ thống nội bộ các share theo giao thức NFS hoặc SMB, nên ứng dụng đang gắn ổ NFS v3 chuyển sang dùng được mà gần như không phải sửa gì — đúng nghĩa "thay thế" ổ NFS cũ.

Điểm mấu chốt: mỗi tệp ghi qua share đó được lưu thành object trong Amazon S3, nên dung lượng khả dụng chính là dung lượng của S3. Đồng thời gateway giữ một local cache trên đĩa cục bộ, nên các tệp được truy cập thường xuyên đọc ra với độ trễ của mạng nội bộ chứ không phải mỗi lần đều đi qua Internet về S3. Đây chính là "commonly used files are locally cached" mà đề yêu cầu.

File Gateway phục vụ được cả ứng dụng on-premises lẫn ứng dụng chạy trên EC2 cần truy cập S3 theo giao thức file.

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

A — Volume Gateway: đây là phương án gần đúng nhất và cũng là bẫy chính. Nó đúng ở hai điểm — cũng là Storage Gateway, cũng triển khai on-premise, cũng có cơ chế cache cục bộ (chế độ cached volumes). Nhưng nó hỏng ở đúng cụm từ đầu tiên của đề: Volume Gateway trình bày ra block storage theo giao thức iSCSI, không phải file share NFS/SMB. Ứng dụng đang mount NFS v3 không nói chuyện được với một LUN iSCSI; muốn dùng thì phải format và quản lý filesystem ở phía client, tức là không còn là "thay thế ổ NFS" nữa. Ngoài ra bản sao trên cloud của Volume Gateway đi kèm dạng EBS Snapshot cho backup/DR, không phải dạng tệp nằm trên S3 để bạn khai thác trực tiếp.

B — EBS Drives: EBS là dịch vụ block storage gắn với EC2 bên trong AWS. Hai chỗ hỏng: nó không phải thứ mount được từ trung tâm dữ liệu on-premise qua NFS, và nó không dùng S3 làm nơi lưu trữ — vậy là trượt cả ràng buộc giao thức lẫn ràng buộc "leverage S3". Cũng không có khái niệm cache tại on-premise ở đây.

D — EFS: nghe hợp lý nhất về mặt giao thức vì EFS thật sự là file storage nói NFS. Nhưng nó hỏng ở ràng buộc thứ hai và thứ ba: EFS là một filesystem riêng, dữ liệu nằm trong chính EFS chứ không tận dụng dung lượng S3 — đề nói rõ muốn dựa vào S3. Và EFS là dịch vụ nằm trong cloud, được thiết kế cho các EC2 instance truy cập đồng thời; nó không cung cấp thiết bị cache tại on-premise cho tệp hay dùng. Chọn EFS là bỏ qua hai chữ "Amazon S3" và "locally cached" trong đề.

📌 Điểm cần nhớ

• Nhận diện Storage Gateway theo giao thức mà đề nêu: NFS/SMB → File Gateway; iSCSI/block/volume → Volume Gateway. Đây là cách phân biệt nhanh và hầu như luôn đúng trong đề thi.
• Cụm "leverage S3" hoặc "lưu thành object trên S3" loại thẳng EBS và EFS — cả hai đều là kho lưu trữ độc lập, không đặt dữ liệu lên S3.
• Từ khoá "on-premises" + "local cache" báo hiệu cần một thiết bị gateway đặt tại chỗ; dịch vụ thuần cloud như EFS không đáp ứng được vế này.
• Volume Gateway và File Gateway giống nhau ở phần "hybrid + cache", nên đừng dừng ở đó — luôn đọc tiếp xem đề yêu cầu file hay block rồi mới chọn.