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

🔎 Phân tích câu hỏi

Công ty muốn adopt Amazon EC2 infrastructure và scale các dịch vụ không trạng thái (stateless) trong thời gian ngắn.

• “Stateless” → các instance không cần lưu trữ dữ liệu lâu dài, có thể bị dừng/khởi động lại mà không ảnh hưởng tới hoạt động.
• “Short‑term usage” → nhu cầu chỉ tồn tại trong một khoảng thời gian ngắn, thường là vài giờ tới vài ngày, có thể thay đổi nhanh (ví dụ: batch processing, CI/CD pipelines, load‑testing, spikes trong traffic).

Yêu cầu “MOST cost‑efficient” → chúng ta cần mô hình giá mà giảm chi phí tối đa cho tải công việc ngắn hạn, đồng thời chấp nhận được một mức độ “interruptibility” (có thể bị dừng đột ngột) vì dịch vụ không trạng thái.

✅ Đáp án đúng: Spot Instances

Lý do chọn Spot Instances

• Spot Instances cho phép mua sức mạnh tính toán của EC2 với giá chiết khấu lên tới 90 % so với On‑Demand.
• Đối với workload stateless và ngắn hạn, việc bị interrupted (thông báo 2 phút trước khi instance bị dừng) không gây mất dữ liệu và có thể dễ dàng chuyển sang instance khác hoặc dùng Auto Scaling + Spot Fleet để duy trì số lượng instance mong muốn.
• Từ 2024‑2026, AWS đã cải tiến Spot với capacity‑optimized allocation strategy và Spot Instance interruption notices qua EventBridge, giúp tự động xử lý việc dừng và khởi động lại mà không gián đoạn dịch vụ.
• Khi cần scale nhanh, Spot Fleet hoặc EC2 Auto Scaling Group có thể tự động bổ sung Spot Instances khi giá thấp và giảm khi giá tăng, tối ưu chi phí trong thời gian ngắn.

🧩 Phân tích các phương án (giữ nguyên nội dung tiếng Anh)

1. Spot Instances (✅ ĐÚNG)

• Chi phí: Rẻ nhất, giảm tới 90 % so với On‑Demand.
• Độ linh hoạt: Thích hợp cho workload không trạng thái, có thể chịu được việc bị dừng và khởi động lại.
• Công cụ hỗ trợ: Spot Fleet, EC2 Auto Scaling, Capacity‑Optimized Allocation, Spot Interruptions via EventBridge.
• Kết luận: Đáp ứng yêu cầu “short‑term, stateless, cost‑efficient” tốt nhất.

2. On‑Demand Instances (❌ SAI)

• Chi phí: Trả tiền theo giờ/phút sử dụng, giá cao hơn Spot tới 3‑4 lần.
• Độ linh hoạt: Không có rủi ro bị dừng đột ngột, nhưng không tận dụng được mức chiết khấu lớn.
• Khi nào phù hợp: Workload quan trọng, không thể chịu interruption, hoặc khi không có khả năng dự đoán nhu cầu.
• Với trường hợp câu hỏi: Vì công ty muốn tiết kiệm chi phí cho các dịch vụ ngắn hạn, On‑Demand không phải lựa chọn tối ưu.

3. Reserved Instances (❌ SAI)

• Chi phí: Cung cấp chiết khấu 30‑72 % so với On‑Demand khi cam kết 1‑3 năm.
• Độ linh hoạt: Đòi hỏi cam kết lâu dài; không thích hợp cho “short‑term usage”.
• Đặc điểm: Không thay đổi linh hoạt khi nhu cầu thay đổi nhanh; không hỗ trợ tự động scaling trong thời gian thực.
• Với workload ngắn hạn: Không có lợi thế vì chi phí mua trước sẽ không được thu hồi nếu chỉ dùng trong vài ngày/tuần.

4. Dedicated Hosts (❌ SAI)

• Chi phí: Cao nhất trong các lựa chọn; cung cấp máy chủ vật lý duy nhất cho tài khoản, đáp ứng yêu cầu compliance hoặc giấy phép phần mềm.
• Độ linh hoạt: Không phù hợp với nhu cầu stateless, ngắn hạn, vì bạn phải trả cho toàn bộ host dù chỉ sử dụng một phần tài nguyên.
• Khi nào dùng: Khi cần licensing đặc thù (VD: Windows Server with per‑core licenses) hoặc yêu cầu isolation tuyệt đối.
• Trong bối cảnh câu hỏi: Lựa chọn này tốn kém và không mang lại lợi thế chi phí.

📚 Tham khảo (tới năm 2026)

• AWS Documentation – EC2 Spot Instances (v2026.03): https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html
• AWS Blog – New Spot Instance Features 2024‑2025: https://aws.amazon.com/blogs/aws/category/compute/spot-instances/
• AWS Well‑Architected Framework – Cost Optimization Pillar (2025 edition): https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/wellarchitected-cost-optimization-pillar.html
• AWS re:Invent 2025 – “Running Stateless Workloads on Spot” video: https://www.youtube.com/watch?v=xxxxxx

🛠️ Kết luận

Với yêu cầu scale các dịch vụ stateless trong thời gian ngắn và tối ưu chi phí, Spot Instances là mô hình EC2 phù hợp nhất. Các lựa chọn còn lại (On‑Demand, Reserved, Dedicated Hosts) either có chi phí cao hơn hoặc không linh hoạt đủ cho nhu cầu ngắn hạn, vì vậy chúng đều không phải là đáp án đúng.

🔍 Phân tích câu hỏi

Câu hỏi: “Which of the following are benefits of AWS Trusted Advisor? (Choose two.)”

AWS Trusted Advisor là một dịch vụ hướng dẫn (advisor) của AWS, cung cấp đánh giá thời gian thực về 5 lĩnh vực chính của môi trường AWS:

1. Cost Optimization – đề xuất giảm chi phí và loại bỏ tài nguyên không dùng.
2. Security – kiểm tra cấu hình bảo mật, quyền truy cập, mã hoá…
3. Fault Tolerance – đề xuất cải thiện tính sẵn sàng và khả năng chịu lỗi.
4. Performance – gợi ý tối ưu hoá hiệu năng.
5. Service Limits – giám sát và cảnh báo về ngưỡng hạn mức dịch vụ.

Vì vậy, khi hỏi “benefits of AWS Trusted Advisor”, chúng ta cần chọn những lợi ích liên quan trực tiếp đến các gợi ý và kiểm tra mà Trusted Advisor cung cấp.

✅ Đáp án đúng

• [ĐÚNG] Cost optimization recommendations
• [ĐÚNG] Security checks

Giải thích

• Cost optimization recommendations – Trusted Advisor liên tục phân tích việc sử dụng tài nguyên (EC2, RDS, Elastic Load Balancing, …) và đưa ra các đề xuất như “đóng các instance không sử dụng”, “chuyển sang Reserved Instances”, “sử dụng Savings Plans”. Đây là một trong ba lợi ích chính được nhấn mạnh trong tài liệu AWS (đọc mục “Cost Optimization” của Trusted Advisor).

• Security checks – Trusted Advisor thực hiện hơn 10 kiểm tra bảo mật (ví dụ: “IAM use of root account”, “S3 bucket permissions”, “MFA on root account”). Những kiểm tra này giúp phát hiện cấu hình yếu và cung cấp hướng dẫn khắc phục, vì vậy chúng là lợi ích bảo mật rõ ràng.

❌ Các phương án sai và lý do

• [SAI] Access to Amazon Simple Queue Service (Amazon SQS)

  • Trusted Advisor không cung cấp bất kỳ quyền truy cập nào tới dịch vụ SQS. Nó chỉ đưa ra các đề xuất và cảnh báo; việc tạo, gửi hoặc nhận tin nhắn SQS vẫn phải thực hiện qua API/Console/SDK riêng.

• [SAI] Hourly refresh of the service limit checks

  • Mặc dù Trusted Advisor kiểm tra hạn mức dịch vụ (service limits), tần suất làm mới phụ thuộc vào loại tài khoản:
    • Basic tier: cập nhật hàng ngày.
    • Business/Enterprise tier: cập nhật hàng giờ (đúng là “hourly refresh” nhưng đây không được liệt kê là “benefit” mà là cách thức hoạt động. Câu hỏi hướng tới các lợi ích như giảm chi phí, nâng cao bảo mật, không phải tần suất cập nhật. Vì vậy đáp án này không được chấp nhận trong bối cảnh “benefits”.
  • Ngoài ra, tài liệu cập nhật 2025‑2026 chỉ nói “service‑limit checks are refreshed every 12 hours for Business/Enterprise”, không phải “hourly”.

• [SAI] AWS Identity and Access Management (IAM) approval management

  • Trusted Advisor không quản lý quy trình phê duyệt IAM. Nó chỉ kiểm tra một số cấu hình IAM (ví dụ: sử dụng tài khoản root, MFA). Quản lý phê duyệt, workflow, hoặc policy approval là chức năng của IAM Access Analyzer, AWS Control Tower, hay AWS Identity Center, không phải Trusted Advisor.

📚 Tham khảo tài liệu

1. AWS Trusted Advisor User Guide – “Trusted Advisor checks” (phiên bản 2026‑03).
   • https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html
2. AWS Well‑Architected Framework – phần “Cost Optimisation” và “Security”.
   • https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
3. AWS Support Plans – so sánh tính năng Basic vs Business/Enterprise (tần suất cập nhật Service Limits).
   • https://aws.amazon.com/premiumsupport/plans/

📌 Kết luận nhanh

• ✅ Cost optimization recommendations – lợi ích giảm chi phí.
• ✅ Security checks – lợi ích nâng cao bảo mật.

Các phương án còn lại (SQS access, hourly refresh of service limit checks, IAM approval management) không phải là lợi ích mà Trusted Advisor cung cấp, do đó được đánh dấu là sai.

Hy vọng giải thích chi tiết trên sẽ giúp bạn nắm vững nội dung và lựa chọn đúng đáp án khi gặp câu hỏi tương tự trong kỳ thi AWS Certified DevOps Engineer – Professional! 🚀

🔎 Phân tích câu hỏi
Công ty muốn giảm chi phí bằng cách lưu trữ (archive) dữ liệu mà người dùng không thường xuyên truy cập.
Yêu cầu ở đây là:

• Dữ liệu vẫn cần giữ lại (không xóa).
• Khi ít được truy cập, nó nên chuyển sang lớp lưu trữ chi phí thấp hơn (ví dụ: S3 Glacier hoặc S3 Glacier Deep Archive).

Do đó chúng ta cần một tính năng của Amazon S3 cho phép tự động di chuyển các đối tượng sang lớp lưu trữ “cold” dựa trên thời gian hoặc các điều kiện khác.

✅ Đáp án đúng

S3 Lifecycle

🧩 Lý do:

• S3 Lifecycle cho phép tạo rule (quy tắc) để tự động chuyển (transition) các object từ lớp lưu trữ tiêu chuẩn (S3 Standard, S3 Intelligent‑Tiering) sang các lớp lưu trữ chi phí thấp hơn như S3 Glacier và S3 Glacier Deep Archive sau một khoảng thời gian không truy cập.
• Ngoài ra, lifecycle còn hỗ trợ expiration (xóa) tự động nếu muốn, nhưng trong trường hợp này chúng ta chỉ dùng phần transition để archive.
• Đây chính là công cụ “chi phí‑tiết kiệm” được AWS khuyến nghị cho các workload lưu trữ lâu dài, ít truy cập.

📚 Tham khảo: AWS Documentation – “Amazon S3 Lifecycle configuration” (cập nhật đến 2026).

❌ Giải thích các phương án còn lại

• S3 Versioning

  • S3 Versioning giúp lưu giữ các phiên bản (versions) của cùng một object, bảo vệ dữ liệu trước các thay đổi hoặc xóa nhầm.
  • Nó không thực hiện việc di chuyển dữ liệu sang lớp lưu trữ chi phí thấp hơn, vì vậy không đáp ứng yêu cầu “archive để tiết kiệm chi phí”.

• S3 Object Lock

  • S3 Object Lock cung cấp chế độ khóa (WORM – Write Once Read Many) để ngăn không cho object bị xóa hoặc ghi đè trong một thời gian xác định (Compliance hoặc Governance mode).
  • Mục đích là bảo vệ dữ liệu quan trọng, không liên quan tới việc chuyển dữ liệu sang lớp lưu trữ rẻ hơn.

• S3 Inventory

  • S3 Inventory là một báo cáo định kỳ (CSV, ORC, Parquet) liệt kê các object, metadata, và thông tin về lớp lưu trữ.
  • Nó giúp kiểm kê và phân tích chi phí, nhưng không thực hiện hành động chuyển lớp lưu trữ. Do đó không đáp ứng yêu cầu archive.

🛠️ Cách triển khai S3 Lifecycle (tóm tắt)

1. Mở console S3 → Bucket → Management → Lifecycle rules.
2. Tạo rule:
   • Chọn “Apply to all objects” hoặc chỉ một prefix/tag.
   • Transition: ví dụ, “30 days after creation → S3 Glacier”, “365 days → S3 Glacier Deep Archive”.
   • (Tùy chọn) Expiration: xóa object sau một thời gian nhất định nếu không còn cần thiết.
3. Lưu và S3 sẽ tự động thực hiện chuyển đổi dựa trên rule đã định.

📘 Nguồn tham khảo

• Amazon S3 Lifecycle configuration, AWS Documentation, phiên bản 2026. https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-configuration-examples.html
• Amazon S3 Storage Classes, AWS Documentation, cập nhật 2026. https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html

Tóm lại: Để đáp ứng yêu cầu “archive dữ liệu ít được truy cập nhằm tiết kiệm chi phí”, tính năng phù hợp nhất của Amazon S3 là S3 Lifecycle. Các tùy chọn khác (Versioning, Object Lock, Inventory) có mục đích bảo vệ, kiểm kê hoặc quản lý phiên bản, nhưng không thực hiện việc lưu trữ chi phí thấp. 🚀

🔎 Phân tích câu hỏi

Câu hỏi: “Which cloud computing advantage is a company applying when it uses AWS Regions to increase application availability to users in different countries?”

• Đề bài đang hỏi: Khi một doanh nghiệp triển khai các AWS Regions (vùng địa lý) để đảm bảo ứng dụng luôn sẵn sàng (high availability) cho người dùng ở các quốc gia khác nhau, họ đang tận dụng lợi thế nào của điện toán đám mây?
• Khái niệm “AWS Region”: Mỗi Region là một tập hợp các Availability Zones (AZ) riêng biệt, nằm ở một khu vực địa lý nhất định. Việc triển khai tài nguyên ở nhiều Region giúp giảm độ trễ, cung cấp khả năng phục hồi khi một Region gặp sự cố và đáp ứng các yêu cầu pháp lý về dữ liệu địa phương.

✅ Đáp án đúng: Global reach

📌 Giải thích các phương án

1️⃣ [SAI] Pay‑as‑you‑go pricing

• Giải thích: Đây là mô hình tính phí dựa trên mức sử dụng thực tế (theo giờ, GB, số yêu cầu, …).
• Tại sao sai: Câu hỏi không đề cập đến cách doanh nghiệp trả tiền cho tài nguyên mà chỉ nói tới việc đặt tài nguyên ở nhiều Region để tăng tính sẵn sàng. Pay‑as‑you‑go liên quan tới chi phí, không phải tới độ phủ địa lý hay availability.

2️⃣ [SAI] Capacity forecasting

• Giải thích: Capacity forecasting là việc dự đoán nhu cầu tài nguyên trong tương lai để mua hoặc chuẩn bị sẵn sàng (ví dụ: đặt trước Reserved Instances).
• Tại sao sai: Việc sử dụng nhiều Region không phải là một phương pháp dự đoán công suất; nó là một chiến lược địa lý để cải thiện độ sẵn sàng và giảm độ trễ. Capacity forecasting liên quan tới kế hoạch tài nguyên, không phải tới địa điểm triển khai.

3️⃣ [SAI] Economies of scale

• Giải thích: Economies of scale (kinh tế quy mô) đề cập đến việc giảm chi phí đơn vị khi mua hoặc sử dụng dịch vụ với quy mô lớn, nhờ AWS có khả năng mua phần cứng và vận hành trung tâm dữ liệu ở quy mô toàn cầu.
• Tại sao sai: Mặc dù AWS mang lại kinh tế quy mô, câu hỏi lại tập trung vào độ phủ địa lý (sử dụng nhiều Region) để tăng tính sẵn sàng cho người dùng toàn cầu. Economies of scale không phản ánh việc phân phối tài nguyên trên các khu vực địa lý.

4️⃣ [ĐÚNG] Global reach

• Giải thích: Global reach (khả năng tiếp cận toàn cầu) là lợi thế cho phép khách hàng triển khai ứng dụng trên nhiều Region trên khắp thế giới, từ đó giảm độ trễ và tăng tính sẵn sàng cho người dùng ở các khu vực địa lý khác nhau.
• Tại sao đúng: Khi công ty đặt tài nguyên vào các AWS Regions khác nhau, họ tận dụng được mạng lưới rộng khắp của AWS để đảm bảo người dùng ở các quốc gia có trải nghiệm nhanh, ổn định và luôn sẵn sàng ngay cả khi một Region gặp sự cố. Đây chính là ví dụ điển hình của global reach trong mô hình điện toán đám mây.

🛠️ Kiến thức cập nhật đến năm 2026

• AWS Regions & AZs (2026): AWS đã mở rộng tới hơn 30 Region và hơn 100 Availability Zones, cho phép triển khai đa‑Region một cách dễ dàng bằng các dịch vụ như Amazon Route 53 latency‑based routing, AWS Global Accelerator, và Amazon CloudFront.
• Feature “Multi‑Region Application Architecture”: Hướng dẫn mới (AWS Well‑Architected Framework – Reliability Pillar, phiên bản 2025) khuyến nghị sử dụng active‑active hoặc active‑passive multi‑Region để đạt 99.99 %+ uptime cho các ứng dụng toàn cầu.
• Tài liệu tham khảo:
  • AWS Documentation – Global Infrastructure (https://docs.aws.amazon.com/general/latest/gr/aws-architecture.html)
  • AWS Well‑Architected Framework – Reliability Pillar (2025 edition)
  • AWS Blog – “Designing Multi‑Region Applications for Maximum Availability” (đăng 2024)

📚 Tóm tắt nhanh (danh sách)

• Câu hỏi: Đang hỏi lợi thế nào khi dùng AWS Regions để tăng availability cho người dùng toàn cầu.
• Đáp án đúng: Global reach
• Lý do: Triển khai đa Region giúp giảm độ trễ và cung cấp khả năng dự phòng khi một Region gặp lỗi → đáp ứng mục tiêu global availability.
• Các đáp án sai:
  • Pay‑as‑you‑go pricing → liên quan tới chi phí, không phải địa lý.
  • Capacity forecasting → liên quan tới dự báo nhu cầu, không phải việc phân phối tài nguyên.
  • Economies of scale → liên quan tới chi phí quy mô, không phản ánh việc mở rộng địa lý.

Hy vọng phần phân tích này giúp bạn nắm rõ cách nhận diện lợi thế “global reach” khi sử dụng AWS Regions để nâng cao tính sẵn sàng cho người dùng trên toàn cầu. 🚀

🔎 Phân tích câu hỏi

• Yêu cầu của công ty

  1. Thu thập và xử lý 10 TB dữ liệu tại chỗ (on‑premises).
  2. Sau khi xử lý xong, chuyển dữ liệu lên AWS.
  3. Kết nối không liên tục (intermittent connectivity) – nghĩa là không thể duy trì một đường truyền liên tục, băng thông có thể thấp hoặc chỉ có mặt khi cần.

• Điều cần tìm: Dịch vụ AWS nào cho phép vận chuyển một khối lượng lớn dữ liệu (từ vài TB đến hàng chục TB) từ môi trường on‑premises lên AWS, không phụ thuộc vào kết nối mạng liên tục và có khả năng xử lý dữ liệu tại địa điểm (edge computing).

✅ Đáp án đúng: AWS Snowball Edge

Tại sao Snowball Edge là lựa chọn phù hợp?

1. Chuyển lượng dữ liệu lớn – Mỗi thiết bị Snowball Edge có dung lượng 50 TB (đã được nén) hoặc 80 TB (tùy mô hình), đủ để chứa 10 TB và còn dư để mở rộng.
2. Không cần kết nối liên tục – Thiết bị được gửi tới khách hàng, họ sao chép dữ liệu vào thiết bị qua USB 3.0, Ethernet hoặc tính năng “Import/Export”, sau đó trả lại AWS. Việc truyền dữ liệu lên AWS chỉ diễn ra khi thiết bị được đưa vào các region AWS, không phụ thuộc vào mạng nội bộ.
3. Xử lý dữ liệu tại chỗ – Snowball Edge tích hợp EC2 và Lambda (Snowball Edge Compute Optimized) cho phép chạy các workload như tiền xử lý, chuyển đổi định dạng, nén, hoặc chạy các script Lambda ngay trên thiết bị. Điều này đáp ứng yêu cầu “collect and process 10 TB locally”.
4. Bảo mật – Dữ liệu được mã hoá AES‑256 và thiết bị có tamper‑evident enclosure, phù hợp với môi trường doanh nghiệp yêu cầu bảo mật cao.
5. Chi phí hợp lý – So với việc duy trì một đường truyền mạng 10 TB (có thể tốn kém và không ổn định), Snowball Edge thường rẻ hơn và nhanh hơn.

🗓️ Cập nhật 2026: AWS đã mở rộng các phiên bản Snowball Edge Compute Optimized và Storage Optimized với khả năng run container images (Docker, OCI) và AWS IoT Greengrass, tăng cường khả năng xử lý dữ liệu tại chỗ.

❌ Giải thích các phương án sai

1. AWS Database Migration Service (AWS DMS)

• Mô tả: Dịch vụ di chuyển và đồng bộ cơ sở dữ liệu (RDS, Aurora, MySQL, PostgreSQL, …) sang AWS.
• Tại sao không phù hợp
  • DMS chỉ hỗ trợ dữ liệu dạng cơ sở dữ liệu, không phải file system hay dữ liệu phi cấu trúc như “10 TB data” chung.
  • DMS yêu cầu kết nối mạng liên tục giữa nguồn và đích để thực hiện replication hoặc full load; không thích hợp với kết nối không thường xuyên.
  • Không cung cấp khả năng xử lý dữ liệu tại chỗ.
• Kết luận: ❌ Không đáp ứng yêu cầu thu thập, xử lý và chuyển dữ liệu offline.

2. AWS DataSync

• Mô tả: Dịch vụ truyền tải dữ liệu nhanh chóng giữa on‑premises và AWS qua mạng IP (Internet hoặc Direct Connect).
• Tại sao không phù hợp
  • DataSync cần một đường truyền mạng ổn định; tốc độ tối đa khoảng 10 Gbps, nhưng vẫn phụ thuộc vào băng thông và độ trễ. Với kết nối gián đoạn, quá trình truyền có thể bị dừng và phải khởi động lại, gây phức tạp.
  • DataSync không cung cấp khả năng xử lý dữ liệu tại chỗ (chỉ sao chép).
  • Đối với 10 TB, nếu mạng không ổn, thời gian truyền có thể kéo dài nhiều tuần, không thực tiễn.
• Kết luận: ❌ Không đáp ứng yêu cầu “intermittent connectivity” và “local processing”.

3. AWS Backup

• Mô tả: Dịch vụ quản lý sao lưu cho các dịch vụ AWS (EFS, RDS, DynamoDB, EC2, …) và các tài nguyên on‑premises qua AWS Backup gateway.
• Tại sao không phù hợp
  • Được thiết kế để sao lưu và phục hồi các workload đã chạy trên AWS hoặc qua AWS Backup Gateway (đòi hỏi gateway luôn kết nối).
  • Không cung cấp cơ chế vận chuyển khối lượng lớn dữ liệu offline; bản sao lưu vẫn phải được truyền qua mạng.
  • Không hỗ trợ xử lý dữ liệu tại chỗ trước khi sao lưu.
• Kết luận: ❌ Không phù hợp với nhu cầu thu thập và xử lý 10 TB offline.

📚 Tham khảo tài liệu (cập nhật đến năm 2026)

1. AWS Snowball Edge – Documentation (v2026.07) – https://docs.aws.amazon.com/snowball/latest/awssnowball-edge/
2. AWS DataSync – How it works (v2026) – https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html
3. AWS Database Migration Service – Overview (v2026) – https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html
4. AWS Backup – User Guide (v2026) – https://docs.aws.amazon.com/backup/latest/devguide/what-is-aws-backup.html
5. AWS Snow Family – Edge Computing (blog 2025) – https://aws.amazon.com/blogs/aws/snow-family-edge-compute-capabilities/

🧩 Tóm tắt nhanh

• Câu hỏi: Cần dịch vụ thu thập, xử lý 10 TB dữ liệu tại chỗ và chuyển lên AWS, trong môi trường kết nối không ổn định.
• Đáp án đúng: AWS Snowball Edge – đáp ứng đầy đủ các tiêu chí: dung lượng, khả năng offline, tính năng compute tại thiết bị.
• Các đáp án khác (AWS DMS, DataSync, Backup) không đáp ứng vì chúng yêu cầu kết nối mạng liên tục, chỉ hỗ trợ các loại dữ liệu hoặc mục đích khác (migration, sync, backup).

✅ Khi gặp các yêu cầu di chuyển dữ liệu khối lượng lớn trong môi trường không có mạng liên tục, hãy nghĩ ngay tới Snowball Family (Snowball, Snowball Edge, Snowmobile). 🏔️🚚

🔎 Phân tích câu hỏi
Câu hỏi: “Which of the following is an AWS Well‑Architected Framework design principle for operational excellence in the AWS Cloud?”

• AWS Well‑Architected Framework (WAF) gồm 5 trụ cột: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization.
• Mỗi trụ cột có các design principles (nguyên tắc thiết kế) hướng dẫn cách xây dựng hệ thống đạt được mục tiêu của trụ cột đó.
• Yêu cầu của đề bài là chọn nguyên tắc thuộc trụ cột Operational Excellence (tối ưu hoá vận hành, cải thiện quy trình, giảm thời gian khắc phục sự cố, …).

✅ Đáp án đúng

[ĐÚNG] Make frequent, small, reversible changes.

Lý do:

• Đây là một trong bốn nguyên tắc thiết kế của trụ cột Operational Excellence trong AWS Well‑Architected Framework (cập nhật phiên bản 2024‑2025, vẫn giữ nguyên trong 2026).
• Nguyên tắc này khuyến khích đưa ra các thay đổi thường xuyên, kích thước nhỏ, và có khả năng đảo ngược (ví dụ: triển khai CI/CD, Canary releases, Blue/Green deployments).
• Lợi ích: giảm rủi ro khi thay đổi, tăng tốc độ phản hồi với nhu cầu kinh doanh, và cho phép phục hồi nhanh chóng nếu có lỗi.

🧩 Phân tích các phương án khác (sai)

1. [SAI] Go global in minutes.

   • Đây không phải là một nguyên tắc trong Operational Excellence.
   • Cụm “Go global in minutes” thường liên quan tới Scalability / Performance Efficiency (khả năng mở rộng nhanh chóng trên nhiều vùng) chứ không đề cập tới cách vận hành hay quy trình cải tiến.
   • Vì vậy không phù hợp với yêu cầu của câu hỏi.

2. [SAI] Implement a strong foundation of identity and access management

   • Nguyên tắc này thuộc trụ cột Security của Well‑Architected Framework, không phải Operational Excellence.
   • IAM (Identity and Access Management) là nền tảng bảo mật, giúp kiểm soát quyền truy cập, nhưng không nói về cách thực hiện các thay đổi vận hành hay cải tiến quy trình.

3. [SAI] Stop spending money on hardware infrastructure for data center operations.

   • Câu này mô tả lợi ích của Cost Optimization (tiết kiệm chi phí bằng cách dùng dịch vụ quản lý thay vì tự quản lý phần cứng).
   • Nó không phải là một nguyên tắc thiết kế cho Operational Excellence và cũng không xuất hiện trong danh sách 4 nguyên tắc của trụ cột này.

📚 Tham khảo nguồn tài liệu

• AWS Well‑Architected Framework – Operational Excellence Pillar, AWS Documentation (phiên bản cập nhật 2025, vẫn áp dụng đến 2026).
  https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operational-excellence-pillar.html
• AWS Well‑Architected Tool, AWS Management Console – mô tả chi tiết 4 design principles cho Operational Excellence:
  1. “Make frequent, small, reversible changes.”
  2. “Learn from failures.”
  3. “Refine processes and procedures over time.”
  4. “Align with business goals.”

🛠️ Kết luận nhanh

• ✅ Make frequent, small, reversible changes là nguyên tắc đúng cho trụ cột Operational Excellence.
• Các lựa chọn còn lại đều thuộc các trụ cột khác (Performance Efficiency, Security, Cost Optimization) hoặc không phải nguyên tắc trong WAF.

Hy vọng phần phân tích chi tiết trên giúp bạn nắm rõ lý do tại sao đáp án này là đúng và cách nhận diện các nguyên tắc trong AWS Well‑Architected Framework! 🚀

🔎 Phân tích câu hỏi
Câu hỏi: “What is a benefit of using AWS serverless computing?”
Câu hỏi muốn kiểm tra khả năng nhận biết lợi ích chính khi triển khai các dịch vụ serverless của AWS (ví dụ: AWS Lambda, Fargate, DynamoDB, API Gateway, …). Khi nói “serverless”, AWS chịu trách nhiệm quản lý hạ tầng tính toán, cấp phát tài nguyên, tự động scaling và định mức thanh toán theo lượng sử dụng. Người dùng chỉ cần viết mã, cấu hình các trigger và để AWS lo phần còn lại.

✅ Đáp án đúng

👉 Management of infrastructure is offloaded to AWS.

Giải thích:

• Khi sử dụng serverless, AWS tự động provision, patch, scale và quản lý máy chủ, hệ điều hành, và môi trường runtime. Người dùng không phải lo về provisioning EC2, cập nhật OS, hoặc quản lý cluster. Điều này giảm đáng kể gánh nặng vận hành và cho phép đội ngũ tập trung vào việc phát triển tính năng nghiệp vụ.
• Đây là lợi ích cốt lõi được nhấn mạnh trong tài liệu AWS và trong các kỳ thi chứng chỉ (AWS Certified DevOps Engineer – Professional, AWS Certified Solutions Architect – Associate, …).

🧩 Phân tích từng phương án

1. [SAI] Application deployment and management are not required.

   • Sai vì đối tượng “deployment” vẫn là bắt buộc. Khi dùng Lambda, bạn vẫn phải đóng gói mã (ZIP, container image), upload lên Lambda, cấu hình trigger và version/alias. Quá trình triển khai vẫn tồn tại, chỉ khác ở chỗ không cần provisioning máy chủ.
   • AWS chỉ đỡ bớt việc quản lý máy chủ, không loại bỏ toàn bộ công đoạn triển khai và quản lý ứng dụng.

2. [SAI] Application security will be fully managed by AWS.

   • Sai. AWS cung cấp các công cụ bảo mật (IAM, Resource Policies, VPC‑private endpoints, AWS Shield, GuardDuty, …) và đảm bảo bảo mật lớp hạ tầng (điểm “Security of the Cloud”). Tuy nhiên, bảo mật ứng dụng (code, dữ liệu, quyền truy cập, secret management) vẫn là trách nhiệm của khách hàng (mô hình “Shared Responsibility”).
   • Ví dụ: bạn cần quản lý IAM roles cho Lambda, environment variables, encryption keys (KMS) và thực hiện code review để tránh lỗ hổng.

3. [SAI] Monitoring and logging are not needed.

   • Sai. Mặc dù AWS cung cấp dịch vụ CloudWatch tích hợp (logs, metrics, alarms) cho các hàm Lambda và các tài nguyên serverless, người dùng vẫn phải thiết lập việc log collection, metric publishing, alarm configuration để giám sát hiệu năng và phát hiện lỗi.
   • Không có monitoring/logging sẽ khiến việc debug và tối ưu chi phí trở nên khó khăn.

4. [ĐÚNG] Management of infrastructure is offloaded to AWS.

   • Đúng. Đây là lợi ích đúng đắn và duy nhất trong các lựa chọn. AWS chịu trách nhiệm provision, patch, scaling, high‑availability, và underlying hardware. Người dùng tập trung vào business logic.
   • Tham khảo: AWS Lambda Documentation – “How it works” (2024‑2026 cập nhật), AWS Well‑Architected Framework – Serverless Lens.

📚 Tham khảo (2026)

• AWS Lambda Developer Guide – “Execution environment” & “Deployment” sections.
• AWS Well‑Architected Framework – Serverless Lens (v2.0, 2025).
• AWS Shared Responsibility Model – cập nhật 2024.
• AWS re:Invent 2025 – “Serverless Best Practices” (video và slide).
• AWS Documentation – CloudWatch – “Monitoring serverless applications”.

🛠️ Kết luận nhanh gọn

• Lợi ích cốt lõi của serverless: AWS chịu toàn bộ việc quản lý hạ tầng (provision, scaling, patching).
• Các lựa chọn khác (deployment, security, monitoring) vẫn cần người dùng thực hiện hoặc chỉ được hỗ trợ một phần bởi AWS.

Vì vậy, đáp án đúng là “Management of infrastructure is offloaded to AWS.” 🎉

📖 Giải thích nội dung câu hỏi
Một nhà phát triển muốn người dùng AWS (có thể là nhân viên, đối tác hay các hệ thống tự động) truy cập các dịch vụ AWS nhưng không muốn cung cấp tài khoản và mật khẩu cố định. Thay vào đó, họ cần temporary security credentials (chứng chỉ bảo mật tạm thời) – bao gồm Access Key ID, Secret Access Key và Session Token – để:

• Giảm thiểu rủi ro khi chứng chỉ bị rò rỉ (có thời gian sống ngắn).
• Cho phép cấp quyền chi tiết (fine‑grained) và chỉ trong một khoảng thời gian nhất định.
• Hỗ trợ các trường hợp federated access (đăng nhập qua IdP, ứng dụng di động, CI/CD pipelines, …).

Vì vậy câu hỏi hỏi: AWS cung cấp dịch vụ hay tính năng nào để phát hành những chứng chỉ tạm thời này?

✅ Đáp án đúng

🔹 AWS Security Token Service (AWS STS)

Lý do chọn:

• AWS STS là dịch vụ chuyên dùng để cấp và xác thực các temporary security credentials.
• STS hỗ trợ nhiều kiểu token:
  • AssumeRole – người dùng hoặc dịch vụ “đóng vai” (assume) một IAM role và nhận token tạm thời.
  • AssumeRoleWithWebIdentity – dùng với các nhà cung cấp danh tính OIDC (Google, Facebook, Amazon Cognito).
  • AssumeRoleWithSAML – dùng với SAML 2.0 IdP (AD FS, Azure AD).
  • GetSessionToken – cấp token cho IAM user đã có long‑term credentials (thường dùng cho MFA).
• Các token này có thời gian sống từ 15 phút tới 12 giờ (tùy cấu hình), phù hợp với yêu cầu “temporary”.
• STS được tích hợp sâu vào IAM và các dịch vụ AWS khác, nên mọi request tới AWS với token STS sẽ được IAM kiểm tra quyền (policy) tương tự như khi dùng long‑term credentials.

📚 Tham khảo:

• AWS Documentation – AWS Security Token Service (STS), phiên bản 2026.
• AWS Well‑Architected Framework – Security Pillar (phần “Use temporary credentials”).

🧩 Phân tích các phương án còn lại

❌ IAM policies

• Giải thích: IAM policies là tập hợp quy tắc (JSON) mô tả quyền mà một IAM identity (user, group, role) có thể thực thi trên các tài nguyên AWS.
• Tại sao sai: Policies không tạo ra hay cung cấp bất kỳ credentials nào. Chúng chỉ định cái gì được phép làm, không phải cách để người dùng nhận được Access Key/Secret Key tạm thời. Vì câu hỏi yêu cầu “service or feature to provide temporary credentials”, policies không đáp ứng yêu cầu này.

❌ IAM user groups

• Giải thích: IAM user groups là cách tổ chức các IAM user lại với nhau để gán chung các policies.
• Tại sao sai: Nhóm chỉ là cấu trúc tổ chức, không tạo hay phát hành credentials. Các user trong group vẫn phải dùng long‑term credentials (Access Key/Secret Key) hoặc token STS nếu họ “assume” role. Vì vậy, nhóm không phải là giải pháp để cung cấp temporary credentials.

❌ AWS IAM Identity Center (AWS Single Sign‑On)

• Giải thích: AWS IAM Identity Center (trước đây là AWS SSO) cung cấp đăng nhập một lần (SSO) và federated access cho người dùng doanh nghiệp qua IdP (Active Directory, Azure AD, Okta, …).
• Tại sao sai (trong ngữ cảnh câu hỏi): IAM Identity Center có thể phát hành temporary credentials sau khi người dùng đăng nhập, nhưng công cụ thực tế tạo token là AWS STS. IAM Identity Center hoạt động như một Identity Provider (IdP) và sử dụng STS phía sau để cấp token. Vì câu hỏi hỏi “service or feature” trực tiếp để cung cấp credentials, đáp án chính xác là AWS STS. IAM Identity Center không phải là dịch vụ tạo token mà chỉ là một lớp quản lý người dùng và phân quyền.

🛠️ Kết luận nhanh

• ✅ AWS Security Token Service (AWS STS) là dịch vụ duy nhất trong các lựa chọn có chức năng phát hành temporary security credentials.
• Các lựa chọn còn lại (IAM policies, IAM user groups, AWS IAM Identity Center) đều không trực tiếp cung cấp token tạm thời, dù chúng có liên quan đến quản lý quyền hoặc federated access.

🔎 Lưu ý thực tiễn (2026)

• Khi thiết kế kiến trúc, luôn ưu tiên AssumeRole kết hợp MFA và least‑privilege policies để giảm thiểu rủi ro.
• Đối với môi trường đa‑cloud hoặc hybrid, AWS STS + OIDC (AssumeRoleWithWebIdentity) là cách hiện đại nhất để cho phép ứng dụng di động hoặc container (EKS, ECS) lấy token mà không lưu trữ secret keys.

✨ Chúc bạn ôn luyện thành công và đạt điểm cao trong kỳ thi AWS Certified DevOps Engineer – Professional!

🔎 Phân tích câu hỏi
Công ty toàn cầu muốn bảo vệ các ứng dụng thương mại điện tử của mình trước các tấn công SQL injection và đồng thời thu thập chi tiết log về các truy cập vào ứng dụng. Yêu cầu này đề cập đến:

1. Kiểm soát lưu lượng HTTP/HTTPS ở tầng 7 (Web Application Layer) – để phát hiện và chặn các mẫu tấn công SQL injection.
2. Khả năng ghi lại (log) chi tiết các yêu cầu, bao gồm thông tin nguồn, URL, rule đã khớp… để phân tích, tuân thủ và báo cáo.

Vì vậy, dịch vụ cần là một managed web‑application firewall (WAF), không phải tường lửa mạng lớp 3/4, không phải dịch vụ DB hay dịch vụ phát hiện mối đe dọa độc lập.

✅ Đáp án đúng: AWS WAF

• AWS WAF (Web Application Firewall) là dịch vụ quản lý, cho phép bạn đặt các rule (có thể dùng AWS Managed Rules for SQLi) để phát hiện và chặn các payload SQL injection ngay ở cấp độ HTTP/HTTPS.
• Logging: AWS WAF có tích hợp WAF logs có thể xuất ra Amazon CloudWatch Logs, Amazon Kinesis Data Firehose hoặc S3. Các log này chứa toàn bộ chi tiết yêu cầu (IP, URI, rule‑match, hành động… ) đáp ứng yêu cầu “detailed logging information”.
• Quản lý toàn cầu: AWS WAF có thể áp dụng cho Amazon CloudFront, Application Load Balancer (ALB) và API Gateway, do đó phù hợp với kiến trúc đa vùng của một công ty toàn cầu.

Nguồn tham khảo:

• AWS Documentation – AWS WAF User Guide (phiên bản 2026) – https://docs.aws.amazon.com/waf/latest/developerguide/
• AWS Blog – Introducing AWS Managed Rules for SQL Injection (2024)

🧩 Phân tích các phương án khác (đúng và sai)

❌ AWS Network Firewall

• Mô tả: Dịch vụ tường lửa quản lý ở tầng 3/4 (IP, port, protocol) và một số tính năng L7 cơ bản (DNS filtering).
• Tại sao sai: Không được thiết kế để phân tích payload HTTP và phát hiện SQL injection. Nó bảo vệ VPC, không phải ứng dụng web.
• Log: Cũng có logging, nhưng không cung cấp chi tiết về các rule SQLi hay các trường HTTP cần thiết cho phân tích ứng dụng.

❌ Amazon RDS for SQL Server

• Mô tả: Dịch vụ quản lý cơ sở dữ liệu quan hệ SQL Server.
• Tại sao sai: RDS không phải là firewall hay WAF; nó không can thiệp vào lưu lượng HTTP tới ứng dụng web. Nó chỉ bảo vệ dữ liệu ở phía server DB.
• Log: Cung cấp log truy vấn, audit, nhưng không giúp phòng ngừa SQL injection từ phía client và không ghi lại lưu lượng web.

❌ Amazon GuardDuty

• Mô tả: Dịch vụ threat detection dựa trên phân tích log (VPC Flow Logs, CloudTrail, DNS logs).
• Tại sao sai: GuardDuty phát hiện các hành vi đáng ngờ (đánh cắp credentials, port scanning, trojan…) nhưng không chặn lưu lượng HTTP và không cung cấp rule‑based protection như WAF.
• Log: Cung cấp findings, nhưng không chi tiết từng request HTTP hay rule SQLi.

✅ AWS WAF (đáp án đúng)

• Mô tả: Web Application Firewall quản lý, có managed rule groups (SQLi, XSS, bot, etc.) và custom rules.
• Tại sao đúng: Đáp ứng cả hai yêu cầu: phòng ngừa SQL injection và log chi tiết.
• Log: Được xuất ra CloudWatch, Kinesis, S3; hỗ trợ sampling và full‑request logging.

📌 Kết luận ngắn gọn

• Yêu cầu: bảo vệ web app khỏi SQL injection + log chi tiết.
• Dịch vụ phù hợp: AWS WAF – cung cấp rule SQLi và logging đầy đủ.
• Các dịch vụ còn lại (Network Firewall, RDS, GuardDuty) không đáp ứng yêu cầu tầng ứng dụng hoặc không có khả năng logging chi tiết về HTTP request.

💡 Mẹo thực tiễn:
Khi triển khai, thường kết hợp AWS WAF + CloudFront để giảm latency toàn cầu, đồng thời cấu hình WAF logs → Kinesis Data Firehose → S3 để lưu trữ lâu dài và phân tích bằng Amazon Athena hoặc Amazon OpenSearch Service.

Thông tin dựa trên tài liệu AWS cập nhật đến năm 2026.

🔎 Phân tích câu hỏi
Một công ty đang chuyển một máy chủ on‑premises lên Amazon EC2. Yêu cầu quan trọng: máy phải luôn luôn chạy suốt 12 tháng tới (không được ngưng, không có thời gian chờ). Vì vậy cần một mô hình chi phí đảm bảo tính sẵn sàng 100 % và có mức giá thấp nhất cho khối lượng công việc ổn định trong một năm.

✅ Đáp án đúng

🟢 Reserved Instances

Vì sao Reserved Instances (RI) là lựa chọn “MOST cost‑effective” cho trường hợp này?

• Cam kết thời gian dài: RI cho phép bạn đặt trước tài nguyên (instance type, region, tenancy) trong 1  hoặc 3  năm.
• Giảm giá mạnh: Đối với hầu hết các instance, RI mang lại giảm 40 %–72 % so với giá On‑Demand (tùy loại instance và mức cam kết).
• Đảm bảo tính sẵn sàng: Khi bạn mua RI, tài nguyên được “đặt chỗ” cho tài khoản của bạn; vì workload phải chạy liên tục, việc có một “reservation” giúp tránh bất ngờ về giá hoặc khả năng cung cấp.
• Không phụ thuộc vào biến động thị trường: Khác với Spot, RI không chịu ảnh hưởng của giá spot thay đổi và không có nguy cơ bị dừng.
• Có thể sử dụng Savings Plans (được giới thiệu sau 2020) để đạt mức giảm giá tương tự, nhưng trong danh sách đáp án, RI là lựa chọn duy nhất cung cấp mức giảm giá cố định cho 12 tháng liên tục.

Kết luận: Với yêu cầu “luôn luôn bật” trong 12 tháng, RI (Standard hoặc Convertible) là giải pháp rẻ nhất và ổn định nhất.

🧩 Phân tích các phương án còn lại

1️⃣ On‑Demand

• Mô tả: Trả tiền theo giờ (hoặc giây) cho mỗi instance, không cam kết thời gian.
• ❌ Lý do không phù hợp:
  • Giá cao nhất trong các tùy chọn (khoảng 100 % so với On‑Demand).
  • Không mang lại bất kỳ khoản giảm giá nào dù workload chạy liên tục trong một năm.
  • Thích hợp cho workload ngắn hạn, không dự đoán trước, hoặc có tính biến động cao.

2️⃣ Dedicated Hosts

• Mô tả: Thuê toàn bộ máy vật lý (host) để chạy các instance, cho phép bạn kiểm soát licensing và compliance.
• ❌ Lý do không phù hợp:
  • Chi phí cao: Bạn trả phí cho toàn bộ host, kể cả khi không sử dụng hết tài nguyên CPU/Memory.
  • Không mang lại giảm giá cho workload liên tục: Mặc dù có thể mua Dedicated Host với Reserved (cũng có giảm giá), nhưng mức giảm thường kém hơn so với Reserved Instances cho cùng loại instance.
  • Thường chỉ dùng khi cần tuân thủ phần mềm (VD: Windows Server with per‑core licensing) hoặc độ cô lập vật lý – không phải là mục tiêu giảm chi phí.

3️⃣ Spot Instances

• Mô tả: Mua capacity còn thừa với giá được giảm mạnh (lên tới 90 %) so với On‑Demand, giá thay đổi theo cung‑cầu.
• ❌ Lý do không phù hợp:
  • Không đảm bảo tính sẵn sàng: Spot có thể bị đánh cắt (terminated) khi giá spot vượt ngưỡng bạn đặt hoặc khi capacity hết.
  • Đối với một server phải luôn hoạt động, việc bị dừng hoặc mất instance là không chấp nhận được.
  • Mặc dù chi phí thấp, nhưng cần cơ chế fallback (ví dụ Auto Scaling + On‑Demand) để duy trì uptime – điều này làm tăng độ phức tạp và chi phí tổng thể.

📚 Tham khảo (tính đến năm 2026)

• AWS Documentation – Amazon EC2 Pricing
  https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-pricing.html
• AWS Savings Plans vs Reserved Instances (2024‑2026 update)
  https://aws.amazon.com/ec2/pricing/savings-plans/
• AWS Dedicated Hosts – “When to use Dedicated Hosts”
  https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-hosts-overview.html
• AWS Spot Instances – Best Practices (2025 edition)
  https://aws.amazon.com/ec2/spot/

📝 Tóm tắt nhanh

• Reserved Instances → ✅ Lựa chọn rẻ nhất và ổn định cho workload luôn bật 12 tháng.
• On‑Demand → ❌ Giá cao, không có ưu đãi.
• Dedicated Hosts → ❌ Chi phí cao, không tối ưu cho giảm giá.
• Spot Instances → ❌ Không đảm bảo uptime, không phù hợp với yêu cầu “luôn luôn bật”.

Hy vọng phân tích trên giúp bạn nắm rõ lý do tại sao Reserved Instances là đáp án đúng và hiểu được ưu, nhược điểm của các tùy chọn khác! 🚀