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

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

Câu hỏi: “Which AWS service or component allows inbound traffic from the internet to access a VPC?”
Yêu cầu xác định dịch vụ hoặc thành phần trong AWS mà cho phép các gói tin từ Internet đi vào (inbound) một VPC. Nói cách khác, chúng ta cần một “cửa ra vào” (gateway) kết nối VPC với Internet để các tài nguyên công cộng (EC2, ALB, …) có thể nhận yêu cầu từ bên ngoài.

✅ Đáp án đúng

Internet gateway

• Internet Gateway (IGW) là một thành phần định danh (logical) được gắn vào một VPC, cung cấp kết nối hai‑chiều (inbound + outbound) giữa VPC và Internet.
• Khi IGW được đính kèm và có route 0.0.0.0/0 trong route table của subnet (public subnet), các instance có public IP hoặc Elastic IP sẽ có thể nhận và trả lời các yêu cầu từ Internet.
• IGW không cần cấu hình NAT, không giới hạn băng thông và hỗ trợ IPv4 & IPv6 (Internet‑gateway‑v6).

📚 Tham khảo: AWS VPC Documentation – Internet Gateways (được cập nhật thường xuyên, phiên bản 2026).

❌ Các phương án sai và giải thích

1. NAT gateway

   • NAT (Network Address Translation) gateway chỉ hỗ trợ lưu lượng outbound từ các private subnet ra Internet. Nó không cho phép inbound kết nối từ Internet đến các instance trong VPC trừ khi có thiết lập port‑forwarding đặc biệt (điều này không phải chức năng chính của NAT).
   • Khi một private subnet có route tới NAT gateway, các instance có thể đặt ra yêu cầu ra bên ngoài, nhưng các yêu cầu đến từ Internet sẽ bị chặn vì NAT không có địa chỉ công cộng để nhận traffic.

2. AWS WAF

   • AWS WAF (Web Application Firewall) là tường lửa lớp 7 dùng để lọc và bảo vệ các HTTP/HTTPS request trên các dịch vụ như Amazon CloudFront, Application Load Balancer (ALB), API Gateway, và AppSync.
   • WAF không phải là một gateway và không tạo ra kết nối mạng giữa VPC và Internet. Nó chỉ đánh giá các request đã đi qua các điểm cuối (endpoint) đã được liên kết, không cung cấp khả năng “đi vào VPC”.

3. VPC peering

   • VPC peering là một kết nối mạng riêng giữa hai VPC (có thể cùng tài khoản hoặc khác tài khoản) để các tài nguyên trong chúng có thể giao tiếp trực tiếp qua địa chỉ IP nội bộ.
   • Peering không liên quan đến Internet và không cho phép traffic từ Internet tới VPC. Nó chỉ hỗ trợ lưu lượng nội bộ giữa VPC đã được peer.

🧩 Tổng hợp lại (liệt kê)

• Internet gateway – ✅ Đúng, cung cấp inbound + outbound traffic từ/đến Internet cho VPC.
• NAT gateway – ❌ Sai, chỉ hỗ trợ outbound traffic cho private subnet.
• AWS WAF – ❌ Sai, là tường lửa ứng dụng, không phải gateway mạng.
• VPC peering – ❌ Sai, là kết nối nội bộ giữa VPC, không liên quan tới Internet.

📌 Lưu ý quan trọng khi dùng Internet Gateway (đến năm 2026)

• Public subnet: Subnet có route 0.0.0.0/0 → igw và các instance trong subnet này cần public IPv4/IPv6 address hoặc Elastic IP để nhận inbound traffic.
• Security Groups & NACLs: Cần mở các port cần thiết (ví dụ: 80/443) trong security group và network ACL để cho phép traffic từ Internet.
• IPv6 support: IGW hỗ trợ IPv6 bằng cách tạo route ::/0 → igw và gán IPv6 CIDR cho VPC.
• High‑availability: IGW là một dịch vụ được quản lý, không có điểm lỗi (single point of failure).

📚 Tham khảo

1. Amazon VPC User Guide – Internet Gateways (AWS Documentation, cập nhật 2026).
2. Amazon VPC – NAT Gateways (AWS Documentation, 2026).
3. AWS WAF and AWS Shield (AWS Documentation, 2026).
4. VPC Peering Guide (AWS Documentation, 2026).

Hy vọng phân tích trên đã giúp bạn hiểu rõ tại sao Internet Gateway là câu trả lời duy nhất đúng cho câu hỏi này. 🚀

🔍 Phân tích câu hỏi
Câu hỏi: “Which AWS service can companies use to create infrastructure from code?”
Nội dung muốn kiểm tra kiến thức của bạn về dịch vụ AWS cho phép Infrastructure as Code (IaC) – tức là mô tả, tạo, cập nhật và quản lý toàn bộ hạ tầng (Mạng, EC2, RDS, IAM, …) bằng các tệp tin cấu hình (JSON hoặc YAML) và thực thi chúng một cách tự động.

✅ Đáp án đúng

🟢 AWS CloudFormation

Lý do:

• CloudFormation là dịch vụ native của AWS dành riêng cho IaC.
• Người dùng viết templates (JSON hoặc YAML) mô tả toàn bộ stack (tài nguyên, phụ thuộc, tham số, output).
• Khi “đẩy” template lên, CloudFormation sẽ tạo, cập nhật, xóa các tài nguyên theo thứ tự phụ thuộc, đồng thời cung cấp drift detection, change sets, và rollback nếu có lỗi.
• Từ phiên bản 2024‑2026, CloudFormation còn hỗ trợ modules, cross‑stack references, transform macros (VD: AWS::Include, AWS::Serverless‑2016‑10‑31) và declarative pipelines thông qua AWS CloudFormation Guard để kiểm tra compliance.

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

• Amazon Elastic Kubernetes Service (Amazon EKS)

  • EKS là managed Kubernetes control plane. Nó giúp chạy các workload container trên Kubernetes, nhưng không phải là công cụ IaC.
  • Để “cấu hình” hạ tầng cho EKS bạn vẫn cần dùng CloudFormation, Terraform, hoặc CDK; EKS chỉ cung cấp môi trường chạy Kubernetes.
  • Vì vậy, EKS không đáp ứng yêu cầu “create infrastructure from code”.

• AWS Outposts

  • Outposts là dịch vụ hạ tầng vật lý được đặt tại trung tâm dữ liệu/on‑premise của khách hàng, mang lại khả năng chạy các dịch vụ AWS (EC2, EBS, RDS…) trên môi trường on‑premise.
  • Outposts là một sản phẩm phần cứng + phần mềm, không phải công cụ mô tả hay tạo hạ tầng bằng code.
  • Việc triển khai Outposts vẫn cần CloudFormation hoặc API, nhưng Outposts tự nó không phải là công cụ IaC.

• AWS CodePipeline

  • CodePipeline là dịch vụ CI/CD pipeline giúp tự động hoá việc xây dựng, kiểm thử và triển khai mã nguồn.
  • Nó kết nối các stage (Source, Build, Deploy) và có thể gọi CloudFormation hoặc CDK để triển khai hạ tầng, nhưng không phải là công cụ để định nghĩa hạ tầng.
  • Vì vậy, CodePipeline không phải đáp án cho “create infrastructure from code”.

📚 Tóm tắt lại (danh sách)

• ✅ AWS CloudFormation – Dịch vụ IaC chính thức của AWS, cho phép tạo, cập nhật và quản lý hạ tầng từ code (templates).
• ❌ Amazon Elastic Kubernetes Service (Amazon EKS) – Managed Kubernetes, không phải IaC.
• ❌ AWS Outposts – Giải pháp hạ tầng on‑premise, không phải công cụ mô tả hạ tầng.
• ❌ AWS CodePipeline – Dịch vụ CI/CD, chỉ dùng để điều phối quá trình triển khai, không tự tạo hạ tầng.

📘 Tham khảo nguồn tài liệu (cập nhật tới 2026)

1. AWS CloudFormation Documentation – https://docs.aws.amazon.com/cloudformation/
2. AWS Well‑Architected Framework – Operational Excellence Pillar (đề cập tới IaC): https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operational-excellence-pillar.html
3. What's New in AWS CloudFormation – 2025/2026 Updates – https://aws.amazon.com/cloudformation/whats-new/
4. AWS CodePipeline User Guide – https://docs.aws.amazon.com/codepipeline/latest/userguide/

🧩 Kết luận: Đối với câu hỏi “Which AWS service can companies use to create infrastructure from code?” đáp án duy nhất và chính xác là AWS CloudFormation. Các tùy chọn còn lại là các dịch vụ hỗ trợ hoặc liên quan, nhưng không thực hiện chức năng IaC trực tiếp.

🔎 Phân tích câu hỏi
Câu hỏi: “Which guideline is a well‑architected design principle for building cloud applications?”
Nó yêu cầu bạn chọn nguyên tắc thiết kế nằm trong AWS Well‑Architected Framework – một tập hợp các hướng dẫn giúp xây dựng, vận hành và tối ưu hoá các ứng dụng trên đám mây một cách an toàn, hiệu quả và chi phí hợp lý. Các nguyên tắc này được chia thành 5 trụ cột: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization. Trong số các lựa chọn, chỉ có một đáp án phản ánh đúng một trong những nguyên tắc này.

✅ Đáp án đúng

✔️ “Design for automated recovery from failure.”

Giải thích:

• Đây là nguyên tắc của trụ cột Reliability trong AWS Well‑Architected Framework.
• Thiết kế để tự động phát hiện, cô lập và khôi phục sau khi xảy ra lỗi giúp hệ thống duy trì độ sẵn sàng cao, giảm thời gian chết (MTTR) và giảm thiểu tác động tới người dùng.
• AWS cung cấp các dịch vụ hỗ trợ tự động phục hồi như Auto Scaling, Elastic Load Balancing, Amazon RDS Multi‑AZ, AWS Elastic Beanstalk health checks, AWS Lambda + EventBridge, …
• Từ phiên bản cập nhật của Framework (2024‑2025) vẫn nhấn mạnh “automated recovery” như một trong “Design for resiliency and fault tolerance”.

Vì vậy đáp án này là đúng.

❌ Các đáp án sai và phân tích

1. ❌ “Keep static data closer to compute resources.”

   • Tại sao sai?
     • Nguyên tắc này không xuất hiện trong AWS Well‑Architected Framework.
     • Thực tế, AWS khuyến nghị đặt dữ liệu tĩnh (ví dụ: hình ảnh, video, tài nguyên tĩnh) vào Amazon S3 hoặc CloudFront (CDN) để tối ưu latency và chi phí, không nhất thiết “gần” compute.
     • Khi cần “gần” compute, chúng ta thường dùng Amazon EFS hoặc Amazon FSx cho workloads có nhu cầu I/O cao, nhưng đây không phải là một “guideline” chung cho toàn bộ thiết kế.

2. ❌ “Provision resources for peak capacity.”

   • Tại sao sai?
     • Đây ngược lại với nguyên tắc Cost Optimization và Performance Efficiency.
     • AWS khuyến cáo “right‑size” và “scale out/in automatically” dựa trên nhu cầu thực tế, không phải provision cho tải cực đại luôn.
     • Việc dự trữ tài nguyên cho đỉnh tải dẫn tới chi phí dư thừa, lãng phí và vi phạm nguyên tắc “pay‑as‑you‑go”.

3. ❌ “Use tightly coupled components.”

   • Tại sao sai?
     • Well‑Architected Framework đề xuất độ liên kết lỏng (loose coupling) để tăng tính resilience và scalability.
     • Khi các thành phần gắn kết chặt chẽ, lỗi ở một thành phần có thể lan truyền tới toàn bộ hệ thống, làm giảm độ tin cậy.
     • AWS khuyến khích sử dụng Amazon SQS, SNS, EventBridge, hoặc AWS Step Functions để tách rời các dịch vụ, tạo kiến trúc event‑driven.

🧩 Tóm tắt nguyên tắc liên quan

• Reliability (Độ tin cậy) → “Design for automated recovery from failure”.
• Performance Efficiency (Hiệu suất) → Sử dụng tài nguyên linh hoạt, không dự trữ cho peak capacity.
• Cost Optimization (Tối ưu chi phí) → Tránh over‑provisioning, chỉ dùng tài nguyên khi cần.
• Operational Excellence (Vận hành xuất sắc) → Tự động hoá quy trình phục hồi, giảm thao tác thủ công.
• Security (Bảo mật) → Không liên quan trực tiếp tới các tùy chọn trên.

📚 Tham khảo

• AWS Well‑Architected Framework, phiên bản cập nhật 2025 – các trụ cột và nguyên tắc thiết kế.
• AWS Documentation – Reliability Pillar, mục “Design for automated recovery”.
• AWS Architecture Blog (2024‑2025): “Building resilient applications with automated recovery”.
• AWS Well‑Architected Tool (console) – hướng dẫn chi tiết từng câu hỏi kiểm tra.

Kết luận:
✅ Đáp án “Design for automated recovery from failure.” là nguyên tắc đúng trong AWS Well‑Architected Framework, còn ba lựa chọn còn lại không phản ánh các guideline được AWS công nhận. Hy vọng phần phân tích trên giúp bạn nắm vững nội dung và lý do lựa chọn! 🚀

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

Công ty cần chuyển 75 petabytes (PB) dữ liệu từ trung tâm dữ liệu on‑premise sang AWS.
Yêu cầu quan trọng nhất trong đề bài là “MOST cost‑effectively” – nghĩa là phải tìm dịch vụ cho phép di chuyển khối lượng dữ liệu cực lớn với chi phí thấp nhất, đồng thời vẫn đảm bảo tính khả dụng và độ tin cậy.

Trong danh sách các dịch vụ AWS, các lựa chọn có tính năng “vận chuyển dữ liệu vật lý” (Snowball, Snowmobile) hoặc “kết nối mạng” (Direct Connect, Storage Gateway). Vì khối lượng dữ liệu rất lớn (75 PB), việc dùng kết nối mạng thông thường sẽ tốn thời gian và chi phí rất cao, trong khi các thiết bị vận chuyển vật lý được thiết kế cho các khối lượng dữ liệu “đại diện” (hundreds of TB – few PB) hoặc “siêu lớn” (tens‑hàng PB).

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

🛠️ Lý do lựa chọn

• Khả năng chứa dữ liệu: Snowmobile là một container vận tải (tương tự một chiếc xe tải) có khả năng chứa tới 100 PB dữ liệu, đáp ứng đủ 75 PB của công ty.
• Chi phí: Mô hình tính phí của Snowmobile dựa trên phí thuê container + phí vận chuyển + phí chuyển dữ liệu sang S3, thường rẻ hơn so với việc truyền 75 PB qua mạng (điều này có thể mất hàng tháng và tính phí băng thông, thiết bị mạng, và chi phí nhân công).
• Thời gian: Snowmobile có thể chuyển toàn bộ dữ liệu trong vài ngày tới vài tuần tùy vào độ phức tạp, nhanh hơn nhiều so với truyền qua mạng với cùng khối lượng.
• Bảo mật: Dữ liệu được mã hoá AES‑256 và bảo vệ bằng khóa KMS; container được giám sát 24/7 và có khóa an toàn.
• Cập nhật 2026: AWS đã mở rộng dịch vụ Snowmobile để hỗ trợ tối đa 200 PB (khi ghép nhiều container) và cung cấp tùy chọn “Hybrid Snowmobile” cho việc di chuyển một phần qua mạng và phần còn lại qua container, nhưng trong trường hợp 75 PB, một Snowmobile duy nhất vẫn là giải pháp tối ưu nhất về chi phí.

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

1. [SAI] AWS Snowball Edge Storage Optimized

• Giải thích: Snowball Edge Storage Optimized có dung lượng ≈ 80 TB mỗi thiết bị và tối đa 42 TB cho phiên bản chuẩn (tùy phiên bản). Để chuyển 75 PB, công ty cần > 900 thiết bị và phải thực hiện hàng trăm chuyến vận chuyển. Chi phí thuê, vận chuyển, và quản lý hàng trăm thiết bị sẽ cao hơn so với Snowmobile.
• Kết luận: Không đáp ứng yêu cầu “most cost‑effective” cho quy mô 75 PB.

2. [ĐÚNG] AWS Snowmobile

• (Đã giải thích ở mục trên)

3. [SAI] AWS Direct Connect

• Giải thích: Direct Connect cung cấp kết nối mạng riêng (10 Gbps, 100 Gbps, thậm chí 200 Gbps trong một số khu vực).
  • Để truyền 75 PB qua đường 100 Gbps, thời gian tính toán sơ bộ:
    • 1 Gbps ≈ 0.125 GB/s → 100 Gbps ≈ 12.5 GB/s.
    • 75 PB = 75 000 TB = 75 000 000 GB.
    • Thời gian = 75 000 000 GB / 12.5 GB/s ≈ 6 000 000 s ≈ 69  ngày (không tính thời gian thiết lập, mất gói, hoặc downtime).
  • Thêm phí băng thông, phí cổng, phí thiết bị sẽ làm tăng chi phí lên hàng chục triệu USD.
• Kết luận: Direct Connect không phải là giải pháp chi phí hiệu quả cho khối lượng dữ liệu khổng lồ này.

4. [SAI] AWS Storage Gateway

• Giải thích: Storage Gateway là một công cụ hybrid cho phép các ứng dụng on‑premise truy cập dịch vụ lưu trữ AWS (S3, Glacier) qua giao thức NFS/SMB hoặc iSCSI. Nó không phải là giải pháp “vận chuyển dữ liệu lớn” mà là cầu nối đồng bộ/đồng bộ một phần.
  • Để di chuyển 75 PB, cần đồng bộ toàn bộ dữ liệu qua Internet hoặc Direct Connect, dẫn tới chi phí băng thông và thời gian cao.
• Kết luận: Không phù hợp cho mục tiêu di chuyển quy mô 75 PB với chi phí thấp nhất.

📚 Tham khảo tài liệu (tính đến 2026)

1. AWS Snowmobile – Overview (AWS Documentation, cập nhật 2026)
   https://docs.aws.amazon.com/snowmobile/latest/ug/what-is-snowmobile.html
2. AWS Snowball Edge – Storage Optimized (AWS Documentation, 2026)
   https://docs.aws.amazon.com/snowball-edge/latest/userguide/what-is-snowball-edge.html
3. AWS Direct Connect – Pricing & Performance (AWS Documentation, 2026)
   https://aws.amazon.com/directconnect/pricing/
4. AWS Storage Gateway – Types & Use Cases (AWS Documentation, 2026)
   https://docs.aws.amazon.com/storagegateway/latest/userguide/what-is-storage-gateway.html
5. AWS Blog – “Cost‑Effective Data Transfer at Scale with Snowmobile” (Mar 2025)
   https://aws.amazon.com/blogs/storage/cost-effective-data-transfer-snowmobile/

🏁 Tổng kết

• Câu hỏi yêu cầu lựa chọn dịch vụ chi phí thấp nhất để di chuyển 75 PB dữ liệu.
• AWS Snowmobile là lựa chọn đúng vì nó được thiết kế cho khối lượng dữ liệu lên tới 100 PB (hoặc hơn khi ghép nhiều container) và chi phí tổng thể thấp hơn so với các giải pháp mạng hoặc các thiết bị Snowball nhỏ hơn.
• Các phương án còn lại (Snowball Edge, Direct Connect, Storage Gateway) không đáp ứng được yêu cầu về khối lượng và chi phí ở mức tối ưu.

📖 Giải thích nội dung câu hỏi

Câu hỏi yêu cầu bạn chọn hai trong số các lựa chọn là cột trụ (pillars) của AWS Well‑Architected Framework.
AWS Well‑Architected Framework (WAF) là bộ hướng dẫn giúp thiết kế, xây dựng và vận hành các kiến trúc trên AWS một cách tối ưu, an toàn và bền vững. Từ phiên bản mới nhất (2024‑2025, vẫn được duy trì trong 2026), năm cột trụ của WAF là:

1. Operational Excellence
2. Security
3. Reliability
4. Performance Efficiency
5. Cost Optimization

Do câu hỏi chỉ cho phép chọn hai đáp án, bạn phải xác định trong các lựa chọn nào thuộc hai cột trụ trên.

✅ Đáp án đúng

• [ĐÚNG] Performance efficiency
• [ĐÚNG] Operational excellence

Lý do lựa chọn:

• Performance efficiency là một trong năm cột trụ, tập trung vào việc sử dụng tài nguyên AWS một cách tối ưu, đáp ứng nhu cầu thay đổi của tải công việc và tận dụng các công nghệ mới.
• Operational excellence cũng là một cột trụ, hướng tới việc vận hành, giám sát và cải tiến quy trình một cách hiệu quả, giảm thiểu lỗi và tăng tốc độ phản hồi.

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

• [SAI] Resource scalability

  • Giải thích: “Resource scalability” (khả năng mở rộng tài nguyên) là một khía cạnh của cột trụ Performance Efficiency và Reliability, nhưng không phải là một cột trụ độc lập trong WAF. Do đó không được liệt kê trong danh sách năm cột trụ.

• [SAI] System elasticity

  • Giải thích: “System elasticity” mô tả khả năng hệ thống tự động thích nghi với biến động tải, là một đặc tính của Reliability và Performance Efficiency, nhưng không phải là cột trụ riêng biệt.

• [SAI] Agile development

  • Giải thích: Phương pháp Agile là một phong cách quản lý dự án/phát triển phần mềm, không phải là một trong năm cột trụ của WAF. Nó có thể hỗ trợ Operational Excellence, nhưng không được công nhận là pillar.

🧩 Tổng hợp lại (danh sách)

1. Performance efficiency – ✅ Đúng, là một pillar.
2. Operational excellence – ✅ Đúng, là một pillar.
3. Resource scalability – ❌ Sai, chỉ là một yếu tố con trong các pillar.
4. System elasticity – ❌ Sai, không phải pillar độc lập.
5. Agile development – ❌ Sai, là phương pháp phát triển, không nằm trong WAF.

📚 Tham khảo

• AWS Well‑Architected Framework – Trang tài liệu chính thức AWS (phiên bản cập nhật 2024‑2025, vẫn áp dụng đến 2026): https://docs.aws.amazon.com/wellarchitected/latest/framework/well-architected-framework.html
• AWS Well‑Architected Tool – Hướng dẫn sử dụng công cụ kiểm tra các pillar: https://aws.amazon.com/well-architected-tool/
• AWS Well‑Architected Whitepaper (2025 edition), phần “Five Pillars of the AWS Well‑Architected Framework”.

🛠️ Kết luận:
Trong các lựa chọn đưa ra, chỉ có Performance efficiency và Operational excellence là hai cột trụ chính thức của AWS Well‑Architected Framework. Các lựa chọn còn lại là các khái niệm phụ hoặc phương pháp quản lý, không nằm trong danh sách năm pillar.

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

Câu hỏi yêu cầu kết nối trung tâm dữ liệu (on‑premises) với AWS Cloud bằng một đường truyền riêng, độ trễ thấp và hiệu suất mạng ổn định.
Điều này gợi ý tới một giải pháp mạng được triển khai riêng biệt (dedicated), không phụ thuộc vào internet công cộng và có thể cung cấp băng thông, độ trễ, và QoS được dự đoán trước.

✅ Đáp án đúng: AWS Direct Connect

👉 Lý do chọn

• Dedicated private connection: Direct Connect tạo một đường dây vật lý (có thể là fiber hoặc copper) giữa cơ sở on‑premises và một AWS Direct Connect location.
• Low latency & consistent performance: Vì lưu lượng không đi qua internet công cộng, độ trễ thường nhỏ hơn 2‑5 ms (tùy region) và băng thông ổn định từ 1 Gbps tới 400 Gbps.
• Hybrid networking features: Có thể tích hợp với AWS Transit Gateway, VPC peering, AWS PrivateLink, và BGP để duy trì định tuyến động và cân bằng tải.
• Cost‑effective for high‑volume traffic: Khi lượng dữ liệu lớn, chi phí chuyển dữ liệu qua Direct Connect thường rẻ hơn so với VPN qua internet.

Nguồn: AWS Documentation – AWS Direct Connect Overview (phiên bản 2026) 📘

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

1️⃣ AWS Global Accelerator (đánh dấu là SAI)

• Chức năng: Dịch vụ tầng 4 (TCP/UDP) cải thiện hiệu suất truy cập ứng dụng trên internet bằng cách đưa người dùng tới điểm cuối (endpoint) gần nhất trong mạng AWS Edge.
• Tại sao không phù hợp: Global Accelerator không tạo kết nối riêng giữa on‑premises và AWS; nó vẫn đi qua internet công cộng và không đảm bảo độ trễ “low‑latency” hay hiệu suất ổn định cho giao thông nội bộ của doanh nghiệp.
• Kết luận: ❌ Không đáp ứng yêu cầu “dedicated, low‑latency connection”.

2️⃣ Amazon CloudFront (đánh dấu là SAI)

• Chức năng: Mạng phân phối nội dung (CDN) cung cấp caching và phân phát tài nguyên tĩnh/dộng tới người dùng cuối trên toàn cầu.
• Tại sao không phù hợp: CloudFront là dịch vụ phía người dùng (client‑side), không phải kết nối mạng nội bộ. Nó không tạo đường truyền riêng giữa data center và AWS và không kiểm soát độ trễ cho traffic nội bộ.
• Kết luận: ❌ Không phải giải pháp kết nối hybrid.

3️⃣ AWS Managed VPN (đánh dấu là SAI)

• Chức năng: Thiết lập đường hầm VPN IPSec giữa VPC và mạng on‑premises qua Internet (hoặc Direct Connect + VPN).
• Tại sao không phù hợp: Mặc dù cung cấp kết nối bảo mật, VPN vẫn đi qua Internet, nên độ trễ và băng thông không ổn định so với Direct Connect. Đối với yêu cầu “dedicated, low‑latency”, VPN không đáp ứng được.
• Kết luận: ❌ Không đáp ứng yêu cầu “dedicated” và “consistent performance”.

📋 Tổng hợp lại (danh sách)

• ✅ AWS Direct Connect – đáp ứng đầy đủ yêu cầu: kết nối riêng, độ trễ thấp, hiệu suất ổn định, khả năng mở rộng băng thông.
• ❌ AWS Global Accelerator – cải thiện hiệu suất truy cập internet, không phải kết nối dedicated.
• ❌ Amazon CloudFront – CDN cho người dùng cuối, không phải giải pháp kết nối hybrid.
• ❌ AWS Managed VPN – VPN qua Internet, không đạt mức độ độ trễ và tính ổn định cần thiết.

📚 Tham khảo

1. AWS Direct Connect – Overview (2026). Amazon Web Services, Inc. https://docs.aws.amazon.com/directconnect/latest/UserGuide/what-is-direct-connect.html
2. AWS Global Accelerator – How it works (2026). https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html
3. Amazon CloudFront – What is CloudFront? (2026). https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html
4. AWS Site‑to‑Site VPN – Overview (2026). https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html

💡 Mẹo thi AWS DevOps Engineer Professional: Khi câu hỏi nói “dedicated, low‑latency connection with consistent network performance” giữa on‑premises và AWS, luôn nghĩ tới Direct Connect. Các dịch vụ khác (Global Accelerator, CloudFront, Managed VPN) đều phụ thuộc vào Internet và không đáp ứng yêu cầu “dedicated”.

🔎 Phân tích câu hỏi
Câu hỏi yêu cầu lựa chọn hai nguyên tắc thiết kế mà một công ty nên áp dụng cho các workload trên AWS nhằm tối đa hoá tính bền vững (sustainability) và giảm thiểu tác động môi trường.
Trong AWS, “Sustainability Pillar” của AWS Well‑Architected Framework (cập nhật tới năm 2026) nhấn mạnh các thực tiễn sau:

1. Tối ưu hoá việc sử dụng tài nguyên – chạy các workload ở mức độ sử dụng cao, tránh “idle” hoặc “over‑provisioned” để giảm lãng phí năng lượng.
2. Giảm thiểu công việc lặp lại, tái triển khai không cần thiết – bằng cách dùng kiến trúc immutable, container, serverless, hoặc các công cụ tự động cập nhật, giảm số lần người dùng phải cài lại ứng dụng.
3. Ưu tiên dịch vụ quản lý (managed services) – vì AWS vận hành hạ tầng hiệu quả hơn so với việc tự quản lý, giúp giảm tiêu thụ năng lượng và tài nguyên.
4. Sử dụng right‑sizing, auto‑scaling, spot instances… để cân bằng giữa nhu cầu và tài nguyên.

Dựa trên những nguyên tắc trên, chúng ta xem xét từng lựa chọn.

✅ Đáp án đúng

1️⃣ Maximize utilization of Amazon EC2 instances.

• Giải thích: Khi các EC2 instance được tận dụng tối đa (CPU, memory, network), chúng hoạt động gần mức công suất thiết kế, giảm thời gian “idle”. Điều này giảm lượng điện tiêu thụ cho cùng một khối lượng công việc, đồng thời giảm nhu cầu mua thêm máy chủ vật lý – một trong những yếu tố chính tạo ra phát thải CO₂. AWS khuyến cáo dùng Auto Scaling, Right‑sizing, và Spot Instances để đạt được mức sử dụng cao nhất.
• Liên quan tới Sustainability Pillar: “Optimize resource utilization to reduce waste.”

2️⃣ Reduce the need for users to reinstall applications.

• Giải thích: Việc giảm số lần người dùng phải cài lại (reinstall) ứng dụng đồng nghĩa với việc giảm các hoạt động I/O, truyền tải dữ liệu, và thời gian chạy các instance chỉ để thực hiện cài đặt. Khi sử dụng immutable infrastructure, container images, hoặc serverless, các bản cập nhật được thực hiện bằng cách thay thế phiên bản mới mà không cần cài lại từ đầu, tiết kiệm năng lượng và giảm tải công việc quản trị.
• Liên quan tới Sustainability Pillar: “Minimize unnecessary compute cycles and storage I/O.”

❌ Các lựa chọn sai

• Minimize utilization of Amazon EC2 instances.

• Giải thích: Giảm mức sử dụng EC2 (để chúng “idle” nhiều hơn) tăng lãng phí năng lượng vì tài nguyên vẫn được cấp phát nhưng không thực hiện công việc. Điều này trái ngược với nguyên tắc “maximize utilization”.

• Minimize usage of managed services.

• Giải thích: AWS managed services (RDS, DynamoDB, Lambda, …) được thiết kế để tối ưu hoá tài nguyên và năng lượng ở mức hạ tầng trung tâm, thường hiệu quả hơn so với việc tự quản lý trên EC2. Vì vậy, không nên giảm việc sử dụng các dịch vụ này; ngược lại, nên tăng việc tận dụng chúng để giảm tiêu thụ tài nguyên.

• Force frequent application reinstallations by users.

• Giải thích: Yêu cầu người dùng cài lại ứng dụng thường xuyên làm tăng số lần khởi động, tải dữ liệu, và tiêu thụ CPU/IO. Đây là hành vi lãng phí năng lượng và tài nguyên, trái hoàn toàn với mục tiêu bền vững.

📚 Tham khảo nguồn tài liệu (AWS, 2026)

• AWS Well‑Architected Framework – Sustainability Pillar (v2023‑2026 update).
• AWS Documentation – Optimize Amazon EC2 Cost and Performance (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/optimizing-ec2.html).
• AWS Blog – Building sustainable applications on AWS (2024).
• AWS Whitepaper – AWS Sustainability Practices (2025).

🧩 Tóm tắt nhanh

• ✅ Maximize utilization of Amazon EC2 instances – dùng tài nguyên ở mức cao, giảm “idle”.
• ✅ Reduce the need for users to reinstall applications – giảm vòng lặp cài đặt, dùng kiến trúc immutable / container / serverless.
• ❌ Minimize utilization of EC2, Minimize usage of managed services, Force frequent application reinstallations – tất cả làm tăng lãng phí năng lượng và không phù hợp với mục tiêu bền vững.

Hy vọng phân tích trên đã giúp bạn nắm rõ nguyên tắc thiết kế bền vững trên AWS! 🌱🚀

📖 Giải thích câu hỏi
Câu hỏi hỏi: “AWS Cloud giúp giảm tổng chi phí sở hữu (Total Cost of Ownership – TCO) của tài nguyên tính toán so với việc tự xây dựng trung tâm dữ liệu tại chỗ (on‑premises) như thế nào? (Chọn 2 đáp án)”.
TCO bao gồm: chi phí vốn ban đầu (CapEx), chi phí vận hành liên tục (OpEx), chi phí bảo trì, nhân lực, năng lượng, giảm thiểu lãng phí tài nguyên, và khả năng tận dụng các ưu đãi quy mô lớn của nhà cung cấp. AWS giảm TCO bằng cách thay đổi mô hình chi trả và khai thác lợi thế quy mô toàn cầu.

✅ Các đáp án đúng

1. “AWS replaces upfront capital expenditures with pay‑as‑you‑go costs.”

   • Giải thích: Trước khi chuyển sang AWS, doanh nghiệp thường phải đầu tư lớn vào phần cứng, phòng máy, phần mềm bản quyền, và chi phí xây dựng hạ tầng (CapEx). AWS cung cấp mô hình pay‑as‑you‑go – trả tiền theo mức sử dụng thực tế (theo giờ, giây, hoặc theo lượng dữ liệu truyền). Điều này chuyển chi phí vốn sang chi phí vận hành (OpEx), giảm rủi ro tài chính, cho phép doanh nghiệp mở rộng hoặc thu hẹp tài nguyên nhanh chóng mà không phải mua thiết bị mới. Đây là một trong những lợi thế TCO nổi bật nhất của đám mây.

2. “AWS uses economies of scale to continually reduce prices.”

   • Giải thích: AWS vận hành hàng triệu máy chủ trên toàn cầu, do đó có khả năng mua phần cứng, năng lượng, và băng thông với chi phí rất thấp (economies of scale). Nhờ vậy, AWS có thể giảm giá dịch vụ thường xuyên (ví dụ: giảm giá EC2 Spot, Reserved Instances, Savings Plans, và giảm giá dịch vụ lưu trữ S3). Khi khách hàng tiêu thụ nhiều tài nguyên, họ còn được hưởng các mức giảm giá sâu hơn. Những giảm giá này không thể đạt được khi tự xây dựng trung tâm dữ liệu quy mô nhỏ.

❌ Các đáp án sai và lý do

• “AWS is designed for high availability, which eliminates user downtime.”

  • Giải thích: Mặc dù AWS cung cấp các dịch vụ và kiến trúc (multi‑AZ, Multi‑Region) giúp đạt được độ sẵn sàng cao, nhưng không có gì có thể “eliminate” (loại bỏ hoàn toàn) thời gian chết. Độ sẵn sàng phụ thuộc vào thiết kế kiến trúc, cấu hình, và các quy trình vận hành của người dùng. Ngoài ra, việc giảm downtime không trực tiếp liên quan tới TCO; nó ảnh hưởng tới chi phí gián đoạn kinh doanh, nhưng không phải là yếu tố giảm chi phí sở hữu trực tiếp.

• “AWS eliminates the need for on‑premises IT staff.”

  • Giải thích: Khi di chuyển lên AWS, doanh nghiệp không thể loại bỏ hoàn toàn đội ngũ IT. Thay vào đó, vai trò của họ chuyển đổi từ quản lý phần cứng và phòng máy sang quản lý dịch vụ đám mây (cloud governance, security, cost‑optimization, automation, CI/CD, v.v.). Các kỹ năng mới (DevOps, Cloud Architecture) vẫn cần có, và nhiều tổ chức vẫn duy trì một phần đội IT nội bộ để quản lý môi trường hybrid hoặc multi‑cloud. Vì vậy, khẳng định AWS “eliminates the need for on‑premises IT staff” là không chính xác.

• “AWS offers a single pricing model for Amazon EC2 instances.”

  • Giải thích: AWS không chỉ có một mô hình giá duy nhất cho EC2. Thực tế, AWS cung cấp nhiều mô hình giá: On‑Demand, Reserved Instances, Savings Plans, Spot Instances, Dedicated Hosts, và các mức giá theo khu vực (region). Sự đa dạng này cho phép khách hàng tối ưu chi phí tùy theo nhu cầu, nhưng không phải là “single pricing model”. Do đó, phát biểu này không phản ánh đúng thực tế và cũng không liên quan trực tiếp tới việc giảm TCO.

🧩 Tổng kết

• Đúng:

  • ✅ AWS replaces upfront capital expenditures with pay-as-you-go costs.
  • ✅ AWS uses economies of scale to continually reduce prices.

• Sai:

  • ❌ AWS is designed for high availability, which eliminates user downtime.
  • ❌ AWS eliminates the need for on-premises IT staff.
  • ❌ AWS offers a single pricing model for Amazon EC2 instances.

📚 Tham khảo

• AWS Well‑Architected Framework – Cost Optimisation Pillar (2024‑2025 updates).
• AWS Pricing Overview, trang chính thức của AWS (https://aws.amazon.com/pricing/).
• AWS Total Cost of Ownership (TCO) Calculator, tài liệu hướng dẫn tính toán TCO (phiên bản 2026).
• AWS Cloud Economics – 2025 Whitepaper, mô tả lợi thế quy mô và mô hình pay‑as‑you‑go.

💡 Lưu ý: Khi trả lời các câu hỏi chứng chỉ, luôn tập trung vào việc liên kết các khái niệm (CapEx → OpEx, economies of scale, đa dạng mô hình giá) với các tiêu chí giảm TCO được nêu trong tài liệu chính thức của AWS.

🔍 Phân tích câu hỏi
Công ty muốn đưa một số tài nguyên lên AWS Cloud nhưng đồng thời phải đáp ứng các yêu cầu quy định:

1. Dữ liệu phải ở lại trên địa bàn (on‑premises) – nghĩa là không được chuyển sang một vùng AWS ở xa, mà cần được lưu trữ, xử lý gần với môi trường vật lý hiện tại của công ty.
2. Độ trễ (latency) phải thấp giữa các tài nguyên AWS và các tài nguyên nội bộ của công ty – để các ứng dụng, dịch vụ có thể giao tiếp nhanh chóng, tránh hiện tượng “lag” khi truy cập qua mạng công cộng.

Vì vậy, câu hỏi đang tìm một dịch vụ hoặc tính năng của AWS cho phép kết nối chặt chẽ, gần địa lý và đảm bảo dữ liệu vẫn ở trong khuôn khổ on‑premises.

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

Lý do:

• AWS Outposts là một phần cứng được AWS cung cấp, được lắp đặt trực tiếp trong trung tâm dữ liệu (data center) hoặc phòng máy của khách hàng.
• Nó cho phép chạy các dịch vụ AWS (EC2, EBS, RDS, ECS, EKS, …) và công cụ quản lý AWS (CloudFormation, CloudWatch, IAM, …) trên hạ tầng nội bộ.
• Dữ liệu luôn ở lại on‑premises, đáp ứng yêu cầu “data must remain local”.
• Vì phần cứng nằm ngay tại chỗ, độ trễ giữa tài nguyên AWS và tài nguyên công ty gần như bằng 0 hoặc cực thấp, đáp ứng yêu cầu “low latency”.
• Ngoài ra, Outposts đồng bộ hoá trạng thái và cấu hình với AWS Region thông qua kết nối AWS Direct Connect hoặc VPN, giúp duy trì tính nhất quán và khả năng mở rộng sang cloud công cộng khi cần.

Nguồn: AWS Documentation – AWS Outposts (phiên bản cập nhật 2026) https://docs.aws.amazon.com/outposts/

🧩 Giải thích các phương án khác (đúng và sai)

- [SAI] AWS Local Zones

• Giải thích: AWS Local Zones là các vùng mở rộng (extension) của một AWS Region, được đặt tại các thành phố lớn để giảm độ trễ cho các ứng dụng chạy trên cloud. Tuy nhiên, Local Zones vẫn là tài nguyên AWS ở ngoài trung tâm dữ liệu của khách hàng; dữ liệu và compute không nằm trên hạ tầng on‑premises mà vẫn ở trong vùng AWS. Vì câu hỏi yêu cầu dữ liệu phải ở lại nội bộ (on‑premises), nên Local Zones không đáp ứng yêu cầu này.
• Kết luận: ❌ Không phù hợp.

- [SAI] Availability Zones

• Giải thích: Availability Zones (AZ) là các trung tâm dữ liệu độc lập trong một Region, được thiết kế để cung cấp tính sẵn sàng và khả năng chịu lỗi. AZ hoàn toàn nằm trong mạng AWS và không có khả năng “đặt tại chỗ” của khách hàng. Do đó, không đáp ứng yêu cầu dữ liệu phải ở trên cơ sở hạ tầng nội bộ và không giảm độ trễ tới mức “on‑premises”.
• Kết luận: ❌ Không phù hợp.

- [ĐÚNG] AWS Outposts

• Giải thích: Như đã nêu ở phần đáp án đúng. Outposts mang lại điểm mạnh:
  • On‑premises: phần cứng AWS được cài đặt tại vị trí khách hàng.
  • Low latency: giao tiếp nội bộ nhanh, không phải đi qua internet công cộng.
  • Quản lý qua console AWS: đồng nhất với các dịch vụ cloud.
  • Tuân thủ quy định: dữ liệu không rời khỏi phạm vi địa lý yêu cầu.
• Kết luận: ✅ Phù hợp hoàn hảo.

- [SAI] AWS Wavelength Zones

• Giải thích: AWS Wavelength được thiết kế để đưa các dịch vụ AWS tới mạng lưới 5G của các nhà cung cấp viễn thông, nhằm giảm độ trễ cho ứng dụng di động, IoT tại cạnh biên (edge). Wavelength Zones nằm trong các nhà mạng, không phải trong trung tâm dữ liệu của khách hàng, và không giữ dữ liệu trên premises. Vì vậy, chúng không đáp ứng yêu cầu “data must remain local/on‑premises”.
• Kết luận: ❌ Không phù hợp.

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

1. AWS Outposts – Documentation (phiên bản 2026). https://docs.aws.amazon.com/outposts/
2. AWS Local Zones – What Is It? (2026). https://aws.amazon.com/about-aws/global-infrastructure/localzones/
3. AWS Wavelength – Overview (2026). https://aws.amazon.com/wavelength/
4. AWS Well‑Architected Framework – Operational Excellence Pillar – đề cập đến việc lựa chọn kiến trúc phù hợp với yêu cầu latency và dữ liệu nội bộ.

🏁 Tổng kết

• Câu hỏi yêu cầu một giải pháp giữ dữ liệu on‑premises đồng thời đảm bảo độ trễ thấp giữa AWS và tài nguyên nội bộ.
• AWS Outposts là lựa chọn duy nhất đáp ứng cả hai yêu cầu này, vì nó mang dịch vụ AWS vào trung tâm dữ liệu của khách hàng, cho phép chạy hầu hết các dịch vụ AWS với độ trễ gần bằng 0 và giữ dữ liệu tại chỗ.

💡 Lưu ý: Khi triển khai Outposts, cần chuẩn bị kết nối AWS Direct Connect hoặc VPN để đồng bộ với Region, và cân nhắc chi phí phần cứng & vận hành so với các giải pháp hybrid khác (ví dụ: VMware Cloud on AWS, hoặc sử dụng Direct Connect + EC2 on‑premises).

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

🔎 Phân tích câu hỏi
Câu hỏi yêu cầu chọn hai dịch vụ AWS thuộc loại “serverless”. “Serverless” ở AWS nghĩa là bạn không cần quản lý, provision, hoặc scaling các máy chủ (instance) dưới lớp hạ tầng; thay vào đó, AWS tự động thực hiện việc này và bạn chỉ trả tiền cho thời gian thực thi thực tế.

✅ Đáp án đúng

• AWS Fargate
• AWS Lambda

Hai dịch vụ này cung cấp môi trường thực thi hoàn toàn không cần quản lý server:

• AWS Lambda: chạy mã (functions) dựa trên sự kiện, tự động scale và chỉ tính phí theo thời gian thực thi (ms).
• AWS Fargate: cho phép chạy containers (ECS hoặc EKS) mà không cần provision EC2 instances; AWS lo việc provisioning, scaling và patching.

📚 Giải thích chi tiết từng phương án

• [SAI] AWS Outposts

  • Outposts là một giải pháp hạ tầng on‑premise do AWS cung cấp (có máy chủ vật lý được đặt tại trung tâm khách hàng). Bạn vẫn phải quản lý tài nguyên (EC2, EBS…) trên thiết bị này, vì vậy không thuộc loại serverless.
  • 🛑 Lý do sai: Yêu cầu quản lý phần cứng và các instance, không tự động scaling như serverless.

• [SAI] Amazon EC2

  • Elastic Compute Cloud (EC2) là dịch vụ IaaS cho phép bạn tạo, cấu hình và quản lý các virtual machine (instances). Bạn phải quyết định loại instance, kích thước, scaling policy, patching, v.v.
  • 🛑 Lý do sai: Người dùng luôn phải quản lý lifecycle của instance; không phải là serverless.

• [SAI] Amazon Elastic Kubernetes Service (Amazon EKS)

  • EKS là dịch vụ managed Kubernetes. Nó quản lý control plane (API server, etcd) nhưng cần các worker nodes (EC2 hoặc Fargate) để chạy pod. Khi bạn dùng EKS trên Fargate, phần compute lại trở thành serverless, nhưng EKS tự nó không phải là serverless vì vẫn yêu cầu provision node group (trừ khi dùng Fargate, thì phần compute thuộc Fargate).
  • 🛑 Lý do sai: EKS chỉ quản lý control plane; compute vẫn cần node (EC2 hoặc Fargate). Do câu hỏi yêu cầu chọn dịch vụ serverless, EKS không đáp ứng.

• [ĐÚNG] AWS Fargate

  • Fargate là engine chạy container (ECS hoặc EKS) không cần provisioning EC2. Bạn chỉ khai báo task definition hoặc pod, còn lại AWS lo việc provisioning, scaling, patching. Tính phí dựa trên vCPU và memory được sử dụng.
  • ✅ Lý do đúng: Hoàn toàn serverless – không có server để quản lý.

• [ĐÚNG] AWS Lambda

  • Lambda thực thi code (functions) dựa trên các trigger (API Gateway, S3, DynamoDB, CloudWatch, v.v.). Bạn không cần provision, scale, hay quản lý server; chi phí tính theo số lần gọi và thời gian thực thi.
  • ✅ Lý do đúng: Điển hình dịch vụ serverless đầu tiên của AWS.

📖 Tham khảo (2026)

1. AWS Lambda – Serverless Compute – AWS Documentation, “What is AWS Lambda?” (updated 2024‑2026).
2. AWS Fargate – Serverless Compute for Containers – AWS Documentation, “AWS Fargate Overview”.
3. Amazon EC2 – Virtual Servers in the Cloud – AWS Documentation.
4. Amazon EKS – Managed Kubernetes – AWS Documentation, “Amazon EKS pricing and node options”.
5. AWS Outposts – Bring native AWS services, infrastructure, and operating models to virtually any data center – AWS Documentation.

🧩 Tóm tắt nhanh

• ✅ Serverless: AWS Lambda, AWS Fargate.
• ❌ Không serverless: AWS Outposts, Amazon EC2, Amazon EKS (trừ khi chạy trên Fargate, nhưng EKS bản thân không phải).

Hy vọng phần phân tích trên giúp bạn nắm rõ lý do lựa chọn đúng và hiểu được điểm khác biệt giữa các dịch vụ! 🚀