Ngân hàng đề — AWS Certified Cloud Practitioner

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

Đề hỏi: mã HTTP nào cho biết đã upload thành công một object lên Amazon S3?

Cụm từ quyết định là "indicates a successful upload" — tức là đề hỏi mã báo thành công, chứ không phải mã báo lỗi hay mã báo chuyển hướng. Đây là câu kiểm tra kiến thức nền về ý nghĩa các dải mã trạng thái HTTP, áp dụng vào ngữ cảnh Amazon S3: S3 là dịch vụ lưu trữ object được truy cập qua API kiểu REST/HTTP, nên mọi thao tác PUT object đều nhận về một mã trạng thái HTTP tiêu chuẩn.

Bốn phương án cố tình chọn mỗi phương án một dải khác nhau (2xx, 3xx, 4xx, 5xx). Vì vậy chỉ cần nhớ ý nghĩa từng dải là loại được ba phương án còn lại ngay, không cần biết chi tiết riêng của S3.

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

Đáp án đúng theo tệp là C — 200.

Dải 2xx là dải "thành công": yêu cầu đã được server nhận, hiểu và xử lý xong đúng ý. Mã 200 (OK) là mã thành công phổ biến nhất, và đúng như phần giải thích gốc nêu, đây chính là mã cho biết upload đã thành công.

Trong ngữ cảnh Amazon S3: khi bạn gửi một object lên bucket qua thao tác PUT và S3 lưu được object đó, phản hồi trả về nằm ở dải 2xx — mã 200 chính là tín hiệu "object đã nằm trong S3". Đây cũng là điều bạn thấy khi bật log truy cập hoặc khi kiểm tra phản hồi từ AWS CLI/SDK sau một lệnh upload thành công.

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

A — 400: dải 4xx là lỗi phía client. Nghĩa là yêu cầu bạn gửi lên có vấn đề: sai cú pháp, thiếu tham số bắt buộc, header không hợp lệ, ký request sai, hoặc dữ liệu gửi lên không đúng định dạng S3 chờ đợi. Đây là phương án dễ gây nhầm nhất với người mới, vì 4xx cũng là một phản hồi "server có trả lời" — nhưng trả lời để từ chối yêu cầu, object không được lưu. Cần phân biệt rõ: server phản hồi ≠ thao tác thành công.

B — 500: dải 5xx là lỗi phía server. Yêu cầu của bạn có thể hoàn toàn hợp lệ, nhưng phía dịch vụ gặp trục trặc khi xử lý nên không hoàn tất được. Đây cũng là kiểu lỗi thường được khuyến nghị thử lại (retry) vì nó có thể chỉ là tạm thời — nhưng bản thân mã 500 nghĩa là upload chưa thành công, không được coi là kết quả tốt.

D — 300: dải 3xx là chuyển hướng (redirection). Nó nói với client rằng "tài nguyên bạn cần nằm ở chỗ khác" hoặc "hãy làm thêm một bước nữa" — client thường phải gửi lại yêu cầu tới địa chỉ mới. Đây là dải "chưa xong việc, đi tiếp đi", không phải dải xác nhận hoàn tất. Người học hay nhầm 3xx là "gần thành công" vì nó không phải lỗi, nhưng nó không khẳng định object đã được ghi vào S3.

📌 Điểm cần nhớ

• Nhớ ý nghĩa theo dải chữ số đầu, đó là cách nhanh nhất để loại phương án: 2xx = thành công, 3xx = chuyển hướng, 4xx = lỗi do phía client, 5xx = lỗi do phía server. Riêng dải 1xx là thông tin, hiếm gặp trong đề.
• Amazon S3 được truy cập qua API dạng REST/HTTP, nên phản hồi của mọi thao tác với object đều tuân theo mã trạng thái HTTP tiêu chuẩn — không có "mã riêng của S3" cần học thuộc.
• Có phản hồi từ server không đồng nghĩa với thành công. 400 và 500 đều là phản hồi hợp lệ về mặt giao thức nhưng đều báo thao tác thất bại; chỉ 2xx mới xác nhận object đã được lưu.
• Khi gỡ lỗi upload lên S3, dải mã cho biết nên sửa ở đâu: 4xx thì rà lại yêu cầu của mình (quyền truy cập, chữ ký, tham số, tên bucket/key); 5xx thì thường là vấn đề tạm thời phía dịch vụ và thử lại là hướng xử lý hợp lý.

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

Đề hỏi: trong bốn việc dưới đây, việc nào KHÔNG phải là best practice để bảo vệ root user của một tài khoản AWS.

Cụm từ quyết định đáp án là chữ "NOT" viết hoa trong đề. Ba trong bốn phương án đều là những khuyến nghị bảo mật quen thuộc đến mức nếu đọc lướt qua chữ "NOT", người làm bài sẽ thấy phương án nào cũng "đúng" và chọn bừa. Đây là dạng câu hỏi phủ định: việc cần làm là tìm ra phương án lạc loài — cái duy nhất không nằm trong danh sách khuyến nghị của AWS, hoặc thậm chí là điều không thể thực hiện được.

Ràng buộc thứ hai nằm ở đối tượng: đề nói rõ root user, không phải IAM user thông thường. Bản chất của root user trong AWS quyết định phương án nào là bất khả thi.

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

A. Remove administrative permissions là đáp án đúng cho câu hỏi phủ định này.

Root user không phải là một IAM user có policy gắn vào để bạn tháo ra. Nó là chủ sở hữu (owner) của chính tài khoản AWS, và quyền lực của nó đến từ vị thế đó chứ không đến từ một identity-based policy nào cả. Vì vậy không có chỗ nào để "gỡ quyền quản trị" khỏi root user — thao tác này đơn giản là không tồn tại trong AWS.

Đúng như phần giải thích gốc nêu: chính vì không thể tước quyền của root user, bạn buộc phải bảo vệ nó bằng các biện pháp khác — đặt mật khẩu phức tạp, bật MFA, cất kỹ access key (nếu thực sự có nhu cầu tạo), và không chia sẻ thông tin đăng nhập cho ai. Ba phương án còn lại chính là ba biện pháp đó.

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

Ba phương án dưới đây "sai" theo nghĩa của câu hỏi phủ định: chúng đều là best practice, nên không thể là câu trả lời cho câu hỏi "cái nào KHÔNG phải".

B. Enable MFA — Đây là khuyến nghị hàng đầu của AWS cho root user. MFA thêm một lớp xác thực thứ hai ngoài mật khẩu, nên kể cả khi mật khẩu root bị lộ, kẻ tấn công vẫn không đăng nhập được. Là best practice ⇒ không phải đáp án.

C. Lock away the AWS root user access keys — Access key cho root user gần như không cần thiết trong vận hành bình thường; công việc hằng ngày nên làm qua IAM user hoặc IAM role có quyền hạn chế. Nếu vì lý do nào đó tài khoản đã có sẵn root access key, khuyến nghị là cất chúng đi hoặc xoá hẳn thay vì để dùng trong script hay ứng dụng. Là best practice ⇒ không phải đáp án.

D. Don't share the root user credentials — Root user có toàn quyền không giới hạn trên tài khoản, và thao tác của nó khó quy trách nhiệm cho một cá nhân cụ thể. Chia sẻ credentials root cho nhiều người là mất cả khả năng kiểm soát lẫn khả năng truy vết. Là best practice ⇒ không phải đáp án.

Lưu ý phương án dễ gây phân vân nhất là A đối với người quen làm việc với IAM user: với IAM user thì việc gỡ bớt permission đúng là một biện pháp bảo mật hợp lý (least privilege). Điểm hỏng của A nằm ở chỗ nó áp dụng tư duy của IAM user lên root user — mà root user thì không hoạt động theo cơ chế policy như vậy.

📌 Điểm cần nhớ

• Root user không thể bị tước quyền. Mọi câu hỏi nói tới việc "hạn chế quyền", "gỡ permission", "gắn policy giới hạn" cho root user đều sai về mặt cơ chế; cách duy nhất là bảo vệ chính thông tin đăng nhập của nó.
• Bộ best practice cho root user cần thuộc lòng: mật khẩu mạnh, bật MFA, không tạo (hoặc cất kỹ / xoá) access key của root, không chia sẻ credentials, và dùng IAM user/role cho công việc hằng ngày.
• Đọc kỹ chữ NOT / EXCEPT / LEAST trong đề. Khi thấy ba phương án đều "nghe rất hợp lý", nhiều khả năng đó là câu hỏi phủ định và bạn đang phải tìm cái lạc loài, không phải cái đúng nhất.
• Phân biệt rõ root user với IAM user: nguyên tắc least privilege qua policy chỉ áp dụng cho IAM identity, không áp dụng cho root user.

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

Đề hỏi: theo shared responsibility model, việc nào thuộc trách nhiệm của khách hàng AWS (chọn HAI).

Cụm từ quyết định đáp án là "the responsibility of the AWS customer". Toàn bộ câu hỏi chỉ xoay quanh một đường ranh giới duy nhất mà shared responsibility model vạch ra:

• AWS chịu trách nhiệm "security of the cloud" — mọi thứ thuộc về hạ tầng vật lý và phần nền tảng chạy dịch vụ: nhà máy dữ liệu, phần cứng, mạng, lớp ảo hoá, và các dịch vụ nền do AWS vận hành.
• Khách hàng chịu trách nhiệm "security in the cloud" — mọi thứ khách hàng đặt vào và cấu hình bên trên: dữ liệu của mình, cấu hình mã hoá, quản lý danh tính và quyền, cấu hình hệ điều hành và ứng dụng, và con người trong tổ chức của mình.

Mẹo lọc nhanh: đọc từng phương án và hỏi "tôi có bấm được nút này trong Console/API của mình không, hay phải là nhân viên AWS bước vào phòng máy mới làm được?". Cái gì khách hàng không có quyền chạm tới thì chắc chắn không phải trách nhiệm của khách hàng. Ba phương án A, B, D đều là thứ khách hàng không hề có cách nào tác động, nên chúng bị loại ngay từ nguyên tắc này.

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

Theo tệp, đáp án là C và E.

C — "Ensuring that users have received security training in the use of AWS services": đào tạo nhân sự là việc thuộc về tổ chức của khách hàng. AWS không biết ai trong công ty bạn được cấp tài khoản, cũng không có cách nào đảm bảo họ hiểu cách dùng dịch vụ an toàn. Yếu tố con người — quy trình, nhận thức bảo mật, thói quen thao tác — nằm hoàn toàn ở phía khách hàng.

E — "Ensuring that application data is encrypted at rest": dữ liệu là tài sản của khách hàng, và việc bảo vệ dữ liệu luôn nằm ở phía khách hàng. AWS cung cấp công cụ để mã hoá (tuỳ chọn encryption trên các dịch vụ lưu trữ, dịch vụ quản lý khoá), nhưng quyết định bật mã hoá hay không, và quản lý khoá thế nào, là của khách hàng. Điều tương tự cũng đúng với encryption in transit. Đây là điểm hay bị hiểu nhầm: "AWS có sẵn tính năng" không đồng nghĩa với "AWS chịu trách nhiệm".

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

A — "Ensuring that hardware is disposed of properly": thanh lý ổ đĩa và thiết bị hết vòng đời là quy trình vật lý bên trong data center của AWS. Khách hàng không sở hữu, không nhìn thấy và không đụng tới phần cứng đó. Đây là "security of the cloud" — trách nhiệm AWS.

B — "Ensuring that AWS NTP servers are set to the correct time": đây là phương án gây nhầm nhất, vì đồng bộ thời gian nghe có vẻ là việc quản trị hệ thống mà khách hàng phải lo. Nhưng hãy đọc kỹ chữ "AWS NTP servers" — đề đang nói về chính các máy chủ NTP do AWS vận hành, tức là một thành phần hạ tầng của AWS. Khách hàng có thể cấu hình client trong instance của mình trỏ tới dịch vụ đó, nhưng tính đúng đắn của bản thân NTP server là AWS bảo đảm. Ranh giới ở đây là: cấu hình bên trong instance của bạn thì bạn lo; còn dịch vụ nền mà bạn chỉ tiêu thụ thì AWS lo.

D — "Ensuring that access to data centers is restricted": kiểm soát ra vào vật lý — hàng rào, bảo vệ, thẻ từ, camera — là an ninh vật lý của cơ sở AWS. Khách hàng thậm chí không được biết địa chỉ chính xác của data center, nên không thể chịu trách nhiệm phần này. Trách nhiệm AWS.

📌 Điểm cần nhớ

• Ranh giới cốt lõi: AWS lo "security of the cloud" (hạ tầng vật lý, phần cứng, data center, dịch vụ nền), khách hàng lo "security in the cloud" (dữ liệu, mã hoá, IAM, cấu hình, con người).
• Dữ liệu luôn thuộc về khách hàng. Mã hoá at rest và in transit, cùng việc quản lý khoá, gần như mặc định là trách nhiệm khách hàng trong mọi câu hỏi kiểu này.
• Đào tạo và quy trình của nhân sự chưa bao giờ là việc của AWS. Bất kỳ phương án nào nhắc tới "users", "staff", "training", "policy nội bộ" đều nghiêng về phía khách hàng.
• Cẩn thận với các phương án nghe giống việc quản trị nhưng có chữ "AWS ..." đứng trước danh từ (như AWS NTP servers): đó là dấu hiệu đang nói về thành phần do AWS vận hành, không phải thứ bạn cấu hình.
• Bộ lọc thực dụng khi bí: nếu việc đó đòi hỏi phải có mặt vật lý trong data center, câu trả lời chắc chắn là AWS.

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

Đề hỏi: theo AWS shared responsibility model, đâu là trách nhiệm của khách hàng (chọn HAI).

Cụm từ quyết định là "customer responsibilities". Toàn bộ mô hình này chỉ có một đường phân chia duy nhất, và mọi phương án chỉ cần đặt lên đường đó là xong:

• AWS chịu trách nhiệm "security OF the cloud" — hạ tầng vật lý, nhà máy điện, tòa nhà data center, phần cứng, tầng ảo hóa, và năng lực vận hành của các dịch vụ managed.
• Khách hàng chịu trách nhiệm "security IN the cloud" — những gì bạn tự bật, tự cấu hình, tự nạp dữ liệu vào: cấu hình mạng, quyền truy cập, mã hóa dữ liệu, hệ điều hành khách trên EC2.

Mẹo phân biệt nhanh: hỏi "cái này tôi có bấm được nút nào để đổi nó không?" Nếu có nút trong console/API do bạn bấm thì đó là việc của bạn; nếu bạn chẳng có cách nào chạm tới thì đó là việc của AWS.

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

A. Network and firewall configurations — Khách hàng là người dựng VPC, chia subnet, viết rule cho Security Group và Network ACL, và cả firewall ở tầng hệ điều hành bên trong EC2 instance. AWS cung cấp công cụ, còn mở cổng nào cho ai là quyết định của bạn. Đây là mục nằm rõ ràng ở cột customer trong sơ đồ chính thức.

D. Setting up server-side encryption on an Amazon S3 bucket — Bảo vệ dữ liệu, cả at rest lẫn in transit, thuộc về khách hàng. S3 có sẵn cơ chế server-side encryption, nhưng việc chọn bật, chọn loại khóa, và cấu hình bucket là hành động của bạn. Nói cách khác: AWS đưa cái khóa, bạn là người quyết định có khóa cửa hay không.

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

B. Compute capacity availability — Đây là trách nhiệm của AWS. Việc bảo đảm có đủ máy chủ vật lý, đủ năng lực tính toán trong các Region và Availability Zone thuộc phần "security and operation of the cloud". Khách hàng không quản lý kho phần cứng của AWS.

C. Amazon RDS instance patching — Đây là phương án gần đúng nhất và dễ sập bẫy nhất. RDS là dịch vụ managed: khách hàng có quyền định nghĩa maintenance window (khung giờ được phép bảo trì), nhưng chính AWS mới là bên thực hiện vá hệ điều hành và database engine. Chọn khi nào vá không đồng nghĩa với chịu trách nhiệm việc vá. Lưu ý ranh giới: nếu bạn tự cài database lên EC2 thì việc vá lại quay về phía khách hàng — chính chữ "RDS" trong đề đẩy nó sang phía AWS.

E. Physical security of data center facilities — An ninh vật lý của data center (hàng rào, kiểm soát ra vào, bảo vệ, camera) là ví dụ kinh điển của "security of the cloud". Khách hàng thậm chí không được biết địa chỉ chính xác của data center, nói gì tới việc bảo vệ nó.

📌 Điểm cần nhớ

• Chia đôi mọi phương án bằng một câu hỏi duy nhất: "security OF the cloud" (AWS) hay "security IN the cloud" (khách hàng)?
• Bất cứ thứ gì thuộc về vật lý — tòa nhà, phần cứng, điện, năng lực compute — luôn là AWS.
• Bất cứ thứ gì là cấu hình do bạn bấm — Security Group, Network ACL, IAM, bật encryption, dữ liệu bạn đưa lên — luôn là khách hàng.
• Với dịch vụ managed như RDS, việc vá thuộc AWS còn khách hàng chỉ chọn maintenance window; cùng công việc đó nếu tự chạy trên EC2 thì lại thuộc khách hàng. Hãy đọc kỹ tên dịch vụ trong đề trước khi quyết định.

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

Đề hỏi: dịch vụ AWS nào cho phép phát hiện việc rò rỉ ngoài ý muốn dữ liệu định danh cá nhân (PII) và dữ liệu thông tin đăng nhập của người dùng.

Cụm từ quyết định là "personally identifiable information (PII)" và "detect ... data leaks". Đây là một câu phân biệt bốn dịch vụ bảo mật AWS bằng đối tượng mà chúng nhìn vào:

• Nhìn vào nội dung dữ liệu (bên trong tệp, xem có phải số CMND, thẻ tín dụng, credential hay không) → chỉ có một dịch vụ làm việc này.
• Nhìn vào hành vi và log tài khoản → phát hiện xâm nhập, không đọc nội dung dữ liệu.
• Nhìn vào lỗ hổng phần mềm / cấu hình sai của workload → không đọc nội dung dữ liệu.
• Nhìn vào lưu lượng mạng tấn công → càng không liên quan tới nội dung dữ liệu.

Chỉ cần xếp được bốn phương án vào bốn nhóm trên là câu này ra ngay, không cần thuộc chi tiết tính năng.

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

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

Macie là dịch vụ quản lý hoàn toàn về data security và data privacy: nó dùng machine learning và pattern matching để quét dữ liệu bạn đang lưu trong Amazon S3, nhận diện và cảnh báo khi tìm thấy dữ liệu nhạy cảm như PII hay thông tin credential.

Điểm mấu chốt: Macie là dịch vụ duy nhất trong bốn phương án thực sự mở nội dung dữ liệu ra để đọc và phân loại. Đề dùng đúng từ khoá "PII" — đây gần như là chữ ký nhận diện Macie trong đề thi Cloud Practitioner. Ngoài việc phát hiện dữ liệu nhạy cảm, Macie còn giúp thấy các bucket S3 đang ở trạng thái cấu hình rủi ro, tức là đúng ngữ cảnh "inadvertent data leak" — rò rỉ do sơ suất chứ không phải do bị tấn công.

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

A. Amazon Inspector — Đây là dịch vụ đánh giá bảo mật tự động cho ứng dụng và workload: tìm lỗ hổng phần mềm, mức độ phơi bày ra ngoài (network exposure), và các sai lệch so với best practice. Nó trả lời câu hỏi "máy/ứng dụng của tôi có lỗ hổng nào không", chứ không hề đọc nội dung dữ liệu để biết đó có phải PII hay không. Đây là phương án dễ nhầm nhất vì nghe cũng như "quét và phát hiện", nhưng đối tượng quét khác hẳn: Inspector quét chỗ chạy code, Macie quét chỗ chứa dữ liệu.

B. Amazon GuardDuty — Dịch vụ phát hiện mối đe doạ (threat detection), phân tích tài nguyên bằng anomaly detection và machine learning để tìm hành vi bất thường và dấu hiệu bị xâm nhập. Đây cũng là phương án gần đúng, vì GuardDuty có cảnh báo những chuyện như truy cập S3 khả nghi. Nhưng nó hỏng ở chỗ: GuardDuty kết luận dựa trên hành vi truy cập, chưa bao giờ nói cho bạn biết bên trong tệp đó có gì. Đề hỏi phát hiện chính bản thân PII và credential — GuardDuty không phân loại nội dung dữ liệu, nên không đáp ứng.

D. AWS Shield — Dịch vụ bảo vệ tài nguyên khỏi tấn công DDoS. Nó nằm hoàn toàn ở tầng khả dụng của hệ thống (giữ cho dịch vụ không bị đánh sập), không liên quan gì tới tính bí mật hay nội dung của dữ liệu. Đây là phương án dễ loại nhất trong bốn phương án.

📌 Điểm cần nhớ

• Thấy "PII", "sensitive data", "data privacy", "S3 data classification" trong đề → nghĩ ngay tới Amazon Macie. Đây là ánh xạ từ khoá gần như một-đối-một trong đề thi.
• Phân biệt ba dịch vụ hay bị trộn lẫn bằng đối tượng chúng nhìn vào: Macie → dữ liệu, GuardDuty → hành vi/mối đe doạ, Inspector → lỗ hổng của workload.
• AWS Shield thuộc nhóm bảo vệ khả dụng (DDoS), không thuộc nhóm phát hiện. Gặp Shield trong câu hỏi về dữ liệu thì gần như chắc chắn là mồi nhử.
• "Inadvertent" (ngoài ý muốn) là gợi ý rò rỉ do sơ suất/cấu hình sai, không phải do bị tấn công chủ động — hướng suy nghĩ về dịch vụ soi dữ liệu và cấu hình lưu trữ, không phải dịch vụ chống tấn công.

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

Đề hỏi: "What methods are available for scaling an Amazon RDS database? (Select TWO.)" — có những cách nào để scale một database Amazon RDS.

Cụm từ quyết định là "scaling an Amazon RDS database", tức đối tượng được scale phải là chính RDS, chứ không phải tầng ứng dụng đứng trước nó. Bốn trong năm phương án đều nhắc tới những cơ chế scale rất quen thuộc trên AWS (EC2 Auto Scaling, Elastic Load Balancing, AWS Auto Scaling), nhưng chúng thuộc về tầng compute — dùng để thêm/bớt EC2 instance và phân phối traffic — chứ không phải công cụ điều khiển một RDS instance.

Ràng buộc phụ thứ hai nằm ở chữ "(Select TWO)" kết hợp với cách diễn đạt của từng phương án: hai phương án đúng là hai thao tác thủ công, do người vận hành chủ động thực hiện trên chính RDS instance (tăng dung lượng storage, đổi sang instance size lớn hơn); các phương án còn lại đều gắn chữ "automatically" hoặc gắn với một dịch vụ bên ngoài RDS.

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

Theo tệp, đáp án đúng là A và E — cả hai đều là hình thức vertical scaling (scale up) trên chính RDS instance:

• E — "You can scale up by moving to a larger instance size": RDS cho phép đổi class của instance sang loại lớn hơn (nhiều vCPU và RAM hơn) để chịu tải cao hơn. Với các engine RDS như MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, danh sách instance size để chọn rất rộng; Aurora cũng có các memory-optimized instance size riêng. Đây chính là "vertically scale up your master database" mà giải thích gốc nói tới.
• A — "You can scale up by increasing storage capacity": ngoài CPU/RAM, dung lượng lưu trữ cấp cho RDS instance cũng tăng lên được. Đây vẫn là scale up — làm cho một instance to hơn — nên nó nằm cùng nhóm với phương án E và cùng thoả yêu cầu "phương pháp scale RDS".

Cả hai đều là hành động tác động trực tiếp lên tài nguyên của RDS instance, không cần dịch vụ trung gian nào.

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

• B — "You can scale out automatically with EC2 Auto Scaling": EC2 Auto Scaling làm việc với EC2 instance nằm trong Auto Scaling group. RDS là managed service, instance của nó không phải EC2 instance mà bạn đưa vào Auto Scaling group được, nên không thể dùng EC2 Auto Scaling để scale RDS. Đây là phương án "bẫy tên dịch vụ quen thuộc".
• C — "You can scale out by implementing Elastic Load Balancing": ELB phân phối request tới nhiều target ở tầng ứng dụng; nó không phải cơ chế scale của database và không đặt trước RDS được. Hình thức scale out thật sự của RDS là read replica — nhưng read replica không xuất hiện trong bất kỳ phương án nào, nên C vẫn sai.
• D — "You can scale up automatically using AWS Auto Scaling": đây là phương án gần đúng nhất và dễ lừa nhất, vì nó dùng đúng chữ "scale up" giống đáp án E. Chỗ hỏng nằm ở chữ "automatically using AWS Auto Scaling". AWS (Application) Auto Scaling điều chỉnh tự động tài nguyên được gán cho một dịch vụ — điển hình là throughput của DynamoDB — chứ không dùng để tự động đổi instance class của RDS. Việc scale up RDS trong ngữ cảnh câu hỏi này là thao tác do người vận hành chủ động thực hiện, không phải do AWS Auto Scaling điều khiển. Bỏ chữ "automatically using AWS Auto Scaling" đi thì D trùng ý với E; giữ nguyên thì nó sai.

📌 Điểm cần nhớ

• Với RDS, scale up (vertical) = đổi sang instance size lớn hơn hoặc tăng storage; scale out (horizontal) = dùng read replica để gánh tải đọc. Nhớ đúng cặp này là loại được phần lớn phương án nhiễu.
• EC2 Auto Scaling và Elastic Load Balancing thuộc tầng compute/ứng dụng, không áp dụng cho RDS. Thấy hai cái tên này trong câu hỏi về database thì gần như chắc chắn là phương án sai.
• Chú ý chữ "automatically" trong phương án: cùng một hành động (scale up) nhưng thêm chữ "tự động bằng AWS Auto Scaling" là đổi hẳn tính đúng/sai. Application Auto Scaling gắn với DynamoDB, không phải RDS.
• Câu "(Select TWO)" thường ghép một phương án hiển nhiên với một phương án ít nghĩ tới (ở đây là tăng storage). Đừng dừng lại khi vừa tìm được một đáp án đẹp — hãy soát xem còn thao tác nào cũng tác động trực tiếp lên chính tài nguyên được hỏi.

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

Đề hỏi: công cụ bảo mật nào của AWS dùng một agent cài trên EC2 instance và đánh giá ứng dụng để tìm lỗ hổng cùng những chỗ đi chệch khỏi best practice?

Cụm từ quyết định là "uses an agent installed in EC2 instances" kết hợp với "assesses applications for vulnerabilities". Hai vế này bổ trợ nhau và loại đi gần hết danh sách:

• Có agent chạy bên trong instance nghĩa là công cụ nhìn được vào bên trong hệ điều hành và phần mềm đang chạy — chứ không phải chỉ đọc cấu hình tài khoản AWS từ bên ngoài.
• "vulnerabilities and deviations from best practices" đặt nó vào nhóm đánh giá bảo mật (security assessment), không phải nhóm tính chi phí hay nhóm báo trạng thái dịch vụ.

Bốn phương án thuộc bốn nhóm mục đích hoàn toàn khác nhau, nên chỉ cần đọc đúng hai ràng buộc trên là chốt được ngay.

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

A — AWS Inspector. Inspector là dịch vụ đánh giá bảo mật tự động, giúp cải thiện mức độ an toàn và tuân thủ của ứng dụng chạy trên AWS. Nó tự động rà ứng dụng để tìm lỗ hổng hoặc những điểm lệch khỏi best practice, và — đúng như đề mô tả — hoạt động thông qua một agent được cài trên EC2 instance. Chính chi tiết "agent" là đặc điểm nhận dạng của Inspector trong đề thi Cloud Practitioner: không dịch vụ nào khác trong danh sách này đặt chân vào bên trong instance.

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

B — AWS TCO Calculator. Đây là công cụ tài chính, không phải bảo mật: nó dùng để so sánh chi phí chạy ứng dụng ở môi trường on-premises hoặc colocation với chi phí chạy trên AWS. Không có agent, không quét lỗ hổng, không liên quan gì tới security assessment. Đây là phương án dễ loại nhất.

C — AWS Trusted Advisor. Đây là phương án gần đúng nhất và là bẫy chính, vì Trusted Advisor cũng đưa ra khuyến nghị theo best practice và cũng có mục về bảo mật. Nhưng nó hỏng ở đúng chỗ đề nhấn mạnh: Trusted Advisor là một dịch vụ trực tuyến kiểm tra môi trường AWS của bạn từ bên ngoài — soi cấu hình tài khoản và tài nguyên để giúp giảm chi phí, tăng hiệu năng và cải thiện bảo mật. Nó không cài agent vào EC2 instance và không quét lỗ hổng bên trong ứng dụng/hệ điều hành. Nếu đề chỉ nói "best practices" thì Trusted Advisor còn cạnh tranh được; thêm "agent installed in EC2 instances" và "vulnerabilities" là nó bị loại.

D — AWS Personal Health Dashboard. Đây là công cụ theo dõi tình trạng dịch vụ, không phải công cụ bảo mật. Nó gửi cảnh báo và hướng dẫn khắc phục khi AWS đang gặp sự cố có thể ảnh hưởng tới tài nguyên của bạn. Nó nói về sức khoẻ của hạ tầng AWS, không nói gì về lỗ hổng trong ứng dụng của bạn, và cũng không có agent nào cả.

📌 Điểm cần nhớ

• Từ khoá "agent" trên EC2 + "vulnerabilities" → Inspector. Đây là cặp từ khoá gần như luôn dẫn thẳng tới đáp án trong các câu hỏi kiểu này.
• Phân biệt Inspector với Trusted Advisor bằng góc nhìn: Inspector nhìn vào trong workload (lỗ hổng ở tầng ứng dụng/OS), Trusted Advisor nhìn cấu hình tài khoản AWS từ bên ngoài và trải rộng ra cả chi phí, hiệu năng, giới hạn dịch vụ chứ không chỉ bảo mật.
• Đọc mục đích của dịch vụ trước khi đọc tên: trong bốn phương án ở đây có đủ bốn nhóm — bảo mật (Inspector), chi phí (TCO Calculator), tối ưu tổng thể (Trusted Advisor), tình trạng dịch vụ (Personal Health Dashboard). Xác định câu hỏi thuộc nhóm nào là loại được ngay hai, ba phương án.
• Personal Health Dashboard = sự cố phía AWS ảnh hưởng tới bạn, không bao giờ là câu trả lời cho câu hỏi về quét lỗ hổng hay tuân thủ bảo mật.

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

Đề hỏi: cách hiệu quả nhất (most efficient) để thiết lập kết nối mạng từ on-premises tới NHIỀU VPC nằm ở NHIỀU Region khác nhau.

Cụm từ quyết định đáp án là "multiple VPCs in different AWS Regions" — số nhiều, và trải trên nhiều Region — cộng với "most efficient". Nếu đề chỉ nói "kết nối on-premises tới một VPC" thì cả AWS VPN lẫn AWS Direct Connect đều là đáp án hợp lệ. Chính chữ multiple mới loại chúng: khi có nhiều VPC, các phương án kết nối điểm-điểm buộc bạn dựng và quản lý một đường riêng cho từng VPC, số kết nối phình lên theo số VPC. "Most efficient" ở đây nghĩa là ít kết nối phải tạo và quản lý nhất, chứ không phải nhanh nhất về băng thông.

Chi tiết thứ hai đáng chú ý: "from on-premises" — tức là kết nối từ trung tâm dữ liệu/văn phòng, không phải từ máy cá nhân của nhân viên. Chi tiết này dùng để loại AWS Client VPN.

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

Đáp án đúng theo tệp là B — Use an AWS Transit Gateway.

AWS Transit Gateway là dịch vụ cho phép khách hàng nối các Amazon VPC và mạng on-premises của mình vào một gateway duy nhất. Nó hoạt động như một hub, còn các VPC và mạng on-premises là các spoke; Transit Gateway kiểm soát cách lưu lượng được định tuyến giữa toàn bộ các mạng được kết nối vào nó.

Điều đó khớp chính xác với yêu cầu của đề: thay vì dựng và duy trì một kết nối riêng tới từng VPC, bạn chỉ tạo và quản lý một kết nối duy nhất từ gateway trung tâm tới từng VPC, từng data center hay từng văn phòng chi nhánh. Mô hình hub-and-spoke này chính là thứ làm cho nó "most efficient" khi số VPC nhiều lên — công sức quản lý không tăng theo kiểu lưới đầy đủ giữa mọi cặp mạng. Transit Gateway cũng là phương án duy nhất trong danh sách được thiết kế để gom nhiều VPC lại phía sau một điểm vào chung, kể cả khi các VPC đó không nằm cùng một Region.

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

A — Use AWS Direct Connect. Đây là phương án gần đúng nhất và dễ chọn nhầm nhất, vì Direct Connect đúng là dịch vụ kết nối on-premises vào AWS bằng đường truyền riêng. Nó hỏng ở chỗ phạm vi kết nối: theo giải thích của đề, Direct Connect chỉ đưa bạn tới một Amazon VPC, chứ không tới nhiều VPC ở nhiều Region. Muốn phủ hết các VPC bạn sẽ phải nhân bản kết nối lên — trái hẳn với chữ "most efficient". Lưu ý cách đề đóng khung: Direct Connect trả lời câu hỏi "nối bằng đường gì", còn câu hỏi ở đây thực chất là "nối tới nhiều đích cùng lúc bằng cách nào cho gọn".

D — Use AWS VPN. Sai vì đây là kết nối điểm-điểm (point-to-point) giữa một địa điểm on-premises và một Amazon VPC. Đúng kiểu kết nối, nhưng vẫn là quan hệ một-một. Với N VPC ở nhiều Region, bạn phải dựng N đường VPN và duy trì bảng định tuyến cho từng đường — đây chính là bài toán mà mô hình hub-and-spoke sinh ra để giải quyết.

C — Use AWS Client VPN. Sai ở mức căn bản hơn hai phương án trên: dịch vụ này dành cho người dùng cuối kết nối vào AWS bằng phần mềm VPN client trên máy của họ. Nó giải quyết bài toán "nhân viên truy cập từ xa", không phải bài toán "nối mạng của cả một data center vào hạ tầng đám mây". Ngay cả khi chỉ có một VPC duy nhất, Client VPN cũng không phải câu trả lời cho từ khoá "from on-premises".

📌 Điểm cần nhớ

• Thấy nhiều VPC / nhiều Region / nhiều chi nhánh đi kèm yêu cầu "efficient", "simplify" hay "reduce management overhead" → nghĩ ngay tới AWS Transit Gateway với mô hình hub-and-spoke: một điểm nối trung tâm thay cho lưới kết nối từng cặp.
• AWS VPN và AWS Direct Connect trả lời câu hỏi "đi bằng đường nào" (Internet có mã hoá, hay đường truyền riêng), còn Transit Gateway trả lời câu hỏi "nối tới bao nhiêu đích và quản lý ra sao". Hai nhóm này không loại trừ nhau — chúng nằm ở hai tầng khác nhau của cùng một thiết kế.
• Phân biệt dứt khoát AWS Client VPN (người dùng cuối, cài phần mềm client, truy cập từ xa) với AWS VPN dạng site-to-site (nối cả một mạng on-premises vào một VPC). Đề nào nhắc "employees", "remote workers", "laptop" thì mới hướng về Client VPN.
• Với câu hỏi so sánh phương án mạng, hãy đếm xem số kết nối phải tạo và duy trì tăng theo cái gì. Phương án nào khiến số kết nối tăng tuyến tính theo số VPC thì thường không phải đáp án "most efficient".

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

Đề bài mô tả một tình huống quen thuộc: nối mạng on-premise của công ty vào AWS bằng AWS managed VPN (AWS Site-to-Site VPN). Câu hỏi không hỏi "cần những gì để dựng VPN" mà hỏi hẹp hơn nhiều.

Cụm từ quyết định đáp án là "on the Amazon VPC side of the connection" — tức là phía AWS của đường kết nối, chứ không phải phía trung tâm dữ liệu của công ty. Một kết nối Site-to-Site VPN luôn có hai đầu, và AWS đặt tên cho từng đầu rất rõ ràng: một đầu nằm trong VPC, một đầu nằm ở mạng của khách hàng. Chỉ cần đọc kỹ vế "Amazon VPC side" là ba trong bốn phương án tự loại.

Cụm phụ "AWS managed VPN" cũng có vai trò: nó ám chỉ AWS lo phần thiết bị đầu cuối VPN ở phía cloud, nên người dùng không phải tự dựng thêm thiết bị mạng nào bên trong VPC.

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

Đáp án đúng theo tệp là A — A Virtual Private Gateway.

Virtual private gateway chính là VPN concentrator ở phía Amazon của kết nối VPN. Đây là thành phần AWS quản lý, bạn tạo nó rồi attach vào VPC mà bạn muốn thiết lập kết nối VPN tới. Không có virtual private gateway thì đầu AWS của đường hầm không có nơi để kết thúc, và kết nối Site-to-Site VPN không thể hình thành.

Nói cách khác, ánh xạ hai đầu như sau:

Đề hỏi đúng vế trên, nên câu trả lời là virtual private gateway.

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

B — A Customer Gateway. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. Customer gateway thật sự là một thành phần bắt buộc của Site-to-Site VPN — nhưng nó đại diện cho thiết bị vật lý hoặc phần mềm nằm ở phía bạn, tức là ở mạng on-premise, không phải trong VPC. Ai đọc lướt qua vế "Amazon VPC side" sẽ chọn nhầm B vì thấy nó cũng xuất hiện trong mọi tài liệu về VPN. Nó hỏng ở chỗ đứng sai phía của đường kết nối, chứ không phải ở chỗ vô dụng.

C — A Firewall. Firewall không phải là thành phần bắt buộc để thiết lập một AWS managed VPN. Bạn có thể có firewall vì lý do bảo mật riêng, nhưng nó không nằm trong danh sách cấu hình cần thiết để dựng kết nối VPN phía VPC. Chọn C là nhầm giữa "thứ nên có trong kiến trúc mạng nói chung" và "thứ đề bài hỏi: cấu hình bắt buộc của VPN".

D — A Network Address Translation device. NAT device cũng không cần cho AWS managed VPN. NAT trong AWS phục vụ mục đích khác hẳn: cho phép tài nguyên trong private subnet đi ra Internet mà không nhận kết nối vào từ Internet. Traffic của Site-to-Site VPN đi qua đường hầm mã hoá giữa hai mạng riêng, không đi qua Internet gateway theo kiểu cần NAT. Đây là phương án dễ loại nhất nếu nắm được NAT dùng để làm gì.

📌 Điểm cần nhớ

• Virtual private gateway = phía AWS; customer gateway = phía on-premise. Đây là cặp thuật ngữ bị hỏi đi hỏi lại trong đề Cloud Practitioner và Solutions Architect. Nhớ đúng hướng của từng cái là giải được cả nhóm câu.
• Với câu hỏi VPN, luôn tìm cụm chỉ phía nào của kết nối ("on the AWS side", "on your side", "on the customer network") — đó thường là ràng buộc duy nhất tách được hai phương án đều hợp lệ.
• Virtual private gateway phải được attach vào VPC thì mới có tác dụng; tạo ra mà để rời là chưa xong việc.
• Firewall và NAT device không là thành phần bắt buộc của AWS managed VPN. Đừng để những từ nghe "rất mạng" kéo mình khỏi danh sách thành phần thực sự của Site-to-Site VPN.

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

Đề hỏi: dịch vụ AWS nào phù hợp cho một event-driven workload (khối lượng công việc hướng sự kiện).

Cụm từ quyết định là "event-driven". Cả bốn phương án đều nằm quanh chủ đề compute, nên nếu chỉ đọc lướt "dịch vụ nào chạy được code" thì A, B, C đều có vẻ đúng — Elastic Beanstalk chạy được ứng dụng, EC2 chạy được mọi thứ. Ràng buộc phân biệt nằm ở chỗ: đề không hỏi "chạy được code hay không", mà hỏi mô hình thực thi có được kích hoạt bởi sự kiện hay không.

Event-driven nghĩa là: có một sự kiện xảy ra ở đâu đó (một object được upload lên S3, một message vào queue, một lời gọi API...) và sự kiện đó tự nó kích hoạt đoạn code chạy. Không có sự kiện thì không có gì chạy, và không có gì để trả tiền. Đây là cách phân loại chuẩn trong phần AWS Compute của kỳ thi Cloud Practitioner: server-based (EC2, Elastic Beanstalk) so với serverless/event-driven (Lambda).

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

B — AWS Lambda.

Lambda là dịch vụ event-driven đúng nghĩa: bạn viết một function, gắn nó với một event source, và AWS lo phần gọi function mỗi khi sự kiện phát sinh. Ví dụ kinh điển được chính tài liệu AWS dùng để minh hoạ: cấu hình event notification trên một Amazon S3 bucket, mỗi lần có dữ liệu được upload lên bucket thì một Lambda function được trigger để xử lý object vừa tới.

Điểm mấu chốt: với Lambda, bạn không có server nào đang chạy chờ sẵn. Không có sự kiện thì không có invocation. Đó chính là định nghĩa của event-driven, và đó là lý do nó là đáp án duy nhất khớp với cụm từ trong đề.

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

A — AWS Elastic Beanstalk. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất. Elastic Beanstalk có giúp bạn triển khai ứng dụng nhanh mà không phải tự dựng hạ tầng, nên nhiều người xếp nó chung nhóm "AWS lo hộ" với Lambda. Nhưng nó hỏng ở đúng chỗ đề hỏi: Elastic Beanstalk là dịch vụ triển khai và điều phối ứng dụng lên hạ tầng bên dưới (EC2, load balancer, auto scaling) — ứng dụng của bạn vẫn là một tiến trình chạy liên tục trên các instance đó, chứ không phải một hàm được đánh thức bởi sự kiện. "AWS quản lý hộ hạ tầng" ≠ "event-driven".

C — Amazon EC2. EC2 cung cấp virtual machine chạy liên tục cho tới khi bạn stop hoặc terminate. Mô hình của nó là server luôn bật, ứng dụng của bạn tự đứng đó lắng nghe; không có cơ chế nào của bản thân EC2 nói rằng "sự kiện X xảy ra thì khởi động đoạn code Y". Về mặt phân loại, EC2 là điển hình của server-based compute, ngược hẳn với event-driven.

D — Amazon Open 3D Engine. Sai hoàn toàn, không liên quan tới compute workload theo nghĩa của đề: đây là một game engine (engine phát triển game và mô phỏng 3D), không phải nơi bạn chạy backend workload hướng sự kiện. Đây là loại phương án nhiễu chỉ để lấp chỗ, nhận ra tên dịch vụ là loại được ngay.

📌 Điểm cần nhớ

• Thấy "event-driven", "triggered by", hoặc "chỉ chạy khi có sự kiện" trong phần AWS Compute → nghĩ tới AWS Lambda trước tiên. Đây là cặp từ khoá – dịch vụ ghép sẵn xuất hiện rất nhiều trong đề Cloud Practitioner.
• Phân biệt "AWS quản lý hộ" với "event-driven". Elastic Beanstalk là managed deployment nhưng vẫn chạy trên server luôn bật; chỉ Lambda mới bỏ hẳn khái niệm server đang chạy chờ.
• EC2 và Elastic Beanstalk cùng thuộc nhóm server-based, nên trong một câu hỏi chỉ chọn một đáp án, nếu hai phương án này cùng xuất hiện thì thường cả hai đều sai — đáp án nằm ở phương án còn lại khác nhóm.
• Ví dụ mẫu cần thuộc: S3 event notification → trigger Lambda function. Đây là minh hoạ chuẩn cho quan hệ event source → function, và tài liệu AWS dùng chính nó để giải thích khái niệm.