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

Đáp án

A — Sinh pre-signed URL cho tệp nội dung cao cấp khi người đăng ký trả phí yêu cầu tải xuống.

Vì sao đúng

Yêu cầu: bucket vẫn riêng tư, nhưng chỉ người đăng ký trả phí tải được nội dung.

Pre-signed URL làm đúng việc đó — một URL mang chữ ký và thời hạn, cho phép tải đúng một object mà không cần mở bucket ra công khai:

url = s3.generate_presigned_url(
    'get_object',
    Params={'Bucket': 'noi-dung-cao-cap', 'Key': 'video-2026.mp4'},
    ExpiresIn=900          # hết hạn sau 15 phút
)

Điểm hay nhất của cách này: ứng dụng của bạn quyết định ai được cấp URL theo logic nghiệp vụ của chính nó:

def yeu_cau_tai(nguoi_dung, ma_tep):
    if not nguoi_dung.dang_ky_con_hieu_luc():
        return {'statusCode': 403, 'body': 'Cần đăng ký trả phí'}
    return {'statusCode': 200, 'body': json.dumps({'url': sinh_url(ma_tep)})}

S3 không cần biết gì về người dùng cuối — nó chỉ xác minh chữ ký và thời hạn.

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

• D. Bucket policy cấp cho người dùng ẩn danh quyền tải nội dung — hoàn toàn ngược yêu cầu: nó mở bucket cho mọi người trên Internet, kể cả khách không trả phí. Đúng thứ đề muốn tránh.
• B. Bucket policy yêu cầu MFA cho request truy cập — không khả thi cho người dùng web: MFA áp cho danh tính AWS, mà người đăng ký của trang web không có tài khoản AWS. Điều kiện aws:MultiFactorAuthPresent chỉ có nghĩa với người dùng IAM.
• C. Bật server-side encryption trên bucket — nhầm hai vấn đề: SSE bảo vệ dữ liệu khi nằm trên đĩa (chống người có quyền truy cập vật lý), nó hoàn toàn không kiểm soát AI ĐƯỢC TẢI. Người có quyền đọc object vẫn tải được bình thường — S3 tự giải mã.

Ghi nhớ

Các cơ chế kiểm soát truy cập S3, theo phạm vi: | Cơ chế | Phạm vi | Thời hạn | |---|---|---| | Pre-signed URL | một object, một người | có, tối đa 7 ngày | | Bucket policy | cả bucket hoặc prefix | tĩnh | | IAM policy | theo danh tính AWS | tĩnh | | CloudFront signed URL/cookie | qua CDN | có, kèm giới hạn IP |

So sánh hai loại signed URL: | | S3 pre-signed | CloudFront signed | |---|---|---| | Tạo bằng | credential IAM | cặp khoá riêng | | Thời hạn tối đa | 7 ngày | không giới hạn | | Giới hạn theo IP | ❌ | ✅ | | Qua CDN | ❌ | ✅ nhanh và rẻ hơn cho tệp lớn | | Signed cookie | ❌ | ✅ — cấp quyền cho NHIỀU tệp một lần |

Hai dòng cuối rất đáng cân nhắc cho nội dung cao cấp thật: với thư viện nhiều tệp, CloudFront signed cookie tiện hơn hẳn — người dùng được cấp cookie một lần rồi duyệt toàn bộ thư viện, thay vì phải sinh URL riêng cho từng tệp.

Ba lưu ý khi dùng pre-signed URL:

1. Thời hạn kế thừa từ credential tạo URL — URL tạo bằng credential tạm thời của Lambda role sẽ hết hiệu lực khi credential đó hết hạn, thường sớm hơn ExpiresIn bạn đặt.
2. Đặt thời hạn ngắn nhất có thể — URL bị chuyển tiếp thì ai cầm cũng dùng được trong khoảng đó.
3. Sinh URL ở phía máy chủ, không bao giờ để logic ký nằm trong JavaScript của trình duyệt.

Và mẹo hiệu năng: dùng pre-signed URL cho PutObject để client tải tệp thẳng lên S3 — tránh giới hạn payload và giảm tải cho máy chủ.

Đáp án

B — Dùng FIFO queue và cấu hình Lambda thêm mã khử trùng lặp (deduplication) cho message.

Vì sao đúng

Vấn đề: cảm biến gửi message trùng lặp cách nhau vài giây, và dữ liệu trùng đang vào Redshift.

FIFO queue có cơ chế khử trùng lặp tích hợp, với cửa sổ 5 phút — thừa sức bao trùm khoảng "vài giây" mà đề mô tả:

sqs.send_message(
    QueueUrl=url_fifo,
    MessageBody=json.dumps(du_lieu),
    MessageGroupId='cam-bien-001',
    MessageDeduplicationId=hashlib.sha256(          # ← mã khử trùng lặp
        f"{du_lieu['cam_bien_id']}-{du_lieu['thoi_diem']}".encode()
    ).hexdigest()
)

Cách nó hoạt động: nếu một message có cùng MessageDeduplicationId được gửi lại trong vòng 5 phút, SQS nhận nhưng không phân phối message thứ hai. Consumer chỉ thấy một bản.

Có hai cách cung cấp mã khử trùng lặp: | Cách | Chi tiết | |---|---| | Khai tường minh | truyền MessageDeduplicationId — kiểm soát chính xác cái gì là "trùng" | | Content-based deduplication | bật ContentBasedDeduplication=true, SQS tự băm SHA-256 của message body |

Cách thứ nhất tốt hơn ở đây: bạn tự quyết định trùng nghĩa là gì (ví dụ cùng cảm biến và cùng mốc thời gian), thay vì phụ thuộc vào việc body có giống hệt từng byte hay không.

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

• D. Dùng FIFO queue và thêm message group ID cho mỗi cảm biến — đúng loại hàng đợi nhưng sai tính năng: MessageGroupId đảm bảo THỨ TỰ, không khử trùng lặp. Nó nhóm các message phải được xử lý tuần tự với nhau — hữu ích, nhưng hai message trùng trong cùng một group vẫn được phân phối cả hai.
• A. Redrive policy với DLQ và maxReceiveCount = 1 — giải quyết vấn đề khác: nó chuyển message xử lý HỎNG sang dead-letter queue. Message trùng lặp không phải message hỏng — chúng xử lý thành công, chỉ là hai lần.
• C. Gọi ChangeMessageVisibility với timeout 30 giây sau mỗi lần nhận — giải quyết vấn đề xử lý trùng do timeout quá ngắn, tức là khi cùng MỘT message bị hai consumer nhận. Ở đây là hai message KHÁC NHAU có nội dung giống nhau — cơ chế hoàn toàn khác.

Ghi nhớ

So sánh Standard và FIFO queue: | | Standard | FIFO | |---|---|---| | Thứ tự | không đảm bảo | đảm bảo trong mỗi message group | | Trùng lặp | at-least-once — có thể trùng | exactly-once trong 5 phút | | Thông lượng | gần như không giới hạn | 300 msg/giây (3.000 với batching) | | Tên hàng đợi | tuỳ ý | phải kết thúc bằng .fifo |

Hai tham số bắt buộc của FIFO queue: | Tham số | Việc | |---|---| | MessageGroupId | đảm bảo THỨ TỰ trong nhóm — bắt buộc | | MessageDeduplicationId | KHỬ TRÙNG LẶP trong 5 phút — bắt buộc trừ khi bật content-based |

Đừng lẫn hai tham số này: group ID lo thứ tự, deduplication ID lo trùng lặp. Đó chính là điểm phân biệt giữa đáp án B và phương án D.

Ba lưu ý khi chuyển sang FIFO:

1. Thông lượng thấp hơn nhiều — 300 message/giây (hoặc 3.000 với batching). Với dữ liệu cảm biến khối lượng lớn, đây có thể là nút thắt. (Chế độ high throughput mode nâng lên tới 70.000 msg/giây nếu bạn dùng nhiều message group.)
2. Chọn MessageGroupId có nhiều giá trị — dùng một group duy nhất là ép mọi message xử lý tuần tự, mất hết khả năng song song.
3. Cửa sổ khử trùng lặp cố định 5 phút — không cấu hình được. Trùng lặp cách nhau hơn 5 phút vẫn lọt qua.

Và giải pháp thay thế nếu FIFO quá chậm: giữ standard queue và khử trùng lặp ở tầng ứng dụng — dùng DynamoDB với attribute_not_exists làm sổ ghi các message đã xử lý.

Đáp án

B và D.

• B — Tạo Origin Access Identity (OAI), gắn vào distribution và cấu hình quyền
• D — Tạo signed URL cho nội dung rồi phân phát cho khách hàng cao cấp

Vì sao đúng

Hai đáp án là hai nửa của một cơ chế hoàn chỉnh, và thiếu một nửa thì cơ chế kia vô nghĩa.

B — OAI khoá cửa sau. Nó đảm bảo bucket S3 chỉ đọc được qua CloudFront, không ai truy cập thẳng được:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E1ABCDEF"},
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::kho-ban-cap-nhat/*"
}

Không có bước này, signed URL trở nên vô dụng — ai cũng lấy được tệp bằng URL trực tiếp của S3.

D — signed URL khoá cửa trước. Nó đảm bảo chỉ khách hàng cao cấp đi qua được CloudFront:

from botocore.signers import CloudFrontSigner

signer = CloudFrontSigner(key_id, rsa_signer)
url = signer.generate_presigned_url(
    'https://d111111abcdef8.cloudfront.net/ban-cap-nhat/v2.zip',
    date_less_than=datetime.now() + timedelta(hours=1)
)

Ghép lại:

Khách cao cấp (có signed URL) → CloudFront → S3 (chỉ mở cho OAI)
Người khác (không có URL)     → CloudFront TỪ CHỐI (403)
Người khác (thử URL S3 trực tiếp) → S3 TỪ CHỐI (403)

Và vế "faster" trong đề cũng được đáp ứng: CloudFront cache nội dung ở hơn 400 edge location, nên khách hàng tải từ điểm gần họ nhất.

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

• C. Dùng ACL trên bucket S3 để giới hạn theo địa chỉ IP — ACL của S3 không hỗ trợ điều kiện IP: nó chỉ cấp quyền cho các grantee định sẵn (chủ sở hữu, tài khoản khác, nhóm công khai). (Và từ tháng 4/2023, AWS tắt ACL theo mặc định cho bucket mới.)
• E. Dùng IAM policy với điều kiện IP của khách hàng cao cấp — không mở rộng được và không thực tế: khách hàng không có danh tính AWS, và IP của họ thay đổi liên tục (mạng di động, văn phòng, VPN). Bạn sẽ phải bảo trì một danh sách IP không bao giờ chính xác.
• A. Tạo signed cookie và gắn vào "Amazon S3 distribution" — sai thuật ngữ: signed cookie gắn với CloudFront distribution, không phải "S3 distribution" (khái niệm không tồn tại). (Signed cookie bản thân nó là cơ chế hợp lệ — và thậm chí tiện hơn signed URL khi cần cấp quyền cho nhiều tệp — nhưng phương án mô tả sai chỗ gắn nó.)

Ghi nhớ

Hai lớp bảo vệ cần có cùng nhau khi phân phối nội dung riêng tư qua CloudFront: | Lớp | Cơ chế | Bảo vệ khỏi | |---|---|---| | Cửa trước | signed URL / signed cookie | người không được phép đi qua CloudFront | | Cửa sau | OAC (hoặc OAI) | người truy cập thẳng vào S3 |

Ghi chú quan trọng về OAI: đây là cơ chế cũ. AWS đã thay thế bằng Origin Access Control (OAC) từ 2022, và OAC tốt hơn ở mấy điểm: | | OAI (cũ) | OAC (mới) | |---|---|---| | Hỗ trợ SSE-KMS | ❌ | ✅ | | Hỗ trợ mọi Region | ❌ (thiếu Region mới) | ✅ | | Hỗ trợ PUT, POST | ❌ | ✅ | | Trạng thái | chỉ để tương thích ngược | khuyến nghị |

Với hệ thống mới, luôn dùng OAC. Câu hỏi này vẫn dùng OAI vì được viết trước khi OAC ra đời.

So sánh signed URL và signed cookie: | | Signed URL | Signed cookie | |---|---|---| | Phạm vi | một tệp | nhiều tệp (theo wildcard path) | | Dùng khi | tải một bản cập nhật cụ thể | truy cập cả thư viện nội dung | | Client | mọi loại | cần hỗ trợ cookie |

Với ISV phân phối nhiều bản cập nhật như đề mô tả, signed cookie thường thực dụng hơn — cấp một lần cho cả kho.

Đáp án

B — Bật S3 Transfer Acceleration trên bucket.

Vì sao đúng

Đề mô tả đúng vấn đề mà Transfer Acceleration sinh ra để giải: tải lên từ nhiều nơi trên thế giới vào một bucket ở us-east-1, và tốc độ đang chậm.

Cách nó hoạt động: thay vì gửi dữ liệu thẳng qua Internet công khai tới Region đích, client tải lên edge location gần nhất, rồi dữ liệu đi tiếp qua mạng backbone riêng của AWS:

Trước: Văn phòng ở Sydney ──Internet công khai (nhiều chặng, chậm)──→ S3 us-east-1

Sau:   Văn phòng ở Sydney ──ngắn──→ Edge Sydney ──backbone AWS──→ S3 us-east-1

Bật chỉ là một lời gọi, không đổi kiến trúc gì:

aws s3api put-bucket-accelerate-configuration \
  --bucket kho-bao-cao --accelerate-configuration Status=Enabled

Rồi client đổi sang endpoint tăng tốc:

Thường:   kho-bao-cao.s3.us-east-1.amazonaws.com
Tăng tốc: kho-bao-cao.s3-accelerate.amazonaws.com

AWS còn có công cụ so sánh tốc độ để đo trước khi quyết định — vì hiệu quả phụ thuộc khoảng cách và chất lượng đường truyền:

https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html

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

• D. Dùng S3 multi-part upload — đây là phương án đáng bàn: multipart upload có cải thiện thông lượng bằng cách tải nhiều phần song song, và nó bắt buộc với tệp trên 5 GB. Nhưng nó không giải quyết vấn đề khoảng cách — mỗi phần vẫn đi qua Internet công khai tới us-east-1. (Trong thực tế nên kết hợp cả hai: multipart chia nhỏ, Transfer Acceleration rút ngắn đường đi.)
• A. Dùng AWS Managed VPN — VPN không tăng tốc gì: nó vẫn đi qua Internet công khai, chỉ thêm mã hoá và thêm chi phí xử lý. Nó dùng để kết nối riêng tư, không phải để tăng tốc.
• C. Tạo Direct Connect từ mỗi văn phòng — giải quyết được nhưng cực kỳ tốn kém và chậm triển khai: mỗi kết nối cần hợp đồng riêng với nhà cung cấp, mất hàng tuần tới hàng tháng để lắp đặt, và chi phí hàng nghìn đô mỗi tháng. Quá tương xứng cho việc tải báo cáo hằng tuần.

Ghi nhớ

Phân biệt hai dịch vụ dùng chung hạ tầng edge nhưng ngược chiều nhau: | | Transfer Acceleration | CloudFront | |---|---|---| | Tối ưu cho | TẢI LÊN từ xa | TẢI XUỐNG, nhiều người xem | | Cache | ❌ | ✅ | | Dùng khi | upload tệp lớn xuyên lục địa | phân phối nội dung |

Nhận dạng nhanh:

• "upload from around the world", "upload latency" ⇒ Transfer Acceleration
• "global users", "improve download performance" ⇒ CloudFront
• "disaster recovery", "data residency" ⇒ Cross-Region Replication

Vài đặc điểm của Transfer Acceleration: | Đặc điểm | Chi tiết | |---|---| | Điều kiện | tên bucket không được chứa dấu chấm | | Chi phí | có phí thêm mỗi GB | | Hiệu quả | càng xa càng rõ; gần Region thì gần như không đổi | | Tương thích | dùng được với multipart upload |

Bốn cách tăng tốc tải lên S3, theo quy mô dữ liệu: | Quy mô | Cách | |---|---| | Tệp < 100 MB | tải thường | | Tệp lớn, cùng Region | multipart upload | | Tệp lớn, xuyên lục địa | Transfer Acceleration + multipart | | Hàng chục TB trở lên | AWS Snowball — chuyển bằng thiết bị vật lý |

Dòng cuối đáng nhớ: với khối lượng rất lớn hoặc đường truyền quá kém, gửi ổ cứng vật lý đôi khi nhanh hơn mọi cách qua mạng.

Đáp án

A — Dùng DynamoDB Accelerator (DAX) để cache dữ liệu.

Vì sao đúng

Đề nêu hai vấn đề, và DAX giải quyết cả hai cùng lúc:

1. Cần độ trễ dưới mili giây cho giao dịch tài chính
2. Phải cấp thừa read capacity rất nhiều để tránh throttle

DAX là cache trong bộ nhớ được quản lý, thiết kế riêng cho DynamoDB:

Trước: Ứng dụng → DynamoDB           → 5–10 mili giây, tốn RCU
Sau:   Ứng dụng → DAX (cache hit)    → DƯỚI mili giây, KHÔNG tốn RCU
              └→ DynamoDB (miss)     → chỉ khi cần

Điểm hay nhất về mặt triển khai: DAX dùng chính API của DynamoDB, nên mã ứng dụng gần như không đổi — chỉ thay client:

import amazondax
dax = amazondax.AmazonDaxClient(endpoint_url='dax://cum-dax.abc123.dax-clusters.ap-southeast-1.amazonaws.com')
table = dax.Table('giao-dich')
table.get_item(Key={'id': 'GD-001'})     # cú pháp y hệt boto3

DAX có hai cache riêng biệt: | Cache | Nội dung | TTL mặc định | |---|---|---| | Item cache | kết quả GetItem, BatchGetItem | 5 phút | | Query cache | kết quả Query, Scan | 5 phút |

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

• B. Tạo Global Secondary Index cho dữ liệu giao dịch — GSI phục vụ MẪU TRUY VẤN KHÁC, không cải thiện độ trễ cho cùng một truy vấn. Và nó tốn thêm capacity riêng — làm chi phí tăng chứ không giảm.
• D. Dùng exponential backoff cho các truy vấn DynamoDB — xử lý throttle nhưng LÀM ĐỘ TRỄ TỆ HƠN: mỗi lần thử lại là thêm thời gian chờ. Với yêu cầu dưới mili giây, đây là hướng ngược.
• C. Lưu dữ liệu giao dịch trên S3 và dùng Transfer Acceleration — sai bản chất hoàn toàn: S3 là kho object với độ trễ hàng chục tới hàng trăm mili giây, chậm hơn DynamoDB rất nhiều. Và Transfer Acceleration tối ưu cho tải lên xuyên lục địa, không liên quan.

Ghi nhớ

So sánh DAX và ElastiCache khi đặt trước DynamoDB: | | DAX | ElastiCache | |---|---|---| | API | giống hệt DynamoDB — không sửa mã | API riêng — phải viết logic cache | | Chỉ dùng với | DynamoDB | mọi nguồn dữ liệu | | Write-through | tự động | tự cài đặt | | Độ trễ | microsecond | microsecond |

Với DynamoDB, DAX gần như luôn là lựa chọn đúng — nó tiết kiệm rất nhiều công sức lập trình.

Ba hạn chế quan trọng của DAX: | Hạn chế | Chi tiết | |---|---| | Không hỗ trợ strongly consistent read | request kiểu đó đi thẳng xuống DynamoDB, bỏ qua cache | | Chỉ nằm trong VPC | ứng dụng phải ở trong VPC đó | | Không dùng với | Global Tables (có giới hạn), transaction (đi thẳng xuống bảng) |

Dòng đầu tiên đáng nhớ với ứng dụng tài chính: dữ liệu giao dịch cần đọc nhất quán mạnh sẽ không được hưởng lợi từ DAX. Nên trong thực tế, DAX hợp với phần đọc dữ liệu tham chiếu (bảng giá, thông tin công cụ tài chính) hơn là phần ghi và đọc số dư.

Ba cách giảm độ trễ DynamoDB, theo thứ tự nên thử: | Cách | Hiệu quả | |---|---| | DAX | microsecond, không tốn RCU khi hit | | Eventually consistent read | rẻ một nửa, nhanh hơn | | Thiết kế lại khoá để dùng Query thay Scan | giảm cả độ trễ lẫn chi phí |

Đáp án

C — Vô hiệu hoá và xoá access key của người dùng, rồi tạo bộ mới.

Vì sao đúng

Điểm mấu chốt: AWS KHÔNG BAO GIỜ hiển thị lại secret access key.

Nó chỉ hiện đúng một lần — ngay lúc tạo. Sau đó AWS không lưu bản có thể đọc được của nó, nên không có cách nào khôi phục, không có nút "hiện lại", và AWS Support cũng không giúp được.

Vậy nên khi mất, cách duy nhất là tạo bộ mới:

# 1. Tạo key mới TRƯỚC (để không gián đoạn dịch vụ)
aws iam create-access-key --user-name lap-trinh-vien

# 2. Cập nhật ứng dụng dùng key mới, kiểm tra hoạt động

# 3. Vô hiệu hoá key cũ (chưa xoá — để quay lại được nếu có vấn đề)
aws iam update-access-key --user-name lap-trinh-vien \
  --access-key-id AKIAOLDKEY --status Inactive

# 4. Theo dõi vài ngày, chắc chắn không còn gì dùng key cũ, rồi mới xoá
aws iam delete-access-key --user-name lap-trinh-vien --access-key-id AKIAOLDKEY

Thứ tự này quan trọng: tạo mới trước, vô hiệu hoá sau — nếu làm ngược thì ứng dụng đang chạy sẽ gián đoạn.

(Mỗi IAM user được phép có tối đa 2 access key cùng lúc — đây chính là lý do: để xoay vòng key mà không gián đoạn.)

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

• B. Liên hệ AWS Support xin đặt lại mật khẩu — sai hai chỗ: AWS Support không khôi phục được secret key (họ cũng không có nó), và mật khẩu khác access key — mật khẩu để đăng nhập Console, access key để dùng CLI và SDK.
• A. Tạo cặp khoá mới từ EC2 management console — nhầm hai loại khoá: EC2 key pair là cặp khoá SSH để đăng nhập vào instance. Nó hoàn toàn không liên quan tới access key của IAM.
• D. "Đặt lại access key của tài khoản AWS" — mơ hồ và sai hướng: nếu hiểu là access key của tài khoản root thì càng sai — AWS khuyến nghị root không nên có access key nào cả. Và việc mất key của một IAM user không liên quan gì tới root.

Ghi nhớ

Nguyên tắc quan trọng nhất về access key: | Thành phần | Có xem lại được? | |---|---| | Access Key ID (AKIA...) | ✅ luôn xem được trong Console | | Secret Access Key | ❌ CHỈ HIỆN MỘT LẦN lúc tạo |

Nên khi tạo key, lưu ngay vào nơi an toàn — password manager hoặc Secrets Manager, không bao giờ vào tệp văn bản hay tin nhắn.

Quy trình xoay vòng access key an toàn — bốn bước, không gián đoạn:

1. Tạo key thứ hai (mỗi user được tối đa 2)
2. Cập nhật ứng dụng dùng key mới
3. Đặt key cũ thành Inactive, theo dõi vài ngày
4. Xoá key cũ

Bước 3 là lưới an toàn: nếu còn ứng dụng nào chưa cập nhật, bạn phát hiện được và kích hoạt lại key cũ ngay.

Công cụ theo dõi: | Công cụ | Cho biết | |---|---| | IAM Credential Report | danh sách mọi credential và LẦN DÙNG CUỐI | | aws iam get-access-key-last-used | key cụ thể lần cuối dùng khi nào, gọi dịch vụ gì | | CloudTrail | mọi lời gọi API của key đó |

Lệnh thứ hai rất hữu ích ở bước 3 — nó cho biết chắc chắn key cũ đã ngừng được dùng chưa:

aws iam get-access-key-last-used --access-key-id AKIAOLDKEY

Và nguyên tắc bao trùm: ứng dụng chạy trên AWS thì KHÔNG BAO GIỜ dùng access key dài hạn — dùng instance profile (EC2), execution role (Lambda), task role (ECS). Với lập trình viên thì dùng IAM Identity Center (SSO). Khi đó vấn đề "mất key" không bao giờ xảy ra.

Đáp án

C — Hàm không xử lý lỗi, nên dịch vụ Lambda cố xử lý lại dữ liệu.

Vì sao đúng

Manh mối quyết định nằm trong đề: khi đọc stream mà không có Lambda thì không có bản ghi trùng — nghĩa là Kinesis hoàn toàn bình thường, vấn đề nằm ở cách Lambda xử lý lỗi.

Cơ chế của event source mapping với Kinesis:

1. Dịch vụ Lambda poll shard, lấy một lô bản ghi
2. Gọi hàm ĐỒNG BỘ với cả lô
3. Hàm ném lỗi (thiếu trường dữ liệu)
4. → Lambda KHÔNG checkpoint, THỬ LẠI CẢ LÔ
5. → Các bản ghi hợp lệ trong lô ĐƯỢC XỬ LÝ LẠI  ← nguồn của trùng lặp
6. Lặp lại cho tới khi thành công hoặc hết hạn giữ dữ liệu (24 giờ)

Điểm mấu chốt: Lambda xử lý theo LÔ, và thử lại theo LÔ. Một bản ghi hỏng khiến toàn bộ lô được chạy lại — nên 99 bản ghi hợp lệ trong lô đó bị xử lý nhiều lần.

Cách sửa gồm hai phần:

Phần 1 — bắt lỗi trong mã, đừng để hàm ném ra:

def lambda_handler(event, context):
    loi = []
    for ban_ghi in event['Records']:
        try:
            xu_ly(giai_ma(ban_ghi))
        except KeyError as e:
            logger.error(f"Bản ghi thiếu trường: {e}")
            loi.append({'itemIdentifier': ban_ghi['kinesis']['sequenceNumber']})
    return {'batchItemFailures': loi}      # chỉ báo lỗi ĐÚNG bản ghi hỏng

Phần 2 — bật các cơ chế cô lập lỗi:

aws lambda update-event-source-mapping --uuid <id> \
  --function-response-types ReportBatchItemFailures \
  --bisect-batch-on-function-error \
  --maximum-retry-attempts 3 \
  --destination-config '{"OnFailure":{"Destination":"arn:aws:sqs:...:ban-ghi-loi"}}'

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

• A. Hàm không đẩy con trỏ stream sang bản ghi tiếp theo sau khi lỗi — mô tả gần đúng triệu chứng nhưng sai về cơ chế: hàm không quản lý con trỏ (iterator) — dịch vụ Lambda làm việc đó. Bạn không "đẩy con trỏ" từ trong mã hàm được.
• B. Event source dùng gọi bất đồng bộ nên sinh trùng lặp — sai về kiểu gọi: với nguồn poll-based như Kinesis, dịch vụ Lambda gọi hàm ĐỒNG BỘ và chờ kết quả để quyết định checkpoint. Chính vì đồng bộ nên nó mới biết là lỗi và thử lại.
• D. Hàm không theo kịp lượng dữ liệu từ stream — gây độ trễ, không gây trùng lặp: triệu chứng của việc tụt lại là IteratorAge tăng dần, và cuối cùng là mất dữ liệu khi hết hạn giữ — chứ không phải dữ liệu trùng.

Ghi nhớ

Cơ chế thử lại theo kiểu gọi: | Kiểu | Nguồn | Thử lại | |---|---|---| | Đồng bộ | API Gateway, ALB | không — lỗi trả về client | | Bất đồng bộ | S3, SNS, EventBridge | 2 lần thêm, rồi DLQ | | Poll-based (gọi đồng bộ) | Kinesis, DynamoDB Streams, SQS | theo cấu hình mapping |

Bốn tham số cứu vãn tình huống "poison pill" — nên cấu hình đủ: | Tham số | Việc | |---|---| | ReportBatchItemFailures | chỉ trả lại ĐÚNG bản ghi hỏng, không cả lô | | BisectBatchOnFunctionError | chia đôi lô khi lỗi để cô lập bản ghi hỏng | | MaximumRetryAttempts | giới hạn số lần thử | | MaximumRecordAgeInSeconds | bỏ qua bản ghi quá cũ | | DestinationConfig | gửi thông tin lô hỏng vào SQS/SNS |

ReportBatchItemFailures là cải tiến quan trọng nhất — nó biến "thử lại cả lô" thành "thử lại đúng bản ghi hỏng", loại bỏ hẳn nguồn trùng lặp trong bài này.

Không có các tham số này, một bản ghi hỏng chặn toàn bộ shard trong 24 giờ — Lambda cứ thử lại mãi cùng một lô, và mọi bản ghi phía sau nằm chờ.

Và nguyên tắc thiết kế quan trọng nhất: hàm xử lý stream phải IDEMPOTENT. Kinesis và Lambda đảm bảo at-least-once, nên trùng lặp là điều phải chấp nhận và xử lý được — dù bạn có cấu hình tốt đến đâu.

Đáp án

B — Tạo một state machine bằng Amazon States Language.

Vì sao đúng

Step Functions định nghĩa workflow bằng Amazon States Language (ASL) — một ngôn ngữ khai báo dựa trên JSON:

{
  "Comment": "Điều phối các microservice",
  "StartAt": "XacThucDonHang",
  "States": {
    "XacThucDonHang": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:xac-thuc",
      "Retry": [{"ErrorEquals": ["States.Timeout"], "MaxAttempts": 3, "BackoffRate": 2.0}],
      "Catch": [{"ErrorEquals": ["States.ALL"], "ResultPath": "$.loi", "Next": "XuLyLoi"}],
      "Next": "KiemTraTonKho"
    },
    "KiemTraTonKho": {
      "Type": "Choice",
      "Choices": [{"Variable": "$.conHang", "BooleanEquals": true, "Next": "ThanhToan"}],
      "Default": "BaoHetHang"
    },
    "ThanhToan": {"Type": "Task", "Resource": "arn:aws:lambda:...:function:thanh-toan", "End": true},
    "BaoHetHang": {"Type": "Task", "Resource": "arn:aws:lambda:...:function:bao-het", "End": true},
    "XuLyLoi": {"Type": "Fail"}
  }
}

Đây là bước đầu tiên và bắt buộc khi dùng Step Functions: bạn phải định nghĩa máy trạng thái trước khi chạy nó.

Điểm mạnh của cách khai báo này: những việc bạn từng phải tự viết đều trở thành cấu hình: | Việc | Cơ chế trong ASL | |---|---| | Thử lại khi lỗi | Retry với backoff | | Bắt và xử lý lỗi | Catch với đường rẽ riêng | | Rẽ nhánh | Choice | | Chạy song song | Parallel, Map | | Chờ | Wait — tới 1 năm |

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

• C. Tạo workflow bằng API action StartExecution — nhầm thứ tự: StartExecution CHẠY một máy trạng thái ĐÃ TỒN TẠI, nó không tạo ra định nghĩa nào. API để tạo là CreateStateMachine.
• D. Tạo CloudFormation stack bằng template YAML — công cụ triển khai, không phải cách định nghĩa workflow. Bạn có thể (và nên) dùng CloudFormation hoặc SAM để triển khai state machine, nhưng nội dung định nghĩa vẫn phải viết bằng ASL:

  MayTrangThai:
    Type: AWS::Serverless::StateMachine
    Properties:
      DefinitionUri: statemachine/quy-trinh.asl.json    # ← vẫn là ASL
  

• A. Tạo layer trong Lambda và thêm các hàm vào layer — hiểu sai chức năng của layer: layer chứa thư viện dùng chung, không chứa hàm và không điều phối gì cả.

Ghi nhớ

Tám loại state của Step Functions: | State | Việc | |---|---| | Task | gọi một dịch vụ (Lambda, ECS, SNS, SDK integration…) | | Choice | rẽ nhánh theo điều kiện | | Parallel | nhiều NHÁNH KHÁC NHAU đồng thời | | Map | CÙNG logic trên từng phần tử mảng | | Wait | tạm dừng | | Pass | truyền dữ liệu, biến đổi | | Succeed / Fail | kết thúc |

Bốn bộ lọc dữ liệu, theo thứ tự xử lý trong một state:

Đầu vào → InputPath → Parameters → [TASK] → ResultSelector → ResultPath → OutputPath → Đầu ra

Trong đó ResultPath GHÉP THÊM kết quả vào đầu vào (giữ được dữ liệu gốc), còn OutputPath THU HẸP — khác biệt này rất hay bị hỏi.

Hai loại workflow: | | Standard | Express | |---|---|---| | Thời gian tối đa | 1 năm | 5 phút | | Tốc độ | 2.000 lần bắt đầu/giây | 100.000 lần/giây | | Đảm bảo | exactly-once | at-least-once | | Lịch sử | hiện đầy đủ trong Console | chỉ CloudWatch Logs |

Và một tính năng rất mạnh đáng biết: AWS SDK integrations cho phép Task gọi thẳng hơn 200 dịch vụ AWS — ghi DynamoDB, gửi SNS, khởi chạy ECS task — mà không cần Lambda trung gian nào:

{"Type": "Task", "Resource": "arn:aws:states:::aws-sdk:dynamodb:putItem", "Parameters": {...}}

Đáp án

C — Tạo một layer trong Lambda chứa thư viện bên ngoài.

Vì sao đúng

Chi tiết quyết định nằm ở đề: NHIỀU hàm Lambda cùng dùng cùng một thư viện.

Layer là gói mã hoặc dữ liệu dùng chung, gắn được vào nhiều hàm:

# Đóng gói thư viện đúng cấu trúc thư mục
mkdir -p python
pip install -r requirements.txt -t python/
zip -r layer.zip python/

# Xuất bản — mỗi lần publish là một VERSION mới
aws lambda publish-layer-version \
  --layer-name thu-vien-chung \
  --zip-file fileb://layer.zip \
  --compatible-runtimes python3.12

# Gắn vào nhiều hàm
aws lambda update-function-configuration --function-name ham-a \
  --layers arn:aws:lambda:...:layer:thu-vien-chung:3
aws lambda update-function-configuration --function-name ham-b \
  --layers arn:aws:lambda:...:layer:thu-vien-chung:3

Ba lợi ích so với việc đóng gói riêng cho từng hàm: | Lợi ích | Chi tiết | |---|---| | Cập nhật một chỗ | publish version mới rồi trỏ các hàm sang | | Gói triển khai nhỏ đi | mỗi lần sửa mã chỉ tải lên vài KB thay vì vài chục MB | | Quản lý phiên bản | mỗi lần publish là một version BẤT BIẾN |

Điểm thứ hai đáng chú ý về trải nghiệm phát triển: không có layer, mỗi lần sửa một dòng mã bạn phải tải lên cả gói chứa thư viện — vòng lặp chậm hẳn.

Cấu trúc thư mục trong ZIP rất quan trọng và hay bị sai — layer được giải nén vào /opt: | Runtime | Đường dẫn trong ZIP | |---|---| | Python | python/ hoặc python/lib/python3.x/site-packages/ | | Node.js | nodejs/node_modules/ | | Java | java/lib/ | | Bất kỳ (nhị phân) | bin/ |

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

• B. Tạo deployment package bao gồm thư viện và D. Đưa thư viện vào cùng mã hàm — hai phương án này mô tả cùng một việc, và nó chạy được nhưng không tối ưu cho NHIỀU hàm: bạn phải lặp lại thư viện trong mọi gói, và mỗi lần cập nhật thư viện phải đóng gói lại và triển khai lại tất cả.
• A. Lưu thư viện trên S3 và tham chiếu từ mã hàm — thêm độ trễ ở mọi cold start (phải tải thư viện về), và bạn phải tự viết logic tải và giải nén. Ngoài ra /var/task chỉ đọc, nên phải giải nén vào /tmp.

Ghi nhớ

Ba cách đưa thư viện vào Lambda: | Cách | Giới hạn | Dùng khi | |---|---|---| | ZIP kèm mã hàm | 50 MB nén / 250 MB giải nén | thư viện riêng của một hàm | | Lambda Layer | 5 layer, tổng vẫn 250 MB | dùng chung cho NHIỀU hàm | | Container image | 10 GB | thư viện rất nặng (OpenCV, ML) |

Lưu ý về giới hạn: 250 MB là tổng của hàm cộng tất cả layer sau khi giải nén — layer không nới rộng hạn mức, nó chỉ giúp tổ chức và tái sử dụng.

Vài đặc điểm khác của layer:

• Version bất biến — publish rồi không sửa được. Nhờ vậy hàm đang chạy không bị ảnh hưởng khi bạn cập nhật layer.
• Chia sẻ chéo tài khoản được bằng add-layer-version-permission — hữu ích khi nhiều đội trong công ty dùng chung thư viện nội bộ.
• Layer công khai có sẵn: AWS Lambda Powertools, Parameters and Secrets Extension, và nhiều nhà cung cấp bên thứ ba (Datadog, New Relic).

Và với thư viện xử lý ảnh hoặc có phần mở rộng biên dịch, nhớ dựng layer trong môi trường tương thích Amazon Linux:

docker run --rm -v "$PWD":/var/task public.ecr.aws/sam/build-python3.12 \
  pip install -r requirements.txt -t python/

Cài trên macOS hay Windows rồi đóng gói sẽ lỗi khi chạy trên Lambda — đây là lỗi phổ biến nhất khi làm layer.

Đáp án

D — Immutable.

Vì sao đúng

Đề nêu ba điều kiện, và Immutable là chính sách duy nhất thoả cả ba:

1. Không chấp nhận website ngừng hoạt động nếu cập nhật thất bại
2. Tác động tối thiểu
3. Rollback càng nhanh càng tốt

Immutable dựng một tập instance MỚI hoàn toàn trước khi chuyển sang:

1. Tạo một Auto Scaling group TẠM THỜI
2. Khởi chạy MỘT instance mới, chờ nó qua health check
3. Nếu đạt → khởi chạy đủ số instance còn lại
4. Chuyển toàn bộ instance mới sang ASG gốc
5. Huỷ các instance cũ

Điểm mấu chốt: cho tới bước 4, các instance cũ vẫn chạy nguyên vẹn và chưa hề bị đụng tới. Nên nếu có vấn đề, Beanstalk chỉ cần huỷ ASG tạm — mất vài giây, và không có instance production nào từng chạy mã lỗi.

So sánh trực quan:

Immutable thất bại: [cũ][cũ][cũ][cũ] + [mới ✗]  →  xoá cái mới, XONG NGAY
Rolling thất bại:   [mới][mới][cũ][cũ]           →  phải TRIỂN KHAI LẠI bản cũ

Bước 2 cũng đáng chú ý: Beanstalk thử một instance trước rồi mới nhân rộng — lỗi cấu hình bị phát hiện sớm với chi phí thấp nhất. Với ứng dụng WordPress như đề mô tả, điều này bắt được ngay các lỗi về phiên bản PHP hay thư viện thiếu.

Cái giá: tốn gấp đôi tài nguyên trong lúc triển khai và chậm nhất trong các chính sách. Nhưng đề đã nói rõ ưu tiên là không downtime và rollback nhanh — và đây cũng là chính sách AWS khuyến nghị cho production.

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

• B. Rolling — cập nhật TẠI CHỖ theo từng lô, nên năng lực giảm trong quá trình và nếu hỏng thì các instance đã cập nhật vẫn đang chạy bản lỗi. Rollback đòi triển khai lại phiên bản cũ — mất thêm chừng ấy thời gian trong khi lỗi vẫn phục vụ người dùng.
• A. All at once — tệ nhất cho yêu cầu này: cập nhật tất cả instance cùng lúc, gây downtime hoàn toàn. Vi phạm điều kiện đầu tiên.
• C. "Snapshots" — không phải một deployment policy của Elastic Beanstalk. Năm chính sách hợp lệ là: All at once, Rolling, Rolling with additional batch, Immutable, và Traffic splitting.

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 mới | Rollback | |---|---|---|---|---| | All at once | CÓ | ❌ | 0 | chậm — deploy lại | | Rolling | không | ❌ giảm | 0 | chậm — deploy lại | | Rolling + additional batch | không | ✅ | một lô | chậm — deploy lại | | Immutable | không | ✅ | toàn bộ | NHANH — huỷ ASG tạm | | Traffic splitting | không | ✅ | toàn bộ | NHANH — chuyển traffic về |

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

Lưu ý về hạn mức khi dùng Immutable: vì nó nhân đôi số instance tạm thời, hãy kiểm tra hạn mức EC2 của tài khoản trước. Chạm trần giữa chừng sẽ khiến triển khai thất bại vì lý do chẳng liên quan tới mã của bạn.

Và với thay đổi lớn hơn cả mã ứng dụng — ví dụ nâng cấp platform version — thì cả Immutable cũng chưa đủ; khi đó dùng blue/green với hoán đổi CNAME giữa hai môi trường riêng.