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

Đáp án

A và E.

• A — Ở Account A: tạo AMI đã mã hoá từ bản chưa mã hoá, chỉ định KMS key của bạn trong lệnh copy, sửa key policy cho Account B được tạo grant, rồi chia sẻ AMI.
• E — Ở Account B: tạo KMS grant uỷ quyền cho service-linked role của Auto Scaling.

Vì sao đúng

Đây là một trong những kịch bản nhiều mảnh nhất của IAM + KMS. Bốn bước, thiếu bước nào cũng hỏng:

1. Mã hoá AMI. Không mã hoá tại chỗ được — phải copy và chỉ định key trong lệnh:

aws ec2 copy-image --source-image-id ami-xxxx --source-region ap-southeast-1 \
  --region ap-southeast-1 --name "ami-da-ma-hoa" \
  --encrypted --kms-key-id arn:aws:kms:...:key/<CMK-cua-A>

2. Sửa key policy ở A. Account B phải được kms:Decrypt, kms:CreateGrant, kms:DescribeKey.

3. Chia sẻ AMI với Account B (modify-image-attribute --launch-permission).

4. Tạo grant cho service-linked role của ASG ở B. Đây là bước hay bị bỏ sót nhất và là lý do E có mặt. Auto Scaling không khởi tạo instance bằng danh tính của người dùng — nó dùng service-linked role AWSServiceRoleForAutoScaling. Role đó cũng phải giải mã được volume, mà nó không nằm trong bất kỳ policy nào của bạn. Phải tạo grant tường minh:

aws kms create-grant --key-id <arn-key-cua-A> \
  --grantee-principal arn:aws:iam::<AccountB>:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling \
  --operations Decrypt GenerateDataKey CreateGrant DescribeKey

Thiếu bước này, triệu chứng rất khó chẩn đoán: launch bằng tay thì được, còn ASG scale-out thì thất bại với Client.InternalError: Client error on launch.

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

• B. Chỉ sửa launch permission của AMI — chia sẻ AMI mà không cấp quyền dùng KMS key. Account B thấy được AMI nhưng không giải mã nổi snapshot.
• C. Không sửa key policy — cùng vấn đề: quyền dùng key không tự đi kèm với việc chia sẻ AMI.
• D. Dùng AWS managed key — sai dứt khoát. Key do AWS quản lý (aws/ebs) không sửa được key policy và không chia sẻ chéo tài khoản được. Đây là ranh giới cứng giữa AWS managed key và customer managed key.

Ghi nhớ

AWS managed key không bao giờ dùng chéo tài khoản được. Cứ thấy đề nói "chia sẻ tài nguyên đã mã hoá sang tài khoản khác" là phải có customer-managed key. Và với Auto Scaling, nhớ thêm grant cho service-linked role — đây là chi tiết bị quên nhiều nhất trong toàn bộ chủ đề này.

Đáp án

A và E.

• E — Gắn chứng chỉ SSL/TLS vào secure listener trên ALB.
• A — Tạo AWS WAF web ACL và gắn vào ALB.

Vì sao đúng

Ba yêu cầu, và ràng buộc cuối là thứ quyết định:

TLS termination trên ALB dời toàn bộ chi phí bắt tay và mã hoá sang load balancer — đúng vế "không ảnh hưởng hiệu năng instance". Chứng chỉ lấy từ ACM thì miễn phí và tự gia hạn, bỏ hẳn nguy cơ sập vì quên gia hạn.

AWS WAF gắn được vào ALB, CloudFront, API Gateway, AppSync và Cognito user pool. Dùng AWS Managed Rules là phủ ngay OWASP Top 10 (SQL injection, XSS, path traversal…) mà không phải viết luật.

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

• B. EBS encryption "để mã hoá mọi traffic" — nhầm lẫn hai khái niệm khác hẳn nhau. EBS encryption bảo vệ dữ liệu nằm yên trên đĩa (at rest), không liên quan gì tới dữ liệu đang truyền (in transit). Câu này sai ngay ở mệnh đề mô tả.
• C. Cài chứng chỉ trên từng EC2 instance — làm được, nhưng vi phạm thẳng ràng buộc "không ảnh hưởng hiệu năng": mọi phép mã hoá đổ lên CPU của instance. Kèm theo đó là gánh nặng phân phối và gia hạn chứng chỉ trên từng máy trong một fleet co giãn.
• D. Server-Side Encryption với KMS — lại là at rest, cho object trong S3. Không phải in transit, cũng không chống được lỗ hổng web.

Ghi nhớ

Phân biệt cho dứt khoát: | | Bảo vệ gì | Công cụ | |---|---|---| | In transit | dữ liệu đang truyền | TLS listener, ACM | | At rest | dữ liệu nằm yên | EBS encryption, SSE-KMS | | Tầng ứng dụng | tấn công web | AWS WAF |

Đáp án

C, D và E.

• E — EventBridge rule kích hoạt bởi lời gọi CreateUser trong CloudTrail.
• C — Lambda vô hiệu hoá access key và xoá login profile của IAM user mới; đặt làm target của rule.
• D — SNS topic làm target thứ hai của rule; đội bảo mật đăng ký nhận.

Vì sao đúng

Ba mảnh khớp đúng ba yêu cầu:

Sự kiện nào (E). Cần bắt lúc user được tạo, nên sự kiện đúng là CreateUser. Rule dạng:

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

Vô hiệu hoá cái gì (C). IAM user có hai loại thông tin xác thực, và phải xử lý cả hai: | Loại | Dùng để | Gỡ bằng | |---|---|---| | Access key | gọi API/CLI | UpdateAccessKey (Inactive) hoặc DeleteAccessKey | | Login profile | đăng nhập Console | DeleteLoginProfile |

Thông báo (D). Một EventBridge rule nhận nhiều target, nên Lambda và SNS chạy song song — không cần Lambda tự gọi SNS.

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

• A. Bắt GetLoginProfile — đây là lời gọi đọc, xảy ra khi ai đó xem thông tin login profile. Nó không phát ra khi user được tạo. Sai sự kiện hoàn toàn.
• B. AWS Config rule thông báo khi tài khoản bị sửa đổi — Config đánh giá theo chu kỳ hoặc theo thay đổi cấu hình, nên có độ trễ. Đề đòi vô hiệu hoá ngay lập tức. Ngoài ra "modified" không phải "created".
• F. Lambda chỉ xoá login profile — đây là bẫy chính, và nó khác C đúng một nửa. Bỏ sót access key nghĩa là user vẫn dùng được CLI, SDK và mọi lời gọi API — tức là để nguyên con đường nguy hiểm nhất mà chỉ khoá con đường dễ nhìn thấy nhất.

Ghi nhớ

Khi "vô hiệu hoá" một IAM user, luôn nghĩ đủ ba đường vào: access key (CLI/SDK), login profile (Console), và MFA device (nên gỡ luôn). Chặn một đường mà bỏ hai đường kia là biện pháp chỉ tồn tại trên giấy tờ kiểm toán.

Đáp án

B — CloudWatch Logs subscription filter đẩy log sang Lambda; Lambda gắn tag cho instance sinh ra sự kiện đăng nhập; một CloudWatch Events rule theo lịch huỷ instance đã gắn tag sau 24 giờ.

Vì sao đúng

Cùng kiến trúc với câu #4431 trước đó, chỉ khác thời hạn (24 giờ thay vì 1 giờ) — và cùng lý do:

1. Subscription filter, không phải metric filter. Cần biết instance nào, tức cần nội dung log. Metric filter chỉ cho con số đếm, không cho biết máy nào.

2. Tag là cầu nối giữa hai thời điểm. Sự kiện đăng nhập xảy ra bây giờ, việc huỷ xảy ra 24 giờ sau. Không có gì nối hai thời điểm đó ngoài một dấu vết bền vững trên chính tài nguyên — đó là tag:

ec2.create_tags(Resources=[instance_id], Tags=[
    {'Key': 'decommission-after', 'Value': (datetime.utcnow()+timedelta(hours=24)).isoformat()}
])

Rồi một rule theo lịch quét các instance có tag đã tới hạn và gọi TerminateInstances.

3. Vì sao huỷ được. Instance nằm trong Auto Scaling group nên ASG tự bù bằng instance sạch từ AMI chuẩn — chính là giá trị của cách xử lý này: không cần "dọn dẹp" máy bị xâm nhập, chỉ cần thay nó.

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

• A. Alarm → Kinesis Data Firehose → SNS → "hướng dẫn người vận hành" — kết thúc bằng thao tác tay, trong khi đề đòi tự động hoá. Firehose ở giữa cũng không đóng vai trò gì.
• C. Subscription filter → Step Functions — gần đúng, nhưng câu chữ của chính phương án tự mâu thuẫn: nó nói "configure the function to tag" trong khi target là state machine. Với một bước gắn tag thì Step Functions cũng là tầng thừa.
• D. Alarm trên sự kiện API call trong CloudTrail — sai nguồn dữ liệu. Đăng nhập SSH/RDP vào hệ điều hành không xuất hiện trong CloudTrail; đó là lý do đề nói rõ CloudWatch Logs agent đã được cấu hình sẵn trên mọi instance.

Ghi nhớ

Mẫu "phát hiện ngay, hành động sau" trên AWS gần như luôn dùng tag làm trạng thái trung gian: sự kiện → Lambda gắn tag → cơ chế theo lịch đọc tag và thực thi. Nó tách được hai khâu, chịu được lỗi tạm thời, và để lại dấu vết cho người vận hành xem trước khi hành động xảy ra.

Đáp án

B và C.

• C — Trong task definition mới, dùng sha256 digest thay vì tag, để ECS luôn kéo đúng image.
• B — Gom mọi phụ thuộc vào một image và kéo từ một registry duy nhất.

Vì sao đúng

Triệu chứng — một số task chạy image cũ, huỷ task hoặc xoá Docker cache thì hết — là dấu hiệu kinh điển của tag không bất biến.

Tag như latest hay v1.2 chỉ là con trỏ, và có thể trỏ sang image khác bất cứ lúc nào. Container instance đã có sẵn image mang tag đó trong cache cục bộ sẽ không kéo lại, tuỳ chính sách pull. Kết quả: cùng một task definition, mỗi instance chạy một nội dung khác nhau.

Digest thì bất biến — nó là hash của nội dung image:

"image": "123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/app@sha256:9f86d081884c7d65..."

Nội dung đổi thì digest đổi, nên cache cục bộ không bao giờ khớp nhầm. Đây là cách chắc chắn nhất, không phụ thuộc vào chính sách pull.

Về B: kéo phụ thuộc rải rác từ nhiều registry tạo ra nhiều mảnh có thể lệch phiên bản độc lập với nhau. Gom vào một image, kéo từ một nơi thì cả đơn vị triển khai chỉ có một digest để nói chuyện — cũng chính là điều làm C phát huy tác dụng.

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

• A. Tải phụ thuộc lúc ứng dụng khởi động — đi ngược nguyên tắc container bất biến. Mỗi lần task khởi động lại tải từ Internet: chậm hơn, phụ thuộc mạng, và hai task khởi động cách nhau một phút có thể nhận hai phiên bản khác nhau. Đúng loại vấn đề đang cần chữa.
• D. Dùng tag latest — sai nặng nhất. latest là tag dễ đổi nhất trong tất cả; nó chính là nguyên nhân phổ biến nhất của đúng triệu chứng trong đề, không phải cách chữa.
• E. Lambda SSH vào ECS instance xoá Docker cache — đề đã nói rõ xoá cache là cách chữa cháy, và họ cần giải pháp bền vững. Ngoài ra SSH vào container instance từ pipeline là một lỗ hổng vận hành (phải quản khoá, phải mở đường mạng), và không dùng được với Fargate vì không có instance nào để SSH vào.

Ghi nhớ

Trong production, luôn tham chiếu image bằng digest ở task definition, và để pipeline điền digest tự động sau khi build:

DIGEST=$(aws ecr describe-images --repository-name app \
  --image-ids imageTag=$BUILD_ID --query 'imageDetails[0].imageDigest' --output text)

Tag để cho người đọc; digest để cho máy triển khai.

Đáp án

D — Triển khai AWS Transit Gateway để có mạng full-mesh với transitive routing, và dùng AWS Firewall Manager để quản lý chính sách bảo mật tập trung.

Vì sao đúng

Hai từ khoá quyết định: transitive routing và kiểm soát tập trung.

Transit Gateway là dịch vụ duy nhất trong bốn phương án cho định tuyến bắc cầu: VPC A nói chuyện được với VPC C thông qua transit gateway, không cần kết nối trực tiếp. Mô hình hình sao (hub-and-spoke) này cũng loại bỏ bài toán bùng nổ số kết nối:

Công thức peering là n(n−1)/2 — tới vài chục VPC là không quản nổi bằng tay nữa.

Firewall Manager lo vế "kiểm soát truy cập mạng tập trung": áp và tự sửa security group, AWS Network Firewall, Route 53 Resolver DNS Firewall trên toàn tổ chức.

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

• A. PrivateLink — PrivateLink phơi bày một dịch vụ cụ thể qua endpoint, một chiều và không phải kết nối mạng đầy đủ. Nó không cho full-mesh và không có transitive routing. Security Hub thì tổng hợp phát hiện bảo mật, không triển khai chính sách mạng.
• B. Site-to-Site VPN giữa từng cặp VPC — VPN sinh ra để nối AWS với mạng ngoài, không phải nối VPC với VPC. Vẫn là mô hình full-mesh với n(n−1)/2 đường hầm, mỗi đường bị giới hạn băng thông ~1,25 Gbps.
• C. VPC peering — điểm chết nằm ở chỗ peering KHÔNG có transitive routing. A↔B và B↔C không làm A nói chuyện được với C; phải nối riêng A↔C. Đề đòi transitive routing nên peering bị loại thẳng. Ngoài ra WAF bảo vệ tầng ứng dụng HTTP, không phải kiểm soát truy cập mạng giữa các VPC.

Ghi nhớ

VPC peering không bắc cầu — đây là giới hạn bị hỏi nhiều nhất về peering. Thấy chữ "transitive" trong đề là chọn Transit Gateway. Và nhớ ba dịch vụ hay lẫn: Firewall Manager (áp và sửa chính sách), Security Hub (gom phát hiện), WAF (lọc HTTP).

Đáp án

B — AWS CodeDeploy với deployment group cấu hình blue/green, dùng BlueInstanceTerminationOption để huỷ fleet xanh lam sau 1 giờ.

Vì sao đúng

Bốn yêu cầu của đề khớp từng dòng với blue/green của CodeDeploy trên EC2/ASG:

Khoảng chờ đó chính là cửa sổ rollback: có sự cố thì trỏ ALB về fleet cũ trong vài giây, không phải deploy lại từ đầu.

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

• A. Hai môi trường Elastic Beanstalk — mô hình đúng nhưng sai nền tảng: ứng dụng đang chạy trên EC2 + ASG + ALB tự quản, không chạy trên Beanstalk. Ngoài ra "application version lifecycle policy" là thứ dọn bản dựng ứng dụng cũ trong Beanstalk, không huỷ môi trường — mô tả trong phương án sai chức năng.
• C. "Retention policy cho ALB đặt là 1 giờ" — không tồn tại thuộc tính nào như vậy trong CloudFormation. Và chuyển traffic bằng Route 53 thì phải chờ TTL, không dứt điểm.
• D. Beanstalk Immutable + .ebextension đặt deletion policy của ALB là 1 giờ — DeletionPolicy chỉ nhận Delete/Retain/Snapshot, không nhận thời lượng. Câu này ghép hai khái niệm không liên quan lại với nhau.

Ghi nhớ

Ba lựa chọn cho fleet xanh lam sau khi chuyển traffic: giữ nguyên (KEEP_ALIVE), huỷ ngay, hoặc huỷ sau N phút (TERMINATE kèm terminationWaitTimeInMinutes). Cái thứ ba là cách rẻ nhất để có rollback tức thời trong một cửa sổ xác định.

Đáp án

A — CodePipeline theo dõi nhánh master của CodeCommit, deploy sang staging bằng CodeDeploy, sau đó gọi một build CodeBuild chạy bộ kiểm thử.

Vì sao đúng

Chi tiết quyết định nằm ở "chạy khoảng hai giờ". Con số đó loại thẳng Lambda và định hình toàn bộ đáp án:

Bộ regression hai tiếng chỉ có CodeBuild chứa nổi. Ngoài ra CodeBuild là action hạng nhất trong CodePipeline: pipeline tự chờ nó xong, tự nhận trạng thái thành công/thất bại, và tự dừng các stage sau nếu test hỏng — không cần viết logic điều phối nào.

Thứ tự cũng đúng: deploy staging trước, rồi mới chạy test đối chiếu với môi trường staging đó.

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

• B. Custom stage dùng Lambda — vướng trần 15 phút. Hàm sẽ bị cắt giữa chừng, và pipeline nhận kết quả thất bại cho một bộ test hoàn toàn khoẻ mạnh.
• C. Chạy CodeBuild ở stage đầu tiên, test đối chiếu staging — sai thứ tự một cách nguy hiểm: test chạy trước khi mã mới được deploy, tức là nó kiểm thử bản cũ đang nằm trên staging. Test xanh không nói gì về mã sắp phát hành.
• D. Step Functions — về kỹ thuật có thể chờ lâu (standard workflow chờ tới 1 năm), nhưng nó vẫn phải gọi cái gì đó để thực sự chạy test, và cái đó lại là CodeBuild hoặc ECS. Thêm một tầng điều phối cho một bước tuần tự duy nhất là phức tạp thừa.

Ghi nhớ

Đề thi rất hay dùng thời lượng làm tiêu chí ngầm để loại phương án. Cứ thấy con số vượt 15 phút là loại Lambda ngay; vượt 8 giờ thì loại luôn CodeBuild và phải nghĩ tới ECS/Batch/EC2.

Đáp án

D — Amazon FSx for Lustre, kèm IAM role cho các participant account assume vào.

Vì sao đúng

Ba yêu cầu, và yêu cầu thứ ba loại hết ba phương án còn lại:

1. HPC — Lustre là hệ thống tệp song song sinh ra cho tính toán hiệu năng cao, thông lượng tới hàng trăm GB/s, độ trễ dưới mili giây.
2. VPC dùng chung, nhiều tài khoản tham gia — chia sẻ VPC bằng AWS RAM, participant account assume một IAM role để dùng tài nguyên.
3. "Truy cập theo tệp tới object nằm trong S3" — đây là câu quyết định. Chỉ FSx for Lustre có tích hợp gốc với S3: liên kết một bucket, object hiện ra thành tệp, đọc là Lustre tự nạp dữ liệu (lazy load), ghi xong thì xuất ngược lại S3.

aws fsx create-file-system --file-system-type LUSTRE \
  --storage-capacity 1200 --subnet-ids subnet-xxx \
  --lustre-configuration ImportPath=s3://du-lieu-phan-tich/,ExportPath=s3://du-lieu-phan-tich/ket-qua/

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

• A. FSx for NetApp ONTAP — hệ thống tệp doanh nghiệp mạnh, nhưng không có tích hợp S3 kiểu này. Câu này còn sai nặng hơn ở đoạn "dùng access key để xác thực" — trong AWS, truy cập chéo tài khoản luôn nên dùng role, và access key tĩnh là thứ đề thi gần như luôn coi là đáp án sai.
• B. FSx for Windows File Server — dành cho workload Windows/SMB, gắn với Active Directory. Không phải HPC, không liên kết S3.
• C. FSx for OpenZFS — hiệu năng tốt cho NFS, nhưng không liên kết S3, và không phải hệ thống tệp song song cho HPC.

Ghi nhớ

Bốn hệ FSx, mỗi cái một chỗ: | Loại | Dành cho | |---|---| | Lustre | HPC, machine learning, tích hợp S3 | | Windows File Server | SMB, Active Directory | | NetApp ONTAP | đa giao thức, tính năng doanh nghiệp | | OpenZFS | NFS, di trú từ ZFS |

Đáp án

C — Gắn SCP của Organizations với Deny tường minh cho iam:CreateUser, kèm điều kiện StringNotLike trên aws:username với danh sách ngoại lệ.

Vì sao đúng

Bài toán: cấm tạo IAM user, trừ một danh sách ngoại lệ. Ba mảnh phải đúng:

1. Đúng action. Việc cần cấm là iam:CreateUser, không phải cái gì khác.

2. Đúng toán tử điều kiện. Đây là chỗ tinh tế nhất. Muốn nói "chặn tất cả trừ những người này", phải dùng toán tử phủ định:

{
  "Effect": "Deny",
  "Action": "iam:CreateUser",
  "Resource": "*",
  "Condition": {
    "StringNotLike": {
      "aws:username": ["admin-ngoaile", "quan-tri-*"]
    }
  }
}

Đọc là: cấm CreateUser khi tên người gọi không nằm trong danh sách. Người trong danh sách không khớp điều kiện nên Deny không áp lên họ.

3. Đúng công cụ. SCP là guardrail có tính ngăn chặn ở tầng Organizations: lời gọi bị chặn trước khi xảy ra, không tài khoản thành viên nào lách được, kể cả tài khoản root của account đó.

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

• A. Cấm iam:CreateLoginProfile + StringEquals — sai hai chỗ. CreateLoginProfile chỉ tạo mật khẩu đăng nhập Console; user vẫn được tạo và vẫn có thể có access key. Và StringEquals với danh sách ngoại lệ sẽ chỉ chặn đúng những người trong danh sách — đảo ngược hoàn toàn ý định.
• B. EventBridge bắt iam:GetUser — GetUser là lời gọi đọc, không phát sinh khi tạo user. Sai sự kiện.
• D. EventBridge bắt CreateUser rồi Lambda xoá — sai về loại kiểm soát. Đây là detective + corrective: user đã được tạo và tồn tại trong khoảng thời gian giữa lúc tạo và lúc Lambda kịp xoá — đủ để sinh access key và dùng. Đề nói "it should not be possible to create IAM users", tức là cần preventive.

Ghi nhớ

Và nhớ ranh giới: SCP ngăn chặn trước; EventBridge + Lambda chỉ sửa sau. Đề dùng chữ "không được phép xảy ra" thì luôn chọn SCP.