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

Đáp án

C — Tạo một health check endpoint trong chính ứng dụng web kiểm tra kết nối tới tầng ứng dụng và tầng CSDL, rồi đặt nó làm URL health check của target group.

Vì sao đúng

Yêu cầu là ALB chỉ gửi traffic tới tầng web khi tầng web nói chuyện được với hai tầng phía sau. Nghĩa là health check phải phản ánh sức khoẻ của cả chuỗi phụ thuộc, không chỉ của tiến trình web.

ALB chỉ biết một việc: gọi một URL và xem mã trả về. Nên phần "biết mình có kết nối được xuống dưới không" phải do ứng dụng tự trả lời:

GET /health
  ├─ gọi thử tầng ứng dụng      → hỏng ⇒ trả 503
  ├─ chạy "SELECT 1" xuống RDS  → hỏng ⇒ trả 503
  └─ tất cả ổn                  → trả 200

Đây gọi là deep health check. Nó biến một câu hỏi ALB không trả lời được thành câu hỏi ứng dụng trả lời được.

Có một đánh đổi cần biết: deep health check quá nhạy có thể làm rớt cả fleet khi CSDL trục trặc thoáng qua. Thực tế thường tách hai endpoint — /health nông cho ALB và /health/deep cho hệ thống giám sát — hoặc thêm cache ngắn cho phần kiểm tra phụ thuộc.

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

• A. Đăng ký RDS instance vào target group — không làm được. Target group của ALB nhận EC2 instance, IP, Lambda hoặc ALB khác. RDS không phải target hợp lệ, và ALB cũng không nói được giao thức CSDL.
• B. Route 53 health check + Application Auto Scaling "huỷ ECS và RDS instance không lành" — sai nhiều tầng: Route 53 health check dùng cho định tuyến DNS chứ không cho quyết định của ALB; Application Auto Scaling không huỷ RDS instance; và tự động huỷ CSDL vì một lần health check hỏng là hành vi phá hoại.
• D. Alarm trên số kết nối RDS rồi "cấu hình load balancer coi target là không lành" — ALB không nhận đầu vào từ CloudWatch alarm để đánh dấu target. Cơ chế đơn giản là không tồn tại. Thêm nữa, số kết nối thay đổi là chỉ báo rất gián tiếp, đầy báo động giả.

Ghi nhớ

Đề nói rõ "chỉ gửi traffic nếu nói chuyện được với các tầng khác" thì chọn deep health check.

Đáp án

B và E.

• B — Cấu hình IAM role có vấn đề.
• E — Bucket policy không cấp quyền.

Vì sao đúng

403 Access Denied là lỗi phân quyền, và quyền truy cập S3 được quyết định bởi việc hợp nhất nhiều loại chính sách. Chỉ cần một nơi thiếu Allow, hoặc bất kỳ nơi nào có Deny, là ra 403:

Hai phương án được chọn là hai lớp phổ biến nhất, và cũng là hai lớp bắt buộc phải cùng cho phép khi truy cập bucket có giới hạn.

Một chi tiết dễ quên: instance chạy mà chưa gắn instance profile nào thì aws s3 cp sẽ báo lỗi xác thực chứ không phải 403 — còn gắn role nhưng thiếu quyền mới ra đúng 403.

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

• A. Bật versioning — versioning chỉ giữ nhiều phiên bản của cùng một key. Nó không ảnh hưởng quyền; GetObject không nêu version vẫn lấy bản mới nhất.
• C. Bật default encryption — với SSE-S3 thì hoàn toàn trong suốt. Với SSE-KMS thì có thể ra AccessDenied nếu thiếu kms:Decrypt — nhưng phương án chỉ nói "default encryption is enabled", không nói loại khoá, nên bản thân việc bật mã hoá không phải nguyên nhân. (Đáng nhớ trong thực tế: đây là nguồn 403 rất hay gặp và rất khó đoán.)
• D. Object đã chuyển sang Glacier — lấy object trong lớp lưu trữ Glacier chưa khôi phục sẽ ra InvalidObjectState, không phải 403. Mã lỗi khác hẳn, và đó là dấu hiệu phân biệt.

Ghi nhớ

Chẩn đoán 403 của S3 theo thứ tự: danh tính có quyền chưa → bucket policy có cho không → có Deny ở đâu không (SCP, endpoint policy, Block Public Access) → nếu là SSE-KMS thì có kms:Decrypt chưa. Và nhớ: Deny luôn thắng mọi Allow.

Đáp án

A — Dùng Amazon Cognito user pool cho federated sign-in, thêm SAML IdP và ánh xạ email đăng nhập sang nhà cung cấp tương ứng; lấy token rồi đổi lấy thông tin xác thực AWS.

Vì sao đúng

Đề đòi ba thứ, và chỉ user pool cho đủ cả ba:

Từ khoá phân biệt là "sign up". Đăng ký tài khoản mới là chức năng của user pool — nó lưu hồ sơ người dùng, xác minh email, quản lý mật khẩu, MFA. Identity pool không lưu người dùng nào cả; nó chỉ đổi một danh tính đã được xác thực ở nơi khác lấy thông tin xác thực AWS tạm thời.

Kiến trúc đầy đủ:

Người dùng → SAML IdP → User pool (sign up/sign in, phát JWT)
                            ↓
                     Identity pool → STS → thông tin xác thực AWS tạm thời

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

• B. AWS Directory Service Simple AD — Simple AD là thư mục tương thích Samba dành cho workload trong VPC (join domain cho EC2 Windows), không hỗ trợ liên kết SAML và không phải giải pháp danh tính cho ứng dụng web công khai.
• C. Identity pool cho federated sign-in — đây là bẫy chính, và nó thiếu đúng vế sign up: identity pool không có thư mục người dùng, không đăng ký được, không quản lý mật khẩu. Nó chỉ là bước sau. Ngoài ra AssumeRoleWithWebIdentity dùng cho OIDC; đường SAML tương ứng là AssumeRoleWithSAML.
• D. API Gateway + Lambda authorizer — dựng được cơ chế kiểm token, nhưng vẫn phải có một nơi nào đó quản lý người dùng và phát token — tức là vẫn cần Cognito. Đây là mô tả một phần của giải pháp, không phải giải pháp.

Ghi nhớ

Nhiều ứng dụng cần cả hai, nối tiếp nhau.

Đáp án

A — Bật access log trên load balancer.

Vì sao đúng

Từ khoá là "processing latencies for requests" — số theo từng request, không phải số tổng hợp.

Access log của ALB ghi mỗi request một dòng, và có sẵn ba trường thời gian tách biệt:

Có ba con số này thì tách được ngay độ trễ nằm ở mạng phía trước, ở ứng dụng, hay ở đường trả về. Kèm theo còn có URL, mã trạng thái, IP client, user agent — nên tìm được request cụ thể nào chậm, đường dẫn nào chậm, khách nào bị ảnh hưởng.

Log ghi thẳng vào S3, truy vấn bằng Athena:

SELECT request_url, AVG(target_processing_time) AS tb, COUNT(*) AS so_luot
FROM alb_logs
WHERE target_processing_time > 1
GROUP BY request_url ORDER BY tb DESC LIMIT 20;

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

• B. Cài CloudWatch Agent — agent thu metric và log của hệ điều hành trên instance (CPU, bộ nhớ, đĩa). Nó không thấy được request đi qua ALB, và không cho phân rã độ trễ theo từng request.
• C. Xem CloudWatch metric — có TargetResponseTime, nhưng đó là giá trị tổng hợp (trung bình, p99) theo khoảng thời gian. Nó nói "hệ thống đang chậm", không nói request nào, URL nào, client nào. Đề yêu cầu điều tra báo cáo cụ thể của người dùng, nên cần dữ liệu chi tiết.
• D. CloudTrail — ghi lời gọi API quản trị AWS (tạo, sửa, xoá ALB), không ghi traffic HTTP đi qua ALB. Đây là nhầm lẫn kinh điển: CloudTrail = mặt phẳng điều khiển, access log = mặt phẳng dữ liệu.

Ghi nhớ

Đáp án

A và D.

• A — Dùng Systems Manager để cài và quản lý Amazon Inspector, Patch Manager và CloudWatch Agent trên toàn bộ instance.
• D — Dùng maintenance window + Run Command để lên lịch tác vụ Patch Manager; dùng EventBridge để lên lịch chạy đánh giá Inspector.

Vì sao đúng

Đề đòi cấu hình chuẩn cho hàng trăm instance với hiệu quả vận hành cao nhất — nghĩa là một mặt phẳng điều khiển duy nhất, không phải bốn công cụ rời rạc.

Systems Manager là mặt phẳng đó. Qua SSM Agent (có sẵn trên hầu hết AMI của AWS), nó:

• Cài và cập nhật phần mềm hàng loạt (State Manager association, Distributor)
• Vá hệ điều hành (Patch Manager) — cả Windows lẫn Linux, cùng một cơ chế
• Chạy lệnh trên hàng trăm máy (Run Command), lọc theo tag
• Lên lịch (Maintenance Windows)

Vế A dựng cấu hình chuẩn; vế D đưa nó vào lịch định kỳ. Hai vế bổ sung nhau: một cái cài, một cái chạy đều.

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

• B. "Dùng Inspector để cài và quản lý SSM, OpsWorks và CloudWatch Agent" — đảo ngược quan hệ. Inspector là công cụ đánh giá lỗ hổng; nó không cài đặt gì cả và bản Inspector hiện hành còn phụ thuộc vào SSM Agent chứ không ngược lại.
• C. CloudFormation change set deploy AMI đã vá "tới các EC2 instance đang tồn tại" — CloudFormation không vá được instance đang chạy; muốn dùng AMI mới thì phải thay instance. Với hàng trăm máy đang phục vụ, đây là cách nặng nề nhất, và câu chữ của phương án mô tả một việc CloudFormation không làm.
• E. AWS OpsWorks với custom recipe — OpsWorks (Chef/Puppet quản lý) là công nghệ đã cũ và AWS đã thông báo ngừng dịch vụ. Nó đòi viết và bảo trì recipe — trái hẳn "most operational efficiency" khi Patch Manager làm sẵn.

Ghi nhớ

Ghép đôi cho đúng: Systems Manager = cấu hình và vận hành hạm đội; Inspector = đánh giá lỗ hổng; CloudWatch = log và metric; Config = tuân thủ cấu hình. Câu hỏi "chuẩn hoá cấu hình trên hàng trăm instance" gần như luôn ra Systems Manager.

Đáp án

D và E.

• E — Subscription filter của CloudWatch Logs dùng Kinesis Data Firehose để chuyển toàn bộ log sang S3.
• D — S3 lifecycle policy chuyển sang S3 Glacier sau 90 ngày và hết hạn sau 3.650 ngày.

Vì sao đúng

Hai vế của bài toán:

Vế vận chuyển (E). Cần tự động và liên tục. Subscription filter đẩy log theo thời gian thực sang Firehose, Firehose gom lô và ghi vào S3. Dựng một lần, chạy mãi, không có bước tay nào.

Vế vòng đời (D). Con số khớp chính xác với đề:

• Ít truy cập sau 90 ngày → chuyển sang Glacier (rẻ hơn S3 Standard nhiều lần)
• Giữ 10 năm = 3.650 ngày → Expiration đúng con số đó

{
  "Rules": [{
    "Status": "Enabled",
    "Transitions": [{"Days": 90, "StorageClass": "GLACIER"}],
    "Expiration": {"Days": 3650}
  }]
}

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

• A. CloudWatch Logs export task — CreateExportTask là thao tác thủ công một lần, không tự động; muốn định kỳ thì phải tự viết Lambda và tự lên lịch. Đề đòi "run in an automated fashion". Nó còn có giới hạn: mỗi tài khoản chỉ chạy một export task tại một thời điểm.
• B. Subscription filter dùng DataSync — subscription filter chỉ nhận ba loại đích: Kinesis Data Streams, Kinesis Data Firehose, và Lambda. DataSync không phải đích hợp lệ — nó là dịch vụ đồng bộ tệp giữa on-premises và AWS, không nhận luồng log.
• C. Chuyển sang Reduced Redundancy — RRS đã lỗi thời, AWS không còn khuyến nghị dùng. Nó có độ bền thấp hơn (99,99% thay vì 11 số 9) và nay còn đắt hơn S3 Standard ở nhiều Region. Dùng lớp kém bền hơn cho dữ liệu phải giữ 10 năm vì tuân thủ là lựa chọn sai về bản chất.

Ghi nhớ

Ba đích hợp lệ của subscription filter: Kinesis Data Streams, Firehose, Lambda. Và với dữ liệu lưu trữ dài hạn, chọn lớp theo tần suất truy cập: Glacier Instant (lấy ngay), Glacier Flexible (vài phút–vài giờ), Glacier Deep Archive (12 giờ, rẻ nhất — hợp nhất với dữ liệu tuân thủ 10 năm).

Đáp án

A — Ứng dụng web đẩy dữ liệu vào AWS Step Functions; tách quy trình thành các task của Step Functions và các hàm Lambda.

Vì sao đúng

Vấn đề hiện tại: một bước hỏng là chạy lại toàn bộ. Cần chuyển sang chỉ chạy lại bước hỏng.

Step Functions sinh ra đúng cho việc này. Nó giữ trạng thái của từng bước, nên biết bước nào đã xong và bước nào hỏng:

{
  "StartAt": "Buoc1",
  "States": {
    "Buoc1": {
      "Type": "Task", "Resource": "arn:aws:lambda:...:xu-ly-buoc-1",
      "Retry": [{"ErrorEquals": ["States.TaskFailed"], "MaxAttempts": 3, "BackoffRate": 2}],
      "Catch": [{"ErrorEquals": ["States.ALL"], "Next": "XuLyLoi"}],
      "Next": "Buoc2"
    }
  }
}

Ba thứ có sẵn, không phải viết:

• Retry — thử lại đúng bước đó với exponential backoff
• Catch — rẽ nhánh xử lý lỗi
• Lịch sử thực thi — nhìn thấy chính xác bước nào hỏng, dữ liệu vào/ra là gì

Chi tiết "mỗi bước xong trong 5 phút" cũng khớp: nằm gọn trong trần 15 phút của Lambda.

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

• B. Một SQS queue cho mỗi bước — dựng được, nhưng bạn phải tự viết toàn bộ phần điều phối: bước này xong thì tự đẩy message sang queue kế tiếp, tự quản DLQ cho từng bước, tự ghép lại để biết một đơn hàng đang ở đâu. Không có cái nhìn tổng thể về một lần chạy. Nhiều mã hơn hẳn, nên trượt tiêu chí "MOST operationally efficient".
• C. S3 + event notification + SQS + EC2 — cùng vấn đề với B, cộng thêm EC2 phải tự quản (vá, scale, giám sát). Đi ngược hướng hiện đại hoá.
• D. Một Lambda xử lý toàn bộ dữ liệu — giữ nguyên đúng vấn đề đang cần chữa: hỏng ở bước 4 thì vẫn phải chạy lại từ bước 1. Ngoài ra nhiều bước × 5 phút sẽ vượt trần 15 phút của Lambda.

Ghi nhớ

Chọn theo mức độ liên kết: | Nhu cầu | Công cụ | |---|---| | Quy trình nhiều bước, có trạng thái, cần retry từng bước | Step Functions | | Tách rời hai thành phần, đệm tải | SQS | | Phát tin cho nhiều người nhận | SNS | | Định tuyến sự kiện theo mẫu | EventBridge |

Đáp án

B — Dùng AWS Elastic Disaster Recovery (DRS) để sao chép dữ liệu sang staging subnet ở Region khác, bằng replication agent cài trên EC2 instance.

Vì sao đúng

Ba yêu cầu của đề khớp gần như từng chữ với mô tả của DRS:

Cơ chế: agent cài trên máy nguồn sao chép liên tục ở mức khối sang các instance staging cỡ nhỏ, giá rẻ ở Region đích. Khi cần, DRS dựng instance đúng cỡ production từ dữ liệu đã sao chép — RPO tính bằng giây, RTO tính bằng phút.

Điểm mạnh mà đề nhấn: failback. Rất nhiều giải pháp DR chỉ lo chiều đi; quay về Region gốc sau sự cố mới là phần đau đớn. DRS làm cả hai chiều bằng cùng một cơ chế.

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

• A. AWS RAM chia sẻ VPC + DataSync — RAM không chia sẻ VPC xuyên Region (chia sẻ subnet chỉ trong cùng Region, giữa các tài khoản trong tổ chức). DataSync đồng bộ tệp, không sao chép toàn bộ máy chủ — nên khôi phục xong bạn có dữ liệu nhưng không có máy chạy.
• C. AWS Resilience Hub — Resilience Hub đánh giá và theo dõi khả năng phục hồi: bạn khai RTO/RPO mục tiêu, nó chấm điểm kiến trúc và khuyến nghị. Nó không sao chép dữ liệu và không thực hiện failover. Đây là công cụ đo, không phải công cụ làm.
• D. AWS Backup cross-Region + Fault Injection Simulator — AWS Backup chụp snapshot định kỳ, nên RPO bằng khoảng cách giữa hai lần chụp (thường hàng giờ) và khôi phục chậm — không đạt "fast failover". FIS là công cụ kỹ thuật hỗn loạn dùng để gây lỗi có kiểm soát nhằm kiểm thử, không phải cơ chế khôi phục tự động. Câu này ghép sai chức năng.

Ghi nhớ

Đáp án

C — Tạo alias trỏ vào phiên bản hiện tại; publish phiên bản mới, thêm nó vào alias và đặt trọng số 10%.

Vì sao đúng

Ràng buộc mấu chốt: không được sửa ứng dụng trên EC2. Nghĩa là địa chỉ mà EC2 gọi phải giữ nguyên — và đó chính là lý do alias tồn tại.

Alias của Lambda là một ARN cố định trỏ vào một (hoặc hai) phiên bản. Ứng dụng gọi alias; bạn đổi phiên bản phía sau alias mà bên gọi không biết gì.

Weighted alias cho phép trỏ vào hai phiên bản cùng lúc với trọng số:

aws lambda update-alias --function-name xu-ly --name prod \
  --function-version 1 \
  --routing-config AdditionalVersionWeights={"2"=0.1}   # 10% sang bản 2

Ba yêu cầu được đáp ứng gọn:

• Không sửa EC2 — ARN alias không đổi
• Thử với một phần traffic — trọng số 0.1
• Rollback — đặt trọng số về 0, có hiệu lực gần như tức thì

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

• A. Route 53 weighted record — Route 53 định tuyến DNS, còn EC2 gọi Lambda qua API Invoke với ARN, không qua tên miền. Cơ chế không áp dụng được. Và phương án còn nói "Modify the application" — vi phạm thẳng ràng buộc.
• B. Lambda layer cho các phiên bản mã — hiểu sai layer. Layer chứa thư viện và phụ thuộc dùng chung, không phải cơ chế phiên bản hoá mã ứng dụng, và alias không trỏ vào layer — alias trỏ vào version của hàm.
• D. Hai hàm riêng biệt, hai alias cùng tên — alias là tài nguyên con của một hàm cụ thể; ARN của nó bao gồm tên hàm. Hai alias trùng tên trên hai hàm khác nhau vẫn là hai ARN khác nhau, nên EC2 vẫn phải đổi địa chỉ gọi. Không giải quyết được ràng buộc.

Ghi nhớ

Weighted alias là cách canary rẻ nhất cho Lambda; muốn tự động hoá cả việc rollback theo alarm thì dùng thêm SAM DeploymentPreference.

Đáp án

B — Bật Amazon GuardDuty cho toàn tổ chức, chỉ định một tài khoản làm GuardDuty administrator, rồi tạo rule trong tài khoản đó để chuyển phát hiện về nơi tập trung.

Vì sao đúng

Hai yêu cầu: phát hiện tấn công lên EC2 và gom mọi phát hiện về một tài khoản bảo mật trung tâm.

GuardDuty là dịch vụ phát hiện mối đe doạ của AWS. Với EC2 nó đọc VPC Flow Logs, DNS logs, CloudTrail (và EBS malware scanning nếu bật) để nhận ra: instance liên lạc với máy chủ C2 đã biết, đào tiền mã hoá, bị quét cổng, thông tin xác thực EC2 bị dùng từ ngoài AWS…

Về vế tập trung, GuardDuty có mô hình administrator/member tích hợp AWS Organizations:

• Chỉ định delegated administrator ở cấp tổ chức
• Bật auto-enable thì mọi tài khoản mới tự động được bật GuardDuty và tự thành member
• Toàn bộ phát hiện chảy về tài khoản administrator, xem ở một chỗ

Phần còn lại — EventBridge bắt sự kiện GuardDuty Finding rồi đẩy đi — chỉ là chuyển tiếp.

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

• A. Có GuardDuty và có administrator account, nhưng thiếu vế liên kết qua Organizations. Bật từng tài khoản một và mời từng member là cách làm thủ công; tài khoản mới sinh ra sẽ không tự được bảo vệ — đúng lỗ hổng mà kiểm toán đang cảnh báo.
• C. Amazon Inspector — Inspector quét lỗ hổng phần mềm và phơi nhiễm mạng, tức là "điểm yếu có thể bị khai thác". Nó không phát hiện tấn công đang diễn ra. Đề nói rõ "detect the attacks".
• D. Amazon Macie — Macie phân loại và bảo vệ dữ liệu nhạy cảm trong S3 (số thẻ, thông tin cá nhân). Nó không nhìn EC2 chút nào. Sai đối tượng hoàn toàn.

Ghi nhớ

Bảng phân vai bảo mật của AWS, cần thuộc: | Dịch vụ | Phát hiện gì | |---|---| | GuardDuty | mối đe doạ, hành vi tấn công | | Inspector | lỗ hổng phần mềm, phơi nhiễm mạng | | Macie | dữ liệu nhạy cảm trong S3 | | Security Hub | gom phát hiện từ cả ba, chấm theo khung chuẩn | | Detective | điều tra sâu sau khi có phát hiện |