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

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

Đề mô tả một web application chạy trên nhiều EC2 instance nằm sau một Auto Scaling Group (ASG). Yêu cầu: hành động scaling phải bắt đầu ngay khi CPU utilization vượt ngưỡng 50% cho các instance đó.

Cụm từ quyết định đáp án là "as soon as CPU utilization crosses 50%". Nó gói hai ràng buộc cùng lúc:

• Tín hiệu kích hoạt là một metric thực tế (CPU utilization), chứ không phải thời gian, không phải dự báo.
• Phản ứng là tức thời và bị động — hệ thống chờ metric vượt ngưỡng rồi mới hành động.

Đây chính là định nghĩa của dynamic scaling, mà trong tài liệu AWS còn gọi là scaling on demand (scaling theo nhu cầu). Bốn phương án của đề thực chất là bốn kiểu scaling của ASG, nên việc phải làm chỉ là khớp đúng tín hiệu kích hoạt trong đề với đúng kiểu scaling.

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

Đáp án đúng: B — Configure ASG to scale based on demand.

Khi bạn cấu hình dynamic scaling (scaling on demand), bạn định nghĩa cách ASG thay đổi capacity để phản ứng với nhu cầu đang thay đổi. Cách làm là tạo một scaling policy gắn với một metric — ở đây là CPU utilization — và một ngưỡng mục tiêu, ví dụ giữ CPU utilization của cả nhóm quanh mức 50%.

Đúng như ví dụ trong tài liệu AWS: một web application đang chạy trên hai instance, bạn muốn CPU utilization của Auto Scaling group giữ quanh 50% khi tải thay đổi. Mức đó cho bạn phần dư để hấp thụ các đợt tăng đột biến mà không phải nuôi quá nhiều instance nằm không.

Với policy đó, EC2 Auto Scaling sẽ scale out (thêm instance) khi nhu cầu tăng cao vào giờ cao điểm, và scale in (bớt instance) khi mức sử dụng thấp để giảm chi phí. Đây là cách trực tiếp nhất đáp ứng đúng yêu cầu "bắt đầu ngay khi CPU vượt 50%".

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

A — Configure ASG to scale based on a schedule. Scaling theo lịch nghĩa là các hành động scaling được thực hiện tự động theo hàm của thời gian và ngày tháng. Nó hữu ích khi bạn biết chính xác khi nào cần tăng hoặc giảm số instance, vì nhu cầu đến theo một lịch dự đoán được. Nhưng đề không cho biết bất kỳ mốc giờ nào — điều kiện kích hoạt là ngưỡng CPU, mà CPU thì có thể vượt 50% vào bất cứ lúc nào. Cấu hình theo lịch sẽ hoàn toàn bỏ lỡ các đợt tăng tải ngoài lịch.

C — Configure ASG to scale based on events. Đây là phương án bịa, đưa vào chỉ để gây nhiễu. ASG không có kiểu scaling mang tên "scale based on events". Nghe hợp lý vì "CPU vượt ngưỡng" trực giác giống một "event", nhưng tên gọi chính thức của cơ chế đó vẫn là dynamic scaling / scaling on demand.

D — Configure ASG to use predictive scaling. Đây là phương án gần đúng nhất và cũng là bẫy chính. Predictive scaling là cách tiếp cận chủ động (proactive): nó dựa trên dữ liệu lịch sử để dự báo tải sắp tới và chuẩn bị capacity trước. Bạn có thể dùng EC2 Auto Scaling kết hợp với AWS Auto Scaling để phối hợp cả predictive scaling lẫn dynamic scaling (chủ động và bị động) nhằm scale nhanh hơn. Nhưng đề nói rõ hành động phải bắt đầu khi CPU thực sự vượt 50% — đó là phản ứng với metric hiện tại, tức là dynamic scaling. Predictive scaling không được kích hoạt bởi việc một ngưỡng CPU bị vượt qua, nên nó không diễn tả đúng yêu cầu. Scaling based on demand mới là cách trực tiếp đạt được yêu cầu này.

📌 Điểm cần nhớ

• Đọc tín hiệu kích hoạt trong đề để chọn kiểu scaling của ASG: metric vượt ngưỡng → dynamic scaling (on demand); mốc thời gian biết trước → scheduled scaling; dự báo từ dữ liệu lịch sử → predictive scaling.
• "Scaling on demand" và "dynamic scaling" là cùng một thứ trong tài liệu AWS — đề thi có thể dùng cách gọi nào cũng được, đừng để cách diễn đạt làm mất dấu.
• Cụm "as soon as" kèm một ngưỡng metric gần như luôn loại predictive scaling: predictive là chuẩn bị trước, không phải phản ứng ngay khi ngưỡng bị vượt.
• Dynamic scaling hoạt động hai chiều: scale out khi tải cao để giữ hiệu năng, scale in khi tải thấp để cắt chi phí — đúng tinh thần của domain tối ưu chi phí và hiệu năng.
• Cẩn thận với phương án nghe hợp lý nhưng không tồn tại như "scale based on events"; hãy đối chiếu với danh sách các kiểu scaling có thật của ASG.

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

Đề mô tả một tình huống vận hành rất cụ thể: công ty lưu dữ liệu trên Amazon S3 Glacier, các chu kỳ thanh toán trước đó luôn lấy dữ liệu về mà không mất phí retrieval, nhưng tháng vừa rồi lại xuất hiện khoản phí retrieval. Câu hỏi yêu cầu chỉ ra nguyên nhân nền tảng của hành vi này.

Cụm từ quyết định nằm ở chỗ so sánh giữa hai giai đoạn: "no charges for the earlier billing cycles" nhưng "some retrieval charges" ở tháng này. Nghĩa là cấu hình không đổi, dịch vụ không đổi, chỉ có khối lượng dữ liệu lấy về trong tháng là thay đổi. Điều đó loại ngay mọi phương án nói về cấu trúc tài khoản hay về một khuyến mãi có thời hạn — vì cả hai đều không giải thích được vì sao phí chỉ mới phát sinh đúng ở tháng có nhu cầu retrieval lớn hơn.

Thêm một chi tiết nữa: phí chỉ là "some" chứ không phải toàn bộ. Đây là dấu hiệu kinh điển của cơ chế free tier theo ngưỡng: phần dưới ngưỡng miễn phí, phần vượt ngưỡng mới tính tiền. Vậy câu hỏi thực chất chỉ còn là: ngưỡng miễn phí đó là bao nhiêu.

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

Phương án C — "You can retrieve 10 GB of your Amazon S3 Glacier data per month for free" là đáp án đúng.

S3 Glacier có một khoản free tier cho retrieval là 10 GB mỗi tháng. Hạn mức này:

• tính theo tháng, không phải một lần duy nhất, nên nó lặp lại đều đặn ở mọi chu kỳ thanh toán;
• áp dụng cho Standard retrievals;
• dùng lúc nào trong tháng cũng được, không bị ràng buộc vào một mốc thời gian cố định.

Ghép với tình huống trong đề: những tháng trước công ty lấy về dưới ngưỡng miễn phí nên hoá đơn không có dòng retrieval nào. Tháng vừa rồi họ lấy vượt ngưỡng đó, và phần vượt bị tính phí. Đây chính là lý do hoá đơn chỉ có một phần phí chứ không phải bị tính từ byte đầu tiên — đúng như từ "some" trong đề gợi ý.

Về mặt định vị dịch vụ, S3 Glacier và S3 Glacier Deep Archive là các storage class rẻ nhất của Amazon S3, thiết kế cho lưu trữ dài hạn khối lượng lớn: trả tiền theo mức dùng, không cam kết tối thiểu, không phí trả trước. Retrieval là thao tác ngoại lệ trong mô hình đó, nên nó được cho một hạn mức miễn phí nhỏ thay vì miễn phí hoàn toàn.

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

A — "Tài khoản AWS giữ tài nguyên S3 Glacier là thành viên của nhiều hơn một AWS Organization" Phát biểu này sai ngay ở mức khái niệm, không cần bàn tới chuyện nó có gây phí hay không: một AWS account tại một thời điểm chỉ có thể thuộc đúng một organization. Muốn chuyển sang organization khác thì phải rời cái cũ trước. Ngoài ra, tư cách thành viên organization liên quan tới consolidated billing và quản trị chính sách, chứ không phải nguyên nhân sinh ra phí retrieval của Glacier.

B — "S3 Glacier miễn phí retrieval trong ba tháng kể từ khi bắt đầu dùng dịch vụ" Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì nó cũng giải thích được mô hình "trước miễn phí, giờ mất tiền". Chỗ hỏng của nó là hiểu sai bản chất ưu đãi: free tier retrieval của Glacier là hạn mức theo dung lượng, lặp lại hằng tháng, không phải một cửa sổ thời gian dùng một lần rồi hết. Nếu B đúng thì sau khi hết ba tháng, mọi lần retrieval đều phải tính phí, và hoá đơn sẽ không còn chỗ cho chữ "some". Đề bài cũng không hề nhắc tới thời điểm công ty bắt đầu dùng dịch vụ — dữ kiện bắt buộc phải có nếu B là nguyên nhân.

D — "Miễn phí retrieval 5 GB mỗi tháng" Phương án này đúng về cơ chế nhưng sai về con số. Nó nhận ra rằng có một hạn mức miễn phí lặp lại hằng tháng — tức là đã đi đúng hướng suy luận — nhưng ghi sai mức hạn ngạch. Free tier retrieval của S3 Glacier là 10 GB mỗi tháng, không phải 5 GB. Đây là kiểu phương án nhiễu điển hình: đặt cạnh đáp án đúng một con số nhỏ hơn để buộc thí sinh phải nhớ chính xác chứ không chỉ nhớ nguyên lý.

📌 Điểm cần nhớ

• S3 Glacier có free tier retrieval 10 GB/tháng, áp dụng cho Standard retrievals, dùng bất cứ lúc nào trong tháng. Đây là con số cần thuộc, vì đề rất hay đặt 5 GB cạnh 10 GB làm nhiễu.
• Hạn mức miễn phí này là định kỳ theo tháng, không phải khuyến mãi có thời hạn cho tài khoản mới — phân biệt được hai kiểu ưu đãi này là loại ngay được cả một nhóm phương án.
• Khi đề nói phí chỉ mới phát sinh dù cấu hình không đổi, hãy nghĩ tới ngưỡng free tier bị vượt trước khi nghĩ tới thay đổi kiến trúc hay quản trị tài khoản. Chữ "some charges" (một phần, không phải toàn bộ) là dấu hiệu của mô hình tính phí theo phần vượt ngưỡng.
• Một AWS account chỉ thuộc một AWS Organization tại một thời điểm. Bất kỳ phương án nào giả định account nằm trong nhiều organization đều loại được ngay, ở mọi đề.
• Với storage class lưu trữ lạnh, chi phí dịch chuyển từ lưu trữ sang truy xuất: lưu rất rẻ nhưng retrieval mới là chỗ sinh tiền — nên câu hỏi về hoá đơn Glacier thường xoay quanh retrieval chứ không phải dung lượng lưu.

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

Đề mô tả một ngân hàng đang có on-premise key store (kho khoá mã hoá đặt tại chỗ) và muốn chuyển nó lên cloud. Câu hỏi cuối cùng chỉ đơn giản là "nên dùng dịch vụ nào".

Cụm từ quyết định nằm ở giữa đề: "the keys were isolated on a self-managed encryption module for compliance reasons" — khoá phải nằm cô lập trên một module mã hoá do chính khách hàng tự quản lý, và lý do là tuân thủ (compliance).

Hai chữ self-managed là điểm phân biệt. Đề không hỏi "cách nào dễ nhất để mã hoá dữ liệu", cũng không hỏi "cách nào rẻ nhất" — nếu hỏi vậy thì KMS hay S3 SSE đều hợp lý. Đề hỏi cách nào cho phép ngân hàng tự sở hữu và tự vận hành phần cứng mã hoá, tức là tự tạo user trên module, tự đặt quyền, tự sinh và giữ khoá. Đây chính là ranh giới kinh điển giữa CloudHSM và KMS trong các đề thi AWS.

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

D — CloudHSM.

AWS CloudHSM là dịch vụ cung cấp hardware security module (HSM) trên cloud. HSM là thiết bị chuyên dụng để sinh và lưu trữ khoá mã hoá, cô lập khoá bên trong ranh giới phần cứng của nó.

Điểm cốt lõi khớp với đề: với CloudHSM, bạn là người quản lý HSM, không phải AWS. Bạn tự tạo HSM, tự tạo user trên đó và đặt quyền cho họ, tự sinh khoá đối xứng và cặp khoá bất đối xứng mà HSM sẽ lưu. Đó đúng nghĩa "self-managed encryption module" mà đề yêu cầu.

Đây cũng là lựa chọn tự nhiên khi chuyển một on-premise key store lên cloud: mô hình vận hành gần như giữ nguyên — vẫn là một thiết bị HSM mà tổ chức tự kiểm soát, chỉ khác là nó chạy trong tài khoản AWS thay vì trong phòng máy của ngân hàng. Với ngành ngân hàng, việc chứng minh được khoá nằm cô lập trên module riêng và chỉ đội ngũ của mình chạm tới được là yêu cầu compliance thường gặp.

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

C — KMS. Đây là phương án gần đúng nhất và là bẫy chính của câu này. KMS cũng cho tạo, lưu và quản lý customer master key (CMK) một cách an toàn; CMK không bao giờ rời KMS ở dạng chưa mã hoá, và mọi thao tác mã hoá đều phải gọi vào KMS. Nền tảng bên dưới KMS cũng là HSM đã được kiểm định FIPS.

Nó hỏng ở đúng chữ self-managed: KMS không cho bạn quản lý HSM. AWS vận hành hạ tầng đó, bạn chỉ làm việc với khoá ở tầng dịch vụ, không tạo được user trên module, không sở hữu module. Nguyên tắc phân biệt: cần bảo vệ khoá bằng HSM đã kiểm định FIPS nhưng không cần tự quản lý HSM → KMS; cần tự quản lý HSM → CloudHSM. Đề đã nói rõ vế thứ hai.

A — S3 SSE. Server-side encryption của S3 bảo vệ dữ liệu ở trạng thái nghỉ trong S3: mỗi object được mã hoá bằng một khoá riêng, khoá đó lại được mã hoá bằng một master key và được xoay định kỳ, dùng thuật toán AES-256. Nhưng đây là cơ chế mã hoá cho một dịch vụ lưu trữ cụ thể, không phải một key store để thay thế kho khoá on-premise của ngân hàng. Và quan trọng hơn: S3 SSE không cung cấp module mã hoá tự quản lý nào cả. Đề đang nói về nơi cất giữ khoá, không nói về việc mã hoá object trong bucket.

B — GuardDuty. Lệch hoàn toàn chủ đề. GuardDuty là dịch vụ phát hiện mối đe doạ, theo dõi hoạt động độc hại và hành vi trái phép trong tài khoản AWS bằng cách phân tích CloudTrail (hoạt động của user và API), VPC Flow Logs (lưu lượng mạng) và DNS logs. Nó không quản lý khoá, không lưu khoá, không mã hoá gì cả. Có gắn GuardDuty vào cũng chẳng giải quyết được yêu cầu cô lập khoá trên module riêng.

📌 Điểm cần nhớ

• Thấy "self-managed HSM", "tự quản lý module mã hoá", "sở hữu/kiểm soát phần cứng mã hoá", hoặc "chuyển key store on-premise lên cloud" → nghĩ ngay CloudHSM.
• Thấy "muốn HSM đã kiểm định FIPS nhưng không muốn tự vận hành", "quản lý CMK", tích hợp sẵn với các dịch vụ AWS → nghĩ KMS. Ranh giới giữa hai dịch vụ này là ai quản lý HSM, không phải có HSM hay không.
• Phân biệt rõ nơi giữ khoá (KMS, CloudHSM) với cơ chế mã hoá dữ liệu của một dịch vụ (S3 SSE). Đề hỏi về key store thì đừng chọn tính năng mã hoá của một kho lưu trữ.
• GuardDuty là threat detection, không liên quan tới quản lý khoá hay mã hoá — gặp nó trong câu hỏi về key management thì loại ngay.

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

Tình huống: một AWS Storage Gateway đang chạy, đội phát triển báo rằng phần cache disk chỉ dùng chưa tới 50% dung lượng. Yêu cầu là tối ưu chi phí, tức là muốn co nhỏ phần cache đang thừa lại.

Cụm từ quyết định đáp án là "cache disk" — chứ không phải "upload buffer". Cả bốn phương án đều xoay quanh việc gỡ đĩa, đổi đĩa hoặc giảm kích thước, và điểm phân biệt duy nhất giữa chúng là loại đĩa local nào của gateway đang bị đụng tới. Storage Gateway có hai loại đĩa local với luật vận hành khác hẳn nhau:

• Cache disk: đã cấp cho gateway rồi thì không giảm kích thước được, và không được gỡ ra.
• Upload buffer disk: có quy trình hợp lệ để gỡ và cấp lại đĩa nhỏ hơn (phải tắt gateway trước).

Đề nói rõ là cache disk thừa dung lượng, nên mọi phương án mô tả đúng quy trình của upload buffer đều là bẫy.

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

A — Create a new gateway with the cache space that you need.

Khi một đĩa đã được cấp làm cache disk cho gateway, AWS không hỗ trợ thu nhỏ nó. Không có thao tác "resize cache disk" nào ở phía gateway, và việc rút đĩa cache ra khỏi gateway đang chạy có thể làm hỏng chức năng của gateway (cache chính là nơi giữ dữ liệu đọc/ghi gần đây trước khi đồng bộ, không phải chỗ vứt đi tuỳ ý).

Vì vậy con đường được AWS mô tả là: tạo một gateway mới với đúng dung lượng cache mình cần, rồi migrate dữ liệu sang gateway mới. Cách này giữ nguyên tính toàn vẹn dữ liệu và đạt được mục tiêu tiết kiệm chi phí — chỉ khác là chi phí bỏ ra là công sức chuyển đổi chứ không phải một nút bấm.

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

B — Remove the disk(s) allocated as cache disks và resize về dung lượng cần. Đây là phương án gần đúng nhất về mặt "ý định", vì nó đúng thứ người dùng muốn làm. Nhưng nó hỏng ở chỗ thao tác: gỡ đĩa đang được cấp làm cache của một gateway hiện hữu là việc AWS khuyến cáo không làm vì có thể phá vỡ hoạt động của gateway, và bản thân cache disk cũng không thu nhỏ được sau khi đã cấp. Phương án mô tả một thao tác không tồn tại và đồng thời rủi ro.

C — Tắt gateway trước rồi mới gỡ đĩa cache và gắn đĩa khác. Đây là bẫy tinh vi nhất, vì quy trình mô tả hoàn toàn đúng — nhưng cho loại đĩa khác. Với đĩa được cấp làm upload buffer, đúng là phải tắt gateway trước, gỡ đĩa upload buffer ra, rồi cấp một đĩa mới với dung lượng nhỏ hơn. Việc tắt máy trước không "hợp thức hoá" thao tác này cho cache disk: giới hạn không nằm ở chỗ gateway đang chạy, mà nằm ở chỗ cache disk không được thiết kế để gỡ/thu nhỏ. Đề hỏi về cache disk, nên C sai.

D — Giảm dung lượng thừa trên cache disk bằng cách giảm upload buffer size từ Storage Gateway console. Phương án này tự mâu thuẫn: nó lấy hành động trên upload buffer để giải quyết vấn đề của cache disk, hai thứ tách biệt nhau. Đây là lựa chọn bịa ra làm nhiễu, không tương ứng với thao tác thật nào trên console.

📌 Điểm cần nhớ

• Storage Gateway có hai loại đĩa local — cache disk và upload buffer — và luật vận hành của chúng khác nhau. Đọc đề phải bắt đúng chữ nào đang được nhắc tới; đó thường là toàn bộ mấu chốt của câu hỏi.
• Cache disk đã cấp thì không thu nhỏ được và không nên gỡ ra; muốn ít cache hơn thì tạo gateway mới với dung lượng mong muốn rồi migrate dữ liệu.
• Upload buffer thì giảm được, nhưng phải tắt gateway trước khi gỡ đĩa rồi mới cấp đĩa mới nhỏ hơn.
• Trong đề trắc nghiệm, một phương án mô tả quy trình chính xác vẫn có thể sai nếu nó áp dụng cho đối tượng khác với đối tượng đề hỏi — hãy kiểm tra "quy trình này dành cho cái gì" trước khi kiểm tra "quy trình này có đúng không".

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

Đề mô tả một EC2 instance đã bị AWS Config rule đánh dấu non-compliant. Sau đó có một lần periodic rule evaluation nữa chạy, và tài nguyên vẫn tiếp tục ở trạng thái non-compliant. Câu hỏi: kết quả của lần đánh giá định kỳ này là gì?

Cụm từ quyết định đáp án là "the resource continues to be in a non-compliant state" — nghĩa là trạng thái tuân thủ không thay đổi giữa hai lần đánh giá. Đó chính là ràng buộc phân biệt các phương án: câu hỏi không hỏi rule có chạy hay không, mà hỏi việc thông báo có được gửi đi hay không khi trạng thái đứng yên.

Nguyên lý cần nhớ: AWS Config gửi notification khi có thay đổi trạng thái compliance, chứ không phải sau mỗi lần đánh giá.

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

B — AWS Config will not send a new notification.

AWS Config chỉ phát notification khi compliance status đổi. Tài nguyên trước đó đã là non-compliant, lần đánh giá định kỳ này kết luận vẫn non-compliant — không có chuyển trạng thái nào xảy ra, nên Config không sinh thông báo mới. Nếu tài nguyên chuyển sang compliant (hoặc từ compliant sang non-compliant), lúc đó mới có notification cho thay đổi trạng thái.

Điểm quan trọng: rule vẫn chạy và vẫn đánh giá tài nguyên như thường; thứ bị bỏ qua chỉ là notification. Hai chuyện này tách bạch — đánh giá diễn ra đều đặn, thông báo thì phụ thuộc vào việc có delta hay không.

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

A — "Once a resource is marked non-compliant, the Config rule will not run on the resource again till the state changes" Đây là phương án gần đúng nhất vì nó cũng mô tả "không có gì xảy ra", nhưng nó hỏng ở chỗ nhầm lẫn giữa đánh giá và thông báo. Config rule tiếp tục được đánh giá trên tài nguyên đó theo đúng chu kỳ periodic. Hơn nữa, lập luận trong phương án này tự mâu thuẫn: nếu rule ngừng chạy cho tới khi state đổi, thì sẽ không bao giờ có gì phát hiện ra state đã đổi.

C — "AWS Config will send a notification with the current status of the resource" Đây là bẫy trực tiếp của câu hỏi. Nó giả định Config báo cáo trạng thái sau mỗi lần đánh giá, kiểu heartbeat. Thực tế Config chỉ báo khi trạng thái thay đổi. Nếu hoạt động theo kiểu phương án này thì một tài nguyên non-compliant lâu dài sẽ tạo ra dòng notification lặp lại vô tận sau mỗi chu kỳ.

D — "AWS Config will not record configuration changes that did not result from API activity on the resource. Hence, the Config rule is not triggered" Sai ngay ở tiền đề. AWS Config có ghi nhận các configuration change không xuất phát từ API activity trên tài nguyên. Ngoài ra phương án này còn lạc đề: câu hỏi nói về periodic evaluation — loại đánh giá chạy theo lịch định kỳ, không phụ thuộc vào việc có configuration change nào hay không. Lập luận "không có API activity nên rule không được trigger" chỉ liên quan tới rule kiểu change-triggered, mà đề đã nói rõ đây là periodic.

📌 Điểm cần nhớ

• AWS Config gửi notification theo thay đổi trạng thái compliance, không phải theo mỗi lần đánh giá. Non-compliant → vẫn non-compliant = im lặng.
• Phân biệt rõ hai khái niệm hay bị trộn trong đề thi: rule có được đánh giá hay không (vẫn chạy) và có notification hay không (chỉ khi đổi trạng thái).
• Config rule có hai kiểu trigger: periodic (chạy theo lịch, độc lập với thay đổi cấu hình) và change-triggered (chạy khi có configuration change). Đề nhắc "periodic" là để loại các phương án lập luận dựa trên configuration change/API activity.
• AWS Config ghi nhận configuration change kể cả khi thay đổi đó không đến từ API activity trên tài nguyên — đừng tin các phương án khẳng định ngược lại.

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

Đề mô tả một tình huống rất cụ thể: SysOps Administrator không launch được EC2 instance từ một AMI đã mã hoá (encrypted AMI) khi dùng Amazon EC2 Auto Scaling, dù IAM identity dùng để tạo Auto Scaling group đã có administrator permissions.

Cụm từ quyết định đáp án là "IAM identities used to create the Amazon EC2 Auto Scaling has administrator permissions". Câu này cố tình loại bỏ giả thuyết "thiếu quyền phía người dùng". Khi Auto Scaling launch instance, nó không dùng quyền của người tạo group mà dùng service-linked role (SLR) của chính dịch vụ EC2 Auto Scaling. Vì vậy quyền admin của người dùng có mạnh tới đâu cũng không giúp gì cho lời gọi KMS xảy ra trong lúc scale-out.

Cụm từ thứ hai là "encrypted AMI" — AMI mã hoá nghĩa là snapshot EBS phía sau nó được mã hoá bằng một KMS key, và việc launch instance đòi hỏi quyền Decrypt/CreateGrant trên key đó. Bài toán rút gọn thành: key đó thuộc loại nào, và SLR của Auto Scaling có được phép dùng key đó không.

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

Đáp án đúng là B — AMI có thể đã được mã hoá bằng customer-managed CMK, phải cấp thêm quyền cho Auto Scaling group.

EC2 Auto Scaling gọi các dịch vụ khác thay mặt bạn thông qua service-linked role. Quyền của SLR này do AWS định sẵn (hardcoded) và bạn không sửa được policy của nó. Trong tập quyền mặc định đó không bao gồm quyền truy cập customer-managed CMK. Đó chính là lý do launch thất bại: instance cần decrypt snapshot của AMI, mà SLR không có grant trên key.

Cách sửa nằm ở phía key policy của KMS key, không phải ở phía IAM role: bạn sửa key policy để cho phép SLR của Auto Scaling dùng key đó. Có hai lựa chọn SLR:

• AWSServiceRoleForAutoScaling — role mặc định của tài khoản, tự gán cho mọi Auto Scaling group nếu không chỉ định gì khác.
• AWSServiceRoleForAutoScaling_mysuffix — role có hậu tố tuỳ chọn, quyền y hệt role mặc định, chỉ khác cái tên.

Nếu muốn cấp quyền chi tiết cho từng key cụ thể, nên dùng role có custom suffix: nó cho phép kiểm soát chặt hơn từng CMK và cho phép truy ra Auto Scaling group nào đã gọi API trong CloudTrail log.

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

A — AMI mã hoá bằng AWS-managed CMK, cần cấp thêm quyền. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi: nó chỉ khác đáp án đúng đúng một chữ (AWS-managed thay vì customer-managed). Bạn hoàn toàn có thể dùng AWS managed CMK để mã hoá EBS volume hoặc AMI với EC2 Auto Scaling — nhưng với loại key này Auto Scaling không cần quyền bổ sung nào cả. Nói cách khác, phần chẩn đoán ("cần thêm quyền") mâu thuẫn với loại key được nêu, nên phương án tự phủ định chính nó.

C — Auto Scaling group cần service-linked role để truy cập KMS, hãy tạo SLR. Sai ở giả định nền: SLR là bắt buộc để tạo được Auto Scaling group ngay từ đầu. Nếu chưa có SLR thì group đã không tồn tại, chứ không phải tồn tại rồi mới hỏng lúc launch. Đề nói rõ Auto Scaling đã được tạo và đang chạy, nên SLR chắc chắn đã có. Vấn đề không phải "thiếu role" mà là "role đã có nhưng key policy không cho phép nó".

D — SLR của ASG có thể đã bị xoá, kiểm tra xem role còn không. Sai vì AWS không cho phép xoá SLR khi vẫn còn tài nguyên phụ thuộc. Muốn xoá AWSServiceRoleForAutoScaling (hoặc bản có suffix), bạn phải xoá hết các Auto Scaling group đang dùng nó trước. Đây là cơ chế bảo vệ có chủ đích để bạn không vô tình tước quyền của EC2 Auto Scaling lên tài nguyên đang chạy. Vì Auto Scaling group trong đề vẫn tồn tại, kịch bản "role bị xoá" là không thể xảy ra.

📌 Điểm cần nhớ

• Quyền của người tạo resource ≠ quyền lúc dịch vụ chạy. EC2 Auto Scaling launch instance bằng service-linked role của nó, nên "IAM user có administrator permissions" là chi tiết dùng để loại trừ, không phải để giải thích lỗi.
• AWS-managed CMK vs customer-managed CMK là ranh giới phân biệt kinh điển trong đề thi. Với AWS managed key, dịch vụ dùng được ngay; với customer-managed key, bạn phải tự mở đường trong key policy.
• Policy của service-linked role không sửa được. Khi SLR thiếu quyền lên một CMK, chỗ sửa luôn là key policy của KMS key, không phải IAM policy của role.
• Service-linked role không thể bị xoá khi còn tài nguyên phụ thuộc, và nó bắt buộc phải tồn tại thì Auto Scaling group mới tạo được — hai sự thật này giết luôn mọi phương án kiểu "role chưa có" hoặc "role đã bị xoá".
• Role mặc định và role có custom suffix có quyền giống hệt nhau; chọn bản custom suffix khi cần phân quyền chi tiết theo từng CMK và cần truy vết trong CloudTrail.

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

Tình huống: Account A sở hữu một S3 bucket và đã cho phép các AWS account khác upload object vào bucket đó. Giờ chủ bucket muốn cấp quyền trên tất cả object trong bucket cho một account thứ ba là Account B.

Cụm từ quyết định nằm ở chỗ "has enabled other AWS accounts to upload objects" — tức là object trong bucket do account khác tạo ra, không phải do chủ bucket tạo. Đây chính là ranh giới mà câu hỏi nhắm tới: trong mô hình quyền cổ điển của S3, người sở hữu bucket không mặc nhiên sở hữu object mà account khác upload lên. Nếu đọc lướt và mặc định "bucket của tôi thì object trong đó là của tôi", bạn sẽ chọn ngay phương án C và trượt.

Cụm thứ hai cần để ý là "to another AWS account B" — đích được cấp quyền là một AWS account khác, chứ không phải một IAM user trong chính account của chủ bucket. Chi tiết này loại phương án D.

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

E — "The bucket owner has no permissions on those objects created by other AWS accounts": đây là nguyên lý gốc của tình huống. Object do account khác upload thuộc quyền sở hữu của account đã tạo ra nó; chủ bucket chỉ sở hữu bucket, còn với các object đó thì mặc định không có quyền và cũng không phải chủ sở hữu.

A — "The AWS account that created the objects must first grant permission to the bucket owner for delegating permissions to other entities": hệ quả trực tiếp của E. Bạn không thể cấp đi thứ quyền mình không có. Vì vậy để chủ bucket cấp quyền trên các object đó cho Account B, object owner (account đã upload) phải cấp quyền cho chủ bucket trước; sau đó chủ bucket mới có thể delegate tiếp phần quyền đó.

Hai phương án này ghép thành một chuỗi hoàn chỉnh: E nêu trạng thái ban đầu, A nêu bước phải làm để gỡ trạng thái đó.

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

B — "The root user has access to all objects created under it. Use root user to delegate necessary permissions": sai ở hai tầng. Về nguyên tắc vận hành, AWS khuyến nghị không dùng root user cho công việc hằng ngày, kể cả việc quản trị — root chỉ dành cho một số ít tác vụ quản lý account và service. Về mặt kỹ thuật, root user của account chủ bucket cũng không có quyền trên object do một AWS account khác tạo, nên nó cũng không delegate được. Phương án này giải quyết vấn đề bằng một thứ quyền không tồn tại.

C — "The bucket owner is the owner of all objects in the bucket, irrespective of the AWS account that uploaded the objects": đây là phương án bẫy nặng nhất vì nghe rất hợp trực giác. Nó mâu thuẫn trực tiếp với E: chủ bucket không là chủ sở hữu của object do account khác upload lên. Chính vì mệnh đề này sai mà toàn bộ câu hỏi mới tồn tại.

D — "The owner should provide cross-account delegation to users in other AWS accounts": gần đúng nhất trong nhóm sai, vì nó có nhắc tới delegation — đúng hướng. Chỗ hỏng nằm ở đích của việc delegate: account chủ bucket chỉ có thể delegate quyền cho user trong chính account của mình, chứ không delegate được sang một AWS account khác — cross-account delegation kiểu này không được hỗ trợ. Nói cách khác D vừa nhầm đối tượng, vừa bỏ qua bước tiên quyết mà A nêu ra (phải được object owner cấp quyền trước đã).

📌 Điểm cần nhớ

• Quyền sở hữu object trong S3 gắn với account đã upload, không gắn với chủ bucket. Đề bài nào có chi tiết "account khác upload vào bucket của tôi" thì đây gần như luôn là điểm mấu chốt.
• Không ai delegate được quyền mình không có. Chuỗi đúng là: object owner cấp quyền cho bucket owner → bucket owner mới delegate tiếp.
• Phân biệt rõ delegate cho IAM user trong cùng account với cấp quyền sang một AWS account khác — hai việc khác nhau, và phương án đánh tráo hai khái niệm này là bẫy quen thuộc.
• Root user không phải "chìa khoá vạn năng". Nó không vượt qua được ranh giới account, và trong mọi câu hỏi về best practice thì "dùng root user để làm việc thường ngày" gần như luôn là phương án sai.

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

Đề đặt một tình huống rất quen: SysOps Administrator phải viết bucket policy cho S3 để nhóm phát triển có quyền read-only trên các bucket của dự án. Câu hỏi không kiểm tra kiến trúc, nó kiểm tra cú pháp của IAM/S3 policy language — bạn có phân biệt được phần tử nào hợp lệ, tên action nào có thật hay không.

Cụm từ quyết định là "read-only access permissions" kết hợp với "the correct JSON policy". Hai vế này ép ba tiêu chí lên bốn phương án:

1. Effect phải là giá trị hợp lệ và phải là Allow (read-only vẫn là cho phép, chỉ là cho phép ít thao tác).
2. Action phải là tên action có thật trong không gian tên s3:.
3. Resource phải trỏ tới đúng thứ mà action đó tác động — và đây là chỗ tinh vi nhất: đọc nội dung object với đọc danh sách bucket là hai ARN khác nhau.

Bốn phương án khác nhau ở đúng ba trục đó, nên chỉ cần soi từng phần tử là loại được.

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

Đáp án đúng theo tệp là A:

• Effect: "Allow" — viết đúng chính tả và đúng ý nghĩa. Trong policy language chỉ có hai giá trị Allow và Deny; không cấp quyền tường minh thì mặc định là bị từ chối ngầm.
• Principal: "*" — trong bucket policy (policy gắn vào tài nguyên) bắt buộc phải có Principal để nói ai là người nhận quyền. Dấu * nghĩa là mọi principal.
• Action: ["s3:GetObject", "s3:ListBucket"] — cả hai đều là action có thật và đủ bộ cho nhu cầu "đọc": ListBucket để liệt kê object có trong bucket, GetObject để tải nội dung object về. Thiếu một trong hai thì hoặc thấy mà không đọc được, hoặc đọc được mà không biết có gì.
• Resource liệt kê cả hai ARN: ...:::mybucket (chính cái bucket, dành cho ListBucket) và ...:::mybucket/* (mọi object bên trong, dành cho GetObject). Đây chính là điểm tách A khỏi B: action cấp bucket và action cấp object không dùng chung một ARN.

(Lưu ý: các phương án trong đề viết tiền tố urn:aws:s3:::; định dạng ARN thật của AWS là arn:aws:s3:::. Đây là lỗi đánh máy của nguồn đề, có ở cả bốn phương án nên không dùng để phân biệt được — cứ chấm theo ba trục Effect/Action/Resource.)

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

B — sai vì action không tồn tại, và Resource cũng thiếu. s3:ReadObject không phải một action của S3; thao tác đọc nội dung object tên là s3:GetObject. Policy chứa action không có thật thì phần đó đơn giản là không khớp với request nào cả. Ngoài ra Resource của B chỉ có ...:::mybucket, không có /*, nên kể cả khi sửa tên action thành GetObject thì vẫn không đọc được object nào. Đây là phương án gần đúng nhất — Effect và Principal đều chuẩn — nhưng hỏng ở đúng hai chỗ mà câu hỏi muốn kiểm tra.

C — sai vì Effect ngược ý đề, Principal hỏng, và có action không tồn tại. Ba lỗi chồng lên nhau: Effect: "deny" là từ chối, trong khi đề cần cấp quyền đọc — dù deny là giá trị hợp lệ về mặt ngữ nghĩa, nó không bao giờ tạo ra quyền. Principal: "." không phải cách khai principal (dấu . không đại diện cho ai). Và s3:GetBucket không phải action có thật — thao tác liệt kê nội dung bucket tên là s3:ListBucket.

D — sai ngay ở giá trị của Effect. Effect: "read-only" không hợp lệ; policy language chỉ chấp nhận Allow hoặc Deny. "Read-only" là mô tả ý định, và ý định đó phải được diễn đạt bằng cách Allow một tập action chỉ-đọc, chứ không phải viết thẳng vào Effect. Đây là bẫy cố ý nhắm vào người đọc lướt: Action của D thực ra đúng, nhưng Principal: "*.*" cũng là cú pháp bịa, và một policy sai giá trị Effect thì không parse được — sai một phần tử bắt buộc là hỏng cả statement.

📌 Điểm cần nhớ

• Effect chỉ có hai giá trị: Allow và Deny. Mọi biến thể kiểu read-only, read, permit đều là phương án bịa — thấy là loại ngay, không cần đọc tiếp.
• Thuộc lòng tên action hay bị chế lại. Đúng: s3:GetObject, s3:ListBucket, s3:PutObject. Bịa: s3:ReadObject, s3:GetBucket, s3:ReadBucket. Đề trắc nghiệm rất hay đổi động từ để tạo phương án nhiễu.
• Action cấp bucket và action cấp object cần ARN khác nhau. ListBucket khớp với arn:aws:s3:::bucket, còn GetObject khớp với arn:aws:s3:::bucket/*. Muốn vừa liệt kê vừa đọc thì Resource phải có cả hai dòng.
• Bucket policy bắt buộc có Principal (khác với identity-based policy gắn vào user/role — loại đó không khai Principal). "*" là mọi principal; các dạng như "." hay "*.*" không có nghĩa gì.
• Read-only = Allow một tập action hẹp, không phải Deny. Deny chỉ dùng để cắt bớt quyền đã được cấp ở nơi khác, tự nó không bao giờ tạo ra quyền truy cập.

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

Một công ty digital marketing bị traffic độc hại tấn công, ứng dụng được phục vụ qua Amazon CloudFront. Họ muốn hai thứ cùng lúc:

1. Chặn traffic độc hại ở tầng web, bảo vệ hạ tầng phía sau (EC2 instances, database).
2. Nhân bản cùng một bộ quy tắc bảo mật đó sang nhiều AWS account mà công ty đang giữ.

Cụm từ quyết định đáp án nằm ở vế thứ hai: "replicate the same security processes across multiple AWS accounts" cộng với "quickly implemented and replicated". Đề không hỏi "dịch vụ nào chặn được request xấu" — nếu chỉ vậy thì có tới ba phương án nhắc tới WAF. Đề hỏi cặp dịch vụ: một cái thực thi luật (enforcement) và một cái quản lý tập trung luật đó trên nhiều account. Chữ "manually exporting" / "exported out" trong các phương án sai là cái bẫy đối lập trực tiếp với chữ "quickly" — xuất cấu hình bằng tay không phải là cơ chế nhân bản mà đề muốn.

Điểm mấu chốt thứ hai: WAF gắn được vào đâu. Đây là thứ phân biệt phương án C với phương án D.

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

Đáp án đúng theo tệp là D — Configure AWS WAF on CloudFront, dùng AWS Firewall Manager để nhân bản và quản lý cấu hình WAF trên nhiều AWS account.

AWS WAF là web application firewall giám sát request HTTP/HTTPS được chuyển tới các resource được hỗ trợ, trong đó có CloudFront distribution, Amazon API Gateway REST API, Application Load Balancer và AWS AppSync GraphQL API. Vì ứng dụng của công ty đang phục vụ qua CloudFront, gắn WAF ngay tại CloudFront là đúng chỗ: request xấu bị chặn ở biên, trước khi đi tiếp về EC2 và database phía sau — đúng yêu cầu "keep the AWS infrastructure safe".

WAF cho phép chọn hành vi: allow tất cả trừ những gì bạn chỉ định, block tất cả trừ những gì bạn chỉ định, hoặc count request khớp điều kiện để kiểm chứng luật trước khi thực sự chặn (tránh lỡ tay block toàn bộ traffic).

Vế nhân bản do AWS Firewall Manager lo. Đây là dịch vụ quản lý bảo mật tích hợp với AWS Organizations, cho phép cấu hình và quản lý tập trung các luật firewall trên toàn bộ account và ứng dụng từ một administrator account duy nhất. Nó bật được AWS WAF rules, AWS Shield Advanced, security groups và AWS Network Firewall rules cho VPC trên nhiều account. Quan trọng hơn: khi có ứng dụng hoặc resource mới, Firewall Manager tự đưa chúng vào diện tuân thủ bộ luật chung — nghĩa là nhân bản diễn ra tự động, không cần export tay.

Ghép lại: WAF thực thi trên CloudFront, Firewall Manager quản lý và trải rộng — đúng cả hai vế của đề.

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

A — Security Group trên CloudFront, export sang account khác. Sai ngay ở tiền đề kỹ thuật. Security Group là virtual firewall cho EC2 instance, kiểm soát traffic vào/ra ở tầng network của instance. CloudFront không hỗ trợ security group — không có chỗ nào để gắn. Ngoài ra Security Group không phải công cụ lọc theo nội dung request web, và "export sang account khác" cũng không phải cơ chế nhân bản tập trung mà đề đòi.

B — Firewall Manager tạo "secure barrier" trên CloudFront, export cấu hình bằng tay. Đây là phương án gần đúng nhất và hỏng ở chỗ đảo vai trò hai dịch vụ. Chính AWS WAF mới là thứ dựng hàng rào lọc request trên CloudFront; Firewall Manager không tự nó là firewall, nó là lớp quản lý tập trung các luật. Nói cách khác, phương án B có đúng dịch vụ quản lý nhưng thiếu hẳn dịch vụ thực thi. Vế thứ hai còn sai thêm một lần nữa: Firewall Manager tích hợp AWS Organizations nên luật lan sang các account tự động — không có nhu cầu export cấu hình bằng tay, và việc export tay đi ngược đúng chữ "quickly" trong đề.

C — WAF trên EC2 instance, viện cớ WAF trên CloudFront làm tăng latency, nhân bản bằng CloudFormation. Sai ở mệnh đề đầu tiên: AWS WAF không gắn trực tiếp lên EC2 instance được. WAF chỉ associate với CloudFront distribution, API Gateway REST API, Application Load Balancer hoặc AppSync GraphQL API. Muốn bảo vệ EC2 thì phải đặt chúng sau CloudFront hoặc sau ALB rồi gắn WAF vào lớp đó. Lý do "tăng latency cho người dùng" là cái cớ bịa để dẫn dụ — chưa kể CloudFront vốn là CDN ở biên, đặt lớp lọc tại đó là hợp lý. Về vế nhân bản, CloudFormation template quả thật tái tạo được resource, nhưng đó là công cụ IaC chung chứ không phải cơ chế quản trị bảo mật tập trung: nó không cho một administrator account duy nhất áp và duy trì tuân thủ bộ luật, cũng không tự kéo resource mới vào diện bảo vệ. Vì mệnh đề đầu đã sai về mặt kỹ thuật nên cả phương án hỏng, dù vế cuối nghe hợp lý.

📌 Điểm cần nhớ

• AWS WAF chỉ associate được với một số resource nhất định: CloudFront distribution, API Gateway REST API, Application Load Balancer, AppSync GraphQL API. Thấy phương án nào gắn WAF thẳng vào EC2 instance là loại được ngay.
• Security Group là firewall cho EC2, không dùng được với CloudFront. Đây là cái bẫy quen mặt trong đề CloudOps.
• Phân biệt vai trò: WAF thực thi, Firewall Manager quản lý. Firewall Manager không tự chặn request; nó tập trung hoá WAF rules, Shield Advanced, security groups và Network Firewall rules trên nhiều account thông qua AWS Organizations.
• Khi đề nhấn "multiple AWS accounts" kèm "quickly / centrally", hướng đúng gần như luôn là dịch vụ tích hợp AWS Organizations, chứ không phải export cấu hình bằng tay hay dựng lại bằng template.

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

Đề mô tả một website tĩnh nằm trên Amazon S3, phân phối qua CloudFront, bucket policy khoá chặt để chỉ CloudFront truy cập được. Câu hỏi cuối cùng chỉ hỏi đúng một việc: trong Route 53 phải tạo loại record nào để tên miền trỏ về CloudFront distribution.

Cụm từ quyết định nằm ở dòng URL mong muốn: https://johntrucks.com/ — không có www, không có subdomain nào phía trước. Đây chính là zone apex (còn gọi là root domain, naked domain) của hosted zone. Toàn bộ phần S3 và bucket policy chỉ là bối cảnh; cái làm các phương án khác nhau là "apex hay subdomain", cộng với việc đích đến là một CloudFront distribution — thứ không có địa chỉ IP cố định để bạn ghi cứng vào record.

Hai ràng buộc đó gộp lại loại sạch ba phương án còn lại.

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

D — Alias.

Alias record là phần mở rộng riêng của Route 53 chồng lên DNS chuẩn. Nó cho phép trỏ một tên miền thẳng tới các tài nguyên AWS như CloudFront distribution, S3 website endpoint, hay chính một record khác trong cùng hosted zone.

Hai điểm khiến nó là lựa chọn duy nhất chạy được ở đây:

• Alias tạo được ngay tại zone apex. Đây đúng là điều DNS chuẩn cấm với CNAME. Vì đề yêu cầu johntrucks.com chứ không phải www.johntrucks.com, chỉ Alias mới đáp ứng nổi.
• Alias phân giải động về đích AWS. Route 53 tự trả về địa chỉ hiện hành của CloudFront distribution, nên khi AWS thay đổi hạ tầng phía sau, bạn không phải sửa gì trong hosted zone.

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

A — CNAME. Đây là phương án gần đúng nhất và cũng là cái bẫy chính. CNAME đúng là cách chuẩn để trỏ một tên tới domain khác, và nếu đề hỏi www.johntrucks.com thì CNAME sẽ chạy được. Chỗ nó hỏng: DNS không cho phép đặt CNAME tại zone apex. Bản chất CNAME là "tên này thực ra là tên kia", nên nó không thể cùng tồn tại với các record bắt buộc phải có ở apex (như NS và SOA). Đề yêu cầu đúng johntrucks.com, nên CNAME bị loại vì lý do giao thức, không phải vì lý do AWS.

C — A. A record ánh xạ một tên miền tới địa chỉ IPv4 dạng dotted-decimal viết cứng trong record. CloudFront không cấp cho bạn một IP cố định — nó là mạng edge toàn cầu, tập IP thay đổi và khác nhau theo vị trí người dùng. Ghi cứng một IP vào đây là tự chuốc lấy website chết khi IP đó đổi. (Lưu ý dễ nhầm: trong console Route 53, Alias tới CloudFront được trình bày như một A record có bật công tắc "Alias" — nhưng đó chính là Alias, không phải A record thường như phương án này mô tả.)

B — AAAA. Cùng vấn đề hệt phương án A, chỉ khác là địa chỉ IPv6 dạng hexa phân tách bằng dấu hai chấm. Vẫn là ghi cứng một địa chỉ IP, vẫn không áp dụng được cho CloudFront distribution. Chọn AAAA vì "CloudFront có hỗ trợ IPv6" là suy luận sai hướng — hỗ trợ IPv6 là chuyện của distribution, không biến IP của nó thành thứ tĩnh để bạn ghi vào record.

📌 Điểm cần nhớ

• Thấy zone apex / root domain / naked domain trong đề là gần như chắc chắn loại CNAME ngay — DNS chuẩn không cho phép CNAME ở apex, còn Alias của Route 53 thì cho.
• Trỏ tới tài nguyên AWS (CloudFront, S3, load balancer) thì dùng Alias, đừng ghi cứng IP: A dành cho IPv4 cụ thể, AAAA dành cho IPv6 cụ thể, cả hai đều không hợp với dịch vụ có IP động.
• Phân biệt hai câu hỏi khác nhau: "loại record nào?" → Alias; còn "record đó hiển thị dưới dạng gì trong console?" → A hoặc AAAA có bật Alias. Đề ở đây hỏi vế thứ nhất.
• Phần S3 + bucket policy chỉ khoá origin để người dùng không vào thẳng bucket. Nó không ảnh hưởng tới lựa chọn record trong Route 53 — đọc lướt rồi bỏ qua để tập trung vào ràng buộc thật.