Ngân hàng đề — AWS Certified Solutions Architect Professional

Đáp án

C — Dùng CloudFront với S3 để phục vụ ứng dụng web; dùng AWS AppSync để dựng API; dùng Cognito group cho phân quyền theo vai; uỷ quyền truy cập dữ liệu bằng Cognito group trong AppSync resolver.

Vì sao đúng

Đề nêu năm yêu cầu, và yêu cầu "minimize the cost of API calls" là thứ chỉ thẳng tới GraphQL.

⚠ Điểm mấu chốt: GraphQL giảm số lời gọi bằng cách gộp nhiều nguồn vào một truy vấn — đó là lý do nó thắng REST ở đây:

Với REST: mỗi nguồn dữ liệu là một endpoint
        ↓
    Màn hình cần 4 loại dữ liệu → 4 lời gọi API
        ↓
    Và mỗi lời gọi trả về nhiều trường hơn mức client cần

Với GraphQL (AppSync)
        ↓
    Client gửi MỘT truy vấn mô tả đúng những gì nó cần
        ↓
    AppSync gọi song song các resolver tới DynamoDB, Lambda, RDS, HTTP...
        ↓
    → một lời gọi thay vì bốn, và không có dữ liệu thừa

Vì sao Cognito group cho RBAC. Cognito user pool quản lý người dùng và nhóm; AppSync đọc claim cognito:groups từ token và áp quyền ngay trong resolver:

type DonHang @aws_auth(cognito_groups: ["quan-tri", "ke-toan"]) {
  id: ID!
  soTien: Float!
}

⚠ Cognito user pool và identity pool là hai thứ khác nhau — đừng lẫn: | Loại | Việc | |---|---| | User pool | thư mục người dùng — đăng ký, đăng nhập, group | | Identity pool | đổi token lấy thông tin đăng nhập AWS tạm thời |

Bài này cần user pool vì phân quyền dựa trên group của người dùng.

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

• D (CloudFront + S3 — đúng; nhưng API Gateway với Lambda custom authorizer, và tra cứu người dùng trong AWS Managed Microsoft AD) — đây là phương án gần nhất và phần front end của nó chính xác. Nhưng nó thua ở hai điểm. Thứ nhất, API Gateway theo mô hình REST không giảm được số lời gọi khi cần dữ liệu từ nhiều nguồn — mỗi nguồn vẫn là một endpoint riêng, đi ngược yêu cầu "minimize the cost of API calls". Thứ hai, AWS Managed Microsoft AD không phải giải pháp serverless: nó chạy trên domain controller có quản lý, tính tiền theo giờ liên tục, và đòi VPC — trái với yêu cầu "fully serverless".

• A (CloudFront + EC2 để host ứng dụng web, API Gateway, Lambda cho xác thực tuỳ chỉnh, IAM role để uỷ quyền) — EC2 phá vỡ yêu cầu serverless ngay từ đầu. Ngoài ra tự viết xác thực bằng Lambda là làm lại thứ Cognito cung cấp sẵn, với nhiều rủi ro bảo mật hơn.

• B (CloudFront + Amazon FSx để host ứng dụng web, AppSync, IAM group cho RBAC) — hai lỗi. FSx là hệ thống tệp cho máy chủ, không phải nơi host website tĩnh — và nó không serverless. Và IAM group dành cho danh tính AWS của bạn, không dành cho người dùng cuối của ứng dụng; hàng nghìn người dùng ứng dụng không thể là IAM user.

Ghi nhớ

⚠ AppSync so với API Gateway — bảng phải thuộc: | | AppSync (GraphQL) | API Gateway (REST) | |---|---|---| | Số lời gọi cho màn hình nhiều dữ liệu | một | nhiều | | Client chọn trường | có | không | | Nhiều nguồn dữ liệu trong một truy vấn | có | không | | Đẩy dữ liệu thời gian thực | subscription có sẵn | cần WebSocket API | | Cache, usage plan, API key | có nhưng khác | đầy đủ hơn |

Từ khoá nhận diện:

"retrieve data from multiple data sources" → AppSync (GraphQL) "minimize the cost of API calls" → GraphQL gộp lời gọi "RBAC cho người dùng ứng dụng" → Cognito group "IAM group cho người dùng cuối" → SAI, IAM dành cho danh tính AWS "fully serverless" → loại EC2, FSx, Managed Microsoft AD

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Token có claim group không | giải mã ID token, tìm cognito:groups | | Resolver có chặn đúng không | gọi truy vấn bằng token của người không thuộc group | | Số lời gọi có giảm không | so số request API trước và sau khi chuyển sang GraphQL |

Và một lời khuyên: hãy đặt giới hạn độ sâu và độ phức tạp cho truy vấn GraphQL ngay từ đầu. Đây là mặt trái của chính ưu điểm mà bạn chọn AppSync: vì client tự soạn truy vấn, một truy vấn lồng nhiều tầng — đơn hàng lấy khách hàng, khách hàng lấy danh sách đơn hàng, mỗi đơn lại lấy khách hàng — có thể khiến AppSync gọi hàng nghìn resolver cho một request duy nhất. Nó không phải tấn công, chỉ là một lập trình viên frontend viết truy vấn tiện tay. Không có lỗi nào xảy ra, request vẫn trả về đúng dữ liệu, và bạn chỉ thấy hậu quả trên hoá đơn Lambda cùng biểu đồ tải của cơ sở dữ liệu.

Đáp án

B — Bật versioning cho hàm Lambda và gắn alias cho mỗi phiên bản mới; dùng lệnh update-alias của AWS CLI với tham số routing-config để chia lưu lượng.

Vì sao đúng

Đề đòi triển khai từng phần nhỏ, tăng dần cho các hàm Lambda. Lambda có cơ chế dựng sẵn cho đúng việc đó, và nó nằm ở alias.

⚠ Điểm mấu chốt: chỉ ALIAS chia được lưu lượng — version thì không:

Version: ảnh chụp bất biến của mã, đánh số 1, 2, 3...
        ↓
    Một version chỉ là chính nó, không trỏ đi đâu
        ↓
Alias: con trỏ có tên (prod, staging) tới một version
        ↓
    Với routing-config, alias trỏ tới HAI version kèm trọng số
        ↓
    → 90% lời gọi vào version 5, 10% vào version 6

Đây là lý do phương án C sai: nó dùng đúng tham số nhưng gắn vào sai đối tượng.

aws lambda publish-version --function-name gio-hang

# 10% lưu lượng sang version mới
aws lambda update-alias --function-name gio-hang --name prod \
  --function-version 5 \
  --routing-config '{"AdditionalVersionWeights":{"6":0.1}}'

# tăng dần
aws lambda update-alias --function-name gio-hang --name prod \
  --function-version 5 --routing-config '{"AdditionalVersionWeights":{"6":0.5}}'

# lùi lại tức thì
aws lambda update-alias --function-name gio-hang --name prod \
  --function-version 5 --routing-config '{}'

⚠ Người gọi phải trỏ tới ALIAS, không trỏ thẳng vào hàm:

API Gateway hoặc event source dùng ARN của hàm mà không có hậu tố alias
        ↓
    Lời gọi đi vào $LATEST, bỏ qua toàn bộ cơ chế alias
        ↓
    → routing-config không có tác dụng, và không có lỗi nào báo cho bạn
        ↓
    → ARN phải dạng arn:...:function:gio-hang:prod

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

• C (bật versioning để đánh dấu từng bước, dùng lệnh update-function-configuration với tham số routing-config) — đây là phương án gần nhất và nó chỉ sai đúng một tên lệnh: phần versioning là đúng và cần thiết, và nó cũng nhận ra routing-config là thứ phải dùng. Nhưng update-function-configuration không có tham số --routing-config — lệnh đó chỉnh cấu hình của chính hàm: bộ nhớ, timeout, biến môi trường, VPC, layer. Chia trọng số là thuộc tính của alias, nên lệnh đúng là update-alias. Đây là bẫy kiểm tra đúng một chi tiết API, và là loại câu thưởng cho người đã thật sự gõ lệnh đó.

• A (dùng CodeDeploy với cấu hình CodeDeployDefault.AllAtOnce) — CodeDeploy triển khai Lambda được và là công cụ rất hợp cho canary, nhưng AllAtOnce chuyển toàn bộ lưu lượng cùng lúc — đối lập hoàn toàn với "small incremental deployments" mà đề yêu cầu. Cấu hình đúng phải là Canary10Percent5Minutes hoặc Linear10PercentEvery1Minute.

• D (triển khai vào một CloudFormation stack mới, dùng Route 53 weighted routing để chia tải) — nặng nề và sai tầng. Route 53 chia lưu lượng ở tầng DNS, chỉ có tác dụng khi người gọi phân giải tên miền — nó không áp dụng cho lời gọi Lambda từ event source như S3, SQS hay EventBridge. Dựng một stack song song cũng tốn kém hơn nhiều so với đổi một tham số trên alias.

Ghi nhớ

⚠ Bốn khái niệm phiên bản của Lambda — bảng phải thuộc: | Khái niệm | Nội dung | |---|---| | $LATEST | bản đang sửa, luôn thay đổi | | Version | ảnh chụp bất biến, đánh số tăng dần | | Alias | con trỏ có tên, chia trọng số được | | Layer | thư viện dùng chung, có version riêng |

Từ khoá nhận diện:

"incremental deployment" / "canary" cho Lambda → alias với routing-config update-alias --routing-config → đúng lệnh update-function-configuration --routing-config → LUÔN SAI, không có tham số đó AllAtOnce khi đề đòi tăng dần → SAI, chuyển hết cùng lúc Route 53 weighted routing cho Lambda → SAI tầng, không áp cho event source

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lưu lượng có chia đúng không | so Invocations theo dimension ExecutedVersion | | Người gọi có trỏ tới alias không | kiểm ARN trong cấu hình event source | | Version mới có lỗi cao hơn không | so tỷ lệ lỗi giữa hai version |

Và một lời khuyên: hãy lọc chỉ số theo ExecutedVersion khi chạy canary, đừng nhìn chỉ số tổng của hàm. Đây là lý do canary thường không phát hiện được chính vấn đề nó sinh ra để phát hiện: nếu version mới lỗi 100% nhưng chỉ nhận 10% lưu lượng, tỷ lệ lỗi tổng chỉ nhích lên 10% — một con số rất dễ bị bỏ qua như nhiễu, nhất là khi hàm vốn đã có vài phần trăm lỗi nền. Bạn sẽ thấy biểu đồ hơi xấu đi, quyết định theo dõi thêm, rồi tăng trọng số lên 50%. Chỉ khi tách theo version thì bức tranh mới rõ: một bên 0% lỗi, một bên hỏng hoàn toàn.

Đáp án

C — Dùng Lambda tạo EBS snapshot hằng ngày và sao chép sang Region dự phòng; dựng Aurora Replica ở Region đó; Route 53 với cấu hình failover active-passive; Auto Scaling group ở Region dự phòng đặt capacity bằng 0.

Vì sao đúng

Đề nói rõ chiến lược pilot light, RTO 6 giờ, RPO 24 giờ, và chi phí tối thiểu. Bốn dữ kiện này chỉ thẳng tới một cấu hình.

⚠ Điểm mấu chốt: pilot light nghĩa là giữ TẦNG DỮ LIỆU sống và tắt TẦNG TÍNH TOÁN:

Tầng dữ liệu (Aurora Replica)
        ↓
    Phải chạy liên tục — sao chép dữ liệu là thứ không dựng lại nhanh được
        ↓
Tầng tính toán (EC2)
        ↓
    Đặt capacity = 0, không trả tiền
    Khi có sự cố → tăng desired capacity, máy khởi động từ AMI
        ↓
    → đó chính là "ngọn lửa mồi": đủ để bùng lên, không đủ để tốn tiền

Đây là điểm phân biệt với warm standby (máy chạy ở quy mô nhỏ) và với backup-restore (không có gì chạy sẵn).

Vì sao active-passive chứ không active-active. Active-active nghĩa là cả hai Region đều phục vụ lưu lượng, đòi hạ tầng đầy đủ ở cả hai nơi — đắt hơn nhiều và mâu thuẫn với chính định nghĩa pilot light.

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name dr-asg \
  --min-size 0 --max-size 20 --desired-capacity 0

⚠ Route 53 failover cần health check trỏ vào một endpoint phản ánh sức khoẻ THẬT:

Health check chỉ ping một trang tĩnh
        ↓
    Web server còn sống nhưng cơ sở dữ liệu đã mất
        ↓
    → health check vẫn xanh, không chuyển vùng, người dùng nhận lỗi 500

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

• B (EBS cross-Region snapshot copy, Aurora Replica ở Region DR, Route 53 active-passive, Auto Scaling group cấu hình GIỐNG HỆT Region chính) — đây là phương án gần nhất và ba phần tư của nó chính xác bằng đáp án đúng: snapshot xuyên Region, Aurora Replica, active-passive failover. Nó chỉ khác ở một chỗ, và chỗ đó quyết định chi phí: Auto Scaling group chạy với cùng số máy như Region chính nghĩa là bạn trả tiền cho một đội EC2 đầy đủ suốt 24/7 chỉ để ngồi chờ. Đó không còn là pilot light mà là warm standby hoặc hơn — và đề nêu thẳng "MINIMAL cost". Với RTO 6 giờ, hoàn toàn đủ thời gian để scale từ 0 lên, nên khoản chi đó không mua lại điều gì.

• D (EBS và RDS cross-Region snapshot copy, Route 53 ACTIVE-ACTIVE, ASG capacity 0) — mâu thuẫn nội tại. Active-active nghĩa là cả hai Region cùng phục vụ, nhưng Region DR có capacity bằng 0 nên không có máy nào phục vụ được — Route 53 sẽ gửi một nửa lưu lượng vào hư không. Ngoài ra dùng snapshot cho tầng dữ liệu thay vì Aurora Replica khiến RTO khó đạt 6 giờ với cơ sở dữ liệu lớn.

• A (Lambda tạo snapshot EBS và RDS hằng ngày, Route 53 active-active, ASG cấu hình giống Region chính) — gộp cả hai lỗi: active-active không hợp với pilot light, và ASG đầy đủ thì tốn tiền. Nó cũng dùng snapshot RDS thay vì replica, làm RTO xấu đi.

Ghi nhớ

⚠ Bốn chiến lược DR — bảng phải thuộc, đây là bảng ra thi nhiều nhất: | Chiến lược | Tầng dữ liệu | Tầng tính toán | RTO | |---|---|---|---| | Backup & Restore | chỉ sao lưu | không có gì | giờ | | Pilot Light | chạy sẵn (replica) | tắt (capacity 0) | chục phút tới giờ | | Warm Standby | chạy sẵn | chạy ở quy mô nhỏ | phút | | Multi-Site Active/Active | chạy sẵn | đầy đủ, đang phục vụ | gần bằng 0 |

Từ khoá nhận diện:

"pilot light" → dữ liệu chạy sẵn, tính toán capacity 0 "MINIMAL cost" + RTO tính bằng giờ → không giữ EC2 chạy ở Region DR "active-active" với capacity 0 → LUÔN SAI, mâu thuẫn "ASG configured the same as primary" khi đòi chi phí tối thiểu → quá đắt cho pilot light RPO 24 giờ → snapshot hằng ngày là đủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | RTO thật là bao lâu | diễn tập chuyển vùng, bấm giờ từ lúc alarm kêu | | AMI có ở Region DR không | describe-images ở Region đó | | Quota có đủ để scale lên không | kiểm service quota vCPU ở Region DR |

Và một lời khuyên: hãy kiểm tra hạn mức vCPU ở Region dự phòng và xin nâng ngay từ bây giờ. Đây là thứ phá hỏng kế hoạch pilot light một cách chắc chắn nhất và không thể phát hiện bằng bất kỳ phép thử nào ngoài việc thật sự scale lên: một Region mới dùng có hạn mức mặc định thấp, và vì Auto Scaling group của bạn luôn ở mức 0, hạn mức đó chưa bao giờ bị chạm tới nên không có gì cảnh báo. Đến ngày sự cố, bạn tăng desired capacity lên hai mươi máy và nhận về InsufficientInstanceCapacity hoặc lỗi vượt quota — trong khi đồng hồ RTO đang chạy và quy trình xin nâng hạn mức mất hàng giờ.

Đáp án

A, D — hai bước giảm thời gian phản hồi cho người dùng toàn cầu:

• D — Dùng Route 53 với latency-based routing; tạo Auto Scaling group cho tầng web và tầng ứng dụng, triển khai ở nhiều Region.
• A — Cấu hình Aurora global database để sao chép xuyên Region ở tầng lưu trữ; dùng S3 với cross-Region replication cho nội dung tĩnh và tạo CloudFront distribution.

Vì sao đúng

Đề đòi giảm thời gian phản hồi cho khán giả toàn cầu, và mỗi tầng cần một cơ chế riêng.

⚠ Điểm mấu chốt: đưa hạ tầng tới gần người dùng chỉ có ý nghĩa nếu DỮ LIỆU cũng đi theo:

Chỉ triển khai web và app ở nhiều Region
        ↓
    Mọi truy vấn vẫn phải quay về cơ sở dữ liệu ở Region gốc
        ↓
    → độ trễ xuyên lục địa vẫn còn, chỉ dịch chuyển sang chặng khác

Thêm Aurora global database
        ↓
    Mỗi Region có replica đọc được tại chỗ
        ↓
    → tải đọc (phần lớn lưu lượng, theo đề) được phục vụ ngay tại Region đó

Đề nói rõ "most website traffic is read-only" — đó là điều kiện khiến global database phát huy tối đa: ghi vẫn về Region chính, nhưng phần lớn lưu lượng là đọc và được phục vụ tại chỗ.

Vì sao latency-based routing. Nó gửi mỗi người dùng tới Region cho độ trễ thấp nhất với chính họ — chính xác hơn geolocation, vì nó đo độ trễ thật chứ không suy từ vị trí địa lý.

aws route53 change-resource-record-sets --hosted-zone-id Z1 --change-batch '{
  "Changes":[{"Action":"CREATE","ResourceRecordSet":{
    "Name":"shop.congty.vn","Type":"A","SetIdentifier":"ap-southeast-1",
    "Region":"ap-southeast-1",
    "AliasTarget":{"HostedZoneId":"Z2","DNSName":"alb-sg.elb.amazonaws.com","EvaluateTargetHealth":true}}}]}'

⚠ Aurora global database chỉ ghi ở Region chính — ứng dụng phải tách đường đọc và đường ghi:

Region phụ: chỉ đọc
        ↓
    Nếu ứng dụng gửi lệnh ghi tới đó → lỗi
        ↓
    → mã phải dùng reader endpoint tại chỗ cho SELECT
      và writer endpoint của Region chính cho INSERT/UPDATE

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

• C (sao chép logic xuyên Region cho Aurora, thay web server bằng S3, cấu hình CRR cho bucket) — đây là phương án gần nhất và phần nội dung tĩnh của nó đúng. Nhưng nó hỏng ở hai chỗ. Sao chép logic (dựa trên binlog) chậm hơn và tốn tài nguyên hơn hẳn so với sao chép ở tầng lưu trữ của global database — đề còn nêu rõ "storage-based cross-Region replication" ở phương án A, cho thấy đó là điểm phân biệt cố ý. Và "thay web server bằng S3" là không thể: đề nói đây là website động với tầng ứng dụng; S3 chỉ phục vụ tệp tĩnh.

• B (chuyển Aurora sang RDS for MySQL, thay web và app bằng Lambda, thêm SQS) — đi lùi ở tầng dữ liệu (Aurora tốt hơn RDS MySQL về hiệu năng và sao chép), và đòi viết lại toàn bộ ứng dụng. Nó cũng không có thành phần nào giảm độ trễ toàn cầu.

• E (Auto Scaling group ở nhiều Region — đúng; nhưng thêm Direct Connect) — Direct Connect nối trung tâm dữ liệu của bạn với AWS, nó không liên quan gì tới độ trễ của khách hàng trên Internet. Đây là công cụ đúng cho một bài toán khác hoàn toàn.

Ghi nhớ

⚠ Bốn tầng cần xử lý khi tối ưu cho khán giả toàn cầu — bảng phải thuộc: | Tầng | Công cụ | |---|---| | Nội dung tĩnh | CloudFront (+ S3 CRR nếu cần origin gần) | | Định tuyến | Route 53 latency-based hoặc Global Accelerator | | Tính toán | Auto Scaling group ở nhiều Region | | Dữ liệu | Aurora global database / DynamoDB global table |

Từ khoá nhận diện:

"global audience" + "optimal performance" → nhiều Region + CloudFront "read-only traffic chiếm phần lớn" → global database phát huy tối đa "storage-based replication" → Aurora global database "logical replication" cho đa Region → chậm hơn, tốn hơn "Direct Connect" để giảm độ trễ cho khách trên Internet → SAI công cụ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng có đi đúng Region không | đo từ nhiều nơi, xem header phản hồi | | Độ trễ sao chép | AuroraGlobalDBReplicationLag | | Tỷ lệ trúng cache | CacheHitRate của CloudFront |

Và một lời khuyên: hãy tách rõ đường đọc và đường ghi trong mã ứng dụng trước khi triển khai đa Region. Đây là chỗ kiến trúc đa Region gây ra lỗi khó hiểu nhất: ứng dụng chạy hoàn hảo ở Region chính vì ở đó reader và writer trỏ về cùng một cụm, nên một lệnh INSERT đi nhầm qua đường đọc vẫn thành công. Chỉ khi triển khai sang Region phụ — nơi cụm thật sự chỉ đọc — thì lỗi mới xuất hiện, và nó xuất hiện rải rác ở đúng những luồng nghiệp vụ ít được kiểm thử nhất. Việc tách hai endpoint ngay từ đầu tốn vài giờ; việc truy tìm chúng sau khi đã lên đa Region tốn nhiều hơn thế rất nhiều.

Đáp án

B — Xác định địa chỉ IP trong request tới S3 bằng S3 access log và Athena; dùng AWS Config với Auto Remediation để khắc phục mọi thay đổi bucket policy; cấu hình cảnh báo bằng AWS Config và SNS.

Vì sao đúng

Đề đòi hai việc tách bạch, và mỗi vế cần một công cụ khác nhau.

⚠ Điểm mấu chốt: AWS Config là dịch vụ duy nhất vừa PHÁT HIỆN lệch cấu hình vừa TỰ KHẮC PHỤC:

Ai đó sửa bucket policy
        ↓
    Config ghi lại configuration item mới
        ↓
    Config rule đánh giá: không tuân thủ
        ↓
    Remediation action (SSM Automation document) tự chạy
        ↓
    → khôi phục policy về trạng thái mong muốn, và bắn SNS

Đây là mẫu detect and auto-remediate mà Config sinh ra để phục vụ, và nó là thứ khiến phương án B khác với A.

Vì sao S3 access log cho phần IP. Nó ghi lại mọi request tới bucket, kèm IP nguồn, người gọi, thao tác, mã phản hồi — rồi Athena truy vấn bằng SQL:

SELECT remoteip, count(*) AS so_lan
FROM s3_access_logs
WHERE requestdatetime >= '01/Sep/2026'
GROUP BY remoteip
ORDER BY so_lan DESC;

⚠ S3 access log và CloudTrail data event ghi những thứ chồng lấn nhưng không giống nhau: | | S3 server access log | CloudTrail data event | |---|---|---| | Chi phí | miễn phí (chỉ trả tiền lưu trữ) | tính phí theo sự kiện | | Độ trễ | vài giờ | vài phút | | Đầy đủ | best-effort, có thể sót | đảm bảo | | Có IP nguồn | có | có |

Với yêu cầu "nhận diện IP" mà không nêu ràng buộc thời gian thực, access log là lựa chọn rẻ hơn.

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

• A (CloudTrail ghi management event, CloudWatch Events + Lambda tự khắc phục thay đổi bucket policy, SNS cảnh báo) — đây là phương án gần nhất và cơ chế khắc phục của nó chạy được: EventBridge bắt sự kiện PutBucketPolicy rồi gọi Lambda là mẫu hợp lệ. Nhưng nó thua ở hai điểm. Thứ nhất, CloudTrail management event không ghi các request đọc/ghi object, nên nó không trả lời được câu hỏi "IP nào đang gọi tới bucket" — muốn vậy phải bật data event, thứ phương án không nhắc tới. Thứ hai, tự viết Lambda để khắc phục là làm lại thứ Config đã có sẵn dưới dạng remediation action, kèm theo lịch sử tuân thủ và báo cáo mà bạn không phải xây.

• D (CloudWatch Logs với Athena connector để tìm IP, CloudWatch Events + Lambda khắc phục) — sai nguồn dữ liệu. CloudWatch Logs không chứa request tới S3 trừ khi bạn tự đẩy chúng vào đó, và không có luồng mặc định nào làm việc ấy. Phương án này giả định một nguồn dữ liệu không tồn tại.

• C (dùng Amazon Macie để tìm IP trong request tới S3, Macie + Lambda tự khắc phục, dùng cảnh báo của Macie) — sai vai trò dịch vụ. Macie phân loại DỮ LIỆU nhạy cảm nằm trong bucket — nó tìm số thẻ tín dụng, số căn cước, thông tin cá nhân trong nội dung object. Nó không phân tích request và không biết IP nào gọi tới, cũng không có cơ chế khắc phục thay đổi bucket policy.

Ghi nhớ

⚠ Bốn dịch vụ hay bị lẫn trong bảo mật S3 — bảng phải thuộc: | Dịch vụ | Trả lời câu hỏi | |---|---| | S3 access log / CloudTrail data event | "Ai đã gọi tới bucket, từ IP nào?" | | AWS Config | "Cấu hình có lệch chuẩn không, và tự sửa lại" | | Macie | "Trong bucket có dữ liệu nhạy cảm gì?" | | GuardDuty (S3 protection) | "Có hành vi truy cập bất thường không?" |

Từ khoá nhận diện:

"identify IP addresses making requests" → S3 access log hoặc CloudTrail data event "automatically remediate configuration changes" → AWS Config + remediation "Macie để tìm IP" → LUÔN SAI, Macie phân loại dữ liệu "CloudWatch Logs chứa request S3" → SAI, không có luồng mặc định "CloudTrail management event" cho thao tác object → cần data event, tính phí riêng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Access log có được ghi không | kiểm bucket đích có tệp log mới | | Remediation có chạy không | cố ý sửa policy trong môi trường thử và quan sát | | Cảnh báo có tới không | kiểm subscription của SNS topic |

Và một lời khuyên: hãy thêm một SCP chặn s3:PutBucketPolicy bên cạnh cơ chế tự khắc phục, đừng chỉ dựa vào Config. Auto-remediation là lưới an toàn, không phải hàng rào: giữa lúc ai đó sửa bucket policy và lúc Config phát hiện rồi khôi phục, có một cửa sổ thật — thường vài phút — trong đó dữ liệu tối mật đang ở trạng thái mà chính sách đã bị thay đổi. Với thông tin cực kỳ nhạy cảm, vài phút là quá đủ để một bucket bị đọc hết. Config cho bạn biết chuyện đã xảy ra và sửa lại; SCP làm cho nó không xảy ra được.

Đáp án

A — Cấu hình security group trên interface endpoint để cho phép kết nối tới dịch vụ AWS.

Vì sao đúng

Đề nói interface endpoint đã được tạo trong private subnet nhưng kết nối thất bại. Với interface endpoint, nguyên nhân số một là security group.

⚠ Điểm mấu chốt: interface endpoint là một ENI, nên nó CÓ security group — và security group mặc định thường không cho gì vào:

Interface endpoint = một ENI trong subnet của bạn, có IP riêng
        ↓
    ENI đó gắn security group
        ↓
    Nếu security group không cho phép cổng 443 từ dải CIDR của VPC
        ↓
    → mọi kết nối tới endpoint bị chặn
        ↓
    → và triệu chứng là TIMEOUT, không phải lỗi quyền

Đây là khác biệt căn bản với gateway endpoint (S3, DynamoDB), vốn là mục trong route table và không gắn security group được.

aws ec2 authorize-security-group-ingress --group-id sg-endpoint \
  --protocol tcp --port 443 --cidr 10.0.0.0/16

⚠ Ba thứ phải đúng cùng lúc cho một interface endpoint: | Thứ | Nội dung | |---|---| | Security group của endpoint | cho phép 443 từ nguồn cần dùng | | Security group của instance | cho phép đi ra tới endpoint | | Private DNS | bật thì tên dịch vụ chuẩn mới trỏ về IP riêng |

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

• C (bật tuỳ chọn private DNS trên thuộc tính của VPC) — đây là phương án gần nhất và private DNS thật sự là một nguyên nhân phổ biến khiến endpoint không dùng được. Nhưng nó bị diễn đạt sai và nhắm sai lớp. Private DNS là tuỳ chọn của chính ENDPOINT, không phải "thuộc tính của VPC" — thứ thuộc về VPC là enableDnsSupport và enableDnsHostnames, hai điều kiện tiên quyết. Quan trọng hơn, khi private DNS chưa bật thì triệu chứng là tên dịch vụ vẫn phân giải ra IP công cộng và lưu lượng đi ra Internet — nghĩa là với một private subnet không có NAT, bạn cũng gặp timeout, nhưng cách chữa là bật đúng tuỳ chọn trên endpoint chứ không phải trên VPC. Đây là bẫy tinh vi vì nó nhắc đúng khái niệm nhưng đặt sai chỗ.

• D (cập nhật route table của subnet để thêm route tới interface endpoint) — nhầm hai loại endpoint. Interface endpoint hoạt động bằng DNS, không bằng route table — nó có IP riêng trong subnet và được truy cập như một máy chủ bình thường. Chỉ gateway endpoint mới cần mục trong route table. Không có cách nào "thêm route tới interface endpoint".

• B (dựng private hosted zone với conditional forwarder cho ứng dụng nội bộ) — không liên quan tới vấn đề. Conditional forwarding dùng để phân giải tên miền của mạng khác (ví dụ Active Directory tại chỗ); nó không phải cách để truy cập dịch vụ AWS qua endpoint.

Ghi nhớ

⚠ Hai loại VPC endpoint — bảng phải thuộc, chú ý cột cơ chế: | | Gateway endpoint | Interface endpoint | |---|---|---| | Dịch vụ | chỉ S3 và DynamoDB | hầu hết dịch vụ AWS | | Cơ chế | mục trong route table | ENI có IP riêng, qua DNS | | Security group | không gắn được | gắn được — và đây là nguyên nhân lỗi số một | | Chi phí | miễn phí | theo giờ + theo GB | | Từ on-premises | không dùng được | dùng được qua DX/VPN |

Từ khoá nhận diện:

"interface endpoint" + kết nối thất bại → kiểm security group của endpoint trước tiên "route table cho interface endpoint" → LUÔN SAI, đó là gateway endpoint "private DNS" → tuỳ chọn của endpoint, cần enableDnsSupport và enableDnsHostnames của VPC gateway endpoint không hoạt động → kiểm route table timeout → tầng mạng; AccessDenied → tầng quyền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Security group của endpoint | describe-vpc-endpoints, xem Groups | | Private DNS đã bật chưa | cùng lệnh, xem PrivateDnsEnabled | | Endpoint có ở đúng subnet không | xem SubnetIds có phủ mọi AZ đang dùng |

Và một lời khuyên: hãy tạo interface endpoint ở MỌI Availability Zone mà bạn có tài nguyên, đừng chỉ một. Đây là cấu hình thiếu sót gây ra lỗi ngắt quãng khó chịu nhất: endpoint chỉ có ENI ở những AZ bạn khai, và một instance ở AZ không có ENI sẽ hoặc không kết nối được, hoặc đi vòng qua AZ khác — thêm độ trễ và thêm phí truyền dữ liệu chéo AZ. Triệu chứng là "đôi khi chạy, đôi khi không", tuỳ máy nào trong Auto Scaling group nhận request, và nó gần như không thể tái hiện được khi bạn thử từ một máy cụ thể.

Đáp án

B, E — hai bước cho cụm HPC 10 node cần kết nối liên node tốc độ cao:

• B — Triển khai EC2 instance trong một placement group.
• E — Dùng loại EC2 instance hỗ trợ Elastic Fabric Adapter (EFA).

Vì sao đúng

Đề nói "high-speed inter-node connectivity" cho một cụm HPC. Đó là bài toán mạng giữa các node, và AWS có đúng hai công cụ cho nó.

⚠ Điểm mấu chốt: EFA bỏ qua kernel, và đó là nơi độ trễ giảm mạnh nhất:

ENA thường: ứng dụng → kernel → driver → card mạng
        ↓
    Mỗi lần chuyển ngữ cảnh tốn vài chục micro giây

EFA: ứng dụng (qua libfabric) → THẲNG tới card mạng
        ↓
    Bỏ qua kernel hoàn toàn
        ↓
    → độ trễ thấp và ổn định — thứ mà workload gắn kết chặt cần nhất

Với HPC, thứ quan trọng không chỉ là băng thông mà là độ trễ và độ ổn định của độ trễ, vì các node trao đổi tin nhắn MPI liên tục và mọi node đều phải chờ node chậm nhất.

Về placement group. Với HPC, chiến lược cần dùng là cluster — nó đặt các instance trong cùng một Availability Zone, trên nhóm phần cứng gần nhau, cho băng thông cao nhất và độ trễ thấp nhất giữa các node.

aws ec2 create-placement-group --group-name hpc-cum --strategy cluster

aws ec2 run-instances --count 10 --instance-type c6in.32xlarge \
  --placement GroupName=hpc-cum \
  --network-interfaces '[{"DeviceIndex":0,"InterfaceType":"efa","SubnetId":"subnet-abc"}]'

⚠ Cluster placement group nằm trong MỘT Availability Zone — đó là đánh đổi có chủ ý:

Mọi node trong một AZ → độ trễ thấp nhất
        ↓
    Mất AZ đó là mất cả cụm
        ↓
    → với HPC gắn kết chặt, đây là đánh đổi ĐÚNG: workload vốn đã không chịu được
      mất một node giữa chừng, nên trải nhiều AZ chỉ thêm độ trễ mà không thêm
      khả năng chịu lỗi

Đây chính là lý do phương án A sai.

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

• C (triển khai EC2 trong Auto Scaling group) — đây là phương án gần nhất trong số các phương án còn lại và Auto Scaling group là công cụ hoàn toàn hợp lệ trong nhiều kiến trúc. Nhưng nó không giải quyết yêu cầu của đề: Auto Scaling lo việc thêm bớt máy theo tải và thay máy hỏng, nó không ảnh hưởng gì tới độ trễ giữa các node. Với một cụm HPC 10 node chạy một bài toán gắn kết chặt, số node thường cố định theo cấu hình bài toán, và việc một node bị thay giữa chừng sẽ làm hỏng cả lần chạy chứ không cứu được nó. Đây là bẫy chọn một dịch vụ quen thuộc cho một bài toán nó không phục vụ.

• A (triển khai instance trên nhiều Availability Zone) — đi ngược trực tiếp mục tiêu. Lưu lượng liên AZ đi qua khoảng cách vật lý lớn hơn, thêm hàng trăm micro giây mỗi chặng — mức phạt khổng lồ khi nhân với hàng triệu tin nhắn MPI. Ngoài ra cluster placement group không thể trải nhiều AZ, nên A và B loại trừ nhau.

• D (dùng instance có burstable performance) — sai hoàn toàn về loại tải. Instance dòng T tích luỹ credit CPU khi nhàn rỗi và tiêu credit khi cần hiệu năng — mô hình cho tải nhẹ, không đều. HPC chạy CPU ở 100% trong nhiều giờ; credit cạn ngay và instance bị bóp xuống mức nền. Đây là lựa chọn tệ nhất có thể cho tính toán hiệu năng cao.

Ghi nhớ

⚠ Ba chiến lược placement group — bảng phải thuộc: | Chiến lược | Bố trí | Dùng cho | |---|---|---| | Cluster | sát nhau, MỘT AZ | HPC, workload gắn kết chặt | | Partition | nhiều nhóm phần cứng tách biệt | HDFS, Cassandra, Kafka | | Spread | mỗi instance một phần cứng riêng | số ít instance quan trọng |

Từ khoá nhận diện:

"HPC" / "high-speed inter-node connectivity" → cluster placement group + EFA "MPI" → EFA "multiple Availability Zones" cho HPC gắn kết chặt → SAI, thêm độ trễ "Auto Scaling group" để cải thiện độ trễ liên node → SAI, không liên quan "burstable performance" cho HPC → LUÔN SAI, credit cạn ngay

Ba việc kiểm chứng: | Việc | Cách | |---|---| | EFA có bật thật không | fi_info -p efa trên instance | | Độ trễ giữa các node | OSU micro-benchmarks hoặc ib_write_lat | | Placement group có nhận đủ máy không | lỗi InsufficientInstanceCapacity khi khởi động cả cụm |

Và một lời khuyên: hãy khởi động toàn bộ cụm trong một lời gọi run-instances duy nhất. Đây là chỗ cluster placement group thất bại theo cách khó hiểu: AWS cần tìm đủ dung lượng liền kề cho cả nhóm, và nếu bạn thêm dần từng instance, những lần sau có thể nhận InsufficientInstanceCapacity dù Region còn rất nhiều máy trống — vì chỗ trống ấy không nằm cạnh những máy đã có. Thông báo lỗi nói về dung lượng chứ không nói về placement group, nên rất dễ đi tìm nguyên nhân ở hạn mức tài khoản hoặc ở loại instance, trong khi vấn đề chỉ là thứ tự khởi động.

Đáp án

B — Tạo EventBridge rule kích hoạt Lambda dùng AWS Trusted Advisor lấy dữ liệu tận dụng và hạn mức mới nhất; nếu vượt 80% thì publish vào SNS topic để cảnh báo đội cloud.

Vì sao đúng

Đề đòi ba thứ: giám sát mỗi 15 phút, cảnh báo ở 80% mức tận dụng, tự động và hiệu quả về vận hành.

⚠ Điểm mấu chốt: Trusted Advisor cho biết cả HẠN MỨC lẫn MỨC ĐANG DÙNG — API của Service Quotas thì chỉ cho hạn mức:

Service Quotas API (GetServiceQuota, ListServiceQuotas)
        ↓
    Trả về: "hạn mức vCPU của bạn là 1.000"
    KHÔNG trả về: "bạn đang dùng 850"
        ↓
Trusted Advisor — nhóm kiểm tra Service Limits
        ↓
    Trả về CẢ hạn mức LẪN mức đang dùng, cho nhiều dịch vụ
        ↓
    → tính được phần trăm tận dụng, thứ mà đề yêu cầu

Đây là điểm phân biệt cốt lõi giữa phương án B và hai phương án dùng Service Quotas API.

import boto3
support = boto3.client('support', region_name='us-east-1')  # chỉ có ở us-east-1

def handler(su_kien, ngu_canh):
    support.refresh_trusted_advisor_check(checkId='eW7HH0l7J9')  # Service Limits
    kq = support.describe_trusted_advisor_check_result(checkId='eW7HH0l7J9')
    for tai_nguyen in kq['result']['flaggedResources']:
        vung, dich_vu, ten, han_muc, dang_dung, trang_thai = tai_nguyen['metadata'][:6]
        if han_muc and dang_dung and float(dang_dung) / float(han_muc) > 0.8:
            canh_bao(vung, dich_vu, ten, dang_dung, han_muc)

⚠ API của Trusted Advisor chỉ có ở us-east-1 và đòi gói hỗ trợ Business trở lên:

Gọi từ Region khác → endpoint không tồn tại
Gói Developer hoặc Basic → không truy cập được nhóm kiểm tra Service Limits
        ↓
    → hai điều kiện này phải kiểm trước khi thiết kế giải pháp

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

• D (EventBridge rule kích hoạt Lambda dùng Trusted Advisor — đúng; nhưng dùng AWS Budgets để gửi cảnh báo) — đây là phương án gần nhất và nó chỉ khác B ở kênh cảnh báo. Nhưng AWS Budgets theo dõi CHI PHÍ và LƯỢNG DÙNG dịch vụ, không theo dõi hạn mức; nó không nhận được đầu vào từ một hàm Lambda và không có cách nào để hàm đó "dùng Budgets gửi alert". Kênh đúng để một Lambda phát cảnh báo là SNS. Đây là bẫy kiểm tra xem có phân biệt được vai trò của Budgets hay không.

• A (scheduled Config rule kích hoạt Lambda gọi GetServiceQuota) — hai vấn đề. GetServiceQuota chỉ trả về giá trị hạn mức, không trả về mức đang dùng — nên không tính được phần trăm tận dụng. Và AWS Config không phải bộ lập lịch: Config rule đánh giá theo thay đổi cấu hình hoặc theo chu kỳ định sẵn của Config (tối thiểu 1 giờ với periodic rule), không phải công cụ để chạy một việc mỗi 15 phút — đó là việc của EventBridge.

• C (scheduled Config rule kích hoạt Lambda gọi ListServiceQuotas) — cùng hai lỗi như A. ListServiceQuotas liệt kê hạn mức của một dịch vụ, vẫn không kèm mức đang dùng.

Ghi nhớ

⚠ Bốn nguồn dữ liệu về hạn mức — bảng phải thuộc: | Nguồn | Cho biết | |---|---| | Trusted Advisor (Service Limits) | hạn mức VÀ mức đang dùng | | Service Quotas API | chỉ hạn mức, và giá trị mặc định | | CloudWatch usage metrics | mức đang dùng cho một số dịch vụ, đặt alarm được | | Cost Explorer | chi phí, không phải hạn mức |

Từ khoá nhận diện:

"monitor quota utilization" → Trusted Advisor "every 15 minutes" → EventBridge scheduled rule "GetServiceQuota để biết mức tận dụng" → SAI, chỉ trả về hạn mức "AWS Config làm bộ lập lịch 15 phút" → SAI, Config không phải scheduler "Budgets để gửi cảnh báo từ Lambda" → SAI, kênh đúng là SNS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm có đọc được dữ liệu không | chạy thử và in kết quả check | | Cảnh báo có tới không | hạ tạm ngưỡng xuống 1% | | Quota nào đang gần trần | mở trang Trusted Advisor, nhóm Service Limits |

Và một lời khuyên: hãy xin nâng hạn mức ngay khi chạm 80%, đừng chờ tới lúc chạm trần. Đây chính là lý do ngưỡng 80% được chọn trong đề: quy trình nâng hạn mức không tức thời — với các quota lớn, nó cần AWS Support xem xét và có thể mất từ vài giờ tới vài ngày. Nếu bạn chỉ phát hiện khi đã chạm 100%, đội vận hành ở Region đó đã không triển khai được gì rồi, và thời gian chờ phê duyệt trở thành thời gian ngừng trệ. Con số 80% không phải mức nguy hiểm — nó là mức cho bạn đủ thời gian xử lý trước khi nguy hiểm tới.

Đáp án

D — Triển khai AWS Application Discovery Service với việc cài data collection agent trên từng máy chủ trong trung tâm dữ liệu để thu thập dữ liệu sử dụng chi tiết và dữ liệu mạng.

Vì sao đúng

Đề liệt kê bốn loại dữ liệu cần thu thập, và hai trong số đó chỉ agent mới lấy được.

⚠ Điểm mấu chốt: Agentless Connector chỉ hỏi vCenter — nó không nhìn được vào bên trong hệ điều hành:

Agentless Discovery Connector
        ↓
    Là một máy ảo cắm vào vCenter, đọc API của VMware
        ↓
    Thấy: máy ảo nào tồn tại, cấp bao nhiêu CPU/RAM, dùng bao nhiêu
    KHÔNG thấy: tiến trình nào đang chạy, cổng nào đang mở, nối tới máy nào
        ↓
Discovery Agent — chạy TRONG hệ điều hành
        ↓
    Đọc bảng tiến trình và bảng kết nối TCP
        ↓
    → đây là nguồn duy nhất cho "active services" và "dependencies"

Đề nêu cả hai thứ đó, nên agent là bắt buộc.

# xem những gì đã phát hiện
aws discovery describe-configurations --configuration-ids <id>

# gom thành ứng dụng để lập kế hoạch di chuyển theo cụm
aws discovery create-application --name "He thong xu ly du lieu"

⚠ Phải để agent chạy đủ lâu để phủ ít nhất một chu kỳ nghiệp vụ:

Thu thập một tuần
        ↓
    Bỏ sót job cuối tháng, báo cáo cuối quý, đỉnh theo mùa
        ↓
    → right-size theo dữ liệu thiếu → máy chọn quá nhỏ
    → và bỏ sót một phụ thuộc chỉ xuất hiện khi job định kỳ chạy

Vì sao đây cũng là phương án tiết kiệm nhất. Application Discovery Service miễn phí — bạn chỉ trả tiền cho việc lưu trữ dữ liệu thu thập. So với việc dựng hạ tầng giám sát riêng, chi phí gần như bằng không.

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

• C (Application Discovery Service với agentless discovery cấu hình trong môi trường ảo hoá) — đây là phương án gần nhất và nó dùng đúng dịch vụ, và agentless là lựa chọn ít công cài đặt nhất. Nhưng nó không thu được hai loại dữ liệu quan trọng nhất của đề: danh sách dịch vụ đang chạy và mẫu lưu lượng mạng để hiểu phụ thuộc. Đề nêu chúng một cách tường minh, nên agentless là thiếu. Đây là bẫy thưởng cho người biết agentless tồn tại rồi phạt vì không đối chiếu với danh sách dữ liệu cần.

• A (kích hoạt Application Discovery Service qua console và dựng network traffic mirroring để phân tích giao tiếp giữa các máy) — traffic mirroring là tính năng của VPC, dùng để nhân bản lưu lượng của ENI trong AWS sang một thiết bị phân tích. Nó không áp dụng cho máy chủ tại chỗ. Ngoài ra, ngay cả khi làm được, phân tích gói tin thô là cách rất tốn kém để suy ra phụ thuộc, trong khi agent đã cung cấp sẵn danh sách kết nối.

• B (cài CloudWatch agent trên mọi máy tại chỗ, gửi số liệu về CloudWatch) — thu được số liệu hiệu năng nhưng không thu được phụ thuộc giữa các máy, và không tích hợp với Migration Hub nên không dùng để lập kế hoạch di chuyển theo ứng dụng. Nó cũng tốn tiền: CloudWatch tính phí theo custom metric và theo lượng log, nhân với số máy chủ — trong khi Discovery Service miễn phí.

Ghi nhớ

⚠ Hai chế độ của Application Discovery Service — bảng phải thuộc: | | Agentless Connector | Discovery Agent | |---|---|---| | Cài ở đâu | máy ảo cắm vào vCenter | trong hệ điều hành | | Chỉ dùng với | VMware | mọi thứ: vật lý, Hyper-V, VMware | | Tiến trình và dịch vụ | không | có | | Phụ thuộc mạng | không | có | | Công cài | một lần | từng máy |

Từ khoá nhận diện:

"list of active services" → bắt buộc có agent "dependencies between servers" → bắt buộc có agent "chỉ cần CPU, RAM, kho máy" → agentless là đủ và nhanh hơn "traffic mirroring" cho máy tại chỗ → SAI, đó là tính năng VPC "CloudWatch agent" để lập kế hoạch di chuyển → thiếu phụ thuộc, và tốn tiền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent có báo về không | aws discovery describe-agents, xem health | | Có dữ liệu phụ thuộc chưa | mở đồ thị Network Connections của một máy bạn biết rõ | | Đã đủ thời gian chưa | so khoảng thu thập với chu kỳ nghiệp vụ dài nhất |

Và một lời khuyên: hãy mở đồ thị phụ thuộc của một máy chủ mà bạn đã biết rõ nó nói chuyện với ai, và kiểm xem công cụ có thấy đúng như vậy không. Đây là phép thử duy nhất phân biệt giữa "dữ liệu đã thu đầy đủ" và "dữ liệu trông có vẻ đầy đủ": nếu một số agent không cài được, hoặc bị tường lửa chặn không báo về, Migration Hub vẫn hiển thị một danh sách máy chủ mạch lạc với đồ thị phụ thuộc trông hợp lý — chỉ là thiếu đúng những kết nối đi tới các máy chưa được khảo sát. Không có màn hình nào cảnh báo về những phụ thuộc mà công cụ không biết, và kế hoạch di chuyển sẽ được lập trên bức tranh thiếu đó.

Đáp án

B, C — hai thứ cần kiểm khi CloudFront trả về 403 với origin là S3 website endpoint:

• B — Kiểm xem tuỳ chọn Block Public Access có đang bật trên bucket không.
• C — Kiểm xem bucket có đang mã hoá bằng AWS KMS không.

Vì sao đúng

Đề có một chi tiết quyết định: origin là S3 website endpoint, không phải REST endpoint. Điều đó thay đổi hoàn toàn cách xác thực hoạt động.

⚠ Điểm mấu chốt: S3 website endpoint KHÔNG hỗ trợ OAI/OAC — nên bucket bắt buộc phải công khai:

S3 REST endpoint (bucket.s3.amazonaws.com)
        ↓
    Hỗ trợ OAC/OAI → bucket giữ riêng tư
        ↓
S3 website endpoint (bucket.s3-website-region.amazonaws.com)
        ↓
    KHÔNG hỗ trợ OAC/OAI — CloudFront gọi tới như một khách ẩn danh
        ↓
    → Block Public Access bật là chặn luôn CloudFront

Đây là lý do phương án B là một trong hai đáp án: với kiến trúc này, Block Public Access chính là thứ gây ra 403.

Vì sao mã hoá KMS cũng gây 403 (C). Khi object được mã hoá bằng SSE-KMS, người đọc cần quyền kms:Decrypt. Một request ẩn danh không có danh tính nào để được cấp quyền đó:

Request ẩn danh tới object mã hoá bằng SSE-KMS
        ↓
    S3 cần gọi KMS để giải mã
        ↓
    Không có principal nào để KMS đánh giá quyền
        ↓
    → 403, và thông báo không nói rõ nguyên nhân nằm ở KMS

Vì thế nội dung phục vụ công khai không dùng được SSE-KMS — chỉ SSE-S3.

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

• A (kiểm xem object lock có bật cho các object trong bucket không) — đây là phương án gần nhất trong số các phương án còn lại vì nó nhắc tới một tính năng bảo vệ có thật. Nhưng Object Lock chặn việc XOÁ và GHI ĐÈ, không chặn việc đọc. Nó phục vụ yêu cầu tuân thủ kiểu WORM (ghi một lần, đọc nhiều lần), và một object bị khoá vẫn đọc được bình thường. Nó không thể là nguyên nhân của lỗi 403 khi tải nội dung.

• D (kiểm xem storage class của object có phải S3 Standard không) — lớp lưu trữ không gây 403. Nếu object nằm trong Glacier Flexible Retrieval thì lỗi sẽ là InvalidObjectState với thông báo rõ ràng về việc cần khôi phục, không phải Access Denied.

• E (kiểm trạng thái versioning của object) — versioning không ảnh hưởng tới quyền đọc phiên bản hiện hành. Nếu phiên bản mới nhất là một delete marker thì lỗi sẽ là 404 Not Found, không phải 403.

Ghi nhớ

⚠ Hai loại endpoint của S3 — bảng phải thuộc, đây là gốc của câu hỏi: | | REST endpoint | Website endpoint | |---|---|---| | Địa chỉ | bucket.s3.region.amazonaws.com | bucket.s3-website-region.amazonaws.com | | OAC / OAI | hỗ trợ | KHÔNG hỗ trợ | | Bucket riêng tư | được | phải công khai | | Trang index và error tuỳ chỉnh | không | có | | HTTPS | có | không (chỉ HTTP) | | Chuyển hướng | không | có |

Từ khoá nhận diện:

"S3 website endpoint" + 403 → Block Public Access, hoặc SSE-KMS "S3 REST endpoint" + 403 → thiếu OAC/OAI trong bucket policy, hoặc thiếu kms:Decrypt "Object Lock" gây lỗi đọc → SAI, nó chặn xoá và ghi đè Glacier → InvalidObjectState, không phải 403 delete marker → 404, không phải 403

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket có công khai được không | tab Access trong console, hoặc get-public-access-block | | Object mã hoá bằng gì | head-object, xem ServerSideEncryption | | Lỗi đến từ đâu | thử curl thẳng vào website endpoint, bỏ qua CloudFront |

Và một lời khuyên: hãy curl thẳng vào S3 website endpoint khi gặp 403, trước khi động vào cấu hình CloudFront. Đây là cách tách bạch hai lớp trong một phút: nếu website endpoint cũng trả 403 thì vấn đề nằm hoàn toàn ở S3 — quyền công khai hoặc mã hoá — và mọi thời gian bỏ ra để rà soát behavior, origin setting hay cache policy của CloudFront đều là lãng phí. Nếu website endpoint trả về 200 mà qua CloudFront vẫn 403, lúc đó mới đáng đi tìm ở tầng phân phối. Phần lớn các cuộc điều tra loại này đi ngược thứ tự đó và mất nhiều giờ ở sai lớp.