Ngân hàng đề — AWS Certified CloudOps Engineer Associate

🧩 Phân tích nội dung câu hỏi

Đề mô tả một SysOps Administrator cập nhật một CloudFormation stack production, bản cập nhật thất bại, và stack rơi vào trạng thái UPDATE_ROLLBACK_FAILED. Yêu cầu là đưa stack trở lại trạng thái hoạt động trước đó mà không mất các tài nguyên đang tồn tại.

Có ba cụm từ quyết định đáp án, phải đọc cùng nhau:

• UPDATE_ROLLBACK_FAILED — đây không phải một stack đang bình thường. Đó là trạng thái CloudFormation rơi vào khi nó không hoàn tất được việc rollback các thay đổi của một lần update. Ở trạng thái này, CloudFormation cố ý hạn chế các thao tác thông thường, vì stack đang ở giữa chừng một lần rollback dở dang.
• "production" — không được phép làm gián đoạn hay xoá dịch vụ đang chạy.
• "without the loss of existing resources" — loại thẳng mọi phương án có xoá và dựng lại.

Cụm từ mấu chốt nhất là UPDATE_ROLLBACK_FAILED. Câu hỏi thực chất kiểm tra: bạn có biết CloudFormation có một hành động chuyên dụng cho đúng trạng thái này hay không.

✅ Vì sao đáp án đúng là đúng

Phương án A — sửa nguyên nhân gây lỗi, rồi chọn Continue Update Rollback trong console.

Đây chính là quy trình mà CloudFormation thiết kế riêng cho trạng thái UPDATE_ROLLBACK_FAILED. Hành động Continue Update Rollback (trong console, hoặc lệnh continue-update-rollback của AWS CLI) khả dụng cho mọi stack đang ở trạng thái này. Nó bảo CloudFormation thử lại việc rollback từ chỗ đã dừng, để đưa stack về UPDATE_ROLLBACK_COMPLETE — tức là về đúng cấu hình hoạt động trước lần update hỏng, mà không phải xoá và dựng lại tài nguyên.

Điểm quan trọng là thứ tự hai bước: sửa nguyên nhân trước, rồi mới continue. CloudFormation rollback thất bại là vì một thao tác nào đó nó cần làm đã không làm được — ví dụ vướng hạn mức (service limit) của một loại tài nguyên. Trong trường hợp đó, phải xin nâng hạn mức hoặc xoá bớt tài nguyên để nằm trong giới hạn, sau đó mới gọi continue update rollback. Nếu bấm continue mà nguyên nhân gốc còn nguyên, rollback sẽ vấp lại đúng chỗ cũ và stack lại rơi về UPDATE_ROLLBACK_FAILED.

Đây cũng là phương án duy nhất thoả mãn cả hai ràng buộc của đề: đưa stack về trạng thái làm việc trước đó, và giữ nguyên tài nguyên hiện có.

❌ Vì sao các phương án còn lại sai

B — Chọn Update Stack với một template chạy được.

Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Với một stack lành lặn, "sửa template rồi update lại" đúng là cách xử lý tự nhiên. Nhưng nó hỏng ở chỗ: UPDATE_ROLLBACK_FAILED không phải trạng thái cho phép update. CloudFormation coi stack đang ở giữa một lần rollback chưa xong, nên hành động Update Stack không dùng được ở đây. Phải đưa stack ra khỏi trạng thái đó — bằng chính Continue Update Rollback — rồi mới nói tới chuyện update tiếp.

C — Xoá stack rồi tạo lại bằng template gốc.

Về lý thuyết thì cuối cùng cũng ra một stack chạy được, nhưng nó vi phạm trực tiếp ràng buộc đề bài: xoá stack sẽ huỷ các tài nguyên đang tồn tại. Đây là stack production — dữ liệu trên các tài nguyên đó, cùng với thời gian gián đoạn dịch vụ, là cái giá không chấp nhận được. Đề đã nói rõ "without the loss of existing resources", nên phương án này bị loại ngay cả trước khi bàn tới tính khả thi.

D — Dùng AWS CLI đổi tay trạng thái stack sang UPDATE_COMPLETE, rồi update tiếp.

Sai ở hai tầng. Thứ nhất, trạng thái stack là thứ CloudFormation tự quản lý theo kết quả thực tế của các thao tác; không có chuyện người dùng gán tay một stack đang hỏng thành UPDATE_COMPLETE. Thứ hai — và đây mới là điểm cốt lõi — kể cả giả sử làm được thì cũng chỉ là che triệu chứng: nguyên nhân khiến rollback thất bại vẫn còn nguyên đó, tài nguyên thật ngoài đời vẫn đang ở trạng thái dở dang, chỉ có nhãn trạng thái là bị nói dối. Lệnh CLI đúng cho tình huống này là continue-update-rollback, không phải một lệnh đổi trạng thái tuỳ ý.

📌 Điểm cần nhớ

• Thấy UPDATE_ROLLBACK_FAILED trong đề thì phản xạ đầu tiên là Continue Update Rollback — đây là hành động CloudFormation làm ra để phục vụ đúng trạng thái này, dùng được cả ở console lẫn CLI (continue-update-rollback).
• Luôn có hai bước, không được đảo: sửa nguyên nhân gốc trước (hạn mức, quyền, tài nguyên bị khoá…), rồi mới continue. Bấm continue khi lỗi còn nguyên chỉ khiến rollback thất bại lại.
• UPDATE_ROLLBACK_FAILED là trạng thái không cho phép Update Stack. Bất kỳ phương án nào bảo "update lại bằng template đúng" mà bỏ qua bước gỡ stack khỏi trạng thái này đều sai.
• Đề nhắc "production" hoặc "without loss of existing resources" là tín hiệu loại ngay các phương án xoá–dựng lại, dù chúng nghe có vẻ dứt điểm.
• Trạng thái của stack do CloudFormation quyết định theo kết quả thao tác thật; đừng chọn phương án nào hứa hẹn "đổi trạng thái bằng tay" — đó là bẫy nhận biết trong đề CloudFormation.

🧩 Phân tích nội dung câu hỏi

Ứng dụng chạy trên các EC2 instance nằm ở nhiều Availability Zone, đứng sau một internet-facing Application Load Balancer. SysOps Administrator cần theo dõi hai thứ cùng lúc cho từng request:

1. IP gốc của client gửi request (originating IP address), và
2. EC2 instance nào đã xử lý chính request đó.

Cụm từ quyết định đáp án là "of each application request" — tức là dữ liệu phải ở mức từng request HTTP (tầng 7), chứ không phải số liệu tổng hợp hay luồng gói tin. Cụm thứ hai cũng quan trọng không kém: "the originating IP address ... and the EC2 instance that processes it" — cần cặp client ↔ target trong cùng một bản ghi. Chỉ có nguồn log nào ghi lại đồng thời hai đầu của một request mới thoả mãn.

Thêm một chi tiết cần để ý: ALB là internet-facing, nên client nằm ngoài VPC và kết nối của client kết thúc tại ALB. Đây chính là chi tiết loại bỏ phương án B.

✅ Vì sao đáp án đúng là đúng

A — The ALB access logs. Elastic Load Balancing cung cấp access logs ghi lại thông tin chi tiết về từng request gửi tới load balancer. Mỗi dòng log chứa trường client:port — địa chỉ IP và cổng của client gửi request — và trường target:port — địa chỉ IP và cổng của target (ở đây là EC2 instance) đã xử lý request đó.

Đúng một bản ghi cho ta cả hai thông tin đề bài hỏi, và đúng ở mức từng request. Access logs của ALB là tính năng tuỳ chọn, bật lên thì log được ghi vào một S3 bucket do bạn chỉ định, sau đó phân tích được bằng các công cụ truy vấn thông thường.

❌ Vì sao các phương án còn lại sai

B — VPC Flow Logs. Đây là phương án gần đúng nhất và cũng là cái bẫy chính, vì Flow Logs đúng là có ghi source IP và destination IP. Chỗ nó hỏng nằm ở kiến trúc: ALB là internet-facing, kết nối TCP từ client kết thúc tại ALB; ALB mở một kết nối mới tới target. Vì vậy luồng traffic mà Flow Logs quan sát được bên trong VPC là giữa ENI của ALB và EC2 instance, không phải giữa client và instance. IP gốc của client không xuất hiện ở đó. Ngoài ra Flow Logs làm việc ở mức luồng gói tin (tầng mạng), không có khái niệm "request" của ứng dụng.

C — AWS CloudTrail. CloudTrail ghi lại các lời gọi API tới AWS phục vụ mục đích kiểm toán — ai gọi API nào, lúc nào, từ đâu. Request của người dùng cuối tới ứng dụng chạy trên EC2 hoàn toàn không phải là API call của AWS, nên không bao giờ xuất hiện trong CloudTrail. Nhầm lẫn hay gặp: thấy "track" và "IP address" liền nghĩ tới CloudTrail, nhưng IP trong CloudTrail là IP của người gọi API AWS, không phải khách truy cập ứng dụng.

D — Amazon CloudWatch. CloudWatch theo dõi metric hiệu năng — số lượng request, độ trễ, số mã lỗi HTTP theo nhóm, tình trạng health check của target. Đây là dữ liệu đã được tổng hợp, không đi kèm thông tin định danh từng kết nối. Nó trả lời được "có bao nhiêu request và chậm bao nhiêu", chứ không trả lời được "request này đến từ IP nào và instance nào xử lý".

📌 Điểm cần nhớ

• ALB access logs là nguồn duy nhất trong danh sách ghi cặp client:port và target:port cho từng request — hỏi "IP client + instance xử lý" thì chọn nó.
• Với internet-facing ALB, kết nối của client kết thúc tại load balancer; mọi thứ quan sát bên trong VPC chỉ thấy ALB ↔ target. Đây là lý do VPC Flow Logs không bao giờ thấy được IP gốc của client trong kiến trúc này.
• Phân biệt ba nguồn dữ liệu theo loại thông tin, không theo tên: CloudTrail = API call của AWS (kiểm toán), CloudWatch = metric hiệu năng tổng hợp, access logs = chi tiết từng request tầng 7.
• Từ khoá "each request" / "từng request" trong đề gần như luôn loại bỏ mọi nguồn dữ liệu dạng metric tổng hợp.

🧩 Phân tích nội dung câu hỏi

Một công ty vận hành rất nhiều EC2 instance và cần một hệ thống tự động báo cho đội vận hành mỗi khi trạng thái của một EC2 instance thay đổi (pending → running → stopping → stopped → terminated…).

Ba cụm từ trong đề quyết định đáp án:

• "a change in the state of an EC2 instance" — đây là sự kiện (event) xảy ra tại một thời điểm, không phải một cấu hình cần được đánh giá theo chuẩn, cũng không phải một trạng thái mong muốn cần được duy trì. Dịch vụ nào sinh ra và định tuyến event thì dịch vụ đó thắng.
• "automated system" — loại ngay mọi phương án còn dính tay người.
• "most efficient solution" — trong đề thi AWS, "efficient" ở đây gần như luôn có nghĩa là ít công vận hành nhất: dùng tính năng có sẵn, không viết code, không phải bảo trì thứ gì.

Khi ba ràng buộc này đứng cạnh nhau, câu hỏi thực chất là: dịch vụ nào của AWS nhận EC2 instance state-change event một cách tự nhiên và đẩy thẳng sang một kênh thông báo?

✅ Vì sao đáp án đúng là đúng

B — Tạo một Amazon EventBridge rule bắt sự kiện đổi trạng thái EC2 và trỏ target vào một Amazon SNS topic.

EC2 tự phát ra event khi instance đổi trạng thái, và những event đó đi thẳng vào event bus mặc định của EventBridge. Việc của người quản trị chỉ là viết một rule khớp với loại event đó rồi chọn target — ở đây là một SNS topic. Toàn bộ đội vận hành subscribe vào topic (email, SMS, HTTPS endpoint…) là nhận được thông báo.

Đây là giải pháp hiệu quả nhất vì:

• Hoàn toàn không có code: rule là cấu hình dạng pattern khớp event, không phải script phải nuôi.
• Không có hạ tầng phải quản lý: cả EventBridge lẫn SNS đều là dịch vụ được quản lý, không có instance nào đứng canh.
• Tự nhiên theo sự kiện: không polling, không quét định kỳ — có đổi trạng thái thì có thông báo.
• Mở rộng tốt cho "numerous EC2 instances": một rule ở cấp tài khoản/Region áp cho toàn bộ instance, không cần cấu hình từng máy.
• SNS lo phần fan-out: thêm hay bớt người nhận chỉ là thêm/bớt subscription, không đụng tới rule.

❌ Vì sao các phương án còn lại sai

A — AWS Config theo dõi và ghi lại cấu hình EC2, cảnh báo qua SNS khi trạng thái đổi.

Đây là phương án gần đúng nhất và cũng là bẫy nặng nhất, vì AWS Config thật sự có tích hợp SNS. Nhưng vai trò của Config là đánh giá, kiểm toán và ghi lịch sử cấu hình tài nguyên — nó trả lời câu hỏi "tài nguyên này có tuân thủ chuẩn không, cấu hình của nó đã đổi thế nào theo thời gian". Nó không phải công cụ cảnh báo tức thời cho các chuyển trạng thái vòng đời của EC2. Dùng Config cho việc này là chọn một dịch vụ audit để làm việc của một dịch vụ event, kèm theo chi phí ghi nhận cấu hình mà mục tiêu bài toán không cần.

C — AWS Systems Manager State Manager tự gửi tin nhắn SNS khi EC2 chuyển trạng thái.

Sai vì hiểu nhầm chữ "State". State Manager giữ instance ở trạng thái mong muốn mà bạn định nghĩa — ví dụ đảm bảo một agent luôn được cài, một service luôn chạy, cấu hình luôn khớp baseline. Nó là công cụ thực thi cấu hình, không phải công cụ quan sát vòng đời instance. Nó không đứng nghe các chuyển trạng thái running/stopped/terminated để phát cảnh báo, nên mô tả trong phương án này không phản ánh đúng chức năng của dịch vụ.

D — Viết script tuỳ biến theo dõi qua AWS CloudTrail rồi gửi email thủ công.

Về lý thuyết thì có thể chạy được — CloudTrail có ghi lại các API call liên quan. Nhưng phương án này hỏng ở hai chỗ ngay trong đề:

• Chữ "manually send emails" mâu thuẫn trực tiếp với yêu cầu "automated system".
• Chữ "custom script" kéo theo công viết, công bảo trì, chỗ để chạy nó, và cả rủi ro nó chết âm thầm — trái hẳn với "most efficient".

Ngoài ra CloudTrail thiên về ghi nhận ai gọi API nào, nên nó là nguồn kiểm toán chứ không phải kênh thông báo thời gian thực.

📌 Điểm cần nhớ

• Đề nói "khi có sự kiện xảy ra thì thông báo/kích hoạt" → nghĩ ngay tới EventBridge rule + target. Mẫu EventBridge → SNS là công thức chuẩn cho "báo cho đội vận hành biết".
• Phân biệt ba dịch vụ hay bị lẫn: EventBridge = phản ứng theo sự kiện gần thời gian thực; AWS Config = đánh giá tuân thủ và lịch sử cấu hình; CloudTrail = nhật ký ai gọi API nào. Cùng nhìn vào tài nguyên, nhưng trả lời ba câu hỏi khác nhau.
• State Manager trong Systems Manager là duy trì trạng thái mong muốn, không phải theo dõi trạng thái instance. Chữ "State" trùng nhau nhưng nghĩa khác hẳn.
• Khi đề dùng chữ "most efficient" / "least operational overhead", phương án chứa custom script, cron tự viết, hay thao tác thủ công gần như luôn sai — dù về kỹ thuật nó chạy được.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một ứng dụng lỗi làm CPU của Amazon EC2 instance chạy ở mức 100%, và yêu cầu tự động reboot instance khi tình trạng đó kéo dài hơn 3 phút.

Cụm từ quyết định đáp án là "for a duration longer than 3 minutes" — nó nói về độ phân giải thời gian của dữ liệu đo, chứ không phải về công cụ. Muốn một CloudWatch alarm khẳng định được "CPU 100% suốt hơn 3 phút", alarm phải có đủ điểm dữ liệu nằm gọn trong khoảng 3 phút đó. Đây chính là ranh giới giữa basic monitoring và detailed monitoring của EC2: basic monitoring đẩy metric theo chu kỳ 5 phút, detailed monitoring đẩy theo chu kỳ 1 phút.

Cụm thứ hai là "MOST effective" — trong bốn phương án có hai hướng: CloudWatch alarm (native, không cần code) và AWS Lambda (phải tự viết và tự nuôi logic). Khi CloudWatch đã làm được đúng việc thì hướng Lambda không còn là lựa chọn hiệu quả nhất.

✅ Vì sao đáp án đúng là đúng

C — CloudWatch alarm với detailed monitoring, action là reboot instance.

Detailed monitoring thu metric của EC2 instance ở chu kỳ 1 phút. Với dữ liệu 1 phút, alarm đặt trên CPUUtilization có thể cấu hình period 1 phút và yêu cầu nhiều điểm dữ liệu liên tiếp vượt ngưỡng, nhờ đó diễn đạt chính xác được điều kiện "100% kéo dài hơn 3 phút" — alarm chỉ chuyển sang trạng thái ALARM khi tình trạng thực sự duy trì qua khoảng thời gian đó, chứ không nổ vì một đỉnh nhất thời.

CloudWatch alarm còn hỗ trợ sẵn EC2 action, trong đó có hành động reboot áp lên chính instance đang được theo dõi. Không cần viết code, không cần hạ tầng thi hành riêng: phát hiện và hành động nằm trong cùng một cấu hình. Đó là lý do đây là cách "MOST effective".

❌ Vì sao các phương án còn lại sai

A — CloudWatch alarm với basic monitoring. Đây là phương án gần đúng nhất, và nó hỏng ở đúng một chỗ: độ phân giải metric. Basic monitoring gửi metric theo chu kỳ 5 phút, nên điểm dữ liệu ngắn nhất mà alarm có được đã dài hơn cả cửa sổ 3 phút mà đề yêu cầu. Không có cách nào ghép các điểm 5 phút lại để khẳng định "CPU 100% suốt hơn 3 phút" — hoặc phải chờ ít nhất một chu kỳ 5 phút (phản ứng chậm hơn yêu cầu), hoặc phải suy diễn từ dữ liệu không tồn tại. Cấu trúc giải pháp đúng, dữ liệu đầu vào không đủ mịn.

B — Lambda reboot, kích hoạt bởi EC2 instance status checks. Sai vì status check không đo CPU. Instance status check kiểm tra sức khoẻ của chính VM (hệ điều hành, cấu hình mạng/hệ thống tệp của instance), còn system status check kiểm tra hạ tầng vật lý bên dưới. Một instance chạy CPU 100% do ứng dụng lỗi vẫn hoàn toàn có thể pass cả hai status check — nó vẫn sống, vẫn phản hồi, chỉ là bận. Nghĩa là điều kiện kích hoạt sẽ không bao giờ xảy ra trong kịch bản của đề.

D — Lambda reboot theo lịch mỗi 3 phút. Sai vì nó bỏ hẳn phần điều kiện. Con số 3 phút trong đề là thời lượng của một trạng thái lỗi, không phải chu kỳ chạy. Phương án này reboot instance cứ mỗi 3 phút bất kể CPU đang ở mức nào — instance khoẻ mạnh cũng bị khởi động lại liên tục, và hệ thống thực tế sẽ không bao giờ ổn định. Đây là bẫy đọc lướt con số trong đề rồi khớp thẳng vào tham số lịch.

📌 Điểm cần nhớ

• Khi đề nêu một khoảng thời gian ngắn hơn 5 phút cho việc phát hiện qua CloudWatch metric của EC2, gần như chắc chắn đáp án là detailed monitoring (chu kỳ 1 phút); basic monitoring dùng chu kỳ 5 phút nên không diễn đạt nổi điều kiện đó.
• EC2 status check ≠ metric hiệu năng. Status check trả lời "instance/hạ tầng còn sống không", không trả lời "CPU, memory hay disk đang thế nào". Câu nào hỏi về mức sử dụng tài nguyên mà phương án đề xuất status check thì loại được ngay.
• CloudWatch alarm có sẵn EC2 action (reboot, stop, terminate, recover). Khi vẫn còn cách làm bằng alarm native mà phương án khác phải viết AWS Lambda, tiêu chí "MOST effective / operationally efficient" nghiêng về alarm.
• Phân biệt thời lượng của điều kiện lỗi với chu kỳ chạy của một job. Lịch chạy định kỳ không thay thế được ngưỡng theo dõi: nó hành động vô điều kiện, kể cả khi hệ thống hoàn toàn bình thường.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một ứng dụng chạy trên EC2 trong Auto Scaling group, đứng sau Application Load Balancer (ALB). Ứng dụng bắt đầu trục trặc khi tổng số request mỗi giây vượt 150, và SysOps administrator được giao việc thu thập số liệu tổng lượng request trong ba tuần để tìm ra những thời điểm đã vượt ngưỡng.

Cụm từ quyết định là "compile information about total requests over a span of three weeks to identify instances where this limit was exceeded" — tức là công việc mang tính hồi cứu dữ liệu quá khứ, tổng hợp lại thứ đã xảy ra, chứ không phải dựng cảnh báo cho tương lai. Thêm một chi tiết nữa: "total requests" ở cấp toàn ứng dụng, mà toàn bộ lưu lượng đều đi qua ALB, nên điểm đo tự nhiên nằm ở ALB chứ không phải từng EC2 instance riêng lẻ. Hai ràng buộc này — dữ liệu lịch sử và đo ở tầng load balancer — loại được ba phương án còn lại.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng là D: dùng metric RequestCount của ALB trong CloudWatch, đặt khoảng thời gian ba tuần với period 1 phút, rồi đọc biểu đồ để tìm các khoảng lưu lượng đỉnh.

RequestCount là metric có sẵn (native) mà ALB tự phát sang CloudWatch — không cần cài agent, không cần viết code thu thập, và nó đếm đúng thứ đề hỏi: tổng số request ALB đã xử lý. Vì CloudWatch giữ lại dữ liệu metric theo lịch sử, administrator chỉ việc chỉnh time range về ba tuần là có ngay chuỗi số liệu quá khứ. Period 1 phút cho phép quy đổi ra request/giây để so với ngưỡng 150 và nhìn thấy từng đỉnh ngắn, thay vì bị san phẳng như khi dùng period lớn. Kết quả là một biểu đồ trả lời trực tiếp câu hỏi "lúc nào vượt ngưỡng, vượt bao nhiêu".

❌ Vì sao các phương án còn lại sai

A. Lambda function gom và tổng hợp request metrics từ các EC2 instance rồi đẩy sang CloudWatch. Đây là tự dựng lại thứ đã có sẵn. CloudWatch đã cung cấp RequestCount ở tầng ALB; viết Lambda để đi thu thập trên từng instance là thêm code, thêm chỗ hỏng, thêm chi phí vận hành mà không thu được gì hơn. Nghiêm trọng hơn: Lambda chỉ bắt đầu ghi nhận từ lúc bạn triển khai nó, trong khi đề cần dữ liệu của ba tuần đã qua — không có cách nào tạo ra dữ liệu quá khứ.

B. CloudWatch Logs Insights tính tổng số request của các EC2 instance trong ba tuần, gom theo khoảng 1 phút. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì Logs Insights thật sự có thể truy vấn theo khoảng thời gian và gom nhóm theo thời gian. Chỗ hỏng nằm ở chỗ nó là công cụ phân tích log, không phải công cụ tổng hợp metric — nó chỉ chạy được nếu log request đã được đẩy vào CloudWatch Logs sẵn từ trước, điều đề bài không hề nêu. So với một metric có sẵn đúng ý nghĩa, đây là đường vòng qua một nguồn dữ liệu chưa chắc tồn tại.

C. CloudWatch Events rule khớp mẫu lưu lượng cao, kết hợp SNS topic để báo cho administrator. Sai vì lệch hẳn mục đích: đây là cơ chế phản ứng theo thời gian thực cho các sự kiện sắp tới, còn đề yêu cầu tổng hợp dữ liệu đã có của ba tuần trước. Dù rule có hoạt động hoàn hảo thì nó cũng chỉ gửi thông báo tại thời điểm vượt ngưỡng, không tích luỹ và không cho ra bức tranh tổng thể để phân tích. Ngoài ra, đây là cơ chế dựa trên event, không phải cơ chế cộng dồn số liệu theo chuỗi thời gian.

📌 Điểm cần nhớ

• Khi đề hỏi dữ liệu quá khứ ("over the last N weeks", "identify when it was exceeded"), hãy loại ngay mọi phương án chỉ hoạt động từ lúc triển khai trở đi — Lambda thu thập mới, hay rule cảnh báo cho tương lai.
• Phân biệt rõ cảnh báo/phản ứng (CloudWatch Events + SNS) với thu thập và phân tích (CloudWatch metrics). Đề hỏi "compile/analyze" thì chọn nhóm sau; đề hỏi "notify/react" thì mới chọn nhóm trước.
• Lưu lượng của ứng dụng đứng sau ALB nên đo tại ALB bằng metric có sẵn như RequestCount, thay vì đi gom số liệu từ từng EC2 instance — instance trong Auto Scaling group còn thay đổi liên tục.
• CloudWatch Logs Insights dùng cho log, CloudWatch metrics dùng cho số liệu chuỗi thời gian. Có metric native đúng ý nghĩa thì đừng chọn đường vòng qua log.
• Period nhỏ (1 phút) giữ được các đỉnh ngắn cần thiết để so với ngưỡng theo giây; period lớn sẽ san phẳng và giấu mất chính những khoảnh khắc vượt ngưỡng.

🧩 Phân tích nội dung câu hỏi

Bối cảnh: các nhóm phóng viên ở châu Âu và châu Á upload ảnh độ phân giải cao lên một S3 bucket duy nhất đặt ở Mỹ, và họ than phiền chậm. Đề hỏi chọn HAI cách tăng tốc upload.

Hai cụm từ quyết định đáp án:

• "MOST cost-effective" — đây là ràng buộc phân biệt chính. Cả năm phương án đều ít nhiều liên quan tới đường truyền, nhưng ba phương án bị loại đều là hạ tầng mạng phải trả tiền theo tháng/theo port, bất kể có upload hay không.
• "large image files" + "long distances" — file lớn đi đường dài. Hai đặc điểm này khớp chính xác với hai kỹ thuật gốc của S3: multipart upload (giải bài toán file lớn) và S3 Transfer Acceleration (giải bài toán khoảng cách xa). Đề cố tình ghép cả hai đặc điểm vào để hai đáp án đúng không trùng nhau về lý do.

✅ Vì sao đáp án đúng là đúng

A — Multipart upload. Object lớn được chia thành nhiều part và upload song song. Lợi ích kép: tận dụng được nhiều kết nối TCP cùng lúc nên throughput tổng cao hơn hẳn một luồng đơn, và nếu một part hỏng giữa chừng thì chỉ cần gửi lại đúng part đó thay vì làm lại từ đầu — điều rất đáng giá trên đường truyền xuyên lục địa vốn hay chập chờn. Đây là tính năng sẵn có của S3, không phát sinh hạ tầng mới, nên chi phí gần như bằng không.

C — S3 Transfer Acceleration. Client upload vào edge location của CloudFront gần mình nhất, rồi dữ liệu đi tiếp tới bucket qua đường backbone tối ưu của AWS thay vì đi lòng vòng qua Internet công cộng. Đúng kịch bản "client ở xa bucket". Đây là tính năng bật/tắt trên chính bucket, tính phí theo lượng dữ liệu thực sự truyền qua — không có phí cố định hằng tháng, nên nếu không upload thì không tốn.

Hai phương án này bổ trợ nhau: A tối ưu cách gửi, C tối ưu đường đi. Dùng chung được, và cũng là lý do đề cho chọn hai.

❌ Vì sao các phương án còn lại sai

B — AWS Site-to-Site VPN. Đây là phương án dễ nhầm nhất vì nghe như "kết nối riêng tới AWS". Nhưng VPN vẫn chạy trên chính Internet công cộng — cùng con đường vật lý, cùng độ trễ, cộng thêm chi phí mã hoá/giải mã. Nó giải quyết bài toán bảo mật và kết nối mạng riêng, không phải bài toán tốc độ. Đề không hề nhắc tới yêu cầu bảo mật hay mạng riêng. Ngoài ra còn phải trả phí connection theo giờ cho từng văn phòng.

D — AWS Direct Connect. Về mặt kỹ thuật thì đây thực sự cải thiện được đường truyền: băng thông ổn định, không đụng Internet công cộng. Nó hỏng ở đúng chữ "cost-effective" — Direct Connect đòi cross-connect vật lý tại colocation facility, phí port theo tháng, và thời gian triển khai tính bằng tuần. Dựng nhiều link cho nhiều văn phòng ở hai châu lục là khoản đầu tư hạ tầng lớn, không tương xứng với nhu cầu upload ảnh hằng ngày.

E — AWS Global Accelerator. Cũng gần đúng, và hay bị chọn nhầm với Transfer Acceleration vì tên na ná. Khác biệt: Global Accelerator cấp anycast IP và định tuyến traffic qua AWS backbone tới các endpoint như ALB/NLB/EC2/Elastic IP — nó dành cho ứng dụng, không phải cho S3. Với kịch bản upload thẳng vào bucket thì công cụ đúng tên là S3 Transfer Acceleration; Global Accelerator vừa không nhắm đúng đối tượng, vừa có phí cố định theo giờ cho mỗi accelerator.

📌 Điểm cần nhớ

• "Xa" và "file lớn" là hai bài toán khác nhau. Xa → S3 Transfer Acceleration (đi qua edge + backbone). Lớn → multipart upload (chia part, gửi song song, retry từng part). Đề nào nêu cả hai thì thường muốn cả hai đáp án.
• Phân biệt Transfer Acceleration với Global Accelerator qua đích đến. Đích là S3 bucket → Transfer Acceleration. Đích là ALB/NLB/EC2/Elastic IP → Global Accelerator. Tên giống nhau nhưng không thay thế cho nhau được.
• Direct Connect và Site-to-Site VPN gần như luôn trượt khi đề nhấn "cost-effective". Chúng là hạ tầng mạng có phí cố định và thời gian triển khai dài; chọn chúng chỉ khi đề nói rõ về mạng riêng, băng thông ổn định cam kết, hoặc yêu cầu không đi qua Internet công cộng.
• VPN giải bài toán bảo mật, không giải bài toán tốc độ. Thấy đề hỏi "tăng tốc" mà phương án là VPN thì gần như chắc chắn là mồi nhử — traffic vẫn đi trên cùng đường Internet.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một VPC đã gán IPv6 CIDR block, và yêu cầu nêu rõ hai điều kiện đi kèm nhau:

• "needs to have access to the internet" — các instance phải gọi ra Internet được (cập nhật gói, gọi API bên ngoài…).
• "while preventing inbound traffic from the internet" — Internet không được chủ động mở kết nối vào.

Cụm từ quyết định nằm ở hai chỗ. Thứ nhất là IPv6 CIDR block: nó loại bỏ mọi thành phần chỉ phục vụ IPv4. Thứ hai là outbound-only (ra được, vào không được): nó loại nốt thành phần cho phép hai chiều. Câu hỏi cũng nói rõ phạm vi cần sửa — "additional route configuration", tức là thứ còn thiếu nằm ở route table, không phải ở security group hay NACL.

Bốn phương án được dựng thành ma trận 2×2: đích route là 0.0.0.0/0 hay ::/0, và target là internet gateway / egress-only internet gateway / NAT gateway. Chọn đúng nghĩa là phải khớp cả hai trục cùng lúc.

✅ Vì sao đáp án đúng là đúng

D. Route ::/0 traffic to an egress-only internet gateway.

• ::/0 là default route của IPv6 — tương đương 0.0.0.0/0 bên IPv4, nghĩa là "mọi đích không nằm trong VPC". Vì VPC ở đây dùng IPv6, entry trong route table phải viết bằng prefix IPv6 thì lưu lượng IPv6 mới khớp và mới được chuyển đi.
• Egress-only internet gateway (EIGW) là thành phần AWS làm riêng cho tình huống trong đề: cho phép lưu lượng IPv6 đi ra Internet, và chặn lưu lượng do Internet khởi tạo đi vào. Nó có trạng thái (stateful) nên phản hồi của kết nối do instance mở ra vẫn quay về được — đúng nghĩa "gọi ra được nhưng không ai gọi vào được".

Ghép lại: đích ::/0 khớp đúng họ địa chỉ, target EIGW khớp đúng yêu cầu một chiều. Đó là lý do administrator "không kết nối được tới internet domains" — thiếu chính entry này trong route table.

❌ Vì sao các phương án còn lại sai

A. Route 0.0.0.0/0 traffic to an internet gateway — sai cả hai trục. 0.0.0.0/0 là default route của IPv4, nên lưu lượng IPv6 của instance sẽ không khớp entry này và vẫn bị bỏ. Ngoài ra internet gateway cho phép kết nối hai chiều: địa chỉ IPv6 vốn là public, nên nếu route qua IGW thì Internet có thể chủ động mở kết nối vào — vi phạm thẳng ràng buộc "preventing inbound traffic".

B. Route 0.0.0.0/0 traffic to an egress-only internet gateway — đây là phương án gần đúng nhất và là cái bẫy chính. Target đã chọn đúng: EIGW đúng là thứ cho outbound-only. Nhưng đích route sai họ địa chỉ: EIGW chỉ dành riêng cho IPv6, ghép nó với prefix IPv4 0.0.0.0/0 là một cặp không hợp lệ. Traffic IPv6 cần đi ra sẽ không bao giờ khớp entry này, nên triệu chứng "không kết nối được" vẫn y nguyên. Bài học: chọn đúng thiết bị chưa đủ, phải viết đúng prefix.

C. Route ::/0 traffic to a NAT gateway — ngược lại với B: đích route đúng (::/0 cho IPv6), nhưng target sai. NAT gateway là thành phần của thế giới IPv4, dùng để các subnet private ra Internet qua địa chỉ IPv4 dịch NAT. Nó không xử lý lưu lượng IPv6. Người học hay chọn phương án này vì NAT gateway cũng có tính chất "ra được, vào không được" giống EIGW — nhưng tính chất đúng mà họ địa chỉ sai thì vẫn không dùng được. Có thể coi EIGW là NAT gateway của IPv6, đúng ở khía cạnh vai trò một chiều, còn về cơ chế thì EIGW không dịch địa chỉ vì IPv6 không cần NAT.

📌 Điểm cần nhớ

• Ghép cặp cố định cần thuộc: 0.0.0.0/0 → internet gateway hoặc NAT gateway (IPv4); ::/0 → internet gateway hoặc egress-only internet gateway (IPv6). Đề trộn chéo hai cột này để tạo phương án nhiễu.
• Egress-only internet gateway chỉ tồn tại cho IPv6 và chỉ làm một việc: cho outbound, chặn inbound do bên ngoài khởi tạo. Thấy đề có IPv6 + "prevent inbound" là gần như chắc chắn hỏi về nó.
• NAT gateway không hỗ trợ IPv6. Đừng suy từ "cùng là outbound-only" mà chọn NAT gateway cho bài toán IPv6.
• IPv6 trong VPC là địa chỉ public, không có khái niệm "private range như IPv4". Vì vậy muốn instance IPv6 kín với Internet thì phải chọn đúng gateway ở route table, chứ subnet không tự bảo vệ như trường hợp IPv4 private.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một ứng dụng chạy trên EC2 instances đặt sau một Application Load Balancer (ALB). Người dùng báo lỗi, và SysOps Administrator thấy metric CloudWatch HTTPCode_ELB_5XX_Count của load balancer tăng lên. Câu hỏi: nguyên nhân nào có thể gây ra chuyện đó?

Cụm từ quyết định đáp án nằm ngay trong tên metric: HTTPCode_ELB_5XX_Count — chữ ELB ở giữa mới là mấu chốt, không phải chữ 5XX. Elastic Load Balancing có hai họ metric mã lỗi tách bạch nhau:

• HTTPCode_ELB_5XX_Count — lỗi 5XX do chính load balancer sinh ra, khi nó không chuyển được request tới target.
• HTTPCode_Target_5XX_Count — lỗi 5XX do target trả về, tức ứng dụng trên EC2 có nhận request nhưng xử lý hỏng.

Đề cố ý chọn metric thứ nhất. Vậy phải tìm phương án giải thích được vì sao load balancer tự sinh lỗi, chứ không phải vì sao ứng dụng lỗi, và cũng không phải vì sao client không kết nối được.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng là B — "The target group of the ALB does not contain healthy EC2 instances".

HTTPCode_ELB_5XX_Count đếm số mã lỗi 5XX phát sinh từ chính load balancer, và không bao gồm mã phản hồi do target sinh ra. Load balancer chỉ tự sinh 5XX khi nó nhận được request nhưng không có chỗ nào hợp lệ để chuyển tiếp — điển hình là target group không còn instance nào ở trạng thái healthy sau health check. Khi đó ALB vẫn nhận kết nối bình thường (nó đang chạy, đang lắng nghe), nhưng phải trả lỗi phía server về cho người dùng vì không hoàn tất được việc định tuyến.

Đúng hai dấu hiệu trong đề khớp với chuyện này: người dùng có tới được ứng dụng và có nhận phản hồi lỗi, và lỗi được ghi ở phía ELB chứ không phải phía target. Instance không healthy nghĩa là không có backend nào sẵn sàng đáp ứng yêu cầu kết nối đến — đúng như metric đang chỉ ra.

❌ Vì sao các phương án còn lại sai

A — "The service limits for ALBs in the VPC has been exceeded" (vượt service limit của ALB trong VPC). Đây là phương án dễ nhầm nhất, vì "vượt giới hạn" nghe rất giống nguyên nhân gây lỗi phía server. Nhưng service limit về số lượng ALB tác động ở thời điểm tạo load balancer: chạm trần thì bạn không tạo được ALB mới, chứ không làm hỏng một ALB đang hoạt động. Ở đây ALB rõ ràng đang vận hành — nó đang nhận request và đang phát ra metric CloudWatch. Vấn đề nằm ở target không healthy, không phải ở việc không dựng nổi load balancer.

C — "The ALB security group does not allow inbound traffic from the users" (security group của ALB không cho traffic vào từ người dùng). Sai vì kết quả của việc này không phải là lỗi 5XX. Security group chặn ở tầng mạng: gói tin bị drop, client chỉ đơn giản là không kết nối được — timeout, không có phản hồi HTTP nào cả. Không có phản hồi HTTP thì cũng chẳng có mã trạng thái nào để load balancer ghi vào HTTPCode_ELB_5XX_Count. Metric tăng chứng tỏ ngược lại: request đã tới được ALB.

D — "The ALB is associated with private subnets within the VPC" (ALB gắn với private subnet). Đây không phải lý do khiến target không sẵn sàng, và bản thân cấu hình này không hề sai: một internal ALB đặt trong private subnet là kiến trúc hoàn toàn hợp lệ, dùng để phục vụ traffic nội bộ trong VPC. Vị trí subnet của load balancer quyết định ai tiếp cận được nó, chứ không quyết định target có healthy hay không. Cũng như C, nếu người dùng không tiếp cận được ALB thì họ sẽ không nhận về lỗi 5XX.

📌 Điểm cần nhớ

• Đọc kỹ tiền tố của metric ELB: HTTPCode_ELB_* là lỗi do load balancer tự sinh, HTTPCode_Target_* là lỗi do ứng dụng trên target trả về. Cùng con số 5XX nhưng hướng chẩn đoán khác hẳn nhau.
• HTTPCode_ELB_5XX_Count tăng thì việc đầu tiên là kiểm tra health check và trạng thái target trong target group, chứ chưa vội soi log ứng dụng.
• Vấn đề ở tầng mạng (security group, network ACL, routing) biểu hiện thành không kết nối được / timeout, không biểu hiện thành mã lỗi HTTP. Phương án nào nói "chặn traffic" mà đề lại đưa ra mã HTTP thì gần như chắc chắn sai.
• Service limit thường chặn ở bước tạo tài nguyên; nếu tài nguyên đang chạy và đang phát metric thì đừng quy nguyên nhân cho limit.
• ALB nằm trong private subnet không phải lỗi cấu hình — đó chính là cách triển khai internal ALB.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một ứng dụng chạy on-premises, mỗi ngày sinh ra hàng chục gigabyte tệp. Yêu cầu gồm hai vế phải thoả đồng thời:

1. Toàn bộ tệp phải được lưu trên AWS cloud.
2. Những tệp mới nhất phải truy cập được ngay tại chỗ (locally) với độ trễ thấp.

Cụm từ quyết định là "the most recent files should be available locally for low latency access" — nghĩa là cần một lớp cache cục bộ nằm trong data center của công ty, giữ lại phần dữ liệu vừa dùng, trong khi bản đầy đủ nằm trên AWS. Cụm phụ trợ nhưng cũng quan trọng là "runs an application on-premises": thiết bị đọc dữ liệu đứng ngoài AWS, nên dịch vụ được chọn phải có thành phần triển khai được ở phía on-premises.

Chỉ cần bám hai cụm này là ba trong bốn phương án tự loại: chúng đều là kho lưu trữ thuần trên cloud, không có cơ chế giữ bản sao nóng ở dưới đất.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là A — AWS Storage Gateway.

Storage Gateway là dịch vụ hybrid: bạn chạy một gateway appliance ngay trong môi trường on-premises, ứng dụng nội bộ nói chuyện với appliance đó bằng giao thức lưu trữ quen thuộc, còn dữ liệu thì được đẩy lên AWS ở phía sau.

Với Volume Gateway, có hai chế độ: cached volumes và stored volumes. Ở chế độ cached volumes, toàn bộ volume được lưu trong Amazon S3 do dịch vụ Storage Gateway quản lý, còn phần dữ liệu vừa được truy cập gần đây được giữ lại trong local cache của gateway để phục vụ với độ trễ thấp. Đây chính xác là mô hình đề bài mô tả: dữ liệu đầy đủ nằm trên cloud, dữ liệu mới nhất/nóng nhất nằm ngay tại chỗ.

Điểm mấu chốt: Storage Gateway là phương án duy nhất trong danh sách có thành phần chạy on-premises kèm local cache, nên nó là phương án duy nhất thoả được cả hai vế cùng lúc.

❌ Vì sao các phương án còn lại sai

B — Amazon S3. Đây là phương án gần đúng nhất và dễ chọn nhầm, vì nó thoả trọn vẹn vế thứ nhất: S3 lưu được hàng gigabyte tệp mỗi ngày trên cloud rất tốt. Chỗ hỏng nằm ở vế thứ hai — S3 không có cơ chế cache cục bộ. Ứng dụng on-premises muốn đọc tệp thì phải gọi qua đường mạng ra Internet/AWS mỗi lần, không có bản sao nóng nào nằm lại trong data center. Đáng chú ý là chính Storage Gateway ở đáp án A vẫn dùng S3 làm nơi chứa phía sau — nhưng phần cache local mới là thứ đề hỏi, và đó là phần S3 đứng một mình không cung cấp.

C — Amazon EFS. Là file system chia sẻ, nghe hợp với chữ "tệp" trong đề. Nhưng EFS là dịch vụ chạy trong AWS, được thiết kế để mount từ các tài nguyên trong VPC; nó không có tính năng local caching ở phía on-premises. Ứng dụng dưới data center truy cập EFS vẫn phải đi qua đường mạng tới AWS, nên không đạt được yêu cầu "low latency access" cho tệp mới nhất.

D — Amazon EBS. Sai nặng nhất trong bốn phương án, hỏng ở cả hai vế. EBS là block storage gắn vào EC2 instance, không truy cập được từ on-premises, và cũng không có tính năng cache cục bộ nào. Nó không phải kho lưu trữ tệp dùng chung cho ứng dụng ngoài AWS, nên không giải quyết được kịch bản hybrid mà đề đặt ra.

📌 Điểm cần nhớ

• Thấy đồng thời hai dấu hiệu "on-premises" + "local / low latency access" trong khi dữ liệu vẫn phải nằm trên AWS → nghĩ ngay tới AWS Storage Gateway, vì đó là dịch vụ hybrid có appliance chạy dưới data center.
• Volume Gateway ở chế độ cached volumes: bản đầy đủ nằm trên S3, dữ liệu truy cập gần đây giữ trong local cache của gateway. Phân biệt với stored volumes (dữ liệu chính nằm ở local, sao lưu lên AWS).
• S3, EFS, EBS đều không có tính năng local caching cho on-premises. Chúng là kho lưu trữ thuần trên cloud; riêng EBS còn không truy cập được từ ngoài AWS.
• Khi đề nêu nhiều ràng buộc, đừng dừng ở phương án thoả ràng buộc đầu tiên (ở đây là "lưu trên AWS" → S3). Ràng buộc còn lại thường mới là cái phân biệt các phương án.

🧩 Phân tích nội dung câu hỏi

Một SysOps Administrator lỡ tay xoá một thư mục chứa dữ liệu quan trọng nằm trên một Amazon EBS volume. May mắn là volume đó đã có snapshot gần đây. Câu hỏi: phải làm gì để lấy lại tệp của người dùng từ snapshot?

Cụm từ quyết định nằm ở chỗ đề chỉ mất một thư mục, chứ không phải hỏng cả volume, và nguồn phục hồi là a recent snapshot. Hai chi tiết này gộp lại tạo ra ràng buộc thật sự: ta cần lấy dữ liệu ra khỏi snapshot ở mức từng tệp, trong khi EBS snapshot là bản sao lưu ở mức khối (block-level) của toàn bộ volume, không phải kho tệp duyệt được. Snapshot không có giao diện "mở ra xem bên trong" trên EC2 console — muốn đọc nội dung của nó thì bắt buộc phải hiện thực hoá (materialize) snapshot thành một EBS volume, gắn volume đó vào một EC2 instance, rồi để hệ điều hành mount và copy tệp.

Vì vậy phương án đúng phải là phương án nêu đủ chuỗi ba bước: snapshot → volume mới → attach → copy. Ai bỏ bớt một mắt xích, hoặc gán cho console một khả năng nó không có, là sai.

✅ Vì sao đáp án đúng là đúng

A. Create a new EBS volume from the snapshot, attach the volume to an Amazon EC2 instance, and copy the deleted file.

Đây đúng là quy trình chuẩn để phục hồi dữ liệu từ EBS snapshot:

1. Tạo volume mới từ snapshot. Snapshot lưu trên Amazon S3 (do AWS quản lý) và không gắn trực tiếp vào instance được; tạo volume là cách duy nhất biến nó thành thiết bị khối dùng được. Lưu ý volume mới phải nằm cùng Availability Zone với EC2 instance thì mới attach được — đây là ràng buộc cố hữu của EBS.
2. Attach volume vào EC2 instance. Volume mới xuất hiện như một ổ đĩa phụ; instance đang chạy vẫn hoạt động bình thường, không cần dừng máy hay đụng vào volume gốc.
3. Mount rồi copy thư mục cần lấy từ volume phục hồi sang vị trí cũ trên volume gốc.

Điểm hay của cách này là nó không phá dữ liệu hiện tại: volume gốc vẫn nguyên vẹn, phần bị xoá được ghép lại có chọn lọc. Sau khi copy xong có thể detach và xoá volume tạm để khỏi trả tiền cho nó.

❌ Vì sao các phương án còn lại sai

B. Restore the file from the snapshot onto the EC2 instance using the Amazon EC2 console. — EC2 console không có chức năng phục hồi ở mức từng tệp từ snapshot. Snapshot là bản sao mức khối; console chỉ cho bạn thao tác trên chính đối tượng snapshot (tạo volume, copy sang Region khác, chia sẻ, xoá), chứ không mở được hệ thống tệp bên trong. Phương án này bỏ hẳn bước tạo volume — tức là bỏ đúng mắt xích bắt buộc.

C. Use the Amazon EC2 console to browse the contents of the snapshot, locate the folder, and then copy it to the EBS volume. — Đây là phương án gài bẫy khéo nhất vì đích đến của nó ("copy sang EBS volume") thì đúng, chỉ có phương tiện là sai: EC2 console không duyệt được nội dung bên trong snapshot và không copy dữ liệu ra khỏi snapshot được. Không có bước hiện thực hoá snapshot thành volume thì cả chuỗi thao tác này không tồn tại trên thực tế.

D. Launch a new Amazon EC2 instance in the same Availability Zone and copy the deleted folder over the network. — Phương án này nhắc đúng ràng buộc AZ nên nghe có vẻ hợp lý, nhưng nó không nói dữ liệu từ đâu ra: chỉ dựng một instance mới thì bản thân instance đó chẳng có thư mục đã xoá, vì thiếu hẳn bước tạo volume từ snapshot. Ngoài ra, ngay cả khi đã có volume phục hồi, việc copy qua mạng là thừa và chậm hơn — bạn hoàn toàn có thể attach thêm volume trực tiếp vào chính instance đang dùng và copy tại chỗ, không cần thêm một máy nữa.

📌 Điểm cần nhớ

• EBS snapshot là bản sao lưu mức khối, không phải kho tệp duyệt được. Muốn lấy một tệp hay một thư mục ra thì luôn phải đi qua chuỗi: tạo EBS volume từ snapshot → attach vào EC2 instance → mount → copy. Thấy phương án nào nói "duyệt/khôi phục tệp từ snapshot bằng EC2 console" thì loại ngay.
• EBS volume và EC2 instance phải cùng Availability Zone mới attach được. Nếu instance nằm ở AZ khác với snapshot ban đầu, cứ tạo volume trong AZ của instance — snapshot vốn dùng được ở phạm vi toàn Region.
• Phục hồi có chọn lọc thì đừng thay volume gốc. Attach volume phục hồi như một ổ phụ rồi copy đúng phần cần lấy sẽ giữ nguyên mọi dữ liệu mới phát sinh sau snapshot; xong việc thì detach và xoá volume tạm để khỏi tốn chi phí.
• Cẩn thận với phương án "đúng đích nhưng sai phương tiện". Trong đề thi CloudOps, một lựa chọn có thể nêu đúng kết quả mong muốn nhưng gán cho console/dịch vụ một khả năng nó không có, hoặc bỏ mất một bước bắt buộc — hãy đọc kỹ đủ chuỗi thao tác chứ không chỉ đọc kết quả cuối.