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

Đáp án

B — Lambda Authorizer.

Vì sao đúng

Chi tiết quyết định: cơ chế phân quyền là của bên thứ ba (3rd party authorization mechanism) — không phải Cognito, không phải IAM.

Lambda authorizer (trước đây gọi là custom authorizer) là điểm mở rộng của API Gateway cho đúng tình huống đó: bạn viết một hàm Lambda thực hiện logic xác thực tuỳ ý, và nó trả về một IAM policy quyết định request được phép hay không.

def handler(event, context):
    token = event['authorizationToken']
    nguoi_dung = kiem_tra_voi_ben_thu_ba(token)      # gọi Auth0, Okta, hệ nội bộ…
    if not nguoi_dung:
        raise Exception('Unauthorized')               # → 401
    return {
        'principalId': nguoi_dung['id'],
        'policyDocument': {
            'Version': '2012-10-17',
            'Statement': [{'Action': 'execute-api:Invoke',
                           'Effect': 'Allow', 'Resource': event['methodArn']}]},
        'context': {'vaiTro': nguoi_dung['role']}     # truyền tiếp xuống backend
    }

Hai kiểu authorizer: | Kiểu | Đầu vào | |---|---| | TOKEN | một header duy nhất (thường là Authorization) | | REQUEST | toàn bộ header, query string, path, stage variable |

Kết quả còn được cache (mặc định 300 giây, tối đa 3.600) theo khoá uỷ quyền, nên không phải gọi hàm ở mọi request.

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

• C. Cognito User Pools — là giải pháp danh tính của chính AWS. Nếu dùng nó thì bạn đã không còn dùng cơ chế của bên thứ ba nữa. (Cognito có thể liên kết với IdP bên ngoài qua SAML/OIDC — nhưng đó là khi bạn muốn Cognito làm trung gian, không phải khi đề nói "kiểm soát truy cập bằng cơ chế của bên thứ ba".)
• D. IAM permissions với SigV4 — đòi client có danh tính AWS và ký request bằng SigV4. Với API mà "anyone can access" và dùng hệ phân quyền bên ngoài, client không có thông tin xác thực AWS nào.
• A. "API Gateway User Pools" — không tồn tại. User pool là khái niệm của Cognito, không phải của API Gateway.

Ghi nhớ

Bốn cơ chế uỷ quyền của API Gateway: | Cơ chế | Dùng khi | |---|---| | IAM | client là dịch vụ AWS hoặc có danh tính AWS | | Cognito user pool | dùng thư mục người dùng của AWS | | Lambda authorizer | logic tuỳ ý — IdP bên thứ ba, token riêng, luật nghiệp vụ | | JWT authorizer (chỉ HTTP API) | OIDC/OAuth2 chuẩn, không cần viết mã |

Và nhớ lại: API key không phải cơ chế xác thực — nó chỉ để định danh và đo lường theo usage plan.

Đáp án

A — Viết template CloudFormation định nghĩa tài nguyên kiểm thử tải, rồi dùng lệnh create-stack-set để tạo stack set ở các Region mong muốn.

Vì sao đúng

Yêu cầu: triển khai cùng một bộ tài nguyên ra nhiều Region, không viết thêm mã ứng dụng.

CloudFormation StackSets là cơ chế duy nhất của AWS cho "một template, nhiều Region và/hoặc nhiều tài khoản, quản lý tập trung":

aws cloudformation create-stack-set --stack-set-name kiem-thu-tai \
  --template-body file://load-test.yaml

aws cloudformation create-stack-instances --stack-set-name kiem-thu-tai \
  --accounts 123456789012 \
  --regions us-east-1 eu-west-1 ap-southeast-1 sa-east-1

Ba điểm khớp với đề:

• Không có mã ứng dụng nào — chỉ template và lệnh CLI
• Quản lý tập trung — cập nhật template một lần, đẩy xuống mọi Region
• Dọn dẹp gọn — xoá stack set là xoá sạch tài nguyên ở mọi Region, quan trọng với hạ tầng kiểm thử tạm thời

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

• C. Viết Lambda riêng cho từng Region để tạo stack — vi phạm thẳng ràng buộc "without additional application code". Nó cũng phải tự xử lý lỗi, tự theo dõi trạng thái, tự dọn dẹp — làm lại bằng tay đúng thứ StackSets có sẵn.
• B. CDK Toolkit tạo stack ở từng Region — làm được, nhưng phải chạy cdk deploy riêng cho mỗi Region và không có cái nhìn tập trung về trạng thái tất cả các Region. Ngoài ra CDK đòi viết mã bằng ngôn ngữ lập trình — lại chạm vào ràng buộc "no additional code". (CDK có StackSets construct, nhưng nó cũng chỉ bọc lại chính StackSets của CloudFormation.)
• D. "AWS Organizations template" — không tồn tại. AWS Organizations quản lý tài khoản, OU và SCP; nó không có khái niệm template hạ tầng. Câu này ghép tên dịch vụ với một tính năng của dịch vụ khác.

Ghi nhớ

Hai chế độ quyền của StackSets: | | Self-managed | Service-managed | |---|---|---| | Điều kiện | tài khoản bất kỳ | Organizations "all features" | | Role | tự tạo administration + execution role | tự động | | Triển khai theo | danh sách account ID | OU | | Tài khoản mới | thêm tay | tự nhận (auto deployment) |

Với nhiều Region trong CÙNG một tài khoản như đề này, self-managed là đủ — chỉ cần cặp role AWSCloudFormationStackSetAdministrationRole và AWSCloudFormationStackSetExecutionRole.

Đáp án

C và D.

• C — AWS Certificate Manager (ACM)
• D — IAM

Vì sao đúng

AWS có hai nơi lưu trữ chứng chỉ SSL/TLS máy chủ, và câu hỏi kiểm tra xem bạn có biết nơi thứ hai không.

C — ACM. Đây là lựa chọn mặc định và tốt nhất:

• Chứng chỉ công cộng miễn phí
• Tự động gia hạn — bỏ hẳn nguy cơ sập vì quên gia hạn
• Tích hợp trực tiếp với ELB, CloudFront, API Gateway, AppSync, Cognito
• Khoá riêng không bao giờ xuất ra được — an toàn hơn

D — IAM certificate store. Đây là cơ chế có trước ACM và vẫn còn tồn tại. Nó cần thiết trong hai trường hợp mà ACM không phục vụ được:

1. Region mà ACM chưa hỗ trợ
2. Cần dùng chứng chỉ ở nơi chỉ nhận IAM certificate (một số cấu hình cũ)

aws iam upload-server-certificate --server-certificate-name chung-chi-cua-toi \
  --certificate-body file://cert.pem \
  --private-key file://privatekey.pem \
  --certificate-chain file://chain.pem

Điểm khác biệt lớn: IAM không tự gia hạn — bạn phải tự theo dõi hạn và tự tải lên bản mới.

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

• A. AWS Systems Manager — Parameter Store lưu được nội dung chứng chỉ dưới dạng chuỗi, nhưng nó không phải kho chứng chỉ: ELB và CloudFront không tham chiếu được chứng chỉ từ Parameter Store.
• E. AWS Secrets Manager — cũng lưu được nội dung, cũng không được các dịch vụ AWS nhận làm nguồn chứng chỉ TLS. Nó dành cho bí mật ứng dụng (mật khẩu CSDL, API key).
• B. AWS CloudFormation — công cụ cung cấp hạ tầng. Nó có thể tạo một tài nguyên AWS::CertificateManager::Certificate, nhưng bản thân nó không lưu trữ chứng chỉ.

Ghi nhớ

Hai ràng buộc hay bị hỏi: chứng chỉ ACM cho CloudFront bắt buộc phải cấp ở us-east-1, và chứng chỉ ACM không tải xuống được — nên không dùng được để cài trực tiếp lên máy chủ web của bạn.

Đáp án

B — IAM username và password KHÔNG được IAM hỗ trợ cho CodeCommit.

Vì sao đúng

CodeCommit hỗ trợ ba cách xác thực cho thao tác Git, và mật khẩu đăng nhập IAM không nằm trong số đó:

Điểm cần phân biệt cho rõ, vì đây là toàn bộ nội dung câu hỏi: Git credentials KHÁC mật khẩu đăng nhập Console.

• Mật khẩu IAM dùng để đăng nhập AWS Management Console — không bao giờ dùng cho git push
• Git credentials là một cặp username/password riêng biệt, do IAM sinh ra ở tab Security credentials của user, và chỉ dùng được với CodeCommit

Cấu hình dùng access key:

git config --global credential.helper '!aws codecommit credential-helper $@'
git config --global credential.UseHttpPath true

Vì sao các phương án khác sai (tức là chúng đều được hỗ trợ)

• A. SSH key — được hỗ trợ. Tải khoá công khai lên IAM user, dùng SSH key ID làm username trong ~/.ssh/config.
• C. Git credentials — được hỗ trợ. Đây là cách đơn giản nhất cho HTTPS, và tương thích với mọi công cụ Git hiểu username/password.
• D. AWS access key — được hỗ trợ qua credential-helper. Đây là cách phù hợp nhất cho CI/CD, vì có thể dùng thông tin xác thực tạm thời từ IAM role thay vì khoá dài hạn.

Ghi nhớ

Dù dùng cách nào, quyền vẫn do IAM policy quyết định — cơ chế xác thực chỉ thay đổi cách bạn chứng minh danh tính. Các quyền chính: | Quyền | Cho phép | |---|---| | codecommit:GitPull | git clone, git fetch, git pull | | codecommit:GitPush | git push | | codecommit:CreateBranch / DeleteBranch | quản lý nhánh | | codecommit:Get* / List* | đọc qua API và Console |

Với CI/CD, luôn ưu tiên IAM role + credential-helper thay vì Git credentials tĩnh — thông tin xác thực tạm thời và tự xoay vòng.

Đáp án

D — AWS Secrets Manager.

Vì sao đúng

Đề nêu hai yêu cầu, và yêu cầu thứ hai loại hết các lựa chọn còn lại:

1. Lưu bí mật an toàn, bỏ chuỗi kết nối ghi cứng trong máy chủ web
2. Tự động xoay vòng thông tin đăng nhập CSDL

Secrets Manager là dịch vụ AWS duy nhất có xoay vòng tự động dựng sẵn, và với các CSDL của AWS (RDS, Aurora, DocumentDB, Redshift) nó còn có sẵn Lambda xoay vòng — bạn chỉ chọn chu kỳ:

aws secretsmanager rotate-secret --secret-id prod/db/creds \
  --rotation-lambda-arn arn:aws:lambda:...:SecretsManagerRDSPostgreSQLRotation \
  --rotation-rules AutomaticallyAfterDays=30

Ứng dụng đọc bí mật lúc chạy thay vì đọc từ tệp cấu hình:

bi_mat = json.loads(sm.get_secret_value(SecretId='prod/db/creds')['SecretString'])
ket_noi = connect(host=bi_mat['host'], user=bi_mat['username'], password=bi_mat['password'])

Cơ chế xoay vòng dùng hai bộ thông tin xen kẽ qua staging label AWSCURRENT và AWSPENDING, nên trong lúc đổi mật khẩu không có khoảng thời gian nào ứng dụng bị từ chối.

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

• C. SSM Parameter Store — lưu được bí mật dưới dạng SecureString mã hoá bằng KMS, và standard parameter miễn phí. Nhưng nó không có xoay vòng tự động — bạn phải tự viết Lambda và tự lên lịch. Đây là điểm loại duy nhất, và nó quyết định.
• B. Systems Manager — quá chung chung; phần liên quan chính là Parameter Store, đã phân tích ở trên.
• A. AWS KMS — quản lý khoá mã hoá, không lưu bí mật dạng văn bản. Có thể dùng KMS để tự mã hoá mật khẩu rồi cất ở đâu đó, nhưng khi ấy bạn phải tự viết toàn bộ phần xoay vòng — đúng thứ Secrets Manager làm sẵn.

Ghi nhớ

Quy tắc chọn: cần xoay vòng ⇒ Secrets Manager. Chỉ cần lưu an toàn và muốn miễn phí ⇒ Parameter Store SecureString.

Đáp án

A — Section Parameters không thể gắn Condition.

Vì sao đúng

Trong CloudFormation, Condition dùng được ở ba nơi, và Parameters không nằm trong số đó:

Vì sao Parameters không thể có điều kiện — lý do nằm ở thứ tự xử lý:

1. Người dùng nhập PARAMETERS          ← xảy ra TRƯỚC
2. CloudFormation đánh giá CONDITIONS  ← dựa trên giá trị parameter
3. Tạo RESOURCES theo điều kiện
4. Sinh OUTPUTS theo điều kiện

Condition được tính TỪ giá trị parameter. Nếu parameter lại phụ thuộc vào condition thì sinh ra vòng lặp logic — parameter cần condition, condition cần parameter.

Ví dụ dùng đúng ở Resources và Outputs:

Parameters:
  MoiTruong: {Type: String, AllowedValues: [dev, prod]}

Conditions:
  LaProduction: !Equals [!Ref MoiTruong, prod]

Resources:
  BanSaoLuu:
    Type: AWS::RDS::DBInstance
    Condition: LaProduction          # ✅ chỉ tạo ở production

Outputs:
  DiaChiBanSaoLuu:
    Condition: LaProduction          # ✅ chỉ xuất khi có
    Value: !GetAtt BanSaoLuu.Endpoint.Address

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

• B. Conditions — điều kiện lồng vào nhau được bằng Fn::And, Fn::Or, Fn::Not, tham chiếu tới điều kiện khác.
• C. Resources — cách dùng phổ biến nhất: tạo tài nguyên chỉ ở một số môi trường.
• D. Outputs — hữu ích để tránh xuất giá trị của tài nguyên không được tạo.

Ghi nhớ

Muốn "parameter có điều kiện" thì dùng cách khác: | Nhu cầu | Cách làm | |---|---| | Giá trị mặc định khác nhau theo môi trường | Mappings + !FindInMap | | Bỏ hẳn một thuộc tính khi không cần | !If [DieuKien, GiaTri, !Ref "AWS::NoValue"] | | Ràng buộc giá trị nhập vào | AllowedValues, AllowedPattern, MinLength |

AWS::NoValue là mẹo rất hữu ích — nó khiến CloudFormation xoá hẳn thuộc tính khỏi tài nguyên thay vì đặt giá trị rỗng.

Đáp án

C — Trust policy là resource-based policy duy nhất mà chính dịch vụ IAM hỗ trợ.

Vì sao đúng

Điểm mấu chốt: câu hỏi giới hạn phạm vi ở chính dịch vụ IAM, không phải toàn bộ AWS. Nhiều dịch vụ khác có resource-based policy (S3 bucket policy, SQS queue policy, KMS key policy, Lambda resource policy…), nhưng trong IAM chỉ có một.

Trust policy (còn gọi là assume role policy document) gắn vào IAM role và trả lời câu hỏi: ai được phép assume role này?

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "ec2.amazonaws.com"},     ← ai được vào
    "Action": "sts:AssumeRole"
  }]
}

Đây đúng là resource-based policy vì nó gắn vào tài nguyên (role) và khai Principal — hai đặc điểm phân biệt với identity-based policy.

Mỗi role có hai policy hoàn toàn khác nhau, và lẫn hai cái này là lỗi rất phổ biến:

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

• A. Service Control Policy (SCP) — thuộc AWS Organizations, không thuộc IAM. Và nó không phải resource-based policy: nó là guardrail giới hạn quyền tối đa của tài khoản, không cấp quyền và không có Principal.
• B. Permissions boundary — là identity-based policy dùng làm trần quyền cho một user hoặc role. Nó gắn vào danh tính, không gắn vào tài nguyên, và không có Principal.
• D. Access control list (ACL) — ACL là cơ chế cũ, tồn tại ở S3 và một số dịch vụ khác, không phải của IAM. AWS cũng khuyến nghị không dùng ACL nữa mà chuyển sang bucket policy.

Ghi nhớ

Mẹo nhận dạng nhanh: policy nào có khối Principal thì đó là resource-based policy.

Đáp án

C — Dùng metric backlog per instance với target tracking scaling policy.

Vì sao đúng

Manh mối trong đề rất rõ: ApproximateNumberOfMessagesVisible tăng vọt, nhưng mọi metric khác của container ECS đều bình thường.

Điều đó có nghĩa: CPU và bộ nhớ không phải là chỉ báo đúng cho việc cần mở rộng. Container không bận — chúng chỉ không đủ số lượng để tiêu thụ kịp hàng đợi. Mở rộng theo CPU sẽ không bao giờ kích hoạt.

Chỉ số đúng là backlog per instance:

backlogPerInstance = ApproximateNumberOfMessagesVisible / số task đang chạy

Ví dụ: mỗi task xử lý được 100 message trong khoảng thời gian chấp nhận được ⇒ đặt giá trị mục tiêu = 100. Application Auto Scaling sẽ tự thêm hoặc bớt task để giữ tỷ lệ đó.

Vì sao dùng target tracking chứ không phải step scaling: bạn chỉ khai một con số mục tiêu, và dịch vụ tự tạo cùng quản lý các alarm cần thiết. Nó cũng phản ứng mượt hơn với tải biến động, đúng với "variable traffic spikes" trong đề.

Vì đây là metric tuỳ chỉnh, cần một Lambda nhỏ chạy định kỳ tính và publish nó — đây là mẫu được chính AWS khuyến nghị trong tài liệu Auto Scaling.

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

• D. ECS step scaling policy — có thể dùng, nhưng kém hơn ở đây: step scaling đòi bạn tự định nghĩa từng nấc (backlog 100–500 thì thêm 2 task, 500–1.000 thì thêm 5 task…). Với tải biến động thất thường thì việc chỉnh các nấc này rất khó và phải điều chỉnh liên tục. Target tracking đơn giản và tự thích nghi hơn.
• B. ECS service scheduler — chỉ đảm bảo số task mong muốn luôn được duy trì và task chết thì được thay. Nó không tự thay đổi số lượng theo tải — đó là việc của Application Auto Scaling.
• A. Docker Swarm — công cụ điều phối container của bên thứ ba, hoàn toàn tách biệt với ECS. Không phải giải pháp trên AWS cho bài toán này, và cũng không giải quyết được vế đo lường.

Ghi nhớ

Chọn metric mở rộng theo bản chất tải: | Loại tải | Metric đúng | |---|---| | Tính toán nặng | CPUUtilization | | Bộ nhớ nặng | MemoryUtilization | | Xử lý hàng đợi | backlog per instance | | Phục vụ HTTP | RequestCountPerTarget của ALB |

Bài học chung: đừng mở rộng theo metric không phản ánh nút thắt thật. Ở đây nút thắt là độ sâu hàng đợi, không phải tài nguyên container.

Đáp án

B — DeleteQueue.

Vì sao đúng

Yêu cầu: xoá queue cùng toàn bộ nội dung của nó sau khi kiểm thử xong.

DeleteQueue xoá hoàn toàn hàng đợi, kể cả mọi message còn nằm trong đó — cả message đang hiển thị lẫn message đang trong trạng thái in-flight:

aws sqs delete-queue --queue-url https://sqs.ap-southeast-1.amazonaws.com/123456789012/hang-doi-test

Hai đặc điểm cần biết:

• Thao tác mất tới 60 giây để có hiệu lực hoàn toàn
• Trong khoảng đó, request tới queue có thể vẫn thành công — nên không tạo lại queue cùng tên trong vòng 60 giây, dễ gây hành vi khó lường

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

• D. PurgeQueue — đây là bẫy chính, và khác biệt rất rõ ràng: PurgeQueue xoá HẾT MESSAGE nhưng GIỮ LẠI QUEUE. Đề yêu cầu xoá cả queue, nên phương án này chỉ làm được nửa việc. (PurgeQueue cũng có giới hạn: chỉ gọi được 60 giây một lần cho mỗi queue.)
• A. RemoveQueue — API này không tồn tại. SQS dùng tiền tố Delete, không phải Remove.
• C. RemovePermission — API có thật, nhưng nó gỡ một statement khỏi queue policy (thu hồi quyền đã cấp cho tài khoản khác). Nó không đụng gì tới queue hay message.

Ghi nhớ

Các API xoá của SQS, phân biệt cho rõ: | API | Xoá gì | Giữ lại gì | |---|---|---| | DeleteQueue | cả queue và toàn bộ message | không gì cả | | PurgeQueue | chỉ message | queue và mọi cấu hình | | DeleteMessage | một message cụ thể (theo receipt handle) | phần còn lại | | DeleteMessageBatch | tối đa 10 message một lần | phần còn lại |

Trong xử lý message, DeleteMessage là bước bắt buộc sau khi xử lý xong — không gọi thì hết VisibilityTimeout message sẽ quay lại queue và bị xử lý lần nữa.

Đáp án

B — Geolocation routing.

Vì sao đúng

Đề có hai yêu cầu, và yêu cầu thứ hai là điểm phân biệt quyết định:

1. Người dùng Brazil được phục vụ bởi máy chủ ở Brazil
2. Người dùng ở nơi khác KHÔNG được truy cập máy chủ đó qua truy vấn DNS

Geolocation routing định tuyến theo vị trí địa lý của người truy vấn, và nó là chính sách duy nhất có khả năng từ chối trả lời cho các vùng không khớp:

aws route53 change-resource-record-sets --hosted-zone-id Zxxx --change-batch '{
  "Changes": [{"Action": "CREATE", "ResourceRecordSet": {
    "Name": "video.example.com", "Type": "A",
    "SetIdentifier": "brazil",
    "GeoLocation": {"CountryCode": "BR"},
    "AliasTarget": {...}}}]}'

Đây chính là điểm mấu chốt: nếu không tạo bản ghi mặc định (CountryCode: *), truy vấn từ vùng không khớp sẽ KHÔNG nhận được câu trả lời nào — Route 53 trả về NOERROR với zero answer. Người dùng ngoài Brazil không phân giải được tên miền, đúng yêu cầu "should not be able to access through DNS queries".

Với các chính sách khác, hành vi đó không diễn đạt được.

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

• C. Latency-based routing — chọn endpoint có độ trễ mạng thấp nhất. Nó không bao giờ từ chối trả lời: người dùng ở châu Âu vẫn nhận được câu trả lời (endpoint nào nhanh nhất với họ), nên vẫn truy cập được. Không thoả yêu cầu chặn.
• A. Failover routing — mô hình active/passive cho tình huống hỏng hóc. Không có khái niệm địa lý, và luôn trả về một endpoint nào đó.
• D. Weighted routing — chia traffic theo tỷ lệ, hoàn toàn không xét vị trí. Người dùng ở bất kỳ đâu cũng có thể rơi vào máy chủ Brazil theo xác suất.

Ghi nhớ

Hai cảnh báo thực tế khi dùng geolocation: luôn cân nhắc tạo bản ghi mặc định (nếu không, người dùng ngoài danh sách bị mất hoàn toàn — điều này là cố ý trong câu hỏi này nhưng thường là sự cố ngoài đời), và nhớ rằng vị trí được suy ra từ IP của DNS resolver, không phải IP của người dùng — nên không chính xác tuyệt đối. Muốn chặn thật sự thì phải kết hợp WAF geo match ở tầng ứng dụng.