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

Đáp án

C và D.

• C — Instance của một loại năng lực cụ thể không được phân bố đều giữa các Availability Zone.
• D — Sticky session đang được bật trên load balancer.

Vì sao đúng

Hai nguyên nhân này giải thích được hai hiện tượng khác nhau trong cùng một triệu chứng.

C — phân bố instance lệch giữa các AZ. Với cross-zone load balancing tắt (mặc định của NLB), traffic chia đều giữa các AZ trước:

AZ-A: 2 instance  →  nhận 50%  →  mỗi instance 25%
AZ-B: 8 instance  →  nhận 50%  →  mỗi instance 6,25%

Instance ở AZ mỏng nhận traffic gấp bốn lần. Ngay cả khi cross-zone bật, việc phân bố lệch vẫn gây vấn đề nếu các loại instance khác nhau về năng lực xử lý.

D — sticky session. Khi bật, load balancer ghim mỗi client vào cùng một target trong suốt phiên:

Client 1 → luôn về Instance A
Client 2 → luôn về Instance A     ← ngẫu nhiên dồn vào cùng chỗ
Client 3 → luôn về Instance B

Client có phiên dài hoặc hoạt động nhiều sẽ liên tục dồn tải vào đúng một instance, và load balancer không thể cân bằng lại — vì đó chính là điều sticky session yêu cầu nó làm.

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

• E. "Với ALB, cross-zone load balancing mặc định TẮT" — sai. ALB LUÔN bật cross-zone và không tắt được ở mức load balancer. Chỉ NLB mới mặc định tắt và bật được. Đây là điểm đảo ngược cần nhớ rõ.
• A. "Sau khi tắt một AZ, target trong AZ đó vẫn đăng ký và nhận traffic ngẫu nhiên" — sai. Tắt một AZ thì load balancer ngừng gửi traffic tới target trong AZ đó ngay lập tức. Không có "bursts of traffic ngẫu nhiên".
• B. "Kết nối TCP ngắn giữa client và instance" — thực ra kết nối ngắn giúp cân bằng tốt hơn, vì mỗi kết nối mới được định tuyến lại. Vấn đề nằm ở kết nối dài (WebSocket, HTTP keep-alive lâu): chúng ghim traffic vào một target suốt vòng đời kết nối.

Ghi nhớ

Cross-zone load balancing — bảng cần thuộc: | | ALB | NLB | GWLB | |---|---|---|---| | Mặc định | luôn BẬT | TẮT | TẮT | | Tắt/bật được | ở mức target group | ✅ | ✅ | | Phí truyền dữ liệu giữa AZ | miễn phí | có phí khi bật | có phí |

Danh sách kiểm khi traffic phân bố lệch:

1. Cross-zone đã bật chưa? (NLB)
2. Số instance có đều giữa các AZ không?
3. Sticky session có đang bật không?
4. Có kết nối dài (WebSocket, keep-alive) không?
5. Các instance có cùng loại và cùng năng lực không?

Đáp án

B và E.

• B — SRR và CRR cấu hình được ở mức bucket, mức prefix dùng chung, hoặc mức object bằng object tag.
• E — Hành động lifecycle của S3 KHÔNG được sao chép cùng với replication.

Vì sao đúng

B — ba mức phạm vi. Replication rule khai được rất linh hoạt:

{
  "Rules": [{
    "Status": "Enabled",
    "Priority": 1,
    "Filter": {
      "And": {
        "Prefix": "tai-lieu/",
        "Tags": [{"Key": "sao-chep", "Value": "co"}]
      }
    },
    "Destination": {"Bucket": "arn:aws:s3:::bucket-dich"}
  }]
}

Bỏ Filter thì áp cho cả bucket; khai Prefix thì áp cho một nhánh; khai Tags thì lọc tới từng object.

E — lifecycle không được sao chép. Đây là chi tiết quan trọng và hay bị bỏ sót: nếu bucket nguồn có lifecycle chuyển object sang Glacier sau 90 ngày, bucket đích KHÔNG tự có quy tắc đó. Phải cấu hình lifecycle riêng cho bucket đích.

Không biết điều này dẫn tới hai hậu quả thực tế: bucket đích phình ra vô hạn vì không có quy tắc hết hạn, và chi phí lưu trữ cao hơn dự kiến vì object không được chuyển xuống lớp rẻ hơn.

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

• A. "Object được sao chép không giữ metadata" — sai. Replication giữ nguyên metadata, tag, ACL, thời điểm tạo object, và version ID. Bản sao gần như giống hệt bản gốc.
• C. "Object tag không sao chép được qua CRR" — sai. Tag được sao chép cùng object. (Thậm chí tag còn dùng được làm bộ lọc trong chính replication rule.)
• D. "Bật replication thì mọi object cũ và mới đều được sao chép" — sai ở vế "cũ". Replication chỉ áp dụng cho object ghi SAU khi bật rule. Muốn chép dữ liệu đã có thì phải dùng S3 Batch Replication — một thao tác riêng.

Ghi nhớ

Điều kiện và đặc điểm của S3 Replication: | Yêu cầu | Chi tiết | |---|---| | Versioning | bắt buộc bật ở cả hai bucket | | Phạm vi | SRR (cùng Region) hoặc CRR (khác Region) | | Chéo tài khoản | ✅ — cần bucket policy ở đích | | Object đã có trước | ❌ — dùng Batch Replication | | Lifecycle | ❌ không sao chép — phải cấu hình riêng | | Xoá | chỉ sao chép delete marker nếu bật DeleteMarkerReplication |

Và với replication chéo tài khoản, nhớ bật ChangeObjectOwnership để tài khoản đích thực sự sở hữu bản sao — nếu không, object thuộc về tài khoản nguồn và bên đích không đọc được.

Đáp án

B — Cấu hình CORS trên bucket B (nơi chứa web font) để cho phép origin của bucket A gửi request.

Vì sao đúng

Đây là một biểu hiện kinh điển của Same-Origin Policy trong trình duyệt.

Trang web được phục vụ từ bucket A, nhưng font nằm ở bucket B — hai origin khác nhau. Trình duyệt chặn việc nạp font cross-origin trừ khi máy chủ cung cấp font cho phép tường minh.

Điểm mấu chốt: CORS được cấu hình ở phía máy chủ CUNG CẤP tài nguyên, tức là bucket B — không phải ở nơi đặt trang web.

[{
  "AllowedHeaders": ["*"],
  "AllowedMethods": ["GET", "HEAD"],
  "AllowedOrigins": ["https://bucket-a.s3-website-ap-southeast-1.amazonaws.com"],
  "ExposeHeaders": [],
  "MaxAgeSeconds": 3000
}]

Với cấu hình này, bucket B trả về header Access-Control-Allow-Origin cho request từ bucket A, và trình duyệt cho phép nạp font.

Web font đặc biệt nhạy với CORS: trình duyệt áp dụng chính sách chặt hơn với @font-face so với ảnh — ảnh cross-origin thường nạp được không cần CORS, còn font thì gần như luôn cần.

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

• C. Cấu hình CORS trên bucket A — đây là bẫy chính, và nó sai chiều. Bucket A phục vụ trang web, không phục vụ font. CORS ở đó không ảnh hưởng gì tới việc trình duyệt có được phép lấy font từ bucket B hay không.
• A. Cập nhật bucket policy trên cả hai bucket — bucket policy kiểm soát quyền truy cập ở phía AWS (ai được GetObject). CORS là cơ chế của trình duyệt, hoàn toàn khác tầng. Font có thể công khai đọc được mà trình duyệt vẫn chặn vì thiếu CORS.
• D. Bật versioning trên cả hai bucket — versioning giữ nhiều phiên bản của object. Không liên quan gì tới CORS.

Ghi nhớ

Phân biệt hai cơ chế thường bị lẫn: | | Bucket policy / IAM | CORS | |---|---|---| | Ai thực thi | AWS (phía máy chủ) | trình duyệt (phía client) | | Trả lời | bạn có quyền đọc object này không? | trang ở origin khác có được đọc kết quả không? | | Thiếu nó thì | 403 AccessDenied | request thành công nhưng JS/CSS không dùng được kết quả |

Nguyên tắc vàng: CORS luôn cấu hình ở phía CUNG CẤP tài nguyên, không phải phía tiêu thụ.

Mẹo chẩn đoán: mở DevTools của trình duyệt. Lỗi CORS hiện rõ trong tab Console ("has been blocked by CORS policy"), và trong tab Network bạn sẽ thấy request có mã 200 nhưng tài nguyên vẫn không được dùng — dấu hiệu phân biệt rõ nhất với lỗi phân quyền.

Đáp án

A — AWS Secrets Manager với customer-managed KMS key, lưu access token làm secret và cấu hình resource-based policy cho phép tài khoản khác truy cập.

Vì sao đúng

Đề nêu bốn yêu cầu, và yêu cầu thứ tư là điểm phân biệt quyết định:

Vế chéo tài khoản là điểm loại. Secrets Manager hỗ trợ resource policy gắn thẳng vào secret:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::999988887777:root"},
  "Action": ["secretsmanager:GetSecretValue"],
  "Resource": "*"
}

Kèm theo, customer-managed KMS key là bắt buộc cho tình huống này: khoá mặc định aws/secretsmanager không sửa được key policy, nên không có cách nào cấp quyền kms:Decrypt cho tài khoản kia.

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

• B. Parameter Store SecureString với resource-based policy — bẫy chính, và nó sai ở đúng một điểm: SSM Parameter Store KHÔNG hỗ trợ resource-based policy. Không có cách nào gắn policy vào một tham số để chia sẻ chéo tài khoản. Muốn chia sẻ thì phải để tài khoản kia assume một role trong tài khoản của bạn — phức tạp hơn hẳn.
• C. Lưu token đã mã hoá trong DynamoDB — DynamoDB không có resource-based policy theo kiểu bucket policy. Và đây là tự dựng lại một dịch vụ quản lý bí mật: phải tự mã hoá, tự phân quyền, tự xoay vòng.
• D. Lưu trên S3 với SSE-KMS — có resource-based policy (bucket policy) nên vế chéo tài khoản chạy được, nhưng S3 không phải kho bí mật: không có xoay vòng, không có versioning theo staging label, không có tích hợp SDK để lấy bí mật. Gánh nặng quản lý cao hơn.

Ghi nhớ

Quy tắc chọn: cần xoay vòng, chia sẻ chéo tài khoản, hoặc đa Region ⇒ Secrets Manager. Chỉ lưu an toàn trong một tài khoản và muốn miễn phí ⇒ Parameter Store.

Đáp án

B — Dùng SQS long polling để nhận message.

Vì sao đúng

Yêu cầu là giảm chi phí SQS, và long polling là cách trực tiếp nhất.

SQS tính tiền theo số request API, không theo số message. Với short polling (mặc định), lời gọi ReceiveMessage trả về ngay lập tức — kể cả khi hàng đợi rỗng. Consumer trong vòng lặp sẽ bắn ra hàng nghìn lời gọi rỗng mỗi phút, và mỗi lời gọi đều tính tiền.

Long polling giữ kết nối chờ tới khi có message hoặc hết thời gian chờ:

aws sqs set-queue-attributes --queue-url <url> \
  --attributes ReceiveMessageWaitTimeSeconds=20     # tối đa 20 giây

Con số cụ thể để thấy khác biệt:

Short polling: gọi liên tục      → ~3.600 request/giờ mỗi consumer
Long polling (20 giây):          →     180 request/giờ mỗi consumer
                                    → giảm khoảng 95% chi phí API

Hai lợi ích đi kèm: giảm tải cho consumer (không quay vòng vô ích), và giảm độ trễ — message vừa tới là được trả về ngay, không phải chờ vòng lặp tiếp theo.

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

• D. Short polling — chính là hành vi mặc định gây tốn kém, tức là ngược lại điều đề cần.
• A. SQS message timer — thiết lập độ trễ (DelaySeconds) cho một message cụ thể trước khi nó hiển thị. Không liên quan tới việc nhận message hay chi phí.
• C. Visibility timeout — khoảng thời gian message bị ẩn sau khi đã được nhận, để consumer xử lý xong rồi xoá. Nó chống xử lý trùng, không giảm số lời gọi API.

Ghi nhớ

Đặc điểm cuối cùng đáng nhớ: short polling chỉ lấy mẫu một phần các server của SQS, nên có thể trả về rỗng dù hàng đợi có message. Long polling quét toàn bộ nên không bị hiện tượng đó.

AWS khuyến nghị bật long polling cho gần như mọi hàng đợi — đặt ReceiveMessageWaitTimeSeconds=20 ở mức queue là xong.

Đáp án

D — Integration type MOCK.

Vì sao đúng

Yêu cầu: mô phỏng (simulate) các thành phần API do đội khác sở hữu, để đội mình phát triển độc lập mà không phải chờ.

MOCK integration làm đúng việc đó: API Gateway tự trả về phản hồi mà không gọi backend nào cả.

// Integration request — dùng để chọn phản hồi trả về
{"statusCode": 200}

// Integration response — nội dung giả lập
{
  "don_hang": "DH-123",
  "trang_thai": "dang_giao",
  "ngay_du_kien": "2026-09-05"
}

Ba giá trị thực tế:

• Đội frontend làm việc ngay với hợp đồng API đã thống nhất, không chờ backend xong
• Không tốn chi phí backend — không Lambda nào chạy, không CSDL nào bị gọi
• Kiểm thử được các mã trạng thái (200, 404, 500) một cách xác định, thứ rất khó tái hiện với backend thật

MOCK còn hữu ích cho vài việc khác: trả về phản hồi CORS preflight cho method OPTIONS, hoặc trả về một phản hồi tĩnh (trang bảo trì chẳng hạn) mà không cần backend.

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

• B. AWS_PROXY — Lambda proxy integration: chuyển toàn bộ request sang một hàm Lambda thật. Cần có hàm để gọi, tức là vẫn phải chờ backend.
• C. HTTP_PROXY — chuyển thẳng request tới một HTTP endpoint bên ngoài. Cũng cần backend thật.
• A. HTTP — gọi HTTP endpoint nhưng có thêm bước biến đổi bằng mapping template. Vẫn cần backend.

Ghi nhớ

Năm loại integration của API Gateway: | Loại | Gọi tới | Biến đổi dữ liệu | |---|---|---| | MOCK | không gọi đâu cả | phản hồi tĩnh do bạn khai | | AWS | dịch vụ AWS (Lambda, SQS, DynamoDB…) | có mapping template | | AWS_PROXY | Lambda | chuyển nguyên, không biến đổi | | HTTP | HTTP endpoint | có mapping template | | HTTP_PROXY | HTTP endpoint | chuyển nguyên |

Mẹo phân biệt: có chữ _PROXY nghĩa là chuyển nguyên request/response, không dùng được mapping template. Và MOCK là loại duy nhất không cần backend.

Đáp án

A — Cho phép toàn quyền S3, nhưng từ chối tường minh việc truy cập bucket Production nếu người dùng chưa đăng nhập bằng MFA trong vòng 30 phút gần nhất.

Vì sao đúng

Policy có bốn statement, ba cho phép và một từ chối:

Ba statement đầu cộng lại cho toàn quyền S3. Statement thứ tư là lớp bảo vệ có điều kiện:

"Condition": {
  "NumericGreaterThanIfExists": {"aws:MultiFactorAuthAge": "1800"}
}

aws:MultiFactorAuthAge là số giây kể từ lần xác thực MFA gần nhất. Điều kiện đọc là: từ chối nếu đã hơn 1.800 giây (30 phút) kể từ lần MFA cuối.

Hậu tố IfExists rất quan trọng: nó khiến điều kiện cũng khớp khi khoá hoàn toàn vắng mặt — tức là khi người dùng chưa hề dùng MFA. Không có IfExists, người không dùng MFA sẽ lọt qua statement Deny này.

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

• B. "Cho phép quản lý MỘT bucket và từ chối MỌI action AWS khác" — sai phạm vi. Resource là arn:aws:s3:::* và arn:aws:s3:::*/* — mọi bucket, không phải một. Và Deny chỉ nhắm s3:* trên Production, không phải mọi dịch vụ AWS.
• C. "Người dùng Cognito… nếu Cognito user chưa được xác thực" — policy hoàn toàn không nhắc tới Cognito. Điều kiện dùng aws:MultiFactorAuthAge, không phải khoá của Cognito.
• D. "Cho phép IAM user truy cập thư mục riêng của họ" — mẫu đó dùng policy variable như ${aws:username} trong Resource. Policy này không có biến nào; nó cấp quyền trên *.

Ghi nhớ

Ba khoá điều kiện về MFA: | Khoá | Nghĩa | |---|---| | aws:MultiFactorAuthPresent | phiên có dùng MFA hay không (boolean) | | aws:MultiFactorAuthAge | số giây kể từ lần MFA gần nhất | | aws:TokenIssueTime | thời điểm phát thông tin xác thực tạm thời |

Và nhớ hai quy tắc IAM cốt lõi mà câu này minh hoạ:

• Deny tường minh luôn thắng mọi Allow
• Dùng hậu tố IfExists khi muốn điều kiện áp cả trường hợp khoá vắng mặt — thiếu nó là để lọt đúng nhóm nguy hiểm nhất

Đáp án

C — Container instance bị huỷ trong lúc đang ở trạng thái STOPPED, gây ra lỗi đồng bộ.

Vì sao đúng

ECS theo dõi container instance thông qua ECS agent chạy trên máy. Agent định kỳ báo cáo trạng thái về dịch vụ ECS, và khi instance bị huỷ trong lúc đang chạy, agent gửi tín hiệu cuối cùng để ECS gỡ nó khỏi cluster.

Vấn đề xảy ra khi instance ở trạng thái STOPPED: agent không chạy, nên không có ai báo cho ECS biết. Huỷ instance ở trạng thái đó thì ECS không nhận được thông báo nào, và bản ghi container instance nằm lại trong cluster ở trạng thái mồ côi.

Cách dọn thủ công:

aws ecs deregister-container-instance \
  --cluster cum-cua-toi \
  --container-instance <container-instance-id> \
  --force

Quy trình đúng để tránh hoàn toàn:

# 1. Rút instance ra khỏi việc nhận task mới
aws ecs update-container-instances-state --cluster cum --container-instances <id> --status DRAINING
# 2. Chờ task hiện có chuyển đi hết
# 3. Huỷ đăng ký
aws ecs deregister-container-instance --cluster cum --container-instance <id>
# 4. Mới huỷ EC2 instance

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

• B. "Huỷ instance khi đang ở trạng thái RUNNING" — đây chính là trường hợp hoạt động đúng: agent còn sống nên ECS được thông báo và tự dọn bản ghi.
• A. "Phải dùng ECS CLI thay vì AWS CLI" — sai. Cả hai đều gọi cùng một API. ECS CLI chỉ là công cụ tiện lợi hơn cho một số tác vụ, không có hành vi đồng bộ đặc biệt nào.
• D. "Phần mềm tuỳ chỉnh trên instance hỏng khiến container treo ở trạng thái không lành" — mô tả một vấn đề khác hẳn: khi ấy instance vẫn tồn tại và bị đánh dấu unhealthy. Đề nói rõ instance đã bị huỷ nhưng vẫn hiện trong cluster.

Ghi nhớ

Các trạng thái của ECS container instance: | Trạng thái | Nghĩa | |---|---| | ACTIVE | nhận task mới bình thường | | DRAINING | không nhận task mới, task hiện có được chuyển đi dần | | INACTIVE | đã huỷ đăng ký |

Nguyên tắc vận hành: luôn DRAINING trước khi huỷ instance. Nó vừa tránh bản ghi mồ côi, vừa đảm bảo task đang chạy được chuyển đi an toàn thay vì bị cắt đột ngột.

(Với capacity provider có managed termination protection, ECS tự lo bước này — instance có task đang chạy sẽ không bị Auto Scaling huỷ.)

Đáp án theo nguồn

C — Giới hạn truy cập bằng CORS.

Vì sao nguồn chọn phương án này

Đề mô tả: API công khai được truy cập từ một tên miền khác, lưu lượng tăng gấp đôi, và muốn ngăn các tên miền không được phép gọi API.

CORS (Cross-Origin Resource Sharing) là cơ chế cho phép máy chủ khai báo những origin nào được phép đọc phản hồi:

{
  "AllowOrigins": ["https://ung-dung-cua-toi.com"],
  "AllowMethods": ["GET", "POST"],
  "AllowHeaders": ["Content-Type", "Authorization"]
}

Với cấu hình này, trình duyệt sẽ chặn JavaScript ở các tên miền khác đọc kết quả từ API — nên trang web của bên thứ ba nhúng API của bạn sẽ không dùng được nữa.

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

• B. Gắn security group cho API Gateway — không làm được. API Gateway (REST/HTTP API công khai) không nằm trong VPC của bạn và không nhận security group. Security group chỉ áp cho ENI: EC2, RDS, ALB, Lambda-trong-VPC…
• A. Mapping template — biến đổi định dạng request và response bằng VTL. Không kiểm soát truy cập.
• D. Account-level throttling — giới hạn tổng số request mỗi giây cho toàn tài khoản. Nó giới hạn tất cả mọi người như nhau, kể cả người dùng hợp lệ — không phân biệt được tên miền nào.

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

CORS không phải cơ chế bảo mật, và nó không thực sự "ngăn truy cập".

CORS được trình duyệt thực thi, không phải máy chủ. Nghĩa là:

• Request vẫn tới API Gateway và vẫn được xử lý
• API Gateway vẫn tính tiền cho request đó
• Bất kỳ ai dùng curl, Postman, hay một máy chủ proxy đều bỏ qua CORS hoàn toàn

Nên nếu mục tiêu thật là giảm chi phí do lưu lượng trái phép, CORS không đạt được. Cách đúng là:

Trong bốn phương án, CORS là thứ gần nhất với ý "hạn chế theo tên miền" — nên nó là đáp án của đề. Nhưng hãy nhớ giới hạn thật của nó.

Đáp án

A — Dùng Lambda alias (với weighted routing).

Vì sao đúng

Yêu cầu: đưa 10% traffic sang phiên bản Lambda mới, phần còn lại giữ ở bản cũ.

Weighted alias của Lambda làm đúng việc đó, và làm ở tầng Lambda nên bên gọi không cần biết gì:

# Publish phiên bản mới
aws lambda publish-version --function-name khoa-hoc

# Alias 'prod' vẫn trỏ chính vào version 1, thêm 10% sang version 2
aws lambda update-alias --function-name khoa-hoc --name prod \
  --function-version 1 \
  --routing-config AdditionalVersionWeights={"2"=0.1}

Ba đặc điểm khớp đúng với nhu cầu:

• ARN alias không đổi — API Gateway vẫn trỏ vào ...:function:khoa-hoc:prod, không phải cấu hình lại
• Chia traffic theo tỷ lệ — 10% sang bản mới
• Rollback tức thì — đặt trọng số về 0, có hiệu lực gần như ngay lập tức

Khi hài lòng thì trỏ hẳn alias sang version 2.

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

• B. Dùng tag để phân biệt phiên bản — tag chỉ là nhãn siêu dữ liệu dùng cho phân bổ chi phí và tổ chức tài nguyên. Chúng không ảnh hưởng gì tới việc định tuyến.
• C. Deploy Lambda trong VPC — cấu hình mạng, cho phép hàm truy cập tài nguyên riêng trong VPC. Hoàn toàn không liên quan tới việc chia traffic giữa các phiên bản.
• D. Dùng biến môi trường — cấu hình theo từng phiên bản của hàm. Bạn có thể dùng chúng để bật/tắt tính năng bên trong mã, nhưng đó là feature flag, không phải chia traffic — và nó không cho bạn tỷ lệ 10/90.

Ghi nhớ

Vài ràng buộc của weighted alias: chỉ chia được giữa hai version, và không trỏ vào $LATEST được.

Muốn tự động hoá cả việc rollback thì dùng SAM DeploymentPreference với CodeDeploy — nó tự tăng dần trọng số và tự rollback khi CloudWatch alarm kêu, thay vì phải theo dõi bằng tay.