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

Đáp án

B — Thêm annotation vào các custom subsegment.

Vì sao đúng

X-Ray cho phép gắn hai loại dữ liệu vào segment, và chỉ một loại tìm kiếm được:

Đề nói rõ lập trình viên muốn lọc kết quả theo cặp khoá–giá trị, nên bắt buộc phải dùng annotation:

from aws_xray_sdk.core import xray_recorder

with xray_recorder.in_subsegment('xu-ly-don-hang') as subsegment:
    subsegment.put_annotation('don_hang_id', 'DH-12345')
    subsegment.put_annotation('loai_khach', 'vip')
    subsegment.put_annotation('tong_tien', 500000)
    xu_ly()

Rồi tìm kiếm bằng filter expression:

annotation.don_hang_id = "DH-12345"
annotation.loai_khach = "vip" AND responsetime > 3
annotation.tong_tien > 1000000

Với ứng dụng sinh lượng trace rất lớn như trong đề, khả năng lọc này là thứ biến đống dữ liệu thành công cụ chẩn đoán dùng được.

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

• A. Thêm metadata vào custom subsegment — đây là bẫy chính, và khác biệt cần thuộc: metadata KHÔNG được đánh chỉ mục, nên không lọc được. Nó vẫn hữu ích — chứa được cấu trúc phức tạp và không giới hạn số lượng — nhưng chỉ để đọc khi đã mở trace ra.
• C. Thiết lập sampling cho custom subsegment — sampling quyết định BAO NHIÊU request được ghi lại, không quyết định tìm kiếm chúng thế nào. Nó giảm khối lượng dữ liệu, nhưng không cho khả năng lọc.
• D. Thêm cặp khoá–giá trị vào Trace ID — Trace ID có định dạng cố định, không nhét thêm dữ liệu được:

  1-5f84c7a1-9d2e1f3a4b5c6d7e8f9a0b1c
  │  │        └─ 96 bit ngẫu nhiên
  │  └─ thời điểm (epoch, hex)
  └─ phiên bản
  

Ghi nhớ

So sánh hai loại dữ liệu — đây là quyết định thiết kế quan trọng nhất khi dùng X-Ray: | | Annotation | Metadata | |---|---|---| | Tìm kiếm được | ✅ | ❌ | | Số lượng tối đa | 50 mỗi trace | không giới hạn | | Kiểu dữ liệu | chuỗi, số, boolean | bất kỳ JSON nào | | Dùng cho | user_id, order_id, environment, tenant | payload đầy đủ, chi tiết để đọc |

Nguyên tắc: thứ gì cần TÌM thì là annotation, thứ gì chỉ để ĐỌC thì là metadata.

Ba trường tích hợp sẵn cũng tìm được, với cú pháp riêng (không có tiền tố annotation.):

user("nguyenvana")
service("api-don-hang") { fault = true }
http.status = 500
responsetime > 5

Và với ứng dụng sinh nhiều trace, sampling rule là công cụ đi kèm quan trọng — nó cho phép ghi đầy đủ những request bạn quan tâm trong khi lấy mẫu thưa phần còn lại:

{
  "rule_name": "don-hang-vip",
  "priority": 100,
  "fixed_target": 10,
  "rate": 1.0,
  "service_name": "api-don-hang",
  "http_method": "POST",
  "url_path": "/don-hang/vip/*"
}

Mặc định X-Ray chỉ lấy 1 request mỗi giây cộng 5% số còn lại — nên nếu không khai rule riêng, những request hiếm mà quan trọng rất dễ không được ghi lại.

Đáp án

B — Tạo bucket policy từ chối mọi request PutObject không kèm header x-amz-server-side-encryption.

Vì sao đúng

Chính sách công ty là bắt buộc, nên cần một cơ chế ngăn chặn, không phải phát hiện. Bucket policy với Deny làm đúng việc đó:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "BatBuocMaHoa",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::giao-dich-nhay-cam/*",
    "Condition": {
      "Null": {"s3:x-amz-server-side-encryption": "true"}
    }
  }]
}

Điều kiện Null đọc là: "nếu header đó KHÔNG có mặt thì từ chối". Request thiếu header sẽ nhận 403 Access Denied — object không bao giờ được ghi vào bucket ở dạng chưa mã hoá.

Muốn chặt hơn nữa, ép luôn thuật toán cụ thể:

"Condition": {
  "StringNotEquals": {"s3:x-amz-server-side-encryption": "aws:kms"}
}

Vì Deny tường minh thắng mọi Allow, không IAM policy nào ở bất kỳ đâu có thể lách qua — kể cả policy rộng từ tài khoản khác. Đó là điều làm cách này phù hợp cho yêu cầu tuân thủ.

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

• D. Bật SSE-S3 mặc định trên bucket — đây là phương án đáng bàn nhất, và nó tốt nhưng chưa đủ cho một chính sách bắt buộc. Default encryption mã hoá mọi object mới, kể cả khi client không gửi header — nên trên thực tế dữ liệu vẫn được bảo vệ. Nhưng nó không TỪ CHỐI request nào: client vẫn gửi được request không mã hoá và nhận về 200 OK, nên không có tín hiệu tuân thủ nào. Với chính sách kiểu "mọi dữ liệu ghi vào phải được mã hoá", cách chuẩn là bucket policy chặn + default encryption làm lưới an toàn.
• A. Bucket policy từ chối PutObject có x-amz-acl là public-read… — sai đối tượng hoàn toàn: điều kiện đó kiểm soát quyền truy cập công khai, không liên quan gì tới mã hoá.
• C. CloudWatch alarm báo cho quản trị viên khi có object chưa mã hoá — phát hiện sau khi việc đã xảy ra: dữ liệu nhạy cảm đã nằm trên S3 ở dạng chưa mã hoá rồi mới có người biết. Không đáp ứng được yêu cầu "must be encrypted".

Ghi nhớ

Bốn cách kiểm soát mã hoá trên S3, theo mức độ chặt: | Cách | Ngăn chặn được | Ghi chú | |---|---|---| | Bucket policy Deny | ✅ từ chối request | cách chuẩn cho tuân thủ | | Default encryption | ❌ (nhưng tự mã hoá) | bật từ 2023 cho mọi bucket | | S3 Inventory + báo cáo | ❌ phát hiện sau | kiểm toán định kỳ | | CloudWatch/Config rule | ❌ phát hiện sau | cảnh báo |

Các điều kiện hay dùng trong bucket policy: | Điều kiện | Kiểm tra | |---|---| | s3:x-amz-server-side-encryption | thuật toán mã hoá at-rest | | s3:x-amz-server-side-encryption-aws-kms-key-id | đúng khoá KMS nào | | aws:SecureTransport | bắt buộc HTTPS (mã hoá khi truyền) | | s3:x-amz-acl | ACL của object |

Bộ đôi policy thường đi cùng nhau cho yêu cầu tuân thủ đầy đủ:

// 1. Bắt buộc mã hoá at-rest
{"Effect":"Deny","Principal":"*","Action":"s3:PutObject","Resource":"...*",
 "Condition":{"Null":{"s3:x-amz-server-side-encryption":"true"}}}

// 2. Bắt buộc HTTPS (mã hoá in-transit)
{"Effect":"Deny","Principal":"*","Action":"s3:*","Resource":["...","...*"],
 "Condition":{"Bool":{"aws:SecureTransport":"false"}}}

Hai statement này phủ cả hai chiều — và đó mới là bộ hoàn chỉnh cho dữ liệu giao dịch nhạy cảm.

Đáp án

D — Blue/green với canary.

Vì sao đúng

Đề mô tả chính xác hành vi của canary:

1. Đưa 10% traffic sang phiên bản mới
2. Sau một khoảng thời gian, chuyển toàn bộ phần còn lại

Đó là định nghĩa của cấu hình canary — hai bước, một khoảng chờ ở giữa:

CodeDeployDefault.ECSCanary10Percent5Minutes
  → 10% traffic sang bản mới
  → chờ 5 phút
  → 90% còn lại chuyển hết

aws deploy create-deployment \
  --application-name ung-dung-ecs \
  --deployment-group-name nhom-production \
  --deployment-config-name CodeDeployDefault.ECSCanary10Percent5Minutes \
  --revision file://appspec.json

Lưu ý về vế "blue/green": với Amazon ECS, CodeDeploy CHỈ hỗ trợ blue/green — không có lựa chọn nào khác. Nên phần cần chọn thực sự là cấu hình chuyển traffic, và canary là cấu hình khớp với mô tả trong đề.

Trong lúc canary chạy, cả hai task set cùng tồn tại, nên rollback chỉ là trỏ listener về task set cũ — gần như tức thì.

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

• C. Blue/green với linear — đây là phương án gần nhất, và khác biệt nằm ở số bước: linear chuyển traffic theo nhiều nấc đều nhau, ví dụ ECSLinear10PercentEvery1Minute là 10% → 20% → 30% → … → 100%. Đề mô tả đúng hai bước (10% rồi phần còn lại), đó là canary.
• A. Blue/green với all at once — chuyển 100% traffic ngay lập tức, không có giai đoạn 10% nào.
• B. Rolling update — không hỗ trợ với CodeDeploy trên ECS. (ECS có kiểu triển khai rolling update riêng của nó — ECS deployment controller — nhưng đó là cơ chế của ECS, không dùng CodeDeploy, và nó cập nhật dần các task chứ không chia traffic theo tỷ lệ.)

Ghi nhớ

Phân biệt ba cấu hình chuyển traffic — đây là điểm được hỏi rất thường xuyên: | Cấu hình | Cách chuyển | |---|---| | AllAtOnce | 100% ngay — nhanh nhất, rủi ro cao nhất | | Canary | HAI bước: X% → chờ → 100% | | Linear | NHIỀU bước đều nhau: +X% mỗi N phút |

Các cấu hình dựng sẵn cho ECS:

CodeDeployDefault.ECSAllAtOnce
CodeDeployDefault.ECSCanary10Percent5Minutes
CodeDeployDefault.ECSCanary10Percent15Minutes
CodeDeployDefault.ECSLinear10PercentEvery1Minutes
CodeDeployDefault.ECSLinear10PercentEvery3Minutes

Tên có quy tắc rõ ràng: <nền tảng><kiểu><tỷ lệ><thời gian> — đọc tên là biết hành vi.

Và hai tầng khái niệm của CodeDeploy, đừng lẫn:

Deployment TYPE:   In-place | Blue/green      ← ECS chỉ có blue/green
Deployment CONFIG: AllAtOnce | Canary | Linear ← đây mới là thứ cần chọn

Hỗ trợ theo nền tảng: | Nền tảng | Type | |---|---| | EC2 / On-premises | in-place hoặc blue/green | | ECS | chỉ blue/green | | Lambda | chỉ blue/green |

Nên với ECS và Lambda, câu hỏi "chọn deployment type nào" luôn có sẵn đáp án — phần thực sự phải suy nghĩ là deployment configuration.

Đáp án

D — Nhập chứng chỉ của bên thứ ba vào ACM, gắn nó với custom domain name trong API Gateway, rồi tạo bản ghi alias (A) trong Route 53.

Vì sao đúng

Có ba bước, và mỗi bước loại bỏ một phương án sai.

Bước 1 — nhập chứng chỉ vào ACM. API Gateway không nhận chứng chỉ trực tiếp; nó chỉ tham chiếu tới chứng chỉ nằm trong ACM. Chứng chỉ từ bên thứ ba nhập được:

aws acm import-certificate \
  --certificate fileb://chung-chi.pem \
  --private-key fileb://khoa-rieng.pem \
  --certificate-chain fileb://chuoi-ca.pem \
  --region us-east-1

Region quan trọng, và nó phụ thuộc vào loại endpoint: | Loại endpoint | Region của chứng chỉ | |---|---| | Edge-optimized (qua CloudFront) | bắt buộc us-east-1 | | Regional | cùng Region với API (ở đây là us-west-2) |

Đề nói dùng CloudFront, tức là edge-optimized — nên chứng chỉ phải ở us-east-1.

Bước 2 — tạo custom domain name trong API Gateway:

aws apigateway create-domain-name \
  --domain-name api.congty.com \
  --certificate-arn arn:aws:acm:us-east-1:123456789012:certificate/abc

Bước 3 — bản ghi alias (A) trong Route 53, trỏ tới tên phân phối của API Gateway. Alias tốt hơn CNAME vì nó dùng được cho tên miền gốc (congty.com, không chỉ api.congty.com) và miễn phí truy vấn.

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

• A. Cài chứng chỉ trực tiếp lên API Gateway và tạo CNAME — API Gateway không nhận chứng chỉ trực tiếp; nó phải đi qua ACM. Và CNAME kém hơn alias.
• B. Dùng chứng chỉ trực tiếp với CloudFront, bỏ qua API Gateway — CloudFront cũng không nhận chứng chỉ trực tiếp — nó cũng lấy từ ACM. Và "bỏ qua API Gateway" thì không còn API để phục vụ.
• C. Route 53 với simple routing trỏ thẳng vào API Gateway — thiếu hẳn phần chứng chỉ: không có custom domain name và không có chứng chỉ thì tên miền riêng không hoạt động với HTTPS.

Ghi nhớ

Hai loại chứng chỉ trong ACM: | | Do ACM cấp | Nhập từ ngoài | |---|---|---| | Chi phí | miễn phí | trả cho CA bên ngoài | | Tự gia hạn | ✅ (với DNS validation) | ❌ phải tự nhập lại | | Xuất private key | ❌ | (bạn đã có sẵn) |

Dòng in đậm là điều quan trọng nhất khi dùng chứng chỉ nhập vào: đặt lịch nhắc trước khi hết hạn, hoặc bắt sự kiện EventBridge:

{"source": ["aws.acm"], "detail-type": ["ACM Certificate Approaching Expiration"]}

Hai loại endpoint của API Gateway: | | Edge-optimized | Regional | |---|---|---| | Đường đi | qua CloudFront edge | thẳng tới Region | | Chứng chỉ ở | us-east-1 | cùng Region với API | | Hợp cho | người dùng toàn cầu | client trong cùng Region |

Và nhớ tạo base path mapping để nối domain với stage:

aws apigateway create-base-path-mapping \
  --domain-name api.congty.com --rest-api-id abc123 --stage prod

Thiếu bước này thì tên miền phân giải được nhưng không trỏ tới API nào — trả về lỗi 403 khó hiểu.

Đáp án

B — Người dùng dùng được mọi action của SQS, nhưng chỉ với các hàng đợi có tên bắt đầu bằng staging-queue.

Vì sao đúng

Đọc policy theo hai trục:

"Action": "sqs:*",                                        ← MỌI action của SQS
"Resource": "arn:aws:sqs:*:513246782345:staging-queue*"    ← tên bắt đầu bằng staging-queue

Trục Action: sqs:* bao gồm tất cả — CreateQueue, SendMessage, ReceiveMessage, DeleteMessage, DeleteQueue, SetQueueAttributes, AddPermission…

Trục Resource: phân tích cấu trúc ARN:

arn:aws:sqs:*:513246782345:staging-queue*
            │      │              └─ tên hàng đợi, có ký tự đại diện *
            │      └─ ID tài khoản
            └─ Region: * nghĩa là MỌI Region

Dấu * ở cuối là ký tự đại diện cho phần còn lại của tên, nên nó khớp:

staging-queue          ✅
staging-queue-1        ✅
staging-queue-orders   ✅
staging-queue-bat-ky   ✅
production-queue       ❌
queue-staging          ❌

Đó chính xác là mô tả của phương án B.

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

• A. Người dùng tạo được hàng đợi tên staging-queue — đúng, nhưng chưa đầy đủ: đây chỉ là một trong rất nhiều thứ policy cho phép. B mô tả trọn vẹn phạm vi quyền, còn A chỉ nêu một trường hợp.
• C. Được cấp quyền truy cập chéo tài khoản từ tài khoản 513246782345 — hiểu ngược vai trò của policy. Đây là identity-based policy gắn vào chính IAM user, không phải resource-based policy. Số tài khoản trong ARN chỉ nói hàng đợi thuộc tài khoản nào. Muốn truy cập chéo tài khoản thật sự thì tài khoản kia phải có queue policy cho phép — identity-based policy một mình không đủ.
• D. Áp dụng được resource-based policy lên hàng đợi staging-queue — đúng nhưng lại chỉ là một phần: sqs:* có bao gồm sqs:AddPermission và sqs:SetQueueAttributes (hai action dùng để đặt queue policy). Nhưng cũng như A, nó chỉ nêu một khả năng nhỏ trong phạm vi rộng mà B mô tả.

Bài học chung từ A và D: khi câu hỏi hỏi "policy này cho phép làm gì", hãy chọn phương án mô tả TOÀN BỘ phạm vi, không phải một ví dụ đúng lẻ.

Ghi nhớ

Cấu trúc ARN của SQS:

arn:aws:sqs:<region>:<account-id>:<queue-name>

Hai ký tự đại diện dùng được trong Resource: | Ký tự | Khớp | |---|---| | * | không hoặc nhiều ký tự bất kỳ | | ? | đúng một ký tự |

Vài mẫu hữu ích:

arn:aws:sqs:*:*:*                        mọi hàng đợi ở mọi nơi
arn:aws:sqs:ap-southeast-1:123:prod-*    hàng đợi prod trong một Region
arn:aws:sqs:*:123:*-dlq                  mọi dead-letter queue

Phân biệt hai loại policy: | | Identity-based | Resource-based | |---|---|---| | Gắn vào | user, group, role | hàng đợi SQS, bucket S3, topic SNS | | Có Principal | ❌ | ✅ | | Truy cập chéo tài khoản | cần cả hai phía | khai principal trực tiếp |

Và quy tắc đánh giá quyền: cần ít nhất một Allow và không có Deny nào. Với truy cập chéo tài khoản, cả hai phía đều phải cho phép — thiếu một bên là bị từ chối.

Đáp án

C — AWS CodeCommit.

Vì sao đúng

Đề mô tả một hệ thống quản lý phiên bản bằng ba đặc điểm:

1. Chia sẻ mã cho đồng đội xem xét — cần pull request và code review
2. Lưu giữ mã theo thời gian, nhiều phiên bản
3. Theo dõi các lô thay đổi (batch modifications) — chính là commit trong Git

CodeCommit là dịch vụ Git được quản lý, nên nó có đủ cả ba một cách tự nhiên:

git checkout -b tinh-nang/thanh-toan
git add src/api.js src/db.js docs/README.md
git commit -m "Thêm module thanh toán"     # một lô thay đổi nhiều tệp
git push origin tinh-nang/thanh-toan
# rồi tạo pull request để đồng đội review

Cộng thêm các đặc điểm của dịch vụ được quản lý: mã hoá at-rest và in-transit mặc định, lưu trữ dư thừa đa AZ, phân quyền bằng IAM, và pull request có bình luận theo dòng.

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

• D. AWS CodeStar — dịch vụ quản lý dự án: nó tạo sẵn một bộ khung gồm kho mã, pipeline và dashboard. Nhưng bản thân nó không lưu trữ mã — nó dùng CodeCommit cho việc đó. Và AWS đã ngừng hoạt động CodeStar từ 31/7/2024.
• A. AWS CodeDeploy — triển khai mã lên EC2, on-premises, ECS, Lambda. Nó lấy gói từ S3 hoặc GitHub; không lưu trữ và không có lịch sử phiên bản.
• B. AWS Cloud9 — IDE trên trình duyệt. Nó có tính năng cộng tác thời gian thực (nhiều người cùng gõ một tệp), nhưng không phải kho lưu trữ: đóng môi trường là hết, không có commit hay branch nào. (Cloud9 cũng đã ngừng nhận khách hàng mới từ giữa 2024.)

Ghi nhớ

Vai trò từng dịch vụ trong bộ công cụ phát triển của AWS: | Dịch vụ | Việc | |---|---| | CodeCommit | lưu trữ mã nguồn (Git) | | CodeBuild | biên dịch, chạy test, đóng gói | | CodeDeploy | triển khai | | CodePipeline | điều phối toàn bộ | | CodeArtifact | kho package | | CodeGuru | review mã và phân tích hiệu năng bằng ML |

Nhận dạng nhanh: đề nói "version control", "multiple versions", "batch changes", "branching", "collaborate on code" ⇒ CodeCommit.

Vì sao S3 versioning không thay thế được Git (một phương án hay xuất hiện trong các biến thể của câu hỏi này): | | S3 Versioning | Git | |---|---|---| | Đơn vị | một object | một commit gồm nhiều tệp | | Nhánh, merge, diff | ❌ | ✅ | | Ai sửa gì, vì sao | chỉ thời điểm | tác giả + thông điệp + diff | | Review trước khi nhận | ❌ | ✅ pull request |

(Ghi chú thời sự: CodeCommit ngừng nhận khách hàng mới từ 25/7/2024; tài khoản đã dùng vẫn hoạt động bình thường. Với dự án mới, dùng GitHub, GitLab hoặc Bitbucket — nối vào CodePipeline qua CodeStar Connections. Câu hỏi vẫn nằm trong phạm vi kỳ thi, nhưng đừng chọn CodeCommit cho hệ thống mới.)

Đáp án

B — Dùng chiến lược write-through caching.

Vì sao đúng

Đề nêu hai yêu cầu, và chỉ write-through thoả cả hai:

1. Nhất quán mạnh giữa CSDL và cache
2. Độ trễ thấp cho MỌI item trong CSDL

Write-through ghi vào cả CSDL và cache trong cùng một thao tác:

def cap_nhat_san_pham(ma_sp, du_lieu):
    csdl.update(ma_sp, du_lieu)          # ghi CSDL
    cache.set(f'sp:{ma_sp}', du_lieu)    # ghi cache NGAY

Kết quả: cache và CSDL không bao giờ lệch nhau — đúng vế "strong consistency".

Và vế thứ hai cũng được đáp ứng: vì mọi lần ghi đều nạp vào cache, nên mọi item đều có mặt trong cache — không có item nào phải chịu cú đọc chậm đầu tiên. Đó chính là nghĩa của "low latency for ALL items".

Đánh đổi cần biết: | Nhược điểm | Chi tiết | |---|---| | Độ trễ ghi cao hơn | mỗi lần ghi làm hai việc | | Cache chứa cả dữ liệu không ai đọc | tốn bộ nhớ hơn |

Với dữ liệu sản phẩm (đọc nhiều hơn ghi rất nhiều), đây là đánh đổi hợp lý — trả giá ở đường ghi để đường đọc luôn nhanh và luôn đúng.

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

• A. Lazy loading — chỉ nạp vào cache khi có người đọc mà không thấy. Hai vấn đề với đề bài: dữ liệu trong cache có thể cũ sau khi CSDL đã đổi (trượt yêu cầu nhất quán), và item chưa từng được đọc thì chưa có trong cache (trượt yêu cầu độ trễ thấp cho mọi item).
• D. Làm mất hiệu lực cache ở mỗi lần ghi CSDL — đảm bảo được tính nhất quán, nhưng không đảm bảo độ trễ thấp: sau mỗi lần ghi, item đó biến mất khỏi cache, nên lần đọc tiếp theo là một cache miss phải xuống CSDL. Với dữ liệu sản phẩm cập nhật thường xuyên, số cache miss sẽ rất cao.
• C. Thêm TTL ngắn cho mỗi lần ghi — giảm thời gian dữ liệu bị cũ, nhưng không loại bỏ nó: trong khoảng TTL, cache vẫn phục vụ giá trị lỗi thời. Và TTL ngắn nghĩa là cache miss thường xuyên — độ trễ tăng.

Ghi nhớ

So sánh các chiến lược, theo đúng hai tiêu chí của đề: | Chiến lược | Nhất quán | Độ trễ mọi item | |---|---|---| | Write-through | ✅ | ✅ | | Lazy loading | ❌ | ❌ (miss lần đầu) | | Cache invalidation | ✅ | ❌ (miss sau mỗi lần ghi) | | TTL ngắn | ❌ (cũ trong khoảng TTL) | ❌ | | Write-behind | ✅ ở cache | rủi ro mất dữ liệu |

Cách chọn theo từ khoá trong đề: | Đề nhấn mạnh | Chọn | |---|---| | "strong consistency", "real-time", "all items" | write-through | | "tiết kiệm bộ nhớ", "chỉ cache dữ liệu hay dùng" | lazy loading | | Hỏi nhược điểm của write-through | cache phình to, tốn tiền |

Mẫu thực hành tốt nhất trong sản xuất là kết hợp cả ba:

def doc(ma_sp):
    gt = cache.get(f'sp:{ma_sp}')
    if gt is None:                            # lazy loading khi miss
        gt = csdl.get(ma_sp)
        cache.setex(f'sp:{ma_sp}', 3600, gt)
    return gt

def ghi(ma_sp, du_lieu):
    csdl.update(ma_sp, du_lieu)
    cache.setex(f'sp:{ma_sp}', 3600, du_lieu)  # write-through + TTL

TTL ở đây là lưới an toàn: nếu có đường ghi nào bỏ qua cache (job batch, sửa tay trên CSDL), dữ liệu lệch sẽ tự được dọn thay vì tồn tại mãi.

Đáp án

B — Rolling with additional batch.

Vì sao đúng

Đề nêu ba ràng buộc:

1. Không giảm hiệu năng và tính sẵn sàng trong lúc cập nhật
2. Tiết kiệm chi phí nhất trong các phương án thoả điều kiện 1
3. Môi trường có 12 instance

Rolling with additional batch giữ đủ năng lực bằng cách thêm một lô instance TẠM THỜI trước khi bắt đầu:

Ban đầu:    [12 instance cũ]
Thêm lô:    [12 cũ] + [3 mới]        ← năng lực TĂNG lên 15
Cập nhật:   [9 cũ][3 mới] + [3 mới]  ← luôn có ít nhất 12 máy phục vụ
            [6 cũ][6 mới] + [3 mới]
            ...
Gỡ lô thêm: [12 instance mới]

Năng lực không bao giờ xuống dưới 100% — đúng yêu cầu "no reduction in performance and availability".

Và vế chi phí: nó chỉ tạo thêm một lô nhỏ (thường bằng kích thước một batch), trong khi Immutable tạo toàn bộ 12 instance mới. Với môi trường 12 máy, đó là khác biệt đáng kể:

Rolling with additional batch: 12 + 3 = 15 instance tạm thời
Immutable:                     12 + 12 = 24 instance tạm thời

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

• D. Immutable — thoả yêu cầu về tính sẵn sàng nhưng đắt gấp đôi: nó tạo một Auto Scaling group tạm với đủ 12 instance mới. An toàn hơn và rollback nhanh hơn, nhưng đề hỏi phương án tiết kiệm chi phí nhất trong số các phương án đạt yêu cầu.
• A. Rolling — giảm năng lực trong quá trình cập nhật: khi một lô đang được cập nhật, số máy phục vụ xuống dưới 12. Vi phạm yêu cầu đầu tiên.
• C. All at once — gây downtime hoàn toàn: cập nhật tất cả instance cùng lúc. Rẻ nhất và nhanh nhất, nhưng vi phạm nặng nhất yêu cầu về tính sẵn sàng.

Ghi nhớ

Bảng so sánh — đáng thuộc vì chủ đề này xuất hiện rất thường xuyên: | Chính sách | Downtime | Đủ năng lực | Instance thêm | Rollback | |---|---|---|---|---| | All at once | CÓ | ❌ | 0 | chậm | | Rolling | không | ❌ giảm | 0 | chậm | | Rolling + additional batch | không | ✅ | một lô | chậm | | Immutable | không | ✅ | toàn bộ | nhanh | | Traffic splitting | không | ✅ | toàn bộ | nhanh |

Cách chọn theo từ khoá trong đề: | Đề nhấn mạnh | Chọn | |---|---| | "không giảm năng lực" + "tiết kiệm chi phí" | Rolling with additional batch | | "rollback nhanh", "an toàn nhất" | Immutable | | "canary", "thử với % người dùng" | Traffic splitting | | "nhanh và rẻ, môi trường dev" | All at once |

Khác biệt về rollback đáng nhớ: với Rolling và Rolling with additional batch, nếu triển khai hỏng thì các instance đã cập nhật vẫn chạy bản mới — muốn quay lại phải triển khai lại bản cũ qua đúng quy trình đó, mất thêm chừng ấy thời gian. Với Immutable, chỉ cần huỷ ASG tạm là xong ngay, vì instance cũ chưa bao giờ bị đụng tới.

Nên trong thực tế: production quan trọng thì chọn Immutable dù đắt hơn; cân đối chi phí thì Rolling with additional batch. Đề này hỏi rõ "most cost-effective" nên đáp án là vế thứ hai.

Đáp án

A và E.

• A — Tạo cache cục bộ bằng AWS Encryption SDK với tính năng LocalCryptoMaterialsCache
• E — Mở case với AWS Support để tăng hạn mức cho tài khoản

Vì sao đúng

Lỗi ThrottlingException từ KMS nghĩa là ứng dụng gọi GenerateDataKey vượt quá hạn mức request mỗi giây. Có hai hướng xử lý, và đề yêu cầu cả hai.

A — giảm số lời gọi bằng data key caching. Đây là giải pháp hiệu quả nhất, và nó là thực hành được AWS khuyến nghị chính thức:

from aws_encryption_sdk import EncryptionSDKClient, CachingCryptoMaterialsManager
from aws_encryption_sdk.caches.local import LocalCryptoMaterialsCache

cache = LocalCryptoMaterialsCache(capacity=100)
cmm = CachingCryptoMaterialsManager(
    master_key_provider=key_provider,
    cache=cache,
    max_age=300.0,           # dùng lại data key trong 5 phút
    max_messages_encrypted=1000   # hoặc tối đa 1.000 message
)

Ý tưởng: thay vì xin một data key cho mỗi giao dịch, ứng dụng dùng lại một data key cho nhiều giao dịch trong một khoảng giới hạn. Với hàng nghìn giao dịch mỗi giây, điều này giảm số lời gọi KMS hàng trăm lần.

Hai tham số max_age và max_messages_encrypted là van an toàn: chúng giới hạn số dữ liệu được mã hoá bằng cùng một khoá, giữ cân bằng giữa hiệu năng và bảo mật. Bạn tự đặt theo mức rủi ro chấp nhận được.

E — tăng hạn mức. Hạn mức request của KMS là hạn mức mềm, tăng được qua Service Quotas hoặc Support. Với ứng dụng tài chính xử lý hàng nghìn giao dịch mỗi giây, đây là bước hợp lý ngay cả sau khi đã bật caching.

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

• D. Gọi thẳng kms:Encrypt để KMS mã hoá dữ liệu — làm tình hình TỆ HƠN: vẫn là một lời gọi KMS cho mỗi giao dịch (không giảm được gì), lại thêm giới hạn 4 KB cho dữ liệu, và chậm hơn vì dữ liệu phải đi qua mạng tới KMS.
• C. Tạo custom key store và sinh data key qua CloudHSM — không giải quyết vấn đề mà còn làm tệ hơn: custom key store có hạn mức thấp hơn KMS thường, và bạn phải vận hành cụm CloudHSM — tốn kém và phức tạp. Nó dành cho yêu cầu tuân thủ đặc thù (FIPS 140-2 Level 3), không phải để tăng thông lượng.
• B. Dùng SQS xếp hàng request và "cấu hình KMS poll hàng đợi" — KMS không poll hàng đợi nào cả; nó là dịch vụ API đồng bộ. Phương án này mô tả một cơ chế không tồn tại.

Ghi nhớ

Ba cách xử lý throttle của KMS, theo thứ tự nên thử: | Cách | Hiệu quả | |---|---| | Data key caching | giảm số lời gọi hàng trăm lần — hiệu quả nhất | | Exponential backoff + jitter | xử lý đỉnh tạm thời | | Xin tăng hạn mức | khi nhu cầu thật sự vượt mức |

Hạn mức request của KMS (thay đổi theo Region, đây là con số tham khảo cho các Region lớn): | Nhóm API | Hạn mức | |---|---| | GenerateDataKey, Encrypt, Decrypt (khoá đối xứng) | vài chục nghìn request/giây | | Thao tác với khoá bất đối xứng | thấp hơn nhiều | | Custom key store (CloudHSM) | thấp hơn hẳn |

Đánh đổi khi bật data key caching — cần hiểu rõ trước khi dùng cho dữ liệu nhạy cảm: | Đặt tham số | Hệ quả | |---|---| | max_age dài, max_messages lớn | ít lời gọi KMS hơn, nhưng một khoá bảo vệ nhiều dữ liệu hơn | | max_age ngắn, max_messages nhỏ | an toàn hơn, nhưng nhiều lời gọi hơn |

AWS gọi đây là security versus performance trade-off, và họ khuyến nghị đặt giới hạn dựa trên lượng dữ liệu tối đa bạn chấp nhận rủi ro nếu một data key bị lộ.

Và một tối ưu tương tự cho S3: bật BucketKeyEnabled giảm số lời gọi KMS tới 99% khi dùng SSE-KMS.

Đáp án

A, C và F.

• A — Amazon DynamoDB (Streams)
• C — Amazon SQS
• F — Amazon Kinesis

Vì sao đúng

Event source mapping là một khái niệm cụ thể: nó dành cho các nguồn mà dịch vụ Lambda phải CHỦ ĐỘNG POLL để lấy dữ liệu.

Lambda service ──poll──→ Nguồn (SQS, Kinesis, DynamoDB Streams)
       ↓ gom thành lô
   Gọi hàm của bạn (đồng bộ)
       ↓ thành công
   Checkpoint / xoá message

Ba nguồn trong đáp án đều thuộc kiểu đó: | Nguồn | Đặc điểm | |---|---| | DynamoDB Streams | thay đổi item, giữ thứ tự trong shard, lưu 24 giờ | | SQS | hàng đợi, BatchSize tới 10.000 với standard queue | | Kinesis Data Streams | luồng dữ liệu, giữ thứ tự, lưu tới 365 ngày |

Tạo event source mapping:

aws lambda create-event-source-mapping \
  --function-name xu-ly \
  --event-source-arn arn:aws:sqs:ap-southeast-1:123456789012:hang-doi \
  --batch-size 10

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

Ba phương án còn lại đều gọi được Lambda, nhưng theo cơ chế khác — chúng đẩy (push) sự kiện tới Lambda thay vì để Lambda poll:

• D. SNS — SNS chủ động gọi hàm khi có message. Đây là subscription, không phải event source mapping. (Khác biệt thực tế: nếu hàm hỏng, SNS chỉ thử lại theo chính sách của nó rồi bỏ; còn với SQS thì message nằm lại trong hàng đợi cho tới khi xử lý được.)
• E. S3 — S3 gửi event notification tới Lambda. Cũng là push, và cũng là gọi bất đồng bộ.
• B. Một hàm Lambda khác — hàm này gọi hàm kia bằng API Invoke. Không có mapping nào cả.

Ghi nhớ

Ba cơ chế gọi Lambda — bảng này giải thích trọn vẹn câu hỏi: | Cơ chế | Nguồn | Thử lại | |---|---|---| | Poll-based (event source mapping) | SQS, Kinesis, DynamoDB Streams, MSK, Kafka, MQ, DocumentDB | theo cấu hình mapping | | Push bất đồng bộ | S3, SNS, EventBridge, CodeCommit | 2 lần thêm, rồi DLQ | | Push đồng bộ | API Gateway, ALB, Lambda gọi Lambda | không — lỗi trả về client |

Cách nhớ nhanh: nguồn nào LƯU TRỮ dữ liệu (hàng đợi, luồng) thì Lambda phải poll — vì dữ liệu nằm đó chờ. Nguồn nào chỉ PHÁT sự kiện rồi thôi thì nó đẩy sang Lambda.

Vài tham số quan trọng của event source mapping: | Tham số | Việc | |---|---| | BatchSize | số bản ghi mỗi lần gọi | | MaximumBatchingWindowInSeconds | chờ gom đủ lô trước khi gọi | | BisectBatchOnFunctionError | chia đôi lô khi lỗi để cô lập bản ghi hỏng | | MaximumRetryAttempts | giới hạn số lần thử | | DestinationConfig | gửi bản ghi hỏng vào SQS/SNS | | ParallelizationFactor | nhiều consumer song song trên một shard (Kinesis, DynamoDB) |

Hai tham số in đậm rất đáng đặt cho nguồn kiểu stream: không có chúng, một bản ghi gây lỗi sẽ chặn toàn bộ shard cho tới khi hết hạn giữ dữ liệu — sự cố khó chịu và khá phổ biến.