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

Đáp án

A — Cài CloudWatch agent lên instance để thu thập chỉ số ĐĨA, rồi tạo alarm cảnh báo khi dung lượng còn thấp.

Vì sao đúng

Có một sự thật nền tảng quyết định câu này: CloudWatch không tự biết ổ đĩa của bạn còn bao nhiêu chỗ trống.

⚠ Điểm mấu chốt — hypervisor không nhìn thấy bên trong hệ điều hành:

CloudWatch mặc định thu chỉ số từ HYPERVISOR
        ↓
    Thấy được:
      DiskReadBytes, DiskWriteBytes,
      VolumeReadOps, VolumeWriteOps
      → tức là HOẠT ĐỘNG đọc ghi
        ↓
    KHÔNG thấy được:
      dung lượng đã dùng / còn trống
      → vì đó là thông tin của FILE SYSTEM
        bên trong hệ điều hành khách
        ↓
    → phải cài AGENT mới lấy được

⚠ Chỉ số cần theo dõi và cấu hình agent:

{
  "metrics": {
    "metrics_collected": {
      "disk": {
        "measurement": ["used_percent", "inodes_free"],
        "resources": ["/"],
        "metrics_collection_interval": 60
      },
      "mem": { "measurement": ["mem_used_percent"] }
    }
  }
}

disk_used_percent  → phần trăm đã dùng
inodes_free        → HẾT INODE cũng gây lỗi
                     "no space left" dù còn dung lượng

⚠ Và alarm nên có hai bậc:

80%  → cảnh báo sớm, còn thời gian xử lý
90%  → khẩn cấp, gọi đội trực
        ↓
    Kèm hành động tự động:
      SSM Automation dọn log cũ,
      hoặc MỞ RỘNG volume (EBS Elastic Volumes)
      rồi resize file system — KHÔNG cần dừng máy

Xem thêm câu #11833 (cùng lô): cùng nguyên tắc — chỉ số bộ nhớ và đĩa đều cần CloudWatch agent.

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

• B (bật detailed monitoring rồi tạo alarm cho dung lượng đĩa) — đây là phương án gần nhất và là bẫy phổ biến nhất của chủ đề này: detailed monitoring chỉ tăng tần suất từ 5 phút xuống 1 phút cho các chỉ số đã có sẵn. Nó không thêm chỉ số mới nào, nên vẫn không có disk_used_percent.

• C (dùng CloudWatch Events theo dõi EC2 status check để biết tình trạng EBS volume) — status check kiểm tra máy có phản hồi được không, không kiểm tra dung lượng còn trống. Một máy đầy ổ vẫn qua status check bình thường.

• D (viết Lambda dùng EBS API để theo dõi chỉ số dung lượng) — EBS API không cung cấp thông tin dung lượng đã dùng; nó chỉ biết kích thước volume, còn phần đã dùng nằm ở file system. Và đây cũng là cách tự làm lại thứ agent đã có sẵn.

Ghi nhớ

⚠ Chỉ số có sẵn ↔ chỉ số cần agent — bảng phải thuộc: | Có sẵn (hypervisor) | Cần CloudWatch agent | |---|---| | CPUUtilization | mem_used_percent | | NetworkIn / NetworkOut | disk_used_percent | | DiskReadBytes / DiskWriteOps (hoạt động) | inodes_free | | StatusCheckFailed_Instance / _System | swap_used_percent | | EBSIOBalance%, EBSByteBalance% | log hệ điều hành và ứng dụng, procstat |

Từ khoá nhận diện:

"dung lượng đĩa còn lại", "bộ nhớ" → CloudWatch agent, LUÔN LUÔN "detailed monitoring" → chỉ đổi TẦN SUẤT, không thêm chỉ số "CPU, mạng" → có sẵn "status check" → máy có sống không, không phải dung lượng "tự động mở rộng ổ khi gần đầy" → EBS Elastic Volumes + SSM Automation

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent có chạy không | amazon-cloudwatch-agent-ctl -a status | | Chỉ số đã lên chưa | CloudWatch → Metrics → namespace CWAgent | | Ổ còn bao nhiêu chỗ | trên máy: df -h và df -i |

Và một nguyên nhân rất hay bị bỏ sót khi máy báo hết chỗ: cạn INODE chứ không phải cạn dung lượng. df -h báo còn trống rất nhiều trong khi mọi thao tác ghi đều lỗi "No space left on device" — đó là dấu hiệu của một thư mục chứa hàng triệu tệp nhỏ, thường là log hoặc cache của phiên làm việc, và chỉ df -i mới cho thấy điều đó.

Đáp án

C — StackSets.

Vì sao đúng

Đề nêu chính xác định nghĩa của StackSets: một template, tạo và quản lý stack ở NHIỀU TÀI KHOẢN và NHIỀU REGION, bằng MỘT thao tác.

⚠ Điểm mấu chốt — StackSets mở rộng CloudFormation ra hai chiều:

Stack thường
        ↓
    Một tài khoản, một Region
        ↓
StackSets
        ↓
    Một template + danh sách TÀI KHOẢN + danh sách REGION
        ↓
    CloudFormation tạo một STACK INSTANCE
    ở mỗi ô của ma trận đó
        ↓
    Ví dụ: 20 tài khoản × 3 Region = 60 stack
    → tạo và cập nhật bằng MỘT lệnh

⚠ Hai chế độ quyền — điểm hay ra thi:

SELF-MANAGED
        ↓
    Bạn tự tạo hai IAM role:
      AWSCloudFormationStackSetAdministrationRole
        (ở tài khoản quản trị)
      AWSCloudFormationStackSetExecutionRole
        (ở MỖI tài khoản đích)
        ↓
    Dùng khi các tài khoản KHÔNG ở cùng tổ chức

SERVICE-MANAGED  ← khuyến nghị
        ↓
    Tích hợp thẳng với AWS Organizations
    → khai OU thay vì từng account id
    → AWS lo phần role
        ↓
    AUTO-DEPLOYMENT:
      tài khoản MỚI vào OU → TỰ ĐỘNG được triển khai
      tài khoản rời OU     → tự gỡ stack

⚠ Kiểm soát mức độ rủi ro khi triển khai:

MaxConcurrentCount / MaxConcurrentPercentage
        ↓
    → bao nhiêu tài khoản triển khai cùng lúc

FailureToleranceCount / Percentage
        ↓
    → hỏng bao nhiêu thì DỪNG toàn bộ
        ↓
    Cộng với RegionOrder
        ↓
    → triển khai Region ít rủi ro trước,
      production sau

Xem thêm câu #11857 (cùng lô): cũng về tái sử dụng template CloudFormation. Hai câu bổ sung cho nhau — Parameters làm một template dùng được cho nhiều môi trường, StackSets đưa nó ra nhiều tài khoản và Region.

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

• A (nested stacks) — đây là phương án gần nhất về mức độ hữu ích, nhưng nested stack dùng để chia một template lớn thành các thành phần con dùng lại được, và tất cả vẫn nằm trong một tài khoản, một Region.

• B (stack policies) — bảo vệ tài nguyên khỏi bị cập nhật hoặc thay thế ngoài ý muốn trong một stack. Không liên quan tới triển khai nhiều nơi.

• D (change sets) — xem trước thay đổi trước khi áp dụng lên một stack đang tồn tại. Cũng chỉ trong phạm vi một stack.

Ghi nhớ

⚠ Bốn khái niệm CloudFormation dễ lẫn — bảng phải thuộc: | Khái niệm | Việc | |---|---| | StackSets | một template → NHIỀU tài khoản và Region | | Nested stacks | chia nhỏ template lớn thành thành phần dùng lại | | Stack policy | bảo vệ tài nguyên khỏi cập nhật ngoài ý muốn | | Change set | xem trước thay đổi trước khi áp dụng | | Cross-stack reference | stack này đọc Export của stack kia | | Drift detection | phát hiện ai đó sửa tay ngoài CloudFormation |

Từ khoá nhận diện:

"nhiều tài khoản VÀ nhiều Region, một thao tác" → StackSets "chia nhỏ template" → nested stacks "đừng để ai xoá nhầm CSDL khi cập nhật" → stack policy "xem trước sẽ ảnh hưởng gì" → change set "tài khoản mới tự động có cấu hình chuẩn" → StackSets service-managed + auto-deployment

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Triển khai tới đâu rồi | list-stack-instances --stack-set-name ... | | Chỗ nào hỏng | describe-stack-instance cho tài khoản/Region đó | | Có ai sửa tay không | drift detection trên stack set |

Và một cách triển khai nên áp dụng cho mọi thay đổi diện rộng: đặt RegionOrder với một Region thử nghiệm đứng đầu và FailureToleranceCount bằng 0. Khi ấy một template có lỗi sẽ dừng lại sau đúng một tài khoản đầu tiên, thay vì lan ra sáu mươi stack — và việc dọn dẹp sẽ là một thao tác, chứ không phải một buổi chiều.

Đáp án

D — Tạo một CloudFront distribution với bucket S3 làm origin.

Vì sao đúng

Đề nêu hai vấn đề — độ trễ cao và tải đọc lớn lên bucket — và CloudFront giải cả hai bằng cùng một cơ chế: cache tại biên.

⚠ Điểm mấu chốt — cache giải đồng thời hai bài toán:

Request đầu tiên cho một tệp
        ↓
    Edge location gần người dùng
    → lấy từ bucket S3 (một lần)
    → LƯU LẠI tại edge
        ↓
Mọi request sau cho cùng tệp đó
        ↓
    → phục vụ NGAY TẠI EDGE
        ↓
    ĐỘ TRỄ giảm: từ hàng trăm ms xuống vài chục ms
    TẢI LÊN S3 giảm: chỉ còn phần cache miss
        ↓
    Với website tĩnh, tỉ lệ cache hit
    thường đạt 90-99%

⚠ Và nó còn giải luôn vấn đề chi phí và bảo mật:

CHI PHÍ
        ↓
    - Dữ liệu ra từ CloudFront RẺ HƠN từ S3
    - Ít request tới S3 → ít phí GET
    - Dữ liệu S3 → CloudFront: MIỄN PHÍ
        ↓
BẢO MẬT
        ↓
    Origin Access Control (OAC)
    → bucket để RIÊNG TƯ HOÀN TOÀN
    → gắn được WAF, chống DDoS bằng Shield

⚠ Vì sao ElastiCache không dùng được ở đây:

ElastiCache
        ↓
    Cache trong bộ nhớ, nằm TRONG VPC
        ↓
    - Không phục vụ trực tiếp cho trình duyệt
    - Cần một ứng dụng đứng giữa để đọc/ghi cache
    - Không có mặt ở gần người dùng
        ↓
    → sai hoàn toàn tầng bài toán

Xem thêm câu #11830, #11868, #11877 và #11847 (cùng lô): đây là chùm năm câu cùng quy về CloudFront cho nội dung tĩnh, mỗi câu nhìn từ một góc — độ trễ địa lý, tải đọc cao, hiệu năng chung, và lỗi 503 do vượt ngưỡng.

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

• C (chuyển sang bucket ở Region gần người dùng cuối hơn) — đây là phương án gần nhất và giảm được độ trễ cho MỘT nhóm người dùng, nhưng nó làm nhóm khác xa hơn, và không giảm tải đọc chút nào — mọi request vẫn tới thẳng bucket.

• B (dùng Cross-Region Replication để nhân bản dữ liệu sang Region khác) — tạo được bản sao, nhưng bạn vẫn phải tự định tuyến người dùng tới bucket đúng, và vẫn không có cache nên tải đọc không giảm. Lại tốn thêm chi phí lưu trữ gấp đôi.

• A (dùng ElastiCache Redis để cache dữ liệu tĩnh từ bucket) — sai tầng kiến trúc: ElastiCache nằm trong VPC, phục vụ ứng dụng, không phục vụ trình duyệt người dùng cuối.

Ghi nhớ

⚠ Các loại cache trên AWS — bảng phải thuộc: | Cache | Ở đâu | Cho ai | |---|---|---| | CloudFront | hơn 400 edge location toàn cầu | người dùng cuối, qua HTTP | | ElastiCache | trong VPC | ứng dụng của bạn (kết quả truy vấn, phiên) | | API Gateway cache | tại Region | phản hồi API | | DAX | trong VPC | chỉ DynamoDB | | Cache trình duyệt | máy người dùng | điều khiển bằng header Cache-Control |

Từ khoá nhận diện:

"tải đọc cao lên S3" → CloudFront "độ trễ cao với người dùng ở xa" → CloudFront "truy vấn CSDL lặp lại tốn kém" → ElastiCache "DynamoDB đọc nhiều, cần dưới mili giây" → DAX "503 SlowDown từ S3" → CloudFront, và chia nhiều prefix

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cache có hiệu quả không | chỉ số CacheHitRate, và header X-Cache | | Tải lên S3 đã giảm chưa | so số request GetObject trước và sau | | Bucket đã đóng chưa | gọi thẳng URL S3 — phải nhận 403 |

Và một điều nên kiểm tra khi tỉ lệ cache hit thấp hơn mong đợi: xem cache policy có đang đưa query string hoặc cookie vào khoá cache không. Chỉ cần một tham số theo dõi quảng cáo được tính vào khoá là mỗi lượt truy cập trở thành một mục cache riêng — và CloudFront khi đó chỉ còn là một lớp trung chuyển tốn tiền, không phải một CDN.

Đáp án

B — Dùng Amazon CloudFront để cache nội dung tĩnh.

Vì sao đúng

Kiến trúc trong đề đã khá tốt — ASG, RDS Multi-AZ, S3 cho nội dung tĩnh — nhưng thiếu đúng một mảnh: không có tầng cache trước nội dung tĩnh.

⚠ Điểm mấu chốt — nội dung tĩnh thường chiếm phần lớn số request:

Một trang web điển hình
        ↓
    1 request HTML  (động)
    + 30-80 request ảnh, CSS, JS, font  (TĨNH)
        ↓
    → phần tĩnh chiếm 80-95% SỐ REQUEST
      và phần lớn KHỐI LƯỢNG dữ liệu
        ↓
CloudFront đứng trước tất cả
        ↓
    - Phần tĩnh phục vụ tại edge → S3 nhẹ hẳn
    - Phần động vẫn về ALB, nhưng ÍT ĐI nhiều
    - Kết nối TLS kết thúc tại edge → bắt tay nhanh hơn
        ↓
    → thời gian phản hồi giảm rõ rệt
    → và hệ thống co giãn tốt hơn hẳn

⚠ CloudFront còn tăng tốc cả phần ĐỘNG:

Ngay cả khi TTL = 0 (không cache)
        ↓
    Request vẫn đi qua ĐƯỜNG TRỤC RIÊNG của AWS
    từ edge về origin
        ↓
    - Kết nối tới origin được TÁI SỬ DỤNG
    - TLS handshake xảy ra ở edge, gần người dùng
    - Đường đi tối ưu hơn internet công cộng
        ↓
    → API động cũng nhanh hơn 20-50%

⚠ Cấu hình cho kiến trúc của đề:

Hai origin:
    S3   → nội dung tĩnh
    ALB  → nội dung động
        ↓
Cache behavior:
    /static/*, /images/*  → S3,  TTL dài
    /api/*                → ALB, TTL 0
    /*                    → ALB, TTL ngắn
        ↓
    Bật nén, dùng OAC cho bucket

Xem thêm câu #11830, #11868, #11876 và #11847 (cùng lô): chùm năm câu về CloudFront cho nội dung tĩnh, khoá nhất quán ở mọi câu.

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

• A (phục vụ nội dung tĩnh từ chính máy EC2 với EFS làm kho lưu trữ) — đây là phương án gần nhất về mặt "cũng làm được", nhưng nó đi ngược hướng: dồn thêm tải lên đúng tầng đang chậm, thêm độ trễ của EFS vào mỗi request, và mất khả năng mở rộng gần như vô hạn của S3.

• C (chuyển CSDL từ RDS sang ElastiCache for Memcached) — hiểu sai vai trò của cache: Memcached là kho khoá-giá trị trong bộ nhớ, KHÔNG BỀN, không thay thế được một CSDL quan hệ. (Đặt ElastiCache TRƯỚC RDS thì hợp lý — nhưng đó là "thêm", không phải "chuyển".)

• D (dùng Route 53 với định tuyến theo vị trí địa lý) — chỉ có ý nghĩa khi hạ tầng được triển khai ở NHIỀU Region. Đề chỉ có một kiến trúc trong một Region.

Ghi nhớ

⚠ Cải thiện hiệu năng — theo đúng tầng bị nghẽn: | Tầng | Triệu chứng | Giải pháp | |---|---|---| | Nội dung tĩnh | ảnh, CSS, JS chậm | CloudFront | | Tầng web | chậm khi đông người | Auto Scaling, máy lớn hơn | | CSDL — đọc | truy vấn đọc chậm | read replica, ElastiCache | | CSDL — ghi | ghi nghẽn | đổi cỡ instance, phân mảnh | | Mã ứng dụng | chậm ở mọi nơi | X-Ray, profiling | | Địa lý | chỉ chậm ở một khu vực | CloudFront, đa Region |

Từ khoá nhận diện:

"nội dung tĩnh trên S3, phản hồi chậm" → CloudFront "đông người thì chậm" → Auto Scaling "CSDL đọc nhiều" → read replica hoặc ElastiCache "định tuyến theo vị trí" → cần NHIỀU Region trước đã "Memcached thay cho CSDL" → luôn SAI — Memcached không bền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nội dung tĩnh chiếm bao nhiêu | mở DevTools, xem tab Network | | Sau khi bật CloudFront | so TargetResponseTime và số request tới ALB | | Cache có hiệu quả không | CacheHitRate — dưới 80% là nên xem lại cache policy |

Và một nguyên tắc nên nhớ khi gặp đề dạng "làm sao tăng hiệu năng": đọc kỹ xem kiến trúc đã có gì rồi. Ở đây ASG, Multi-AZ và S3 đều đã có, nên câu trả lời không nằm ở việc thêm một tầng nữa vào những thứ đã tốt — nó nằm ở mảnh còn thiếu duy nhất, và trong hầu hết đề về ứng dụng web phục vụ nội dung tĩnh, mảnh còn thiếu đó là CloudFront.

Đáp án

C — Đổi điều kiện thành StringNotEquals.

Vì sao đúng

Chính sách đang Deny nhưng điều kiện viết sai chiều, nên nó không khớp với request nào cả.

⚠ Điểm mấu chốt — Deny phải khớp với những gì bạn muốn CẤM:

Ý định: chỉ cho phép t2.micro
        ↓
Cách viết SAI (StringEquals):
    Deny  ec2:RunInstances
    Condition: StringEquals
        ec2:InstanceType = "t2.micro"
        ↓
    → CẤM đúng t2.micro
    → mọi loại KHÁC vẫn chạy được
    → ngược hoàn toàn ý định

Cách viết ĐÚNG (StringNotEquals):
    Deny  ec2:RunInstances
    Condition: StringNotEquals
        ec2:InstanceType = "t2.micro"
        ↓
    → CẤM mọi loại KHÔNG PHẢI t2.micro
    → chỉ t2.micro đi qua được

⚠ SCP viết đầy đủ:

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {
    "StringNotEquals": {
      "ec2:InstanceType": "t2.micro"
    }
  }
}

Lưu ý Resource phải là instance/*
        ↓
    RunInstances chạm tới NHIỀU loại tài nguyên
    (instance, volume, network-interface, image…)
        ↓
    Chỉ đặt điều kiện ở instance/*
    → nếu Deny toàn bộ arn:aws:ec2:*:*:*
      thì chặn luôn cả volume và ENI
      → không tạo được máy nào cả

⚠ Vì sao Deny + NotEquals thay vì Allow:

SCP mặc định có FullAWSAccess ở root
        ↓
    Thêm một Allow hẹp KHÔNG thu hẹp được gì
    (quyền là HỢP của các Allow)
        ↓
    Muốn thu hẹp thì phải:
      a) dùng Deny  ← an toàn, phổ biến
      b) gỡ FullAWSAccess rồi chỉ Allow
         → rủi ro cao, dễ khoá sạch

Xem thêm câu #11865 (lô 128) và #11882 (cùng lô): cùng chủ đề SCP làm trần quyền cho tài khoản trong Organizations.

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

• A (đổi Effect từ Deny sang Allow) — đây là phương án gần nhất về trực giác, nhưng thêm một Allow vào SCP không cấm được gì: FullAWSAccess gắn sẵn ở root vẫn cho phép mọi thứ, và quyền hiệu lực là hợp của các Allow.

• B (đổi Resource thành arn:aws:ec2:*:*:t2.micro/*) — không phải một ARN hợp lệ. Loại instance không phải là tài nguyên; nó là thuộc tính của request, nên phải kiểm bằng Condition, không phải bằng Resource.

• D (đổi ngày trong trường Version) — Version không phải ngày tháng bạn tự đặt. Nó là phiên bản ngôn ngữ chính sách, luôn là "2012-10-17" và không được đổi.

Ghi nhớ

⚠ SCP — những điều phải nhớ chính xác: | Đặc điểm | Nội dung | |---|---| | Bản chất | TRẦN quyền tối đa — KHÔNG cấp quyền | | Quyền hiệu lực | SCP ∩ IAM policy | | Không áp cho | tài khoản quản lý (management account) | | Cách siết an toàn | dùng Deny, giữ nguyên FullAWSAccess | | Version | luôn là "2012-10-17" | | Kế thừa | cộng dồn từ root xuống, mọi cấp đều phải cho qua |

Từ khoá nhận diện:

"chỉ được dùng X" → Deny + StringNotEquals "không được dùng X" → Deny + StringEquals "chặn Region" → aws:RequestedRegion với StringNotEquals "bắt buộc gắn tag" → Deny + Null trên aws:RequestTag/... "chính sách không có tác dụng" → kiểm tra chiều của Condition trước tiên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SCP thực sự áp là gì | describe-effective-policy --policy-type SERVICE_CONTROL_POLICY | | Chính sách có chặn đúng không | đăng nhập tài khoản đó rồi thử chạy một loại máy khác | | Vì sao bị chặn | CloudTrail — lỗi AccessDenied ghi rõ "with an explicit deny in a service control policy" |

Và một cách kiểm chứng nhanh hơn nhiều so với thử thật: dùng --dry-run với run-instances. Nó gửi request đầy đủ qua toàn bộ chuỗi kiểm quyền nhưng không tạo máy — nên bạn xác nhận được SCP đang chặn đúng loại nào và cho qua loại nào trong vài giây, thay vì phải khởi chạy rồi huỷ từng máy một.

Đáp án

A — Bảo đảm cụm Redshift TRUY CẬP ĐƯỢC tới các endpoint dịch vụ AWS cần thiết.

Vì sao đúng

Thông báo lỗi đã nói gần như toàn bộ câu trả lời: Failed connect to datacatalog.us-west-2.amazonaws.com:443 — đây là lỗi MẠNG, không phải lỗi dữ liệu hay lỗi quyền.

⚠ Điểm mấu chốt — Redshift Spectrum cần gọi ra ngoài cụm:

Redshift Spectrum truy vấn dữ liệu trong S3
        ↓
    Nhưng nó cần LƯỢC ĐỒ BẢNG trước
        ↓
    Lược đồ nằm ở AWS GLUE DATA CATALOG
      (endpoint: datacatalog.<region>.amazonaws.com)
        ↓
    Cụm phải kết nối được tới:
      - Glue Data Catalog
      - Amazon S3
        ↓
    Cụm nằm trong SUBNET RIÊNG của VPC
        ↓
    → nếu subnet không có đường ra
      thì không gọi được endpoint nào
    → đúng lỗi "Failed connect ... :443"

⚠ Ba cách mở đường, chọn theo yêu cầu bảo mật:

1. VPC ENDPOINT  ← an toàn nhất, khuyến nghị
        ↓
    Gateway endpoint cho S3        (MIỄN PHÍ)
    Interface endpoint cho Glue    (PrivateLink)
        ↓
    → lưu lượng KHÔNG ra internet

2. NAT GATEWAY
        ↓
    Cụm ở private subnet, đi ra qua NAT
        ↓
    → chạy được, nhưng qua internet công cộng
      và tốn phí xử lý dữ liệu

3. Enhanced VPC Routing + endpoint
        ↓
    Ép MỌI lưu lượng COPY/UNLOAD đi qua VPC
    → kiểm soát và ghi log được bằng flow log

⚠ Đừng quên vế QUYỀN — hay hỏng cùng lúc:

Cụm Redshift cần một IAM ROLE gắn vào nó
        ↓
    Quyền cần:
      glue:GetTable, GetPartitions, GetDatabase…
      s3:GetObject, s3:ListBucket
        ↓
    Và role phải được khai trong câu lệnh
      CREATE EXTERNAL SCHEMA ... IAM_ROLE 'arn:...'

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

• B (thiếu năng lực, dùng Elastic resize) — đây là phương án gần nhất vì Redshift có vấn đề năng lực thật, nhưng lỗi thiếu năng lực trông hoàn toàn khác: truy vấn chạy chậm, hoặc xếp hàng chờ, chứ không phải "Failed connect" tới một tên miền.

• C (các node chạy ở nhiều AZ, hãy dồn về một AZ) — cụm Redshift LUÔN nằm trong MỘT Availability Zone; không có cấu hình nhiều AZ để mà sửa.

• D (sai thông tin đăng nhập) — sai thông tin đăng nhập trả về lỗi xác thực rõ ràng, không phải lỗi kết nối TCP tới cổng 443.

Ghi nhớ

⚠ Đọc thông báo lỗi để phân loại — bảng đáng thuộc: | Thông báo | Loại lỗi | Nghi phạm | |---|---|---| | Failed connect to ...:443 | MẠNG | route table, endpoint, security group, NAT | | AccessDenied, not authorized | QUYỀN | IAM role, bucket policy, key policy | | Invalid credentials | XÁC THỰC | mật khẩu, khoá | | Table not found | DỮ LIỆU | lược đồ, catalog | | Truy vấn chạy nhưng chậm | NĂNG LỰC | cỡ cụm, phân bố dữ liệu |

Từ khoá nhận diện:

"Failed connect tới một endpoint AWS" → đường mạng: VPC endpoint hoặc NAT "Redshift Spectrum" → cần Glue Data Catalog VÀ S3 "không được ra internet" → VPC endpoint "truy vấn Spectrum chậm" → phân vùng dữ liệu, dùng Parquet, nén "ép lưu lượng đi trong VPC" → Enhanced VPC Routing

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cụm có ra được endpoint không | tạm bật NAT rồi thử lại — chạy được thì đúng là lỗi mạng | | Endpoint đã có chưa | describe-vpc-endpoints, tìm s3 và glue | | Role có đủ quyền không | CloudTrail, tìm AccessDenied với action glue:GetTable |

Và một trình tự chẩn đoán đáng theo cho mọi lỗi kiểu này: phân loại thông báo trước, rồi mới đi tìm nguyên nhân. "Failed connect" là lỗi ở tầng vận chuyển — nó xảy ra trước cả khi quyền hay dữ liệu được xem xét tới, nên mọi thời gian bỏ ra để soi IAM policy hay lược đồ bảng ở giai đoạn này đều là thời gian đi lạc hướng.

Đáp án

A — Tạo quy tắc EventBridge theo dõi dung lượng còn trống của file system, kích hoạt thông báo SNS khi FreeStorageSpace xuống dưới 100 GB, và ĐĂNG KÝ địa chỉ email vào SNS topic.

Vì sao đúng

Phương án A là phương án duy nhất mô tả toàn bộ chuỗi từ chỉ số tới hộp thư, và chính chuỗi đầy đủ đó mới đáp ứng yêu cầu "nhận được email".

⚠ Điểm mấu chốt — cảnh báo chỉ hữu ích khi đủ BA mắt xích:

1. THEO DÕI chỉ số
        ↓
    FSx for Windows phát chỉ số FreeStorageSpace
    vào namespace AWS/FSx
        ↓
2. KÍCH HOẠT khi vượt ngưỡng
        ↓
    Ngưỡng: dưới 100 GB
        ↓
3. GỬI TỚI NGƯỜI NHẬN
        ↓
    SNS topic → ĐĂNG KÝ EMAIL → xác nhận đăng ký
        ↓
    Thiếu mắt xích 3 → có cảnh báo mà không ai biết

⚠ Vì sao mắt xích thứ ba lại là điểm phân biệt:

Phương án D dừng ở "đặt ngưỡng cho alarm"
        ↓
    → không nói gì tới HÀNH ĐỘNG của alarm
    → không nói gì tới SNS
    → không nói gì tới đăng ký email
        ↓
    Một alarm không có alarm action
      chỉ đổi màu trên console
        ↓
    → không ai nhận được email nào

⚠ Và một chi tiết vận hành phải nhớ:

Đăng ký email vào SNS
        ↓
    AWS gửi thư XÁC NHẬN
        ↓
    Người nhận PHẢI BẤM LINK xác nhận
        ↓
    Chưa xác nhận → trạng thái PendingConfirmation
    → cảnh báo bắn ra nhưng KHÔNG tới hộp thư
        ↓
    → đây là nguyên nhân số một khiến
      "alarm chạy mà không ai nhận được gì"

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

• D (cấu hình CloudWatch alarm theo dõi FreeStorageSpace, đặt ngưỡng dưới 100 GB) — đây là phương án gần nhất và cách tiếp cận đúng chuẩn mực, nhưng nó dừng ở việc đặt ngưỡng: không cấu hình hành động gửi SNS, không đăng ký email. Yêu cầu của đề là nhận được email, và phương án này chưa đi tới đó.

• B (bật CloudWatch Logs cho file system rồi dùng metric filter bắt thay đổi dung lượng) — dung lượng còn trống là một CHỈ SỐ, không phải một dòng log. Metric filter dùng để trích chỉ số từ văn bản log, hoàn toàn không áp dụng được ở đây.

• C (viết Lambda định kỳ kiểm tra dung lượng rồi gửi email) — tự làm lại thứ CloudWatch đã có sẵn, kèm hàm phải bảo trì và một lịch phải theo dõi.

Ghi nhớ

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

Cách diễn đạt của phương án A không hoàn toàn chính xác về mặt kỹ thuật: EventBridge không "theo dõi chỉ số" — việc so sánh một chỉ số với ngưỡng là công việc của CloudWatch alarm. EventBridge phản ứng với sự kiện, và một trong những sự kiện nó bắt được chính là thay đổi trạng thái của CloudWatch alarm.

Cách triển khai chuẩn mực cho yêu cầu này là: CloudWatch alarm trên FreeStorageSpace với ngưỡng 100 GB → alarm action là SNS topic → email đã đăng ký và xác nhận.

Khoá đáp án vẫn là A, vì trong bốn lựa chọn thì chỉ A mô tả đủ cả ba mắt xích tới hộp thư người nhận, còn D bỏ mất phần thông báo. Khi gặp đề dạng này, hãy chọn phương án đi trọn vẹn tới kết quả mà đề yêu cầu, kể cả khi cách diễn đạt của nó có chỗ chưa chuẩn.

⚠ Chỉ số quan trọng của FSx for Windows — bảng đáng thuộc: | Chỉ số | Ý nghĩa | |---|---| | FreeStorageCapacity | dung lượng còn trống — chỉ số của đề này | | DataReadBytes / DataWriteBytes | thông lượng đọc ghi | | DataReadOperations / DataWriteOperations | số thao tác | | ClientConnections | số client đang kết nối | | FileServerDiskThroughputUtilization | mức dùng thông lượng — cạn là nghẽn |

Từ khoá nhận diện:

"cảnh báo khi chỉ số vượt ngưỡng" → CloudWatch alarm + SNS "phản ứng với một SỰ KIỆN" → EventBridge "trích chỉ số từ nội dung log" → metric filter "alarm chạy mà không ai nhận email" → đăng ký SNS chưa XÁC NHẬN "tự động mở rộng khi gần đầy" → Lambda hoặc SSM Automation gọi update-file-system

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng ký email đã xác nhận chưa | list-subscriptions-by-topic — không được là PendingConfirmation | | Đường thông báo có chạy không | set-alarm-state --state-value ALARM rồi xem hộp thư | | Dung lượng còn bao nhiêu | CloudWatch → namespace AWS/FSx → FreeStorageCapacity |

Và một việc nên làm ngay khi dựng bất kỳ cảnh báo nào: ép nó vào trạng thái ALARM một lần bằng set-alarm-state để xác nhận email thật sự tới nơi. Toàn bộ giá trị của một hệ thống cảnh báo nằm ở mắt xích cuối cùng, và đó cũng chính là mắt xích duy nhất mà console không hiển thị trạng thái cho bạn thấy.

Đáp án

D — Tạo network ACL với một luật OUTBOUND từ chối lưu lượng tới địa chỉ IP bên ngoài đó.

Vì sao đúng

Yêu cầu là CHẶN lưu lượng tới một địa chỉ IP cụ thể, và chỉ có một công cụ trong VPC làm được điều đó.

⚠ Điểm mấu chốt — security group KHÔNG CÓ luật Deny:

SECURITY GROUP
        ↓
    Chỉ có luật ALLOW
    Mặc định outbound: cho phép TẤT CẢ
        ↓
    Muốn chặn một IP:
      → phải liệt kê MỌI IP KHÁC vào luật allow
      → bất khả thi
        ↓
NETWORK ACL
        ↓
    Có CẢ Allow LẪN DENY
        ↓
    Thêm một luật Deny cho đúng IP đó
    với số thứ tự THẤP (xét trước)
        ↓
    → chặn được chính xác một địa chỉ

⚠ Cấu hình luật cho đúng:

NACL của subnet chứa máy bị nghi ngờ

  Outbound rules:
    #90   DENY   203.0.113.55/32   ALL   ← luật mới
    #100  ALLOW  0.0.0.0/0         ALL
        ↓
    NACL xét theo SỐ THỨ TỰ TĂNG DẦN
    và DỪNG ở luật khớp ĐẦU TIÊN
        ↓
    → luật Deny phải đứng TRƯỚC luật Allow rộng
    → đánh số 90 < 100

⚠ Nhưng chặn IP chỉ là bước ĐẦU của xử lý sự cố:

GuardDuty báo lưu lượng bất thường
        ↓
    → nghĩa là máy CÓ THỂ ĐÃ BỊ XÂM NHẬP
        ↓
Quy trình đầy đủ:
    1. CÔ LẬP: đổi sang security group không cho gì
    2. GIỮ HIỆN TRƯỜNG: snapshot EBS, chụp bộ nhớ
    3. ĐIỀU TRA: flow log, CloudTrail, log hệ thống
    4. Kiểm tra IAM role gắn vào máy có bị lạm dụng không
    5. DIỆT: dựng máy mới từ AMI sạch, KHÔNG "dọn dẹp"
       máy cũ rồi dùng lại

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

• B (tạo security group mới để chặn lưu lượng rồi gắn vào instance) — đây là phương án gần nhất và cũng là nhầm lẫn phổ biến nhất về security group: nó không có luật Deny. (Cách dùng SG đúng trong tình huống này là cô lập máy bằng một SG không cho phép gì cả — nhưng như vậy là chặn tất cả, không phải chặn một IP.)

• C (tạo security group chặn IP rồi gắn vào VPC) — sai hai lần: SG không có Deny, và security group không gắn vào VPC mà gắn vào ENI của instance.

• A (dùng VPC Flow Logs kết hợp Athena để chặn lưu lượng) — flow log và Athena chỉ PHÂN TÍCH, hoàn toàn không chặn được gói tin nào. Chúng hữu ích cho bước điều tra, không phải bước ngăn chặn.

Ghi nhớ

⚠ Security Group ↔ Network ACL — bảng phải thuộc: | | Security Group | Network ACL | |---|---|---| | Luật Deny | KHÔNG CÓ | CÓ | | Trạng thái | stateful | stateless | | Phạm vi | ENI / instance | cả subnet | | Thứ tự xét | xét tất cả, hợp lại | theo số, dừng ở luật khớp đầu | | Chặn một IP cụ thể | không làm được | LÀM ĐƯỢC |

Từ khoá nhận diện:

"CHẶN một địa chỉ IP" → NACL với luật Deny "cho phép truy cập" → security group "cô lập máy bị xâm nhập" → SG không có luật nào "chặn ở quy mô lớn, nhiều VPC" → AWS Network Firewall "chặn theo TÊN MIỀN" → Route 53 Resolver DNS Firewall hoặc Network Firewall

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật đã chặn chưa | VPC Flow Logs — luồng tới IP đó phải thành REJECT | | Còn máy nào gọi ra IP đó không | Logs Insights, lọc dstAddr | | Máy đã sạch chưa | giả định là chưa — thay bằng máy mới |

Và một nhắc nhở quan trọng về thứ tự ưu tiên khi GuardDuty báo động: chặn IP đích là biện pháp cầm máu, không phải cách chữa. Kẻ tấn công đổi địa chỉ đích trong vài phút, còn thứ thực sự cần xử lý là làm sao máy đó bị chiếm và IAM role gắn trên nó đã bị dùng để làm gì — hai câu hỏi mà một luật NACL không trả lời được.

Đáp án

C — Tạo một SERVICE CONTROL POLICY trong AWS Organizations và áp lên tài khoản mới.

Vì sao đúng

Đề có một ràng buộc mà chỉ SCP thoả được: lập trình viên có toàn quyền quản trị, KỂ CẢ quyền tạo IAM policy và role, nhưng vẫn phải bị chặn khỏi vài dịch vụ.

⚠ Điểm mấu chốt — ai tạo được IAM policy thì tự gỡ được mọi giới hạn IAM:

Chặn bằng IAM policy
        ↓
    Lập trình viên có quyền iam:CreatePolicy,
    iam:AttachUserPolicy, iam:CreateRole…
        ↓
    → họ TỰ TẠO một policy mới cho chính mình
    → hoặc tạo một role rồi assume vào
        ↓
    → mọi giới hạn IAM đều VÔ HIỆU
        ↓
Chặn bằng SCP
        ↓
    SCP là TRẦN quyền của CẢ TÀI KHOẢN
        ↓
    → không IAM policy nào vượt qua được
    → kể cả người dùng có AdministratorAccess
    → kể cả role mới tạo

⚠ Cách viết SCP cho yêu cầu này:

{
  "Effect": "Deny",
  "Action": [
    "sagemaker:*",
    "redshift:*",
    "emr:*"
  ],
  "Resource": "*"
}

Deny đơn giản, không cần Condition
        ↓
    → mọi lời gọi tới các dịch vụ đó bị chặn
      ở tầng trên IAM

⚠ Và mô hình quyền hiệu lực:

Quyền THỰC SỰ  =  SCP  ∩  IAM policy
        ↓
    SCP cho phép + IAM cho phép  → ĐƯỢC
    SCP cho phép + IAM cấm       → bị cấm
    SCP CẤM      + IAM cho phép  → BỊ CẤM  ← trường hợp này
    SCP cấm      + IAM cấm       → bị cấm
        ↓
    → SCP luôn thắng khi nó nói Deny

Xem thêm câu #11865 (lô 128) và #11878 (cùng lô): cùng chủ đề SCP. #11878 bổ sung chi tiết về chiều của toán tử điều kiện khi viết Deny.

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

• A (tạo IAM group cho lập trình viên và áp policy giới hạn dịch vụ) — đây là phương án gần nhất và có vẻ hợp lý, nhưng lập trình viên có quyền tạo và gắn IAM policy, nên họ chỉ cần tự rời khỏi group hoặc gắn thêm một policy khác là xong.

• B (tạo job-specific policy trong IAM và áp cho mọi người dùng) — cùng lỗ hổng như A: IAM policy không tự bảo vệ được trước người có quyền quản trị IAM.

• D (tạo customer managed policy trong IAM và áp cho mọi người dùng) — cũng vậy: gỡ ra hoặc ghi đè bằng một policy khác đều nằm trong tầm tay họ.

Ghi nhớ

⚠ Vì sao SCP mạnh hơn IAM policy — bảng phải thuộc: | | SCP | IAM policy | |---|---|---| | Phạm vi | cả TÀI KHOẢN hoặc OU | một danh tính | | Ai gỡ được | chỉ tài khoản QUẢN LÝ của tổ chức | bất kỳ ai có quyền IAM | | Áp cho root user của tài khoản | CÓ | không | | Cấp quyền | KHÔNG — chỉ giới hạn | có | | Không áp cho | tài khoản quản lý | — |

Từ khoá nhận diện:

"admin nhưng vẫn phải bị chặn vài dịch vụ" → SCP "ngăn cả người có quyền quản trị" → SCP "giới hạn trong một tài khoản, người dùng không có quyền IAM" → IAM policy đủ dùng "giới hạn quyền tối đa của một role khi được assume" → permissions boundary "chỉ được dùng hạ tầng đã duyệt" → Service Catalog (bổ trợ, không thay SCP)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SCP thực tế đang áp | describe-effective-policy cho tài khoản đó | | Có chặn đúng không | đăng nhập tài khoản rồi thử gọi dịch vụ bị cấm | | Vì sao một lời gọi bị chặn | CloudTrail — đọc trường errorMessage |

Và một cặp công cụ nên dùng cùng nhau cho đúng tình huống này: SCP để chặn dịch vụ, permissions boundary để chặn leo thang quyền. SCP giải quyết vế "không được dùng dịch vụ X", nhưng vế còn lại — lập trình viên có quyền tạo role và có thể tự cấp cho mình những quyền mà tổ chức chưa lường trước — chỉ được đóng lại khi mọi role họ tạo đều bắt buộc mang một boundary.

Đáp án

C — Dùng LIFECYCLE HOOK của EC2 Auto Scaling để tạm dừng quá trình kết thúc máy sau khi máy đã được rút khỏi dịch vụ.

Vì sao đúng

Đề cần phân tích máy KHÔNG khoẻ TRƯỚC khi nó bị huỷ, và lifecycle hook sinh ra chính xác cho việc đó.

⚠ Điểm mấu chốt — hook giữ máy lại ở một trạng thái chờ:

ASG quyết định kết thúc một máy
        ↓
    Máy chuyển sang Terminating
        ↓
    LIFECYCLE HOOK chặn lại
        ↓
    Trạng thái: Terminating:Wait
        ↓
    → máy VẪN CHẠY, VẪN SSH/Session Manager vào được
    → đã bị rút khỏi target group của ALB
      nên không phục vụ ai
        ↓
    Giữ tối đa 1 giờ (mặc định)
    Kéo dài được tới 48 giờ
        ↓
    Xong việc: complete-lifecycle-action
    → máy mới thực sự bị huỷ

⚠ Hai loại hook:

autoscaling:EC2_INSTANCE_LAUNCHING
        ↓
    Giữ máy ở Pending:Wait khi KHỞI CHẠY
    → cài đặt, tải cấu hình, đăng ký dịch vụ
      trước khi nhận lưu lượng

autoscaling:EC2_INSTANCE_TERMINATING   ← đề này
        ↓
    Giữ máy ở Terminating:Wait khi KẾT THÚC
    → thu thập log, chụp bộ nhớ, gỡ đăng ký

⚠ Tự động hoá việc thu thập bằng chứng:

Hook phát sự kiện vào EventBridge
        ↓
    Lambda hoặc SSM Automation nhận sự kiện
        ↓
    Chạy trên máy đang chờ:
      - đẩy log lên S3
      - chụp snapshot EBS
      - lấy thread dump / heap dump
        ↓
    Rồi gọi complete-lifecycle-action
        ↓
    → không bao giờ mất bằng chứng
    → và không giữ máy quá lâu một cách vô ích

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

• B (dùng CloudWatch Events bắt lifecycle event rồi gọi Lambda) — đây là phương án gần nhất và là một phần của giải pháp đầy đủ, nhưng nếu không có lifecycle hook thì không có gì giữ máy lại: máy đã bị huỷ trước khi Lambda kịp làm gì. Hook mới là thứ tạo ra khoảng thời gian đó.

• A (Lambda chụp snapshot trước khi máy bị kết thúc) — vẫn là bài toán chạy đua với thời gian: không có cơ chế nào bảo đảm Lambda kịp chạy xong trước khi ASG huỷ máy. (Và snapshot ổ đĩa cũng không giữ được trạng thái bộ nhớ hay tiến trình.)

• D (chỉ dùng ALB health check để máy bị rút khỏi dịch vụ mà không bị huỷ) — hiểu sai cách ASG hoạt động: ASG luôn kết thúc máy mà nó coi là không khoẻ, bất kể nguồn health check là EC2 hay ELB.

Ghi nhớ

⚠ Vòng đời instance trong ASG — bảng phải thuộc: | Trạng thái | Nghĩa | |---|---| | Pending | đang khởi chạy | | Pending:Wait | hook khi KHỞI CHẠY đang giữ | | InService | đang phục vụ | | Terminating | đang bị kết thúc | | Terminating:Wait | hook khi KẾT THÚC đang giữ — vào được máy | | Terminated | đã huỷ | | Standby | rút khỏi dịch vụ THỦ CÔNG, không bị huỷ |

Từ khoá nhận diện:

"phân tích máy trước khi bị huỷ" → lifecycle hook TERMINATING "cài đặt xong mới nhận lưu lượng" → lifecycle hook LAUNCHING, hoặc cfn-signal "tạm gỡ một máy ra để sửa, không muốn nó bị thay" → Standby "giữ log khi máy bị thay" → CloudWatch agent đẩy log liên tục "máy bị thay liên tục" → xem lại health check và grace period

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy đang ở trạng thái nào | describe-auto-scaling-instances — tìm Terminating:Wait | | Vì sao bị kết thúc | tab Activity của ASG — ghi rõ lý do | | Hook có bị hết giờ không | sự kiện EventBridge, và trạng thái sau khi hết HeartbeatTimeout |

Và một lời khuyên về HeartbeatTimeout: đừng đặt 48 giờ chỉ vì đặt được. Một máy nằm ở Terminating:Wait vẫn được tính tiền và vẫn chiếm một chỗ trong MaxSize của ASG — nên nếu quy trình phân tích tự động của bạn xong trong năm phút, hãy đặt timeout ngắn và gọi complete-lifecycle-action ngay, dành thời gian dài chỉ cho những lần thực sự cần người vào xem tận nơi.