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

Đáp án

D và E.

• E — Gắn IAM instance profile cho EC2 với quyền cần thiết cho Systems Manager.
• D — Tạo VPC endpoint cho Systems Manager ở Region đang chạy instance.

Vì sao đúng

Hai yêu cầu: dùng Session Manager thay SSH, và kết nối đi qua mạng riêng.

Vế quyền (E). SSM Agent phải tự đăng ký với dịch vụ Systems Manager, và nó dùng instance profile để làm việc đó. Policy dựng sẵn là AmazonSSMManagedInstanceCore. Không có nó thì instance không bao giờ hiện ra trong danh sách managed instances.

Vế mạng riêng (D). Mặc định SSM Agent gọi ra endpoint công cộng, tức là cần Internet (qua IGW hoặc NAT). Muốn đi hoàn toàn trong mạng riêng thì phải có VPC interface endpoint — và cần 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 bấm mở phiên thì treo rồi timeout mà không có thông báo nào hữu ích.

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

• A. Mở cổng 22 vào 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 cổng inbound nào cả; agent tự mở kết nối đi ra. Giá trị lớn nhất của Session Manager chính là security group không cần rule inbound nào.
• B. NAT gateway + Elastic IP — cách này có làm Session Manager chạy được, nhưng traffic đi ra Internet công cộng rồi vòng lại AWS. Đề yêu cầu rõ "private network connection", nên VPC endpoint mới đúng. NAT cũng tốn phí giờ chạy và phí xử lý dữ liệu.
• C. "Thiết lập kết nối riêng bằng instance ID" — vô nghĩa về mặt kỹ thuật. Instance ID là thứ bạn chỉ định khi mở phiên, không phải cấu hình mạng.

Ghi nhớ

Công thức Session Manager trong subnet riêng: AmazonSSMManagedInstanceCore + ba VPC endpoint (ssm, ssmmessages, ec2messages) + security group của endpoint cho phép HTTPS 443 từ dải VPC. Cộng 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

C — Cấu hình SNS notification cho chính Auto Scaling group, chọn sự kiện EC2_INSTANCE_LAUNCH_ERROR.

Vì sao đúng

Auto Scaling group có cơ chế thông báo dựng sẵn, khai một lần là xong, không cần alarm, không cần Lambda:

aws autoscaling put-notification-configuration \
  --auto-scaling-group-name nhom-web \
  --topic-arn arn:aws:sns:ap-southeast-1:123456789012:canh-bao-asg \
  --notification-types autoscaling:EC2_INSTANCE_LAUNCH_ERROR

Bốn loại thông báo có sẵn:

Thông báo kèm lý do thất bại — hết dung lượng instance type ở AZ đó, chạm service quota, AMI không tồn tại, subnet hết địa chỉ IP — tức là đúng thứ đội hỗ trợ cần để xử lý.

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

• A. Alarm khi "gọi SetInstanceHealth thất bại" — không liên quan. SetInstanceHealth là API bạn gọi để đánh dấu instance không lành; lời gọi đó thất bại chẳng nói gì về việc launch. Và CloudWatch alarm không đặt trực tiếp lên "một lời gọi API thất bại" như vậy được.
• B. Alarm khi EC2 status check hỏng — status check chỉ chạy trên instance đã tồn tại và đang chạy. Instance không launch được thì không bao giờ có status check nào để mà hỏng. Sai hẳn giai đoạn trong vòng đời.
• D. "Thêm health check vào ASG để gọi Lambda khi instance bị impaired" — ASG không hỗ trợ gọi Lambda từ health check. Health check chỉ có hai loại (EC2 và ELB), và kết quả của nó chỉ dẫn tới việc thay thế instance. Ngoài ra "impaired" lại là trạng thái của instance đang chạy, không phải launch hỏng.

Ghi nhớ

Trước khi nghĩ tới CloudWatch alarm hay Lambda, hãy kiểm xem dịch vụ đã có sẵn cơ chế thông báo chưa. Ngoài ASG notification, còn có EventBridge sự kiện EC2 Instance Launch Unsuccessful — cho cùng thông tin nhưng định tuyến linh hoạt hơn.

Đáp án

A — Amazon Managed Service for Prometheus để thu thập metric, Amazon Managed Grafana để trực quan hoá và phân tích.

Vì sao đúng

Ba đặc điểm của đề chỉ thẳng vào cặp này:

Từ khoá quan trọng nhất là on-premises. Cụm nằm ngoài AWS vẫn đẩy metric lên Managed Service for Prometheus được qua remote write, nên một hệ giám sát duy nhất phủ cả ba môi trường — đúng yêu cầu "thu thập và tổng hợp từ tất cả".

Cả hai đều là bản được AWS quản lý của phần mềm mã nguồn mở: không phải tự vận hành máy chủ Prometheus, không lo mở rộng lưu trữ, nhưng vẫn dùng đúng PromQL và đúng dashboard đã quen.

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

• B. AWS AppConfig — dịch vụ quản lý cấu hình ứng dụng (feature flag, tham số triển khai theo giai đoạn). Nó không thu thập metric. Sai hoàn toàn vai trò.
• C. SSM Agent thu metric, Prometheus trực quan hoá — đảo ngược vai trò: Prometheus là nơi lưu trữ và truy vấn, không phải công cụ trực quan hoá (giao diện tự thân của nó rất tối giản). SSM Agent cũng không phải cơ chế thu metric container.
• D. CloudWatch Agent + Athena + Glue để trực quan hoá — sai ở vế cuối: Glue là dịch vụ ETL, không vẽ được gì cả. Ngoài ra, đường CloudWatch Container Insights có dùng được cho EKS/ECS nhưng phủ on-premises kém, và mô hình truy vấn theo SQL không hợp với dữ liệu chuỗi thời gian bằng PromQL.

Ghi nhớ

Đáp án

B — CloudWatch Logs agent thu log ở cả tài khoản AWS lẫn máy chủ on-premises, rồi lưu toàn bộ vào một S3 bucket ở tài khoản trung tâm.

Vì sao đúng

Đề đòi hiệu quả nhất và tiết kiệm nhất, cho log nằm rải rác ở nhiều tài khoản AWS và một trung tâm dữ liệu riêng.

Vế thu thập. CloudWatch Logs agent chạy được trên máy chủ on-premises — chỉ cần một IAM user hoặc role với quyền logs:PutLogEvents (thực tế nên dùng SSM hybrid activation để có thông tin xác thực tạm thời thay vì khoá tĩnh). Nhờ vậy một cơ chế duy nhất phủ cả hai bên.

Vế lưu trữ — và đây là điểm quyết định. Gom về một bucket ở tài khoản trung tâm:

• S3 rẻ hơn hẳn CloudWatch Logs khi lưu dài hạn, và có lifecycle chuyển sang Glacier
• Một chỗ duy nhất để phân quyền và kiểm toán
• Athena truy vấn thẳng, không cần dựng gì

So sánh nhanh chi phí lưu trữ: CloudWatch Logs tính khoảng 0,03 USD/GB/tháng, S3 Standard khoảng 0,023 USD/GB/tháng, và Glacier rẻ hơn nhiều lần nữa. Với log nhiều terabyte, khoảng cách này là đáng kể.

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

• A. "Dùng S3 API để export log file" — CreateExportTask là thao tác thủ công, một lần, không phải cơ chế liên tục. Muốn tự động thì phải tự viết và tự lên lịch, và mỗi tài khoản chỉ chạy được một export task tại một thời điểm.
• C. Dùng S3 API để "export log on-premises" — nghĩa là tự viết công cụ tải log cho máy chủ on-premises, trong khi CloudWatch agent đã chạy được ở đó. Thêm mã, thêm chỗ hỏng, không được gì.
• D. Lưu log trong các bucket riêng ở từng tài khoản — đi ngược thẳng yêu cầu "centralize and aggregate". Muốn truy vấn xuyên tài khoản thì phải cấu hình quyền chéo cho từng bucket, hoặc chạy truy vấn nhiều lần rồi tự ghép — đúng vấn đề mà đề đang muốn bỏ.

Ghi nhớ

Mẫu chuẩn cho log tập trung đa tài khoản: agent → CloudWatch Logs (từng tài khoản) → subscription filter → Kinesis Data Firehose xuyên tài khoản → một S3 bucket trung tâm → Athena. Giữ log nóng trong CloudWatch Logs vài tuần cho việc gỡ lỗi, đẩy log nguội xuống S3/Glacier cho lưu trữ dài hạn.

Đáp án

C, D và E.

• C — Dựng CodePipeline, đưa mã vào repository làm nguồn của pipeline.
• E — CodeBuild dựng artifact và đẩy lên S3; CodeDeploy triển khai xuống EC2.
• D — Script xoá cache khai trong hook BeforeInstall của tệp AppSpec.

Vì sao đúng

Đề mô tả một quy trình thủ công gồm bốn bước và đòi tự động hoá kèm theo dõi tiến trình và rollback khi hỏng. Ba phương án được chọn khớp từng bước:

Vì sao BeforeInstall. Cache phải được dọn trước khi phiên bản mới được ghi xuống. Vòng đời CodeDeploy trên EC2:

ApplicationStop → DownloadBundle → BeforeInstall → Install → AfterInstall
→ ApplicationStart → ValidateService

BeforeInstall là mốc đúng: bundle đã tải xong, tệp mới chưa được đặt vào chỗ.

Vì sao CodePipeline là mảnh không thể thiếu. Nó cho cái nhìn tiến trình theo từng stage và là nơi gắn quy tắc dừng/rollback — đúng hai thứ đề nêu tên.

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

• A. User data xoá cache, hỏng thì "deploy lại" — user data chỉ chạy lúc instance khởi động lần đầu, không chạy mỗi lần deploy. Và "hỏng thì deploy lại" chính là không có rollback.
• B. Lambda tự build artifact khi có pull vào master — Lambda vướng trần 15 phút cho việc build, không có môi trường build sẵn, không có cache phụ thuộc, và không cho khả năng theo dõi tiến trình như pipeline.
• F. Dùng Systems Manager tải artifact và deploy — Run Command chạy lệnh được, nhưng không có khái niệm lifecycle hook, không có rollback tự động, không có theo dõi tiến trình deploy. Nó là công cụ vận hành, không phải công cụ triển khai.

Ghi nhớ

Bộ ba của AWS cho CI/CD trên EC2: CodePipeline điều phối, CodeBuild dựng, CodeDeploy triển khai. Và học thuộc vòng đời hook của CodeDeploy — đề rất hay hỏi "đặt script ở hook nào", mà câu trả lời luôn suy ra được từ vị trí của hook trong chuỗi.

Đáp án

A — Tạo AWS Config rule ở cấp tổ chức kiểm tra EBS đã mã hoá chưa, và áp SCP cấm dừng hoặc xoá AWS Config trong toàn tổ chức.

Vì sao đúng

Đọc kỹ hai yêu cầu: volume chưa mã hoá phải bị đánh dấu non-compliant, và giải pháp phải tự động triển khai cho nhiều tài khoản.

Chữ "marked as non-compliant" là chìa khoá: đề đòi kiểm soát phát hiện (detective), không phải kiểm soát ngăn chặn (preventive). Đó chính xác là vai trò của AWS Config.

Config organization rule triển khai một lần từ tài khoản quản lý (hoặc delegated administrator) và phủ mọi tài khoản thành viên, kể cả tài khoản tạo sau này:

aws configservice put-organization-config-rule \
  --organization-config-rule-name encrypted-volumes-toan-to-chuc \
  --organization-managed-rule-metadata RuleIdentifier=ENCRYPTED_VOLUMES

Vế SCP là mảnh thường bị bỏ quên và rất quan trọng. Một kiểm soát phát hiện chỉ có giá trị khi không ai tắt được nó. SCP cấm config:StopConfigurationRecorder, config:DeleteConfigurationRecorder, config:DeleteConfigRule khoá luôn khả năng "vô hiệu hoá bộ giám sát rồi vi phạm thoải mái" — kể cả với root của tài khoản thành viên.

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

• B. Lambda theo lịch ở mỗi tài khoản + báo cáo S3 + Athena — tự viết lại AWS Config: phải deploy hàm vào từng tài khoản, tự phân trang, tự bảo trì, tự dựng báo cáo. Trái hẳn tiêu chí "MOST efficiently".
• C. SCP chặn tạo EC2 với EBS chưa mã hoá — đây là preventive, và nghe rất hấp dẫn. Nhưng nó không làm được điều đề yêu cầu: những volume chưa mã hoá ĐANG TỒN TẠI vẫn nằm đó và không bị đánh dấu gì cả. SCP chỉ chặn hành động tương lai. Nó bổ sung tốt cho A, nhưng không thay được A.
• D. Rule ec2-ebs-encryption-by-default deploy ở management account — sai hai chỗ. Thứ nhất, rule đó kiểm cài đặt "mã hoá mặc định" của tài khoản, không kiểm từng volume đã mã hoá hay chưa — volume tạo trước khi bật cài đặt vẫn không mã hoá và vẫn lọt. Thứ hai, deploy ở một tài khoản duy nhất thì không phủ các tài khoản thành viên.

Ghi nhớ

Đề dùng chữ "marked as non-compliant" thì luôn là Config. Và đừng quên: kiểm soát phát hiện phải được bảo vệ khỏi việc bị tắt.

Đáp án

A, B và C.

• A — Cung cấp toàn bộ tài nguyên bằng CloudFormation.
• C — Cấu hình CodePipeline với một build stage dùng CodeBuild.
• B — Dựng EC2 trong môi trường Elastic Beanstalk và đặt môi trường đó làm đích triển khai của CodePipeline.

Vì sao đúng

Ba yêu cầu, mỗi phương án đáp một cái:

"Tái tạo toàn bộ pipeline ở tài khoản/Region khác trong vài phút" ⇒ A. Chỉ hạ tầng dưới dạng mã làm được. Toàn bộ pipeline, build project, deployment group, vai trò IAM đều khai trong template; deploy sang nơi khác chỉ là chạy lại một stack.

"Continuous integration" ⇒ C. CodePipeline điều phối, CodeBuild dựng và chạy test. Đây là phần CI.

"Continuous delivery + tự động rollback khi deploy hỏng" ⇒ B. Đây là mảnh cần lý giải kỹ nhất. Elastic Beanstalk là đích triển khai hợp lệ của CodePipeline và có rollback tự động dựng sẵn: deploy hỏng health check thì môi trường tự quay về phiên bản trước, không cần cấu hình thêm.

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

• E. EC2 trong ASG sau ALB, đặt ALB làm đích triển khai của CodePipeline — đây là bẫy chính, và nó sai ở một chi tiết cụ thể: ALB không phải deployment target. CodePipeline triển khai qua CodeDeploy (nhắm vào deployment group), qua Elastic Beanstalk, ECS, CloudFormation, S3 — nhưng không bao giờ nhắm thẳng vào một load balancer. Mô tả trong phương án không tồn tại về mặt kỹ thuật.
• D. SQS để "tách rời các thành phần pipeline" — CodePipeline tự quản chuyển tiếp giữa các stage. Chèn hàng đợi vào giữa là thêm một tầng không có vai trò gì.
• F. Chép artifact từ CodeCommit sang S3 — nhầm khái niệm: CodeCommit chứa mã nguồn, không chứa artifact đã build. Artifact do CodeBuild sinh ra và CodePipeline tự đưa vào artifact store, không cần bước chép tay nào.

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

Đề không hề nói ứng dụng chạy trên Elastic Beanstalk, nên thoạt nhìn B có vẻ áp đặt một nền tảng. Nhưng nó vẫn là đáp án đúng nhất trong bộ này vì phương án thay thế duy nhất (E) mô tả một cơ chế không tồn tại. Nếu E viết là "đặt CodeDeploy deployment group làm đích" thì E mới là câu trả lời tự nhiên hơn — điểm loại thật sự nằm ở chữ "ALB as the deployment target", không nằm ở việc chọn nền tảng.

Đáp án

C — Thêm phase post_build vào buildspec và đặt lệnh đẩy image trong khối commands.

Vì sao đúng

Cấu trúc của buildspec chạy theo thứ tự cố định:

version: 0.2
phases:
  install:      # cài công cụ cần cho build
    commands: [...]
  pre_build:    # chuẩn bị — đăng nhập ECR ở đây
    commands:
      - aws ecr get-login-password --region ap-southeast-1 | docker login --username AWS --password-stdin $ECR_URI
  build:        # dựng image
    commands:
      - docker build -t $ECR_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION .
  post_build:   # chỉ chạy SAU KHI build kết thúc
    commands:
      - docker push $ECR_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION

post_build là phase đúng vì nó chạy sau phase build. Và khối commands của post_build chỉ chạy khi build thành công — đúng yêu cầu "chỉ đẩy khi build hoàn tất thành công".

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

• A. Phase install — chạy đầu tiên, trước cả khi image được dựng. Lúc đó chẳng có gì để đẩy.

• B. post_build với khối finally — đây là bẫy tinh vi nhất và cần hiểu chính xác:

  • commands — chỉ chạy khi các lệnh trước thành công
  • finally — luôn chạy, kể cả khi commands thất bại

  Đặt docker push vào finally nghĩa là đẩy image kể cả khi build hỏng — trái thẳng yêu cầu. finally dành cho dọn dẹp, ghi log, gửi thông báo.

• D. Dùng sequence artifacts — artifacts khai tệp nào được đóng gói và đưa vào S3 (artifact store của pipeline). Nó không đẩy được Docker image lên ECR; đẩy image là việc của lệnh docker push.

Ghi nhớ

Và nhớ đăng nhập ECR ở pre_build: token của get-login-password có hạn 12 giờ, lấy sớm rồi dùng ở post_build là hoàn toàn an toàn.

Đáp án

C — Thay Jenkins chạy trên EC2 bằng AWS CodeBuild và bật mã hoá artifact.

Vì sao đúng

Yêu cầu kép: mã hoá artifact và giảm gánh nặng vận hành lâu dài.

Chỉ chữa vế mã hoá thì vẫn còn nguyên gánh nặng Jenkins: vá hệ điều hành, vá chính Jenkins và hàng chục plugin, quản lý build agent, xử lý lúc máy hết đĩa, tự lo dung lượng khi tải tăng.

CodeBuild bỏ toàn bộ phần đó:

• Không máy chủ nào để quản — mỗi build chạy trong môi trường sạch, cô lập
• Trả tiền theo phút build, không trả tiền cho máy nhàn rỗi
• Mã hoá artifact bằng KMS ngay trong cấu hình project — mặc định đã dùng khoá quản lý được, chỉ định CMK riêng cũng được
• Tích hợp sẵn IAM role nên không cần khoá tĩnh

aws codebuild create-project --name dung-ung-dung \
  --artifacts type=S3,location=kho-artifact,encryptionDisabled=false \
  --encryption-key arn:aws:kms:ap-southeast-1:123456789012:key/xxxx

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

• A. S3 default encryption + đưa Jenkins vào Auto Scaling group — vế mã hoá thì đúng, nhưng ASG không giảm gánh nặng vận hành Jenkins; nó thêm việc: Jenkins controller có trạng thái (job config, lịch sử build, plugin), nên đưa vào ASG còn phải giải bài toán lưu trữ chia sẻ và bầu chọn node. Nhiều việc hơn, không ít hơn.
• B. "Mã hoá artifact bằng AWS Certificate Manager" — nhầm dịch vụ hoàn toàn. ACM cấp và quản lý chứng chỉ TLS; nó không mã hoá dữ liệu lưu trữ. Việc đó thuộc về KMS.
• D. Vá Jenkins bằng SSM + mã hoá EBS — mã hoá EBS bảo vệ đĩa của máy Jenkins, nhưng artifact được đẩy lên S3 hoặc nơi khác vẫn không được bảo vệ. Và vá bằng SSM chỉ làm nhẹ một phần rất nhỏ trong gánh nặng vận hành Jenkins.

Ghi nhớ

Câu hỏi có cụm "reducing operational overhead" thường là dấu hiệu chuyển từ tự vận hành sang dịch vụ được quản lý: Jenkins → CodeBuild, tự dựng Git → CodeCommit, tự viết script deploy → CodeDeploy. Và nhớ tách bạch: KMS mã hoá dữ liệu, ACM cấp chứng chỉ TLS — hai việc không liên quan.

Đáp án

B — Kiểm tra xem đã có CloudWatch Events (EventBridge) rule cho nhánh main để kích hoạt pipeline hay chưa.

Vì sao đúng

Điều nhiều người tưởng nhầm: CodePipeline không tự theo dõi CodeCommit. Có hai cơ chế phát hiện thay đổi, và mặc định hiện nay là cơ chế thứ nhất:

Khi tạo pipeline qua Console hoặc CloudFormation, rule này được sinh tự động — nhưng nó là một tài nguyên riêng biệt. Ai đó xoá nhầm, hoặc rule bị tạo cho sai tên nhánh (master trong khi đội đã đổi sang main), thì triệu chứng đúng như đề: push thành công, pipeline im lặng, không lỗi ở đâu cả.

Kiểm tra:

aws events list-rules --name-prefix codepipeline-
aws events list-targets-by-rule --rule <ten-rule>

Chú ý mẫu sự kiện phải khớp đúng tên nhánh:

{"source": ["aws.codecommit"],
 "detail-type": ["CodeCommit Repository State Change"],
 "detail": {"referenceName": ["main"], "referenceType": ["branch"]}}

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

• A. Lambda kiểm tra commit — không phải cơ chế của CodePipeline. Không có Lambda nào tham gia vào luồng kích hoạt chuẩn.
• C. Quyền của CodePipeline service role với CodeCommit — thiếu quyền thì pipeline vẫn khởi động rồi thất bại ở source stage với lỗi rõ ràng. Triệu chứng đề mô tả là pipeline không chạy chút nào, khác hẳn.
• D. Quyền push của lập trình viên — đề nói rõ "the developer pushed code changes", tức là push đã thành công. Nếu thiếu quyền thì chính lệnh git push đã báo lỗi.

Ghi nhớ

Chẩn đoán "pipeline không chạy" theo thứ tự: (1) rule EventBridge còn tồn tại không, (2) mẫu sự kiện có khớp đúng tên nhánh không, (3) target của rule có trỏ đúng pipeline không, (4) role của rule có quyền codepipeline:StartPipelineExecution không. Ngược lại, "pipeline chạy rồi hỏng ở source stage" mới là câu chuyện về quyền của service role.