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

Đáp án

A — CloudWatch Agent đẩy log ứng dụng vào CloudWatch Logs; CloudTrail ghi hoạt động API cũng vào CloudWatch Logs; truy vấn cả hai bằng CloudWatch Logs Insights.

Vì sao đúng

Yêu cầu là truy vấn được cả hai loại log, nên nguyên tắc rất đơn giản: đưa chúng về cùng một nơi, dùng cùng một công cụ.

CloudTrail ghi được vào hai đích: S3 (mặc định) và CloudWatch Logs (bật thêm). CloudWatch Agent thì đẩy thẳng vào CloudWatch Logs. Cho cả hai vào cùng một chỗ thì Logs Insights truy vấn được nhiều log group cùng lúc bằng một ngôn ngữ:

fields @timestamp, @log, @message
| filter @message like /ERROR/ or eventName = "TerminateInstances"
| sort @timestamp desc
| limit 100

Ưu điểm thực tế: kết quả gần như tức thì (log tới nơi là truy vấn được), không cần định nghĩa schema, không cần crawler, không cần bảng ngoài.

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

• C. App log → CloudWatch Logs, CloudTrail → S3, rồi dùng Logs Insights truy vấn cả hai — không làm được: Logs Insights chỉ đọc CloudWatch Logs, nó không đọc được S3. Hai tập log nằm ở hai nơi không truy vấn chung được bằng công cụ này. Đây là điểm loại rõ ràng nhất.
• D. Cả hai vào S3, dùng Athena — về nguyên tắc chạy được và là lựa chọn tốt cho phân tích lịch sử dài hạn. Nhưng CloudWatch Agent không ghi thẳng vào S3 — phải qua Firehose hoặc script tự viết, nên mô tả trong phương án đã đơn giản hoá quá mức. Với nhu cầu vận hành hằng ngày, Logs Insights cho kết quả nhanh hơn nhiều.
• B. Cả hai vào SQS — SQS là hàng đợi tin nhắn, không phải kho log và không truy vấn được. Message còn bị xoá sau khi tiêu thụ và có giới hạn thời gian giữ (tối đa 14 ngày). Sai loại dịch vụ hoàn toàn.

Ghi nhớ

Mẫu tối ưu ngoài đời: giữ log nóng trong CloudWatch Logs vài tuần cho Logs Insights, đồng thời xuất bản sao xuống S3 cho Athena và lưu trữ dài hạn.

Đáp án

A — Cập nhật launch template của Auto Scaling group để thêm tag cost center cho volume EBS.

Vì sao đúng

Điểm mấu chốt là phân biệt hai cơ chế gắn tag hoàn toàn khác nhau trong Auto Scaling:

Volume EBS là tài nguyên riêng biệt với instance, nên chỉ launch template mới gắn tag cho nó được:

{
  "TagSpecifications": [
    {"ResourceType": "instance", "Tags": [{"Key": "CostCenter", "Value": "KT-100"}]},
    {"ResourceType": "volume",   "Tags": [{"Key": "CostCenter", "Value": "KT-100"}]}
  ]
}

Sửa launch template thì mọi volume tạo từ đó về sau đều có tag — tự động, không cần quét, không cần sửa chữa định kỳ. Đó là vế "MOST efficient".

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

• C. Thêm tag vào ASG với PropagateAtLaunch: true — đây là bẫy trung tâm của câu hỏi, và rất nhiều người chọn nhầm. PropagateAtLaunch chỉ lan tag xuống instance EC2, không lan xuống volume EBS. Làm xong thì instance có tag, volume vẫn trắng như cũ.
• B. Tag Editor quét và sửa tay — chữa triệu chứng, không chữa nguyên nhân. Volume tạo ra sau đó vẫn thiếu tag, nên bạn phải quét lại mãi mãi. Không phải giải pháp tự động.
• D. AWS Config "cưỡng chế gắn tag lúc tạo và từ chối volume thiếu tag" — AWS Config không chặn được việc tạo tài nguyên. Nó là kiểm soát phát hiện (báo NON_COMPLIANT sau khi đã tạo), không phải kiểm soát ngăn chặn. Muốn chặn thì dùng SCP hoặc IAM policy với điều kiện aws:RequestTag.

Ghi nhớ

Nhớ dứt khoát: PropagateAtLaunch của ASG chỉ gắn tag cho instance. Muốn tag cả volume, ENI, hay các tài nguyên đi kèm thì phải khai TagSpecifications trong launch template. Đây là câu hỏi rất phổ biến vì hậu quả của việc nhầm lẫn — báo cáo phân bổ chi phí bị hụt phần lưu trữ — diễn ra hoàn toàn im lặng.

Đáp án

C — Dùng CloudFormation triển khai, dùng Lambda function version; khi đổi mã thì cập nhật stack và dùng canary release của API Gateway, kiểm thử xong thì promote.

Vì sao đúng

Yêu cầu: bản mới được một số ít người dùng thử trước khi phát cho tất cả — đúng định nghĩa canary.

Ứng dụng có hai tầng, và phải chia traffic ở tầng cửa ngõ:

Canary của API Gateway làm việc ở mức stage, ngay tại nơi request đi vào:

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations op=replace,path=/canarySettings/percentTraffic,value=10

• Chia theo phần trăm, cấu hình được stageVariableOverrides để canary trỏ sang version Lambda mới
• Metric riêng cho canary trong CloudWatch — so trực tiếp tỷ lệ lỗi và độ trễ giữa hai bản
• Rollback = xoá canary settings, tức thì
• Promote khi hài lòng

Lambda version cho phần bất biến: mỗi lần deploy tạo một bản chụp có số, nên canary và production trỏ vào hai bản khác nhau một cách rõ ràng.

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

• A. Route 53 latency routing làm canary — hiểu sai chính sách: latency routing chọn endpoint theo độ trễ mạng, hoàn toàn không có khái niệm phần trăm. Nó không chia traffic theo tỷ lệ được. (Muốn canary bằng DNS thì phải dùng weighted — nhưng DNS vẫn là lựa chọn kém vì vướng TTL.)
• B. Route 53 failover routing làm canary — sai còn xa hơn: failover là active/passive, chỉ chuyển khi endpoint chính hỏng. Nó không đưa một phần người dùng sang bản mới bao giờ.
• D. Elastic Beanstalk cho ứng dụng serverless — Beanstalk không triển khai được Lambda hay API Gateway. Nó dành cho ứng dụng chạy trên EC2 hoặc container. Sai nền tảng hoàn toàn.

Ghi nhớ

Có nhiều chỗ chia traffic được, chọn nơi gần cửa ngõ nhất: | Tầng | Cơ chế | |---|---| | API Gateway | canary stage — có metric riêng | | Lambda | weighted alias, hoặc SAM DeploymentPreference | | ALB | weighted target group | | Route 53 | weighted record — chậm vì TTL |

Với kiến trúc API Gateway + Lambda, canary ở API Gateway thường là lựa chọn tốt nhất vì nó có sẵn bộ metric để so sánh hai nhánh.

Đáp án

C — Tạo CloudTrail trail, tạo EventBridge rule bắt lời gọi API qua CloudTrail, và đặt SNS làm target.

Vì sao đúng

Cần cảnh báo gần thời gian thực khi có ai gọi DeleteTable, với chi phí thấp nhất.

Đường đi ngắn nhất có thể: CloudTrail → EventBridge → SNS, không có bước trung gian nào:

{
  "source": ["aws.dynamodb"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["dynamodb.amazonaws.com"],
    "eventName": ["DeleteTable"]
  }
}

Vì sao đây là rẻ nhất: SNS là target hợp lệ của EventBridge, nên không cần Lambda ở giữa. Không có mã để viết, không có hàm để trả tiền, không có gì để bảo trì. Và EventBridge chỉ tính tiền cho sự kiện tuỳ chỉnh, còn sự kiện dịch vụ AWS thì miễn phí.

Vế "gần thời gian thực" cũng đạt: CloudTrail đẩy sự kiện quản trị lên EventBridge trong vài phút.

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

• A. "CloudTrail event filter" + Lambda + SNS — CloudTrail không có cơ chế "event filter" tự phát thông báo. Việc lọc và định tuyến là của EventBridge. Và kể cả làm được thì thêm Lambda vào giữa là thêm chi phí không cần thiết khi SNS đã là target trực tiếp — trượt tiêu chí "most cost-effectively".
• B. "CloudWatch event filter theo dõi DeleteTable" — mô tả lẫn lộn hai thứ. Metric filter của CloudWatch Logs làm việc trên log group, nên nó chỉ dùng được nếu CloudTrail đã được cấu hình ghi vào CloudWatch Logs — mà cách đó tốn thêm phí nạp và lưu log, đắt hơn đường EventBridge trực tiếp.
• D. DynamoDB Streams — hiểu sai phạm vi của Streams: nó ghi lại thay đổi dữ liệu bên trong bảng (thêm/sửa/xoá item), không ghi thao tác quản trị như tạo hay xoá bảng. Xoá bảng thì stream cũng biến mất theo. Sai loại sự kiện hoàn toàn.

Ghi nhớ

Phân biệt hai mặt phẳng: | | Control plane | Data plane | |---|---|---| | Ví dụ | CreateTable, DeleteTable | PutItem, GetItem | | Ghi bởi | CloudTrail (management event) | CloudTrail data event (phải bật riêng, có phí) hoặc DynamoDB Streams |

Và nhớ: EventBridge gửi thẳng SNS được — đừng chèn Lambda vào khi không cần biến đổi nội dung.

Đáp án

C — EventBridge rule gọi một Lambda hằng ngày; hàm tìm volume chưa gắn, gắn tag ngày hiện tại, và xoá những volume đã mang tag quá 14 ngày.

Vì sao đúng

Thử thách thật của bài toán không phải "tìm volume chưa gắn" — mà là biết nó đã ở trạng thái đó bao lâu. AWS không lưu mốc thời gian tách rời ở đâu cả: create_time là lúc volume được tạo, không phải lúc nó bị tách khỏi instance.

Cách chữa là tự sinh ra dấu thời gian đó bằng tag:

def handler(event, context):
    hom_nay = datetime.utcnow().date()
    for v in ec2.describe_volumes(Filters=[{'Name':'status','Values':['available']}])['Volumes']:
        tag = {t['Key']: t['Value'] for t in v.get('Tags', [])}
        if 'ChuaGanTu' not in tag:
            ec2.create_tags(Resources=[v['VolumeId']],
                            Tags=[{'Key':'ChuaGanTu','Value':str(hom_nay)}])
        elif (hom_nay - date.fromisoformat(tag['ChuaGanTu'])).days >= 14:
            ec2.delete_volume(VolumeId=v['VolumeId'])

Cơ chế tự chữa: volume được gắn lại vào instance thì lần chạy sau nó không còn ở trạng thái available, và tag nên được xoá đi — đồng hồ đếm lại từ đầu nếu sau này nó lại bị tách.

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

• A. Data Lifecycle Manager với "volume lifecycle policy" cho volume chưa gắn — DLM không có loại policy này. DLM lên lịch tạo và xoá snapshot và AMI; nó không xoá volume. Phương án bịa ra một tính năng.
• B. Trusted Advisor phát hiện volume tách quá 14 ngày — Trusted Advisor có check "Underutilized Amazon EBS Volumes", nhưng nó dựa trên mức sử dụng I/O thấp, không theo dõi số ngày ở trạng thái tách rời. Nó cũng làm mới chậm và đòi gói hỗ trợ Business trở lên.
• D. Config rule ec2-volume-inuse-check + EventBridge "gọi Lambda sau 14 ngày" — rule này có thật và đánh dấu đúng volume chưa gắn, nhưng vế sau bất khả thi: EventBridge không lên lịch được một lần chạy trễ 14 ngày cho từng tài nguyên. Nó chỉ có lịch định kỳ. Muốn làm vậy phải dùng Step Functions với trạng thái Wait — phức tạp hơn hẳn cách gắn tag.

Ghi nhớ

Mẫu "tag làm đồng hồ" rất hay gặp trên AWS: khi cần biết một tài nguyên đã ở trạng thái nào đó bao lâu mà API không cho biết, hãy tự ghi mốc thời gian vào tag ở lần phát hiện đầu tiên, rồi so sánh ở các lần chạy sau. Áp dụng được cho volume mồ côi, snapshot cũ, Elastic IP không dùng, security group không ai gắn.

Đáp án

D — EventBridge rule với nguồn là AWS Health, bắt sự kiện instance retirement đã được lên lịch, rồi chạy SSM Automation document để stop và start các instance bị ảnh hưởng.

Vì sao đúng

Chi tiết quyết định: EC2 instance retirement là sự kiện được AWS thông báo TRƯỚC, và nó đến từ AWS Health, không phải từ EC2.

{
  "source": ["aws.health"],
  "detail-type": ["AWS Health Event"],
  "detail": {
    "service": ["EC2"],
    "eventTypeCategory": ["scheduledChange"],
    "eventTypeCode": ["AWS_EC2_PERSISTENT_INSTANCE_RETIREMENT_SCHEDULED"]
  }
}

Sự kiện này còn kèm danh sách instance bị ảnh hưởng (affectedEntities), nên Automation document biết chính xác phải xử lý máy nào.

Vì sao stop rồi start, không phải reboot. Đây là điểm kỹ thuật quan trọng nhất của câu hỏi: reboot giữ nguyên instance trên đúng máy chủ vật lý đang hỏng. Chỉ stop rồi start mới khiến EC2 đặt instance lên phần cứng khác — tức là thật sự thoát khỏi máy sắp bị thu hồi. Đây là lý do phương án nói rõ "stops and starts".

Với thousands of instances, việc chủ động xử lý trước theo lịch của mình tốt hơn nhiều so với để AWS tự dừng máy vào ngày đã định.

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

• A. EventBridge với nguồn aws.ec2, bắt state-change "shutting-down" — phản ứng quá muộn: lúc instance đã bắt đầu tắt thì thiệt hại đã xảy ra. Toàn bộ giá trị của retirement notice là nó đến trước hàng ngày hoặc hàng tuần.
• B. EC2 Auto Recovery + alarm với action Recover — Auto Recovery kích hoạt khi status check của hệ thống đã hỏng, tức là sau khi có sự cố. Nó không phản ứng với thông báo retirement. Ngoài ra "chỉ định thời điểm phục hồi ngoài giờ làm việc" là thứ alarm action không hỗ trợ.
• C. Alarm status check → SNS → để đội vận hành tự stop/start — thủ công. Với hàng nghìn instance thì bất khả thi, và đề yêu cầu tự động hoá.

Ghi nhớ

Và nhớ: mọi sự kiện thông báo trước của AWS (retirement, bảo trì theo lịch, sự cố Region, chứng chỉ sắp hết hạn) đều đến qua AWS Health, nguồn aws.health trong EventBridge — không phải qua sự kiện của từng dịch vụ.

Đáp án

C — Application Load Balancer làm cửa ngõ, tạo HTTP listener, đặt các hàm Lambda làm target trong các target group riêng, và tạo path-based routing rule.

Vì sao đúng

Đề có một yêu cầu bất thường và đó chính là chìa khoá: "hỗ trợ HTTP không mã hoá".

API Gateway chỉ phục vụ HTTPS. Nó không có cách nào tạo endpoint HTTP thuần — mọi endpoint đều là https://. Điều đó loại thẳng cả A và B, bất kể chúng mô tả tích hợp Lambda kiểu gì.

ALB thì tạo được listener trên cổng 80 với giao thức HTTP, và từ 2018 nó gọi Lambda trực tiếp làm target:

Listener HTTP:80
  ├─ Rule: path = /don-hang/*   → target group A (Lambda xu-ly-don-hang)
  ├─ Rule: path = /nguoi-dung/* → target group B (Lambda xu-ly-nguoi-dung)
  └─ Default                    → target group C

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

• A. API Gateway HTTP API "với HTTP endpoint" — tên gọi gây nhầm lẫn: "HTTP API" là loại API (đơn giản và rẻ hơn REST API), không có nghĩa là nó phục vụ giao thức HTTP không mã hoá. Endpoint của nó vẫn là HTTPS.
• B. API Gateway REST API "với HTTP endpoint" — cùng lỗi. REST API cũng chỉ có HTTPS.
• D. Network Load Balancer với HTTP listener và IP-based routing — sai hai chỗ. NLB làm việc ở tầng 4, nó không đọc được HTTP nên không có listener HTTP và không định tuyến theo path được. Ngoài ra NLB không nhận Lambda làm target — chỉ ALB mới nhận.

Ghi nhớ

Từ khoá "unencrypted HTTP" trong đề gần như luôn dùng để loại API Gateway.

Đáp án

A — Sửa service role của CodeBuild project để thêm quyền S3, rồi dùng AWS CLI tải dữ liệu về.

Vì sao đúng

Nguyên tắc bất di bất dịch: compute của AWS luôn dùng role, không bao giờ dùng khoá tĩnh.

CodeBuild chạy dưới một service role. Mọi lệnh AWS CLI trong buildspec tự động dùng thông tin xác thực tạm thời lấy từ role đó — có hạn, tự xoay vòng, không bao giờ xuất hiện trong mã nguồn hay biến môi trường:

phases:
  pre_build:
    commands:
      - aws s3 cp s3://kho-du-lieu/du-lieu.json .

Chỉ cần bổ sung policy cho role, giới hạn đúng bucket và đúng prefix:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:ListBucket"],
  "Resource": ["arn:aws:s3:::kho-du-lieu", "arn:aws:s3:::kho-du-lieu/*"]
}

Đây cũng là mẫu chung cho toàn bộ AWS: EC2 → instance profile, Lambda → execution role, ECS → task role, CodeBuild → service role.

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

• D. Ghi access key và secret key trong mã ứng dụng — kém an toàn nhất trong bốn phương án. Khoá nằm trong repo, ai clone cũng có, không tự hết hạn, và rò rỉ thì kẻ tấn công dùng được cho tới khi có người phát hiện và thu hồi.
• B. "Bật HTTPS basic authentication trên bucket S3 và chỉ định token" — S3 không có tính năng này. S3 xác thực bằng SigV4; không có basic auth, không có token tự đặt. Phương án bịa ra một khả năng không tồn tại.
• C. Dùng điều kiện aws:Referer — aws:Referer đọc header HTTP Referer, mà header đó client tự đặt được và giả mạo trong một dòng lệnh:

  curl -H "Referer: gia-mao" https://bucket.s3.amazonaws.com/file
  

  AWS ghi rõ trong tài liệu rằng nó không nên dùng làm cơ chế bảo mật. Ngoài ra CodeBuild project cũng không có chỗ nào đặt điều kiện này.

Ghi nhớ

Thứ tự ưu tiên khi cấp quyền cho một dịch vụ AWS gọi dịch vụ AWS khác: IAM role trước, IAM role giữa, IAM role sau. Thấy phương án nào nhắc tới access key tĩnh, basic auth, hay aws:Referer trong ngữ cảnh này thì gần như chắc chắn loại được.

Đáp án

A và C.

• C — Gắn IAM policy cấp quyền Systems Manager cho instance profile hiện có.
• A — Tạo VPC endpoint cho Systems Manager ở Region liên quan.

Vì sao đúng

Hai yêu cầu: dùng Session Manager thay key pair, và truy cập chỉ đi qua mạng riêng.

Vế quyền (C). SSM Agent tự đăng ký với dịch vụ Systems Manager bằng instance profile. Policy dựng sẵn là AmazonSSMManagedInstanceCore. Không có nó, instance không bao giờ hiện ra trong danh sách managed instances — và không có thông báo lỗi nào ở phía Console.

Vế mạng riêng (A). Mặc định SSM Agent gọi ra endpoint công cộng qua Internet. Muốn đi hoàn toàn trong VPC thì cần interface endpoint, và phải đủ ba cái:

Thiếu ssmmessages là lỗi kinh điển: instance hiện trạng thái Managed bình thường, nhưng mở phiên thì treo rồi timeout không rõ lý do.

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

• D. Mở cổng SSH 22 từ dải CIDR của VPC — đi ngược mục đích. Session Manager không dùng SSH và không cần rule inbound nào; agent tự mở kết nối đi ra. Giá trị lớn nhất của nó chính là security group không có rule inbound nào cả.
• B. Chạy aws configure để đặt access key trên mọi instance — thay khoá SSH bằng khoá AWS tĩnh: vẫn là bí mật dài hạn nằm rải rác trên hàng loạt máy, không tự hết hạn, và cực khó xoay vòng. Instance profile là giải pháp đúng.
• E. Site-to-Site VPN — VPN nối mạng on-premises với VPC. Nó không làm cho traffic từ instance trong VPC tới dịch vụ AWS đi qua đường riêng — việc đó là của VPC endpoint.

Ghi nhớ

Công thức Session Manager trong subnet riêng: AmazonSSMManagedInstanceCore + ba interface endpoint (ssm, ssmmessages, ec2messages) + security group của endpoint mở HTTPS 443 từ dải VPC. Thêm s3 gateway endpoint nếu muốn ghi log phiên vào S3, và kms nếu bật mã hoá phiên.

Đáp án

B và E.

• B — Người dùng hoặc role thực hiện cập nhật stack không đủ quyền.
• E — Tài nguyên bị thay đổi bên ngoài CloudFormation mà template không được cập nhật theo.

Vì sao đúng

UPDATE_ROLLBACK_FAILED nghĩa là: cập nhật hỏng, CloudFormation cố quay về trạng thái trước đó, và chính việc quay về cũng thất bại. Hai nguyên nhân phổ biến nhất chính là hai phương án được chọn.

Nguyên nhân B — thiếu quyền. Rollback đòi CloudFormation phải hoàn tác thay đổi: tạo lại thứ đã xoá, xoá thứ vừa tạo, đặt lại giá trị cũ. Nếu role không đủ quyền cho một trong các thao tác đó, rollback dừng giữa chừng. Rất hay xảy ra khi role có quyền Create nhưng thiếu Delete, hoặc thiếu iam:PassRole.

Nguyên nhân E — drift. Ai đó sửa tài nguyên bằng tay qua Console. CloudFormation vẫn tin vào trạng thái nó ghi nhớ, nên khi rollback nó cố khôi phục về một trạng thái không còn khớp với thực tế — ví dụ trỏ vào một security group đã bị xoá, hoặc gán lại một tên đã bị người khác chiếm. Đây là lý do vì sao sửa tay tài nguyên do CloudFormation quản lý là việc nên tránh.

Cách chữa:

aws cloudformation continue-update-rollback --stack-name my-stack
# Bó tay với một tài nguyên cụ thể thì bỏ qua nó (để lại drift):
aws cloudformation continue-update-rollback --stack-name my-stack \
  --resources-to-skip LogicalIdCuaTaiNguyenKetCung

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

• A. Interface VPC endpoint không hoạt động — có thể gây lỗi tạm thời, nhưng nó không phải nguyên nhân điển hình của UPDATE_ROLLBACK_FAILED, và CloudFormation không cần VPC endpoint để quản lý tài nguyên (nó gọi API dịch vụ ở mặt phẳng điều khiển).
• C. Chạy yum update trên EC2 trong stack — cập nhật gói phần mềm bên trong hệ điều hành. CloudFormation không theo dõi nội dung bên trong instance, chỉ theo dõi thuộc tính của tài nguyên EC2. Việc này không gây drift ở mức CloudFormation.
• D. Không tạo và chạy change set trước — change set là công cụ xem trước thay đổi. Bỏ qua nó làm bạn mất cơ hội phát hiện vấn đề sớm, nhưng nó không phải nguyên nhân khiến rollback thất bại.

Ghi nhớ

Ba trạng thái "kẹt" của CloudFormation và cách thoát: | Trạng thái | Cách thoát | |---|---| | UPDATE_ROLLBACK_FAILED | ContinueUpdateRollback (sửa nguyên nhân trước) | | ROLLBACK_FAILED (lúc tạo mới) | chỉ xoá stack được | | DELETE_FAILED | xoá lại với --retain-resources |

Phòng bệnh tốt nhất: đừng sửa tay tài nguyên do CloudFormation quản lý, và chạy drift detection định kỳ.