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

Đáp án

A — Phân bố task đều trên các Availability Zone, rồi phân bố đều trên các instance trong từng AZ.

Vì sao đúng

Placement strategy của ECS được đánh giá theo thứ tự trong mảng, và mỗi phần tử là một tầng lọc:

"placementStrategy": [
  { "field": "attribute:ecs.availability-zone", "type": "spread" },   ← tầng 1
  { "field": "instanceId", "type": "spread" }                          ← tầng 2
]

Tầng 1 — spread theo AZ: ECS đặt task sao cho số lượng cân bằng nhất có thể giữa các AZ. Ba AZ, sáu task ⇒ mỗi AZ hai task.

Tầng 2 — spread theo instanceId: trong AZ đã chọn, ECS lại phân bố đều giữa các instance. Đây là điều làm nên khác biệt với "ngẫu nhiên".

Kết quả là mẫu đặt task chịu lỗi tốt nhất: một AZ sập thì chỉ mất phần tương ứng, một instance chết thì cũng chỉ mất phần nhỏ.

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

• B. "…rồi phân bố ngẫu nhiên trong từng AZ" — nhầm spread với random. Đây là hai type khác nhau: spread cân bằng có chủ đích, random chọn tuỳ ý. Tầng 2 trong đề ghi rõ "type": "spread".
• C. "…rồi bin pack theo bộ nhớ trong từng AZ" — binpack là chiến lược ngược lại: nó dồn task lên càng ít instance càng tốt để tiết kiệm chi phí. Nó không có trong JSON của đề.
• D. "…phân bố đều trên các instance riêng biệt (distinct)" — khác biệt tinh tế: distinctInstance là một placement CONSTRAINT, không phải strategy. Nó bắt buộc mỗi instance chỉ được có một task, trong khi spread theo instanceId chỉ cân bằng số lượng và vẫn cho phép nhiều task trên cùng một máy.

Ghi nhớ

Và phân biệt hai khái niệm: strategy = ưu tiên đặt ở đâu; constraint = bắt buộc/cấm đặt ở đâu.

Đáp án

A — Tạo global secondary index (GSI) với partition key là game_name và sort key là TopScore.

Vì sao đúng

Bảng gốc (nhìn thấy trong ảnh cấu hình) có:

• Partition key: user_id (String)
• Sort key: game_name (String)

Với khoá đó, bạn chỉ truy vấn hiệu quả theo một người dùng cụ thể ("người này chơi những game nào"). Nhưng bảng xếp hạng hỏi ngược lại: "game này ai điểm cao nhất" — tức là truy vấn theo game_name và sắp xếp theo TopScore.

GSI cho phép định nghĩa một cặp khoá hoàn toàn khác:

Với GSI này, một lệnh Query duy nhất trả về bảng xếp hạng đã sắp xếp sẵn:

table.query(
    IndexName='leaderboard-index',
    KeyConditionExpression=Key('game_name').eq('space-race'),
    ScanIndexForward=False,   # giảm dần — điểm cao lên trước
    Limit=10)

Đây chính là mẫu "đảo khoá" kinh điển của DynamoDB.

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

• C. Local secondary index (LSI) — đây là điểm loại quan trọng nhất, và nó là một ràng buộc cứng: LSI bắt buộc dùng CÙNG partition key với bảng gốc, chỉ được đổi sort key. Bảng gốc có partition key là user_id, nên không thể tạo LSI với partition key game_name. Ngoài ra LSI chỉ tạo được lúc tạo bảng, không thêm sau được.
• B. Dùng Scan — Scan đọc toàn bộ bảng rồi lọc ở phía client. Với bảng của một công ty game thì đó là hàng triệu item mỗi lần xem bảng xếp hạng: cực chậm, cực tốn read capacity. Và Scan không sắp xếp kết quả.
• D. GSI với partition key user_id và sort key game_name — trùng y hệt khoá của bảng gốc, nên không mở ra kiểu truy vấn nào mới. Vẫn không trả lời được câu hỏi "game này ai cao điểm nhất".

Ghi nhớ

Câu thần chú: cần đổi partition key ⇒ bắt buộc là GSI.

Đáp án

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

Vì sao đúng

Template trong đề dùng transform AWS::Serverless-2016-10-31 — tức là template SAM. Với AWS::Serverless::Function, thuộc tính CodeUri (hoặc mặc định là thư mục hiện tại) trỏ tới mã nguồn cục bộ.

Nhưng CloudFormation không đọc được đường dẫn cục bộ trên máy bạn. Nó chỉ nhận URI của S3. Đó là lý do phải có bước package:

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

Lệnh này làm ba việc: nén mã nguồn, tải lên S3, và sinh ra template mới trong đó CodeUri đã được thay bằng URI S3 thật:

CodeUri: s3://kho-artifact-cua-toi/a1b2c3d4e5f6...

Sau đó mới deploy được:

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

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

• B. aws cloudformation compile — lệnh này không tồn tại. AWS CLI cho CloudFormation có package, deploy, create-stack, update-stack, validate-template… nhưng không có compile. Và nhúng mã base64 vào template cũng không phải cách SAM hoạt động — template có giới hạn kích thước 51.200 byte khi truyền trực tiếp.
• C. aws lambda zip — cũng không tồn tại. Lệnh aws lambda có create-function, update-function-code, invoke… nhưng không có zip. Việc nén là do package hoặc sam build tự làm.
• D. aws serverless create-package — không có namespace aws serverless trong AWS CLI. Công cụ chuyên cho SAM là sam CLI (sam build, sam package, sam deploy), một chương trình riêng biệt.

Ghi nhớ

Hai bộ lệnh tương đương cho SAM: | AWS CLI | SAM CLI | |---|---| | aws cloudformation package | sam package | | aws cloudformation deploy | sam deploy |

sam deploy --guided gộp cả hai và tự hỏi các tham số cần thiết — cách gọn nhất trong thực tế. Nguyên tắc cần nhớ: CodeUri trỏ vào máy cục bộ thì luôn phải qua bước package trước khi deploy.

Đáp án

B — Người dùng thực hiện được mọi hành động SQS, nhưng chỉ trên các queue có tên bắt đầu bằng staging-queue.

Vì sao đúng

Đọc từng phần của policy:

{
  "Effect": "Allow",
  "Action": "sqs:*",                                          ← MỌI hành động SQS
  "Resource": "arn:aws:sqs:*:513246782345:staging-queue*"     ← queue khớp mẫu
}

Nên staging-queue, staging-queue-1, staging-queue-orders đều khớp; còn prod-queue hay my-staging-queue thì không (* ở cuối chỉ mở rộng về phía sau).

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

• A. "Chỉ tạo được queue tên staging-queue" — quá hẹp về hành động (policy cho sqs:*, không riêng CreateQueue) và quá hẹp về tài nguyên (mẫu có * nên khớp nhiều tên, không chỉ một). Phương án này mô tả một tập con rất nhỏ của quyền thực tế.
• C. "Được cấp quyền truy cập chéo tài khoản từ tài khoản 513246782345" — hiểu ngược. Đây là identity policy gắn vào một IAM user; số tài khoản trong ARN chỉ nói queue nằm ở tài khoản nào. Truy cập chéo tài khoản còn cần resource policy của queue ở phía bên kia cho phép — mà policy này không phải thứ đó.
• D. "Áp được resource-based policy lên queue" — quá hẹp. Đúng là sqs:* bao gồm sqs:SetQueueAttributes (dùng để đặt queue policy), nhưng đó chỉ là một trong hàng chục hành động được cấp. Mô tả này bỏ sót phần lớn nội dung policy.

Ghi nhớ

Cấu trúc ARN của SQS: arn:aws:sqs:<region>:<account-id>:<ten-queue>.

Vài lưu ý về ký tự đại diện trong IAM:

• * khớp không hoặc nhiều ký tự bất kỳ
• ? khớp đúng một ký tự
• Deny luôn thắng mọi Allow, bất kể thứ tự
• Với truy cập chéo tài khoản, phải có cả hai vế: identity policy bên gọi và resource policy bên nhận

Đá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 dùng transform AWS::Serverless-2016-10-31 với CodeUri: . — trỏ vào thư mục cục bộ. CloudFormation không đọc được đường dẫn cục bộ, nên quy trình luôn có hai bước:

1. Package — nén mã, tải lên S3, sinh template mới với CodeUri là URI S3
2. Deploy — tạo hoặc cập nhật stack từ template đã đóng gói

Và có hai bộ lệnh tương đương để làm việc đó:

# Cách 1 — AWS CLI (phương án C)
aws cloudformation package --template-file template.yaml \
    --s3-bucket kho-artifact --output-template-file packaged.yaml
aws cloudformation deploy --template-file packaged.yaml --stack-name ung-dung

# Cách 2 — SAM CLI (phương án E)
sam package --template-file template.yaml --s3-bucket kho-artifact \
    --output-template-file packaged.yaml
sam deploy --template-file packaged.yaml --stack-name ung-dung

sam package và sam deploy thực chất là lớp bọc mỏng quanh chính hai lệnh CloudFormation kia — nên cả hai đều đúng, và đó là lý do câu hỏi có hai đáp án.

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

• A. aws serverless package / aws serverless deploy — namespace aws serverless không tồn tại trong AWS CLI. Công cụ chuyên cho SAM là chương trình riêng tên sam.
• B. aws cloudformation compile — lệnh này không có. AWS CLI cho CloudFormation không có compile.
• D. sam build rồi sam package — cả hai lệnh đều có thật, nhưng dãy này thiếu bước deploy. sam build biên dịch phụ thuộc, sam package tải lên S3 — xong rồi vẫn chưa có gì được triển khai. Đây là bẫy tinh vi nhất: đúng lệnh, thiếu bước cuối.

Ghi nhớ

Quy trình SAM đầy đủ:

sam build     →  biên dịch mã và phụ thuộc (tuỳ chọn với runtime thông dịch)
sam package   →  nén + tải lên S3 + sinh template mới     (= aws cloudformation package)
sam deploy    →  tạo/cập nhật stack                        (= aws cloudformation deploy)

Trong thực tế thường chỉ cần sam deploy --guided — nó gộp package và deploy, đồng thời lưu cấu hình vào samconfig.toml cho các lần sau.

Đáp án

D — Hàm Lambda đã được gọi bất đồng bộ và đã hoàn tất thành công việc tiếp nhận.

Vì sao đúng

Hai manh mối trong lệnh và kết quả:

Manh mối 1 — --invocation-type Event. Đây là cờ quyết định kiểu gọi:

Manh mối 2 — StatusCode: 202. Mã HTTP 202 là Accepted — "đã nhận yêu cầu, sẽ xử lý". Đây chính là mã trả về của lời gọi bất đồng bộ thành công.

Cần hiểu chính xác "thành công" ở đây nghĩa là gì: 202 chỉ xác nhận Lambda đã nhận và xếp sự kiện vào hàng đợi, không nói gì về việc mã trong hàm chạy đúng hay sai. Kết quả thật phải xem trong CloudWatch Logs, hoặc cấu hình destination / DLQ để bắt lỗi.

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

• A. "Bất đồng bộ và chưa hoàn tất thành công" — đúng kiểu gọi nhưng sai kết luận: 202 là mã thành công. Nếu lời gọi bị từ chối thì sẽ là 4xx (403 thiếu quyền, 429 bị throttle) hoặc 5xx.
• B và C. "Đồng bộ…" — sai kiểu gọi. Cờ --invocation-type Event nói rõ đây là bất đồng bộ; lời gọi đồng bộ trả về 200, không phải 202.

Ghi nhớ

Và nhớ hai đặc điểm chỉ có ở lời gọi bất đồng bộ: Lambda tự thử lại 2 lần khi hàm lỗi, và có thể cấu hình DLQ hoặc on-failure destination để giữ lại sự kiện hỏng.

Đáp án

C — Tạo lại bảng với khoá phức hợp (composite key) gồm userid và timestamp.

Vì sao đúng

Cấu hình bảng (nhìn thấy trong ảnh) cho biết:

• Primary partition key: userid (String)
• Primary sort key: - (không có)

Đây là khoá đơn giản (simple primary key), và với loại khoá này DynamoDB có một quy tắc cứng: partition key phải là duy nhất trên toàn bảng. Ghi item thứ hai với userid = "user0001" sẽ ghi đè item cũ, hoặc — nếu dùng ConditionExpression: attribute_not_exists(userid) — trả về đúng lỗi trong đề: "The conditional request failed".

Muốn nhiều item cùng một userid thì bắt buộc phải có khoá phức hợp:

Và điểm đau đớn: không đổi được lược đồ khoá của bảng đã tồn tại. Partition key và sort key là bất biến. Phải tạo bảng mới rồi di trú dữ liệu sang.

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

• B. "Cập nhật bảng để thêm primary sort key" — bẫy chính. Nghe rất hợp lý, nhưng DynamoDB không cho sửa lược đồ khoá sau khi tạo bảng. UpdateTable đổi được throughput, thêm/bớt GSI, bật stream — nhưng không đổi được khoá chính.
• D. Thêm LSI cho timestamp — hai lỗi. Thứ nhất, LSI chỉ tạo được lúc tạo bảng. Thứ hai, và quan trọng hơn: index không thay đổi ràng buộc duy nhất của bảng gốc — userid vẫn phải duy nhất, nên item thứ hai vẫn bị từ chối.
• A. "Dùng SDK thay vì Console" — công cụ không liên quan gì. Ràng buộc duy nhất của khoá chính được thực thi ở tầng dịch vụ; SDK, CLI hay Console đều nhận cùng một lỗi.

Ghi nhớ

Bài học lớn hơn: thiết kế khoá trong DynamoDB là quyết định gần như không thể đảo ngược. Nếu có bất kỳ khả năng nào cần nhiều item cho cùng một thực thể, hãy khai sort key ngay từ đầu.

Đáp án

C — Thêm đúng hai quyền codecommit:CreateBranch và codecommit:DeleteBranch.

Vì sao đúng

Đề nói rõ tiêu chí: nguyên tắc đặc quyền tối thiểu. Nghĩa là cấp chính xác những gì cần, không hơn.

Policy hiện tại có:

"Action": ["codecommit:BatchGetRepositories", "codecommit:Get*",
           "codecommit:List*", "codecommit:GitPull"]

Toàn bộ là quyền đọc. Việc cần thêm là tạo và xoá nhánh, và AWS có sẵn đúng hai hành động mang tên đó — nên đáp án tối thiểu chính là hai hành động đó, không gì khác.

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

• B. codecommit:* — cấp toàn quyền trên CodeCommit, bao gồm cả DeleteRepository, PutRepositoryTriggers, UpdateDefaultBranch, quản lý pull request… Vi phạm đặc quyền tối thiểu ở mức nặng nhất trong bốn phương án.
• A. codecommit:Put* — khớp PutFile, PutRepositoryTriggers, PutCommentReaction và nhiều hành động khác, nhưng không khớp CreateBranch hay DeleteBranch (chúng bắt đầu bằng Create và Delete). Vừa cấp thừa quyền, vừa không giải quyết được việc cần làm.
• D. codecommit:Update* — khớp UpdateRepositoryDescription, UpdateDefaultBranch, UpdatePullRequestTitle… nhưng cũng không khớp CreateBranch và DeleteBranch. Cùng lỗi với A.

Ghi nhớ

Vài lưu ý thực dụng khi làm việc với quyền CodeCommit:

• Truy cập qua SSH hay HTTPS đều dùng cùng bộ quyền IAM; khoá SSH chỉ thay cho mật khẩu ở khâu xác thực.
• codecommit:GitPull và codecommit:GitPush là hai quyền riêng, kiểm soát thao tác Git thật; các quyền Get*/List* là cho API.
• Muốn chặt hơn nữa, dùng điều kiện codecommit:References để giới hạn theo tên nhánh:

  {"Effect": "Deny", "Action": "codecommit:GitPush", "Resource": "*",
   "Condition": {"StringEqualsIfExists": {"codecommit:References": ["refs/heads/main"]}}}
  

Nguyên tắc chung khi đề hỏi "least privilege": luôn chọn phương án liệt kê đúng tên hành động cần dùng, không bao giờ chọn phương án có ký tự đại diện.

Đáp án

A — Task sẽ được đặt trên các container instance thuộc task group "databases".

Vì sao đúng

Phân tích biểu thức:

"placementConstraints": [
  { "expression": "task:group == databases", "type": "memberOf" }
]

Đọc trọn vẹn: chỉ đặt task này lên container instance đang chạy task thuộc group "databases".

Đây là cách gom các task liên quan lại gần nhau — hữu ích khi chúng cần chia sẻ dữ liệu cục bộ hoặc cần độ trễ mạng giữa các task ở mức thấp nhất.

Task group là gì: một nhãn tuỳ ý bạn gán cho task khi chạy nó (--group databases). Mặc định, task chạy như một phần của service thuộc group service:<ten-service>.

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

• B. "Chúng sẽ trở thành thành viên của task group databases" — nhầm chiều hoàn toàn. Constraint là điều kiện lọc nơi đặt, không phải lệnh gán nhãn. Muốn task thuộc một group thì khai --group lúc run-task, không khai trong placementConstraints.
• C. "Chúng sẽ KHÔNG được đặt trên instance thuộc group databases" — đảo ngược ý nghĩa của memberOf. Muốn diễn đạt phủ định thì viết task:group != databases.
• D. "Không được chạy trừ khi có tag databases" — nhầm task:group với tag của tài nguyên. Tag của instance được tham chiếu bằng cú pháp attribute:<ten>; task:group là một thuộc tính riêng của ECS, chỉ về task group.

Ghi nhớ

Hai loại placement constraint của ECS: | Type | Nghĩa | |---|---| | memberOf | chỉ đặt ở nơi thoả biểu thức | | distinctInstance | mỗi instance tối đa một task của task này |

Các toán tử trong biểu thức: ==, !=, >, <, in, not_in, =~ (khớp biểu thức chính quy), và các toán tử logic and, or.

Và nhớ phân biệt: constraint = bắt buộc/cấm; strategy = ưu tiên. Constraint không thoả được thì task không chạy; strategy chỉ ảnh hưởng thứ tự ưu tiên.

Đáp án

C — Hàm Lambda được gọi đồng bộ và đã hoàn tất thành công.

Vì sao đúng

Hai manh mối:

Manh mối 1 — không có --invocation-type. Khi bỏ trống, AWS CLI dùng giá trị mặc định là RequestResponse, tức là gọi đồng bộ: CLI chờ hàm chạy xong và nhận kết quả trả về.

Manh mối 2 — StatusCode: 200. Với lời gọi đồng bộ, 200 = OK: hàm đã chạy và trả về phản hồi. Nội dung phản hồi nằm trong tệp response.json.

Một điểm tinh tế cần biết: 200 nghĩa là lời gọi thành công, không hẳn nghĩa là mã trong hàm chạy không lỗi. Nếu hàm ném ngoại lệ, bạn vẫn nhận 200 nhưng kèm trường FunctionError: "Unhandled" trong phản hồi, và chi tiết lỗi nằm trong tệp output. Đề chỉ hiển thị StatusCode, và với thông tin đó thì lời gọi là thành công.

So sánh trực tiếp với câu trước trong bộ đề này (#4991):

# Bất đồng bộ → 202
aws lambda invoke --function-name MyFunction --invocation-type Event --payload ... response.json
# Đồng bộ (mặc định) → 200
aws lambda invoke --function-name MyFunction --payload ... response.json

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

• A và B. "Bất đồng bộ…" — bất đồng bộ đòi cờ --invocation-type Event, mà lệnh trong đề không có. Và bất đồng bộ trả về 202, không phải 200.
• D. "Đồng bộ và chưa hoàn tất thành công" — đúng kiểu gọi nhưng sai kết luận: 200 là mã thành công. Lời gọi thất bại ở tầng dịch vụ sẽ trả 4xx hoặc 5xx.

Ghi nhớ

Và nhớ: FunctionError mới là trường cho biết mã trong hàm có lỗi hay không — StatusCode chỉ nói về lời gọi.