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

Đáp án

B — Gắn managed policy AmazonSSMManagedInstanceCore vào IAM role của instance Ubuntu.

Vì sao đúng

Đề đã loại sẵn hai nghi phạm lớn: SSM Agent đã cài sẵn, và các máy khác trong CÙNG subnet vào được — nên vấn đề là của riêng máy này, không phải của mạng.

⚠ Điểm mấu chốt — Session Manager cần ĐÚNG BA điều kiện:

1. SSM AGENT đã cài và đang chạy
        ↓
    → đề nói "pre-configured with SSM Agent" ✓

2. INSTANCE PROFILE với quyền SSM
        ↓
    → AmazonSSMManagedInstanceCore
    → NGHI PHẠM DUY NHẤT CÒN LẠI

3. ĐƯỜNG MẠNG ra endpoint SSM
        ↓
    → máy khác cùng subnet vào được
    → nên mạng chắc chắn OK ✓

⚠ Không có role thì agent không đăng ký được:

SSM Agent chạy nhưng không có quyền
        ↓
    Không gọi được ssm:UpdateInstanceInformation
        ↓
    → máy KHÔNG XUẤT HIỆN trong Fleet Manager
    → hoặc hiện trạng thái "Connection lost"
        ↓
    Đội DevOps có đủ quyền IAM của HỌ
        ↓
    → nhưng quyền của NGƯỜI DÙNG
      khác với quyền của MÁY
    → đây chính là điểm mà câu hỏi kiểm tra

⚠ Quyền trong AmazonSSMManagedInstanceCore gồm gì:

ssm:UpdateInstanceInformation   → đăng ký máy
ssm:ListAssociations, ListInstanceAssociations
ssmmessages:*                   → KÊNH PHIÊN LÀM VIỆC
ec2messages:*                   → kênh nhắn tin của agent
s3:GetObject (giới hạn)         → tải tài liệu và gói
        ↓
    Thiếu ssmmessages
      → máy hiện Online nhưng KHÔNG mở phiên được

Xem thêm câu #11813 và #11814 (lô 127): cùng chủ đề — máy không xuất hiện trong Systems Manager vì thiếu instance profile. Khoá nhất quán.

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

• C (thêm luật inbound cổng 22 vào security group) — đây là phương án gần nhất về trực giác, nhưng Session Manager KHÔNG DÙNG cổng 22. Agent tự kết nối RA qua HTTPS 443, nên không cần mở cổng vào nào cả. Đây chính là ưu điểm lớn nhất của Session Manager.

• A (tạo key pair mới, cấu hình Session Manager dùng key pair đó) — Session Manager không dùng key pair. Nó xác thực bằng IAM, không bằng khoá SSH.

• D (cấu hình SSM Agent xác thực bằng tên người dùng "admin") — không có cơ chế nào như vậy. Agent xác thực bằng thông tin từ instance profile.

Ghi nhớ

⚠ Ba điều kiện của Session Manager — bảng phải thuộc: | Điều kiện | Nội dung | |---|---| | SSM Agent | đã cài và đang chạy — có sẵn trên Amazon Linux, Ubuntu mới | | IAM instance profile | AmazonSSMManagedInstanceCore | | Đường mạng ra | NAT Gateway, hoặc 3 VPC endpoint | | Thiếu bất kỳ điều nào | máy không xuất hiện, hoặc phiên không mở được |

Từ khoá nhận diện:

"Session Manager không kết nối được" → instance profile, trước tiên "máy không hiện trong Fleet Manager" → agent chưa chạy, hoặc thiếu quyền "máy hiện Online nhưng phiên không mở" → thiếu ssmmessages endpoint hoặc quyền "không muốn mở cổng 22" → Session Manager "máy tại chỗ cũng cần quản lý" → SSM Hybrid Activation

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy đã đăng ký chưa | describe-instance-information | | Instance profile là gì | describe-instances --query '...IamInstanceProfile' | | Agent báo lỗi gì | /var/log/amazon/ssm/amazon-ssm-agent.log |

Và một cách rất nhanh để khoanh vùng loại sự cố này: mở Fleet Manager và xem máy có trong danh sách hay không. Nếu máy không xuất hiện, vấn đề gần như chắc chắn là instance profile hoặc đường mạng; nếu máy xuất hiện nhưng phiên không mở được, thì hãy nhìn sang ssmmessages — hoặc quyền ssm:StartSession của chính người đang thao tác.

Đáp án

C — Tạo CROSS-REGION READ REPLICA cho CSDL.

Vì sao đúng

Đề hỏi giải pháp có RTO và RPO THẤP NHẤT cho khôi phục thảm hoạ giữa các vùng địa lý.

⚠ Điểm mấu chốt — replica luôn được đồng bộ, snapshot thì không:

CROSS-REGION READ REPLICA
        ↓
    Sao chép LIÊN TỤC, bất đồng bộ
        ↓
    RPO: thường vài GIÂY
      (đúng bằng độ trễ sao chép)
        ↓
    RTO: thời gian THĂNG CẤP replica
      thường vài PHÚT
        ↓
    → thấp nhất trong bốn phương án

SNAPSHOT SAO CHÉP ĐỊNH KỲ
        ↓
    RPO = KHOẢNG CÁCH GIỮA HAI LẦN CHỤP
      → hàng giờ, có khi cả ngày
        ↓
    RTO = thời gian khôi phục instance
      → hàng chục phút tới HÀNG GIỜ
        ↓
    → cao hơn nhiều

⚠ Nhắc lại hai khái niệm để không lẫn:

RPO — Recovery Point Objective
        ↓
    CHẤP NHẬN MẤT BAO NHIÊU DỮ LIỆU
    → đo bằng THỜI GIAN dữ liệu bị mất

RTO — Recovery Time Objective
        ↓
    CHẤP NHẬN NGỪNG BAO LÂU
    → đo bằng thời gian khôi phục dịch vụ

⚠ Và replica còn có lợi ích kép:

Trong lúc bình thường
        ↓
    → phục vụ tải ĐỌC ở Region đó
    → giảm độ trễ cho người dùng khu vực

Khi có thảm hoạ
        ↓
    → promote-read-replica
    → trở thành instance độc lập, ghi được
        ↓
    Lưu ý: THĂNG CẤP LÀ MỘT CHIỀU
    → không quay lại làm replica được

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

• D (tạo read replica MULTI-AZ cho CSDL) — đây là phương án gần nhất và cải thiện tính sẵn sàng thật, nhưng Multi-AZ nằm TRONG MỘT REGION. Đề đòi khôi phục giữa các vùng địa lý — mất cả Region thì Multi-AZ không cứu được.

• A (chụp snapshot tự động và sao chép sang Region khác) — chạy được nhưng RPO và RTO cao hơn nhiều: RPO bằng khoảng cách giữa hai lần chụp, RTO là thời gian khôi phục cả một instance.

• B (dùng Lambda theo lịch để tạo và sao chép snapshot) — cùng nhược điểm như A, cộng thêm mã phải bảo trì. (Và AWS Backup đã làm sẵn việc này.)

Ghi nhớ

⚠ Các chiến lược khôi phục thảm hoạ — bảng phải thuộc: | Chiến lược | RPO | RTO | Chi phí | |---|---|---|---| | Backup & Restore | giờ | giờ | thấp nhất | | Pilot Light | phút | hàng chục phút | thấp | | Warm Standby | giây | phút | trung bình | | Multi-Site Active/Active | gần 0 | gần 0 | cao nhất | | Cross-Region read replica | giây | phút | thuộc nhóm warm standby |

Từ khoá nhận diện:

"RTO và RPO thấp nhất cho CSDL đa Region" → cross-Region read replica "gần như không mất dữ liệu, gần như không ngừng" → Aurora Global Database "rẻ nhất, chấp nhận mất vài giờ" → sao lưu và khôi phục "chịu được mất một AZ" → Multi-AZ (không phải DR theo Region) "tự động hoá sao lưu đa Region" → AWS Backup cross-Region copy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Replica trễ bao nhiêu | chỉ số ReplicaLag — chính là RPO thực tế | | Thăng cấp mất bao lâu | diễn tập ở môi trường thử, bấm giờ | | Ứng dụng có chuyển được không | kiểm thử đổi endpoint trong staging |

Và một điều cần nói rõ khi trình bày phương án DR: con số RTO chỉ có giá trị khi đã được đo bằng một cuộc diễn tập thật. Rất nhiều tài liệu ghi RTO là "vài phút" dựa trên thời gian thăng cấp replica, nhưng bỏ qua thời gian dựng tầng ứng dụng ở Region phụ, thời gian đổi DNS và thời gian con người phát hiện ra sự cố — ba khoản này gộp lại thường lớn hơn nhiều so với phần CSDL.

Đáp án

A và E — Gọi DescribeSubnets rồi đối chiếu availabilityZoneId, VÀ gọi DescribeAvailabilityZones rồi đối chiếu zoneId.

Vì sao đúng

Có một sự thật rất quan trọng về AZ mà câu hỏi này kiểm tra: TÊN của AZ được XÁO NGẪU NHIÊN cho từng tài khoản.

⚠ Điểm mấu chốt — us-east-1a của bạn KHÔNG phải us-east-1a của tôi:

AWS ánh xạ TÊN AZ sang HẠ TẦNG VẬT LÝ
một cách NGẪU NHIÊN cho mỗi tài khoản
        ↓
    Tài khoản A: us-east-1a  →  use1-az2
    Tài khoản B: us-east-1a  →  use1-az4
        ↓
    → hai tài khoản cùng dùng "us-east-1a"
      nhưng thực tế ở HAI TRUNG TÂM DỮ LIỆU KHÁC NHAU
        ↓
    Vì sao AWS làm vậy:
      → để tải phân bố đều, tránh mọi người
        cùng dồn vào "AZ a"

⚠ AZ ID mới là định danh THẬT:

AZ ID: use1-az1, use1-az2, apse1-az3…
        ↓
    GIỐNG NHAU ở MỌI TÀI KHOẢN
        ↓
    → muốn biết hai subnet ở hai tài khoản
      có CÙNG một AZ vật lý hay không
      → so AZ ID, KHÔNG so tên

⚠ Hai API đều lấy được thông tin này:

DescribeAvailabilityZones          ← phương án E
        ↓
    Trả về: zoneName (us-east-1a)
            zoneId   (use1-az2)   ← cái cần
        ↓
    → dựng được BẢNG ÁNH XẠ cho mỗi tài khoản

DescribeSubnets                    ← phương án A
        ↓
    Mỗi subnet có:
      availabilityZone   (tên)
      availabilityZoneId (ID)      ← cái cần
        ↓
    → biết ngay subnet nào ở AZ vật lý nào

⚠ Vì sao điều này quan trọng với tính sẵn sàng:

Hai tài khoản cùng triển khai vào "us-east-1a"
        ↓
    Tưởng là cùng AZ → thực ra khác AZ
    → phát sinh PHÍ DỮ LIỆU QUA AZ ngoài dự kiến
    → độ trễ cao hơn dự tính

Hoặc ngược lại:
    Tưởng là khác AZ → thực ra CÙNG AZ
    → mất AZ đó là MẤT CẢ HAI
    → cam kết sẵn sàng cao bị phá vỡ
        ↓
    → đây là rủi ro nghiêm trọng nhất

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

• C (gọi DescribeAvailabilityZones và đối chiếu zoneName) — đây là phương án gần nhất và là bẫy chính của câu hỏi: zoneName chính là cái được xáo ngẫu nhiên giữa các tài khoản, nên đối chiếu nó cho kết quả SAI.

• D (gọi DescribeSubnets và đối chiếu availabilityZoneName) — cùng lỗi như C, chỉ ở API khác.

• B (gọi DescribeSubnets và đối chiếu defaultForAz) — defaultForAz chỉ cho biết subnet đó có phải subnet MẶC ĐỊNH của AZ hay không, hoàn toàn không giúp ánh xạ AZ giữa các tài khoản.

Ghi nhớ

⚠ AZ Name ↔ AZ ID — bảng phải thuộc: | | AZ Name | AZ ID | |---|---|---| | Ví dụ | us-east-1a | use1-az1 | | Nhất quán giữa các tài khoản | KHÔNG — bị xáo ngẫu nhiên | CÓ — luôn giống nhau | | Dùng để | hiển thị trong console của chính bạn | ánh xạ AZ giữa các tài khoản | | Lấy ở đâu | zoneName, availabilityZone | zoneId, availabilityZoneId | | Khi nào cần AZ ID | liên tài khoản, VPC sharing, tối ưu phí qua AZ | |

Từ khoá nhận diện:

"ánh xạ AZ giữa các tài khoản" → AZ ID, không phải AZ name "cùng AZ hay khác AZ" → so zoneId "chia sẻ subnet giữa tài khoản" → AWS RAM — hiển thị theo AZ ID "phí dữ liệu qua AZ cao bất ngờ" → kiểm tra xem có thật sự cùng AZ không "AZ nào hỗ trợ loại instance này" → describe-instance-type-offerings theo AZ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng ánh xạ của tài khoản này | describe-availability-zones --query 'AvailabilityZones[].[ZoneName,ZoneId]' | | Subnet ở AZ vật lý nào | describe-subnets --query 'Subnets[].[SubnetId,AvailabilityZoneId]' | | Hai tài khoản có trùng AZ không | so AvailabilityZoneId, không so tên |

Và một hệ quả rất tốn kém nếu bỏ qua chi tiết này: một kiến trúc "đa AZ" trên giấy có thể thực chất nằm gọn trong một AZ vật lý. Hai tài khoản cùng chọn us-east-1a và us-east-1b trông như đã trải hai AZ, nhưng nếu ánh xạ của chúng lệch nhau thì bốn subnet đó có thể chỉ phủ hai AZ vật lý theo một cách hoàn toàn khác dự kiến — và điều đó chỉ lộ ra vào đúng ngày một AZ gặp sự cố.

Đáp án

D — Dùng APPLICATION LOAD BALANCER với định tuyến THEO ĐƯỜNG DẪN (path-based routing).

Vì sao đúng

Đề cần định tuyến request tới các microservice khác nhau với ít công quản trị nhất, và ALB có sẵn tính năng đó.

⚠ Điểm mấu chốt — ALB hoạt động ở TẦNG 7, đọc được URL:

ALB là load balancer TẦNG 7 (HTTP/HTTPS)
        ↓
    Đọc được nội dung request:
      đường dẫn, host header, HTTP header,
      query string, phương thức, IP nguồn
        ↓
    Listener rule với điều kiện path-pattern:
        ↓
      /api/nguoi-dung/*  →  target group A
      /api/don-hang/*    →  target group B
      /api/thanh-toan/*  →  target group C
      /*                 →  target group mặc định
        ↓
    → đúng mô hình microservice
    → cấu hình bằng vài luật, không cần mã

⚠ Vì sao NLB không làm được:

NLB là load balancer TẦNG 4 (TCP/UDP)
        ↓
    Chỉ thấy IP và CỔNG
        ↓
    KHÔNG đọc được URL
        ↓
    → không thể định tuyến theo đường dẫn
    → phương án B mâu thuẫn ngay trong chính nó

⚠ Các loại điều kiện của listener rule — rất linh hoạt:

path-pattern      → /api/*, /images/*
host-header       → api.example.com
http-header       → theo một header bất kỳ
http-request-method → GET, POST
query-string      → ?version=2
source-ip         → theo dải IP nguồn
        ↓
    Kết hợp được nhiều điều kiện trong một luật
    → và mỗi luật có SỐ ƯU TIÊN

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

• B (dùng Network Load Balancer và định tuyến theo đường dẫn) — đây là phương án gần nhất và là bẫy chính: NLB hoạt động ở tầng 4, không đọc được đường dẫn HTTP. Định tuyến theo path là tính năng riêng của ALB.

• A (dùng CloudFront và chuyển tiếp host header về origin) — CloudFront có định tuyến theo path (qua cache behavior), nhưng nó là CDN cho phân phối toàn cầu, không phải công cụ cân bằng tải nội bộ. Dùng nó cho việc này là thêm một tầng không cần thiết, và vẫn cần một load balancer phía sau.

• C (dùng Global Accelerator với chính sách định tuyến theo trọng số) — Global Accelerator hoạt động ở tầng 4, chia lưu lượng theo trọng số hoặc theo Region, không đọc được đường dẫn.

Ghi nhớ

⚠ Ba loại load balancer — bảng phải thuộc: | | ALB | NLB | GWLB | |---|---|---|---| | Tầng | 7 (HTTP/HTTPS) | 4 (TCP/UDP/TLS) | 3 (GENEVE) | | Định tuyến theo path | CÓ | KHÔNG | — | | Định tuyến theo host | có | không | — | | IP tĩnh | không | CÓ, mỗi AZ một cái | — | | Hiệu năng | rất cao | cực cao, độ trễ thấp nhất | — | | Sticky session | cookie | theo IP nguồn | — | | Dùng khi | web, API, microservice | game, IoT, cần IP tĩnh | thiết bị bảo mật |

Từ khoá nhận diện:

"định tuyến theo đường dẫn / theo host" → ALB "cần IP tĩnh" → NLB "TCP/UDP, độ trễ cực thấp" → NLB "phân phối nội dung toàn cầu" → CloudFront "microservice, container" → ALB + ECS/EKS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật đang định tuyến ra sao | describe-rules --listener-arn ... | | Request đi tới target nào | ALB access log, cột target:port | | Target có khoẻ không | HealthyHostCount theo từng target group |

Và một chi tiết dễ gây bối rối khi mới cấu hình nhiều luật: thứ tự ưu tiên quyết định luật nào được áp dụng. ALB xét luật theo số ưu tiên tăng dần và dừng ở luật khớp đầu tiên, nên một luật /* đặt ở ưu tiên thấp sẽ nuốt hết mọi request trước khi các luật cụ thể hơn kịp được xem xét — hãy luôn để luật rộng nhất ở số ưu tiên lớn nhất.

Đáp án

A — Chuyển bản ghi Route 53 hiện có sang chính sách LATENCY ROUTING, với hai bản ghi latency trỏ tới hai ALB tương ứng.

Vì sao đúng

Đề nói rất rõ mục tiêu: "route users to the LOWEST LATENCY endpoint" — đưa người dùng tới điểm cuối có độ trễ thấp nhất.

⚠ Điểm mấu chốt — latency routing chọn theo ĐỘ TRỄ ĐO ĐƯỢC:

Route 53 duy trì một BẢNG ĐỘ TRỄ
      giữa các mạng trên thế giới và các Region AWS
        ↓
    Người dùng truy vấn DNS
        ↓
    Route 53 xem resolver đó ở đâu
    → tra bảng độ trễ
    → trả về bản ghi của Region CÓ ĐỘ TRỄ THẤP NHẤT
        ↓
    → không phải Region GẦN NHẤT trên bản đồ
    → mà Region NHANH NHẤT về đường mạng

⚠ Vì sao "độ trễ thấp nhất" khác "gần nhất":

Khoảng cách địa lý ≠ độ trễ mạng
        ↓
    Đường cáp quang không đi thẳng
    Chất lượng nhà mạng khác nhau theo vùng
    Điểm trao đổi lưu lượng nằm ở những nơi bất ngờ
        ↓
    → có trường hợp Region xa hơn lại nhanh hơn
        ↓
    Latency routing dùng SỐ LIỆU THẬT của AWS
    → tự cập nhật khi hạ tầng mạng thay đổi

⚠ Cách cấu hình cho đề này:

Cùng một tên bản ghi (www.congty.com):
        ↓
    Bản ghi 1: Alias → ALB ở ap-southeast-1
               Routing policy: Latency
               Region: ap-southeast-1
        ↓
    Bản ghi 2: Alias → ALB ở us-west-2
               Routing policy: Latency
               Region: us-west-2
        ↓
    → URL KHÔNG ĐỔI, đúng yêu cầu "maintain the URL"
    → Route 53 tự chọn giữa hai bản ghi
        ↓
    Nên ghép thêm HEALTH CHECK
    → Region hỏng thì tự chuyển sang Region kia

Xem thêm câu #11922 (lô 129) và #11855 (lô 128): cũng chọn kiểu định tuyến của Route 53 nhưng khoá là geolocation, vì ở đó đề đòi người dùng châu Âu phải về Region châu Âu — một ràng buộc theo VỊ TRÍ. Ở đây đề đòi độ trễ thấp nhất — một ràng buộc về HIỆU NĂNG. Hai khoá khác nhau vì ràng buộc khác nhau, không mâu thuẫn.

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

• B (chuyển sang geolocation routing, liên kết tới ALB ở mỗi Region) — đây là phương án gần nhất và cũng đưa người dùng về Region theo khu vực, nhưng nó chọn theo vị trí địa lý, không theo độ trễ đo được. Đề nói rõ mục tiêu là độ trễ thấp nhất, nên latency routing đúng hơn. (Geolocation là lựa chọn đúng khi có ràng buộc pháp lý hoặc nội dung theo vùng.)

• C (chuyển sang multivalue answer và thêm tên DNS của ALB mới) — multivalue trả về nhiều bản ghi khoẻ mạnh một cách ngẫu nhiên, hoàn toàn không xét độ trễ hay vị trí. Người dùng Bắc Mỹ vẫn có thể bị đưa về Singapore.

• D (chỉ gắn thêm tên DNS của ALB mới vào bản ghi hiện có) — tạo ra một bản ghi có nhiều giá trị nhưng không có logic chọn nào; hành vi sẽ tương tự phương án C.

Ghi nhớ

⚠ Chọn kiểu định tuyến theo đúng RÀNG BUỘC — bảng phải thuộc: | Ràng buộc trong đề | Kiểu định tuyến | |---|---| | "độ trễ thấp nhất", "hiệu năng tốt nhất" | Latency-based | | "người dùng nước X phải về Region Y", tuân thủ | Geolocation | | "chia N% lưu lượng", canary | Weighted | | "chính / dự phòng" | Failover | | "điều chỉnh vùng phục vụ của một Region" | Geoproximity với bias | | Trả nhiều IP khoẻ mạnh | Multivalue answer |

Từ khoá nhận diện:

"lowest latency" → latency-based routing "người dùng ở quốc gia X" → geolocation "dữ liệu phải ở lại trong nước" → geolocation, BẮT BUỘC "giữ nguyên URL" → cùng một tên bản ghi, nhiều bản ghi con "failover nhanh hơn DNS" → Global Accelerator

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng vùng X nhận gì | test-dns-answer với --resolver-ip của vùng đó | | Health check đang báo gì | Route 53 → Health checks → tab Monitoring | | Có cải thiện thật không | đo độ trễ từ Bắc Mỹ trước và sau |

Và một chi tiết nên biết về giới hạn của latency routing: nó dựa trên vị trí của RESOLVER, không phải của người dùng. Một người ở Bắc Mỹ dùng DNS công cộng có thể được đo theo vị trí của resolver đó thay vì của chính họ — Route 53 có hỗ trợ EDNS Client Subnet để giảm bớt sai lệch này, nhưng nó phụ thuộc vào việc resolver có gửi thông tin đó hay không.

Đáp án

D — Bật DynamoDB STREAMS và thêm một GLOBAL TABLE REGION.

Vì sao đúng

Yêu cầu là nhân bản bảng sang Region khác cho khôi phục thảm hoạ, và global table là cơ chế duy nhất làm điều đó.

⚠ Điểm mấu chốt — global table nhân bản đa Region:

DynamoDB Global Table
        ↓
    Bảng tồn tại ở NHIỀU Region cùng lúc
        ↓
    Ghi ở Region nào cũng được (multi-active)
    → tự nhân bản sang các Region còn lại
        ↓
    Độ trễ nhân bản: thường DƯỚI MỘT GIÂY
        ↓
    → RPO gần bằng 0
    → mất cả một Region vẫn còn bản đầy đủ

⚠ Vì sao phải bật Streams trước:

Global table dùng STREAMS làm cơ chế nhân bản
        ↓
    Streams ghi lại mọi thay đổi ở mức bản ghi
        ↓
    → phải bật với StreamViewType:
      NEW_AND_OLD_IMAGES
        ↓
    → sau đó chỉ cần THÊM MỘT REGION
      vào bảng là xong

⚠ Xử lý xung đột:

Hai Region cùng sửa một bản ghi
        ↓
    LAST WRITER WINS theo dấu thời gian
        ↓
    → phù hợp với phần lớn ứng dụng
    → nhưng KHÔNG dùng cho giao dịch
      đòi nhất quán nghiêm ngặt liên Region
        ↓
    Cách tránh: định tuyến người dùng
    về đúng một Region theo khu vực

Xem thêm câu #11934 (CÙNG LÔ): gần như cùng một câu hỏi, cùng đáp án Streams + global table. Chỉ khác chữ cái vì bộ đề xáo thứ tự phương án (ở đó là B, ở đây là D). Khoá nhất quán.

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

• B (bật Streams và thêm một global secondary index — GSI) — đây là phương án gần nhất và là bẫy đặt tên kinh điển: GSI là chỉ mục phụ TRONG CÙNG bảng và CÙNG Region. Chữ "global" ở đây nghĩa là phủ toàn bộ bảng (khác local secondary index), không phải toàn cầu về địa lý.

• A (bật point-in-time recovery sang một Region thứ hai) — PITR không có khái niệm Region thứ hai: nó khôi phục theo thời điểm trong cùng Region (35 ngày gần nhất).

• C (bật sao lưu theo lịch kiểu on-demand) — sao lưu không phải nhân bản: RPO bằng khoảng cách giữa hai lần sao lưu, RTO là thời gian khôi phục cả bảng. Và bản thân on-demand backup cũng nằm trong cùng Region trừ khi dùng AWS Backup để copy.

Ghi nhớ

⚠ Các tính năng DynamoDB dễ nhầm — bảng phải thuộc: | Tính năng | Việc | |---|---| | Global Table | nhân bản ĐA REGION, ghi được ở mọi Region | | Global Secondary Index (GSI) | chỉ mục phụ TRONG CÙNG bảng, cùng Region | | Local Secondary Index (LSI) | cùng khoá phân vùng, phải tạo lúc tạo bảng | | DAX | cache trong bộ nhớ, độ trễ micro giây | | Streams | luồng thay đổi — nền tảng của global table | | PITR | 35 ngày, tới từng giây, CÙNG Region |

Từ khoá nhận diện:

"nhân bản sang Region khác" → Global Table "khôi phục về thời điểm trước sự cố" → PITR "truy vấn theo thuộc tính khác khoá chính" → GSI "đọc cần micro giây" → DAX "phản ứng khi dữ liệu thay đổi" → Streams + Lambda

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã có replica chưa | describe-table → Replicas | | Nhân bản trễ bao nhiêu | chỉ số ReplicationLatency | | PITR đã bật chưa | describe-continuous-backups |

Và một điều đáng nhớ về đặt tên trong AWS: chữ "global" trong "global secondary index" và trong "global table" mang hai nghĩa hoàn toàn khác nhau. Một cái nói về phạm vi khoá phân vùng trong bảng, cái kia nói về phạm vi địa lý — và đây là một trong những bẫy đặt tên xuất hiện đều đặn trong đề thi.

Đáp án

C — Tạo CloudWatch alarm theo dõi CPUUtilization và DỪNG máy nếu mức dùng dưới 5% trong 30 phút.

Vì sao đúng

Đề cần tự động dừng máy không dùng tới trong một tài khoản development, và alarm với EC2 action làm đúng việc đó mà không cần mã.

⚠ Điểm mấu chốt — CloudWatch alarm có hành động EC2 tích hợp sẵn:

CloudWatch alarm
        ↓
    Hành động gắn được:
      - SNS notification
      - Auto Scaling action
      - EC2 ACTION: stop / terminate / reboot / recover
      - SSM Incident / OpsItem
        ↓
    → chọn "Stop this instance"
        ↓
    → KHÔNG cần Lambda, KHÔNG cần mã
    → đây là cách đơn giản nhất

⚠ Cấu hình cho ứng dụng CPU-heavy:

Metric:            CPUUtilization
Threshold:         < 5%
Period:            5 phút
EvaluationPeriods: 6   → tổng 30 phút
DatapointsToAlarm: 6
Action:            EC2 → Stop this instance
        ↓
    Ứng dụng NẶNG CPU
    → CPU dưới 5% suốt 30 phút
      nghĩa là gần như chắc chắn không ai dùng
        ↓
    → ngưỡng này hợp lý cho đúng loại tải trong đề

⚠ Nhưng phải cẩn thận với cách chọn chỉ số:

CPU thấp KHÔNG LUÔN nghĩa là nhàn rỗi
        ↓
    Máy đang chờ I/O
    Máy đang chờ dữ liệu từ mạng
    Máy chạy tác vụ nặng bộ nhớ
        ↓
    → với ứng dụng CPU-heavy như đề mô tả
      thì rủi ro này thấp
        ↓
    Với tải khác, nên kết hợp thêm:
      NetworkIn/Out, số phiên đăng nhập,
      hoặc composite alarm

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

• D (dùng AWS Config phát hiện thay đổi trạng thái tài nguyên rồi gọi Lambda dừng máy) — đây là phương án gần nhất về mức độ tự động hoá, nhưng Config theo dõi THAY ĐỔI CẤU HÌNH, không theo dõi mức sử dụng. Một máy nhàn rỗi thì cấu hình của nó không đổi gì cả, nên Config sẽ không bao giờ kích hoạt.

• B (dùng Athena tìm trong log CloudTrail rồi gọi Lambda khi không có hoạt động API) — hoạt động API không phản ánh việc máy có đang được dùng hay không: một máy chạy tính toán suốt ngày cũng không sinh lời gọi API nào. Lại rất phức tạp và tốn kém.

• A (tạo chỉ số CloudWatch để dừng máy khi VolumeIdleTime > 1800 giây) — sai hai chỗ: VolumeIdleTime đo thời gian rảnh của EBS, không phải của máy, và bạn không "tạo chỉ số" để dừng máy — phải tạo alarm.

Ghi nhớ

⚠ Bốn hành động EC2 của CloudWatch alarm — bảng phải thuộc: | Hành động | Dùng khi | |---|---| | Stop | máy nhàn rỗi — tiết kiệm chi phí | | Terminate | máy dùng một lần, không cần giữ | | Reboot | ứng dụng treo, cần khởi động lại | | Recover | StatusCheckFailed_System — chuyển sang phần cứng mới | | Điều kiện | máy phải là EBS-backed (với Stop) |

Từ khoá nhận diện:

"tự dừng máy nhàn rỗi" → CloudWatch alarm + EC2 action Stop "tự khởi động lại khi treo" → alarm + EC2 action Reboot "phần cứng lỗi" → alarm trên StatusCheckFailed_System + Recover "tắt máy theo LỊCH ngoài giờ" → Instance Scheduler, hoặc EventBridge + SSM "máy không đúng chuẩn cấu hình" → AWS Config

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Alarm có kích hoạt không | describe-alarm-history | | Máy có bị dừng nhầm không | CloudTrail, tìm StopInstances với nguồn là CloudWatch | | Tiết kiệm được bao nhiêu | Cost Explorer, so chi phí EC2 trước/sau |

Và một biện pháp bổ sung rất đáng làm cùng lúc: thêm một tag ngoại lệ như AlwaysOn=true và loại những máy đó khỏi cơ chế tự dừng. Trong một tài khoản development luôn có vài máy chạy build agent, license server hay cơ sở dữ liệu dùng chung — chúng có CPU rất thấp nhưng không được phép tắt, và cách rẻ nhất để tránh một sự cố khó chịu là chừa sẵn một lối ra ngay từ đầu.

Đáp án

C — Dùng SERVICE CONTROL POLICY để từ chối hành động s3:DeleteBucket trên mọi bucket ở mọi tài khoản.

Vì sao đúng

Đề yêu cầu bucket KHÔNG BAO GIỜ được xoá trên nhiều tài khoản production, với cách đơn giản nhất.

⚠ Điểm mấu chốt — SCP là trần quyền cho CẢ TÀI KHOẢN:

SCP áp lên root hoặc OU
        ↓
    Áp cho MỌI danh tính trong các tài khoản đó:
      - IAM user, IAM role
      - kể cả người có AdministratorAccess
      - kể cả ROOT USER của tài khoản thành viên
        ↓
    Deny s3:DeleteBucket
        ↓
    → KHÔNG AI xoá được bucket
    → và chỉ cần cấu hình MỘT LẦN ở tài khoản quản lý

⚠ Chính sách viết rất gọn:

{
  "Effect": "Deny",
  "Action": "s3:DeleteBucket",
  "Resource": "*"
}

    Không cần Condition
    Không cần liệt kê bucket
        ↓
    → áp cho mọi bucket, mọi tài khoản
      trong phạm vi được gắn

⚠ Vì sao IAM policy KHÔNG đủ:

IAM policy gắn vào user hoặc group
        ↓
    Người có quyền quản trị IAM
      → tự gỡ chính sách ra
      → hoặc tạo một role mới không bị ràng buộc
        ↓
    Và phải cấu hình ở TỪNG TÀI KHOẢN
    → tài khoản mới lại phải làm lại
        ↓
    → không phải "đơn giản nhất",
      và cũng không thật sự bảo đảm

Xem thêm câu #11865 (lô 128), #11882 và #11894 (lô 129): cùng chùm SCP — công cụ duy nhất chặn được cả người có quyền quản trị trong tài khoản thành viên. Khoá nhất quán.

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

• A (tạo IAM group với chính sách Deny s3:DeleteBucket trên mọi bucket ở mọi tài khoản) — đây là phương án gần nhất và chính sách đúng nội dung, nhưng IAM group chỉ tồn tại trong MỘT tài khoản: phải tạo ở từng tài khoản, và người dùng không thuộc group đó thì không bị ràng buộc.

• B (bật MFA Delete trên mọi bucket) — MFA Delete bảo vệ việc xoá PHIÊN BẢN ĐỐI TƯỢNG và việc tắt versioning, không ngăn xoá bucket theo cách đề cần. (Và nó chỉ bật được bằng root user với CLI, rất bất tiện ở quy mô nhiều tài khoản.)

• D (dùng Access Control List để từ chối s3:DeleteBucket ở cấp tổ chức) — S3 ACL là cơ chế cũ, chỉ cấp quyền đọc/ghi cho đối tượng và bucket, không có khái niệm Deny và không áp ở cấp tổ chức.

Ghi nhớ

⚠ Bốn tầng kiểm soát quyền — bảng phải thuộc: | Tầng | Phạm vi | Ai gỡ được | |---|---|---| | SCP | cả TÀI KHOẢN hoặc OU | chỉ tài khoản QUẢN LÝ | | Permissions boundary | một danh tính | người có quyền IAM | | Identity policy | user/group/role | bất kỳ ai có quyền IAM | | Resource policy | một tài nguyên | người quản lý tài nguyên đó | | Hiệu lực | giao của tất cả — Deny ở bất kỳ đâu là TỪ CHỐI | |

Từ khoá nhận diện:

"không ai được làm X, nhiều tài khoản" → SCP "kể cả quản trị viên cũng bị chặn" → SCP "chống xoá nhầm ĐỐI TƯỢNG trong bucket" → versioning + MFA Delete + Object Lock "chống xoá nhầm một tài nguyên cụ thể" → deletion protection, DeletionPolicy: Retain "phát hiện tài nguyên sai chuẩn" → AWS Config

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 | thử delete-bucket ở một tài khoản thành viên — phải AccessDenied | | Có làm đứt gì không | theo dõi CloudTrail tìm AccessDenied bất thường sau khi áp |

Và một điều nên cân nhắc khi viết SCP loại này: đừng dùng s3:Delete*. Mẫu đó sẽ chặn luôn s3:DeleteObject và s3:DeleteObjectVersion, khiến mọi quy trình dọn dẹp và mọi lifecycle rule do ứng dụng gọi bị hỏng — trong khi yêu cầu của công ty chỉ là không cho xoá bucket, một hành động hoàn toàn khác.

Đáp án

D — Cấu hình client GỬI SAML ASSERTION và dùng ENDPOINT ĐĂNG NHẬP SSO của AWS.

Vì sao đúng

Đề nói rõ mục tiêu: mở AWS Management Console THAY MẶT người dùng. Đó là một luồng của trình duyệt, không phải một lời gọi API.

⚠ Điểm mấu chốt — hai luồng SAML hoàn toàn khác nhau:

LUỒNG CONSOLE (đề này)
        ↓
    IdP xác thực người dùng
        ↓
    Trình duyệt POST SAML assertion tới
      https://signin.aws.amazon.com/saml
        ↓
    AWS xác minh assertion, ánh xạ sang IAM role
        ↓
    → chuyển hướng thẳng vào CONSOLE
    → người dùng KHÔNG cần thao tác gì thêm

LUỒNG API / CLI
        ↓
    Ứng dụng gọi sts:AssumeRoleWithSAML
        ↓
    → nhận về access key, secret, session token
    → dùng cho SDK và CLI
    → KHÔNG mở console

⚠ Vì sao gọi thẳng AssumeRoleWithSAML không mở được console:

AssumeRoleWithSAML trả về THÔNG TIN XÁC THỰC TẠM
        ↓
    Muốn từ đó vào console
        ↓
    → phải gọi thêm federation endpoint
      để đổi lấy một SIGN-IN TOKEN
    → rồi dựng một URL đăng nhập
        ↓
    → nhiều bước hơn, và không phải
      luồng chuẩn cho SSO qua trình duyệt

⚠ Cấu hình cần có ở phía AWS:

1. Tạo IAM IDENTITY PROVIDER kiểu SAML
     → tải lên metadata XML của IdP
        ↓
2. Tạo IAM ROLE với trust policy:
     Principal: Federated → ARN của IdP
     Action: sts:AssumeRoleWithSAML
     Condition: SAML:aud =
       https://signin.aws.amazon.com/saml
        ↓
3. Ở phía IdP, khai các thuộc tính SAML:
     Role       → ARN của role và ARN của IdP
     RoleSessionName → tên phiên
     SessionDuration → thời hạn phiên

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

• B (gọi thẳng API AssumeRoleWithSAML) — đây là phương án gần nhất và là API đúng cho SAML, nhưng nó phục vụ luồng API/CLI, trả về thông tin xác thực chứ không mở console. Đề yêu cầu mở console thay mặt người dùng.

• C (gọi thẳng AssumeRoleWithWebIdentity) — API này dành cho OIDC / web identity (Google, Facebook, Cognito), không dành cho SAML 2.0.

• A (gửi SAML assertion và dùng endpoint Amazon Cognito) — Cognito phục vụ người dùng của ỨNG DỤNG, không phải để đưa nhân viên vào AWS Management Console.

Ghi nhớ

⚠ Các API của STS — bảng phải thuộc: | API | Dùng khi | |---|---| | AssumeRole | cross-account, hoặc đổi vai trong cùng tài khoản | | AssumeRoleWithSAML | liên kết SAML 2.0 — cho API/CLI | | AssumeRoleWithWebIdentity | OIDC: Google, Facebook, Cognito, IRSA của EKS | | GetFederationToken | liên kết cho người dùng không phải IAM | | GetSessionToken | thêm MFA cho IAM user | | Endpoint console | https://signin.aws.amazon.com/saml |

Từ khoá nhận diện:

"mở CONSOLE thay mặt người dùng" → POST SAML assertion tới endpoint SSO "lấy thông tin xác thực cho CLI/SDK" → AssumeRoleWithSAML "OIDC, Google, Cognito" → AssumeRoleWithWebIdentity "nhiều tài khoản AWS, một lần đăng nhập" → IAM Identity Center "người dùng của ứng dụng" → Cognito

Ba việc kiểm chứng: | Việc | Cách | |---|---| | IdP đã đăng ký chưa | list-saml-providers | | Trust policy đúng chưa | get-role → đọc AssumeRolePolicyDocument | | Ai đã đăng nhập | CloudTrail, tìm AssumeRoleWithSAML và RoleSessionName |

Và một khuyến nghị nên đặt vào lộ trình dù hôm nay dùng liên kết SAML trực tiếp: chuyển sang IAM Identity Center khi số tài khoản tăng lên. Với một tài khoản thì hai cách tương đương, nhưng với hai mươi tài khoản thì cách truyền thống nghĩa là hai mươi bộ IdP và role phải giữ đồng bộ — trong khi Identity Center chỉ cần một permission set áp cho tất cả.

Đáp án

C — Luật OUTBOUND của NETWORK ACL.

Vì sao đúng

Hai dòng flow log trong đề đã trả lời gần như trọn vẹn — chỉ cần đọc đúng chiều.

⚠ Điểm mấu chốt — đọc hai dòng log:

Dòng 1:  200.10.11.12 → 172.31.16.25   ACCEPT
        ↓
    Gói ĐI VÀO được CHẤP NHẬN
    → security group inbound ĐÚNG
    → NACL inbound ĐÚNG
    → gói tin ĐÃ TỚI máy

Dòng 2:  172.31.16.25 → 200.10.11.12   REJECT
        ↓
    Gói trả lời ĐI RA bị TỪ CHỐI
        ↓
    → chỉ một thứ chặn được chiều ra ở đây

⚠ Vì sao chắc chắn là NACL chứ không phải security group:

SECURITY GROUP có TRẠNG THÁI (stateful)
        ↓
    Đã cho gói vào → gói trả lời TỰ ĐỘNG được ra
    → KHÔNG cần luật outbound
    → và SG KHÔNG CÓ luật Deny
        ↓
    → SG không thể là thủ phạm của dòng REJECT

NETWORK ACL KHÔNG có trạng thái (stateless)
        ↓
    Chiều vào và chiều ra xét ĐỘC LẬP
    → cho vào rồi vẫn phải có luật cho RA
        ↓
    → thủ phạm là NACL, chiều OUTBOUND

⚠ Sửa thế nào — chú ý giao thức:

protocol = 1  →  ICMP (đây là lệnh ping)
        ↓
    ICMP KHÔNG có khái niệm cổng
    → phải mở ICMP chiều ra tới 200.10.11.12
        ↓
Nếu là TCP (SSH, HTTP…) thì
        ↓
    Chiều ra phải mở DẢI CỔNG TẠM 1024-65535
        ↓
    → đây là lỗi NACL phổ biến nhất

Xem thêm câu #11848 (lô 128): gần như cùng một câu hỏi, cùng hai dòng log ACCEPT/REJECT và cùng đáp án NACL outbound. Chỉ khác chữ cái vì bộ đề xáo thứ tự phương án (ở đó là D, ở đây là C). Khoá nhất quán.

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

• D (luật Deny outbound của security group) — đây là phương án gần nhất vì cùng nói đúng chiều, nhưng security group KHÔNG CÓ luật Deny, và vì stateful nên gói trả lời luôn được đi ra.

• B (luật Deny inbound của security group) — sai cả hai vế: SG không có Deny, và dòng log đầu tiên đã là ACCEPT, chứng minh chiều vào thông.

• A (luật inbound của NACL) — cũng bị chính dòng ACCEPT đầu tiên bác bỏ.

Ghi nhớ

⚠ Security Group ↔ Network ACL — bảng phải thuộc: | | Security Group | Network ACL | |---|---|---| | Trạng thái | CÓ (stateful) | KHÔNG (stateless) | | Luật Deny | KHÔNG CÓ | CÓ | | 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 tiên | | Mặc định | vào: chặn hết, ra: mở hết | NACL mặc định VPC: mở cả hai chiều | | Gói trả lời chiều ra | tự động cho qua | PHẢI CÓ LUẬT |

Từ khoá nhận diện:

"flow log: vào ACCEPT, ra REJECT" → NACL thiếu luật OUTBOUND "vào REJECT" → security group hoặc NACL inbound "kết nối TCP hỏng một chiều" → NACL thiếu DẢI CỔNG TẠM "cần CHẶN một IP cụ thể" → NACL (SG không có Deny) "request timed out" → gói bị bỏ im lặng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | NACL nào gắn vào subnet | describe-network-acls --filters Name=association.subnet-id,Values=... | | Gói bị chặn ở đâu | VPC Flow Logs — tìm REJECT và xem HƯỚNG | | Đường đi lý thuyết | VPC Reachability Analyzer |

Và một công cụ nên dùng trước khi ngồi đọc từng dòng log: VPC Reachability Analyzer. Nó phân tích đường đi mà không gửi gói tin nào, rồi nói thẳng "bị chặn tại network ACL nào, luật số mấy" — nhanh hơn nhiều so với việc bật flow log rồi chờ dữ liệu, và trả lời luôn câu hỏi tiếp theo là cần sửa chính xác luật nào.