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

Đáp án

C, D — hai bước đạt RTO 30 phút và RPO 5 phút với chi phí tối ưu:

• D — Tạo cross-Region Aurora MySQL Replica cho cơ sở dữ liệu.
• C — Triển khai hot standby của các tầng ứng dụng sang Region khác.

Vì sao đúng

Hai con số của đề quyết định tất cả: RPO 5 phút loại mọi cách sao lưu theo lô, RTO 30 phút loại mọi cách phải khôi phục 30 TB từ đầu.

⚠ Điểm mấu chốt: sao chép liên tục và sao lưu theo lô là hai thứ khác hẳn nhau về RPO:

Snapshot mỗi 5 phút
        ↓
    Snapshot 30 TB KHÔNG hoàn thành trong 5 phút
        ↓
    Snapshot sau chồng lên snapshot trước chưa xong
        ↓
    → RPO thực tế tệ hơn nhiều so với 5 phút, và tải I/O tăng liên tục

Cross-Region Aurora Replica
        ↓
    Sao chép liên tục ở mức storage, độ trễ thường dưới một giây
        ↓
    → RPO tính bằng giây, không tính bằng phút

D — vì sao cross-Region replica là câu trả lời cho tầng dữ liệu. Aurora sao chép liên tục sang Region khác với độ trễ thường dưới một giây. Khi có sự cố, bạn promote replica thành cụm chính:

# tạo bản sao xuyên Region
aws rds create-db-cluster \
  --db-cluster-identifier aurora-dr --engine aurora-mysql \
  --replication-source-identifier arn:aws:rds:ap-southeast-1:111122223333:cluster:aurora-chinh \
  --region ap-northeast-1

# khi sự cố: nâng lên làm cụm chính (vài phút)
aws rds promote-read-replica-db-cluster \
  --db-cluster-identifier aurora-dr --region ap-northeast-1

C — vì sao tầng ứng dụng cần hot standby. Đề nói tầng ứng dụng stateless, nên chúng không giữ dữ liệu gì cần sao chép — nhưng chúng vẫn cần thời gian để sẵn sàng. Với RTO 30 phút, dựng hạ tầng từ con số không ở Region thứ hai là quá rủi ro: phải tạo VPC, ALB, Auto Scaling group, chờ instance khởi động và qua health check. Hot standby giữ sẵn mọi thứ, chỉ cần chuyển lưu lượng sang.

⚠ RTO 30 phút phải tính CẢ thời gian phát hiện và thời gian quyết định:

Sự cố xảy ra
        ↓
    Phát hiện: 5 phút (alarm)
        ↓
    Quyết định chuyển vùng: 5 phút (con người)
        ↓
    Promote replica: 3-5 phút
        ↓
    Đổi DNS + TTL: 2-5 phút
        ↓
    → còn lại rất ít cho việc dựng hạ tầng, nên hạ tầng phải sẵn sàng từ trước

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

• A (snapshot Aurora mỗi 5 phút) — đây là phương án gần nhất và nó nhắm đúng con số RPO của đề: nhìn thoáng qua, "snapshot mỗi 5 phút" trông như đúng nghĩa RPO 5 phút. Nhưng nó bất khả thi ở quy mô này. Một snapshot của cụm 30 TB không xong trong 5 phút; snapshot Aurora tuy là incremental nhưng vẫn cần thời gian, và chồng chu kỳ lên nhau sẽ đẩy tải I/O lên liên tục. Nặng hơn nữa là phía RTO: khôi phục 30 TB từ snapshot mất hàng giờ, không có cách nào lọt vào 30 phút. Và quan trọng nhất — Aurora đã có sẵn backtrack và continuous backup tới mức giây, nên tự dựng lịch snapshot dày đặc là làm lại thứ đã có, theo cách tệ hơn.

• B (snapshot EC2 hằng ngày, nhân bản sang Region khác) — sai cả hai chỉ tiêu. Hằng ngày nghĩa là RPO 24 giờ, cách RPO 5 phút rất xa. Và đề nói tầng ứng dụng stateless — snapshot chúng chẳng bảo vệ dữ liệu gì cả, vì dữ liệu không nằm ở đó. Khôi phục từ AMI rồi khởi động cũng khó lọt 30 phút.

• E (dùng DMS sao chép Aurora sang một RDS ở Region khác) — DMS có làm được sao chép liên tục (CDC), nhưng đây là công cụ sai cho bài này. Nó thêm một tầng phải vận hành và giám sát, trong khi Aurora đã có cơ chế sao chép xuyên Region ở mức storage vừa nhanh hơn vừa không tốn công. DMS sinh ra để chuyển giữa các engine khác nhau hoặc từ ngoài vào AWS; dùng nó để nối Aurora với Aurora là chọn đường vòng. Về chi phí cũng đắt hơn: phải trả cho replication instance chạy 24/7 cộng với chính cái RDS đích.

Ghi nhớ

⚠ Bốn chiến lược DR — bảng phải thuộc, đây là bảng ra thi nhiều nhất: | Chiến lược | RTO | RPO | Chi phí | Cách làm | |---|---|---|---|---| | Backup & Restore | nhiều giờ | nhiều giờ | thấp nhất | chỉ có sao lưu | | Pilot Light | hàng chục phút | phút | thấp | dữ liệu sao chép sẵn, ứng dụng tắt | | Warm Standby | phút | giây–phút | trung bình | mọi thứ chạy ở quy mô nhỏ | | Multi-Site Active/Active | gần bằng 0 | gần bằng 0 | cao nhất | hai bên cùng phục vụ |

Đề này rơi vào Warm Standby: dữ liệu sao chép liên tục (D) cộng với ứng dụng đã sẵn sàng (C).

Từ khoá nhận diện:

"RPO tính bằng phút hoặc giây" → sao chép liên tục, không phải snapshot "RTO 30 phút" + cơ sở dữ liệu hàng chục TB → không kịp khôi phục từ snapshot "application tiers are stateless" → không cần sao chép dữ liệu ở tầng đó, chỉ cần sẵn sàng "optimizing costs" + RTO/RPO chặt → warm standby, không phải active/active "snapshot every 5 minutes" cho CSDL lớn → LUÔN SAI, snapshot không xong kịp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ sao chép thực tế | chỉ số AuroraGlobalDBReplicationLag hoặc ReplicaLag | | RTO thực tế | diễn tập chuyển vùng thật, bấm giờ từ lúc phát hiện | | Region dự phòng có đủ hạn mức không | kiểm service quota ở Region đó trước khi cần dùng |

Và một lời khuyên: hãy diễn tập chuyển vùng thật ít nhất mỗi quý, và bấm giờ từ lúc alarm kêu chứ không từ lúc bạn bắt đầu gõ lệnh. Kế hoạch DR trên giấy luôn đạt RTO; thực tế thì thời gian trôi ở những chỗ không ai ghi vào kế hoạch — ai có quyền quyết định chuyển vùng, người đó có đang ngủ không, tài khoản ở Region dự phòng có đủ hạn mức vCPU để scale lên không. Hạn mức là cái bẫy im lặng điển hình: nó không gây ra vấn đề gì suốt thời gian bình thường, và chỉ hiện ra đúng vào lúc bạn cần scale gấp, dưới dạng một lỗi InsufficientInstanceCapacity giữa khủng hoảng.

Đáp án

B, E — hai thay đổi chữa cả thời gian chạy lẫn lỗi throttle:

• E — Tăng bộ nhớ cấp cho hàm Lambda.
• B — Đưa dữ liệu từ API Gateway vào Kinesis Data Stream và xử lý theo lô.

Vì sao đúng

Đề có hai triệu chứng riêng biệt, và mỗi phương án đúng chữa đúng một cái.

⚠ Điểm mấu chốt: trong Lambda, CPU được cấp TỶ LỆ THUẬN với bộ nhớ — không có nút chỉnh CPU riêng:

Đặt memory = 128 MB
        ↓
    Nhận một phần rất nhỏ của một vCPU
        ↓
    Tăng lên 1.769 MB → tương đương trọn một vCPU
        ↓
    → hàm chạy nhanh hơn nhiều lần mà không sửa một dòng mã

Đây là lý do phương án A ("tăng CPU units") không tồn tại như một thiết lập, còn E lại chính là cách tăng CPU. Nhiều người bỏ qua E vì nghĩ "hàm này đâu có thiếu bộ nhớ" — nhưng với Lambda, chỉnh bộ nhớ là chỉnh cả bộ nhớ lẫn CPU lẫn băng thông mạng.

Có một hệ quả trái trực giác: tăng bộ nhớ thường làm giảm chi phí. Lambda tính tiền theo GB-giây, nên nếu tăng gấp đôi bộ nhớ mà thời gian chạy giảm hơn một nửa, hoá đơn giảm:

B — vì sao Kinesis giải quyết chuyện throttle. Hiện tại mỗi request từ mỗi xe sinh ra một lời gọi Lambda riêng. Thêm xe, thêm chỉ số, thì số lời gọi đồng thời tăng tuyến tính cho tới khi đụng trần concurrency:

API Gateway → Kinesis Data Stream (đệm lại)
        ↓
    Lambda đọc theo lô: một lời gọi xử lý tới 10.000 bản ghi
        ↓
    Số lời gọi đồng thời = số shard, KHÔNG phải số xe
        ↓
    → concurrency trở nên tiên đoán được, không còn phụ thuộc số thiết bị

Đây là thay đổi về hình thái tải: từ "mỗi sự kiện một lời gọi" sang "mỗi lô một lời gọi". Ghi vào DynamoDB cũng hiệu quả hơn hẳn vì gom được BatchWriteItem.

⚠ Số lời gọi đồng thời của Lambda đọc Kinesis bằng số shard, không phải số bản ghi:

Muốn xử lý song song hơn → thêm shard
        ↓
    Hoặc bật parallelization factor (tối đa 10 lời gọi mỗi shard)
        ↓
    → nhưng khi đó thứ tự trong shard không còn được giữ nguyên

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

• C (gom vào SQS FIFO, mỗi tin nhắn kích hoạt một Lambda) — đây là phương án gần nhất và ý tưởng đệm lại bằng hàng đợi là đúng hướng: SQS thật sự tách được tốc độ nhận khỏi tốc độ xử lý, và nó cũng hỗ trợ đọc theo lô. Nhưng mô tả trong phương án nói rõ "kích hoạt một Lambda để xử lý từng tin nhắn" — tức là giữ nguyên mô hình một-sự-kiện-một-lời-gọi, đúng cái đang gây throttle. Chọn FIFO còn làm mọi thứ tệ hơn: hàng đợi FIFO giới hạn 300 thao tác mỗi giây (3.000 khi gom lô), thấp hơn nhiều so với standard queue, nên nó tạo ra một nút thắt mới. Dữ liệu cảm biến từ nhiều xe cũng không cần thứ tự tuyệt đối toàn cục — đó là thứ FIFO đánh đổi thông lượng để đạt được.

• A (tăng "CPU units" cho Lambda) — không tồn tại thiết lập này. "CPU units" là khái niệm của ECS task definition, không phải Lambda. Trong Lambda, CPU đi kèm bộ nhớ. Đây là bẫy đọc nhanh: nó nghe rất giống E nhưng dùng sai tên nút chỉnh, và người chọn A thường bỏ qua E vì tưởng hai phương án nói cùng một chuyện.

• D (dùng EC2 thay Lambda) — viết lại toàn bộ kiến trúc để né một vấn đề chỉnh cấu hình là được. Thêm máy phải vá, phải co giãn, phải giám sát. Đề mô tả tải theo đợt mỗi 4 phút — đúng hình thái mà serverless phù hợp nhất.

Ghi nhớ

⚠ Bốn điều về bộ nhớ Lambda — bảng phải thuộc: | Điều | Nội dung | |---|---| | Khoảng cấu hình | 128 MB tới 10.240 MB | | CPU tỷ lệ với bộ nhớ | 1.769 MB ≈ trọn một vCPU | | Băng thông mạng | cũng tăng theo bộ nhớ | | Tính tiền | GB-giây — nhanh hơn có thể bù lại việc cấp nhiều hơn |

Từ khoá nhận diện:

"execution time increased" → xét tăng bộ nhớ trước tiên "TooManyRequestsException" → đang bị throttle concurrency "increase CPU units" cho Lambda → LUÔN SAI, không có thiết lập đó "process the data in batches" → Kinesis hoặc SQS với batch size lớn "triggers a Lambda to process EACH message" khi đang bị throttle → SAI, giữ nguyên vấn đề

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm có thiếu bộ nhớ không | dòng Max Memory Used trong log REPORT của mỗi lời gọi | | Có đang bị throttle không | chỉ số Throttles | | Lô có đầy không | IteratorAge cao nghĩa là đang tụt lại phía sau |

Và một lời khuyên: hãy so Max Memory Used với mức đã cấp trước khi kết luận là hàm chậm vì mã xấu. Đây là chỗ người ta mất nhiều ngày nhất: một hàm cấp 256 MB mà chỉ dùng 90 MB trông như "còn thừa bộ nhớ", nên không ai nghĩ tới việc tăng — trong khi thứ nó thật sự đang thiếu là CPU, thứ không có chỉ số riêng nào để nhìn và không xuất hiện trong bất kỳ cảnh báo nào. Hàm vẫn chạy đúng, vẫn trả kết quả đúng, chỉ là chậm gấp năm lần mức cần thiết, và nguyên nhân nằm ở một nút chỉnh mang tên hoàn toàn khác.

Đáp án

A — Lượng đọc/ghi lớn đã dùng hết số dư I/O credit, vì dung lượng đĩa cấp lúc dựng quá nhỏ.

Vì sao đúng

Câu này giải bằng cách loại trừ theo chỉ số. Đề đưa ra bốn quan sát, và ba trong số đó là để loại phương án:

⚠ Điểm mấu chốt: gp2 cấp IOPS theo DUNG LƯỢNG, nên "còn nhiều chỗ trống" và "đủ IOPS" là hai chuyện khác nhau:

Volume gp2 dung lượng nhỏ
        ↓
    IOPS nền = 3 × số GB (tối thiểu 100)
        ↓
    Khi cần hơn mức nền, volume tiêu I/O credit để bùng lên 3.000 IOPS
        ↓
    Đỉnh mua sắm kéo dài → credit cạn
        ↓
    → tụt về IOPS nền, độ trễ tăng vọt, mà mọi chỉ số khác vẫn "khoẻ"

Đây chính là hình thái của đề: chạy tốt suốt nhiều tuần rồi hỏng đúng vào lúc cao điểm. Đó là dấu hiệu đặc trưng của cơ chế credit — trong điều kiện bình thường, tải thấp hơn mức nền nên credit tích lại và mọi thứ mượt; chỉ khi tải cao kéo dài đủ lâu, credit mới cạn và hiệu năng rơi xuống mức nền.

Cách chữa vì thế là tăng dung lượng (kéo IOPS nền lên) hoặc đổi loại volume:

# xem số dư credit — chỉ số quyết định
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS --metric-name BurstBalance \
  --dimensions Name=DBInstanceIdentifier,Value=shop-db \
  --start-time 2026-08-25T00:00:00Z --end-time 2026-09-01T00:00:00Z \
  --period 300 --statistics Minimum

# chuyển sang gp3: IOPS tách khỏi dung lượng
aws rds modify-db-instance --db-instance-identifier shop-db \
  --storage-type gp3 --iops 6000 --apply-immediately

⚠ BurstBalance là chỉ số duy nhất báo trước chuyện này, và nó không được bật cảnh báo theo mặc định:

BurstBalance giảm dần từ 100% xuống
        ↓
    Chưa có triệu chứng gì — ứng dụng vẫn nhanh
        ↓
    Chạm 0%
        ↓
    → độ trễ tăng đột ngột, và lúc đó mới đi tìm nguyên nhân

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

• D (hết băng thông mạng của instance RDS) — đây là phương án gần nhất và nó cũng là một nghẽn tài nguyên có thật: instance RDS đúng là có trần băng thông mạng, và với các lớp máy nhỏ thì trần đó có thể chạm tới. Nhưng ba lý do khiến nó không khớp. Thứ nhất, đề mô tả thời gian phản hồi đọc và ghi dài — đó là ngôn ngữ của chỉ số ReadLatency/WriteLatency, thuộc tầng lưu trữ, không phải tầng mạng. Thứ hai, nghẽn mạng thường biểu hiện thành lỗi kết nối hoặc timeout ở tầng ứng dụng, mà đề nói rõ log ứng dụng không có dấu hiệu vấn đề kết nối. Thứ ba, đề nêu thẳng "General Purpose SSD" — một gợi ý cố ý trỏ về cơ chế credit của gp2, và nó sẽ thừa nếu đáp án là chuyện mạng.

• B (chỉ mục cần dựng lại vì dữ liệu thay đổi nhiều) — chỉ mục phân mảnh làm chậm truy vấn đọc, nhưng không làm chậm ghi theo cách đối xứng như đề mô tả, và triệu chứng của nó là tăng dần theo tuần chứ không đột ngột xuất hiện đúng đợt cao điểm. Nó cũng thường đi kèm CPU tăng, mà đề nói CPU dưới 50%.

• C (đã chạm giới hạn số kết nối tối đa) — đề đã loại tường minh: "không có dấu hiệu vấn đề kết nối trong log ứng dụng". Hết connection thì ứng dụng nhận lỗi Too many connections rõ ràng, không phải "phản hồi chậm". Đây là phương án bị bác bỏ bởi chính một câu trong đề, nên nếu chọn nó nghĩa là đã bỏ qua một dữ kiện.

Ghi nhớ

⚠ Bốn loại EBS — bảng phải thuộc: | Loại | IOPS | Ghi chú | |---|---|---| | gp2 | 3 IOPS/GB, bùng 3.000 bằng credit | IOPS trói vào dung lượng | | gp3 | 3.000 nền, mua thêm tới 16.000 độc lập dung lượng | rẻ hơn gp2 khoảng 20%, thế hệ mặc định mới | | io1 / io2 | tới 64.000 (io2 Block Express tới 256.000) | khi cần IOPS rất cao và ổn định | | st1 / sc1 | HDD, tính theo throughput | không dùng cho CSDL truy cập ngẫu nhiên |

Từ khoá nhận diện:

"chạy tốt vài tuần rồi chậm đúng đợt cao điểm" → cạn burst credit "CPU thấp, RAM đủ, đĩa còn trống, nhưng vẫn chậm" → nghẽn IOPS "General Purpose SSD" + hiệu năng tụt → gợi ý trực tiếp về gp2 credit "no connectivity errors in the logs" → loại phương án hết connection "provisioning low disk storage during setup" → đúng nguyên nhân gốc của gp2

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có phải cạn credit không | vẽ BurstBalance trong đợt sự cố — nếu chạm 0 thì đã rõ | | IOPS nền hiện tại là bao nhiêu | dung lượng GB × 3 | | Đang cần bao nhiêu IOPS | ReadIOPS + WriteIOPS ở lúc cao điểm |

Và một lời khuyên: hãy đặt cảnh báo CloudWatch trên BurstBalance ở ngưỡng 20%, ngay hôm nay. Đây là ví dụ mẫu mực của lỗi im lặng: trong suốt thời gian credit đang cạn dần, không có chỉ số nào khác thay đổi — CPU vẫn thấp, bộ nhớ vẫn dư, độ trễ vẫn hoàn hảo, dashboard vẫn xanh toàn bộ. Hệ thống trông khoẻ mạnh cho tới đúng thời điểm số dư chạm đáy, và khi đó bạn đang ở giữa đợt cao điểm doanh thu lớn nhất năm — thời điểm tệ nhất để bắt đầu chẩn đoán một thứ lẽ ra đã báo trước bạn nhiều giờ.

Đáp án

B — Tạo một kết nối DX mới ở CÙNG Region, dựng Direct Connect gateway, và thiết lập các private VIF mới tới virtual private gateway của VPC ở mỗi Region.

Vì sao đúng

Đề có hai yêu cầu tách biệt, và Direct Connect gateway là thứ giải quyết cái thứ hai.

⚠ Điểm mấu chốt: Direct Connect gateway là tài nguyên TOÀN CẦU, đó là lý do không cần kết nối vật lý ở Region thứ hai:

Kết nối DX vật lý tại một địa điểm (một Region)
        ↓
    Private VIF gắn vào Direct Connect gateway
        ↓
    DX gateway liên kết với virtual private gateway ở NHIỀU Region
        ↓
    → một kết nối vật lý tới được VPC ở bất kỳ Region nào (trừ Trung Quốc)

Đây là hiểu lầm phổ biến nhất về Direct Connect: người ta tưởng muốn tới VPC ở Region khác thì phải kéo cáp tới Region đó. Không phải. DX gateway tồn tại chính là để phá bỏ ràng buộc đó. Lưu lượng đi vào tại địa điểm DX rồi chạy trên xương sống của AWS tới Region đích.

Vì thế kết nối thứ hai nên đặt ở cùng Region — mục đích của nó là dự phòng, không phải để với tới Region mới. Đặt nó ở Region thứ hai (phương án A, D) thì hai kết nối không dự phòng cho nhau: mỗi cái phục vụ một nơi, hỏng cái nào thì mất phần đó.

# dựng DX gateway (toàn cầu)
aws directconnect create-direct-connect-gateway \
  --direct-connect-gateway-name dxgw-cong-ty --amazon-side-asn 64512

# gắn VGW của VPC ở Region 1
aws directconnect create-direct-connect-gateway-association \
  --direct-connect-gateway-id dxgw-abc --virtual-gateway-id vgw-region1

# gắn VGW của VPC ở Region 2 — cùng một DX gateway
aws directconnect create-direct-connect-gateway-association \
  --direct-connect-gateway-id dxgw-abc --virtual-gateway-id vgw-region2

⚠ Dự phòng thật đòi hai kết nối ở hai địa điểm khác nhau:

Hai kết nối cùng một địa điểm DX
        ↓
    Mất điện hoặc sự cố cả toà nhà đó
        ↓
    → mất cả hai cùng lúc
        ↓
    → SLA cao nhất của AWS đòi hai kết nối tại HAI địa điểm riêng biệt

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

• C (DX mới cùng Region, DX gateway, private VIF tới TRANSIT GATEWAY) — đây là phương án gần nhất và nó chỉ sai đúng một từ: mọi thứ khác — kết nối thứ hai ở cùng Region, dùng DX gateway — đều đúng. Nhưng loại VIF không khớp với đích. Private VIF nối tới virtual private gateway; nối tới transit gateway phải dùng transit VIF. Đây không phải chuyện đặt tên: hai loại VIF khác nhau về cách gắn và về giới hạn. Đề cũng không nói gì tới transit gateway hay nhu cầu nối nhiều VPC với nhau, nên đưa nó vào là thêm một thành phần không cần thiết. Đây là bẫy tinh vi nhất của câu này vì nó thưởng cho người nhớ được cặp "loại VIF ↔ loại gateway".

• A (DX mới tới Region thứ hai, private VIF tới VGW ở đó) — chạy được, nhưng không đáp ứng yêu cầu dự phòng. Kết nối thứ nhất phục vụ Region 1, kết nối thứ hai phục vụ Region 2 — không cái nào đỡ cho cái nào. Hỏng kết nối thứ nhất là mất VPC thứ nhất, y như trước. Nó cũng đắt hơn nhiều: kéo một đường DX mới tới Region khác là chi phí và thời gian lớn, trong khi DX gateway làm được việc đó miễn phí.

• D (DX mới tới Region thứ hai, dựng transit gateway, private VIF tới VGW ở mỗi Region) — mắc cả hai lỗi cùng lúc: đặt kết nối sai chỗ nên không có dự phòng, và trộn lẫn transit gateway với private VIF/VGW theo cách không tồn tại. Transit gateway không phải là thứ private VIF gắn vào.

Ghi nhớ

⚠ Ba loại VIF — bảng phải thuộc, đây là bảng ra thi nhiều nhất về Direct Connect: | Loại VIF | Gắn tới | Dùng để | |---|---|---| | Private VIF | virtual private gateway, hoặc Direct Connect gateway | vào tài nguyên riêng trong VPC | | Transit VIF | Direct Connect gateway → transit gateway | nối nhiều VPC qua transit gateway | | Public VIF | endpoint công cộng của AWS | S3, DynamoDB, API công khai — không vào VPC |

Từ khoá nhận diện:

"connect to VPCs in multiple Regions" → Direct Connect gateway "redundancy for the existing connection" → kết nối thứ hai, cùng Region, khác địa điểm "private VIF to a transit gateway" → LUÔN SAI, phải là transit VIF "public VIF" để vào VPC → LUÔN SAI "new DX connection to the second Region" khi đã có DX gateway → thừa và không tạo dự phòng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | BGP có lên không | aws directconnect describe-virtual-interfaces, xem bgpPeers | | Đường dự phòng có thật sự nhận tải không | rút thử đường chính, xem lưu lượng có chuyển sang không | | Tuyến có được quảng bá tới cả hai Region không | kiểm bảng định tuyến của VPC ở từng Region |

Và một lời khuyên: hãy thật sự rút đường chính trong một cửa sổ bảo trì có kế hoạch, đừng chỉ nhìn thấy hai đường đều "up". Đây là chỗ dự phòng hay hỏng nhất mà không ai biết: hai kết nối đều xanh, BGP đều thiết lập, dashboard hoàn hảo — nhưng đường thứ hai quảng bá thiếu tuyến, hoặc thuộc tính BGP đặt sao cho nó không bao giờ được chọn, hoặc băng thông của nó không đủ gánh toàn bộ tải. Không có chỉ số nào cho bạn biết điều đó, vì trong trạng thái bình thường đường dự phòng chẳng phải làm gì cả. Nó chỉ được kiểm tra đúng một lần duy nhất — vào lúc đường chính đứt.

Đáp án

D — Dựng cụm ECS bằng một đội Spot Instance có bật Spot Instance draining, và cấp cơ sở dữ liệu bằng Reserved Instance.

Vì sao đúng

Đây là câu về ghép đúng mô hình giá với đúng đặc tính khối lượng công việc. Hai tầng trong đề có đặc tính trái ngược nhau, nên chúng cần hai mô hình giá khác nhau.

⚠ Điểm mấu chốt: Spot có thể bị thu hồi bất cứ lúc nào với 2 phút báo trước — và đó là lý do RDS không bao giờ chạy trên Spot:

AWS cần lại dung lượng
        ↓
    Gửi thông báo thu hồi trước 2 phút
        ↓
    Spot Instance draining: ECS ngừng đưa task mới vào máy đó
        ↓
    Task đang chạy được chuyển sang máy khác trong đội
        ↓
    → dịch vụ không gián đoạn vì container vốn thay thế được

Với cơ sở dữ liệu thì kịch bản đó là thảm hoạ — mà thực tế câu hỏi còn đơn giản hơn thế: RDS không có tuỳ chọn Spot. Đây là chi tiết quyết định loại thẳng phương án A. RDS chỉ có On-Demand và Reserved Instance.

Spot Instance draining là mảnh ghép làm cho Spot dùng được với ECS:

# bật trên từng container instance qua user data
echo "ECS_ENABLE_SPOT_INSTANCE_DRAINING=true" >> /etc/ecs/ecs.config

Không bật cờ này thì khi máy bị thu hồi, task chết đột ngột cùng với máy. Bật rồi thì ECS coi máy đó là DRAINING, ngừng xếp task mới vào, và chuyển task hiện có sang chỗ khác trong khoảng hai phút được báo trước.

⚠ Reserved Instance của RDS là cam kết theo LỚP MÁY, không phải theo instance cụ thể:

Mua RI cho db.r6g.large ở một Region
        ↓
    Giảm giá tự động áp cho BẤT KỲ instance nào khớp lớp máy đó
        ↓
    → xoá instance rồi dựng lại vẫn được giảm giá
        ↓
    → nhưng đổi sang lớp máy khác thì RI thành tiền vứt đi

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

• C (ECS trên Spot có draining, cơ sở dữ liệu On-Demand) — đây là phương án gần nhất và nửa đầu của nó chính xác bằng đáp án đúng: Spot cho ECS với draining bật là hoàn toàn chuẩn. Nó chỉ bỏ lỡ khoản tiết kiệm ở tầng dữ liệu. Cơ sở dữ liệu là thứ chạy 24/7 không nghỉ — đó đúng là hình thái mà Reserved Instance sinh ra để phục vụ. Trả giá On-Demand cho một máy chạy liên tục nhiều năm là bỏ qua tới 72% tiết kiệm mà không đổi lấy điều gì: RI không thay đổi hành vi, không thêm rủi ro, không thêm việc vận hành. Với câu hỏi hỏi "MOST cost-effective", phương án bỏ sót một khoản giảm giá lớn mà không có lý do thì không thể là đáp án.

• A (ECS On-Demand, cơ sở dữ liệu trên Spot) — đảo ngược hoàn toàn, và sai theo cách nặng nhất. Thứ nhất, RDS không chạy trên Spot — tuỳ chọn đó không tồn tại. Thứ hai, kể cả nếu tự dựng MySQL trên EC2 Spot thì mỗi lần thu hồi là cơ sở dữ liệu chết giữa chừng, mất kết nối, có nguy cơ hỏng dữ liệu. Đây là phương án đặt tầng chịu lỗi kém nhất lên nền tảng kém ổn định nhất.

• B (cả hai đều On-Demand) — chạy được, an toàn, và là phương án đắt nhất. On-Demand đúng cho tải khó đoán và ngắn hạn; ở đây cả hai tầng đều không phải vậy. Không tận dụng gì cả thì không thể là câu trả lời cho "cost-effective nhất".

Ghi nhớ

⚠ Bốn mô hình giá EC2 — bảng phải thuộc: | Mô hình | Giảm giá | Hợp với | Rủi ro | |---|---|---|---| | On-Demand | 0% | tải khó đoán, ngắn hạn | không | | Reserved Instance | tới 72% | tải ổn định 1–3 năm | cam kết dài hạn | | Savings Plans | tới 72% | như RI nhưng linh hoạt hơn về lớp máy | cam kết theo số tiền/giờ | | Spot | tới 90% | stateless, chịu gián đoạn, xử lý theo lô | bị thu hồi với 2 phút báo trước |

Từ khoá nhận diện:

"stateless" / "fault-tolerant" / "batch" → Spot "database" / "steady state" / "runs continuously" → Reserved Instance hoặc Savings Plans "RDS on Spot Instances" → LUÔN SAI, không tồn tại "Spot Instance draining" → bắt buộc khi chạy ECS trên Spot "MOST cost-effective" → tìm phương án tận dụng giảm giá ở MỌI tầng phù hợp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tần suất bị thu hồi | Spot Instance Advisor cho từng lớp máy và Region | | RI có được dùng hết không | báo cáo RI utilization và RI coverage trong Cost Explorer | | Draining có hoạt động không | huỷ thử một máy, xem task có chuyển sang máy khác không |

Và một lời khuyên: hãy xem báo cáo RI utilization mỗi tháng, đừng mua rồi quên. Reserved Instance là khoản trả trước cho một lớp máy cụ thể ở một Region cụ thể; nếu đội của bạn đổi lớp máy — nâng cấp thế hệ, đổi sang Graviton, hay đơn giản là xoá cụm cũ dựng cụm mới khác cỡ — thì RI vẫn tiếp tục được tính tiền đều đặn trong khi không giảm giá cho gì cả. Không có cảnh báo nào, không có dòng log nào; hoá đơn vẫn về đúng hạn với đúng số tiền cam kết, và khoản chi ấy chỉ hiện ra khi có người mở đúng báo cáo và thấy con số utilization đang ở mức vài phần trăm.

Đáp án

D — Tạo AWS WAF web ACL với luật geo-match chặn request từ ngoài quốc gia chỉ định, rồi gắn web ACL vào ALB.

Vì sao đúng

Đề nêu ba yêu cầu, và WAF geo-match là thứ duy nhất đáp ứng cả ba mà không phải bảo trì gì.

⚠ Điểm mấu chốt: geo-match tra cứu bằng CSDL do AWS duy trì, đó chính là chỗ khác biệt với việc tự giữ danh sách IP:

Request tới ALB
        ↓
    WAF tra IP nguồn trong CSDL địa lý của AWS
        ↓
    Không thuộc quốc gia cho phép
        ↓
    → chặn, và ghi một bản ghi log đầy đủ

Dải IP theo quốc gia thay đổi liên tục — nhà mạng được cấp dải mới, dải cũ chuyển chủ, IPv6 mở rộng. Tự giữ danh sách nghĩa là nhận một công việc bảo trì không bao giờ kết thúc, và mỗi lần lỡ cập nhật là chặn nhầm khách thật. Geo-match đẩy toàn bộ việc đó sang AWS.

# luật geo-match: chặn mọi thứ không đến từ Việt Nam
cat > luat-dia-ly.json <<'JSON'
[{
  "Name": "ChiChoVN", "Priority": 0,
  "Statement": {"NotStatement": {"Statement": {
    "GeoMatchStatement": {"CountryCodes": ["VN"]}
  }}},
  "Action": {"Block": {}},
  "VisibilityConfig": {"SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true, "MetricName": "ChiChoVN"}
}]
JSON

aws wafv2 create-web-acl --name chi-cho-vn --scope REGIONAL \
  --default-action Allow={} --rules file://luat-dia-ly.json \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=chiChoVN

# bật log để đáp ứng yêu cầu ghi nhận lượt bị chặn
aws wafv2 put-logging-configuration --logging-configuration \
  ResourceArn=<web-acl-arn>,LogDestinationConfigs=<firehose-arn>

⚠ WAF gắn vào ALB thì scope là REGIONAL, gắn vào CloudFront thì scope là CLOUDFRONT và phải tạo ở us-east-1:

Tạo web ACL scope REGIONAL rồi thử gắn vào CloudFront
        ↓
    → không gắn được, và thông báo lỗi không nói rõ nguyên nhân

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

• C (tạo IPSet chứa dải IP của quốc gia đó, luật WAF từ chối request ngoài dải) — đây là phương án gần nhất và nó dùng đúng dịch vụ, đúng chỗ gắn, và ghi log được y hệt: về mặt kỹ thuật nó chạy. Nó chỉ thua ở đúng tiêu chí đề nhấn mạnh — low maintenance. Ai đó phải đi lấy danh sách dải IP của cả một quốc gia, nạp vào IPSet, rồi cập nhật nó mãi mãi. Một IPSet còn có trần 10.000 mục, trong khi một quốc gia lớn có nhiều dải hơn thế. Và mỗi lần danh sách lỗi thời, hậu quả không phải là lỗi rõ ràng mà là khách thật bị chặn nhầm — thứ chỉ phát hiện được qua khiếu nại. Đây là bẫy hay của câu này: nó đúng về mọi mặt trừ mặt được hỏi.

• A (AWS Shield từ chối request ngoài quốc gia) — sai vai trò dịch vụ. Shield là chống DDoS, nó bảo vệ khỏi tấn công làm cạn tài nguyên ở tầng 3/4 và một phần tầng 7. Nó không có luật lọc theo quốc gia và không phải công cụ kiểm soát truy cập. Shield Advanced có gói WAF đi kèm, nhưng việc lọc vẫn do WAF làm chứ không phải Shield.

• B (security group cho ALB chỉ cho phép dải IP của quốc gia đó trên cổng 80/443) — hai vấn đề. Thứ nhất, cùng gánh nặng bảo trì như C nhưng tệ hơn: security group có trần khoảng 60 rule mỗi group (nâng lên được nhưng vẫn rất hạn chế), không đủ chỗ cho dải IP của một quốc gia. Thứ hai, và đây là điểm quyết định: security group không ghi log thứ nó chặn. Yêu cầu "log any access attempts that are blocked" không thể đáp ứng bằng security group — bạn sẽ phải bật VPC Flow Logs rồi tự suy luận, mà Flow Logs không có thông tin HTTP.

Ghi nhớ

⚠ Bốn loại luật WAF hay dùng — bảng phải thuộc: | Loại luật | Chặn theo | |---|---| | Geo match | quốc gia của IP nguồn | | IP set | dải IP cụ thể bạn tự quản | | Rate-based | số request từ một IP trong 5 phút | | Managed rule group | bộ luật AWS/bên thứ ba soạn sẵn (SQLi, XSS, bot) |

Từ khoá nhận diện:

"only users from a specific country" → geo-match "log blocked attempts" → WAF (security group không ghi log) "low maintenance" → loại mọi phương án phải tự giữ danh sách IP "Shield to filter by country" → LUÔN SAI, Shield là chống DDoS "security group with country IP ranges" → SAI về cả trần rule lẫn khả năng ghi log

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật có chặn đúng không | chạy ở chế độ Count trước, xem log vài ngày | | Ai đang bị chặn | WAF log đẩy sang Firehose/S3, truy vấn bằng Athena | | Có chặn nhầm không | so số request bị chặn với lưu lượng bình thường theo giờ |

Và một lời khuyên: hãy bật luật ở chế độ Count trước vài ngày rồi mới chuyển sang Block. Chặn theo địa lý có một loại thiệt hại rất khó nhìn thấy: người dùng hợp lệ đang đi công tác, đang dùng VPN doanh nghiệp có điểm ra ở nước khác, hoặc thuộc một nhà mạng bị gán nhầm quốc gia trong CSDL địa lý. Với họ, trang chỉ đơn giản là không mở được — không có thông báo, không có cách nào tự khắc phục, và phần lớn sẽ bỏ đi thay vì báo cho ai đó. Số liệu của bạn sẽ hiện đúng thứ bạn muốn thấy: lưu lượng nước ngoài về 0. Chỉ có điều một phần trong số đó lẽ ra là khách hàng.

Đáp án

B — Tạo SCP với hiệu lực Deny trên hành động ec2:PurchaseReservedInstancesOffering, gắn vào ROOT của tổ chức.

Vì sao đúng

Đề có một chi tiết quyết định mà nhiều người lướt qua: "current and future member accounts". Chữ future loại thẳng mọi phương án dựa trên việc di chuyển tài khoản vào một OU cụ thể.

⚠ Điểm mấu chốt: SCP KHÔNG ÁP CHO management account — đây chính là cơ chế làm cho phương án B hoạt động:

SCP Deny ec2:PurchaseReservedInstancesOffering gắn ở root
        ↓
    Mọi OU và mọi tài khoản thành viên đều thừa hưởng → bị chặn
        ↓
    Management account (master) KHÔNG chịu tác động của SCP
        ↓
    → chỉ master mua được RI, đúng yêu cầu, không cần luật ngoại lệ nào

Đây là một trong số ít trường hợp mà hạn chế nổi tiếng của SCP lại chính là tính năng cần dùng. Ở hầu hết bài toán, việc SCP không áp cho management account là một cái bẫy (như đã thấy ở các câu về kiểm thử chính sách). Ở đây nó là lời giải.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ChiMasterDuocMuaRI",
    "Effect": "Deny",
    "Action": [
      "ec2:PurchaseReservedInstancesOffering",
      "ec2:PurchaseHostReservation",
      "rds:PurchaseReservedDBInstancesOffering",
      "elasticache:PurchaseReservedCacheNodesOffering",
      "redshift:PurchaseReservedNodeOffering",
      "savingsplans:CreateSavingsPlan"
    ],
    "Resource": "*"
  }]
}

⚠ Chặn mỗi EC2 RI là để hở nhiều cửa khác cùng tác dụng tài chính:

Chỉ Deny ec2:PurchaseReservedInstancesOffering
        ↓
    Tài khoản thành viên vẫn mua được Savings Plans, RDS RI, ElastiCache RI...
        ↓
    → cam kết tài chính dài hạn vẫn phát sinh ngoài tầm kiểm soát
        ↓
    → và cam kết đó KHÔNG huỷ được, chỉ bán lại được trong một số trường hợp

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

• C (chuyển mọi tài khoản thành viên hiện tại sang một OU mới, gắn SCP Deny vào OU đó) — đây là phương án gần nhất và nó thật sự chặn được các tài khoản hiện tại: SCP đúng, hành động đúng, hiệu lực đúng. Nó chỉ hỏng ở đúng chữ "future" trong đề. Tài khoản mới tạo ra sau này sẽ nằm ở nơi mặc định — thường là ngay dưới root — chứ không tự vào OU mới đó. Ai đó phải nhớ di chuyển từng tài khoản mới, mãi mãi. Đây là kiểu giải pháp đúng ở thời điểm triển khai rồi mục ruỗng dần: mỗi tài khoản bị quên là một lỗ hổng, và không có gì báo cho bạn biết. Gắn ở root thì bài toán "nhớ di chuyển" không tồn tại.

• A (OU riêng cho master và cho từng thành viên, gắn SCP Allow vào OU của master) — hiểu sai bản chất SCP. SCP không cấp quyền, nên một SCP Allow không cho phép ai làm gì thêm; nó chỉ mở rộng trần khi có Deny ở nơi khác. Ở đây không có Deny nào cả, nên các tài khoản thành viên vẫn mua RI thoải mái. Phương án này còn thừa: đặt master vào một OU là việc không cần thiết, vì SCP vốn đã không chạm tới nó.

• D (CloudWatch Events kích hoạt Lambda huỷ RI mà tài khoản thành viên mua) — phát hiện và dọn dẹp thay vì ngăn chặn, và ở đây việc dọn dẹp không khả thi. Reserved Instance là cam kết tài chính không huỷ được: mua rồi thì tiền đã tiêu, dù bạn có "terminate" gì đi nữa. Cách duy nhất thoát ra là bán lại trên RI Marketplace, vốn chỉ áp dụng cho một số loại RI và không đảm bảo bán được. Phương án này còn nhầm thuật ngữ: RI không phải là thứ được "launch" để rồi "terminate" — nó là một khoản giảm giá gắn với hoá đơn, không phải một tài nguyên đang chạy.

Ghi nhớ

⚠ Bốn điều về phạm vi SCP — bảng phải thuộc: | Điều | Nội dung | |---|---| | Không áp cho management account | dù gắn ở root — vừa là bẫy vừa là tính năng | | Không áp cho service-linked role | các role dịch vụ tự tạo vẫn chạy | | Gắn ở root | phủ mọi OU và mọi tài khoản, kể cả tài khoản tạo sau này | | Chỉ đặt trần | không cấp quyền, luôn cần IAM policy song song |

Từ khoá nhận diện:

"current and future member accounts" → gắn ở root, không phải ở OU "only the master account can ..." → SCP Deny ở root (master miễn nhiễm) "apply an SCP with the Allow effect" để cấp quyền → LUÔN SAI, SCP không cấp quyền "Lambda to terminate Reserved Instances" → SAI, RI không huỷ được "move accounts to a new OU" khi cần phủ cả tài khoản tương lai → mong manh, dễ quên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SCP có chặn thật không | thử aws ec2 purchase-reserved-instances-offering trong tài khoản thành viên | | Ai đã mua gì | lọc CloudTrail theo các tên hành động ở bảng trên | | RI đang dùng ra sao | báo cáo RI utilization và coverage trong Cost Explorer |

Và một lời khuyên: hãy chặn cả savingsplans:CreateSavingsPlan trong cùng chính sách, đừng chỉ chặn EC2 RI. Đây là lỗ hổng im lặng kinh điển của loại chính sách này: bạn triển khai SCP, thử nghiệm thấy lệnh mua RI bị từ chối, và coi như xong việc. Trong khi đó Savings Plans — một cam kết tài chính tương đương, cũng một hoặc ba năm, cũng không huỷ được — vẫn mua được bình thường từ bất kỳ tài khoản thành viên nào. Không có gì bị chặn, không có gì bị ghi lại như một vi phạm, và khoản cam kết chỉ xuất hiện vào kỳ hoá đơn tiếp theo dưới dạng một dòng chi phí mà không ai trong đội tài chính nhớ đã duyệt.

Đáp án

C, D — hai bước để quản lý tập trung dịch vụ hạ tầng và phân phối theo nguyên tắc quyền tối thiểu:

• C — Định nghĩa dịch vụ hạ tầng bằng CloudFormation template, tải mỗi template lên làm Service Catalog product trong các portfolio ở một tài khoản trung tâm, rồi chia sẻ portfolio với cấu trúc AWS Organizations.
• D — Cho người dùng IAM chỉ quyền AWSServiceCatalogEndUserReadOnlyAccess, gán cho nhóm Endusers, và áp dụng launch constraint.

Vì sao đúng

Đề nêu ba yêu cầu, và AWS Service Catalog là dịch vụ được thiết kế đúng cho cả ba.

⚠ Điểm mấu chốt: launch constraint là thứ cho phép người dùng KHÔNG có quyền vẫn dựng được tài nguyên:

Người dùng chỉ có AWSServiceCatalogEndUserReadOnlyAccess
        ↓
    Bấm "Launch" trên một product trong portfolio
        ↓
    Service Catalog KHÔNG dùng quyền của người dùng
        ↓
    Nó assume vào IAM role khai trong launch constraint
        ↓
    → CloudFormation dựng RDS, EC2, VPC bằng quyền của ROLE đó
        ↓
    → người dùng không bao giờ cần quyền ec2:RunInstances hay rds:CreateDBInstance

Đây là toàn bộ giá trị của Service Catalog và là câu trả lời cho "least privilege". Không có launch constraint thì người dùng phải có đủ quyền tạo mọi tài nguyên trong template — nghĩa là họ cũng có thể tạo chúng trực tiếp, ngoài mọi khuôn khổ, và Service Catalog trở thành vô nghĩa.

# gán role dựng tài nguyên cho product — người dùng mượn quyền của role này
aws servicecatalog create-constraint \
  --portfolio-id port-abc --product-id prod-xyz --type LAUNCH \
  --parameters '{"RoleArn":"arn:aws:iam::111122223333:role/ServiceCatalogLaunchRole"}'

# chia sẻ portfolio với cả tổ chức, không phải từng tài khoản
aws servicecatalog create-portfolio-share \
  --portfolio-id port-abc \
  --organization-node Type=ORGANIZATION,Value=o-abc123

⚠ EndUserFullAccess phá vỡ chính nguyên tắc quyền tối thiểu: | Policy | Người dùng làm được | |---|---| | EndUserReadOnlyAccess | xem product, launch, xem provisioned product của mình | | EndUserFullAccess | thêm quyền cập nhật và chấm dứt provisioned product, thao tác rộng hơn |

Với yêu cầu "limit end users' permissions", bản read-only là lựa chọn đúng.

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

• A (AWSServiceCatalogEndUserFullAccess + nhóm Endusers + launch constraint) — đây là phương án gần nhất và hai phần ba của nó đúng: dùng nhóm Endusers và áp launch constraint đều chuẩn. Nó chỉ sai ở việc chọn bản Full thay vì ReadOnly của policy. Với một câu nêu thẳng "follow the principle of least privilege to limit end users' permissions", chọn policy rộng hơn khi bản hẹp hơn đã đủ việc là sai đúng vào tiêu chí được hỏi. Đây là bẫy đọc nhanh: hai tên policy chỉ khác nhau một từ, và người đọc lướt rất dễ chọn nhầm.

• B (template CloudFormation trong bucket S3 trung tâm, thêm IAM user vào bucket policy) — mất hết những gì Service Catalog mang lại. Người dùng tải template về rồi tự chạy create-stack, nghĩa là họ phải có đủ quyền tạo mọi tài nguyên trong đó — trái hẳn với quyền tối thiểu. Không có kiểm soát phiên bản product, không có danh mục được duyệt, không có ràng buộc tham số, và không có gì ngăn họ sửa template trước khi chạy.

• E (cấp AWSCloudFormationFullAccess + AmazonS3ReadOnlyAccess, dùng SCP chặn mọi dịch vụ trừ CloudFormation và S3) — nghe có vẻ chặt nhưng thực chất rất lỏng, vì hiểu sai cách CloudFormation hoạt động. CloudFormation dựng tài nguyên bằng quyền của người gọi (trừ khi khai service role). Nếu SCP chặn mọi dịch vụ trừ CloudFormation và S3 thì template sẽ thất bại ngay khi thử tạo EC2 hay RDS. Còn nếu nới SCP ra cho các dịch vụ đó thì người dùng lại có quyền tạo chúng trực tiếp. Phương án này không có đường ra đúng ở cả hai chiều.

Ghi nhớ

⚠ Bốn loại constraint của Service Catalog — bảng phải thuộc: | Loại | Việc | |---|---| | Launch | chỉ định IAM role mà Service Catalog assume để dựng tài nguyên | | Template | giới hạn giá trị tham số người dùng nhập được | | Notification | gửi thông báo SNS khi có sự kiện stack | | Stack set | triển khai ra nhiều tài khoản và Region cùng lúc |

Từ khoá nhận diện:

"pre-approved IT services" / "standardized products" → Service Catalog "least privilege" + người dùng vẫn phải dựng được tài nguyên → launch constraint "distribute to multiple accounts in Organizations" → portfolio share với organization node "EndUserFullAccess" khi đề nói least privilege → SAI, dùng bản ReadOnly "put templates in S3 and let users run them" → SAI, mất hết kiểm soát

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Launch constraint có hoạt động không | đăng nhập bằng chính người dùng cuối và bấm launch | | Role có đủ quyền không | xem sự kiện stack thất bại trong CloudFormation | | Portfolio đã tới tài khoản con chưa | aws servicecatalog list-accepted-portfolio-shares ở tài khoản đó |

Và một lời khuyên: hãy thử launch bằng chính danh tính của người dùng cuối, đừng thử bằng tài khoản quản trị. Đây là chỗ cấu hình Service Catalog hay hỏng nhất mà không ai phát hiện trong lúc dựng: quản trị viên tạo portfolio, thêm product, bấm launch thử và thấy chạy hoàn hảo — nhưng nó chạy bằng quyền quản trị của chính họ, không đi qua launch constraint chút nào. Cấu hình role thiếu quyền, hoặc trust policy của role không cho Service Catalog assume, đều không lộ ra ở phép thử đó. Chúng chỉ lộ ra vào ngày người dùng thật bấm nút, nhận về một stack thất bại giữa chừng với thông báo AccessDenied trỏ tới một role họ chưa từng nghe tên.

Đáp án

B, C, F — ba công cụ để khảo sát môi trường và ước tính chi phí sau di chuyển:

• B — AWS Application Discovery Service
• C — AWS Cloud Adoption Readiness Tool (CART)
• F — AWS Migration Hub

Vì sao đúng

Đề mô tả một môi trường hỗn tạp và không có CMDB, rồi đòi hai thứ: hiểu môi trường hiện tại và ước tính chi phí sau khi lên cloud. Ba công cụ đúng chia nhau đúng ba vai.

⚠ Điểm mấu chốt: Discovery Service thu thập, Migration Hub là nơi dữ liệu đó sống — hai cái luôn đi cùng nhau:

Discovery Agent / Connector chạy tại chỗ
        ↓
    Đẩy dữ liệu về Application Discovery Service
        ↓
    Dữ liệu hiện ra trong AWS Migration Hub
        ↓
    Ở đó: nhóm máy chủ thành ứng dụng, xem phụ thuộc, theo dõi từng làn di chuyển

Nói cách khác, chọn B mà không chọn F là có dữ liệu mà không có nơi làm việc với nó; chọn F mà không chọn B là có bảng điều khiển trống.

Về môi trường hỗn tạp của đề — Windows và Linux, máy vật lý và máy ảo, MySQL và Oracle — Discovery Service phủ được nhờ hai chế độ:

CART (C) là mảnh ghép khác hẳn về bản chất. Nó không phải công cụ kỹ thuật — không cài gì, không quét gì. Đó là một bảng khảo sát đánh giá mức sẵn sàng của tổ chức trên các trục: nhân sự, quy trình, quản trị, bảo mật, kỹ năng vận hành. Kết quả là một báo cáo chỉ ra khoảng trống cần lấp và giúp lập kế hoạch ở mức chương trình.

⚠ CART và Migration Evaluator trả lời hai câu hỏi khác nhau:

"Tổ chức của tôi đã sẵn sàng di chuyển chưa?"
        ↓
    → CART — đánh giá năng lực, quy trình, con người

"Chạy đội máy này trên AWS tốn bao nhiêu tiền?"
        ↓
    → Migration Evaluator (trước là TSO Logic) — mô hình hoá chi phí chi tiết

Trong danh sách phương án của đề không có Migration Evaluator, nên CART là lựa chọn hợp lý nhất cho vế "ước tính".

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

• E (AWS Server Migration Service) — đây là phương án gần nhất và nó thật sự là một công cụ di chuyển thật, đúng lĩnh vực: SMS sao chép máy ảo tại chỗ lên AWS thành AMI. Nhưng nó thuộc giai đoạn thực thi, không thuộc giai đoạn lập kế hoạch mà đề đang hỏi. SMS không khảo sát gì, không đo hiệu năng, không phát hiện phụ thuộc và không ước tính chi phí — nó chỉ chuyển máy khi bạn đã biết máy nào cần chuyển. Còn một điểm nữa đáng nhớ: SMS đã ngừng nhận khách hàng mới và được thay bằng AWS Application Migration Service (MGN), nên đây là một dấu hiệu tuổi đời của bộ đề.

• A (CloudWatch Logs) — thu thập log của tài nguyên đang chạy trên AWS. Ở giai đoạn này công ty còn chưa có gì trên AWS, và CloudWatch Logs không nhìn thấy máy chủ tại chỗ trừ khi bạn tự cài agent và tự đẩy log lên — mà kể cả vậy thì log ứng dụng cũng không cho ra kho máy, quan hệ phụ thuộc hay ước tính chi phí.

• D (AWS Config) — ghi lại cấu hình tài nguyên AWS và đánh giá chúng theo quy tắc tuân thủ. Cũng như CloudWatch Logs, nó nhìn vào bên trong AWS, không nhìn ra trung tâm dữ liệu tại chỗ. Config trả lời "tài nguyên AWS của tôi có lệch chuẩn không", một câu hỏi thuộc giai đoạn sau khi đã di chuyển xong.

Ghi nhớ

⚠ Bốn giai đoạn di chuyển và công cụ tương ứng — bảng phải thuộc: | Giai đoạn | Công cụ | |---|---| | Đánh giá (Assess) | CART, Migration Evaluator | | Khảo sát (Discover) | Application Discovery Service, Migration Hub | | Di chuyển (Migrate) | MGN (thay SMS), DMS + SCT, DataSync, Snow Family | | Vận hành (Operate) | CloudWatch, Config, Systems Manager |

Từ khoá nhận diện:

"no CMDB, documentation outdated" → Application Discovery Service "understand the current environment" → Discovery Service + Migration Hub "estimate cloud resource costs" → Migration Evaluator, hoặc CART nếu không có Evaluator trong danh sách "readiness" → CART "Server Migration Service" ở giai đoạn lập kế hoạch → SAI, đó là công cụ thực thi (và đã bị MGN thay thế)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã khảo sát đủ máy chưa | so số máy trong Migration Hub với kiểm kê vật lý | | Có dữ liệu phụ thuộc chưa | mở đồ thị Network Connections của vài máy | | Ước tính có sát không | đối chiếu số liệu hiệu năng thu được với lớp máy được đề xuất |

Và một lời khuyên: hãy để giai đoạn khảo sát chạy đủ ít nhất một chu kỳ tháng trước khi chốt bất kỳ ước tính nào. Đây là chỗ các dự án di chuyển hay trượt dự toán nhất, và trượt một cách hoàn toàn im lặng: dữ liệu thu trong một tuần bình thường trông rất sạch, rất đầy đủ, đủ để dựng một bảng chi phí trông thuyết phục. Nhưng nó không chứa đợt chốt sổ cuối tháng, không chứa job báo cáo cuối quý, không chứa mùa cao điểm. Không có gì trong báo cáo cảnh báo bạn rằng nó đang thiếu những thứ đó — chúng chỉ đơn giản là chưa xảy ra trong khoảng thời gian bạn đo, và hệ quả xuất hiện nhiều tháng sau dưới dạng những máy được cấp quá nhỏ vào đúng tuần bận nhất năm.

Đáp án

D — Dùng Tag Editor gắn tag cho tài nguyên hiện có, tạo cost allocation tag cho cost center và project ID, và dùng SCP chặn việc tạo tài nguyên không có hai tag đó.

Vì sao đúng

Đề đòi ba việc, và phương án D là phương án duy nhất làm đủ cả ba bằng công cụ đúng.

⚠ Điểm mấu chốt: cost allocation tag chỉ hiện trong báo cáo chi phí sau khi được KÍCH HOẠT, và nó không hồi tố:

Gắn tag lên tài nguyên
        ↓
    Tag tồn tại, nhưng chưa xuất hiện trong Cost Explorer
        ↓
    Phải vào Billing console kích hoạt nó làm cost allocation tag
        ↓
    Chờ tới 24 giờ
        ↓
    → từ đó trở đi chi phí mới được phân bổ — CHI PHÍ TRƯỚC ĐÓ KHÔNG ĐƯỢC GÁN LẠI

Đây là chi tiết đáng nhớ nhất của cả câu hỏi: kích hoạt muộn một tháng là mất khả năng phân tích chi phí của tháng đó, vĩnh viễn.

Vì sao SCP là cách ép tag đúng. Đề nói công ty dùng AWS Organizations và CloudFormation, và yêu cầu là mọi EC2/RDS tương lai đều phải có tag. SCP chặn ngay tại lời gọi API, nên không tài nguyên nào lọt qua:

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
  "Resource": "*",
  "Condition": {
    "Null": {
      "aws:RequestTag/CostCenter": "true",
      "aws:RequestTag/ProjectId": "true"
    }
  }
}

Điều kiện Null với giá trị "true" nghĩa là "chặn khi tag này không có mặt trong request". Vì SCP áp ở tầng tổ chức, nó phủ luôn cả tài nguyên do CloudFormation dựng — CloudFormation gọi cùng những API đó.

⚠ Ép tag phải chặn cả CreateTags và DeleteTags, nếu không người ta gắn tag rác rồi sửa sau:

Chỉ chặn ở RunInstances
        ↓
    Người dùng truyền CostCenter=x cho qua cửa
        ↓
    Rồi gọi DeleteTags hoặc CreateTags đè giá trị khác
        ↓
    → tài nguyên tồn tại với tag sai hoặc không tag, mà không vi phạm luật nào

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

• B (Tag Editor + cost allocation tag + chờ 24 giờ) — đây là phương án gần nhất và hai bước đầu của nó giống hệt đáp án đúng: gắn tag cho tài nguyên cũ và kích hoạt cost allocation tag đều chuẩn, kể cả chi tiết "chờ 24 giờ" cũng chính xác. Nó chỉ thiếu đúng một thứ — không có gì ép tài nguyên TƯƠNG LAI phải có tag. Mà đề nói thẳng: "cost center numbers and project ID numbers are added to all future EC2 instances and RDS databases". Không có cơ chế ép buộc thì việc gắn tag phụ thuộc vào trí nhớ của người dựng hạ tầng, và sau vài tháng tỷ lệ phủ tag sẽ tụt dần mà không ai để ý cho tới kỳ phân tích chi phí tiếp theo.

• C (cost allocation tag + permissions boundary chặn tạo tài nguyên thiếu tag) — sai công cụ ép buộc. Permissions boundary gắn vào IAM user hoặc role, không gắn vào tài khoản, nên muốn phủ toàn tổ chức thì phải gắn cho từng entity trong từng tài khoản và duy trì mãi. Nó cũng bỏ qua bước gắn tag cho tài nguyên hiện có — mà đề nói chi phí đã tăng rồi, tức là tài nguyên đã tồn tại và cần được phân loại ngay.

• A (Config rule tìm tài nguyên thiếu tag + Lambda tự gắn tag mỗi giờ qua cross-account role) — phát hiện rồi sửa thay vì ngăn chặn, và ở đây việc sửa không thể đúng được. Câu hỏi cốt lõi là: Lambda lấy đâu ra giá trị cost center và project ID? Nó không thể suy ra thứ chỉ người tạo tài nguyên mới biết. Kết quả thực tế sẽ là gắn một giá trị mặc định kiểu unknown, tức là tag có mặt nhưng vô dụng cho việc phân bổ chi phí. Thêm nữa, chu kỳ một giờ để lại khoảng trống chi phí không gán được, và giải pháp này đòi triển khai Config + Lambda + cross-account role cho mọi tài khoản — nhiều việc hơn hẳn một SCP.

Ghi nhớ

⚠ Bốn cách ép chuẩn tag — bảng phải thuộc: | Cách | Thời điểm | Phạm vi | |---|---|---| | SCP với điều kiện aws:RequestTag | chặn lúc tạo | toàn tổ chức | | Tag policy của Organizations | chuẩn hoá khoá và giá trị, có thể chỉ báo cáo | toàn tổ chức | | IAM policy với aws:RequestTag | chặn lúc tạo | từng entity | | AWS Config rule required-tags | phát hiện sau | báo cáo, không chặn |

Từ khoá nhận diện:

"track costs by cost center / project" → cost allocation tag "all FUTURE resources must have tags" → SCP hoặc IAM condition, không phải Config "tag existing resources" → Tag Editor (Resource Groups) "permissions boundaries applied to an account" → LUÔN SAI, boundary gắn cho IAM entity "Lambda tự gắn tag thiếu" → SAI, không suy ra được giá trị đúng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỷ lệ phủ tag hiện tại | Tag Editor lọc tài nguyên thiếu tag, hoặc Config rule required-tags | | Tag đã kích hoạt chưa | Billing console → Cost allocation tags → trạng thái Active | | SCP có chặn thật không | thử run-instances không kèm tag trong tài khoản thành viên |

Và một lời khuyên: hãy kích hoạt cost allocation tag ngay hôm nay, ngay cả khi chiến lược tag của bạn còn chưa hoàn chỉnh. Đây là mất mát im lặng đặc trưng của quản trị chi phí: tag vẫn nằm trên tài nguyên, mọi thứ trông như đã sẵn sàng, và bạn tin rằng khi nào cần thì mở Cost Explorer ra nhóm theo cost center là xong. Nhưng dữ liệu phân bổ chỉ tồn tại cho khoảng thời gian sau khi tag được kích hoạt — những tháng trước đó vĩnh viễn không thể tách được theo cost center, dù tag đã ở trên tài nguyên suốt thời gian ấy. Không có cảnh báo nào cho chuyện này, và nó chỉ lộ ra vào đúng lúc ban lãnh đạo hỏi chi phí quý vừa rồi thuộc về dự án nào.