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

Đáp án

D — Dùng S3 Object Ownership để mặc định chủ sở hữu bucket cũng là chủ sở hữu mọi object trong bucket.

Vì sao đúng

Vấn đề: nhiều tài khoản cùng tải tệp lên một bucket, và theo mặc định lịch sử của S3, tài khoản tải lên là chủ sở hữu object, không phải chủ bucket. Hệ quả là chủ bucket không đọc, không sửa, không phân quyền được cho những object đó — đúng khó khăn đề nêu.

S3 Object Ownership giải quyết tận gốc, với ba thiết lập:

aws s3api put-bucket-ownership-controls --bucket kho-chung \
  --ownership-controls 'Rules=[{ObjectOwnership=BucketOwnerEnforced}]'

Với Bucket owner enforced, quyền truy cập được quyết định hoàn toàn bằng bucket policy và IAM policy — không còn ACL nào can thiệp. Đây cũng là điều AWS khuyến nghị cho mọi bucket mới: mô hình phân quyền trở nên đơn giản và dễ kiểm toán hơn hẳn.

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

• A. Dùng bucket ACL để kiểm soát và định nghĩa chủ sở hữu — ACL không đổi được quyền sở hữu; nó chỉ cấp quyền đọc/ghi. Và AWS khuyến nghị không dùng ACL nữa — chính Object Ownership sinh ra để thay thế chúng.
• B. S3 CORS — Cross-Origin Resource Sharing kiểm soát việc trình duyệt ở tên miền này có được gọi tài nguyên ở tên miền khác hay không. Hoàn toàn không liên quan tới quyền sở hữu object.
• C. "S3 Access Analyzer để xác định chủ sở hữu rồi đổi" — IAM Access Analyzer for S3 báo cáo bucket nào đang chia sẻ ra ngoài tài khoản hoặc tổ chức. Nó là công cụ phát hiện, không đổi quyền sở hữu object và không liệt kê chủ sở hữu từng object.

Ghi nhớ

Ba lớp kiểm soát truy cập S3, và hướng phát triển của chúng: | Lớp | Trạng thái | |---|---| | IAM policy | ✅ khuyến nghị | | Bucket policy | ✅ khuyến nghị | | ACL | ❌ AWS khuyến nghị vô hiệu hoá |

Cấu hình mặc định nên có cho mọi bucket mới:

• Block Public Access: bật cả bốn tuỳ chọn
• Object Ownership: Bucket owner enforced (ACL tắt)
• Mã hoá mặc định: SSE-S3 hoặc SSE-KMS
• Versioning: bật cho dữ liệu quan trọng

Đáp án

B — Gọi GenerateDataKey, nhận về khoá bản rõ và bản mã, rồi dùng khoá bản rõ để mã hoá dữ liệu.

Vì sao đúng

Dữ liệu là 111 GB — vượt xa giới hạn 4 KB của kms:Encrypt. Nên bắt buộc phải dùng envelope encryption, và GenerateDataKey là API khởi đầu cho nó:

kq = kms.generate_data_key(KeyId='alias/khoa-cua-toi', KeySpec='AES_256')
khoa_ban_ro = kq['Plaintext']        # dùng để mã hoá NGAY TẠI CHỖ
khoa_ban_ma = kq['CiphertextBlob']   # lưu kèm dữ liệu

ma_hoa_111gb(du_lieu, khoa_ban_ro)   # AES-256 tại chỗ, không qua mạng
del khoa_ban_ro                      # XOÁ khỏi bộ nhớ ngay sau khi dùng xong
luu(du_lieu_da_ma_hoa, khoa_ban_ma)

Khi cần đọc lại: gọi kms:Decrypt trên khoá bản mã (chỉ vài trăm byte) để lấy lại khoá bản rõ, rồi giải mã 111 GB tại chỗ.

Điểm cốt lõi: 111 GB không bao giờ đi qua mạng tới KMS — chỉ có khoá 256-bit đi qua. Đó là toàn bộ ý nghĩa của envelope encryption.

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

• D. GenerateDataKeyWithoutPlaintext rồi "dùng khoá đã mã hoá để mã hoá dữ liệu" — mâu thuẫn nội tại: không thể mã hoá bằng một khoá đang ở dạng bản mã. API này có thật và hữu ích, nhưng dùng cho tình huống khác: tạo sẵn khoá để dùng sau (ví dụ một dịch vụ chuẩn bị khoá cho dịch vụ khác). Khi cần mã hoá thật thì vẫn phải gọi Decrypt để lấy bản rõ trước.
• A. "GenerateDataKeyWithPlaintext trả về một bản sao đã mã hoá của data key" — tên API này không tồn tại. Tên đúng là GenerateDataKey (nó vốn đã trả về cả bản rõ). Mô tả cũng thiếu: nó nói chỉ trả về bản mã, trong khi thứ cần là cả hai.
• C. Encrypt với CMK dùng imported key material — vẫn vướng trần 4 KB, bất kể khoá được tạo trong KMS hay import từ ngoài vào. Nguồn gốc của key material không thay đổi giới hạn kích thước payload.

Ghi nhớ

Quy tắc vàng của envelope encryption: luôn xoá data key bản rõ khỏi bộ nhớ ngay sau khi dùng xong. Giữ nó lại là vô hiệu hoá toàn bộ mô hình bảo mật.

(Ghi chú: SDK của S3, EBS và nhiều dịch vụ AWS đã tự làm envelope encryption bên dưới — bạn chỉ chỉ định CMK và không phải viết đoạn mã trên.)

Đáp án

C — Tăng bộ nhớ cấp cho các hàm Lambda.

Vì sao đúng

Đề nói rõ workload là compute-heavy và đang có performance lag. Với Lambda, đây là tình huống có đúng một câu trả lời.

Đặc điểm nền tảng: Lambda không cho cấu hình CPU — CPU được cấp tỷ lệ thuận với bộ nhớ.

Nên với hàm nặng tính toán, 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í:

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 gấp N lần với bộ nhớ gấp N lần có chi phí tương đương. Trên mốc 1.769 MB, hàm còn dùng được đa luồng — rất đáng kể với workload tính toán song song được.

Công cụ nên dùng: AWS Lambda Power Tuning chạy thử hàm ở nhiều mức bộ nhớ và vẽ biểu đồ chi phí – thời gian để tìm điểm tối ưu, thay vì đoán.

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

• B. Provisioned concurrency — giải quyết cold start bằng cách giữ sẵn môi trường ấm. Nhưng cold start là chi phí khởi tạo môi trường, còn vấn đề ở đây là thời gian tính toán sau khi đã khởi động. Không giúp gì.
• A. Reserved concurrency — chỉ đặt trần số lần chạy đồng thời. Nó không tăng tốc gì cả, và còn có thể gây throttle.
• D. Gọi hàm bất đồng bộ — đổi cách gọi, không đổi tốc độ chạy. Hàm vẫn mất đúng bấy nhiêu thời gian; chỉ là bên gọi không phải chờ. Với vấn đề "performance lag" thì đây là giấu triệu chứng, không phải chữa.

Ghi nhớ

Nguyên tắc thực dụng: đừng mặc định để 128 MB. Đó là giá trị mặc định, không phải giá trị tối ưu — và với hàm nặng tính toán, để nguyên nó thường vừa chậm hơn vừa đắt hơn.

Đáp án

C — Khai một parameter với danh sách instance type cho phép trong thuộc tính AllowedValues.

Vì sao đúng

Yêu cầu: người dùng template chỉ được chọn từ danh sách instance type đã được duyệt.

AllowedValues là cách diễn đạt trực tiếp ràng buộc đó:

Parameters:
  LoaiInstance:
    Type: String
    Default: t3.micro
    AllowedValues:
      - t3.micro
      - t3.small
      - m5.large
      - m5.xlarge
    Description: Chọn loại instance từ danh sách đã được duyệt
    ConstraintDescription: Phải là một trong các loại instance được phê duyệt

Ba lợi ích:

• CloudFormation từ chối ngay giá trị ngoài danh sách, trước khi tạo bất kỳ tài nguyên nào — không có stack nào chạy nửa chừng rồi hỏng
• Console hiển thị dropdown thay vì ô nhập tự do, nên người dùng không phải nhớ tên
• Một chỗ duy nhất để cập nhật khi danh sách duyệt thay đổi

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

• B. Tạo parameter riêng cho từng loại instance — hiểu sai vấn đề: bạn cần một giá trị được chọn từ nhiều lựa chọn, không phải nhiều tham số. Cách này còn khiến template không biết phải dùng tham số nào.
• D. Dùng Mappings với danh sách instance type làm parameter — Mappings là bảng tra cứu, dùng để ánh xạ khoá sang giá trị (ví dụ Region → AMI ID). Nó không ràng buộc được đầu vào của người dùng; ai đó vẫn nhập được giá trị bất kỳ. (Mappings có thể dùng kèm — ví dụ ánh xạ dev/prod sang instance type — nhưng phần ràng buộc vẫn phải là AllowedValues.)
• A. "Cấu hình một pseudo parameter với AllowedValues" — sai khái niệm. Pseudo parameter là giá trị do CloudFormation tự cung cấp (AWS::Region, AWS::AccountId, AWS::StackName…); bạn không định nghĩa và không ràng buộc chúng được.

Ghi nhớ

Các thuộc tính ràng buộc parameter: | Thuộc tính | Tác dụng | |---|---| | AllowedValues | danh sách giá trị hợp lệ | | AllowedPattern | biểu thức chính quy | | MinLength / MaxLength | độ dài chuỗi | | MinValue / MaxValue | khoảng số | | NoEcho | che giá trị trong Console và API | | ConstraintDescription | thông báo lỗi dễ hiểu khi vi phạm |

Với môi trường nhiều tài khoản như trong đề, có hai công cụ mạnh hơn nữa nên biết: Service Catalog (đóng gói template thành sản phẩm đã duyệt) và SCP với điều kiện ec2:InstanceType (chặn ở tầng tổ chức, không ai lách được kể cả khi không dùng CloudFormation).

Đáp án

A — Sửa policy của IAM user để cho phép action kms:GenerateDataKey.

Vì sao đúng

Đây là một trong những lỗi AccessDenied khó chẩn đoán nhất trên S3, vì quyền S3 đã đúng — thiếu sót nằm ở KMS.

Khi bucket dùng SSE-KMS làm mã hoá mặc định, việc PutObject thực ra là hai thao tác:

1. Gọi KMS: GenerateDataKey  →  lấy data key để mã hoá object
2. Gọi S3 : PutObject        →  ghi object đã mã hoá

IAM user chỉ có s3:PutObject, nên bước 1 thất bại — và S3 trả về AccessDenied mà không nói gì về KMS. Đó là lý do lỗi này gây mất thời gian.

Policy đầy đủ phải có cả hai:

{
  "Effect": "Allow",
  "Action": ["s3:PutObject"],
  "Resource": "arn:aws:s3:::kho-du-lieu/*"
},
{
  "Effect": "Allow",
  "Action": ["kms:GenerateDataKey", "kms:Decrypt"],
  "Resource": "arn:aws:kms:ap-southeast-1:123456789012:key/xxxx"
}

kms:Decrypt cũng cần khi sau đó muốn đọc lại object — nhiều người chỉ thêm GenerateDataKey rồi lại gặp lỗi ở chiều đọc.

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

• D. "Cho phép action s3:Encrypt" — action này không tồn tại. S3 không có s3:Encrypt; việc mã hoá được điều khiển qua header x-amz-server-side-encryption và các condition key như s3:x-amz-server-side-encryption.
• B. Sửa bucket policy — bucket policy có thể là nguyên nhân của AccessDenied trong nhiều tình huống khác, nhưng ở đây đề nói rõ IAM user đã có s3:PutObject, và điểm chặn thật nằm ở KMS. Sửa bucket policy không thêm quyền KMS nào.
• C. Sửa ACL của bucket — ACL là cơ chế cũ mà AWS khuyến nghị không dùng, và nó không cấp quyền KMS. Với bucket dùng SSE-KMS, ACL hoàn toàn không tham gia vào đường đi này.

Ghi nhớ

Bảng quyền KMS cần thêm khi dùng SSE-KMS: | Thao tác S3 | Quyền KMS cần | |---|---| | PutObject | kms:GenerateDataKey | | GetObject | kms:Decrypt | | CopyObject | cả hai | | Multipart upload | cả hai |

Và nhớ: quyền phải có ở cả hai phía khi khoá thuộc tài khoản khác — identity policy của người gọi và key policy của CMK.

Mẹo chẩn đoán: gặp AccessDenied trên S3 mà quyền S3 nhìn có vẻ đủ, hãy kiểm tra ngay xem bucket có mã hoá SSE-KMS không. Đây là nguyên nhân số một của loại lỗi này.

Đáp án

D — AWS Kinesis Data Streams.

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. Chạy quy trình tính tiền trên dữ liệu clickstream
2. Có cùng dữ liệu đã được sắp xếp để kiểm toán trong vòng 7 ngày

Kinesis Data Streams là dịch vụ duy nhất có ba đặc tính cần thiết:

Đặc tính thứ ba là điểm quyết định: hai consumer đọc cùng một dữ liệu mà không ảnh hưởng nhau:

                        ┌→ Consumer A: quy trình tính tiền
Clickstream → Stream ───┤
   (giữ 7 ngày)         └→ Consumer B: quy trình kiểm toán

Consumer kiểm toán có thể tua lại bất kỳ điểm nào trong 7 ngày để đối chiếu — đúng yêu cầu của ngành được quản lý.

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

• C. Amazon SQS — điểm chặn: message bị XOÁ sau khi được xử lý. Không có phát lại, không có consumer thứ hai đọc lại cùng dữ liệu. Standard queue còn không đảm bảo thứ tự; FIFO queue có thứ tự nhưng vẫn không phát lại được.
• A. Kinesis Data Firehose — dịch vụ nạp dữ liệu vào đích (S3, Redshift, OpenSearch). Nó không giữ dữ liệu để phát lại — chỉ đệm tạm rồi ghi đi. Muốn kiểm toán thì phải đọc từ đích, mất tính "cùng một luồng đã sắp xếp".
• B. Kinesis Data Analytics — dịch vụ xử lý luồng (SQL hoặc Apache Flink trên dữ liệu đang chảy). Nó là bộ xử lý ở giữa, cần một stream làm nguồn — tức là vẫn cần Data Streams bên dưới.

Ghi nhớ

Nhận dạng nhanh: đề nói "replay", "multiple consumers", "ordered", hoặc "retention/audit window" ⇒ Kinesis Data Streams, không phải SQS.

Đáp án

C — WebSocket API.

Vì sao đúng

Yêu cầu: gửi cảnh báo và thông báo thời gian thực từ backend về client, và tránh cơ chế polling phức tạp.

Vấn đề với REST và HTTP API là chúng chỉ hỗ trợ một chiều: client hỏi, máy chủ trả lời. Máy chủ không tự gửi được gì cho client. Muốn có thông báo thì client phải liên tục hỏi — chính là polling mà đề muốn tránh.

WebSocket API giữ một kết nối hai chiều, bền vững:

Client  ←────── kết nối WebSocket mở liên tục ──────→  API Gateway
                                                            ↓
Backend đẩy thông báo bất cứ lúc nào ────────────────→  Client nhận NGAY

API Gateway quản lý connection ID cho mỗi client, và backend đẩy tin bằng:

apigw = boto3.client('apigatewaymanagementapi', endpoint_url=WS_ENDPOINT)
apigw.post_to_connection(
    ConnectionId=conn_id,
    Data=json.dumps({'loai': 'canh_bao', 'noi_dung': 'Giao dịch bất thường'}))

WebSocket API có ba route dựng sẵn: $connect (client kết nối — thường lưu connection ID vào DynamoDB), $disconnect (dọn dẹp), và $default (tin nhắn không khớp route nào).

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

• D. REST API và A. HTTP API — cả hai đều là request/response một chiều. Không có cách nào để máy chủ chủ động đẩy dữ liệu.
• B. "REST hoặc HTTP API" — cùng lý do, chỉ là gộp hai lựa chọn sai lại.

Ghi nhớ

Ba loại API của API Gateway: | | REST API | HTTP API | WebSocket API | |---|---|---|---| | Chiều | một chiều | một chiều | hai chiều | | Chi phí | cao nhất | rẻ hơn ~70% | theo phút kết nối + tin nhắn | | Tính năng | đầy đủ (cache, usage plan, request validation, WAF) | tối giản, độ trễ thấp | route theo nội dung tin nhắn | | Hợp cho | API doanh nghiệp | API đơn giản, hiệu năng cao | chat, thông báo, dashboard trực tiếp |

Các lựa chọn khác cho thông báo thời gian thực trên AWS — đáng biết để so sánh: | Giải pháp | Đặc điểm | |---|---| | API Gateway WebSocket | kiểm soát đầy đủ, tự quản connection | | AWS AppSync subscription | GraphQL, tự quản kết nối và ngoại tuyến | | Amazon SNS mobile push | thông báo đẩy tới thiết bị di động | | Amazon IoT Core (MQTT) | thiết bị IoT, số lượng kết nối rất lớn |

Đáp án

B và E.

• E — Lời gọi Lambda là bất đồng bộ.
• B — Sự kiện thất bại ở tất cả các lần thử.

Vì sao đúng

DLQ của Lambda chỉ hoạt động trong một kịch bản rất cụ thể, và cả hai điều kiện phải cùng đúng.

E — chỉ áp dụng cho lời gọi bất đồng bộ. Đây là ràng buộc cứng:

B — sau khi thất bại hết mọi lần thử. Với lời gọi bất đồng bộ, Lambda tự thử lại 2 lần (tổng cộng 3 lần chạy) với khoảng chờ tăng dần. Chỉ khi cả ba đều hỏng, sự kiện mới được đưa vào DLQ:

Lần 1 hỏng → chờ ~1 phút → Lần 2 hỏng → chờ ~2 phút → Lần 3 hỏng → DLQ

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

• A. "Lời gọi là đồng bộ" — trái với E. Lời gọi đồng bộ không dùng DLQ; lỗi được trả về ngay cho bên gọi.
• C. "Thất bại một lần rồi sau đó thành công" — không vào DLQ. Toàn bộ ý nghĩa của cơ chế thử lại là để những lỗi tạm thời tự khỏi. Chỉ thất bại hoàn toàn mới vào DLQ.
• D. "Sự kiện đã được xử lý thành công" — hiển nhiên không vào DLQ.

Ghi nhớ

Lambda có hai cơ chế xử lý lỗi bất đồng bộ, và cái mới tốt hơn hẳn:

EventInvokeConfig:
  MaximumRetryAttempts: 2
  MaximumEventAge: 3600
  DestinationConfig:
    OnFailure: {Destination: arn:aws:sqs:...:su-kien-hong}

Điểm khác biệt quan trọng nhất: destination kèm theo thông tin lỗi, còn DLQ chỉ đưa payload trần — nên gỡ lỗi bằng DLQ khó hơn nhiều. Với thiết kế mới, hãy dùng destination.

Đáp án

C — Blue/Green deployment.

Vì sao đúng

Chi tiết quyết định nằm ở câu cuối của đề: "re-route traffic from your application's original environment to the new environment" — chuyển hướng traffic từ môi trường gốc sang môi trường mới.

Đó là định nghĩa của blue/green, và CodeDeploy có đúng hai kiểu deployment:

Với EC2 + Auto Scaling + ELB như trong đề, CodeDeploy blue/green làm:

1. Sao chép Auto Scaling group hiện có, dựng fleet mới với cùng dung lượng
2. Deploy bản mới lên fleet xanh lá, chờ health check
3. Đăng ký fleet mới vào ELB, gỡ fleet cũ ra
4. Huỷ fleet cũ — ngay, sau N phút, hoặc giữ lại

Bước 4 với tuỳ chọn "sau N phút" chính là cửa sổ rollback: có sự cố thì trỏ ELB về fleet cũ trong vài giây.

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

• B. In-place deployment — kiểu deployment có thật của CodeDeploy, nhưng nó cập nhật trên chính các instance đang có. Không có môi trường mới nào để chuyển traffic sang.

• A. "Immutable deployment" và D. "Rolling deployment" — cả hai đều không phải kiểu deployment của CodeDeploy. Đây là thuật ngữ của Elastic Beanstalk: | Thuật ngữ | Thuộc dịch vụ | |---|---| | In-place, Blue/Green | CodeDeploy | | All at once, Rolling, Rolling with additional batch, Immutable, Blue/Green | Elastic Beanstalk |

  Đây là bẫy trộn thuật ngữ giữa hai dịch vụ — rất hay gặp trong đề.

Ghi nhớ

Các deployment configuration của CodeDeploy trên EC2, dùng được cho cả in-place và blue/green: | Cấu hình | Hành vi | |---|---| | CodeDeployDefault.AllAtOnce | tất cả cùng lúc | | CodeDeployDefault.HalfAtATime | 50% mỗi lượt | | CodeDeployDefault.OneAtATime | một instance mỗi lượt |

Và hai tính năng nên luôn bật cho production: rollback tự động theo CloudWatch alarm, và terminationWaitTimeInMinutes để giữ fleet cũ một khoảng làm cửa sổ rollback.

Đáp án

C và D.

• C — AWS Serverless Application Model (SAM)
• D — AWS Elastic Beanstalk

Vì sao đúng

Cả hai dịch vụ này đều dựng tài nguyên bằng cách sinh ra và thực thi CloudFormation stack bên dưới.

C — SAM là phần mở rộng trực tiếp của CloudFormation. Dòng Transform: AWS::Serverless-2016-10-31 gọi một macro biến cú pháp rút gọn của SAM thành CloudFormation đầy đủ:

Template SAM (8 dòng) → macro Transform → CloudFormation (hàng chục dòng) → triển khai

Mỗi AWS::Serverless::Function nở ra thành AWS::Lambda::Function + AWS::IAM::Role + AWS::Lambda::Permission + (nếu có event API) cả AWS::ApiGateway::RestApi và Deployment.

D — Elastic Beanstalk tạo một CloudFormation stack cho mỗi môi trường. Bạn thấy được stack đó trong console CloudFormation, tên bắt đầu bằng awseb-e-.... Chính vì vậy .ebextensions có khoá Resources cho phép thêm tài nguyên CloudFormation tuỳ ý vào môi trường:

# .ebextensions/them-tai-nguyen.config
Resources:
  HangDoi:
    Type: AWS::SQS::Queue

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

• A. AWS Auto Scaling — dịch vụ độc lập với API riêng (CreateAutoScalingGroup). Nó được CloudFormation tạo ra, nhưng bản thân nó không dùng CloudFormation để làm việc gì.
• B. AWS CodeBuild — dịch vụ build, chạy lệnh trong container tạm thời. Nó có thể deploy CloudFormation stack như một bước trong buildspec, nhưng đó là bạn bảo nó làm — không phải cơ chế nội tại.
• E. AWS Lambda — dịch vụ tính toán. Hàm Lambda được CloudFormation tạo ra, nhưng Lambda không dùng CloudFormation để chạy hàm.

Ghi nhớ

Các dịch vụ dựa trên CloudFormation bên dưới: | Dịch vụ | Quan hệ | |---|---| | SAM | macro của CloudFormation | | Elastic Beanstalk | tạo stack cho mỗi môi trường | | AWS CDK | cdk synth sinh ra template CloudFormation | | AWS Service Catalog | sản phẩm là template CloudFormation | | AWS Amplify (backend) | sinh CloudFormation | | AWS Proton | template dựa trên CloudFormation/Terraform |

Hệ quả thực dụng đáng nhớ: khi một trong các dịch vụ trên gặp lỗi khó hiểu, hãy mở console CloudFormation xem sự kiện của stack tương ứng — thông báo lỗi ở đó thường cụ thể hơn nhiều so với giao diện của chính dịch vụ.