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 bắt đầu chuyển hạ tầng on-premises lên AWS, và bước đầu là đưa các file workflow hằng ngày lên cloud. Có ba ràng buộc nằm ngay trong đề, và chúng quyết định toàn bộ đáp án:

1. "the files are accessible from the on-premises systems as well as AWS Cloud" — đây là cụm từ then chốt. Dữ liệu phải truy cập được từ cả hai phía cùng lúc, tức là bài toán hybrid storage, không phải bài toán "chép dữ liệu lên cloud rồi thôi".
2. "workflow files" — đơn vị dữ liệu là file, nên giao diện cần là file protocol (NFS/SMB), chứ không phải block device hay object API.
3. "fully managed service" — loại bỏ mọi phương án đòi công ty tự dựng và tự vận hành file server.

Cả bốn phương án đều là dịch vụ lưu trữ hợp lệ của AWS. Điểm phân biệt duy nhất là: cái nào vừa là file interface, vừa bắc cầu được sang on-premises.

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

A – File Gateway của AWS Storage Gateway.

AWS Storage Gateway là dịch vụ hybrid cloud storage: nó cho hệ thống on-premises truy cập kho lưu trữ trên AWS thông qua các giao thức lưu trữ tiêu chuẩn (NFS, SMB, iSCSI), nhờ vậy ứng dụng cũ không cần viết lại vẫn dùng được cloud storage.

Riêng File Gateway trình bày giao diện file trên nền Amazon S3: bucket S3 đã cấu hình sẽ xuất hiện dưới dạng NFS mount point hoặc SMB file share. Ứng dụng on-premises đọc/ghi file và thư mục như với một file server bình thường, còn gateway dịch các thao tác file đó thành request object trên S3. Kết quả là cùng một tập dữ liệu: on-premises thấy nó là file share, còn phía AWS Cloud thấy nó là object trong S3 — đúng yêu cầu "truy cập được từ cả hai phía".

Gateway còn cache dữ liệu hay dùng ngay tại on-premises để giảm độ trễ, và tối ưu đường truyền bằng cách chỉ gửi phần dữ liệu thay đổi kèm nén dữ liệu. Storage Gateway là dịch vụ managed của AWS, khớp với yêu cầu giảm gánh nặng vận hành.

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

B – Amazon S3. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì File Gateway thực chất lưu dữ liệu vào chính S3. Nhưng S3 đứng một mình chỉ cung cấp giao diện web service dạng object (API/SDK), không phải file share. Muốn hệ thống on-premises dùng được, ứng dụng phải được viết lại theo API của S3 — trong khi đề nói rõ cần dữ liệu accessible from the on-premises systems, tức là một cơ chế hybrid. S3 không tự nó bắc cầu đó; đúng chỗ hỏng của phương án này là thiếu lớp trình bày file cho phía on-premises.

C – Volume Gateway của AWS Storage Gateway. Phương án này đúng "họ" dịch vụ (vẫn là Storage Gateway, vẫn hybrid, vẫn managed) nên rất dễ chọn nhầm. Nhưng Volume Gateway cung cấp iSCSI target, tạo ra các block storage volume để mount như thiết bị iSCSI từ server on-premises hoặc EC2 (chạy ở chế độ cached hoặc stored). Đó là block storage, không phải file storage — không phù hợp với yêu cầu chia sẻ file workflow. Nó hỏng đúng ở tiêu chí thứ hai: sai loại giao diện dữ liệu.

D – Amazon EBS. EBS là dịch vụ block storage hiệu năng cao thiết kế để dùng cùng với Amazon EC2. Nó gắn vào instance trong AWS, không đóng vai trò kho dữ liệu hybrid mà hệ thống on-premises truy cập tới được. Vừa sai kiểu lưu trữ (block thay vì file), vừa không đáp ứng ràng buộc "truy cập từ cả hai phía".

📌 Điểm cần nhớ

• Thấy chữ on-premises + AWS Cloud cùng truy cập trong đề là tín hiệu của hybrid storage; một dịch vụ lưu trữ thuần cloud (S3, EBS) tự nó không đáp ứng được.
• Phân biệt hai loại gateway theo giao thức: File Gateway → NFS/SMB (file), lưu vào S3; Volume Gateway → iSCSI (block). Đề hỏi "file" thì chọn File Gateway, đề hỏi "volume/block device" thì chọn Volume Gateway.
• "S3" và "File Gateway" không loại trừ nhau: File Gateway chính là lớp giao diện file đặt trước S3. Khi đề yêu cầu ứng dụng cũ dùng được mà không phải viết lại, chọn gateway chứ không chọn S3 trần.
• Ràng buộc "fully managed" loại bỏ các hướng tự dựng file server; Storage Gateway là dịch vụ do AWS quản lý nên vẫn thoả tiêu chí này.

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

Đề mô tả một systems administrator muốn tạo chữ ký số (digital signature) để SSH vào các Amazon EC2 instance. Câu hỏi là: entity nào của AWS phục vụ được nhu cầu đó?

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

• "digital signature" — nghĩa là cần một cặp khoá bất đối xứng: private key ký, public key xác minh. Thứ này khác hẳn với "mật khẩu" hay "mã OTP".
• "SSH'ing into the EC2 instances" — đích đến là đăng nhập vào bên trong hệ điều hành của instance, không phải gọi AWS API hay đăng nhập AWS Management Console.

Đây chính là ràng buộc phân biệt các phương án: ba phương án còn lại đều là credential dùng để chứng thực với AWS (console hoặc API), còn đề hỏi credential để chứng thực với chính máy chủ EC2 qua giao thức SSH.

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

C — Key pairs.

Key pair gồm một public key và một private key. Bạn giữ private key và dùng nó để tạo digital signature; phía đối diện dùng public key tương ứng để xác minh chữ ký đó — đúng mô hình mà SSH hoạt động. Khi launch một EC2 instance, public key của key pair được đặt vào instance, còn private key nằm ở máy của bạn, nên lệnh ssh chứng minh danh tính bằng chữ ký chứ không gửi mật khẩu đi.

Vài điểm nữa từ tài liệu nguồn đáng nhớ: key pair trong AWS được dùng cho Amazon EC2 và Amazon CloudFront; AWS không tự cấp sẵn key pair cho tài khoản của bạn — bạn phải tạo, qua EC2 console, CLI hoặc API. So với việc dùng password, key pair là cách truy cập instance chắc chắn hơn.

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

A — Access keys. Đây là phương án dễ nhầm nhất vì nó cũng gồm hai phần (access key ID + secret access key) và cũng thực sự được dùng để "sign" request. Nhưng nó hỏng ở đúng chỗ đề nhấn mạnh: access key ký các request lập trình gửi tới AWS API (qua AWS CLI hoặc SDK) — tức là chứng thực với dịch vụ AWS. Nó hoàn toàn không tham gia vào phiên SSH tới hệ điều hành của instance.

B — Root user credentials. Là email và mật khẩu tạo ra tài khoản AWS, có toàn quyền trên mọi dịch vụ trong tài khoản đó. Root user có thể tạo ra access keys hay key pairs, nhưng bản thân credential của root không dùng trực tiếp để truy cập EC2 instance hay tạo digital signature. Nó là danh tính cấp tài khoản, không phải danh tính cấp hệ điều hành.

D — Multi-Factor Authentication (MFA). MFA là một lớp bảo vệ tăng cường, không phải một loại credential dùng để ký. Khi bật MFA, lúc đăng nhập AWS bạn phải nhập thêm mã xác thực từ thiết bị MFA bên cạnh username và password. Nó bảo vệ tài khoản AWS và các thiết lập/tài nguyên trong đó, chứ không sinh ra chữ ký số và không phải thứ SSH dùng để xác thực.

📌 Điểm cần nhớ

• Phân biệt theo đích chứng thực: key pair → vào bên trong EC2 instance (SSH); access keys → gọi AWS API/CLI; root credentials và MFA → đăng nhập tài khoản AWS.
• Thấy chữ "digital signature" cùng "SSH" trong cùng một câu thì gần như chắc chắn đang nói tới key pair (private key ký, public key xác minh).
• Access keys tuy cũng "ký request" nhưng chỉ ký request tới AWS services — đừng để chữ "sign" kéo bạn chọn nhầm.
• MFA là lớp bảo mật bổ sung, không bao giờ là câu trả lời cho câu hỏi "dùng gì để tạo chữ ký số" hay "dùng gì để đăng nhập vào instance".
• Key pair là thứ bạn phải tự tạo (EC2 console/CLI/API), AWS không cấp sẵn, và phạm vi dùng của nó trong AWS là EC2 và CloudFront.

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

Tình huống: một secret trong AWS Secrets Manager đã bị xoá, và khi team tạo lại secret cùng tên thì nhận lỗi You can't create this secret because a secret with this name is already scheduled for deletion.

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

• "scheduled for deletion" — thông báo lỗi nói rõ secret chưa biến mất hẳn, nó đang nằm trong recovery window. Tên của nó vẫn bị giữ chỗ trong Secrets Manager, nên mọi lệnh CreateSecret với tên đó đều bị từ chối.
• "The secret has to be created with the same name to avoid issues in their application" — đây là ràng buộc loại bỏ mọi phương án kiểu "chờ đi" hoặc "chịu thua". Ứng dụng đang tham chiếu đúng cái tên đó, nên câu trả lời phải là một hành động giải phóng tên ngay lập tức, không phải một lời giải thích tại sao không làm được.

Ghép hai điều kiện lại, câu hỏi thực chất là: làm cách nào xoá vĩnh viễn một secret đang trong recovery window để lấy lại tên?

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

Đáp án D: dùng AWS CLI gọi DeleteSecret kèm tham số ForceDeleteWithoutRecovery.

Khi xoá secret theo cách thông thường, Secrets Manager không xoá ngay mà đánh dấu nó scheduled for deletion và giữ trong một recovery window (mặc định bảy ngày) để có thể RestoreSecret nếu xoá nhầm. Trong suốt thời gian đó, tên secret vẫn bị chiếm — đó chính là nguyên nhân của thông báo lỗi trong đề.

ForceDeleteWithoutRecovery bỏ hẳn recovery window: secret bị xoá vĩnh viễn ngay, tên được giải phóng, và team tạo lại được secret cùng tên để ứng dụng chạy tiếp. Đây là con đường duy nhất trong bốn phương án thực sự thay đổi trạng thái của secret cũ.

Đánh đổi phải nhớ: secret xoá bằng tham số này không khôi phục lại được bằng bất kỳ cách nào. Đó là lý do AWS không đặt nó làm hành vi mặc định.

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

A — "Secrets Manager giữ recovery window bảy ngày, không thể tạo secret cùng tên trong thời gian đó." Đây là phương án gần đúng nhất và cũng là cái bẫy chính: nửa đầu của câu hoàn toàn chính xác, nó mô tả đúng cơ chế recovery window và đúng lý do sinh ra lỗi. Chỗ hỏng nằm ở nửa sau — câu này kết luận là "không thể", trong khi thực tế ForceDeleteWithoutRecovery qua CLI vẫn xoá được ngay. Một mô tả đúng về vấn đề không phải là câu trả lời cho câu hỏi "how will you recreate the secret". Đề yêu cầu cách làm, không yêu cầu chẩn đoán.

B — "Xoá secret là quy trình bất đồng bộ, đợi vài phút là xong." Đây là phương án bịa ra làm nhiễu. Thông báo lỗi nói scheduled for deletion — tức là một trạng thái có chủ đích, có thời hạn được đặt trước, chứ không phải độ trễ lan truyền vài phút. Chờ thêm vài phút không thay đổi được gì; secret vẫn nằm trong recovery window cho tới khi hết hạn hoặc bị xoá cưỡng bức.

C — "Dùng AWS Management Console xoá vĩnh viễn, xong rồi tạo lại tên cũ." Sai ở chỗ công cụ. Console không cho bỏ qua recovery window — thao tác xoá trên Console luôn đặt secret vào trạng thái scheduled for deletion. Nếu chỉ dùng Console thì team buộc phải chờ hết recovery window mới lấy lại được tên. Phương án này đúng về ý định (xoá vĩnh viễn rồi tạo lại) nhưng chọn sai đường đi, và chính sự khác biệt Console ↔ CLI mới là điều câu hỏi muốn kiểm tra.

📌 Điểm cần nhớ

• Xoá secret trong Secrets Manager là xoá mềm: secret vào trạng thái scheduled for deletion, tên vẫn bị chiếm cho tới khi hết recovery window, nên CreateSecret cùng tên sẽ lỗi.
• Muốn lấy lại tên ngay thì dùng DeleteSecret với ForceDeleteWithoutRecovery — chỉ có ở API/CLI, không có trên Console. Đổi lại là mất khả năng RestoreSecret.
• Nhiều câu AWS cố ý đặt một phương án mô tả đúng cơ chế nhưng kết luận "không làm được". Khi đề hỏi "how will you…", hãy chọn hành động, đừng chọn lời giải thích.
• Khi các phương án khác nhau ở công cụ (Console / CLI / SDK), hãy nghĩ ngay tới những tham số chỉ lộ ra ở tầng API — Console thường chỉ phơi bày phần hành vi an toàn, mặc định.

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

Công ty đã có sẵn Direct Connect giữa on-premises và AWS. Nhu cầu: ứng dụng chạy tại on-premises cần kéo dữ liệu khách hàng từ một S3 bucket. Câu hỏi là cách cấu hình đúng.

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

• "hosted on the on-premises infrastructure" — bên tiêu thụ dữ liệu nằm ngoài VPC. Mọi phương án dựa trên VPC endpoint lập tức gặp vấn đề, vì VPC endpoint là thứ chỉ có tác dụng bên trong VPC.
• "access the Amazon S3 bucket" — S3 là dịch vụ có public endpoint, tên miền của nó phân giải ra địa chỉ IP public, khác hẳn một EC2 instance nằm trong subnet riêng.

Ghép hai điều đó lại: cần một đường đi tới IP public của AWS mà không qua Internet công cộng. Trong Direct Connect, loại virtual interface làm được việc này là public VIF, không phải private VIF.

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

Đáp án đúng là C — tạo dedicated hoặc hosted connection, thiết lập cross-network connection, tạo public virtual interface, rồi cấu hình router đầu cuối để dùng với public VIF đó.

Cách này đúng vì:

• Public VIF sinh ra đúng để tới các public endpoint của AWS. Sau khi phiên BGP thiết lập xong, router Direct Connect quảng bá các public IP prefix của AWS về phía on-premises, trong đó có prefix của Amazon S3.
• Nhờ vậy, lưu lượng đi tới S3 được định tuyến qua public VIF trên đường Direct Connect — tức là đi trên kết nối riêng giữa data center và AWS, chứ không đi ra Internet.
• Không cần VPC endpoint cho S3 trong mô hình này, vì lưu lượng không hề đi xuyên qua VPC nào cả. Đây chính là điểm khiến C khác hẳn ba phương án còn lại: nó không cố nhét traffic vào một VPC mà ứng dụng vốn không nằm trong đó.

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

A — Truy cập thẳng S3 qua private VIF. Private VIF dùng để vào một Amazon VPC bằng địa chỉ IP private. S3 không nằm trong VPC của bạn và phân giải ra IP public, nên private VIF không có đường nào dẫn tới nó. Không thể truy cập S3 trực tiếp qua private VIF — đây là mấu chốt mà cả ba phương án sai đều vấp phải.

D — Tạo VPC gateway endpoint cho S3, rồi dùng private VIF. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì gateway endpoint đúng là loại endpoint dành cho S3 nên nửa đầu câu nghe rất hợp lý. Chỗ hỏng nằm ở nửa sau: kết nối qua VPC endpoint không mở rộng được ra ngoài phạm vi VPC. Endpoint chỉ phục vụ tài nguyên nằm trong chính VPC đó; máy chủ on-premises đi vào bằng private VIF vẫn không dùng được nó. Thêm nữa, S3 vẫn phân giải ra IP public ngay cả khi đã bật VPC endpoint cho S3, nên giả định "bật endpoint là traffic thành private, private VIF sẽ tới được" là sai từ gốc.

B — Tạo VPC interface endpoint cho S3, rồi dùng private VIF. Phương án này sai hai tầng. Tầng thứ nhất: theo cách phân loại mà câu hỏi dựa vào, truy cập S3 bucket dùng gateway endpoint chứ không phải interface endpoint — chọn sai ngay loại endpoint. Tầng thứ hai: kể cả bỏ qua chuyện đó, nó vẫn dính đúng lỗi của D — endpoint không vươn ra ngoài VPC, và S3 vẫn phân giải ra IP public. Nói cách khác, B sai theo mọi cách mà D sai, cộng thêm một lỗi riêng.

📌 Điểm cần nhớ

• Bên tiêu thụ nằm ở on-premises + đích là dịch vụ có public endpoint (như S3) → public VIF. Bên tiêu thụ cần vào tài nguyên private bên trong VPC → private VIF. Đây là tiêu chí phân loại nhanh nhất cho mọi câu hỏi Direct Connect.
• VPC endpoint (cả gateway lẫn interface) không mở rộng ra ngoài VPC. Thấy đề ghép "VPC endpoint" với một máy chủ on-premises là dấu hiệu phương án đó sai.
• Bật VPC endpoint cho S3 không làm S3 ngừng phân giải ra IP public. Đừng suy luận rằng có endpoint thì mọi đường đi tới S3 đều thành private.
• Public VIF vẫn là kết nối riêng, không phải Internet. Sau khi BGP lên, AWS quảng bá public prefix qua đường Direct Connect — nên "public" ở đây nói về loại địa chỉ đích, không nói về việc traffic đi ra Internet công cộng.

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

Một công ty phân tích dữ liệu muốn kết nối trung tâm dữ liệu tại chỗ (on-premises) với hệ thống trên AWS. Trong giai đoạn thí điểm, họ muốn đưa các tệp dữ liệu từ máy chủ on-premises vào AWS thông qua giao diện NFS.

Cụm từ quyết định nằm ở chính câu đó: "integrate data files ... via an NFS interface". Ở đây có hai ràng buộc chồng lên nhau:

• Đối tượng cần đưa lên là data files — dữ liệu ở mức tệp, không phải block, không phải băng từ ảo.
• Cách truy cập bắt buộc là NFS — một giao thức chia sẻ tệp qua mạng.

Từ khóa MOST efficient ở đây có nghĩa là: chọn dịch vụ được thiết kế sẵn cho đúng nhu cầu này, không phải dựng thêm hạ tầng rồi tự xoay xở. Vì vậy chỉ cần đối chiếu từng phương án với câu hỏi "dịch vụ này có phơi ra giao diện NFS cho máy chủ on-premises hay không?" là loại được ba phương án còn lại.

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

C — AWS Storage Gateway - File Gateway.

AWS Storage Gateway là dịch vụ lưu trữ lai (hybrid), cho phép ứng dụng on-premises truy cập vào kho lưu trữ trên cloud. Dịch vụ có ba kiểu gateway — File Gateway, Volume Gateway và Tape Gateway — và chúng khác nhau chính ở giao thức phơi ra phía on-premises.

File Gateway là kiểu duy nhất cung cấp giao diện dạng tệp: NFS hoặc SMB. Máy chủ on-premises mount điểm chia sẻ NFS như một thư mục mạng bình thường, ghi tệp vào đó, và File Gateway lưu các tệp ấy thành object trên Amazon S3. Gateway còn giữ cache cục bộ để dữ liệu vừa dùng được truy cập với độ trễ thấp.

Đúng với những gì đề đòi hỏi: tệp dữ liệu, giao diện NFS, không phải sửa ứng dụng đang chạy — chỉ mount thêm một share. Đó là lý do File Gateway là lựa chọn hiệu quả nhất cho tình huống này.

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

A — AWS Storage Gateway - Volume Gateway. Đây là phương án gần đúng nhất vì cùng thuộc họ Storage Gateway, và nhiều người chọn theo phản xạ "cần lưu trữ hybrid thì dùng Storage Gateway". Nhưng Volume Gateway phơi ra volume block dạng iSCSI, không phải NFS. Máy chủ nhìn thấy nó như một ổ đĩa thô, phải tự định dạng file system lên trên — hoàn toàn khác mô hình chia sẻ tệp qua mạng mà đề yêu cầu. Sai ở tầng giao thức, dù đúng họ dịch vụ.

B — AWS Site-to-Site VPN. Dịch vụ này tạo đường hầm IPSec mã hóa giữa mạng on-premises và Amazon VPC, tức là nó giải quyết bài toán kết nối mạng, chứ bản thân nó không lưu trữ gì và không cung cấp bất kỳ giao diện NFS nào. Site-to-Site VPN chỉ là ống dẫn — nó không "integrate data files" như đề hỏi. Phương án này đánh trúng vế "seamlessly integrate on-premises with AWS" trong câu mở đầu, nhưng bỏ qua ràng buộc thật sự là NFS.

D — AWS Storage Gateway - Tape Gateway. Tape Gateway mô phỏng thư viện băng từ ảo (VTL) để phần mềm sao lưu hiện có ghi "băng" lên cloud thay vì băng vật lý. Giao diện nó phơi ra là giao diện băng từ, không phải NFS, và mục đích là backup dài hạn/lưu trữ nguội chứ không phải cho ứng dụng đọc ghi tệp hằng ngày. Sai cả về giao thức lẫn về kịch bản sử dụng.

📌 Điểm cần nhớ

• Ba kiểu Storage Gateway phân biệt nhau bằng giao thức phía on-premises: File Gateway → NFS/SMB (object trên S3), Volume Gateway → iSCSI block, Tape Gateway → VTL cho phần mềm backup. Nhận ra giao thức trong đề là đủ để chọn đúng.
• Thấy NFS hoặc SMB trong đề kèm nhu cầu đẩy tệp lên AWS → nghĩ ngay tới File Gateway.
• Phân biệt dịch vụ kết nối mạng (Site-to-Site VPN, Direct Connect) với dịch vụ truy cập dữ liệu. VPN cho hai mạng nói chuyện được với nhau, nhưng không tự nó tạo ra một điểm mount tệp.
• Từ khóa MOST efficient thường ám chỉ dịch vụ được thiết kế đúng cho nhu cầu, không phải phương án ghép nhiều thành phần lại rồi tự dựng phần còn thiếu.

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

Bối cảnh: một lập trình viên lỡ tay tắt (shutdown) instance test, Team Lead quyết định bật termination protection cho toàn bộ instance. Nhiệm vụ của bạn là rà lại chính sách chấm dứt instance và xem nó có đáp ứng được yêu cầu không.

Câu hỏi thực chất là: những phát biểu nào đúng về termination policy của EC2 — chọn hai.

Cụm từ quyết định nằm ở chỗ đề nói "configure termination protection on all the instances". Chữ all là cái bẫy: ngân hàng instance trong thực tế không đồng nhất — có instance nằm trong Auto Scaling group, có instance là Spot Instance. Termination protection (DisableApiTermination) là một thuộc tính ở tầng EC2 API, và nó không phủ được hai trường hợp đó. Bốn trong năm phương án xoay quanh đúng một câu hỏi: DisableApiTermination chặn được cái gì và không chặn được cái gì.

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

B — Để ngăn instance thuộc Auto Scaling group bị chấm dứt khi scale in, hãy dùng instance protection. DisableApiTermination không ngăn được Amazon EC2 Auto Scaling chấm dứt instance. Auto Scaling hoạt động ở tầng riêng của nó, nên với instance nằm trong group bạn phải dùng đúng cơ chế của Auto Scaling thay vì termination protection của EC2:

• chống bị chấm dứt lúc scale in → instance protection;
• chống bị thay thế khi bị đánh dấu unhealthy → suspend tiến trình ReplaceUnhealthy;
• muốn quyết định instance nào bị chấm dứt trước → chọn termination policy của group.

C — Không thể bật termination protection cho Spot Instance. Spot Instance bị thu hồi khi giá Spot vượt quá mức bạn sẵn sàng trả, và việc thu hồi đó thuộc quyền của Spot service chứ không phải một lệnh terminate qua API mà bạn có thể chặn. Vì vậy termination protection đơn giản là không áp dụng được cho Spot. Cách xử lý đúng là chuẩn bị cho ứng dụng chịu được Spot Instance interruption, chứ không phải cố khoá nó lại.

Hai điểm này chính là lý do kế hoạch "bật cho tất cả instance" của Team Lead không khả thi nguyên vẹn.

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

A — DisableApiTermination ngăn EC2 Auto Scaling chấm dứt instance. Sai, và đây là phương án gần đúng nhất vì nó nói đúng tinh thần mong muốn (bảo vệ instance khỏi bị chấm dứt) nhưng nhầm tầng. Thuộc tính này chỉ chặn thao tác terminate qua console/CLI/API do người dùng phát ra; Auto Scaling có đường chấm dứt riêng và không bị nó chặn. Đây chính là phát biểu mà phương án B đưa ra cách chữa đúng — hai phương án loại trừ nhau, chọn được B thì đương nhiên A sai.

D — DisableApiTermination ngăn bạn chấm dứt instance bằng cách shutdown từ bên trong instance. Sai. Tên thuộc tính đã nói rõ phạm vi: API termination. Lệnh shutdown/halt phát ra từ hệ điều hành bên trong instance không đi qua EC2 API, nên thuộc tính này không chặn được. Đáng chú ý là tình huống mở đầu đề bài lại nói lập trình viên "shutdown" instance — nếu đó là shutdown từ bên trong OS thì termination protection còn không cứu được, đúng ý "check its viability".

E — DisableApiTermination không ngăn bạn chấm dứt instance từ EC2 console. Sai vì đảo ngược đúng công dụng chính của tính năng. Mặc định bạn terminate được instance qua console, CLI hoặc API; bật termination protection chính là để chặn đúng ba đường đó, tránh chấm dứt nhầm. Console là trường hợp nó bảo vệ rõ ràng nhất, không phải ngoại lệ. Lưu ý cái bẫy chữ "does not" — đọc lướt rất dễ gật đầu.

📌 Điểm cần nhớ

• DisableApiTermination chặn terminate qua console/CLI/API; không chặn shutdown phát ra từ hệ điều hành bên trong instance, và không chặn EC2 Auto Scaling.
• Instance nằm trong Auto Scaling group thì dùng công cụ của Auto Scaling: instance protection (scale in), suspend ReplaceUnhealthy (instance unhealthy), termination policy (chọn thứ tự chấm dứt).
• Spot Instance không bật được termination protection — thu hồi Spot là hành vi của dịch vụ, cách đúng là thiết kế ứng dụng chịu được interruption.
• Gặp phương án dạng "thuộc tính X chặn hành vi Y", hãy soi xem Y có thực sự đi qua cùng một tầng với X không: EC2 API, hệ điều hành khách, và Auto Scaling là ba tầng khác nhau.

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

Một lập trình viên mới viết stack policy cho AWS CloudFormation, trong đó có hẳn một câu lệnh "Effect": "Allow" với "Action": "Update:*", "Principal": "*", "Resource": "*". Nhìn qua thì giống hệt một IAM policy mở toang quyền cho mọi người. Vậy mà người dùng vẫn không truy cập được stack resources. Đề hỏi: tại sao?

Cụm từ quyết định nằm ngay ở bản thân đối tượng được tạo ra: stack policy — chứ không phải IAM policy — và ở chỗ mọi Action trong đó đều mang tiền tố Update:. Hai chi tiết đó gộp lại đã trả lời xong câu hỏi: đây là một cơ chế chỉ có tiếng nói trong lúc stack được update, và nó chỉ biết nói về các hành động update. Nó không phải nơi cấp quyền truy cập. Đề cố tình đánh vào phản xạ "thấy Effect/Action/Principal/Resource là nghĩ tới IAM".

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

Đáp án đúng theo tệp là D — stack policy chỉ áp dụng trong lúc cập nhật stack, nó không làm nhiệm vụ kiểm soát truy cập; muốn cấp quyền thì phải dùng IAM policy.

Khi bạn tạo một stack, mặc định mọi hành động update đều được phép trên mọi resource: ai có quyền update stack là update được tất cả. Stack policy sinh ra để hãm chuyện đó lại — nó là một tài liệu JSON khai báo những hành động update nào được phép thực hiện trên những resource được chỉ định, nhằm tránh việc một resource quan trọng bị sửa hoặc xoá ngoài ý muốn trong một lần cập nhật. Đúng như câu lệnh Deny thứ hai trong đề: bảo vệ ProductionDatabase khỏi bị đụng tới khi update.

Điểm mấu chốt: sau khi đặt stack policy, mọi resource trong stack được bảo vệ theo mặc định, và bạn phải viết Allow tường minh để mở lại — nhưng cái "mở lại" đó chỉ có ý nghĩa trong phạm vi thao tác update stack. Nó không cấp cho ai quyền gọi CloudFormation, không cấp quyền xem hay thao tác với AWS resources. Stack policy là cơ chế chống nhầm lẫn (fail-safe), còn phân quyền truy cập là việc của IAM. Vì thế người dùng trong đề vẫn không vào được stack resources: họ thiếu IAM permissions, và không có câu Allow nào trong stack policy bù đắp được chuyện đó.

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

A — "Stack policy gắn với một IAM role hoặc IAM user cụ thể, nên chỉ có tác dụng với người đã được gắn policy." Sai ở chỗ bịa ra một liên kết không tồn tại. Stack policy gắn với stack, không gắn với principal nào cả, và nó áp dụng cho mọi người dùng CloudFormation tìm cách update stack đó. Bạn cũng không thể gắn stack policy khác nhau cho những người dùng khác nhau — mỗi stack chỉ có đúng một stack policy. Đây là phương án dễ nhầm vì nó mượn đúng cách IAM policy hoạt động (gắn vào user/role) rồi áp sang một thứ hoàn toàn khác.

B — "Stack policy không cho dùng ký tự đại diện * cho phần tử Principal." Ngược hoàn toàn với sự thật. Phần tử Principal chỉ định đối tượng mà policy áp dụng lên; trong stack policy nó là bắt buộc phải có, nhưng lại chỉ chấp nhận đúng giá trị * — nghĩa là policy luôn áp cho tất cả principal. Nói cách khác, cái mà lập trình viên viết ở đây không những hợp lệ mà còn là giá trị duy nhất được phép. Phương án này gần đúng ở chỗ nó chú ý tới Principal, nhưng kết luận thì lộn đầu.

C — "Policy sai cú pháp nên không cấp được quyền nào; phải sửa lỗi cú pháp." Không có lỗi cú pháp nào trong đoạn JSON của đề: cấu trúc Statement với Effect, Action, Principal, Resource là đúng khuôn của stack policy, Update:* là dạng action hợp lệ, và cách chỉ resource bằng LogicalResourceId/ProductionDatabase cũng đúng quy ước. Đây thuần tuý là phương án gây nhiễu: nó dụ người học đi soi dấu phẩy thay vì nhận ra vấn đề nằm ở loại policy được dùng, chứ không nằm ở cách viết.

📌 Điểm cần nhớ

• Stack policy ≠ IAM policy. Stack policy trả lời câu hỏi "resource nào được phép đổi trong lần update này"; IAM trả lời câu hỏi "ai được phép làm gì". Đề bài nào nói về truy cập mà đưa ra stack policy thì gần như chắc chắn đáp án là "phải dùng IAM".
• Nhận diện stack policy qua tiền tố Update: trong Action (Update:*, Update:Modify, Update:Replace, Update:Delete) — IAM policy của CloudFormation thì viết kiểu cloudformation:UpdateStack.
• Trong stack policy, Principal là bắt buộc và chỉ nhận *; đừng kỳ vọng giới hạn theo từng user ở tầng này.
• Mỗi stack có một stack policy; sau khi đặt, mọi resource được bảo vệ mặc định và phải Allow tường minh mới update được. Hãy coi nó là lưới an toàn chống thao tác nhầm, không phải hàng rào bảo mật.

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

Tình huống: một Load Balancer internet facing vừa được cấu hình để phân phối lưu lượng tới các EC2 instance nằm ở nhiều Availability Zone khác nhau. Vấn đề: client không kết nối được tới Load Balancer.

Cụm từ quyết định đáp án là "clients are unable to connect to the Load Balancer" — chứ không phải "nhận được mã lỗi 5xx", không phải "trang tải chậm", cũng không phải "một số request thất bại". Kết nối không thiết lập được nghĩa là gói tin của client thậm chí chưa tới được listener của Load Balancer, hoặc tới rồi mà phản hồi không quay về được. Đây là dấu hiệu điển hình của tầng mạng: security group hoặc network ACL chặn đường, chứ không phải lỗi phát sinh trong quá trình xử lý request.

Chi tiết thứ hai cần chú ý: internet facing. Loại này bắt buộc phải đặt trong public subnet — subnet có route ra Internet Gateway của VPC — và security group của nó phải mở inbound từ client trên listener port.

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

Đáp án đúng theo tệp là B — A security group or network ACL is not allowing traffic from the client.

Với một internet facing Load Balancer, lưu lượng từ client phải vượt qua hai lớp lọc mạng độc lập:

1. Security group gắn trên Load Balancer — stateful, và phải cho phép inbound từ dải IP của client trên đúng listener port (ví dụ 80/443).
2. Network ACL của các subnet chứa Load Balancer — stateless, nghĩa là chiều đi và chiều về được đánh giá riêng. Phải mở cả inbound từ client lẫn outbound trả về client. Rất nhiều ca hỏng nằm đúng ở đây: người quản trị mở inbound mà quên chiều outbound (bao gồm cả dải ephemeral port cho gói phản hồi), nên bắt tay TCP không bao giờ hoàn tất và client thấy timeout.

Cả hai lớp này khi chặn đều tạo ra đúng triệu chứng mà đề mô tả: kết nối không thiết lập được, không có mã lỗi HTTP nào trả về vì phiên HTTP chưa từng bắt đầu. Đây cũng là mục đầu tiên trong danh sách kiểm tra khi Load Balancer không phản hồi request của client.

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

A — The target returned the error code of 200 indicating an error on the server side. Sai ngay ở tiền đề. Mặc định, mã 200 chính là mã báo thành công trong health check của Load Balancer, không phải mã lỗi. Phương án này tự mâu thuẫn với chính nó. Ngoài ra, dù target có trả mã gì đi nữa thì client vẫn kết nối được tới Load Balancer và nhận về một phản hồi HTTP — trái với mô tả trong đề.

C — It is an internal server error. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. HTTP 500 là mã internal server error mà Load Balancer sinh ra rồi gửi ngược về client. Nhưng để client nhận được mã 500, kết nối tới Load Balancer phải đã thành công. Đề nói rõ client không kết nối được tới chính Load Balancer, tức là vấn đề nằm trước cả bước sinh mã lỗi HTTP. Chỗ hỏng của phương án này là nhầm lẫn giữa "kết nối được nhưng bị lỗi ứng dụng" và "không kết nối được".

D — The target was incorrectly configured as a Lambda function and not an EC2 instance. ELB hỗ trợ Lambda function làm target một cách hợp lệ. Đây không phải cấu hình sai, nên nó không gây ra lỗi truy cập hay lỗi kết nối nào. Bên cạnh đó, đề đã nêu rõ target là các EC2 instance ở nhiều AZ, nên phương án này còn mâu thuẫn với chính đề bài.

📌 Điểm cần nhớ

• Phân biệt rõ hai lớp triệu chứng: không kết nối được → nghi ngờ tầng mạng (security group, network ACL, subnet/route). Kết nối được nhưng nhận mã lỗi 4xx/5xx → nghi ngờ target hoặc ứng dụng. Đề bài luôn cài sẵn manh mối để phân biệt hai nhóm này.
• Security group là stateful, network ACL là stateless. Với network ACL phải mở cả hai chiều; chỉ mở inbound là gói phản hồi bị chặn và client thấy timeout.
• Internet facing Load Balancer bắt buộc nằm trong public subnet — subnet có route tới Internet Gateway. Đặt nhầm vào private subnet là nguyên nhân kinh điển thứ hai khiến client không kết nối được.
• Mã 200 là mã thành công mặc định của health check, không bao giờ là dấu hiệu lỗi. Và Lambda function là target hợp lệ của ELB, không phải cấu hình sai.

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

Đề mô tả một công ty y tế chạy ứng dụng chính trên AWS, với ràng buộc bảo mật dữ liệu là encryption key phải được giữ trong một ứng dụng tự viết chạy on-premises. Công ty muốn đẩy việc lưu trữ dữ liệu và quá trình mã hoá sang Amazon S3, nhưng vẫn dùng đúng bộ key đang có.

Cụm từ quyết định đáp án nằm ở hai vế cùng lúc:

• "encryption key must be stored in a custom application running on-premises" → key không được nằm trong AWS, kể cả trong KMS.
• "offload the data storage as well as the encryption process to Amazon S3" → hành động mã hoá/giải mã phải do S3 làm, không phải do phía client làm.

Đây là ràng buộc kép, và nó là thứ tách bốn phương án ra: một nhóm để AWS giữ key (SSE-S3, SSE-KMS), một nhóm để client tự giữ key. Trong nhóm thứ hai lại chia tiếp: client giữ key nhưng ai là người thực hiện phép mã hoá. Bỏ sót vế thứ hai là chọn ngay Client-Side Encryption.

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

B — Server-Side Encryption with Customer-Provided Keys (SSE-C) thoả đúng cả hai vế.

S3 cho hai hướng bảo vệ dữ liệu at rest: Server-Side Encryption — S3 mã hoá object trước khi ghi xuống đĩa trong data center của nó và giải mã khi bạn tải về; và Client-Side Encryption — bạn mã hoá trước rồi mới upload, tự lo toàn bộ quá trình, key và công cụ liên quan.

SSE-C thuộc nhóm server-side: phép mã hoá do S3 thực hiện, đúng yêu cầu "offload the encryption process". Nhưng khác SSE-S3 và SSE-KMS ở chỗ key do khách hàng cung cấp kèm theo mỗi request, chứ AWS không lưu key đó. Nhờ vậy ứng dụng on-premises vẫn là nơi cất giữ key duy nhất, và công ty tiếp tục dùng được bộ key sẵn có.

Nói gọn: công ty muốn tự quản lý key qua ứng dụng riêng, còn để S3 lo việc mã hoá — đó chính xác là định nghĩa của SSE-C.

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

A — SSE-KMS (Customer Master Keys lưu trong AWS Key Management Service). Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì chữ "Customer Master Key" nghe như "key của khách hàng". SSE-KMS về bản chất giống SSE-S3, chỉ thêm audit trail cho biết CMK được dùng khi nào và bởi ai, cùng khả năng tạo/quản lý customer-managed CMK hoặc dùng AWS managed CMK. Nhưng điểm chết là key nằm trong KMS, tức là trong AWS, trong khi đề nói thẳng key phải nằm ở ứng dụng on-premises. Vế "encryption process" thì SSE-KMS thoả, vế "key ở đâu" thì không — trượt một trong hai là loại.

C — SSE-S3 (Amazon S3-Managed Keys). Với SSE-S3, mỗi object được mã hoá bằng một key riêng, và bản thân key đó lại được mã hoá bằng một master key do S3 quản lý và xoay vòng định kỳ. Toàn bộ vòng đời key nằm trong tay AWS — công ty không đưa key của mình vào, cũng không tiếp tục dùng được bộ key hiện có. Sai cả hai ý "key on-premises" và "dùng key sẵn có".

D — Client-Side Encryption. Phương án này thoả vế key: bạn mã hoá ở phía client nên key hoàn toàn không rời khỏi hệ thống của bạn. Nhưng nó hỏng đúng ở vế còn lại: khi mã hoá client-side, bạn quản lý cả quá trình mã hoá, key, lẫn công cụ đi kèm; S3 chỉ nhận về một khối dữ liệu đã mã hoá sẵn và không hề tham gia. Đề yêu cầu offload cả encryption process sang S3, nên D làm ngược lại chính điều được hỏi. Đây là phương án gần đúng thứ hai — chọn nó nghĩa là đọc sót cụm "as well as the encryption process".

📌 Điểm cần nhớ

• Với câu hỏi mã hoá S3, tách đề thành hai câu hỏi riêng: key nằm ở đâu và ai thực hiện phép mã hoá. Bốn phương án của S3 phân biệt nhau đúng theo hai trục này.
• SSE-C là lựa chọn duy nhất cho phép "key ở ngoài AWS nhưng S3 vẫn mã hoá" — key được gửi kèm request, AWS không lưu lại.
• Cụm từ "custom application running on-premises", "keys in our own HSM/key server", "continue to use existing keys" là tín hiệu loại bỏ SSE-S3 và SSE-KMS, vì cả hai đều giữ key trong AWS.
• Đừng để chữ "Customer Master Key" trong SSE-KMS đánh lừa: "customer-managed" nghĩa là bạn quản lý vòng đời key bên trong KMS, không phải bạn giữ key ở nơi khác.
• Client-Side Encryption đặt toàn bộ gánh nặng mã hoá lên phía bạn; hễ đề nói muốn "offload the encryption process" thì phương án này tự loại, dù nó thoả điều kiện về key.

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

Một công ty dùng Amazon S3 bucket replication để sao chép dữ liệu từ bucket này sang bucket khác vì mục đích tuân thủ (compliance). Technical Lead muốn được thông báo tự động khi việc replication một object bị thất bại.

Cụm từ quyết định đáp án là "be notified if replication of an object across S3 buckets fails" — tức là cần thông báo về sự kiện replication hỏng, chứ không phải cần một cơ chế sao chép mới. Chi tiết "for compliance purposes" cũng là gợi ý mạnh: đây chính là bối cảnh mà tính năng cam kết thời gian replication được thiết kế cho.

Điểm mấu chốt cần nhớ: replication trong S3 không mặc định phát ra sự kiện về việc replication chậm hoặc chưa hoàn tất. Muốn có loại sự kiện đó thì phải bật một tính năng cụ thể — và tính năng đó có tên riêng.

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

D — Enable S3 Replication Time Control (S3 RTC).

S3 RTC là tính năng bổ sung cho S3 Replication, sinh ra đúng cho nhu cầu compliance: nó đặt ra một mục tiêu thời gian replication có ràng buộc và cung cấp khả năng quan sát (visibility) vào quá trình replication.

Khi bật S3 RTC, bạn nhận kèm hai thứ mà replication thường không có:

• S3 replication metrics — theo dõi số lượng thao tác đang chờ replication, tổng dung lượng object đang chờ, và thời gian replication lớn nhất.
• S3 event notifications riêng cho replication — S3 phát sự kiện khi một object đủ điều kiện (eligible) cho S3 RTC không replicate kịp trong ngưỡng thời gian cam kết, và phát tiếp một sự kiện nữa khi object đó cuối cùng cũng sang tới Region đích.

Chính hai loại sự kiện này là thứ Technical Lead cần. Sự kiện S3 có thể đưa tới Amazon SQS, Amazon SNS hoặc AWS Lambda, nên việc dựng cảnh báo qua SNS là chuyện làm được ngay sau khi bật RTC.

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

A — S3 publishes object events to CloudWatch, rồi cấu hình SNS gửi thông báo khi replication hỏng. Đây là phương án gần đúng nhất và cũng là bẫy chính. Nó đúng ở chỗ SNS thật sự là nơi nhận thông báo cuối cùng, nhưng hỏng ở chỗ mắt xích đầu: sự kiện replication chỉ được S3 phát ra khi bạn đã bật S3 Replication Time Control. Không bật RTC thì đơn giản là không có sự kiện replication failure nào tồn tại để mà đẩy đi đâu — bạn cấu hình SNS xong sẽ ngồi chờ một sự kiện không bao giờ đến. Phương án này mô tả nửa sau của giải pháp mà bỏ mất điều kiện tiên quyết.

B — "Enable S3 Replication with Notification". Không có tính năng nào tên như vậy. Đây là một cái tên bịa ra, đặt vào chỉ để làm distractor. Nó nghe rất thuyết phục vì ghép đúng hai từ khoá trong đề ("replication" + "notification"), nên đây là loại mồi bắt người học chọn theo cảm giác thay vì theo tên tính năng thật. Gặp phương án nghe hợp lý mà không khớp tên dịch vụ/tính năng chính thức nào thì phải nghi ngờ ngay.

C — Dùng Amazon SQS queue để copy object giữa hai bucket, replication hỏng thì message trong queue gửi thông báo qua SNS. Sai ở tầng thiết kế chứ không chỉ ở chi tiết. Đề nói rõ công ty đang dùng S3 bucket replication — một tính năng có sẵn của S3. Phương án này lại vứt bỏ tính năng đó và dựng một cơ chế sao chép thủ công bằng queue. Tự viết logic sao chép để thay thế một tính năng gốc của dịch vụ là làm phức tạp không cần thiết, và nó cũng không trả lời câu hỏi: câu hỏi là làm sao được báo khi replication hỏng, không phải làm sao sao chép object.

📌 Điểm cần nhớ

• S3 Replication mặc định không phát sự kiện về replication chậm/hỏng. Muốn có thông báo dạng đó thì bắt buộc bật S3 Replication Time Control (S3 RTC) — đây là điều kiện tiên quyết, không phải tuỳ chọn trang trí.
• S3 RTC đi kèm cả replication metrics lẫn event notifications, nên nó vừa giải quyết bài toán cam kết thời gian, vừa giải quyết bài toán quan sát/cảnh báo.
• Sự kiện S3 luôn đi ra qua SQS, SNS hoặc Lambda. Vì vậy trong đề thi, nếu phương án chỉ nhắc SNS mà thiếu nguồn phát sự kiện hợp lệ thì đó là phương án cụt.
• Thấy từ khoá "compliance" đi cùng replication trong đề AWS thì hãy nghĩ ngay tới S3 RTC — đó là tính năng được đặt ra cho các yêu cầu tuân thủ về thời gian sao chép dữ liệu.
• Cảnh giác với phương án mang tên tính năng nghe hợp lý nhưng không tồn tại (như "S3 Replication with Notification"). Chuẩn kiểm tra duy nhất là tên chính thức của dịch vụ/tính năng, không phải cảm giác quen tai.