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

Đáp án

B — Transform.

Vì sao đúng

Template SAM có đúng hai section bắt buộc:

Template SAM tối thiểu chỉ cần hai dòng đầu:

Transform: AWS::Serverless-2016-10-31       # ← BẮT BUỘC
Resources:                                   # ← BẮT BUỘC
  HamXuLy:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: python3.12
      CodeUri: ./src

Bỏ dòng Transform thì CloudFormation không biết cách xử lý AWS::Serverless::Function và báo lỗi "Unrecognized resource type". Đó chính là thứ biến một template CloudFormation thường thành template SAM.

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

• A. Globals — hữu ích nhưng tuỳ chọn. Nó đặt giá trị mặc định cho mọi hàm, API hay bảng, tránh lặp lại:

  Globals:
    Function:
      Runtime: python3.12
      Timeout: 30
      MemorySize: 512
  

  Đây là section riêng của SAM, không có trong CloudFormation thường.
• C. Parameters — tuỳ chọn, dùng khi cần truyền giá trị khác nhau theo môi trường.
• D. Mappings — tuỳ chọn, dùng cho bảng tra cứu tĩnh (ví dụ AMI theo Region).

Ghi nhớ

So sánh CloudFormation và SAM về section bắt buộc: | | CloudFormation | SAM | |---|---|---| | Bắt buộc | Resources | Transform + Resources | | Section riêng | — | Globals |

Và nhớ: SAM là phần mở rộng của CloudFormation. Mọi section của CloudFormation đều dùng được trong SAM, và bạn hoàn toàn trộn được tài nguyên AWS::Serverless::* với tài nguyên CloudFormation thường trong cùng một template — điều rất hay dùng khi cần Cognito, SNS hay S3 bên cạnh Lambda.

Đáp án

A — Dùng Cognito user pool + user pool authorizer trên API Gateway; Lambda lưu ảnh trong S3 và lưu S3 key vào DynamoDB.

Vì sao đúng

Ba quyết định thiết kế, và mỗi phương án sai đúng một trong ba:

Quyết định 1 — quản lý người dùng: user pool. Đề nói người dùng phải "create an account". Đăng ký tài khoản là chức năng của user pool — nó lưu hồ sơ, xác minh email, quản lý mật khẩu, MFA. Identity pool không lưu người dùng nào cả.

Quyết định 2 — authorizer: user pool authorizer. API Gateway có sẵn loại authorizer này; nó xác minh JWT do user pool phát ra, không cần viết mã.

Quyết định 3 — lưu ảnh ở S3, chỉ lưu key trong DynamoDB. Đây là quyết định quan trọng nhất, vì ảnh nặng 500 KB – 5 MB:

Giới hạn 400 KB của DynamoDB là ranh giới cứng — ảnh 500 KB đã vượt, ảnh 5 MB thì vượt hơn mười lần. Đây là điểm loại tuyệt đối của phương án C.

Mẫu chuẩn: S3 giữ nội dung, DynamoDB giữ con trỏ và metadata.

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

• C. Lưu cả ảnh lẫn metadata trong DynamoDB — không làm được: vượt giới hạn 400 KB mỗi item. Kể cả nếu ảnh nhỏ hơn thì vẫn cực kỳ đắt so với S3.
• B. Dùng identity pool và "identity pool authorizer" — hai lỗi. Identity pool không quản lý tài khoản (không có sign up). Và không tồn tại "identity pool authorizer" trong API Gateway — chỉ có Cognito user pool authorizer, Lambda authorizer, IAM và JWT authorizer.
• D. "Identity pool tạo một IAM user cho mỗi người dùng" — hiểu sai hoàn toàn cách identity pool hoạt động. Nó không tạo IAM user; nó phát thông tin xác thực tạm thời qua STS. Và tạo IAM user cho từng người dùng cuối là chống chỉ định: giới hạn cứng 5.000 IAM user mỗi tài khoản, trong khi ứng dụng có hàng chục nghìn người dùng.

Ghi nhớ

Mẫu kiến trúc chuẩn cho ứng dụng lưu tệp:

Client → API Gateway (Cognito user pool authorizer)
       → Lambda
            ├→ S3        (tệp thật)
            └→ DynamoDB  (S3 key + metadata: chủ sở hữu, thời gian, kích thước)

Tối ưu thêm cho tệp lớn: dùng S3 pre-signed URL để client tải thẳng lên S3, không đi qua Lambda. Cách này tránh được giới hạn payload 6 MB của Lambda, giảm thời gian chạy hàm, và rẻ hơn nhiều.

Và nhớ dứt khoát: giới hạn 400 KB mỗi item của DynamoDB — con số này bị hỏi rất thường xuyên.

Đáp án

D — Triển khai bằng chính sách Immutable.

Vì sao đúng

Đề nêu hai yêu cầu, và chúng cùng nhau chỉ về đúng một chính sách:

1. Giữ ÍT NHẤT năng lực đầy đủ của ứng dụng trong lúc deploy
2. Tác động tối thiểu khi deploy thất bại

Immutable dựng một fleet hoàn toàn mới song song với fleet cũ:

Fleet cũ (100% năng lực) ──── vẫn phục vụ toàn bộ traffic ────┐
                                                              │ trong lúc
Fleet mới ──── dựng đầy đủ, kiểm tra sức khoẻ ────────────────┘ deploy
                          ↓ tất cả đều lành
                  chuyển traffic sang, huỷ fleet cũ

Vế năng lực: fleet cũ không bị đụng tới cho tới khi fleet mới sẵn sàng hoàn toàn — nên năng lực luôn ở mức 100%, thậm chí 200% trong khoảnh khắc chuyển giao.

Vế thất bại: nếu instance mới không qua được health check, Beanstalk huỷ toàn bộ fleet mới và fleet cũ tiếp tục phục vụ như chưa có gì xảy ra. Không có trạng thái hỗn hợp, không có instance nào chạy bản hỏng.

Đây chính là điều mà lần deploy trước đã thiếu: đề nói ứng dụng bị giảm hiệu năng vì deploy ở năng lực giảm đúng lúc có đợt bán hàng.

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

• B. Rolling with additional batch — đây là phương án gần nhất và cũng giữ được 100% năng lực. Nhưng khi thất bại, nó để lại trạng thái hỗn hợp: một số lô đã lên bản mới, số còn lại vẫn bản cũ, và phải deploy thêm một lần nữa để dọn. Thua ở vế "MINIMAL impact of failed deployment".
• C. Rolling — giảm năng lực trong lúc mỗi lô đang được cập nhật. Đây chính xác là nguyên nhân sự cố lần trước, nên chọn lại nó là lặp lại lỗi cũ.
• A. All at once — có thời gian chết, và deploy hỏng thì cả môi trường hỏng. Tệ nhất trong bốn phương án theo cả hai tiêu chí.

Ghi nhớ

Bảng so sánh đầy đủ các chính sách deploy của Elastic Beanstalk: | Chính sách | Thời gian chết | Năng lực trong lúc deploy | Chi phí thêm | Khi thất bại | |---|---|---|---|---| | All at once | có | 0% | không | cả môi trường hỏng | | Rolling | không | giảm | không | trạng thái hỗn hợp | | Rolling + additional batch | không | 100% | +1 lô | trạng thái hỗn hợp | | Immutable | không | 100% | gấp đôi tạm thời | huỷ fleet mới, fleet cũ nguyên vẹn | | Blue/Green | không | 100% | gấp đôi | môi trường cũ nguyên vẹn, rollback tức thì |

Đánh đổi của Immutable: chậm hơn (phải dựng cả fleet mới) và tốn gấp đôi tạm thời. Đổi lại là mức an toàn cao nhất trong các chính sách nội bộ của một môi trường.

Lưu ý đã nói ở câu #5069: Immutable làm mất toàn bộ EC2 burst balance vì instance cũ bị huỷ.

Đáp án

B — Dùng envelope encryption và tham chiếu dữ liệu dưới dạng tệp trong mã.

Vì sao đúng

Hai giới hạn cứng quyết định câu trả lời:

Dữ liệu trong đề là hơn 1 MB — vượt cả hai. Nên phải giải quyết cùng lúc hai vấn đề:

Vấn đề 1 — mã hoá dữ liệu lớn ⇒ envelope encryption:

1. GenerateDataKey → KMS trả về cặp: data key bản rõ + data key bản mã
2. Mã hoá 1 MB dữ liệu bằng data key bản rõ (AES-256, ngay trong hàm)
3. Xoá data key bản rõ khỏi bộ nhớ
4. Lưu: dữ liệu đã mã hoá + data key bản mã
5. Khi cần đọc: kms:Decrypt data key rồi giải mã dữ liệu tại chỗ

Nhờ vậy 1 MB không bao giờ phải đi qua mạng tới KMS — chỉ có khoá 256-bit đi qua.

Vấn đề 2 — cất dữ liệu ở đâu ⇒ tệp trong gói triển khai. Biến môi trường chỉ chứa được 4 KB tổng cộng, nên tệp là lựa chọn duy nhất. Gói triển khai Lambda cho phép tới 50 MB (zip) hoặc 250 MB (giải nén), thoải mái cho 1 MB.

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

• A. Envelope encryption nhưng lưu biến môi trường — đúng cách mã hoá, sai chỗ lưu: vượt trần 4 KB của biến môi trường.
• C. KMS mã hoá trực tiếp, lưu thành tệp — đúng chỗ lưu, sai cách mã hoá: kms:Encrypt từ chối dữ liệu trên 4 KB.
• D. KMS mã hoá trực tiếp + biến môi trường — sai cả hai vế.

Ghi nhớ

Và các giới hạn của Lambda liên quan: | Giới hạn | Giá trị | |---|---| | Biến môi trường (tổng) | 4 KB | | Gói triển khai (zip) | 50 MB | | Gói giải nén | 250 MB | | /tmp | 512 MB – 10.240 MB | | Container image | 10 GB |

Nhận dạng nhanh: thấy dữ liệu lớn + KMS ⇒ envelope encryption với GenerateDataKey.

Đáp án

A và E.

• A — Khi tạo signer, khoá công khai nằm ở CloudFront còn khoá riêng dùng để ký một phần của URL.
• E — Khi dùng root user để quản lý CloudFront key pair, mỗi tài khoản chỉ có tối đa hai key pair đang hoạt động.

Vì sao đúng

A — mô hình mã hoá bất đối xứng. Signed URL hoạt động theo đúng nguyên lý chữ ký số:

Bạn giữ  : khoá RIÊNG  →  dùng để KÝ policy (đường dẫn, thời hạn, dải IP)
CloudFront giữ: khoá CÔNG KHAI  →  dùng để XÁC MINH chữ ký

Khoá riêng không bao giờ rời khỏi bạn; CloudFront chỉ cần khoá công khai để kiểm tra URL có bị sửa hay không.

E — giới hạn hai key pair. Đây là ràng buộc cứng của cơ chế CloudFront key pair (cũ), và nó có lý do thực dụng: hai khoá cho phép xoay vòng khoá không gián đoạn — tạo khoá mới, chuyển dần sang dùng nó, rồi mới xoá khoá cũ.

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

• B. "Cả hai loại signer đều quản lý được bằng CloudFront API" — sai. Trusted key group quản lý được bằng API (CreatePublicKey, CreateKeyGroup), nhưng CloudFront key pair thì KHÔNG — chúng chỉ tạo được qua trang Security Credentials của root user.
• C. "CloudFront key pair tạo được bằng bất kỳ tài khoản nào có quyền quản trị" — sai. Chỉ root user tạo được, kể cả IAM user có quyền AdministratorAccess cũng không.
• D. "Dùng IAM policy để giới hạn root user với CloudFront key pair" — sai về nguyên lý: IAM policy không giới hạn được root user của tài khoản. Root luôn có toàn quyền; muốn chặn root thì phải dùng SCP ở tầng Organizations.

Ghi nhớ

Hai cơ chế signer của CloudFront — nên dùng cái nào: | | CloudFront key pair (cũ) | Trusted key group (khuyến nghị) | |---|---|---| | Ai tạo | chỉ root user | IAM user có quyền | | Số lượng | tối đa 2 đang hoạt động | tối đa 5 key group mỗi distribution, mỗi group 5 khoá | | Quản lý bằng API | ❌ | ✅ | | Khuyến nghị | không dùng cho thiết kế mới | ✅ |

AWS khuyến nghị luôn dùng trusted key group — nó bỏ được yêu cầu đăng nhập root, tự động hoá được, và cho nhiều khoá hơn.

Đáp án

B — Application Load Balancer + Amazon ECS.

Vì sao đúng

Đề nêu ba yêu cầu kỹ thuật rất cụ thể, và chúng cùng chỉ về ALB:

Dynamic port mapping là điểm mấu chốt. Không có nó, mỗi container phải gắn với một cổng host cố định — nên chỉ chạy được một task mỗi service trên mỗi instance (hai task cùng đòi cổng 80 thì task thứ hai không khởi động được).

Với ALB, task definition khai hostPort: 0:

"portMappings": [{"containerPort": 8080, "hostPort": 0}]

ECS tự gán một cổng ngẫu nhiên trên host (dải ephemeral) và tự đăng ký cặp instance + cổng đó vào target group. Nhờ vậy chạy được nhiều task của cùng service trên cùng một máy, đúng yêu cầu "All services should run on the same EC2 instance".

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

• A và D. Classic Load Balancer — CLB không hỗ trợ dynamic port mapping và không có target group. Nó chỉ ánh xạ cổng cố định, nên mỗi instance chỉ chạy được một task mỗi service. CLB cũng là công nghệ thế hệ cũ mà AWS không còn khuyến nghị.
• C và D. Elastic Beanstalk — Beanstalk có hỗ trợ Docker (kể cả multi-container qua ECS), nhưng nó là lớp trừu tượng che đi phần cấu hình ECS chi tiết. Bạn không kiểm soát trực tiếp task definition, placement strategy hay dynamic port mapping ở mức cần thiết. Đề mô tả yêu cầu ở tầng ECS, nên ECS trực tiếp là lựa chọn đúng.

Ghi nhớ

Nhận dạng nhanh: thấy "dynamic port mapping" hoặc "nhiều task cùng service trên một instance" ⇒ ALB + ECS.

(Ghi chú: với Fargate thì vấn đề này không tồn tại — mỗi task có ENI riêng và IP riêng, nên không có xung đột cổng.)

Đáp án

B — Một SNS topic duy nhất, mỗi đối tác đăng ký vào đó; Lambda publish message kèm thuộc tính (attribute), và mỗi subscription có filter policy phù hợp.

Vì sao đúng

Yêu cầu: thông báo cho đúng đối tác về đơn hàng của họ, không ảnh hưởng đối tác khác, và thêm đối tác mới với công sức tối thiểu.

Message filtering của SNS giải quyết trọn vẹn: một topic, nhiều subscription, mỗi subscription chỉ nhận message khớp bộ lọc của mình.

# Lambda publish kèm thuộc tính
sns.publish(
    TopicArn=TOPIC,
    Message=json.dumps({'don_hang': 'DH-123', 'trang_thai': 'da_giao'}),
    MessageAttributes={'doi_tac': {'DataType': 'String', 'StringValue': 'CONG-TY-A'}})

// Filter policy trên subscription của đối tác A
{"doi_tac": ["CONG-TY-A"]}

Ba lợi ích khớp đúng với đề:

• Cách ly: SNS lọc ở phía dịch vụ, nên đối tác B không bao giờ nhận message của đối tác A
• Mở rộng dễ: thêm đối tác mới chỉ là thêm một subscription với filter policy — không sửa mã Lambda, không tạo topic mới
• Hiệu quả: message không khớp bộ lọc không được gửi đi và không tính phí

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

• C và D. Mỗi đối tác một SNS topic riêng — làm được nhưng kém mở rộng: mỗi đối tác mới là một topic mới, và Lambda phải biết topic nào ứng với đối tác nào — tức là phải sửa mã hoặc duy trì một bảng ánh xạ. Nhiều tài nguyên hơn để quản lý mà không được gì thêm.
• A. Mỗi đối tác một Lambda function riêng — tệ nhất. Đề nói rõ đơn hàng được xử lý bởi một Lambda dùng chung; tách thành N hàm nghĩa là nhân bản cùng một logic nghiệp vụ N lần, và mỗi lần sửa quy tắc xử lý là phải deploy lại tất cả.

Ghi nhớ

Cú pháp filter policy của SNS hỗ trợ khá nhiều toán tử:

{
  "doi_tac": ["CONG-TY-A", "CONG-TY-B"],           // khớp một trong các giá trị
  "gia_tri": [{"numeric": [">", 1000]}],            // so sánh số
  "loai":    [{"prefix": "don-"}],                  // tiền tố
  "vung":    [{"anything-but": "test"}]             // loại trừ
}

Và nhớ hai chế độ lọc: mặc định lọc theo MessageAttributes; đặt FilterPolicyScope: MessageBody thì lọc thẳng theo nội dung JSON của message — hữu ích khi không muốn nhân đôi dữ liệu vào attribute.

Đáp án

C và D.

• D — Dùng DynamoDB transactional API để đọc và ghi như một thao tác tất-cả-hoặc-không-gì.
• C — Thực hiện cả hai thao tác trên RDS MySQL trong một transaction block.

Vì sao đúng

Yêu cầu là tính chất nguyên tử (atomicity): bản ghi của cả hai người dùng phải cùng được ghi thành công, hoặc không có gì thay đổi.

D — DynamoDB Transactions. TransactWriteItems đảm bảo ACID trên tối đa 100 thao tác:

dynamodb.transact_write_items(TransactItems=[
    {'Update': {  # trừ voucher của người gửi
        'TableName': 'nguoi_dung', 'Key': {'id': {'S': 'A'}},
        'UpdateExpression': 'SET voucher = voucher - :n',
        'ConditionExpression': 'voucher >= :n',
        'ExpressionAttributeValues': {':n': {'N': '1'}}}},
    {'Update': {  # cộng voucher cho người nhận
        'TableName': 'nguoi_dung', 'Key': {'id': {'S': 'B'}},
        'UpdateExpression': 'SET voucher = voucher + :n',
        'ExpressionAttributeValues': {':n': {'N': '1'}}}}])

Người gửi không đủ voucher ⇒ toàn bộ giao dịch bị huỷ, không ai bị trừ hay cộng gì.

C — RDS MySQL với transaction block. Đây là tính nguyên tử kinh điển của CSDL quan hệ:

START TRANSACTION;
UPDATE nguoi_dung SET voucher = voucher - 1 WHERE id = 'A' AND voucher >= 1;
UPDATE nguoi_dung SET voucher = voucher + 1 WHERE id = 'B';
COMMIT;   -- lỗi ở bất kỳ đâu → ROLLBACK, không gì thay đổi

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

• E. Đọc ghi DynamoDB với ConsistentRead = true — hiểu nhầm hai khái niệm khác hẳn nhau. Nhất quán mạnh đảm bảo bạn đọc được giá trị mới nhất; nó không đảm bảo tính nguyên tử khi ghi nhiều item. Hai lệnh ghi riêng lẻ vẫn có thể một thành một bại.
• B. Amazon Redshift — kho dữ liệu phân tích (OLAP), tối ưu cho quét lớn và báo cáo. Nó không phải CSDL giao dịch: không hợp với cập nhật từng dòng tần suất cao, và độ trễ cao hơn nhiều so với nhu cầu của một ứng dụng game.
• A. "Amazon Athena transactional read and write API" — không tồn tại. Athena là công cụ truy vấn dữ liệu trên S3; nó chủ yếu chỉ đọc và không có giao dịch theo nghĩa ACID cho ứng dụng.

Ghi nhớ

Hai điều dễ nhầm và đều xuất hiện ở câu này: BatchWriteItem không phải giao dịch, và ConsistentRead không liên quan gì tới tính nguyên tử.

Đáp án

D — Giữ API key trong AWS Secrets Manager và lấy nó lúc chạy bằng AWS SDK.

Vì sao đúng

Đề đòi cách an toàn nhất, và có thêm ràng buộc không ảnh hưởng hiệu năng.

Secrets Manager là dịch vụ chuyên trách cho bí mật, và nó thắng ở mọi tiêu chí:

Về vế hiệu năng: lấy bí mật ở mỗi request thì đúng là thêm độ trễ, nhưng cách chuẩn là cache trong bộ nhớ với TTL ngắn:

_cache = {}
def lay_api_key():
    if 'key' not in _cache or time.time() - _cache['t'] > 300:
        _cache['key'] = json.loads(
            sm.get_secret_value(SecretId='doi-tac/api-key')['SecretString'])['key']
        _cache['t'] = time.time()
    return _cache['key']

Với Lambda, biến toàn cục sống qua nhiều lần gọi trong cùng môi trường, nên thực tế chỉ gọi Secrets Manager vài lần mỗi giờ. AWS còn cung cấp sẵn Parameters and Secrets Lambda Extension làm đúng việc này.

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

• A. Biến cục bộ trong mã — kém an toàn nhất: bí mật nằm trong mã nguồn, nên vào Git, vào mọi bản sao repo, vào lịch sử commit mãi mãi. Đổi khoá là phải deploy lại.
• B. Tệp mã hoá trên S3 — khá hơn A nhưng đẻ ra câu hỏi khó nhất: khoá giải mã cất ở đâu? Nếu dùng SSE-KMS thì bạn đang tự dựng lại một phần Secrets Manager, mà thiếu xoay vòng và thiếu resource policy.
• C. Bảng mã hoá trong RDS MySQL — nặng nề và sai công cụ: phải nuôi một CSDL, tự quản lý khoá mã hoá, tự viết cơ chế truy cập. Và thêm một phụ thuộc vào đường đi nóng của ứng dụng.

Ghi nhớ

Quy tắc chọn: cần xoay vòng hoặc chia sẻ chéo tài khoản ⇒ Secrets Manager; chỉ cần lưu an toàn và tiết kiệm ⇒ Parameter Store. Và trong mọi trường hợp: đừng bao giờ để bí mật trong mã nguồn.

Đáp án

C — Không giới hạn số lượng message lưu trong một SQS queue.

Vì sao đúng

Đây là một trong những đặc điểm quan trọng nhất của SQS: hàng đợi không có giới hạn về số message. Bạn có thể để một message hay một tỷ message trong đó — SQS tự lo phần lưu trữ và mở rộng.

Chính vì vậy SQS là công cụ đệm tải (buffering) lý tưởng: producer đẩy nhanh bao nhiêu cũng được, consumer xử lý theo tốc độ của mình, và hàng đợi phình ra rồi xẹp lại mà không cần ai can thiệp.

Nhưng SQS có những giới hạn khác, và đó mới là thứ cần thuộc:

Giới hạn in-flight là thứ hay gây nhầm nhất: đó là số message đã được nhận nhưng chưa bị xoá, không phải số message trong queue. Chạm trần này thì ReceiveMessage trả về lỗi OverLimit.

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

• A. 10.000, D. 100.000, B. 10.000.000 — không con số nào trong ba con số này là giới hạn của SQS. Chúng chỉ là các số tròn nghe hợp lý.

Ghi nhớ

Điều thực sự cần lưu tâm không phải "queue chứa được bao nhiêu" mà là MessageRetentionPeriod: message nằm quá thời hạn đó sẽ bị xoá vĩnh viễn, kể cả khi chưa ai xử lý.

Nên với hệ thống production, hãy luôn:

• Đặt alarm trên ApproximateAgeOfOldestMessage — message cũ nghĩa là consumer không theo kịp
• Đặt alarm trên ApproximateNumberOfMessagesVisible — hàng đợi phình ra bất thường
• Cấu hình DLQ để message hỏng không quay vòng mãi rồi biến mất