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

Đáp án

C — Dùng API Gateway Mapping Templates.

Vì sao đúng

Vấn đề: Lambda trả về toàn bộ tập dữ liệu, và cần định dạng lại phản hồi trước khi tới client.

Mapping template là cơ chế biến đổi dữ liệu dựng sẵn của API Gateway, viết bằng VTL (Velocity Template Language). Nó hoạt động ở hai chiều:

Ví dụ chỉ giữ lại vài trường và đổi tên chúng:

#set($inputRoot = $input.path('$'))
{
  "danhSach": [
#foreach($item in $inputRoot.items)
    {
      "ma": "$item.id",
      "ten": "$item.product_name"
    }#if($foreach.hasNext),#end
#end
  ],
  "tong": $inputRoot.items.size()
}

Điểm mạnh: không phải sửa mã Lambda. Cùng một hàm có thể phục vụ nhiều client với nhiều định dạng khác nhau, mỗi client một template.

Lưu ý quan trọng: mapping template chỉ dùng được với integration kiểu non-proxy (custom integration). Nếu dùng Lambda proxy integration (AWS_PROXY) thì API Gateway chuyển thẳng phản hồi, và bạn phải định dạng trong mã hàm.

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

• B. Stage variable — là cặp khoá–giá trị cấu hình theo từng stage (dev/test/prod), dùng để trỏ tới các alias Lambda hay endpoint khác nhau. Nó không biến đổi dữ liệu.
• A. "Deploy một interceptor shell script" và D. "Lambda custom interceptor" — cả hai đều không phải khái niệm của API Gateway. API Gateway có mapping template, model, authorizer, và các loại integration — không có "interceptor".

Ghi nhớ

Các biến hay dùng trong mapping template: | Biến | Nội dung | |---|---| | $input.path('$') | toàn bộ body dưới dạng đối tượng | | $input.json('$.field') | một trường dưới dạng JSON | | $input.params('name') | tham số path, query hoặc header | | $context.requestId | ID của request | | $util.escapeJavaScript() | thoát ký tự an toàn |

Cân nhắc thực tế: mapping template mạnh nhưng VTL khó đọc và khó gỡ lỗi. Với logic phức tạp, định dạng trong mã Lambda thường dễ bảo trì hơn.

Đáp án

D — Policy Deny cho s3:PutObject với điều kiện StringNotEquals trên s3:x-amz-server-side-encryption bằng aws:kms.

Vì sao đúng

Ba thành phần phải đúng đồng thời, và mỗi phương án sai đúng một trong ba:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",                                  ← đúng hành động
  "Resource": "arn:aws:s3:::examplebucket/*",
  "Condition": {
    "StringNotEquals": {                                     ← đúng toán tử
      "s3:x-amz-server-side-encryption": "aws:kms"           ← đúng giá trị
    }
  }
}

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

• A. Dùng s3:GetObject và giá trị aws:AES256 — sai hai chỗ. GetObject là đọc, không phải upload. Và aws:AES256 không phải giá trị hợp lệ — giá trị đúng cho SSE-S3 là AES256 (không có tiền tố aws:), còn cho SSE-KMS là aws:kms.
• B. Giá trị "false" — không phải giá trị hợp lệ của header x-amz-server-side-encryption. Header này chỉ nhận AES256, aws:kms, hoặc aws:kms:dsse.
• C. Dùng StringEquals với aws:kms — đảo ngược hoàn toàn ý nghĩa: nó từ chối upload khi header BẰNG aws:kms, tức là chặn đúng những request đã mã hoá đúng cách và cho qua mọi request không mã hoá. Đây là bẫy nguy hiểm nhất vì nhìn qua rất giống D.

Ghi nhớ

Giá trị hợp lệ của header x-amz-server-side-encryption: | Loại mã hoá | Giá trị | |---|---| | SSE-S3 | AES256 | | SSE-KMS | aws:kms | | SSE-KMS DSSE | aws:kms:dsse |

Và một chi tiết quan trọng khi viết policy dạng này: StringNotEquals không khớp khi khoá điều kiện hoàn toàn vắng mặt. Request không gửi header nào sẽ lọt qua. Muốn chặn kín thì thêm một statement thứ hai:

"Condition": {"Null": {"s3:x-amz-server-side-encryption": "true"}}

Đáp án

D — Bật API caching trong API Gateway.

Vì sao đúng

Đề mô tả đúng loại tải mà cache sinh ra để phục vụ:

• Truy cập đọc, không cần xác thực
• Dữ liệu thống kê chỉ cập nhật hằng ngày
• API rất phổ biến (nhiều request cho cùng dữ liệu)

Khi bật cache ở mức stage, API Gateway lưu phản hồi và trả thẳng từ cache mà không gọi Lambda:

Không cache: 1.000.000 request/ngày → 1.000.000 lần gọi Lambda
Có cache   : 1.000.000 request/ngày →     vài trăm lần gọi Lambda

Ba lợi ích cùng lúc: độ trễ giảm mạnh, chi phí Lambda giảm mạnh, và giảm tải cho backend.

Cấu hình:

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations \
    op=replace,path=/cacheClusterEnabled,value=true \
    op=replace,path=/cacheClusterSize,value=0.5 \
    op=replace,path=/*/*/caching/ttlInSeconds,value=3600

Vì dữ liệu chỉ đổi mỗi ngày, TTL đặt được rất dài — tỷ lệ trúng cache sẽ gần như tuyệt đối.

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

• A. "API Gateway dùng ElastiCache for Memcached" — không có tích hợp này. API Gateway có cache riêng dựng sẵn ở mức stage; nó không nối vào ElastiCache. (Ứng dụng của bạn có thể dùng ElastiCache, nhưng khi ấy Lambda vẫn bị gọi — không giải quyết được vế chi phí và độ trễ ở tầng API.)
• B. Gateway VPC Endpoint — cho phép tài nguyên trong VPC gọi dịch vụ AWS mà không ra Internet. API trong đề là public, unauthenticated, phục vụ client bên ngoài — VPC endpoint không liên quan gì. (Và API Gateway dùng interface endpoint, không phải gateway endpoint.)
• C. Usage plan và API key — dùng để định danh, đo lường và giới hạn tốc độ. Chúng làm chậm client lại, không làm API nhanh hơn. Đề nói rõ API là unauthenticated, nên API key còn đi ngược thiết kế.

Ghi nhớ

Đặc điểm của API Gateway cache: | | Chi tiết | |---|---| | Kích thước | 0,5 GB → 237 GB | | TTL | mặc định 300 giây, tối đa 3.600 giây | | Phạm vi | theo stage, ghi đè được theo từng method | | Khoá cache | tuỳ chỉnh được qua cache key parameters | | Vô hiệu hoá | header Cache-Control: max-age=0 (cần quyền InvalidateCache) | | Chi phí | tính theo giờ, không theo request — nên chỉ đáng khi lưu lượng đủ lớn |

Đáp án

C — IAM policy variables.

Vì sao đúng

Yêu cầu: một policy duy nhất dùng chung cho cả đội, mỗi người chỉ vào được thư mục của mình — và người quản lý không phải viết policy riêng cho từng người.

Policy variable là cơ chế chèn giá trị động vào policy tại thời điểm đánh giá:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
  "Resource": "arn:aws:s3:::bucket-a/user/${aws:username}/*"
}

Khi user user-x gọi API, IAM thay ${aws:username} bằng user-x, nên policy trở thành bucket-a/user/user-x/*. Cùng một policy đó, với user-y lại thành bucket-a/user/user-y/*.

Một policy, N người dùng, không bảo trì thêm. Thêm thành viên mới chỉ cần gắn cùng policy đó — không viết gì thêm.

Cần bổ sung một statement nữa để người dùng liệt kê được thư mục của mình:

{
  "Effect": "Allow",
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::bucket-a",
  "Condition": {"StringLike": {"s3:prefix": "user/${aws:username}/*"}}
}

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

• A. IAM policy condition — Condition là khối để đặt điều kiện, nhưng bản thân nó không sinh ra giá trị động. Trong ví dụ trên, Condition có mặt nhưng thứ làm nên tính tổng quát vẫn là biến ${aws:username} bên trong nó.
• B. IAM policy principal — khối Principal chỉ dùng trong resource-based policy (bucket policy, trust policy), không dùng trong identity-based policy gắn vào user. Và nó vẫn phải liệt kê từng principal, không tổng quát hoá được.
• D. IAM policy resource — Resource là nơi đặt biến, nhưng viết ARN tĩnh thì vẫn phải một policy cho mỗi người. Chính biến mới là kỹ thuật cần dùng.

Ghi nhớ

Các policy variable hay dùng: | Biến | Giá trị | |---|---| | ${aws:username} | tên IAM user | | ${aws:userid} | ID duy nhất của principal | | ${aws:PrincipalTag/<key>} | tag của principal — nền tảng của ABAC | | ${aws:SourceIp} | IP nguồn | | ${cognito-identity.amazonaws.com:sub} | ID người dùng Cognito |

Lưu ý: ${aws:username} chỉ có giá trị với IAM user, không có với role. Với role thì dùng ${aws:PrincipalTag/...} hoặc ${aws:userid}.

Đáp án

C — AWS::AccountId.

Vì sao đúng

Pseudo parameter là các biến CloudFormation tự cung cấp, không cần khai trong section Parameters. AWS::AccountId trả về ID 12 chữ số của tài khoản đang chạy stack:

Outputs:
  SoTaiKhoan:
    Description: Tài khoản AWS mà stack này được triển khai
    Value: !Ref "AWS::AccountId"

Vì giá trị được phân giải lúc chạy, cùng một template chạy ở tài khoản nào cũng tự trả về đúng ID của tài khoản đó — chính là điều đề yêu cầu cho môi trường nhiều tài khoản trong AWS Organizations.

Pseudo parameter cũng rất hay dùng để dựng ARN mà không phải ghi cứng:

Value: !Sub "arn:${AWS::Partition}:s3:::${AWS::AccountId}-du-lieu-${AWS::Region}"

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

• A. AWS::Region — trả về Region đang deploy (ap-southeast-1, us-east-1…). Hữu ích, nhưng không phải thứ đề hỏi.
• B. AWS::NoValue — dùng cùng Fn::If để loại bỏ hẳn một thuộc tính khỏi tài nguyên khi điều kiện không thoả:

  SnapshotIdentifier: !If [KhoiPhucTuSnapshot, !Ref MaSnapshot, !Ref "AWS::NoValue"]
  

  Nó không trả về giá trị nào cả — đó chính là mục đích của nó.
• D. AWS::StackName — trả về tên stack, không phải ID tài khoản.

Ghi nhớ

Toàn bộ pseudo parameter của CloudFormation — danh sách ngắn, nên thuộc: | Pseudo parameter | Giá trị | |---|---| | AWS::AccountId | ID tài khoản 12 chữ số | | AWS::Region | Region hiện tại | | AWS::StackName | tên stack | | AWS::StackId | ARN đầy đủ của stack | | AWS::Partition | aws, aws-cn, aws-us-gov | | AWS::URLSuffix | amazonaws.com, amazonaws.com.cn | | AWS::NoValue | xoá thuộc tính khỏi tài nguyên | | AWS::NotificationARNs | danh sách SNS topic của stack |

Dùng AWS::Partition và AWS::URLSuffix khi viết template cần chạy được ở cả Region Trung Quốc hoặc GovCloud.

Đáp án

D — Lưu định danh duy nhất của mỗi request vào một bảng DynamoDB, và sửa hàm Lambda để kiểm tra bảng trước khi xử lý.

Vì sao đúng

Bài toán là idempotency — đảm bảo cùng một request được gửi nhiều lần vẫn cho cùng một kết quả, không xử lý trùng.

Đề đã cho sẵn nguyên liệu: ứng dụng tự gán một định danh duy nhất cho mỗi request. Việc còn lại là lưu định danh đó ở đâu và làm gì với nó.

Vì sao DynamoDB. Ba lý do rất khớp với đề:

• Bền vững — dữ liệu không mất khi có sự cố
• Tự co giãn — đề nói lưu lượng "randomly vary at any given time of day"
• Có ghi có điều kiện (conditional write) — nguyên tử, chống đua tranh giữa các lần gọi Lambda song song:

try:
    table.put_item(
        Item={'request_id': rid, 'processed_at': int(time.time()),
              'ttl': int(time.time()) + 86400},
        ConditionExpression='attribute_not_exists(request_id)')
except ClientError as e:
    if e.response['Error']['Code'] == 'ConditionalCheckFailedException':
        return ket_qua_da_luu(rid)      # đã xử lý rồi — trả về kết quả cũ
    raise
xu_ly_request()

Thêm TTL để bảng tự dọn, không phình mãi.

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

• C. DynamoDB nhưng trả về lỗi client khi gặp request trùng — đây là bẫy chính, và nó sai về mặt nghiệp vụ. Đề nói rõ ứng dụng thử lại khi bị throttle — tức là request trùng là chuyện bình thường và hợp lệ. Trả lỗi cho một lần thử lại hợp lệ sẽ khiến client tưởng thao tác thất bại và có thể thử lại nữa, hoặc báo lỗi cho người dùng dù đơn hàng đã được xử lý. Cách đúng là nhận diện là trùng rồi trả về kết quả đã có.
• A. ElastiCache for Memcached — không bền vững: mất node là mất sạch danh sách request đã xử lý, và khi đó mọi lần thử lại đều bị xử lý trùng. Memcached cũng không có thao tác ghi có điều kiện kiểu DynamoDB.
• B. RDS MySQL — làm được về mặt kỹ thuật (khoá chính đảm bảo duy nhất), nhưng không hợp với tải biến động mạnh: RDS có giới hạn số kết nối, và Lambda mở rộng nhanh rất dễ làm cạn connection pool. DynamoDB là lựa chọn tự nhiên hơn hẳn cho serverless.

Ghi nhớ

Mẫu idempotency chuẩn cho Lambda:

1. Client sinh idempotency key duy nhất cho mỗi thao tác nghiệp vụ
2. Lambda thử ghi có điều kiện key đó vào DynamoDB
3. Ghi thành công ⇒ xử lý lần đầu
4. ConditionalCheckFailedException ⇒ đã xử lý ⇒ trả về kết quả đã lưu, không báo lỗi
5. Đặt TTL để bảng tự dọn

(AWS Lambda Powertools có sẵn module idempotency hiện thực đúng mẫu này.)

Đáp án

A và C.

• A — Mặc định, script trong user data chạy với quyền root.
• C — Mặc định, user data chỉ chạy trong chu kỳ boot lần đầu tiên khi instance được tạo.

Vì sao đúng

A — chạy bằng root. Trên Linux, user data được thực thi bởi cloud-init dưới quyền root; trên Windows là bởi EC2Launch/EC2Config với quyền SYSTEM. Đó là lý do script cài gói không cần sudo:

#!/bin/bash
yum update -y
yum install -y httpd        # không cần sudo — đã là root
systemctl start httpd

C — chỉ chạy lần đầu. Đây là điểm quan trọng nhất và hay bị hiểu nhầm nhất. Mặc định, cloud-init đánh dấu user data đã chạy và bỏ qua ở mọi lần khởi động sau. Khởi động lại instance không làm script chạy lại.

Muốn chạy mỗi lần boot thì phải khai tường minh:

#cloud-config
cloud_final_modules:
  - [scripts-user, always]        # ← 'always' bắt chạy mỗi lần boot

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

• B. "Mặc định user data chạy lại mỗi lần khởi động" — trái với C, và là hiểu nhầm phổ biến nhất về user data.
• D. "Script không có quyền root" — trái với A.
• E. "Instance đang chạy thì cập nhật được user data bằng thông tin xác thực root" — sai về cơ chế. Muốn sửa user data thì phải dừng instance trước (ModifyInstanceAttribute chỉ chấp nhận khi instance ở trạng thái stopped), rồi khởi động lại. Việc này cũng không liên quan gì tới "root credentials".

Ghi nhớ

Ba điều cần nhớ khi dùng user data:

• Không bao giờ đặt bí mật trong đó — mọi tiến trình trên máy đều đọc được qua metadata endpoint
• Log nằm ở /var/log/cloud-init-output.log — nơi đầu tiên nên xem khi script không chạy
• Với dữ liệu lớn, hãy để user data tải script từ S3 thay vì nhét hết vào 16 KB

Đáp án

D — Elastic Beanstalk sẽ thay thế các instance hỏng bằng instance chạy phiên bản ứng dụng từ lần deploy thành công gần nhất.

Vì sao đúng

Tình huống: rolling deployment hỏng giữa chừng — hai lô đã lên bản mới, các lô còn lại thất bại, và đội vận hành tự huỷ các instance hỏng.

Khi instance bị huỷ, Auto Scaling group tạo instance mới để giữ đúng desired capacity. Câu hỏi là: instance mới chạy phiên bản nào?

Câu trả lời nằm ở chỗ Beanstalk lưu "application version" nào là bản hiện hành của môi trường. Vì lần deploy vừa rồi thất bại, môi trường không cập nhật con trỏ đó — nó vẫn trỏ vào lần deploy thành công gần nhất. Instance mới lấy đúng phiên bản đó.

Đây là hành vi có chủ đích và an toàn: hệ thống quay về trạng thái tốt đã biết, thay vì nhân bản thêm một phiên bản đang hỏng.

Hệ quả cần lưu ý: sau sự cố, môi trường ở trạng thái hỗn hợp — hai lô chạy bản mới, phần còn lại chạy bản cũ. Đó là lý do sau mỗi rolling deployment thất bại nên chạy ngay một lần deploy dứt điểm (bản cũ để rollback, hoặc bản mới đã sửa) để đưa toàn bộ fleet về cùng một phiên bản.

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

• A. "Beanstalk sẽ không thay thế instance hỏng" — sai. Auto Scaling group luôn duy trì desired capacity; instance bị huỷ thì máy mới được tạo tự động, không cần ai can thiệp.
• B. "Phải chọn phiên bản thủ công trong Console" — sai. Quá trình hoàn toàn tự động; môi trường đã biết phiên bản hiện hành của nó là gì.
• C. "Dùng phiên bản từ lần deploy thành công cũ nhất" — vô lý: quay về bản đầu tiên trong lịch sử sẽ vứt bỏ mọi cập nhật đã thành công từ trước tới nay.

Ghi nhớ

Hành vi khi deploy thất bại, theo từng chính sách: | Chính sách | Khi thất bại | |---|---| | All at once | môi trường hỏng hoàn toàn, phải deploy lại | | Rolling | trạng thái hỗn hợp — một số lô bản mới, còn lại bản cũ | | Rolling with additional batch | như trên, nhưng giữ đủ năng lực | | Immutable | huỷ fleet mới, fleet cũ nguyên vẹn — an toàn nhất | | Blue/Green | môi trường cũ không bị đụng tới |

Đây chính là lý do Immutable và Blue/Green được ưa dùng cho production: thất bại không để lại trạng thái hỗn hợp.

Đáp án

D — Triển khai hàm với bộ nhớ đặt ở mức tối đa.

Vì sao đúng

Đây là một đặc điểm nền tảng của Lambda mà nhiều người không biết: bạn không cấu hình CPU trực tiếp — CPU được cấp tỷ lệ thuận với bộ nhớ.

Với hàm nặng về CPU, tăng bộ nhớ là cách duy nhất để có thêm sức tính toán — và nó thường không làm tăng chi phí, đôi khi còn giảm:

128 MB  × 10 giây  = 1.280 MB-giây
1.024 MB × 1 giây  = 1.024 MB-giây   ← nhanh gấp 10 lần VÀ rẻ hơn

Vì Lambda tính tiền theo GB-giây, hàm chạy nhanh hơn gấp 8 lần với bộ nhớ gấp 8 lần sẽ có chi phí tương đương — nhưng độ trễ giảm mạnh. Trên mốc 1.769 MB, hàm còn dùng được đa luồng.

Công cụ đáng biết: AWS Lambda Power Tuning (một state machine của Step Functions) chạy thử hàm ở nhiều mức bộ nhớ và vẽ ra biểu đồ chi phí – thời gian để chọn điểm tối ưu.

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

• A. "Đặt CPU allocation ở mức tối đa" — Lambda không có thiết lập CPU. Đây là bẫy trung tâm của câu hỏi: cấu hình duy nhất bạn chỉnh được là bộ nhớ, và CPU đi theo nó.
• B. Lambda layer — layer chỉ là cách đóng gói thư viện dùng chung giữa nhiều hàm. Nó không ảnh hưởng gì tới hiệu năng tính toán (thậm chí layer lớn còn làm cold start chậm hơn một chút).
• C. Triển khai ra nhiều Region — giảm độ trễ mạng cho người dùng ở xa, nhưng thời gian chạy của hàm không đổi. Đề hỏi về "average runtime of the function", tức là thời gian tính toán, không phải độ trễ đường truyền.

Ghi nhớ

Nguyên tắc thực dụng: đừng mặc định để 128 MB. Với hàm nặng tính toán, tăng bộ nhớ thường vừa nhanh hơn vừa không đắt hơn.

Đáp án

D — Tạo một stage development trên API Gateway API và cho lập trình viên trỏ endpoint vào stage đó.

Vì sao đúng

Yêu cầu: cho một nhóm nhỏ lập trình viên dùng thử phiên bản mới có thay đổi phá vỡ tương thích ngược, mà không ảnh hưởng khách hàng hiện tại.

Stage của API Gateway là cơ chế sinh ra đúng cho việc này: mỗi stage là một bản triển khai độc lập của cùng một API, có URL riêng:

https://abc123.execute-api.ap-southeast-1.amazonaws.com/prod   ← khách hàng hiện tại
https://abc123.execute-api.ap-southeast-1.amazonaws.com/dev    ← đội lập trình viên

Ba đặc điểm quan trọng:

• Cách ly hoàn toàn — deploy lên dev không đụng gì tới prod, kể cả khi API mới có endpoint và cấu trúc hoàn toàn khác
• Cấu hình riêng cho từng stage — stage variable, throttling, cache, logging, cả authorizer
• Không tốn thêm chi phí cố định — chỉ trả theo request thực tế

Vì stage là một phần của cùng một API, mọi cấu hình dùng chung (domain, authorizer Cognito, log) được kế thừa — nên đây cũng là phương án ít thao tác vận hành nhất, đúng tiêu chí của đề.

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

• C. Canary release deployment — đây là bẫy sát nhất và cần phân biệt rõ. Canary chia traffic theo phần trăm trên CÙNG một stage, dùng để phát hành dần một thay đổi tương thích ngược. Ở đây đề nói rõ API mới backward-incompatible, và nhóm dùng thử là một nhóm xác định (đội lập trình viên), không phải một tỷ lệ ngẫu nhiên người dùng. Canary sai mô hình.
• B. Tạo hẳn một API Gateway API mới — làm được nhưng tốn công hơn hẳn: phải cấu hình lại authorizer, domain, logging, và duy trì hai API song song. Stage cho cùng kết quả với một thao tác.
• A. Tạo API key mới — API key không thay đổi hành vi của API. Nó chỉ định danh và đo lường; mọi người vẫn gọi cùng một endpoint và nhận cùng một phiên bản. Không giải quyết gì.

Ghi nhớ

Mẹo hay dùng cùng stage: stage variable trỏ tới alias Lambda khác nhau, nên cùng một cấu hình API phục vụ được nhiều phiên bản backend:

Integration URI: arn:aws:lambda:...:function:xu-ly:${stageVariables.alias}