Ngân hàng đề — AWS Certified Developer Associate

Đáp án

B và D.

• B — Security group của EC2 không cho phép traffic từ security group của ALB.
• D — Đường dẫn health check bị cấu hình sai.

Vì sao đúng

Manh mối quyết định: truy cập thẳng IP của instance thì được, nhưng ALB báo unhealthy. Nghĩa là ứng dụng vẫn chạy tốt — vấn đề nằm ở đường đi từ ALB tới instance hoặc ở thứ ALB đang kiểm tra.

B — security group. Đây là nguyên nhân phổ biến nhất. Health check xuất phát từ security group của ALB, không phải từ IP của bạn. Instance phải cho phép nguồn đó:

aws ec2 authorize-security-group-ingress --group-id sg-instance \
  --protocol tcp --port 80 --source-group sg-alb

Thực tế trong đề còn xác nhận điều này: bạn vào được bằng trình duyệt vì security group đang mở cho IP của bạn, nhưng không mở cho ALB.

D — đường dẫn health check sai. Mặc định ALB kiểm tra /. Nếu ứng dụng chỉ phục vụ ở /app và / trả 404, health check luôn thất bại trong khi trang chính vẫn xem được bình thường.

Chỗ để xem lý do chính xác: Target group → Targets, cột Health status details nói thẳng, ví dụ Health checks failed with these codes: [404].

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

• A. "Cần gắn Elastic IP cho instance" — ALB liên lạc với target bằng IP RIÊNG trong VPC. Instance đứng sau ALB không cần IP công khai chút nào — và đó chính là điểm cộng về bảo mật của kiến trúc này.
• C. "Runtime của ứng dụng không được ALB hỗ trợ" — ALB không quan tâm ngôn ngữ hay runtime. Nó chỉ nói HTTP/HTTPS: gửi request, đọc mã trạng thái. Java, Node.js, Go hay PHP đều như nhau.
• E. "EBS volume bị mount sai" — nếu vậy thì ứng dụng đã không chạy được, mà đề nói rõ truy cập thẳng vẫn xem được website.

Ghi nhớ

Danh sách kiểm khi target group báo unhealthy nhưng ứng dụng vẫn chạy:

1. Security group của instance có cho phép security group của ALB không? ← nguyên nhân số một
2. Đường dẫn health check có tồn tại và trả đúng mã trạng thái không? (matcher mặc định là 200)
3. Cổng health check có đúng cổng ứng dụng đang nghe không?
4. Thời gian khởi động ứng dụng có dài hơn interval × threshold không?
5. NACL của subnet có chặn đường về không? (NACL stateless — phải mở cả hai chiều)

Đáp án

B — Tên của exported output phải là duy nhất trong phạm vi MỘT Region.

Vì sao đúng

CloudFormation có một quy tắc rất cụ thể về phạm vi duy nhất của export:

Tên export phải là duy nhất trong một cặp tài khoản + Region.

Diễn giải cho tình huống trong đề:

Thông báo lỗi thực tế sẽ là:

Export with name ELBDNSName is already exported by stack Application2

Cách chữa là đưa tên stack hoặc Region vào tên export để tự động tránh trùng:

Outputs:
  ELBDNSName:
    Value: !GetAtt LoadBalancer.DNSName
    Export:
      Name: !Sub "${AWS::StackName}-ELBDNSName"    # → Application1-ELBDNSName

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

• C. "Duy nhất trên mọi Region" — quá chặt. Nếu đúng thì tình huống ban đầu (hai stack ở hai Region khác nhau, cùng tên export) đã lỗi ngay từ đầu — nhưng đề nói rõ cả hai đều tạo thành công.
• **A và D. Nói về "Output Values" thay vì "Exported Output Values" — sai đối tượng. Output thường không có ràng buộc duy nhất nào: hai stack trong cùng một Region hoàn toàn được phép có output trùng tên. Ràng buộc chỉ áp dụng khi output được Export.

Ghi nhớ

Ba ràng buộc của cross-stack reference, nên thuộc: | Ràng buộc | Chi tiết | |---|---| | Phạm vi duy nhất | tài khoản + Region | | Không xuyên Region hay xuyên tài khoản | Fn::ImportValue chỉ dùng trong cùng tài khoản + Region | | Không xoá được khi đang bị import | phải gỡ mọi stack import trước |

Ràng buộc thứ ba vừa là bảo vệ vừa là phiền toái: nó ngăn bạn vô tình phá hỏng stack khác, nhưng cũng khiến việc tái cấu trúc trở nên khó. Với dữ liệu cần chia sẻ xuyên Region hoặc xuyên tài khoản, dùng SSM Parameter Store thay cho export.

Đáp án

C — KMS lưu giữ CMK, nhận dữ liệu từ client, mã hoá và gửi lại.

Vì sao đúng

Nguyên tắc thiết kế cốt lõi của KMS: khoá chính (CMK) không bao giờ rời khỏi KMS ở dạng bản rõ.

Luồng của một lời gọi Encrypt:

Client                          KMS
  │  ── dữ liệu (≤ 4 KB) ──→     │
  │                              │  CMK nằm trong module phần cứng (HSM)
  │                              │  thực hiện mã hoá NGAY TRONG KMS
  │  ←── ciphertext ────────     │

Bốn đặc điểm quan trọng của CMK:

• Được tạo và lưu trong KMS, bảo vệ bởi HSM đạt chuẩn FIPS 140-2
• Không xuất ra được — không có API nào lấy được bản rõ của CMK
• Mọi phép mã hoá/giải mã bằng CMK diễn ra bên trong KMS
• Mọi lời gọi đều được ghi vào CloudTrail

Đây cũng là lý do có giới hạn 4 KB cho Encrypt: dữ liệu phải đi qua mạng tới KMS. Với dữ liệu lớn, dùng envelope encryption qua GenerateDataKey — KMS trả về một data key (bản rõ + bản mã), bạn mã hoá dữ liệu tại chỗ bằng data key rồi xoá bản rõ khỏi bộ nhớ.

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

• D. "KMS gửi CMK cho client rồi client tự mã hoá" — vi phạm thẳng nguyên tắc thiết kế của KMS. CMK không bao giờ rời khỏi dịch vụ. (Thứ được gửi cho client là data key trong envelope encryption — nhưng đó là khoá con, không phải CMK.)
• A. "KMS tạo CMK mới cho mỗi lời gọi Encrypt" — sai. CMK là tài nguyên bền vững, có vòng đời riêng: tạo một lần, dùng lâu dài, có thể bật/tắt, đặt lịch xoay vòng hằng năm, và có ARN cố định.
• B. "Client gửi CMK lên KMS ở mỗi lời gọi" — ngược hoàn toàn. Client chỉ gửi key ID hoặc ARN; bản thân khoá đã nằm sẵn trong KMS.

Ghi nhớ

Hệ quả thực tế quan trọng nhất: chỉ customer managed key mới dùng chéo tài khoản được, vì chỉ nó cho phép sửa key policy.

Đáp án

A — 0 giây (không bị tính tiền).

Vì sao đúng

Chi tiết quyết định nằm ngay ở câu đầu của đề: "a startup with newly created AWS account".

Tài khoản AWS mới được hưởng AWS Free Tier, trong đó có:

35 giây nằm gọn trong hạn mức 750 giờ, nên hoá đơn cho phần này là 0.

Nhưng có một chi tiết thứ hai cũng cần biết, và nó là lý do các phương án nhiễu tồn tại: EC2 tính tiền theo giây với mức tối thiểu 60 giây. Nghĩa là nếu không có Free Tier, chạy 35 giây vẫn bị tính 60 giây. Câu trả lời sẽ là B.

Hai quy tắc này chồng lên nhau: tối thiểu 60 giây áp dụng trước, rồi Free Tier khấu trừ phần đó về 0.

Một lưu ý thực tế thường bị bỏ qua: EBS volume gắn với instance vẫn tính tiền kể cả khi instance đã dừng. Free Tier cho 30 GB EBS, nhưng vượt qua đó là phải trả — nhiều người "dừng instance để tiết kiệm" rồi vẫn thấy hoá đơn.

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

• B. 60 giây — đúng nếu không có Free Tier (do quy tắc tối thiểu 60 giây). Đề đã cố ý nêu "tài khoản mới tạo", nên Free Tier áp dụng.
• C. 35 giây — bỏ qua quy tắc tối thiểu 60 giây. AWS không tính tiền dưới một phút cho instance Linux.
• D. 30 giây — không tương ứng với quy tắc nào của AWS.

Ghi nhớ

Cách tính tiền EC2: | Nền tảng | Đơn vị | Tối thiểu | |---|---|---| | Linux, Windows (từ 2017) | theo giây | 60 giây | | Một số AMI thương mại từ Marketplace | theo giờ | 1 giờ |

Và nhớ: trạng thái stopped không tính tiền compute, nhưng EBS, Elastic IP không gắn, và snapshot thì vẫn tính.

Đáp án

B — AWS CodeDeploy.

Vì sao đúng

Đề đòi hai thứ: triển khai lên fleet EC2, và kiểm soát đầy đủ từng bước của quy trình blue/green.

CodeDeploy là dịch vụ triển khai chuyên trách, và điểm mạnh của nó chính là mức độ kiểm soát:

• Hỗ trợ blue/green trên EC2/On-Premises, ECS và Lambda
• Lifecycle hook cho phép chèn script vào từng bước của quy trình
• Rollback tự động theo CloudWatch alarm hoặc khi deploy thất bại
• Kiểm soát thời điểm huỷ fleet cũ (ngay, sau N phút, hoặc giữ lại)

Vòng đời blue/green trên EC2 với các điểm móc script:

ApplicationStop → BeforeInstall → AfterInstall → ApplicationStart
→ ValidateService → BeforeAllowTraffic → AllowTraffic → AfterAllowTraffic

Đây chính là "full control over the deployment steps" mà đề yêu cầu — mỗi hook là một script bạn viết, chạy đúng ở điểm bạn chọn.

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

• A. CodeBuild — dịch vụ build và test: biên dịch mã, chạy unit test, tạo artifact. Nó không triển khai gì cả.
• C. Elastic Beanstalk — có blue/green (qua swap CNAME), nhưng nó là nền tảng quản lý toàn bộ — bạn giao cả hạ tầng cho nó và mất phần lớn quyền kiểm soát chi tiết. Không có lifecycle hook chi tiết như CodeDeploy, và đề nói rõ "full control over the deployment steps".
• D. CodePipeline — dịch vụ điều phối: nối các stage source → build → deploy lại với nhau. Bản thân nó không triển khai gì; ở stage deploy nó gọi CodeDeploy (hoặc Beanstalk, ECS, CloudFormation). Nó là nhạc trưởng, không phải nhạc công.

Ghi nhớ

Bộ công cụ "Code" của AWS, mỗi cái một việc: | Dịch vụ | Vai trò | |---|---| | CodeCommit | lưu trữ mã (Git) | | CodeBuild | biên dịch, kiểm thử, tạo artifact | | CodeDeploy | triển khai lên EC2, ECS, Lambda, on-premises | | CodePipeline | điều phối toàn bộ chuỗi | | CodeArtifact | kho gói phụ thuộc | | CodeGuru | rà soát mã và phân tích hiệu năng |

Nhận dạng nhanh: đề nói deployment strategy, blue/green, lifecycle hook, rollback ⇒ CodeDeploy.

Đáp án

A — ALB access logs.

Vì sao đúng

Đề cần hai loại thông tin theo từng request: độ trễ và địa chỉ IP của client.

Access log của ALB ghi mỗi request một dòng với đầy đủ cả hai:

Ba trường thời gian tách bạch cho phép xác định độ trễ nằm ở mạng phía trước, ở ứng dụng, hay ở đường trả về — chính là điều đề cần "analyze traffic patterns".

Log ghi thẳng vào S3 (miễn phí, chỉ trả tiền lưu trữ) và truy vấn bằng Athena:

SELECT client_ip, AVG(target_processing_time) AS do_tre_tb, COUNT(*) AS so_luot
FROM alb_logs
GROUP BY client_ip ORDER BY do_tre_tb DESC LIMIT 20;

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

• D. CloudWatch metrics — 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 client nào, request nào. Đề yêu cầu cả mẫu IP của client, thứ metric không bao giờ có.
• B. CloudTrail logs — ghi lời gọi API quản trị đối với chính load balancer (ai tạo, ai sửa listener). Nó không ghi traffic HTTP đi qua ALB. Đây là nhầm lẫn kinh điển giữa mặt phẳng điều khiển và mặt phẳng dữ liệu.
• C. ALB request tracing — có thật: ALB chèn header X-Amzn-Trace-Id vào mỗi request để theo dấu nó qua các dịch vụ. Nhưng đó là công cụ liên kết một request qua nhiều thành phần, không tự tổng hợp độ trễ hay IP client. Nó bổ sung cho access log, không thay thế.

Ghi nhớ

Lưu ý vận hành: access log mặc định TẮT và phải bật thủ công; log được ghi theo lô mỗi 5 phút, nên nó không phải công cụ theo dõi thời gian thực.

Đáp án

B — Phải kích hoạt quyền truy cập của IAM user vào Billing and Cost Management console.

Vì sao đúng

Đây là một trong số rất ít trường hợp trên AWS mà có IAM policy đúng vẫn không đủ.

Console Billing được bảo vệ bằng hai lớp, và phải bật cả hai:

Đội phát triển đã làm lớp 2, nhưng lớp 1 vẫn chưa được bật — và mặc định nó tắt. Kết quả đúng như đề: policy có đủ, mà người dùng không thấy dịch vụ trong Console.

Đặc điểm cần nhớ: chỉ root user bật được công tắc này, và nó áp dụng cho toàn tài khoản — không bật riêng cho từng người.

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

• A. "Chỉ root user truy cập được Billing console" — sai. IAM user hoàn toàn truy cập được, miễn là công tắc ở lớp 1 đã bật và có policy phù hợp. Nếu điều này đúng thì cả tính năng phân quyền Billing sẽ vô nghĩa.
• C. "IAM user phải được tạo bên trong Billing and Cost Management" — vô nghĩa: không có không gian IAM riêng cho Billing. IAM là dịch vụ toàn cầu duy nhất cho cả tài khoản.
• D. "Người dùng có policy khác chặn họ lại" — về lý thuyết Deny tường minh có gây ra triệu chứng này, nhưng nó không giải thích được vì sao TẤT CẢ người dùng của phòng Tài chính đều gặp cùng vấn đề ngay sau khi vừa gắn policy. Nguyên nhân đồng loạt và ngay lập tức chỉ ra một thiết lập cấp tài khoản, không phải một policy cá biệt.

Ghi nhớ

Những thứ chỉ root user làm được — danh sách ngắn nhưng quan trọng: | Thao tác | |---| | Bật quyền IAM truy cập Billing console | | Đổi tên tài khoản, email, mật khẩu root | | Đóng tài khoản AWS | | Đổi gói hỗ trợ | | Tạo CloudFront key pair | | Bật MFA Delete cho bucket S3 | | Rời khỏi một AWS Organization |

Ghi chú: các action aws-portal:* đang được AWS thay dần bằng bộ action mới chi tiết hơn (billing:*, payments:*, ce:*) — policy viết mới nên dùng bộ mới.

Đáp án

B — Sự hiện diện của section Transform cho biết đây là template AWS Serverless Application Model (SAM).

Vì sao đúng

Transform: 'AWS::Serverless-2016-10-31' là dòng bắt buộc của mọi template SAM. Nó khai báo với CloudFormation rằng: hãy chạy macro SAM để mở rộng template này trước khi triển khai.

Cơ chế hoạt động:

Template SAM (ngắn gọn)  →  macro Transform  →  Template CloudFormation đầy đủ  →  triển khai

Một ví dụ cho thấy SAM tiết kiệm bao nhiêu:

Transform: 'AWS::Serverless-2016-10-31'
Resources:
  HamXuLy:
    Type: AWS::Serverless::Function        # ← 8 dòng ở đây...
    Properties:
      Handler: index.handler
      Runtime: nodejs20.x
      Events:
        Api:
          Type: Api
          Properties: {Path: /don-hang, Method: post}

Macro SAM biến đoạn này thành hàng chục dòng CloudFormation: AWS::Lambda::Function, AWS::IAM::Role, AWS::ApiGateway::RestApi, AWS::ApiGateway::Deployment, AWS::Lambda::Permission…

SAM là một phần mở rộng của CloudFormation, không phải công nghệ khác. Bạn hoàn toàn có thể trộn tài nguyên SAM và tài nguyên CloudFormation thường trong cùng một template.

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

• A. "Đại diện cho định nghĩa một hàm Lambda" — hàm Lambda được khai trong section Resources với type AWS::Serverless::Function hoặc AWS::Lambda::Function. Transform chỉ khai báo macro.
• C. "Là một CloudFormation Parameter" — Parameters là một section hoàn toàn khác, dùng để nhận giá trị đầu vào lúc deploy. Transform không nhận đầu vào từ ai.
• D. "Là một intrinsic function" — intrinsic function là các hàm dùng bên trong template: !Ref, !GetAtt, !Sub, !Join, !FindInMap… Transform là một section cấp cao nhất, không phải hàm.

Ghi nhớ

Các giá trị Transform thường gặp: | Giá trị | Tác dụng | |---|---| | AWS::Serverless-2016-10-31 | macro SAM | | AWS::Include | chèn nội dung từ một tệp trên S3 | | AWS::LanguageExtensions | thêm hàm và cú pháp mở rộng | | Tên macro tự viết | macro riêng do bạn tạo |

Nhận dạng nhanh một template: thấy Transform: AWS::Serverless-* ⇒ đây là SAM. Và nhớ: SAM cuối cùng vẫn biến thành CloudFormation — nên mọi khái niệm của CloudFormation (stack, change set, drift, rollback) đều áp dụng.

Đáp án

C — AWS Cloud Development Kit (CDK).

Vì sao đúng

Yêu cầu rất cụ thể: mô hình hoá hạ tầng bằng chính các ngôn ngữ lập trình mà đội đang dùng — Python, .NET và JavaScript.

CDK là công cụ duy nhất trong bốn phương án làm được điều đó. Nó hỗ trợ:

Viết hạ tầng như viết ứng dụng — có biến, vòng lặp, hàm, lớp, kiểm thử đơn vị:

from aws_cdk import aws_lambda as _lambda, aws_apigateway as apigw

for ten in ["don-hang", "thanh-toan", "giao-hang"]:      # vòng lặp thật
    ham = _lambda.Function(self, f"Ham-{ten}",
        runtime=_lambda.Runtime.PYTHON_3_12,
        handler="index.handler",
        code=_lambda.Code.from_asset(f"src/{ten}"))
    apigw.LambdaRestApi(self, f"Api-{ten}", handler=ham)

CDK cuối cùng vẫn sinh ra template CloudFormation (cdk synth), nên bạn được cả hai: sức mạnh của ngôn ngữ lập trình và tính bền vững của CloudFormation (stack, change set, rollback).

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

• A. AWS CloudFormation — viết bằng YAML hoặc JSON, không phải ngôn ngữ lập trình. Không có vòng lặp, không có hàm; muốn tạo mười tài nguyên giống nhau thì phải chép mười lần.
• B. AWS SAM — cũng là YAML/JSON, chỉ là bản rút gọn của CloudFormation dành riêng cho serverless. Nó giảm số dòng phải viết nhưng vẫn không cho bạn lập trình.
• D. AWS CodeDeploy — dịch vụ triển khai mã ứng dụng lên EC2, ECS, Lambda. Nó không mô hình hoá hạ tầng chút nào.

Ghi nhớ

Ba mức trừu tượng cho hạ tầng dưới dạng mã trên AWS: | Công cụ | Viết bằng | Hợp cho | |---|---|---| | CloudFormation | YAML/JSON | kiểm soát chi tiết, template ổn định | | SAM | YAML/JSON | ứng dụng serverless, ít dòng | | CDK | ngôn ngữ lập trình thật | logic phức tạp, tái sử dụng, nhiều môi trường |

CDK còn có construct ba cấp: L1 (ánh xạ 1-1 với CloudFormation), L2 (có giá trị mặc định hợp lý — dùng nhiều nhất), L3/pattern (mẫu kiến trúc hoàn chỉnh). Và đừng quên chạy cdk bootstrap một lần cho mỗi cặp tài khoản + Region trước khi deploy.

Đáp án

B — IAM Access Analyzer.

Vì sao đúng

Vấn đề: một lần sửa bucket policy đã vô tình mở bucket ra cho cả bên ngoài tổ chức, và cần cơ chế phát hiện những sự cố tương tự với công sức tối thiểu.

IAM Access Analyzer sinh ra đúng cho việc này. Nó dùng suy luận logic hình thức (automated reasoning) để phân tích policy và kết luận tài nguyên nào thực sự có thể truy cập được từ bên ngoài zone of trust (tài khoản hoặc tổ chức của bạn).

Nó phủ các loại tài nguyên hay bị mở nhầm nhất:

• S3 bucket và access point
• IAM role (trust policy)
• KMS key
• Lambda function và layer
• SQS queue, Secrets Manager secret, EFS file system, ECR repository, RDS snapshot, SNS topic

Điểm mạnh về "minimum effort":

• Bật một lần ở mức tài khoản hoặc tổ chức, không cần cấu hình gì thêm
• Tự phân tích lại mỗi khi policy thay đổi — phát hiện gần như tức thì
• Miễn phí cho external access analyzer
• Phát hiện chảy vào EventBridge và Security Hub, nên nối cảnh báo được ngay

Quan trọng nhất: nó không đoán mò. Nó chứng minh về mặt toán học rằng một đường truy cập tồn tại — nên tỷ lệ báo động giả rất thấp.

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

• A. S3 Analytics — phân tích mẫu truy cập dữ liệu để khuyến nghị chuyển lớp lưu trữ (Standard → Infrequent Access). Hoàn toàn về chi phí, không về bảo mật.
• C. Access Advisor trên IAM console — cho biết dịch vụ nào đã được một IAM entity truy cập lần cuối khi nào, dùng để thu hẹp quyền thừa. Hữu ích nhưng nó nhìn từ phía danh tính, không phát hiện tài nguyên đang mở ra ngoài.
• D. S3 Object Lock — cơ chế WORM (write once, read many) chống xoá và ghi đè object trong một khoảng thời gian, phục vụ tuân thủ lưu trữ. Nó không kiểm soát ai đọc được và không phát hiện gì.

Ghi nhớ

IAM Access Analyzer có ba tính năng, đều đáng dùng: | Tính năng | Cho biết | |---|---| | External access | tài nguyên nào truy cập được từ ngoài tài khoản/tổ chức | | Unused access | role, khoá, quyền nào chưa từng được dùng | | Policy validation & generation | kiểm tra policy trước khi áp, và sinh policy tối thiểu từ lịch sử CloudTrail |

Kèm theo, ba lớp bảo vệ S3 nên bật mặc định: Block Public Access ở mức tài khoản, bucket policy chặt, và Access Analyzer làm lưới an toàn.