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

Đáp án

C — Bật tính năng GEO RESTRICTION trong CloudFront distribution và tạo danh sách chặn các quốc gia bị cấm.

Vì sao đúng

Đề nhấn mạnh "tiết kiệm chi phí nhất", và geo restriction của CloudFront là tính năng có sẵn, MIỄN PHÍ.

⚠ Điểm mấu chốt — chặn ngay tại edge, không tốn thêm gì:

CloudFront geo restriction
        ↓
    Xác định quốc gia từ IP người dùng
      (CSDL địa lý IP của AWS)
        ↓
    Danh sách CHẶN (blacklist) hoặc
    danh sách CHO PHÉP (whitelist)
        ↓
    Người dùng bị chặn → nhận 403 NGAY TẠI EDGE
        ↓
    → nội dung KHÔNG bao giờ được lấy từ origin
    → không tốn phí origin, không tốn dữ liệu ra
    → và bản thân tính năng KHÔNG TÍNH PHÍ

⚠ Cấu hình rất đơn giản:

CloudFront distribution → Restrictions
        ↓
    Geographic restrictions
      → Restriction type: Blacklist
      → chọn các quốc gia bị cấm
        ↓
    Hoặc Whitelist nếu chỉ cho phép vài nước
        ↓
    Tuỳ biến trang lỗi:
      Custom error response cho mã 403
      → hiện thông báo thân thiện thay vì trang trắng

Xem thêm câu #11913 (cùng lô): cùng bài toán chặn theo quốc gia, nhưng ở đó đề yêu cầu chọn HAI biện pháp nên đáp án gồm cả Route 53 geolocation. Ở đây đề đòi tiết kiệm nhất nên chỉ cần CloudFront geo restriction — khoá nhất quán, ràng buộc trong đề khác nhau.

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

• D (Route 53 geolocation routing, đưa lưu lượng từ nước bị cấm tới một website EC2 trả 403) — đây là phương án gần nhất và thực sự chạy được, nhưng nó tốn tiền: phải chạy thêm một máy EC2 (hoặc cả một ASG) chỉ để trả về mã 403. Trái thẳng yêu cầu "tiết kiệm nhất". (Và định tuyến theo resolver cũng kém chính xác hơn.)

• B (Network ACL với luật deny theo địa chỉ IP của các nước bị cấm) — bất khả thi trong thực tế: dải IP của một quốc gia gồm hàng nghìn khối CIDR và thay đổi liên tục, trong khi NACL chỉ chứa được một số luật giới hạn. Và NACL nằm trong VPC, không áp cho lưu lượng tới CloudFront.

• A (tạo OAI thứ hai và dùng bucket policy chặn truy cập từ nước không được phép) — bucket policy không có điều kiện theo quốc gia, và OAI dùng để CloudFront truy cập bucket riêng tư, không liên quan tới việc chặn người dùng cuối.

Ghi nhớ

⚠ Các cách chặn theo quốc gia — bảng phải thuộc: | Cách | Chi phí | Đặc điểm | |---|---|---| | CloudFront geo restriction | MIỄN PHÍ | allow/block theo quốc gia, trả 403 tại edge | | WAF geo match rule | có phí | linh hoạt: kết hợp với đường dẫn, rate limit, ngoại lệ | | Route 53 geolocation | phí truy vấn | theo resolver, kém chính xác hơn | | Security group / NACL | — | chỉ theo CIDR — không khả thi | | Xác thực người dùng | tuỳ ứng dụng | chính xác nhất, VPN không vượt được |

Từ khoá nhận diện:

"chặn theo quốc gia, tiết kiệm nhất" → CloudFront geo restriction "chặn theo quốc gia có ngoại lệ" → WAF geo match rule "hướng người dùng theo vùng (không chặn)" → Route 53 geolocation "chống DDoS" → Shield "chỉ người đã trả tiền mới xem được" → signed URL / signed cookie

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chặn có hiệu lực không | kiểm tra từ IP ở quốc gia bị chặn — phải nhận 403 | | Cấu hình hiện tại | get-distribution-config → Restrictions | | Ai bị chặn | CloudFront access log, cột x-edge-result-type |

Và một lưu ý về độ chính xác nên trao đổi trước với bộ phận pháp lý: CSDL địa lý IP không hoàn hảo. Sẽ có một tỉ lệ nhỏ người dùng hợp lệ bị chặn nhầm và một tỉ lệ nhỏ người dùng ở nước bị cấm lọt qua — nên nếu hợp đồng bản quyền đòi hỏi mức bảo đảm chặt chẽ hơn, cần bổ sung một lớp xác thực tài khoản, và điều đó nên được thống nhất trước khi hệ thống lên production.

Đáp án

B — BẬT ALL FEATURES cho tổ chức.

Vì sao đúng

Tag policy là một tính năng thuộc nhóm quản trị nâng cao, và nhóm đó chỉ dùng được khi tổ chức ở chế độ all features.

⚠ Điểm mấu chốt — Organizations có HAI chế độ:

CONSOLIDATED BILLING ONLY
        ↓
    Chỉ gộp hoá đơn
        ↓
    KHÔNG dùng được:
      - Service Control Policy (SCP)
      - Tag Policy
      - Backup Policy
      - AI services opt-out policy
      - trusted access với nhiều dịch vụ

ALL FEATURES  ← cần cho tag policy
        ↓
    Toàn bộ khả năng quản trị
        ↓
    → tag policy hiện ra và bật được

⚠ Chuyển lên all features cần sự ĐỒNG Ý của mọi thành viên:

Tài khoản quản lý gửi yêu cầu
        ↓
    enable-all-features
        ↓
    MỌI tài khoản thành viên nhận một handshake
        ↓
    Từng tài khoản phải CHẤP NHẬN
        ↓
    Đủ hết → tổ chức chuyển sang all features
        ↓
    → không hoàn tác được
    → và đây là lý do việc này mất thời gian

⚠ Tag policy làm gì:

Chuẩn hoá TAG trên toàn tổ chức
        ↓
    - Khai KHOÁ tag hợp lệ (viết hoa/thường ra sao)
    - Khai GIÁ TRỊ hợp lệ cho từng khoá
    - Khai loại tài nguyên nào bắt buộc tuân thủ
        ↓
    Chế độ:
      Chỉ BÁO CÁO (mặc định) — thấy vi phạm
      Hoặc ÉP TUÂN THỦ cho một số loại tài nguyên
        ↓
    → khác SCP: SCP CHẶN hành động,
      tag policy chuẩn hoá ĐỊNH DẠNG

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

• D (bật SCP trước) — đây là phương án gần nhất vì SCP cũng nằm trong nhóm tính năng nâng cao, nhưng SCP không phải điều kiện tiên quyết của tag policy. Cả hai đều đòi all features — và đó mới là thứ cần bật.

• A (bật consolidated billing cho tổ chức) — consolidated billing là chế độ THẤP HƠN, đã bật sẵn. Nó chính là chế độ đang chặn tag policy.

• C (đăng nhập từng tài khoản thành viên để bật tag policy) — tag policy chỉ quản lý từ tài khoản QUẢN LÝ; thành viên không bật được.

Ghi nhớ

⚠ Hai chế độ của Organizations — bảng phải thuộc: | | Consolidated billing only | All features | |---|---|---| | Gộp hoá đơn | có | có | | SCP | KHÔNG | CÓ | | Tag Policy | KHÔNG | CÓ | | Backup Policy | không | có | | Trusted access nhiều dịch vụ | hạn chế | đầy đủ | | Chuyển lên | cần MỌI thành viên đồng ý | không hoàn tác được | | Mặc định khi tạo mới | all features | |

Từ khoá nhận diện:

"không bật được tag policy / SCP" → tổ chức chưa ở all features "chuẩn hoá định dạng tag" → Tag Policy "CHẶN tạo tài nguyên thiếu tag" → SCP với aws:RequestTag "phát hiện tài nguyên thiếu tag" → Config rule required-tags "chia chi phí theo tag" → kích hoạt cost allocation tag ở tài khoản quản lý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức đang ở chế độ nào | describe-organization → FeatureSet | | Còn ai chưa đồng ý | list-handshakes-for-organization | | Tag policy đã bật chưa | list-roots → xem PolicyTypes |

Và một việc rất nên làm ngay sau khi bật all features: bật cả tag policy lẫn SCP cùng lúc. Hai cơ chế này bổ sung nhau — SCP bảo đảm không ai tạo được tài nguyên thiếu tag, còn tag policy bảo đảm những tag được gắn đều đúng định dạng — và triển khai chúng cùng một đợt sẽ tránh được tình trạng nửa vời, nơi mọi tài nguyên đều có tag nhưng mỗi đội viết hoa một kiểu.

Đáp án

A — Lưu nội dung trong bucket S3 đã tắt truy cập công khai; tạo CloudFront distribution dùng ORIGIN ACCESS IDENTITY (OAI) để đọc bucket; dùng CLOUDFRONT SIGNED URL để giới hạn người dùng được phép.

Vì sao đúng

Đề đòi hai thứ: cache toàn cầu và chỉ người được uỷ quyền mới xem được. Phương án A ghép đúng ba mảnh.

⚠ Mảnh thứ nhất — cache toàn cầu là CloudFront:

CloudFront
        ↓
    Cache ở hơn 400 điểm hiện diện
        ↓
    → đúng yêu cầu "caching content globally"

⚠ Mảnh thứ hai — bucket phải RIÊNG TƯ:

Block Public Access bật + OAI (hoặc OAC)
        ↓
    CloudFront được cấp quyền đọc bucket
    qua bucket policy
        ↓
    → không ai gọi thẳng S3 được
    → mọi đường vào đều qua CloudFront

⚠ Mảnh thứ ba — và đây là điểm phân biệt QUAN TRỌNG NHẤT:

Phải dùng CLOUDFRONT SIGNED URL,
KHÔNG phải S3 PRESIGNED URL
        ↓
    S3 presigned URL trỏ THẲNG tới S3
        ↓
    → BỎ QUA CloudFront hoàn toàn
    → mất cache, mất tăng tốc toàn cầu
    → và bucket đang riêng tư nên
      cũng không hợp với kiến trúc này
        ↓
    CloudFront signed URL
        ↓
    → người dùng vẫn đi qua edge
    → vẫn hưởng cache
    → CloudFront kiểm chữ ký trước khi phục vụ

⚠ Signed URL hoạt động thế nào:

Tạo một KEY GROUP với public key trong CloudFront
        ↓
    Ứng dụng dùng PRIVATE KEY để ký URL
        ↓
    URL chứa:  Policy, Signature, Key-Pair-Id
        ↓
    Chính sách khai được:
      - thời hạn hết hiệu lực
      - thời điểm bắt đầu có hiệu lực
      - dải IP được phép
        ↓
    CloudFront kiểm chữ ký TẠI EDGE
    → hợp lệ thì phục vụ, không thì 403

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

• B (cùng kiến trúc nhưng dùng S3 PRESIGNED URL) — đây là phương án gần nhất và chỉ sai một chi tiết, nhưng chi tiết đó phá vỡ cả kiến trúc: presigned URL trỏ thẳng tới S3, nên người dùng không đi qua CloudFront — mất toàn bộ lợi ích cache toàn cầu mà đề yêu cầu.

• C (tạo IAM role có quyền vào bucket rồi gán cho CloudFront distribution) — CloudFront không nhận IAM role. Nó truy cập bucket riêng tư bằng OAC hoặc OAI, được cấp quyền qua bucket policy.

• D (bucket CÔNG KHAI, bật field-level encryption, dùng S3 presigned URL) — sai nhiều chỗ: bucket công khai thì presigned URL vô nghĩa (ai cũng vào được), và field-level encryption dùng để bảo vệ dữ liệu người dùng GỬI LÊN, không liên quan tới việc giới hạn truy cập.

Ghi nhớ

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

Phương án đúng dùng Origin Access Identity (OAI), là cơ chế cũ. AWS hiện khuyến nghị Origin Access Control (OAC) cho mọi distribution mới: OAC hỗ trợ SSE-KMS, hỗ trợ mọi Region, và xử lý được cả PUT/DELETE — những thứ OAI không làm được.

Khoá đáp án không đổi: OAI vẫn hoạt động, vẫn giữ được bucket riêng tư, và trong bốn lựa chọn thì A vẫn là phương án duy nhất đúng về mặt kiến trúc. Nhưng khi triển khai thật hôm nay, hãy dùng OAC; và khi gặp đề nhắc tới OAI, hãy hiểu đó là cách diễn đạt theo tài liệu cũ.

⚠ CloudFront signed URL ↔ S3 presigned URL — bảng phải thuộc: | | CloudFront signed URL | S3 presigned URL | |---|---|---| | Đi qua CloudFront | CÓ — vẫn hưởng cache | KHÔNG — thẳng tới S3 | | Ai ký | private key của key group | thông tin xác thực IAM | | Điều kiện khai được | thời hạn, thời điểm bắt đầu, dải IP | thời hạn | | Dùng khi | phân phối toàn cầu có kiểm soát | tải lên/xuống một lần, nội bộ | | Nhiều tệp | signed COOKIE tiện hơn | phải ký từng URL |

Từ khoá nhận diện:

"cache toàn cầu + chỉ người được phép" → CloudFront + OAC/OAI + signed URL "cho phép tải lên một tệp trong 15 phút" → S3 presigned URL "nhiều tệp, cả một thư mục" → CloudFront signed COOKIE "bucket phải riêng tư" → OAC + Block Public Access "chặn theo quốc gia" → geo restriction

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi thẳng S3 có được không | mở URL của bucket — phải nhận 403 | | URL chưa ký có vào được không | gọi CloudFront không kèm chữ ký — phải 403 | | Chữ ký có hết hạn đúng không | thử URL sau thời điểm Expires |

Và một điều nên nghĩ tới ngay khi thiết kế: thời hạn của signed URL nên đủ ngắn nhưng phải dài hơn thời gian tải xong tệp. Với một video vài trăm megabyte trên đường truyền chậm, một URL hết hạn sau năm phút sẽ khiến người dùng bị ngắt giữa chừng — và triệu chứng đó chỉ xuất hiện với đúng nhóm người dùng có kết nối yếu nhất, tức là nhóm khó tái hiện lỗi nhất.

Đáp án

B — Thêm tuyến cho 0.0.0.0/0 trỏ tới INTERNET GATEWAY.

Vì sao đúng

Route table trong đề đã có hai mục, nhưng thiếu đúng mục cho phép đi ra internet.

⚠ Điểm mấu chốt — đọc route table đã cho:

Destination        Target
10.0.0.0/16        Local              ← trong VPC
172.31.0.0/16      pcx-123456123456   ← VPC peering
        ↓
    KHÔNG có tuyến 0.0.0.0/0
        ↓
    → mọi đích ngoài hai dải trên
      đều KHÔNG BIẾT ĐI ĐÂU
    → gói tin bị bỏ
        ↓
    → subnet này là PRIVATE

⚠ Và đề đã cho sẵn hai điều kiện còn lại:

"subnet is configured to auto assign public IP"
        ↓
    → máy CÓ IP công cộng ✓

"must be directly accessible from the internet"
        ↓
    → cần cả chiều VÀO
    → chỉ IGW làm được
        ↓
    Thiếu duy nhất: tuyến 0.0.0.0/0 → igw-xxxxx

⚠ Vì sao NAT Gateway không đúng ở đây:

NAT Gateway
        ↓
    Cho máy đi RA internet
    Chặn hoàn toàn chiều VÀO
        ↓
    Đề: "directly accessible FROM the internet"
        ↓
    → NAT không thoả
        ↓
    Và IP công cộng của máy cũng
    trở thành vô dụng khi đi qua NAT

Xem thêm câu #11862 (lô 128) và #11915 (cùng lô): cùng chủ đề — public subnet cần IGW gắn vào VPC và tuyến 0.0.0.0/0 trong route table. Khoá nhất quán ở cả ba câu.

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

• D (tuyến 0.0.0.0/0 trỏ tới NAT gateway) — đây là phương án gần nhất và cho phép đi RA internet thật, nhưng chặn chiều VÀO — trái yêu cầu "truy cập trực tiếp từ internet".

• A (tuyến 0.0.0.0/0 trỏ tới egress-only internet gateway) — egress-only IGW CHỈ dùng cho IPv6 và chỉ một chiều ra. Đề nói tới IPv4 và cần cả hai chiều. (Với IPv6 thì đích phải là ::/0, không phải 0.0.0.0/0.)

• C (tuyến 0.0.0.0/0 trỏ tới một elastic network interface) — về kỹ thuật thì trỏ tuyến tới ENI được, nhưng đó là mô hình của NAT instance hoặc thiết bị mạng tự dựng, và bản thân ENI đó cũng phải nằm ở một subnet có đường ra internet. Không phải câu trả lời cho một website cần truy cập trực tiếp.

Ghi nhớ

⚠ Các target hợp lệ của một tuyến — bảng phải thuộc: | Target | Việc | |---|---| | local | trong VPC — tự có, không xoá được | | Internet Gateway (igw-) | ra và vào internet, IPv4 + IPv6 | | NAT Gateway (nat-) | chỉ ra, IPv4 | | Egress-only IGW (eigw-) | chỉ ra, CHỈ IPv6 | | VPC Peering (pcx-) | sang VPC khác | | Transit Gateway (tgw-) | trung tâm kết nối nhiều VPC/VPN | | VPC Endpoint (vpce-) | tới S3/DynamoDB (gateway endpoint) | | Virtual Private Gateway (vgw-) | VPN / Direct Connect | | ENI (eni-) | NAT instance, thiết bị mạng tự dựng |

Từ khoá nhận diện:

"truy cập trực tiếp từ internet" → IGW "ra được nhưng không ai vào được" → NAT Gateway "IPv6, chỉ ra" → egress-only IGW, đích ::/0 "sang VPC khác" → peering hoặc Transit Gateway "tới S3 không qua internet" → gateway endpoint

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Route table hiện tại | describe-route-tables --route-table-ids rtb-xxx | | IGW đã gắn chưa | describe-internet-gateways | | Máy có IP công cộng không | describe-instances --query '...PublicIpAddress' |

Và một thói quen đáng có khi chẩn đoán mạng VPC: đọc route table trước tiên, trước cả security group. Route table quyết định gói tin có đường đi hay không — nếu không có đường thì mọi luật security group đều vô nghĩa, và triệu chứng timeout sẽ giống hệt như khi bị firewall chặn, dẫn người gỡ lỗi đi lạc rất lâu.

Đáp án

D — Tạo IAM policy CHỈ ĐỌC với tài nguyên EC2 trong mỗi tài khoản development, gắn vào một CROSS-ACCOUNT IAM ROLE, và để đội bảo mật ĐẢM NHẬN role đó từ tài khoản của họ.

Vì sao đúng

Phương án D là phương án duy nhất đúng cả hai nguyên tắc bảo mật mà câu hỏi đang kiểm tra.

⚠ Nguyên tắc thứ nhất — QUYỀN TỐI THIỂU:

Đội bảo mật cần "REVIEW cấu hình"
        ↓
    → chỉ cần ĐỌC
    → không cần tạo, sửa, xoá gì
        ↓
    Chính sách: ReadOnlyAccess giới hạn ở EC2
      ec2:Describe*, ec2:Get*
        ↓
    → cấp quyền quản trị là thừa và nguy hiểm

⚠ Nguyên tắc thứ hai — DÙNG ROLE, KHÔNG CHIA SẺ KHOÁ:

Chia sẻ thông tin đăng nhập của IAM user
        ↓
    → khoá dài hạn, không tự hết hạn
    → không biết AI trong đội đã dùng
      (CloudTrail chỉ thấy một danh tính chung)
    → có người nghỉ việc → phải xoay khoá tay
    → khoá bị lộ là dùng được mãi
        ↓
CROSS-ACCOUNT ROLE
        ↓
    Đội bảo mật đăng nhập bằng danh tính CỦA HỌ
    rồi AssumeRole sang tài khoản development
        ↓
    → STS cấp thông tin TẠM THỜI (mặc định 1 giờ)
    → CloudTrail ghi rõ TỪNG NGƯỜI đã assume
    → thu hồi = sửa trust policy, tức thì
    → ép được MFA trong trust policy

⚠ Trust policy nên viết thế nào:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::<tai-khoan-bao-mat>:root"
  },
  "Action": "sts:AssumeRole",
  "Condition": {
    "Bool": { "aws:MultiFactorAuthPresent": "true" },
    "StringEquals": { "sts:ExternalId": "..." }
  }
}

    MFA bắt buộc  → thêm một lớp bảo vệ
    ExternalId    → dùng khi bên thứ ba truy cập
                    (chống confused deputy)

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

• C (chính sách QUẢN TRỊ EC2 gắn vào cross-account role) — đây là phương án gần nhất và dùng đúng cơ chế role, nhưng cấp quyền quản trị cho một việc chỉ cần đọc. Vi phạm quyền tối thiểu: một sai sót hoặc một tài khoản bị chiếm có thể xoá máy ở mọi tài khoản development.

• A (chính sách chỉ đọc gắn vào IAM USER, chia sẻ thông tin đăng nhập) — quyền thì đúng nhưng cơ chế sai: chia sẻ khoá dài hạn giữa nhiều người là điều nên tránh tuyệt đối.

• B (quyền quản trị + chia sẻ thông tin đăng nhập của IAM user) — sai cả hai vế, tệ nhất trong bốn phương án.

Ghi nhớ

⚠ Truy cập liên tài khoản — bảng phải thuộc: | Cách | Đánh giá | |---|---| | Cross-account IAM role + AssumeRole | ĐÚNG — khoá tạm thời, ghi log theo từng người | | IAM Identity Center với permission set | tốt hơn nữa khi có nhiều tài khoản | | IAM user + chia sẻ khoá | KHÔNG BAO GIỜ | | Resource policy | dùng cho bucket, KMS key, SQS — không thay role |

Từ khoá nhận diện:

"truy cập tài khoản khác" → cross-account role + AssumeRole "an toàn NHẤT" → role + quyền tối thiểu + MFA "nhiều tài khoản, nhiều người" → IAM Identity Center "bên thứ ba truy cập" → role + sts:ExternalId "chia sẻ access key" → luôn SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đã assume role | CloudTrail, tìm AssumeRole — thấy rõ từng người | | Role có đủ/thừa quyền không | IAM Access Advisor | | Trust policy đúng chưa | get-role --role-name ... → đọc AssumeRolePolicyDocument |

Và một cải tiến rất đáng cân nhắc cho chính tình huống này: AWS Config aggregator. Nếu mục đích của đội bảo mật là rà soát cấu hình có tuân thủ hay không, họ có thể xem toàn bộ tài nguyên EC2 của mọi tài khoản từ một màn hình duy nhất mà không cần assume role vào từng tài khoản — nhanh hơn nhiều, và cũng ít bề mặt quyền hơn.

Đáp án

C — Yêu cầu chứng chỉ CÔNG KHAI qua AWS Certificate Manager (ACM) và dùng XÁC THỰC BẰNG DNS. ACM sẽ tự động gia hạn.

Vì sao đúng

Đề đòi tự động gia hạn với cách hiệu quả nhất, và chỉ tổ hợp "công khai + DNS validation" cho ra điều đó.

⚠ Điểm mấu chốt thứ nhất — vì sao phải là chứng chỉ CÔNG KHAI:

Ứng dụng HƯỚNG RA INTERNET
        ↓
    Trình duyệt người dùng phải TIN chứng chỉ
        ↓
    → cần chứng chỉ do một CA công cộng ký
        ↓
    Chứng chỉ RIÊNG (private CA)
        ↓
    → trình duyệt KHÔNG tin
    → hiện cảnh báo bảo mật
    → chỉ dùng cho nội bộ, nơi máy client
      đã cài CA gốc của công ty

⚠ Điểm mấu chốt thứ hai — DNS validation TỰ GIA HẠN được, EMAIL thì không:

DNS VALIDATION
        ↓
    Thêm một bản ghi CNAME vào hosted zone
        ↓
    Bản ghi đó nằm lại VĨNH VIỄN
        ↓
    → ACM tự kiểm tra lại khi tới hạn gia hạn
    → GIA HẠN HOÀN TOÀN TỰ ĐỘNG, không ai phải làm gì
        ↓
EMAIL VALIDATION
        ↓
    ACM gửi thư tới địa chỉ quản trị của tên miền
        ↓
    → PHẢI CÓ NGƯỜI BẤM LINK
    → tại thời điểm cấp, VÀ ở mỗi lần gia hạn
      nếu chứng chỉ không đang được dùng
        ↓
    → không phải "tự động" đúng nghĩa
    → và rất dễ bỏ lỡ thư

⚠ Và ACM còn có một điểm rất đáng nhớ:

Chứng chỉ ACM CÔNG KHAI
        ↓
    MIỄN PHÍ hoàn toàn
        ↓
    Nhưng CHỈ dùng được với các dịch vụ
    tích hợp sẵn:
      ALB / NLB / CloudFront / API Gateway
      Elastic Beanstalk / App Runner
        ↓
    → KHÔNG tải private key về được
    → KHÔNG cài lên EC2 được

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

• A (chứng chỉ công khai + EMAIL validation) — đây là phương án gần nhất và chứng chỉ đúng loại, nhưng email validation cần thao tác thủ công ở mỗi lần gia hạn khi chứng chỉ không đang được sử dụng. Không thoả yêu cầu "tự động gia hạn" một cách đáng tin cậy.

• B (chứng chỉ RIÊNG + DNS validation) — DNS validation thì đúng, nhưng chứng chỉ riêng không được trình duyệt tin. Ứng dụng hướng ra internet sẽ hiện cảnh báo với mọi người dùng.

• D (chứng chỉ công khai + viết Lambda để tự gia hạn) — tự làm lại thứ ACM đã làm sẵn và miễn phí, kèm mã phải bảo trì và một điểm hỏng mới.

Ghi nhớ

⚠ Hai cách xác thực của ACM — bảng phải thuộc: | | DNS validation | Email validation | |---|---|---| | Tự gia hạn | HOÀN TOÀN TỰ ĐỘNG | cần thao tác tay | | Cách xác thực | thêm bản ghi CNAME | bấm link trong thư | | Với Route 53 | ACM tự tạo bản ghi giúp — một cú bấm | — | | Rủi ro | phải giữ nguyên bản ghi CNAME | bỏ lỡ thư là chứng chỉ hết hạn | | Khuyến nghị | LUÔN dùng DNS validation | |

Từ khoá nhận diện:

"tự động gia hạn" → ACM + DNS validation "chứng chỉ cho website công khai" → chứng chỉ CÔNG KHAI, miễn phí "chứng chỉ cho nội bộ, cho IoT" → AWS Private CA "cài chứng chỉ lên EC2" → ACM công khai KHÔNG làm được "chứng chỉ cho CloudFront" → BẮT BUỘC ở Region us-east-1

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chứng chỉ ở trạng thái nào | describe-certificate → Status và RenewalEligibility | | Bản ghi xác thực còn không | dig CNAME <ten-ban-ghi-xac-thuc> | | Sắp hết hạn chưa | EventBridge hoặc alarm trên DaysToExpiry |

Và một cảnh báo rất đáng dựng dù đã dùng DNS validation: EventBridge rule bắt sự kiện chứng chỉ sắp hết hạn. ACM gia hạn tự động trong hầu hết trường hợp, nhưng nếu ai đó lỡ xoá bản ghi CNAME xác thực trong lúc dọn dẹp hosted zone, việc gia hạn sẽ thất bại lặng lẽ — và bạn chỉ biết vào ngày chứng chỉ hết hạn, khi mọi trình duyệt cùng lúc từ chối kết nối.

Đáp án

D — Tạo cụm Amazon Elasticsearch (nay là Amazon OpenSearch Service) và dùng AWS Lambda xử lý dữ liệu từ bucket S3 rồi đẩy vào domain đó.

Vì sao đúng

Đề đòi dịch vụ ĐƯỢC QUẢN LÝ HOÀN TOÀN để tìm kiếm, phân tích log và trực quan hoá bằng Kibana.

⚠ Điểm mấu chốt — Kibana đi kèm sẵn với dịch vụ được quản lý:

Amazon OpenSearch Service
(tên cũ: Amazon Elasticsearch Service)
        ↓
    AWS lo: dựng cụm, vá lỗi, sao lưu,
    mở rộng, giám sát
        ↓
    Kibana / OpenSearch Dashboards
    ĐƯỢC CÀI SẴN, truy cập qua endpoint của domain
        ↓
    → không phải cài, không phải vận hành
    → đúng nghĩa "fully managed"

⚠ Đưa dữ liệu từ S3 vào bằng cách nào:

S3 event notification khi có tệp mới
        ↓
    Kích hoạt Lambda
        ↓
    Lambda đọc tệp, phân tích, chuẩn hoá
    rồi gọi API `_bulk` của domain
        ↓
    → xử lý được cả log định dạng lạ
    → và lọc bớt trước khi nạp (giảm chi phí)
        ↓
    Với dữ liệu đã có sẵn trong bucket:
      chạy Lambda hoặc AWS Batch một lần
      để nạp lại toàn bộ

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

Đề dùng tên Amazon Elasticsearch Service và Kibana. Từ tháng 9 năm 2021, dịch vụ này đã đổi tên thành Amazon OpenSearch Service, và Kibana được thay bằng OpenSearch Dashboards. Đây chỉ là đổi tên và đổi nhánh mã nguồn, không phải một dịch vụ khác.

Khoá đáp án không đổi: phương án D vẫn mô tả đúng kiến trúc — một cụm tìm kiếm được quản lý, kèm giao diện trực quan hoá có sẵn, được nạp dữ liệu từ S3 qua Lambda. Khi tra tài liệu hôm nay hãy tìm theo OpenSearch Service; khi làm đề, hãy hiểu "Amazon Elasticsearch Service" và "Amazon OpenSearch Service" là cùng một dịch vụ.

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

• C (Kinesis Data Firehose lấy dữ liệu TỪ bucket S3 rồi đẩy sang domain) — đây là phương án gần nhất và Firehose thật sự đẩy được vào OpenSearch, nhưng S3 KHÔNG phải là NGUỒN của Firehose. Firehose nhận dữ liệu từ producer (SDK, Kinesis Data Streams, CloudWatch Logs…) và GHI RA S3, không đọc ngược lại.

• B (dựng cụm Elasticsearch trên EC2) — KHÔNG phải dịch vụ được quản lý: bạn phải tự vá, tự mở rộng, tự sao lưu, tự cài Kibana. Trái thẳng yêu cầu của đề.

• A (DynamoDB + Lambda nạp dữ liệu) — DynamoDB không phải công cụ tìm kiếm toàn văn, và không có Kibana.

Ghi nhớ

⚠ Chọn công cụ phân tích log — bảng phải thuộc: | Nhu cầu | Dịch vụ | |---|---| | Tìm kiếm toàn văn, dashboard phong phú | OpenSearch Service (Kibana/Dashboards) | | Truy vấn nhanh log trong CloudWatch | CloudWatch Logs Insights | | SQL trên khối lượng LỚN ở S3 | Athena | | Dashboard nghiệp vụ cho người không kỹ thuật | QuickSight | | ETL trước khi phân tích | Glue | | Đẩy log theo luồng | Kinesis Data Firehose |

Từ khoá nhận diện:

"Kibana / OpenSearch Dashboards" → OpenSearch Service "fully managed" → KHÔNG dựng trên EC2 "truy vấn SQL trên S3" → Athena "log đã ở CloudWatch" → Logs Insights "Firehose đọc từ S3" → luôn SAI — S3 là ĐÍCH, không phải nguồn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu đã vào chưa | gọi _cat/indices trên domain | | Cụm có khoẻ không | chỉ số ClusterStatus.yellow/red, FreeStorageSpace | | Lambda có lỗi không | CloudWatch Logs của hàm, và chỉ số Errors |

Và một quyết định nên cân nhắc trước khi dựng cụm: log này có thật sự cần tìm kiếm toàn văn và dashboard không. OpenSearch mạnh nhưng tốn kém vì các node chạy liên tục — nếu nhu cầu chỉ là thỉnh thoảng truy vấn log lịch sử, thì giữ nguyên trong S3 và dùng Athena thường rẻ hơn cả một bậc, và cũng không cần ai vận hành cụm.

Đáp án

A — Bật tuỳ chọn "Receive Billing Alerts" ở TÀI KHOẢN THANH TOÁN, đặt billing alarm trong Amazon CLOUDWATCH, và dùng SNS để gửi thông báo.

Vì sao đúng

Có hai chi tiết quyết định câu này: bật ở tài khoản nào, và đặt alarm ở dịch vụ nào.

⚠ Điểm mấu chốt thứ nhất — chỉ TÀI KHOẢN THANH TOÁN thấy tổng chi phí:

Trong AWS Organizations với consolidated billing
        ↓
    Chi phí của MỌI tài khoản thành viên
    gộp về TÀI KHOẢN QUẢN LÝ (payer)
        ↓
    Chỉ số billing chỉ được phát ra ở đó
        ↓
    Bật "Receive Billing Alerts" ở TÀI KHOẢN THÀNH VIÊN
        ↓
    → vô nghĩa, họ không có chi phí tổng
        ↓
    → phải bật ở TÀI KHOẢN THANH TOÁN

⚠ Điểm mấu chốt thứ hai — chỉ số billing chỉ có ở us-east-1:

Chỉ số EstimatedCharges
        ↓
    Namespace: AWS/Billing
    Region: CHỈ us-east-1 (N. Virginia)
        ↓
    → dù bạn dùng Region nào, alarm billing
      PHẢI tạo ở us-east-1
        ↓
    → đây là bẫy rất hay gặp
        ↓
    Cập nhật: mỗi 6 GIỜ một lần
    → không phải công cụ theo dõi thời gian thực

⚠ Và vì sao là CloudWatch chứ không phải Config:

CloudWatch  → theo dõi CHỈ SỐ, so với NGƯỠNG
        ↓
    → billing alarm là một CloudWatch alarm
      trên chỉ số EstimatedCharges

AWS Config  → theo dõi CẤU HÌNH tài nguyên
        ↓
    → hoàn toàn không có khái niệm chi phí

Xem thêm câu #11831 (lô 128): cùng nguyên tắc — trong tổ chức, thao tác về hoá đơn (kích hoạt cost allocation tag) chỉ làm được ở tài khoản quản lý.

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

• D (bật ở TỪNG tài khoản thành viên, đặt alarm CloudWatch ở tài khoản thanh toán) — đây là phương án gần nhất và vế alarm hoàn toàn đúng, nhưng bật tuỳ chọn ở tài khoản thành viên là thừa và vô ích: chúng không có dữ liệu chi phí tổng của tổ chức.

• C (bật ở tài khoản thanh toán, đặt alarm trong AWS CONFIG) — vế đầu đúng, nhưng AWS Config không đặt được alarm theo ngưỡng chi phí.

• B (bật ở từng tài khoản thành viên, alarm trong AWS Config) — sai cả hai vế.

Ghi nhớ

⚠ Billing alarm — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Bật ở đâu | TÀI KHOẢN THANH TOÁN — Billing preferences → Receive Billing Alerts | | Chỉ số | EstimatedCharges, namespace AWS/Billing | | Region | CHỈ us-east-1 — bẫy kinh điển | | Tần suất cập nhật | khoảng 6 giờ một lần | | Dimension | Currency (bắt buộc), ServiceName, LinkedAccount | | Hành động | SNS |

Từ khoá nhận diện:

"cảnh báo khi chi phí vượt ngưỡng" → AWS Budgets (tốt hơn), hoặc billing alarm "billing alarm không hiện chỉ số" → chưa bật preference, hoặc sai Region "chi phí tăng bất thường" → Cost Anomaly Detection "vì sao chi phí tăng" → Cost Explorer "chi tiết theo giờ, theo tài nguyên" → Cost and Usage Report

⚠ AWS Budgets — thường là lựa chọn TỐT HƠN billing alarm: | Đặc điểm | Nội dung | |---|---| | Lọc được | theo tài khoản, dịch vụ, TAG, cost category | | Loại ngân sách | chi phí, mức dùng, RI/SP utilization và coverage | | Cảnh báo theo dự báo | báo khi DỰ BÁO sẽ vượt, chứ không đợi vượt thật | | Nhiều ngưỡng | ví dụ 50%, 80%, 100% | | Budget Actions | tự áp SCP hoặc dừng instance khi vượt | | Chi phí | 2 ngân sách đầu miễn phí, sau đó tính phí nhỏ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số có tồn tại không | CloudWatch ở us-east-1 → namespace AWS/Billing | | Alarm có gửi được không | set-alarm-state --state-value ALARM rồi xem hộp thư | | Đăng ký SNS đã xác nhận chưa | list-subscriptions-by-topic |

Và một khuyến nghị nên nói rõ dù đề chọn billing alarm: với hệ thống mới, hãy dùng AWS Budgets thay vì billing alarm. Budgets lọc được theo tag và theo tài khoản, cảnh báo được theo dự báo chứ không đợi tới lúc đã vượt, và còn kích hoạt được hành động tự động — trong khi billing alarm chỉ nhìn được đúng một con số tổng, cập nhật sáu giờ một lần.

Đáp án

A — KÍCH HOẠT cost allocation tag, và GẮN TAG cho tài nguyên theo dự án.

Vì sao đúng

Muốn Cost Explorer chia chi phí theo dự án thì phải làm đủ hai việc, và phương án A nêu đúng cả hai.

⚠ Điểm mấu chốt — hai bước, thiếu một là không thấy gì:

BƯỚC 1 — GẮN TAG lên tài nguyên
        ↓
    Project=Alpha, Project=Beta…
    trên EC2, RDS, S3, Lambda, EBS…
        ↓
    Công cụ: Tag Editor, CloudFormation, Terraform
        ↓
BƯỚC 2 — KÍCH HOẠT làm cost allocation tag
        ↓
    Billing → Cost Allocation Tags → Activate
        ↓
    Chưa kích hoạt → tag CÓ trên tài nguyên
    nhưng KHÔNG hiện trong Cost Explorer

⚠ Và một ràng buộc về thời gian phải nói rõ với ban quản lý:

Sau khi kích hoạt
        ↓
    Mất TỚI 24 GIỜ dữ liệu mới xuất hiện
        ↓
    Và KHÔNG áp ngược cho chi phí quá khứ
        ↓
    → chi phí của tháng trước sẽ KHÔNG BAO GIỜ
      chia được theo tag này
        ↓
    → kích hoạt càng sớm càng tốt

⚠ Xem kết quả ở đâu:

Cost Explorer → Group by → Tag → Project
        ↓
    → biểu đồ chi phí theo từng dự án
        ↓
    Muốn cảnh báo:  Budgets lọc theo tag đó
    Muốn chi tiết:  Cost and Usage Report

Xem thêm câu #11854 và #11831 (lô 128): cùng chùm cost allocation tag. #11831 bổ sung chi tiết quan trọng — trong tổ chức, bước kích hoạt chỉ làm được ở tài khoản quản lý.

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

• B (dùng cost categories để định nghĩa nhóm tuỳ chỉnh dựa trên các chiều chi phí) — đây là phương án gần nhất và cost category là công cụ có thật, rất hữu ích, nhưng nó nhóm chi phí theo quy tắc trên các chiều đã có (tài khoản, dịch vụ, tag…). Nó vẫn cần tag làm dữ liệu đầu vào khi muốn chia theo dự án trong cùng một tài khoản. Là công cụ bổ trợ, không thay thế bước gắn và kích hoạt tag.

• C (tạo billing alert trong AWS Budgets theo dõi tài nguyên của từng dự án) — Budgets cảnh báo khi vượt ngưỡng, không phân tích và trình bày chi phí. Và bản thân Budgets cũng cần tag đã kích hoạt mới lọc được theo dự án.

• D (dùng Organizations, bật consolidated billing, tạo Cost and Usage Report) — consolidated billing gộp chi phí giữa các TÀI KHOẢN, trong khi đề nói rõ là chia theo dự án trong MỘT tài khoản.

Ghi nhớ

⚠ Bốn công cụ chi phí — bảng phải thuộc: | Công cụ | Việc | |---|---| | Cost Explorer | xem, lọc, nhóm, dự báo — 13 tháng lịch sử | | Cost and Usage Report | chi tiết nhất: theo GIỜ, theo từng tài nguyên | | Budgets | cảnh báo và hành động khi vượt ngưỡng | | Cost Anomaly Detection | phát hiện bất thường bằng học máy | | Cost Categories | nhóm chi phí theo quy tắc riêng của công ty |

Từ khoá nhận diện:

"chia chi phí theo dự án / phòng ban" → gắn tag + KÍCH HOẠT tag "nhóm nhiều tài khoản và dịch vụ thành một 'đơn vị kinh doanh'" → cost category "cảnh báo khi vượt ngân sách" → Budgets "chi phí tăng bất thường" → Cost Anomaly Detection "tag không hiện trong Cost Explorer" → chưa kích hoạt, hoặc chưa qua 24 giờ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tag đã kích hoạt chưa | Billing → Cost Allocation Tags — cột Status | | Tài nguyên nào chưa gắn tag | Tag Editor, lọc "tag không tồn tại" | | Dữ liệu đã về chưa | Cost Explorer → Group by → Tag |

Và một điều nên chốt trước khi gắn tag hàng loạt: quy ước về chữ hoa chữ thường. Cost Explorer coi Project, project và PROJECT là ba tag hoàn toàn khác nhau, nên chỉ cần vài người gõ khác nhau là báo cáo chi phí bị chẻ thành nhiều nhánh vô nghĩa — và Tag Policy của Organizations chính là công cụ để ép quy ước đó ngay từ đầu.

Đáp án

C và E — CloudFront ACCESS LOG và ALB ACCESS LOG.

Vì sao đúng

Mã trạng thái HTTP là khái niệm của tầng 7, và trong kiến trúc này chỉ hai thành phần ghi lại chúng.

⚠ Điểm mấu chốt — đường đi của request và nơi có log tầng 7:

Người dùng
    │
    ▼
CLOUDFRONT  ──► access log: sc-status
    │           (200, 403, 502, 504…)
    ▼
ALB         ──► access log: elb_status_code
    │                     VÀ target_status_code
    ▼
EC2         ──► log ứng dụng (nếu có đẩy đi)
    │
    ▼
DYNAMODB    ──► không có khái niệm HTTP status
                của ứng dụng

⚠ ALB access log có HAI cột mã trạng thái — rất hữu ích:

elb_status_code     → ALB trả cho client
target_status_code  → EC2 trả cho ALB
        ↓
    So hai cột biết ngay lỗi ở đâu:
        ↓
    elb 502, target rỗng → EC2 không phản hồi,
                           hoặc phản hồi sai định dạng
    elb 503, target rỗng → KHÔNG CÓ target khoẻ mạnh
    elb 504, target rỗng → EC2 quá chậm (timeout)
    elb 500, target 500  → lỗi trong ỨNG DỤNG

⚠ CloudFront log phân biệt lỗi ở EDGE hay ở ORIGIN:

x-edge-result-type
        ↓
    Hit / Miss / RefreshHit  → cache
    Error                    → lỗi
    LimitExceeded            → chạm giới hạn
        ↓
x-edge-response-result-type
        ↓
    → đối chiếu với sc-status để biết
      CloudFront tự trả lỗi hay origin trả lỗi

Xem thêm câu #11887 (lô 129): gần như cùng một câu hỏi, cùng đáp án CloudFront access log + ALB access log, và cũng cùng chữ cái C và E. Khoá nhất quán.

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

• D (VPC Flow Logs) — đây là phương án gần nhất vì cũng là log mạng, nhưng flow log ghi ở tầng 3/4: IP, cổng, giao thức, số byte, ACCEPT/REJECT. Không có mã HTTP nào.

• B (CloudTrail logs) — ghi lời gọi API tới AWS, không ghi request HTTP của người dùng tới ứng dụng.

• A (DynamoDB logs) — DynamoDB không có access log kiểu đó; hoạt động của nó được ghi qua CloudTrail data event, và cũng không phải mã HTTP của ứng dụng.

Ghi nhớ

⚠ Log ở tầng nào — bảng phải thuộc: | Nguồn | Tầng | Có mã HTTP | |---|---|---| | CloudFront access log | 7 | CÓ — sc-status | | ALB access log | 7 | CÓ — elb_status_code + target_status_code | | API Gateway access log | 7 | có | | NLB access log | 4 | KHÔNG | | VPC Flow Logs | 3/4 | KHÔNG — chỉ ACCEPT/REJECT | | CloudTrail | API | mã lỗi API, không phải HTTP |

Từ khoá nhận diện:

"mã trạng thái HTTP, lỗi 5xx" → ALB và CloudFront access log "gói tin bị chặn" → VPC Flow Logs "ai gọi API nào" → CloudTrail "truy vấn DynamoDB nào chậm" → CloudWatch metrics + Contributor Insights "phân tích khối lượng log lớn" → Athena trên S3

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lỗi ở ALB hay ở ứng dụng | so HTTPCode_ELB_5XX với HTTPCode_Target_5XX | | Lỗi ở edge hay ở origin | CloudFront log, cột x-edge-result-type | | Request cụ thể nào lỗi | Athena trên log ALB, lọc elb_status_code >= 500 |

Và một điều nên kiểm tra sớm khi backend là DynamoDB: chỉ số ThrottledRequests. Nếu bảng bị giới hạn thông lượng, ứng dụng sẽ trả 500 hoặc 503 lên ALB, và bạn sẽ thấy target_status_code = 500 trong log — nhưng nguyên nhân thật nằm ở tầng dữ liệu, không phải ở mã ứng dụng, và chỉ chỉ số của DynamoDB mới chỉ ra điều đó.