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

Đáp án

C — Phần tử Principal.

Vì sao đúng

Principal là phần tử khai AI được cấp quyền — và nó là đặc trưng riêng của resource-based policy.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ChoDoiPhatTrienTruyCap",
    "Effect": "Allow",
    "Principal": {
      "AWS": [
        "arn:aws:iam::123456789012:user/lap-trinh-vien-a",
        "arn:aws:iam::123456789012:user/lap-trinh-vien-b"
      ]
    },
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::kho-du-an/*"
  }]
}

Principal nhận nhiều dạng, tuỳ đối tượng cần cấp quyền:

"Principal": {"AWS": "arn:aws:iam::123456789012:user/ten"}      // IAM user
"Principal": {"AWS": "arn:aws:iam::123456789012:role/ten"}      // IAM role
"Principal": {"AWS": "123456789012"}                             // cả tài khoản
"Principal": {"Service": "lambda.amazonaws.com"}                 // dịch vụ AWS
"Principal": {"Federated": "cognito-identity.amazonaws.com"}     // danh tính liên kết
"Principal": "*"                                                  // MỌI NGƯỜI — cẩn thận

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

• A. Condition — thêm điều kiện để statement có hiệu lực (IP nguồn, phải dùng HTTPS, phải có MFA, thời gian). Nó thu hẹp quyền, không xác định ai được cấp.

  "Condition": {"Bool": {"aws:SecureTransport": "true"}}
  

• B. Sid — Statement ID, chỉ là nhãn mô tả để con người đọc và để tham chiếu khi sửa policy. Không ảnh hưởng gì tới quyền.
• D. Id — định danh cho toàn bộ policy (không phải cho từng statement). Cũng chỉ là siêu dữ liệu.

Ghi nhớ

Các phần tử của một IAM policy statement: | Phần tử | Việc | Bắt buộc | |---|---|---| | Version | phiên bản ngôn ngữ policy (2012-10-17) | nên có | | Id | định danh cả policy | ❌ | | Sid | nhãn cho một statement | ❌ | | Effect | Allow hoặc Deny | ✅ | | Principal | AI được cấp quyền | ✅ với resource-based | | Action | được làm gì | ✅ | | Resource | trên tài nguyên nào | ✅ | | Condition | điều kiện áp dụng | ❌ |

Khác biệt cốt lõi giữa hai loại policy — chính là ý của câu hỏi này: | | Identity-based | Resource-based | |---|---|---| | Gắn vào | user, group, role | S3 bucket, SQS, SNS, KMS, Lambda | | Có Principal | ❌ (ngầm hiểu là danh tính được gắn) | ✅ bắt buộc | | Truy cập chéo tài khoản | cần cả hai phía cho phép | khai principal trực tiếp |

Đó là lý do resource-based policy đặc biệt hữu ích cho truy cập chéo tài khoản: bạn khai thẳng tài khoản kia trong Principal, không cần tạo role trung gian.

Ba cảnh báo về Principal:

1. "Principal": "*" kết hợp Effect: Allow là mở tài nguyên ra toàn Internet — luôn kèm Condition để thu hẹp.
2. Với Effect: Deny thì "Principal": "*" lại là cách viết đúng cho các guardrail (ví dụ chặn HTTP).
3. Dùng IAM Access Analyzer để phát hiện tài nguyên đang bị chia sẻ ra ngoài tài khoản hoặc ngoài tổ chức — nó quét tự động và cảnh báo.

Đáp án

A và D.

• A — Amazon SQS
• D — Amazon SNS

Vì sao đúng

Đề yêu cầu các microservice giao tiếp bất đồng bộ và ghép lỏng (decoupled). Hai dịch vụ này là công cụ nhắn tin cốt lõi của AWS cho đúng mục đích đó — với hai mô hình bổ sung cho nhau:

A — SQS: hàng đợi, một tới một

Service A → SQS queue → Service B (poll và xử lý)

D — SNS: pub/sub, một tới nhiều

                 ┌→ Service B
Service A → SNS ─┼→ Service C
                 └→ SQS queue → Service D

Và mẫu mạnh nhất là kết hợp cả hai: SNS fan-out sang nhiều SQS queue — mỗi service có hàng đợi riêng, vừa nhận được mọi sự kiện, vừa không mất message khi đang hỏng.

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

• E. Amazon Kinesis — đây là phương án đáng cân nhắc nhất, vì Kinesis cũng truyền dữ liệu bất đồng bộ. Nhưng nó được thiết kế cho luồng dữ liệu khối lượng lớn, có thứ tự, phát lại được (log, telemetry, clickstream) chứ không phải nhắn tin giữa các microservice. Nó đòi quản lý shard và có mô hình chi phí khác hẳn. Với giao tiếp giữa service, SQS và SNS mới là công cụ chuẩn.
• B. Amazon ECS — dịch vụ chạy container. Nó là nơi microservice chạy, không phải cách chúng nói chuyện với nhau.
• C. AWS Lambda — dịch vụ tính toán. Cũng là nơi mã chạy; nó tiêu thụ message từ SQS/SNS chứ không phải cơ chế truyền message.

Hai phương án B và C có điểm chung: chúng là nơi microservice sống, không phải kênh liên lạc.

Ghi nhớ

So sánh ba dịch vụ nhắn tin: | | SQS | SNS | Kinesis | |---|---|---|---| | Mô hình | hàng đợi | pub/sub | luồng | | Số người nhận | một | nhiều | nhiều | | Lưu trữ | 14 ngày | không | tới 365 ngày | | Phát lại | ❌ (đã xoá là hết) | ❌ | ✅ | | Thứ tự | FIFO queue mới có | ❌ | ✅ trong shard | | Quản lý hạ tầng | không | không | quản shard (trừ on-demand) |

Cách chọn: | Nhu cầu | Chọn | |---|---| | Hàng đợi công việc, mỗi việc một lần | SQS | | Một sự kiện, nhiều nơi quan tâm | SNS (thường + SQS) | | Định tuyến sự kiện theo mẫu, nhiều nguồn | EventBridge | | Luồng dữ liệu lớn, cần phát lại và thứ tự | Kinesis |

EventBridge đáng nhắc thêm dù không có trong phương án: với kiến trúc microservice hiện đại, nó thường là lựa chọn tốt hơn SNS vì có lọc theo mẫu sự kiện phong phú, schema registry, và kết nối sẵn với hơn 200 dịch vụ SaaS.

Và mẫu fan-out đáng nhớ như một kiến trúc chuẩn:

Producer → SNS topic ─┬→ SQS queue A → Service A
                      ├→ SQS queue B → Service B
                      └→ SQS queue C → Service C

Đặt SQS ở giữa cho hai lợi ích lớn: message không mất nếu consumer đang hỏng, và mỗi service xử lý theo nhịp riêng của nó.

Đáp án

D — Mã hoá các giá trị bí mật ở phía client bằng encryption helpers.

Vì sao đúng

Yêu cầu rất đặc thù: giá trị phải bị che đi trong Console và trong kết quả API, kể cả với người có quyền dùng khoá.

Đây là chỗ cần phân biệt hai lớp mã hoá của biến môi trường Lambda:

Dòng thứ hai là điểm mấu chốt: mã hoá at-rest không che gì cả trong Console — nó chỉ bảo vệ dữ liệu trên đĩa. Người có quyền lambda:GetFunctionConfiguration vẫn đọc được nguyên văn mật khẩu.

Encryption helpers giải quyết đúng chỗ đó: bạn bấm "Encrypt" trong Console, giá trị được mã hoá bằng CMK ngay tại trình duyệt, và chỉ ciphertext được lưu:

import boto3, os
from base64 import b64decode

kms = boto3.client('kms')

# Giải mã ở giai đoạn INIT — chạy một lần mỗi môi trường, không phải mỗi request
MAT_KHAU = kms.decrypt(
    CiphertextBlob=b64decode(os.environ['MAT_KHAU_DA_MA']),
    EncryptionContext={'LambdaFunctionName': os.environ['AWS_LAMBDA_FUNCTION_NAME']}
)['Plaintext'].decode()

def lambda_handler(event, context):
    ket_noi(mat_khau=MAT_KHAU)

Đặt lệnh giải mã ngoài handler là chi tiết quan trọng cho vế "MINIMIZE latency": nó chạy một lần khi khởi tạo môi trường, rồi được tái sử dụng qua hàng nghìn lần gọi.

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

• C. Mã hoá bằng customer-managed CMK — đây là bẫy chính, và nó chỉ là mã hoá at-rest với khoá của bạn. Nó cải thiện kiểm soát khoá và có vết kiểm toán, nhưng Console vẫn hiện bản rõ — không đáp ứng yêu cầu "obscured in the console".
• B. Lưu giá trị đã mã hoá trong bucket S3 rồi đọc từ mã — thêm độ trễ ở mọi lần khởi tạo (một lời gọi mạng tới S3), thêm quyền phải quản lý, và thêm một dịch vụ vào đường đi. Trái yêu cầu "minimize complexity and latency".
• A. Dùng hạ tầng mã hoá bên ngoài — phức tạp nhất: phải tự dựng và vận hành hệ thống mã hoá riêng, trong khi Lambda đã tích hợp sẵn với KMS.

Ghi nhớ

Hai lớp bảo vệ biến môi trường Lambda:

Lớp 1 — at-rest: LUÔN bật, tự động, KHÔNG che trong Console
Lớp 2 — encryption helpers: tuỳ chọn, CHE trong Console và API

Ba cách lưu bí mật cho Lambda, và cách chọn: | Cách | Che trong Console | Xoay vòng | Độ trễ | |---|---|---|---| | Biến môi trường thường | ❌ | ❌ | không | | Encryption helpers | ✅ | ❌ | một lần khi INIT | | Secrets Manager | ✅ | ✅ tự động | một lần khi INIT | | SSM Parameter Store (SecureString) | ✅ | ❌ | một lần khi INIT |

Với đề này, encryption helpers thắng vì nó đơn giản nhất — không thêm dịch vụ nào. Nhưng trong thực tế, nếu bí mật cần xoay vòng định kỳ (mật khẩu CSDL chẳng hạn), Secrets Manager là lựa chọn đúng hơn.

Hai lưu ý khi dùng encryption helpers:

1. Bắt buộc dùng customer-managed CMK — không dùng được với khoá mặc định của Lambda.
2. Encryption context phải khớp giữa lúc mã hoá và lúc giải mã. Console tự đặt LambdaFunctionName, nên mã giải mã cũng phải truyền đúng giá trị đó — quên là nhận lỗi InvalidCiphertextException khá khó hiểu.

Đáp án

C — AWS X-Ray.

Vì sao đúng

Đề mô tả đúng bài toán mà X-Ray sinh ra để giải: theo dấu và phân tích request người dùng qua API Gateway rồi xuống các dịch vụ backend.

Kiến trúc trong đề có ba chặng, và mỗi chặng đều có thể là nguyên nhân:

Client → API Gateway → Lambda authorizer → Lambda backend → (DynamoDB, S3…)

X-Ray gắn một trace ID vào mỗi request và theo nó qua toàn bộ chuỗi, rồi dựng ra: | Tính năng | Cho biết | |---|---| | Service map | sơ đồ toàn bộ đường đi, chặng lỗi hiện màu đỏ | | Trace timeline | thời gian ở từng chặng — chậm ở đâu | | Exception và stack trace | lỗi cụ thể của từng segment | | Annotation | lọc trace theo user_id, order_id… |

Với kiến trúc có Lambda authorizer, X-Ray đặc biệt hữu ích: nó tách riêng thời gian ở authorizer khỏi thời gian ở backend — điều mà metric của API Gateway không cho thấy.

Bật rất gọn:

# API Gateway
aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations op=replace,path=/tracingEnabled,value=true

# Lambda
aws lambda update-function-configuration \
  --function-name xu-ly --tracing-config Mode=Active

Và với mã Lambda, chỉ cần bọc SDK là mọi lời gọi downstream tự xuất hiện trong trace:

from aws_xray_sdk.core import patch_all
patch_all()

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

• B. Amazon CloudWatch — cho metric (Latency, 5XXError, Count) và log. Nó cho biết có bao nhiêu lỗi và lúc nào, nhưng không cho biết một request cụ thể đã đi qua đâu và hỏng ở chặng nào. Hữu ích để phát hiện, không đủ để chẩn đoán trong kiến trúc nhiều tầng.
• A. VPC Flow Logs — ghi metadata luồng IP ở tầng mạng. Nó không biết gì về request HTTP hay về logic ứng dụng. Và các dịch vụ trong đề (API Gateway, Lambda không gắn VPC) không sinh flow log nào.
• D. Amazon Inspector — công cụ quét lỗ hổng bảo mật trên EC2, container image và Lambda. Nó tìm CVE và cấu hình rủi ro, không gỡ lỗi hành vi ứng dụng.

Ghi nhớ

Bốn công cụ quan sát, mỗi cái trả lời một câu hỏi: | Công cụ | Trả lời | |---|---| | X-Ray | Request đi qua đâu, hỏng và chậm ở CHẶNG NÀO? | | CloudWatch Metrics | Có bao nhiêu lỗi, khi nào? | | CloudWatch Logs | Ứng dụng đã ghi ra gì? | | CloudTrail | Ai gọi API quản trị? | | Inspector | Có lỗ hổng bảo mật nào? |

Nhận dạng nhanh: đề nói "trace", "through to the back end", "across services", "which component is failing" ⇒ X-Ray.

Hai khái niệm cần phân biệ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 | | Dùng cho | user_id, order_id | payload chi tiết để đọc |

Muốn tìm trace của một đơn hàng cụ thể thì phải ghi nó làm annotation — ghi vào metadata sẽ không tìm được.

Và một lưu ý về sampling: mặc định X-Ray chỉ lấy 1 request mỗi giây cộng 5% số còn lại. Với sự cố hiếm gặp, hãy khai sampling rule riêng để đảm bảo loại request đó luôn được ghi lại — nếu không, đúng lúc cần nhất thì không có dữ liệu.

Đáp án

C — Gọi hàm Lambda bất đồng bộ với invocation type Event và xử lý các tệp song song.

Vì sao đúng

Đề nêu ba dữ kiện, và chúng cùng chỉ về gọi bất đồng bộ:

1. Mỗi tệp mất khoảng 3 phút để xử lý
2. Hàm không trả về dữ liệu quan trọng nào
3. Cần cách nhanh nhất để xử lý hết

Dữ kiện thứ hai là chìa khoá: không cần kết quả trả về nghĩa là không cần chờ.

# Gọi bất đồng bộ — trả về NGAY với mã 202, không chờ hàm chạy xong
for tep in danh-sach-tep/*; do
  aws lambda invoke --function-name xu-ly-tep \
    --invocation-type Event \
    --payload "{\"tep\":\"$tep\"}" \
    /dev/null &
done
wait

So sánh thời gian với 100 tệp:

Tuần tự (đồng bộ):    100 × 3 phút = 300 phút (5 giờ)
Song song (bất đồng bộ): ~3 phút     ← tất cả chạy cùng lúc

Cơ chế: với --invocation-type Event, Lambda nhận request, xếp vào hàng đợi nội bộ, rồi trả về 202 Accepted ngay lập tức. Script không bị chặn, nên nó gửi hết 100 request trong vài giây và Lambda chạy 100 hàm song song.

Điều kiện: tổng concurrency phải nằm trong hạn mức. Với 100 tệp thì thoải mái (mặc định 1.000), nhưng với hàng nghìn tệp thì cần tính toán.

Và vì gọi bất đồng bộ, nên cấu hình on-failure destination để không mất tệp nào khi có lỗi:

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

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

• A. Gọi đồng bộ với RequestResponse và xử lý tuần tự — chậm nhất: mỗi lời gọi chặn script 3 phút. Đúng chức năng nhưng hoàn toàn trái yêu cầu "FASTEST".
• B. "Gọi bất đồng bộ với invocation type RequestResponse" — tự mâu thuẫn: RequestResponse chính là kiểu ĐỒNG BỘ. Và vế "xử lý tuần tự" cũng trái yêu cầu.
• D. "Gọi đồng bộ với invocation type Event" — cũng tự mâu thuẫn theo chiều ngược lại: Event chính là kiểu BẤT ĐỒNG BỘ.

Hai phương án B và D là bẫy tốt vì chúng ghép nhầm tên kiểu gọi với tính chất của nó.

Ghi nhớ

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

Cách nhớ: RequestResponse = có response, tức là phải chờ. Event = bắn sự kiện đi rồi thôi.

Cách chọn: | Tình huống | Kiểu | |---|---| | Cần kết quả trả về ngay (API, ALB) | RequestResponse | | Xử lý nền, không cần kết quả | Event | | Muốn xử lý hàng loạt có kiểm soát | SQS + event source mapping |

Dòng cuối đáng cân nhắc cho bài toán thật: với rất nhiều tệp, đưa danh sách vào SQS rồi để Lambda poll thường tốt hơn gọi trực tiếp — bạn được thử lại tự động, DLQ, và kiểm soát được tốc độ bằng BatchSize cùng reserved concurrency, thay vì bắn hàng nghìn request cùng lúc rồi bị throttle.

Và nhớ hai đặc điểm của gọi bất đồng bộ: Lambda tự thử lại 2 lần khi hàm lỗi, và cùng một request ID cho cả ba lần — nên hàm phải idempotent.

Đáp án

A — Cài đặt developer-authenticated identities bằng Amazon Cognito, và lấy credential cho các danh tính đó.

Vì sao đúng

Yêu cầu: gán định danh duy nhất cho mỗi người dùng, bất kể họ dùng thiết bị nào.

Cognito identity pool cấp cho mỗi người dùng một identity ID duy nhất và không phụ thuộc thiết bị:

Người dùng đăng nhập trên điện thoại  → identity ID: ap-southeast-1:abc-123-def
Cùng người dùng trên máy tính bảng    → CÙNG identity ID: ap-southeast-1:abc-123-def

Developer-authenticated identities là cơ chế cho phép bạn dùng hệ thống xác thực của riêng mình rồi vẫn lấy được identity ID và credential AWS:

# Backend của bạn xác thực người dùng theo cách riêng, rồi gọi:
response = cognito_identity.get_open_id_token_for_developer_identity(
    IdentityPoolId='ap-southeast-1:xxxx-xxxx',
    Logins={'login.congty.myapp': 'ma-nguoi-dung-noi-bo-12345'},
    TokenDuration=3600
)
# → trả về IdentityId (duy nhất, ổn định) và OpenIdToken

Điểm quan trọng: bạn ánh xạ định danh nội bộ của mình (ma-nguoi-dung-noi-bo-12345) sang identity ID của Cognito. Người dùng đăng nhập từ thiết bị nào cũng ra cùng một identity ID.

Rồi client đổi token đó lấy credential AWS:

const credentials = fromCognitoIdentityPool({
  identityPoolId: 'ap-southeast-1:xxxx-xxxx',
  logins: { 'cognito-identity.amazonaws.com': openIdToken }
});

Và identity ID dùng được luôn trong IAM policy để phân quyền theo từng người:

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

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

• D. Gán IAM user và role cho từng người dùng — không mở rộng được: giới hạn 5.000 IAM user và 1.000 role mỗi tài khoản. Đề nói hàng trăm người dùng, nhưng ứng dụng di động thì luôn có thể tăng lên hàng nghìn. IAM dành cho nhân sự và ứng dụng, không dành cho người dùng cuối — đây là nguyên tắc quan trọng nhất.
• B. Dùng IAM access key ID làm định danh, không lưu secret key — sai về mọi mặt: vẫn vướng giới hạn 5.000 IAM user, và access key ID không phải định danh người dùng — nó là một phần của credential. Access key không có secret thì cũng vô dụng.
• C. Tạo bảng DynamoDB ánh xạ người dùng với thiết bị — tự dựng lại thứ Cognito làm sẵn, và không giải quyết vế credential: bạn có định danh, nhưng người dùng vẫn không truy cập được dịch vụ AWS. Bạn sẽ phải tự viết thêm toàn bộ phần cấp quyền.

Ghi nhớ

Ba loại danh tính trong Cognito identity pool: | Loại | Nguồn xác thực | |---|---| | Authenticated (public provider) | Google, Facebook, Amazon, Apple, SAML, OIDC | | Developer-authenticated | hệ thống xác thực của riêng bạn | | Unauthenticated (guest) | không đăng nhập |

Loại thứ hai hữu ích khi bạn đã có hệ thống người dùng riêng và không muốn di trú sang Cognito user pool, nhưng vẫn muốn dùng identity pool để cấp credential AWS.

Quy trình developer-authenticated:

1. Người dùng đăng nhập vào hệ thống của BẠN
2. Backend của bạn gọi GetOpenIdTokenForDeveloperIdentity
   → nhận IdentityId + OpenIdToken
3. Trả token cho client
4. Client gọi GetCredentialsForIdentity → nhận credential AWS tạm thời

Bước 2 phải chạy ở backend với credential có quyền phù hợp — không bao giờ ở client.

Và một tính năng liên quan: MergeDeveloperIdentities cho phép gộp hai identity ID làm một — hữu ích khi người dùng ban đầu dùng chế độ khách rồi sau đó mới đăng ký tài khoản, và bạn muốn giữ lại dữ liệu của họ.

Đáp án

C — Thêm một SQS queue giữa tầng web và tầng ứng dụng.

Vì sao đúng

Đề mô tả chính xác vấn đề: tầng web nhận đỉnh traffic đột ngột, tầng ứng dụng không co giãn kịp, và message bị mất.

Nguyên nhân là hai tầng đang ghép chặt và đồng bộ — tầng web gọi thẳng tầng ứng dụng, nên khi tầng sau quá tải thì request rơi mất.

SQS đặt giữa hai tầng biến quan hệ đó thành bất đồng bộ và có đệm:

Trước:  Web tier ──gọi trực tiếp──→ App tier (quá tải → MẤT message)

Sau:    Web tier → SQS queue → App tier (xử lý theo nhịp của mình)
                     ↑
              đệm chứa message trong lúc đỉnh

Ba vấn đề được giải quyết cùng lúc: | Vấn đề | Cách SQS giải quyết | |---|---| | Mất message | lưu tới 14 ngày — không mất dù tầng sau đang hỏng | | Đỉnh tải | hàng đợi hấp thụ đỉnh, tầng sau xử lý dần | | Ghép chặt | hai tầng không cần biết nhau, mở rộng độc lập |

Và có một lợi ích thêm rất đáng giá: hàng đợi trở thành tín hiệu co giãn tốt nhất cho tầng ứng dụng:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name nhom-ung-dung \
  --policy-name theo-do-dai-hang-doi \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "CustomizedMetricSpecification": {
      "MetricName": "ApproximateNumberOfMessagesVisible",
      "Namespace": "AWS/SQS",
      "Dimensions": [{"Name":"QueueName","Value":"hang-doi-ung-dung"}],
      "Statistic": "Average"},
    "TargetValue": 100}'

So với co giãn theo CPU, độ dài hàng đợi phản ánh công việc tồn đọng trực tiếp hơn — nó tăng ngay khi đỉnh đến, trong khi CPU là chỉ báo trễ.

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

• B. Thêm SQS giữa tầng ứng dụng và tầng CSDL — sai vị trí: nút thắt nằm giữa web và app, không phải giữa app và CSDL. Ngoài ra CSDL vốn không phù hợp để giao tiếp qua hàng đợi (bạn cần kết quả truy vấn trả về ngay).
• A. Web tier publish lên SNS topic, app tier đăng ký nhận — SNS không lưu trữ: nếu tầng ứng dụng đang quá tải hoặc hỏng, message mất luôn. Nó là fan-out, không phải đệm. (Mẫu đúng nếu muốn dùng SNS là SNS → SQS → app tier, khi đó SQS vẫn là thứ giải quyết vấn đề.)
• D. Chuyển tầng CSDL sang DynamoDB và bật xử lý session co giãn — giải quyết vấn đề khác: session và loại CSDL không liên quan tới việc message bị mất giữa hai tầng tính toán.

Ghi nhớ

So sánh SQS và SNS trong vai trò tách rời hệ thống: | | SQS | SNS | |---|---|---| | Lưu trữ | ✅ tới 14 ngày | ❌ | | San phẳng đỉnh | ✅ | ❌ | | Số người nhận | một | nhiều | | Mô hình | pull | push |

Nguyên tắc: cần đệm và không được mất dữ liệu ⇒ SQS. Cần một sự kiện tới nhiều nơi ⇒ SNS (và thường kèm SQS phía sau).

Ba tính năng của SQS đáng cấu hình cho kiến trúc này: | Tính năng | Việc | |---|---| | VisibilityTimeout | ẩn message trong lúc xử lý — đặt lớn hơn thời gian xử lý | | Dead-letter queue | tách message hỏng sau maxReceiveCount lần | | Long polling (WaitTimeSeconds=20) | giảm số request rỗng và chi phí |

Và nhớ: SQS standard là at-least-once, nên consumer phải idempotent — cùng một message có thể được xử lý hai lần. Nếu nghiệp vụ tuyệt đối không chịu được trùng lặp, dùng FIFO queue (có khử trùng lặp trong 5 phút), đổi lại thông lượng thấp hơn.

Đáp án

C — Cache tệp trong thư mục /tmp.

Vì sao đúng

Chìa khoá nằm ở một đặc điểm của Lambda: môi trường thực thi được tái sử dụng giữa các lần gọi, và /tmp sống cùng môi trường đó.

Nên tệp tải về một lần vẫn còn nguyên ở các lần gọi sau:

import os, requests

DUONG_DAN = '/tmp/du-lieu.dat'

def lambda_handler(event, context):
    if not os.path.exists(DUONG_DAN):          # chỉ tải ở lần gọi ĐẦU TIÊN
        r = requests.get('https://nguon.example.com/du-lieu.dat')
        with open(DUONG_DAN, 'wb') as f:
            f.write(r.content)

    with open(DUONG_DAN, 'rb') as f:
        return xu_ly(f.read())

Hiệu quả với hàm được gọi nhiều lần mỗi giây:

Không cache: mỗi lần gọi tải 50 MB → vài giây độ trễ + tốn băng thông
Có cache:    lần đầu tải, hàng nghìn lần sau đọc từ đĩa cục bộ → vài mili giây

Vì hàm được gọi liên tục, môi trường luôn ở trạng thái ấm, nên tỷ lệ trúng cache rất cao — chỉ những lần cold start (khi Lambda mở rộng thêm môi trường mới) mới phải tải lại.

Dung lượng /tmp cấu hình được từ 512 MB đến 10 GB, thừa cho tệp 50 MB:

aws lambda update-function-configuration \
  --function-name xu-ly --ephemeral-storage '{"Size": 1024}'

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

• A. Cache tệp trong S3 — vẫn phải tải qua mạng ở MỖI lần gọi. S3 nhanh hơn Internet công khai và rẻ hơn về băng thông, nhưng nó không loại bỏ được lần tải — chỉ rút ngắn nó. /tmp thì loại bỏ hoàn toàn.
• D. Tăng thời gian chạy tối đa của Lambda — chỉ cho phép hàm chạy lâu hơn trước khi bị cắt. Nó không làm gì nhanh hơn, và với hàm gọi nhiều lần mỗi giây, kéo dài thời gian chạy còn làm tăng concurrency và có thể gây throttle.
• B. Đặt Elastic Load Balancer trước hàm Lambda — sai vấn đề hoàn toàn: ALB là cửa ngõ định tuyến traffic vào. Nó không ảnh hưởng gì tới việc hàm tải tệp từ Internet.

Ghi nhớ

Ba vùng lưu trữ của Lambda và vòng đời của chúng: | Vùng | Tồn tại | Ghi được | Kích thước | |---|---|---|---| | /var/task (mã hàm) | suốt vòng đời môi trường | ❌ chỉ đọc | 250 MB | | /tmp | suốt vòng đời môi trường | ✅ | 512 MB – 10 GB | | Biến toàn cục (RAM) | suốt vòng đời môi trường | ✅ | theo bộ nhớ hàm |

Với dữ liệu nhỏ, biến toàn cục còn nhanh hơn /tmp (không chạm đĩa):

du_lieu = None                      # ngoài handler

def lambda_handler(event, context):
    global du_lieu
    if du_lieu is None:
        du_lieu = tai_ve()          # chỉ chạy ở cold start
    return xu_ly(du_lieu)

Nhưng với 50 MB thì /tmp hợp lý hơn — nó không chiếm bộ nhớ mà bạn phải trả tiền theo cấu hình hàm.

Ba cảnh báo quan trọng khi cache trong /tmp:

1. Không chia sẻ giữa các môi trường — mỗi môi trường có /tmp riêng, nên với concurrency cao, tệp sẽ được tải nhiều lần (một lần cho mỗi môi trường).
2. Không đảm bảo tồn tại — luôn kiểm tra os.path.exists trước khi dùng.
3. Đây là chỗ rò rỉ dữ liệu tiềm tàng — tệp của lần gọi trước vẫn còn ở lần gọi sau, có thể phục vụ người dùng khác. Với dữ liệu nhạy cảm, xoá ngay sau khi dùng.

Và nếu tệp thay đổi theo thời gian, nhớ thêm cơ chế làm mới — ví dụ kiểm tra ETag hoặc lưu kèm thời điểm tải và tải lại sau N phút.

Đáp án

D — CodeDeployDefault.LambdaCanary10Percent5Minutes.

Vì sao đúng

Đề đưa ra hai yêu cầu tưởng như mâu thuẫn, và cần đọc kỹ cả hai:

1. Traffic phải chuyển DẦN DẦN (gradually)
2. Trong KHOẢNG THỜI GIAN NGẮN NHẤT

Nên phải chọn cấu hình có chuyển dần nhưng hoàn tất nhanh nhất. So sánh tổng thời gian:

Canary chỉ có hai bước, nên nó nhanh nhất trong các phương án vẫn chuyển dần.

Khai trong template SAM:

Resources:
  HamXuLy:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs20.x
      AutoPublishAlias: live
      DeploymentPreference:
        Type: Canary10Percent5Minutes
        Alarms:
          - !Ref CanhBaoLoi          # tự rollback nếu alarm kêu
        Hooks:
          PreTraffic:  !Ref HamKiemThuTruoc
          PostTraffic: !Ref HamKiemThuSau

Phần Alarms rất đáng dùng: nếu trong 5 phút canary mà CloudWatch alarm chuyển sang ALARM, CodeDeploy tự rollback — bạn không phải ngồi canh.

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

• B. LambdaLinear10PercentEvery1Minute — đây là phương án gần nhất: nó cũng chuyển dần và nhanh hơn A. Nhưng 10 bước × 1 phút = 10 phút, gấp đôi canary.
• A. LambdaLinear10PercentEvery2Minutes — cùng cơ chế nhưng 20 phút, chậm nhất.
• C. CodeDeployDefault.HalfAtATime — cấu hình dành cho EC2/on-premises, không dùng được với Lambda. Nhận biết bằng tên: cấu hình cho Lambda luôn có tiền tố Lambda.

Ghi nhớ

Quy tắc đặt tên của cấu hình CodeDeploy — đọc tên là biết hành vi:

CodeDeployDefault.<NềnTảng><Kiểu><TỷLệ><ThờiGian>
                   Lambda    Canary  10Percent  5Minutes

Các cấu hình cho Lambda:

CodeDeployDefault.LambdaAllAtOnce                    ← ngay lập tức
CodeDeployDefault.LambdaCanary10Percent5Minutes      ← 5 phút
CodeDeployDefault.LambdaCanary10Percent10Minutes
CodeDeployDefault.LambdaCanary10Percent15Minutes
CodeDeployDefault.LambdaCanary10Percent30Minutes
CodeDeployDefault.LambdaLinear10PercentEvery1Minute  ← 10 phút
CodeDeployDefault.LambdaLinear10PercentEvery2Minutes ← 20 phút
CodeDeployDefault.LambdaLinear10PercentEvery3Minutes
CodeDeployDefault.LambdaLinear10PercentEvery10Minutes

Phân biệt ba kiểu: | Kiểu | Số bước | Đặc điểm | |---|---|---| | AllAtOnce | 1 | nhanh nhất, KHÔNG chuyển dần | | Canary | 2 | X% → chờ → 100% | | Linear | nhiều | +X% mỗi N phút |

Cách chọn theo từ khoá trong đề:

• "gradually" + "shortest time" ⇒ Canary với khoảng chờ ngắn nhất ← câu này
• "nhanh nhất, không cần thận trọng" ⇒ AllAtOnce
• "chuyển từ từ, theo dõi kỹ từng bước" ⇒ Linear

Và với Lambda, nhớ hai điều: CodeDeploy chỉ hỗ trợ blue/green (không có in-place), và AutoPublishAlias là bắt buộc trong SAM — thiếu nó thì không có alias để chuyển traffic.

Đáp án

B — Cài đặt dead-letter queue cho các đơn hàng xử lý thất bại.

Vì sao đúng

Đề nêu hai yêu cầu, và DLQ đáp ứng cả hai:

1. Gỡ lỗi các đơn hàng thất bại về sau
2. Xử lý lại chúng khi cần

Dead-letter queue là một hàng đợi riêng, tự động nhận những message đã thất bại quá số lần cho phép:

aws sqs set-queue-attributes --queue-url <url-hang-doi-chinh> \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:...:don-hang-loi\",
                       \"maxReceiveCount\":\"3\"}"
  }'

Đọc thế này: message nào bị nhận và xử lý hỏng 3 lần thì tự chuyển sang DLQ — không mất đi.

Vì sao nó đáp ứng đúng hai yêu cầu: | Yêu cầu | Cách DLQ đáp ứng | |---|---| | Gỡ lỗi về sau | message được giữ nguyên vẹn kèm toàn bộ payload và thuộc tính | | Xử lý lại | redrive đưa message về hàng đợi chính |

Và tính năng redrive làm việc thứ hai chỉ bằng một thao tác:

aws sqs start-message-move-task \
  --source-arn arn:aws:sqs:...:don-hang-loi \
  --destination-arn arn:aws:sqs:...:don-hang

Sau khi đã sửa lỗi trong mã, bạn đẩy toàn bộ đơn hàng hỏng trở lại và chúng được xử lý lại bình thường.

DLQ còn có lợi ích quan trọng thứ ba: nó ngăn message hỏng chặn hàng đợi. Không có DLQ, một đơn hàng gây lỗi sẽ quay vòng vô hạn và tiêu tốn năng lực xử lý mãi mãi.

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

• A. Publish đơn hàng thất bại lên SNS topic — SNS không lưu trữ: nếu không ai đang nghe hoặc subscriber đang hỏng, message mất luôn. Không đáp ứng vế "xử lý lại về sau".
• C. Ghi đơn hàng thất bại vào CloudWatch Logs — giúp gỡ lỗi nhưng không xử lý lại được: log là văn bản chỉ đọc, không có cơ chế đưa message trở lại hàng đợi. Bạn sẽ phải tự viết công cụ đọc log, phân tích, rồi tạo lại message — rất thủ công và dễ sai.
• D. Gửi đơn hàng thất bại vào CloudTrail logs — sai bản chất: CloudTrail ghi lời gọi API quản trị, và bạn không gửi dữ liệu vào CloudTrail — nó tự ghi. Không dùng được cho mục đích này.

Ghi nhớ

Hai loại DLQ trong hệ sinh thái Lambda + SQS — hay bị lẫn: | | SQS redrive policy | Lambda destination | |---|---|---| | Đặt ở | hàng đợi SQS | cấu hình hàm Lambda | | Kích hoạt khi | message hỏng maxReceiveCount lần | lần gọi bất đồng bộ hỏng hết số lần thử | | Đích | hàng đợi khác | SQS, SNS, Lambda, EventBridge |

Với kiến trúc trong đề (SQS + Lambda event source mapping), DLQ trên hàng đợi là đúng — Lambda destination chỉ áp cho gọi bất đồng bộ.

Ba việc nên làm cùng với DLQ:

1. Đặt CloudWatch alarm trên ApproximateNumberOfMessagesVisible của DLQ — có message vào DLQ nghĩa là có vấn đề, và bạn cần biết ngay:

   aws cloudwatch put-metric-alarm --alarm-name canh-bao-dlq \
     --namespace AWS/SQS --metric-name ApproximateNumberOfMessagesVisible \
     --dimensions Name=QueueName,Value=don-hang-loi \
     --statistic Sum --period 300 --threshold 0 \
     --comparison-operator GreaterThanThreshold --evaluation-periods 1
   

2. Đặt MessageRetentionPeriod của DLQ dài hơn hàng đợi chính — thường là 14 ngày, để có thời gian điều tra.
3. Bật ReportBatchItemFailures với Lambda để chỉ những message thực sự hỏng bị trả lại, thay vì cả lô.

Và chọn maxReceiveCount hợp lý: quá thấp thì lỗi tạm thời (mạng chập chờn) cũng đẩy message vào DLQ; quá cao thì message hỏng chiếm chỗ quá lâu. Giá trị 3–5 là phổ biến.