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

Đáp án

D — Bật AWS Config rules và cấu hình automatic remediation bằng SSM Automation document.

Vì sao đúng

Đề đòi bốn thứ áp cho cả bucket đang có lẫn bucket tạo mới mỗi ngày: mã hoá, logging, versioning, và không được công khai.

AWS Config là công cụ duy nhất trong bốn phương án làm được cả hai vế — phát hiện và tự sửa — với managed rule sẵn cho từng yêu cầu:

Mỗi rule nối với một SSM Automation document dựng sẵn (AWS-ConfigureS3BucketLogging, AWS-ConfigureS3BucketVersioning, AWS-DisableS3BucketPublicReadWrite…), nên phần sửa cũng không phải viết mã.

Quan trọng nhất: Config đánh giá lại mỗi khi cấu hình tài nguyên thay đổi, nên bucket tạo hôm nay được kiểm ngay hôm nay — đúng vế "all existing and future buckets".

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

• A. Trusted Advisor — có check về quyền bucket S3, nhưng làm mới rất chậm (theo chu kỳ, không theo sự kiện), không phủ đủ bốn yêu cầu (không có check versioning hay logging riêng), và đòi gói hỗ trợ Business trở lên.
• B. "Bật Systems Manager và tự khắc phục bằng SSM document" — SSM có phần thực thi (document), nhưng không có phần phát hiện: nó không đánh giá tuân thủ và không biết bucket nào đang lệch chuẩn. Đây chỉ là nửa sau của giải pháp.
• C. CloudTrail + Lambda — CloudTrail cho biết ai đã làm gì, nên bắt được CreateBucket, nhưng không đánh giá trạng thái hiện tại. Hàng trăm bucket đã tồn tại trước khi bật sẽ nằm ngoài tầm hoàn toàn — mà đề nói rõ "all existing and future buckets". Và phần đánh giá phải tự viết bằng Lambda.

Ghi nhớ

Chia vai cho rõ: Config = trạng thái tài nguyên có đúng chuẩn không (detective); CloudTrail = ai đã gọi API nào (audit); SSM = thực thi việc sửa (corrective); SCP/IAM = chặn ngay từ đầu (preventive). Câu hỏi phủ "cả hiện tại lẫn tương lai" thì Config gần như luôn là trục chính.

Đáp án

C — Cấu hình ứng dụng lưu thông tin phiên đã xác thực vào một cụm Amazon ElastiCache.

Vì sao đúng

Nguyên nhân gốc: phiên đăng nhập đang được lưu trên chính instance. Mà kiến trúc ở đây là immutable blue/green — mỗi lần deploy là thay toàn bộ instance bằng máy mới. Máy cũ biến mất kéo theo mọi phiên, nên người dùng bị đăng xuất. Điều tương tự xảy ra ở mỗi lần scale-in.

Cách chữa đúng là tách trạng thái ra khỏi máy tính toán — biến ứng dụng thành stateless:

Trước:  Instance A [phiên 1,2,3]   Instance B [phiên 4,5]   ← thay máy là mất
Sau:    Instance A ─┐
        Instance B ─┼─→ ElastiCache [phiên 1..5]            ← máy đến và đi tuỳ ý
        Instance C ─┘

ElastiCache hợp cho dữ liệu phiên vì độ trễ dưới mili giây (mỗi request đều phải đọc phiên), có TTL sẵn để phiên tự hết hạn, và với Redis thì có replica đa AZ.

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

• A. Sticky session + lưu phiên trên block volume của instance và B. Session affinity + lưu trên block volume — hai phương án này thực chất giống nhau (sticky session và session affinity là cùng một thứ, khác tên). Cả hai đều không chữa được vấn đề: sticky session chỉ giữ một người dùng quay lại đúng instance cũ, nhưng khi instance đó bị thay thế trong lúc deploy thì không còn gì để quay lại. Phiên vẫn mất.
• D. Lưu phiên vào S3 — S3 là kho object, độ trễ hàng chục mili giây cho mỗi lần đọc/ghi. Phiên phải đọc ở mỗi request, nên đây là lựa chọn chậm và tốn kém (tính tiền theo số request). S3 cũng không có TTL tự động cho từng khoá theo kiểu phiên — chỉ có lifecycle theo ngày.

Ghi nhớ

Nguyên tắc lớn hơn: hạ tầng bất biến đòi ứng dụng không trạng thái. Mọi trạng thái phải nằm ngoài instance.

Đáp án

D — Dùng Lambda action trong CodePipeline để chạy một hàm Lambda kiểm tra và đẩy phiên bản sản phẩm mới vào AWS Service Catalog.

Vì sao đúng

Câu này thực ra kiểm tra một sự thật đơn giản: CodePipeline có những loại action nào.

CodePipeline hỗ trợ các nhóm action: Source, Build, Test, Deploy, Approval, Invoke (Lambda hoặc Step Functions). Trong đó:

Điểm quyết định là logic cần chạy: đọc mapping.yaml, kiểm tra tính hợp lệ, rồi tạo portfolio và sản phẩm cùng với phân quyền đi kèm. Đó là logic tuỳ biến, và Lambda action là chỗ duy nhất trong pipeline để đặt logic tuỳ biến.

def handler(event, context):
    job_id = event['CodePipeline.job']['id']
    try:
        # đọc mapping.yaml, kiểm tra, gọi API Service Catalog
        sc.create_portfolio(...); sc.create_product(...)
        codepipeline.put_job_success_result(jobId=job_id)
    except Exception as e:
        codepipeline.put_job_failure_result(jobId=job_id,
            failureDetails={'type': 'JobFailed', 'message': str(e)})

Bắt buộc gọi put_job_success_result / put_job_failure_result — không gọi thì pipeline treo tới khi hết giờ.

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

• A và C. "action ... trong AWS CodeBuild" — CodeBuild không có action nào cả. Nó chạy các lệnh khai trong buildspec. Khái niệm "action" thuộc về CodePipeline. Cả hai phương án sai ở tầng khái niệm.
• B. Service Catalog deploy action trong CodePipeline — action này có tồn tại, nhưng nó chỉ đẩy một phiên bản sản phẩm mới cho một sản phẩm đã có. Nó không tạo portfolio, không gán phân quyền, không đọc được tệp mapping để suy ra cần tạo những gì. Không đủ cho yêu cầu.

Ghi nhớ

Khi đề mô tả logic tuỳ biến không nằm gọn trong một action dựng sẵn, câu trả lời trong CodePipeline gần như luôn là Lambda Invoke action (hoặc Step Functions cho quy trình dài). Và nhớ ranh giới: CodePipeline có action, CodeBuild có phase và command.

Đáp án

A — Tạo API Gateway API ở mỗi Region, cấu hình Route 53 latency-based routing kèm health check; mỗi API tích hợp Lambda proxy tới hàm trong cùng Region.

Vì sao đúng

Yêu cầu là phản hồi nhanh cho người dùng ở từng khu vực địa lý, triển khai đa Region.

Hai chi tiết phải cùng đúng:

1. Latency-based routing. Route 53 đưa mỗi người dùng tới Region có độ trễ mạng đo được thấp nhất — không phải Region gần nhất trên bản đồ, mà là Region thực sự nhanh nhất theo dữ liệu Route 53 tự đo. Kèm health check, Region hỏng sẽ bị loại khỏi kết quả DNS, nên có luôn khả năng chịu lỗi.

2. Lambda ở CÙNG Region với API. Đây là điểm phân biệt A với C và là chỗ dễ mất điểm nhất. Nếu API ở Singapore mà gọi Lambda ở Virginia thì mỗi request phải vượt Thái Bình Dương — toàn bộ lợi ích của việc đặt API gần người dùng bị xoá sạch, thậm chí còn tệ hơn vì thêm một chặng.

Người dùng châu Á → Route 53 (latency) → API Gateway ap-southeast-1 → Lambda ap-southeast-1
Người dùng châu Âu → Route 53 (latency) → API Gateway eu-west-1     → Lambda eu-west-1

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

• B. Chỉ có health check, không có latency-based routing — thiếu đúng cơ chế cho vế "fast response times". Có health check mà không có chính sách định tuyến theo độ trễ thì không ai được đưa tới Region gần mình.
• C. Latency routing nhưng Lambda tập trung ở một Region — bẫy chính, như phân tích ở trên. Định tuyến người dùng tới API gần họ rồi lại đẩy request đi nửa vòng trái đất là tự vô hiệu hoá giải pháp.
• D. Failover routing giữa hai Region — failover là mô hình active/passive: mọi người dùng vào Region chính, chỉ chuyển sang Region phụ khi Region chính hỏng. Nó cho độ sẵn sàng chứ không cho độ trễ thấp theo khu vực.

Ghi nhớ

Với API serverless đa Region, ba mảnh phải cùng đúng: latency-based routing, health check, và mọi tầng phải cục bộ trong Region (API Gateway, Lambda, và nếu dùng DynamoDB thì global table). Đưa bất kỳ tầng nào về một Region tập trung là mất hết lợi ích.

Đáp án

B — Tạo us.example.com với failover routing (US là primary, EU là secondary), tạo eu.example.com với failover ngược lại, rồi tạo bản ghi latency-based cho example.com trỏ (alias) vào hai tên miền con đó.

Vì sao đúng

Đề đòi hai hành vi cùng lúc:

1. Định tuyến tới Region có độ trễ thấp nhất
2. Region hỏng thì chuyển sang Region còn lại

Route 53 giải bài này bằng cách lồng các chính sách định tuyến — và thứ tự lồng là toàn bộ nội dung câu hỏi:

example.com  ──── latency-based ────┬──→ us.example.com ── failover ──┬─ ALB us-east-1 (primary)
   (lớp ngoài: chọn Region nhanh)   │                                 └─ ALB eu-west-1 (secondary)
                                    └──→ eu.example.com ── failover ──┬─ ALB eu-west-1 (primary)
   (lớp trong: chịu lỗi trong Region đã chọn)                         └─ ALB us-east-1 (secondary)

Lớp ngoài phải là latency, vì đó là quyết định đầu tiên cần đưa ra cho mỗi truy vấn: người này nên đi Region nào. Lớp trong là failover, xử lý tình huống Region vừa chọn đang hỏng.

Đảo thứ tự thì hỏng hẳn: failover ở lớp ngoài nghĩa là tất cả đi về US trước, và độ trễ cho người dùng châu Âu không bao giờ được xét tới.

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

• A. Weighted + geolocation — geolocation định tuyến theo vị trí địa lý, không theo độ trễ thực tế. Trọng số 2:1 cũng vẫn gửi một phần ba traffic của người dùng Mỹ sang châu Âu ngay cả khi mọi thứ đều khoẻ mạnh — đó không phải định tuyến độ trễ thấp, và cũng không phải failover.
• C. Latency ở lớp trong, failover ở lớp ngoài — đảo ngược đúng thứ tự cần thiết. Bản ghi failover ở example.com gửi mọi người dùng tới us.example.com trước; người dùng châu Âu chỉ được sang EU khi US hỏng, chứ không phải vì EU gần hơn.
• D. Multivalue answer — trả về nhiều bản ghi khoẻ mạnh và để client tự chọn ngẫu nhiên. Có kiểm tra sức khoẻ nên tránh được endpoint hỏng, nhưng không có khái niệm độ trễ: người dùng Mỹ hoàn toàn có thể được đưa sang EU.

Ghi nhớ

Route 53 cho phép lồng chính sách bằng alias record, và quy tắc chung là: chính sách quyết định "đi đâu" đặt ở ngoài, chính sách xử lý "chỗ đó có sống không" đặt ở trong. Đây là mẫu thiết kế đa Region kinh điển và bị hỏi rất nhiều — thường bằng cách đảo thứ tự hai lớp để xem bạn có đọc kỹ không.

Đáp án

A — EventBridge rule trên repository CodeCommit phản ứng với code push, gọi Lambda để lấy mã, nén lại và gửi tới API bên ngoài.

Vì sao đúng

Yêu cầu: chạy công cụ SAST/DAST cho mỗi lần push, mã phải gửi qua một API bên ngoài, và làm hiệu quả nhất.

CodeCommit phát sự kiện CodeCommit Repository State Change lên EventBridge ở mỗi lần push, gần như tức thì:

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

Lambda nhận sự kiện, gọi GetFolder/GetFile hoặc git archive để lấy mã, nén, rồi POST sang API của công cụ quét. Không máy chủ nào phải nuôi, không polling, và chỉ tốn tiền khi thực sự có push.

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

• B. EventBridge theo lịch 5 phút, Lambda tự tra xem có commit mới không — polling thay cho sự kiện. Vừa lãng phí (~8.640 lần chạy mỗi tháng dù không ai push), vừa để trễ tới 5 phút, vừa buộc bạn tự lưu trạng thái "commit cuối đã xử lý là cái nào".
• C. "Chọn S3 bucket làm target để mã tự động được nén vào S3" — EventBridge không có target kiểu này. Không có cơ chế nào tự lấy mã từ CodeCommit và nén vào S3 chỉ bằng cách chọn bucket làm target. Phương án bịa ra một tích hợp không tồn tại.
• D. Git hook trên EC2 + cron — trái ngược hoàn toàn với "MOST efficiently": phải nuôi một EC2 chạy 24/7, tự vá, tự giám sát; cron lại thêm độ trễ; và bản thân CodeCommit không hỗ trợ server-side hook kiểu tự chạy script trên máy bạn.

Ghi nhớ

Có sự kiện thì bám vào sự kiện. CodeCommit phát sự kiện lên EventBridge cho push, tạo/xoá nhánh, pull request — nên mọi tự động hoá quanh CodeCommit đều nên bắt đầu từ EventBridge, không bao giờ từ cron.

Đáp án

C — Dùng template AWS SAM cho ứng dụng serverless, và CodeDeploy triển khai Lambda với kiểu Canary10Percent30Minutes.

Vì sao đúng

Yêu cầu: giảm thiểu tác động khi deploy hỏng. Nghĩa là bản mới không được chạm vào toàn bộ người dùng ngay lập tức.

Canary10Percent30Minutes đưa 10% traffic sang phiên bản mới, giữ nguyên 30 phút để quan sát, rồi mới chuyển nốt 90%. Nếu bản mới hỏng, chỉ 10% người dùng bị ảnh hưởng và chỉ trong cửa sổ đó.

Khai bằng SAM chỉ vài dòng:

Resources:
  HamXuLy:
    Type: AWS::Serverless::Function
    Properties:
      AutoPublishAlias: prod
      DeploymentPreference:
        Type: Canary10Percent30Minutes
        Alarms: [!Ref AlarmTyLeLoi]        # alarm kêu ⇒ CodeDeploy tự rollback
        Hooks:
          PreTraffic:  !Ref KiemTraTruoc
          PostTraffic: !Ref KiemTraSau

Điểm mấu chốt: Alarms biến canary thành cơ chế tự chữa. Không có nó, canary chỉ làm sự cố lan chậm hơn chứ không tự dừng.

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

• A. AllAtOnce — chuyển 100% traffic ngay lập tức. Đây chính xác là điều đề bảo phải tránh: deploy hỏng thì mọi người dùng bị ảnh hưởng ngay. Giám sát bằng CloudWatch chỉ cho bạn biết sau khi thiệt hại đã xảy ra.
• B. RoutingConfig của AWS::Lambda::Alias — về kỹ thuật có chia được traffic theo trọng số, nhưng bạn phải tự quản toàn bộ tiến trình: tự cập nhật trọng số từng bước, tự theo dõi, tự rollback bằng tay. CodeDeploy làm sẵn tất cả.
• D. Manual approval trong CodePipeline — kiểm thử thủ công trước khi deploy không thay thế được việc giới hạn bán kính ảnh hưởng trong lúc deploy. Và nó thêm một điểm chờ người, trái với "continuous deployment" mà đề nêu.

Ghi nhớ

Các kiểu deployment preference của SAM/CodeDeploy cho Lambda: | Kiểu | Hành vi | |---|---| | AllAtOnce | 100% ngay — rủi ro cao nhất | | Canary10Percent5Minutes / …30Minutes | 10% trước, chờ, rồi 90% | | Linear10PercentEvery1Minute / …10Minutes | tăng đều 10% mỗi khoảng |

Và luôn khai Alarms — đó là thứ biến việc chia traffic thành rollback tự động.

Đáp án

D — Amazon Inspector tự động dò lỗ hổng trên EC2; CloudWatch Agent thu system log và đẩy lên CloudWatch Logs.

Vì sao đúng

Đề đòi hai thứ, và mỗi thứ có đúng một công cụ:

Inspector quét CVE của gói phần mềm đã cài và phân tích khả năng tiếp cận từ mạng (đọc security group, NACL, route table để kết luận cổng nào thực sự với tới được). Bản Inspector hiện hành quét liên tục — có gói mới cài hoặc có CVE mới công bố là đánh giá lại ngay, không cần lên lịch.

Vết đăng nhập bắt buộc phải có agent. Đăng nhập SSH/RDP là sự kiện trong hệ điều hành; không log nào của AWS ghi lại nó. CloudWatch Agent đẩy /var/log/secure (Linux) hoặc Security event log (Windows) lên CloudWatch Logs, từ đó truy vấn được bằng Logs Insights và đặt alarm bằng metric filter.

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

• A. "Systems Manager tự động dò lỗ hổng" + "xem hoạt động đăng nhập trong Console" — SSM Inventory liệt kê gói đã cài và Patch Manager biết bản vá nào thiếu, nhưng cả hai không phải công cụ đánh giá lỗ hổng. Và không có màn hình nào trong Console hiển thị "login activity" của EC2.
• B. GuardDuty dò lỗ hổng + X-Ray — hai nhầm lẫn. GuardDuty phát hiện mối đe doạ, không dò lỗ hổng. X-Ray là công cụ theo dấu request trong ứng dụng để phân tích hiệu năng, hoàn toàn không liên quan tới log đăng nhập.
• C. SSM dò lỗ hổng + Kinesis Client Library thu system log — KCL là thư viện để viết ứng dụng đọc từ Kinesis stream, không phải tác nhân thu log trên máy. Ghép sai vai trò hoàn toàn.

Ghi nhớ

Inspector — lỗ hổng và phơi nhiễm mạng. GuardDuty — mối đe doạ và hành vi bất thường. Macie — dữ liệu nhạy cảm trong S3. CloudWatch Agent — log và metric của hệ điều hành. Bốn thứ này bị hoán đổi cho nhau trong đề thi rất thường xuyên.

Đáp án

C — Cấu hình các hàm Lambda chạy song song bằng cách đặt cùng một runOrder cho các action trong cùng một stage của CodePipeline.

Vì sao đúng

Vấn đề: bốn hàm Lambda độc lập với nhau đang được build, test và deploy tuần tự. Tổng thời gian = tổng của bốn chuỗi.

CodePipeline điều khiển thứ tự bằng thuộc tính runOrder trong mỗi action:

• Action có runOrder khác nhau → chạy lần lượt theo thứ tự tăng dần
• Action có cùng runOrder → chạy song song

"actions": [
  {"name": "Build-Ham-1", "runOrder": 1, ...},
  {"name": "Build-Ham-2", "runOrder": 1, ...},
  {"name": "Build-Ham-3", "runOrder": 1, ...},
  {"name": "Build-Ham-4", "runOrder": 1, ...}
]

Thời gian tổng chuyển từ tổng bốn chuỗi xuống còn chuỗi dài nhất. Với bốn hàm gần bằng nhau, đó là giảm khoảng bốn lần — không đổi một dòng mã ứng dụng nào.

Đây cũng là cách sửa đúng về bản chất: pipeline đang chậm vì cấu trúc tuần tự không cần thiết, không phải vì máy build yếu.

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

• A. Tăng compute type của CodeBuild — làm mỗi build nhanh hơn một chút, nhưng vẫn chạy nối đuôi nhau. Nếu mỗi build tốn 4 phút thì tổng vẫn là 16 phút; tăng vCPU may ra xuống 12 phút, trong khi song song hoá cho ra 4 phút. Và trả tiền nhiều hơn cho mỗi phút.
• B. Chạy CodeBuild trong VPC + "dedicated instances" — chạy trong VPC thực ra làm build chậm hơn (phải tạo ENI ở mỗi lần chạy, thêm hàng chục giây khởi động). CodeBuild cũng không có khái niệm "dedicated instances".
• D. Batch build với build graph — build graph khai quan hệ phụ thuộc giữa các build trong một batch. Nhưng ở đây bốn hàm không phụ thuộc lẫn nhau, nên không có đồ thị nào cần khai. Nó cũng chỉ giải quyết phần build, không giải quyết phần deploy.

Ghi nhớ

Trong CodePipeline: stage chạy tuần tự, còn action trong cùng stage chạy song song nếu cùng runOrder. Mặc định khi tạo qua Console, mỗi action được gán runOrder tăng dần — nên pipeline sinh tự động rất hay bị tuần tự hoá một cách không cần thiết.

Đáp án

B và E.

• E — Dùng Application Load Balancer phía trước Auto Scaling group.
• B — Dùng CloudFront với Lambda@Edge.

Vì sao đúng

Hai yêu cầu: hiệu năng cao và chi phí tối thiểu, cho ứng dụng phục vụ nội dung tuỳ biến theo thiết bị dựa trên định tuyến theo đường dẫn.

Vì sao ALB (E). Đề nói rõ path-based routing. Đó là tính năng của tầng 7, và trong hai loại load balancer thì chỉ ALB đọc được HTTP để định tuyến theo /mobile/*, /tablet/*, /desktop/*.

Vì sao CloudFront + Lambda@Edge (B). Đây là phần vừa tăng hiệu năng vừa giảm chi phí:

• Cache ở edge ⇒ phần lớn request không chạm tới EC2 ⇒ ít instance hơn, ít phí truyền dữ liệu ra hơn
• Lambda@Edge chạy ngay tại edge location, đọc header User-Agent hoặc CloudFront-Is-Mobile-Viewer để quyết định phục vụ biến thể nào — không cần đi về Region

exports.handler = async (event) => {
  const req = event.Records[0].cf.request;
  const h = req.headers;
  if (h['cloudfront-is-mobile-viewer'] && h['cloudfront-is-mobile-viewer'][0].value === 'true')
    req.uri = '/mobile' + req.uri;
  return req;
};

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

• A. Route 53 traffic flow policies — định tuyến ở tầng DNS, mà DNS không nhìn thấy đường dẫn URL. Không thể định tuyến /mobile/* bằng DNS. Traffic flow cũng có phí chính sách hằng tháng.
• C. Trang tĩnh trên S3 — đề mô tả ứng dụng động, tuỳ biến theo người dùng và chế độ xem, đang chạy trên EC2 có Auto Scaling. S3 chỉ phục vụ nội dung tĩnh, không thay thế được tầng ứng dụng.
• D. Network Load Balancer — NLB làm việc ở tầng 4; nó không đọc được HTTP nên không định tuyến theo đường dẫn được. NLB hợp khi cần thông lượng cực lớn, IP tĩnh, hoặc giao thức không phải HTTP.

Ghi nhớ

Và nhớ: CloudFront tự thêm các header CloudFront-Is-*-Viewer — dùng chúng thay vì tự phân tích User-Agent, vừa chính xác hơn vừa cache hiệu quả hơn.