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

Đáp án

D — Co giãn dựa trên chỉ số số lượng kết nối (connection count) của Load Balancer.

Vì sao đúng

Đề nêu rõ muốn co giãn theo số người dùng, và load balancer đã cấp sẵn một đại lượng gần đúng rất tốt cho điều đó.

⚠ Điểm mấu chốt — số kết nối là thước đo có sẵn, không cần dựng thêm gì:

ALB → chỉ số ActiveConnectionCount, NewConnectionCount,
      RequestCountPerTarget
        ↓
    Tất cả có SẴN, không cần agent, không cần script
        ↓
    Target Tracking Scaling Policy dùng thẳng
        ↓
    → ASG tự giữ số kết nối mỗi máy quanh một mức mục tiêu

Chính sách co giãn tương ứng:

{
  "TargetValue": 1000,
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "ALBRequestCountPerTarget",
    "ResourceLabel": "app/ten-alb/xxxx/targetgroup/ten-tg/yyyy"
  }
}

⚠ Vì sao đây là lựa chọn đúng cho một ứng dụng NGỐN BỘ NHỚ:

Ứng dụng ledger tốn RAM theo SỐ NGƯỜI DÙNG
        ↓
    CPU có thể vẫn thấp trong khi RAM sắp cạn
        ↓
    → co giãn theo CPU sẽ phản ứng QUÁ MUỘN
        ↓
    Co giãn theo số kết nối = co giãn theo nguyên nhân gốc
        ↓
    → thêm máy TRƯỚC khi RAM chạm trần

Nói cách khác: đo nguyên nhân (người dùng) tốt hơn đo hậu quả (RAM cạn).

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

• A (đẩy mức dùng RAM lên làm chỉ số tuỳ chỉnh cho Load Balancer) — đây là phương án gần nhất và ý tưởng theo dõi RAM là hợp lý, nhưng cách diễn đạt sai chỗ then chốt: RAM là chỉ số của INSTANCE, không phải của load balancer. Load balancer không có bộ nhớ nào để đo. (Đo RAM của instance qua CloudWatch agent rồi co giãn theo nó là một cách hợp lệ — nhưng phức tạp hơn và phản ứng muộn hơn.)

• C (dùng thẳng chỉ số RAM của Load Balancer) — cùng lỗi và còn nặng hơn: không tồn tại chỉ số RAM nào cho load balancer.

• B (triển khai script trên Load Balancer để đếm người dùng) — không thể: ALB là dịch vụ được quản lý, bạn không có quyền truy cập vào máy chủ nào của nó, không cài được gì lên đó.

Ghi nhớ

⚠ Chỉ số có sẵn của ALB dùng để co giãn — bảng phải thuộc: | Chỉ số | Nội dung | |---|---| | RequestCountPerTarget | số request mỗi target — hay dùng nhất | | ActiveConnectionCount | số kết nối TCP đang mở | | NewConnectionCount | số kết nối mới | | TargetResponseTime | độ trễ của ứng dụng | | HealthyHostCount | số target khoẻ | | HTTPCode_Target_5XX_Count | lỗi phía ứng dụng |

Từ khoá nhận diện:

"co giãn theo số người dùng" → RequestCountPerTarget hoặc connection count "chỉ số RAM của load balancer" → KHÔNG TỒN TẠI "cài script lên ALB" → KHÔNG THỂ, dịch vụ được quản lý "co giãn theo RAM của instance" → CloudWatch agent + chỉ số tuỳ chỉnh "co giãn theo độ dài hàng đợi" → chỉ số SQS ApproximateNumberOfMessagesVisible

⚠ Bốn kiểu chính sách co giãn — bảng phải thuộc: | Kiểu | Cách hoạt động | |---|---| | Target Tracking | giữ một chỉ số quanh giá trị mục tiêu — đơn giản nhất, nên ưu tiên | | Step Scaling | thêm/bớt N máy theo từng bậc vượt ngưỡng | | Simple Scaling | một hành động rồi chờ cooldown — cách cũ | | Scheduled Scaling | theo lịch, cho tải biết trước | | Predictive Scaling | học máy dự đoán trước, co giãn sớm |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách có đang chạy không | lịch sử hoạt động của ASG | | Có co giãn dao động không | xem có scale out rồi scale in liên tục — chỉnh cooldown | | Chỉ số có phản ánh đúng tải không | vẽ chồng biểu đồ số request và RAM |

Và một lời khuyên về thiết kế chính sách co giãn: hãy co giãn theo chỉ số dẫn dắt, đừng co giãn theo chỉ số hậu quả. Số người dùng tăng trước, RAM cạn sau, ứng dụng chết sau nữa — chọn đúng điểm đầu chuỗi nghĩa là máy mới đã sẵn sàng phục vụ vào lúc mà nếu chọn điểm cuối chuỗi thì bạn mới chỉ vừa bắt đầu khởi chạy nó.

Đáp án

C — Bật EC2 detailed monitoring (giám sát chi tiết).

Vì sao đúng

Đề cần chỉ số CÓ SẴN của EC2 ở độ phân giải 1 phút — và đó chính xác là định nghĩa của detailed monitoring.

⚠ Điểm mấu chốt — hai mức giám sát của EC2:

Basic monitoring (mặc định)
        ↓
    5 PHÚT một điểm dữ liệu, MIỄN PHÍ
        ↓
    → alarm phản ứng chậm: phải chờ tới 5 phút mới biết

Detailed monitoring
        ↓
    1 PHÚT một điểm dữ liệu, có phí
        ↓
    → alarm phản ứng nhanh gấp 5 lần
    → bật bằng MỘT công tắc, không cần cài gì

Bật rất đơn giản:

aws ec2 monitor-instances --instance-ids i-xxxxxxxx

Hoặc đặt sẵn trong launch template để mọi máy mới đều có.

⚠ Vì sao 1 phút lại quan trọng với alarm — không chỉ là con số:

Alarm cần 3 chu kỳ liên tiếp để kích hoạt
        ↓
    Basic (5 phút)    → 15 phút mới báo
    Detailed (1 phút) →  3 phút đã báo
        ↓
    → với một game đang tăng tải đột ngột,
      12 phút chênh lệch là rất nhiều người dùng

⚠ Và một hệ quả kèm theo, ít người biết:

Auto Scaling cũng đọc chính những chỉ số này
        ↓
    → detailed monitoring làm ASG phản ứng nhanh hơn
    → co giãn kịp hơn, không chỉ cảnh báo kịp hơn

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

• B (đội phát triển tự tạo và gửi chỉ số tuỳ chỉnh độ phân giải cao) — đây là phương án gần nhất và kỹ thuật thì làm được (high-resolution custom metric xuống tới 1 giây). Nhưng đề nói cần "các chỉ số liên quan" của EC2 — CPU, mạng, đĩa — những thứ AWS đã cấp sẵn. Tự viết mã đẩy lại chúng là công sức thừa, tốn tiền PutMetricData, và thêm một chỗ có thể hỏng. Đề hỏi cách tối ưu nhất.

• A (dùng Lambda gọi đường dẫn /health thường xuyên) — đây là kiểm tra sức khoẻ ứng dụng, không phải thu thập chỉ số hệ thống. Nó cũng tự dựng lại thứ mà health check của ELB đã làm sẵn.

• D (dùng Systems Manager) — Systems Manager quản lý cấu hình, vá lỗi, chạy lệnh. Nó không phải công cụ giám sát chỉ số.

Ghi nhớ

⚠ Ba mức độ phân giải chỉ số — bảng phải thuộc: | Mức | Chu kỳ | Ghi chú | |---|---|---| | Basic monitoring | 5 phút | mặc định, miễn phí | | Detailed monitoring | 1 phút | có phí, một công tắc | | High-resolution custom metric | tới 1 giây | tự đẩy bằng PutMetricData |

Từ khoá nhận diện:

"chỉ số EC2 mỗi 1 phút" → detailed monitoring "nhanh hơn 1 phút" → high-resolution custom metric "RAM, dung lượng đĩa" → CloudWatch agent (không phải detailed monitoring) "log của ứng dụng" → CloudWatch agent "chỉ số 1 giây cho alarm" → high-resolution alarm (10 hoặc 30 giây)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã bật chưa | describe-instances, xem Monitoring.State: enabled | | Có dữ liệu 1 phút chưa | truy vấn với --period 60, xem có điểm liên tục không | | Alarm nhanh hơn chưa | so describe-alarm-history trước và sau khi bật |

Và một lời khuyên khi cân nhắc chi phí: detailed monitoring tính tiền theo từng instance, nên hãy bật cho những máy mà tốc độ phản ứng thật sự quan trọng, chứ đừng bật cho toàn bộ fleet theo phản xạ. Với một fleet vài trăm máy chạy công việc nền, khác biệt giữa 1 phút và 5 phút chẳng thay đổi điều gì — nhưng khoản phí thì nhân lên đúng số máy, mỗi tháng, mãi mãi.

Đáp án

A, C — hai cách cải thiện khả năng đọc:

• C — Dựng Read Replica.
• A — Dựng cụm ElastiCache.

Vì sao đúng

Đề mô tả một phân bố rất đặc trưng: 10% sản phẩm chiếm 90% lưu lượng — và mỗi giải pháp giải quyết một mặt của vấn đề đó.

⚠ ElastiCache — nhắm thẳng vào 90% lưu lượng tập trung:

10% mặt hàng "hot" được hỏi đi hỏi lại
        ↓
    Cache chúng trong bộ nhớ (Redis / Memcached)
        ↓
    → phần lớn request KHÔNG chạm tới cơ sở dữ liệu
    → độ trễ từ mili giây xuống dưới mili giây
        ↓
    → đây là giải pháp hiệu quả nhất cho đúng phân bố này

⚠ Read Replica — chia đều phần còn lại:

RDS tạo bản sao chỉ đọc (bất đồng bộ)
        ↓
    Ứng dụng gửi truy vấn đọc sang replica
        ↓
    → instance chính chỉ còn lo việc ghi
    → thêm được tối đa 5 replica (15 với Aurora)

⚠ Hai thứ này BỔ SUNG cho nhau, không thay thế nhau:

Request tới
        ↓
    Có trong cache? → trả về ngay (90% trường hợp)
        ↓ không
    Đọc từ read replica
        ↓
    Ghi vào cache cho lần sau
        ↓
    → cơ sở dữ liệu chính gần như chỉ còn phục vụ ghi

Với ElastiCache, hai mẫu thiết kế cần nhớ:

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

• D (dựng RDS Multi-AZ) — đây là phương án gần nhất và là nhầm lẫn kinh điển nhất về RDS. Multi-AZ là để SẴN SÀNG CAO, không phải để chia tải: bản standby KHÔNG phục vụ đọc, nó chỉ nằm chờ failover.

• E (dựng cụm DAX) — DAX chỉ dùng được với DynamoDB, còn đề nói rõ là RDS. Đây là bẫy tên gọi: DAX nghe như một loại cache tổng quát, nhưng nó là cache chuyên dụng gắn chặt với DynamoDB.

• B (đặt API Gateway có bật cache trước cơ sở dữ liệu) — API Gateway không đứng trước cơ sở dữ liệu được; nó đứng trước API. Cache của nó cũng là cache phản hồi HTTP, không phải cache truy vấn.

Ghi nhớ

⚠ Multi-AZ và Read Replica — bảng phải thuộc, đây là câu hỏi kinh điển: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | sẵn sàng cao | chia tải đọc | | Sao chép | đồng bộ | bất đồng bộ | | Phục vụ đọc | KHÔNG | CÓ | | Failover | tự động | phải promote thủ công | | Vị trí | AZ khác | cùng AZ, khác AZ, hoặc khác Region | | Số lượng | 1 standby | tối đa 5 (Aurora: 15) |

Từ khoá nhận diện:

"cải thiện hiệu năng ĐỌC" → Read Replica + ElastiCache "sẵn sàng cao, chịu lỗi" → Multi-AZ "một số ít mục chiếm phần lớn lưu lượng" → ElastiCache "cache cho DynamoDB" → DAX "quá nhiều kết nối tới RDS" → RDS Proxy "đọc ở Region khác" → cross-Region read replica / Aurora Global

⚠ Redis và Memcached — chọn cái nào: | | Redis | Memcached | |---|---|---| | Kiểu dữ liệu | phong phú (list, set, sorted set, stream) | chỉ chuỗi | | Bền vững | có (snapshot, AOF) | không | | Sao chép, failover | có | không | | Đa luồng | ít hơn | có, mở rộng theo lõi tốt | | Chọn khi | cần bảng xếp hạng, phiên, pub/sub, độ bền | cache đơn giản, muốn nhiều lõi |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỷ lệ trúng cache | chỉ số CacheHitRate — dưới 80% thì xem lại chiến lược | | Replica trễ bao nhiêu | ReplicaLag (RDS) / AuroraReplicaLag | | DB chính đã nhẹ chưa | so ReadIOPS và DatabaseConnections trước và sau |

Và một lời khuyên về thứ tự triển khai: hãy làm ElastiCache trước, read replica sau. Với phân bố 90/10 như đề mô tả, cache thường gánh phần lớn tải chỉ sau vài giờ triển khai và rẻ hơn nhiều so với việc chạy thêm mấy bản sao cơ sở dữ liệu; sau đó bạn mới đo lại xem phần tải còn sót có thật sự cần replica hay không — và rất thường xuyên, câu trả lời là không.

Đáp án

C — Dùng Snowball Edge.

Vì sao đúng

Đề dựng lên đúng kịch bản mà Snowball Edge sinh ra để giải, với ba ràng buộc cùng lúc:

⚠ Điểm mấu chốt thứ nhất — vì sao không truyền qua mạng:

5 PB qua đường 1 Gbps chạy hết công suất
        ↓
    ≈ hơn 460 NGÀY
        ↓
    Mà đề nói băng thông vốn đã thiếu
        ↓
    → phải chuyển bằng THIẾT BỊ VẬT LÝ

⚠ Điểm mấu chốt thứ hai — Snowball Edge không chỉ là ổ cứng:

Snowball Edge Compute Optimized
        ↓
    Có vCPU, RAM, và chạy được EC2 instance NGAY TRÊN THIẾT BỊ
        ↓
    → chạy quy trình làm sạch dữ liệu NGAY TẠI TRUNG TÂM DỮ LIỆU
    → chỉ chuyển lên đám mây phần dữ liệu ĐÃ SẠCH
        ↓
    → khớp chính xác yêu cầu "làm sạch bằng quy trình riêng trên EC2"

Luồng hoàn chỉnh:

Snowball Edge tới trung tâm dữ liệu
        ↓
    Chép dữ liệu vào (còn chạy được Lambda và EC2 tại chỗ)
        ↓
    Gửi thiết bị về AWS
        ↓
    Dữ liệu nhập vào S3
        ↓
    Athena truy vấn trực tiếp, hoặc nạp vào Redshift

Với 5 PB thì cần vài chục thiết bị chạy song song, và AWS gửi chúng cùng lúc — vài tuần thay vì hơn một năm.

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

• A (Volume Gateway) — đây là phương án gần nhất vì cũng liên quan tới việc đưa dữ liệu tại chỗ lên AWS. Nhưng Storage Gateway là cầu nối LÂU DÀI qua đường mạng, nên nó vấp đúng vào giới hạn băng thông mà đề nêu ra. Nó cũng không có năng lực tính toán để chạy quy trình làm sạch.

• D (S3 Transfer Acceleration) — tăng tốc truyền qua mạng lưới edge của CloudFront, giúp ích khi bạn ở xa Region. Nhưng nó vẫn là truyền qua internet, không phá được trần băng thông cho 5 PB.

• B ("AWS Data Migration") — tên gọi mơ hồ. Dịch vụ thật là AWS DMS (Database Migration Service), và nó dùng để di chuyển CƠ SỞ DỮ LIỆU, không phải hàng petabyte tệp thô. Nó cũng chạy qua đường mạng.

Xem thêm câu #11584: cũng 5 PB dữ liệu tại chỗ và cũng dùng Snowball, nhưng mục đích là lưu trữ dài hạn — khi đó phải nhớ thêm rằng Snowball chỉ nhập được vào S3, muốn sang Glacier phải dùng lifecycle policy.

Ghi nhớ

⚠ Họ AWS Snow — bảng phải thuộc: | Thiết bị | Dung lượng | Đặc điểm | |---|---|---| | Snowcone | 8–14 TB | nhỏ nhất, chạy pin được, mang ra hiện trường | | Snowball Edge Storage Optimized | ~80 TB dùng được | cho di chuyển dữ liệu lớn | | Snowball Edge Compute Optimized | ít dung lượng hơn | có GPU, chạy EC2 và Lambda tại chỗ | | Snowmobile | tới 100 PB | xe container 45 foot |

Từ khoá nhận diện:

"hàng PB, băng thông không đủ" → Snowball Edge "cần xử lý dữ liệu ngay tại chỗ" → Snowball Edge Compute Optimized "trên 10 PB, một lần" → cân nhắc Snowmobile "đồng bộ định kỳ qua mạng" → DataSync "cầu nối lâu dài cho ứng dụng tại chỗ" → Storage Gateway "di chuyển cơ sở dữ liệu" → DMS (+ SCT nếu đổi công cụ)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần bao nhiêu thiết bị | tổng dung lượng ÷ ~80 TB, cộng dự phòng | | Chép xong chưa | OpsHub hiển thị tiến độ | | Nhập vào S3 xong chưa | trạng thái job trong Snow Family console |

Và một lưu ý về lập kế hoạch mà nhiều đội bỏ qua: thời gian chép dữ liệu VÀO thiết bị thường lâu hơn thời gian vận chuyển. Một Snowball Edge nhận dữ liệu qua mạng nội bộ 10 Gbps vẫn cần khoảng một ngày để chép đầy 80 TB, nên với 5 PB thì lịch trình thật phụ thuộc vào việc bạn chép được bao nhiêu thiết bị song song — chứ không phải vào việc AWS giao hàng nhanh đến đâu.

Đáp án

A, C — hai lý do khiến ASG không scale out dù CPU ở 90%:

• C — ASG đã ở mức dung lượng TỐI ĐA.
• A — Tiến trình Launch của ASG đang bị TẠM NGỪNG (suspended).

Vì sao đúng

⚠ Lý do C — đơn giản nhưng là nguyên nhân phổ biến nhất:

MaxSize = 10, DesiredCapacity đã bằng 10
        ↓
    Chính sách vẫn báo "cần thêm máy"
        ↓
    → ASG KHÔNG THỂ vượt MaxSize
        ↓
    → không có hành động nào diễn ra
    → và cũng KHÔNG có lỗi nào nổi lên, chỉ một dòng
      lặng lẽ trong Activity history

⚠ Lý do A — tiến trình bị tạm ngừng, thường là dấu vết của một lần gỡ lỗi:

Ai đó chạy suspend-processes --scaling-processes Launch
        ↓
    Có thể để bảo trì, để điều tra sự cố
        ↓
    → quên bật lại
        ↓
    → chính sách vẫn kích hoạt, alarm vẫn kêu,
      nhưng ASG KHÔNG khởi chạy máy nào

Kiểm tra và khôi phục:

aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names ten-asg \
  --query 'AutoScalingGroups[0].{Max:MaxSize,Desired:DesiredCapacity,
           Tam_ngung:SuspendedProcesses}'

aws autoscaling resume-processes --auto-scaling-group-name ten-asg

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

• D (thời gian warm-up của instance chưa trôi qua) — đây là phương án gần nhất và warm-up là một cơ chế có thật khiến ASG tạm hoãn hành động tiếp theo. Nhưng nó tính bằng vài phút, còn đề nói tình trạng kéo dài hơn 3 tiếng. Không có cấu hình warm-up nào dài như vậy.

• B (AWS hết dung lượng cho loại instance yêu cầu) — nếu vậy thì ASG VẪN THỬ khởi chạy và ghi lỗi InsufficientInstanceCapacity vào Activity history. Đề mô tả là không có hành động nào diễn ra, tức là ASG còn chưa thử.

• E (tiến trình AZRebalance bị tạm ngừng) — AZRebalance chỉ lo cân bằng số máy giữa các AZ. Tạm ngừng nó không ngăn việc scale out.

Ghi nhớ

⚠ Các tiến trình của Auto Scaling tạm ngừng được — bảng phải thuộc: | Tiến trình | Việc | |---|---| | Launch | khởi chạy instance mới — tạm ngừng là không scale out được | | Terminate | chấm dứt instance — tạm ngừng là không scale in được | | HealthCheck | đánh dấu instance hỏng | | ReplaceUnhealthy | thay máy hỏng | | AZRebalance | cân bằng giữa các AZ | | AlarmNotification | nhận cảnh báo từ CloudWatch | | ScheduledActions | thực thi hành động theo lịch | | AddToLoadBalancer | đăng ký máy mới vào ELB |

Từ khoá nhận diện:

"ASG không thêm máy dù CPU cao" → MaxSize, hoặc tiến trình bị tạm ngừng "máy mới không nhận lưu lượng" → AddToLoadBalancer bị tạm ngừng "máy hỏng không được thay" → ReplaceUnhealthy bị tạm ngừng "vừa scale out xong lại scale in" → cooldown quá ngắn, hoặc hai chính sách đánh nhau "máy mới bị giết ngay khi vừa lên" → health check grace period quá ngắn

⚠ Bốn nguyên nhân ASG không scale out — kiểm tra theo thứ tự này: | Thứ tự | Kiểm tra | |---|---| | 1 | MaxSize đã chạm trần chưa | | 2 | SuspendedProcesses có gì không | | 3 | Hạn mức vCPU của tài khoản (VcpuLimitExceeded trong Activity history) | | 4 | Alarm có thật sự ở trạng thái ALARM không |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trần hiện tại | describe-auto-scaling-groups, xem MaxSize | | Có tiến trình nào bị ngừng | trường SuspendedProcesses | | Vì sao khởi chạy thất bại | describe-scaling-activities — đọc StatusMessage |

Và một thói quen đáng xây dựng: hãy đặt cảnh báo cho tình huống DesiredCapacity == MaxSize. Chạm trần là trạng thái nguy hiểm nhưng hoàn toàn im lặng — hệ thống vẫn "hoạt động", biểu đồ vẫn có dữ liệu, không có lỗi nào ở đâu, chỉ là mỗi người dùng mới đến đều được phục vụ chậm hơn người trước một chút, cho tới lúc mọi thứ đổ sập cùng lúc.

Đáp án

C — Tạo MỘT CloudWatch dashboard, thêm mỗi Region một biểu đồ bằng cách dùng bộ chọn Region ở góc trên bên phải của console khi thêm widget.

Vì sao đúng

Điểm quan trọng nhất của câu này: CloudWatch dashboard là tài nguyên GLOBAL, dù chỉ số thì thuộc từng Region.

⚠ Điểm mấu chốt — một dashboard xem được chỉ số của mọi Region:

Chỉ số CloudWatch: thuộc về từng Region riêng biệt
        ↓
    Dashboard: là tài nguyên GLOBAL
        ↓
    Mỗi WIDGET trong dashboard khai riêng Region của nó
        ↓
    → một dashboard duy nhất hiện chỉ số của
      Singapore, Frankfurt, Virginia... cùng lúc

Cách làm trên console:

Tạo dashboard
        ↓
    Add widget → chọn chỉ số
        ↓
    ĐỔI REGION ở bộ chọn góc trên bên phải
        ↓
    Chọn chỉ số của Region đó → thêm widget
        ↓
    Lặp lại cho từng Region
        ↓
    → mỗi widget nhớ đúng Region của nó

Trong định nghĩa JSON của dashboard, mỗi widget mang trường region riêng:

{
  "type": "metric",
  "properties": {
    "region": "eu-central-1",
    "metrics": [["AWS/ApplicationELB", "ActiveConnectionCount",
                 "LoadBalancer", "app/web-eu/xxxx"]],
    "title": "Người dùng — Frankfurt"
  }
}

⚠ Vì sao "một dashboard" tốt hơn "mỗi Region một dashboard":

Một màn hình duy nhất
        ↓
    → so sánh các Region cạnh nhau, thấy ngay bất thường
    → một link duy nhất cho cả đội trực
        ↓
Nhiều dashboard rời rạc
        ↓
    → phải chuyển qua lại, dễ bỏ sót Region đang có sự cố

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

• D (tạo mỗi Region một dashboard) — đây là phương án gần nhất và về kỹ thuật thì làm được. Nhưng nó đi ngược mục đích của đề: cần một cái nhìn tổng thể toàn cầu, mà chia nhỏ ra thì mất đúng khả năng so sánh đó. Nó cũng bỏ qua sự thật rằng dashboard vốn đã là tài nguyên global.

• A (thêm widget loại "multi-region graph") — không có loại widget nào tên như vậy. Việc chọn Region nằm ở từng widget chứ không phải một loại widget riêng.

• B (tick tuỳ chọn "global metric" rồi dùng dropdown Region để đổi) — không có tuỳ chọn "global metric" nào. Ngoài ra "đổi biểu đồ theo yêu cầu" lại quay về đúng vấn đề: không xem được nhiều Region cùng lúc.

Ghi nhớ

⚠ Cái gì global, cái gì theo Region trong CloudWatch — bảng phải thuộc: | Thành phần | Phạm vi | |---|---| | Dashboard | GLOBAL — widget khai Region riêng | | Metric | theo Region | | Alarm | theo Region | | Log group | theo Region | | Composite alarm | theo Region — không gộp chéo Region được |

Từ khoá nhận diện:

"một màn hình cho nhiều Region" → một dashboard, mỗi widget một Region "widget multi-region" → KHÔNG TỒN TẠI "gom chỉ số nhiều Region thành một số" → Metric Math không làm chéo Region; phải tự đẩy chỉ số về một nơi "gom log nhiều tài khoản/Region" → cross-account observability "chỉ số của CloudFront, Route 53, Billing" → luôn ở us-east-1

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Widget đang trỏ Region nào | mở View/edit source của dashboard, xem trường region | | Có chỉ số nào ở Region đó không | đổi Region rồi list-metrics | | Dashboard có chia sẻ được không | có shared dashboard cho người ngoài tài khoản |

Và một mẹo đáng giá cho đội trực: hãy thêm một widget kiểu Text ở đầu mỗi dashboard, chứa link tới runbook và tên người trực. Dashboard tồn tại để được xem vào lúc hai giờ sáng bởi người có thể chưa từng thấy hệ thống này; vài dòng Markdown chỉ ra "biểu đồ này bất thường thì làm gì" có giá trị hơn hẳn một widget đẹp thứ mười.

Đáp án

C — Dùng thiết lập "Default Encryption" của Amazon S3.

Vì sao đúng

Đề hỏi cách ép mã hoá cho MỌI tệp tải lên bucket — tức là mã hoá khi lưu (at rest).

⚠ Điểm mấu chốt — Default Encryption mã hoá mọi đối tượng mới, kể cả khi client không yêu cầu:

Bật Default Encryption trên bucket
        ↓
    Mọi PutObject từ nay
        ↓
    → S3 tự mã hoá, dù client KHÔNG gửi header mã hoá nào
        ↓
    → không phải sửa một dòng mã ứng dụng nào
    → không có đường nào lọt qua

Ba lựa chọn khoá:

⚠ Một chi tiết cập nhật đáng biết:

Từ tháng 1/2023, AWS bật SSE-S3 mặc định cho MỌI bucket mới
        ↓
    → hành vi này giờ là mặc định, không còn phải nhớ bật
        ↓
    Nhưng vẫn nên khai tường minh khi cần SSE-KMS,
    và vẫn nên có bucket policy chặn nếu yêu cầu tuân thủ
      đòi một loại khoá cụ thể

⚠ Muốn chặt hơn nữa — thêm bucket policy từ chối tệp không mã hoá đúng cách:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::bucketname/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "aws:kms"
    }
  }
}

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

• A (bucket policy Deny khi aws:SecureTransport là false) — đây là phương án gần nhất và là một chính sách RẤT TỐT, nên có ở mọi bucket. Nhưng nó ép mã hoá KHI TRUYỀN (bắt buộc HTTPS), không phải mã hoá KHI LƯU. Đề hỏi về tệp đã tải lên, tức là vế thứ hai. Đây chính là bẫy trung tâm của câu hỏi.

• D (Deny khi aws:SecureTransport là true) — cùng nhầm lẫn với A, và còn ngược logic: chính sách này chặn đúng những kết nối HTTPS an toàn và chỉ cho phép HTTP — hoàn toàn phản tác dụng.

• B (đặt một CloudFront distribution "được mã hoá" trước bucket) — CloudFront lo truyền dữ liệu tới người dùng, nó không quyết định cách dữ liệu được lưu trong S3. Ngoài ra người ta vẫn tải tệp lên thẳng S3, không đi qua CloudFront.

Ghi nhớ

⚠ Mã hoá khi truyền và khi lưu — bảng phải thuộc: | | In transit | At rest | |---|---|---| | Ép bằng | aws:SecureTransport: false → Deny | Default Encryption + s3:x-amz-server-side-encryption | | Bảo vệ khỏi | nghe lén trên đường truyền | đọc trộm dữ liệu đã lưu | | Cơ chế | HTTPS/TLS | AES-256, KMS |

Từ khoá nhận diện:

"mọi tệp tải lên phải được mã hoá" → Default Encryption "bắt buộc dùng HTTPS" → aws:SecureTransport: false → Deny "phải dùng đúng khoá KMS này" → s3:x-amz-server-side-encryption-aws-kms-key-id "client tự giữ khoá" → SSE-C (khách gửi khoá theo từng request) "mã hoá trước khi rời máy khách" → client-side encryption

⚠ Các kiểu mã hoá của S3 — bảng phải thuộc: | Kiểu | Ai giữ khoá | Ghi chú | |---|---|---| | SSE-S3 | AWS | mặc định, miễn phí, header AES256 | | SSE-KMS | bạn, qua KMS | kiểm toán được, có hạn mức lời gọi KMS | | DSSE-KMS | bạn | mã hoá hai lớp | | SSE-C | bạn tự giữ hoàn toàn | phải gửi khoá mỗi request, S3 không lưu | | Client-side | bạn | mã hoá trước khi gửi |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket đang mã hoá kiểu gì | get-bucket-encryption | | Một đối tượng cụ thể ra sao | head-object, xem ServerSideEncryption | | Còn tệp cũ chưa mã hoá không | Default Encryption KHÔNG áp cho tệp đã có — dùng S3 Batch Operations để mã hoá lại |

Và một lưu ý mà rất nhiều đội chỉ phát hiện khi kiểm toán: Default Encryption chỉ áp cho đối tượng GHI MỚI, nó không đụng tới hàng triệu tệp đã nằm sẵn trong bucket từ trước. Muốn phủ kín thì phải chạy S3 Batch Operations để copy đè chúng bằng cấu hình mã hoá mới — một việc tốn thời gian và tiền bạc, nhưng là việc duy nhất khiến câu trả lời cho kiểm toán viên trở thành "toàn bộ", chứ không phải "từ tháng sau trở đi".

Đáp án

B — AWS Config.

Vì sao đúng

Đề nêu hai yêu cầu, và AWS Config đáp ứng cả hai bằng một quy tắc dựng sẵn:

⚠ Điểm mấu chốt — Config đánh giá NGAY khi cấu hình thay đổi, không phải theo lịch:

Ai đó thêm luật mở cổng 846 vào một security group
        ↓
    Config nhận sự kiện thay đổi cấu hình
        ↓
    Đánh giá lại quy tắc → NON_COMPLIANT
        ↓
    EventBridge bắt sự kiện → SNS → email/chat cho đội bảo mật
        ↓
    → phát hiện trong vài phút, không phải hôm sau

Cấu hình quy tắc:

{
  "ConfigRuleName": "cam-cong-846",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "RESTRICTED_INCOMING_TRAFFIC"
  },
  "InputParameters": "{\"blockedPort1\": \"846\"}"
}

⚠ Và Config còn làm được bước tiếp theo — TỰ SỬA:

Remediation action (SSM Automation)
        ↓
    AWS-DisablePublicAccessForSecurityGroup
        ↓
    → tự gỡ luật vi phạm ngay sau khi phát hiện
        ↓
    Nên chạy chế độ Manual trước để xem nó định sửa gì

Xem thêm câu #11583: cùng dịch vụ AWS Config nhưng áp cho một chuẩn khác — kiểm tra bucket S3 đã bật logging hay chưa, kèm remediation tự động.

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

• C (AWS GuardDuty) — đây là phương án gần nhất vì đề mở đầu bằng "đội bảo mật phát hiện tấn công", nên GuardDuty nghe rất hợp. Nhưng GuardDuty phát hiện HÀNH VI đáng ngờ (máy đang liên lạc với địa chỉ độc hại, đào tiền ảo, dò quét). Nó không kiểm tra cấu hình security group có tuân thủ chuẩn hay không.

• A (AWS WAF) — WAF lọc lưu lượng HTTP/HTTPS ở tầng ứng dụng cho CloudFront, ALB và API Gateway. Nó không nhìn tới cổng TCP tuỳ ý như 846, và cũng không kiểm tra cấu hình.

• D (AWS Shield) — dịch vụ chống DDoS. Không kiểm tra tuân thủ cấu hình.

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 | |---|---| | AWS Config | "cấu hình có đúng chuẩn không" | | GuardDuty | "có hành vi độc hại nào đang diễn ra không" | | Inspector | "phần mềm có lỗ hổng nào không" | | Security Hub | "tổng hợp mọi phát hiện ở một chỗ" | | WAF | lọc request HTTP độc hại | | Shield | chống DDoS | | Macie | tìm dữ liệu nhạy cảm trong S3 |

Từ khoá nhận diện:

"security group phải luôn đóng cổng X" → AWS Config "phát hiện hành vi bất thường" → GuardDuty "chặn SQL injection, XSS" → WAF "chống tấn công từ chối dịch vụ" → Shield "tìm số thẻ tín dụng trong S3" → Macie "CHẶN HẲN không cho ai mở cổng" → SCP — Config chỉ phát hiện sau khi đã mở

⚠ Điểm yếu quan trọng nhất của AWS Config — phải hiểu để trả lời đúng câu hỏi thiết kế: | Nội dung | |---| | Config là cơ chế PHÁT HIỆN (detective), không phải NGĂN CHẶN (preventive) | | Cổng đã mở ra rồi mới bị phát hiện — có một khoảng thời gian phơi nhiễm | | Muốn chặn từ đầu: SCP, permission boundary, hoặc kiểm tra trong pipeline IaC | | Kiến trúc tốt: SCP chặn + Config phát hiện + remediation tự sửa |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai vi phạm | bảng compliance của quy tắc | | Ai đã mở cổng | CloudTrail sự kiện AuthorizeSecurityGroupIngress | | Trước đây cấu hình ra sao | Config timeline của chính security group đó |

Và một lời khuyên về thiết kế phòng thủ: hãy dùng SCP để chặn hẳn việc mở cổng nguy hiểm, rồi dùng Config như lưới an toàn phía sau. Config chỉ báo cho bạn sau khi cổng đã mở, và trong khoảng vài phút đó thì cổng thật sự đang mở ra internet — với một cổng đang bị tấn công chủ động như tình huống của đề, vài phút là quá đủ để kẻ tấn công tìm thấy nó.

Đáp án

A — S3.

Vì sao đúng

Câu này kiểm tra một điều rất thực dụng: dịch vụ nào cho bật mã hoá TẠI CHỖ, không phải tạo lại tài nguyên.

⚠ Điểm mấu chốt — chỉ S3 làm được, ba dịch vụ kia đều phải dựng lại:

S3   → bật Default Encryption bất cứ lúc nào
       → không gián đoạn, không phải tạo bucket mới

EBS  → mã hoá chỉ đặt được LÚC TẠO volume
       → phải: snapshot → copy CÓ mã hoá → tạo volume mới → gắn lại

RDS  → mã hoá chỉ đặt được LÚC TẠO instance
       → phải: snapshot → copy CÓ mã hoá → restore thành instance MỚI
       → đổi endpoint hoặc đổi DNS

EFS  → mã hoá at-rest chỉ đặt được LÚC TẠO file system
       → phải tạo file system mới rồi DataSync sang

⚠ Nhưng có một cảnh báo quan trọng đi kèm với đáp án S3:

Bật Default Encryption
        ↓
    → chỉ áp cho đối tượng GHI MỚI
        ↓
    → hàng triệu tệp CŨ vẫn không mã hoá
        ↓
Muốn phủ kín: S3 Batch Operations copy đè toàn bộ

Nói cách khác, "in-place" ở đây nghĩa là không gián đoạn hoạt động, chứ không phải "mọi thứ tự động được mã hoá".

⚠ Một điểm cập nhật đáng biết:

Từ tháng 1/2023, AWS bật SSE-S3 mặc định cho MỌI bucket mới
        ↓
    → bucket tạo từ đó trở đi đã mã hoá sẵn
    → câu hỏi này vẫn đúng cho bucket cũ và cho việc
      chuyển sang SSE-KMS

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

• C (EBS) — đây là phương án gần nhất vì EBS có Elastic Volumes cho phép đổi dung lượng, loại volume và IOPS khi máy đang chạy — nên rất dễ tưởng mã hoá cũng vậy. Nhưng mã hoá là thuộc tính bất biến của volume: phải đi đường vòng qua snapshot.

• D (RDS) — cũng phải qua snapshot rồi restore, và bản restore là một instance MỚI với endpoint mới. Đây là một trong những việc gây gián đoạn nhất trong danh sách.

• B (EFS) — mã hoá at-rest đặt lúc tạo file system, không đổi được sau. (Mã hoá khi truyền thì bật/tắt được ở phía client khi mount — nhưng đó là chuyện khác.)

Ghi nhớ

⚠ Bật mã hoá cho tài nguyên đang chạy — bảng phải thuộc: | Dịch vụ | Bật tại chỗ | Cách làm nếu không | |---|---|---| | S3 | ĐƯỢC | Batch Operations cho tệp cũ | | EBS | không | snapshot → copy có mã hoá → volume mới | | RDS | không | snapshot → copy có mã hoá → restore | | EFS | không | tạo mới + DataSync | | DynamoDB | ĐƯỢC (đổi giữa các loại khoá KMS) | — | | Redshift | được (chạy nền, mất thời gian) | — |

Từ khoá nhận diện:

"bật mã hoá mà không gián đoạn" → S3 "mã hoá RDS đang chạy" → snapshot, copy có mã hoá, restore "mã hoá EBS đang gắn" → snapshot, copy có mã hoá, volume mới "tệp cũ trong bucket vẫn chưa mã hoá" → S3 Batch Operations "buộc mọi kết nối phải mã hoá" → aws:SecureTransport (S3) / parameter group (RDS)

⚠ Quy trình mã hoá một RDS đang chạy — các bước phải thuộc: | Bước | Nội dung | |---|---| | 1 | tạo snapshot của instance chưa mã hoá | | 2 | copy-db-snapshot với --kms-key-id | | 3 | restore-db-instance-from-db-snapshot từ bản sao đã mã hoá | | 4 | đồng bộ phần dữ liệu phát sinh (DMS nếu cần gần như không gián đoạn) | | 5 | đổi chuỗi kết nối hoặc bản ghi DNS |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài nguyên đã mã hoá chưa | describe-volumes / describe-db-instances, xem Encrypted | | Bucket dùng loại mã hoá gì | get-bucket-encryption | | Còn tài nguyên nào chưa mã hoá | AWS Config quy tắc encrypted-volumes, rds-storage-encrypted |

Và một lời khuyên phòng bệnh hơn chữa bệnh: hãy bật "EBS encryption by default" cho mọi Region đang dùng, ngay hôm nay. Đây là một công tắc ở cấp Region khiến mọi volume và snapshot mới đều được mã hoá tự động, và nó xoá sổ vĩnh viễn cái công việc khổ sở mà câu hỏi này mô tả — bởi vì mã hoá lại một hệ thống đang chạy bao giờ cũng tốn kém hơn nhiều lần so với việc mã hoá đúng ngay từ đầu.

Đáp án

A — Việc cân bằng lại sẽ bắt đầu, instance mới được khởi chạy, ASG phình lên tới 10% kích thước của nó, và các instance cũ KHÔNG bị chấm dứt.

Vì sao đúng

Câu này kiểm tra hiểu biết về thứ tự các bước trong AZRebalance và hệ quả khi thiếu một bước.

⚠ Điểm mấu chốt — AZRebalance luôn khởi chạy TRƯỚC rồi mới chấm dứt sau:

ASG phát hiện các AZ mất cân bằng
        ↓
    Bước 1: KHỞI CHẠY instance ở AZ đang thiếu
        ↓
    Bước 2: CHẤM DỨT instance ở AZ đang thừa
        ↓
    Thứ tự này là CÓ CHỦ Ý: không bao giờ giảm
    dung lượng phục vụ trước khi có máy thay thế

⚠ Khi tiến trình Terminate bị tạm ngừng thì chuỗi đó đứt ở giữa:

Bước 1 chạy bình thường → có máy mới
        ↓
    Bước 2 bị chặn → máy cũ KHÔNG bị chấm dứt
        ↓
    → ASG vượt quá dung lượng mong muốn
        ↓
    → nhưng chỉ vượt tối đa 10%, đây là trần cứng

⚠ Trần 10% là con số phải nhớ:

AWS cho phép AZRebalance vượt tạm thời
    tối đa 10% dung lượng mong muốn (hoặc MaxSize)
        ↓
    → tránh việc cân bằng lại làm bùng nổ số máy
        ↓
    Chạm trần rồi thì việc cân bằng dừng lại,
    và ASG nằm ở trạng thái thừa máy cho tới khi
    ai đó resume tiến trình Terminate

Hệ quả thực tế: bạn đang trả tiền cho số máy nhiều hơn cần thiết, một cách hoàn toàn im lặng.

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

• D (khởi chạy, phình 10%, rồi một lúc sau instance bị chấm dứt vì thừa) — đây là phương án gần nhất và là điều sẽ xảy ra nếu Terminate KHÔNG bị tạm ngừng. Nhưng đề nói rõ tiến trình đó đang bị ngừng, nên bước chấm dứt không bao giờ chạy.

• C (việc cân bằng không bắt đầu vì Terminate bị tạm ngừng) — sai; AZRebalance và Terminate là hai tiến trình độc lập. Ngừng cái này không ngăn cái kia khởi động.

• B (việc cân bằng bắt đầu nhưng instance khởi chạy thất bại) — sai; tiến trình Launch vẫn hoạt động bình thường, đề chỉ tạm ngừng Terminate.

Ghi nhớ

⚠ Các tiến trình của Auto Scaling — bảng phải thuộc: | Tiến trình | Việc | Tạm ngừng thì sao | |---|---|---| | Launch | khởi chạy máy mới | không scale out được | | Terminate | chấm dứt máy | không scale in, ASG phình dần | | AZRebalance | cân bằng giữa các AZ | AZ lệch nhau, không tự sửa | | HealthCheck | đánh dấu máy hỏng | máy chết vẫn được coi là khoẻ | | ReplaceUnhealthy | thay máy hỏng | máy hỏng nằm lại mãi | | AlarmNotification | nhận cảnh báo | chính sách co giãn không kích hoạt | | ScheduledActions | hành động theo lịch | lịch không chạy | | AddToLoadBalancer | đăng ký vào ELB | máy mới không nhận lưu lượng |

Từ khoá nhận diện:

"AZRebalance + Terminate bị ngừng" → phình tối đa 10%, máy cũ ở lại "ASG phình dần không rõ lý do" → Terminate bị tạm ngừng "máy mới lên nhưng không có lưu lượng" → AddToLoadBalancer bị tạm ngừng "máy hỏng không được thay" → ReplaceUnhealthy hoặc HealthCheck bị ngừng "muốn bảo trì một máy mà không bị ASG giết" → enter-standby, không phải suspend

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tiến trình nào bị ngừng | describe-auto-scaling-groups, trường SuspendedProcesses | | Ai đã ngừng và lúc nào | CloudTrail sự kiện SuspendProcesses | | Bật lại | resume-processes --auto-scaling-group-name ten-asg |

Và một thói quen nên có: hãy đặt một quy tắc AWS Config hoặc một cảnh báo phát hiện ASG có SuspendedProcesses khác rỗng. Suspend là công cụ hợp lệ và đôi khi rất cần trong lúc xử lý sự cố, nhưng nó không tự hết hạn và không hiện lên bất cứ bảng điều khiển nào — nên nó thường được phát hiện nhiều tháng sau đó, hoặc bởi một hoá đơn cao bất thường, hoặc bởi một đêm mà hệ thống đáng lẽ phải scale out nhưng đã không làm vậy.