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

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

Công ty lưu toàn bộ dữ liệu trên Amazon EFS, được nhiều ứng dụng chạy trên EC2 truy cập. Chính sách bảo mật mới bắt buộc mã hoá toàn bộ dữ liệu ở trạng thái nghỉ (data-at-rest). Câu hỏi: làm sao enforce việc tạo file system EFS có mã hoá at-rest? Chọn hai.

Cụm từ quyết định là "enforce the creation" — bắt buộc, ngăn chặn ngay từ lúc tạo. Đây không phải câu hỏi "làm sao biết ai đã tạo file system chưa mã hoá", cũng không phải "làm sao mã hoá dữ liệu". Nó hỏi cơ chế phòng ngừa (preventive), tức là chặn hành động CreateFileSystem không mã hoá trước khi nó xảy ra. Chỉ có tầng quyền IAM/Organizations mới làm được điều đó; mọi thứ chạy sau khi tài nguyên đã tồn tại đều là phát hiện (detective), không phải enforce.

Cụm thứ hai đáng chú ý là "data-at-rest", phân biệt với in-transit — nên trọng tâm là tham số mã hoá lúc tạo file system, không phải TLS khi mount.

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

C — dùng condition key elasticfilesystem:Encrypted trong IAM identity-based policy. EFS cung cấp một condition key kiểu Boolean cho biết file system đang được tạo là mã hoá hay không. Gắn key này vào action elasticfilesystem:CreateFileSystem cùng với Effect Allow hoặc Deny, bạn viết được policy kiểu "chỉ cho phép tạo khi Encrypted là true" (hoặc "từ chối khi false"). Đây là chốt chặn ngay tại thời điểm gọi API: request không mã hoá bị trả về AccessDenied, file system không mã hoá không bao giờ tồn tại.

E — dùng Service Control Policies (SCPs) trong AWS Organizations. SCP là loại organization policy đặt trần quyền tối đa cho mọi account thành viên, kể cả root user của account đó. Nếu SCP không cho phép (hoặc explicitly deny) một action, thì dù IAM policy trong account có cấp quyền, user/role vẫn không thực hiện được. Nhờ vậy SCP áp luật mã hoá EFS một lần cho toàn tổ chức, không phụ thuộc vào việc từng account có nhớ gắn IAM policy hay không. Đây chính là mảnh ghép mà C còn thiếu: C phải được gắn đúng vào từng identity, còn E phủ toàn bộ.

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

A — "mã hoá at-rest bật mặc định khi tạo bằng AWS CLI, nên bắt buộc dùng CLI". Sai ở phần tiền đề: mã hoá at-rest không được bật mặc định khi tạo file system qua AWS CLI. Ngoài ra, ngay cả khi tiền đề đúng thì cách này vẫn không phải enforce — "bắt buộc mọi người dùng CLI" là quy ước con người, không có cơ chế kỹ thuật nào chặn ai đó mở console hay gọi API trực tiếp.

D — tương tự A nhưng với AWS SDKs. Cũng sai tiền đề: tạo file system qua SDK hoặc gọi API trực tiếp không tự bật mã hoá. Và cũng mắc đúng lỗi logic như A: không thể enforce bằng cách "quy định dùng công cụ nào", vì bản thân việc chọn công cụ không kiểm soát được.

B — dùng AWS Config. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. AWS Config rules và conformance packs đánh giá cấu hình tài nguyên so với luật bạn đặt, chạy định kỳ hoặc khi phát hiện thay đổi cấu hình, rồi báo tài nguyên nào compliant / non-compliant. Vấn đề: nó đánh giá sau khi tài nguyên đã được tạo. Config không chặn user thực hiện hành động không tuân thủ, cũng không đảm bảo tài nguyên sẽ compliant. Với đề bài yêu cầu enforce, Config chỉ cho bạn biết mình đã vi phạm — dữ liệu vẫn nằm không mã hoá trong khoảng thời gian giữa lúc tạo và lúc phát hiện.

📌 Điểm cần nhớ

• Phân biệt preventive và detective: IAM policy và SCP chặn hành động ngay tại API call; AWS Config chỉ phát hiện và báo cáo vi phạm sau khi tài nguyên đã tồn tại. Đề hỏi "enforce"/"prevent" thì loại Config; hỏi "audit"/"detect"/"report compliance" thì mới chọn Config.
• EFS có condition key elasticfilesystem:Encrypted (Boolean) dùng kèm action elasticfilesystem:CreateFileSystem — đây là cách chuẩn để bắt buộc mã hoá at-rest ở tầng IAM.
• SCP đặt trần quyền cho toàn organization, áp lên mọi IAM user và role trong account thành viên kể cả root user của account đó. IAM policy cấp quyền nhưng SCP không cho thì kết quả vẫn là từ chối. Cần luật áp cho nhiều account → nghĩ tới SCP.
• Cảnh giác với các phương án dạng "X được bật mặc định, nên hãy bắt buộc dùng X". Mã hoá at-rest của EFS không mặc định bật khi tạo qua CLI, SDK hay API — và "bắt buộc mọi người dùng một công cụ" chưa bao giờ là cơ chế enforce.

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

Tình huống: một EBS volume đã bị xoá vì doanh nghiệp không dùng nữa, nhưng AWS Config rule vẫn hiển thị volume đó ở trạng thái compliant. Đề hỏi hai thứ: nguyên nhân của hành vi này và cách tránh nhầm lẫn về sau.

Cụm từ quyết định nằm ở chỗ tưởng như vô hại: "the volume was no longer needed" kết hợp với việc AWS Config vẫn còn thấy tài nguyên. Nghĩa là thao tác xoá đã thành công (không có lỗi), nhưng AWS Config không nhận được tín hiệu về việc xoá đó. Đây chính là mấu chốt phân biệt các phương án: cùng một kết quả "volume biến mất khỏi tài khoản", nhưng cách nó biến mất quyết định AWS Config có ghi nhận được hay không.

AWS Config theo dõi thay đổi tài nguyên dựa trên các lời gọi API được ghi nhận. Vậy nên câu hỏi thực chất là: con đường xoá nào không phát ra lời gọi DeleteVolume?

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

Đáp án D — EBS volume bị xoá thông qua lời gọi TerminateInstances sẽ còn hiển thị một thời gian trên AWS Config console.

Khi bạn terminate một EC2 instance, mỗi EBS volume đang gắn vào instance đó được xử lý theo thuộc tính DeleteOnTermination. Volume nào có DeleteOnTermination = true thì Amazon EC2 tự xoá volume đó — nhưng EC2 không phát ra lời gọi DeleteVolume khi làm việc này.

Đó chính là chỗ hỏng. AWS Config dùng DeleteVolume làm trigger cho rule; không có lời gọi đó thì thay đổi cấu hình của volume không được ghi nhận, và volume tiếp tục nằm trong kết quả đánh giá với trạng thái compliant (hoặc noncompliant) như thể nó vẫn tồn tại.

Phần "cách tránh nhầm lẫn" nằm ở cơ chế tự chữa: AWS Config chạy một lượt baseline định kỳ để rà các configuration item có trạng thái ResourceDeleted, và sau lượt rà đó rule sẽ loại các EBS volume đã xoá khỏi kết quả đánh giá. Vì vậy đề mới dùng chữ "for some time" — đây là độ trễ có giới hạn, không phải lỗi vĩnh viễn.

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

A — EBS volume bị xoá bằng DeleteVolume API vẫn còn hiển thị một thời gian. Đây là phương án gần đúng nhất, và nó sai vì nói ngược đúng cơ chế của đáp án D. Khi xoá bằng DeleteVolume, AWS Config sẽ gọi DescribeVolumes lên volume đó; lời gọi này trả về mã lỗi InvalidVolume.NotFound, và volume được gỡ ngay khỏi danh sách tài nguyên trong AWS Config. Cấu hình cập nhật của volume được ghi lại thành một configuration item với trạng thái ResourceDeleted rồi chuyển vào S3 bucket. Nói cách khác, đường xoá tường minh bằng DeleteVolume là đường hoạt động đúng — nó không gây ra hiện tượng trong đề.

C — Thuộc tính DeleteOnTermination được đặt false nên volume vẫn còn sống. Phương án này lấy đúng thuật ngữ có liên quan nhưng lắp sai vào tình huống. Đúng là khi instance terminate, giá trị DeleteOnTermination của từng EBS volume đang gắn quyết định giữ lại hay xoá volume. Nhưng đề đã nói rõ volume đã bị xoá; nếu DeleteOnTermination = false thì volume còn nguyên và AWS Config hiển thị nó là hoàn toàn chính xác, chẳng có gì để "fix". Ngoài ra, bật hay tắt cờ này không có nghĩa là volume không thể bị xoá bằng cách khác. Phương án C giải thích một hiện tượng không tồn tại trong đề.

B — Volume không được xoá đúng cách, có thể do vấn đề permission. Sai ở logic nhân quả. Nếu thiếu quyền, thao tác xoá EBS volume sẽ không thành công và người thực hiện nhận được lỗi ngay. Đề mô tả một thao tác xoá đã diễn ra trót lọt, không có lỗi nào được nhắc tới — vậy nên đây không phải chuyện permission. Đây là loại phương án "đổ lỗi cho IAM" hay xuất hiện trong đề thi; hãy kiểm tra xem thao tác có báo lỗi hay không trước khi tin vào nó.

📌 Điểm cần nhớ

• AWS Config phát hiện thay đổi qua lời gọi API. Tài nguyên biến mất mà không có lời gọi API tương ứng thì Config không biết — nó vẫn báo trạng thái cũ. Đây là mẫu suy luận dùng lại được cho nhiều câu hỏi về Config.
• TerminateInstances xoá EBS volume mà không phát DeleteVolume. Đây là ngoại lệ cụ thể cần nhớ: EC2 dọn volume theo DeleteOnTermination bằng đường nội bộ, không đi qua lời gọi DeleteVolume mà AWS Config đang lắng nghe.
• Xoá tường minh bằng DeleteVolume thì Config cập nhật ngay: DescribeVolumes trả InvalidVolume.NotFound, tài nguyên bị gỡ khỏi danh sách và sinh configuration item trạng thái ResourceDeleted.
• AWS Config có lượt baseline định kỳ rà các configuration item ResourceDeleted và dọn chúng khỏi kết quả đánh giá — nên hiện tượng này là độ trễ tạm thời, không phải sai lệch vĩnh viễn.
• Khi một phương án quy nguyên nhân về permission, hãy đối chiếu với mô tả trong đề: thao tác thất bại vì thiếu quyền luôn kèm lỗi, còn đề mô tả thao tác thành công thì phương án đó bị loại.

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

Một công ty dịch vụ tài chính dùng AWS CloudTrail để ghi lại hoạt động của người dùng trên các tài nguyên AWS. Đơn vị kiểm toán đặt câu hỏi về tính tin cậy của log, và yêu cầu được nêu ra là: bảo vệ log khỏi bị sửa đổi (secure these logs from being tampered).

Cụm từ quyết định là "from being tampered" kết hợp với "An audit firm has raised several security-specific questions". Bối cảnh kiểm toán có nghĩa là thứ cần là bằng chứng chứng minh được rằng file log sau khi CloudTrail giao tới S3 có bị sửa, bị xoá hay còn nguyên vẹn — tức là integrity validation, không phải chỉ là giữ nhiều bản sao hay siết quyền xoá. Ba phương án còn lại đều xoay quanh việc hạn chế hoặc phục hồi thao tác xoá trên S3, chỉ có một phương án nói tới việc phát hiện được sự thay đổi.

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

A — Use CloudTrail log file integrity to keep the logs tamper-proof.

CloudTrail có tính năng log file integrity validation, sinh ra chính xác cho nhu cầu này. Cách nó hoạt động:

• Khi bật, CloudTrail tạo một hash (SHA-256) cho mỗi file log mà nó giao tới bucket S3.
• Mỗi giờ, CloudTrail tạo thêm một digest file tham chiếu tới các file log của giờ vừa qua và chứa hash của từng file đó.
• Digest file được ký số bằng private key của một cặp khoá (SHA-256 with RSA); CloudTrail dùng cặp khoá riêng cho mỗi region. Bạn dùng public key tương ứng để xác thực digest file.
• Mỗi digest file còn chứa chữ ký số của digest file trước đó, tạo thành một chuỗi liên kết — sửa hay xoá một mắt xích là phá vỡ cả chuỗi.

Nhờ vậy, việc sửa, xoá hoặc giả mạo file log CloudTrail mà không bị phát hiện là bất khả thi về mặt tính toán. Digest file được giao vào cùng bucket với log nhưng nằm ở thư mục tách riêng, cho phép áp chính sách bảo mật chặt hơn cho phần digest, đồng thời các hệ thống xử lý log sẵn có vẫn chạy bình thường không cần sửa gì.

Đây chính là câu trả lời "recommended way" mà đề hỏi: một tính năng có sẵn của chính CloudTrail, đo may cho đúng bài toán chứng minh tính toàn vẹn của log trước kiểm toán viên.

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

B — Use Amazon S3 MFA Delete to know the delete operations performed by any user on the logs stored in S3 buckets. MFA Delete là tính năng thật, nhưng làm việc khác. Khi bucket bật versioning kèm MFA Delete, chủ bucket phải gửi kèm header x-amz-mfa trong request để xoá vĩnh viễn một object version hoặc đổi trạng thái versioning của bucket. Tức là nó dựng thêm một rào cản cho thao tác xoá — nó không cho bạn "biết ai đã xoá" như phương án diễn đạt, và quan trọng hơn, nó không nói được gì về việc nội dung file log có bị sửa hay không. Đây là phương án gần đúng nhất về mặt "chống phá hoại log", nhưng nó chặn/hạn chế hành vi chứ không cung cấp bằng chứng toàn vẹn cho kiểm toán viên.

C — Use Amazon S3 Versioning to keep all versions of the file created. Versioning giữ lại mọi phiên bản của một object, nên nếu ai đó ghi đè file log, bạn còn bản cũ để quay lại. Chỗ hỏng: versioning chỉ cho bạn lưu trữ, không cho bạn xác minh. Không có hash, không có chữ ký số, nên không có cách nào chứng minh bản nào là bản gốc do CloudTrail giao. CloudTrail log file integrity mới là giải pháp làm riêng cho yêu cầu này.

D — Use KMS logfile security keys to keep the CloudTrail logs secure and tamper-proof. "KMS logfile security keys" không phải là một tính năng có thật — đây là phương án bịa, đưa vào làm distractor. KMS thật sự có vai trò với CloudTrail, nhưng là để mã hoá log bằng SSE-KMS (bảo vệ tính bí mật), chứ không có thứ gọi là "logfile security key" để chứng minh tính toàn vẹn. Nghe hợp lý vì có ghép chữ "KMS" với "tamper-proof", nhưng tên tính năng là dấu hiệu nhận ra ngay.

📌 Điểm cần nhớ

• Phân biệt ba nhóm mục tiêu khi bảo vệ log: confidentiality (mã hoá — SSE-KMS), availability/khôi phục (S3 Versioning), và integrity/chứng minh không bị sửa (CloudTrail log file integrity validation). Đề hỏi "tamper-proof" hoặc có bối cảnh audit thì hướng về nhóm thứ ba.
• Log file integrity validation dùng SHA-256 để hash và SHA-256 with RSA để ký; digest file sinh theo giờ, nằm cùng bucket nhưng khác thư mục, và mỗi digest chứa chữ ký của digest trước — chính chuỗi liên kết này khiến việc sửa lén bị lộ.
• MFA Delete gắn với versioning và chỉ áp cho việc xoá vĩnh viễn version hoặc đổi trạng thái versioning; nó là biện pháp kiểm soát thao tác xoá, không phải cơ chế audit hay phát hiện sửa đổi nội dung.
• Gặp tên tính năng lạ kiểu "KMS logfile security keys" thì cảnh giác: các đề AWS thường cài distractor bằng cách ghép tên dịch vụ có thật với một tính năng không tồn tại.

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

Đề mô tả một AWS Storage Gateway nối trung tâm dữ liệu on-premises với AWS Cloud và gateway này đã hỏng (malfunctioning). Câu hỏi: đâu là best practice để khôi phục dữ liệu (recover data) từ gateway — chọn hai.

Cụm từ quyết định là "recover data from the Gateway", chứ không phải "recover the gateway VM". Hai vế này nghe rất giống nhau nhưng dẫn tới hai nhóm phương án khác hẳn: một nhóm nói về việc lấy lại dữ liệu đã được đẩy lên AWS hoặc còn nằm trên đĩa cục bộ, nhóm kia nói về việc dựng lại chính máy ảo gateway từ ảnh chụp. Cụm thứ hai cần chú ý là "best practices" — tức cách làm mà Storage Gateway thực sự hỗ trợ, chứ không phải cách nghe hợp lý theo thói quen quản trị máy ảo.

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

A — For stored volumes gateways, you can recover data from your most recent Amazon EBS snapshot of the volume. Khi gateway hoặc VM hỏng, dữ liệu đã upload lên AWS vẫn còn nguyên trong Amazon S3 dưới dạng volume của Storage Gateway. Cách lấy lại phụ thuộc loại gateway: với cached volumes thì phục hồi từ recovery snapshot, với stored volumes thì phục hồi từ EBS snapshot gần nhất của volume đó, còn với tape gateway thì phục hồi một hoặc nhiều tape từ recovery point sang một tape gateway mới. Phương án A chính là nhánh dành cho stored volumes.

D — If your file system gets corrupted, you can use the fsck command to repair it. Đây là nhánh xử lý khi bản thân file system trên đĩa bị hỏng. Chạy fsck để kiểm tra và sửa lỗi file system; nếu sửa được thì có thể tiếp tục khôi phục dữ liệu từ các volume nằm trên file system đó. Đây là bước được AWS nêu trong hướng dẫn recover data from gateway.

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

B — Recover the failed Gateway VM from your Amazon EC2 AMI. Nghe rất hợp lý vì gateway có thể chạy như một EC2 instance, nhưng Storage Gateway không hỗ trợ khôi phục gateway VM từ AMI. Khi VM gateway hỏng, quy trình đúng là kích hoạt một gateway mới rồi khôi phục dữ liệu sang gateway đó theo hướng dẫn của AWS — chứ không phải dựng lại VM cũ.

E — Recover the failed Gateway VM from a snapshot created by your hypervisor. Hỏng vì đúng lý do như B, chỉ khác ở chỗ ảnh chụp đến từ hypervisor tại chỗ (VMware, Hyper-V, KVM) thay vì AMI. Đây là phương án bẫy nặng nhất với người quen quản trị ảo hoá: thói quen "VM hỏng thì rollback snapshot" không áp dụng được ở đây. Storage Gateway cũng không hỗ trợ cách này. Ngoài ra cả B lẫn E đều lệch trọng tâm câu hỏi: đề hỏi khôi phục dữ liệu, còn hai phương án này nói về khôi phục máy ảo.

C — If the status of your volume is IRRECOVERABLE, you can no longer recover data from this volume. Đây là phương án gần đúng nhất và cũng dễ mắc nhất, vì chính chữ "irrecoverable" gợi ý là hết cứu. Nhưng phát biểu này quá tuyệt đối: trạng thái IRRECOVERABLE nghĩa là volume đó không dùng tiếp được nữa, không có nghĩa là dữ liệu mất hẳn. Với stored volumes, vẫn lấy được dữ liệu sang một volume mới bằng quy trình: tạo volume mới từ chính đĩa đã dùng để tạo volume irrecoverable, chọn preserve existing data khi tạo, xoá các snapshot job đang chờ của volume cũ, rồi xoá volume irrecoverable khỏi gateway. Vì vẫn còn đường khôi phục dữ liệu nên C sai.

📌 Điểm cần nhớ

• Phân biệt rõ recover data với recover the gateway VM. Storage Gateway không hỗ trợ dựng lại VM gateway từ AMI hay từ hypervisor snapshot; VM hỏng thì activate gateway mới rồi khôi phục dữ liệu sang đó.
• Đường khôi phục dữ liệu khác nhau theo loại gateway: cached volumes → recovery snapshot; stored volumes → EBS snapshot gần nhất; tape gateway → tape từ recovery point sang tape gateway mới.
• Trạng thái IRRECOVERABLE nói về volume, không nói về dữ liệu. Với stored volumes vẫn tạo được volume mới từ đúng đĩa cũ và giữ lại dữ liệu đang có.
• File system hỏng thì dùng fsck để kiểm tra và sửa trước, sửa được thì khôi phục tiếp dữ liệu từ các volume trên file system đó.
• Mẹo chung với dạng câu này: phương án chứa từ tuyệt đối kiểu "no longer", "never", "always" thường sai, vì tài liệu AWS hầu như luôn còn một quy trình dự phòng.

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

Đội phát triển muốn thêm alternate domain name (còn gọi là CNAME) cho một CloudFront distribution, để link trong ứng dụng dùng tên miền của công ty thay vì tên miền *.cloudfront.net mà CloudFront tự cấp.

Cụm từ quyết định đáp án là "mandatory steps" — bước bắt buộc, và "Select two". Đề không hỏi "cách nào tốt nhất" hay "cách nào tối ưu chi phí", mà hỏi điều kiện tiên quyết: thứ gì phải có sẵn trước khi bạn được phép gán alternate domain name vào distribution. Đây chính là cái phân biệt các phương án, vì nhiều lựa chọn còn lại đều là những thứ có liên quan tới CloudFront + HTTPS + tên miền, nhưng không phải điều kiện bắt buộc.

Muốn dùng tên miền riêng trên CloudFront thì logic rất đơn giản: bạn phải sở hữu tên miền đó, và phải chứng minh với CloudFront rằng bạn được phép dùng nó. Hai vế đó tương ứng đúng hai đáp án.

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

E — Register the domain name with Route 53 or another domain registrar

Không thể khai một tên miền mà mình không đăng ký. Alternate domain name chỉ có ý nghĩa khi bạn kiểm soát được bản ghi DNS để trỏ tên miền đó về distribution. Lưu ý đề viết "Route 53 or another domain registrar" — không bắt buộc phải dùng Route 53, registrar nào cũng được; điều bắt buộc là tên miền phải thuộc về bạn.

B — Get an SSL/TLS certificate from an authorized certificate authority (CA) that covers the domain name

CloudFront yêu cầu gắn một certificate phủ tên miền đó vào distribution, và certificate này đóng vai trò bằng chứng ủy quyền: nó xác nhận bạn thật sự được phép dùng tên miền, chứ không phải cướp tên miền của người khác. Certificate phải đến từ một CA công cộng được tin cậy (qua ACM hoặc import vào ACM/IAM), vì người dùng trên Internet mới là bên phải tin certificate này.

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

A — Configure an AWS Global Accelerator to route to different registered domain names Đây là distractor thuần túy. Global Accelerator là dịch vụ mạng cấp static IP làm điểm vào cố định, giúp cải thiện tính sẵn sàng và hiệu năng cho ứng dụng toàn cầu bằng cách định tuyến qua mạng lưới AWS. Nó không tham gia vào việc gán alternate domain name cho một CloudFront distribution.

C — Register a private certificate with AWS Certificate Manager (ACM) that covers the domain name Đây là phương án gần đúng nhất và cũng nguy hiểm nhất, vì nó cũng nói về ACM và cũng phủ đúng tên miền. Chỗ hỏng nằm ở đúng một chữ: private. Private certificate dùng để định danh tài nguyên bên trong một tổ chức — ứng dụng, dịch vụ, thiết bị, người dùng nội bộ — và chỉ được tin cậy bởi những client đã cài root CA nội bộ. Ứng dụng sau CloudFront thì được truy cập từ Internet, trình duyệt của khách vãng lai không hề biết CA nội bộ của công ty, nên certificate loại này sẽ không được chấp nhận. Phải là public certificate từ CA được tin cậy rộng rãi.

D — Use Server Name Indication (SNI) to authorize the SSL/TLS certificate for your domain name Cũng là phương án gần đúng, vì SNI thật sự xuất hiện trong quy trình cấu hình HTTPS với alternate domain name. Nhưng động từ trong câu sai: SNI không authorize bất cứ certificate nào. SNI là một phần mở rộng của giao thức TLS, cho phép client báo tên miền nó muốn kết nối ngay trong lúc bắt tay, nhờ đó CloudFront biết trả certificate nào khi nhiều tên miền dùng chung một IP. Nó là cách phục vụ HTTPS (một lựa chọn cấu hình, đối lập với dedicated IP), chứ không phải bước bắt buộc để có quyền dùng tên miền. Việc "chứng minh bạn được phép dùng domain" nằm ở certificate, không nằm ở SNI.

📌 Điểm cần nhớ

• Alternate domain name (CNAME) trên CloudFront cần đúng hai điều kiện tiên quyết: sở hữu tên miền (đăng ký ở Route 53 hoặc registrar khác) và certificate công cộng phủ tên miền đó gắn vào distribution.
• Certificate ở đây có hai vai trò cùng lúc: mã hóa HTTPS và chứng minh quyền dùng tên miền — nên nó là bước bắt buộc chứ không phải tùy chọn.
• Private certificate (ACM Private CA) chỉ dùng cho nội bộ. Hễ thấy tài nguyên phục vụ người dùng trên Internet mà phương án nhắc tới "private certificate", gần như chắc chắn đó là bẫy.
• SNI là cách phục vụ HTTPS, không phải cách cấp quyền. Nó quyết định cách CloudFront chọn certificate khi nhiều tên miền chung IP, không thay thế được việc phải có certificate hợp lệ.
• Với câu hỏi có chữ "mandatory" hoặc "required", hãy loại ngay những phương án chỉ liên quan tới chủ đề (như SNI, Global Accelerator) mà không phải điều kiện tiên quyết.

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

Đề mô tả một internet-facing Network Load Balancer (NLB) đã bật cross-zone load balancing, đang trải trên ba Availability Zone. Đội phát triển muốn tắt bớt một AZ để chạy thử nghiệm, và câu hỏi là cách "tối ưu" để làm việc đó mà không gián đoạn luồng traffic.

Cụm từ quyết định nằm ở "disabling an AZ" đối với Network Load Balancer — chứ không phải Application Load Balancer, và cũng không phải "gỡ target ra khỏi vòng phục vụ". Với NLB, các AZ được chọn tại thời điểm tạo load balancer: mỗi AZ bật lên tương ứng với một subnet, và ELB dựng một load balancer node cùng một network interface trong subnet đó. Chi tiết cross-zone load balancing trong đề chỉ là bối cảnh, nó nói về cách phân phối traffic giữa các AZ đang bật, chứ không mở ra khả năng tắt một AZ.

Vì vậy câu này không hỏi "thao tác nào là đúng quy trình" mà hỏi ngầm một điều khác: thao tác này có tồn tại không. Đây là kiểu câu mà phương án đúng chính là câu phủ định.

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

B — You cannot disable Availability Zones for a Network Load Balancer after you create it.

Với NLB, bạn bật một hoặc nhiều AZ khi tạo load balancer; bật nhiều AZ làm tăng khả năng chịu lỗi của ứng dụng. Sau khi đã tạo, hành vi được hỗ trợ chỉ là thêm AZ mới, còn gỡ bỏ một AZ đang bật thì không làm được. Do đó không có "cách tối ưu để tắt AZ mà không gián đoạn traffic" — bản thân yêu cầu là thứ NLB không cho phép, và đó chính là điều câu hỏi muốn kiểm tra.

Điểm này khác với ALB (nơi tập AZ chỉnh sửa được sau khi tạo), nên đề cố tình ghi rõ "Network Load Balancer" ngay từ câu đầu.

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

A — Detach Elastic IP address của subnet ứng với AZ đó. Đây là phương án gần đúng nhất về mặt trực giác, vì với internet-facing NLB bạn có thể tuỳ chọn gán một Elastic IP cho mỗi subnet lúc tạo. Nhưng nó hỏng ở hai chỗ: (1) các Elastic IP này không thay đổi được sau khi load balancer đã tạo, nên không có thao tác "detach" để thực hiện; và (2) kể cả nếu đổi được địa chỉ IP thì đó cũng không phải là hành động "disable AZ" — AZ vẫn nằm trong tập AZ đã bật của load balancer.

C — Xoá hết target trong AZ đó. Phương án này nhầm lẫn giữa target và AZ đã bật của load balancer. Xoá hoặc gỡ đăng ký target chỉ khiến AZ đó không còn đích lành mạnh để nhận traffic, nhưng AZ vẫn nằm trong cấu hình NLB, node và network interface trong subnet vẫn tồn tại. Nói cách khác nó thay đổi nơi traffic đi tới, chứ không disable AZ như đề hỏi — và đây đúng là kiểu "gần đúng" hay bị chọn.

D — Xoá subnet đã chỉ định cho AZ đó. Khi bạn bật một AZ, bạn chỉ định một subnet thuộc AZ đó, và Elastic Load Balancing tạo load balancer node cùng network interface trong subnet ấy. Nhưng xoá subnet không disable AZ: quan hệ đi theo chiều ngược lại — cấu hình AZ của load balancer mới là thứ giữ subnet, không phải subnet quyết định AZ. Đây còn là thao tác phá hoại ở tầng VPC, trái hẳn yêu cầu "không làm gián đoạn traffic" của đề.

📌 Điểm cần nhớ

• Với Network Load Balancer, tập Availability Zone được cố định lúc tạo: thêm được AZ mới, không gỡ được AZ đang có. Đây là điểm khác biệt hay bị hỏi so với Application Load Balancer.
• Với internet-facing NLB, Elastic IP gán cho mỗi subnet không đổi được sau khi tạo — mọi phương án dựa trên việc "detach/đổi EIP" của một NLB đang chạy đều sai.
• Phân biệt rạch ròi ba tầng: AZ đã bật của load balancer ≠ subnet trong VPC ≠ target đã đăng ký. Tác động lên hai tầng dưới không thay đổi tầng trên.
• Cross-zone load balancing chỉ quyết định cách trải traffic giữa các AZ đang bật; nó không liên quan gì tới việc bật/tắt một AZ. Thấy cụm từ này trong đề thì đừng để nó dẫn hướng.
• Trong đề trắc nghiệm AWS, một phương án dạng phủ định ("bạn không thể làm điều đó") hoàn toàn có thể là đáp án đúng — đừng loại nó chỉ vì nó không mô tả một thao tác.

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

Một công ty dùng AWS Service Catalog để quản lý danh mục dịch vụ IT (máy ảo, server, phần mềm, database). Quản trị viên cần chia sẻ một tham chiếu (reference) tới products và portfolios của tài khoản này sang một AWS account khác, sao cho mọi bản sao của catalog luôn đồng bộ với nhau.

Cụm từ quyết định nằm ở hai chỗ, và phải đọc cùng nhau:

• "share a reference" — chia sẻ tham chiếu, không phải chia sẻ bản sao.
• "all copies of the catalog remain in sync" — sửa ở portfolio gốc thì bên nhận phải thấy ngay, không cần thao tác gì thêm.

Đây chính là ranh giới phân biệt các phương án: cả bốn phương án đều nói về việc "đưa catalog sang account khác", nhưng chỉ có một cách giữ được liên kết sống giữa bản gốc và bản bên nhận. Ba cách còn lại đều tạo ra bản sao độc lập — sau thời điểm sao chép, hai bên trôi dạt khỏi nhau.

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

A. Use account-to-account sharing.

Service Catalog cho phép admin chia sẻ portfolio sang account khác. Admin bên nhận import portfolio đó vào account của họ rồi phân phối products cho end-user trong account mình.

Điểm mấu chốt: portfolio được import không phải là một bản sao độc lập. Products và constraints trong đó giữ đồng bộ với mọi thay đổi bạn làm trên portfolio gốc:

• Thêm product hoặc constraint vào portfolio gốc → thay đổi lan sang tất cả các bản đã import.
• Gỡ một product khỏi portfolio gốc → product đó cũng biến mất khỏi portfolio đã import, kể cả khi nó đã được thêm vào các local portfolio bên nhận.
• Product đã được end-user launch trước khi bị gỡ thì provisioned product vẫn tiếp tục chạy, chỉ là không launch mới được nữa.

Admin bên nhận không sửa được products hay constraints — họ chỉ thêm được quyền IAM cho end-user của mình. Đúng nghĩa "tham chiếu", đúng nghĩa "remain in sync".

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

B. Use stack sets to deploy your catalog to another AWS account — đây là phương án gần đúng nhất, và nó thật sự tồn tại: stack sets là một trong các cách đưa catalog sang nhiều account cùng lúc, rất tiện khi cần triển khai diện rộng. Nhưng cơ chế của nó là deploy, tức là tạo ra thực thể riêng ở account đích chứ không phải import một tham chiếu. Đề yêu cầu "share a reference … remain in sync", mà muốn có tham chiếu đồng bộ thì phải dùng account-to-account sharing hoặc chia sẻ qua AWS Organizations. Chọn B là trả lời đúng câu hỏi "làm sao đưa catalog sang nhiều account", sai câu hỏi "làm sao giữ chúng đồng bộ".

C. Deploy a copy of the catalog into each of recipient AWS accounts — sai đúng ở chỗ đề nhấn mạnh. Khi tạo bản sao của catalog, bản đó không còn là tham chiếu tới portfolio gốc. Mọi thay đổi thực hiện sau thời điểm sao chép sẽ không lan tới bản đã copy — bên nhận đóng băng ở trạng thái lúc copy. Chưa kể phải lặp lại thao tác thủ công cho từng account mỗi lần catalog gốc đổi.

D. Catalogs cannot be shared but can be re-deployed or re-created in a different AWS account — sai ngay ở tiền đề. Catalog chia sẻ được giữa các AWS account; đó là tính năng có sẵn của Service Catalog. Phương án này phủ định một khả năng đang tồn tại, nên loại được ngay mà không cần xét vế sau.

📌 Điểm cần nhớ

• Trong Service Catalog, phân biệt rõ share/import (tham chiếu, đồng bộ hai chiều theo hướng gốc → bản import) với deploy/copy (thực thể độc lập, không đồng bộ). Từ khoá "in sync" trong đề gần như luôn trỏ về nhóm thứ nhất.
• Có nhiều cách đưa portfolio sang account khác: account-to-account sharing, chia sẻ qua AWS Organizations, và stack sets. Ba cách này không tương đương — chỉ hai cách đầu giữ được tham chiếu sống.
• Admin bên nhận chỉ được thêm quyền IAM cho end-user, không sửa được products/constraints của portfolio đã import. Đây là ranh giới quyền hay bị hỏi.
• Gỡ product khỏi portfolio gốc thì nó biến mất ở mọi bản import, nhưng provisioned product đã launch vẫn chạy tiếp — chỉ chặn launch mới.

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

Đề mô tả một công ty đang dùng AWS Systems Manager để quản lý tập trung toàn bộ EC2 instance và cấu hình tương ứng. Nhu cầu mới: cần một dịch vụ quản lý tập trung tương tự cho các máy chủ on-premises, trong đó có cả hệ thống Raspbian.

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

• "centrally managed service to maintain their on-premises servers" — bài toán là quản lý vận hành máy chủ (cấu hình, vá lỗi, kiểm kê phần mềm, chạy lệnh từ xa), không phải quản trị tài khoản hay đánh giá bảo mật.
• "on-premises" — máy nằm ngoài AWS, nên dịch vụ được chọn phải làm việc được với máy không phải EC2.
• "which also include Raspbian systems" — đây là ràng buộc phân biệt sắc nhất. Raspbian là hệ điều hành của Raspberry Pi, tức là thiết bị nhỏ ngoài trung tâm dữ liệu. Dịch vụ được chọn phải hỗ trợ luôn cả nhóm này chứ không chỉ Windows/Linux server thông thường.

Đề còn cài sẵn một cái bẫy tâm lý: vì công ty đã dùng Systems Manager cho EC2, người làm bài dễ nghĩ "chắc phải là dịch vụ khác thì mới thành câu hỏi", rồi đi tìm một cái tên lạ hơn. Nhưng đề chỉ hỏi "dịch vụ nào là lựa chọn đúng", không hề nói phải là dịch vụ mới.

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

A — AWS Systems Manager.

Systems Manager gom dữ liệu vận hành từ nhiều dịch vụ AWS và tự động hoá tác vụ trên các tài nguyên. Bạn nhóm tài nguyên theo ứng dụng, theo tầng của kiến trúc, hay theo môi trường production/development, rồi từ một nhóm xem được hoạt động API gần đây, thay đổi cấu hình, thông báo liên quan, cảnh báo vận hành, kiểm kê phần mềm và tình trạng tuân thủ vá lỗi.

Điểm mấu chốt khớp thẳng vào đề: Systems Manager quản lý được máy chủ chạy trên AWS, máy chủ trong trung tâm dữ liệu on-premises, và cả thiết bị như Raspberry Pi — qua cùng một giao diện. Cơ chế là một agent nhẹ cài trên máy/thiết bị, giao tiếp an toàn với dịch vụ để thực thi tác vụ quản lý. Nhờ agent này, phạm vi hỗ trợ phủ Windows, Linux và Raspbian.

Nói cách khác, công ty không cần một dịch vụ thứ hai — chỉ cần mở rộng chính Systems Manager đang dùng ra ngoài AWS bằng cách cài agent lên máy on-premises và thiết bị Raspbian. Đó vừa là câu trả lời đúng về mặt kỹ thuật, vừa là câu trả lời đúng về mặt vận hành: một giao diện duy nhất cho cả hai môi trường.

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

B — AWS Service Catalog. Đây là dịch vụ để tổ chức tạo và quản lý danh mục các dịch vụ CNTT đã được phê duyệt dùng trên AWS: image máy ảo, server, phần mềm, cơ sở dữ liệu, cho tới cả kiến trúc ứng dụng nhiều tầng. Nó giúp quản trị nhất quán và đáp ứng yêu cầu tuân thủ, đồng thời cho người dùng tự triển khai nhanh những thứ đã được duyệt. Đây là phương án dễ nhầm nhất vì nó cũng có chữ "centrally manage", nhưng cái nó quản lý tập trung là danh mục thứ được phép triển khai, không phải trạng thái cấu hình của máy chủ đang chạy — và trọng tâm là tài nguyên AWS, không phải máy Raspbian ngoài trung tâm dữ liệu.

C — Amazon Inspector. Là dịch vụ đánh giá bảo mật tự động, giúp cải thiện bảo mật và tuân thủ cho ứng dụng triển khai trên AWS. Nó rà quét ứng dụng để tìm mức độ phơi bày, lỗ hổng và những chỗ lệch khỏi best practice, rồi trả về danh sách phát hiện được xếp theo mức nghiêm trọng. Gần đúng ở chỗ nó cũng "nhìn vào máy" và cũng liên quan tới tuân thủ, nhưng nó chỉ báo cáo rủi ro bảo mật chứ không phải công cụ quản lý cấu hình, chạy lệnh hay kiểm kê phần mềm cho một đội máy chủ hỗn hợp.

D — AWS Control Tower. Là cách nhanh nhất để thiết lập và quản trị một môi trường AWS nhiều tài khoản an toàn. Nó dựng landing zone dựa trên blueprint best practice và áp guardrail chọn từ danh sách có sẵn; landing zone là nền nhiều tài khoản theo Well-Architected, còn guardrail là luật quản trị về bảo mật, tuân thủ và vận hành. Phạm vi của nó là ranh giới tài khoản và quản trị tổ chức, hoàn toàn không chạm tới hệ điều hành bên trong máy chủ — và càng không có gì để nói với một thiết bị Raspbian ngoài AWS.

📌 Điểm cần nhớ

• Thấy đề nhắc on-premises + Raspberry Pi/Raspbian + quản lý tập trung, gần như chắc chắn là AWS Systems Manager: phạm vi của nó là máy trên AWS, máy trong trung tâm dữ liệu và thiết bị nhỏ, thống nhất qua một giao diện nhờ agent nhẹ cài trên máy.
• Phân biệt bốn động từ để loại nhanh: Systems Manager vận hành máy chủ, Service Catalog phê duyệt và phát hành dịch vụ CNTT, Inspector đánh giá bảo mật, Control Tower quản trị nhiều tài khoản. Cả bốn đều mang chữ "quản lý" nên phải đọc kỹ đối tượng bị quản lý là gì.
• Đừng loại một phương án chỉ vì công ty trong đề đã dùng nó. Đề hỏi "dịch vụ nào đúng", không hỏi "dịch vụ nào mới" — mở rộng công cụ sẵn có ra môi trường lai thường chính là câu trả lời AWS muốn nghe.
• Với AWS, khả năng quản lý máy ngoài AWS thường đến từ agent cài trên máy đó. Nhớ cơ chế này để trả lời được cả những câu hỏi về vá lỗi, kiểm kê phần mềm hay chạy lệnh từ xa trên đội máy chủ hỗn hợp.

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

Một nhóm EC2 instances cùng mount chung một Amazon EFS file system. Yêu cầu của quản trị viên là: đếm xem có bao nhiêu EC2 instance đang kết nối tới file system trong một khoảng thời gian nhất định.

Cụm từ quyết định nằm ở chỗ "track the number of Amazon EC2 instances connected to a file system" — đề hỏi số lượng kết nối của client, không hỏi throughput, không hỏi hiệu năng, không hỏi khả năng burst. Đây thuần tuý là câu kiểm tra bạn có thuộc bảng metric của EFS trong CloudWatch hay không: metric nào đo client, chứ không phải metric nào đo dữ liệu.

Chi tiết thứ hai cũng đáng để ý: mỗi phương án đi kèm một statistic khác nhau (mean / sum / average). Vậy muốn chọn đúng phải đúng cả hai vế — đúng tên metric và đúng phép thống kê áp lên nó.

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

C — Calculate the sum of ClientConnections.

ClientConnections là metric mà EFS đẩy sang CloudWatch để đếm số kết nối từ client tới file system. Đúng như tài liệu AWS được dẫn trong lời giải: để theo dõi số EC2 instance đang kết nối tới một file system, hãy quan sát statistic Sum của metric ClientConnections.

Vế statistic không phải chuyện phụ. Sum cộng dồn các mẫu trong period, nên nếu period dài hơn một phút thì con số thu được là tổng của nhiều phút gộp lại — muốn ra số kết nối trung bình thì lấy Sum chia cho số phút trong period. Đó chính là cách AWS mô tả, và cũng là lý do phương án ghi rõ "sum" chứ không ghi "average".

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

A — mean của BurstCreditBalance. Metric này có thật, nhưng nó đo số burst credit còn lại của file system — tức khả năng file system còn "đẩy" throughput vượt mức nền được bao lâu nữa. Nó là chỉ số về hiệu năng và ngân sách throughput, hoàn toàn không mang thông tin về việc có bao nhiêu client đang mount. File system có một client hay một trăm client thì burst credit vẫn cứ tăng/giảm theo lượng I/O, nên không suy ngược ra số instance được.

B — sum của InstanceConnections. Đây là phương án bẫy nguy hiểm nhất, vì cái tên nghe đúng y hệt điều đề bài hỏi ("instance" + "connections") và statistic Sum thì lại đúng. Nhưng EFS không có metric nào tên InstanceConnections — nó được dựng ra làm distractor. Metric đúng nói về client, không nói về instance. Bài học: khi hai phương án khác nhau đúng ở tên metric, cái tên nghe hợp lý nhất chưa chắc là cái tồn tại.

D — average của TotalIOBytes. TotalIOBytes là metric có thật, nhưng nó đo khối lượng byte đọc/ghi trên file system, tức là dùng để tính throughput — quan sát statistic Sum theo ngày sẽ cho biết throughput đang ở mức nào. Phương án này sai cả hai vế cùng lúc: sai metric (đo dữ liệu chứ không đo kết nối) và sai cách dùng (nếu muốn xem throughput thì phải lấy Sum, không phải average). Lượng byte lớn có thể đến từ một client duy nhất đang chạy tác vụ nặng, nên không thể suy ra số kết nối.

📌 Điểm cần nhớ

• ClientConnections + statistic Sum là cặp chuẩn để đếm số client (EC2 instance) đang kết nối tới một EFS file system. Muốn ra trung bình cho period dài hơn một phút thì chia Sum cho số phút trong period.
• Phân nhóm metric của EFS theo thứ chúng đo: ClientConnections đo client, TotalIOBytes đo lượng dữ liệu / throughput, BurstCreditBalance đo ngân sách burst throughput. Câu hỏi hỏi về thứ nào thì lấy metric của nhóm đó.
• Đề thi AWS rất hay cài metric không tồn tại với cái tên trùng khớp từ khoá trong đề (ở đây là InstanceConnections cho câu hỏi về "instances connected"). Tên nghe càng khớp đề càng nên nghi ngờ.
• Một phương án CloudWatch chỉ đúng khi cả tên metric lẫn statistic đều đúng — luôn đọc kỹ phần Sum / Average / Maximum chứ đừng dừng lại ở tên metric.

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

Đề bài mô tả một công ty đang chạy các ứng dụng nền Windows trên AWS và cần một dịch vụ lưu trữ được quản lý (managed storage service). Ba ràng buộc được nêu thẳng trong câu hỏi, và phải thỏa cả ba cùng lúc:

• hỗ trợ NTFS — hệ thống tệp gốc của Windows;
• hỗ trợ giao thức SMB — giao thức chia sẻ tệp của Windows;
• tích hợp với Active Directory để xác thực.

Cụm từ quyết định là "Windows NTFS and SMB protocol" đi kèm "integrate with Active Directory". Đây chính là bộ ba đặc trưng của môi trường file server Windows. Chỉ cần một trong ba thứ này xuất hiện trong đề là đã loại được phần lớn các dịch vụ lưu trữ khác; cả ba cùng lúc thì gần như chỉ trỏ tới đúng một dịch vụ. Thêm vào đó, chữ "managed" loại bỏ hướng tự dựng hoặc hướng lai (hybrid) nối về hạ tầng tại chỗ.

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

A — Amazon FSx for Windows File Server.

Đây là dịch vụ file server Windows được AWS quản lý hoàn toàn, xây dựng trên chính Windows Server. Vì vậy nó không "mô phỏng" mà mang đúng các đặc tính mà ứng dụng Windows trông đợi từ một file system: định dạng NTFS, truy cập qua giao thức SMB, và tích hợp Microsoft Active Directory để xác thực người dùng cùng phân quyền theo ACL của Windows.

Đối chiếu từng ràng buộc của đề: NTFS ✔, SMB ✔, Active Directory ✔, được quản lý (kèm sao lưu tự động) ✔. Không có ràng buộc nào bị bỏ sót.

Đây cũng là dịch vụ AWS định vị cho các workload "lift-and-shift" — ERP, CRM, ứng dụng nội bộ, home directories (user shares), media workflows — tức đúng nhóm ứng dụng Windows cần chia sẻ tệp mà đề đang nói tới. Chia sẻ SMB này truy cập được từ cả instance Windows lẫn Linux, nhưng điểm mấu chốt vẫn là nó sinh ra cho môi trường Windows.

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

B — Amazon EFS. Đây là phương án dễ nhầm nhất, vì EFS cũng là dịch vụ lưu trữ tệp được quản lý, cũng chia sẻ được cho nhiều instance cùng lúc, cũng có ngữ nghĩa file system (khóa tệp, tính nhất quán). Nhưng nó hỏng ở đúng chỗ đề nhấn mạnh: EFS là file system dành cho môi trường Linux, dùng giao thức NFS chứ không phải SMB, không phải NTFS, và không hỗ trợ các instance Windows. Cấu trúc "giống về vai trò, sai về giao thức và hệ điều hành" là bẫy kinh điển của dạng câu này.

C — Amazon FSx for Lustre. Cùng họ FSx nên tên gọi rất dễ kéo người học chọn nhầm — nhưng "FSx" chỉ là họ dịch vụ file system, mỗi thành viên phục vụ một loại workload khác nhau. Lustre nhắm vào các tải tính toán nặng, xử lý nhanh: HPC, machine learning, EDA, xử lý media, với dữ liệu vào/ra gắn với Amazon S3. Nó là file system cho Linux, không cung cấp NTFS/SMB và không phải nơi để cắm Active Directory phục vụ ứng dụng Windows. Đề bài không hề nói tới hiệu năng tính toán hay HPC, nên tín hiệu để chọn Lustre hoàn toàn vắng mặt.

D — AWS Storage Gateway. Storage Gateway là nhóm dịch vụ hybrid cloud: nó cho hệ thống tại chỗ (on-premises) truy cập kho lưu trữ trên đám mây, phục vụ các tình huống như đưa bản sao lưu lên cloud, dùng file share tại chỗ nhưng dữ liệu nằm trên cloud, hoặc cho ứng dụng on-premises đọc dữ liệu ở AWS với độ trễ thấp. Hai vấn đề: (1) đề nói ứng dụng đang chạy trên AWS cloud, không có yếu tố on-premises nào để cần một gateway; (2) bản thân Storage Gateway không phải là dịch vụ lưu trữ, nó chỉ là cầu nối và dữ liệu thực sự nằm trên S3.

📌 Điểm cần nhớ

• NTFS + SMB + Active Directory là bộ ba từ khóa trỏ thẳng tới Amazon FSx for Windows File Server. Thấy đủ chúng trong đề thì gần như không cần cân nhắc thêm.
• EFS ≠ FSx for Windows. EFS phục vụ Linux qua NFS; câu hỏi nhắc tới Windows hay SMB là EFS bị loại, dù nó cũng là managed file storage.
• "FSx" không phải một dịch vụ duy nhất. Phải đọc tiếp phần sau tên: for Windows File Server dành cho ứng dụng Windows, for Lustre dành cho HPC/ML/xử lý media trên Linux.
• Storage Gateway thuộc nhóm hybrid, dùng khi đề nhắc tới hệ thống on-premises. Workload đã nằm sẵn trên AWS thì đây thường là phương án gây nhiễu.