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

Đáp án

A — Tận dụng việc tái sử dụng môi trường thực thi (execution environment reuse).

Vì sao đúng

Lambda không tạo môi trường mới cho mỗi lần gọi. Sau khi một lần gọi kết thúc, môi trường được giữ lại (đóng băng) một thời gian và tái sử dụng cho lần gọi tiếp theo.

Điều đó tạo ra hai vùng mã với vòng đời khác nhau:

import boto3

s3 = boto3.client('s3')          # ← CHẠY MỘT LẦN mỗi môi trường (cold start)

def lambda_handler(event, context):
    return s3.list_objects_v2(Bucket='kho')   # ← chạy MỖI lần gọi

Nên khởi tạo SDK ngoài handler nghĩa là: lần gọi đầu tiên chịu chi phí khởi tạo, hàng nghìn lần gọi sau dùng lại miễn phí.

Lợi ích đo được: | Việc | Chi phí nếu để trong handler | |---|---| | Khởi tạo client boto3 | 50–200 ms mỗi lần gọi | | Thiết lập kết nối TLS | 20–100 ms | | Kết nối CSDL | 100–500 ms | | Nạp cấu hình từ Secrets Manager | 50–150 ms |

Với hàm được gọi hàng triệu lần, tiết kiệm 100 ms mỗi lần là khác biệt rất lớn về cả độ trễ lẫn hoá đơn.

Các thứ nên khởi tạo ngoài handler: SDK client, kết nối CSDL, cấu hình và bí mật, mô hình machine learning, biên dịch regex.

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

• B. Tạo một instance SDK mới cho mỗi lần gọi — ngược hẳn: đặt ngoài handler chính là để KHÔNG tạo mới mỗi lần. Muốn tạo mới mỗi lần thì phải đặt trong handler.
• C. Cải thiện tính dễ đọc và giảm độ phức tạp — có thể đúng ở mức phụ, nhưng không phải lợi ích CHÍNH mà đề hỏi. Lý do là hiệu năng.
• D. Giảm kích thước gói triển khai — không liên quan: kích thước gói phụ thuộc vào thư viện nào được đóng gói, không phụ thuộc vào vị trí đặt lệnh khởi tạo trong mã.

Ghi nhớ

Vòng đời môi trường thực thi Lambda:

INIT   → khởi tạo runtime + chạy MÃ NGOÀI HANDLER   (cold start)
INVOKE → chạy handler                                (nhiều lần)
SHUTDOWN → huỷ môi trường                            (sau một thời gian rảnh)

Ba hệ quả của việc môi trường được tái sử dụng — không chỉ là lợi ích: | Hệ quả | Chi tiết | |---|---| | Tái dùng kết nối | ✅ lợi ích chính | | /tmp còn dữ liệu cũ | ⚠ tệp từ lần gọi trước vẫn nằm đó | | Biến toàn cục giữ giá trị | ⚠ đừng dùng để lưu trạng thái của một request |

Hai dòng cảnh báo rất đáng nhớ: đừng bao giờ để dữ liệu của người dùng này rò rỉ sang lần gọi phục vụ người dùng khác qua biến toàn cục hay tệp trong /tmp.

Mẫu đúng cho kết nối CSDL:

conn = None                       # ngoài handler

def lambda_handler(event, context):
    global conn
    if conn is None or conn.closed:
        conn = psycopg2.connect(...)    # chỉ nối lại khi cần
    ...

Và nếu cold start vẫn là vấn đề với hàm nhạy cảm về độ trễ, dùng provisioned concurrency — nó khởi tạo sẵn môi trường ấm nên phần INIT đã chạy xong trước khi request tới.

Đáp án

A — Chạy aws cloudformation package để tải mã nguồn lên S3 bucket và sinh ra một template CloudFormation đã được sửa lại.

Vì sao đúng

Vấn đề: template SAM trong đề khai Handler: index.handler nhưng không nói mã nguồn nằm ở đâu. CloudFormation không đọc được tệp trên máy của bạn — nó chỉ nhận mã từ S3.

aws cloudformation package làm cầu nối đó, và nó thực hiện ba việc:

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

Template kết quả trông như sau:

Resources:
  LambdaFunctionWithAPI:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs12.x
      CodeUri: s3://kho-trien-khai-cua-toi/a1b2c3d4e5f6...   # ← được thêm vào

Rồi mới triển khai được:

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

Việc dùng mã băm nội dung làm tên object rất đáng chú ý: 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

• B. aws cloudformation compile để mã hoá base64 và nhúng mã vào template — không có lệnh compile. Và CloudFormation không nhúng được mã nguồn kiểu đó: giới hạn template là 51.200 byte khi truyền trực tiếp (460.800 byte qua S3), quá nhỏ cho hầu hết mã nguồn. (Có thuộc tính ZipFile cho mã inline, nhưng nó giới hạn 4.096 ký tự và chỉ hợp cho hàm rất nhỏ.)
• C. aws lambda zip để đóng gói mã cùng template — không có lệnh này trong AWS CLI. Và bản thân việc gộp template với mã vào một ZIP cũng không phải cách CloudFormation làm việc.
• D. aws serverless create-package để nhúng mã trực tiếp vào template — không có lệnh aws serverless trong AWS CLI, và lại là ý tưởng nhúng mã vốn không khả thi.

Ghi nhớ

Hai bộ lệnh tương đương cho quy trình SAM: | CloudFormation CLI | SAM CLI | |---|---| | aws cloudformation package | sam build + sam package | | aws cloudformation deploy | sam deploy |

SAM CLI gọn hơn nhiều vì gộp cả hai bước, 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 trong template SAM:

AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'    # ← THIẾU DÒNG NÀY thì SAM không hoạt động

Transform là thứ báo cho CloudFormation biết phải biến đổi cú pháp SAM thành tài nguyên CloudFormation 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à 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 (nested stack) |

Đáp án

C — Liên hệ AWS và xin tăng hạn mức concurrent executions.

Vì sao đúng

Bắt đầu bằng phép tính concurrency:

Concurrency = số lần gọi mỗi giây × thời lượng mỗi lần (giây)
            = 50 × 100
            = 5.000

Và so với hạn mức mặc định:

Cần        : 5.000
Mặc định   : 1.000 mỗi Region
             ─────
Thiếu      : 4.000

Nhu cầu vượt xa hạn mức của cả tài khoản, nên không có cách nào khác ngoài việc xin tăng — đây là hạn mức mềm (soft limit), AWS tăng được qua Service Quotas hoặc AWS Support:

aws service-quotas request-service-quota-increase \
  --service-code lambda \
  --quota-code L-B99A9384 \
  --desired-value 6000

Điểm cần nhấn mạnh: hạn mức 1.000 là của toàn tài khoản trong một Region, chia sẻ cho mọi hàm Lambda. Nên kể cả khi hàm này là hàm duy nhất, nó vẫn không thể vượt 1.000.

Với nguồn là Kinesis, bị throttle còn có hậu quả riêng: Lambda thử lại bản ghi cho tới khi thành công hoặc hết hạn giữ dữ liệu, và vì Kinesis xử lý theo thứ tự trong mỗi shard, một shard bị kẹt sẽ chặn toàn bộ bản ghi phía sau nó.

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

• D. Tăng concurrency limit cho hàm — đây là bẫy tinh vi nhất: reserved concurrency của một hàm KHÔNG THỂ vượt quá hạn mức của tài khoản. Bạn không "cấp" thêm concurrency được — bạn chỉ chia phần trong tổng 1.000 đang có. Đặt reserved concurrency ở đây thậm chí còn giới hạn hàm chặt hơn.
• A. Không cần làm gì, Lambda tự đáp ứng được — sai: 5.000 vượt hạn mức mặc định, và hàm sẽ bị throttle ngay khi tải lên tới mức thiết kế.
• B. Cài đặt exponential backoff trong mã hàm — sai chỗ: throttle xảy ra trước khi hàm được gọi — Lambda từ chối lời gọi, nên mã bên trong hàm không bao giờ chạy để mà thử lại. (Backoff hữu ích cho lỗi mà hàm gặp khi gọi dịch vụ khác, không phải cho việc chính hàm bị throttle.)

Ghi nhớ

Công thức cần thuộc:

Concurrency = Requests/giây × Thời lượng (giây)

Nhận xét quan trọng: thời lượng chạy ảnh hưởng tới concurrency mạnh ngang số request. Trong bài này, tối ưu hàm từ 100 giây xuống 20 giây sẽ giảm concurrency cần thiết từ 5.000 xuống 1.000 — vừa khít hạn mức mặc định. Đó thường là hướng đáng cân nhắc trước khi xin tăng hạn mức.

Các hạn mức của Lambda: | Hạn mức | Giá trị | Loại | |---|---|---| | Concurrent executions | 1.000 mỗi Region | mềm — tăng được | | Burst concurrency | 500–3.000 tuỳ Region | mềm | | Timeout | 15 phút | cứng | | Bộ nhớ | 128 MB – 10.240 MB | cứng | | Kích thước gói (ZIP giải nén) | 250 MB | cứng |

Phân biệt hai khái niệm hay bị lẫn: | | Reserved concurrency | Hạn mức tài khoản | |---|---|---| | Là gì | phần dành riêng cho một hàm | tổng của cả Region | | Tăng được | chỉ trong phạm vi tổng | xin AWS tăng | | Đặt = 0 | tắt hàm | — |

Đáp án

B — AWS CodeCommit.

Vì sao đúng

Đề mô tả chính xác một hệ thống quản lý phiên bản (version control system) bằng hai đặc điểm kỹ thuật:

1. Hỗ trợ các lô thay đổi trên nhiều tệp — chính là commit trong Git
2. Phân nhánh song song — chính là branch

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

git checkout -b tinh-nang/thanh-toan     # phân nhánh song song
git add src/api.js src/db.js README.md
git commit -m "Thêm module thanh toán"    # một lô thay đổi trên nhiều tệp
git push origin tinh-nang/thanh-toan

Cộng thêm các đặc điểm của một dịch vụ được quản lý: | Đặc điểm | Chi tiết | |---|---| | Mã hoá | at-rest (KMS) và in-transit, mặc định | | Bền và sẵn sàng cao | lưu trữ dư thừa trên nhiều AZ | | Phân quyền bằng IAM | tới từng kho, từng nhánh | | Pull request và code review | có sẵn | | Không giới hạn dung lượng kho | — |

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

• D. Amazon S3 — có versioning, nhưng versioning của S3 là theo TỪNG OBJECT, không phải theo tập thay đổi. Nó không có khái niệm nhánh, merge, diff, hay commit message. Bạn không thể trả lời câu hỏi "thay đổi nào đã sửa năm tệp này cùng lúc, và vì sao?" — mà đó chính là "batch of changes".
• A. AWS CodePipeline — điều phối quy trình CI/CD: nó lấy mã từ nơi khác (CodeCommit, GitHub, S3) rồi chạy build và deploy. Nó không lưu trữ mã và không có lịch sử phiên bản.
• C. AWS CodeBuild — biên dịch mã và chạy test. Cũng lấy mã từ nơi khác, cũng không lưu trữ gì.

Ghi nhớ

So sánh S3 versioning với version control thật — đây là điểm phân biệt chính của câu này: | | S3 Versioning | Git (CodeCommit) | |---|---|---| | Đơn vị thay đổi | một object | một commit gồm nhiều tệp | | Nhánh song song | ❌ | ✅ | | Merge, diff | ❌ | ✅ | | Thông tin thay đổi | chỉ thời điểm và ai ghi | tác giả + thông điệp + diff đầy đủ | | Review trước khi nhận | ❌ | ✅ pull request |

Vai trò từng dịch vụ trong bộ công cụ phát triển: | Dịch vụ | Việc | |---|---| | CodeCommit | lưu trữ mã nguồn (Git) | | CodeBuild | biên dịch, test, đóng gói | | CodeDeploy | triển khai | | CodePipeline | điều phối toàn bộ | | CodeArtifact | kho package (npm, Maven, PyPI) |

Nhận dạng nhanh: đề nói "version control", "branching", "collaborative development" ⇒ CodeCommit.

(Ghi chú thời sự: từ 25/7/2024, AWS ngừng cho khách hàng mới tạo repository trên CodeCommit; các tài khoản đã dùng vẫn hoạt động và AWS cam kết tiếp tục vận hành. Với dự án mới, dùng GitHub, GitLab hoặc Bitbucket — chúng 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

C — Bật DynamoDB Stream và kích hoạt hàm Lambda đồng bộ (synchronously) từ stream.

Vì sao đúng

Cụm từ "item lifecycle activity" trong đề chỉ các thay đổi ở mức item — thêm, sửa, xoá. Đó chính xác là những gì DynamoDB Streams ghi lại:

Ứng dụng ghi vào bảng
      ↓ DynamoDB tự phát bản ghi thay đổi
  DynamoDB Streams
      ↓ event source mapping
    Lambda được gọi

Điểm phân biệt của câu này là chữ "synchronously", và nó cần giải thích vì rất dễ hiểu nhầm.

Với nguồn kiểu poll-based (DynamoDB Streams, Kinesis, SQS), cơ chế hoạt động thế này:

1. Dịch vụ Lambda (không phải hàm của bạn) chủ động poll stream
2. Khi có bản ghi, nó gom thành lô rồi gọi hàm của bạn ĐỒNG BỘ
3. Nó chờ kết quả: thành công thì chuyển tiếp (checkpoint), thất bại thì thử lại cùng lô đó

Vì sao phải đồng bộ: DynamoDB Streams đảm bảo thứ tự trong mỗi shard. Nếu gọi bất đồng bộ, dịch vụ Lambda sẽ không biết lô nào đã xử lý xong, và thứ tự sẽ vỡ — bản ghi sau có thể được xử lý trước bản ghi trước.

aws lambda create-event-source-mapping \
  --function-name xu-ly-thay-doi \
  --event-source-arn arn:aws:dynamodb:...:table/don-hang/stream/2026-08-05T00:00:00.000 \
  --starting-position LATEST \
  --batch-size 100 \
  --maximum-retry-attempts 3 \
  --bisect-batch-on-function-error true

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

• D. Bật stream và kích hoạt Lambda bất đồng bộ — chỉ khác đáp án đúng một từ, nhưng đó là từ quyết định. Lambda luôn gọi đồng bộ với nguồn poll-based — bạn không chọn được kiểu gọi. Bất đồng bộ sẽ phá vỡ đảm bảo thứ tự và làm mất khả năng thử lại theo lô.
• A. CloudWatch alarm → SNS → Lambda — alarm hoạt động trên METRIC số, không phản ứng với thay đổi dữ liệu ở mức item. Không có metric nào biểu diễn "item X vừa được cập nhật".
• B. CloudTrail API alarm → SQS → Lambda poll — CloudTrail không ghi thao tác dữ liệu của DynamoDB theo mặc định. Nó ghi lời gọi API quản trị (tạo bảng, sửa capacity). (Có thể bật data event cho DynamoDB, nhưng đó là đường vòng đắt đỏ cho việc mà Streams làm sẵn và miễn phí.)

Ghi nhớ

Kiểu gọi Lambda theo nguồn sự kiện: | 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ộ) | DynamoDB Streams, Kinesis, SQS, MSK | theo cấu hình event source mapping |

Bốn kiểu StreamViewType: | Kiểu | Nội dung | |---|---| | KEYS_ONLY | chỉ khoá chính | | NEW_IMAGE | item sau thay đổi | | OLD_IMAGE | item trước thay đổi | | NEW_AND_OLD_IMAGES | cả hai — linh hoạt nhất |

Hai tham số quan trọng để tránh "poison pill" chặn cả shard: | Tham số | Việc | |---|---| | BisectBatchOnFunctionError | chia đôi lô khi lỗi để cô lập bản ghi hỏng | | MaximumRetryAttempts | giới hạn số lần thử, tránh kẹt vĩnh viễn | | DestinationConfig | gửi bản ghi hỏng vào SQS/SNS để điều tra |

Không đặt chúng thì một bản ghi gây lỗi sẽ chặn toàn bộ shard cho tới khi hết hạn 24 giờ — sự cố rất khó chịu và khá phổ biến.

Và nhớ: Streams đảm bảo at-least-once khi Lambda đọc, nên hàm phải idempotent.

Đáp án

A và B.

• B — AWS::Serverless::Function cho hàm Lambda
• A — AWS::Serverless::SimpleTable cho bảng DynamoDB

Vì sao đúng

SAM cung cấp một tập loại tài nguyên rút gọn, giúp khai serverless bằng vài dòng thay vì hàng chục dòng CloudFormation:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  XuLyDonHang:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs20.x
      CodeUri: ./src
      Environment:
        Variables:
          BANG: !Ref BangDonHang
      Policies:
        - DynamoDBCrudPolicy:
            TableName: !Ref BangDonHang

  BangDonHang:
    Type: AWS::Serverless::SimpleTable
    Properties:
      PrimaryKey:
        Name: don_hang_id
        Type: String

SimpleTable đúng như tên gọi: dành cho bảng DynamoDB chỉ có partition key, không có sort key, không có index. Nó ẩn đi phần lớn cấu hình và mặc định dùng on-demand billing.

Đoạn Policies cũng đáng chú ý — SAM policy template sinh ra IAM policy đúng phạm vi mà không cần viết JSON tay. Đây là một trong những tiện ích lớn nhất của SAM.

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

Ba phương án còn lại đều là loại tài nguyên SAM có thật, nhưng không phải thứ đề cần:

• D. AWS::Serverless::Api — khai API Gateway. Đề chỉ nói tới Lambda và DynamoDB. (Và thường không cần khai tường minh: nếu hàm có Events kiểu Api, SAM tự tạo một API ngầm.)
• C. AWS::Serverless::Application — nhúng một ứng dụng lồng nhau, thường lấy từ Serverless Application Repository.
• E. AWS::Serverless::LayerVersion — khai Lambda Layer để dùng chung thư viện.

Ghi chú về chất lượng câu hỏi

Ba phương án B, D, E trong nguồn viết thiếu một dấu hai chấm: AWS::Serverless:Function thay vì AWS::Serverless::Function. Đó là lỗi chính tả khi nhập liệu, không phải một cú pháp khác.

Điều này không làm sai đáp án — B vẫn là lựa chọn duy nhất cho Lambda — nhưng khi viết template thật thì phải đủ hai dấu hai chấm ở cả hai chỗ. Sai một dấu là CloudFormation báo loại tài nguyên không tồn tại.

Ghi nhớ

Các loại tài nguyên của SAM: | Loại | Sinh ra | |---|---| | AWS::Serverless::Function | Lambda + IAM role + log group | | AWS::Serverless::SimpleTable | bảng DynamoDB đơn giản | | AWS::Serverless::Api | API Gateway REST API | | AWS::Serverless::HttpApi | API Gateway HTTP API | | AWS::Serverless::StateMachine | Step Functions | | AWS::Serverless::LayerVersion | Lambda Layer | | AWS::Serverless::Application | nested stack |

Khi nào không dùng SimpleTable: nó chỉ hỗ trợ partition key. Cần sort key, GSI, LSI, stream hay TTL thì phải dùng thẳng AWS::DynamoDB::Table — và SAM cho phép trộn cả hai loại trong cùng một template.

Hai dòng bắt buộc ở đầu mọi template SAM:

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

Và phần Globals đáng dùng để tránh lặp lại cấu hình chung:

Globals:
  Function:
    Runtime: nodejs20.x
    Timeout: 30
    MemorySize: 512
    Tracing: Active

Đáp án

C — Tạo flow log trong VPC và xuất dữ liệu ra Amazon S3.

Vì sao đúng

Đề mô tả chính xác chức năng của VPC Flow Logs: ghi lại thông tin về traffic IP đi vào và đi ra các network interface trong VPC.

Mỗi bản ghi chứa metadata của một luồng:

2 123456789012 eni-abc 10.1.0.5 10.1.2.8 43521 443 6 25 3400 1628... 1628... ACCEPT OK
                       └nguồn┘  └─đích─┘ └cổng┘  └gt┘ └gói┘└byte┘         └kết quả┘

Trường ACCEPT/REJECT ở cuối là thứ hữu ích nhất khi chẩn đoán: nó cho biết traffic được cho qua hay bị security group/NACL chặn.

Flow log tạo được ở ba mức: | Mức | Phạm vi | |---|---| | VPC | mọi ENI trong VPC — đúng yêu cầu đề | | Subnet | mọi ENI trong subnet | | ENI | một network interface |

aws ec2 create-flow-logs \
  --resource-type VPC --resource-ids vpc-abc123 \
  --traffic-type ALL \
  --log-destination-type s3 \
  --log-destination arn:aws:s3:::kho-flow-logs/vpc/ \
  --destination-options FileFormat=parquet,HiveCompatiblePartitions=true

Chọn S3 làm đích rất hợp cho ứng dụng tài chính như trong đề: rẻ hơn CloudWatch Logs đáng kể cho khối lượng lớn, lưu được lâu dài phục vụ kiểm toán, và truy vấn được bằng Athena.

Hai tuỳ chọn ở dòng cuối đáng bật: định dạng Parquet giảm 80–90% dung lượng và chi phí truy vấn, còn phân vùng kiểu Hive giúp Athena chỉ quét đúng khoảng thời gian cần.

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

• D. Tạo flow log và xuất ra CloudTrail — CloudTrail không phải đích hợp lệ của flow log. Ba đích được hỗ trợ là CloudWatch Logs, S3, và Kinesis Data Firehose. Ngoài ra CloudTrail là dịch vụ ghi lời gọi API quản trị, không nhận dữ liệu từ nơi khác.
• B. "Ghi thông tin trực tiếp vào CloudWatch Logs" — thiếu mất bước quan trọng: phải tạo flow log trước. Traffic không tự chảy vào CloudWatch Logs; flow log mới là cơ chế thu thập. (CloudWatch Logs là một đích hợp lệ, nhưng phương án bỏ qua việc phải tạo flow log.)
• A. Thu thập thông tin bằng Network ACL — NACL là bộ lọc, không phải công cụ ghi log. Nó cho phép hoặc chặn traffic ở mức subnet, nhưng không ghi lại gì cả.

Ghi nhớ

Ba đích của VPC Flow Logs: | Đích | Hợp cho | |---|---| | CloudWatch Logs | cảnh báo gần thời gian thực, dùng metric filter | | S3 | lưu trữ lâu dài, rẻ, truy vấn bằng Athena | | Kinesis Data Firehose | đẩy sang hệ thống phân tích bên ngoài |

Ba loại traffic ghi được: ACCEPT, REJECT, hoặc ALL.

Ba giới hạn cần biết:

1. Không ghi nội dung gói tin — chỉ metadata. Cần nội dung thì dùng Traffic Mirroring.
2. Bỏ qua một số loại traffic: DNS tới Amazon DNS server, DHCP, metadata service (169.254.169.254), Windows license activation.
3. Không phải thời gian thực — bản ghi được gom lô, độ trễ 1 hoặc 10 phút tuỳ cấu hình.

Truy vấn flow log bằng Athena để tìm traffic bị chặn:

SELECT srcaddr, dstaddr, dstport, count(*) AS so_lan
FROM vpc_flow_logs
WHERE action = 'REJECT' AND day = '2026-08-05'
GROUP BY srcaddr, dstaddr, dstport
ORDER BY so_lan DESC LIMIT 20;

Và với việc chẩn đoán một sự cố kết nối cụ thể, có công cụ nhanh hơn: VPC Reachability Analyzer phân tích tĩnh cấu hình và chỉ thẳng ra thành phần đang chặn, không cần chờ traffic thật đi qua.

Đáp án

B — Eventually consistent read, 15 RCU, item 1 KB.

Vì sao đúng

Câu hỏi là: cấu hình nào tận dụng throughput hiệu quả nhất — tức là cùng một lượng RCU thì đọc được nhiều item nhất.

Nhắc lại công thức RCU:

Đơn vị đọc = ceil(kích_thước / 4 KB)
Strongly consistent  : 1 RCU  cho mỗi đơn vị
Eventually consistent: 0,5 RCU cho mỗi đơn vị  (tức 1 RCU đọc được 2 đơn vị)

Tính số item đọc được mỗi giây cho từng phương án:

B cho 30 item mỗi giây — cao nhất.

Hai yếu tố khiến B thắng:

1. Item 1 KB vẫn tính là 1 đơn vị (tối thiểu là 4 KB), nhưng nó có nhiều RCU hơn — 15 so với 5.
2. Eventually consistent nhân đôi số item so với strongly consistent cùng mức RCU.

Và với bảng lưu log như đề mô tả, eventually consistent hoàn toàn phù hợp: log không cần đọc được tức thì ngay sau khi ghi, nên trả gấp đôi tiền cho tính nhất quán mạnh là lãng phí.

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

• D. Strongly consistent, 15 RCU, item 1 KB — cùng RCU với B nhưng chỉ đọc được một nửa số item, vì strongly consistent tốn gấp đôi.
• A. Eventually consistent, 5 RCU, item 4 KB — loại đọc rẻ nhưng chỉ có 5 RCU, nên chỉ được 10 item/giây.
• C. Strongly consistent, 5 RCU, item 4 KB — kém nhất: vừa ít RCU vừa dùng loại đọc đắt, chỉ 5 item/giây.

Ghi nhớ

Một điểm quan trọng ẩn trong bài này: item 1 KB và item 4 KB tốn RCU BẰNG NHAU, vì đơn vị tính là 4 KB và luôn làm tròn lên.

Item 0,5 KB → 1 đơn vị
Item 1 KB   → 1 đơn vị     ← lãng phí 3 KB "đã trả tiền"
Item 4 KB   → 1 đơn vị     ← tận dụng tối đa
Item 4,1 KB → 2 đơn vị     ← tốn gấp đôi vì lố 0,1 KB

Hệ quả thực tế: gom nhiều bản ghi nhỏ vào một item gần 4 KB sẽ tiết kiệm đáng kể — với bảng log, gộp nhiều dòng log của cùng một phiên vào một item là tối ưu đáng cân nhắc. Và tránh để item lố qua bội số của 4 KB một chút.

Hai bảng công thức, chú ý đơn vị khác nhau:

RCU (4 KB):  strongly × 1  |  eventually × 0,5  |  transactional × 2
WCU (1 KB):  ghi thường × 1                     |  transactional × 2

Cách chọn loại đọc trong thực tế: | Dữ liệu | Loại đọc | |---|---| | Log, thống kê, nội dung ít đổi | eventually consistent — rẻ một nửa | | Số dư, tồn kho, đọc lại ngay sau khi ghi | strongly consistent |

Mặc định của DynamoDB đã là eventually consistent — nhiều ứng dụng bật ConsistentRead=True mà không thực sự cần, và trả gấp đôi tiền cho việc đó.

Đáp án

C — Cognito user pools và identity pools dùng cùng nhau.

Vì sao đúng

Đề nêu ba yêu cầu, và chúng đòi cả hai thành phần của Cognito:

Đây là kiến trúc chuẩn khi ứng dụng vừa cần xác thực vừa cần gọi thẳng dịch vụ AWS:

Người dùng đăng nhập
      ↓
  USER POOL  (xác thực: đăng ký, đăng nhập, MFA, quên mật khẩu)
      ↓ phát ra JWT
  IDENTITY POOL  (đổi JWT lấy credential AWS)
      ↓ credential tạm thời
  Gọi S3, DynamoDB trực tiếp

User pool lo việc tự đặt lại mật khẩu — hoàn toàn không cần viết mã:

// Bước 1: gửi mã xác nhận qua email hoặc SMS
await cognito.forgotPassword({ Username: 'nguoidung@example.com' });

// Bước 2: đặt mật khẩu mới bằng mã nhận được
await cognito.confirmForgotPassword({
  Username: 'nguoidung@example.com',
  ConfirmationCode: '123456',
  Password: 'MatKhauMoi!2026'
});

Identity pool lo phần quyền AWS, và nó còn cho phép phân quyền tới từng người:

"Resource": "arn:aws:s3:::kho/${cognito-identity.amazonaws.com:sub}/*"

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

• A. Identity pool + IAM — thiếu user pool, tức là thiếu thư mục người dùng. Identity pool không lưu người dùng và không có chức năng đặt lại mật khẩu — nó chỉ đổi danh tính đã xác thực từ nơi khác lấy credential AWS.
• B. User pool + KMS — có quản lý người dùng và đặt lại mật khẩu, nhưng KMS là dịch vụ quản lý KHOÁ MÃ HOÁ, không cấp quyền truy cập S3 hay DynamoDB. Thiếu mắt xích để gọi dịch vụ AWS.
• D. Identity pool + STS — STS chính là thứ identity pool gọi bên dưới (AssumeRoleWithWebIdentity), nên nêu nó không thêm gì. Và vẫn thiếu user pool.

Ghi nhớ

Cách chọn nhanh khi làm bài: | Đề nói | Chọn | |---|---| | "đăng ký, đăng nhập, quản lý người dùng" | user pool | | "truy cập dịch vụ AWS", "quyền theo từng người" | identity pool | | cả hai | cả hai ← câu này |

Các luồng có sẵn của user pool — không phải viết mã cho bất kỳ luồng nào: | Luồng | API | |---|---| | Đăng ký | SignUp + ConfirmSignUp | | Đăng nhập | InitiateAuth | | Quên mật khẩu | ForgotPassword + ConfirmForgotPassword | | Đổi mật khẩu | ChangePassword | | MFA | RespondToAuthChallenge |

Và nếu dùng hosted UI, toàn bộ các luồng trên có sẵn giao diện — bạn chỉ cần cấu hình logo và màu sắc.

Đáp án

B — Dùng context.awsRequestId để lấy định danh duy nhất của mỗi lần gọi.

Vì sao đúng

Lambda truyền hai tham số vào handler, và chúng chứa hai loại thông tin khác nhau:

Định danh của lần gọi thuộc về nhóm thứ hai, và tên chính xác là awsRequestId:

exports.handler = async (event, context) => {
    const maYeuCau = context.awsRequestId;

    console.log(`[${maYeuCau}] Bắt đầu xử lý`);
    await xuLy(event);
    console.log(`[${maYeuCau}] Hoàn tất`);

    return { statusCode: 200 };
};

Vì sao nó hữu ích đúng như đề mô tả: cùng một awsRequestId xuất hiện trong ba dòng log hệ thống mà Lambda tự ghi:

START RequestId: 8f3c2a1b-... Version: $LATEST
[8f3c2a1b-...] Bắt đầu xử lý
[8f3c2a1b-...] Hoàn tất
END RequestId: 8f3c2a1b-...
REPORT RequestId: 8f3c2a1b-... Duration: 42.15 ms Billed Duration: 43 ms ...

Nên khi cần điều tra một lần chạy cụ thể, bạn lọc CloudWatch Logs theo một chuỗi duy nhất và thấy trọn vẹn diễn biến của đúng lần gọi đó — kể cả khi hàng nghìn lần gọi khác đang chạy song song.

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

• A. context.invocationId — không tồn tại. Tên nghe rất hợp lý (và nhiều nền tảng khác dùng tên này), nên đây là bẫy tốt nhất trong bốn phương án.
• C. context.lambdaId — không tồn tại.
• D. event.requestId — sai đối tượng: event chứa dữ liệu của sự kiện, không chứa thông tin về lần gọi. (Có một nhầm lẫn dễ xảy ra ở đây: với API Gateway, event.requestContext.requestId có tồn tại — nhưng đó là request ID của API Gateway, khác với request ID của Lambda. Chúng là hai định danh riêng biệt, và khi gỡ lỗi cần đối chiếu cả hai.)

Ghi nhớ

Các thuộc tính của đối tượng context: | Thuộc tính | Nội dung | |---|---| | awsRequestId | định danh duy nhất của lần gọi | | functionName | tên hàm | | functionVersion | version đang chạy | | invokedFunctionArn | ARN được gọi (cho biết alias nào) | | memoryLimitInMB | bộ nhớ cấu hình | | getRemainingTimeInMillis() | thời gian còn lại trước timeout | | logGroupName, logStreamName | vị trí log |

getRemainingTimeInMillis() đáng dùng hơn nhiều người nghĩ — nó cho phép hàm kết thúc chủ động và có trật tự thay vì bị cắt ngang:

while (conViec()) {
    if (context.getRemainingTimeInMillis() < 5000) {
        await luuTienDo();       // lưu lại để lần sau tiếp tục
        break;
    }
    await xuLyMotPhan();
}

Và với hệ thống nhiều dịch vụ, hãy truyền awsRequestId xuống các lời gọi downstream (qua header hoặc trường trong message) để lần theo được một request qua cả chuỗi. Với X-Ray thì công cụ tương ứng là trace ID — mạnh hơn vì nó tự động liên kết các segment lại thành một bức tranh.