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

Đáp án

D — EventBridge rule khớp kết quả đánh giá NON_COMPLIANT của đúng rule restricted-ssh, dùng input transformer, đẩy sang SNS.

Vì sao đúng

Đề có ba ràng buộc và phương án D là phương án duy nhất thoả cả ba:

1. Chỉ rule restricted-ssh — lọc theo tên rule trong event pattern.
2. Chỉ trạng thái NON_COMPLIANT — không phải mọi kết quả.
3. Thông báo phải có tên và ID của security group — đây là việc của input transformer: bóc trường từ event JSON và ghép thành câu tiếng người.

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

Không có input transformer thì SNS gửi nguyên khối JSON thô — kỹ thuật là đủ thông tin, nhưng đề đòi thông báo tuỳ biến nêu rõ tên và ID.

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

• A. Khớp NON_COMPLIANT của mọi managed rule — sẽ dội thông báo từ mọi rule đang bật trong tài khoản. Nhiễu nhiều tới mức đội trực bắt đầu bỏ qua, và khi ấy cảnh báo mất hết giá trị.
• B. Khớp trạng thái ERROR — ERROR nghĩa là rule không đánh giá được (thiếu quyền, throttle). Đó là lỗi vận hành của chính hệ thống giám sát, không phải security group hở.
• C. Khớp mọi kết quả của restricted-ssh — bao gồm cả COMPLIANT, nên đội sẽ nhận thông báo mỗi lần một security group được sửa đúng. Cảnh báo cho tin tốt là cách nhanh nhất giết một kênh cảnh báo.

Ghi nhớ

Event pattern của EventBridge nên hẹp nhất có thể ngay từ đầu: lọc ở tầng rule không tốn gì, còn lọc ở Lambda phía sau thì vẫn phải trả tiền cho mọi lần gọi. Và khi đề nói "customized notification", hãy tìm chữ input transformer.

Đáp án

B — Pilot light: dựng bản sao phần lõi của hạ tầng ở Region khác, tạo RDS read replica cross-Region, khi có sự cố thì promote và mở rộng.

Vì sao đúng

Chọn chiến lược DR luôn bắt đầu từ hai con số. Đề cho RTO = 3 giờ và RPO ≈ 15 phút.

RTO 3 giờ khá rộng rãi, còn RPO 15 phút thì loại backup & restore (snapshot định kỳ không đảm bảo được 15 phút). Pilot light nằm đúng ô: dữ liệu luôn được sao chép liên tục (read replica cross-Region, độ trễ thường vài giây), còn tầng compute thì tắt hoặc chỉ có khuôn và được dựng lên khi cần — hoàn toàn kịp trong 3 giờ.

Điểm cốt lõi phân biệt pilot light: phần dữ liệu luôn sống, phần xử lý thì ngủ.

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

• A. Pilot light nhưng khôi phục từ full backup — mâu thuẫn nội tại. Khôi phục từ backup đầy đủ đưa RPO về đúng khoảng cách giữa hai lần backup, phá vỡ mục tiêu 15 phút.
• C. Multi-site active/active — thoả yêu cầu quá dư nhưng đắt hơn nhiều lần và phức tạp hơn nhiều lần. Đề chỉ cần 3 giờ; trả tiền cho RTO gần bằng 0 là chọn sai theo chiều ngược lại.
• D. Warm standby — cũng thoả, cũng đắt hơn cần thiết: warm standby giữ toàn bộ môi trường chạy thu nhỏ 24/7. Với RTO 3 giờ thì không có lý do trả khoản đó.

Ghi nhớ

Đọc RTO/RPO trước, chọn chiến lược sau. RPO nhỏ ⇒ phải sao chép dữ liệu liên tục; RTO nhỏ ⇒ phải giữ sẵn compute. Câu này RPO chặt còn RTO lỏng, nên đáp án là chiến lược chỉ giữ sẵn dữ liệu.

Đáp án

B — Rolling restart ASG xanh để cài phần mềm mới, sau đó dùng lệnh AWS CLI đổi ALB trỏ sang target group của môi trường xanh.

Vì sao đúng

Hạ tầng đã dựng xong: hai ASG, hai target group, một ALB trỏ được vào cả hai, Route 53 alias trỏ vào ALB. Còn lại đúng hai việc, và thứ tự là điều quan trọng nhất:

1. Deploy trước lên môi trường xanh (đang không nhận traffic) — sai sót ở bước này không ảnh hưởng ai.
2. Chuyển traffic sau, bằng cách sửa rule của listener trên ALB.

aws elbv2 modify-listener --listener-arn <arn-listener> \
  --default-actions Type=forward,TargetGroupArn=<arn-tg-xanh>

Chuyển ở tầng ALB chứ không phải tầng DNS là điểm mấu chốt của đề: yêu cầu là all-at-once. Sửa listener có hiệu lực ngay và cho mọi client; đổi bản ghi Route 53 thì phải chờ TTL và resolver ngoài tầm kiểm soát, nên trong nhiều phút vẫn có người đi vào môi trường cũ — đó là chuyển dần, không phải all-at-once.

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

• A. Deploy lên môi trường xanh lam (blue) rồi đổi DNS sang xanh lá (green) — deploy một nơi, chuyển traffic sang nơi khác. Người dùng sẽ được đưa tới môi trường chưa cập nhật.
• C. Deploy đúng nhưng chuyển bằng Route 53 — chuyển traffic không dứt khoát vì TTL của DNS, trượt yêu cầu all-at-once.
• D. Chuyển traffic trước rồi mới deploy — nguy hiểm nhất. Traffic thật đổ vào môi trường xanh trong lúc nó đang được rolling restart, nghĩa là cố ý phục vụ khách trên một fleet đang bị xáo trộn.

Ghi nhớ

Blue/Green thì luôn deploy vào môi trường đang nhàn rỗi, chuyển traffic sau cùng, và nếu muốn cắt dứt điểm thì chuyển ở ALB/target group, đừng chuyển ở DNS — DNS không bao giờ tức thời.

Đáp án

A — Thêm hook BeforeAllowTraffic vào AppSpec để kiểm tra và chờ thay đổi CSDL lan xong trước khi cho traffic vào phiên bản Lambda mới.

Vì sao đúng

CodeDeploy khi deploy Lambda chỉ có bốn lifecycle event, ít hơn hẳn so với deploy lên EC2:

Start → BeforeAllowTraffic → AllowTraffic → AfterAllowTraffic → End

Chỉ BeforeAllowTraffic và AfterAllowTraffic là hook viết được (mỗi hook là một Lambda validation function). AllowTraffic do chính CodeDeploy thực hiện.

Triệu chứng trong đề — lỗi rải rác ngay sau deploy rồi tự hết — khớp chính xác với "traffic vào trước khi thay đổi CSDL sẵn sàng". Vậy phải chặn ở trước cửa AllowTraffic:

version: 0.0
Resources:
  - myFunction:
      Type: AWS::Lambda::Function
      Properties:
        Name: xu-ly-don
        Alias: prod
        CurrentVersion: 1
        TargetVersion: 2
Hooks:
  - BeforeAllowTraffic: kiem-tra-migration-xong

Hàm kiem-tra-migration-xong chờ tới khi CSDL sẵn sàng rồi gọi PutLifecycleEventHookExecutionStatus với Succeeded; nếu hết giờ thì trả Failed và CodeDeploy tự rollback, không client nào chạm vào phiên bản mới.

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

• B. BeforeInstall và C. ValidateService — hai event này không tồn tại trong deploy Lambda; chúng thuộc bộ hook của EC2/On-Premises. Khai vào AppSpec của Lambda thì bị bỏ qua, và bạn có một biện pháp bảo vệ chỉ tồn tại trên giấy.
• D. AfterAllowTestTraffic — có thật nhưng thuộc bộ hook của ECS blue/green, không phải Lambda. Và kể cả có, "sau khi cho test traffic vào" đã là muộn với vấn đề này.

Ghi nhớ

Bộ hook khác nhau theo nền tảng: | Nền tảng | Hook viết được | |---|---| | Lambda | BeforeAllowTraffic, AfterAllowTraffic | | ECS | thêm AfterAllowTestTraffic, BeforeInstall, AfterInstall | | EC2/On-prem | ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart, ValidateService… |

Đáp án

D và E.

• D — Gọi ContinueUpdateRollback.
• E — Sửa tay tài nguyên về đúng trạng thái mà stack mong đợi.

Vì sao đúng

UPDATE_ROLLBACK_FAILED là một trong số ít trạng thái mà CloudFormation không tự thoát được. Nó nghĩa là: bản 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.

Ở trạng thái này stack chỉ chấp nhận đúng hai thao tác: ContinueUpdateRollback và DeleteStack. Mọi lệnh UpdateStack đều bị từ chối — nên phương án C bất khả thi về mặt cơ học.

Quy trình chuẩn:

1. Đọc sự kiện của stack tìm tài nguyên nào chặn rollback và vì sao.
2. Sửa tay nguyên nhân đó (E) — ví dụ trả lại một bản ghi bị xoá, gỡ object khỏi bucket không xoá được, sửa lại tham số bị đổi ngoài CloudFormation.
3. Gọi ContinueUpdateRollback (D) để CloudFormation thử lại từ chỗ dừng.

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ó:
aws cloudformation continue-update-rollback --stack-name my-stack \
  --resources-to-skip LogicalIdCuaTaiNguyenKetCung

--resources-to-skip đưa stack về UPDATE_ROLLBACK_COMPLETE nhưng để lại drift: tài nguyên bị bỏ qua không còn khớp template.

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

• A. StackSets — công cụ triển khai một template ra nhiều tài khoản/Region, chẳng liên quan gì tới việc cứu một stack hỏng.
• B. Drift detection — chỉ báo cáo khác biệt, không sửa gì. Nó có ích ở bước chẩn đoán, nhưng không phải hành động cứu.
• C. UpdateStack với template gốc — bị API từ chối thẳng ở trạng thái UPDATE_ROLLBACK_FAILED.

Ghi nhớ

Ba trạng thái "kẹt" cần nhớ: UPDATE_ROLLBACK_FAILED → ContinueUpdateRollback; ROLLBACK_FAILED khi tạo mới → chỉ xoá stack được; DELETE_FAILED → xoá lại và bỏ qua tài nguyên cứng đầu.

Đáp án

D — Bật provisioned concurrency cho Lambda và dùng Application Auto Scaling với min = 1, max = 100.

Vì sao đúng

Đề mô tả rất rõ cold start 7–10 giây, tập trung vào khung 14h–17h. Provisioned concurrency là cơ chế duy nhất của Lambda loại bỏ cold start: AWS khởi tạo sẵn số môi trường thực thi bạn yêu cầu, chạy xong phần init (nạp runtime, code ngoài handler, mở kết nối), rồi giữ chúng ở trạng thái ấm.

Ghép với Application Auto Scaling thì lượng dự phòng tự lên xuống theo tải, không phải trả tiền giữ 100 môi trường cả ngày cho một khung ba tiếng.

Điểm cần phân biệt cho rõ:

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

• A. Reserved concurrency — đây là bẫy trung tâm của câu hỏi. Reserved concurrency chỉ giới hạn trần; nó không giữ môi trường nào ấm cả. Đặt nó xong cold start vẫn nguyên vẹn, mà giờ còn thêm nguy cơ bị throttle. Ngoài ra Application Auto Scaling không nhận reserved concurrency làm scalable target.
• B. Lambda layer để "xử lý song song" — hiểu sai layer. Layer chỉ là cách đóng gói thư viện dùng chung; nó không liên quan gì tới đồng thời hay hiệu năng khởi động.
• C. Ephemeral storage /tmp 10.240 MB — /tmp chỉ tồn tại trong vòng đời một môi trường thực thi và không dùng được như cache giữa các lần gọi một cách đảm bảo. Quan trọng hơn: cold start là chi phí khởi tạo môi trường, tăng dung lượng đĩa không rút ngắn được nó. Đề cũng đã có DAX cho phần cache dữ liệu.

Ghi nhớ

Thấy chữ cold start trong đề Lambda thì đáp án gần như chắc chắn là provisioned concurrency. Thấy chữ giới hạn/throttle/bảo vệ downstream thì là reserved concurrency. Hai tên rất giống nhau, tác dụng hoàn toàn khác.

Đáp án

A — Lambda phải gửi phản hồi (SUCCESS hoặc FAILED) tới pre-signed S3 URL mà CloudFormation cung cấp.

Vì sao đúng

Custom resource hoạt động theo mô hình gọi lại (callback), và đây là chỗ hầu hết người mới vấp:

CloudFormation → gửi request (kèm ResponseURL) → Lambda
CloudFormation ← ĐỢI ← Lambda PUT phản hồi vào ResponseURL

CloudFormation không nhìn kết quả trả về của hàm Lambda. Nó chỉ chờ một HTTP PUT vào pre-signed S3 URL nằm trong trường ResponseURL của event. Hàm chạy xong, thậm chí chạy đúng, mà quên PUT thì stack đứng ở CREATE_IN_PROGRESS cho tới khi hết giờ chờ — mặc định là 1 giờ. Đúng triệu chứng trong đề.

Trong Python thì cfnresponse lo phần này:

import cfnresponse
def handler(event, context):
    try:
        # ... việc thật ...
        cfnresponse.send(event, context, cfnresponse.SUCCESS, {'KetQua': 'xong'})
    except Exception as e:
        # BẮT BUỘC báo cả khi lỗi, nếu không stack treo nguyên giờ
        cfnresponse.send(event, context, cfnresponse.FAILED, {'Loi': str(e)})

Khối except cũng phải gửi — đó là lỗi phổ biến thứ hai sau việc quên gửi hoàn toàn.

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

• B. "Phải dùng AWS::CloudFormation::CustomResource" — không bắt buộc. Dạng Custom::TenGiDo hoàn toàn hợp lệ và còn được khuyến nghị vì tên hiện rõ hơn trong console. Cả hai đều cần phản hồi như nhau.
• C. "Người viết template và người cung cấp custom resource là một thì stack lỗi" — bịa. CloudFormation không có khái niệm nào như vậy.
• D. "Sau send thì hàm kết thúc, mã phía sau bị bỏ qua" — câu này đúng về mặt sự thật (đó là một lưu ý có thật trong tài liệu AWS) nhưng không phải nguyên nhân của triệu chứng đang mô tả. Đề hỏi bước nào bị bỏ sót, và bước bị bỏ sót là chính lời gọi send. Đây là kiểu nhiễu tinh vi: một câu đúng đặt sai chỗ.

Ghi nhớ

Stack treo ở CREATE_IN_PROGRESS với custom resource ⇒ gần như luôn là thiếu phản hồi. Luôn bọc toàn bộ handler trong try/except và gửi FAILED ở nhánh lỗi — nếu không, mỗi lần deploy hỏng là một tiếng đồng hồ chờ vô ích.

Đáp án

B — Dùng AWS SAM với tính năng traffic-shifting sẵn có, deploy qua CodeDeploy, kèm hàm kiểm thử pre-traffic và post-traffic.

Vì sao đúng

Quy trình hiện tại là hai script CLI: một để deploy, một để lùi lại khi hỏng. Vấn đề không phải script xấu, mà là phát hiện lỗi và rollback đều do người khởi động. Đề đòi giảm cả hai: thời gian deploy và thời gian phát hiện + rollback.

SAM khai bốn dòng là có đủ:

Resources:
  HamXuLy:
    Type: AWS::Serverless::Function
    Properties:
      AutoPublishAlias: prod
      DeploymentPreference:
        Type: Linear10PercentEvery1Minute   # hoặc Canary10Percent5Minutes
        Alarms:
          - !Ref AlarmLoiCao
        Hooks:
          PreTraffic:  !Ref KiemTraTruoc
          PostTraffic: !Ref KiemTraSau

Ba thứ có được ngay:

• Traffic shifting dần qua alias weight — lỗi chỉ chạm vào một phần nhỏ người dùng.
• Alarms — CloudWatch alarm kêu là CodeDeploy tự rollback, không cần ai bấm gì. Đây chính là vế "giảm thời gian phát hiện".
• Pre/post-traffic hook — chặn bản hỏng trước khi nó chạm production.

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

• A. CloudFormation stack với API Gateway endpoint mới cho mỗi phiên bản — mỗi lần deploy lại dựng một endpoint mới rồi sửa origin CloudFront: chậm hơn hẳn (CloudFront lan cấu hình mất vài phút), và rollback vẫn là thao tác tay.
• C và D. Nested stack — cập nhật nested stack không nhanh hơn, và cũng không có cơ chế tự phát hiện lỗi nào. Rollback vẫn phải người bấm, đúng vấn đề cần bỏ.

Ghi nhớ

Với Lambda, cặp SAM DeploymentPreference + Alarms là cách rẻ nhất để có canary deploy và rollback tự động theo chỉ số. Không có Alarms thì traffic shifting chỉ làm chậm sự cố lại, chứ không tự chữa.

Đáp án

B và E.

• B — Bật Auto Remediation cho rule s3-bucket-logging-enabled, chọn sẵn action AWS-ConfigureS3BucketLogging.
• E — AutomationAssumeRole phải cho SSM assume được, và người tạo remediation phải có quyền iam:PassRole với role đó.

Vì sao đúng

Đề nhấn mạnh quy trình thủ công đang chậm và để lộ tài nguyên lâu. AWS Config Auto Remediation giải quyết trọn vẹn: rule phát hiện NON_COMPLIANT → tự chạy một SSM Automation document để sửa.

Vì sao chọn document dựng sẵn (B). AWS đã có AWS-ConfigureS3BucketLogging; viết Lambda làm lại đúng việc đó là thêm code phải bảo trì mà không được gì.

Vì sao E là bắt buộc. Config không tự sửa bằng danh tính của nó — nó truyền một role (AutomationAssumeRole) cho SSM để SSM dùng role đó. Nên cần đủ hai vế:

// Trust policy của AutomationAssumeRole
{"Effect":"Allow","Principal":{"Service":"ssm.amazonaws.com"},"Action":"sts:AssumeRole"}

và người cấu hình remediation phải có iam:PassRole lên role đó. Thiếu vế nào thì remediation im lặng không chạy, còn rule vẫn báo NON_COMPLIANT mãi.

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

• A. Chọn Lambda tự viết — về nguyên tắc làm được, nhưng thừa khi đã có document dựng sẵn cho đúng việc này.
• C. "Truyền resource ID là bắt buộc" — sai ở chữ bắt buộc. Tham số ResourceId là tuỳ chọn; nếu không khai, Config tự truyền ID của tài nguyên vi phạm vào tham số mặc định của document. Có khai thì hữu ích khi tên tham số không khớp, nhưng không phải điều kiện để auto remediation hoạt động.
• D. Rule tên s3-logging-enabled — không có rule nào tên như vậy. Tên đúng là s3-bucket-logging-enabled. Đề thi AWS rất hay bẫy bằng cách bớt một chữ trong tên managed rule.

Ghi nhớ

Auto Remediation cần đủ bốn mảnh: rule, document, AutomationAssumeRole mà SSM assume được, và iam:PassRole cho người cấu hình. Nó cũng có MaximumAutomaticAttempts — sửa hoài không đạt thì Config dừng, không lặp vô hạn.

Đáp án

C và E.

• C — Cài SSM Agent trên toàn bộ instance, thử bản vá ở pre-production rồi triển khai như maintenance window task có phê duyệt.
• E — Áp patch baseline bằng document AWS-RunPatchBaseline.

Vì sao đúng

Đề đòi: đội máy lẫn Windows và Linux, phải kiểm toán được, phải an toàn, và ít công sức nhất.

AWS Systems Manager Patch Manager đáp ứng cả bốn bằng một công cụ:

Maintenance window cho phần lịch và phần phê duyệt: vá chỉ chạy trong cửa sổ đã định, sau khi đã thử ở pre-production.

Về tên document (E): đây là mấu chốt phân biệt C/D/E. Document đúng và hiện hành là AWS-RunPatchBaseline, chạy được trên cả Windows lẫn Linux.

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

• A. Công cụ vá của chính hệ điều hành — nghĩa là WSUS cho Windows và yum-cron/unattended-upgrades cho Linux: hai hệ thống, hai bộ báo cáo, hai chỗ để hỏng. Trái hẳn với "MINIMAL effort".
• B. "CloudFormation automatic patching" — không tồn tại. CloudFormation cung cấp hạ tầng, không vá hệ điều hành đang chạy.
• D. AWS-ApplyPatchBaseline — document này đã cũ, chỉ chạy trên Windows và bị AWS-RunPatchBaseline thay thế. Đây đúng là loại bẫy "tên gần giống" mà đề hay dùng; nhớ chữ Run, không phải Apply.

Ghi nhớ

Bộ ba của Patch Manager: patch baseline (vá nào được duyệt) + patch group (áp cho máy nào, gắn bằng tag Patch Group) + maintenance window (chạy lúc nào). Document luôn là AWS-RunPatchBaseline.