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

Đáp án

A, D — hai lý do khiến CloudFormation không nhận được tín hiệu:

• A — Subnet chứa ứng dụng KHÔNG có tuyến mạng tới dịch vụ CloudFormation, qua NAT Gateway hoặc Internet Gateway.
• D — Script cfn-signal không kịp chạy trước khi WaitCondition hết hạn.

Vì sao đúng

Chú ý cách đề diễn đạt: "CloudFormation KHÔNG NHẬN ĐƯỢC tín hiệu" — nghĩa là tín hiệu không tới nơi, chứ không phải tín hiệu báo thất bại.

⚠ Lý do A — đề nói rõ đây là hệ thống NỘI BỘ, tức là nằm ở private subnet:

cfn-signal gọi tới endpoint CÔNG KHAI của CloudFormation
        ↓
    Instance nằm ở private subnet không có NAT
        ↓
    → lời gọi treo cho tới khi hết thời gian chờ
        ↓
    → CloudFormation chờ mãi rồi thất bại
        ↓
Chữa: NAT Gateway, hoặc VPC endpoint cho CloudFormation
      com.amazonaws.<region>.cloudformation

⚠ Lý do D — hết thời gian trước khi kịp gửi:

CreationPolicy Timeout: PT5M
        ↓
    Nhưng cfn-init phải cài Apache, PHP, MySQL...
        ↓
    Mất 8 phút mới xong
        ↓
    → tới lúc cfn-signal chạy thì WaitCondition đã hết hạn
        ↓
Chữa: nới Timeout cho tương xứng với việc cài đặt thật

Ngoài ra còn hai nguyên nhân thực tế hay gặp cùng loại: user data lỗi cú pháp nên script chết trước khi tới dòng cfn-signal, và cfn-signal khai sai --resource hoặc --region.

Xem thêm câu #11593: cùng bộ công cụ này nhưng hỏi triệu chứng ngược — stack báo hoàn tất quá sớm vì thiếu WaitCondition. Hai câu là hai mặt của một cơ chế.

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

• E (script cfn-init thất bại) — đây là phương án gần nhất và rất dễ chọn. Nhưng hãy đọc kỹ: nếu cfn-init hỏng mà user data viết đúng chuẩn cfn-signal -e $?, thì một tín hiệu THẤT BẠI vẫn được gửi đi và CloudFormation VẪN NHẬN ĐƯỢC nó — stack rollback ngay với thông báo rõ ràng, chứ không phải "không nhận được tín hiệu".

• C (instance thiếu IAM role để gửi tín hiệu) — đây là bẫy tinh vi nhất: cfn-signal KHÔNG cần chứng chỉ AWS. Nó gọi tới một URL đã được ký sẵn (presigned) của WaitConditionHandle, hoặc dùng đường dẫn tín hiệu của chính stack. Không có IAM role vẫn gửi được.

• B (AWS hết dung lượng cho loại instance yêu cầu) — khi đó instance không khởi chạy được và stack thất bại ngay ở bước tạo tài nguyên với lỗi InsufficientInstanceCapacity — một thông báo hoàn toàn khác, không phải chuyện chờ tín hiệu.

Ghi nhớ

⚠ Bốn nguyên nhân "không nhận được tín hiệu" — bảng phải thuộc: | Nguyên nhân | Dấu hiệu | |---|---| | Không có đường mạng ra | phổ biến nhất ở private subnet | | Timeout quá ngắn | cài đặt lâu hơn thời gian chờ | | User data lỗi, chết trước khi tới cfn-signal | cloud-init-output.log dừng giữa chừng | | Sai --resource hoặc --region | tín hiệu gửi nhầm chỗ |

Từ khoá nhận diện:

"không nhận được tín hiệu" → mạng hoặc hết thời gian "nhận tín hiệu THẤT BẠI" → cfn-init hỏng, đọc cfn-init.log "cfn-signal cần IAM role" → SAI, dùng presigned URL "stack xong quá sớm" → thiếu CreationPolicy (xem #11593) "private subnet gọi dịch vụ AWS" → NAT Gateway hoặc VPC endpoint

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance ra được mạng không | từ trong máy curl -I https://cloudformation.<region>.amazonaws.com | | Stack chờ bao lâu | xem Timeout trong CreationPolicy | | Đã tới bước nào | tab Events của stack, so mốc thời gian với log trong máy |

Và một mẹo giúp mọi lần gỡ lỗi sau này nhanh hơn: hãy thêm dòng exec > >(tee /var/log/user-data.log|logger -t user-data) 2>&1 vào đầu mọi script user data. Mặc định, đầu ra của user data nằm rải rác và dễ mất khi instance bị rollback xoá đi; ghi nó ra một tệp cố định (và đẩy sang CloudWatch Logs nếu được) nghĩa là lần sau bạn có bằng chứng để đọc, thay vì phải đoán.

Đáp án

C, D — hai kết quả khi deregister một AMI đã chia sẻ:

• D — KHÔNG khởi chạy được instance mới từ AMI đó, ở cả tài khoản A lẫn tài khoản B.
• C — Các instance ĐÃ khởi chạy từ AMI được chia sẻ ở tài khoản B KHÔNG bị ảnh hưởng.

Vì sao đúng

⚠ Điểm mấu chốt — AMI chỉ là "bản thiết kế", dùng lúc khởi chạy rồi thôi:

Khởi chạy instance từ AMI
        ↓
    EC2 tạo EBS volume từ snapshot của AMI
        ↓
    → từ giây phút đó instance KHÔNG còn phụ thuộc vào AMI
        ↓
Deregister AMI
        ↓
    → instance đang chạy: KHÔNG SAO CẢ  ← điều C
    → khởi chạy MỚI: thất bại ở MỌI tài khoản  ← điều D

⚠ Vì sao tài khoản B cũng không dùng được nữa:

Chia sẻ AMI KHÔNG tạo ra bản sao ở tài khoản B
        ↓
    Nó chỉ CẤP QUYỀN khởi chạy trên AMI của tài khoản A
        ↓
    AMI vẫn thuộc sở hữu tài khoản A
        ↓
    → A xoá thì B mất quyền dùng ngay lập tức

Đây là bài học kiến trúc quan trọng nhất của câu hỏi:

Muốn KHÔNG phụ thuộc vào bên chia sẻ
        ↓
    Tài khoản B phải COPY AMI về tài khoản mình
        aws ec2 copy-image --source-image-id ami-xxx \
            --source-region ap-southeast-1 \
            --region ap-southeast-1 --name "ban-sao-noi-bo"
        ↓
    → tạo AMI MỚI với id mới, snapshot mới, THUỘC SỞ HỮU B
    → A xoá bản gốc cũng không ảnh hưởng gì

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

• B (các instance khởi chạy từ AMI được chia sẻ ở tài khoản B bị "deregister") — đây là phương án gần nhất và nó mâu thuẫn trực tiếp với đáp án C. Instance không có khái niệm "deregister"; hơn nữa chúng hoàn toàn độc lập với AMI sau khi đã khởi chạy.

• A (chỉ tài khoản B khởi chạy được, AMI không hợp lệ ở tài khoản A) — ngược đời: AMI thuộc sở hữu tài khoản A. Xoá ở A thì B mất quyền trước tiên, không thể có chuyện ngược lại.

• E (copy AMI sang Region khác ở tài khoản B rồi tạo instance) — đây là một lời khuyên đúng nếu làm TRƯỚC khi AMI bị xoá, nhưng không phải "kết quả" của việc deregister. Sau khi AMI đã bị xoá thì không copy được nữa — không còn gì để copy.

Ghi nhớ

⚠ Chia sẻ và sao chép AMI — bảng phải thuộc: | | Chia sẻ (share) | Sao chép (copy) | |---|---|---| | Tạo AMI mới | không | có, id mới | | Ai sở hữu | vẫn là bên chia sẻ | bên sao chép | | Bên gốc xoá thì sao | mất quyền dùng ngay | không ảnh hưởng | | Tốn dung lượng | không | có, snapshot mới | | Sang Region khác | không được | được |

Từ khoá nhận diện:

"AMI bị xoá, instance đang chạy có sao không" → KHÔNG SAO "nhận AMI chia sẻ, muốn dùng lâu dài" → COPY về tài khoản mình "dùng AMI ở Region khác" → copy-image "AMI bị xoá thì ASG thế nào" → hỏng ở lần scale-out tiếp theo "khôi phục AMI đã xoá" → KHÔNG có, chỉ dựng lại từ snapshot

Ba việc kiểm chứng: | Việc | Cách | |---|---| | AMI còn dùng được không | describe-images --image-ids ami-xxx | | Ai đang trỏ vào AMI đó | rà launch template, launch configuration, CloudFormation template | | Snapshot có bị bỏ quên không | describe-snapshots --owner-ids self, đối chiếu với AMI còn sống |

Và một lời khuyên vận hành: hãy dùng deprecate-image trước, deregister-image sau — cách nhau vài tuần. Deprecation ẩn AMI khỏi danh sách và cảnh báo người dùng rằng nó sắp biến mất, nhưng vẫn cho khởi chạy bình thường. Còn deregister là một hành động không đảo ngược được, và hậu quả tệ nhất của nó thường không xảy ra ngay hôm đó — nó nằm im trong một Auto Scaling group cho tới đêm cao điểm tiếp theo, khi hệ thống cần thêm máy và không có máy nào lên được.

Đáp án

C — Dùng Volume Gateway của dịch vụ AWS Storage Gateway.

Vì sao đúng

Đề có một từ khoá quyết định: "iSCSI block device". Trong toàn bộ danh mục lưu trữ của AWS, chỉ Volume Gateway phục vụ giao thức iSCSI ở mức khối.

⚠ Điểm mấu chốt — mỗi loại Storage Gateway nói một giao thức khác nhau:

Volume Gateway  → iSCSI (block)        ← đề bài cần cái này
File Gateway    → NFS và SMB (tệp)
Tape Gateway    → iSCSI VTL (thư viện băng ảo)
FSx File Gateway → SMB, đệm cho FSx for Windows

⚠ Volume Gateway có HAI chế độ, và câu hỏi thường xoay quanh chỗ này:

Cached volumes
        ↓
    Dữ liệu CHÍNH nằm ở S3
    Chỉ phần hay dùng được đệm tại chỗ
        ↓
    → tiết kiệm hạ tầng tại chỗ nhiều nhất
    → mỗi volume tới 32 TB, tổng tới 1 PB

Stored volumes
        ↓
    TOÀN BỘ dữ liệu nằm tại chỗ
    Sao lưu bất đồng bộ lên S3 dạng EBS snapshot
        ↓
    → độ trễ thấp nhất (đọc hoàn toàn tại chỗ)
    → mỗi volume tới 16 TB, tổng tới 512 TB

Đề nêu hai mục tiêu — giảm chi phí hạ tầng tại chỗ và giữ độ trễ thấp — nên cached volumes là lựa chọn cân bằng nhất: dữ liệu nóng vẫn đọc từ bộ đệm tại chỗ, còn khối dữ liệu lớn nằm trên S3.

Và mục tiêu thứ ba của đề, khôi phục thảm hoạ, cũng được giải quyết luôn: snapshot trên AWS khôi phục thành EBS volume để khởi chạy hệ thống trên EC2 khi trung tâm dữ liệu gặp sự cố.

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

• D (File Gateway) — đây là phương án gần nhất vì cũng thuộc Storage Gateway, nhưng nó phục vụ NFS/SMB ở mức TỆP, còn đề nói rõ là iSCSI ở mức KHỐI. Ứng dụng đang gắn ổ đĩa khối thì không chuyển sang chia sẻ tệp mà không sửa ứng dụng được.

• A (dùng giao diện web service của S3) — S3 là lưu trữ đối tượng qua API HTTP, không phải thiết bị khối. Ứng dụng tại chỗ đang dùng iSCSI không nói được giao thức đó nếu không viết lại.

• B (Amazon EFS) — EFS là NFS, và quan trọng hơn: nó nằm trong VPC của AWS. Ứng dụng tại chỗ truy cập EFS qua Direct Connect hay VPN sẽ chịu độ trễ của đường truyền — đúng thứ mà đề muốn tránh.

Xem thêm câu #11603: cùng họ Storage Gateway nhưng ứng dụng tại chỗ dùng NFS mức tệp, khi đó câu trả lời là File Gateway. Phân biệt hai câu này là phân biệt khối với tệp.

Ghi nhớ

⚠ Bốn loại Storage Gateway — bảng phải thuộc: | Loại | Giao thức | Lưu vào | |---|---|---| | Volume Gateway | iSCSI (khối) | S3, hiện ra dạng EBS snapshot | | File Gateway (S3) | NFS, SMB | S3 — mỗi tệp là một đối tượng | | Tape Gateway | iSCSI VTL | S3 rồi Glacier / Deep Archive | | FSx File Gateway | SMB | FSx for Windows File Server |

Từ khoá nhận diện:

"iSCSI", "thiết bị khối", "block" → Volume Gateway "NFS", "SMB", "chia sẻ tệp" → File Gateway "phần mềm sao lưu ra băng từ" → Tape Gateway "toàn bộ dữ liệu phải ở tại chỗ" → Stored volumes "dữ liệu chính ở đám mây, đệm tại chỗ" → Cached volumes "đồng bộ dữ liệu một lần / định kỳ" → DataSync, không phải Storage Gateway

⚠ Storage Gateway khác DataSync thế nào — hay bị nhầm: | | Storage Gateway | DataSync | |---|---|---| | Mục đích | cầu nối LÂU DÀI, ứng dụng đọc ghi hằng ngày | di chuyển dữ liệu một lần hoặc định kỳ | | Cách dùng | mount như ổ đĩa hoặc chia sẻ tệp | chạy tác vụ đồng bộ | | Có đệm không | có | không |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bộ đệm có đủ không | chỉ số CachePercentUsed — đầy là hiệu năng tụt hẳn | | Dữ liệu đã lên AWS chưa | chỉ số WorkingStorageUsed và độ trễ upload | | Snapshot có chạy đúng lịch không | lịch snapshot của gateway |

Và một lời khuyên khi vận hành cached volumes: hãy theo dõi tỷ lệ trúng bộ đệm và cấp phát đĩa đệm rộng rãi ngay từ đầu. Toàn bộ lời hứa "độ trễ thấp" của kiến trúc này đứng trên giả định dữ liệu nóng nằm trong bộ đệm tại chỗ; khi bộ đệm quá nhỏ, mỗi lần đọc trượt phải đi vòng ra S3 và ứng dụng đột nhiên chậm đi hàng chục lần — mà không có lỗi nào xuất hiện ở đâu để chỉ ra nguyên nhân.

Đáp án

D — Bật ELB access log và truy vấn chúng bằng Amazon Athena.

Vì sao đúng

Đề đặt ra một ràng buộc nghiệt ngã: máy đã bị chấm dứt, không SSH vào được nữa. Vậy log phải nằm ở một nơi ngoài instance — và load balancer chính là nơi đó.

⚠ Điểm mấu chốt: ELB nhìn thấy mọi request, và nó vẫn ở đó sau khi instance biến mất:

Request → ELB → EC2 instance
                    ↓
            instance bị chaos testing giết
                    ↓
            → log trong máy mất theo
                    ↓
    Nhưng ELB đã ghi request đó vào S3 rồi
                    ↓
    → access log còn nguyên, độc lập với vòng đời instance

⚠ Access log ghi đúng thứ đề cần cho lỗi 4XX:

So sánh hai cột mã trạng thái là cách chẩn đoán nhanh nhất:

elb_status_code = 4XX, target_status_code = 4XX
        ↓
    → ứng dụng thật sự trả lỗi đó (đường dẫn sai, thiếu xác thực)

elb_status_code = 4XX, target_status_code = "-"
        ↓
    → ELB tự từ chối, request KHÔNG tới ứng dụng
    → ví dụ 400 do header hỏng, 401 từ listener rule

⚠ Athena đọc thẳng log trên S3, không cần dựng hạ tầng gì:

SELECT request_url, elb_status_code, count(*) AS so_lan
FROM alb_logs
WHERE elb_status_code LIKE '4%'
  AND day BETWEEN '2026/08/01' AND '2026/08/31'
GROUP BY request_url, elb_status_code
ORDER BY so_lan DESC
LIMIT 20;

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

• B (xem "EC2 default logs" trong CloudWatch Logs) — đây là phương án gần nhất và là hiểu nhầm rất phổ biến: EC2 KHÔNG tự đẩy log nào vào CloudWatch Logs. Muốn có log ứng dụng ở đó thì phải cài CloudWatch agent và cấu hình từ trước — mà đề không hề nói tới. (Nếu có làm việc đó thì đây cũng là một câu trả lời tốt.)

• C (dùng EC2 Rescue lấy log từ EBS volume đã bị xoá) — instance bị terminate thì volume gốc bị xoá theo (DeleteOnTermination: true là mặc định), và EBS đã xoá thì không khôi phục được. EC2Rescue cũng cần một volume còn tồn tại mới làm việc được.

• A (nhờ AWS Support khôi phục instance) — AWS không khôi phục instance đã chấm dứt. Đây là ranh giới rõ ràng của mô hình trách nhiệm chia sẻ.

Ghi nhớ

⚠ Log nằm ở đâu — bảng phải thuộc, đặc biệt với hạ tầng tạm bợ: | Nguồn | Lưu ở | Còn sau khi instance chết | |---|---|---| | ELB access log | S3 | CÒN | | VPC Flow Logs | S3 / CloudWatch Logs | CÒN | | CloudTrail | S3 / CloudWatch Logs | CÒN | | CloudWatch Logs (qua agent) | CloudWatch | CÒN | | Log trong /var/log của máy | EBS volume | MẤT khi terminate |

Từ khoá nhận diện:

"instance đã chết, cần log HTTP" → ELB access log + Athena "cần log ứng dụng sau khi máy chết" → CloudWatch agent, cấu hình TRƯỚC "ai chấp nhận/từ chối gói tin ở tầng mạng" → VPC Flow Logs "ai gọi API nào" → CloudTrail "EC2 tự có log trong CloudWatch" → LUÔN SAI

⚠ Ý nghĩa các mã lỗi của ALB — bảng đáng thuộc: | Mã | Nguyên nhân thường gặp | |---|---| | 400 | request hỏng, header sai định dạng | | 401 / 403 | listener rule, WAF, hoặc xác thực từ chối | | 460 | client ngắt kết nối trước khi ELB trả lời | | 463 | X-Forwarded-For có quá nhiều địa chỉ | | 502 | target trả về phản hồi không hợp lệ | | 503 | không có target khoẻ, hoặc target group rỗng | | 504 | target không trả lời kịp — so với idle timeout |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Access log đã bật chưa | thuộc tính access_logs.s3.enabled của load balancer | | Log có tới S3 không | xem bucket — chờ ít nhất 5 phút | | Truy vấn Athena có nhanh không | phân vùng theo ngày — không phân vùng là quét cả bucket, rất tốn |

Và một bài học rút ra từ chính triết lý chaos testing của công ty trong đề: nếu bạn cố tình giết máy chủ trong môi trường sản xuất, thì mọi thứ có giá trị chẩn đoán phải rời khỏi máy TRƯỚC khi nó chết. Chaos engineering chỉ dạy được điều gì đó khi bạn còn đọc được bằng chứng sau mỗi lần thử; giết máy mà không có đường ống log tập trung thì bạn chỉ đang phá hệ thống của chính mình một cách có lịch trình.

Đáp án

B — Dùng Aurora Reader Endpoint.

Vì sao đúng

Nguyên nhân sự cố nằm ở một mâu thuẫn hiển nhiên: địa chỉ CỐ ĐỊNH trỏ vào hạ tầng CO GIÃN.

⚠ Điểm mấu chốt — vì sao chuỗi kết nối trong Parameter Store trở nên vô nghĩa:

SSM Parameter Store lưu endpoint của một read replica cụ thể
        ↓
    Aurora Auto Scaling co lại (scale in)
        ↓
    → chính replica đó bị xoá
        ↓
    → endpoint đã lưu trỏ vào hư không
        ↓
    → ứng dụng mất kết nối hoàn toàn

⚠ Reader endpoint giải quyết tận gốc vì nó là một địa chỉ KHÔNG BAO GIỜ ĐỔI:

ten-cluster.cluster-ro-xxxx.<region>.rds.amazonaws.com
        ↓
    Aurora tự cập nhật DNS phía sau địa chỉ này
        ↓
    Thêm replica → tự đưa vào vòng phân phối
    Xoá replica → tự loại khỏi vòng phân phối
        ↓
    → ứng dụng dùng MỘT chuỗi kết nối duy nhất, mãi mãi

⚠ Aurora có BA loại endpoint — phải phân biệt:

Chính instance endpoint là thứ đã bị lưu nhầm vào Parameter Store và gây ra sự cố.

⚠ Một lưu ý về cách reader endpoint cân bằng tải:

Cân bằng theo KẾT NỐI, không theo truy vấn
        ↓
    Ứng dụng dùng connection pool giữ kết nối lâu dài
        ↓
    → tải có thể phân bố không đều
        ↓
    → cân nhắc tái tạo kết nối định kỳ, hoặc dùng RDS Proxy

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

• D (Lambda chạy cron cập nhật SSM bằng danh sách replica còn sống) — đây là phương án gần nhất và về lý thuyết thì làm được. Nhưng nó là bản tự chế của thứ Aurora đã cấp sẵn miễn phí, lại có độ trễ: giữa hai lần cron chạy vẫn có khoảng thời gian chuỗi kết nối sai. Đề hỏi cách "dễ và bền lâu" — thêm một Lambda phải bảo trì thì không phải.

• C (dựng Network Load Balancer trước các read replica) — chạy được nhưng thừa và tốn kém: thêm một tầng hạ tầng, thêm chi phí, thêm chỗ hỏng, để làm đúng việc mà reader endpoint đã làm. Ngoài ra target group cũng phải cập nhật khi replica thay đổi.

• A (tắt Aurora Auto Scaling) — "chữa" bằng cách vứt bỏ tính co giãn, trong khi đề nói rõ ứng dụng cần vẫn co giãn được. Đây là chữa triệu chứng bằng cách bỏ đi tính năng.

Ghi nhớ

⚠ Endpoint của Aurora — bảng phải thuộc: | Endpoint | Dạng tên | |---|---| | Cluster (writer) | ten.cluster-xxxx.<region>.rds.amazonaws.com | | Reader | ten.cluster-ro-xxxx.<region>.rds.amazonaws.com | | Instance | ten-instance-1.xxxx.<region>.rds.amazonaws.com | | Custom | ten-tuy-chinh.cluster-custom-xxxx... |

Từ khoá nhận diện:

"chia tải đọc, số replica thay đổi" → reader endpoint "ghi dữ liệu, cần tự chuyển khi failover" → cluster endpoint "lưu endpoint của một instance cụ thể" → LUÔN SAI trong hệ co giãn "quá nhiều kết nối, Lambda mở connection ồ ạt" → RDS Proxy "đọc ở Region khác" → Aurora Global Database

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng đang nối vào đâu | so chuỗi kết nối với describe-db-cluster-endpoints | | Tải có phân đều không | chỉ số DatabaseConnections theo từng instance | | Replica trễ bao nhiêu | AuroraReplicaLag — cao thì đọc ra dữ liệu cũ |

Và một cảnh báo về tính nhất quán khi dùng reader endpoint: replica của Aurora là bất đồng bộ, nên ghi xong rồi đọc ngay qua reader endpoint có thể không thấy dữ liệu vừa ghi. Độ trễ thường chỉ vài chục mili giây và phần lớn ứng dụng không bận tâm, nhưng những luồng kiểu "lưu rồi chuyển trang xem lại" thì phải đọc từ writer endpoint, nếu không người dùng sẽ thấy dữ liệu họ vừa nhập biến mất một cách khó hiểu.

Đáp án

B, C — hai việc cần làm trước ngày cao điểm:

• C — Mở yêu cầu hỗ trợ để TĂNG HẠN MỨC số lượng instance của loại EC2 đang dùng.
• B — Mở yêu cầu hỗ trợ để AWS "pre-warm" (làm nóng trước) load balancer.

Vì sao đúng

Chiến dịch dự kiến gấp 10 lần lưu lượng vào một ngày đã biết trước. Có hai trần cứng có thể chặn bạn lại, và cả hai chỉ gỡ được bằng cách báo trước cho AWS.

⚠ Trần thứ nhất — hạn mức instance của tài khoản:

Bình thường chạy 20 instance
        ↓
    Ngày cao điểm cần 200
        ↓
    Hạn mức vCPU của tài khoản không đủ
        ↓
    → ASG khởi chạy thất bại với VcpuLimitExceeded
        ↓
    → website sập ĐÚNG lúc chiến dịch thành công nhất

⚠ Trần thứ hai — bản thân load balancer cũng phải mở rộng:

ELB tự co giãn dựa trên lưu lượng QUAN SÁT ĐƯỢC
        ↓
    Nhưng nó co giãn TỪ TỪ, mất vài phút tới hàng chục phút
        ↓
    Lưu lượng tăng vọt gấp 10 trong vài phút
        ↓
    → ELB chưa kịp lớn → 503, kết nối bị từ chối
        ↓
Chữa: báo trước cho AWS Support để pre-warm
      (nêu ngày giờ, mức lưu lượng dự kiến, kích thước request)

Bên cạnh hai việc bắt buộc này, ba việc nên làm thêm:

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

• E (dùng weighted policy record của Route 53) — đây là phương án gần nhất vì Route 53 đúng là công cụ định tuyến. Nhưng weighted routing chia lưu lượng theo tỷ lệ giữa nhiều đích — dùng cho triển khai canary hay thử nghiệm A/B. Nó không tạo thêm dung lượng nào; chia 10 lần lưu lượng cho một hạ tầng quá tải vẫn là quá tải.

• A (bật triển khai Blue/Green cho Beanstalk) — là chiến lược triển khai phiên bản mới không gián đoạn. Rất tốt, nhưng không liên quan gì tới khả năng chịu tải.

• D (xin phép AWS để kiểm thử xâm nhập) — kiểm thử xâm nhập là việc bảo mật. Hơn nữa AWS đã cho phép sẵn kiểm thử xâm nhập trên hầu hết dịch vụ từ năm 2019, không cần xin phép nữa.

Ghi nhớ

⚠ Chuẩn bị cho sự kiện lưu lượng lớn — bảng phải thuộc: | Việc | Vì sao | |---|---| | Tăng hạn mức dịch vụ | Service Quotas — xin sớm, có thể mất vài ngày | | Pre-warm load balancer | ELB co giãn chậm hơn cú tăng đột ngột | | Scheduled scaling | có máy sẵn trước khi lưu lượng tới | | Capacity Reservation | đảm bảo có phần cứng ở AZ cần | | Kiểm thử tải | tìm nút thắt thật, thường là cơ sở dữ liệu | | Read replica / cache | giảm tải cho cơ sở dữ liệu |

Từ khoá nhận diện:

"lưu lượng tăng vọt vào ngày biết trước" → tăng hạn mức + pre-warm + scheduled scaling "pre-warm ELB" → phải mở ticket, không tự làm được "đảm bảo có dung lượng phần cứng" → On-Demand Capacity Reservation "chia lưu lượng theo tỷ lệ" → Route 53 weighted — không tạo thêm dung lượng "triển khai không gián đoạn" → blue/green

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hạn mức hiện tại | Service Quotas console, so với nhu cầu đỉnh | | ASG có được phép lớn tới đâu | tham số MaxSize — rất hay bị quên nâng | | Nút thắt thật nằm ở đâu | kiểm thử tải, xem chỉ số của cả ba tầng |

Và một lời khuyên rút ra từ kinh nghiệm chung của ngành: hãy nhớ nâng MaxSize của Auto Scaling group, không chỉ nâng hạn mức tài khoản. Đây là thứ bị quên nhiều nhất trong mọi buổi chuẩn bị sự kiện: AWS sẵn sàng cấp 500 instance, hạn mức đã xin xong, mọi biểu đồ đều xanh — nhưng ASG dừng lại ở đúng con số 20 mà ai đó đặt từ năm ngoái, và nó không phát ra lỗi nào ngoài một dòng lặng lẽ trong lịch sử hoạt động.

Đáp án

B — Dùng CloudTrail và Athena.

Vì sao đúng

Câu hỏi của đề là "ai đang dùng AWS nhiều nhất" — và trong toàn bộ danh mục AWS, chỉ CloudTrail ghi lại ai gọi API nào.

⚠ Điểm mấu chốt — mỗi bản ghi CloudTrail đều có danh tính người gọi:

Mỗi lời gọi API để lại một sự kiện chứa:
        userIdentity  → AI gọi (IAM user, role, người đóng vai)
        eventName     → gọi CÁI GÌ (RunInstances, CreateBucket...)
        eventTime     → LÚC NÀO
        eventSource   → dịch vụ nào
        sourceIPAddress, userAgent
        ↓
    → gom nhóm theo userIdentity là ra ngay bảng xếp hạng

⚠ Đưa CloudTrail vào S3 rồi truy vấn bằng Athena:

SELECT useridentity.username AS nguoi_dung,
       count(*) AS so_lan_goi,
       count(DISTINCT eventsource) AS so_dich_vu
FROM cloudtrail_logs
WHERE eventtime > '2026-08-01'
  AND useridentity.type = 'IAMUser'
GROUP BY useridentity.username
ORDER BY so_lan_goi DESC
LIMIT 20;

Cột so_dich_vu thực ra còn hợp với mục đích của đề hơn cả so_lan_goi: người dùng nhiều dịch vụ khác nhau thường là người hiểu AWS rộng nhất, trong khi một script tự động cũng có thể tạo ra hàng triệu lời gọi mà chẳng nói lên trình độ ai cả.

⚠ Hai lưu ý bắt buộc khi làm việc này:

1. Management event MIỄN PHÍ, nhưng lịch sử trên console
   chỉ giữ 90 NGÀY
        ↓
    → muốn phân tích dài hơn phải TẠO TRAIL đổ vào S3

2. Bảng Athena PHẢI phân vùng theo ngày
        ↓
    → không phân vùng thì mỗi truy vấn quét cả bucket
    → chậm và tốn tiền (Athena tính theo lượng dữ liệu quét)

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

• D (dùng "IAM usage report" và Athena) — đây là phương án gần nhất và nghe rất hợp lý, nhưng không có dịch vụ nào tên "IAM usage report". Thứ gần nhất là IAM Credential Report (báo cáo trạng thái chứng chỉ: MFA, tuổi mật khẩu, lần dùng khoá cuối) và Access Advisor (dịch vụ nào một principal đã truy cập). Cả hai đều không đếm được mức độ hoạt động như đề cần.

• A (VPC Flow Logs và Athena) — Flow Logs ghi lưu lượng mạng ở tầng IP: địa chỉ nguồn, đích, cổng, chấp nhận hay từ chối. Nó không biết danh tính người dùng nào cả.

• C (GuardDuty và Athena) — GuardDuty là dịch vụ phát hiện mối đe doạ; nó đọc CloudTrail nhưng chỉ xuất ra cảnh báo bảo mật, không phải thống kê hoạt động.

Ghi nhớ

⚠ Bốn nguồn log lớn của AWS — bảng phải thuộc: | Nguồn | Ghi lại | |---|---| | CloudTrail | AI gọi API nào, lúc nào | | VPC Flow Logs | gói tin đi từ đâu tới đâu, chấp nhận hay từ chối | | CloudWatch Logs | log do ứng dụng và dịch vụ đẩy lên | | ELB / S3 access log | request HTTP tới load balancer / bucket |

Từ khoá nhận diện:

"ai làm gì trên AWS" → CloudTrail "lưu lượng mạng bị chặn ở đâu" → VPC Flow Logs "phát hiện hành vi bất thường, đào tiền ảo" → GuardDuty "khoá nào lâu rồi không dùng" → IAM Credential Report "role này thực sự cần quyền gì" → IAM Access Advisor / Access Analyzer "truy vấn log trên S3 bằng SQL" → Athena

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trail có đang ghi không | get-trail-status, xem IsLogging | | Log có tới S3 không | xem tiền tố AWSLogs/<account>/CloudTrail/ | | Có ai xoá log không | bật log file validation và khoá bucket bằng Object Lock |

Và một lưu ý về diễn giải kết quả: đừng đánh đồng "gọi nhiều API" với "hiểu AWS giỏi". Bảng xếp hạng theo số lời gọi thường bị các tài khoản dịch vụ và script tự động chiếm trọn — một Lambda chạy mỗi phút sẽ vượt xa mọi kỹ sư trong công ty. Hãy lọc theo userIdentity.type = 'IAMUser', và xem thêm số dịch vụ khác nhau mà mỗi người chạm tới; đó mới là dấu hiệu của người thực sự đang khám phá nền tảng.

Đáp án

A — EC2 Spot Instances.

Vì sao đúng

Đề nêu chính xác các điều kiện của một workload lý tưởng cho Spot:

⚠ Điểm mấu chốt — Spot là dung lượng nhàn rỗi của AWS, và có thể bị lấy lại:

AWS còn máy trống → bán rẻ dưới dạng Spot
        ↓
    AWS cần lại máy đó
        ↓
    → gửi cảnh báo thu hồi trước 2 PHÚT
        ↓
    → instance bị dừng hoặc chấm dứt
        ↓
    → chỉ dùng được cho việc CHỊU ĐƯỢC gián đoạn

⚠ Bắt cảnh báo hai phút để lưu tiến độ:

# Đọc metadata trong máy — trường này xuất hiện khi sắp bị thu hồi
TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/spot/instance-action

Với công việc như đề mô tả, kiến trúc tốt là lưu tiến độ định kỳ (checkpoint) lên S3 — bị thu hồi thì lần chạy sau đọc lại và đi tiếp từ đó.

⚠ Cách dùng Spot an toàn nhất trong thực tế:

Đừng khai một loại instance duy nhất
        ↓
    Dùng ASG với chính sách hỗn hợp:
        - nhiều loại instance (m5.large, m5a.large, m6i.large...)
        - nhiều Availability Zone
        - chiến lược phân bổ capacity-optimized
        ↓
    → giảm mạnh xác suất bị thu hồi cùng lúc

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

• D (Reserved Instances) — đây là phương án gần nhất vì cũng là cách giảm giá thật. Nhưng RI đòi cam kết 1 hoặc 3 năm và tối ưu cho workload chạy liên tục 24/7. Công việc của đề chỉ chạy một lần mỗi ngày, nên mua RI là trả tiền cho những giờ không dùng — với Savings Plans cũng vậy.

• C (On-Demand) — chạy được, không cam kết gì, nhưng đắt nhất. Đề hỏi cách giữ chi phí thấp, và workload này thoả mọi điều kiện của Spot.

• B (EC2 Placement Group kiểu Cluster) — không phải một mô hình giá. Placement group quyết định vị trí vật lý của instance để giảm độ trễ mạng; nó không rẻ hơn hay đắt hơn.

Ghi nhớ

⚠ Năm mô hình giá EC2 — bảng phải thuộc: | Mô hình | Giảm giá | Cam kết | Dùng cho | |---|---|---|---| | On-Demand | không | không | tải bất thường, thử nghiệm ngắn | | Savings Plans | tới 72% | 1 hoặc 3 năm | tải ổn định, linh hoạt loại máy | | Reserved Instance | tới 72% | 1 hoặc 3 năm | tải ổn định, cố định hơn | | Spot | tới 90% | không | chịu được gián đoạn | | Dedicated Host | — | tuỳ | yêu cầu tuân thủ, giấy phép theo socket |

Từ khoá nhận diện:

"chịu lỗi", "chạy lại được", "xử lý theo lô" → Spot "chạy 24/7, ổn định lâu dài" → Savings Plans / RI "không được gián đoạn" → KHÔNG dùng Spot "đảm bảo có dung lượng" → Capacity Reservation (không giảm giá) "độ trễ mạng thấp giữa các máy" → cluster placement group

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Loại nào ít bị thu hồi | Spot Instance Advisor — xem tần suất bị thu hồi | | Đang tiết kiệm bao nhiêu | Cost Explorer, lọc theo purchase option | | Bị thu hồi lúc nào | EventBridge sự kiện EC2 Spot Instance Interruption Warning |

Và một lời khuyên khi bắt đầu dùng Spot: hãy khai càng nhiều loại instance càng tốt trong ASG, thay vì chọn đúng một loại rẻ nhất. Rủi ro thật của Spot không phải là bị thu hồi — chuyện đó nằm trong thiết kế — mà là bị thu hồi toàn bộ cùng lúc, điều gần như chắc chắn xảy ra khi cả nhóm máy của bạn nằm trong đúng một nhóm dung lượng. Mười loại instance trải trên ba AZ thì rất hiếm khi cạn cùng một lúc.

Đáp án

B — Bật S3 Access Logs và phân tích chúng bằng Amazon Athena.

Vì sao đúng

Đề có hai yêu cầu, và yêu cầu thứ hai mới là chỗ loại bỏ các phương án khác: "mà họ không nhận ra".

⚠ Điểm mấu chốt — access log ghi lại cả những lần truy cập BỊ TỪ CHỐI:

Nhân viên thử mở một tệp không có quyền
        ↓
    S3 từ chối → HTTP 403 AccessDenied
        ↓
    Nhưng lần thử đó VẪN được ghi vào access log
        ↓
    → có bằng chứng ai thử, thử tệp nào, lúc nào
    → và họ hoàn toàn không biết mình đang bị ghi lại

Truy vấn tìm ra ngay:

SELECT requester, key, operation, remoteip,
       count(*) AS so_lan_thu
FROM s3_access_logs
WHERE httpstatus = '403'
GROUP BY requester, key, operation, remoteip
ORDER BY so_lan_thu DESC;

⚠ Vì sao "âm thầm" lại quan trọng đến vậy:

Siết quyền TRƯỚC khi điều tra
        ↓
    → người đó thấy lỗi mới, biết mình bị để ý
        ↓
    → dừng lại, hoặc đổi cách làm
        ↓
    → mất luôn bằng chứng cần cho quy trình xử lý nội bộ

Bật ghi log rồi lặng lẽ quan sát
        ↓
    → không có gì thay đổi từ góc nhìn của họ
    → thu được đủ chứng cứ trước khi hành động

Đây cũng là nguyên tắc chung của điều tra sự cố nội bộ: quan sát trước, can thiệp sau.

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

• A (siết chính sách IAM của họ rồi xem log CloudTrail) — đây là phương án gần nhất và vế CloudTrail là một công cụ hợp lệ (data event ghi cả AccessDenied). Nhưng vế đầu phá hỏng yêu cầu quan trọng nhất: siết quyền là một thay đổi người dùng nhìn thấy ngay. Đề nói rõ phải làm mà họ không nhận ra.

• C (dùng AWS Config để định nghĩa quy tắc tuân thủ cho những người dùng này) — hiểu sai công dụng: AWS Config đánh giá CẤU HÌNH tài nguyên, nó không ghi lại hành vi truy cập của ai cả.

• D (dùng bucket policy) — bucket policy là công cụ thực thi quyền, không phải công cụ ghi nhận. Nó lại càng là thứ người dùng sẽ nhận ra ngay.

Ghi nhớ

⚠ Hai cách ghi nhật ký truy cập S3 — bảng phải thuộc: | | Server Access Logging | CloudTrail Data Events | |---|---|---| | Chi phí | miễn phí (trả tiền lưu log) | có phí theo sự kiện | | Độ trễ | vài giờ | gần thời gian thực | | Ghi lần bị từ chối | có | có | | Thông tin identity | ít hơn | chi tiết hơn (role, session) | | Cảnh báo tự động | không sẵn | EventBridge, CloudWatch |

Xem thêm câu #11585: cùng công cụ này nhưng hỏi ở góc chi phí — vì sao Server Access Logging được chọn thay cho CloudTrail data event khi ngân sách eo hẹp.

Từ khoá nhận diện:

"phát hiện truy cập trái phép mà không để lộ" → bật log, KHÔNG đổi quyền "cần cảnh báo ngay khi có 403" → CloudTrail data event + EventBridge "quyền nào đang thừa" → IAM Access Analyzer / Access Advisor "bucket có bị mở ra ngoài không" → IAM Access Analyzer for S3 "phát hiện hành vi bất thường tự động" → GuardDuty (có nhóm phát hiện cho S3)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Log đã bật chưa | get-bucket-logging --bucket <ten> | | Log có tới không | xem bucket đích — chờ vài giờ | | Truy vấn có bỏ sót không | access log là best effort, nên đối chiếu thêm CloudTrail nếu vụ việc nghiêm trọng |

Và một lưu ý về mặt con người, không phải kỹ thuật: hãy phối hợp với bộ phận nhân sự và pháp chế trước khi giám sát một nhân viên cụ thể. Về kỹ thuật thì bật access log là chuyện của vài phút, nhưng thu thập bằng chứng nhắm vào một cá nhân là việc có ràng buộc pháp lý ở nhiều nơi, và bằng chứng thu được sai quy trình thì thường không dùng được vào đúng lúc bạn cần tới nó nhất.

Đáp án

C — File Gateway.

Vì sao đúng

Đề nêu ba manh mối, và cả ba đều chỉ về cùng một dịch vụ:

⚠ Điểm mấu chốt — File Gateway biến S3 thành một thư mục chia sẻ:

Máy chủ tại chỗ mount NFS như bình thường
        mount -t nfs <ip-gateway>:/du-lieu /mnt/du-lieu
        ↓
    File Gateway nhận thao tác đọc/ghi tệp
        ↓
    MỖI TỆP thành MỘT ĐỐI TƯỢNG trong bucket S3
        ↓
    Tệp hay dùng nằm trong bộ đệm đĩa tại chỗ
        ↓
    → ứng dụng không phải sửa một dòng mã nào

⚠ Đặc điểm quan trọng nhất và cũng hữu ích nhất:

Tệp lưu trên S3 ở ĐỊNH DẠNG GỐC, một-đối-một
        ↓
    → mở được thẳng từ S3 console, từ ứng dụng khác, từ Athena
        ↓
    Khác hẳn Volume Gateway: dữ liệu ở đó là
    EBS snapshot, KHÔNG đọc trực tiếp từ S3 được

Đây chính là lý do File Gateway thường được chọn cho dữ liệu cần dùng tiếp trên đám mây — hồ dữ liệu, kho ảnh, kho tài liệu.

Xem thêm câu #11596: cùng họ Storage Gateway nhưng hỏi tình huống ngược lại — ứng dụng dùng iSCSI mức khối, khi đó câu trả lời là Volume Gateway. Phân biệt hai câu này là phân biệt tệp với khối.

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 là Storage Gateway và cũng có bộ đệm tại chỗ. Nhưng nó phục vụ iSCSI ở mức KHỐI, còn đề nói rõ đang thay thế một ổ NFS. Và dữ liệu của nó nằm dưới dạng snapshot, không phải tệp đọc được trên S3.

• D (EFS) — EFS đúng là NFS, nhưng nó nằm trong VPC của AWS. Máy chủ tại chỗ truy cập nó phải đi qua Direct Connect hoặc VPN, chịu độ trễ đường truyền, và không có bộ đệm tại chỗ — trái với yêu cầu của đề.

• B (ổ EBS) — EBS chỉ gắn được vào EC2 instance, không có cách nào mount từ trung tâm dữ liệu tại chỗ.

Ghi nhớ

⚠ Bốn loại Storage Gateway — bảng phải thuộc: | Loại | Giao thức | Dữ liệu trên AWS trông thế nào | |---|---|---| | File Gateway (S3) | NFS, SMB | đối tượng S3 ở định dạng gốc | | Volume Gateway | iSCSI (khối) | EBS snapshot | | Tape Gateway | iSCSI VTL | băng ảo trong S3/Glacier | | FSx File Gateway | SMB | FSx for Windows File Server |

Từ khoá nhận diện:

"NFS/SMB tại chỗ, muốn lưu lên S3" → File Gateway "iSCSI, thiết bị khối" → Volume Gateway "muốn đọc tệp thẳng từ S3 sau đó" → File Gateway "phần mềm sao lưu ra băng từ" → Tape Gateway "chia sẻ tệp cho EC2 trong VPC" → EFS (Linux) hoặc FSx (Windows) "di chuyển dữ liệu một lần" → DataSync

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bộ đệm còn chỗ không | chỉ số CachePercentUsed | | Dữ liệu đã lên S3 chưa | CloudBytesUploaded, và xem thẳng bucket | | Client có thấy tệp mới không | nếu ghi ngoài gateway thì phải RefreshCache |

Và một lời cảnh báo về cạm bẫy hay gặp nhất khi vận hành File Gateway: đừng để hai đường ghi cùng tồn tại vào một bucket. Khi có ứng dụng ghi thẳng vào S3 còn máy chủ tại chỗ ghi qua gateway, hai bên nhìn thấy hai phiên bản khác nhau của cùng một thư mục, và không có cảnh báo nào cho biết chúng đã lệch nhau — chỉ có những tệp "biến mất" một cách bí ẩn với một bên trong khi bên kia khẳng định chúng vẫn ở đó.