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

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

Đề mô tả một S3 bucket chứa dữ liệu nhạy cảm và giao cho SysOps administrator hai việc cùng lúc:

1. Ghi lại địa chỉ IP gắn với các lần xác thực thất bại khi truy cập object trong bucket.
2. Bảo vệ chính các log đó khỏi bị ghi đè hoặc xoá trong 90 ngày.

Cụm từ quyết định nằm ở vế thứ hai: "secure the logs from being overwritten or erased for a period of 90 days". Đây không phải yêu cầu giữ log bao lâu (retention) mà là yêu cầu không ai được sửa hay xoá log trong khoảng thời gian đó — tức là tính bất biến (immutability / WORM). Một chính sách retention thông thường chỉ nói "sau X ngày thì log tự hết hạn", nó hoàn toàn không ngăn được người có quyền xoá log sớm hơn. Phân biệt được hai khái niệm này là loại ngay được phương án gây nhiễu nặng nhất.

Cụm từ thứ hai đáng chú ý: "IP addresses associated with failed authentication attempts" — cần một nguồn log ghi ở mức request tới bucket, có trường IP người gọi và trạng thái lỗi, chứ không phải một dịch vụ phân tích hay quét bảo mật.

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

D — Enable server access logging for the S3 bucket và bảo vệ log bằng S3 Object Lock.

Phương án này giải quyết đúng cả hai vế:

• S3 server access logging ghi lại chi tiết từng request gửi tới bucket, trong đó có địa chỉ IP của người gọi, thao tác được yêu cầu và mã trạng thái/mã lỗi trả về. Nhờ vậy các lần xác thực thất bại và IP đứng sau chúng đều nằm trong bản ghi. Đây là nguồn dữ liệu trực tiếp cho yêu cầu của đề.
• S3 Object Lock áp mô hình WORM lên các object log: trong thời hạn giữ đã đặt, object không thể bị ghi đè hay xoá. Đó chính là nghĩa đen của "không được overwrite hoặc erase trong 90 ngày" mà đề đòi.

Nói gọn: server access logging tạo ra bằng chứng, Object Lock khiến bằng chứng đó không sửa được. Không phương án nào khác chạm được vào vế thứ hai.

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

B — CloudWatch Logs với log retention policy đặt 90 ngày. Đây là phương án gần đúng nhất và cũng là cái bẫy chính, hỏng ở cả hai chỗ. Thứ nhất, retention policy chỉ quyết định thời điểm log tự động hết hạn; nó không khoá log lại — người có quyền phù hợp vẫn xoá log stream hoặc log group bất cứ lúc nào, nên yêu cầu "không được xoá trong 90 ngày" không được đáp ứng. Thứ hai, bản thân CloudWatch Logs là nơi chứa log do nguồn khác đẩy vào; nó không tự sinh ra bản ghi request tới S3 kèm IP xác thực thất bại. Chỉ bật CloudWatch Logs suông thì chẳng có dữ liệu nào để giữ cả.

C — Amazon Inspector giám sát truy cập bucket. Inspector là dịch vụ đánh giá bảo mật: nó rà lỗ hổng và sai lệch so với thực hành tốt trên khối lượng công việc như EC2. Nó hoạt động theo hướng quét và báo cáo tình trạng cấu hình/lỗ hổng, không phải theo hướng ghi nhật ký từng request. Nó không tạo ra bản ghi IP của các lần xác thực thất bại tới S3, và đương nhiên cũng không có cơ chế khoá log bất biến 90 ngày.

A — Amazon Macie giám sát truy cập bucket. Macie cũng là dịch vụ bảo mật liên quan tới S3, nên nghe rất hợp tai — nhưng công việc của nó là phát hiện và phân loại dữ liệu nhạy cảm (ví dụ PII) nằm trong bucket. Nó trả lời câu hỏi "trong bucket này có dữ liệu nhạy cảm gì", chứ không trả lời "ai đã gọi vào bucket này từ IP nào và bị từ chối". Đề có nhắc "sensitive data", đó chính là mồi nhử kéo người học chọn Macie; nhưng yêu cầu thực sự là logging truy cập, không phải phân loại dữ liệu. Macie cũng không cung cấp tính bất biến cho log.

📌 Điểm cần nhớ

• Retention ≠ immutability. "Giữ log 90 ngày" và "không ai được xoá log trong 90 ngày" là hai yêu cầu khác nhau. Khi đề dùng các từ overwritten, erased, tamper-proof, WORM, compliance, hãy tìm phương án có S3 Object Lock, đừng chọn phương án chỉ đặt retention policy.
• Cần IP của người gọi tới S3 → nghĩ tới log ở mức request, mà S3 server access logging là nguồn ghi chi tiết request tới bucket kèm IP và trạng thái lỗi.
• Phân biệt vai trò các dịch vụ bảo mật: Macie = phát hiện/phân loại dữ liệu nhạy cảm trong S3; Inspector = đánh giá lỗ hổng và sai lệch cấu hình của workload; cả hai đều không phải công cụ ghi nhật ký truy cập.
• Từ khoá "sensitive data" trong đề thường là mồi nhử Macie. Đọc kỹ động từ chính của câu hỏi — nếu nó là track / log / record ai truy cập, thì đó là bài toán logging, không phải bài toán phân loại dữ liệu.

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

Đề mô tả một ứng dụng chạy trên Amazon EC2 instances cần ghi log lên một Amazon S3 bucket, và hỏi cách cấp quyền truy cập an toàn nhất.

Cụm từ quyết định là "MOST secure method" — cả bốn phương án đều có thể (về mặt lý thuyết) làm ứng dụng ghi được vào bucket, nên đề không hỏi cách nào chạy được, mà hỏi cách nào ít rủi ro lộ thông tin xác thực nhất. Cụm từ thứ hai cũng quan trọng không kém: "running on Amazon EC2 instances" — khi khối lượng công việc chạy trên chính EC2, AWS có sẵn cơ chế cấp credential tạm thời cho instance mà không cần ai nhúng gì vào code.

Ghép hai ràng buộc lại, tiêu chí phân biệt các phương án rất rõ: phương án nào còn nhúng thông tin xác thực vào application code thì bị loại; phương án nào để EC2 tự lấy credential từ hạ tầng thì thắng.

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

D. Create an IAM role with the required privileges and associate it with the EC2 instance.

Đây là mô hình chuẩn của AWS: tạo IAM role có đúng quyền cần thiết trên S3 bucket, rồi gắn role đó vào EC2 instance (thông qua instance profile). Khi đó ứng dụng lấy được credential tạm thời, tự động xoay vòng, do chính hạ tầng EC2 cung cấp — AWS SDK/CLI tự tìm thấy chúng mà lập trình viên không phải viết dòng nào để nạp key.

Điểm mạnh về bảo mật, đúng như phần giải thích gốc nhấn mạnh: không có credential nào nằm trong application code. Không có gì để lộ khi code bị đẩy nhầm lên repo, khi ai đó đọc được file cấu hình, hay khi image/AMI bị sao chép. Quyền cũng sửa được tập trung ở IAM role mà không cần build lại hay deploy lại ứng dụng.

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

A. IAM role + nhúng "role credentials" vào code. Đây là phương án bẫy vì nó chọn đúng công cụ (IAM role) nhưng dùng sai cách. Bản thân một IAM role không có bộ credential cố định để bạn đem đi nhúng vào code — role được assume, và thứ sinh ra là credential tạm thời có hạn. Nhúng credential tạm thời vào code vừa vô nghĩa (nó sẽ hết hạn) vừa đánh mất đúng cái lợi ích khiến role an toàn hơn. Cách dùng role đúng là gắn nó vào instance, tức phương án D.

B. IAM user + tạo key pair rồi nhúng key pair vào code. Sai ở hai tầng. Thứ nhất, key pair không phải là cơ chế xác thực với Amazon S3 — key pair trong EC2 dùng để đăng nhập SSH/lấy mật khẩu quản trị vào instance, không phải để ký request lên S3. Thứ hai, dù có dùng được thì việc nhúng thông tin xác thực vào code vẫn vi phạm chính tiêu chí "MOST secure" mà đề đặt ra.

C. IAM user + tạo access key rồi nhúng vào code. Đây là phương án gần đúng nhất trong ba phương án sai, vì access key thật sự là cách xác thực hợp lệ với S3 và ứng dụng sẽ chạy được. Nhưng nó hỏng ở chỗ: access key của IAM user là credential dài hạn, không tự xoay vòng, và bị hard-code trong application code — lộ ra là kẻ tấn công dùng được cho tới khi có người phát hiện và thu hồi thủ công. So với D, nó chạy được nhưng kém an toàn hơn hẳn, nên không thể là câu trả lời cho một câu hỏi hỏi "MOST secure".

📌 Điểm cần nhớ

• Khi khối lượng công việc chạy trên chính tài nguyên AWS (EC2, Lambda, ECS…), câu trả lời an toàn nhất gần như luôn là gắn IAM role vào tài nguyên đó, không phải tạo IAM user với access key.
• Bất kỳ phương án nào chứa cụm "embed ... in the application code" đều nên bị nghi ngờ ngay trong câu hỏi có từ khoá secure — credential nằm trong code là rủi ro lộ lọt kinh điển.
• Phân biệt hai khái niệm dễ lẫn: access key (IAM user, credential dài hạn, dùng để gọi API AWS như S3) và key pair (dùng để truy cập vào EC2 instance, không dùng để xác thực với S3).
• IAM role cung cấp credential tạm thời tự xoay vòng; chính vì tạm thời nên không tồn tại khái niệm "nhúng role credentials vào code" — thấy phương án nói vậy là phương án sai.

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

Đề mô tả một EC2 instance dùng EBS, trong đó data volume có status là impaired và I/O đã bị vô hiệu hoá do vấn đề nhất quán dữ liệu (data consistency). Câu hỏi: SysOps Administrator nên làm gì đầu tiên để khôi phục volume.

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

• "I/O has also been disabled due to data consistency issues" — đây là hành vi có chủ đích của EBS. Khi EBS phát hiện volume có thể không nhất quán, nó tự động dừng I/O để bảo vệ dữ liệu, chuyển volume sang trạng thái impaired. Nghĩa là volume chưa chắc đã hỏng vật lý; nó chỉ đang bị "treo" chờ người vận hành xác nhận dữ liệu còn dùng được hay không.
• "first step" — đề không hỏi cách sửa triệt để, mà hỏi bước đầu tiên. Đây là cụm phân biệt giữa phương án D và phương án A: cả hai đều có thể dẫn tới một volume dùng được, nhưng chỉ một cái là bước đầu đúng thứ tự.

Ghép hai cụm lại: bài toán là "EBS đang chờ tôi xác nhận dữ liệu", chứ không phải "volume đã mất, đi tìm bản sao lưu" hay "hiệu năng volume kém".

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

Đáp án đúng theo tệp là D — Perform a consistency check on the volume attached to the instance.

Quy trình khuyến nghị khi volume ở trạng thái impaired với I/O bị disable là giữ nguyên volume đang gắn vào instance và làm ba việc theo thứ tự:

1. Dừng mọi ứng dụng đang dùng volume, để không có ghi mới trong lúc kiểm tra.
2. Bật lại I/O trên volume (enable I/O) — bước này chính là cách nói với EBS rằng "tôi chấp nhận rủi ro và sẽ tự kiểm tra dữ liệu".
3. Kiểm tra dữ liệu trên volume bằng công cụ consistency check của hệ điều hành (ví dụ tiện ích kiểm tra filesystem).

Đây là lựa chọn đơn giản nhất và ít mất mát nhất: volume vẫn đang gắn sẵn, không phải tạo tài nguyên mới, và nếu dữ liệu thực ra vẫn nguyên vẹn thì hệ thống quay lại hoạt động mà không mất bất kỳ ghi nào. Chỉ khi kiểm tra cho thấy dữ liệu thực sự hỏng thì mới tính tới chuyện khôi phục từ snapshot.

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

A — Recreate the volume by restoring an Amazon EBS snapshot. Đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi. Khôi phục từ snapshot đúng là một cách hợp lệ để có lại volume, nhưng không phải bước đầu tiên: snapshot chỉ phản ánh trạng thái tại thời điểm nó được chụp, nên mọi ghi phát sinh sau đó sẽ mất. Vứt bỏ volume hiện tại khi còn chưa kiểm tra xem dữ liệu trong đó có thực sự hỏng hay không là tự gây mất dữ liệu không cần thiết. Nguyên tắc là thử cứu volume đang có trước, snapshot là phương án dự phòng khi bước cứu thất bại.

B — Attach an Elastic Fabric Adapter (EFA) to the instance and restart I/O. Sai hoàn toàn về loại vấn đề. EFA là thiết bị mạng dành cho khối lượng công việc HPC và tính toán phân tán cần độ trễ mạng thấp; nó không liên quan gì tới lớp lưu trữ block của EBS. Gắn EFA không ảnh hưởng đến trạng thái impaired của volume và không giải quyết được vấn đề nhất quán dữ liệu. Phần "restart I/O" nghe có vẻ đúng hướng, nhưng nó bị buộc chung với một hành động vô nghĩa, và bật lại I/O mà không kiểm tra dữ liệu thì cũng chưa phải là "khôi phục volume".

C — Change the volume to a general purpose SSD volume type. Nhầm giữa vấn đề hiệu năng và vấn đề tính toàn vẹn dữ liệu. Đổi volume type là thao tác dùng khi cần thêm IOPS hoặc throughput, hoặc tối ưu chi phí. Trạng thái impaired ở đây phát sinh từ nghi ngờ về tính nhất quán của dữ liệu, và loại volume không phải nguyên nhân — đổi sang gp SSD thì dữ liệu nghi ngờ vẫn nguyên nghi ngờ.

📌 Điểm cần nhớ

• Volume EBS ở trạng thái impaired kèm I/O bị disable là cơ chế bảo vệ dữ liệu, không mặc nhiên là volume đã hỏng. Phản xạ đúng: enable I/O rồi chạy consistency check trên volume đang gắn, chứ không phải bỏ volume đi ngay.
• Đề có chữ "first step" thì phải xếp các phương án theo thứ tự thao tác, không chỉ theo tính hợp lệ. Khôi phục từ snapshot là hợp lệ nhưng đứng sau, vì nó đánh đổi bằng dữ liệu ghi sau thời điểm chụp.
• Trước khi kiểm tra dữ liệu, phải dừng ứng dụng đang dùng volume — kiểm tra trong lúc còn ghi mới thì kết quả không đáng tin.
• Phân biệt rõ ba lớp vấn đề khi đọc đề EBS: toàn vẹn dữ liệu (consistency check / snapshot), hiệu năng (đổi volume type, thêm IOPS), và mạng (EFA, ENA). Phương án nào giải quyết sai lớp thì loại ngay, dù tên dịch vụ nghe rất "AWS".

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

Đề mô tả một tình huống rất cụ thể: một AWS Lambda function vừa được nối vào một Amazon VPC và sau đó mất khả năng kết nối ra dịch vụ bên ngoài trên Internet. Câu hỏi là làm sao khắc phục.

Cụm từ quyết định đáp án là "has been connected to an Amazon VPC and is no longer able to connect to an external service on the internet" — hai vế nối với nhau bằng quan hệ nhân quả. Trước khi nối VPC, Lambda chạy trong môi trường mạng do AWS quản lý và đi ra Internet được ngay. Sau khi nối vào VPC, toàn bộ lưu lượng đi ra (outbound) của function được đẩy qua đường mạng trong VPC của bạn, và nó phải tuân theo route table của subnet mà function được gắn vào. Nếu subnet đó không có đường ra Internet, function mất kết nối — đúng hiện tượng đề mô tả.

Vậy việc phải làm là tạo đường ra Internet cho subnet của function, chứ không phải sửa code hay bật một tính năng nào đó trên Lambda.

Một chi tiết nữa cần để ý: elastic network interface mà Lambda dùng trong VPC không có địa chỉ IP công cộng. Điều này loại trừ cách "gắn Internet gateway rồi đi thẳng" như một EC2 instance có public IP — lưu lượng phải đi qua một thành phần làm NAT.

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

Đáp án đúng theo tệp là A — Add an entry to the subnet route table pointing to a NAT gateway.

Mô hình chuẩn cho Lambda-trong-VPC cần ra Internet là:

• Đặt một NAT gateway trong một public subnet (subnet có route mặc định trỏ tới Internet gateway).
• Gắn Lambda function vào private subnet.
• Trong route table của private subnet đó, thêm một entry cho lưu lượng ra Internet trỏ tới NAT gateway.

Vì ENI của Lambda chỉ có private IP, NAT gateway đóng vai trò dịch địa chỉ: nó có địa chỉ public, nhận gói tin từ private subnet, đổi source address rồi gửi ra Internet qua Internet gateway, và ánh xạ ngược chiều phản hồi về đúng function. Đây chính là điều tài liệu troubleshooting của Lambda hướng dẫn: cấu hình VPC để gửi lưu lượng outbound từ subnet của function tới một NAT gateway đặt ở public subnet.

Đáp án A nói đúng thao tác cụ thể cần làm — sửa route table của subnet — nên nó khớp với nguyên nhân gốc mà đề đã nêu.

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

B — Update the function code to avoid the VPC and connect directly. Đây là phương án gây nhầm nhiều nhất vì nghe có vẻ "đi tắt cho nhanh", nhưng nó bất khả thi về mặt kỹ thuật. Việc một function có nối VPC hay không là thuộc tính cấu hình của function, không phải thứ mà code bên trong quyết định. Một khi function đã được nối vào VPC, mọi lưu lượng ra đều đi qua VPC; không có API hay thư viện nào trong code cho phép một request "vòng qua" đường mạng đó. Muốn function không đi qua VPC thì phải gỡ cấu hình VPC khỏi function — nhưng khi ấy nó lại mất quyền truy cập các tài nguyên private bên trong VPC, tức là đổi vấn đề này lấy vấn đề khác chứ không phải giải pháp.

C — Create a virtual private gateway (VGW) to the subnet. Sai vì nhầm mục đích của thành phần. Virtual private gateway là đầu nối phía AWS cho kết nối lai: AWS Managed VPN (Site-to-Site VPN) tới mạng on-premises, hoặc dùng cùng Direct Connect. Nó mở đường tới mạng riêng của bạn, không mở đường ra Internet công cộng. Thêm nữa VGW gắn vào VPC, không phải "gắn vào subnet" như câu chữ của phương án. Dù có dựng VGW, function vẫn không tới được dịch vụ external trên Internet.

D — Enable enhanced VPC routing for the AWS Lambda function. Đây là bẫy kiểu "tên nghe rất đúng". Enhanced VPC routing là tính năng của Amazon Redshift, dùng để ép lưu lượng COPY/UNLOAD giữa cluster và Amazon S3 đi qua VPC thay vì đi ngoài. Lambda không có tính năng này — không có công tắc nào tên như vậy để bật cho function. Chọn D là chọn một thao tác không tồn tại. Ngoài ra, ngay cả nếu hiểu theo tinh thần của Redshift, tính năng đó là để ép lưu lượng vào VPC, tức là đi ngược hướng với thứ đề đang cần (mở đường ra Internet).

📌 Điểm cần nhớ

• Nối Lambda vào VPC là mất Internet mặc định. Khi function chưa gắn VPC, nó ra Internet được ngay; gắn VPC xong thì mọi lưu lượng outbound tuân theo route table của subnet, và bạn phải tự dựng đường ra.
• ENI của Lambda không có public IP, nên chỉ gắn Internet gateway cho VPC là chưa đủ. Cần NAT gateway ở public subnet + entry trong route table của private subnet trỏ tới NAT gateway đó.
• Phân biệt rõ ba gateway: Internet gateway = đường ra/vào Internet cho subnet có public IP; NAT gateway = đường ra Internet cho tài nguyên chỉ có private IP; virtual private gateway = đầu nối tới mạng on-premises qua VPN/Direct Connect, không liên quan tới Internet công cộng.
• Enhanced VPC routing thuộc về Redshift, không thuộc Lambda. Trong đề trắc nghiệm AWS, phương án gắn một tính năng có thật của dịch vụ này sang dịch vụ khác là kiểu bẫy rất phổ biến — thấy tên tính năng quen mà đứng cạnh dịch vụ lạ thì nên nghi ngờ ngay.

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

Đề mô tả một SysOps Administrator triển khai CloudFormation StackSet ra nhiều AWS account. Thao tác thất bại và stack instance status là OUTDATED.

Cụm từ quyết định đáp án là "the stack instance status is OUTDATED", cộng với "across multiple AWS accounts".

Cần hiểu hai lớp trạng thái của StackSet:

• Stack set operation (thao tác trên toàn bộ stack set) có kết quả thành công hoặc thất bại.
• Stack instance (một stack cụ thể trong một cặp account + region) có trạng thái riêng. OUTDATED nghĩa là stack instance đó không được cập nhật theo phiên bản mới nhất của stack set — thường vì thao tác tạo/cập nhật ở chính account đích đã hỏng, nên bản triển khai ở đó bị bỏ lại phía sau.

Nói cách khác, OUTDATED là dấu hiệu lỗi xảy ra tại account đích khi CloudFormation cố tạo/sửa tài nguyên ở đó, chứ không phải lỗi ở khâu nộp yêu cầu. Đây chính là cái ràng buộc phân biệt các phương án: phải chọn nguyên nhân nằm ở phía target account, phát sinh lúc thực thi.

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

B — "The deployment was run with insufficient permissions in the target account."

Theo tài liệu troubleshooting StackSets, đây là một trong những nguyên nhân phổ biến nhất khiến stack operation thất bại. Mô hình quyền của StackSets tách làm hai vai: một vai ở administrator account để khởi chạy thao tác, và một vai ở target account để CloudFormation thay mặt tạo tài nguyên. Nếu vai ở target account không đủ quyền với những tài nguyên mà template khai báo, CloudFormation ở account đó không tạo được stack, thao tác báo lỗi, và stack instance bị bỏ lại ở trạng thái không khớp với stack set → OUTDATED.

Điểm khớp hoàn hảo với đề: đây là lỗi runtime, xảy ra tại account đích, đúng loại lỗi mà OUTDATED phản ánh. Trong danh sách nguyên nhân của tài liệu, các nguyên nhân khác cùng loại còn có: template có lỗi cú pháp, template tạo tài nguyên global phải là duy nhất (ví dụ S3 bucket trùng tên), số hiệu account đích không tồn tại, administrator account không có trust relationship với target account, chạm hạn mức tài nguyên (ví dụ số IAM role) ở target account, hoặc chạm giới hạn số stack trong một stack set. Nhưng trong bốn phương án được đưa ra, chỉ B nằm trong danh sách đó.

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

A — "Trying to create resources in other accounts in a different region." Đây là phương án gần đúng nhất vì nó có nhắc tới account và region, nghe như đang chạm vào một giới hạn nào đó. Nhưng nó hỏng ở chỗ mô tả sai bản chất của StackSets: triển khai xuyên account và xuyên region chính là mục đích tồn tại của StackSet. Khi tạo stack instance, bạn khai rõ danh sách account đích và danh sách region đích. Việc tài nguyên được tạo ở region khác không phải lỗi, đó là hành vi thiết kế.

C — "Run without specifying a CloudFormation template." Không thể xảy ra. Template là thành phần bắt buộc để tạo một stack set — không có template thì yêu cầu bị từ chối ngay từ đầu, ở phía administrator account. Nếu đây là nguyên nhân thì sẽ không có stack instance nào được tạo ra để mà mang trạng thái OUTDATED. Lỗi này thuộc loại "chưa bao giờ khởi động được", trái với tình huống đề mô tả là thao tác đã chạy rồi mới hỏng.

D — "Requires multi-factor authentication and a token was not provided." StackSets không dùng MFA như một cơ chế trong luồng triển khai. Quyền giữa administrator account và target account được xử lý bằng IAM role và trust relationship (hoặc bằng service-managed permissions khi tích hợp AWS Organizations), không phải bằng việc nộp MFA token cho từng thao tác. Phương án này đưa một cơ chế không tồn tại trong ngữ cảnh vào làm nguyên nhân.

📌 Điểm cần nhớ

• OUTDATED ở stack instance = stack ở account/region đó không theo kịp phiên bản hiện tại của stack set, thường do thao tác tạo/cập nhật ở chính account đó thất bại. Gặp trạng thái này thì hướng điều tra là phía target account, không phải phía người bấm nút.
• Quyền là nguyên nhân số một khi StackSet hỏng. Nhớ mô hình hai vai: role ở administrator account để khởi chạy, role ở target account để tạo tài nguyên, cộng thêm trust relationship giữa hai bên.
• Xuyên account và xuyên region là tính năng, không phải lỗi. Bất kỳ phương án nào ngụ ý "StackSet không làm được việc đó" đều là mồi nhử.
• Phân biệt lỗi ở khâu nộp yêu cầu (thiếu template, tham số không hợp lệ — hỏng ngay, không sinh ra stack instance) với lỗi lúc thực thi ở account đích (thiếu quyền, trùng tên tài nguyên global, chạm hạn mức — sinh ra stack instance ở trạng thái bất thường). Đề bài mô tả loại nào thì loại phương án theo loại đó.

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

Đề đặt ra một quy trình change control: mọi thay đổi trên hạ tầng production phải được xem xét kỹ trước khi triển khai bản cập nhật lên các AWS CloudFormation stack. Câu hỏi kết thúc bằng: hành động nào cho phép Administrator hiểu được tác động của thay đổi trước khi thực hiện.

Có hai cụm từ quyết định đáp án, và phải đọc cả hai cùng lúc:

• "AWS CloudFormation stacks" — phạm vi công việc nằm gọn trong CloudFormation. Mọi phương án nói về công cụ triển khai khác đều lệch chủ thể ngay từ đầu.
• "before implementation" / "before deploying" — thứ cần là một bước xem trước (preview), tách rời khỏi bước thực thi. Không phải một chiến lược triển khai an toàn, không phải cách giảm rủi ro trong lúc triển khai, mà là khả năng nhìn thấy điều gì sẽ xảy ra khi chưa có gì bị đụng tới.

Ràng buộc thứ hai chính là thứ tách A khỏi B và C: blue/green và canary đều làm giảm rủi ro, nhưng chúng giảm rủi ro sau khi thay đổi đã bắt đầu chạy, chứ không cho biết trước tài nguyên nào sẽ bị sửa hay bị xoá.

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

A — Create a change set for the running stack.

Change set là cơ chế của chính CloudFormation dành đúng cho tình huống này. Khi bạn nộp một template hoặc bộ tham số mới dưới dạng change set, CloudFormation so sánh với trạng thái hiện tại của stack đang chạy và liệt kê ra danh sách thay đổi dự kiến: tài nguyên nào được thêm, tài nguyên nào bị sửa đổi, tài nguyên nào bị xoá hoặc bị thay thế (replacement). Đây chính là thông tin mà một hội đồng change control cần để đánh giá tác động — đặc biệt là cảnh báo về việc thay thế tài nguyên quan trọng, vì replacement đồng nghĩa với tài nguyên cũ bị xoá và tạo lại với danh tính mới.

Điểm mấu chốt: tạo change set không thay đổi gì trên stack. CloudFormation chỉ thực sự áp dụng khi bạn quyết định execute change set đó. Nếu thấy kết quả không ổn, bạn có thể bỏ nó đi và tạo một change set khác từ template đã sửa. Đúng tinh thần "review rồi mới deploy" mà đề yêu cầu. Change set dùng được qua CloudFormation console, AWS CLI hoặc API.

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

B — Implement a blue/green strategy using AWS Elastic Beanstalk. Sai ở chủ thể. Đề nói rõ hạ tầng đang được quản lý bằng CloudFormation stack, không phải bằng Elastic Beanstalk. Nếu dùng Elastic Beanstalk thì thao tác thay đổi sẽ diễn ra trong môi trường Elastic Beanstalk chứ không phải trên CloudFormation stack — tức là phương án này đề nghị đổi luôn công cụ quản lý hạ tầng thay vì trả lời câu hỏi. Ngoài ra blue/green là kỹ thuật cắt chuyển lưu lượng giữa hai môi trường; nó cho phép rollback nhanh, nhưng không sinh ra bản báo cáo "những tài nguyên nào sẽ bị xoá" để đem đi review.

C — Perform a canary deployment using Application Load Balancers and target groups. Đây là phương án gần đúng nhất về mặt "giảm rủi ro khi thay đổi", nên cần nói rõ nó hỏng ở đâu. Canary với ALB và target group hoạt động ở tầng lưu lượng ứng dụng: đưa một phần nhỏ traffic sang phiên bản mới rồi quan sát. Nó không hề đánh giá được tác động của một bản cập nhật CloudFormation lên các tài nguyên hạ tầng, và bạn không thể "canary" một stack update theo cách này — kiểu triển khai từng phần như vậy thuộc về công cụ triển khai ứng dụng như AWS CodeDeploy. Quan trọng hơn, canary chỉ cho tín hiệu sau khi phiên bản mới đã được đưa lên và bắt đầu nhận traffic, còn đề đòi hiểu tác động trước khi triển khai.

D — Submit the update using the UpdateStack API call. Đúng dịch vụ, đúng đối tượng, nhưng sai thời điểm — và đây là cái bẫy chính của câu. UpdateStack là lời gọi bắt đầu cập nhật ngay lập tức: CloudFormation áp dụng template mới lên stack đang chạy, không có bước dừng lại cho ai xem xét. Chọn D nghĩa là bỏ qua toàn bộ quy trình change control mà đề mô tả. Lời gọi đúng cho ý định "xem trước" là tạo change set (create-change-set), rồi sau khi review mới execute-change-set.

📌 Điểm cần nhớ

• Từ khoá "preview / understand the impact before deploying" gắn với CloudFormation thì gần như luôn dẫn tới change set. Change set liệt kê add / modify / delete / replace mà không đụng vào stack.
• Phân biệt rạch ròi UpdateStack (thực thi ngay) với CreateChangeSet → review → ExecuteChangeSet (có chốt kiểm duyệt). Cùng một mục tiêu cập nhật, khác nhau ở chỗ có bước dừng cho con người hay không.
• Cảnh giác với cụm "replacement" trong kết quả change set: tài nguyên bị thay thế là tài nguyên bị xoá và tạo lại — đây thường là rủi ro lớn nhất trong một bản cập nhật hạ tầng production.
• Blue/green và canary là chiến lược triển khai, không phải công cụ phân tích tác động. Chúng giới hạn thiệt hại trong và sau khi triển khai; chỉ change set mới trả lời được câu hỏi "chuyện gì sẽ xảy ra nếu tôi bấm nút". Ngoài ra, để ý xem đề đang nói tới công cụ nào (CloudFormation, Elastic Beanstalk, CodeDeploy) — phương án đổi sang công cụ khác thường là phương án lạc đề.

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

Một công ty dùng Amazon ElastiCache for Redis làm database cho web application. Cụm hiện tại có đúng một shard chạy trên một node cỡ large, và node đó chỉ còn 20% freeable memory. Người quản trị được yêu cầu làm hai việc cùng lúc: resize cụm và thêm high availability.

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

• "a single shard running on a large node" — cụm đang ở dạng cluster mode disabled, một shard duy nhất, không có replica nào. Đây là điểm xuất phát.
• "20% freeable memory" — bộ nhớ còn trống thấp. Đây là tín hiệu về dung lượng của node, và cách xử lý trực tiếp là chuyển sang node lớn hơn (scale up).
• "add high availability" — chứ không phải "tăng throughput đọc" hay "phân vùng dữ liệu". HA trong ElastiCache Redis nghĩa là có bản sao của cùng dữ liệu ở một Availability Zone khác để tự động failover khi AZ hoặc node primary hỏng.

Vì đề hỏi hai hành động, cách đọc đúng là ghép một hành động cho vế "resize" và một hành động cho vế "high availability" — chứ không phải chọn hai cách khác nhau cho cùng một vế.

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

A — Resize the cluster nodes to use extra-large nodes. Đây là vế resize. Node large chỉ còn 20% freeable memory là mức khá thấp với Redis, nơi toàn bộ dataset nằm trong RAM và còn cần chỗ trống cho overhead vận hành. Chuyển sang node cỡ extra-large là scale up theo chiều dọc: cùng một shard, cùng một cách truy cập, chỉ là node có nhiều memory hơn. Nó giải quyết đúng vấn đề mà con số 20% chỉ ra, và không đòi thay đổi gì ở phía application.

B — Add a read replica in a different Availability Zone. Đây là vế high availability. Với cluster mode disabled và một shard, ElastiCache cho phép gắn thêm read replica vào shard đó, và replica có thể đặt ở AZ khác. Khi bật Multi-AZ, replica ở AZ khác cho phép automatic failover: primary node hoặc cả AZ hỏng thì một replica được thăng cấp lên primary. Điểm mấu chốt là replica giữ bản sao của chính dữ liệu đang có, nên nó thực sự bảo vệ dữ liệu hiện tại — đúng nghĩa HA.

Hai hành động này bổ sung cho nhau: A lo dung lượng, B lo tính sẵn sàng, và cả hai đều làm được trên kiến trúc một shard hiện tại mà không phải dựng lại cụm.

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

C — Enable multithreading and update the application. Sai ở tầng nền tảng: đây không phải một nút bấm tồn tại trong ElastiCache for Redis. Redis xử lý lệnh theo mô hình đơn luồng, không có tuỳ chọn "bật multithreading" cho người dùng cấu hình. Kể cả nếu có, nó cũng chỉ liên quan tới cách dùng CPU, chứ không thêm được một byte memory nào và càng không tạo ra bản sao dữ liệu ở AZ khác — trượt cả hai yêu cầu của đề.

D — Add a shard in a different Availability Zone. Đây là phương án gần đúng và dễ nhầm nhất, vì nó có chữ "different Availability Zone" trông rất giống HA. Nhưng shard là một phân vùng dữ liệu (data partition), không phải bản sao. Thêm shard nghĩa là chia keyspace ra, shard mới giữ phần dữ liệu khác, chứ không giữ bản sao của dữ liệu đang nằm trong shard hiện tại. Dữ liệu cũ vẫn chỉ tồn tại ở một chỗ trong một AZ — mất node đó là mất phần dữ liệu đó. Thêm shard là scale out để tăng dung lượng, không phải cơ chế high availability. Nó chạm được nửa yêu cầu (dung lượng) nhưng trả lời sai nửa còn lại, mà đề thì đòi cả hai.

E — Enable cluster mode and configure high availability. Cũng gần đúng nhưng hỏng ở chỗ thừa và không cần thiết. Cluster mode enabled tồn tại để tạo nhiều shard — nó là câu trả lời cho bài toán phân vùng dữ liệu vượt quá sức một node. Bài này chỉ có một shard và HA mà đề cần hoàn toàn đạt được bằng cách gắn read replica ở AZ khác trên cấu hình cluster mode disabled hiện tại. Ngoài ra, đổi sang cluster mode là thay đổi kiến trúc lớn: client phải dùng thư viện hỗ trợ cluster, tức là kéo theo sửa application — trong khi đề không hề nhắc tới việc được phép thay đổi ứng dụng.

📌 Điểm cần nhớ

• Replica ≠ shard. Replica là bản sao của cùng dữ liệu → cho HA và failover. Shard là phân vùng dữ liệu khác nhau → cho dung lượng và throughput. Câu hỏi nào nói "high availability" mà phương án chào mời "add a shard" thì gần như chắc chắn là bẫy.
• Cluster mode disabled vẫn làm được HA. Một shard đơn vẫn gắn được read replica ở AZ khác và vẫn có automatic failover khi bật Multi-AZ. Không cần bật cluster mode chỉ để có tính sẵn sàng.
• Đọc con số trong đề như một tín hiệu chỉ hướng. "Freeable memory thấp" trỏ thẳng tới bài toán dung lượng node → scale up sang node lớn hơn; nó không nói gì về tính sẵn sàng.
• Câu "Select TWO" thường ghép một hành động cho mỗi yêu cầu trong đề. Đề nêu hai mục tiêu (resize + HA) thì hãy soi từng phương án xem nó phục vụ mục tiêu nào, thay vì chọn hai phương án cùng giải quyết một mục tiêu.
• Redis chạy đơn luồng. Bất kỳ phương án nào đề nghị "bật multithreading" cho ElastiCache for Redis đều là phương án bịa để loạ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ởi chạy EC2 instance và nhận về thông báo lỗi

InstanceLimitExceeded — "Your quota allows for 0 more running instance(s)."

Câu hỏi là: hành động nào giải quyết được vấn đề này để launch được instance?

Cụm từ quyết định đáp án nằm ngay trong chính thông báo lỗi: InstanceLimitExceeded và Your quota allows for 0 more running instance(s). Đây không phải lỗi về capacity của AWS, không phải lỗi cấu hình mạng, không phải lỗi thiếu quyền IAM — nó nói thẳng rằng tài khoản đã chạm trần quota số lượng running On-Demand instance trong Region đó.

Hai chi tiết cần bám vào:

• Đây là quota (service limit) của tài khoản, chứ không phải sự cố kỹ thuật.
• Quota này áp ở cấp Region, không phải cấp Availability Zone.

Nắm được hai điều này thì ba phương án còn lại tự rụng, vì mỗi phương án đều vi phạm một trong hai.

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

A. Open a case with AWS Support requesting an increase of the EC2 instance limit.

Khi đã chạm trần quota, cách duy nhất để launch thêm instance là xin nâng quota, và việc nâng quota là quyết định thuộc về AWS chứ không phải của người dùng. Người quản trị mở case với AWS Support (hoặc gửi yêu cầu nâng limit) cho Region đang gặp lỗi, nêu rõ loại instance và số lượng cần thêm; AWS xét duyệt rồi mới nới trần.

Điểm mấu chốt theo hướng nguyên lý: quota là ràng buộc phía nhà cung cấp, không phải một thiết lập người dùng tự bật tắt được. Vì thế mọi cách "xoay xở" phía client — đổi công cụ gọi API, đổi AZ, thử lại — đều không chạm được vào nguyên nhân. Chỉ có yêu cầu nâng limit và được AWS chấp thuận mới làm lệnh launch thành công.

Quota EC2 cũng được xin nâng theo từng Region một, nên yêu cầu phải nhắm đúng Region đang báo lỗi.

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

B. Use the AWS Management Console to increase the limits for the region. — Đây là phương án gần đúng nhất và cũng là cái bẫy chính của câu. Console đúng là nơi bạn xem limit hiện tại và gửi yêu cầu nâng limit, nhưng bạn không tự tay chỉnh con số trần lên được. Phương án này diễn đạt như thể admin vào Console rồi sửa giá trị limit là xong — đó là chỗ nó hỏng. Việc nới quota luôn cần AWS phê duyệt, còn Console chỉ là giao diện để đề đạt yêu cầu đó. Theo cách diễn giải của đề, hành động dẫn tới kết quả là mở case với AWS Support, nên A mới là đáp án.

C. Launch the EC2 instances by using the run-instances CLI command. — Đổi công cụ không đổi được quota. Console, CLI (run-instances), SDK hay CloudFormation đều gọi cùng một EC2 API và đều bị cùng một bộ đếm quota chặn lại. Chạy run-instances chỉ khiến bạn nhận lại đúng lỗi InstanceLimitExceeded, lần này ở dạng text trong terminal thay vì banner đỏ trên Console. Đây là kiểu phương án đánh vào phản xạ "thử cách khác xem sao" thay vì đọc kỹ nguyên nhân lỗi.

D. Try to launch the EC2 instances into another Availability Zone. — Sai vì nhầm phạm vi áp dụng của quota. Giới hạn số running instance được tính trên toàn Region, gộp mọi AZ trong Region đó. Chuyển từ AZ này sang AZ khác trong cùng Region không làm bộ đếm giảm đi, nên lỗi vẫn y nguyên. Phương án này sẽ hợp lý với một lớp lỗi khác hẳn — lỗi kiểu không đủ capacity trong một AZ cụ thể — nhưng thông báo InstanceLimitExceeded nói rõ đây là chuyện quota, không phải chuyện capacity.

📌 Điểm cần nhớ

• Đọc mã lỗi trước khi đọc phương án. InstanceLimitExceeded = chạm trần quota của tài khoản, hoàn toàn khác với lỗi capacity của AWS. Xác định đúng loại lỗi là đã loại được hơn nửa số phương án.
• Quota EC2 running instances áp theo Region. Đổi AZ trong cùng Region không giúp gì; đây là ràng buộc phân biệt phương án "đổi AZ" trong rất nhiều câu tương tự.
• Đổi công cụ gọi API không đổi được giới hạn. Console, CLI, SDK, CloudFormation đều đi qua cùng một API và chịu cùng một quota — phương án dạng "dùng CLI thay vì Console" gần như luôn là mồi nhử.
• Nâng quota là việc phải xin, không phải việc tự chỉnh. Người dùng gửi yêu cầu và AWS phê duyệt; phương án nào mô tả admin tự đặt lại con số trần thì đó là chỗ để loại nó.

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

Tình huống: một SysOps Administrator đang dùng AWS Systems Manager Patch Manager để vá một nhóm EC2 instance. Người này đã làm xong ba việc: tạo patch baseline, đặt maintenance window, và dùng instance tag để chọn instance nào sẽ được vá.

Cụm từ quyết định nằm ở câu cuối phần mô tả: "To ensure that the Systems Manager can gain access to these EC2 instances" — nghĩa là Systems Manager phải truy cập được vào chính các instance đó. Đề không hỏi về bảo mật mạng, không hỏi về chống tấn công, cũng không hỏi về danh tính người dùng đăng nhập vào máy. Nó hỏi về quyền để dịch vụ thao tác trên instance thay mặt bạn.

Trong AWS, "một dịch vụ được phép làm gì trên EC2 instance" luôn là câu chuyện của IAM, chứ không phải của security group hay của một dịch vụ bảo vệ nào khác. Nhận ra được chữ access/permissions trong đề là đã loại được ba phương án còn lại.

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

D. Associate an IAM role with the necessary permissions to the EC2 instances.

Để Systems Manager truy cập và thực hiện hành động trên EC2 instance, bạn phải gắn một IAM role có đủ quyền cần thiết vào các instance đó (instance profile). Role này chính là thứ cho phép Systems Manager thay mặt bạn thực hiện các thao tác như vá lỗi.

Cơ chế ở đây: SSM Agent chạy bên trong instance sẽ dùng thông tin xác thực tạm thời lấy từ IAM role gắn trên instance để nói chuyện với endpoint của Systems Manager. Không có role, agent không có danh tính hợp lệ, và instance sẽ không xuất hiện như một managed instance — Patch Manager có patch baseline đẹp đến mấy, maintenance window đúng giờ đến mấy, tag chuẩn đến mấy thì cũng không có mục tiêu nào để vá.

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

B. Update the security group attached to instances with an inbound rule — đây là phương án gần đúng nhất và cũng là bẫy chính. Giữ security group đúng đắn là việc quan trọng cho bảo mật EC2 instance, nhưng thêm một inbound rule không cấp quyền cho Systems Manager truy cập và quản lý instance. Hai lý do: thứ nhất, quyền là chuyện của IAM chứ không phải của tầng mạng; thứ hai, kết nối trong mô hình Systems Manager là do agent bên trong instance chủ động đi ra tới endpoint dịch vụ, nên chiều cần quan tâm là outbound/khả năng tới được endpoint, không phải inbound. Mở thêm cổng vào chỉ làm rộng bề mặt tấn công mà không giải quyết được gì.

C. Activate AWS Shield for the EC2 instances — AWS Shield là dịch vụ được quản lý dùng để chống tấn công DDoS cho ứng dụng chạy trên AWS. Nó có bổ sung một lớp bảo vệ cho instance, nhưng không cấp cho Systems Manager quyền truy cập instance. Đây là kiểu phương án "nghe có vẻ bảo mật" — đúng lĩnh vực AWS Security, sai hoàn toàn về loại vấn đề.

A. Enable AWS Managed Microsoft AD on the instances — AWS Managed Microsoft AD là dịch vụ dựng và duy trì một Microsoft Active Directory trên AWS. Bật nó lên không tạo ra quyền truy cập cần thiết để Systems Manager quản lý EC2 instance. Active Directory phục vụ việc xác thực người dùng và join máy vào domain — một trục danh tính khác hẳn với trục "dịch vụ AWS thao tác trên tài nguyên AWS".

📌 Điểm cần nhớ

• Khi đề nói một dịch vụ AWS cần "access"/"permissions" lên EC2 instance, câu trả lời gần như luôn là IAM role gắn vào instance, không phải security group, không phải một dịch vụ bảo mật khác.
• Với Systems Manager, một instance chỉ trở thành managed instance khi có đủ ba thứ: SSM Agent chạy được, IAM role đúng quyền, và đường ra tới endpoint dịch vụ. Patch baseline, maintenance window và tag chỉ quyết định vá cái gì, lúc nào — chúng vô nghĩa nếu instance chưa được quản lý.
• Phân biệt hai trục hay bị trộn lẫn trong đề thi: IAM = ai/cái gì được phép làm gì trên tài nguyên AWS; security group = gói tin nào đi qua được. Đề hỏi trục nào thì trả lời trục đó.
• Cảnh giác với phương án "đúng lĩnh vực, sai vấn đề" như AWS Shield (DDoS) hay AWS Managed Microsoft AD (xác thực người dùng/domain) — chúng thật sự là dịch vụ bảo mật, nhưng không dính gì tới việc uỷ quyền cho Systems Manager.

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

Đề mô tả một website chạy trên Amazon EC2 trong Auto Scaling group, đứng sau một Application Load Balancer (ALB), và hỏi: trong Amazon Route 53 phải tạo loại record set nào để tên miền phân giải về ALB đó.

Cụm từ quyết định đáp án nằm ở câu: "The website's apex domain name is example.com" — tức là apex domain (còn gọi là zone apex, naked domain), là chính example.com chứ không phải một subdomain như www.example.com.

Đây chính là ràng buộc phân biệt hai phương án gần giống nhau nhất là ALIAS và CNAME. Nếu đề viết "www.example.com must resolve to the ALB" thì cả CNAME lẫn ALIAS đều dùng được và câu hỏi mất tính phân biệt. Vì đề cố ý nói apex, chỉ còn một loại record hợp lệ.

Chi tiết thứ hai đáng để ý: mục tiêu là một load balancer, không phải một địa chỉ IP cố định. ALB không có IP tĩnh — địa chỉ của nó thay đổi khi hệ thống scale hoặc khi AWS cập nhật phần mềm — nên bản ghi phải trỏ tới tên DNS của load balancer, không phải trỏ cứng vào IP.

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

Đáp án đúng theo tệp là A – ALIAS.

Route 53 cung cấp một loại record riêng gọi là Alias record, cho phép ánh xạ tên ở zone apex (example.com) sang tên DNS của một tài nguyên AWS, ví dụ tên của ELB dạng my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com.

Điểm mấu chốt: Alias record không phải là một bản ghi DNS chuẩn được trả về cho client như CNAME. Route 53 tự phân giải phía sau và trả lời truy vấn bằng một hoặc nhiều địa chỉ IP hiện tại của load balancer. Nhờ vậy nó hoạt động đúng như một bản ghi địa chỉ và không vi phạm ràng buộc của DNS về apex, đồng thời vẫn theo kịp khi IP của ALB thay đổi do scale up, scale down hay cập nhật phần mềm.

Route 53 hỗ trợ alias record cho cả ba loại load balancer: Application Load Balancer, Network Load Balancer và Classic Load Balancer — nên trường hợp ALB trong đề nằm đúng trong phạm vi hỗ trợ.

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

D – CNAME — đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. CNAME đúng là cách chuẩn để trỏ một tên sang tên DNS khác, và nếu đích là ALB thì về mặt ý tưởng là hợp lý. Nhưng nó hỏng ở đúng chỗ đề nhấn mạnh: không thể dùng CNAME cho zone apex. Chuẩn DNS không cho phép một tên đã có các bản ghi bắt buộc của zone (như SOA và NS) mang thêm CNAME. Muốn dùng CNAME thì phải là subdomain, ví dụ www.example.com — mà đề nói rõ tên cần phân giải là example.com.

C – SOA — Start of Authority record. Đây là bản ghi khai báo thông tin thẩm quyền của một hosted zone: name server chính, email người quản trị, số serial, các tham số refresh/retry/expire. Mỗi zone có đúng một bản ghi SOA và Route 53 tự tạo nó khi bạn tạo hosted zone. Nó là siêu dữ liệu về zone, hoàn toàn không có chức năng trỏ một tên tới một tài nguyên nào cả — không phải loại record dùng cho việc này.

B – TXT — bản ghi văn bản, dùng để gắn chuỗi tuỳ ý vào một tên miền. Công dụng thực tế thường gặp là xác minh quyền sở hữu tên miền hoặc khai báo chính sách email (SPF, DKIM, DMARC). Trình phân giải DNS của trình duyệt không dùng TXT để tìm ra địa chỉ máy chủ, nên đặt tên ALB vào một TXT record thì example.com vẫn không phân giải được — không phải loại record dùng cho việc này.

📌 Điểm cần nhớ

• Thấy chữ apex domain / zone apex / naked domain đi cùng một tài nguyên AWS (ALB, NLB, CLB, CloudFront, S3 website endpoint) → đáp án gần như chắc chắn là Alias record, không phải CNAME.
• CNAME chỉ dùng được cho subdomain, không dùng được ở zone apex. Đây là ranh giới phân biệt kinh điển giữa hai phương án ALIAS và CNAME trong đề thi AWS.
• Alias record trả về IP hiện tại của tài nguyên chứ không trả về một tên để client tra tiếp — nhờ vậy nó theo kịp việc IP của load balancer thay đổi khi scale hoặc cập nhật. Đừng bao giờ trỏ cứng IP vào một ELB.
• SOA và TXT là bản ghi siêu dữ liệu/văn bản, không phải bản ghi phân giải tới tài nguyên. Gặp chúng trong danh sách phương án của câu hỏi kiểu "trỏ tên miền về X" thì loại ngay.