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

Đáp án

A và D.

• A — Event notification đã bị xoá khỏi bucket S3.
• D — Resource-based policy đã bị gỡ khỏi hàm Lambda.

Vì sao đúng

Để S3 gọi được Lambda, cần hai cấu hình ở hai nơi khác nhau — và đây chính là chỗ dễ hỏng nhất:

Xoá bất kỳ cái nào thì hàm im lặng không được gọi nữa — không có lỗi ở đâu cả, đúng triệu chứng đề mô tả.

Kiểm tra cả hai:

aws s3api get-bucket-notification-configuration --bucket kho-anh
aws lambda get-policy --function-name xu-ly-anh

Chi tiết đáng chú ý: khi cấu hình qua Console, AWS tự thêm cả hai nên người dùng không biết chúng tồn tại riêng biệt. Nhưng chúng là hai tài nguyên độc lập — một script dọn dẹp IAM hoặc một lần deploy CloudFormation ghi đè policy của hàm là đủ để phá vỡ liên kết.

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

• B. Execution role của hàm thiếu quyền — bẫy chính, và cần phân biệt kỹ. Execution role quyết định hàm làm được gì sau khi đã chạy; nó không quyết định hàm có được gọi hay không. Thiếu quyền ở đó thì hàm vẫn được gọi rồi thất bại bên trong, và bạn sẽ thấy lỗi trong CloudWatch Logs. Đề nói hàm "no longer being invoked" — không được gọi chút nào.
• C. Bucket không cho truy cập công khai — truy cập công khai chẳng liên quan gì tới event notification. S3 gọi Lambda bằng danh tính dịch vụ của chính nó, không qua đường công khai.
• E. Bật default encryption — với SSE-S3 hay SSE-KMS thì event notification vẫn phát bình thường. (Với SSE-KMS, hàm có thể thất bại khi đọc object nếu thiếu kms:Decrypt — nhưng đó lại là "được gọi rồi lỗi", không phải "không được gọi".)

Ghi nhớ

Phân biệt hai loại policy của Lambda — bị nhầm rất thường xuyên: | Loại | Trả lời câu hỏi | |---|---| | Resource-based policy | AI được phép GỌI hàm này? | | Execution role | Hàm này được phép LÀM GÌ? |

"Hàm không được gọi" ⇒ nghi resource-based policy hoặc cấu hình trigger. "Hàm chạy rồi lỗi" ⇒ nghi execution role.

Đáp án

A — Bật S3 server access logging, dùng Athena tạo external table trên log và truy vấn bằng SQL.

Vì sao đúng

Đề cần biết, theo từng ngày: bao nhiêu người dùng truy cập từng video và bao nhiêu lượt request cho từng file.

Server access logging ghi mỗi request một dòng với đúng những trường cần thiết:

Athena truy vấn thẳng trên S3, không dựng gì:

SELECT key,
       date_parse(substr(requestdatetime,1,11),'%d/%b/%Y') AS ngay,
       COUNT(*) AS luot_truy_cap,
       COUNT(DISTINCT requester) AS so_nguoi_dung
FROM s3_access_logs
WHERE operation = 'REST.GET.OBJECT'
GROUP BY key, date_parse(substr(requestdatetime,1,11),'%d/%b/%Y')
ORDER BY luot_truy_cap DESC;

Bản thân việc ghi log không mất phí, chỉ trả tiền lưu trữ; Athena tính theo dữ liệu quét.

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

• B. Nạp log vào Redshift — cho ra cùng kết quả nhưng đòi một cụm Redshift chạy liên tục cộng với một đường ống nạp dữ liệu. Đắt hơn và chậm triển khai hơn nhiều so với việc chỉ tạo một external table.
• C. Event notification cho mọi sự kiện truy cập object → Lambda → Redshift — nhầm về khả năng của S3: event notification không phát cho GetObject. Nó chỉ phát cho các sự kiện thay đổi (s3:ObjectCreated:*, s3:ObjectRemoved:*, s3:ObjectRestore:*…). Không có cách nào bắt lượt đọc bằng cơ chế này.
• D. "Bật logging của bucket S3 ra CloudWatch Logs" — không có tích hợp này. S3 server access log ghi ra một bucket S3 khác; muốn vào CloudWatch Logs thì phải tự dựng đường ống. Phương án mô tả một tính năng không tồn tại.

Ghi nhớ

Hai cách ghi lại truy cập S3: | | Server access logging | CloudTrail data events | |---|---|---| | Chi phí | miễn phí (chỉ trả lưu trữ) | tính tiền theo sự kiện | | Độ trễ | vài giờ | vài phút | | Định dạng | text | JSON, có nhiều ngữ cảnh IAM hơn | | Hợp cho | phân tích mẫu truy cập | kiểm toán bảo mật |

Và nhớ dứt khoát: S3 event notification không bắt lượt đọc.

Đáp án

C — Thêm lambda.amazonaws.com vào trust relationship của IAM execution role mà CloudWatch Logs tạo ra cho hàm Lambda của subscription filter.

Vì sao đúng

Điều nhiều người không biết: CloudWatch Logs không ghi thẳng vào OpenSearch. Khi bạn tạo một "OpenSearch subscription filter" qua Console, AWS tự sinh một hàm Lambda trung gian (LogsToElasticsearch_<ten-domain>) cùng với một IAM role cho nó. Đường đi thực tế là:

CloudWatch Logs → subscription filter → Lambda (do AWS sinh) → OpenSearch trong VPC

Hàm Lambda đó chỉ chạy được khi trust policy của role cho phép chính dịch vụ Lambda assume:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "lambda.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}

Thiếu dòng này thì hàm không bao giờ khởi chạy được, và triệu chứng đúng như đề: filter đã tạo, không báo lỗi ở đâu, mà log không bao giờ xuất hiện trong OpenSearch.

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

• B. Chữ nghĩa gần như trùng C nhưng nói về "IAM execution role của AWS Lambda function" một cách chung chung, không phải role cụ thể mà CloudWatch Logs tạo cho luồng này. Trong bối cảnh đề, C mô tả chính xác tài nguyên cần sửa.
• A. Tạo export task rồi tích hợp vào OpenSearch — CreateExportTask là thao tác thủ công, một lần, xuất ra S3. Nó không phải cơ chế streaming, và không có tích hợp trực tiếp nào từ export task vào OpenSearch.
• D. Gắn policy AWSLambdaVPCAccessExecutionRole vào Amazon OpenSearch — sai đối tượng: policy này dành cho role của hàm Lambda (để hàm tạo được ENI trong VPC), không gắn vào OpenSearch domain. OpenSearch không assume role kiểu đó.

Ghi nhớ

Với OpenSearch trong VPC, cần đủ ba thứ cho hàm trung gian: trust policy cho lambda.amazonaws.com, quyền ec2:CreateNetworkInterface/DescribeNetworkInterfaces/DeleteNetworkInterface (thường qua AWSLambdaVPCAccessExecutionRole), và security group của OpenSearch cho phép hàm vào cổng 443. Thiếu bất cứ cái nào cũng cho cùng một triệu chứng: im lặng, không có log.

Đáp án

C và D.

• C — Dùng thuộc tính NoEcho của CloudFormation parameter để che giá trị nhạy cảm.
• D — Lưu bí mật trong Secrets Manager và tham chiếu bằng dynamic reference trong template.

Vì sao đúng

Hai vấn đề khác nhau, hai cách chữa:

Vấn đề 1 — giá trị hiện ra trong Console và API (C). Không có NoEcho, giá trị parameter hiển thị nguyên văn trong DescribeStacks, trong tab Parameters của Console, và trong sự kiện stack:

Parameters:
  MatKhauCSDL:
    Type: String
    NoEcho: true      # hiển thị thành ****

Với NoEcho: true, mọi nơi đều thấy ****.

Vấn đề 2 — bí mật vẫn phải truyền vào từ đâu đó (D). Dynamic reference giải quyết tận gốc: giá trị không bao giờ nằm trong template và không bao giờ đi qua parameter:

Resources:
  CSDL:
    Type: AWS::RDS::DBInstance
    Properties:
      MasterUserPassword: '{{resolve:secretsmanager:prod/db:SecretString:password}}'

CloudFormation lấy giá trị tại thời điểm triển khai, phân quyền bằng IAM, và mọi lần truy cập đều có vết trong CloudTrail.

Hai biện pháp bổ sung nhau: D loại bỏ bí mật khỏi template, C bảo vệ những parameter vẫn buộc phải có.

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

• A. "Dùng Secrets Manager để mã hoá template bằng KMS" — nhầm chức năng. Secrets Manager lưu bí mật, không mã hoá tệp template. Và mã hoá template cũng không chữa được việc giá trị parameter hiện ra lúc chạy.
• B. Parameter Store SecureString "tham chiếu bằng tags trong template" — sai ở chữ tags. Tham chiếu bí mật dùng dynamic reference ({{resolve:ssm-secure:...}}), không dùng tag. Tag chỉ là nhãn siêu dữ liệu, chẳng liên quan gì.
• E. Lưu template trong S3 bucket có bật mã hoá mặc định — bảo vệ tệp template lúc nằm yên, nhưng nếu bí mật đã ghi cứng trong đó thì bất kỳ ai đọc được bucket vẫn thấy, và giá trị vẫn hiện ra trong Console lúc deploy. Chữa vỏ, không chữa ruột.

Ghi nhớ

Ba dạng dynamic reference cần thuộc: | Cú pháp | Nguồn | |---|---| | {{resolve:ssm:ten:phien-ban}} | Parameter Store (plaintext) | | {{resolve:ssm-secure:ten:phien-ban}} | Parameter Store SecureString | | {{resolve:secretsmanager:ten:SecretString:khoa}} | Secrets Manager |

Và nhớ giới hạn của NoEcho: nó che giá trị ở Console và API, nhưng không che nếu bạn tự Fn::Sub giá trị đó vào Output hoặc vào user data — lúc đó nó lại hiện ra.

Đáp án

A — Tạo IAM role ở từng tài khoản đối tác cho phép quản trị viên bên nhà cung cấp thực hiện stack set operations, rồi dùng StackSets với self-managed permissions.

Vì sao đúng

Chi tiết quyết định nằm ở bối cảnh: các tài khoản đối tác thuộc về những công ty khác nhau. Chúng không nằm chung một AWS Organization với nhà cung cấp dịch vụ — và điều đó loại thẳng mọi phương án dùng service-managed permissions.

Với các tài khoản ngoài tổ chức, StackSets chỉ chạy được ở chế độ self-managed permissions, dựa trên hai IAM role:

Đề đã nói rõ mỗi đối tác đã cấp quyền để tạo IAM role trong tài khoản của họ — đúng điều kiện tiên quyết của mô hình này. Sau khi role có mặt, nhà cung cấp quản lý mọi thứ từ một chỗ, cập nhật một lần là đẩy xuống tất cả — đó là vế "minimize operational overhead and stack management".

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

• B. Self-managed nhưng chỉ tạo role ở tài khoản nhà cung cấp — thiếu vế quan trọng nhất. Không có execution role ở tài khoản đối tác thì administration role không có gì để assume, và không tài nguyên nào được tạo.
• C. Đưa các tài khoản đối tác vào AWS Organization của nhà cung cấp — bất khả thi về mặt tổ chức và không được phép về mặt thương mại: gia nhập một Organization nghĩa là trao quyền kiểm soát tài khoản cho management account (bao gồm SCP và khả năng thu hồi). Không công ty đối tác nào chấp nhận điều đó.
• D. Đặt template vào S3, tạo tài khoản quản trị ở từng nơi, đăng nhập từng tài khoản để tạo stack set — quay về thao tác tay ở từng tài khoản, mất hết ý nghĩa của StackSets, và tạo ra n bộ thông tin đăng nhập phải quản lý.

Ghi nhớ

Từ khoá nhận dạng: đề nói "partner companies", "different organizations" ⇒ chắc chắn là self-managed.

Đáp án

D — Thêm manual approval action vào một stage đứng trước action deploy lên môi trường PROD.

Vì sao đúng

Bối cảnh: pipeline "single click deployment" hoàn toàn tự động, và mã có lỗ hổng đã lọt vào production. Yêu cầu là "phải có thêm kiểm tra trước khi mã được đưa lên production".

Manual approval action đặt một cổng chặn cứng ngay trước bước deploy PROD:

{
  "name": "Duyet-Truoc-Khi-Len-PROD",
  "actionTypeId": {"category": "Approval", "owner": "AWS", "provider": "Manual", "version": "1"},
  "configuration": {
    "NotificationArn": "arn:aws:sns:...:duyet-deploy",
    "CustomData": "Xem lại kết quả quét bảo mật trước khi duyệt",
    "ExternalEntityLink": "https://ket-qua-quet/bao-cao"
  }
}

Pipeline dừng lại và chờ, gửi thông báo SNS, và chỉ đi tiếp khi có người được uỷ quyền bấm duyệt. Người duyệt xem được liên kết tới báo cáo quét bảo mật ngay trong màn hình phê duyệt.

Điểm quan trọng: vấn đề trong đề là lỗ hổng bảo mật lọt qua — thứ mà kiểm thử tự động thường không bắt được hết. Một cặp mắt người trước cổng PROD là biện pháp đúng bản chất, và timeout mặc định 7 ngày đảm bảo pipeline không treo mãi.

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

• A. "Tạm dừng deployment stage để validate lần cuối" — mơ hồ và không phải một cấu hình có thật của CodePipeline. Không có nút "pause" cho stage; cơ chế chính thức để dừng chờ người chính là manual approval.
• B. Thêm test stage trước và sau action deploy — test sau khi deploy lên PROD là quá muộn: mã lỗi đã ở production. Và test tự động, dù có ích, không thay thế được kiểm duyệt bảo mật cho thứ đề đang mô tả.
• C. Build stage gọi Lambda để verify — Lambda chạy tự động, nên nó chỉ kiểm được thứ đã lập trình sẵn để kiểm — đúng loại kiểm tra đã có mà vẫn để lọt. Nó cũng vướng trần 15 phút và không cho ai cơ hội xem xét.

Ghi nhớ

Manual approval trong CodePipeline: timeout mặc định 7 ngày, gửi được SNS, kèm được ExternalEntityLink trỏ tới báo cáo, và quyền duyệt kiểm soát bằng IAM (codepipeline:PutApprovalResult). Đây là cách chuẩn để đặt cổng người vào một pipeline tự động — thường ghép cùng SAST/DAST chạy tự động ở stage trước đó.

Đáp án

C — AZ mới chưa được bật cho ALB.

Vì sao đúng

Điểm mấu chốt: Auto Scaling group và Application Load Balancer có danh sách AZ riêng, độc lập với nhau.

Thêm AZ thứ ba cho ASG chỉ nói rằng instance được phép tạo ở đó. Nhưng ALB chỉ đặt node xử lý ở các AZ đã được bật cho chính nó, và nó chỉ định tuyến tới target nằm trong những AZ đó. Instance ở AZ mà ALB không biết sẽ nằm im không nhận request nào.

Sửa bằng cách thêm subnet mapping cho ALB:

aws elbv2 set-subnets --load-balancer-arn <arn> \
  --subnets subnet-az-a subnet-az-b subnet-az-c

Đây là một trong những lỗi hay gặp nhất khi mở rộng ra AZ mới, và nó hoàn toàn im lặng: instance khoẻ mạnh, ASG báo đủ dung lượng, không có thông báo lỗi nào — chỉ là một phần ba số máy không làm gì cả.

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

• A. Chưa bật cross-zone load balancing — bẫy hợp lý nhất, nhưng sai vì hai lý do. Thứ nhất, ALB luôn bật cross-zone load balancing và không tắt được (đó là NLB mới có tuỳ chọn, và mặc định tắt). Thứ hai, cross-zone quyết định cách phân bổ traffic giữa các AZ đã bật, chứ không làm ALB nhận thêm một AZ chưa được khai.
• B. "AMI chưa được cập nhật để bao gồm AZ mới" — AMI là ảnh đĩa; nó không chứa thông tin AZ và không liên quan gì tới định tuyến. Câu này vô nghĩa về mặt kỹ thuật.
• D. Không có subnet nào trong AZ mới — nếu vậy thì ASG không tạo nổi instance nào ở đó, và ASG sẽ báo lỗi launch. Nhưng đề nói rõ instance đã được tạo trong AZ mới, chỉ là không nhận traffic. Nên subnet chắc chắn tồn tại.

Ghi nhớ

Danh sách kiểm khi thêm một AZ:

1. Có subnet trong AZ mới chưa?
2. ASG đã thêm subnet đó vào chưa?
3. ALB đã bật AZ/subnet đó chưa? ← bước hay bị quên nhất
4. Route table và NACL của subnet mới có đúng không?
5. Security group có cho ALB vào instance không?

Và nhớ khác biệt: ALB luôn cross-zone; NLB thì mặc định tắt và bật được.

Đáp án

B — Elastic Beanstalk với load balancing và Auto Scaling, nhưng tạo RDS MySQL BÊN NGOÀI stack của Beanstalk.

Vì sao đúng

Câu này chỉ khác A ở đúng một chữ — trong hay ngoài môi trường Beanstalk — và đó là toàn bộ nội dung câu hỏi.

Khi tạo RDS bên trong môi trường Beanstalk, vòng đời của CSDL gắn chặt với vòng đời môi trường:

Đề nêu hai yêu cầu chỉ B thoả:

1. "Không có thời gian chết khi deploy" và "rollback dễ" — nghĩa là blue/green. Mà blue/green với RDS bên trong thì môi trường xanh lá có một CSDL trống hoàn toàn khác; swap CNAME sẽ đưa người dùng sang một hệ không có dữ liệu.
2. "CSDL có thể được dùng bởi ứng dụng khác" — RDS bên trong Beanstalk là tài nguyên riêng của môi trường đó, không phải thứ để chia sẻ.

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

• A. RDS bên trong Beanstalk — phá vỡ cả hai yêu cầu trên. Đây là lựa chọn chỉ nên dùng cho môi trường dev/test dùng một lần.
• C. EC2 thuần + Lambda chụp snapshot EBS định kỳ — bỏ hết tính năng quản lý của Beanstalk, phải tự dựng deploy và rollback. Snapshot EBS cũng chẳng liên quan gì tới yêu cầu (CSDL đã là RDS, được sao lưu tự động).
• D. Amazon ECS — làm được, nhưng đòi container hoá ứng dụng Node.js, quản cluster, task definition, service. Với yêu cầu "môi trường được quản lý cho Node.js", Beanstalk là mức trừu tượng phù hợp; ECS là bước phức tạp hơn không cần thiết.

Ghi nhớ

Quy tắc vàng của Elastic Beanstalk: KHÔNG BAO GIỜ đặt CSDL production bên trong môi trường. Nếu lỡ tạo rồi thì có đường cứu: chụp snapshot, tạo RDS độc lập từ snapshot, đổi DeletionPolicy và cấu hình môi trường trỏ sang CSDL mới qua biến môi trường.

Đáp án

A — Cài CloudWatch Agent đẩy log lên CloudWatch Logs, tạo metric filter tìm sự kiện đăng nhập, và cảnh báo.

Vì sao đúng

Ba lý do khớp với ba đặc điểm của đề:

1. Đúng nguồn dữ liệu. Sự kiện cần bắt là đăng nhập vào hệ điều hành — /var/log/secure trên Linux, Security event log trên Windows. Đây là log bên trong instance; chỉ agent cài trên máy mới thấy được.

2. Đúng độ trễ. Đề cho 15 phút. Đường CloudWatch Agent → Logs → metric filter → alarm → SNS thường mất dưới một phút, dư sức.

3. Ít gánh nặng vận hành nhất. Toàn bộ đường đi là cấu hình, không phải mã: agent triển khai bằng SSM State Manager cho cả hạm đội, metric filter và alarm khai một lần. Không có hàm nào phải viết và bảo trì.

"Failed password|Accepted password|session opened"  ← mẫu metric filter

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

• C. CloudTrail — CloudTrail ghi lời gọi API tới AWS, không ghi phiên SSH/RDP vào instance. Người ta ssh vào máy thì CloudTrail hoàn toàn không thấy. Sai nguồn dữ liệu — đây là điểm loại quyết định.
• B. SSM chạy script đẩy log lên S3 + S3 event + Lambda — nhiều mảnh phải tự viết và tự nuôi (script, lịch, hàm phân tích), trong khi CloudWatch Agent làm sẵn phần thu thập. Đẩy theo lô lên S3 cũng thêm độ trễ, dễ vượt cửa sổ 15 phút.
• D. SSM Agent + "đăng ký nhận CloudWatch Events" + Lambda — SSM Agent không phát sự kiện đăng nhập hệ điều hành lên EventBridge. Nó chỉ phát sự kiện về vòng đời của chính SSM (Run Command chạy xong, association thay đổi…). Cơ chế được mô tả không tồn tại.

Ghi nhớ

Ghi chú thực tế: nếu chuẩn hoá truy cập qua Session Manager, bạn có thêm được vết trong CloudTrail và log toàn bộ phiên — nhưng chỉ khi đã chặn hẳn đường SSH, nếu không thì vẫn phải có agent.

Đáp án

A, C và D.

• C — Tạo ALB và Auto Scaling group mới ở eu-central-1, ALB mới trỏ vào ASG mới.
• A — Dùng DynamoDB Global Tables để tạo bản sao của bảng ở eu-central-1.
• D — Tạo bản ghi Route 53 với latency-based routing và health check trỏ tới các ALB.

Vì sao đúng

Người dùng ở Frankfurt đang phải đi tới us-east-1 cho mọi request. Muốn giảm độ trễ thì phải đưa toàn bộ ba tầng về gần họ:

Ba mảnh này phải đi cùng nhau. Thiếu tầng dữ liệu thì ứng dụng ở EU vẫn phải gọi ngược về DynamoDB ở Mỹ cho mỗi truy vấn — xoá gần hết lợi ích. Global Tables là bản sao multi-active: đọc và ghi đều được ở cả hai Region, sao chép ngầm dưới một giây.

Health check trong D cũng lo luôn vế "improve availability": Region hỏng thì bị loại khỏi kết quả DNS.

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

• B. Failover routing — mô hình active/passive: mọi người dùng vào Region chính, chỉ chuyển khi Region đó hỏng. Cho độ sẵn sàng nhưng không cho độ trễ thấp — người dùng Frankfurt vẫn đi tới Mỹ.
• E. ASG mới ở EU nhưng dùng ALB hiện có — không làm được: ALB là tài nguyên theo Region, nó chỉ đăng ký target trong VPC của chính nó. Một ALB ở us-east-1 không thể trỏ vào instance ở eu-central-1.
• F. "Bảng DynamoDB mới ở EU với cross-Region replication" — mô tả mơ hồ một thứ mà DynamoDB thực hiện bằng đúng Global Tables (chính là A). Tạo một bảng rời rồi tự đồng bộ nghĩa là tự viết lại cơ chế đã có, kèm bài toán giải quyết xung đột.

Ghi nhớ

Kiến trúc đa Region chỉ có tác dụng khi mọi tầng đều cục bộ. Danh sách kiểm: compute ở Region đó ✅, dữ liệu ở Region đó ✅, định tuyến theo latency ✅, health check ✅. Bỏ sót tầng nào là request vẫn phải vượt đại dương ở tầng đó.