Ngân hàng đề — AWS Certified Cloud Practitioner

Đáp án

A và E — AWS Database Migration Service (DMS) và AWS Snowball

Vì sao đúng

Cả hai đều là dịch vụ chuyên cho việc di chuyển dữ liệu, nhưng phục vụ hai tình huống khác nhau:

DMS đáng chú ý ở chỗ nó hỗ trợ di trú không đồng nhất — chuyển Oracle sang PostgreSQL chẳng hạn, kết hợp với AWS Schema Conversion Tool.

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

Ba phương án còn lại là hạ tầng mạng — chúng cung cấp đường đi, nhưng không thực hiện việc di chuyển:

• D. AWS Direct Connect — đường truyền riêng; DMS hay Snowball vẫn cần thứ khác để làm việc di trú. Đây là phương án nhiễu chính.
• B. Site-to-Site VPN — đường hầm mã hoá qua Internet.
• C. AWS Transit Gateway — trung tâm định tuyến.

Đáp án

C — AWS Health Dashboard — Your account health

Vì sao đúng

Đây là dịch vụ duy nhất thông báo về sự cố hạ tầng của AWS ảnh hưởng tới tài nguyên cụ thể của bạn, kèm hướng dẫn khắc phục.

Khi phần cứng chạy EBS volume của bạn gặp sự cố, Account Health Dashboard gửi sự kiện nêu rõ:

• Định danh chính xác của volume bị ảnh hưởng.
• Việc cần làm — ví dụ tạo snapshot và khôi phục sang volume mới, hoặc dừng rồi khởi động lại instance để nó chuyển sang phần cứng khác.
• Thời hạn nếu AWS có lịch thay thế phần cứng.

Sự kiện cũng phát qua EventBridge, nên bạn tự động hoá phản ứng được.

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

• B. AWS Trusted Advisor — khuyến nghị theo thực hành tốt, không báo sự cố phần cứng đang xảy ra.
• A. AWS Config — theo dõi thay đổi cấu hình tài nguyên, không biết gì về tình trạng phần cứng bên dưới.
• D. Amazon GuardDuty — phát hiện mối đe doạ bảo mật, không liên quan tới hỏng hóc phần cứng.

Phân biệt hai bảng của AWS Health

Đáp án

A và C — Amazon Rekognition và AWS Lambda

Vì sao đúng

Dịch vụ theo khu vực (regional) nghĩa là tài nguyên tồn tại trong đúng một Region, và bạn phải tạo lại ở từng Region nếu muốn dùng nhiều nơi:

• C. AWS Lambda — hàm nằm trong một Region cụ thể; hàm ở ap-southeast-1 không thấy được từ us-east-1.
• A. Amazon Rekognition — endpoint theo Region, và các bộ sưu tập khuôn mặt cũng nằm trong Region.

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

Ba dịch vụ còn lại là toàn cầu:

• B. AWS IAM — người dùng, vai và chính sách áp cho toàn bộ tài khoản; đây là dịch vụ toàn cầu điển hình nhất.
• D. Amazon CloudFront — mạng phân phối nội dung, theo bản chất là toàn cầu.
• E. AWS WAF — được xếp vào nhóm toàn cầu. Cần nói cho chính xác: web ACL gắn với CloudFront thì là toàn cầu, còn gắn với Application Load Balancer hoặc API Gateway thì phải tạo trong cùng Region với tài nguyên đó. Trong bối cảnh câu hỏi này nó được coi là toàn cầu.

Ghi nhớ

Đáp án

D — Dùng Amazon CloudFront

Vì sao đúng

Vấn đề trong đề: nội dung nằm ở một Region tại châu Á, nhưng người dùng ở khắp thế giới — nên người ở châu Âu hay châu Mỹ phải chờ dữ liệu đi nửa vòng trái đất cho mỗi lần tải trang.

CloudFront giải bằng cách cache nội dung tại hàng trăm edge location gần người dùng. Lần đầu có người ở Đức truy cập, nội dung được kéo về edge location tại Đức; mọi người dùng sau đó ở khu vực đó nhận nội dung ngay tại chỗ.

Ba lợi ích đi kèm: giảm tải cho bucket S3, giảm chi phí truyền dữ liệu (giá truyền ra của CloudFront rẻ hơn của S3), và có sẵn HTTPS cùng chứng chỉ miễn phí từ ACM.

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

• C. Amazon S3 Transfer Acceleration — cũng dùng mạng biên của CloudFront, nhưng nó tăng tốc việc tải lên (upload) vào bucket, không phải việc phục vụ nội dung cho người đọc. Đây là phương án nhiễu chính và là chỗ dễ nhầm nhất:

  	CloudFront	S3 Transfer Acceleration
  Tối ưu chiều	Tải xuống — phục vụ người xem	Tải lên — đưa dữ liệu vào bucket
  Có cache	Có	Không

• B. AWS WAF — tường lửa ứng dụng; nó bảo vệ chứ không tăng tốc.

• A. AWS CloudFormation — hạ tầng dưới dạng mã.

Đáp án

A — Failover routing (định tuyến chuyển dự phòng)

Vì sao đúng

Failover routing dựng chính xác cho mô hình active-passive: bạn khai một bản ghi chính (primary) và một bản ghi phụ (secondary), kèm health check.

Route 53 luôn trả về bản ghi chính khi nó còn khoẻ. Khi health check báo hỏng, nó tự chuyển sang bản ghi phụ.

Health check của endpoint chính:  OK      →  trả về endpoint CHÍNH
Health check của endpoint chính:  FAILED  →  trả về endpoint PHỤ

Ứng dụng phổ biến: trang chính chạy trên ELB, còn bản dự phòng là một trang tĩnh trên S3 hiển thị thông báo bảo trì.

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

• C. Weighted routing — chia lưu lượng theo tỷ lệ bạn đặt; cả hai endpoint đều nhận lưu lượng, tức là active-active. (Có thể mô phỏng failover bằng cách đặt trọng số 0, nhưng đó là cách vòng vo và không tự động.)
• B. Latency-based routing — chọn endpoint có độ trễ thấp nhất; mọi endpoint đều hoạt động.
• D. Simple routing — không hỗ trợ health check, nên không phát hiện được endpoint hỏng.

Đáp án

B — AWS Cost & Usage Report (AWS CUR)

Vì sao đúng

Đề nêu hai yêu cầu rất cụ thể, và chỉ CUR đáp ứng cả hai: báo cáo chi tiết theo giờ và giao vào một bucket S3.

CUR là bộ dữ liệu chi phí chi tiết nhất mà AWS cung cấp: mỗi dòng là một mục sử dụng, kèm dịch vụ, loại sử dụng, Region, tài nguyên cụ thể, thẻ, và các khoản giảm giá đã áp. Bạn chọn mức chi tiết theo giờ, ngày hoặc tháng.

Vì nó nằm trên S3 ở dạng CSV hoặc Parquet, bạn phân tích được bằng Athena, Redshift hoặc QuickSight — hoặc nạp vào công cụ báo cáo riêng.

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

• C. AWS Cost Explorer — trực quan hoá chi phí trong giao diện web và cho xem theo giờ (trong 14 ngày gần nhất), nhưng nó không giao báo cáo chi tiết vào S3. Đây là phương án nhiễu chính.
• A. AWS Budgets — đặt ngưỡng và gửi cảnh báo, không tạo báo cáo chi tiết.
• D. AWS Pricing Calculator — ước tính chi phí trước khi dùng.

Ghi nhớ theo nhu cầu

Đáp án

*D — Triển khai EC2 instance trên nhiều Availability Zone trong cùng một AWS Region

Vì sao đúng

Mỗi Availability Zone có nguồn điện, làm mát và mạng riêng, và cách nhau đủ xa để một sự cố cục bộ không ảnh hưởng cả hai — nhưng vẫn đủ gần để độ trễ giữa chúng chỉ ở mức mili giây một chữ số.

Nhờ vậy đây là cách tăng tính sẵn sàng hiệu quả nhất mà ít phức tạp nhất: mất một AZ thì các instance ở AZ khác vẫn phục vụ, và ELB tự ngừng gửi lưu lượng tới phần hỏng.

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

• C. Cùng một AZ trong một Region — mọi instance nằm chung một AZ, nên mất AZ là mất tất cả. Đây là điều cần tránh.
• A và B — cả hai đều nói tới "cùng một AZ trên nhiều Region", và điều này không có nghĩa: tên Availability Zone (us-east-1a, ap-southeast-1a) chỉ có ý nghĩa trong Region của nó; không tồn tại khái niệm "cùng một AZ" giữa hai Region khác nhau.

Về phương án đa Region

Triển khai trên nhiều Region cho mức bảo vệ cao hơn nữa — chịu được cả sự cố toàn Region. Nhưng nó phức tạp và tốn kém hơn nhiều (đồng bộ dữ liệu xuyên Region, độ trễ cao, chi phí truyền dữ liệu). Với yêu cầu "tăng tính sẵn sàng" thông thường, đa AZ là câu trả lời đúng.

Đáp án

D — Tự tạo tài nguyên mới ở Region đích rồi chuyển dữ liệu và ứng dụng sang

Vì sao đúng

Điểm cốt lõi cần hiểu: AWS không có nút "chuyển Region". Tài nguyên gắn với Region nơi chúng được tạo, và không có dịch vụ nào bê nguyên cả môi trường sang nơi khác.

Quy trình thực tế là dựng lại rồi chuyển dữ liệu:

1. Tạo hạ tầng ở Region đích  (dùng CloudFormation hoặc Terraform cho nhanh và nhất quán)
2. Sao chép dữ liệu           (S3 CRR, snapshot xuyên Region, AWS DMS cho cơ sở dữ liệu)
3. Kiểm thử ở Region mới
4. Chuyển lưu lượng           (đổi DNS trong Route 53, giảm TTL trước)
5. Ngừng và xoá tài nguyên ở Region cũ

Lưu ý về quy định: nếu chuyển sang châu Âu thì phải xem xét GDPR và các yêu cầu về nơi lưu trữ dữ liệu — đây thường là lý do khiến người ta chuyển Region ngay từ đầu.

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

• B. Dùng AWS CloudFormation để chuyển tài nguyên — CloudFormation dựng lại hạ tầng rất tốt và nên dùng ở bước 1, nhưng nó không chuyển dữ liệu. Đây là phương án nhiễu chính vì nó đúng một phần.
• A. Dùng AWS DMS — DMS chuyển được cơ sở dữ liệu, nhưng không chuyển ứng dụng hay hạ tầng.
• C. Mở ticket với AWS Support — AWS không thực hiện việc di trú thay bạn.

Đáp án

C và E — Auto Scaling group scale in để giảm số instance, và scale out để tăng số instance

Vì sao đúng

Câu này kiểm tra đúng thuật ngữ, vì Auto Scaling group chỉ làm một việc: thay đổi số lượng instance.

Hai cặp này khác nhau về chiều: out và in đi theo chiều ngang (số lượng), còn up và down đi theo chiều dọc (kích cỡ).

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

• B. Scale down và hạ xuống instance yếu hơn và D. Scale up và nâng lên instance mạnh hơn — cả hai mô tả mở rộng theo chiều dọc, việc Auto Scaling group không làm. Muốn đổi loại instance thì phải sửa launch template và thay thế máy.
• A. Scale down và giảm số lượng instance — mô tả hành động đúng nhưng dùng sai thuật ngữ: giảm số lượng gọi là scale in, không phải scale down. Đây là phương án nhiễu tinh vi nhất, và nó cho thấy câu hỏi đang kiểm tra từ vựng chứ không chỉ kiểm tra khái niệm.

Đáp án

D — Amazon ElastiCache

Vì sao đúng

ElastiCache là dịch vụ cơ sở dữ liệu trong bộ nhớ (in-memory) được quản lý, hỗ trợ hai công cụ: Redis và Memcached.

Vì dữ liệu nằm trong RAM chứ không trên đĩa, độ trễ tính bằng micro giây thay vì mili giây — nhanh hơn cơ sở dữ liệu trên đĩa hàng chục tới hàng trăm lần.

Ứng dụng phổ biến: cache kết quả truy vấn tốn kém, lưu phiên đăng nhập, bảng xếp hạng thời gian thực, đếm tần suất.

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

• C. Amazon DynamoDB — rất nhanh (mili giây một chữ số) nhưng lưu trên đĩa SSD, không phải trong bộ nhớ. Nó có DAX làm lớp cache trong bộ nhớ, nhưng bản thân DynamoDB thì không. Đây là phương án nhiễu chính.
• B. Amazon RDS — cơ sở dữ liệu quan hệ trên đĩa.
• A. Amazon Athena — truy vấn dữ liệu trên S3 bằng SQL; không phải cơ sở dữ liệu.

Lưu ý

AWS còn có MemoryDB for Redis — cơ sở dữ liệu trong bộ nhớ bền vững, dùng làm cơ sở dữ liệu chính chứ không chỉ làm cache. Nó không có trong bốn phương án.