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

Đáp án

C — Ổ gốc EBS được mã hoá và người quản trị KHÔNG có quyền truy cập khoá KMS để giải mã.

Vì sao đúng

Triệu chứng rất đặc trưng: pending → terminated NGAY LẬP TỨC, không qua trạng thái running nào.

⚠ Điểm mấu chốt — chuỗi khởi chạy dừng ngay ở bước tạo volume:

Khởi chạy instance với AMI có ổ gốc mã hoá
        ↓
    EC2 cần tạo EBS volume từ snapshot đã mã hoá
        ↓
    Phải gọi KMS để lấy khoá dữ liệu
        ↓
    Thiếu quyền trên CMK
        ↓
    → tạo volume THẤT BẠI
    → instance chuyển thẳng sang "terminated"
        ↓
    → chưa từng khởi động, chưa có log nào để đọc

⚠ Bốn quyền cần có trên CMK — thiếu một là hỏng:

kms:Decrypt
kms:GenerateDataKeyWithoutPlaintext
kms:CreateGrant                     ← hay bị quên nhất
kms:DescribeKey

⚠ Và nơi DUY NHẤT thấy nguyên nhân:

aws ec2 describe-instances --instance-ids i-xxxx \
  --query 'Reservations[].Instances[].StateReason'
        ↓
    → thường thấy: "Client.InternalError: Client error on launch"
        ↓
    Với Auto Scaling group:
        → xem ACTIVITY HISTORY của ASG
        ↓
    → không có log ứng dụng, không có console output

Xem thêm câu #11769, #11558 và #11566: cùng nguyên nhân KMS ở các bối cảnh khác — Auto Scaling group với AMI mã hoá, và trường hợp CMK nằm ở tài khoản khác.

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

• D (đã vượt hạn mức số instance trong Region) — đây là phương án gần nhất vì cũng khiến việc khởi chạy thất bại. Nhưng khi đó lời gọi RunInstances bị TỪ CHỐI NGAY với lỗi InstanceLimitExceeded — không có instance nào được tạo ra, nên cũng không có trạng thái pending rồi terminated.

• A (AWS không đủ dung lượng On-Demand) — cho lỗi InsufficientInstanceCapacity, và cũng từ chối ngay chứ không tạo instance rồi chấm dứt.

• B (API khởi chạy loại instance đó bị hạn chế trong tài khoản) — nếu bị SCP hoặc IAM chặn thì lời gọi trả về UnauthorizedOperation hoặc AccessDenied — lại là từ chối ngay từ đầu.

Ghi nhớ

⚠ Phân biệt hai kiểu thất bại khi khởi chạy — bảng phải thuộc: | Kiểu | Biểu hiện | |---|---| | Lời gọi API bị TỪ CHỐI | không có instance nào được tạo — InstanceLimitExceeded, InsufficientInstanceCapacity, UnauthorizedOperation | | Instance được tạo rồi CHẤM DỨT | pending → terminated — thường là KMS, hoặc AMI hỏng, hoặc user data lỗi nặng |

Từ khoá nhận diện:

"pending rồi terminated ngay" → thiếu quyền KMS (hoặc AMI/snapshot có vấn đề) "Client.InternalError khi khởi chạy" → key policy của CMK "InsufficientInstanceCapacity" → đổi AZ, đổi loại instance "InstanceLimitExceeded" → Service Quotas "ASG không khởi chạy được máy" → Activity history của ASG

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lý do chấm dứt | describe-instances, đọc StateReason.Message | | Key policy có đủ không | get-key-policy, tìm principal của người khởi chạy | | AMI mã hoá bằng khoá nào | describe-images, xem block device mapping |

Và một mẹo chẩn đoán rất nhanh cho loại lỗi này: thử khởi chạy cùng cấu hình đó với một AMI KHÔNG mã hoá. Nếu máy lên bình thường thì nguyên nhân gần như chắc chắn nằm ở quyền KMS — và bạn tiết kiệm được cả buổi đọc thông báo Client.InternalError, một dòng lỗi nổi tiếng vì nó không nói gì về nguyên nhân thật.

Đáp án

A — Đổi bucket ACL để giới hạn quyền truy cập chỉ cho chủ sở hữu bucket.

Vì sao đúng

Trong bốn phương án, A là phương án duy nhất thực sự thu hồi quyền truy cập của tài khoản khác.

⚠ Điểm mấu chốt — bucket ACL cấp quyền cho tài khoản AWS khác:

Bucket ACL có thể cấp quyền cho:
        - chủ sở hữu bucket
        - TÀI KHOẢN AWS KHÁC (theo canonical ID hoặc email)
        - nhóm "Authenticated Users" / "All Users"
        ↓
    Đặt ACL về "private" (chỉ chủ sở hữu)
        ↓
    → thu hồi mọi quyền đã cấp cho tài khoản khác

aws s3api put-bucket-acl --bucket ten-bucket --acl private

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

ACL là cơ chế CŨ, và AWS nay khuyến nghị TẮT nó đi.

Từ tháng 4/2023, bucket tạo mới mặc định:
        Object Ownership = BucketOwnerEnforced
        ↓
    → ACL bị VÔ HIỆU HOÁ hoàn toàn
    → mọi phân quyền chuyển sang BUCKET POLICY
        ↓
    → với bucket hiện đại, "đổi bucket ACL" là thao tác
      KHÔNG CÒN Ý NGHĨA

Cách làm được khuyến nghị hiện nay:

// Bucket policy chỉ cho phép tài khoản của chính mình
{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::ten-bucket", "arn:aws:s3:::ten-bucket/*"],
  "Condition": {
    "StringNotEquals": { "aws:PrincipalAccount": "111122223333" }
  }
}

Khoá đáp án giữ nguyên vì trong bốn phương án đã cho, A là phương án duy nhất đúng về mặt cơ chế — ba phương án kia đều sai hẳn. Nhưng khi làm việc thật, hãy dùng bucket policy và bật BucketOwnerEnforced, đồng thời rà lại Block Public Access.

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

• D (tạo "object policy" giới hạn quyền cho người dùng cùng tài khoản) — đây là phương án gần nhất và cái tên nghe rất hợp lý, nhưng S3 KHÔNG có khái niệm "object policy". Chỉ có bucket policy (cấp bucket) và object ACL (cấp đối tượng).

• B (tạo presigned URL để truy cập đối tượng) — presigned URL CẤP THÊM quyền truy cập tạm thời cho người không có chứng chỉ. Nó làm điều ngược lại với yêu cầu của đề.

• C (chuyển bucket sang lớp S3 One Zone-IA và tắt versioning) — hai thao tác về lớp lưu trữ và bảo vệ dữ liệu, hoàn toàn không liên quan tới kiểm soát truy cập.

Ghi nhớ

⚠ Ba cơ chế phân quyền của S3 — bảng phải thuộc: | Cơ chế | Phạm vi | Trạng thái | |---|---|---| | Bucket policy | cả bucket, JSON, mạnh nhất | khuyến nghị dùng | | IAM policy | gắn vào user/role | khuyến nghị dùng | | Bucket ACL / Object ACL | cấp thô, theo tài khoản | CŨ — AWS khuyến nghị tắt | | S3 Access Points | mỗi ứng dụng một chính sách riêng | cho bucket dùng chung |

Từ khoá nhận diện:

"thu hồi quyền của tài khoản khác" → bucket policy (hiện đại) hoặc ACL (cũ) "object policy" → KHÔNG TỒN TẠI "cấp quyền tạm thời cho người ngoài" → presigned URL "nhiều ứng dụng dùng chung bucket" → S3 Access Points "chặn hẳn mọi truy cập công khai" → Block Public Access

⚠ Ba chế độ Object Ownership — nhắc lại: | Chế độ | Nội dung | |---|---| | BucketOwnerEnforced | ACL VÔ HIỆU, chủ bucket luôn sở hữu — mặc định mới, AWS khuyến nghị | | BucketOwnerPreferred | chủ bucket sở hữu nếu người ghi dùng bucket-owner-full-control | | ObjectWriter | người ghi sở hữu — cách cũ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | ACL hiện tại là gì | get-bucket-acl --bucket <ten> | | Bucket có chia sẻ ra ngoài không | IAM Access Analyzer for S3 | | Object Ownership đang ở chế độ nào | get-bucket-ownership-controls |

Và một việc nên làm ngay sau khi xử lý xong yêu cầu này: chạy IAM Access Analyzer for S3 để xem còn bucket nào khác đang chia sẻ ra ngoài tài khoản. Quyền truy cập liên tài khoản thường được cấp trong một dự án cụ thể rồi không ai thu hồi khi dự án kết thúc — và công cụ này liệt kê chúng ra chỉ trong vài giây, miễn phí.

Đáp án

B, D — hai việc cần làm:

• D — Tạo một Elastic IP và gắn nó vào EC2 instance.
• B — Tạo một bản ghi A trong Route 53 trỏ tới địa chỉ IP của EC2.

Vì sao đúng

Đề nêu ba ràng buộc, và cặp Elastic IP + A record thoả cả ba:

⚠ Điều D — vì sao phải là Elastic IP:

IP công cộng TỰ ĐỘNG của EC2
        ↓
    MẤT khi stop/start, đổi sang địa chỉ khác
        ↓
    → không phải "địa chỉ tĩnh"
        ↓
Elastic IP
        ↓
    Là TÀI NGUYÊN ĐỘC LẬP của tài khoản
        ↓
    → giữ nguyên qua stop/start
    → chuyển sang máy khác được khi cần
    → đúng nghĩa "single static public IP"

⚠ Điều B — bản ghi A trỏ tới một địa chỉ IPv4:

Elastic IP là một địa chỉ IPv4 CỐ ĐỊNH
        ↓
    Bản ghi A: tên miền → địa chỉ IPv4
        ↓
    example.com  A  52.1.2.3
        ↓
    → đúng loại bản ghi cho tình huống này
    → và example.com là ZONE APEX, nơi CNAME không dùng được

⚠ Vì sao KHÔNG dùng ALB ở đây — đây là chỗ dễ chọn nhầm:

ALB KHÔNG có IP tĩnh
        ↓
    → nó có nhiều IP thay đổi liên tục
    → chỉ dùng được qua tên DNS
        ↓
    Đề nói rõ cần MỘT IP CÔNG CỘNG TĨNH
        ↓
    → ALB trái thẳng yêu cầu
    → (muốn IP tĩnh cho load balancer thì phải dùng NLB)

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

• C (dựng ALB và đưa EC2 vào target group của nó) — đây là phương án gần nhất và là kiến trúc tốt hơn về mặt sẵn sàng cao. Nhưng ALB không cung cấp IP tĩnh, nên nó trái ràng buộc rõ ràng nhất của đề; và nó thêm một tài nguyên phải quản lý và trả tiền.

• E (tạo bản ghi CNAME trỏ tới IP của EC2) — sai hai lần: CNAME trỏ tới TÊN MIỀN, không trỏ tới địa chỉ IP, và CNAME không dùng được ở zone apex như example.com.

• A (tạo Auto Scaling group với min 1, max 2) — mâu thuẫn với ràng buộc "một IP tĩnh duy nhất": ASG có thể chạy hai instance, mỗi máy một địa chỉ khác nhau. Nó cũng thêm công sức quản lý.

Ghi nhớ

⚠ Các loại địa chỉ IP của EC2 — bảng phải thuộc: | Loại | Giữ khi stop/start | Chuyển sang máy khác | Tính tiền | |---|---|---|---| | Private IPv4 | có | không (cố định trong ENI) | không | | Public IPv4 (auto) | KHÔNG | KHÔNG | có (từ 2024) | | Elastic IP | CÓ | CÓ | có, kể cả khi không dùng | | IPv6 | có | có | không |

Từ khoá nhận diện:

"một IP công cộng tĩnh cho EC2" → Elastic IP "IP tĩnh cho LOAD BALANCER" → NLB (ALB không có) "IP tĩnh anycast toàn cầu" → Global Accelerator "trỏ tên miền tới một địa chỉ IP" → bản ghi A (IPv4) hoặc AAAA (IPv6) "trỏ tên miền tới ALB/CloudFront" → Alias record

⚠ Ba cách có IP tĩnh trên AWS — chọn cho đúng: | Cách | Dùng cho | |---|---| | Elastic IP | một EC2 instance hoặc NAT Gateway | | Network Load Balancer | IP tĩnh MỖI AZ, gán được Elastic IP | | AWS Global Accelerator | hai IP anycast toàn cầu, định tuyến tới nhiều Region |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Elastic IP đã gắn chưa | describe-addresses, xem có InstanceId không | | Bản ghi đã lan chưa | dig example.com — phải ra đúng Elastic IP | | Có Elastic IP nào đang rảnh không | describe-addresses — mục thiếu InstanceId là đang tốn tiền vô ích |

Và một lời khuyên nên nói với đội ứng dụng ngay khi triển khai xong: kiến trúc này có một điểm chết đơn, và Elastic IP không thay đổi điều đó. Elastic IP giúp bạn chuyển địa chỉ sang máy khác khi cần — nhưng việc chuyển đó là thủ công. Nếu ứng dụng trở nên quan trọng, bước nâng cấp tự nhiên là NLB với Elastic IP đặt trước một Auto Scaling group nhiều AZ: bạn giữ nguyên địa chỉ tĩnh mà có thêm khả năng chịu lỗi.

Đáp án

A, D — hai việc cần làm:

• D — Tạo một IAM policy cấp quyền trên instance có tag cụ thể, dùng phần tử Condition.
• A — Gắn chính sách đó vào user hoặc group cần quyền.

Vì sao đúng

Đây là mô hình ABAC (Attribute-Based Access Control) — phân quyền theo thuộc tính thay vì liệt kê từng tài nguyên.

⚠ Điểm mấu chốt — dùng Condition với khoá ec2:ResourceTag:

{
  "Effect": "Allow",
  "Action": ["ec2:StartInstances", "ec2:StopInstances", "ec2:RebootInstances"],
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {
    "StringEquals": { "ec2:ResourceTag/Doi": "PhatTrien" }
  }
}

    → chính sách áp cho MỌI instance
    → nhưng CHỈ có hiệu lực với instance mang tag Doi=PhatTrien
        ↓
    → thêm máy mới gắn đúng tag là TỰ ĐỘNG được quản
    → KHÔNG phải sửa chính sách

⚠ Vì sao phải có cả hai bước:

Bước D — VIẾT chính sách
        ↓
    Chính sách tồn tại nhưng chưa có hiệu lực với ai

Bước A — GẮN chính sách vào user hoặc group
        ↓
    → giờ mới có người thật sự được cấp quyền
        ↓
    Thiếu bước nào cũng không hoàn thành yêu cầu

⚠ Và đây là điểm phân biệt quan trọng nhất — Condition chứ không phải Principal:

Principal  → "AI được phép"
        ↓
    → chỉ có trong RESOURCE-BASED policy
      (bucket policy, key policy, trust policy)
    → chính sách IAM gắn vào user KHÔNG CÓ Principal

Condition  → "TRONG ĐIỀU KIỆN NÀO"
        ↓
    → đây mới là nơi khai điều kiện về tag

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

• B (tạo IAM policy cấp quyền dựa trên phần tử Principal) — đây là phương án gần nhất và là hiểu nhầm cơ bản nhất: chính sách gắn vào user hoặc group là identity-based policy, và loại này KHÔNG CÓ trường Principal (principal chính là danh tính được gắn chính sách). Principal chỉ xuất hiện trong resource-based policy.

• C (gắn IAM role vào các EC2 instance) — làm việc ngược lại: role gắn vào instance cho ứng dụng TRÊN máy gọi được dịch vụ AWS. Đề hỏi cách kiểm soát ai được quản lý những máy đó.

• E (tạo Auto Scaling group cho các instance và gắn tag) — ASG là cơ chế co giãn, không phải cơ chế phân quyền. Gắn tag qua ASG thì tiện, nhưng bản thân nó không cấp hay chặn quyền nào.

Ghi nhớ

⚠ ABAC — phân quyền theo tag, bảng phải thuộc: | Khoá điều kiện | Nghĩa | |---|---| | ec2:ResourceTag/<key> | tag trên TÀI NGUYÊN được thao tác | | aws:RequestTag/<key> | tag trong REQUEST đang tạo tài nguyên | | aws:PrincipalTag/<key> | tag trên chính NGƯỜI GỌI | | aws:TagKeys | danh sách khoá tag trong request |

Từ khoá nhận diện:

"cấp quyền theo tag" → Condition với ec2:ResourceTag "Principal trong chính sách gắn vào user" → KHÔNG CÓ "ứng dụng trên EC2 gọi S3" → IAM role gắn vào instance "ép phải gắn tag khi tạo tài nguyên" → aws:RequestTag + aws:TagKeys "phân quyền không cần sửa chính sách khi thêm tài nguyên" → ABAC

⚠ ABAC và RBAC — khác biệt và khi nào dùng: | | RBAC (theo vai trò) | ABAC (theo thuộc tính) | |---|---|---| | Cách làm | liệt kê từng tài nguyên trong Resource | dùng Condition với tag | | Thêm tài nguyên mới | phải sửa chính sách | tự động áp dụng | | Số chính sách | tăng theo số nhóm tài nguyên | ít, dùng lại được | | Điều kiện | — | phải có kỷ luật gắn tag |

⚠ Mẫu ABAC mạnh nhất — so tag của NGƯỜI với tag của TÀI NGUYÊN:

{
  "Effect": "Allow",
  "Action": "ec2:*",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "ec2:ResourceTag/Doi": "${aws:PrincipalTag/Doi}"
    }
  }
}

    → MỘT chính sách duy nhất cho MỌI đội
    → mỗi người chỉ quản được máy của đội mình
    → thêm đội mới: chỉ cần gắn tag, không sửa chính sách

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách có hiệu lực đúng không | IAM Policy Simulator với ARN của instance cụ thể | | Action đó có hỗ trợ điều kiện tag không | tra tài liệu Service Authorization Reference | | Instance đã gắn tag chưa | describe-instances --filters "Name=tag:Doi,Values=PhatTrien" |

Và một cạm bẫy rất hay gặp khi triển khai ABAC cho EC2: ec2:DescribeInstances không hỗ trợ điều kiện theo tag. Nghĩa là dù bạn viết chính sách chặt tới đâu, người dùng vẫn nhìn thấy toàn bộ instance trong tài khoản — họ chỉ không start, stop hay terminate được những máy không thuộc tag của mình. Nếu yêu cầu là "không được nhìn thấy", thì ABAC ở tầng IAM không giải quyết được, và bạn cần tách sang tài khoản riêng.

Đáp án

B — String match condition (điều kiện khớp chuỗi).

Vì sao đúng

Đề cần đọc giá trị của một HEADER và đếm theo giá trị đó — đó chính là việc của string match.

⚠ Điểm mấu chốt — string match soi được vào bên trong request:

String match condition khớp được với:
        - HEADER cụ thể (ví dụ X-Front-End-Id)   ← đề bài cần
        - URI, query string
        - HTTP method
        - body của request
        - cookie
        ↓
    Với mỗi giá trị header khác nhau → một rule riêng
        ↓
    Đặt rule ở chế độ COUNT thay vì BLOCK
        ↓
    → WAF ĐẾM số request khớp, KHÔNG chặn
    → đúng yêu cầu "identify and count"

⚠ Và chế độ Count là chi tiết quan trọng nhất của câu này:

Action = BLOCK  → chặn request
Action = ALLOW  → cho qua
Action = COUNT  → CHỈ ĐẾM, không can thiệp
        ↓
    → đề chỉ muốn NHẬN DIỆN và ĐẾM
    → dùng Count là đúng, không được Block

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

CloudWatch metrics của WAF
        ↓
    Mỗi rule có chỉ số riêng, gắn nhãn theo tên rule
        ↓
    → vẽ đồ thị số request từ từng front-end server

WAF sampled requests
        ↓
    → xem mẫu request thật đã khớp rule nào

WAF logs → Kinesis Data Firehose → S3
        ↓
    → phân tích đầy đủ bằng Athena

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

• D ("ID match" condition) — đây là phương án gần nhất vì đề nhắc tới "ID của front-end server", nên cái tên nghe rất khớp. Nhưng WAF KHÔNG có loại điều kiện nào tên "ID match". Đây là bẫy đặt tên.

• A (size constraint) — khớp theo ĐỘ DÀI của một phần request (header dài bao nhiêu byte, body lớn cỡ nào). Nó không đọc giá trị.

• C (IP match) — khớp theo địa chỉ IP nguồn. Có thể dùng nếu mỗi front-end server có IP cố định, nhưng đề nói rõ định danh nằm trong header, không phải ở IP.

Ghi nhớ

⚠ Các loại điều kiện của AWS WAF — bảng phải thuộc: | Loại | Khớp theo | |---|---| | String match / regex match | nội dung của header, URI, query, body, cookie | | Size constraint | độ dài của một phần request | | IP set match | địa chỉ IP nguồn | | Geo match | quốc gia của người gửi | | SQL injection match | mẫu tấn công SQL | | XSS match | mẫu tấn công cross-site scripting | | Rate-based rule | số request từ một IP trong 5 phút | | Labels | kết quả của rule khác (dùng cho rule ghép) |

Từ khoá nhận diện:

"khớp giá trị của một header" → string match "đếm mà không chặn" → action COUNT "giới hạn số request từ một IP" → rate-based rule "chặn theo quốc gia" → geo match "ID match condition" → KHÔNG TỒN TẠI

⚠ Ba action của một WAF rule — bảng phải thuộc: | Action | Nội dung | |---|---| | ALLOW | cho qua, dừng đánh giá các rule sau | | BLOCK | chặn, trả về 403 | | COUNT | chỉ đếm, KHÔNG can thiệp — tiếp tục đánh giá rule sau | | CAPTCHA / Challenge | thử thách người gửi thay vì chặn thẳng |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Rule có khớp gì không | WAF sampled requests trong console | | Đếm được bao nhiêu | CloudWatch metrics của WAF, theo từng rule | | Header thật sự chứa gì | bật WAF logging ra S3 rồi truy vấn bằng Athena |

Và một lời khuyên khi dùng WAF để phân tích thay vì để chặn: hãy bật WAF logging ra S3 và phân tích bằng Athena, thay vì chỉ dựa vào chỉ số CloudWatch. Chỉ số cho bạn con số tổng theo từng rule, nhưng log cho bạn toàn bộ nội dung request — nghĩa là bạn trả lời được cả những câu hỏi chưa nghĩ ra lúc viết rule, mà không phải sửa cấu hình rồi chờ dữ liệu mới.

Đáp án

B — Network ACL gắn với subnet KHÔNG cho phép lưu lượng ĐI RA trên dải cổng tạm (ephemeral port).

Vì sao đúng

Chính bản ghi flow log trong đề đã chỉ ra câu trả lời — chỉ cần đọc đúng.

⚠ Đọc hai dòng flow log:

Dòng 1: 10.0.1.23 → 172.32.17.148  cổng 60004 → 8081  ACCEPT
        ↓
    Hmm, khoan — hãy đọc kỹ hướng
        ↓
Dòng 2: 172.32.17.148 → 10.0.1.23  cổng 8081 → 60004  REJECT
        ↓
    → gói ĐI RA từ cổng dịch vụ 8081
      tới CỔNG TẠM 60004 của bên kia
        ↓
    → đó chính là GÓI PHẢN HỒI
    → và nó BỊ TỪ CHỐI

⚠ Điểm mấu chốt — chỉ NACL mới từ chối một gói phản hồi:

Security Group là STATEFUL
        ↓
    Kết nối đã được chấp nhận ở chiều vào
        ↓
    → gói phản hồi TỰ ĐỘNG được phép đi ra
    → SG KHÔNG BAO GIỜ chặn phản hồi
        ↓
Network ACL là STATELESS
        ↓
    Xét từng gói độc lập, không nhớ kết nối nào
        ↓
    → gói phản hồi phải khớp một luật OUTBOUND
    → không khớp → REJECT
        ↓
    → chỉ NACL giải thích được dòng log thứ hai

⚠ Cách sửa:

Thêm luật outbound vào NACL:
        Allow TCP 1024–65535 tới 0.0.0.0/0
        ↓
    → phủ mọi dải cổng tạm của mọi hệ điều hành
      (Linux 32768–60999, Windows 49152–65535,
       NLB/Lambda 1024–65535)

Xem thêm câu #11730, #11721, #11727: cùng nguyên lý NACL stateless ở các bối cảnh khác. Câu này đặc biệt vì cho đọc flow log để tự suy ra nguyên nhân.

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

• A (Security Group của NLB không có luật cho phép lưu lượng vào từ trung tâm dữ liệu) — đây là phương án gần nhất vì SG là nghi phạm quen thuộc. Nhưng dòng log thứ nhất đã ACCEPT, nghĩa là chiều vào hoàn toàn thông. (Ngoài ra, trong nhiều năm NLB không hề có Security Group — chỉ mới hỗ trợ từ tháng 8/2023.)

• D (Security Group của EC2 thiếu luật cho lưu lượng đến từ NLB) — cùng lý do: nếu SG chặn thì dòng đầu tiên đã là REJECT, chứ không phải ACCEPT.

• C (tường lửa ở trung tâm dữ liệu không cho lưu lượng tới VPC) — nếu vậy thì gói tin không bao giờ tới được VPC, và sẽ không có dòng log nào cả. Nhưng ở đây có tới hai dòng.

Ghi nhớ

⚠ Cách đọc một bản ghi VPC Flow Log — bảng phải thuộc: | Trường | Vị trí | Ý nghĩa | |---|---|---| | version | 1 | phiên bản định dạng | | account-id | 2 | tài khoản | | interface-id | 3 | ENI nào | | srcaddr | 4 | IP nguồn | | dstaddr | 5 | IP đích | | srcport | 6 | cổng nguồn | | dstport | 7 | cổng đích | | protocol | 8 | 6 = TCP, 17 = UDP | | packets, bytes | 9, 10 | khối lượng | | start, end | 11, 12 | mốc thời gian | | action | 13 | ACCEPT hoặc REJECT | | log-status | 14 | OK, NODATA, SKIPDATA |

Từ khoá nhận diện:

"gói vào ACCEPT, gói ra REJECT" → NACL thiếu luật outbound "cả hai chiều đều REJECT" → NACL inbound hoặc Security Group "không có dòng log nào" → gói chưa từng tới VPC — tường lửa bên ngoài, hoặc route table "SG chặn phản hồi" → KHÔNG BAO GIỜ, SG là stateful

⚠ Chẩn đoán bằng flow log — cách suy luận từng bước:

1. Có dòng log không?
        KHÔNG → gói chưa tới VPC (route, tường lửa ngoài, DNS sai)
        CÓ    → đi tiếp

2. Dòng ĐI VÀO là ACCEPT hay REJECT?
        REJECT → NACL inbound hoặc Security Group
        ACCEPT → đi tiếp

3. Có dòng ĐI RA không, và nó là gì?
        REJECT → NACL OUTBOUND thiếu cổng tạm  ← câu này
        KHÔNG CÓ → ứng dụng không trả lời (kiểm tra trong máy)
        ACCEPT → mạng thông, vấn đề ở tầng cao hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | NACL có mở chiều ra không | describe-network-acls — xem cả Egress: true | | Đường đi có thông không | VPC Reachability Analyzer | | Ứng dụng có lắng nghe không | ss -tlnp trên chính máy đó |

Và một kỹ năng rất đáng luyện vì nó rút ngắn mọi cuộc chẩn đoán mạng: đọc flow log theo CẶP hai dòng — một chiều vào, một chiều ra. Chỉ riêng việc xác định gói nào bị chặn ở chiều nào đã khoanh vùng được nguyên nhân xuống còn một hoặc hai khả năng, thay vì phải rà lần lượt security group, NACL, route table và cấu hình ứng dụng.

Đáp án

B — Chọn widget phù hợp và chọn chỉ số từ CUSTOM NAMESPACE, rồi thêm vào dashboard.

Vì sao đúng

Chi tiết quyết định: chỉ số do CloudWatch agent đẩy lên nằm ở NAMESPACE TUỲ CHỈNH, không nằm chung với chỉ số dựng sẵn của AWS.

⚠ Điểm mấu chốt — hai loại namespace hoàn toàn tách biệt:

Namespace của AWS
        ↓
    AWS/EC2, AWS/RDS, AWS/ApplicationELB, AWS/Lambda...
        ↓
    → chỉ số AWS tự cấp: CPU, mạng, đĩa (instance store)

Namespace TUỲ CHỈNH
        ↓
    Mặc định của CloudWatch agent: CWAgent
    Hoặc tên bạn tự đặt trong tệp cấu hình agent
        ↓
    → mem_used_percent, disk_used_percent, swap_used_percent
    → chỉ số của ứng dụng bạn tự đẩy lên

⚠ Quy trình tạo dashboard:

CloudWatch console → Dashboards → Create dashboard
        ↓
    Add widget → chọn loại (Line, Number, Gauge, Stacked area)
        ↓
    Trong danh sách namespace, chọn CWAgent
      (KHÔNG phải AWS/EC2)
        ↓
    Chọn chỉ số và dimension cần vẽ
        ↓
    → thêm vào dashboard

⚠ Và một chi tiết về dimension rất đáng nhớ:

Trong cấu hình agent, mục append_dimensions
        ↓
    ${aws:InstanceId}           → xem theo từng máy
    ${aws:AutoScalingGroupName} → xem trung bình cả nhóm
        ↓
    → dimension quyết định bạn NHÓM chỉ số theo chiều nào
        ↓
    Cảnh báo: mỗi tổ hợp dimension là MỘT CHỈ SỐ RIÊNG
              được tính tiền

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

• D (chọn AWS Namespace, lọc theo tên chỉ số, rồi thêm vào dashboard) — đây là phương án gần nhất và chỉ sai một từ: chỉ số tuỳ chỉnh KHÔNG nằm trong namespace của AWS. Tìm ở đó sẽ không thấy gì cả — và đây chính là chỗ nhiều người bối rối khi mới cài agent.

• C (mở CloudWatch Logs console, tạo metric filter, rồi chọn chỉ số) — metric filter dùng để biến MẪU TRONG LOG thành chỉ số. Nhưng chỉ số ở đây đã là chỉ số rồi — agent đã đẩy chúng lên qua PutMetricData, không cần biến đổi gì.

• A (từ CloudWatch Events, thêm tất cả chỉ số tuỳ chỉnh) — nhầm dịch vụ: CloudWatch Events (nay là EventBridge) xử lý SỰ KIỆN, không phải nơi quản lý chỉ số hay dashboard.

Ghi nhớ

⚠ Chỉ số EC2 có sẵn và phải cài agent — bảng phải thuộc: | Có sẵn (namespace AWS/EC2) | Phải cài CloudWatch agent (CWAgent) | |---|---| | CPUUtilization | mem_used_percent (RAM) | | NetworkIn / NetworkOut | disk_used_percent (đĩa còn trống) | | DiskReadBytes / DiskWriteBytes (instance store) | swap_used_percent | | StatusCheckFailed* | chỉ số theo tiến trình | | EBSReadOps / EBSWriteOps (Nitro) | log của ứng dụng |

Từ khoá nhận diện:

"chỉ số từ CloudWatch agent" → namespace CWAgent "RAM, dung lượng đĩa của EC2" → phải cài agent "biến mẫu trong log thành chỉ số" → metric filter "phản ứng khi có sự kiện xảy ra" → EventBridge "phản ứng khi chỉ số vượt ngưỡng" → CloudWatch Alarm

⚠ Dashboard là tài nguyên GLOBAL — nhắc lại: | Thành phần | Phạm vi | |---|---| | Dashboard | GLOBAL — mỗi widget khai Region riêng | | Metric | theo Region | | Alarm | theo Region | | Hệ quả | một dashboard xem được chỉ số của nhiều Region |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số có lên không | tìm namespace CWAgent trong CloudWatch | | Có những dimension nào | list-metrics --namespace CWAgent | | Vì sao không thấy | đọc log của chính agent tại /opt/aws/amazon-cloudwatch-agent/logs/ |

Và một mẹo nên áp dụng cho mọi dashboard dành cho đội trực: thêm một widget kiểu Text ở đầu, chứa link tới runbook và tên người trực. Dashboard tồn tại để được xem vào lúc hai giờ sáng bởi người có thể chưa từng thấy hệ thống này — và vài dòng Markdown chỉ ra "biểu đồ này bất thường thì làm gì" có giá trị hơn hẳn một widget đẹp thứ mười.

Đáp án

D — AWS Cost and Usage Report (CUR).

Vì sao đúng

Đề hỏi cách theo dõi việc PHÂN BỔ chiết khấu Reserved Instance trong hoá đơn gộp — và chỉ CUR có dữ liệu ở mức chi tiết đó.

⚠ Điểm mấu chốt — CUR là dữ liệu THÔ, chi tiết nhất mà AWS cung cấp:

Cost and Usage Report
        ↓
    Một dòng cho MỖI đơn vị sử dụng, MỖI giờ
        ↓
    Các cột dành riêng cho Reserved Instance:
        reservation/ReservationARN
        reservation/SubscriptionId
        reservation/AmortizedUpfrontFeeForBillingPeriod
        reservation/EffectiveCost
        reservation/UnusedQuantity
        lineItem/LineItemType = "DiscountedUsage"
        ↓
    → biết CHÍNH XÁC RI nào đã được áp cho
      TÀI KHOẢN nào, INSTANCE nào, GIỜ nào

⚠ Và vì sao điều này quan trọng với hoá đơn gộp:

Reserved Instance mua ở tài khoản A
        ↓
    Trong Organizations, chiết khấu được CHIA SẺ
    cho mọi tài khoản trong tổ chức
        ↓
    → tài khoản B, C có thể đang hưởng chiết khấu của A
        ↓
    → công ty cần biết AI hưởng BAO NHIÊU
      để phân bổ chi phí nội bộ cho đúng
        ↓
    → chỉ CUR trả lời được câu hỏi đó

⚠ Cách khai thác CUR:

CUR đổ vào một bucket S3 (định dạng CSV hoặc Parquet)
        ↓
    Bật tích hợp Athena → truy vấn bằng SQL
        ↓
    SELECT line_item_usage_account_id,
           SUM(reservation_effective_cost)
    FROM cur
    WHERE line_item_line_item_type = 'DiscountedUsage'
    GROUP BY 1;
        ↓
    Hoặc dựng bảng điều khiển bằng QuickSight

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

• C (AWS Budgets) — đây là phương án gần nhất về mặt "công cụ tài chính", và Budgets có loại ngân sách theo RI utilization và RI coverage. Nhưng nó dùng để đặt ngưỡng và cảnh báo, không phải để theo dõi việc phân bổ chiết khấu chi tiết trong hoá đơn gộp.

• A (AWS Organizations) — quản lý cấu trúc tài khoản, SCP, và bật thanh toán gộp. Nó không cung cấp dữ liệu chi phí chi tiết nào.

• B (Amazon Inspector) — dịch vụ quét lỗ hổng bảo mật. Không liên quan gì tới chi phí.

Ghi nhớ

⚠ Bộ công cụ chi phí — bảng phải thuộc: | Công cụ | Mức chi tiết | Việc | |---|---|---| | Cost and Usage Report (CUR) | chi tiết nhất — từng dòng, từng giờ | phân tích sâu, phân bổ nội bộ | | Cost Explorer | tổng hợp, có giao diện | xem nhanh, khuyến nghị rightsizing | | AWS Budgets | ngưỡng | cảnh báo khi vượt | | Cost Anomaly Detection | bất thường | phát hiện tăng đột biến | | Billing console | hoá đơn | tổng quan theo tháng |

Từ khoá nhận diện:

"phân bổ chiết khấu RI trong hoá đơn gộp" → CUR "dữ liệu chi phí chi tiết nhất" → CUR "cảnh báo khi RI utilization thấp" → Budgets "xem nhanh chi phí theo dịch vụ" → Cost Explorer "chi phí theo phòng ban" → cost allocation tag + Cost Explorer

⚠ Ba kiểu chiết khấu cam kết — bảng phải thuộc: | Kiểu | Linh hoạt | Đảm bảo dung lượng | |---|---|---| | Standard RI | ít nhất — cố định loại instance | zonal RI có | | Convertible RI | đổi được loại instance | có (zonal) | | Savings Plans | linh hoạt nhất — theo mức chi tiêu | KHÔNG | | Cả ba | cam kết 1 hoặc 3 năm, giảm tới 72% | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | RI đang được dùng bao nhiêu | Cost Explorer → RI Utilization report | | Bao nhiêu tải được RI phủ | RI Coverage report | | Ai hưởng chiết khấu | CUR + Athena, nhóm theo line_item_usage_account_id |

Và một lời khuyên khi thiết lập CUR: hãy chọn granularity theo GIỜ và bật "include resource IDs" ngay từ đầu. Hai tuỳ chọn này làm tệp lớn hơn đáng kể, nhưng chúng là thứ quyết định bạn có trả lời được câu hỏi "instance nào, giờ nào, tài khoản nào" hay không — và CUR không hồi tố: dữ liệu của tháng trước sẽ mãi mãi ở mức chi tiết mà bạn đã chọn lúc ấy.

Đáp án

C — Trong namespace AWS/ApplicationELB, đặt alarm khi chỉ số HealthyHostCount nhỏ hơn hoặc bằng 0.

Vì sao đúng

Đề hỏi "mọi target sau ALB đều không khoẻ" — và ALB có sẵn một chỉ số đếm đúng số target khoẻ.

⚠ Điểm mấu chốt — HealthyHostCount bằng 0 nghĩa là không còn máy nào phục vụ được:

HealthyHostCount
        ↓
    Số target ĐANG KHOẺ trong một target group
        ↓
    Bằng 0 → KHÔNG CÒN máy nào qua được health check
        ↓
    → alarm khi <= 0 là đúng điều kiện đề nêu

⚠ Vì sao phải dùng chỉ số của ALB chứ không phải của EC2:

Chỉ số EC2 (StatusCheckFailed) chỉ biết:
        "máy còn sống hay không"
        ↓
    Ứng dụng treo, cổng 8080 không trả lời
        ↓
    → EC2 status check vẫn PASS
    → nhưng ALB đánh dấu target là unhealthy
        ↓
    → chỉ ALB mới biết ỨNG DỤNG có phục vụ được không

⚠ Và một chi tiết quan trọng khi cấu hình alarm này:

HealthyHostCount có dimension theo TARGET GROUP
        ↓
    → nếu ALB có nhiều target group, phải đặt alarm cho TỪNG cái
        ↓
Thống kê nên dùng: Minimum
        ↓
    → vì chỉ số được báo cáo theo từng AZ
    → dùng Average có thể che mất việc một AZ đã hết máy khoẻ
        ↓
Treat missing data: notBreaching hay breaching?
        ↓
    → ALB ngừng phát chỉ số khi không có target nào ĐĂNG KÝ
    → cân nhắc "treat missing data as breaching" cho an toàn

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

• D (cùng namespace ALB, nhưng alarm khi HealthyHostCount >= 1) — đây là phương án gần nhất và đảo ngược điều kiện: nó sẽ kêu khi hệ thống đang khoẻ mạnh, và im lặng đúng lúc mọi máy đã chết.

• B (StatusCheckFailed_Instance >= 1 trong namespace EC2) — chỉ báo khi một máy có vấn đề ở tầng hệ điều hành. Nó không biết ứng dụng có phục vụ được không, và cũng không cho biết TẤT CẢ máy đã hỏng hay chưa.

• A (StatusCheckFailed_System <= 0 trong namespace EC2) — sai cả chỉ số lẫn điều kiện: StatusCheckFailed_System bằng 0 nghĩa là hạ tầng AWS đang BÌNH THƯỜNG, nên alarm này sẽ kêu liên tục khi mọi thứ vẫn tốt.

Ghi nhớ

⚠ Các chỉ số của ALB nên đặt cảnh báo — bảng phải thuộc: | Chỉ số | Cảnh báo khi | |---|---| | HealthyHostCount | = 0 — không còn máy nào phục vụ | | UnHealthyHostCount | tăng bất thường | | TargetResponseTime | p99 vượt ngưỡng — dùng p99, không dùng trung bình | | HTTPCode_Target_5XX_Count | ứng dụng đang lỗi | | HTTPCode_ELB_5XX_Count | load balancer không phục vụ được | | RejectedConnectionCount | chạm giới hạn kết nối |

Từ khoá nhận diện:

"mọi target đều unhealthy" → HealthyHostCount <= 0 "máy chết ở tầng hệ điều hành" → StatusCheckFailed_Instance "hạ tầng AWS lỗi" → StatusCheckFailed_System "ứng dụng treo nhưng máy vẫn sống" → ELB health check, không phải EC2 status check "tự thay máy hỏng" → ASG với health check type = ELB

⚠ Nhắc lại hành vi khi mọi target unhealthy — điều rất dễ bất ngờ:

Tất cả target trong một AZ đều unhealthy
        ↓
    ALB "FAIL OPEN": vẫn gửi request tới CHÍNH những target đó
        ↓
    → vì health check có thể báo sai
    → thà thử còn hơn từ chối mọi khách
        ↓
    → hệ quả: sự cố này KHÔNG hiện ra dưới dạng lỗi 503
    → khách vẫn nhận được trả lời, chỉ là từ máy đã hỏng
        ↓
    → đây chính là lý do PHẢI đặt alarm trên HealthyHostCount

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hiện có bao nhiêu máy khoẻ | chỉ số HealthyHostCount | | Vì sao máy không khoẻ | describe-target-health, trường Reason | | Alarm có kích hoạt đúng không | describe-alarm-history |

Và một lưu ý khi cấu hình alarm này cho hệ thống nhiều AZ: hãy dùng thống kê Minimum thay vì Average. ALB báo cáo HealthyHostCount theo từng Availability Zone, nên với hai AZ mà một AZ còn 4 máy khoẻ và AZ kia còn 0, giá trị trung bình vẫn là 2 — trông hoàn toàn bình thường, trong khi một nửa hệ thống của bạn đã ngừng phục vụ.

Đáp án

A, C — hai cách cho EC2 không có IP công cộng vẫn truy cập S3:

• A — Tạo VPC endpoint trong VPC và cấu hình route table cho phù hợp.
• C — Triển khai NAT Gateway ở public subnet và cấu hình route table của VPC.

Vì sao đúng

Cả hai đều cho phép instance ở private subnet ra ngoài mà không cần IP công cộng, nhưng theo hai đường khác nhau.

⚠ Cách A — VPC endpoint: đi trong mạng AWS, KHÔNG ra internet:

Gateway endpoint cho S3
        ↓
    Thêm một TUYẾN vào route table của private subnet:
        pl-xxxxxxx (prefix list của S3) → vpce-xxxxxxx
        ↓
    → lưu lượng tới S3 đi trong mạng riêng của AWS
    → KHÔNG bao giờ ra internet
        ↓
    → HOÀN TOÀN MIỄN PHÍ

⚠ Cách C — NAT Gateway: ra internet nhưng chỉ một chiều:

NAT Gateway đặt ở PUBLIC subnet
        ↓
    Route table của private subnet:
        0.0.0.0/0 → nat-xxxxxxx
        ↓
    → instance RA được internet (và tới S3)
    → KHÔNG AI từ internet vào được instance
        ↓
    → tính tiền theo giờ VÀ theo mỗi GB

⚠ Và đây là lời khuyên thực tế — nên dùng CẢ HAI:

Gateway endpoint cho S3 và DynamoDB (MIỄN PHÍ)
        +
NAT Gateway cho mọi thứ khác (tải gói, gọi API bên ngoài)
        ↓
    → lưu lượng S3 đi thẳng, KHÔNG qua NAT
    → cắt được phần lớn phí xử lý dữ liệu của NAT
        ↓
    → đây là mẹo tiết kiệm chi phí lớn nhất
      liên quan tới VPC endpoint

Xem thêm câu #11763 và #11589: cùng chủ đề truy cập riêng tư tới S3 — #11763 cho File Gateway (chọn VPC endpoint vì rẻ nhất), #11589 cho instance cần tải bản vá (chọn NAT Gateway).

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

• B (dựng Direct Connect và cấu hình virtual interface giữa EC2 và S3) — đây là phương án gần nhất về mặt "kết nối riêng tư", nhưng hiểu sai công dụng: Direct Connect nối trung tâm dữ liệu TẠI CHỖ với AWS. EC2 đã nằm trong AWS rồi, không cần Direct Connect để tới S3.

• E (cấu hình Internet Gateway để định tuyến kết nối tới S3 bằng IP riêng) — IGW không làm việc đó: nó chỉ chuyển tiếp lưu lượng ra internet bằng IP công cộng. Và đề nói rõ là bỏ IP công cộng đi.

• D (thêm luật outbound vào Security Group cho S3 bằng IP riêng) — Security Group mặc định đã cho phép mọi lưu lượng đi ra. Và S3 không có IP riêng nào để khai — nó là dịch vụ công khai.

Ghi nhớ

⚠ Hai loại VPC endpoint — bảng phải thuộc: | | Gateway endpoint | Interface endpoint (PrivateLink) | |---|---|---| | Dịch vụ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS | | Chi phí | MIỄN PHÍ | theo giờ + theo GB | | Cơ chế | tuyến trong route table | ENI có IP riêng trong subnet | | Máy tại chỗ dùng được | KHÔNG | CÓ (qua DX/VPN) | | Bảo mật thêm | endpoint policy | endpoint policy + Security Group |

Từ khoá nhận diện:

"truy cập S3 từ private subnet, rẻ nhất" → gateway endpoint (miễn phí) "private subnet cần ra internet nói chung" → NAT Gateway "truy cập S3 từ TẠI CHỖ" → interface endpoint hoặc DX public VIF "IGW cho IP riêng" → KHÔNG LÀM ĐƯỢC "bỏ IP công cộng nhưng vẫn cần tải bản vá" → NAT Gateway

⚠ Mẹo tiết kiệm chi phí lớn nhất với VPC endpoint:

VPC có NAT Gateway, fleet đọc ghi S3 nhiều
        ↓
    Không có gateway endpoint
        ↓
    → mọi lưu lượng S3 đi qua NAT Gateway
    → tính phí XỬ LÝ DỮ LIỆU theo từng GB
        ↓
    Thêm gateway endpoint cho S3 (MIỄN PHÍ)
        ↓
    → lưu lượng S3 đi thẳng
    → cắt được một khoản đáng kể mỗi tháng
        ↓
    → nên làm cho MỌI VPC có NAT Gateway

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Endpoint đã tạo chưa | describe-vpc-endpoints | | Route table đã có tuyến chưa | gateway endpoint thêm tuyến — kiểm tra đúng bảng | | Instance ra được S3 chưa | từ trong máy: aws s3 ls |

Và một việc nên làm ngay trong mọi VPC đang có NAT Gateway: thêm gateway endpoint cho S3 và DynamoDB. Chúng hoàn toàn miễn phí, cấu hình mất vài phút, và với một fleet thường xuyên đọc ghi S3 thì chúng cắt đi phần lớn phí xử lý dữ liệu của NAT — một khoản mà rất nhiều đội trả đều đặn hằng tháng suốt nhiều năm mà không biết rằng nó hoàn toàn tránh được.