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

Đáp án

D — Một pipeline CodePipeline duy nhất, triển khai song song bằng một CodeDeploy application với deployment group riêng cho từng cặp ALB + ASG.

Vì sao đúng

Bài toán: nhiều cặp ALB + ASG, cần deploy đồng thời tới tất cả, với ít cấu hình nhất.

Mô hình phân cấp của CodeDeploy trả lời trực tiếp:

CodeDeploy application "ung-dung-web"      ← MỘT ứng dụng
 ├── deployment group "cum-1"  → ALB-1 + ASG-1
 ├── deployment group "cum-2"  → ALB-2 + ASG-2
 └── deployment group "cum-3"  → ALB-3 + ASG-3

Application đại diện cho phần mềm; deployment group đại diện cho một tập hạ tầng cụ thể. Cùng một ứng dụng nên chỉ cần một application — đó là vế "least configuration".

Deployment group phải tách riêng vì mỗi cặp có ALB và ASG khác nhau, mà một deployment group chỉ gắn được với một cấu hình load balancer.

Chạy song song đạt được bằng cách đặt các action cùng runOrder trong một stage của pipeline.

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

• A. Nhiều CodeDeploy application riêng cho mỗi cặp — thừa: bạn đang deploy cùng một ứng dụng. Mỗi application mới là thêm một bộ cấu hình, thêm một chỗ để lệch nhau khi sửa. Nhiều cấu hình hơn D mà không được gì.
• B. Mỗi cặp một pipeline riêng — nhiều cấu hình nhất trong bốn phương án: n pipeline, n source action, n trigger. Và không còn deploy đồng thời một cách phối hợp — n pipeline chạy độc lập, không có điểm nào biết tổng thể đã xong hay chưa.
• C. Một deployment group chứa tất cả ALB và ASG — nghe gọn nhất nhưng không làm được: một deployment group chỉ cấu hình được một load balancer (hoặc một target group) cho việc gỡ/đăng ký instance trong lúc deploy. Không có cách nào khai ba ALB khác nhau vào một group.

Ghi nhớ

Phân cấp của CodeDeploy: application (phần mềm) → deployment group (môi trường/tập hạ tầng) → deployment (một lần chạy). Quy tắc thực dụng: một application cho một ứng dụng, một deployment group cho mỗi môi trường hoặc mỗi cụm hạ tầng riêng biệt.

Đáp án

A và C.

• C — Đặt DeletionPolicy: Retain cho AWS::RDS::DBInstance.
• A — Đặt DeletionPolicy: Snapshot cho volume EBS gắn với EC2.

Vì sao đúng

Đề nêu hai vấn đề khác nhau, và mỗi vấn đề cần một giá trị DeletionPolicy khác nhau — đó chính là điểm hay của câu hỏi.

Vấn đề 1 — RDS bị tạo lại khi đổi instance class, mất dữ liệu (C).

CoSoDuLieu:
  Type: AWS::RDS::DBInstance
  DeletionPolicy: Retain          # giữ nguyên, không xoá
  UpdateReplacePolicy: Retain     # nên khai thêm — cho trường hợp bị THAY THẾ

Với Retain, khi CloudFormation cần thay thế tài nguyên, nó bỏ quản lý chứ không xoá — dữ liệu còn nguyên.

Vấn đề 2 — cần giữ snapshot EBS khi xoá stack, để sao lưu và tuân thủ (A).

OD:
  Type: AWS::EC2::Volume
  DeletionPolicy: Snapshot        # chụp ảnh trước khi xoá

Đề nói rõ "mandatory to keep a snapshot" — chính là Snapshot, không phải Retain.

Điểm cần phân biệt cho rõ: Snapshot vẫn XOÁ tài nguyên gốc, chỉ giữ lại một bản chụp. Retain thì giữ nguyên vật.

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

• B. Stack policy chặn cập nhật + trò xoay quanh SetStackPolicy — stack policy có chặn được việc cập nhật một tài nguyên, nhưng cách đó chặn cả những cập nhật hợp lệ và không giải quyết được vế snapshot EBS. Vế "chỉ cấp UpdateStack cho principal bị từ chối SetStackPolicy" là một cấu trúc rối rắm không cần thiết.
• D. Đặt thuộc tính DBInstanceClass thành "read-only" — không có khái niệm này. Thuộc tính của tài nguyên CloudFormation không có cờ read-only; muốn chặn thay đổi thì dùng stack policy hoặc IAM.
• E. Bật termination protection cho EC2 và RDS — chỉ chặn lời gọi xoá thủ công. Nó không ngăn CloudFormation thay thế tài nguyên khi một thuộc tính đòi replacement, và không tạo snapshot nào. Thực tế còn gây rắc rối: xoá stack sẽ thất bại giữa chừng và để lại stack ở trạng thái DELETE_FAILED.

Ghi nhớ

Rất nhiều người chỉ khai DeletionPolicy rồi vẫn mất dữ liệu — vì tình huống trong đề (đổi instance class) là replacement, không phải deletion. Khai cả hai.

Đáp án

C — Dùng EventBridge theo lịch gọi một Lambda chạy lệnh RefreshCache.

Vì sao đúng

Đây là một giới hạn quan trọng và rất hay bị hỏi về File Gateway của AWS Storage Gateway.

File Gateway giữ một bộ nhớ đệm cục bộ về siêu dữ liệu (metadata cache) — danh sách tệp và thuộc tính của chúng. Cache này chỉ được cập nhật khi:

• Có thao tác đi qua chính gateway, hoặc
• Có ai đó gọi RefreshCache

Khi batch job ghi thẳng vào S3 bucket (bỏ qua gateway), gateway không hề biết. Tệp có thật trong S3 nhưng không xuất hiện trong danh sách thư mục ở phía người dùng — đúng triệu chứng đề mô tả.

Lịch chạy nên khớp với lịch batch — ví dụ 5 giờ sáng, sau khi job đêm đã xong:

aws storagegateway refresh-cache --file-share-arn <arn> \
  --folder-list "/" --recursive

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

• A. S3 Transfer Acceleration — chỉ tăng tốc độ tải lên cho client ở xa bằng cách đi qua edge location của CloudFront. Tệp đã lên tới S3 rồi (đề nói rõ chúng tồn tại trong bucket); vấn đề hoàn toàn không nằm ở tốc độ.
• B. S3 same-Region replication "để sao chép thay đổi sang Storage Gateway" — hiểu sai kiến trúc: Storage Gateway không phải đích của replication. Nó là một cửa sổ nhìn vào bucket, không phải một bản sao độc lập. Sao chép sang một bucket khác cũng không cập nhật cache của gateway.
• D. Chuyển sang Cached Volume Gateway + S3 event notification — sai loại gateway. Volume Gateway phơi bày ổ đĩa khối (iSCSI), không phơi bày tệp; nó lưu dữ liệu ở định dạng riêng và không cho bạn truy cập object trong S3 như tệp. Đổi sang nó là mất hẳn khả năng "batch job ghi vào S3, người dùng đọc như tệp".

Ghi nhớ

Ba loại Storage Gateway: | Loại | Phơi bày | Dữ liệu trong S3 | |---|---|---| | File Gateway | NFS/SMB | object đọc được trực tiếp | | Volume Gateway | iSCSI (khối) | định dạng riêng, không đọc trực tiếp | | Tape Gateway | VTL | archive |

Và nhớ dứt khoát: ghi thẳng vào bucket thì phải gọi RefreshCache, nếu không File Gateway sẽ không bao giờ thấy tệp mới. Cách hiện đại hơn là dùng S3 event notification kích hoạt RefreshCache ngay khi có object mới, thay vì chạy theo lịch.

Đáp án

D — Khi bật secret rotation, Secrets Manager xoay vòng ngay lần đầu tiên lúc bạn lưu bí mật, dẫn tới việc thông tin đăng nhập cũ không còn dùng được.

Vì sao đúng

Ba manh mối trong đề khoanh vùng rất chặt:

1. Phiên bản trước chạy được
2. Không có thay đổi nào ở CSDL
3. Lỗi là kết nối CSDL

Nghĩa là thứ thay đổi không phải CSDL, mà là thông tin đăng nhập. Và Secrets Manager có một hành vi ít người biết: bật rotation là nó xoay vòng ngay lập tức một lần, không chờ tới chu kỳ đầu tiên.

Hậu quả điển hình: mật khẩu trong CSDL đã đổi, nhưng ứng dụng đang cache giá trị cũ — hoặc tệ hơn, đang gọi GetSecretValue với một version stage cũ. Kết quả là lỗi xác thực trong khi cả ứng dụng lẫn CSDL đều "không có gì thay đổi".

Cách phòng: luôn đọc bí mật ở stage AWSCURRENT, và khi lỗi xác thực thì đọc lại bí mật rồi thử lại thay vì dùng giá trị đã cache:

val = sm.get_secret_value(SecretId='prod/db', VersionStage='AWSCURRENT')

Secrets Manager dùng bốn staging label: AWSCURRENT (đang dùng), AWSPENDING (sắp áp dụng), AWSPREVIOUS (bản trước), và nhãn tuỳ chỉnh. Ứng dụng luôn phải bám vào AWSCURRENT.

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

• A. GetSecretValue không nêu version — không nêu version là hành vi ĐÚNG: khi ấy Secrets Manager trả về bản mang nhãn AWSCURRENT, tức là bản mới nhất đang hiệu lực. Không nêu version mới là cách dùng khuyến nghị.
• B. Thiếu quyền secretsmanager:DescribeSecret — quyền cần để đọc giá trị là secretsmanager:GetSecretValue. DescribeSecret chỉ trả về siêu dữ liệu (tên, mô tả, lịch rotation), không trả về giá trị. Và thiếu quyền sẽ cho lỗi AccessDenied rõ ràng, không phải lỗi kết nối CSDL.
• C. Bí mật mã hoá bằng KMS key mặc định, ứng dụng ở tài khoản khác — tình huống này có thật và có gây lỗi, nhưng nó mâu thuẫn với đề: nếu cấu hình chéo tài khoản sai thì phiên bản trước cũng đã không chạy được. Đề nói rõ bản đầu tiên hoạt động bình thường.

Ghi nhớ

Hai điều cần thuộc về Secrets Manager rotation:

1. Bật rotation là xoay vòng ngay lập tức — đừng bật lần đầu vào giờ cao điểm.
2. Đừng cache bí mật vô thời hạn. Cache có TTL ngắn, và luôn đọc lại rồi thử lại khi gặp lỗi xác thực — đó là cách duy nhất để ứng dụng sống sót qua mỗi lần xoay vòng.

Đáp án

B và C.

• C — Chuyển workload container sang Amazon ECS với Fargate launch type trong một VPC riêng.
• B — Dùng AWS Managed VPN để mã hoá lưu lượng giữa trung tâm dữ liệu và VPC.

Vì sao đúng

Hai yêu cầu, hai câu trả lời:

Vế "ít gánh nặng quản lý nhất" (C). Ứng dụng đã chạy trên Docker, nên lựa chọn nằm giữa ECS trên EC2 và ECS trên Fargate:

Fargate thắng dứt khoát ở tiêu chí "minimal management overhead".

Vế "kết nối mã hoá tới on-premises" (B). Site-to-Site VPN tạo đường hầm IPsec mã hoá qua Internet công cộng, thiết lập nhanh và không cần hạ tầng vật lý mới. Đây là câu trả lời chuẩn cho "encrypted communications between the data center and AWS".

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

• D. ECS với EC2 launch type — làm được nhưng bạn phải tự quản cụm EC2: vá hệ điều hành, vá ECS agent, tính dung lượng cluster, xử lý instance hỏng. Trái thẳng yêu cầu.
• A. NLB với IP target và HTTPS listener — sai hai chỗ: NLB không có HTTPS listener (nó có TLS listener ở tầng 4; HTTPS là khái niệm của ALB ở tầng 7). Và một load balancer không tạo kết nối tới trung tâm dữ liệu — nó nhận kết nối đến, không phải cơ chế kết nối lai.
• E. VPC endpoint để truy cập ECS — VPC endpoint cho phép tài nguyên trong VPC gọi API của AWS mà không ra Internet. Nó không nối trung tâm dữ liệu với AWS, nên không đáp ứng vế kết nối lai.

Ghi nhớ

Chi tiết hay bị hỏi: Direct Connect KHÔNG mã hoá dữ liệu mặc định — nó chỉ là đường truyền riêng. Đề nêu "encrypted communications" thì luôn là VPN, hoặc VPN chạy trên Direct Connect.

Đáp án

D — Mọi hành động phê duyệt bị từ chối hoặc thất bại trên tất cả pipeline.

Vì sao đúng

Đọc từng dòng của event pattern trong đề:

{
  "source": ["aws.codepipeline"],
  "detail-type": ["CodePipeline Action Execution State Change"],   ← mức ACTION
  "detail": {
    "state": ["FAILED"],                                            ← trạng thái thất bại
    "type": { "category": ["Approval"] }                            ← chỉ action loại Approval
  }
}

Ba điều kiện kết hợp lại:

Và điểm cuối cùng: với manual approval, khi người duyệt bấm Reject, CodePipeline ghi nhận action ở trạng thái FAILED. Nên pattern này bắt được cả trường hợp bị từ chối lẫn trường hợp thất bại — đúng như phương án D mô tả.

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

• A. "Deploy và build action thất bại trên mọi pipeline" — bộ lọc "category": ["Approval"] loại thẳng action loại Deploy và Build. Chỉ approval mới khớp.
• B. "Approval action bị abandoned hoặc cancelled" — pattern chỉ khớp state = FAILED. Các trạng thái khác như CANCELED hay ABANDONED không khớp, nên chúng sẽ không kích hoạt rule.
• C. "Sự kiện thất bại ở mức stage" — sai detail-type. Sự kiện mức stage có detail-type là CodePipeline Stage Execution State Change, còn pattern trong đề dùng Action. Đây là điểm phân biệt then chốt: CodePipeline phát ba mức sự kiện khác nhau.

Ghi nhớ

Ba detail-type của CodePipeline, đi từ rộng tới hẹp: | detail-type | Phạm vi | |---|---| | CodePipeline Pipeline Execution State Change | cả pipeline | | CodePipeline Stage Execution State Change | một stage | | CodePipeline Action Execution State Change | một action — có type.category để lọc theo loại |

Và nhớ: không khai trường nào trong detail thì trường đó khớp mọi giá trị. Pattern trong đề không nêu tên pipeline, nên nó bắt tất cả — đó là lý do các phương án đúng đều có cụm "across all the pipelines".

Đáp án

D — Tạo CloudWatch alarm cho metric StatusCheckFailed_System và chọn hành động recover instance.

Vì sao đúng

Đề nêu hai loại sự cố cụ thể: mất kết nối mạng và mất điện ở máy chủ vật lý. Cả hai đều là hỏng ở tầng hạ tầng AWS, không phải hỏng bên trong hệ điều hành.

EC2 có hai status check, và chúng phân biệt đúng theo ranh giới đó:

Hành động recover làm đúng thứ cần: khởi động lại instance trên phần cứng vật lý khác, đồng thời giữ nguyên:

• Instance ID
• Địa chỉ IP riêng và IP công khai (Elastic IP)
• Toàn bộ EBS volume và dữ liệu trên đó
• Siêu dữ liệu và cấu hình mạng

Đó chính là "phục hồi nhanh, mất dữ liệu tối thiểu" mà đề yêu cầu.

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

• A. Alarm StatusCheckFailed_Instance + reboot — bẫy đối xứng. Reboot giữ instance trên đúng máy chủ vật lý đang hỏng; với sự cố mất điện hoặc hỏng mạng ở tầng hạ tầng, reboot không giải quyết được gì.
• B. Auto Scaling group với min = max = desired = 1 — có thay được instance khi nó chết, nhưng máy mới được tạo từ launch template, tức là một instance hoàn toàn mới với EBS volume mới rỗng. Ứng dụng legacy với dữ liệu trên EBS sẽ mất sạch dữ liệu — vi phạm thẳng "minimal data losses".
• C. Spread placement group + auto recovery — spread placement group đặt các instance trên các phần cứng khác nhau để một sự cố phần cứng không hạ nhiều máy cùng lúc. Nhưng đây chỉ có một instance duy nhất, nên placement group không mang lại lợi ích nào. Vế "auto recovery" thì đúng, nhưng phần đầu là thừa và gây nhiễu.

Ghi nhớ

Recover là lựa chọn duy nhất vừa đổi được phần cứng vừa giữ nguyên địa chỉ — đó là lý do nó tồn tại. (Ngày nay EC2 còn có automatic recovery mặc định cho hầu hết instance type, không cần tự tạo alarm — nhưng biết cơ chế alarm vẫn cần cho đề thi và cho các cấu hình đặc biệt.)

Đáp án

A — Nhúng thông tin từ AWS Health API vào pipeline CI/CD bằng Lambda, để tự động dừng triển khai khi có sự kiện AWS Health được báo trong Region đó.

Vì sao đúng

Nguyên nhân gốc của sự cố: pipeline hoàn toàn mù trước tình trạng sức khoẻ của chính AWS. Nó bắt đầu nâng cấp CSDL trong khi Region đang có sự cố theo lịch, và mắc kẹt giữa chừng — trạng thái nguy hiểm nhất cho một lần nâng cấp CSDL.

AWS Health API là nguồn dữ liệu chính thức về:

• Sự kiện theo lịch (bảo trì, retirement) — biết trước hàng ngày
• Sự cố đang diễn ra ảnh hưởng tới Region hoặc dịch vụ bạn dùng
• Tài nguyên bị ảnh hưởng trong chính tài khoản bạn

Thêm một stage kiểm tra trước khi deploy:

def handler(event, context):
    health = boto3.client('health', region_name='us-east-1')  # API toàn cầu
    su_kien = health.describe_events(filter={
        'regions': ['ap-southeast-1'],
        'eventStatusCodes': ['open', 'upcoming'],
        'services': ['RDS']})
    if su_kien['events']:
        codepipeline.put_job_failure_result(...)   # dừng pipeline
    else:
        codepipeline.put_job_success_result(...)

Vế "không gây gián đoạn" cũng được thoả: pipeline không bao giờ bắt đầu thay vì bị kẹt giữa chừng. Dừng trước khi động vào CSDL an toàn hơn dừng ở giữa một cuộc nâng cấp rất nhiều.

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

• B. CSDL thứ hai, nâng cấp bản passive rồi chuyển đổi — đây là một cải tiến kiến trúc tốt (blue/green cho CSDL), nhưng không giải quyết vấn đề đã nêu: nếu Region đang có sự cố, thao tác trên CSDL passive cũng có thể mắc kẹt y hệt. Nó cũng tốn kém và là thay đổi kiến trúc lớn.
• C. Thêm stage tự chạy lại pipeline — nguy hiểm với nâng cấp CSDL: chạy lại một quá trình đã dừng giữa chừng có thể áp dụng migration hai lần hoặc chạy trên lược đồ đã ở trạng thái nửa vời. Nó cũng không biết Region còn đang hỏng hay không, nên rất dễ lặp vô hạn.
• D. Lên lịch nâng cấp để tránh các đợt bảo trì đã công bố — chỉ tránh được sự cố theo lịch, hoàn toàn không bảo vệ trước sự cố ngoài dự kiến. Nó cũng là công việc thủ công phải theo dõi mãi, trong khi Health API cho biết cùng thông tin đó một cách tự động.

Ghi nhớ

Hai lưu ý kỹ thuật: Health API đòi gói hỗ trợ Business trở lên, và endpoint của nó nằm ở us-east-1. Ngoài ra sự kiện Health cũng chảy vào EventBridge với nguồn aws.health, nên có thể phản ứng theo sự kiện thay vì hỏi định kỳ.

Đáp án

C và D.

• D — Tạo CloudFront distribution với ALB làm origin, cấu hình tên miền tuỳ chỉnh và gắn chứng chỉ SSL/TLS.
• C — Tạo WAF web ACL và gắn vào CloudFront distribution.

Vì sao đúng

Bốn yêu cầu, và thứ tự các quyết định rất rõ:

Vì sao origin phải là ALB, không phải Auto Scaling group (D vs B). CloudFront cần một endpoint có thể phân giải bằng DNS làm origin. Auto Scaling group không có endpoint; nó chỉ là một tập instance thay đổi liên tục. ALB mới là thứ có tên miền ổn định. Đây là điểm loại của phương án B.

Vì sao WAF gắn vào CloudFront, không phải ALB (C vs E). Cả hai đều gắn được, nhưng gắn ở CloudFront tốt hơn hẳn:

• Chặn ngay tại edge, gần người tấn công nhất — request độc hại không bao giờ tới Region
• Giảm tải và giảm chi phí cho origin
• Bảo vệ luôn cả nội dung được cache

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

• A. WAF "kiểm tra Auto Scaling group" — không làm được. WAF chỉ gắn được vào CloudFront, ALB, API Gateway, AppSync và Cognito user pool. Auto Scaling group không nằm trong danh sách.
• B. CloudFront với Auto Scaling group làm origin — như phân tích ở trên, ASG không phải origin hợp lệ.
• E. WAF gắn vào ALB — hợp lệ về kỹ thuật, nhưng kém hơn C: traffic độc hại phải đi hết đường tới Region mới bị chặn, tốn băng thông và không bảo vệ được tầng cache.

Ghi nhớ

Thứ tự phòng thủ chuẩn cho ứng dụng web toàn cầu:

Người dùng → Route 53 → CloudFront (+ Shield + WAF) → ALB → EC2
                          ↑ chặn ở đây, càng sớm càng tốt

Và nhớ chi tiết hay bị hỏi: chứng chỉ ACM cho CloudFront bắt buộc phải cấp ở us-east-1, bất kể ứng dụng chạy ở Region nào.

Đáp án

A — Tạo bảng trong Amazon DynamoDB và bật global tables ở cả bốn Region.

Vì sao đúng

Yêu cầu quyết định: người dùng ở mỗi Region phải ghi được và đọc được với độ trễ thấp nhất.

DynamoDB Global Tables là dịch vụ duy nhất trong bốn phương án cho multi-active: mọi Region đều nhận cả đọc lẫn ghi, sao chép ngầm giữa các Region thường dưới một giây.

Điểm cần biết về mô hình nhất quán: Global Tables dùng last-writer-wins để giải quyết xung đột. Với ứng dụng "người dùng gửi dữ liệu của chính mình" như đề mô tả, điều đó hoàn toàn ổn — hai Region hiếm khi ghi cùng một item.

DynamoDB cũng phù hợp với quy mô "hàng triệu người dùng": độ trễ mili số một chữ số, tự co giãn, không có máy chủ nào phải quản.

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

• D. RDS với read replica ở ba Region còn lại — bẫy chính. Read replica chỉ đọc; mọi lệnh ghi vẫn phải đi về Region chứa primary. Người dùng ở Tokyo ghi dữ liệu sẽ phải chờ một vòng tới Bắc Mỹ — trượt thẳng yêu cầu "lowest latency of reads and writes".
• C. ElastiCache for Redis với replication group ở bốn Region — hai vấn đề. ElastiCache là cache trong bộ nhớ, không phải kho lưu trữ bền vững cho dữ liệu người dùng gửi lên. Và Global Datastore của Redis là mô hình một Region chính ghi, các Region khác chỉ đọc — cùng hạn chế với read replica.
• B. DocumentDB ở mỗi Region — bốn cụm hoàn toàn độc lập, không có cơ chế sao chép tự động giữa chúng. Người dùng ở Region này không đọc được dữ liệu ghi ở Region kia, trái thẳng yêu cầu "data can be read through the application layer in each Region". (DocumentDB có global cluster, nhưng cũng là mô hình một writer.)

Ghi nhớ

Danh sách rất ngắn các dịch vụ AWS cho ghi được ở nhiều Region: | Dịch vụ | Mô hình | |---|---| | DynamoDB Global Tables | multi-active, last-writer-wins | | S3 Multi-Region Access Points | multi-active cho object | | Aurora Global Database | một writer, các Region khác chỉ đọc | | RDS read replica | một writer |

Từ khoá "lowest latency of reads AND writes" ở nhiều Region gần như luôn dẫn tới DynamoDB Global Tables.