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

Đáp án

C — Tăng VisibilityTimeout của hàng đợi.

Vì sao đúng

Triệu chứng trong đề rất đặc trưng: ứng dụng nhận được message đang được xử lý bởi tiến trình khác, gây xử lý trùng.

Nguyên nhân là VisibilityTimeout ngắn hơn thời gian xử lý thực tế:

0s   Consumer A nhận message → message BỊ ẨN trong 30 giây
30s  VisibilityTimeout hết hạn → message HIỆN LẠI trong hàng đợi
     ↑ nhưng Consumer A VẪN ĐANG XỬ LÝ
35s  Consumer B nhận cùng message đó → XỬ LÝ TRÙNG
40s  Consumer A xong, gọi DeleteMessage

Cách chữa là đặt VisibilityTimeout dài hơn thời gian xử lý dài nhất:

aws sqs set-queue-attributes --queue-url <url> \
  --attributes VisibilityTimeout=300

Hoặc đặt cho từng lần nhận, linh hoạt hơn:

sqs.receive_message(QueueUrl=url, VisibilityTimeout=300)

Và với công việc có thời gian không đoán trước được, dùng heartbeat: gia hạn định kỳ trong lúc đang xử lý:

while dang_xu_ly():
    time.sleep(20)
    sqs.change_message_visibility(
        QueueUrl=url, ReceiptHandle=receipt, VisibilityTimeout=60)

Cách này tốt hơn việc đặt một timeout rất dài ngay từ đầu: nếu consumer chết giữa chừng, message quay lại hàng đợi nhanh thay vì kẹt cả 5 phút.

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

• A. Tăng ReceiveMessageWaitTimeSeconds — đây là tham số của long polling: nó quyết định chờ bao lâu khi hàng đợi trống. Nó giảm số request rỗng và chi phí, nhưng không ảnh hưởng gì tới việc message bị ẩn bao lâu sau khi đã được nhận.
• B. Tạo RedrivePolicy cho hàng đợi — RedrivePolicy cấu hình dead-letter queue: message hỏng quá maxReceiveCount lần thì chuyển sang hàng đợi khác. Nó xử lý message LỖI, không ngăn được việc message ĐANG XỬ LÝ bị nhận lại.
• D. Tăng DelaySeconds — hoãn message MỚI trước khi nó xuất hiện lần đầu (delay queue). Nó không liên quan tới message đã được nhận.

Ghi nhớ

Bốn tham số thời gian của SQS — phân biệt cho rõ vì chúng rất hay bị lẫn: | Tham số | Áp cho | Việc | Phạm vi | |---|---|---|---| | VisibilityTimeout | message ĐÃ nhận | ẩn trong lúc xử lý | 0 – 12 giờ | | ReceiveMessageWaitTimeSeconds | lời gọi nhận | long polling | 0 – 20 giây | | DelaySeconds | message MỚI | hoãn lần xuất hiện đầu | 0 – 15 phút | | MessageRetentionPeriod | mọi message | giữ bao lâu | 60 giây – 14 ngày |

Cách đặt VisibilityTimeout đúng:

VisibilityTimeout > thời gian xử lý DÀI NHẤT (không phải trung bình)

Hai hệ quả của việc đặt sai: | Đặt | Hậu quả | |---|---| | Quá ngắn | xử lý trùng ← vấn đề của đề bài | | Quá dài | message kẹt lâu khi consumer chết đột ngột |

Và quy tắc vàng cho cặp SQS + Lambda: VisibilityTimeout phải lớn hơn timeout của hàm, khuyến nghị gấp 6 lần. Đây là cấu hình bị sai nhiều nhất, và nó gây ra đúng triệu chứng trong đề.

Cuối cùng, một điểm không thể tránh: SQS standard đảm bảo at-least-once, nên trùng lặp vẫn có thể xảy ra ngay cả khi VisibilityTimeout đúng (do bản chất phân tán của dịch vụ). Consumer phải idempotent. Nếu nghiệp vụ tuyệt đối không chịu được trùng lặp, dùng FIFO queue — nó có khử trùng lặp trong cửa sổ 5 phút, đổi lại thông lượng thấp hơn.

Đáp án

A và D.

• A — Tải tệp ZIP chứa mã hàm lên S3, rồi tham chiếu nó trong tài nguyên AWS::Lambda::Function
• D — Tạo tài nguyên AWS::Lambda::Function và viết mã trực tiếp trong template

Vì sao đúng

CloudFormation có đúng hai cách cung cấp mã cho một hàm Lambda.

A — mã nằm trên S3 (cách dùng cho hầu hết trường hợp thật):

Resources:
  HamXuLy:
    Type: AWS::Lambda::Function
    Properties:
      Handler: index.handler
      Runtime: python3.12
      Role: !GetAtt VaiTroHam.Arn
      Code:
        S3Bucket: kho-trien-khai
        S3Key: ham/xu-ly-v1.2.3.zip
        S3ObjectVersion: abc123        # nên dùng để CloudFormation nhận ra thay đổi

S3ObjectVersion là chi tiết đáng nhớ: nếu bạn ghi đè cùng một S3Key mà không đổi version, CloudFormation không nhận ra có thay đổi và bỏ qua việc cập nhật hàm. Cách phổ biến để tránh là đặt tên tệp có phiên bản hoặc mã băm.

D — mã viết thẳng trong template (chỉ hợp cho hàm rất nhỏ):

Resources:
  HamNho:
    Type: AWS::Lambda::Function
    Properties:
      Handler: index.handler
      Runtime: python3.12
      Role: !GetAtt VaiTroHam.Arn
      Code:
        ZipFile: |
          import json
          def handler(event, context):
              return {'statusCode': 200, 'body': json.dumps('Xin chào')}

Giới hạn của ZipFile là 4.096 ký tự, và nó chỉ hỗ trợ Node.js và Python — nên chỉ dùng cho custom resource nhỏ hoặc hàm tiện ích vài dòng.

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

• B. Tải tệp ZIP lên chính CloudFormation — không có cơ chế nào như vậy: CloudFormation nhận template, không nhận tệp mã. Mã phải nằm trên S3 hoặc viết inline.
• C. Tải mã lên CodeCommit rồi tham chiếu và E. Tải lên kho Git riêng tư rồi tham chiếu — AWS::Lambda::Function không tham chiếu được kho Git. Thuộc tính Code chỉ nhận S3Bucket/S3Key, ZipFile, hoặc ImageUri (container image trong ECR).

Ghi nhớ

Ba cách khai Code trong AWS::Lambda::Function: | Cách | Giới hạn | Dùng khi | |---|---|---| | S3Bucket + S3Key | 50 MB nén / 250 MB giải nén | hầu hết trường hợp | | ZipFile (inline) | 4.096 ký tự, chỉ Node.js và Python | hàm rất nhỏ, custom resource | | ImageUri | 10 GB | container image, thư viện rất nặng |

Cách gọn nhất trong thực tế là để aws cloudformation package hoặc SAM CLI lo bước tải lên S3:

# Viết template với đường dẫn cục bộ
#   CodeUri: ./src

aws cloudformation package \
  --template-file template.yaml \
  --s3-bucket kho-trien-khai \
  --output-template-file da-dong-goi.yaml

aws cloudformation deploy --template-file da-dong-goi.yaml \
  --stack-name ung-dung --capabilities CAPABILITY_IAM

Lệnh package tự nén, tự tải lên S3, và tự thay đường dẫn trong template — với tên object là mã băm nội dung, nên mã không đổi thì không triển khai lại.

Hai lỗi hay gặp khi triển khai Lambda bằng CloudFormation:

1. Quên --capabilities CAPABILITY_IAM — template tạo IAM role nên CloudFormation đòi xác nhận tường minh.
2. Ghi đè cùng S3Key mà quên S3ObjectVersion — hàm không được cập nhật, và không có thông báo lỗi nào.

Đáp án

A — Tạo một CloudTrail trail áp dụng cho tất cả Region, cấu hình ghi log vào một S3 bucket duy nhất.

Vì sao đúng

CloudTrail có sẵn tuỳ chọn multi-region trail cho đúng nhu cầu này — một trail, mọi Region, một bucket:

aws cloudtrail create-trail \
  --name trail-toan-bo \
  --s3-bucket-name kho-cloudtrail-cong-ty \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id alias/khoa-cloudtrail

aws cloudtrail start-logging --name trail-toan-bo

Cờ --is-multi-region-trail là toàn bộ câu trả lời. Nó khiến CloudTrail: | Việc | Chi tiết | |---|---| | Ghi log từ mọi Region hiện có | không phải tạo trail ở từng nơi | | Tự áp dụng cho Region MỚI | AWS mở Region mới, trail tự phủ tới | | Gộp về một bucket | mọi log ở cùng một chỗ, cùng cấu trúc thư mục |

Điểm thứ hai đáng chú ý: với cách tạo trail ở từng Region, mỗi khi AWS mở một Region mới bạn lại phải nhớ tạo thêm — và quên là có một vùng mù trong kiểm toán.

Log được tổ chức sẵn theo Region trong cùng một bucket:

s3://kho-cloudtrail-cong-ty/AWSLogs/123456789012/CloudTrail/
  ├── ap-southeast-1/2026/08/05/...
  ├── us-east-1/2026/08/05/...
  └── eu-west-1/2026/08/05/...

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

• C. Tạo trail ở từng Region, cùng ghi vào một bucket — cho kết quả tương tự nhưng nhiều việc hơn hẳn: phải tạo và bảo trì hàng chục trail, và phải nhớ thêm trail mỗi khi AWS mở Region mới. Trái yêu cầu "EASIEST".
• B. Tạo trail ở từng Region, ghi vào bucket địa phương rồi dùng cross-region replication — phức tạp nhất: hàng chục trail, hàng chục bucket, hàng chục quy tắc nhân bản, cộng thêm chi phí lưu trữ gấp đôi và độ trễ nhân bản.
• D. Tạo multi-region trail nhưng ghi vào bucket địa phương rồi nhân bản — tự mâu thuẫn: một multi-region trail chỉ ghi vào MỘT bucket, không có khái niệm "bucket địa phương" cho từng Region. Và nếu đã có một bucket rồi thì nhân bản để làm gì.

Ghi nhớ

Đặc điểm của CloudTrail: | Đặc điểm | Chi tiết | |---|---| | Event history 90 ngày | miễn phí, bật sẵn, nhưng chỉ management event và không lưu ra S3 | | Trail | lưu lâu dài ra S3, cấu hình được | | Multi-region trail | một trail phủ mọi Region, kể cả Region mới | | Organization trail | một trail cho TOÀN BỘ tổ chức |

Dòng cuối đáng nhớ: với AWS Organizations, organization trail còn tiện hơn — một trail duy nhất thu log của mọi tài khoản thành viên, và tài khoản thành viên không tắt được.

Hai loại sự kiện: | Loại | Nội dung | Chi phí | |---|---|---| | Management event | thao tác quản trị (tạo instance, sửa policy) | trail đầu tiên miễn phí | | Data event | thao tác dữ liệu (s3:GetObject, lambda:Invoke) | có phí, khối lượng rất lớn |

Data event tắt theo mặc định — bật nó cho một bucket bận rộn có thể sinh hàng triệu bản ghi mỗi ngày, nên hãy chọn lọc đúng tài nguyên cần kiểm toán.

Ba việc nên bật cho một trail phục vụ tuân thủ:

1. --enable-log-file-validation — sinh tệp digest có chữ ký để chứng minh log không bị sửa.
2. Mã hoá bằng KMS với CMK riêng.
3. Bucket policy chặt kèm MFA Delete và Object Lock — để ngay cả người có quyền admin cũng không xoá được log.

Và điểm cuối đáng nhấn mạnh: CloudTrail ghi lời gọi API, không ghi traffic của người dùng cuối. Muốn biết ai truy cập ứng dụng thì dùng ALB access log, CloudFront log, hoặc VPC Flow Logs.

Đáp án

D — Tăng kích cỡ EC2 instance VÀ thêm shard vào stream.

Vì sao đúng

Đề mô tả hai nút thắt riêng biệt, và cần đọc kỹ cả hai:

1. EC2 instance đã chạm giới hạn xử lý — nút thắt ở tầng tính toán
2. Stream không đủ shard để chịu tốc độ dữ liệu vào — nút thắt ở tầng nạp

Sửa một cái mà bỏ cái kia thì hệ thống vẫn nghẽn ở chỗ còn lại:

Cảm biến IoT → Kinesis Data Stream → EC2 consumer
                  ↑ thiếu shard        ↑ hết công suất
                  (nút thắt 1)          (nút thắt 2)

Thêm shard để tăng năng lực nạp — mỗi shard cho 1 MB/giây ghi và 2 MB/giây đọc:

aws kinesis update-shard-count \
  --stream-name du-lieu-iot \
  --target-shard-count 20 \
  --scaling-type UNIFORM_SCALING

Tăng kích cỡ instance để consumer theo kịp. Với KCL, mỗi worker xử lý một hoặc nhiều shard, nên nhiều shard hơn cũng đòi nhiều năng lực xử lý hơn.

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

• B. Chỉ tăng số shard — giải quyết nút thắt nạp, nhưng EC2 vẫn hết công suất nên dữ liệu vào nhanh hơn mà không ai xử lý kịp. Độ trễ chỉ càng tăng.
• C. Chỉ tăng kích cỡ EC2 — consumer khoẻ hơn, nhưng stream vẫn không nhận đủ dữ liệu vào vì thiếu shard. Producer sẽ nhận ProvisionedThroughputExceededException.
• A. Tăng số EC2 instance cho bằng số shard — nghe hợp lý về nguyên tắc (một shard chỉ được một KCL worker xử lý tại một thời điểm), nhưng nó hoàn toàn bỏ qua nút thắt về số shard mà đề đã nêu rõ. Thêm instance mà không thêm shard thì các instance dư ra nằm không, vì không có shard nào để nhận.

Phương án A là bẫy tốt nhất vì nó dựa trên một sự thật đúng về KCL, nhưng áp vào sai vấn đề.

Ghi nhớ

Giới hạn của mỗi shard trong Kinesis Data Streams: | Chiều | Giới hạn mỗi shard | |---|---| | Ghi | 1 MB/giây hoặc 1.000 bản ghi/giây | | Đọc (shared fan-out) | 2 MB/giây, tối đa 5 lời gọi GetRecords/giây | | Đọc (enhanced fan-out) | 2 MB/giây RIÊNG cho mỗi consumer |

Dòng cuối đáng nhớ: với shared fan-out, nhiều consumer chia nhau 2 MB/giây; với enhanced fan-out, mỗi consumer có băng thông riêng và độ trễ giảm còn khoảng 70 mili giây.

Quan hệ giữa shard và consumer:

1 shard ←→ tối đa 1 KCL worker tại một thời điểm
N shard ←→ tối đa N worker chạy song song

Nên số instance nhiều hơn số shard là lãng phí — các instance thừa sẽ không nhận được shard nào.

Các metric cần theo dõi để biết nút thắt nằm đâu: | Metric | Ý nghĩa | |---|---| | WriteProvisionedThroughputExceeded | thiếu shard cho ghi | | ReadProvisionedThroughputExceeded | thiếu băng thông đọc | | GetRecords.IteratorAgeMilliseconds | consumer đang tụt lại bao xa | | IncomingBytes, IncomingRecords | lượng dữ liệu vào |

Metric thứ ba là quan trọng nhất khi chẩn đoán: iterator age tăng dần nghĩa là consumer không theo kịp — đúng triệu chứng trong đề.

Và với tải khó dự đoán, chế độ on-demand loại bỏ hẳn việc quản shard — Kinesis tự co giãn tới 200 MB/giây, đổi lại đơn giá cao hơn.

Đáp án

D — Tạo một Lambda layer chứa toàn bộ thư viện tuỳ chỉnh.

Vì sao đúng

Đề nêu ba yêu cầu, và Lambda layer đáp ứng cả ba với công sức thấp nhất:

1. Tập trung thư viện dùng chung
2. Cập nhật với ít công sức nhất
3. Quản lý phiên bản cho thư viện

Layer là một 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/lib/python3.12/site-packages
pip install -r requirements.txt -t python/lib/python3.12/site-packages/
zip -r layer.zip python/

# Xuất bản — mỗi lần xuất bản 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 hàm
aws lambda update-function-configuration \
  --function-name ham-a \
  --layers arn:aws:lambda:ap-southeast-1:123456789012:layer:thu-vien-chung:3

Ba yêu cầu được đáp ứng thế nào: | Yêu cầu | Cách layer đáp ứng | |---|---| | Tập trung | một layer, nhiều hàm dùng chung | | Cập nhật ít công sức | xuất bản version mới rồi trỏ các hàm sang — không phải đóng gói lại mã hàm | | Quản lý phiên bản | mỗi lần publish là một version bất biến, số tăng dầ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, và runtime chỉ tự tìm ở các đường dẫn quy ước: | 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/ |

Lợi ích thêm rất thực dụng: gói triển khai của hàm nhỏ đi rất nhiều, nên mỗi lần sửa mã chỉ phải tải lên vài KB thay vì vài chục MB — vòng lặp phát triển nhanh hơn hẳn.

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

• A. Tạo S3 bucket lưu thư viện — hàm sẽ phải tải thư viện về lúc chạy, tốn thời gian ở mọi cold start, và bạn phải tự viết logic tải và quản lý phiên bản. Layer làm sẵn tất cả.
• B. Tạo CodeCommit repository lưu thư viện — kho Git là nơi tốt để lưu mã nguồn của thư viện, nhưng Lambda không đọc được từ CodeCommit. Bạn vẫn phải có bước đóng gói và phân phối — tức là vẫn cần layer.
• C. Tạo AMI tuỳ chỉnh chứa thư viện — AMI dành cho EC2, Lambda không dùng AMI. Sai hẳn nền tảng.

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, chỉ tạo version mới. 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ộ.
• AWS và nhiều nhà cung cấp có layer công khai sẵn (ví dụ AWS Parameters and Secrets Extension, Datadog, Lambda Powertools).

Đáp án

D — AWS Lambda.

Vì sao đúng

Đề nêu ba dữ kiện, và chúng cùng chỉ về Lambda:

1. Chạy theo lịch hằng ngày
2. Thời gian chạy dưới 60 giây
3. Cần phù hợp nhất và tiết kiệm nhất

Với tác vụ ngắn, chạy một lần mỗi ngày, mô hình trả theo lượng dùng thắng tuyệt đối:

Lambda:      chạy 60 giây/ngày → trả tiền cho 60 giây
EC2/Fargate: phải chạy liên tục hoặc tự khởi động/tắt
             → trả tiền cho thời gian nhàn rỗi

Ước tính cụ thể: một hàm 512 MB chạy 60 giây mỗi ngày trong cả tháng tốn vài xu — và thực tế thường nằm gọn trong gói miễn phí (1 triệu request và 400.000 GB-giây mỗi tháng, không hết hạn).

Lên lịch bằng EventBridge, không cần hạ tầng nào:

aws events put-rule --name chay-hang-ngay \
  --schedule-expression "cron(0 2 * * ? *)"      # 2 giờ sáng mỗi ngày

aws events put-targets --rule chay-hang-ngay \
  --targets "Id"="1","Arn"="arn:aws:lambda:...:function:thu-thap-web"

aws lambda add-permission --function-name thu-thap-web \
  --statement-id EventBridgeInvoke --action lambda:InvokeFunction \
  --principal events.amazonaws.com

Và 60 giây nằm thoải mái trong giới hạn 15 phút của Lambda.

(Một lưu ý thiết kế: đề nói "vài trăm website". Nếu xử lý tuần tự thì 60 giây có thể không đủ — nên thường tách thành một hàm điều phối gọi nhiều hàm con song song, hoặc dùng Step Functions Map state với MaxConcurrency.)

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

• B. Amazon EC2 — trả tiền theo giờ liên tục, kể cả 23 giờ 59 phút không làm gì. Bạn có thể lên lịch bật/tắt instance, nhưng đó là thêm hạ tầng và thêm việc quản lý cho một tác vụ 60 giây.
• A. Amazon ECS Fargate — đỡ hơn EC2 ở khoản vận hành, nhưng task vẫn tính tiền theo thời gian chạy, và thời gian khởi động task (vài chục giây) chiếm tỷ lệ lớn so với 60 giây làm việc thật. Fargate hợp cho tác vụ chạy lâu hoặc cần môi trường container đặc thù.
• C. Amazon API Gateway — không phải dịch vụ tính toán: nó là cửa ngõ cho API. Nó không chạy mã và không lên lịch được.

Ghi nhớ

Chọn dịch vụ tính toán theo dạng tải: | Dạng tải | Chọn | |---|---| | Ngắn, thưa, theo sự kiện hoặc theo lịch | Lambda | | Tác vụ container chạy vài phút tới vài giờ | Fargate / ECS task | | Chạy liên tục, tải đều | EC2 (kèm Savings Plan) | | Xử lý lô lớn, chịu gián đoạn | AWS Batch với Spot |

Giới hạn của Lambda cần đối chiếu trước khi chọn: | Giới hạn | Giá trị | |---|---| | Timeout | 15 phút | | Bộ nhớ | 128 MB – 10.240 MB | | Concurrency mặc định | 1.000 mỗi Region | | /tmp | 512 MB – 10 GB | | Gói triển khai (giải nén) | 250 MB |

Nhận dạng nhanh trong đề: "theo lịch", "chạy ngắn", "cost-effective" ⇒ Lambda + EventBridge. Nếu đề nói "chạy hơn 15 phút" thì Lambda bị loại ngay, và câu trả lời thường là Fargate hoặc Batch.

Và một mẹo tối ưu chi phí ít người dùng: tăng bộ nhớ cho Lambda có thể làm nó RẺ hơn — vì CPU tỷ lệ với bộ nhớ, hàm chạy nhanh hơn và tổng GB-giây có thể giảm. Công cụ AWS Lambda Power Tuning đo giúp bạn điểm tối ưu.

Đáp án

C và E.

• C — aws cloudformation package rồi aws cloudformation deploy
• E — sam package rồi sam deploy

Vì sao đúng

Template trong đề khai CodeUri: . — tức là mã nguồn đang nằm ở thư mục cục bộ. Mà CloudFormation chỉ đọc mã từ S3, nên phải có bước đóng gói và tải lên trước khi triển khai.

Có hai bộ lệnh tương đương làm việc đó.

C — bộ lệnh của CloudFormation:

aws cloudformation package \
  --template-file template.yaml \
  --s3-bucket kho-trien-khai \
  --output-template-file da-dong-goi.yaml

aws cloudformation deploy \
  --template-file da-dong-goi.yaml \
  --stack-name ung-dung \
  --capabilities CAPABILITY_IAM

E — bộ lệnh của SAM CLI:

sam package --output-template-file da-dong-goi.yaml --s3-bucket kho-trien-khai
sam deploy --template-file da-dong-goi.yaml --stack-name ung-dung --capabilities CAPABILITY_IAM

Cả hai làm cùng ba việc: nén thư mục mã, tải lên S3 với tên là mã băm nội dung, và sinh template mới với CodeUri trỏ tới đường dẫn S3:

CodeUri: s3://kho-trien-khai/a1b2c3d4e5f6...    # được thay vào

(Việc dùng mã băm làm tên object rất tiện: mã không đổi thì tên không đổi, nên CloudFormation biết là không cần cập nhật hàm — tránh triển khai lại vô ích.)

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

• D. sam build rồi sam package — đây là phương án gần nhất và cần phân biệt: sam build biên dịch mã và cài phụ thuộc, sam package tải lên S3. Nhưng thiếu hẳn bước deploy — sau hai lệnh này bạn có template đã đóng gói mà chưa triển khai gì cả.
• A. aws serverless package rồi aws serverless deploy — không có lệnh aws serverless trong AWS CLI.
• B. aws cloudformation compile — không có lệnh compile. Và ý tưởng "nhúng mã vào template" cũng không khả thi: giới hạn template là 51.200 byte khi truyền trực tiếp.

Ghi nhớ

Đối chiếu hai bộ lệnh: | CloudFormation CLI | SAM CLI | |---|---| | aws cloudformation package | sam package | | aws cloudformation deploy | sam deploy | | — | sam build (biên dịch, cài phụ thuộc) | | — | sam local invoke (chạy cục bộ) |

Quy trình gọn nhất trong thực tế chỉ có hai lệnh — SAM CLI tự tạo bucket và nhớ cấu hình:

sam build
sam deploy --guided        # lần đầu; sau đó chỉ cần: sam deploy

Hai dòng bắt buộc ở đầu template SAM — đã có trong đề bài:

AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'    # ← thiếu là SAM không hoạt động

Transform là thứ báo cho CloudFormation biến đổi cú pháp SAM thành tài nguyên thật — thiếu nó, AWS::Serverless::Function bị coi là loại tài nguyên không tồn tại.

Các tài nguyên mà lệnh package xử lý — không chỉ Lambda: | Tài nguyên | Thuộc tính được thay | |---|---| | AWS::Serverless::Function | CodeUri | | AWS::Lambda::Function | Code | | AWS::Serverless::Api | DefinitionUri | | AWS::Serverless::LayerVersion | ContentUri | | AWS::CloudFormation::Stack | TemplateURL |

Và nhớ --capabilities CAPABILITY_IAM ở bước deploy: template tạo IAM role nên CloudFormation đòi xác nhận tường minh — thiếu là lỗi ngay.

Đáp án

D — Dùng DynamoDB Time to Live (TTL) để tự động xoá item cũ.

Vì sao đúng

DynamoDB có sẵn tính năng TTL cho đúng nhu cầu này, và nó thoả cả hai tiêu chí của đề — đơn giản nhất và chi phí thấp nhất:

aws dynamodb update-time-to-live \
  --table-name phien-lam-viec \
  --time-to-live-specification "Enabled=true, AttributeName=het_han"

Khi ghi session, kèm theo mốc hết hạn:

import time
table.put_item(Item={
    'session_id': sid,
    'du_lieu': du_lieu,
    'het_han': int(time.time()) + 3600      # DynamoDB tự xoá sau 1 giờ
})

Ba đặc điểm khiến nó thắng tuyệt đối về chi phí: | Đặc điểm | Chi tiết | |---|---| | Việc xoá HOÀN TOÀN MIỄN PHÍ | không tốn WCU nào | | Không cần hạ tầng | không script, không máy chủ, không lịch chạy | | Không ảnh hưởng hiệu năng | chạy nền, không tranh throughput với ứng dụng |

Định dạng bắt buộc: giá trị phải là Unix epoch tính bằng GIÂY, kiểu Number. Dùng mili giây hoặc chuỗi ISO 8601 thì TTL im lặng bỏ qua item đó — lỗi rất khó phát hiện vì không có thông báo nào.

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

• B. Lambda định kỳ quét bảng và xoá item cũ — chạy được nhưng đắt nhất: Scan đọc toàn bộ bảng ở mỗi lần chạy (tốn RCU tỷ lệ với kích thước bảng), rồi mỗi lần xoá tốn WCU. Với bảng session lớn, chi phí này rất đáng kể — trong khi TTL làm cùng việc đó miễn phí.
• C. Dùng CloudWatch để giám sát và xoá item cũ — CloudWatch không xoá dữ liệu: nó là dịch vụ giám sát và cảnh báo. Nó không có cơ chế nào thao tác lên item trong DynamoDB.
• A. Dùng AWS DMS để dọn item cũ — sai công cụ hoàn toàn: DMS (Database Migration Service) dùng để di trú dữ liệu giữa các CSDL. Nó không phải công cụ dọn dẹp.

Ghi nhớ

Yêu cầu để TTL hoạt động: | Yêu cầu | Chi tiết | |---|---| | Kiểu dữ liệu | Number | | Định dạng | Unix epoch tính bằng GIÂY | | Bật ở mức bảng | chỉ định tên thuộc tính | | Item thiếu thuộc tính đó | không bao giờ bị xoá | | Giá trị quá 5 năm trong quá khứ | bị bỏ qua |

Ba điều đáng biết thêm:

1. TTL không đảm bảo thời điểm chính xác — thường trong vài giờ, AWS chỉ cam kết "trong vài ngày". Nếu ứng dụng không được phép thấy session đã hết hạn, hãy lọc thêm ở tầng đọc:

   if item['het_han'] < time.time():
       return None        # coi như hết hạn dù chưa bị xoá
   

2. Item bị TTL xoá vẫn xuất hiện trong DynamoDB Streams, với userIdentity.principalId = "dynamodb.amazonaws.com" — nên bạn lưu trữ dữ liệu hết hạn sang S3 hoặc xử lý hậu kỳ trước khi mất hẳn.
3. Item đã hết hạn nhưng chưa bị xoá vẫn xuất hiện trong Query và Scan.

Các dịch vụ khác cũng có cơ chế hết hạn tương tự — đáng nhớ để so sánh: | Dịch vụ | Cơ chế | |---|---| | DynamoDB | thuộc tính TTL | | ElastiCache Redis | EXPIRE / SETEX | | S3 | lifecycle rule | | CloudWatch Logs | retention policy | | SQS | MessageRetentionPeriod |

Đáp án

C — Tạo custom metric và cấu hình chúng ở dạng high resolution.

Vì sao đúng

Yêu cầu là độ chi tiết dữ liệu một giây, và chỉ high-resolution custom metric cho được điều đó.

CloudWatch có hai độ phân giải: | | Standard resolution | High resolution | |---|---|---| | Chu kỳ | 60 giây | 1 giây | | Chu kỳ alarm cho phép | 60, 300, 900… giây | 10, 30, và bội số của 60 | | Chi phí | thường | cao hơn |

Đăng metric ở độ phân giải cao bằng tham số StorageResolution=1:

aws cloudwatch put-metric-data \
  --namespace "UngDung/HieuNang" \
  --metric-data MetricName=DoTrePhanHoi,Value=0.234,Unit=Seconds,StorageResolution=1

Và với dữ liệu một giây, bạn đặt được alarm phản ứng trong 10 giây:

aws cloudwatch put-metric-alarm \
  --alarm-name do-tre-cao \
  --namespace UngDung/HieuNang --metric-name DoTrePhanHoi \
  --period 10 --evaluation-periods 2 \
  --threshold 1.0 --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:...:canh-bao

Điều này đặc biệt hữu ích cho việc chẩn đoán vấn đề hiệu năng như trong đề: đỉnh tải ngắn vài giây sẽ bị san phẳng và biến mất trong metric chu kỳ 60 giây, nhưng hiện rõ ở độ phân giải một giây.

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

• D. Custom metric ở dạng standard resolution — đúng hướng nhưng chu kỳ là 60 giây, chậm hơn yêu cầu 60 lần.
• A. Custom metric và bật detailed monitoring — nhầm hai khái niệm: detailed monitoring là thiết lập của EC2 (và vài dịch vụ khác), đổi chu kỳ metric từ 5 phút xuống 1 phút. Nó không áp cho custom metric và cũng không xuống được mức một giây.
• B. Không cần làm gì, CloudWatch mặc định dùng standard resolution — mô tả đúng về mặc định, nhưng mặc định chính là thứ không đáp ứng được yêu cầu.

Ghi nhớ

Thời gian lưu dữ liệu của CloudWatch — dữ liệu cũ tự động được gộp lại: | Tuổi dữ liệu | Độ chi tiết còn giữ | |---|---| | 3 giờ đầu | 1 giây (nếu là high-res) | | 15 ngày | 60 giây | | 63 ngày | 5 phút | | 15 tháng | 1 giờ |

Dòng đầu tiên rất quan trọng: dữ liệu một giây chỉ tồn tại 3 giờ. High-resolution dùng để phát hiện và chẩn đoán nhanh, không dùng để phân tích lịch sử dài hạn.

Ba mức chu kỳ trong hệ sinh thái CloudWatch — đừng lẫn: | Khái niệm | Chu kỳ | Áp cho | |---|---|---| | Basic monitoring | 5 phút | EC2, mặc định | | Detailed monitoring | 1 phút | EC2, có phí | | Standard custom metric | 60 giây | metric của bạn | | High-resolution custom metric | 1 giây | metric của bạn, có phí cao hơn |

Mẹo giảm chi phí và số lời gọi khi đăng metric tần suất cao: dùng statistic set thay vì gửi từng điểm một:

--metric-data MetricName=DoTre,StatisticValues={Sum=500,Minimum=1,Maximum=50,SampleCount=100},StorageResolution=1

Một lời gọi mang thông tin của 100 mẫu — vẫn vẽ được biểu đồ đúng mà tốn ít request hơn nhiều.

Và nhớ đặt --treat-missing-data cho alarm ở độ phân giải cao: nếu ứng dụng ngừng gửi metric, alarm rơi vào INSUFFICIENT_DATA chứ không phải ALARM — vô hiệu hoá cảnh báo đúng lúc cần nhất.

Đáp án

B — Đặt tuỳ chọn --invocation-type Event.

Vì sao đúng

AWS CLI dùng tham số --invocation-type để chọn cách gọi hàm, và Event là giá trị cho gọi bất đồng bộ:

aws lambda invoke \
  --function-name xu-ly-don-hang \
  --invocation-type Event \
  --payload '{"don_hang_id":"DH-001"}' \
  response.json

Kết quả trả về ngay lập tức, không chờ hàm chạy xong:

{"StatusCode": 202}

Mã 202 Accepted là dấu hiệu của gọi bất đồng bộ: Lambda đã nhận request và xếp vào hàng đợi nội bộ, nhưng chưa chạy xong. Tệp response.json sẽ rỗng — vì không có kết quả nào để trả về.

Cách nhớ tên: Event = "bắn một sự kiện đi rồi thôi", không chờ phản hồi.

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

• C. --invocation-type Invoke — không phải giá trị hợp lệ. Invoke là tên của API, không phải một loại invocation type. Ba giá trị hợp lệ là RequestResponse, Event, DryRun.
• A. Đặt --payload thành Asynchronous — --payload là DỮ LIỆU truyền vào hàm (JSON đầu vào), không phải nơi khai cách gọi.
• D. Đặt --qualifier thành Asynchronous — --qualifier chọn version hoặc alias của hàm:

  aws lambda invoke --function-name xu-ly --qualifier prod ...
  

  Nó không liên quan tới kiểu gọi.

Ghi nhớ

Ba invocation type của Lambda: | Type | Đồng bộ? | Mã trả về | Thử lại | |---|---|---|---| | RequestResponse (mặc định) | ✅ đồng bộ | 200 + kết quả | không | | Event | ❌ bất đồng bộ | 202 Accepted | 2 lần thêm, rồi DLQ | | DryRun | — | 204 | chỉ kiểm tra quyền và tham số |

Cách chọn: | Tình huống | Kiểu | |---|---| | Cần kết quả trả về ngay (API Gateway, ALB) | RequestResponse | | Xử lý nền, không cần kết quả | Event | | Kiểm tra quyền mà không muốn chạy thật | DryRun |

Hai đặc điểm quan trọng của gọi bất đồng bộ:

1. Lambda tự thử lại 2 lần khi hàm lỗi (tổng 3 lần chạy), và cả ba lần dùng CÙNG một request ID — nên hàm phải idempotent.
2. Nên cấu hình on-failure destination để không mất sự kiện:

   aws lambda put-function-event-invoke-config --function-name xu-ly \
     --maximum-retry-attempts 2 \
     --maximum-event-age-in-seconds 3600 \
     --destination-config '{"OnFailure":{"Destination":"arn:aws:sqs:...:su-kien-loi"}}'
   

Và với các nguồn sự kiện tự động, kiểu gọi đã được định sẵn: | Nguồn | Kiểu gọi | |---|---| | API Gateway, ALB | đồng bộ | | S3, SNS, EventBridge | bất đồng bộ | | SQS, Kinesis, DynamoDB Streams | poll-based (dịch vụ Lambda gọi đồng bộ) |