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

Đáp án

B — Công ty tạo IAM role với quyền cần thiết; khách hàng dùng ARN của role đó để xin quyền, và trust policy của role có kèm external ID.

Vì sao đúng

Đây là bài toán truy cập liên tài khoản cho bên thứ ba, và AWS có một mẫu chuẩn duy nhất cho nó: IAM role + sts:AssumeRole + external ID.

⚠ Điểm mấu chốt: external ID chống lại "confused deputy" — kịch bản mà không có nó thì role bị lợi dụng:

Không có external ID:
    Công ty tạo role tin tài khoản của khách hàng A
        ↓
    Khách hàng A cũng là nhà cung cấp dịch vụ cho khách hàng B
        ↓
    B lừa được A gọi AssumeRole vào role của bạn
        ↓
    → A trở thành "phó thác bị lẫn lộn": dùng quyền của mình cho việc của B

Có external ID:
    Trust policy đòi sts:ExternalId khớp một chuỗi bí mật
        ↓
    Chỉ ai biết chuỗi đó mới assume được
        ↓
    → B không biết chuỗi ấy nên không lợi dụng được

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::444455556666:root"},
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {"sts:ExternalId": "khach-hang-a-9f3c2e8b41"}
  }
}

Khách hàng gọi vào bằng CLI:

aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/DichVuChoKhach \
  --role-session-name phien-cua-khach \
  --external-id khach-hang-a-9f3c2e8b41

⚠ External ID KHÔNG phải là bí mật cần bảo vệ như mật khẩu — nó là định danh chống nhầm lẫn:

Vai trò của external ID: đảm bảo bên thứ ba chỉ dùng role ĐÚNG cho khách ĐÚNG
        ↓
    Nó không thay thế việc giới hạn principal trong trust policy
        ↓
    → phải có CẢ hai: principal đúng VÀ external ID

Nguyên tắc thực hành: mỗi khách hàng một external ID riêng, do bên cung cấp dịch vụ sinh ra (không để khách tự chọn).

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

• C (IAM role + khách dùng ARN của role, KHÔNG có external ID) — đây là phương án gần nhất và nó đã đúng về mô hình: role liên tài khoản với thông tin đăng nhập tạm thời là cách làm chuẩn, tốt hơn hẳn hai phương án còn lại. Nó chỉ thiếu đúng một lớp bảo vệ, và đề hỏi "MOST secure" nên lớp đó là yếu tố quyết định. Không có external ID, bất kỳ ai biết được ARN của role — mà ARN không phải bí mật, nó xuất hiện trong tài liệu, trong log, trong ticket hỗ trợ — và điều khiển được tài khoản đã được tin tưởng đều có thể assume vào. Với kịch bản nhà cung cấp dịch vụ phục vụ nhiều khách hàng, đây chính là lỗ hổng confused deputy mà AWS khuyến nghị external ID để bịt.

• A (đưa access key của tài khoản công ty cho khách hàng) — vi phạm nghiêm trọng mọi nguyên tắc. Đây là thông tin đăng nhập dài hạn, không hết hạn, không giới hạn phạm vi, không truy vết được ai đã dùng. Chia sẻ chúng cho một tổ chức khác nghĩa là trao toàn bộ quyền của danh tính đó, và thu hồi thì phải xoay khoá và cập nhật mọi nơi đang dùng.

• D (tạo IAM user riêng rồi đưa thông tin đăng nhập cho khách) — khá hơn A một chút vì phạm vi hẹp hơn, nhưng vẫn là thông tin đăng nhập dài hạn được chia sẻ. Không biết ai bên phía khách đang dùng, không tự hết hạn, và mỗi khách hàng mới là một user mới phải quản lý. AWS khuyến nghị rõ: không tạo IAM user cho người hoặc hệ thống ngoài tổ chức — dùng role.

Ghi nhớ

⚠ Bốn cách cho bên ngoài truy cập, xếp theo mức an toàn: | Cách | Thời hạn | Truy vết | Đánh giá | |---|---|---|---| | Role + AssumeRole + external ID | tạm thời (1–12 giờ) | có, qua CloudTrail | chuẩn mực | | Role + AssumeRole, không external ID | tạm thời | có | tốt, thiếu một lớp | | IAM user riêng cho khách | vĩnh viễn | mờ | không nên | | Chia sẻ access key của mình | vĩnh viễn | không | không bao giờ |

Từ khoá nhận diện:

"customer in a separate AWS account" → cross-account role "MOST secure" + bên thứ ba → phải có external ID "least privilege" + API/CLI → role với thông tin đăng nhập tạm thời "provide access keys" / "provide credentials" → LUÔN SAI "create an IAM user for the customer" → SAI, dùng role

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đã assume role | CloudTrail, sự kiện AssumeRole, xem sourceIdentity | | Role có quá rộng không | IAM Access Analyzer, xem quyền chưa dùng tới | | External ID có bắt buộc không | thử assume không kèm external ID — phải bị từ chối |

Và một lời khuyên: hãy thử assume role mà KHÔNG kèm external ID và xác nhận rằng nó bị từ chối. Đây là chỗ cấu hình hay sai mà không ai phát hiện: nếu điều kiện sts:ExternalId bị viết nhầm khoá, viết sai chính tả, hoặc đặt nhầm vào khối StringLike với ký tự đại diện, thì trust policy vẫn hợp lệ, vẫn lưu được, vẫn hiện đầy đủ trong console — và luồng làm việc bình thường của khách hàng vẫn chạy trơn tru vì họ luôn gửi kèm external ID đúng. Lớp bảo vệ đã biến mất nhưng không có bất kỳ triệu chứng nào cho thấy điều đó. Cách duy nhất để biết là chủ động thử con đường mà lẽ ra phải bị chặn.

Đáp án

B — Thêm CIDR IPv6 do Amazon cấp cho VPC và các subnet; public subnet định tuyến ::/0 tới internet gateway, private subnet định tuyến ::/0 tới egress-only internet gateway.

Vì sao đúng

Với IPv6, mô hình mạng đổi căn bản: mọi địa chỉ IPv6 đều là địa chỉ công cộng, có thể định tuyến toàn cầu. Không còn khái niệm "địa chỉ riêng" như IPv4. Vì thế AWS tạo ra một thành phần chuyên biệt để giữ được tính chất "chỉ đi ra".

⚠ Điểm mấu chốt: egress-only internet gateway là bản IPv6 của NAT — nó cho ra, chặn vào, mà không dịch địa chỉ:

Instance IPv6 trong private subnet mở kết nối ra ngoài
        ↓
    Đi qua egress-only internet gateway
        ↓
    Gói trả về được cho vào (nó CÓ TRẠNG THÁI)
        ↓
    Kết nối do bên ngoài chủ động khởi tạo → BỊ CHẶN
        ↓
    → giữ được đúng tính chất của private subnet mà không cần NAT

Khác biệt quan trọng với NAT gateway: egress-only IGW không dịch địa chỉ. Instance vẫn giữ nguyên địa chỉ IPv6 toàn cầu của nó; thứ egress-only IGW làm là lọc chiều kết nối, dựa trên trạng thái. Đây là lý do nó tồn tại như một thành phần riêng chứ không phải là "NAT cho IPv6".

# thêm CIDR IPv6 do Amazon cấp
aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-abc --amazon-provided-ipv6-cidr-block

# egress-only internet gateway
aws ec2 create-egress-only-internet-gateway --vpc-id vpc-abc

# private subnet: chỉ đi ra
aws ec2 create-route --route-table-id rtb-private \
  --destination-ipv6-cidr-block ::/0 \
  --egress-only-internet-gateway-id eigw-abc

# public subnet: ra vào bình thường
aws ec2 create-route --route-table-id rtb-public \
  --destination-ipv6-cidr-block ::/0 --gateway-id igw-abc

⚠ CIDR IPv6 do Amazon cấp là bắt buộc trừ khi bạn tự mang dải của mình (BYOIP):

"Custom IPv6 CIDR block" không phải thứ bạn tự bịa ra
        ↓
    IPv6 định tuyến toàn cầu — dải phải được cấp phát hợp lệ
        ↓
    → hoặc dùng dải Amazon cấp (/56 cho VPC, /64 cho subnet)
        ↓
    → hoặc mang dải bạn sở hữu qua BYOIP, một quy trình xác minh riêng

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

• A (CIDR IPv6 tuỳ chọn, dựng "NAT gateway hỗ trợ IPv6", private subnet định tuyến ::/0 qua đó) — đây là phương án gần nhất và cấu trúc suy nghĩ của nó đúng: nó nhận ra private subnet cần một thứ khác public subnet, và nó đi tìm cơ chế "chỉ ra không vào". Nhưng nó gọi sai thành phần. NAT gateway của AWS chỉ hoạt động với IPv4 — không có "IPv6-enabled NAT gateway" theo nghĩa phương án này mô tả. (AWS có NAT64/DNS64 để instance chỉ có IPv6 nói chuyện được với dịch vụ chỉ có IPv4, nhưng đó là bài toán khác hẳn: dịch giữa hai giao thức, không phải bảo vệ chiều kết nối.) Thêm nữa, "custom IPv6 CIDR" cũng không đúng: dải IPv6 phải do Amazon cấp hoặc do bạn mang tới qua BYOIP.

• C (egress-only IGW cho CẢ public lẫn private subnet) — dùng đúng thành phần nhưng áp sai chỗ. Đặt egress-only IGW cho public subnet nghĩa là các tài nguyên ở đó không nhận được kết nối từ Internet nữa — mà public subnet tồn tại chính để làm việc đó. Nó cũng lặp lại lỗi "custom IPv6 CIDR".

• D (định tuyến ::/0 của cả hai loại subnet qua NAT gateway hiện có) — NAT gateway hiện có chỉ xử lý IPv4; nó không nhận tuyến IPv6. Ngoài ra đẩy public subnet qua NAT là làm mất khả năng nhận kết nối vào của nó.

Ghi nhớ

⚠ Bốn thành phần định tuyến ra Internet — bảng phải thuộc: | Thành phần | Giao thức | Chiều | |---|---|---| | Internet gateway | IPv4 + IPv6 | cả vào lẫn ra | | NAT gateway | chỉ IPv4 | chỉ ra | | Egress-only internet gateway | chỉ IPv6 | chỉ ra | | NAT64 + DNS64 | IPv6 → dịch vụ IPv4 | chỉ ra, có dịch giao thức |

Từ khoá nhận diện:

"IPv6" + "private subnets must not be reachable from the internet" → egress-only internet gateway "Amazon-provided IPv6 CIDR block" → đúng, đây là cách chuẩn "custom IPv6 CIDR block" → SAI trừ khi có BYOIP "IPv6-enabled NAT gateway" → LUÔN SAI, NAT gateway chỉ IPv4 "egress-only gateway cho public subnet" → SAI, public subnet cần nhận kết nối vào

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ra ngoài có được không | từ instance private: curl -6 https://checkip.amazonaws.com | | Vào có bị chặn không | từ máy ngoài, thử kết nối tới địa chỉ IPv6 của instance private | | Security group đã có rule IPv6 chưa | kiểm Ipv6Ranges chứ không chỉ IpRanges |

Và một lời khuyên: hãy rà lại toàn bộ security group để thêm rule IPv6 ngay khi bật IPv6, và kiểm tra từ bên ngoài xem private subnet có thật sự không vào được. Đây là chỗ nguy hiểm nhất của việc chuyển sang IPv6, và nó nguy hiểm theo cả hai chiều. Rule security group viết cho 0.0.0.0/0 không áp dụng cho lưu lượng IPv6 — nên một rule bạn tưởng đang chặn thì thực ra không chặn gì cả trên đường IPv6, và một rule bạn tưởng đang cho phép thì lưu lượng IPv6 lại bị từ chối. Không có cảnh báo nào cho sự lệch pha này; hệ thống chỉ đơn giản là hành xử khác đi trên một giao thức mà phần lớn công cụ giám sát của bạn chưa được cấu hình để nhìn tới.

Đáp án

B, C — hai bước để tính được chi phí theo dự án/môi trường và giới hạn dịch vụ được triển khai:

• B — Gắn tag environment, cost center và application name cho mọi tài nguyên hỗ trợ tag.
• C — Tạo AWS Service Catalog portfolio cho từng đơn vị kinh doanh, thêm product bằng CloudFormation template.

Vì sao đúng

Đề nêu hai yêu cầu tách bạch, và mỗi phương án đúng lo trọn một yêu cầu.

⚠ Điểm mấu chốt: tài khoản riêng chỉ tách được MÔI TRƯỜNG, không tách được DỰ ÁN — nên phải có tag:

Công ty có tài khoản dev / staging / production
        ↓
    Chi phí theo môi trường: đã có sẵn từ consolidated billing
        ↓
    Nhưng trong một tài khoản có NHIỀU dự án chạy song song
        ↓
    → không có cách nào tách chi phí theo dự án nếu không gắn tag

Đây là lý do B là bắt buộc chứ không phải tuỳ chọn. Đề đòi tính chi phí theo cả hai chiều — dự án và môi trường — mà ranh giới tài khoản chỉ cho một chiều.

Tag phải đi kèm bước kích hoạt, nếu không nó vô hình trong báo cáo chi phí:

# gắn tag cho tài nguyên
aws ec2 create-tags --resources i-0abc123 \
  --tags Key=MoiTruong,Value=production \
         Key=CostCenter,Value=CC-1042 \
         Key=UngDung,Value=dat-hang

# rồi PHẢI kích hoạt làm cost allocation tag trong Billing console

C — vì sao Service Catalog là câu trả lời cho vế quản trị. Đề đòi "commonly deployed IT services must be centrally managed" và "business units restricted to deploying pre-approved IT services only". Đó là mô tả nguyên văn chức năng của Service Catalog: một danh mục product đã duyệt, tổ chức thành portfolio, chia sẻ tới các đơn vị, và người dùng chỉ dựng được thứ có trong đó.

Đội hạ tầng trung tâm
        ↓
    Viết CloudFormation template cho các mẫu chuẩn (VPC, RDS, EC2 đã cứng hoá)
        ↓
    Đưa lên làm product trong portfolio của từng đơn vị
        ↓
    Đơn vị kinh doanh chỉ thấy và chỉ dựng được product trong portfolio của mình
        ↓
    → không dựng được gì ngoài danh mục

⚠ Tag nên được nhúng thẳng vào template Service Catalog, đừng trông vào việc người dùng nhớ gắn:

TagOptions của Service Catalog áp tag tự động cho mọi tài nguyên do product dựng
        ↓
    → tag trở thành hệ quả của việc dùng danh mục, không phải một bước riêng phải nhớ

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

• A (đặt ngân sách tuỳ chỉnh và ngưỡng bằng AWS Cost Explorer) — đây là phương án gần nhất về mặt chủ đề và kiểm soát chi phí đúng là một phần bức tranh. Nhưng nó sai ở hai điểm. Thứ nhất, ngân sách và ngưỡng được tạo trong AWS Budgets, không phải Cost Explorer — Cost Explorer là công cụ phân tích và trực quan hoá, không phải nơi đặt ngân sách. Thứ hai, và quan trọng hơn: cảnh báo ngân sách không phải là năng lực tính chi phí theo dự án. Muốn đặt được ngân sách cho một dự án thì trước hết phải có cách nhận ra chi phí nào thuộc dự án nào — tức là phải có tag trước đã. Phương án này giả định bước B đã xong.

• D (dùng AWS Savings Plans để đặt ngưỡng ngân sách và gửi cảnh báo) — nhầm hoàn toàn về bản chất dịch vụ. Savings Plans là một mô hình giá — cam kết chi tiêu một mức nhất định mỗi giờ trong 1 hoặc 3 năm để đổi lấy giảm giá. Nó không đặt ngưỡng, không gửi cảnh báo, không kiểm soát ai tiêu gì. Đây là phương án chỉ giống đúng ở chỗ có chữ "ngân sách" trong mô tả.

• E (CloudWatch billing alarm báo cho quản lý khi vượt ngưỡng) — có thật và dùng được, nhưng nó chỉ báo động, không đáp ứng yêu cầu nào trong hai yêu cầu của đề. Billing alarm cũng rất thô: nó theo dõi tổng chi phí ước tính, không tách được theo dự án nếu chưa có tag. Ngoài ra AWS Budgets đã thay thế phần lớn công dụng của nó với khả năng lọc theo tag, theo dịch vụ, theo tài khoản.

Ghi nhớ

⚠ Bốn công cụ quản trị chi phí — bảng phải thuộc, và đừng lẫn chúng: | Công cụ | Việc | |---|---| | Cost Explorer | phân tích và trực quan hoá — KHÔNG tạo ngân sách | | AWS Budgets | đặt ngưỡng và cảnh báo | | Cost and Usage Report | dữ liệu chi tiết nhất, xuất ra S3 | | Savings Plans / RI | mô hình giá, không phải công cụ quản trị |

Từ khoá nhận diện:

"calculate costs per project AND per environment" → tag (tài khoản chỉ tách được một chiều) "pre-approved IT services only" → Service Catalog "centrally managed" + hạ tầng chuẩn → Service Catalog + CloudFormation "custom budgets using Cost Explorer" → SAI, ngân sách nằm ở AWS Budgets "Savings Plans to configure budget thresholds" → LUÔN SAI, đó là mô hình giá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tag đã kích hoạt chưa | Billing console → Cost allocation tags → trạng thái Active | | Tỷ lệ chi phí có tag | Cost Explorer, nhóm theo tag, xem phần "No tag key" lớn bao nhiêu | | Đơn vị có dựng được thứ ngoài danh mục không | thử bằng chính danh tính người dùng cuối |

Và một lời khuyên: hãy theo dõi tỷ lệ chi phí KHÔNG có tag như một chỉ số riêng, hằng tháng. Đây là chỗ chiến lược tag mục ruỗng một cách âm thầm: bạn triển khai tag, mọi thứ được gắn đầy đủ, báo cáo theo dự án chạy đẹp trong vài tháng đầu. Rồi ai đó dựng tài nguyên bằng tay cho một việc gấp, một template cũ được dùng lại, một dịch vụ mới ra mắt chưa được đưa vào chuẩn. Chi phí của chúng không biến mất — chúng dồn vào mục "No tag key", một dòng mà không ai mở ra xem vì báo cáo theo dự án vẫn hiện đầy đủ các dự án. Đến khi có người đối chiếu tổng các dự án với hoá đơn thật thì khoảng cách đã lên tới hai chữ số phần trăm.

Đáp án

D, E — hai cách để EC2 trong VPC phân giải được địa chỉ riêng của VPC interface endpoint:

• D — Cấu hình DNS trên máy chủ Active Directory chuyển tiếp mọi truy vấn KHÔNG thuộc thẩm quyền của nó tới VPC Resolver.
• E — Dựng Route 53 Resolver outbound endpoint, đặt luật chuyển tiếp có điều kiện cho tên miền Active Directory tới máy chủ AD, và đặt DHCP options set dùng AmazonProvidedDNS.

Vì sao đúng

Nguyên nhân sự cố nằm gọn trong một câu của đề: DHCP options set trỏ DNS về máy chủ Active Directory. Từ đó mọi truy vấn DNS của EC2 đi tới AD, và AD không biết gì về tên riêng của interface endpoint.

⚠ Điểm mấu chốt: bản ghi DNS riêng của VPC endpoint CHỈ có ở VPC Resolver tại địa chỉ base+2:

VPC Resolver nằm ở địa chỉ CIDR-của-VPC + 2 (ví dụ 10.0.0.2)
        ↓
    Nó là nơi duy nhất biết tên riêng của interface endpoint,
    của RDS, của ElastiCache, của mọi private hosted zone gắn với VPC
        ↓
    DHCP options set trỏ đi nơi khác
        ↓
    → toàn bộ lớp tên riêng đó biến mất khỏi tầm nhìn của EC2

Hai phương án đúng giải quyết cùng một vấn đề theo hai hướng ngược nhau — và đó chính là điều làm chúng thành một cặp hợp lý.

D — giữ AD làm DNS chính, cho nó chuyển tiếp phần nó không biết:

EC2 hỏi AD (theo DHCP options set hiện tại)
        ↓
    Tên thuộc miền AD → AD tự trả lời
        ↓
    Tên KHÔNG thuộc miền AD (ví dụ endpoint) → chuyển tiếp tới 10.0.0.2
        ↓
    → VPC Resolver trả lời, AD chuyển kết quả về

Chữ "non-authoritative" là chi tiết quyết định. Chuyển tiếp mọi truy vấn (phương án C) sẽ gửi cả truy vấn về chính miền AD đi nơi khác — mà VPC Resolver không biết gì về miền đó, nên việc gia nhập miền và đăng nhập sẽ hỏng.

E — đổi sang VPC Resolver làm DNS chính, cho nó chuyển tiếp ngược lại phần của AD:

# outbound endpoint: VPC Resolver gửi truy vấn RA máy chủ AD
aws route53resolver create-resolver-endpoint \
  --direction OUTBOUND --name ra-ad \
  --security-group-ids sg-resolver \
  --ip-addresses SubnetId=subnet-a SubnetId=subnet-b

# luật: tên thuộc miền AD thì hỏi máy chủ AD
aws route53resolver create-resolver-rule \
  --rule-type FORWARD --domain-name congty.local \
  --resolver-endpoint-id rslvr-out-abc \
  --target-ips Ip=10.0.1.10,Port=53 Ip=10.0.2.10,Port=53

⚠ Hướng của Resolver endpoint hay bị nhầm — nhớ theo chiều truy vấn ĐI: | Hướng | Truy vấn đi từ | Tới | |---|---|---| | Outbound | VPC | DNS bên ngoài (AD, on-premises) | | Inbound | mạng ngoài | VPC Resolver |

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

• C (cấu hình AD chuyển tiếp TẤT CẢ truy vấn tới VPC Resolver) — đây là phương án gần nhất và nó chỉ khác D đúng một từ: cùng ý tưởng chuyển tiếp từ AD sang VPC Resolver, cùng hướng giải quyết. Nhưng "tất cả" thay vì "không thuộc thẩm quyền" phá hỏng chính vai trò của AD. Domain controller là nơi có thẩm quyền cho miền của nó — nó giữ các bản ghi SRV mà máy khách cần để tìm dịch vụ Kerberos, LDAP, để gia nhập miền và để đăng nhập. Chuyển tiếp mọi thứ đi nghĩa là AD hỏi VPC Resolver về chính những bản ghi mà nó đang giữ; VPC Resolver không biết miền đó nên trả về không tìm thấy, và toàn bộ chức năng Active Directory sụp đổ. Đây là bẫy tinh vi nhất của câu hỏi vì nó chữa được đúng triệu chứng được nêu trong khi phá vỡ một thứ đề không nhắc tới.

• A (dựng Resolver INBOUND endpoint với luật chuyển tiếp có điều kiện cho miền AD) — sai hướng. Inbound endpoint dùng khi mạng bên ngoài muốn truy vấn VÀO VPC Resolver; ở đây nhu cầu là VPC Resolver cần hỏi RA máy chủ AD, tức là outbound. Luật chuyển tiếp có điều kiện chỉ gắn được với outbound endpoint.

• B (đặt VPC Resolver làm DNS phụ trên các EC2) — không đáng tin về hành vi. DNS phụ chỉ được dùng khi DNS chính không phản hồi, không phải khi nó trả về "không tìm thấy". Vì AD có phản hồi — nó trả lời NXDOMAIN — máy khách coi như đã có câu trả lời và không bao giờ hỏi tới máy chủ thứ hai. Đây là hiểu nhầm phổ biến về cách hoạt động của danh sách DNS server.

Ghi nhớ

⚠ Bốn điều về DNS trong VPC — bảng phải thuộc: | Điều | Nội dung | |---|---| | Địa chỉ VPC Resolver | CIDR của VPC + 2 (và 169.254.169.253) | | Chỉ nó biết | tên riêng của endpoint, RDS, ELB nội bộ, private hosted zone | | Hai thuộc tính VPC | enableDnsSupport và enableDnsHostnames — phải bật cả hai | | DHCP options set | quyết định EC2 hỏi ai |

Từ khoá nhận diện:

"DHCP options set trỏ về máy chủ AD" + không phân giải được endpoint → đúng nguyên nhân "forward all non-authoritative queries" → đúng, giữ AD làm chủ miền của nó "forward ALL queries" từ AD đi → SAI, phá hỏng chính miền AD "inbound resolver" khi VPC cần hỏi ra ngoài → SAI hướng "đặt làm DNS phụ" để bù cho NXDOMAIN → SAI, DNS phụ chỉ dùng khi chính không phản hồi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | EC2 đang hỏi ai | cat /etc/resolv.conf trên chính máy đó | | VPC Resolver có trả lời đúng không | dig @<cidr+2> như bảng trên | | Miền AD còn phân giải được không | dig _ldap._tcp.congty.local SRV |

Và một lời khuyên: hãy kiểm tra bản ghi SRV của miền AD sau MỌI thay đổi về chuyển tiếp DNS. Đây là kiểu hỏng có sức tàn phá lớn nhất mà lại xuất hiện chậm nhất: sau khi bạn sửa cấu hình chuyển tiếp, endpoint phân giải được ngay — vấn đề ban đầu coi như đã xong, và mọi máy đang chạy vẫn hoạt động bình thường vì chúng đã đăng nhập từ trước và đang giữ vé Kerberos còn hiệu lực. Sự cố chỉ nổ ra vài giờ sau, khi vé hết hạn hoặc khi có máy mới cần gia nhập miền, dưới dạng những lỗi xác thực rải rác mà không ai liên hệ được với thay đổi DNS đã làm từ lâu.

Đáp án

B — Dựng Step Functions workflow chạy các hàm Lambda song song; tạo một Lambda lấy danh sách tệp và ghi từng mục vào hàng đợi SQS; một Lambda khác đọc tin nhắn từ hàng đợi và gọi StartExecution.

Vì sao đúng

Đề đã làm xong nửa việc: tách một hàm Lambda lớn thành nhiều hàm theo loại ảnh. Việc còn lại là chạy chúng song song và điều phối ở quy mô lớn. Phương án B giải cả hai bằng hai cơ chế riêng.

⚠ Điểm mấu chốt: SQS nằm giữa để việc liệt kê không bị giới hạn tần suất của StartExecution bóp nghẹt:

Lambda liệt kê tệp — có thể ra hàng trăm nghìn mục rất nhanh
        ↓
    Ghi mỗi mục thành một tin nhắn SQS (rất rẻ, rất nhanh)
        ↓
    Lambda thứ hai đọc hàng đợi, gọi StartExecution theo nhịp
        ↓
    Chạm giới hạn tần suất → tin nhắn quay lại hàng đợi, thử lại sau
        ↓
    → không mất mục nào, và tốc độ tự điều tiết

Đây là phần thực chất của câu hỏi. StartExecution có giới hạn tần suất; gọi nó trực tiếp trong một vòng lặp trên hàng trăm nghìn tệp sẽ bị throttle, và những lời gọi thất bại biến mất nếu không có nơi hứng. SQS biến vấn đề đó thành chuyện tự khắc phục.

# Lambda đọc SQS rồi khởi động workflow
import boto3, json
sfn = boto3.client('stepfunctions')

def handler(su_kien, ngu_canh):
    for ban_ghi in su_kien['Records']:
        sfn.start_execution(
            stateMachineArn='arn:aws:states:ap-southeast-1:111122223333:stateMachine:TrichXuat',
            input=ban_ghi['body'])

Còn phần song song nằm trong định nghĩa máy trạng thái:

{
  "Type": "Parallel",
  "Branches": [
    {"StartAt": "TrichPhongCanh", "States": {"TrichPhongCanh": {"Type": "Task", "Resource": "arn:...:ham-phong-canh", "End": true}}},
    {"StartAt": "TrichChanDung",  "States": {"TrichChanDung":  {"Type": "Task", "Resource": "arn:...:ham-chan-dung",  "End": true}}}
  ],
  "End": true
}

⚠ Lịch sử thực thi của Step Functions có trần 25.000 sự kiện — workflow quá dài sẽ chết giữa chừng:

Nhồi hàng nghìn tệp vào MỘT lần thực thi
        ↓
    Mỗi bước sinh vài sự kiện trong lịch sử
        ↓
    Chạm 25.000 → thực thi thất bại
        ↓
    → vì thế mỗi tệp nên là một lần thực thi riêng, đúng như phương án B làm

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

• A (Step Functions song song + một workflow Step Functions khác lấy danh sách tệp và gọi workflow trích xuất cho từng tệp) — đây là phương án gần nhất và phần song song của nó giống hệt đáp án đúng; ý tưởng dùng một workflow điều phối cũng không vô lý. Nó thua ở khâu điều tiết. Không có bộ đệm giữa việc liệt kê và việc khởi động, workflow điều phối sẽ đâm thẳng vào giới hạn tần suất của StartExecution khi thư viện lớn, và nó cũng tự chạm trần 25.000 sự kiện lịch sử nếu lặp qua quá nhiều tệp trong một lần thực thi. (Step Functions có Distributed Map ra đời sau để giải đúng bài toán này, nhưng phương án A không nhắc tới nó — nó chỉ nói "một workflow khác lấy danh sách và thực thi cho từng tệp", tức là mẫu vòng lặp thường.) Không có SQS thì mọi lời gọi bị throttle đều là một tệp bị bỏ sót, và không có gì báo cho bạn biết.

• D (Lambda ghi danh sách tệp vào SQS, các hàm trích xuất đăng ký đọc hàng đợi với batch size lớn) — bỏ mất tính song song, thứ chính là mục tiêu của đề. Nếu các hàm cùng đọc chung một hàng đợi thì mỗi tin nhắn chỉ được một hàm nhận — nghĩa là mỗi ảnh chỉ được xử lý bởi một loại trích xuất, không phải tất cả. Muốn nhiều hàm cùng nhận một sự kiện thì phải dùng SNS fan-out hoặc EventBridge, không phải một SQS dùng chung. Batch size lớn cũng làm mỗi lời gọi chạy lâu hơn, đi ngược mục tiêu giảm thời gian.

• C (dựng AWS Batch compute environment cho mỗi hàm Lambda) — nhầm lẫn hai mô hình thực thi. AWS Batch chạy job trong container trên EC2 hoặc Fargate, không chạy hàm Lambda; "compute environment cho mỗi Lambda function" là một cấu trúc không tồn tại. Batch phù hợp với job tính toán nặng, chạy lâu — còn ở đây là các tác vụ trích xuất metadata ngắn, đúng hình thái của Lambda.

Ghi nhớ

⚠ Bốn cách chạy song song trong Step Functions — bảng phải thuộc: | Cách | Dùng khi | |---|---| | Parallel state | số nhánh cố định, biết trước — đúng bài này | | Map state (inline) | lặp trên một mảng, tối đa 40 nhánh đồng thời | | Distributed Map | lặp trên hàng triệu mục từ S3, tới 10.000 nhánh đồng thời | | Nhiều lần thực thi độc lập | mỗi mục một execution — đơn giản và co giãn tốt nhất |

Từ khoá nhận diện:

"run the Lambda functions in parallel" → Step Functions Parallel state "can take up to 60 minutes" → vượt trần 15 phút của Lambda, cần điều phối "retrieve a list of files" ở quy mô lớn → cần bộ đệm, đừng gọi StartExecution trực tiếp "AWS Batch compute environment for each Lambda" → LUÔN SAI, Batch không chạy Lambda nhiều hàm cùng đọc một SQS để mỗi hàm đều xử lý → SAI, mỗi tin nhắn chỉ một bên nhận

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bị throttle không | chỉ số ExecutionsFailed và lỗi ThrottlingException | | Có tệp nào bị bỏ sót không | so số tin nhắn vào hàng đợi với số lần thực thi thành công | | Nhánh nào chậm nhất | xem biểu đồ thời gian trong console Step Functions |

Và một lời khuyên: hãy đối chiếu số mục đã đưa vào hàng đợi với số lần thực thi hoàn thành, đừng chỉ nhìn tỷ lệ thành công. Đây là kiểu mất việc âm thầm đặc trưng của các đường ống điều phối: nếu bạn gọi StartExecution trực tiếp mà không có hàng đợi, những lời gọi bị throttle sẽ ném ngoại lệ trong một vòng lặp mà thường không ai bắt — vòng lặp chạy tiếp, hàm kết thúc "thành công", và tỷ lệ thành công của mọi lần thực thi đã bắt đầu vẫn là 100%. Không có chỉ số nào đếm những workflow chưa bao giờ được khởi động. Con số duy nhất phát hiện ra chúng là phép trừ giữa đầu vào và đầu ra.

Đáp án

B — Chạy nhiều thao tác sao chép cùng lúc, mỗi lệnh trong một cửa sổ terminal riêng, dùng các thực thể Snowball client riêng biệt.

Vì sao đúng

Đề đã chẩn đoán đúng: chậm vì hàng triệu tệp nhỏ, và phần tốn thời gian là mã hoá và chi phí cố định trên mỗi tệp, không phải băng thông đường truyền.

⚠ Điểm mấu chốt: với tệp nhỏ, nút thắt là CPU của MÁY KHÁCH chứ không phải mạng hay thiết bị:

Mỗi tệp phải: mở → đọc → mã hoá → đóng gói → gửi → xác nhận
        ↓
    Chi phí cố định này gần như KHÔNG phụ thuộc kích thước tệp
        ↓
    Một luồng đơn chỉ dùng được một lõi CPU
        ↓
    → chạy nhiều thực thể song song mới dùng hết được nhiều lõi
        ↓
    → thông lượng tăng gần tuyến tính theo số luồng, tới khi bão hoà CPU

Đây là khuyến nghị chính thức của AWS cho Snowball: chạy nhiều phiên sao chép đồng thời để tăng thông lượng. Số luồng hợp lý thường xấp xỉ số lõi CPU của máy trạm.

# mỗi lệnh trong một terminal riêng, mỗi cái một phần dữ liệu
snowball cp -r /du-lieu/phan-01 s3://bucket-dich/phan-01 --recursive
snowball cp -r /du-lieu/phan-02 s3://bucket-dich/phan-02 --recursive
snowball cp -r /du-lieu/phan-03 s3://bucket-dich/phan-03 --recursive

⚠ Với hàng triệu tệp rất nhỏ, gộp chúng lại trước còn hiệu quả hơn nữa:

Hàng triệu tệp vài KB
        ↓
    Mỗi tệp vẫn trả đủ chi phí cố định, dù chỉ nặng vài KB
        ↓
    Gộp thành các tệp lưu trữ lớn trước khi sao chép
        ↓
    → thông lượng tăng mạnh
        ↓
    → đánh đổi: phải giải nén sau khi lên S3, và mất khả năng truy cập từng tệp riêng

AWS khuyến nghị gộp khi kích thước tệp trung bình dưới khoảng 1 MB.

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

• D (ghép hai thiết bị Snowball Edge thành cụm để tăng thông lượng) — đây là phương án gần nhất và cụm Snowball Edge là một thứ có thật: bạn ghép được 5 tới 10 thiết bị. Nhưng mục đích của việc ghép cụm là tăng dung lượng và tăng độ bền dữ liệu, không phải tăng tốc độ ghi cho một máy khách. Quan trọng hơn: nút thắt trong bài toán này nằm ở CPU của máy trạm đang chạy script, không nằm ở thiết bị. Thêm thiết bị thứ hai không làm máy trạm mã hoá nhanh hơn, nên tốc độ gần như không đổi. Đây là bẫy hay vì nó nghe rất giống "thêm phần cứng thì nhanh hơn", trong khi phần cứng đang thừa còn phần mềm mới là chỗ nghẽn.

• A (sửa script để sao chép từng tệp riêng thay vì cả thư mục) — làm mọi thứ tệ hơn. Gọi lệnh cho từng tệp nghĩa là khởi tạo lại client, thiết lập lại phiên, trả lại chi phí khởi động cho mỗi tệp. Sao chép theo thư mục cho phép client tự tối ưu và tái sử dụng kết nối.

• C (nối trực tiếp vào cổng USB của Snowball Edge và chép cục bộ) — Snowball Edge không có giao diện USB để chép dữ liệu. Thiết bị chỉ nhận dữ liệu qua mạng (RJ45, SFP+, QSFP+) thông qua Snowball client, giao diện S3 hoặc giao diện tệp. Đây là phương án mô tả một khả năng không tồn tại.

Ghi nhớ

⚠ Bốn cách tăng tốc chuyển dữ liệu bằng Snowball — bảng phải thuộc: | Cách | Hiệu quả | |---|---| | Nhiều phiên sao chép song song | lớn nhất — dùng hết lõi CPU của máy trạm | | Gộp tệp nhỏ trước | lớn khi tệp trung bình dưới 1 MB | | Dùng nhiều máy trạm cùng lúc | tăng thêm khi một máy đã bão hoà | | Mạng nhanh hơn (SFP+, QSFP+) | chỉ có ích khi mạng mới là nút thắt |

Từ khoá nhận diện:

"millions of small files" + chậm → song song hoá, hoặc gộp tệp "overhead of encrypting" → nút thắt ở CPU máy khách "copy individual files rather than directories" → SAI, làm chậm thêm "USB interface on Snowball Edge" → LUÔN SAI, không tồn tại "cluster devices to increase throughput" → SAI mục đích — cụm để tăng dung lượng và độ bền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nút thắt ở đâu | top trên máy trạm — CPU đầy nghĩa là nghẽn mã hoá | | Bao nhiêu luồng là đủ | tăng dần, dừng khi thông lượng không tăng nữa | | Đã chép đủ chưa | so số object trên thiết bị với số tệp nguồn |

Và một lời khuyên: hãy đếm số tệp ở nguồn và số object ở đích rồi so bằng nhau, đừng chỉ so dung lượng. Đây là chỗ mất dữ liệu âm thầm nhất khi chạy nhiều phiên sao chép song song: một luồng bị lỗi giữa chừng — hết bộ nhớ, đứt phiên, một thư mục không đọc được vì quyền — sẽ dừng lại trong terminal của riêng nó, còn các terminal khác chạy tiếp bình thường. Bạn quay lại sau vài giờ, thấy các cửa sổ đã kết thúc và tổng dung lượng trông xấp xỉ đúng, rồi gửi thiết bị đi. Con số duy nhất phát hiện được phần thiếu là số lượng tệp, và sau khi thiết bị rời khỏi trung tâm dữ liệu thì việc đối chiếu lại đã quá muộn.

Đáp án

A — Gắn mỗi VPC vào một transit gateway dùng chung; dựng một egress VPC có thiết bị tường lửa ở hai AZ và nối transit gateway bằng IPSec VPN chạy BGP.

Vì sao đúng

Đề đòi bốn thứ cùng lúc: tập trung, kiểm soát được, sẵn sàng cao, mở rộng ngang tới hơn năm mươi VPC. Transit gateway là nền tảng, còn cách nối tường lửa vào nó là phần quyết định giữa A và B.

⚠ Điểm mấu chốt: BGP với ECMP là thứ cho phép mở rộng NGANG, và nó cần VPN attachment chứ không phải VPC attachment:

Transit gateway nối tới thiết bị tường lửa bằng nhiều đường hầm IPSec
        ↓
    BGP quảng bá cùng một tuyến qua nhiều đường hầm
        ↓
    Transit gateway bật ECMP → chia tải đều giữa các đường
        ↓
    → thêm thiết bị tường lửa = thêm đường hầm = thêm thông lượng
        ↓
    → và BGP tự rút tuyến khi một thiết bị chết

Đây là điểm phân biệt A với B, và nó tinh tế. Với VPC attachment thông thường, transit gateway gửi lưu lượng tới ENI trong subnet của VPC đó — không có giao thức định tuyến động, nên không có cơ chế phát hiện thiết bị tường lửa đã chết ở tầng ứng dụng và không có ECMP giữa các thiết bị. Với VPN attachment chạy BGP, mỗi thiết bị là một BGP peer: nó rút tuyến khi hỏng, và transit gateway chia tải giữa những cái còn sống.

# transit gateway bật ECMP cho VPN
aws ec2 create-transit-gateway \
  --options VpnEcmpSupport=enable,DefaultRouteTableAssociation=enable

# mỗi thiết bị tường lửa là một customer gateway
aws ec2 create-vpn-connection \
  --type ipsec.1 --transit-gateway-id tgw-abc \
  --customer-gateway-id cgw-tuong-lua-az1 \
  --options TunnelInsideIpVersion=ipv4,StaticRoutesOnly=false

⚠ Định tuyến egress tập trung cần bảng định tuyến của transit gateway, không chỉ của VPC:

Bảng định tuyến VPC ứng dụng: 0.0.0.0/0 → transit gateway attachment
        ↓
    Bảng định tuyến của transit gateway: 0.0.0.0/0 → VPN attachment tới tường lửa
        ↓
    Tường lửa kiểm tra, rồi ra Internet qua NAT gateway của egress VPC
        ↓
    → mọi lưu lượng ra ngoài của hơn 50 VPC đi qua đúng một điểm kiểm soát

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

• B (transit gateway + egress VPC có tường lửa ở hai AZ, gắn transit gateway bằng VPC attachment) — đây là phương án gần nhất và kiến trúc tổng thể của nó đúng hoàn toàn: transit gateway làm trung tâm, egress VPC riêng, tường lửa ở hai AZ. Khác biệt duy nhất là cách nối — VPC attachment thay vì VPN với BGP. Với VPC attachment, transit gateway định tuyến tĩnh tới ENI trong egress VPC; không có BGP nghĩa là không có ECMP giữa các thiết bị tường lửa và không có cơ chế tự rút tuyến khi một thiết bị hỏng. Kết quả là kiến trúc chạy được nhưng không đạt hai tiêu chí đề nêu thẳng: highly available và horizontally scalable. (Ngày nay AWS có Gateway Load Balancer để làm việc này gọn hơn nhiều, nhưng nó không có trong danh sách phương án.) Đây là bẫy hay nhất của câu này vì hai phương án chỉ khác một mệnh đề cuối.

• C (VPC peering với một VPC trung tâm, NAT gateway ở hai AZ trong đó) — hỏng ở quy mô. VPC peering không có tính bắc cầu: mỗi cặp cần một kết nối riêng, và mỗi VPC phải có tuyến trỏ tới VPC trung tâm. Với hơn 50 VPC, đó là hơn 50 peering và một cơn ác mộng bảng định tuyến. Quan trọng hơn: lưu lượng không thể đi qua một VPC để tới Internet của VPC khác — peering không cho phép chuyển tiếp qua trung gian, nên NAT gateway trong VPC trung tâm không phục vụ được các VPC khác. Kiến trúc này đơn giản là không hoạt động.

• D (transit VPC với VPN tới từng VPC độc lập) — đây là mẫu transit VPC, thứ có trước khi transit gateway ra đời và đã bị nó thay thế. Nó đòi các thiết bị router ảo tự quản trong transit VPC, mỗi VPC một cặp đường hầm VPN, và toàn bộ thông lượng bị giới hạn bởi kích thước của những EC2 đó. Với hơn 50 VPC, chi phí vận hành và trần thông lượng đều không chấp nhận được.

Ghi nhớ

⚠ Bốn cách nối nhiều VPC — bảng phải thuộc: | Cách | Quy mô hợp lý | Bắc cầu | |---|---|---| | VPC peering | vài VPC | không | | Transit gateway | hàng nghìn VPC | có | | Transit VPC (mẫu cũ) | vài chục, tự quản | có | | PrivateLink | phơi một dịch vụ, không nối mạng | không áp dụng |

Từ khoá nhận diện:

"more than fifty VPCs" → transit gateway, loại peering "centralized egress" + "firewall appliances" → egress VPC riêng "highly available AND horizontally scalable" → BGP + ECMP "VPC peering to a central VPC" cho egress → LUÔN SAI, peering không bắc cầu "transit VPC" → mẫu cũ, đã bị transit gateway thay thế

Ba việc kiểm chứng: | Việc | Cách | |---|---| | ECMP có chia tải không | so lưu lượng giữa các đường hầm | | BGP có lên đủ không | aws ec2 describe-vpn-connections, xem trạng thái từng tunnel | | Đường lùi có hoạt động không | tắt thử một thiết bị tường lửa, xem tuyến có rút không |

Và một lời khuyên: hãy tắt thật một thiết bị tường lửa trong cửa sổ bảo trì và xác nhận BGP rút tuyến trong vài giây. Đây là chỗ kiến trúc egress tập trung hay hỏng nhất mà không ai biết trước: cả hai thiết bị đều hiện up, cả hai đường hầm đều xanh, lưu lượng đi qua bình thường — nhưng nếu bộ hẹn giờ BGP để ở giá trị mặc định quá dài, hoặc thiết bị chết theo kiểu "còn sống nhưng không chuyển tiếp" (tiến trình treo mà cổng mạng vẫn lên), thì tuyến vẫn được quảng bá và transit gateway vẫn đều đặn gửi một nửa lưu lượng vào một cái hố đen. Không có chỉ số nào ở phía AWS phát hiện chuyện đó; thứ duy nhất bạn thấy là một nửa số kết nối ra Internet bỗng nhiên hết thời gian chờ.

Đáp án

A, D — hai bước để áp ngân sách tập trung mà đội vẫn tự xem được chi phí cụm của mình:

• D — Tạo AWS Service Catalog portfolio cho từng đội, đưa cụm Redshift của họ vào dưới dạng product bằng CloudFormation template.
• A — Trong template đó, khai tài nguyên AWS::Budgets::Budget kèm thuộc tính NotificationsWithSubscribers.

Vì sao đúng

Chìa khoá của câu này là từ "centrally enforced" trong môi trường nhiều tài khoản. Không thể trông vào việc mỗi đội tự nhớ tạo ngân sách — ngân sách phải ra đời cùng lúc với cụm, như một phần không tách rời của nó.

⚠ Điểm mấu chốt: đưa ngân sách vào template biến nó thành thứ KHÔNG THỂ quên:

Đội muốn cụm Redshift → chỉ dựng được qua Service Catalog
        ↓
    Template dựng CẢ cụm LẪN ngân sách của cụm đó
        ↓
    Không có đường nào dựng cụm mà không có ngân sách
        ↓
    → chính sách được thực thi bằng kiến trúc, không bằng quy trình con người

Đây là khác biệt giữa "có chính sách" và "chính sách được thực thi". Mọi cách khác đều dựa vào việc ai đó nhớ làm thêm một bước.

Resources:
  CumRedshift:
    Type: AWS::Redshift::Cluster
    Properties:
      NodeType: ra3.xlplus
      ClusterType: multi-node
      NumberOfNodes: 2

  NganSach:
    Type: AWS::Budgets::Budget
    Properties:
      Budget:
        BudgetName: !Sub "ngan-sach-redshift-${AWS::StackName}"
        BudgetType: COST
        TimeUnit: MONTHLY
        BudgetLimit: {Amount: 5000, Unit: USD}
        CostFilters:
          TagKeyValue: [!Sub "user:Doi$${TenDoi}"]
      NotificationsWithSubscribers:
        - Notification:
            NotificationType: ACTUAL
            ComparisonOperator: GREATER_THAN
            Threshold: 80
          Subscribers:
            - {SubscriptionType: EMAIL, Address: quanly@congty.vn}

⚠ Ngân sách phải có CostFilters, nếu không nó theo dõi toàn bộ tài khoản:

AWS::Budgets::Budget không có bộ lọc
        ↓
    Nó tính TỔNG chi phí của cả tài khoản
        ↓
    → cảnh báo kêu vì một dịch vụ khác tăng, chẳng liên quan cụm Redshift
        ↓
    → và ngân sách của cụm thật thì không bao giờ được đánh giá đúng

Bộ lọc thường theo tag, nên chiến lược tag phải có trước — đây là chỗ câu này nối với các câu về cost allocation tag.

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

• E (tạo CloudWatch metric cho billing và cảnh báo tuỳ chỉnh khi vượt ngưỡng) — đây là phương án gần nhất và billing alarm trên CloudWatch là một thứ có thật, dùng được. Nhưng nó thua ở ba điểm so với AWS Budgets. Thứ nhất, chỉ số billing của CloudWatch chỉ tồn tại ở us-east-1 và chỉ chia được theo dịch vụ hoặc theo tài khoản liên kết — không lọc được theo tag, nên không tách được cụm của từng đội. Thứ hai, nó không phải là thứ áp đặt tập trung được: ai đó vẫn phải tạo cảnh báo cho từng cụm bằng tay. Thứ ba, đề nói đội cần xem chi phí của cụm mình tới thời điểm hiện tại — Budgets có sẵn giao diện đó, còn một CloudWatch alarm chỉ cho biết đã vượt ngưỡng hay chưa.

• B (cài unified CloudWatch Agent lên các host của cụm Redshift) — không làm được về mặt kỹ thuật. Redshift là dịch vụ có quản lý; bạn không truy cập được vào máy chủ bên dưới để cài agent. Ngoài ra CloudWatch Agent thu thập chỉ số hệ thống và log, không thu thập dữ liệu hoá đơn — dữ liệu chi phí đến từ hệ thống billing của AWS, không đến từ máy.

• C (CloudTrail trail theo dõi data event, CloudWatch giám sát trail để cảnh báo khi chỉ số billing vượt ngưỡng) — trộn lẫn hai thứ không liên quan. CloudTrail ghi lại lời gọi API, không ghi chi phí; data event ghi thao tác trên dữ liệu (object S3, mục DynamoDB), càng xa hơn nữa. Không có đường nào từ một trail ra được chỉ số billing.

Ghi nhớ

⚠ Bốn cách kiểm soát chi phí — bảng phải thuộc: | Cách | Mức độ áp đặt | |---|---| | Budget trong template Service Catalog | mạnh nhất — không dựng được nếu không có | | AWS Budgets tạo thủ công | phụ thuộc việc nhớ tạo | | CloudWatch billing alarm | thô, chỉ theo dịch vụ hoặc tài khoản | | Xem Cost Explorer định kỳ | hoàn toàn thủ công |

Từ khoá nhận diện:

"centrally enforced" + môi trường nhiều tài khoản → Service Catalog "budget thresholds + notify a distribution list" → AWS::Budgets::Budget với NotificationsWithSubscribers "teams can view their own spend" → budget riêng cho từng cụm "install CloudWatch Agent on Redshift hosts" → LUÔN SAI, không truy cập được host "CloudTrail data events" để theo dõi chi phí → SAI, CloudTrail ghi API, không ghi tiền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ngân sách có lọc đúng không | aws budgets describe-budget, xem CostFilters | | Cảnh báo có tới không | hạ tạm ngưỡng xuống rất thấp và chờ | | Đội có dựng cụm ngoài danh mục được không | thử bằng danh tính người dùng cuối |

Và một lời khuyên: hãy thêm một cảnh báo FORECASTED bên cạnh cảnh báo ACTUAL, đừng chỉ dùng loại thứ hai. Cảnh báo dựa trên chi phí thật chỉ kêu sau khi tiền đã tiêu — với một cụm Redshift dựng nhầm kích cỡ và chạy suốt cuối tuần, lúc bạn nhận email thì khoản chi đã xong và không lấy lại được. Tệ hơn nữa, ngân sách chỉ được đánh giá lại vài lần mỗi ngày chứ không theo thời gian thực, nên độ trễ giữa lúc chi phí vượt ngưỡng và lúc có người biết thường tính bằng giờ. Cảnh báo dự báo bắt được xu hướng từ khi nó mới hình thành, và đó là khác biệt giữa việc dừng một cụm vào sáng thứ Bảy và việc đọc về nó vào sáng thứ Hai.

Đáp án

B — Dùng AWS CodePipeline TẠO change set khi template trong GitHub được cập nhật, thêm một action kiểm thử bằng script chạy trong AWS CodeBuild, và chỉ sau khi kiểm thử đạt mới cho CodePipeline THỰC THI change set để triển khai lên production.

Vì sao đúng

Đề nêu đúng một vấn đề: các bản cập nhật template gây lỗi khi thực thi. Lời giải là chèn một cổng kiểm thử vào giữa việc tạo thay đổi và việc áp dụng thay đổi.

⚠ Điểm mấu chốt: thứ tự tạo–kiểm–thực thi là toàn bộ nội dung câu hỏi:

Template được đẩy lên GitHub
        ↓
    CodePipeline TẠO change set (chưa đụng gì tới hạ tầng)
        ↓
    CodeBuild chạy kiểm thử: lint, validate, dựng thử ở môi trường staging
        ↓
    Đạt → CodePipeline THỰC THI change set lên production
    Không đạt → dừng lại, production không bị đụng tới

Change set là gì và vì sao nó quan trọng. Nó là bản kê những thay đổi CloudFormation sẽ thực hiện — tài nguyên nào được tạo, sửa, xoá, và quan trọng nhất là tài nguyên nào phải thay thế:

aws cloudformation create-change-set \
  --stack-name ha-tang-prod --change-set-name thay-doi-2026-09 \
  --template-body file://ha-tang.yaml --capabilities CAPABILITY_IAM

# xem trước — bước cứu mạng
aws cloudformation describe-change-set \
  --stack-name ha-tang-prod --change-set-name thay-doi-2026-09 \
  --query 'Changes[].ResourceChange.{Hanh:Action,Loai:ResourceType,ThayThe:Replacement}'

# chỉ chạy khi kiểm thử đạt
aws cloudformation execute-change-set \
  --stack-name ha-tang-prod --change-set-name thay-doi-2026-09

⚠ Trường Replacement: True là cảnh báo nghiêm trọng nhất trong một change set:

Thay đổi một thuộc tính không sửa tại chỗ được (ví dụ tên DB, AZ của subnet)
        ↓
    CloudFormation sẽ TẠO MỚI rồi XOÁ cái cũ
        ↓
    → mất dữ liệu nếu tài nguyên đó có trạng thái
        ↓
    → và điều này chỉ nhìn thấy trong change set, không nhìn thấy trong diff của template

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

• D (CodePipeline tạo VÀ thực thi change set khi có cập nhật, rồi kiểm thử bằng CodeDeploy, đạt thì thực thi change set và triển khai) — đây là phương án gần nhất và các thành phần của nó gần như trùng khớp với đáp án đúng. Nhưng nó sai ở đúng chỗ quan trọng nhất: thực thi change set ngay khi có cập nhật, TRƯỚC khi kiểm thử. Như vậy production đã bị thay đổi rồi mới đi kiểm tra — chính xác là vấn đề mà đề đang muốn chữa. Câu cuối "đạt thì thực thi change set" cũng tự mâu thuẫn vì nó đã được thực thi ở bước đầu. Ngoài ra dùng CodeDeploy để chạy script kiểm thử là không đúng vai: CodeDeploy triển khai ứng dụng lên EC2/Lambda/ECS, còn công cụ chạy script kiểm thử trong pipeline là CodeBuild.

• A (Lambda đồng bộ GitHub sang CodeCommit, CodeDeploy tạo và thực thi change set, CodeBuild chạy kiểm thử) — thừa một bước và sai vai trò. Thêm khâu đồng bộ sang CodeCommit là vô ích vì CodePipeline nối trực tiếp với GitHub qua CodeStar connection. Nặng hơn: CodeDeploy không tạo và không thực thi change set của CloudFormation — đó là việc của CodePipeline với action CloudFormation, hoặc của chính CLI/API CloudFormation.

• C (Lambda đồng bộ sang CodeCommit, CodeBuild tạo và thực thi change set, CodeBuild kiểm thử) — cũng thừa khâu đồng bộ, và tuy CodeBuild về lý thuyết chạy được lệnh AWS CLI để tạo change set, nhưng nó vẫn thiếu cổng chặn giữa hai bước: mô tả nói CodeBuild "tạo và thực thi" rồi mới kiểm thử, lặp lại đúng lỗi của D. Phương án này cũng bỏ mất khả năng phê duyệt và điều phối nhiều giai đoạn mà CodePipeline cung cấp sẵn.

Ghi nhớ

⚠ Bốn dịch vụ Code — bảng phải thuộc, đây là chỗ hay lẫn nhất:* | Dịch vụ | Việc | |---|---| | CodePipeline | điều phối — nối các giai đoạn lại thành một luồng | | CodeBuild | biên dịch, chạy kiểm thử, chạy script | | CodeDeploy | triển khai ứng dụng lên EC2, Lambda, ECS | | CodeCommit | kho Git có quản lý |

Từ khoá nhận diện:

"automated testing of CloudFormation updates" → CodePipeline + CodeBuild + change set "create a change set ... then test ... then execute" → đúng thứ tự "create AND execute a change set" rồi mới kiểm thử → SAI, đã đụng production "CodeDeploy chạy testing scripts" → SAI, đó là việc của CodeBuild "sync GitHub to CodeCommit" → thừa, CodePipeline nối GitHub trực tiếp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Change set có gây thay thế tài nguyên không | đọc trường Replacement của từng thay đổi | | Kiểm thử có thật sự chặn được không | cố ý đẩy một template hỏng và xem pipeline có dừng không | | Stack có bị sửa tay không | chạy drift detection định kỳ |

Và một lời khuyên: hãy đọc trường Replacement trong mỗi change set trước khi thực thi, và cho pipeline tự dừng nếu nó bằng True với tài nguyên có trạng thái. Đây là kiểu mất dữ liệu tàn khốc nhất mà quy trình review thông thường không bắt được: bản diff của template có thể chỉ là một dòng đổi tên, trông hoàn toàn vô hại trong pull request, và mọi bài kiểm thử cú pháp đều xanh. Nhưng với một số thuộc tính, CloudFormation không sửa tại chỗ được — nó tạo tài nguyên mới rồi xoá cái cũ, mang theo toàn bộ dữ liệu bên trong. Thông tin ấy chỉ xuất hiện trong change set, không xuất hiện trong template, không xuất hiện trong git diff, và không có ai cảnh báo bạn vào lúc bấm nút triển khai.

Đáp án

C — Thêm rule vào security group của ALB, chỉ cho phép lưu lượng từ AWS managed prefix list của CloudFront.

Vì sao đúng

Đề hỏi cách chặn đường vòng qua CloudFront với ít việc vận hành nhất. Managed prefix list là câu trả lời vì nó cho ra kết quả của việc lọc theo IP mà AWS tự cập nhật danh sách.

⚠ Điểm mấu chốt: managed prefix list là một danh sách IP do AWS cập nhật, tham chiếu được như một nguồn duy nhất trong security group:

Tham chiếu com.amazonaws.global.cloudfront.origin-facing trong security group
        ↓
    AWS thêm/bớt dải IP khi hạ tầng CloudFront thay đổi
        ↓
    Security group tự động phản ánh danh sách mới
        ↓
    → không ai phải theo dõi thông báo thay đổi dải IP, không có gì để cập nhật

Prefix list này còn có một tính chất quan trọng: nó không tính vào hạn mức rule của security group theo cách một danh sách CIDR rời rạc sẽ tính — bạn viết đúng một rule thay vì hàng chục.

# tìm id của prefix list dành cho CloudFront
aws ec2 describe-managed-prefix-lists \
  --filters Name=prefix-list-name,Values=com.amazonaws.global.cloudfront.origin-facing

# một rule duy nhất, thay cho toàn bộ danh sách dải IP
aws ec2 authorize-security-group-ingress --group-id sg-alb \
  --ip-permissions 'IpProtocol=tcp,FromPort=443,ToPort=443,PrefixListIds=[{PrefixListId=pl-3b927c52}]'

⚠ Prefix list chỉ chứng minh "đến từ CloudFront", không chứng minh "đến từ distribution CỦA BẠN":

Dải IP origin-facing dùng chung cho MỌI distribution của MỌI khách hàng AWS
        ↓
    Ai đó tạo distribution riêng, trỏ origin vào ALB của bạn
        ↓
    → lưu lượng của họ cũng đến từ dải đó và cũng lọt qua
        ↓
    → muốn chặt hơn thì thêm custom header + WAF (xem câu về OAI/custom header)

Với yêu cầu "LEAST operational overhead" của đề thì prefix list là đáp án đúng; nhưng khi cần bảo vệ chặt, hai lớp nên đi cùng nhau.

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

• A (thêm rule security group cho phép các dải IP của CloudFront) — đây là phương án gần nhất và kết quả bảo mật của nó gần như y hệt đáp án đúng: cùng lọc theo IP, cùng chặn được đường vòng. Nó chỉ khác ở chỗ ai giữ danh sách. Tự nạp dải IP nghĩa là phải theo dõi tệp ip-ranges.json của AWS, tự động hoá việc cập nhật security group, và xử lý chuyện danh sách dài hơn hạn mức rule của security group (mặc định 60). Mỗi lần AWS thêm dải mới mà bạn chưa cập nhật, một phần lưu lượng hợp lệ bị chặn — sự cố xuất hiện ngẫu nhiên, khó tái hiện. Đề hỏi "LEAST operational overhead", và đây chính là phần overhead mà prefix list xoá bỏ.

• B (network ACL từ chối mọi khối IP trừ dải CloudFront) — cùng gánh nặng bảo trì như A, cộng thêm hai nhược điểm. NACL không có trạng thái, nên phải tự mở cổng ephemeral cho chiều về, rất dễ sai. Và NACL có hạn mức entry rất thấp (20 mặc định, tối đa 40) — không đủ chỗ cho danh sách dải IP của CloudFront. Ngoài ra NACL áp cho cả subnet, ảnh hưởng mọi tài nguyên trong đó chứ không riêng ALB.

• D (tạo web ACL chặn truy cập ứng dụng và gắn vào ALB) — mâu thuẫn với chính mục tiêu. Một web ACL "chặn truy cập ứng dụng" gắn vào ALB sẽ chặn cả lưu lượng đến từ CloudFront, vì với ALB thì CloudFront cũng chỉ là một client. Kết quả là ứng dụng ngừng phục vụ hoàn toàn. Muốn dùng WAF ở đây thì luật phải là "cho qua nếu có custom header bí mật", không phải "chặn tất cả".

Ghi nhớ

⚠ Bốn cách khoá ALB sau CloudFront, xếp theo công vận hành: | Cách | Công vận hành | Độ chặt | |---|---|---| | Managed prefix list | gần như bằng 0 | chặn được người ngoài, không chặn distribution khác | | Custom header + WAF | thấp (nhớ xoay chuỗi bí mật) | chặt nhất | | Tự nạp dải IP | cao, liên tục | như prefix list | | NACL theo IP | cao, và vướng hạn mức | kém |

Từ khoá nhận diện:

"prevent connecting directly to the ALB" + "LEAST operational overhead" → managed prefix list "allow the CloudFront IP address ranges" tự nạp → đúng ý tưởng, sai về công bảo trì "network ACL" cho danh sách IP dài → SAI, hạn mức quá thấp và không có trạng thái "web ACL that blocks access" gắn vào ALB → SAI, chặn luôn CloudFront cần chặt tuyệt đối → custom header + WAF, không chỉ IP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đường vòng đã bị chặn chưa | curl thẳng vào tên miền ALB từ máy ngoài — phải timeout hoặc bị từ chối | | Đường chính còn chạy không | curl qua tên miền CloudFront — phải 200 | | Rule có đúng prefix list không | describe-security-groups, xem PrefixListIds |

Và một lời khuyên: hãy curl thẳng vào tên miền của ALB từ một mạng bên ngoài sau khi áp rule, và lặp lại phép thử đó định kỳ. Đây là lớp bảo vệ dễ bị vô hiệu hoá một cách vô tình nhất: một security group thường có nhiều rule, và chỉ cần ai đó thêm lại một rule cho phép 0.0.0.0/0 trên cổng 443 — để gỡ lỗi, để thử nghiệm, hoặc vì một template cũ dựng lại — là toàn bộ hiệu quả biến mất. Rule mới không xoá rule cũ, không gây xung đột, không sinh cảnh báo; security group chỉ đơn giản là hợp nhất chúng theo hướng dễ dãi nhất. Ứng dụng vẫn chạy bình thường qua CloudFront, mọi chỉ số vẫn đẹp, và cánh cửa sau lại mở ra mà không có sự kiện nào đánh dấu thời điểm đó.