Ngân hàng đề — AWS Certified DevOps Engineer Professional

Đáp án

D — Tạo CloudFormation service role với đúng quyền cần thiết, gắn vào stack, và cấp cho developer quyền iam:PassRole lên role đó.

Vì sao đúng

Đây là mẫu quyền uỷ nhiệm kinh điển của CloudFormation. Mặc định, CloudFormation dùng quyền của chính người gọi để tạo tài nguyên — nên developer không có quyền tạo RDS thì stack cũng không tạo được RDS.

Service role đảo chuyện đó: CloudFormation dùng quyền của role, không dùng quyền của người gọi. Developer chỉ cần đúng hai quyền:

{
  "Effect": "Allow",
  "Action": ["cloudformation:CreateStack", "cloudformation:UpdateStack",
             "cloudformation:DescribeStacks"],
  "Resource": "*"
},
{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::123456789012:role/cfn-deploy-role"
}

iam:PassRole là mảnh bắt buộc và hay bị quên. Không có nó thì AWS chặn ngay lời gọi với thông báo is not authorized to perform: iam:PassRole — chính là cơ chế ngăn người dùng tuỳ tiện trao cho dịch vụ một role mạnh hơn quyền của mình.

Về least privilege: developer không hề được cấp quyền tạo RDS/EC2. Họ chỉ được phép trao đúng một role cụ thể cho CloudFormation, và role đó chỉ tạo được đúng những gì template khai.

Vì sao các phương án khác sai

• A. Service role full permissions — vi phạm thẳng yêu cầu "least privileges possible". Giới hạn PassRole theo tag làm hẹp ai được trao role nào, nhưng bản thân role vẫn toàn quyền — leo thang đặc quyền chỉ cách một template.
• **B. Có service role nhưng không cấp iam:PassRole — thiếu đúng mảnh ghép then chốt. Developer sẽ nhận AccessDenied ngay khi gọi CreateStack với --role-arn.
• C. Dùng aws:SourceIp giới hạn theo IP — IP không phải cơ chế cấp quyền. Developer làm việc từ xa, đổi mạng, hoặc dùng VPN là hỏng; ngược lại ai đang ở trong dải IP đó cũng không vì thế mà đáng tin. Và cũng vẫn thiếu iam:PassRole.

Ghi nhớ

Bất cứ khi nào một dịch vụ AWS hành động thay mặt bạn bằng một role (CloudFormation service role, EC2 instance profile, Lambda execution role, CodePipeline service role), người cấu hình luôn cần iam:PassRole lên role đó — và nên giới hạn Resource xuống đúng ARN, đừng để *.

Đáp án

C — Metric filter trên CloudWatch Logs bắt từ khoá Critical, phát metric tuỳ chỉnh, đặt alarm trên metric đó và gửi SNS.

Vì sao đúng

Đề đã cho sẵn nửa đầu: log của firewall appliance đã ở trong CloudWatch Logs. Việc còn lại là biến chuỗi văn bản thành cảnh báo, và đường đi chuẩn có đúng ba bước:

Metric filter (log → số)  →  CloudWatch alarm (số → trạng thái)  →  SNS (trạng thái → người)

Metric filter là mắt xích không thể thiếu vì CloudWatch alarm chỉ làm việc với metric, không đọc được văn bản log. Filter đếm số dòng khớp Critical trong mỗi khoảng thời gian; alarm kêu khi con số đó > 0.

# Mẫu filter đơn giản
"Critical"
# Hoặc theo trường nếu log là JSON
{ $.severity = "Critical" }

Vì sao các phương án khác sai

• A. Transit Gateway Flow Log — flow log ghi metadata luồng mạng (IP nguồn/đích, cổng, số byte, accept/reject). Nó không chứa phán quyết Critical của firewall appliance; đó là log ứng dụng do chính appliance sinh ra. Sai nguồn dữ liệu.
• B. CloudWatch Lambda Insights — Lambda Insights là công cụ giám sát hiệu năng hàm Lambda (CPU, bộ nhớ, cold start). Không liên quan gì tới lọc log firewall.
• D. Metric stream + Firehose + Lambda — Metric Streams đẩy metric (không phải log) ra ngoài gần thời gian thực, phục vụ nạp vào công cụ bên thứ ba. Ở đây nó chỉ thêm hai dịch vụ vào đường đi mà vẫn phải tự viết logic cảnh báo — trong khi CloudWatch alarm làm sẵn.

Ghi nhớ

Nhớ dứt khoát ba cặp hay lẫn: | Muốn | Dùng | |---|---| | Cảnh báo theo mẫu trong log | metric filter + alarm | | Đưa log thô sang nơi khác | subscription filter | | Đưa metric sang nơi khác | Metric Streams |

Đáp án

A — AWS Config với managed rule cho AWS::EC2::Volume báo NON_COMPLIANT khi thiếu tag, kèm remediation tự gắn tag.

Vì sao đúng

Vấn đề trong đề là thiếu tag ⇒ không được sao lưu, và đáng sợ ở chỗ nó im lặng: không có lỗi nào, chỉ có volume lặng lẽ nằm ngoài lịch backup cho tới khi kiểm toán phát hiện.

AWS Config hợp ở đây vì ba lý do:

1. Có managed rule sẵn — required-tags — nhận tối đa 6 cặp khoá/giá trị, và lọc được theo loại tài nguyên đúng AWS::EC2::Volume.
2. Đánh giá cả tài nguyên đang tồn tại lẫn tài nguyên mới. Đây là điểm quyết định: EventBridge chỉ bắt được volume tạo từ nay trở đi, còn những volume đã tồn tại mà thiếu tag — chính là những cái đang bị bỏ sót trong báo cáo kiểm toán — thì không ai chạm tới.
3. Nối được thẳng vào Auto Remediation để tự gắn tag weekly mặc định.

Vì sao các phương án khác sai

• B. EventBridge bắt sự kiện CreateVolume từ CloudTrail — chỉ vá được về sau. Volume cũ vẫn nằm nguyên ngoài vùng phủ, mà đó mới là thứ báo cáo kiểm toán đang chỉ ra. Ngoài ra, chỉ dựa vào sự kiện thì không phát hiện được trường hợp tag bị gỡ sau đó.
• C. Trusted Advisor "EBS VolumeBackup check" — không có check nào tên như vậy phát ra sự kiện EventBridge kiểu này. Trusted Advisor có check về snapshot EBS nhưng chạy theo chu kỳ chậm và không phải cơ chế thực thi tag.
• D. Rule cho EC2::Instance thay vì EC2::Volume — sai đối tượng theo hai cách. Thứ nhất, tag phải nằm trên volume, vì công cụ backup đọc tag của volume. Thứ hai, volume chưa gắn vào instance nào sẽ hoàn toàn nằm ngoài tầm của rule này — mà volume rời chính là loại dễ bị quên nhất.

Ghi nhớ

Config đánh giá trạng thái hiện tại của tất cả tài nguyên; EventBridge chỉ phản ứng với sự kiện xảy ra từ lúc bật. Bài toán có phần "dọn nợ cũ" thì phải chọn Config. Muốn đủ bộ thì dùng cả hai: Config dọn nợ cũ, EventBridge chặn ngay từ đầu.

Đáp án

D — Giá trị checksum mới được tính từ checksum của các phần riêng lẻ; đây là hành vi đúng như thiết kế.

Vì sao đúng

Chuyện xảy ra nằm ở chỗ cách object được ghi lần thứ hai, chứ không phải ở metadata hay kích thước ngưỡng.

• Lần đầu: developer dùng REST API PutObject để tải một phần (single-part) 100 MB. Checksum tính trên toàn bộ object.
• Lần sau: đổi tên / sao chép / sửa metadata trong Console. Console không sao chép object bằng một lời gọi đơn — với object lớn nó dùng multipart copy. Object mới vì thế được ghi thành nhiều phần, và checksum trở thành checksum của các checksum thành phần, kèm hậu tố -<số phần>.

Single-part : a1b2c3d4e5f6...            (checksum của toàn bộ nội dung)
Multipart   : 9f8e7d6c5b4a...-8          (checksum tổng hợp, 8 phần)

Nội dung file không hề đổi. Chỉ cách tính đổi vì cách ghi đổi. Muốn so sánh có ý nghĩa thì phải so hai object được ghi cùng kiểu, hoặc dùng thuật toán checksum full-object như CRC64NVME/CRC32 với chế độ full-object.

Vì sao các phương án khác sai

• A. "Đổi metadata thì thuật toán checksum đổi theo mặc định" — không có hành vi nào như vậy. Thuật toán do người gọi chọn; cái đổi là phạm vi tính (toàn bộ vs. theo phần), không phải thuật toán.
• B. Ngưỡng 16 MB và C. Ngưỡng 50 MB — cả hai đều bịa ra một con số. S3 không có ngưỡng cố định nào tự chuyển object sang chế độ checksum theo phần. Ngưỡng thực tế là ngưỡng multipart của công cụ đang dùng (AWS CLI mặc định 8 MB, Console và các SDK có giá trị riêng), và nó có thể chỉnh được — không phải hằng số của dịch vụ.

Ghi nhớ

ETag/checksum có hậu tố -N nghĩa là object được ghi bằng multipart, và giá trị đó không phải hash của toàn bộ nội dung. Đây là lý do rất nhiều script kiểm tra toàn vẹn báo sai sau khi file được copy bằng công cụ khác — file vẫn nguyên, chỉ cách ghi khác.

Đáp án

C — Route 53 trỏ tới API Gateway ở cả hai Region, dùng latency-based routing kèm health check.

Vì sao đúng

Đề yêu cầu ba thứ: độ trễ thấp cho người dùng toàn cầu, độ tin cậy cao, và giải pháp nhanh triển khai (quick-start).

Latency-based routing đưa mỗi người dùng tới Region có độ trễ mạng đo được thấp nhất tới họ — không phải Region gần nhất về mặt địa lý. Đây là khác biệt quan trọng: đường đi mạng thực tế nhiều khi không theo bản đồ, và Route 53 dùng dữ liệu độ trễ nó tự đo liên tục.

Ghép với health check, Region hỏng sẽ bị loại khỏi kết quả DNS và traffic tự dồn sang Region còn lại — đó là vế "high reliability".

Vì sao các phương án khác sai

• A. Geolocation routing — định tuyến theo vị trí địa lý của người truy vấn, không theo độ trễ. Nó hợp khi có ràng buộc pháp lý ("người EU phải vào hạ tầng EU") hoặc cần nội dung theo vùng. Người dùng ở Trung Đông có thể bị gán về EU trong khi đường tới Singapore lại nhanh hơn. Ngoài ra geolocation có một cái bẫy: phải có bản ghi mặc định, thiếu nó thì truy vấn từ vùng không khớp sẽ không nhận được câu trả lời nào.
• B. Failover routing — mô hình active/passive: mọi người dùng vào Region chính, chỉ chuyển sang phụ khi chính hỏng. Cho độ sẵn sàng nhưng không cho độ trễ thấp — người dùng châu Á vẫn đi tới Region châu Âu.
• D. Global Accelerator qua ALB tới API Gateway — Global Accelerator là một giải pháp tốt cho độ trễ toàn cầu (anycast IP, đi vào mạng lưng AWS ngay từ edge). Nhưng phương án này bắt dựng thêm ALB đứng trước API Gateway — thêm một tầng, thêm chi phí, thêm cấu hình — nên trượt tiêu chí quick-start. Với API Gateway, cách rẻ và nhanh hơn là edge-optimized endpoint hoặc chính latency-based routing.

Ghi nhớ

Đáp án

B và C.

• C — Thêm lifecycle hook đưa instance vào trạng thái Terminating:Wait, và tạo CloudWatch/EventBridge rule theo dõi trạng thái đó.
• B — Đặt SSM Automation document làm target; document chạy PowerShell gỡ máy khỏi domain rồi tạo AMI.

Vì sao đúng

Mặc định, scale-in huỷ instance ngay lập tức, không cho ai kịp làm gì. Lifecycle hook là cơ chế duy nhất tạm dừng việc đó.

Vòng đời khi có hook:

InService → Terminating → Terminating:Wait ← (dừng ở đây, mặc định 1 giờ)
                                ↓ CompleteLifecycleAction
                          Terminating:Proceed → Terminated

Ở Terminating:Wait, ASG phát một sự kiện; EventBridge bắt nó và gọi SSM Automation document. Document chạy PowerShell trên máy Windows:

Remove-Computer -UnjoinDomainCredential $cred -Force -PassThru

rồi gọi New-EC2Image để tạo AMI, cuối cùng gọi Complete-ASLifecycleAction để thả instance cho ASG huỷ. Nếu quên bước cuối, instance nằm ở Terminating:Wait cho tới khi hết timeout (mặc định 3600 giây, tối đa 48 giờ) — vẫn tính tiền suốt thời gian đó.

Vì sao các phương án khác sai

• A. Patch Manager làm target — Patch Manager chỉ làm một việc: vá hệ điều hành theo baseline. Nó không chạy được PowerShell tuỳ ý và không tạo AMI.
• D. Terminating:Pending — trạng thái này không tồn tại. Cặp Pending:Wait/Pending:Proceed thuộc phía launch; phía terminate là Terminating:Wait/Terminating:Proceed. Bẫy đối xứng cố ý.
• E. Maintenance Window theo lịch — scale-in xảy ra bất kỳ lúc nào tuỳ tải, không theo lịch. Cửa sổ bảo trì chạy 2 giờ sáng thì instance bị huỷ lúc 10 giờ sáng đã biến mất từ lâu.

Ghi nhớ

Bốn trạng thái lifecycle hook cần thuộc: Pending:Wait, Pending:Proceed (lúc tạo), Terminating:Wait, Terminating:Proceed (lúc huỷ). Và luôn gọi CompleteLifecycleAction ở nhánh thành công lẫn nhánh lỗi — nếu không, mỗi lần scale-in để lại một instance treo tính tiền cả tiếng.

Đáp án

B — Từ management account của Organizations, tạo CloudFormation StackSet để triển khai IAM role tập trung và bật cấu hình, dùng automatic deployment để tài khoản mới tự nhận.

Vì sao đúng

Hai từ khoá của đề: hàng trăm tài khoản và "tự động áp cho mọi tài khoản mới".

StackSets với service-managed permissions đáp ứng cả hai:

• Triển khai một template ra toàn bộ OU đã chọn, không phải từng tài khoản.
• Bật automatic deployment thì mọi tài khoản mới được thêm vào OU sẽ tự nhận stack, không ai phải làm gì. Đây chính là vế quan trọng nhất của đề.
• Tài khoản bị chuyển ra khỏi OU thì stack instance cũng tự gỡ (tuỳ cấu hình).

aws cloudformation create-stack-set --stack-set-name nen-tang-bao-mat \
  --template-body file://baseline.yaml \
  --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \
  --capabilities CAPABILITY_NAMED_IAM

Vì sao các phương án khác sai

• A. SSM Automation + resource group đặt tên giống nhau ở mọi tài khoản — chạy được lệnh trên nhiều tài khoản, nhưng SSM là công cụ vận hành (chạy tác vụ), không phải công cụ cung cấp hạ tầng có trạng thái. Nó không theo dõi drift, không dựng lại khi bị xoá, và điều kiện "resource group đặt tên hệt nhau ở mọi tài khoản" là một quy ước mong manh do người giữ.
• C. Bật CloudTrail cho member account rồi "chia sẻ IAM role" — IAM role không chia sẻ được giữa các tài khoản. Mỗi tài khoản có không gian IAM riêng; muốn có cùng role thì phải tạo role đó trong từng tài khoản — đúng là việc StackSets làm.
• D. EventBridge bắt sự kiện tạo tài khoản → Lambda — có thể chạy được, nhưng đó là tự dựng lại StackSets bằng tay: phải tự viết hàm, tự xử lý lỗi, tự xử lý chạy lại, tự xử lý drift, tự xử lý hàng trăm tài khoản đã tồn tại (sự kiện chỉ bắt tài khoản mới). Nhiều mã, nhiều chỗ hỏng, không được gì thêm.

Ghi nhớ về chất lượng câu hỏi

Đề nói yêu cầu là IAM role + CloudTrail, nhưng phương án B lại viết "enable AWS Config and deploy your centralized IAM roles". Nội dung phương án lệch với đề bài ở đúng chỗ nhạy cảm: Config không phải CloudTrail.

Dù vậy B vẫn là đáp án đúng vì cơ chế mới là thứ đang được hỏi — StackSets với automatic deployment là câu trả lời duy nhất đúng cho "áp cấu hình nền cho mọi tài khoản hiện có và tương lai". Ba phương án còn lại sai ở tầng cơ chế, không phải ở tầng tên dịch vụ. Ngoài đời, cách chuẩn cho vế CloudTrail còn gọn hơn: organization trail bật một lần ở management account là phủ toàn tổ chức.

Đáp án

C — CloudWatch Logs subscription filter đẩy sự kiện đăng nhập sang Lambda; Lambda gắn tag decommission cho instance, rồi cơ chế theo lịch huỷ instance đã gắn tag.

Vì sao đúng

Ba mảnh phải khớp với ba đặc điểm của bài toán:

1. Vì sao subscription filter chứ không metric filter. Cần biết instance nào đã bị đăng nhập, tức là cần nội dung dòng log (instance id nằm trong tên log stream hoặc trong message). Metric filter chỉ tạo ra con số đếm — nó nói "có 3 lần đăng nhập" mà không nói ở máy nào. Subscription filter chuyển log thô sang Lambda, nên Lambda đọc được instance id.

2. Vì sao gắn tag rồi mới huỷ. Đề cho một giờ để hành động, không phải huỷ ngay. Tag là cách ghi lại "instance này đã bị đánh dấu" một cách bền vững, tách khâu phát hiện khỏi khâu thực thi. Cũng nhờ vậy mà có thời gian để người vận hành can thiệp nếu đó là truy cập hợp lệ.

3. Vì sao huỷ được an toàn. Instance nằm trong Auto Scaling group, nên huỷ xong ASG tự bù instance sạch — dịch vụ không gián đoạn.

Vì sao các phương án khác sai

• A. Step Functions điều phối Lambda và EventBridge — không sai về kỹ thuật nhưng thừa hẳn một tầng. Step Functions dành cho quy trình nhiều bước có nhánh, có chờ đợi dài; ở đây chỉ có "đọc log, gắn tag" là xong.
• B. CloudWatch alarm kích hoạt bởi "login event data" — alarm không đọc được log, nó chỉ đọc metric. Và nếu đi vòng qua metric filter thì lại mất thông tin instance nào (xem điểm 1). Cùng lỗi khái niệm với D.
• D. Alarm gửi SNS cho quản trị viên — biến quy trình tự động thành thao tác tay. Đề nói rõ "automate this process", và chính sách đòi huỷ trong vòng một giờ — dựa vào người đọc email là không đảm bảo được thời hạn.

Ghi nhớ

Câu hỏi tiếp theo trong bộ đề này (#4437) là cùng một tình huống với ngưỡng 24 giờ, và đáp án cũng đúng kiến trúc đó: subscription filter → Lambda → gắn tag → cơ chế theo lịch huỷ. Nhớ một lần, trả lời được cả hai.

Đáp án

B và E.

• B — Tạo AWS KMS key để dùng với CodePipeline ở tài khoản development; bucket đầu vào phải bật versioning.
• E — Tạo cross-account role ở tài khoản production; gắn policy cho CodePipeline service role ở tài khoản development để nó assume được role đó.

Vì sao đúng

Pipeline chạy ở development, deploy sang production. Hai điều kiện bắt buộc:

Vế mã hoá (B). Artifact của CodePipeline nằm trong S3 và bắt buộc được mã hoá. Để tài khoản production giải mã được, phải dùng customer-managed KMS key — key mặc định aws/s3 không sửa được key policy, nên không có cách nào cấp quyền cho tài khoản khác. Đây là lý do kinh điển vì sao deploy chéo tài khoản luôn cần CMK.

Vế versioning cũng bắt buộc: CodePipeline dựa vào version ID của object để biết đâu là artifact của lần chạy nào. Bucket nguồn không bật versioning thì source action báo lỗi thẳng.

Vế quyền (E). Đúng mẫu hai vế quen thuộc:

• Trust policy của role ở production nêu tên tài khoản development.
• Identity policy của CodePipeline service role ở development cho phép sts:AssumeRole lên ARN role đó.

Thêm một mảnh mà đề không nêu nhưng thực tế phải có: bucket policy ở production cho phép ghi, và thường kèm s3:x-amz-acl: bucket-owner-full-control để tài khoản đích thực sự sở hữu object nhận được.

Vì sao các phương án khác sai

• A. Cross-account role ở tài khoản development — ngược chiều. Role được assume phải nằm ở nơi cần đi tới, tức là production.
• C. "Phải dùng KMS multi-Region key" — không cần. Đề nói rõ cả hai tài khoản đều ở us-east-1. Multi-Region key chỉ cần khi giải mã ở Region khác.
• D. "Secrets Manager key" — nhầm dịch vụ. Secrets Manager giữ bí mật (mật khẩu, chuỗi kết nối); mã hoá artifact là việc của KMS.

Ghi nhớ

Ba thứ luôn phải có khi CodePipeline deploy chéo tài khoản: customer-managed KMS key, versioning trên bucket artifact, và cặp trust + assume-role đúng chiều. Quên CMK thì triệu chứng đặc trưng là action ở tài khoản đích báo AccessDenied khi giải mã, dù quyền S3 nhìn có vẻ đủ.

Đáp án

A — Dùng CloudWatch cross-account observability, đặt tài khoản security/operations làm monitoring account và liên kết các tài khoản thành viên qua AWS Organizations.

Vì sao đúng

Ba yêu cầu của đề, và cross-account observability đáp ứng đủ:

Điểm quyết định nằm ở chữ "qua AWS Organizations". Khi liên kết theo tổ chức, mọi tài khoản được tạo sau này trong phạm vi đã chọn tự động trở thành source account. Đó chính xác là yêu cầu cuối của đề.

Cần nhớ hướng của mô hình này: monitoring account (nơi xem) và source account (nơi sinh dữ liệu). Dữ liệu vẫn nằm ở tài khoản nguồn, monitoring account chỉ truy vấn xuyên qua — không có bản sao, không có chi phí nhân đôi.

Vì sao các phương án khác sai

• **C. Cùng tính năng nhưng liên kết từng tài khoản qua console — đây là bẫy tinh vi nhất của câu này. Cùng dịch vụ, cùng kết quả trước mắt, nhưng thiếu vế tự động: hàng trăm tài khoản phải nối tay, và mỗi tài khoản mới sinh ra lại phải nhớ nối. Yêu cầu "tự động onboard tài khoản mới" bị bỏ.
• B. Alarm → EventBridge → S3 → Athena — alarm chỉ phát khi vượt ngưỡng; nó không phải cơ chế xuất dữ liệu. Và cách này không mang được log lẫn trace về.
• D. Metric Streams → Firehose → S3 — chỉ mang được metric, mất hẳn log và trace. Ngoài ra phải tự dựng và tự nuôi đường ống cho hàng trăm tài khoản, trả tiền lưu trữ bản sao, trong khi vẫn không có công cụ tra cứu thống nhất.

Ghi nhớ

CloudWatch cross-account observability là câu trả lời chuẩn cho "giám sát tập trung nhiều tài khoản". Hai chi tiết hay bị hỏi: nó mang được cả ba loại tín hiệu (metrics, logs, traces), và liên kết qua Organizations mới có tự động onboard.