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

Đáp án

C — Dùng API GetTraceSummaries với một filter expression.

Vì sao đúng

Câu hỏi hỏi cách tìm kiếm trace, và trong X-Ray thì việc tìm kiếm được thực hiện qua GetTraceSummaries — đây là API duy nhất nhận filter expression:

aws xray get-trace-summaries \
  --start-time 2026-08-05T00:00:00 \
  --end-time 2026-08-05T23:59:59 \
  --filter-expression 'user("nguyenvana")'

Trường user mà lập trình viên đã đặt là một trường tích hợp sẵn của segment, và X-Ray đánh chỉ mục nó tự động — nên tìm theo nó được ngay, không cần khai thêm gì:

from aws_xray_sdk.core import xray_recorder
xray_recorder.current_segment().set_user('nguyenvana')

Vài mẫu filter expression hay dùng:

user("nguyenvana")                          # theo người dùng
service("api-don-hang") { fault = true }    # request lỗi của một dịch vụ
responsetime > 5                            # chậm hơn 5 giây
http.status = 500                           # theo mã trạng thái
annotation.don_hang_id = "DH-123"           # theo annotation tuỳ chỉnh

Quy trình tìm kiếm gồm hai bước: GetTraceSummaries trả về danh sách tóm tắt kèm trace ID, rồi BatchGetTraces lấy chi tiết đầy đủ của các trace đó.

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

• D. Dùng filter expression để tìm trường user trong annotation — đây là phương án gần nhất và cần phân biệt kỹ. user KHÔNG phải annotation — nó là trường tích hợp sẵn của segment, nên cú pháp tìm cũng khác: user("ten") chứ không phải annotation.user = "ten". (Và phương án này không nêu API nào, trong khi đề hỏi cách tìm kiếm.)
• B. Dùng filter expression để tìm trường user trong metadata — sai nghiêm trọng hơn: metadata KHÔNG được đánh chỉ mục và KHÔNG tìm kiếm được. Đây là khác biệt cốt lõi giữa annotation và metadata.
• A. Dùng API GetTraceGraph — API này trả về cấu trúc service map (các dịch vụ và quan hệ giữa chúng), dùng để vẽ sơ đồ. Nó không tìm kiếm trace theo điều kiện.

Ghi nhớ

Ba loại dữ liệu bạn gắn vào segment — và chỉ hai loại đầu tìm kiếm được: | Loại | Đánh chỉ mục | Cú pháp tìm | |---|---|---| | Trường tích hợp (user, http.status, responsetime, fault) | ✅ | user("ten") | | Annotation (cặp khoá–giá trị của bạn) | ✅ | annotation.khoa = "gia_tri" | | Metadata | ❌ | không tìm được |

Đây là quyết định thiết kế quan trọng nhất khi dùng X-Ray: thứ gì cần tìm kiếm thì phải là annotation, thứ gì chỉ để đọc khi đã mở trace ra thì để metadata.

# Annotation — tìm kiếm được, tối đa 50 mỗi trace
xray_recorder.put_annotation('don_hang_id', 'DH-123')

# Metadata — không tìm được, nhưng chứa được cấu trúc phức tạp
xray_recorder.put_metadata('chi_tiet_don', {'san_pham': [...], 'tong': 500000})

Các API của X-Ray: | API | Việc | |---|---| | GetTraceSummaries | TÌM KIẾM trace bằng filter expression | | BatchGetTraces | lấy chi tiết đầy đủ theo trace ID | | GetTraceGraph | cấu trúc service map | | GetServiceGraph | service map theo khoảng thời gian | | PutTraceSegments | gửi segment (agent dùng) |

Và nhớ về sampling: mặc định X-Ray chỉ lấy 1 request mỗi giây cộng 5% số còn lại — nên không phải request nào cũng có trace. Nếu cần chắc chắn ghi lại một loại request nhất định, hãy khai sampling rule riêng cho nó.

Đáp án

D — Write capacity units của GSI được cấp phát không đủ.

Vì sao đúng

Đây là một trong những hành vi gây bất ngờ nhất của DynamoDB, và nó giải thích chính xác triệu chứng trong đề: bảng gốc bị throttle ghi trong khi WCU của bảng gốc chưa dùng hết.

Nguyên nhân nằm ở cách GSI được cập nhật:

Ghi vào bảng gốc
      ↓
  ┌───┴────────────────────┐
  ↓                        ↓
Bảng gốc (tốn WCU gốc)   GSI (tốn WCU RIÊNG của GSI)

Mỗi lần ghi vào bảng gốc kéo theo một lần ghi vào GSI, và GSI có ngân sách WCU hoàn toàn riêng. Khi ngân sách đó cạn:

DynamoDB throttle chính thao tác ghi vào BẢNG GỐC — dù bảng gốc còn thừa capacity.

Lý do là để giữ nhất quán: nếu cho phép ghi vào bảng gốc mà không ghi được vào GSI, index sẽ lệch với dữ liệu thật vĩnh viễn. DynamoDB chọn cách chặn ngay từ đầu.

Tình huống trong đề càng dễ xảy ra vì đề nói rõ: GSI chủ yếu phục vụ đọc, còn bảng gốc ghi rất nhiều — nên rất có thể GSI được cấp nhiều RCU nhưng ít WCU, trong khi tải ghi mà nó phải hứng lại bằng đúng tải ghi của bảng gốc.

Cách sửa:

aws dynamodb update-table --table-name du-lieu \
  --global-secondary-index-updates '[{
    "Update": {
      "IndexName": "ChiMucTraCuu",
      "ProvisionedThroughput": {"ReadCapacityUnits": 100, "WriteCapacityUnits": 500}
    }}]'

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

• C. Thiếu WCU trên bảng gốc — mâu thuẫn với dữ kiện của đề: đề nói rõ "the write capacity units on the primary table are not fully utilized". Nếu bảng gốc thiếu WCU thì nó đã bị dùng hết.
• A. Thiếu RCU trên bảng gốc — RCU không liên quan tới thao tác GHI. Thiếu RCU chỉ gây throttle khi đọc.
• B. Lẽ ra nên dùng LSI thay vì GSI — không phải nguyên nhân, và trong nhiều trường hợp còn không làm được. LSI bắt buộc dùng chung partition key với bảng gốc và chỉ tạo được lúc tạo bảng. (Điểm đáng chú ý: LSI dùng chung capacity với bảng gốc, nên nó không gây ra kiểu throttle này — nhưng đổi lại nó kém linh hoạt hơn nhiều, và có giới hạn 10 GB cho mỗi partition key.)

Ghi nhớ

Khác biệt về capacity giữa hai loại index — chính là mấu chốt của câu này: | | GSI | LSI | |---|---|---| | Capacity | RIÊNG, phải cấp riêng | dùng chung với bảng gốc | | Partition key | tự do | phải giống bảng gốc | | Tạo lúc nào | bất cứ lúc nào | chỉ khi tạo bảng | | Strongly consistent read | ❌ | ✅ | | Số lượng | 20 | 5 |

Danh sách kiểm khi bảng bị throttle ghi mà capacity còn dư:

1. WCU của GSI có đủ không? ← nguyên nhân phổ biến nhất
2. Có hot partition không (một partition key nhận quá nhiều ghi)?
3. Item có vượt quá kích thước dự kiến không?

Ba cách phòng tránh: | Cách | Chi tiết | |---|---| | Cấp WCU cho GSI ≥ WCU bảng gốc | vì mỗi ghi gốc kéo theo một ghi GSI | | Bật Auto Scaling cho cả bảng và GSI | tự điều chỉnh theo tải | | Dùng on-demand mode | GSI tự co giãn cùng bảng, không phải tính toán |

Và một tối ưu quan trọng: chỉ chiếu các thuộc tính cần thiết vào GSI (ProjectionType: KEYS_ONLY hoặc INCLUDE). Chiếu ALL nghĩa là mỗi lần ghi phải sao chép toàn bộ item sang index — tốn WCU nhiều hơn hẳn, và cũng tốn gấp đôi chi phí lưu trữ.

Theo dõi metric ThrottledRequests kèm dimension GlobalSecondaryIndexName để biết chính xác index nào đang là nút thắt.

Đáp án

C — Triển khai các phiên bản API thành các stage riêng biệt với endpoint riêng, và dùng stage variable để cung cấp thêm ngữ cảnh.

Vì sao đúng

Stage là cơ chế phiên bản hoá dựng sẵn của API Gateway. Mỗi stage là một bản triển khai độc lập với URL riêng:

https://abc123.execute-api.ap-southeast-1.amazonaws.com/v1
https://abc123.execute-api.ap-southeast-1.amazonaws.com/v2
https://abc123.execute-api.ap-southeast-1.amazonaws.com/test

Mỗi stage có cấu hình hoàn toàn riêng: throttling, caching, mức log, WAF, và quan trọng nhất là stage variable.

Stage variable là mảnh ghép còn lại — nó cho phép cùng một định nghĩa API trỏ tới backend khác nhau theo từng stage:

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

Stage v1   → stageVariables.alias = "v1"
Stage v2   → stageVariables.alias = "v2"
Stage test → stageVariables.alias = "test"

Kết hợp với Lambda alias, bạn có một mô hình rất gọn:

Lambda: xu-ly
├── alias "v1"   → version 3
├── alias "v2"   → version 7
└── alias "test" → $LATEST

Muốn phát hành phiên bản mới, chỉ cần trỏ alias sang version khác — không đụng gì tới cấu hình API.

Stage variable còn dùng được ở nhiều nơi khác: ${stageVariables.tenBang} cho tên bảng DynamoDB, ${stageVariables.urlBackend} cho HTTP integration.

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

• A. Tạo Lambda authorizer để định tuyến client tới đúng phiên bản — sai chức năng: authorizer dùng để xác thực và uỷ quyền — nó trả về một IAM policy cho phép hoặc từ chối. Nó không định tuyến request tới backend khác nhau.
• B. Tạo resource policy của API Gateway để cô lập phiên bản — resource policy kiểm soát AI được gọi API (theo IP, VPC endpoint, tài khoản AWS). Nó không phân tách phiên bản và không truyền ngữ cảnh nào xuống Lambda.
• D. Triển khai HTTP Proxy integration và cấu hình proxy với các phiên bản — thêm một tầng proxy tự dựng để làm việc mà stage đã làm sẵn. Nhiều hạ tầng hơn, nhiều chỗ hỏng hơn, và phải tự bảo trì logic định tuyến.

Ghi nhớ

Ba cách phiên bản hoá API — thường kết hợp cả ba: | Cách | Ví dụ | |---|---| | Stage | /v1, /v2 — cơ chế dựng sẵn của API Gateway | | Đường dẫn trong resource | /v1/don-hang, /v2/don-hang | | Header | Accept: application/vnd.api.v2+json |

Những gì cấu hình riêng được cho từng stage: | Cấu hình | Ghi chú | |---|---| | Stage variables | truyền ngữ cảnh xuống backend | | Throttling | request/giây và burst | | Caching | tính tiền theo GIỜ — nhớ tắt ở stage dev | | Logging và X-Ray | mức log, dataTrace | | WAF Web ACL | — | | Canary release | chia % traffic sang bản mới trong cùng stage |

Canary release đáng biết: nó cho phép thử phiên bản mới với một tỷ lệ nhỏ traffic ngay trong một stage, thay vì tạo stage mới:

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations op=replace,path=/canarySettings/percentTraffic,value=10

Và một cảnh báo quan trọng khi dùng stage variable với Lambda: API Gateway không tự thêm quyền vào resource-based policy của hàm cho các alias động. Bạn phải tự thêm quyền cho MỌI alias có thể được gọi — thiếu là API trả về 500 mà không có thông báo gì hữu ích:

aws lambda add-permission --function-name xu-ly --qualifier v2 \
  --statement-id ApiGatewayInvokeV2 --action lambda:InvokeFunction \
  --principal apigateway.amazonaws.com

Đáp án

C và E.

• C — AWS CodeBuild để chạy test trên mã nguồn
• E — AWS CodeDeploy để cài mã đã biên dịch lên tài nguyên AWS

Vì sao đúng

Đề hỏi hai việc cụ thể, và mỗi việc thuộc về đúng một dịch vụ:

C — CodeBuild chạy test. Nó là dịch vụ build được quản lý: biên dịch mã, chạy kiểm thử, và đóng gói artifact.

version: 0.2
phases:
  build:
    commands:
      - mvn test              # ← chạy test
      - mvn package
reports:
  bao-cao-test:
    files: ['target/surefire-reports/*.xml']
    file-format: JUNITXML

Phần reports đáng chú ý: CodeBuild hiển thị kết quả test trực quan ngay trong Console, kèm tỷ lệ đạt và lịch sử theo thời gian.

E — CodeDeploy cài đặt mã. Nó tự động hoá việc triển khai lên EC2, on-premises, ECS và Lambda, với các hook cho từng giai đoạn:

version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/ung-dung
hooks:
  ApplicationStop:  [{location: scripts/dung.sh}]
  AfterInstall:     [{location: scripts/cai-dat.sh}]
  ApplicationStart: [{location: scripts/khoi-dong.sh}]
  ValidateService:  [{location: scripts/kiem-tra.sh}]

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

• B. CodePipeline để chạy test — CodePipeline điều phối, nó không tự chạy test. Nó gọi CodeBuild làm việc đó. Nó là cái bao trùm, không phải cái thực thi.
• D. CodeCommit để cài mã lên tài nguyên AWS — CodeCommit là kho lưu trữ mã nguồn. Nó không triển khai gì.
• A. Cloud9 để chạy test — Cloud9 là IDE trên trình duyệt. Bạn chạy test thủ công trong đó khi phát triển, nhưng nó không phải một bước tự động trong pipeline.

Ghi nhớ

Vai trò từng dịch vụ trong một pipeline CI/CD:

CodeCommit → CodeBuild → CodeDeploy
 (lưu mã)    (build+test)  (triển khai)
      └────── CodePipeline điều phối tất cả ──────┘

Câu thần chú: CodePipeline là nhạc trưởng; CodeBuild và CodeDeploy là nhạc công.

Điểm mạnh riêng của CodeDeploy so với các cách triển khai khác: nó là dịch vụ duy nhất của AWS triển khai được lên máy chủ on-premises — chỉ cần cài CodeDeploy agent và đăng ký máy vào một deployment group.

(Ghi chú thời sự: CodeCommit ngừng nhận khách hàng mới từ 7/2024, nhưng CodeBuild, CodeDeploy và CodePipeline vẫn phát triển bình thường và làm việc tốt với GitHub, GitLab, Bitbucket qua CodeStar Connections.)

Đáp án

D — Sửa API hiện có để thêm request validation, triển khai sang một stage mới, kiểm thử ở đó, rồi mới triển khai sang stage production.

Vì sao đúng

Đây chính là lý do stage tồn tại trong API Gateway: cùng một định nghĩa API, nhiều bản triển khai độc lập với URL riêng.

Định nghĩa API (một bản duy nhất)
    ├── deploy → stage "test" → https://abc123.../test   ← kiểm thử ở đây
    └── deploy → stage "prod" → https://abc123.../prod   ← không bị ảnh hưởng

Quy trình chỉ gồm hai lệnh:

# 1. Thêm request validator vào API
aws apigateway create-request-validator --rest-api-id abc123 \
  --name kiem-tra-body --validate-request-body --validate-request-parameters

# 2. Triển khai sang stage test — production KHÔNG đổi
aws apigateway create-deployment --rest-api-id abc123 --stage-name test

# 3. Kiểm thử bằng công cụ bất kỳ
curl -X POST https://abc123.execute-api.ap-southeast-1.amazonaws.com/test/don-hang -d '{...}'

# 4. Hài lòng thì mới triển khai sang production
aws apigateway create-deployment --rest-api-id abc123 --stage-name prod

Điểm mấu chốt khiến nó "least operational overhead": thay đổi trong định nghĩa API không có hiệu lực cho tới khi bạn deploy sang stage. Nên bạn sửa API thoải mái, kiểm thử ở stage test, mà production vẫn chạy bản cũ nguyên vẹn.

Không phải sao chép API, không phải quản lý hai bản định nghĩa, không có nguy cơ hai bản lệch nhau.

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

• A. Nhân bản API, thêm validation, kiểm thử, rồi sửa API gốc — làm hai lần cùng một việc: bạn phải sửa validation ở bản sao để thử, rồi sửa lại lần nữa ở bản gốc. Đó là chỗ dễ sai — thứ bạn kiểm thử không phải thứ bạn triển khai.
• C. Xuất OpenAPI, tạo API mới từ tệp đó, thêm validation, kiểm thử, rồi sửa API gốc — cùng vấn đề với A nhưng nhiều bước hơn: export, import, sửa, kiểm thử, rồi lại sửa bản gốc.
• B. Tạo API hoàn toàn mới từ đầu — nhiều công sức nhất: dựng lại toàn bộ resource, method, integration, rồi vẫn phải sửa API gốc. Và bản dựng lại rất dễ khác bản thật ở những chi tiết nhỏ.

Ghi nhớ

Những gì cấu hình riêng được cho từng stage: | Cấu hình | Ghi chú | |---|---| | Stage variables | truyền ngữ cảnh xuống backend | | Throttling | request/giây và burst | | Caching | tính phí theo GIỜ — nhớ tắt ở stage test | | Logging, X-Ray | mức log, dataTrace | | WAF Web ACL | — | | Canary release | chia % traffic ngay trong một stage |

Về request validation — tính năng đang được kiểm thử trong đề: | Kiểm tra | Cách khai | |---|---| | Body khớp JSON Schema | --validate-request-body + Model | | Tham số bắt buộc | --validate-request-parameters |

Nó chặn request sai ngay tại API Gateway, trả về 400 mà không gọi backend — vừa bảo vệ Lambda vừa tiết kiệm chi phí.

Nguyên tắc chung khi làm bài: đề hỏi "least operational overhead" mà có phương án dùng tính năng dựng sẵn (stage) so với phương án nhân bản tài nguyên, thì tính năng dựng sẵn gần như luôn đúng.

Đáp án

B và C.

• B — Đặt chữ ký vào HTTP header tên Authorization
• C — Đặt chữ ký vào query string parameter tên X-Amz-Signature

Vì sao đúng

Signature Version 4 có đúng hai cách truyền chữ ký, và AWS quy định tên cụ thể cho từng cách.

B — qua HTTP header Authorization (cách phổ biến nhất, dùng cho hầu hết lời gọi API):

Authorization: AWS4-HMAC-SHA256
  Credential=AKIAIOSFODNN7EXAMPLE/20260805/ap-southeast-1/s3/aws4_request,
  SignedHeaders=host;x-amz-date,
  Signature=fe5f80f77d5fa3beca038a248ff027d0445342fe2855ddc963176630326f1024

C — qua query string, tham số X-Amz-Signature (gọi là presigned URL):

https://kho.s3.amazonaws.com/tep.pdf
  ?X-Amz-Algorithm=AWS4-HMAC-SHA256
  &X-Amz-Credential=AKIA.../20260805/ap-southeast-1/s3/aws4_request
  &X-Amz-Date=20260805T120000Z
  &X-Amz-Expires=3600
  &X-Amz-SignedHeaders=host
  &X-Amz-Signature=fe5f80f77d5fa3...

Cách thứ hai đặc biệt hữu ích khi không đặt được header — ví dụ khi đưa link cho trình duyệt tải tệp trực tiếp, hoặc nhúng vào thẻ <img>.

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

Ba phương án còn lại đều dùng tên không tồn tại trong đặc tả SigV4:

• A. Header Authorization-Key — tên đúng là Authorization, không có hậu tố.
• D. Query parameter Signature-Token — không tồn tại.
• E. Query parameter X-Amz-Credentials — gần đúng nhưng sai: tham số thật là X-Amz-Credential (số ít), và nó chứa thông tin định danh cùng scope, không phải chữ ký. Chữ ký nằm ở X-Amz-Signature.

Phương án E là bẫy tốt nhất vì nó vừa sai số ít/số nhiều, vừa nhầm giữa hai tham số có vai trò khác nhau.

Ghi nhớ

Bốn bước của SigV4 — đề đã nêu ba bước đầu, và câu hỏi là bước thứ tư: | Bước | Việc | |---|---| | 1 | Canonical request — chuẩn hoá method, URI, query, header, hash payload | | 2 | String to sign — thuật toán, thời điểm, scope, hash của bước 1 | | 3 | Signing key — HMAC nhiều lớp: secret → ngày → region → service → aws4_request | | 4 | Gắn chữ ký — header Authorization hoặc query X-Amz-Signature |

Các tham số của presigned URL: | Tham số | Nội dung | |---|---| | X-Amz-Algorithm | AWS4-HMAC-SHA256 | | X-Amz-Credential | access key + scope (ngày/region/service) | | X-Amz-Date | thời điểm ký, định dạng ISO8601 | | X-Amz-Expires | thời hạn tính bằng giây, tối đa 604.800 (7 ngày) | | X-Amz-SignedHeaders | các header tham gia ký | | X-Amz-Signature | chữ ký |

Lời khuyên thực tế: đừng tự cài đặt SigV4. Mọi AWS SDK đều làm sẵn, và tự viết là hàng chục dòng mã rất dễ sai ở những chi tiết tinh vi (thứ tự header, cách encode ký tự, xử lý payload rỗng). Chỉ nên tìm hiểu chi tiết khi phải gọi API AWS từ môi trường không có SDK.

Đáp án

C — Cấu hình ECS task IAM role cho ứng dụng sử dụng.

Vì sao đúng

Task role gắn quyền vào task definition, tức là vào từng container. Ứng dụng bên trong container tự động nhận credential tạm thời — không có access key nào nằm ở đâu cả:

{
  "family": "ung-dung-dynamodb",
  "taskRoleArn": "arn:aws:iam::123456789012:role/TaskRole-UngDung",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [{"name": "ung-dung", "image": "..."}]
}

Mã ứng dụng không cần đổi một dòng nào — AWS SDK tự tìm credential qua endpoint riêng của task:

import boto3
dynamodb = boto3.resource('dynamodb')      # SDK tự lấy credential từ task role

Vì sao đây là cách an toàn nhất: | Lợi ích | Chi tiết | |---|---| | Không có credential dài hạn | không có gì để lộ, để commit nhầm, hay để xoay vòng | | Tự động xoay vòng | AWS làm mới credential | | Cô lập theo container | mỗi task chỉ có quyền của chính nó | | Đổi quyền tức thì | sửa policy của role, không cần triển khai lại |

Dòng thứ ba đáng nhấn mạnh: nếu nhiều service khác nhau chạy chung một EC2 instance, task role đảm bảo container này không dùng được quyền của container kia.

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

• B. Thêm quyền vào ECS instance profile — đây là bẫy chính. Instance profile gắn quyền ở mức máy chủ, nên MỌI container trên máy đó đều thừa hưởng — kể cả container của service khác. Vi phạm đặc quyền tối thiểu. (Và nó không dùng được với Fargate, nơi không có instance nào.)
• A. Cấu hình tệp credentials với access key mới và D. Đặt access key vào biến môi trường — cả hai đều giữ nguyên vấn đề gốc: vẫn có credential dài hạn phải bảo vệ và xoay vòng thủ công. Phương án D còn tệ hơn: biến môi trường trong task definition hiện nguyên văn trong Console và CloudTrail cho bất kỳ ai có quyền ecs:DescribeTaskDefinition.

Ghi nhớ

Ba loại role của ECS — nhầm lẫn giữa chúng là lỗi cấu hình phổ biến nhất: | Role | Ai dùng | Cho việc gì | |---|---|---| | Task role | mã trong container | gọi DynamoDB, S3, SQS… | | Task execution role | ECS agent | kéo image từ ECR, ghi log, đọc secret | | Instance profile (EC2 launch type) | ECS agent trên host | đăng ký instance vào cluster |

Cách nhớ nhanh:

• "Ứng dụng của tôi cần gọi dịch vụ AWS" ⇒ task role
• "Không kéo được image / không thấy log" ⇒ execution role

Nguyên tắc bao trùm, áp cho mọi nơi mã chạy trên AWS: không bao giờ dùng access key dài hạn. | Nơi chạy | Cơ chế | |---|---| | EC2 | instance profile | | ECS / Fargate | task role | | Lambda | execution role | | EKS | IAM Roles for Service Accounts (IRSA) | | On-premises | IAM Roles Anywhere, SSM hybrid activation |

Và với EC2 launch type, nên đặt thêm ECS_AWSVPC_BLOCK_IMDS=true (hoặc dùng network mode awsvpc) để chặn container truy cập instance metadata — nếu không, container vẫn lấy được credential của instance profile bất chấp task role.

Đáp án

C — Publish message lên SNS topic và đăng ký từng SQS queue vào topic đó.

Vì sao đúng

Đây là mẫu fan-out, và nó là kiến trúc chuẩn cho đúng nhu cầu trong đề: một message tới nhiều hàng đợi.

Ứng dụng → SNS topic ─┬→ SQS queue A → xử lý thanh toán
                      ├→ SQS queue B → cập nhật kho
                      └→ SQS queue C → gửi email

Ứng dụng publish một lần, SNS tự nhân bản tới mọi subscriber:

sns.publish(
    TopicArn='arn:aws:sns:ap-southeast-1:123456789012:don-hang-moi',
    Message=json.dumps({'don_hang_id': 'DH-001', 'tong_tien': 500000})
)

Ba lợi ích khiến đây là "BEST solution": | Lợi ích | Chi tiết | |---|---| | Ghép lỏng | bên gửi không cần biết có bao nhiêu hàng đợi | | Mở rộng không sửa mã | thêm hàng đợi mới chỉ là thêm một subscription | | Không mất message | SQS lưu tới 14 ngày nếu consumer đang hỏng |

Và message filtering làm mẫu này còn mạnh hơn — mỗi hàng đợi chỉ nhận loại message nó quan tâm:

{"loai_don": ["quoc_te"], "tong_tien": [{"numeric": [">", 1000000]}]}

Hai lưu ý khi cấu hình: cần queue policy cho phép SNS gửi message, và nên bật raw message delivery nếu không muốn payload bị bọc trong lớp vỏ JSON của SNS.

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

• A. Publish vào một SQS queue rồi dùng Lambda nhân bản sang các queue khác — tự dựng lại chức năng của SNS: thêm một hàng đợi, một hàm Lambda, thêm độ trễ, thêm chi phí, và thêm một chỗ có thể hỏng. Mọi lần thêm hàng đợi mới đều phải sửa mã Lambda.
• B. Step Functions với nhiều Lambda đẩy message vào các queue — phức tạp và tốn kém nhất: Step Functions dùng để điều phối quy trình nghiệp vụ nhiều bước, không phải để nhân bản message. Mỗi lần chuyển trạng thái đều tính tiền.
• D. Tạo workflow Amazon SWF — sai công cụ: SWF điều phối workflow phức tạp có trạng thái. Và AWS đã khuyến nghị dùng Step Functions thay cho SWF từ lâu.

Ghi nhớ

So sánh SNS và SQS: | | SNS (push) | SQS (pull) | |---|---|---| | Mô hình | pub/sub — một tới nhiều | hàng đợi — một tới một | | Cách hoạt động | SNS gọi subscriber | consumer hỏi hàng đợi | | Lưu trữ | không — không ai nhận là mất | giữ tới 14 ngày | | Số người nhận | nhiều | thường một nhóm consumer |

Vì sao mẫu SNS + SQS tốt hơn SNS gọi thẳng Lambda: | Vấn đề | SNS → Lambda | SNS → SQS → Lambda | |---|---|---| | Consumer đang hỏng | message mất | message chờ trong hàng đợi | | Đỉnh tải đột ngột | Lambda bị throttle | hàng đợi san phẳng đỉnh | | Muốn xử lý theo lô | khó | BatchSize tới 10.000 | | Message hỏng | DLQ của Lambda | DLQ của hàng đợi, có maxReceiveCount |

Nhận dạng nhanh trong đề: "nhiều hàng đợi", "nhiều consumer", "fan-out" ⇒ SNS + SQS. Đây là một trong những mẫu kiến trúc được hỏi nhiều nhất.

Đáp án

C — Dùng Kinesis Data Streams với Kinesis Client Library (KCL) để nạp và phân phối message.

Vì sao đúng

Đề nêu bốn yêu cầu, và chúng cùng chỉ về Kinesis Data Streams:

1. Vài terabyte mỗi giờ từ rất nhiều nguồn phân tán
2. Liên tục 24/7
3. Thời gian thực cho phân tích an ninh
4. Dashboard vận hành trực tiếp

Kinesis Data Streams được thiết kế đúng cho quy mô và độ trễ đó: | Đặc điểm | Chi tiết | |---|---| | Độ trễ | dưới một giây từ khi ghi tới khi đọc được | | Thông lượng | 1 MB/giây ghi và 2 MB/giây đọc MỖI SHARD, thêm shard là mở rộng | | Nhiều consumer đồng thời | phân tích an ninh và dashboard đọc song song cùng một luồng | | Phát lại được | giữ dữ liệu 24 giờ đến 365 ngày |

Điểm thứ ba rất quan trọng với đề này: cùng một luồng phục vụ được nhiều ứng dụng độc lập — điều mà SQS không làm được (message bị xoá sau khi một consumer xử lý).

KCL là thư viện lo phần khó của việc đọc: | KCL tự làm | Chi tiết | |---|---| | Phân phối shard giữa các worker | mỗi worker nhận một phần | | Checkpoint | ghi vị trí đã đọc vào DynamoDB | | Tự cân bằng lại | khi worker chết hoặc số shard thay đổi |

Với thông lượng vài TB/giờ, số shard cần khá lớn:

2 TB/giờ ≈ 570 MB/giây → cần khoảng 570 shard

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

• B. SQS + fleet EC2 — không phải thời gian thực đúng nghĩa và quan trọng hơn: message bị xoá sau khi xử lý, nên không thể có hai ứng dụng độc lập (phân tích an ninh và dashboard) cùng đọc. Muốn vậy phải dựng nhiều hàng đợi và fan-out — phức tạp hơn hẳn.
• A. Ghi vào S3 rồi xử lý bằng Redshift — kiến trúc theo lô: phải chờ tệp ghi xong, chờ nạp vào Redshift. Độ trễ tính bằng phút tới giờ, trái yêu cầu "real time".
• D. AWS Data Pipeline — dịch vụ điều phối di chuyển dữ liệu theo lô, theo lịch. Không phải nạp luồng, và AWS đã ngừng phát triển dịch vụ này (không nhận khách hàng mới từ 7/2024).

Ghi nhớ

Bốn dịch vụ nạp dữ liệu, và cách chọn: | Dịch vụ | Độ trễ | Nhiều consumer | Phát lại | |---|---|---|---| | Kinesis Data Streams | dưới giây | ✅ | ✅ tới 365 ngày | | Kinesis Data Firehose | ~60 giây | ❌ (chỉ tới đích) | ❌ | | SQS | dưới giây | ❌ (xoá sau khi đọc) | ❌ | | MSK (Kafka) | dưới giây | ✅ | ✅ |

Cách chọn nhanh:

• Dưới giây + nhiều consumer + phát lại ⇒ Data Streams
• Chỉ nạp vào S3/Redshift, gần thời gian thực, rẻ ⇒ Firehose
• Hàng đợi công việc, mỗi message một consumer ⇒ SQS

Hai chế độ năng lực của Data Streams: | Chế độ | Đặc điểm | |---|---| | Provisioned | tự quản số shard, rẻ hơn khi tải đều | | On-demand | tự co giãn tới 200 MB/giây, không quản shard |

Và Enhanced Fan-Out đáng biết khi có nhiều consumer: mỗi consumer nhận 2 MB/giây riêng cho mỗi shard thay vì chia nhau, kèm độ trễ khoảng 70 mili giây — đúng thứ cần khi phân tích an ninh và dashboard không được làm chậm lẫn nhau.

Đáp án

B — Dùng tính năng canary release deployment của API Gateway, cấu hình canarySettings để chuyển một phần traffic.

Vì sao đúng

API Gateway có canary release dựng sẵn ngay trong stage — không cần thêm hạ tầng nào:

# Tạo canary với 10% traffic sang phiên bản mới
aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations \
    op=replace,path=/canarySettings/percentTraffic,value=10.0 \
    op=replace,path=/canarySettings/useStageCache,value=false

# Hài lòng thì chuyển hết
aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations op=replace,path=/canarySettings/percentTraffic,value=100.0

# Rồi hợp nhất canary thành bản chính
aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations op=remove,path=/canarySettings

Cách nó hoạt động: một stage duy nhất phục vụ hai bản triển khai, và API Gateway tự chia traffic theo tỷ lệ bạn đặt:

https://abc123.../prod  ──90%──→ deployment cũ
                        ──10%──→ deployment canary

Ba đặc điểm khiến nó là cách "MOST straightforward": | Đặc điểm | Chi tiết | |---|---| | Cùng một URL | client không phải đổi gì | | Metric và log tách riêng | so sánh được tỷ lệ lỗi giữa hai bản | | Rollback tức thì | đặt percentTraffic về 0 | | Stage variable riêng cho canary | trỏ sang alias Lambda khác |

Điểm thứ hai rất quan trọng: CloudWatch tách metric của canary, nên bạn thấy ngay bản mới có tỷ lệ lỗi cao hơn không trước khi mở rộng.

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

• A. Viết Lambda tuỳ chỉnh để phân phối traffic giữa hai phiên bản — tự dựng lại tính năng đã có: thêm một hàm phải viết và bảo trì, thêm độ trễ ở mọi request, và tự lo phần đo lường.
• C. Dùng failover routing policy của Route 53 để chuyển một phần trăm traffic — sai loại chính sách: failover routing là chủ động – dự phòng, nó gửi toàn bộ traffic tới endpoint chính và chỉ chuyển khi endpoint đó hỏng. Chính sách chia theo tỷ lệ là weighted routing — nhưng ngay cả weighted routing cũng thô hơn canary của API Gateway (phụ thuộc TTL của DNS, không tách được metric).
• D. Triển khai API mới trong VPC riêng và dùng CloudFront phân phối traffic — phức tạp nhất: thêm VPC, thêm distribution, và CloudFront không có cơ chế chia traffic theo tỷ lệ giữa hai origin theo cách đơn giản (phải viết Lambda@Edge).

Ghi nhớ

Các cơ chế phát hành từng phần trên AWS: | Dịch vụ | Cơ chế | |---|---| | API Gateway | canary release trong stage | | Lambda | alias với weighted routing | | ALB | weighted target group | | CodeDeploy (Lambda/ECS) | canary, linear | | Route 53 | weighted routing (thô, phụ thuộc DNS TTL) | | Elastic Beanstalk | traffic splitting |

Các thuộc tính của canarySettings: | Thuộc tính | Việc | |---|---| | percentTraffic | % traffic sang canary (0–100) | | deploymentId | bản triển khai nào là canary | | stageVariableOverrides | stage variable riêng cho canary | | useStageCache | canary có dùng chung cache không |

stageVariableOverrides là mảnh ghép hay dùng nhất: đặt alias = "v2" cho canary trong khi stage chính vẫn alias = "v1", thì 10% traffic đi vào Lambda version mới mà không đụng gì tới cấu hình integration.

Quy trình canary an toàn: 10% → theo dõi metric 30 phút → 50% → theo dõi → 100% → hợp nhất. Thấy tỷ lệ lỗi tăng ở bất kỳ bước nào thì đặt về 0 — mất vài giây.