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

Đáp án

D — test.sample.com.

Vì sao đúng

Quy tắc khớp của host-based routing trong ALB có một đặc điểm quan trọng: * chỉ khớp MỘT nhãn (label) trong tên miền, và không khớp chuỗi rỗng.

Nên mẫu *.sample.com khớp:

test.sample.com   ✅  (* = "test")
api.sample.com    ✅  (* = "api")
www.sample.com    ✅  (* = "www")

Và không khớp:

sample.com            ❌  (không có nhãn nào ở vị trí *)
a.b.sample.com        ❌  (* không khớp nhiều nhãn)
sample.test.com       ❌  (tên miền gốc khác hẳn)

Về chữ hoa chữ thường: DNS vốn không phân biệt hoa thường, nhưng đề đưa SAMPLE.COM như một phương án — và nó sai vì lý do khác: thiếu nhãn con để * khớp vào, giống hệt trường hợp sample.com.

Cấu hình:

{"Conditions": [{"Field": "host-header", "HostHeaderConfig": {"Values": ["*.sample.com"]}}],
 "Actions": [{"Type": "forward", "TargetGroupArn": "..."}]}

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

• B. sample.com — không khớp: mẫu đòi có một nhãn ở vị trí *, mà sample.com không có nhãn con nào. Muốn khớp cả tên miền gốc thì phải khai thêm một giá trị riêng:

  "Values": ["sample.com", "*.sample.com"]
  

  Đây là chi tiết rất hay bị quên trong cấu hình thật.
• A. SAMPLE.COM — cùng lý do với B: thiếu nhãn con.
• C. sample.test.com — tên miền hoàn toàn khác. Mẫu *.sample.com đòi phần sau * phải là .sample.com; ở đây phần đó là .test.com.

Ghi nhớ

Quy tắc khớp của ALB: | Loại | Ký tự đại diện | |---|---| | host-header | * khớp một nhãn, ? khớp một ký tự | | path-pattern | * khớp nhiều ký tự bất kỳ, kể cả / |

Khác biệt này đáng nhớ: /img/* khớp cả /img/a/b/c.png, nhưng *.sample.com KHÔNG khớp a.b.sample.com.

Vài giới hạn: mỗi rule tối đa 5 giá trị cho host header, độ dài mỗi giá trị tối đa 128 ký tự, và một ALB tối đa 100 rule.

Và nhớ: muốn phục vụ cả tên miền gốc lẫn mọi tên miền con, phải khai hai giá trị — sample.com và *.sample.com.

Đáp án

B — Dùng pre-signed URL.

Vì sao đúng

Sau khi bucket thành riêng tư, ứng dụng cần cấp quyền truy cập tạm thời cho từng người dùng vào từng object — mà không mở bucket ra công khai.

Pre-signed URL làm đúng việc đó: một URL mang chữ ký và thời hạn, cho phép tải đúng một object:

var request = new GetPreSignedUrlRequest {
    BucketName = "du-lieu-rieng",
    Key = "bao-cao.pdf",
    Expires = DateTime.UtcNow.AddMinutes(15),
    Verb = HttpVerb.GET
};
string url = s3Client.GetPreSignedURL(request);

Cách nó hoạt động: URL mang chữ ký tạo từ thông tin xác thực của ứng dụng, cộng với thời điểm hết hạn nằm ngay trong chữ ký. S3 xác minh chữ ký, kiểm hạn, rồi mới cho tải.

Điểm hay: ứng dụng quyết định ai được cấp URL theo logic nghiệp vụ của mình — S3 không cần biết gì về người dùng cuối.

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

• A. Dùng IAM policy — IAM cấp quyền cho danh tính AWS. Người dùng web không có danh tính AWS, và tạo IAM user cho từng người là bất khả thi (giới hạn 5.000 IAM user mỗi tài khoản).
• D. Dùng bucket policy — bucket policy là chính sách tĩnh ở mức bucket. Muốn cấp quyền cho một người trong một khoảng thời gian là phải sửa policy rồi nhớ gỡ ra — không mở rộng được, và bucket policy còn có giới hạn kích thước 20 KB.
• C. "Routing Policy" — khái niệm của Route 53 (DNS). Nó không kiểm soát quyền truy cập object trong S3.

Ghi nhớ

Các cơ chế kiểm soát truy cập S3, theo phạm vi: | Cơ chế | Phạm vi | Thời hạn | |---|---|---| | Pre-signed URL | một object, một người | có, tối đa 7 ngày | | Bucket policy | cả bucket hoặc prefix | tĩnh | | IAM policy | theo danh tính AWS | tĩnh | | CloudFront signed URL/cookie | qua CDN | có, kèm giới hạn IP |

Khác biệt giữa hai loại signed URL: | | S3 pre-signed | CloudFront signed | |---|---|---| | Tạo bằng | thông tin xác thực IAM | cặp khoá riêng | | Thời hạn tối đa | 7 ngày | không giới hạn | | Giới hạn IP | ❌ | ✅ |

Mẹo hiệu năng cho tệp lớn: dùng pre-signed URL cho PutObject để client tải thẳng lên S3, không đi qua ứng dụng — tránh giới hạn payload và giảm tải cho máy chủ.

Đáp án

C — SSE-S3.

Vì sao đúng

Đề nêu ba yêu cầu, và chúng cùng nhau chỉ về đúng một lựa chọn:

SSE-S3 dùng AES-256 và AWS lo trọn vòng đời khoá: tạo, xoay vòng, bảo vệ. Bạn không thấy khoá, không phải làm gì cả.

aws s3api put-object --bucket kho-bao-mat --key tai-lieu.pdf \
  --body tai-lieu.pdf --server-side-encryption AES256

Ba đặc điểm khác khiến nó phù hợp: không tốn thêm chi phí, không cần quyền KMS nào, và không có giới hạn tần suất API (khác với SSE-KMS vốn chịu request quota của KMS).

(Ghi chú thời sự: từ đầu 2023, S3 mã hoá mặc định bằng SSE-S3 cho mọi object mới — nên về mặt kỹ thuật, object đã được mã hoá kể cả khi không gửi header nào.)

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

• D. SSE-KMS — cũng là server-side và cũng dùng AES-256 bên dưới, nhưng bạn phải quản lý CMK: tạo khoá, đặt key policy, cấp quyền kms:GenerateDataKey và kms:Decrypt. Đề nói rõ "does not want to manage S3 encryption keys". SSE-KMS cũng có phí và chịu giới hạn tần suất API của KMS.
• A. SSE-C — ngược hẳn yêu cầu: bạn phải tự sinh, tự lưu, và gửi khoá kèm MỖI request. Mất khoá là mất dữ liệu vĩnh viễn. Đây là mức quản lý khoá cao nhất có thể.
• B. Client-Side Encryption — không phải server-side, và bạn phải tự quản lý toàn bộ: mã hoá trước khi gửi, lưu khoá, xoay vòng khoá.

Ghi nhớ

Cách chọn nhanh:

• "Không muốn quản lý khoá" ⇒ SSE-S3
• "Cần kiểm soát khoá và có vết kiểm toán" ⇒ SSE-KMS
• "Bắt buộc dùng khoá của riêng tôi" ⇒ SSE-C

Đáp án

A — Bật Health Checks.

Vì sao đúng

Triệu chứng: load balancer tiếp tục gửi traffic tới instance đã crash.

Đó là điều xảy ra khi load balancer không biết instance nào còn khoẻ — tức là health check chưa được cấu hình đúng.

Health check là cơ chế load balancer liên tục kiểm tra từng target:

ALB → GET /health tới mỗi target, mỗi 30 giây
   ├─ Trả về 200          → healthy   → tiếp tục gửi traffic
   └─ Trả lỗi hoặc timeout → unhealthy → NGỪNG gửi traffic

Các tham số quan trọng: | Tham số | Ý nghĩa | Mặc định | |---|---|---| | HealthCheckPath | đường dẫn kiểm tra | / | | HealthCheckIntervalSeconds | tần suất | 30 giây | | HealthyThresholdCount | số lần đúng để đánh dấu lành | 5 | | UnhealthyThresholdCount | số lần sai để đánh dấu hỏng | 2 | | Matcher | mã trạng thái chấp nhận | 200 |

Với cấu hình mặc định, instance hỏng bị loại khỏi vòng phân phối trong khoảng 60 giây (2 lần × 30 giây).

Và nên đi thêm một bước: đặt HealthCheckType: ELB cho Auto Scaling group, để ASG tự thay instance đó bằng máy mới — chứ không chỉ ngừng gửi traffic.

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

• C. Bật Stickiness — ghim một client vào một target trong suốt phiên. Nó làm tình hình TỆ HƠN: client đã bị ghim vào instance hỏng sẽ tiếp tục bị gửi tới đó.
• B. Bật SSL — mã hoá dữ liệu khi truyền. Hoàn toàn không liên quan tới việc phát hiện instance hỏng.
• D. Bật Multi-AZ deployments — trải instance trên nhiều AZ để chống hỏng cả một AZ. Hữu ích, nhưng không giải quyết vấn đề này: nếu không có health check, load balancer vẫn gửi traffic tới instance hỏng ở bất kỳ AZ nào.

Ghi nhớ

Hai tầng health check, và cả hai đều cần: | Tầng | Tác dụng | |---|---| | Target group health check | ELB ngừng gửi traffic tới target hỏng | | ASG health check type ELB | ASG thay thế instance hỏng bằng máy mới |

Chỉ có tầng một thì instance hỏng nằm đó mãi (vẫn tính tiền, vẫn chiếm chỗ trong desired capacity). Chỉ có tầng hai thì không thể xảy ra — tầng hai dựa vào tầng một.

Và cân nhắc về độ sâu của health check: | Loại | Kiểm gì | Rủi ro | |---|---|---| | Nông (/ping trả 200) | tiến trình còn sống | không phát hiện phụ thuộc hỏng | | Sâu (kiểm cả CSDL) | cả chuỗi phụ thuộc | một sự cố downstream có thể hạ cả fleet |

Đáp án

C và D.

• C — Mã hoá lúc lưu bằng KMS (server-side encryption).
• D — Mã hoá khi truyền qua endpoint HTTPS.

Vì sao đúng

Ràng buộc quan trọng nhất của đề: không được đổi mã ứng dụng. Nên chỉ những cơ chế trong suốt với ứng dụng mới đáp ứng được.

C — server-side encryption với KMS. Bật bằng một thiết lập, Kinesis tự mã hoá khi ghi và tự giải mã khi đọc:

aws kinesis start-stream-encryption \
  --stream-name du-lieu-nhay-cam \
  --encryption-type KMS \
  --key-id alias/aws/kinesis

Producer vẫn gọi PutRecord, consumer vẫn gọi GetRecords — không một dòng mã nào thay đổi. Thứ duy nhất phải thêm là quyền KMS (GenerateDataKey, Decrypt) cho producer và consumer.

D — HTTPS endpoint. Mọi endpoint của Kinesis đã là HTTPS mặc định, nên dữ liệu được mã hoá khi truyền mà không cần làm gì.

Hai biện pháp này phủ trọn hai chiều: at rest và in transit.

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

• B. Client-side encryption — an toàn nhất về lý thuyết (Kinesis không bao giờ thấy bản rõ), nhưng nó đòi sửa mã ở cả producer lẫn consumer, cộng với việc tự quản lý khoá. Vi phạm thẳng ràng buộc "won't require code changes".
• A. Envelope Encryption — đây là kỹ thuật bên dưới mà KMS dùng, không phải một tính năng bạn bật của Kinesis. Nếu tự cài đặt thì lại là client-side encryption — vẫn phải sửa mã.
• E. SSE-C encryption — Kinesis không hỗ trợ SSE-C. Đó là cơ chế của S3 (khoá do khách hàng cung cấp kèm mỗi request). Kinesis chỉ có SSE với KMS.

Ghi nhớ

Bảo mật cho Kinesis Data Streams: | Lớp | Cơ chế | |---|---| | At rest | SSE với KMS — bật một thiết lập | | In transit | HTTPS — mặc định | | Truy cập | IAM policy cho stream | | Mạng riêng | VPC interface endpoint (PrivateLink) |

Vài lưu ý về SSE của Kinesis:

• Dùng được AWS managed key (aws/kinesis, miễn phí quản lý) hoặc CMK riêng (kiểm soát và kiểm toán tốt hơn)
• Bật hoặc tắt mã hoá không ảnh hưởng dữ liệu đã có — chỉ áp cho bản ghi mới
• Có phí KMS API cho mỗi lần mã hoá/giải mã; với thông lượng rất cao, cân nhắc chi phí này

Nguyên tắc chung: "mã hoá mà không sửa mã" ⇒ server-side encryption — ở Kinesis cũng như ở S3, SQS, EBS, RDS.

Đáp án

C — 10 message.

Vì sao đúng

ReceiveMessage của SQS có tham số MaxNumberOfMessages với phạm vi 1 đến 10:

aws sqs receive-message --queue-url <url> \
  --max-number-of-messages 10 \
  --wait-time-seconds 20

Mặc định là 1 — nên rất nhiều ứng dụng vô tình nhận từng message một, tốn gấp 10 lần số lời gọi API.

Vì SQS tính tiền theo số request API, đặt MaxNumberOfMessages=10 là cách giảm chi phí đơn giản nhất:

Nhận 1.000 message, mỗi lần 1  → 1.000 request
Nhận 1.000 message, mỗi lần 10 →   100 request  ← giảm 90%

Kết hợp với long polling (WaitTimeSeconds=20) thì hiệu quả càng rõ: chờ cho đủ 10 message rồi trả về một lượt, thay vì trả về ngay với một message.

Một lưu ý: SQS không đảm bảo trả về đủ 10 — nó trả về số message có sẵn tại thời điểm đó, có thể ít hơn.

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

• A. 20 — đây là giá trị tối đa của WaitTimeSeconds (long polling), không phải số message. Dễ nhớ nhầm vì hai tham số hay đi cùng nhau.
• B. 5 và D. 100 — không tương ứng với giới hạn nào của SQS.

Ghi nhớ

Các giới hạn theo lô của SQS: | Thao tác | Giới hạn | |---|---| | ReceiveMessage | 10 message | | SendMessageBatch | 10 message, tổng 256 KB | | DeleteMessageBatch | 10 message | | ChangeMessageVisibilityBatch | 10 message |

Và bốn tham số thời gian, để không lẫn con số: | Tham số | Phạm vi | |---|---| | MaxNumberOfMessages | 1 – 10 | | WaitTimeSeconds (long polling) | 0 – 20 giây | | VisibilityTimeout | 0 – 12 giờ | | DelaySeconds | 0 – 15 phút | | MessageRetentionPeriod | 60 giây – 14 ngày |

Cấu hình tối ưu cho consumer thông thường: MaxNumberOfMessages=10 kết hợp WaitTimeSeconds=20 — giảm cả số lời gọi lẫn độ trễ.

Đáp án

A — Dùng action ChangeMessageVisibility để kéo dài visibility timeout của message.

Vì sao đúng

Vấn đề: xử lý mất khoảng 20 giây, nhưng đôi khi lâu hơn — và khi vượt quá VisibilityTimeout, message quay lại hàng đợi và bị consumer khác nhận, gây xử lý trùng.

ChangeMessageVisibility cho phép consumer gia hạn thời gian giữ message ngay trong lúc đang xử lý:

msg = sqs.receive_message(QueueUrl=url, MaxNumberOfMessages=1)['Messages'][0]
receipt = msg['ReceiptHandle']

while dang_xu_ly():
    time.sleep(15)
    sqs.change_message_visibility(       # gia hạn thêm 60 giây
        QueueUrl=url, ReceiptHandle=receipt, VisibilityTimeout=60)

sqs.delete_message(QueueUrl=url, ReceiptHandle=receipt)

Đây gọi là heartbeat pattern: consumer định kỳ báo "tôi vẫn đang làm" để giữ message cho riêng mình.

Ưu điểm so với việc chỉ đặt VisibilityTimeout lớn ngay từ đầu: nếu consumer chết giữa chừng, message quay lại hàng đợi nhanh (sau khoảng gia hạn cuối) thay vì phải chờ hết một timeout dài.

Giới hạn: tổng thời gian một message bị ẩn không vượt quá 12 giờ.

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

• C. "Dùng DelaySeconds để trì hoãn visibility timeout" — nhầm hai khái niệm khác hẳn. DelaySeconds hoãn message MỚI trước khi nó xuất hiện lần đầu; nó không liên quan tới message đã được nhận.
• B và D. Dùng WaitTimeSeconds để short/long poll "và kéo dài visibility timeout" — WaitTimeSeconds chỉ điều khiển long polling (thời gian chờ khi hàng đợi rỗng). Nó không kéo dài visibility timeout chút nào. Cả hai phương án gán cho nó một chức năng không có. (D còn mô tả đúng long polling nhưng vẫn sai ở vế thứ hai.)

Ghi nhớ

Bốn tham số thời gian của SQS, phân biệt cho rõ: | Tham số | Áp cho | Tác dụng | |---|---|---| | VisibilityTimeout | message ĐÃ nhận | ẩn trong lúc xử lý | | ChangeMessageVisibility | message ĐÃ nhận | gia hạn thời gian ẩn | | DelaySeconds | message MỚI | hoãn lần xuất hiện đầu | | WaitTimeSeconds | lời gọi nhận | long polling |

Hai cách xử lý công việc kéo dài: | Cách | Đặc điểm | |---|---| | Đặt VisibilityTimeout lớn ngay từ đầu | đơn giản, nhưng consumer chết thì message kẹt lâu | | Heartbeat với ChangeMessageVisibility | phức tạp hơn, nhưng phục hồi nhanh khi consumer chết |

Và quy tắc vàng cho cặp SQS + Lambda: VisibilityTimeout phải lớn hơn timeout của hàm — khuyến nghị gấp 6 lần.

Đáp án

B — Dùng dịch vụ X-Ray.

Vì sao đúng

Bối cảnh: kiến trúc microservices phía sau API Gateway, và người dùng nhận lỗi. Câu hỏi là thành phần nào đang hỏng.

Với microservices, một request đi qua nhiều dịch vụ nối tiếp nhau — và đó chính là bài toán mà X-Ray sinh ra để giải:

Client → API Gateway → Service A → Service B → DynamoDB
                                 ↘ Service C → dịch vụ bên ngoài

X-Ray gắn một trace ID vào mỗi request và theo nó qua mọi chặng, rồi dựng ra:

Với log rời rạc của từng service, bạn phải tự ghép chúng lại bằng tay. X-Ray làm sẵn việc đó.

Bật cho API Gateway chỉ là một thiết lập stage:

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

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

• C. CloudWatch — cho metric (5XXError, Latency, 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 lỗi phát sinh ở service nào trong chuỗi. Hữu ích để phát hiện, không đủ để chẩn đoán.
• D. CloudTrail — ghi lời gọi API quản trị (ai tạo, ai sửa API Gateway). Nó không ghi traffic đi qua API. Đây là nhầm lẫn kinh điển giữa mặt phẳng điều khiển và mặt phẳng dữ liệu.
• A. "Dùng chính dịch vụ API Gateway" — API Gateway có execution log và access log, hữu ích cho vấn đề ở tầng API. Nhưng nó chỉ thấy chặng đầu tiên — không biết gì về những gì xảy ra bên trong chuỗi microservices.

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, lúc nào? | | CloudWatch Logs | Ứng dụng đã ghi gì? | | CloudTrail | Ai gọi API quản trị? |

Nhận dạng nhanh: đề nói microservices, distributed, trace, không biết thành phần nào hỏng ⇒ X-Ray.

(Ghi chú về mã lỗi: 501 Not Implemented thường nghĩa là phương thức HTTP không được hỗ trợ — với API Gateway, nó có thể xuất hiện khi integration hoặc method chưa được cấu hình đúng. X-Ray vẫn là công cụ đúng để xác định chặng phát sinh.)

Đáp án

A — Đặt resource-based policy trên S3 bucket để TỪ CHỐI truy cập khi request có điều kiện "aws:SecureTransport": "false".

Vì sao đúng

Yêu cầu: bắt buộc mã hoá khi truyền cho mọi người dùng được cấp quyền GetObject, trên nhiều tài khoản AWS.

Có ba quyết định trong câu này, và phương án đúng thoả cả ba:

1. Đặt ở S3 bucket, không phải KMS key. Yêu cầu là bắt buộc HTTPS khi gọi S3. Đặt điều kiện ở KMS chỉ kiểm soát lời gọi tới KMS, không kiểm soát cách client nói chuyện với S3.

2. Dùng Deny, không dùng Allow. Đây là điểm quan trọng nhất về mặt bảo mật:

Vì Deny tường minh luôn thắng mọi Allow, cách này bảo vệ được kể cả khi ai đó thêm một IAM policy rộng ở tài khoản khác.

3. Resource-based policy phủ được nhiều tài khoản. Bucket policy áp cho mọi request tới bucket, bất kể người gọi thuộc tài khoản nào — nên một policy là đủ cho toàn bộ.

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::du-lieu-nhay-cam", "arn:aws:s3:::du-lieu-nhay-cam/*"],
  "Condition": {"Bool": {"aws:SecureTransport": "false"}}
}

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

• D. Allow trên S3 khi SecureTransport = false — cấp quyền cho đúng thứ cần chặn. Sai hoàn toàn về ý định.
• C. Deny trên KMS key khi SecureTransport = false — chặn được lời gọi KMS qua HTTP, nhưng không chặn được request tới S3 qua HTTP. Sai đối tượng. (Và trên thực tế, mọi endpoint AWS đều đã là HTTPS, nên điều kiện này ở KMS gần như không bao giờ khớp.)
• B. Allow trên KMS key khi SecureTransport = false — sai cả hai vế.

Ghi nhớ

aws:SecureTransport là khoá điều kiện toàn cục, dùng được với mọi dịch vụ AWS — không chỉ S3:

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

Vài khoá điều kiện toàn cục hữu ích khác: | Khoá | Kiểm tra | |---|---| | aws:SecureTransport | request có dùng HTTPS không | | aws:SourceIp | IP nguồn | | aws:SourceVpce | đến từ VPC endpoint nào | | aws:PrincipalOrgID | thuộc tổ chức nào | | aws:MultiFactorAuthPresent | có dùng MFA không |

Và nguyên tắc thiết kế: dùng Deny cho guardrail bảo mật, Allow cho việc cấp quyền. Deny không thể bị lách bởi bất kỳ policy nào khác — đó là điều làm nó phù hợp cho các yêu cầu tuân thủ.

Đáp án

B và D.

• B — API Gateway + Lambda
• D — ALB + ECS

Vì sao đúng

Đề nêu ba yêu cầu: kiến trúc mới phải có tính sẵn sàng cao, co giãn được, và thay thế mô hình "tất cả nằm trên một máy chủ" cho một API gửi/nhận tin nhắn.

Cả hai phương án đều là kiến trúc web nhiều tầng đúng chuẩn, chỉ khác mức trừu tượng:

B — API Gateway + Lambda (serverless):

Client → API Gateway (đa AZ, co giãn tự động)
              ↓
         Lambda (đồng thời tới 1.000+, tự phục hồi)

D — ALB + ECS (container):

Client → ALB (đa AZ)
            ↓
     ECS service (nhiều task, trải trên nhiều AZ, tự co giãn)

Phù hợp khi tác vụ chạy lâu, cần kiểm soát runtime, hoặc di trú ứng dụng có sẵn vào container mà không viết lại.

Cả hai đều loại bỏ điểm hỏng đơn lẻ — đúng vấn đề mà đề mô tả.

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

• E. EBS + RDS — hai dịch vụ lưu trữ, không phải tầng tính toán. Chúng không phục vụ được request nào. Và EBS gắn vào một instance trong một AZ, nên bản thân nó còn là điểm hỏng đơn lẻ.
• A. SES + S3 — SES gửi EMAIL, không gửi tin nhắn SMS/text theo API (dịch vụ đó là SNS hoặc Pinpoint). S3 là kho object tĩnh, không chạy được logic ứng dụng.
• C. CloudWatch + CloudFront — CloudWatch là giám sát, CloudFront là CDN. Không cái nào chạy mã ứng dụng; CloudFront còn cần một origin ở phía sau, mà phương án không nêu origin nào.

Ghi nhớ

Một kiến trúc web sẵn sàng cao luôn cần đủ ba tầng: | Tầng | Lựa chọn | |---|---| | Vào | API Gateway, ALB, CloudFront | | Tính toán | Lambda, ECS/Fargate, EC2 trong ASG | | Dữ liệu | DynamoDB, RDS Multi-AZ, Aurora, ElastiCache |

Thiếu tầng tính toán thì không có ứng dụng — đó là điểm loại của A, C và E trong câu này.

Và nguyên tắc chống điểm hỏng đơn lẻ: luôn ≥ 2 AZ, không lưu trạng thái trên máy tính toán, có health check kèm tự thay thế.