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

Đáp án

C — Tạo hai ổ gp2 dung lượng 4 TB và gắn chúng theo RAID 0 trên EC2 instance.

Vì sao đúng

Điểm mấu chốt nằm ở cách tính IOPS của gp2 và cái trần cứng của nó.

⚠ Công thức gp2 và trần 16.000 IOPS:

gp2 cho 3 IOPS mỗi GB
        ↓
    8 TB = 8192 GB → 8192 × 3 = 24.576 IOPS trên lý thuyết
        ↓
    NHƯNG mỗi volume gp2 bị chặn ở 16.000 IOPS
        ↓
    Và ở kích thước 8 TB, hiệu năng thực tế
    đã chạm mức mà đề mô tả (10.000 IOPS)
        ↓
    → tăng dung lượng thêm KHÔNG giúp gì nữa

⚠ RAID 0 phá trần bằng cách CỘNG hiệu năng của nhiều volume:

Hai ổ gp2 4 TB, mỗi ổ 4096 × 3 = 12.288 IOPS
        ↓
    Gắn RAID 0 (striping)
        ↓
    → IOPS CỘNG LẠI, băng thông CỘNG LẠI
    → tổng dung lượng vẫn là 8 TB
        ↓
    → CHI PHÍ GẦN NHƯ KHÔNG ĐỔI (vẫn trả tiền cho 8 TB gp2)
    → đúng yêu cầu "giữ chi phí ở mức cũ" của đề

⚠ Nhưng phải hiểu rõ cái giá của RAID 0:

RAID 0 KHÔNG có dự phòng nào
        ↓
    Một volume hỏng → MẤT TOÀN BỘ dữ liệu trên cả dải
        ↓
    → xác suất hỏng NHÂN ĐÔI so với một volume
        ↓
    → bắt buộc phải có snapshot đều đặn
    → và snapshot RAID phải chụp NHẤT QUÁN cả bộ
      (dùng lệnh create-snapshots số nhiều)

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

• B (chuyển gp2 sang io1 rồi tăng PIOPS) — đây là phương án gần nhất và về kỹ thuật thì đúng: io1 lên tới 64.000 IOPS. Nhưng nó vi phạm ràng buộc về chi phí của đề — io1 đắt hơn gp2 đáng kể, và bạn còn phải trả riêng cho mỗi IOPS đã cấp phát. (Trong đời thực, gp3 mới là câu trả lời tốt nhất — xem phần Ghi nhớ.)

• A (hai ổ 4 TB gắn RAID 1) — RAID 1 là nhân bản (mirroring): cùng dữ liệu ghi lên cả hai ổ. Nó tăng độ an toàn nhưng không cộng IOPS ghi, và bạn trả tiền cho 8 TB để chỉ dùng được 4 TB.

• D (bật "burst mode" trên ổ gp2) — không có công tắc nào tên như vậy. Cơ chế burst của gp2 là tự động và dựa trên tín dụng I/O, và volume từ 1 TB trở lên đã luôn chạy ở hiệu năng nền, không còn dùng tín dụng nữa.

Ghi nhớ

⚠ Các loại EBS volume — bảng phải thuộc: | Loại | IOPS tối đa | Đặc điểm | |---|---|---| | gp2 | 16.000 | 3 IOPS/GB, có burst khi volume nhỏ | | gp3 | 16.000 | IOPS và throughput cấp ĐỘC LẬP với dung lượng | | io1 | 64.000 | PIOPS, tỷ lệ tối đa 50:1 | | io2 | 64.000 | bền hơn, tỷ lệ 500:1 | | io2 Block Express | 256.000 | độ trễ dưới mili giây | | st1 | throughput cao | HDD, cho tải tuần tự (log, big data) | | sc1 | rẻ nhất | HDD lạnh, ít truy cập |

⚠ Trong đời thực, gp3 mới là câu trả lời hay nhất cho bài toán này:

gp3 cho SẴN 3.000 IOPS và 125 MB/s ở MỌI kích thước
        ↓
    Mua thêm IOPS tới 16.000 mà KHÔNG cần tăng dung lượng
        ↓
    → rẻ hơn gp2 khoảng 20% cho cùng dung lượng
    → chuyển đổi TẠI CHỖ, không gián đoạn (Elastic Volumes)
        ↓
    → đề này không nêu gp3 trong phương án, nên đáp án là RAID 0

Từ khoá nhận diện:

"vượt trần IOPS của một volume" → RAID 0, hoặc io2 Block Express "cần IOPS cao mà không cần dung lượng" → gp3 "cần dự phòng" → RAID 1 (hoặc tốt hơn: snapshot + Multi-AZ ở tầng ứng dụng) "gp2 burst mode" → KHÔNG TỒN TẠI như một công tắc "độ trễ thấp nhất, IOPS cực cao" → io2 Block Express "throughput tuần tự lớn, rẻ" → st1

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Volume có đang chạm trần không | chỉ số VolumeQueueLength — cao là đang xếp hàng | | Instance có đang chạm trần không | EBSIOBalance% tụt về 0 | | gp3 rẻ hơn bao nhiêu | tính lại giá: gp3 rẻ hơn gp2 và tách riêng phần IOPS |

Và một lời khuyên thẳng thắn về thứ tự cân nhắc: trước khi nghĩ tới RAID, hãy kiểm tra xem gp3 có giải quyết được không. RAID 0 thêm một lớp phức tạp vào hệ điều hành, nhân đôi rủi ro mất dữ liệu, và làm việc chụp snapshot khó hơn hẳn — trong khi gp3 cho bạn IOPS cần thiết bằng một lần modify-volume không gián đoạn, và thường còn rẻ hơn cấu hình gp2 đang có.

Đáp án

B — Direct Connect là thành phần KHÔNG nên dùng.

Vì sao đúng

Từ khoá quyết định nằm ở hai chữ trong đề: "software only" — chỉ bằng phần mềm, không dựng hạ tầng vật lý.

⚠ Điểm mấu chốt — VPN là phần mềm, Direct Connect là phần cứng và hợp đồng:

Site-to-Site VPN (software only)
        ↓
    Dựng trong VÀI PHÚT, hoàn toàn bằng cấu hình
    Chạy qua internet công cộng, mã hoá IPsec
        ↓
    Ba thành phần cần có:
        Virtual Private Gateway (phía AWS)
        Customer Gateway (đại diện thiết bị của bạn)
        Site-to-Site VPN connection (đường hầm nối hai bên)

Direct Connect
        ↓
    Đường CÁP VẬT LÝ riêng tới một Direct Connect location
    Cần hợp đồng với đối tác viễn thông, cần cross-connect
        ↓
    → mất HÀNG TUẦN tới HÀNG THÁNG để có
    → KHÔNG phải "software only"

⚠ Ba thành phần của VPN, phải nhớ đúng vai:

Điểm hay nhầm: Customer Gateway không phải thiết bị vật lý ở nhà bạn, nó là một đối tượng cấu hình trong AWS mô tả thiết bị đó.

⚠ Và một đặc điểm đáng nhớ về tính sẵn sàng:

Mỗi Site-to-Site VPN connection tự có HAI ĐƯỜNG HẦM
        ↓
    Hai đường ở HAI endpoint khác nhau của AWS
        ↓
    → AWS bảo trì một đường thì đường kia vẫn chạy
    → nhưng thiết bị PHÍA BẠN phải cấu hình dùng cả hai
      mới thật sự có dự phòng

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

(Ba phương án còn lại đều là thành phần CẦN dùng, nên chúng không phải đáp án cho câu hỏi "KHÔNG nên dùng cái nào".)

• A (Virtual Private Gateway) — là đầu mối phía AWS của kết nối VPN, bắt buộc phải có.

• C (Customer Gateway) — là đối tượng khai báo thiết bị VPN phía bạn, cũng bắt buộc.

• D (Site-to-Site VPN) — chính là kết nối cần dựng, đúng nghĩa "software only".

Ghi nhớ

⚠ Site-to-Site VPN và Direct Connect — bảng phải thuộc: | | Site-to-Site VPN | Direct Connect | |---|---|---| | Thời gian có được | vài phút | vài tuần tới vài tháng | | Đường truyền | internet công cộng | cáp riêng | | Mã hoá | có sẵn (IPsec) | KHÔNG mã hoá mặc định — cần thêm VPN hoặc MACsec | | Băng thông | tới ~1,25 Gbps mỗi đường hầm | 50 Mbps tới 100 Gbps | | Độ ổn định độ trễ | thay đổi theo internet | rất ổn định | | Chi phí | thấp | cao (cổng + truyền dữ liệu) |

Từ khoá nhận diện:

"software only", "nhanh", "ngay lập tức" → Site-to-Site VPN "băng thông ổn định, độ trễ đều" → Direct Connect "vừa riêng vừa mã hoá" → Direct Connect + VPN chạy đè lên "dự phòng cho Direct Connect" → VPN làm đường backup "nối nhiều VPC và nhiều chi nhánh" → Transit Gateway "nối một dịch vụ, không nối cả mạng" → PrivateLink

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đường hầm có lên không | describe-vpn-connections, xem trạng thái cả hai tunnel | | Định tuyến đã đúng chưa | route table của VPC phải có tuyến về mạng tại chỗ (bật route propagation) | | Lưu lượng có đi qua không | VPC Flow Logs, và chỉ số TunnelState |

Và một lời khuyên vận hành hay bị bỏ qua: hãy cấu hình thiết bị phía bạn để dùng CẢ HAI đường hầm của VPN, và đặt cảnh báo trên chỉ số TunnelState. Rất nhiều nơi chỉ cấu hình một đường hầm rồi coi VPN là "đã có dự phòng" — cho tới ngày AWS bảo trì đúng endpoint đó và kết nối tới trung tâm dữ liệu đứt hẳn, trong khi đường hầm thứ hai vẫn nằm đó, sẵn sàng, và chưa từng được cấu hình.

Đáp án

D — Dùng Cost Allocation Tags.

Vì sao đúng

Bẫy của câu này rất tinh vi: có tới hai phương án nói về tag, và chỉ một cái đúng.

⚠ Điểm mấu chốt — gắn tag KHÔNG làm cho tag hiện ra trong báo cáo chi phí:

Bước 1: gắn tag lên tài nguyên
        Department = KyThuat
        ↓
    → tag tồn tại, tìm kiếm được, lọc được
    → nhưng KHÔNG hiện trong Cost Explorer

Bước 2: KÍCH HOẠT tag đó làm COST ALLOCATION TAG
        Billing console → Cost allocation tags → Activate
        ↓
    → từ giờ tag mới xuất hiện trong dữ liệu chi phí
    → Cost Explorer nhóm theo nó được

Đây chính là khác biệt giữa phương án A và phương án D: "Tags" là điều kiện cần, "Cost Allocation Tags" mới là điều kiện đủ.

⚠ Vì sao đây là cách "ít công sức quản trị nhất" như đề yêu cầu:

Giữ nguyên MỘT tài khoản
        ↓
    Chỉ cần gắn tag + kích hoạt + mở Cost Explorer
        ↓
    → không phải di chuyển tài nguyên
    → không phải dựng lại quyền hạn
    → làm xong trong một buổi

⚠ Cảnh báo quan trọng — dữ liệu chi phí KHÔNG hồi tố:

Kích hoạt tag hôm nay
        ↓
    → chỉ áp cho dữ liệu chi phí TỪ NAY TRỞ ĐI
        ↓
    → hoá đơn tháng trước không được gắn tag lại
    → phải chờ tới chu kỳ thanh toán sau mới có báo cáo đầy đủ

Xem thêm câu #11590: cùng đáp án cost allocation tag nhưng đặt vấn đề từ chi phí Elastic IP nằm không — ở đó nhấn mạnh việc phát hiện lãng phí, còn ở đây nhấn mạnh việc phân bổ theo phòng ban.

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

• A (dùng Tags) — đây là phương án gần nhất và là bẫy chính. Gắn tag là một nửa việc; thiếu bước kích hoạt thì Cost Explorer không nhóm theo tag đó được, và bạn không có báo cáo nào cả.

• B (dùng AWS Organizations) — hoạt động được và là kiến trúc tốt hơn về lâu dài (tách tài khoản theo phòng ban thì chi phí tự tách bạch). Nhưng đề nói rõ "ít công sức quản trị nhất" và "hiện đang dùng chung một tài khoản" — tách hàng trăm tài nguyên sang nhiều tài khoản là một dự án lớn, không phải một cấu hình.

• C ("EC2 Billing Report") — không tồn tại dịch vụ nào tên như vậy. Các báo cáo chi phí thật là Cost Explorer, Cost and Usage Report (CUR), và Budgets.

Xem thêm câu #11663: cùng cơ chế cost allocation tag nhưng áp cho chi phí từng bucket S3 — ở đó có thêm S3 Storage Lens để biết chi phí đến từ đâu.

Ghi nhớ

⚠ Bộ công cụ chi phí của AWS — bảng phải thuộc: | Công cụ | Việc | |---|---| | Cost Explorer | xem và phân tích, nhóm theo tag / dịch vụ / tài khoản | | Cost and Usage Report (CUR) | dữ liệu thô chi tiết nhất, đổ vào S3 | | AWS Budgets | đặt ngân sách và cảnh báo khi sắp vượt | | Cost Anomaly Detection | phát hiện chi phí tăng bất thường | | Compute Optimizer | gợi ý giảm cỡ tài nguyên | | Trusted Advisor | khuyến nghị tối ưu chi phí |

Từ khoá nhận diện:

"chi phí theo phòng ban / dự án, một tài khoản" → Cost Allocation Tags "chỉ gắn tag là xong" → SAI, phải KÍCH HOẠT tag "tách bạch chi phí triệt để" → Organizations, mỗi phòng ban một tài khoản "cảnh báo khi vượt ngân sách" → AWS Budgets "EC2 Billing Report" → KHÔNG TỒN TẠI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tag đã kích hoạt chưa | Billing console → Cost allocation tags | | Bao nhiêu chi phí chưa gắn tag | Cost Explorer, nhóm theo tag, xem mục "No tag key" | | Tài nguyên nào thiếu tag | Tag Editor hoặc Config rule |

Và một lời khuyên khi triển khai: hãy kích hoạt cost allocation tag ngay cả khi chưa gắn tag xong cho toàn bộ tài nguyên. Vì dữ liệu chi phí không hồi tố, mỗi ngày trì hoãn là một ngày dữ liệu vĩnh viễn không phân bổ được — kích hoạt trước rồi gắn tag dần sẽ cho bạn báo cáo từng phần ngay từ tháng này, thay vì một khoảng trắng hoàn toàn cho tới khi công việc gắn tag hoàn tất.

Đáp án

D — Kiểm tra route table ở VPC B.

Vì sao đúng

Đề đã tự chỉ ra manh mối: "route table đã được cập nhật cho VPC A" — nghĩa là mới làm một phía.

⚠ Điểm mấu chốt — VPC peering đòi định tuyến ở CẢ HAI PHÍA:

VPC A route table: 10.2.0.0/16 → pcx-xxxxx   ✓ đã có
VPC B route table: 10.1.0.0/16 → pcx-xxxxx   ✗ THIẾU
        ↓
    Gói tin từ A đi sang B bình thường
        ↓
    B nhận được, xử lý xong, muốn trả lời
        ↓
    → B không biết đường về A
        ↓
    → gói trả lời rơi vào hư không
    → triệu chứng: TIMEOUT, không phải "connection refused"

Peering connection chỉ là một đường ống; nó không tự tạo tuyến đường nào. Bạn phải tự khai ở cả hai bên rằng "muốn tới dải kia thì đi qua ống này".

⚠ Danh sách kiểm tra đầy đủ cho VPC peering:

1. Peering connection ở trạng thái ACTIVE
       (bên nhận phải CHẤP NHẬN yêu cầu)
2. Route table VPC A → dải của B qua pcx
3. Route table VPC B → dải của A qua pcx   ← thường quên
4. Security Group hai bên cho phép dải IP của nhau
5. NACL hai bên cho phép cả hai chiều

⚠ Và ba giới hạn của peering phải thuộc:

KHÔNG bắc cầu (non-transitive)
        ↓
    A ↔ B và B ↔ C không làm cho A ↔ C
    → muốn A ↔ C phải tạo peering riêng

CIDR KHÔNG được chồng lấn
        ↓
    Hai VPC cùng dùng 10.0.0.0/16 → không peer được

KHÔNG dùng chung internet/NAT/VPC endpoint của nhau
        ↓
    Không "mượn" NAT Gateway của VPC bên kia được

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

• C (kiểm tra security group của instance) — đây là phương án gần nhất và là thứ đáng kiểm tra tiếp theo. Nhưng đề đã nêu rõ chỉ mới cập nhật route table của một phía, nên nguyên nhân có khả năng cao nhất là thiếu tuyến ở phía kia. (Trong đời thực thì SG cũng rất hay là thủ phạm — nhớ dùng tham chiếu SG chéo VPC, chỉ hoạt động khi hai VPC cùng Region.)

• B (kiểm tra NACL) — cũng đáng kiểm tra, nhưng NACL mặc định cho phép mọi thứ; nó chỉ thành vấn đề nếu ai đó đã sửa. Thiếu tuyến đường là nguyên nhân trực tiếp hơn.

• A (kiểm tra DNS Resolution có bật không) — chỉ ảnh hưởng tới việc phân giải tên miền riêng giữa hai VPC. Nếu kết nối bằng địa chỉ IP thì nó hoàn toàn không liên quan.

Ghi nhớ

⚠ Ba giới hạn của VPC Peering — bảng phải thuộc: | Giới hạn | Nội dung | |---|---| | Không bắc cầu | A↔B, B↔C không cho A↔C | | CIDR không được chồng lấn | kể cả một phần | | Không dùng chung gateway | không mượn NAT, IGW, VPC endpoint của nhau |

Từ khoá nhận diện:

"peering rồi mà không thông" → kiểm tra route table CẢ HAI PHÍA "nhiều VPC cần nối với nhau" → Transit Gateway, không phải peering từng cặp "CIDR trùng nhau" → peering KHÔNG được — dùng PrivateLink "chỉ cần lộ một dịch vụ" → PrivateLink "peering chéo Region" → được, nhưng tham chiếu SG thì KHÔNG

⚠ Peering so với Transit Gateway — bảng phải thuộc: | | VPC Peering | Transit Gateway | |---|---|---| | Số kết nối cho N VPC | N×(N−1)/2 — bùng nổ | N | | Bắc cầu | không | có | | Chi phí | chỉ trả tiền truyền dữ liệu | thêm phí gắn kết + phí xử lý dữ liệu | | Nối mạng tại chỗ | không | có, qua VPN/Direct Connect | | Khi nào dùng | vài VPC, đơn giản, rẻ | nhiều VPC, kiến trúc trung tâm |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Peering đã active chưa | describe-vpc-peering-connections | | Tuyến hai phía | describe-route-tables cho cả hai VPC | | Gói bị chặn ở đâu | VPC Flow Logs, tìm bản ghi REJECT |

Và một lời khuyên về kiến trúc dài hạn: nếu bạn đã có từ bốn năm VPC trở lên cần nối với nhau, hãy chuyển sang Transit Gateway trước khi mạng lưới peering trở nên không quản nổi. Với 5 VPC là 10 kết nối, với 10 VPC là 45 — và mỗi kết nối lại cần hai dòng route ở hai bảng khác nhau, nên đúng cái lỗi trong câu hỏi này sẽ lặp lại nhiều lần, mỗi lần một chỗ khác nhau.

Đáp án

B — Bật RDS Multi-AZ.

Vì sao đúng

Đề nêu ba yêu cầu, và Multi-AZ là lựa chọn duy nhất thoả cả ba:

⚠ Điểm mấu chốt — sao chép ĐỒNG BỘ nghĩa là không mất dữ liệu:

Ứng dụng gửi COMMIT
        ↓
    RDS ghi vào instance chính
        ↓
    ĐỒNG THỜI ghi sang standby ở AZ khác
        ↓
    Chỉ khi CẢ HAI đã ghi xong mới báo commit thành công
        ↓
    → mọi giao dịch đã commit CHẮC CHẮN có mặt ở standby
    → failover không mất giao dịch nào

Đối lập với read replica:

Read replica dùng sao chép BẤT ĐỒNG BỘ
        ↓
    Instance chính báo commit NGAY, không chờ replica
        ↓
    Máy chính chết đột ngột
        ↓
    → những giao dịch chưa kịp sao chép sang BỊ MẤT
    → vi phạm thẳng yêu cầu của đề

⚠ Failover diễn ra thế nào:

Instance chính không phản hồi
        ↓
    AWS phát hiện, chuyển bản ghi DNS của endpoint
    sang standby (thường 60–120 giây)
        ↓
    → ứng dụng KHÔNG cần đổi chuỗi kết nối
    → chỉ cần kết nối lại

Xem thêm câu #11581: cùng đáp án Multi-AZ nhưng đặt vấn đề từ góc "cách dễ và hiệu quả để có sẵn sàng cao", với bẫy là cấu hình TTL của JVM.

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

• A (read replica cùng Region + Lambda tự promote khi máy chính chết) — đây là phương án gần nhất và về mặt cơ khí thì chạy được. Nhưng nó vi phạm yêu cầu quan trọng nhất: sao chép bất đồng bộ có thể mất giao dịch đã commit. Ngoài ra bạn phải tự viết và tự bảo trì logic phát hiện lỗi — mà tự dựng cơ chế failover là một trong những thứ khó làm đúng nhất.

• D (read replica ở Region khác + Lambda promote) — cùng vấn đề mất dữ liệu, và còn tệ hơn: sao chép chéo Region có độ trễ cao hơn nhiều, nên cửa sổ mất dữ liệu rộng hơn. (Cách này hợp cho khôi phục thảm hoạ cấp Region, không phải cho sẵn sàng cao hằng ngày.)

• C (đặt CloudWatch alarm khi RAM vượt 90% rồi khởi động lại cơ sở dữ liệu) — chữa triệu chứng bằng cách gây ra sự cố: khởi động lại cơ sở dữ liệu là gián đoạn dịch vụ, và đề nói máy "đôi khi không phản hồi" chứ không nói nguyên nhân là RAM.

Ghi nhớ

⚠ Đồng bộ và bất đồng bộ — bảng phải thuộc, đây là chỗ quyết định mọi câu hỏi loại này: | | Multi-AZ (đồng bộ) | Read Replica (bất đồng bộ) | |---|---|---| | Mất dữ liệu khi failover | KHÔNG | CÓ THỂ | | Mục đích | sẵn sàng cao | chia tải đọc | | Phục vụ đọc | không | có | | Failover | tự động | thủ công (promote) | | Ảnh hưởng độ trễ ghi | có (phải chờ cả hai) | không |

Từ khoá nhận diện:

"không được mất giao dịch đã commit" → Multi-AZ (đồng bộ) "failover tự động" → Multi-AZ "chia tải đọc" → Read Replica "chịu được mất cả một Region" → cross-Region replica hoặc Aurora Global Database "tự viết Lambda để promote" → thường SAI khi đã có Multi-AZ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã bật Multi-AZ chưa | describe-db-instances, xem MultiAZ: true | | Failover mất bao lâu thật | reboot-db-instance --force-failover rồi bấm giờ | | Ứng dụng có nối lại được không | kiểm tra DNS cache và connection pool |

Và một lời khuyên rất thực tế: hãy chủ động kích hoạt failover mỗi quý một lần trong giờ bảo trì. Multi-AZ hứa chuyển đổi trong một tới hai phút, nhưng con số đó chỉ nói về phía cơ sở dữ liệu — thời gian ứng dụng của bạn thật sự hồi phục còn phụ thuộc vào DNS cache (JVM cache vĩnh viễn nếu không cấu hình), vào connection pool có phát hiện kết nối chết hay không, và vào logic thử lại — ba thứ chỉ lộ ra khi bạn thử thật.

Đáp án

D — Amazon Inspector.

Vì sao đúng

Câu này phân định rạch ròi hai việc mà nhiều người gộp làm một: VÁ lỗ hổng và CHỨNG MINH đã hết lỗ hổng.

⚠ Điểm mấu chốt — Patch Manager vá, Inspector chứng minh:

Systems Manager Patch Manager
        ↓
    Cài bản vá, báo cáo COMPLIANT / NON_COMPLIANT
        ↓
    → "máy đã cài đủ bản vá được duyệt chưa"

Amazon Inspector
        ↓
    Quét và đối chiếu với cơ sở dữ liệu CVE
        ↓
    → "máy còn LỖ HỔNG ĐÃ BIẾT nào không"
        ↓
    → đây mới là thứ báo cáo tuân thủ cần

Khác biệt tinh tế nhưng quan trọng: một máy có thể tuân thủ chính sách vá mà vẫn còn lỗ hổng — vì baseline chưa duyệt bản vá đó, vì lỗ hổng nằm trong thư viện của ứng dụng chứ không phải gói hệ điều hành, hoặc vì bản vá vừa mới được công bố.

⚠ Inspector thế hệ mới quét liên tục, không cần lên lịch:

Inspector v2 tự động quét khi:
        - có instance mới
        - có gói phần mềm được cài hoặc cập nhật
        - có CVE MỚI được công bố
        ↓
    → không cần "chạy quét hằng tuần"
    → chỉ cần XUẤT báo cáo hằng tuần

⚠ Xuất báo cáo cho kiểm toán:

Inspector → xuất findings ra S3 (định dạng CSV hoặc JSON)
        ↓
    Hoặc đẩy vào Security Hub để tổng hợp
        ↓
    Tự động hoá bằng EventBridge theo lịch tuần
        ↓
    → đúng yêu cầu "báo cáo hằng tuần" của đề

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

• A (AWS SSM) — đây là phương án gần nhất và là thứ đề đã nói đang dùng để vá máy. Nhưng báo cáo của Patch Manager trả lời câu hỏi "đã cài đủ bản vá được duyệt chưa", không phải "còn lỗ hổng đã biết nào không". Hai công cụ bổ sung cho nhau: SSM sửa, Inspector kiểm chứng.

• C (Amazon GuardDuty) — phát hiện HÀNH VI đáng ngờ (liên lạc với địa chỉ độc hại, đào tiền ảo, dò quét bất thường). Nó không quét lỗ hổng phần mềm.

• B (AWS Shield) — dịch vụ chống DDoS. Không liên quan tới lỗ hổng hay tuân thủ bản vá.

Ghi nhớ

⚠ Bốn dịch vụ bảo mật hay bị nhầm — bảng phải thuộc: | Dịch vụ | Trả lời câu hỏi | |---|---| | Inspector | "phần mềm có LỖ HỔNG ĐÃ BIẾT nào không" | | GuardDuty | "có HÀNH VI độc hại nào đang diễn ra không" | | AWS Config | "CẤU HÌNH có đúng chuẩn không" | | Security Hub | "tổng hợp mọi phát hiện ở một chỗ" | | Macie | "có dữ liệu nhạy cảm nào trong S3 không" | | Patch Manager | "máy đã cài đủ bản vá chưa" | | Detective | "sự cố này bắt nguồn từ đâu" |

Từ khoá nhận diện:

"báo cáo lỗ hổng, CVE, tuân thủ bảo mật" → Inspector "cài bản vá" → Patch Manager "hành vi bất thường, tài khoản bị xâm nhập" → GuardDuty "cấu hình lệch chuẩn" → AWS Config "gom mọi cảnh báo bảo mật" → Security Hub "tìm dữ liệu nhạy cảm trong S3" → Macie

⚠ Inspector v2 quét được những gì: | Đối tượng | Nội dung | |---|---| | EC2 | gói hệ điều hành, và CVE của ứng dụng | | Container image trong ECR | quét khi push, và quét lại khi có CVE mới | | Lambda | mã hàm và các phụ thuộc | | Cách bật | một công tắc ở cấp tài khoản hoặc tổ chức | | Yêu cầu với EC2 | SSM Agent — Inspector dùng nó để lấy kiểm kê phần mềm |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy nào chưa được quét | Inspector coverage — máy vắng mặt mới là vấn đề lớn | | Lỗ hổng nghiêm trọng còn bao nhiêu | lọc theo severity = CRITICAL | | Báo cáo có xuất được không | create-findings-report với đích là S3 |

Và một lời nhắc quan trọng khi đọc kết quả: máy không xuất hiện trong Inspector nguy hiểm hơn máy có nhiều lỗ hổng. Inspector phụ thuộc vào SSM Agent để biết máy đang cài những gói nào; một instance thiếu agent hay thiếu IAM role đơn giản là không nằm trong phạm vi quét, và báo cáo gửi cho kiểm toán viên sẽ hiện một bức tranh sạch sẽ cho những máy còn lại — hãy luôn đối chiếu số máy được quét với số instance đang chạy thật.

Đáp án

C — Tạo MỘT VPC với hai subnet.

Vì sao đúng

Câu này kiểm tra một điều rất cơ bản mà đề cố tình làm rối bằng các phương án phức tạp: mọi subnet trong cùng một VPC đã tự nói chuyện được với nhau rồi.

⚠ Điểm mấu chốt — VPC có một route table ngầm cho chính dải CIDR của nó:

Tạo VPC 10.0.0.0/16
        ↓
    Mọi route table trong VPC đó tự có một dòng:
        10.0.0.0/16 → local
        ↓
    → dòng này KHÔNG XOÁ ĐƯỢC, KHÔNG SỬA ĐƯỢC
    → mọi subnet trong VPC nối được với nhau
      bằng IP RIÊNG, kể cả khác Availability Zone

⚠ "Public" và "private" không phải hai thế giới tách biệt:

Public subnet  = có route 0.0.0.0/0 → Internet Gateway
Private subnet = không có route đó
        ↓
    Khác biệt DUY NHẤT là đường ra internet
        ↓
    → giữa hai subnet với nhau, chúng hoàn toàn bình đẳng
    → nói chuyện bằng IP riêng không cần thêm gì cả

⚠ Vậy nếu không thông thì lỗi ở đâu:

Trong cùng VPC, chỉ có hai thứ chặn được:
        ↓
    Security Group  → phải cho phép dải IP hoặc SG của bên kia
    Network ACL     → phải cho phép CẢ HAI CHIỀU (stateless)
        ↓
    Định tuyến thì KHÔNG BAO GIỜ là nguyên nhân
    trong cùng một VPC

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

• B (tạo hai VPC mỗi cái một subnet rồi peering) — đây là phương án gần nhất và về kỹ thuật thì chạy được, nhưng nó là cách phức tạp nhất có thể cho một việc đơn giản: thêm peering connection, thêm hai bộ route table phải sửa ở cả hai phía, thêm ràng buộc CIDR không được chồng lấn. Đề hỏi cách đơn giản nhất.

• A (dùng NAT Gateway) — NAT Gateway để private subnet ra INTERNET, không phải để hai subnet nói chuyện với nhau. Nó còn tốn tiền theo giờ và theo mỗi GB đi qua.

• D (dùng NAT instance) — cùng lỗi như A, và còn là cách cũ phải tự vận hành (nhớ tắt source/destination check, tự lo sẵn sàng cao).

Ghi nhớ

⚠ Tuyến local — điều đầu tiên phải nhớ về VPC: | Nội dung | |---| | Mỗi VPC tự có tuyến <CIDR-cua-VPC> → local trong mọi route table | | Tuyến này không xoá được, không sửa được | | Nhờ nó, mọi subnet trong VPC nối được với nhau, kể cả khác AZ | | Lưu lượng giữa các AZ có tính phí truyền dữ liệu, nhưng vẫn thông |

Từ khoá nhận diện:

"hai subnet trong cùng VPC không nói chuyện được" → SG hoặc NACL, KHÔNG BAO GIỜ là route "private subnet cần ra internet" → NAT Gateway "hai VPC cần nối" → peering hoặc Transit Gateway "public subnet" → có route 0.0.0.0/0 → IGW "gọi dịch vụ AWS không qua internet" → VPC endpoint

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hai subnet có cùng VPC không | describe-subnets, so VpcId | | Có gì đang chặn | VPC Reachability Analyzer — chỉ đích danh thành phần | | Gói bị bỏ ở đâu | VPC Flow Logs, tìm bản ghi REJECT |

Và một lời khuyên khi thiết kế: hãy dùng nhiều subnet trong một VPC, chứ đừng dùng nhiều VPC, trừ khi có lý do rõ ràng. Mỗi VPC thêm vào là thêm một bộ route table, một lớp peering hoặc Transit Gateway, và một khoản chi phí truyền dữ liệu — trong khi phần lớn nhu cầu "tách biệt" mà người ta nghĩ cần VPC riêng thì thực ra chỉ cần subnet riêng cộng với security group viết cho tử tế.

Đáp án

A — Dùng DeletionPolicy=Snapshot.

Vì sao đúng

CloudFormation có sẵn một thuộc tính làm đúng điều đề yêu cầu: chụp ảnh trước khi xoá.

⚠ Điểm mấu chốt — ba giá trị của DeletionPolicy:

Delete (mặc định) → xoá tài nguyên cùng stack
Retain            → GIỮ LẠI tài nguyên, stack buông tay
Snapshot          → CHỤP SNAPSHOT rồi mới xoá  ← đáp án

Khai rất gọn:

OCuLuuTru:
  Type: AWS::EC2::Volume
  DeletionPolicy: Snapshot
  UpdateReplacePolicy: Snapshot
  Properties:
    Size: 500
    AvailabilityZone: !Select [0, !GetAZs '']
    Encrypted: true

⚠ Đừng quên UpdateReplacePolicy — nửa còn lại của bức tranh:

DeletionPolicy    → áp dụng khi XOÁ STACK
UpdateReplacePolicy → áp dụng khi CẬP NHẬT khiến tài nguyên
                      bị THAY THẾ (Replacement: True)
        ↓
    Chỉ khai DeletionPolicy
        ↓
    → một lần update có Replacement vẫn xoá volume cũ
      mà KHÔNG chụp snapshot
        ↓
    → mất dữ liệu ngay giữa một lần triển khai bình thường

⚠ Những loại tài nguyên hỗ trợ Snapshot — phải nhớ danh sách này:

AWS::EC2::Volume
AWS::RDS::DBInstance     và  AWS::RDS::DBCluster
AWS::ElastiCache::CacheCluster  và  ReplicationGroup
AWS::Redshift::Cluster
AWS::Neptune::DBCluster
AWS::DocDB::DBCluster
        ↓
    Loại KHÔNG hỗ trợ Snapshot (ví dụ S3 bucket)
        ↓
    → dùng Retain thay thế

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

• B (bật termination protection) — đây là phương án gần nhất và cũng là một biện pháp bảo vệ thật. Nhưng nó chặn hẳn việc xoá stack chứ không tạo snapshot nào; và đề nói rõ stack sẽ bị xoá, chỉ cần giữ lại bản sao lưu.

• D (đưa EBS volume ra làm stack output) — Outputs chỉ xuất một giá trị (id, ARN) cho stack khác dùng. Nó không ảnh hưởng gì tới số phận tài nguyên khi xoá stack.

• C (dùng cfn helper script và Wait Condition khi xoá stack) — hiểu sai công dụng: các kịch bản cfn-init/cfn-signal và WaitCondition chỉ chạy lúc TẠO hoặc CẬP NHẬT, không có móc nào chạy khi xoá stack.

Ghi nhớ

⚠ Ba chính sách vòng đời của tài nguyên CloudFormation — bảng phải thuộc: | Chính sách | Khi nào áp dụng | |---|---| | DeletionPolicy | khi XOÁ stack | | UpdateReplacePolicy | khi CẬP NHẬT làm tài nguyên bị THAY THẾ | | CreationPolicy | chờ tín hiệu khi TẠO | | UpdatePolicy | cách cập nhật Auto Scaling group |

Từ khoá nhận diện:

"giữ bản sao lưu khi xoá stack" → DeletionPolicy: Snapshot "giữ nguyên tài nguyên khi xoá stack" → DeletionPolicy: Retain "chặn hẳn không cho xoá stack" → termination protection "chặn sửa một tài nguyên cụ thể" → stack policy "đưa tài nguyên có sẵn vào stack" → resource import

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Snapshot có được tạo không | describe-snapshots sau khi xoá stack thử | | Tài nguyên nào chưa được bảo vệ | rà template tìm loại có trạng thái mà thiếu DeletionPolicy | | Ai đã xoá stack | CloudTrail sự kiện DeleteStack |

Và một thói quen nên áp dụng cho mọi template: hãy khai cả DeletionPolicy lẫn UpdateReplacePolicy cho mọi tài nguyên có lưu trạng thái. Trường hợp mất dữ liệu đau đớn nhất không phải là ai đó xoá nhầm stack — chuyện đó ai cũng đề phòng — mà là một lần cập nhật trông rất vô hại làm tài nguyên bị thay thế, im lặng, giữa ban ngày, trong một pipeline đã chạy trơn tru hàng trăm lần trước đó.

Đáp án

A, D — hai cách khắc phục:

• A — Instance T2.micro đã cạn tín dụng burst. Đổi sang T2.large hoặc m4.large để ổn định hơn.
• D — Bật T2 Unlimited.

Vì sao đúng

Đề mô tả chính xác triệu chứng cạn tín dụng CPU, kèm một chi tiết rất quan trọng: "ASG không co giãn".

⚠ Điểm mấu chốt — vì sao ASG đứng im dù CPU cao:

Instance họ T bị THROTTLE khi hết tín dụng
        ↓
    CPU bị giới hạn ở mức nền (T2.micro: 10%)
        ↓
    → chỉ số CPUUtilization báo về CloudWatch
      là % của phần CPU ĐƯỢC PHÉP DÙNG
        ↓
    → không vượt ngưỡng co giãn
        ↓
    → ASG tưởng mọi thứ bình thường
    → trong khi người dùng đang chờ dài cổ

Đây là một trong những cái bẫy khó chịu nhất khi vận hành họ T: hệ thống chậm thảm hại mà mọi biểu đồ đều xanh.

⚠ Cơ chế tín dụng của instance họ T:

Mỗi giờ được cộng một lượng tín dụng CPU cố định
        ↓
    Dùng ít hơn mức nền → tích luỹ tín dụng (có trần)
    Dùng nhiều hơn      → tiêu tín dụng
        ↓
    HẾT tín dụng → bị ép về mức NỀN
        ↓
    T2.micro: mức nền chỉ 10% của một vCPU

⚠ Hai cách chữa, hai triết lý khác nhau:

T2 Unlimited hợp khi tải thỉnh thoảng mới cao; đổi sang họ M hợp khi tải thường xuyên cao — vì lúc đó phí vượt của Unlimited sẽ đắt hơn cả một instance họ M.

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

• C (load balancer cần được pre-warm) — đây là phương án gần nhất vì pre-warm là việc có thật khi lưu lượng tăng đột ngột. Nhưng đề nói rõ vấn đề nằm ở CPU của instance bị throttle, không phải ở khả năng chịu tải của ELB.

• B (đổi ALB sang NLB) — NLB nhanh hơn ở tầng 4 nhưng không giải quyết gì cho việc CPU bị giới hạn. Đổi sang NLB còn mất các tính năng tầng 7 (định tuyến theo đường dẫn, WAF).

• E (tắt stickiness của ELB) — stickiness ảnh hưởng tới cách phân bố phiên làm việc, có thể gây lệch tải nhẹ. Nhưng nó không phải nguyên nhân khi mọi instance đều đang bị throttle.

Ghi nhớ

⚠ Instance họ T — bảng phải thuộc: | Nội dung | Chi tiết | |---|---| | Cơ chế | tích và tiêu tín dụng CPU | | Hết tín dụng | bị ép về mức nền (T2.micro: 10%) | | T2 Unlimited | vượt mức nền được, trả thêm phí cho phần vượt | | T3/T4g | mặc định là Unlimited (T2 mặc định là Standard) | | Chỉ số theo dõi | CPUCreditBalance, CPUSurplusCreditBalance |

Từ khoá nhận diện:

"CPU bị throttle, hiệu năng tệ" → cạn tín dụng của họ T "ASG không co giãn dù máy chậm" → CPUUtilization bị che bởi throttle "tải cao thường xuyên" → đổi sang họ M/C, đừng dùng họ T "tải thỉnh thoảng mới cao" → T3 hoặc T2 Unlimited "cần hiệu năng ổn định, dự đoán được" → họ M (cân bằng), C (thiên CPU), R (thiên bộ nhớ)

⚠ Các họ instance chính — bảng đáng thuộc: | Họ | Thiên về | |---|---| | T | burstable — rẻ, cho tải thấp và không đều | | M | cân bằng — CPU, bộ nhớ, mạng | | C | CPU — tính toán nặng | | R | bộ nhớ — cơ sở dữ liệu, cache | | I / D | lưu trữ — I/O cao, dung lượng local lớn | | P / G / Inf | GPU / tăng tốc ML |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có đang bị throttle không | biểu đồ CPUCreditBalance — chạm 0 là đang bị | | Unlimited đang tốn thêm bao nhiêu | CPUSurplusCreditsCharged | | Đổi họ instance có rẻ hơn không | so giá T2-Unlimited-có-phí-vượt với m5 tương đương |

Và một lời khuyên rút thẳng từ tình huống của đề: hãy đặt cảnh báo trên CPUCreditBalance, không chỉ trên CPUUtilization. Đây là sự cố tự che giấu hoàn hảo — máy chậm tới mức người dùng phàn nàn, nhưng CPU hiển thị khoảng 10% và mọi cảnh báo đều im lặng, nên đội vận hành đi tìm nguyên nhân ở cơ sở dữ liệu, ở mạng, ở mã nguồn — mọi nơi trừ đúng chỗ nó đang nằm.

Đáp án

A — Sinh pre-signed URL cho các báo cáo.

Vì sao đúng

Đề đã dựng sẵn một nửa kiến trúc (Cognito + API Gateway + Lambda) và hỏi mảnh ghép còn lại phía S3. Pre-signed URL khớp hoàn hảo.

⚠ Điểm mấu chốt — pre-signed URL là quyền truy cập tạm thời, nhúng ngay trong đường link:

Khách hàng đăng nhập → Cognito xác thực
        ↓
    Gọi API Gateway → Lambda
        ↓
    Lambda kiểm tra: khách này được xem báo cáo nào
        ↓
    Sinh pre-signed URL cho đúng tệp đó
        ↓
    Trả link về cho khách
        ↓
    → khách tải thẳng từ S3, KHÔNG cần chứng chỉ AWS nào
    → link tự hết hạn sau thời gian đã định

url = s3.generate_presigned_url(
    'get_object',
    Params={'Bucket': 'bao-cao', 'Key': f'{ma_khach}/2026-09-02.pdf'},
    ExpiresIn=900)          # 15 phút

⚠ Vì sao cách này mở rộng được tới hơn 10.000 khách hàng:

Bucket vẫn RIÊNG TƯ hoàn toàn
        ↓
    Không tạo IAM user nào (IAM chỉ cho 5.000 user)
    Không sửa bucket policy khi danh sách khách đổi
        ↓
    Logic phân quyền nằm trong Lambda — nơi dễ đổi nhất
        ↓
    → danh sách khách thay đổi liên tục cũng không sao

⚠ Và một điểm rất quan trọng về hiệu năng và chi phí:

Tệp KHÔNG đi qua Lambda hay API Gateway
        ↓
    Khách tải THẲNG từ S3
        ↓
    → không chạm giới hạn 6 MB payload của Lambda
    → không trả tiền cho thời gian Lambda chạy khi truyền tệp lớn
    → không chạm giới hạn 10 MB của API Gateway

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

• D (bucket policy chỉ cho CloudFront truy cập, dùng SSL mutual authentication) — đây là phương án gần nhất vì đặt CloudFront trước S3 là mẫu quen thuộc. Nhưng mutual TLS đòi mỗi khách hàng có một chứng chỉ client — cấp và xoay chứng chỉ cho hơn 10.000 khách hàng luôn thay đổi là gánh nặng vận hành khổng lồ, và nó không dùng được danh tính Cognito mà đề đã có. (Nếu muốn dùng CloudFront thì câu trả lời đúng là CloudFront signed URL, không phải mutual TLS.)

• C (cấp cho mỗi khách một IAM user và bảo họ dùng CLI) — không mở rộng được: IAM có hạn mức mặc định 5.000 user mỗi tài khoản. Và IAM dành cho danh tính nội bộ, không dành cho khách hàng của bạn.

• B (mở bucket công khai rồi đặt mật khẩu cho từng tệp) — S3 không có tính năng đặt mật khẩu cho tệp. Mở bucket công khai nghĩa là ai đoán được tên tệp cũng tải được — đây là cách rò rỉ dữ liệu, không phải cách bảo vệ.

Ghi nhớ

⚠ Ba cách cho người dùng bên ngoài truy cập S3 — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Pre-signed URL | tạm thời, cho một đối tượng, không cần chứng chỉ AWS | | CloudFront signed URL / cookie | qua CDN — thêm cache, thêm chống DDoS, giới hạn theo IP | | Cognito Identity Pool | cấp chứng chỉ AWS tạm cho ứng dụng gọi S3 trực tiếp |

Từ khoá nhận diện:

"cho khách tải một tệp, có hạn giờ" → pre-signed URL "cho khách tải nhiều tệp trong một phiên" → CloudFront signed cookie "ứng dụng di động ghi thẳng lên S3" → Cognito Identity Pool "tạo IAM user cho mỗi khách hàng" → LUÔN SAI, không mở rộng được "đặt mật khẩu cho tệp S3" → KHÔNG TỒN TẠI

⚠ Bẫy lớn nhất — thời hạn bị cắt ngắn mà không báo:

Lambda chạy bằng IAM role → chứng chỉ tạm sống ~1 giờ
        ↓
    Ký một URL với ExpiresIn = 7 ngày
        ↓
    → URL vẫn được tạo ra, KHÔNG có lỗi nào
    → nhưng nó CHẾT khi chứng chỉ của Lambda hết hạn
        ↓
    Cần link sống lâu → phải ký bằng chứng chỉ dài hạn,
    hoặc dùng CloudFront signed URL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | URL có hoạt động không | curl -I <url> — phải trả 200 | | Hết hạn khi nào | đọc tham số X-Amz-Expires trong URL | | Ai đã tải gì | CloudTrail data event hoặc S3 access log |

Và một lời khuyên về bảo mật khi vận hành: hãy đặt thời hạn ngắn — vài phút là đủ cho một lượt tải — và ghi log mọi lần Lambda sinh URL. Pre-signed URL không thu hồi được, nên một link bị chuyển tiếp nhầm sang người khác vẫn hoạt động cho tới khi hết hạn; thời hạn 15 phút biến rủi ro đó thành gần như vô hại, còn thời hạn 7 ngày biến nó thành một lỗ rò dữ liệu kéo dài cả tuần mà không ai biết.