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

Đáp án

A — Dùng UpdatePolicy với AutoScalingRollingUpdate và thuộc tính MinInstancesInService.

Vì sao đúng

Yêu cầu là cập nhật không gián đoạn và luôn có ít nhất 4 instance chạy trong tổng số 8.

AutoScalingRollingUpdate thay instance theo từng lô, và MinInstancesInService là con số sàn mà CloudFormation không được phép tụt xuống dưới:

NhomAutoScaling:
  Type: AWS::AutoScaling::AutoScalingGroup
  UpdatePolicy:
    AutoScalingRollingUpdate:
      MinInstancesInService: 4      # luôn giữ ít nhất 4 instance phục vụ
      MaxBatchSize: 2               # thay tối đa 2 instance mỗi lô
      PauseTime: PT5M
      WaitOnResourceSignals: true

Với 8 instance và MinInstancesInService: 4, CloudFormation thay từng lô sao cho số instance đang phục vụ không bao giờ xuống dưới 4 — chính xác điều đề yêu cầu.

WaitOnResourceSignals: true thêm một lớp an toàn: CloudFormation chờ tín hiệu cfn-signal từ instance mới báo ứng dụng đã sẵn sàng, thay vì chỉ chờ EC2 chạy.

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

• B. AutoScalingScheduledAction — policy này chỉ để giữ nguyên min/max/desired khi stack cập nhật mà nhóm đang bị scheduled action điều khiển. Nó không thay instance và không có thuộc tính MaxBatchSize.
• C. AutoScalingReplacingUpdate — dựng một ASG hoàn toàn mới rồi mới xoá cái cũ. Nó không có MinInstancesInService (thuộc tính đó thuộc về rolling update), nên không diễn đạt được ràng buộc "luôn ≥ 4". Hướng đi đúng cho blue/green, sai cho yêu cầu này.
• D. UpdateReplacePolicy — đây là thứ khác hẳn: nó quyết định làm gì với tài nguyên CŨ khi tài nguyên bị thay thế (Delete/Retain/Snapshot). Không nhận MinSuccessfulInstancesPercent hay MaxBatchSize.

Ghi nhớ

Ba UpdatePolicy của Auto Scaling group, đừng lẫn: | Policy | Làm gì | |---|---| | AutoScalingRollingUpdate | thay instance tại chỗ theo lô — có MinInstancesInService, MaxBatchSize | | AutoScalingReplacingUpdate | dựng ASG mới rồi bỏ cái cũ | | AutoScalingScheduledAction | giữ nguyên min/max/desired khi cập nhật stack |

Đáp án

D — Dùng AWS App2Container (A2C) để phân tích và kiểm kê ứng dụng on-premises, container hoá lên ECS, rồi để A2C dựng pipeline CI/CD bằng CodeBuild và CodeDeploy.

Vì sao đúng

Đề nói rõ ứng dụng chưa được container hoá và cần vừa hiện đại hoá vừa có CI/CD. App2Container sinh ra đúng cho kịch bản này:

1. Inventory — quét máy chủ, liệt kê ứng dụng Java/.NET đang chạy:

   sudo app2container inventory
   sudo app2container analyze --application-id java-tomcat-9e8e4799
   

2. Containerize — tự sinh Dockerfile, tự phát hiện phụ thuộc, tự đóng gói
3. Deploy — sinh template CloudFormation cho ECS hoặc EKS
4. CI/CD — sinh sẵn pipeline dùng CodeCommit + CodeBuild + CodeDeploy

Điểm mạnh của A2C là bước phân tích ứng dụng đang chạy: nó bám vào tiến trình thật để suy ra cấu hình, thay vì bắt bạn tự đọc lại một ứng dụng legacy không ai còn nhớ.

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

• A. Amazon AppFlow — dịch vụ tích hợp luồng dữ liệu giữa SaaS (Salesforce, Slack…) và AWS. Không liên quan gì tới container hoá.
• B. AWS Proton — Proton quản lý template hạ tầng cho ứng dụng đã được container hoá/serverless; nó không phân tích và không container hoá ứng dụng on-premises. Nó là công cụ của bước sau, không phải bước di trú.
• C. AWS Copilot — Copilot dựng và vận hành ứng dụng trên ECS rất tốt, nhưng nó làm việc với ứng dụng đã có Dockerfile. Nó không "analyze and inventory" ứng dụng on-premises — đó chính xác là điều A2C làm và Copilot không.

Ghi nhớ

Đáp án

B — Dùng AWS Compute Optimizer để báo cáo mức sử dụng tài nguyên trên EC2 và làm theo khuyến nghị để chỉnh lại cấu hình.

Vì sao đúng

Tình huống rất cụ thể: không được huỷ instance nào (tất cả đang dùng), và lập trình viên không biết nhu cầu tài nguyên thật. Vậy việc duy nhất còn lại là right-sizing — giữ nguyên số máy, chỉnh đúng cỡ máy.

Compute Optimizer làm chính xác việc đó, bằng máy học trên metric lịch sử của CloudWatch:

• Phân loại over-provisioned / under-provisioned / optimized
• Đề xuất loại instance cụ thể kèm ước tính tiết kiệm
• Cho biết rủi ro hiệu năng của mỗi khuyến nghị

Nó bật miễn phí, không cần cài agent (dù bật memory metric qua CloudWatch Agent thì khuyến nghị chính xác hơn nhiều — CPU đơn thuần hay đánh lừa).

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

• A. Amazon Detective — công cụ điều tra bảo mật, dựng đồ thị hành vi từ VPC Flow Logs, CloudTrail và GuardDuty. Không đụng gì tới chi phí hay right-sizing. Ngoài ra "tự động tắt dịch vụ không cần thiết" trên máy đang phục vụ là hành động rất nguy hiểm.
• C. AWS Control Tower — dựng và quản trị môi trường multi-account (landing zone, guardrail). Nó không phân tích mức sử dụng workload. EC2 Image Builder cũng chỉ dựng AMI, không đổi được instance type.
• D. Dashboard CloudWatch + tự động đổi instance type bằng SSM — về nguyên tắc làm được, nhưng đây là tự viết lại Compute Optimizer mà không có phần máy học và không có ước tính rủi ro hiệu năng. Và tự động đổi instance type trên máy đang phục vụ là thay đổi cần khởi động lại — đề nói rõ mọi instance đang được dùng.

Ghi nhớ

Bộ công cụ chi phí trên AWS, mỗi cái một câu hỏi: | Dịch vụ | Trả lời | |---|---| | Compute Optimizer | máy này có đúng cỡ không? | | Cost Explorer | tiền đang đi đâu? | | Budgets | đã vượt ngưỡng chưa? | | Trusted Advisor | có tài nguyên nhàn rỗi/lãng phí rõ ràng không? |

Đáp án

D — Kinesis Agent đẩy log lên Kinesis Data Firehose, dùng AWS Lambda để chuẩn hoá trước khi Firehose ghi vào S3.

Vì sao đúng

Yêu cầu là chuẩn hoá nhiều định dạng log khác nhau TRƯỚC KHI ghi vào S3, với chi phí thấp nhất.

Firehose có tính năng data transformation dựng sẵn: nó gom bản ghi thành lô, gọi Lambda để biến đổi, rồi mới ghi kết quả xuống S3. Không phải tự dựng đường ống nào cả.

Ứng dụng → Kinesis Agent → Firehose ─(gọi Lambda biến đổi)─→ S3 (đã chuẩn hoá)

Vì sao rẻ nhất:

• Firehose hoàn toàn được quản lý, tính tiền theo lượng dữ liệu nạp, không có cụm nào phải nuôi
• Lambda tính theo lượt gọi và thời gian, và Firehose gọi theo lô chứ không gọi từng bản ghi
• Không cụm nào chạy 24/7 — đây là điểm phân biệt lớn nhất với A và C

Thêm một điểm hay: Firehose giữ bản gốc chưa biến đổi vào một prefix S3 riêng nếu bạn bật, nên biến đổi sai vẫn còn dữ liệu để làm lại.

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

• A. OpenSearch cluster — cụm OpenSearch chạy liên tục, tính tiền theo giờ node kể cả lúc rảnh. Dùng nó làm trạm trung chuyển để rồi lại xuất ra S3 là đắt gấp nhiều lần mà chẳng thêm giá trị.
• B. QuickSight + SPICE để chuẩn hoá log — hiểu sai vai trò. QuickSight là công cụ trực quan hoá, SPICE là bộ nhớ đệm tính toán trong đó. Chúng không phải tầng ETL để nhận log thô từ ứng dụng.
• C. Redshift Spectrum "chuẩn hoá tại chỗ" — Spectrum chỉ đọc dữ liệu trên S3; nó không sửa dữ liệu tại chỗ. Và nó đòi một cụm Redshift làm điểm vào — lại là chi phí thường trực. Ngoài ra, làm vậy nghĩa là log thô đã nằm trên S3 rồi, trái yêu cầu "chuẩn hoá trước khi ghi".

Ghi nhớ

Firehose + Lambda transformation là mẫu chuẩn cho "biến đổi dữ liệu trên đường vào S3". Nhớ thêm: Firehose còn tự chuyển sang Parquet/ORC và phân vùng động — hai thứ làm truy vấn Athena sau này rẻ hơn nhiều.

Đáp án

C — Lambda làm mới các check của AWS Trusted Advisor theo lịch (EventBridge), và một EventBridge rule thứ hai bắt sự kiện Trusted Advisor để gửi thông báo.

Vì sao đúng

Yêu cầu là cảnh báo khi tài nguyên sắp chạm service limit, với ít công sức phát triển nhất.

Trusted Advisor đã có sẵn nhóm check "Service Limits": nó theo dõi mức dùng so với hạn mức của hàng chục dịch vụ và chuyển sang trạng thái cảnh báo ở 80%. Không phải viết logic nào cả.

Vì sao vẫn cần Lambda: Trusted Advisor chỉ tự làm mới theo chu kỳ (service limit check làm mới không quá một lần mỗi ngày). Muốn kiểm tra dày hơn thì gọi RefreshTrustedAdvisorCheck:

support = boto3.client('support', region_name='us-east-1')  # bắt buộc us-east-1
support.refresh_trusted_advisor_check(checkId='eW7HH0l7J9')  # Service Limits

Sau khi làm mới, Trusted Advisor phát sự kiện lên EventBridge; rule thứ hai bắt sự kiện trạng thái WARN/ERROR và đẩy sang SNS.

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

• A. Personal Health Dashboard — PHD báo sự kiện sức khoẻ dịch vụ của AWS ảnh hưởng tới bạn (bảo trì, sự cố Region). Nó không phải nơi theo dõi service limit, và cũng không có API "refresh check" như Trusted Advisor.
• B. Lambda tự đếm tài nguyên rồi tự so với hạn mức — đây là nhiều công sức nhất: phải viết mã cho từng dịch vụ, tự lấy hạn mức hiện hành (chúng thay đổi), tự xử lý phân trang, tự bảo trì mãi. Trái thẳng tiêu chí "LEAST development effort".
• D. AWS Config custom rule kiểm tra service limit — Config theo dõi cấu hình tài nguyên, không có khái niệm hạn mức tài khoản. Custom rule nghĩa là lại tự viết Lambda — cùng vấn đề với B, thêm một tầng.

Ghi nhớ

Hai chi tiết hay bị hỏi: API của Trusted Advisor (support) chỉ có ở us-east-1 và đòi gói hỗ trợ Business trở lên. Ngoài ra còn có Service Quotas — dịch vụ chuyên trách hạn mức, có CloudWatch metric ResourceCount để đặt alarm trực tiếp, và trong nhiều tình huống thực tế nó gọn hơn cả Trusted Advisor.

Đáp án

B — Aurora với read replica cho danh mục sản phẩm, và các cụm Aurora cục bộ ở từng Region cho dữ liệu mua hàng của khách.

Vì sao đúng

Tiêu chí quyết định nằm ở cuối đề: "LEAST changes to the application". Ứng dụng hiện chạy MySQL quan hệ, nên giữ nguyên mô hình quan hệ là con đường ít sửa nhất — Aurora MySQL tương thích ở mức giao thức với MySQL, gần như chỉ đổi chuỗi kết nối.

Hai loại dữ liệu, hai cách bố trí:

Điểm quan trọng ở vế thứ hai: dữ liệu mua hàng không được sao chép ra ngoài Region. Nên phải là các cụm độc lập, không phải một cụm toàn cầu — và điều này loại thẳng mọi phương án dùng global table.

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

• A. DynamoDB global table cho danh mục + regional table cho mua hàng — bố trí dữ liệu thì đúng, nhưng đòi viết lại toàn bộ tầng truy cập dữ liệu từ SQL sang NoSQL: bỏ join, thiết kế lại khoá phân vùng, bỏ giao dịch quan hệ. Vi phạm nặng nhất tiêu chí "ít thay đổi nhất".
• C. Aurora cho danh mục + DynamoDB global table cho dữ liệu mua hàng — sai ở đúng chỗ nhạy cảm nhất: global table sao chép dữ liệu sang mọi Region tham gia, tức là đưa dữ liệu mua hàng ra khỏi Region gốc — vi phạm thẳng yêu cầu tuân thủ.
• D. Redshift cho danh mục — Redshift là kho dữ liệu phân tích (OLAP), tối ưu cho quét lớn, không phải cho tra cứu từng bản ghi với độ trễ thấp trong ứng dụng web (OLTP). Sai loại tải hoàn toàn.

Ghi nhớ

Khi đề nêu ràng buộc pháp lý về nơi lưu dữ liệu (data residency), hãy loại ngay mọi dịch vụ sao chép tự động xuyên Region: DynamoDB global tables, Aurora Global Database, S3 CRR. Ràng buộc tuân thủ thắng mọi tiện lợi kỹ thuật.

Đáp án

B — Trang tĩnh trên Amazon S3, đặt sau CloudFront và bảo vệ bằng AWS WAF web ACL.

Vì sao đúng

Đọc lại ba yêu cầu và soi từng cái:

Chữ "client-side scripts" là chi tiết quan trọng: JavaScript chạy trên trình duyệt, không cần máy chủ nào thực thi. Nên toàn bộ trang là nội dung tĩnh thuần.

Cách làm chuẩn hiện nay còn dùng Origin Access Control (OAC) để bucket đóng hoàn toàn với Internet và chỉ CloudFront đọc được — vừa an toàn hơn vừa dùng được S3 encryption với KMS.

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

• A. EC2 + ElastiCache + Shield — không serverless (phải quản instance, phải vá, phải scale). ElastiCache là cache dữ liệu trong ứng dụng, không phải CDN. Và Shield Standard chống DDoS ở tầng mạng/vận chuyển, không chống lỗ hổng tầng ứng dụng như SQL injection hay XSS — đó là việc của WAF.
• C. Lambda + API Gateway + GuardDuty — serverless nhưng sai kiến trúc cho nội dung tĩnh: trả ảnh và video qua Lambda là vừa đắt vừa chậm, còn vướng giới hạn kích thước phản hồi (6 MB). GuardDuty là phát hiện mối đe doạ, không chặn tấn công web.
• D. ECS Fargate + ElastiCache + WAF — Fargate bớt được việc quản máy chủ nhưng vẫn phải quản container, vẫn trả tiền theo thời gian chạy, và vẫn không có CDN toàn cầu. Thừa hẳn một tầng cho nội dung tĩnh.

Ghi nhớ

S3 + CloudFront + WAF là bộ ba mặc định cho "trang tĩnh, serverless, toàn cầu, có bảo vệ". Nhớ rõ ranh giới: Shield chống DDoS (tầng 3/4), WAF chống lỗ hổng ứng dụng (tầng 7), GuardDuty phát hiện hành vi đe doạ — ba việc khác nhau.

Đáp án

C — AWS CodeDeploy với EC2 Auto Scaling, dùng cấu hình CodeDeployDefault.OneAtATime, tạo alarm trên CPU và bật automatic rollback theo alarm.

Vì sao đúng

Ba yêu cầu, và CodeDeploy đáp ứng cả ba bằng cấu hình có sẵn:

1. Mỗi lần một instance — deployment configuration CodeDeployDefault.OneAtATime làm đúng nghĩa đen: cập nhật xong instance này mới sang instance kế tiếp. Instance nào đang deploy thì được gỡ khỏi target group trước.
2. Các instance còn lại vẫn phục vụ — hệ quả trực tiếp của (1): n−1 instance luôn nhận traffic.
3. Rollback khi CPU vượt 85% — CodeDeploy có rollback tự động dựa trên CloudWatch alarm. Tạo alarm CPUUtilization > 85, khai nó trong deployment group, alarm chuyển sang ALARM là CodeDeploy dừng và deploy lại bản trước.

aws deploy update-deployment-group --application-name ung-dung \
  --current-deployment-group-name prod \
  --deployment-config-name CodeDeployDefault.OneAtATime \
  --alarm-configuration enabled=true,alarms=[{name=CPU-Vuot-85}] \
  --auto-rollback-configuration enabled=true,events=DEPLOYMENT_FAILURE,DEPLOYMENT_STOP_ON_ALARM

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

• A. Elastic Beanstalk rolling với batch size 1 — làm được vế "mỗi lần một instance", nhưng ứng dụng không chạy trên Beanstalk (đề nói Auto Scaling thuần). Quan trọng hơn: rolling deployment của Beanstalk không có cơ chế rollback theo CloudWatch alarm — nó chỉ rollback khi health check của chính Beanstalk hỏng, không theo một metric tuỳ ý.
• B. "Systems Manager thực hiện blue/green với EC2 Auto Scaling" — SSM không có tính năng blue/green deployment. Đó là việc của CodeDeploy. Ngoài ra blue/green dựng cả fleet thứ hai, trái yêu cầu "chỉ ảnh hưởng một instance mỗi lần".
• D. Step Functions + lifecycle hook + SSM Automation — về lý thuyết dựng được, nhưng đó là tự viết lại CodeDeploy bằng ba dịch vụ: tự quản trạng thái, tự xử lý rollback, tự xử lý lỗi giữa chừng. Rất nhiều mã cho thứ đã có sẵn.

Ghi nhớ

Ba deployment configuration dựng sẵn của CodeDeploy trên EC2: | Cấu hình | Hành vi | |---|---| | OneAtATime | một instance mỗi lượt — an toàn nhất, chậm nhất | | HalfAtATime | 50% mỗi lượt | | AllAtOnce | tất cả cùng lúc — nhanh nhất, rủi ro nhất |

Và rollback theo CloudWatch alarm là tính năng riêng của CodeDeploy — nhớ nó khi đề nêu một ngưỡng metric cụ thể.

Đáp án

D — Chứng chỉ SSL trên máy chủ web legacy đã hết hạn; phải cấp lại chứng chỉ do một CA được công nhận toàn cầu ký, và cài đủ chuỗi chứng chỉ đầy đủ.

Vì sao đúng

Đây là câu về cách CloudFront nói chuyện với custom origin, và có hai quy tắc cứng:

Quy tắc 1 — CloudFront kiểm chứng chỉ của origin. Khi origin dùng HTTPS, CloudFront bắt buộc chứng chỉ đó phải:

• còn hạn,
• do một CA công cộng được tin cậy ký (danh sách Mozilla CA),
• có chuỗi trung gian đầy đủ,
• và tên miền khớp với origin domain name.

Chứng chỉ hết hạn ⇒ CloudFront không bắt tay được với origin ⇒ trả lỗi 502.

Quy tắc 2 — ACM không cấp chứng chỉ cho máy chủ ngoài AWS. Đây là điểm loại B. Chứng chỉ công cộng của ACM chỉ dùng được với các dịch vụ AWS tích hợp (CloudFront, ALB, API Gateway); bạn không tải được private key về để cài lên một máy chủ trong trung tâm dữ liệu riêng. Muốn vậy phải dùng ACM Private CA (mà private CA thì trình duyệt và CloudFront không tin) hoặc mua chứng chỉ từ CA công cộng.

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

• A. Chứng chỉ tự ký — chẩn đoán đúng nhưng cách chữa sai dứt khoát: CloudFront từ chối chứng chỉ tự ký từ custom origin. Lỗi 502 sẽ y nguyên. (Ngoại lệ duy nhất: đặt OriginProtocolPolicy thành http-only, nhưng khi ấy đường CloudFront→origin không còn mã hoá.)
• B. Cấp lại chứng chỉ cho web server bằng ACM — không làm được, theo Quy tắc 2 ở trên.
• C. "Chứng chỉ trên CloudFront distribution hết hạn" — sai chỗ. Chứng chỉ ACM gắn vào CloudFront (cho tên miền phía người dùng) tự gia hạn khi vẫn còn xác thực được quyền sở hữu tên miền. Và triệu chứng cũng khác: chứng chỉ phía viewer hỏng thì trình duyệt báo cảnh báo bảo mật, không phải lỗi 502 từ CloudFront.

Ghi nhớ

Và đừng quên chuỗi trung gian: chứng chỉ đúng nhưng thiếu intermediate là lỗi rất hay gặp — trình duyệt hiện đại thường tự vá được, còn CloudFront thì không.

Đáp án

C — Chặn truy cập ẩn danh bằng bucket policy, sửa service role của CodeBuild để có quyền S3, rồi tải script bằng AWS CLI.

Vì sao đúng

Nguyên tắc: không bao giờ dùng thông tin xác thực tĩnh khi đã có role.

CodeBuild chạy dưới một service role. Mọi lời gọi AWS 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ờ nằm trong mã nguồn.

# buildspec.yml — không có khoá nào cả
phases:
  pre_build:
    commands:
      - aws s3 cp s3://kho-script/nap-du-lieu.sql .

Kèm theo, bucket policy chặn truy cập ẩn danh:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::123456789012:role/codebuild-service-role"},
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::kho-script/*"
}

Đây cũng là mẫu chung cho mọi compute của AWS: EC2 dùng instance profile, Lambda dùng execution role, ECS task dùng task role. Không cái nào cần access key.

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

• A. Dùng access key và secret key — đúng phần chặn ẩn danh nhưng sai phần còn lại. Khoá tĩnh phải cất ở đâu đó (biến môi trường, Parameter Store), không tự hết hạn, và nếu rò rỉ thì kẻ tấn công dùng được cho tới khi có người phát hiện. Đây gần như luôn là đáp án sai trong đề thi.
• B. "Bật HTTPS basic authentication trên bucket S3" — S3 không có tính năng này. S3 xác thực bằng SigV4, không bằng basic auth hay token tự đặt. Phương án bịa ra một tính năng.
• D. "AllowedBuckets trong cấu hình CodeBuild project" — cũng không tồn tại. CodeBuild không có danh sách bucket cho phép; quyền truy cập S3 hoàn toàn do IAM quyết định.

Ghi nhớ

Trong mọi câu hỏi kiểu này, thứ tự ưu tiên là bất biến: IAM role > IAM role > … > (rất xa) > access key tĩnh. Thấy phương án nào nhắc tới access key trong ngữ cảnh dịch vụ AWS gọi dịch vụ AWS thì gần như chắc chắn loại được.