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

Đáp án

D — Tạo CloudWatch alarm với hành động KHỞI ĐỘNG LẠI instance, và dùng DETAILED MONITORING.

Vì sao đúng

Đề đòi phản ứng khi vấn đề kéo dài HƠN 2 PHÚT, và đó chính là chi tiết quyết định chọn detailed monitoring.

⚠ Điểm mấu chốt — basic monitoring KHÔNG đo được ngưỡng 2 phút:

BASIC MONITORING (mặc định, miễn phí)
        ↓
    Chỉ số CPU thu thập mỗi 5 PHÚT
        ↓
    Chu kỳ tối thiểu của alarm cũng là 5 phút
        ↓
    → KHÔNG thể phát hiện tình trạng
      kéo dài "hơn 2 phút"
        ↓
DETAILED MONITORING (có phí)
        ↓
    Chỉ số thu thập mỗi 1 PHÚT
        ↓
    → alarm đặt Period = 60 giây,
      EvaluationPeriods = 2
    → phát hiện đúng ngưỡng 2 phút

⚠ Cấu hình alarm cho đúng yêu cầu:

Metric:            CPUUtilization
Threshold:         > 95%  (hoặc ngưỡng phù hợp)
Period:            60 giây      ← cần detailed monitoring
EvaluationPeriods: 2            → 2 phút
DatapointsToAlarm: 2
Action:            EC2 → Reboot this instance
        ↓
    → hoàn toàn không cần mã
    → CloudWatch có sẵn hành động reboot

⚠ Bốn hành động EC2 của alarm — nhớ phân biệt:

Reboot   → khởi động lại, CÙNG máy chủ vật lý  ← đề này
Stop     → dừng máy (tiết kiệm chi phí)
Terminate→ huỷ hẳn
Recover  → chuyển sang PHẦN CỨNG MỚI
           (dùng cho StatusCheckFailed_System)

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

• A (alarm với hành động reboot, dùng BASIC monitoring) — đây là phương án gần nhất và chỉ sai đúng một chi tiết: basic monitoring cho chỉ số mỗi 5 phút, nên không thể đánh giá một tình trạng kéo dài 2 phút. Đây chính là điểm phân biệt giữa A và D.

• C (EventBridge chạy Lambda theo LỊCH để khởi động lại máy) — chạy theo lịch cố định, không phản ứng theo tình trạng thật: sẽ khởi động lại cả khi máy đang khoẻ, và bỏ sót khi sự cố xảy ra giữa hai lần chạy.

• B (tạo một "CloudTrail API action" khởi động lại máy khi tài nguyên bị dùng hết) — CloudTrail chỉ GHI LẠI lời gọi API, không thực hiện hành động nào và cũng không theo dõi mức sử dụng.

Ghi nhớ

⚠ Basic ↔ Detailed monitoring — bảng phải thuộc: | | Basic | Detailed | |---|---|---| | Tần suất | 5 phút | 1 phút | | Chi phí | miễn phí | có phí mỗi instance | | Chỉ số | CÙNG một bộ chỉ số | cùng bộ, chỉ dày hơn | | Bật ở đâu | mặc định | lúc khởi chạy, hoặc monitor-instances | | Cần khi | | alarm phản ứng dưới 5 phút, Auto Scaling nhạy hơn | | KHÔNG thêm chỉ số mới | | bộ nhớ và đĩa vẫn cần AGENT |

Từ khoá nhận diện:

"phản ứng trong vòng 1-4 phút" → detailed monitoring "tự khởi động lại khi treo" → alarm + EC2 action Reboot "phần cứng lỗi" → StatusCheckFailed_System + Recover "máy nhàn rỗi, tiết kiệm chi phí" → alarm + Stop "bộ nhớ, dung lượng đĩa" → CloudWatch agent — detailed monitoring không giúp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Detailed monitoring đã bật chưa | describe-instances --query '...Monitoring.State' | | Alarm có kích hoạt không | describe-alarm-history | | Máy có bị reboot lặp lại không | CloudTrail, đếm số RebootInstances |

Và một cảnh báo nên đặt kèm ngay từ đầu: SNS báo mỗi lần alarm kích hoạt reboot. Tự động khởi động lại giữ cho dịch vụ tiếp tục chạy, nhưng nếu nó diễn ra mười lần một ngày mà không ai biết thì bạn đã che mất một lỗi nghiêm trọng trong ứng dụng — và triệu chứng duy nhất còn lại sẽ là những khoảng gián đoạn ngắn mà không ai giải thích được.

Đáp án

C — Tạo AMI từ instance hiện có, khởi chạy nó ở Availability Zone MỚI, rồi huỷ instance cũ.

Vì sao đúng

Có một sự thật nền tảng quyết định câu này: instance EC2 KHÔNG DI CHUYỂN được giữa các Availability Zone.

⚠ Điểm mấu chốt — AZ được cố định lúc khởi chạy:

Instance được khởi chạy vào một SUBNET
        ↓
    Subnet thuộc đúng MỘT Availability Zone
        ↓
    → AZ của instance là CỐ ĐỊNH
    → không có thao tác "đổi AZ"
    → không có nút nào, không có lệnh CLI nào
        ↓
    Cách duy nhất: TẠO MÁY MỚI ở AZ khác

⚠ Quy trình đầy đủ:

1. Tạo AMI từ instance hiện có
     create-image --instance-id i-xxx
        ↓
    (AMI chụp cả cấu hình và dữ liệu trên EBS)
        ↓
2. Khởi chạy instance mới từ AMI đó,
   chọn SUBNET thuộc AZ MỚI
        ↓
3. Kiểm chứng ứng dụng chạy đúng
        ↓
4. Chuyển lưu lượng sang (ALB, DNS)
        ↓
5. Huỷ instance cũ

⚠ Những gì cần chú ý khi chuyển:

IP RIÊNG          → ĐỔI (thuộc dải CIDR của subnet mới)
IP công cộng      → đổi (trừ khi dùng Elastic IP)
Instance ID       → MỚI
EBS volume        → tạo mới từ AMI
Instance store    → MẤT dữ liệu
Security group    → chọn lại (nếu khác VPC)
        ↓
    → gắn ELASTIC IP trước để giữ địa chỉ công cộng
    → cập nhật mọi nơi tham chiếu IP riêng

⚠ Và với volume dữ liệu riêng thì có cách khác:

Nếu dữ liệu nằm trên một EBS volume riêng
        ↓
    Snapshot volume đó
    → tạo volume mới TỪ SNAPSHOT ở AZ MỚI
    → gắn vào instance mới
        ↓
    (EBS volume cũng KHÔNG di chuyển
     giữa AZ được — phải qua snapshot)

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

• B (tắt máy, đổi Availability Zone, rồi bật lại) — đây là phương án gần nhất về trực giác, nhưng không có thuộc tính "Availability Zone" nào để sửa trên một instance đã dừng. AZ được quyết định bởi subnet lúc khởi chạy.

• A (dùng console để chuyển instance sang AZ khác) — không có chức năng này trong console.

• D (dùng AWS CLI để chuyển trực tiếp instance sang AZ khác) — không có lệnh CLI nào làm việc này.

Ghi nhớ

⚠ Những gì KHÔNG di chuyển được — bảng phải thuộc: | Tài nguyên | Chuyển AZ / Region | |---|---| | EC2 instance | KHÔNG — phải tạo AMI rồi khởi chạy lại | | EBS volume | KHÔNG — phải snapshot rồi tạo volume mới | | Subnet | KHÔNG — thuộc cố định một AZ | | RDS instance | đổi AZ được qua Multi-AZ failover; sang Region thì dùng snapshot/replica | | Elastic IP | gắn lại được trong cùng Region | | AMI, snapshot | copy sang Region khác được |

Từ khoá nhận diện:

"chuyển EC2 sang AZ khác" → AMI → khởi chạy mới → huỷ cũ "chuyển EC2 sang Region khác" → copy AMI sang Region đó rồi khởi chạy "chuyển EBS sang AZ khác" → snapshot → tạo volume mới "tránh phải làm thủ công" → Auto Scaling group trải nhiều AZ "giữ IP công cộng" → Elastic IP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy mới ở AZ nào | describe-instances --query '...Placement.AvailabilityZone' | | AMI đã sẵn sàng chưa | describe-images --query '...State' | | Ứng dụng có chạy đúng không | health check của ALB, và log ứng dụng |

Và một điều nên dọn dẹp sau khi hoàn tất: deregister AMI tạm VÀ xoá các snapshot phía sau nó. Rất nhiều tài khoản tích tụ hàng trăm snapshot mồ côi từ những lần di chuyển máy như thế này — chúng không hiện ra ở đâu dễ thấy, nhưng vẫn được tính tiền đều đặn hàng tháng cho tới khi có người ngồi rà lại hoá đơn.

Đáp án

A — Tạo web ACL với hành động mặc định ALLOW, tạo RATE-BASED RULE để CHẶN lưu lượng khớp, rồi gắn web ACL vào ALB.

Vì sao đúng

Đây là mô hình đúng của WAF cho một website công khai: mặc định cho qua, chỉ chặn cái bất thường.

⚠ Điểm mấu chốt — chiều của default action và của rule:

Website CÔNG KHAI
        ↓
    Phần lớn lưu lượng là NGƯỜI DÙNG THẬT
        ↓
    Default action = ALLOW
        ↓
    Rule = BLOCK cho lưu lượng bất thường
        ↓
    → mô hình DANH SÁCH CHẶN (blacklist)
        ↓
Nếu làm ngược lại (default BLOCK):
        ↓
    → phải liệt kê MỌI người dùng hợp lệ
    → bất khả thi với một website công khai
    → chặn sạch khách truy cập

⚠ Rate-based rule hoạt động thế nào:

Đếm số request theo ĐỊA CHỈ IP nguồn
    trong một CỬA SỔ TRƯỢT
        ↓
    Cửa sổ: 1, 2, 5 hoặc 10 phút
    Ngưỡng: số request tối thiểu là 100
        ↓
    IP vượt ngưỡng → BỊ CHẶN
        ↓
    Tự động BỎ CHẶN khi tốc độ giảm xuống
        ↓
    → không cần ai can thiệp
    → đúng nghĩa "rate limiting"

⚠ Chọn ngưỡng cho đúng:

Quá thấp
        ↓
    → chặn nhầm người dùng thật
    → nhất là khi nhiều người
      chung một IP (văn phòng, NAT của nhà mạng)

Quá cao
        ↓
    → không chặn được gì
        ↓
Cách làm đúng:
        ↓
    1. Bật rule ở chế độ COUNT trước
    2. Xem log WAF, tìm phân bố request theo IP
    3. Đặt ngưỡng trên mức người dùng bình thường
    4. Rồi mới chuyển sang BLOCK

Xem thêm câu #11816 (lô 127): cùng chủ đề WAF rate-based rule để chống lạm dụng. Khoá nhất quán.

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

• C (web ACL với default action BLOCK, rate-based rule để ALLOW) — đây là phương án gần nhất và dùng đúng loại rule, nhưng đảo ngược hoàn toàn logic: mặc định chặn hết thì website không phục vụ được ai, và một rate-based rule kiểu "allow" không có ý nghĩa — nó vốn để phát hiện tốc độ VƯỢT ngưỡng.

• B (default allow, REGULAR rule với điều kiện khớp IP để chặn) — IP match condition chặn một danh sách IP CỐ ĐỊNH, không phải giới hạn theo tốc độ. Với DDoS thì địa chỉ nguồn thay đổi liên tục, nên cách này không theo kịp.

• D (default block, regular rule với IP match để allow) — cùng vấn đề đảo ngược logic như C, cộng thêm việc phải duy trì một danh sách IP hợp lệ bằng tay.

Ghi nhớ

⚠ Các loại rule của AWS WAF — bảng phải thuộc: | Loại rule | Việc | |---|---| | Rate-based | giới hạn số request mỗi IP trong cửa sổ trượt | | IP set match | chặn hoặc cho phép một danh sách IP/CIDR | | Geo match | theo quốc gia | | String / regex match | tìm mẫu trong URI, header, body | | SQLi / XSS match | phát hiện tấn công tiêm mã | | Size constraint | giới hạn kích thước request | | Managed rule group | bộ luật do AWS hoặc bên thứ ba duy trì |

Từ khoá nhận diện:

"giới hạn tốc độ, chống lạm dụng" → rate-based rule, default ALLOW "chặn danh sách IP cụ thể" → IP set match "chặn theo quốc gia" → geo match, hoặc CloudFront geo restriction "chống SQL injection, XSS" → managed rule group của AWS "DDoS quy mô lớn ở tầng 3/4" → Shield Advanced

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có chặn nhầm không | WAF log, xem action và terminatingRuleId | | Bao nhiêu request bị chặn | chỉ số BlockedRequests | | Ngưỡng có hợp lý không | phân bố request theo IP trong ALB access log |

Và một chi tiết rất quan trọng nếu ALB nằm sau CloudFront: dùng FORWARDED_IP thay vì IP làm khoá gộp. Nếu không, WAF ở ALB sẽ nhìn thấy toàn bộ lưu lượng đến từ một nhúm IP của CloudFront — và rate-based rule hoặc là không bao giờ kích hoạt, hoặc là chặn nhầm toàn bộ người dùng cùng lúc.

Đáp án

C — Cấu hình NAT GATEWAY ở public subnet của MỖI AZ, và thêm tuyến tới NAT trong route table của từng private subnet.

Vì sao đúng

Đề cần một danh sách IP TĨNH cho bên thứ ba đưa vào danh sách cho phép, trong khi máy được Auto Scaling khởi chạy và huỷ liên tục.

⚠ Điểm mấu chốt — NAT gom mọi IP nguồn về Elastic IP của nó:

Hàng trăm instance ở private subnet
    IP riêng đổi liên tục theo Auto Scaling
        ↓
    Tất cả đi ra qua NAT Gateway
        ↓
    NAT thay IP nguồn bằng ELASTIC IP của nó
        ↓
    Bên thứ ba chỉ thấy 3 địa chỉ
      (một cho mỗi AZ)
        ↓
    → khai MỘT LẦN vào danh sách cho phép
    → thêm hay bớt máy KHÔNG cần báo lại

⚠ Vì sao phải MỖI AZ MỘT NAT:

Một NAT dùng chung cho cả ba AZ
        ↓
    → lưu lượng của hai AZ kia phải đi QUA AZ
    → PHÍ DỮ LIỆU QUA AZ, tính cả hai chiều
    → và NAT đó là ĐIỂM HỎNG ĐƠN LẺ:
      mất AZ của nó là cả ba AZ mất internet
        ↓
Mỗi AZ một NAT
        ↓
    → không phí qua AZ
    → AZ hỏng chỉ ảnh hưởng chính AZ đó
        ↓
    Đổi lại: BA Elastic IP thay vì một
    → khai cả ba vào danh sách cho phép
    → gần như bên nào cũng chấp nhận

⚠ Route table phải tách riêng theo AZ:

Private subnet AZ-a  →  route table A  →  NAT ở AZ-a
Private subnet AZ-b  →  route table B  →  NAT ở AZ-b
Private subnet AZ-c  →  route table C  →  NAT ở AZ-c
        ↓
    Dùng CHUNG một route table cho cả ba
        ↓
    → mọi lưu lượng dồn về một NAT
    → mất hết lợi ích vừa nói

Xem thêm câu #11834 (lô 128): gần như cùng một câu hỏi — dùng NAT Gateway để có IP nguồn cố định cho danh sách cho phép của bên thứ ba. Chỉ khác chữ cái (ở đó là D, ở đây là C) và ở đây đề nhấn thêm vào việc mỗi AZ một NAT. Khoá nhất quán.

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

• A (gắn Elastic IP cho từng instance, cấu hình VPC endpoint cho lưu lượng ra) — đây là phương án gần nhất về ý tưởng "IP tĩnh", nhưng hàng trăm máy co giãn liên tục thì nghĩa là hàng trăm Elastic IP thay đổi không ngừng — bất khả thi để whitelist, và chạm hạn mức 5 EIP mỗi Region ngay lập tức. (VPC endpoint cũng chỉ dùng cho dịch vụ AWS, không phải API bên thứ ba trên internet.)

• B (gắn Elastic IP vào internet gateway) — IGW KHÔNG NHẬN Elastic IP. Nó là thành phần định tuyến ảo, không có địa chỉ.

• D (gắn Elastic IP cho từng AZ rồi liên kết với các instance trong AZ đó) — không có khái niệm "Elastic IP của một AZ". EIP gắn vào instance, ENI, NAT Gateway hoặc NLB — và một EIP chỉ gắn được vào MỘT tài nguyên tại một thời điểm.

Ghi nhớ

⚠ Bốn thành phần ra internet — bảng phải thuộc: | Thành phần | IP nguồn bên ngoài thấy | NAT nhiều-thành-một | |---|---|---| | Internet Gateway | IP công cộng của TỪNG máy | không | | NAT Gateway | Elastic IP của NAT — MỘT địa chỉ | có | | NAT Instance | EIP của instance đó | có, tự quản lý | | Egress-only IGW | chỉ IPv6 | không |

Từ khoá nhận diện:

"bên kia chỉ cho phép danh sách IP" → NAT Gateway + Elastic IP "máy private cần ra internet" → NAT Gateway "gọi dịch vụ AWS không qua internet" → VPC endpoint "phí NAT tăng" → gateway endpoint cho S3 và DynamoDB "IP phải thuộc dải của công ty" → BYOIP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | IP bên ngoài nhìn thấy | từ instance: curl https://checkip.amazonaws.com | | NAT đang dùng EIP nào | describe-nat-gateways | | Có đi đúng NAT cùng AZ không | VPC Flow Logs, và đọc route table của từng subnet |

Và một đánh đổi nên nói rõ với bên thứ ba trước khi chốt thiết kế: yêu cầu "chỉ một IP duy nhất" và yêu cầu "chịu được mất một AZ" kéo về hai hướng ngược nhau. Cách dung hoà thường dùng là giữ một NAT mỗi AZ và thuyết phục họ nhận danh sách ba IP — gần như bên nào cũng chấp nhận, và nó rẻ hơn nhiều so với việc đánh đổi khả năng chịu lỗi của cả hệ thống.

Đáp án

D — Cập nhật TRAIL và bật LOG FILE VALIDATION.

Vì sao đúng

CloudTrail có sẵn một tính năng làm đúng việc này, và nó là thuộc tính của TRAIL, không phải của bucket.

⚠ Điểm mấu chốt — log file validation dùng chữ ký số:

Bật log file validation trên trail
        ↓
    CloudTrail tính HÀM BĂM (SHA-256) cho mỗi tệp log
        ↓
    Mỗi giờ, ghi ra một DIGEST FILE
      chứa băm của mọi tệp log trong giờ đó
        ↓
    Digest file được KÝ SỐ bằng khoá riêng
    (thuật toán RSA) của CloudTrail
        ↓
    → sửa một tệp log  → băm không khớp
    → xoá một tệp log  → thiếu trong digest
    → sửa digest file  → chữ ký không hợp lệ
        ↓
    → phát hiện được CẢ BA trường hợp
      mà đề nêu: sửa, xoá, hay còn nguyên

⚠ Kiểm chứng bằng một lệnh:

aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:...:trail/ten \
  --start-time 2026-09-01T00:00:00Z
        ↓
    → báo cáo tệp nào hợp lệ,
      tệp nào bị sửa, tệp nào bị xoá
        ↓
    Digest file nằm ở
      s3://bucket/AWSLogs/<acct>/CloudTrail-Digest/

⚠ Và nó MIỄN PHÍ, chỉ cần bật một công tắc:

Không phải viết mã
Không phải trả thêm tiền (ngoài phí lưu digest file)
        ↓
    → đúng nghĩa "hiệu quả nhất"

Xem thêm câu #11942 (cùng lô): cùng chủ đề bảo vệ CloudTrail — ở đó là bảo đảm trail luôn được bật bằng Config rule kèm khắc phục tự động. Khoá nhất quán.

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

• B (cập nhật S3 BUCKET và bật log file validation) — đây là phương án gần nhất và chỉ sai đúng một chỗ: log file validation là thuộc tính của TRAIL trong CloudTrail, không phải một cài đặt của bucket. Bucket không có tuỳ chọn nào tên như vậy.

• A (viết Lambda tính băm MD5 của các tệp log) — tự làm lại tính năng đã có sẵn và miễn phí, kèm mã phải bảo trì. (Và bản thân bảng băm do Lambda lưu cũng cần được bảo vệ — bài toán chỉ bị đẩy lùi một bước.)

• C (bật mã hoá mặc định trên bucket) — mã hoá bảo vệ TÍNH BÍ MẬT, không bảo vệ TÍNH TOÀN VẸN: kẻ có quyền ghi vẫn xoá hoặc thay thế được tệp đã mã hoá.

Ghi nhớ

⚠ Bảo vệ log CloudTrail nhiều lớp — bảng phải thuộc: | Lớp | Bảo vệ gì | |---|---| | Log file validation | TOÀN VẸN — phát hiện sửa và xoá | | Mã hoá SSE-KMS | BÍ MẬT | | Bucket ở TÀI KHOẢN KHÁC | kẻ chiếm một tài khoản không xoá được | | S3 Object Lock | BẤT BIẾN — không xoá được kể cả khi có quyền | | Versioning + MFA Delete | chống xoá nhầm | | Organization trail | thành viên KHÔNG tắt được | | SCP | chặn cloudtrail:StopLogging, DeleteTrail |

Từ khoá nhận diện:

"phát hiện log bị sửa hay xoá" → log file validation "log không được ai xoá" → Object Lock + bucket ở tài khoản khác "không ai được tắt CloudTrail" → organization trail + SCP "log phải bí mật" → SSE-KMS với CMK riêng "tự bật lại nếu bị tắt" → Config rule + AWS-ConfigureCloudTrailLogging

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Validation đã bật chưa | get-trail-status, hoặc describe-trails → LogFileValidationEnabled | | Log có bị đụng vào không | aws cloudtrail validate-logs | | Ai đã sửa cấu hình trail | CloudTrail — tìm UpdateTrail, StopLogging |

Và một điều đáng lưu ý về giới hạn của tính năng này: log file validation PHÁT HIỆN việc log bị sửa, chứ không NGĂN nó xảy ra. Muốn thật sự không ai đụng được vào log, bạn cần bucket nằm ở một tài khoản riêng với S3 Object Lock ở chế độ Compliance — khi đó ngay cả người chiếm được tài khoản production cũng không xoá được dấu vết của chính họ.

Đáp án

A — AWS WAF.

Vì sao đúng

XSS là một tấn công ở tầng ứng dụng (tầng 7), và WAF là dịch vụ duy nhất của AWS lọc được nội dung request HTTP.

⚠ Điểm mấu chốt — WAF chặn XSS ngay trước khi request tới ứng dụng:

Ứng dụng có lỗ hổng XSS, chưa vá được
        ↓
    WAF đặt trước ALB / CloudFront / API Gateway
        ↓
    Kiểm tra NỘI DUNG request:
      query string, body, header, URI, cookie
        ↓
    Phát hiện mẫu script độc hại
        ↓
    → CHẶN trước khi tới ứng dụng
        ↓
    → đây gọi là VÁ ẢO (virtual patching)
    → mua thời gian trong lúc chờ bản vá thật

⚠ Dùng managed rule group có sẵn — nhanh nhất:

AWSManagedRulesCommonRuleSet
        ↓
    Đã bao gồm luật chống XSS
    (XSS_QUERYARGUMENTS, XSS_BODY, XSS_COOKIE…)
        ↓
    AWS duy trì và cập nhật liên tục
        ↓
    → bật trong vài phút
    → không phải tự viết biểu thức khớp mẫu
        ↓
Hoặc tự viết rule:
    Statement: XssMatchStatement
    Field to match: query string / body / header
    Text transformation: URL_DECODE,
      HTML_ENTITY_DECODE, LOWERCASE

⚠ Nhớ dùng TEXT TRANSFORMATION:

Kẻ tấn công mã hoá payload để né luật
        ↓
    %3Cscript%3E   (URL encode)
    <script> (HTML entity)
        ↓
    Text transformation GIẢI MÃ trước khi khớp
        ↓
    → URL_DECODE, HTML_ENTITY_DECODE,
      LOWERCASE, COMPRESS_WHITE_SPACE
    → xếp chồng nhiều phép biến đổi

Xem thêm câu #11966 (cùng lô): cùng dịch vụ WAF, ở đó dùng rate-based rule để giới hạn tốc độ. Khoá nhất quán.

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

• C (AWS Shield Standard) — đây là phương án gần nhất vì cũng là dịch vụ bảo vệ, nhưng Shield chống DDoS ở tầng 3/4 (làm cạn băng thông hoặc tài nguyên mạng), không đọc nội dung HTTP nên không phát hiện được XSS.

• B (AWS Secrets Manager) — lưu và xoay bí mật, hoàn toàn không liên quan tới lọc lưu lượng web.

• D (AWS KMS) — quản lý khoá mã hoá, cũng không liên quan.

Ghi nhớ

⚠ Bốn dịch vụ bảo vệ — bảng phải thuộc: | Dịch vụ | Bảo vệ gì | Tầng | |---|---|---| | WAF | XSS, SQLi, bot, rate limit — lọc NỘI DUNG | 7 | | Shield Standard | DDoS phổ biến — miễn phí, tự động | 3/4 | | Shield Advanced | DDoS nâng cao, đội DRT, bồi hoàn chi phí | 3/4 và 7 | | Network Firewall | lọc lưu lượng VPC, IPS | 3-7 | | GuardDuty | phát hiện hành vi đe doạ | — | | Inspector | quét lỗ hổng phần mềm | — |

Từ khoá nhận diện:

"XSS, SQL injection" → WAF "DDoS lớn" → Shield Advanced "chặn bot" → WAF Bot Control "giới hạn tốc độ" → WAF rate-based rule "quét lỗ hổng trên máy" → Inspector

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật có bắt được không | gửi thử một payload XSS đã biết — phải nhận 403 | | Có chặn nhầm không | WAF log, xem terminatingRuleId | | Bao nhiêu request bị chặn | chỉ số BlockedRequests |

Và một điều nên nói rõ với đội phát triển khi bật WAF cho tình huống này: đây là biện pháp mua thời gian, không phải bản vá. WAF chặn được những mẫu khai thác đã biết, nhưng lỗ hổng vẫn nằm trong mã — và mỗi ngày trôi qua là một ngày ai đó có thể tìm ra một cách mã hoá payload mà bộ luật hiện tại chưa nghĩ tới.

Đáp án

A — Cấu hình lại alarm để dùng VolumeReadBytes và VolumeWriteBytes CỦA CÁC EBS VOLUME.

Vì sao đúng

Alarm không bao giờ kích hoạt vì nó đang theo dõi chỉ số đo một thứ hoàn toàn khác.

⚠ Điểm mấu chốt — hai họ chỉ số đĩa:

DiskReadBytes / DiskWriteBytes
        ↓
    → ĐO INSTANCE STORE (ổ cục bộ, ephemeral)
    → namespace AWS/EC2
        ↓
    Máy không có instance store
      → chỉ số LUÔN BẰNG 0
      → alarm không bao giờ vượt ngưỡng
        ↓
    Đúng hiện tượng trong đề

VolumeReadBytes / VolumeWriteBytes
        ↓
    → ĐO EBS VOLUME
    → namespace AWS/EBS
    → dimension là VolumeId

⚠ Và alarm phải gắn vào ĐÚNG dimension:

Chỉ số EBS có dimension: VolumeId
        ↓
    → tạo alarm cho TỪNG volume
    → không gắn theo InstanceId
        ↓
    Đây là lý do phương án C sai:
      nó nói dùng VolumeReadBytes
      nhưng "cho các EC2 instance"
        ↓
    → sai namespace và sai dimension

⚠ Nhưng để chẩn đoán ĐỘ TRỄ thì có chỉ số tốt hơn:

VolumeReadBytes chỉ đo KHỐI LƯỢNG
        ↓
    Muốn biết độ trễ và tình trạng nghẽn:
        ↓
    VolumeQueueLength     → I/O đang XẾP HÀNG
    VolumeTotalReadTime   → tổng thời gian đọc
    VolumeTotalWriteTime  → tổng thời gian ghi
    EBSIOBalance%         → credit IOPS còn lại
    EBSByteBalance%       → credit thông lượng
        ↓
    → VolumeQueueLength cao kéo dài
      là dấu hiệu rõ nhất của nghẽn I/O

Xem thêm câu #11949 (CÙNG LÔ): cùng nguyên tắc — DiskReadBytes đo instance store, không đo EBS. Ở đó câu hỏi là "vì sao chỉ số bằng 0", ở đây là "vì sao alarm không kích hoạt". Khoá nhất quán.

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

• C (dùng VolumeReadBytes và VolumeWriteBytes CỦA CÁC EC2 INSTANCE) — đây là phương án gần nhất và tên chỉ số hoàn toàn đúng, nhưng chúng thuộc namespace AWS/EBS với dimension VolumeId, không phải của EC2 instance. Đây chính là điểm phân biệt giữa A và C.

• D (cài CloudWatch agent để thu chỉ số mong muốn) — chỉ số EBS đã có sẵn, không cần agent. Agent chỉ cần cho bộ nhớ và dung lượng đĩa đã dùng.

• B (cài SSM Agent để thu chỉ số) — SSM Agent dùng để QUẢN LÝ máy (chạy lệnh, vá lỗi, Session Manager), không thu thập chỉ số cho CloudWatch.

Ghi nhớ

⚠ Chỉ số đĩa — đo cái gì, bảng phải thuộc: | Chỉ số | Đo gì | Namespace | Dimension | |---|---|---|---| | DiskReadBytes / DiskWriteBytes | INSTANCE STORE | AWS/EC2 | InstanceId | | VolumeReadBytes / VolumeWriteBytes | EBS | AWS/EBS | VolumeId | | VolumeQueueLength | hàng đợi I/O của EBS | AWS/EBS | VolumeId | | EBSReadBytes / EBSWriteBytes | EBS nhìn từ instance (máy hỗ trợ) | AWS/EC2 | InstanceId | | disk_used_percent | dung lượng đã dùng — CẦN AGENT | CWAgent | — |

Từ khoá nhận diện:

"alarm trên đĩa không kích hoạt" → đang dùng Disk* thay vì Volume* "hoạt động của EBS" → Volume*, namespace AWS/EBS "độ trễ EBS" → VolumeQueueLength, VolumeTotalReadTime "dung lượng còn lại" → CloudWatch agent "EBS chạm trần IOPS" → EBSIOBalance%, EBSByteBalance%

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số có dữ liệu không | CloudWatch → namespace AWS/EBS → chọn VolumeId | | Volume nào chậm | so VolumeQueueLength giữa các volume | | Loại volume hiện tại | describe-volumes --query '...VolumeType,Iops,Throughput' |

Và một cách xác nhận rất nhanh trước khi sửa alarm: mở CloudWatch, chọn namespace và xem chỉ số có dữ liệu hay không. Một alarm gắn vào chỉ số không tồn tại sẽ nằm mãi ở trạng thái INSUFFICIENT_DATA thay vì OK — và chính trạng thái đó là dấu hiệu rõ nhất cho thấy bạn đang theo dõi nhầm chỗ, chứ không phải hệ thống đang khoẻ.

Đáp án

C — Tạo GATEWAY VPC ENDPOINT và gắn BUCKET POLICY với điều kiện giới hạn truy cập theo VPC endpoint ID.

Vì sao đúng

Đề đòi hai thứ: lưu lượng không đi qua internet, và bucket chỉ nhận truy cập từ VPC đó.

⚠ Vế thứ nhất — gateway endpoint giữ lưu lượng trong mạng AWS:

Gateway VPC Endpoint cho S3
        ↓
    Thêm một tuyến vào route table:
      prefix list của S3  →  vpce-xxxxx
        ↓
    Lưu lượng đi thẳng qua hạ tầng AWS
        ↓
    → KHÔNG qua Internet Gateway
    → KHÔNG qua NAT Gateway
    → và gateway endpoint MIỄN PHÍ

⚠ Vế thứ hai — bucket policy khoá theo endpoint:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::bucket-nhay-cam",
    "arn:aws:s3:::bucket-nhay-cam/*"
  ],
  "Condition": {
    "StringNotEquals": {
      "aws:sourceVpce": "vpce-0123456789abcdef0"
    }
  }
}

    → mọi request KHÔNG qua đúng endpoint đó
      đều bị TỪ CHỐI
    → kể cả người có khoá hợp lệ gọi từ internet

⚠ Vì sao BUCKET POLICY chứ không phải IAM POLICY:

IAM policy (phương án D)
        ↓
    Chỉ ràng buộc danh tính ĐƯỢC GẮN chính sách
        ↓
    → một role khác, một tài khoản khác
      VẪN truy cập bucket từ internet được
        ↓
Bucket policy
        ↓
    Áp cho MỌI người gọi, mọi danh tính
        ↓
    → đây mới là "bảo vệ BUCKET"

Xem thêm câu #11852 (lô 128): gần như cùng một câu hỏi, cùng đáp án gateway endpoint + bucket policy với aws:sourceVpce. Và #11884 (lô 129), #11977 (cùng lô): cùng chủ đề gateway endpoint cho S3. Khoá nhất quán ở mọi câu.

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

• D (gateway endpoint + IAM POLICY với điều kiện theo endpoint ID) — đây là phương án gần nhất, điều kiện aws:sourceVpce hoàn toàn đúng, chỉ sai chỗ gắn: IAM policy chỉ ràng buộc danh tính được gắn, nên bucket vẫn mở với mọi danh tính khác.

• B (interface VPC endpoint service kèm Network Load Balancer) — đây là mô hình PrivateLink để BẠN PHÁT HÀNH một dịch vụ của chính mình cho VPC khác dùng. S3 dùng gateway endpoint, không cần dựng endpoint service.

• A (NAT Gateway và định tuyến toàn bộ lưu lượng S3 qua NAT) — NAT đưa lưu lượng RA INTERNET, vi phạm thẳng yêu cầu. Lại còn tốn phí trong khi gateway endpoint miễn phí.

Ghi nhớ

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

Từ khoá nhận diện:

"S3, không qua internet" → gateway endpoint "chỉ VPC này được truy cập bucket" → bucket policy + aws:sourceVpce "mạng tại chỗ cũng cần truy cập riêng tư" → interface endpoint "phát hành dịch vụ của mình cho VPC khác" → PrivateLink endpoint service + NLB "giảm phí NAT" → gateway endpoint cho S3 và DynamoDB

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Endpoint đã vào route table chưa | describe-route-tables, tìm vpce- | | Chính sách có chặn đúng không | thử aws s3 ls từ ngoài VPC — phải 403 | | Lưu lượng có ra internet không | VPC Flow Logs — không thấy đích là IP công cộng của S3 |

Và một lời khuyên nên tuân thủ trước khi áp bucket policy loại này: thử ở bucket kiểm thử trước, và giữ sẵn một lối vào cho quản trị. Một điều kiện StringNotEquals viết nhầm endpoint id sẽ khoá tất cả mọi người ra khỏi bucket — kể cả bạn, kể cả tài khoản gốc — và cách gỡ duy nhất khi đó là dùng root user để xoá bucket policy, một thao tác mà không phải tổ chức nào cũng thực hiện được nhanh.

Đáp án

D — Hướng dẫn người dùng chạy aws sts get-session-token và dùng THÔNG TIN XÁC THỰC TẠM THỜI trả về để ký các lời gọi API.

Vì sao đúng

Chính sách từ chối lời gọi không có MFA, và GetSessionToken là cách để "gắn" thông tin MFA vào một phiên CLI.

⚠ Điểm mấu chốt — khoá dài hạn KHÔNG mang thông tin MFA:

Access key thường của IAM user
        ↓
    Ký request nhưng KHÔNG kèm bằng chứng MFA
        ↓
    Chính sách kiểm aws:MultiFactorAuthPresent
        ↓
    → điều kiện KHÔNG khớp
    → mọi lời gọi bị TỪ CHỐI
        ↓
GetSessionToken với mã MFA
        ↓
    aws sts get-session-token \
      --serial-number arn:aws:iam::123:mfa/nguoi-dung \
      --token-code 123456
        ↓
    → trả về AccessKeyId, SecretAccessKey,
      và SESSION TOKEN
    → phiên này CÓ ĐÁNH DẤU đã xác thực MFA
        ↓
    → aws:MultiFactorAuthPresent = true
    → lời gọi được chấp nhận

⚠ Cách dùng thông tin tạm thời đó:

Đặt vào biến môi trường:
    AWS_ACCESS_KEY_ID
    AWS_SECRET_ACCESS_KEY
    AWS_SESSION_TOKEN     ← BẮT BUỘC phải có
        ↓
    Thiếu AWS_SESSION_TOKEN
      → request bị coi là dùng khoá thường
      → vẫn bị từ chối
        ↓
    Thời hạn: mặc định 12 giờ
              (15 phút tới 36 giờ với IAM user)

⚠ Chính sách kiểm MFA viết thế nào:

{
  "Effect": "Deny",
  "NotAction": [
    "iam:CreateVirtualMFADevice",
    "iam:EnableMFADevice",
    "iam:ListMFADevices",
    "sts:GetSessionToken"
  ],
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}

    Phải CHỪA các action để người dùng
    tự đăng ký MFA và lấy session token
        ↓
    Không chừa → không ai bật MFA được
    → tự khoá cả tài khoản

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

• A (đăng nhập console với MFA trước rồi mới gọi API bằng CLI) — đây là phương án gần nhất về trực giác, nhưng phiên console và phiên CLI hoàn toàn tách biệt. Đăng nhập console không làm cho access key của CLI mang thông tin MFA.

• B (đưa người dùng cần CLI vào một group và loại trừ họ khỏi yêu cầu MFA) — phá vỡ chính sách bảo mật mà đội bảo mật vừa ban hành. Không phải giải pháp, mà là né tránh.

• C (không dùng được CLI, phải dùng console) — sai về sự thật: CLI hoàn toàn dùng được với MFA qua GetSessionToken hoặc AssumeRole.

Ghi nhớ

⚠ Hai cách dùng MFA với CLI — bảng phải thuộc: | Cách | Dùng khi | |---|---| | sts get-session-token | IAM user tự nâng phiên của mình lên có MFA | | sts assume-role với --serial-number và --token-code | đảm nhận một role đòi MFA | | Profile trong ~/.aws/config | khai mfa_serial → CLI tự hỏi mã MFA | | Thời hạn | GetSessionToken tối đa 36 giờ; AssumeRole tối đa 12 giờ |

Từ khoá nhận diện:

"MFA cho CLI" → sts get-session-token, hoặc assume-role với mfa_serial "ép MFA cho mọi lời gọi" → aws:MultiFactorAuthPresent trong Deny "MFA cho việc xoá phiên bản S3" → MFA Delete (chỉ root, chỉ CLI) "không muốn quản lý IAM user" → IAM Identity Center — MFA có sẵn "root account" → BẮT BUỘC bật MFA phần cứng hoặc ảo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phiên có MFA chưa | aws sts get-caller-identity rồi thử một action bị chặn | | Ai chưa bật MFA | IAM Credential Report | | Vì sao bị từ chối | CloudTrail — errorMessage nói rõ điều kiện nào không khớp |

Và một cách làm giúp việc ép MFA không gây khó chịu hằng ngày: khai mfa_serial trong profile của AWS CLI. Khi đó CLI tự hỏi mã MFA lần đầu, tự cache token trong nhiều giờ, và mọi lệnh sau đó chạy bình thường — thay vì bắt người dùng chạy get-session-token rồi dán ba biến môi trường mỗi buổi sáng, cách mà hầu như không đội nào duy trì được lâu.

Đáp án

B — AWS/ApplicationELB → HealthyHostCount <= 0.

Vì sao đúng

Đề cần alarm kích hoạt khi TẤT CẢ máy trong target group đều không khoẻ, và chỉ một điều kiện diễn đạt được điều đó một cách chắc chắn.

⚠ Điểm mấu chốt — HealthyHostCount = 0 nghĩa là KHÔNG CÒN AI phục vụ:

HealthyHostCount <= 0
        ↓
    Không còn target khoẻ mạnh nào
        ↓
    → ALB không có nơi nào để gửi request
    → mọi người dùng nhận 503
        ↓
    → đây chính là điều kiện "tất cả đều hỏng"
    → và nó ĐÚNG bất kể target group có
      2 máy hay 200 máy

⚠ Vì sao UnhealthyHostCount >= 1 KHÔNG đúng:

UnhealthyHostCount >= 1
        ↓
    Chỉ cần MỘT máy hỏng là kích hoạt
        ↓
    Target group có 10 máy, 1 máy hỏng
        ↓
    → alarm bật, nhưng dịch vụ VẪN BÌNH THƯỜNG
    → 9 máy còn lại phục vụ tốt
        ↓
    → BÁO ĐỘNG GIẢ liên tục
    → và đội trực sẽ bắt đầu bỏ qua nó

⚠ Và vì sao status check của EC2 cũng không đúng:

StatusCheckFailed_Instance / _System
        ↓
    Kiểm tra máy có SỐNG không
        ↓
    → không kiểm tra ỨNG DỤNG có phục vụ được không
        ↓
    Ứng dụng treo, trả lỗi 500
      → máy vẫn qua status check
      → nhưng ALB đánh dấu là unhealthy
        ↓
    → chỉ health check của ALB mới phản ánh
      đúng trải nghiệm người dùng

Xem thêm câu #11802 (lô 127): gần như cùng một câu hỏi, cùng đáp án HealthyHostCount <= 0. Khoá nhất quán.

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

• C (UnhealthyHostCount >= 1) — đây là phương án gần nhất và dùng đúng namespace, nhưng nó kích hoạt khi chỉ MỘT máy hỏng, trong khi dịch vụ vẫn hoàn toàn bình thường. Không diễn đạt được "tất cả đều hỏng".

• A (AWS/EC2 StatusCheckFailed_Instance <= 0) — sai hai lần: dùng chỉ số của EC2 thay vì của ALB, và <= 0 nghĩa là status check THÀNH CÔNG — tức là alarm sẽ bật khi máy đang khoẻ.

• D (AWS/EC2 StatusCheckFailed_System >= 1) — kiểm tra hạ tầng AWS bên dưới, không phản ánh tình trạng ứng dụng, và cũng không cho biết cả target group có hỏng hết hay không.

Ghi nhớ

⚠ Chỉ số sức khoẻ của ALB — bảng phải thuộc: | Chỉ số | Ý nghĩa | |---|---| | HealthyHostCount | số target KHOẺ — về 0 là mất dịch vụ | | UnhealthyHostCount | số target không khoẻ | | TargetResponseTime | độ trễ backend — chỉ số trải nghiệm chính | | RequestCount | lưu lượng | | HTTPCode_ELB_5XX_Count | lỗi do ALB — 503 khi không có target khoẻ | | HTTPCode_Target_5XX_Count | lỗi do ứng dụng | | RejectedConnectionCount | chạm giới hạn kết nối |

Từ khoá nhận diện:

"tất cả máy đều hỏng" → HealthyHostCount <= 0 "một máy hỏng" → UnhealthyHostCount >= 1 — thường là báo động giả "máy có sống không" → StatusCheckFailed_* "phần cứng lỗi" → StatusCheckFailed_System + hành động Recover "người dùng thấy chậm" → TargetResponseTime

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Target đang thế nào | describe-target-health --target-group-arn ... | | Vì sao unhealthy | đọc trường TargetHealth.Reason và Description | | Alarm có gửi được không | set-alarm-state --state-value ALARM |

Và một cấu hình rất quan trọng cho chính alarm này: đặt TreatMissingData thành breaching. Nếu target group hoàn toàn trống — chẳng hạn Auto Scaling đã huỷ hết máy — thì chỉ số HealthyHostCount có thể ngừng được phát ra, và một alarm cấu hình mặc định sẽ nằm im ở trạng thái cũ thay vì báo động, đúng vào lúc dịch vụ đã ngừng hoàn toàn.