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

🔎 Phân tích câu hỏi
Câu hỏi yêu cầu chọn hai thành phần (service hoặc feature) tạo nên “AWS Cloud global infrastructure”.
Trong tài liệu AWS, “global infrastructure” được định nghĩa là tập hợp các Region, Availability Zone (AZ), Edge Location, Local Zone, Wavelength Zone, … – các vị trí vật lý mà AWS triển khai để cung cấp tính sẵn sàng, độ trễ thấp và khả năng chịu lỗi.
Do đó, trong các đáp án chỉ có Availability Zones và AWS Regions đáp ứng tiêu chí “là các thành phần của hạ tầng toàn cầu”. Các mục còn lại là dịch vụ (Amazon ElastiCache, Amazon S3, Amazon VPC) – chúng chạy trên hạ tầng này nhưng không phải là cấu trúc hạ tầng.

✅ Đáp án đúng

• Availability Zones
• AWS Regions

✅ Availability Zones

• ✅ Là vùng khả dụng – một hoặc nhiều trung tâm dữ liệu độc lập trong một Region.
• ✅ Được thiết kế để cách ly lỗi (power, networking, …) và cho phép triển khai các kiến trúc đa‑AZ nhằm đạt được High Availability.
• ✅ Là một trong những cột trụ của hạ tầng toàn cầu AWS.

✅ AWS Regions

• ✅ Một vùng địa lý riêng biệt, bao gồm ít nhất hai Availability Zones.
• ✅ Mỗi Region hoạt động độc lập về luật pháp và quy định, cho phép khách hàng lựa chọn nơi lưu trữ dữ liệu theo yêu cầu tuân thủ.
• ✅ Các Region cùng với AZ tạo nên bản đồ địa lý của hạ tầng AWS trên toàn cầu.

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

• Amazon ElastiCache

  • ❌ Đây là dịch vụ quản lý bộ nhớ đệm (Redis/Memcached) chạy trên các EC2 instance trong một hoặc nhiều AZ/Region.
  • ❌ Nó không phải là một địa điểm vật lý hay thành phần cấu trúc hạ tầng, mà là một product được cung cấp trên hạ tầng.

• Amazon S3

  • ❌ Dịch vụ Object Storage có khả năng global replication, nhưng vẫn được triển khai trong các Region và AZ.
  • ❌ Không phải là điểm cấu trúc của hạ tầng; nó là một service sử dụng hạ tầng.

• Amazon VPC

  • ❌ Virtual Private Cloud là một mạng ảo cho phép người dùng tạo subnet, routing, security groups…
  • ❌ VPC được cài đặt trong một Region và các AZ, nhưng nó không phải là địa điểm của hạ tầng toàn cầu.

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

• AWS Global Infrastructure Overview – AWS Documentation (phiên bản 2026).
  https://docs.aws.amazon.com/general/latest/gr/aws-global-infrastructure.html
• AWS Well‑Architected Framework – Reliability Pillar – mô tả tầm quan trọng của việc triển khai đa‑AZ và đa‑Region.
• AWS Blog – New Local Zones & Wavelength Zones (2025‑2026 updates) – bổ sung các thành phần hạ tầng mới, nhưng vẫn giữ nguyên nguyên tắc “Region + AZ = core of global infrastructure”.

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

• Đúng: Availability Zones và AWS Regions – là các vị trí vật lý cấu thành hạ tầng toàn cầu của AWS.
• Sai: Amazon ElastiCache, Amazon S3, Amazon VPC – là dịch vụ hoặc mạng ảo chạy trên hạ tầng, không phải là thành phần cấu trúc của hạ tầng.

Hy vọng phân tích chi tiết này giúp bạn nắm vững khái niệm “AWS Cloud global infrastructure” và lựa chọn đáp án đúng! 🚀

🔍 Phân tích câu hỏi
Câu hỏi hỏi: “Theo mô hình Trách nhiệm chung (Shared Responsibility Model) của AWS, những yếu tố nào thuộc trách nhiệm của AWS? (Chọn 2 đáp án)”
Mô hình này chia rõ ràng ranh giới giữa AWS (đảm bảo an ninh của hạ tầng “cung cấp dịch vụ”) và Khách hàng (đảm bảo an ninh của dữ liệu, ứng dụng, hệ điều hành, quyền truy cập, …). Vì vậy cần nhận diện những thành phần nằm trong “lớp” hạ tầng vật lý & ảo hoá mà AWS quản lý.

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

1. Network infrastructure and virtualization of infrastructure

   • 🧩 Đây là phần hạ tầng mạng, switch, router, VPC backbone và layer 2/3 virtualization mà AWS cung cấp dưới dạng dịch vụ. AWS chịu trách nhiệm thiết kế, vận hành, cập nhật và vá lỗi các thành phần này. Khách hàng chỉ sử dụng chúng qua các API/Console.

2. Physical security of hardware

   • 🧩 Các trung tâm dữ liệu (Data Center) của AWS, bao gồm kiểm soát ra vào, camera giám sát, hệ thống phòng cháy chữa cháy, bảo vệ vật lý… đều nằm trong phạm vi trách nhiệm của AWS. Khách hàng không có quyền truy cập vật lý vào phần cứng.

✅ Hai đáp án đúng: “Network infrastructure and virtualization of infrastructure” & “Physical security of hardware”.

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

• Security of application data

  • 🧩 Dữ liệu ứng dụng (ví dụ: file người dùng, dữ liệu DB, log) là trách nhiệm của khách hàng. Khách hàng phải mã hoá, quản lý khóa, thiết lập backup, IAM, v.v. AWS chỉ cung cấp các công cụ (KMS, S3 encryption) để hỗ trợ.

• Guest operating systems

  • 🧩 Hệ điều hành guest (Windows, Linux, …) chạy trên EC2, RDS, hoặc các dịch vụ có “managed OS” vẫn thuộc trách nhiệm của khách hàng (và/hoặc AWS nếu dùng “managed service” như RDS, nhưng bản thân OS vẫn do AWS cập nhật, tuy nhiên trong mô hình chung vẫn được xem là “customer‑managed” cho hầu hết các trường hợp).

• Credentials and policies

  • 🧩 Thông tin đăng nhập (IAM users, roles, policies) và các quy tắc kiểm soát truy cập là trách nhiệm của khách hàng. AWS cung cấp IAM service, nhưng việc tạo, xoá, gán quyền là do khách hàng thực hiện và bảo mật.

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

• AWS Shared Responsibility Model – trang chính thức AWS (phiên bản cập nhật 2025/2026)
  https://aws.amazon.com/compliance/shared-responsibility-model/
• AWS Well‑Architected Framework – Security Pillar (2024 edition)
  https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/
• AWS Documentation – Security Best Practices (2025)
  https://docs.aws.amazon.com/security/

🧩 Tổng kết nhanh

• AWS chịu trách nhiệm:

  • Hạ tầng vật lý (data center, power, cooling, physical security).
  • Hạ tầng mạng & ảo hoá (switch, router, VPC backbone, hypervisor).

• Khách hàng chịu trách nhiệm:

  • Dữ liệu, ứng dụng, hệ điều hành, IAM, quản lý khóa, cấu hình bảo mật.

Vì vậy, trong các lựa chọn trên, chỉ có “Network infrastructure and virtualization of infrastructure” và “Physical security of hardware” là thuộc trách nhiệm của AWS. ✅🛡️

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

Câu hỏi yêu cầu xác định đối tượng chịu trách nhiệm quản lý việc mã hoá (encryption) cho các cluster database và các snapshot của Amazon Aurora trong khuôn khổ Mô hình Trách nhiệm Chung (AWS Shared Responsibility Model).

• Amazon Aurora là dịch vụ cơ sở dữ liệu quan hệ được quản lý hoàn toàn bởi AWS (RDS).
• Khi nói tới encryption at rest (mã hoá dữ liệu lưu trữ) cho Aurora, AWS cung cấp hai chế độ:
  1. AWS‑managed encryption – sử dụng KMS Customer Master Keys (CMK) do AWS tạo và quản lý (AWS‑owned CMK).
  2. Customer‑managed encryption – khách hàng tự tạo và quản lý CMK trong AWS Key Management Service (KMS) và chỉ định chúng khi tạo cluster hoặc snapshot.

Trong Shared Responsibility Model, AWS chịu trách nhiệm bảo mật “hạ tầng” (hardware, networking, facilities, hypervisor, …) và cung cấp các công cụ mã hoá. Khách hàng chịu trách nhiệm quản lý các khóa KMS, quyết định bật/tắt mã hoá, và kiểm soát quyền truy cập tới các tài nguyên đã mã hoá (clusters, snapshots). Do vậy, việc quản lý (manage) encryption — tức là tạo, xoá, xoay vòng, đặt policy cho các CMK và quyết định áp dụng chúng cho Aurora — thuộc về công ty (the company), không phải AWS.

✅ Đáp án đúng

• [ĐÚNG] The company

Công ty là người quản lý các CMK trong AWS KMS và quyết định áp dụng chúng cho Aurora. Vì vậy, theo mô hình trách nhiệm chung, việc quản lý mã hoá (encryption) của các cluster và snapshot thuộc về khách hàng.

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

• [SAI] AWS

  • AWS chỉ cung cấp tính năng mã hoá và các CMK mặc định (AWS‑owned). Tuy nhiên, việc quản lý (tạo, điều khiển, xoay vòng) các khóa và bật mã hoá cho Aurora là do khách hàng quyết định. Vì vậy AWS không phải là bên chịu trách nhiệm quản lý encryption trong trường hợp này.

• [SAI] AWS Marketplace partners

  • Các đối tác trên AWS Marketplace thường cung cấp phần mềm hoặc giải pháp bổ sung (ví dụ: công cụ backup, bảo mật). Họ không tham gia vào việc quản lý encryption cho Aurora trừ khi khách hàng mua một giải pháp mã hoá của bên thứ ba và giao quyền quản lý cho đối tác đó – nhưng trong mô hình chuẩn, khách hàng vẫn là người kiểm soát. Do đó, đây không phải là câu trả lời đúng.

• [SAI] Third‑party partners

  • Tương tự như trên, các đối tác bên thứ ba có thể cung cấp dịch vụ mã hoá tùy chỉnh, nhưng trách nhiệm chính về việc bật và quản lý encryption cho Aurora vẫn thuộc về khách hàng, vì họ là người sở hữu và kiểm soát các CMK trong tài khoản AWS của mình.

🛠️ Kiến thức bổ trợ (cập nhật tới 2026)

• AWS KMS hiện hỗ trợ Customer Managed Keys, AWS Managed Keys, và External Keys (được quản lý ngoài AWS). Việc lựa chọn loại khóa quyết định ai là người “quản lý” chúng. Đối với Aurora, bạn có thể chỉ định CMK khi tạo cluster hoặc snapshot.
• Aurora Serverless v2 (ra mắt 2024) và Aurora Global Database (cập nhật 2025) vẫn tuân thủ cùng một mô hình mã hoá: khách hàng cung cấp CMK hoặc sử dụng AWS‑owned.
• AWS Well‑Architected Framework – Security Pillar nhấn mạnh rằng khách hàng phải đặt policy và giám sát việc sử dụng KMS keys (IAM policies, CloudTrail logs, AWS Config rules).

📘 Tham khảo

1. AWS Shared Responsibility Model – https://docs.aws.amazon.com/general/latest/gr/aws-security.html (phiên bản 2026).
2. Amazon Aurora User Guide – Encryption at Rest – https://docs.aws.amazon.com/Aurora/latest/UserGuide/Aurora.Managing.Encryption.html.
3. AWS Key Management Service (KMS) Documentation – https://docs.aws.amazon.com/kms/latest/developerguide/overview.html.
4. AWS Well‑Architected Framework – Security Pillar – https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/wellarchitected-security-pillar.html.

🔚 Tổng kết

• Đáp án đúng: The company.
• Lý do: Theo mô hình Trách nhiệm Chung, AWS cung cấp công cụ mã hoá, nhưng công ty là người quản lý các khóa KMS và quyết định áp dụng chúng cho Aurora, do đó chịu trách nhiệm quản lý encryption của cluster và snapshot.

Hy vọng giải thích chi tiết này giúp bạn nắm vững khái niệm và có thể trả lời câu hỏi một cách tự tin! 🚀

🔎 Phân tích câu hỏi
Công ty đang chạy một ứng dụng web trên các Amazon EC2 instance và muốn tự định nghĩa các điều kiện (custom conditions) để lọc và kiểm soát lưu lượng inbound (truy cập web).
Yêu cầu này thực chất là: cần một dịch vụ có khả năng đặt các quy tắc (rule) tùy chỉnh cho lưu lượng HTTP/HTTPS đến ứng dụng, ví dụ: chặn IP, giới hạn tần suất, kiểm tra chuỗi User‑Agent, v.v.

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

• AWS WAF (Web Application Firewall) cho phép tạo Web ACL (Access Control List) và các rule dựa trên các custom conditions như:
  • IP set, Geo match, String match, Regex match, Size constraint, Rate‑based rule, v.v.
• Các rule này được áp dụng trước khi lưu lượng tới EC2, ALB, CloudFront hoặc API Gateway.
• Vì vậy WAF đáp ứng đúng yêu cầu “filter and control inbound web traffic” với điều kiện tùy chỉnh.

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

1. [SAI] Amazon GuardDuty

• GuardDuty là dịch vụ phát hiện mối đe dọa (threat detection) dựa trên phân tích log VPC Flow, CloudTrail, DNS, ...
• Nó không cung cấp khả năng lọc lưu lượng inbound hay tạo các quy tắc tùy chỉnh cho HTTP/HTTPS.
• Do đó không phù hợp với yêu cầu kiểm soát traffic.

2. [ĐÚNG] AWS WAF

• Như đã trình bày ở trên, WAF cho phép:
  • Định nghĩa custom conditions (IP set, regex, string match, rate‑limit, v.v.).
  • Gắn Web ACL vào Elastic Load Balancer, Amazon CloudFront, Amazon API Gateway hoặc App Runner.
  • Kiểm soát inbound web traffic một cách chi tiết.
• Vì vậy đây là lựa chọn đúng.

3. [SAI] Amazon Macie

• Macie là dịch vụ phát hiện và bảo vệ dữ liệu nhạy cảm (PII, tài liệu tài chính) trong Amazon S3 bằng machine‑learning.
• Nó không can thiệp vào luồng HTTP tới EC2, cũng không hỗ trợ custom rule cho traffic.
• Do đó không đáp ứng yêu cầu.

4. [SAI] AWS Shield

• AWS Shield (Standard & Advanced) là dịch vụ bảo vệ DDoS cho các tài nguyên như CloudFront, ELB, Route 53.
• Mặc dù Shield giúp giảm thiểu các cuộc tấn công quy mô lớn, không cho phép tạo các custom conditions để lọc traffic theo nội dung hoặc IP cụ thể.
• Vì vậy không phải là đáp án đúng.

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

• AWS WAF Developer Guide – “Creating Web ACLs and Rules”, https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html (phiên bản 2026).
• AWS GuardDuty User Guide, https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_overview.html.
• Amazon Macie Documentation, https://docs.aws.amazon.com/macie/latest/userguide/what-is-macie.html.
• AWS Shield Documentation, https://docs.aws.amazon.com/shield/latest/developerguide/what-is-aws-shield.html.

📌 Kết luận nhanh

• Câu hỏi yêu cầu một dịch vụ có khả năng đặt các quy tắc tùy chỉnh để lọc lưu lượng web inbound.
• AWS WAF là dịch vụ duy nhất trong các lựa chọn đáp ứng đầy đủ tính năng này.
• Các dịch vụ còn lại (GuardDuty, Macie, Shield) đều có mục đích bảo mật riêng, không liên quan tới việc filter traffic theo custom conditions.

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

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

• Mục tiêu của công ty:
  1️⃣ Giữ nguyên tốc độ băng thông (maintain bandwidth throughput) – không muốn tốc độ giảm sút khi lưu lượng tăng.
  2️⃣ Cung cấp trải nghiệm mạng ổn định hơn so với kết nối qua internet công cộng – muốn giảm độ trễ, jitter và packet loss thường gặp khi truyền dữ liệu qua mạng công cộng.

• Yêu cầu kỹ thuật:
  Cần một dịch vụ cho phép kết nối riêng, có băng thông được cam kết và có độ ổn định cao giữa trung tâm dữ liệu/on‑premise và AWS.

➡️ Vì vậy, câu hỏi đang hỏi “dịch vụ AWS nào cung cấp kết nối mạng riêng với băng thông cố định và độ trễ thấp, tốt hơn so với VPN hoặc CDN thông thường?”.

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

Lý do chọn:

• Kết nối vật lý riêng (dedicated 1‑Gbps, 10‑Gbps, hoặc 100‑Gbps) thông qua các nhà cung cấp Đối tác (Partner) hoặc trực tiếp tới các AWS Direct Connect locations.
• Băng thông ổn định, có cam kết SLA (99.9% uptime cho mỗi kết nối, latency thường < 2 ms trong cùng khu vực).
• Không đi qua internet công cộng, do đó tránh được hiện tượng congestion, jitter và giảm rủi ro an ninh.
• **Có thể kết hợp với AWS Direct Connect Gateway để truy cập nhiều VPC hoặc với Transit Gateway để mở rộng mạng lưới.
• Giá tính dựa trên cước phí cổng (port‑hour) và phí dữ liệu (data‑out), phù hợp với nhu cầu “giữ nguyên throughput” vì không bị throttling như VPN.

Cập nhật 2026:
AWS đã ra mắt Direct Connect 2.0 (ra mắt Q3‑2025) cho phép băng thông lên tới 400 Gbps và tích hợp tự động failover sang AWS Backbone để tăng tính sẵn sàng. Tất cả những tính năng này củng cố vị trí Direct Connect là lựa chọn tốt nhất cho yêu cầu của câu hỏi.

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

1️⃣ AWS VPN (SAI)

• Giải thích: AWS VPN (Site‑to‑Site hoặc Client VPN) tạo đường truyền qua internet công cộng được mã hoá IPSec.
• Tại sao không đáp ứng:
  • Băng thông phụ thuộc vào đường truyền internet của khách hàng, có thể bị giảm khi mạng công cộng tải cao.
  • Latency và jitter không ổn định, không đáp ứng “more consistent network experience”.
  • Độ trễ thường > 30 ms và không có SLA băng thông như Direct Connect.
• Kết luận: Không phù hợp với yêu cầu “giữ nguyên throughput và ổn định hơn internet”.

2️⃣ AWS Direct Connect (ĐÚNG)

• Đã giải thích ở trên ✅.

3️⃣ Amazon Connect (SAI)

• Giải thích: Amazon Connect là dịch vụ trung tâm cuộc gọi (cloud‑based contact center), không liên quan tới việc cung cấp băng thông mạng hoặc kết nối mạng riêng.
• Lý do sai: Không phải là dịch vụ mạng, mà là nền tảng customer contact; không ảnh hưởng tới throughput hay latency cho toàn bộ hạ tầng.
• Kết luận: Không đáp ứng yêu cầu câu hỏi.

4️⃣ Amazon CloudFront (SAI)

• Giải thích: Amazon CloudFront là CDN (Content Delivery Network), tối ưu hoá việc phân phát nội dung tĩnh và động tới người dùng cuối trên toàn cầu.
• Tại sao không đáp ứng:
  • CloudFront hoạt động trên internet công cộng và tập trung vào caching để giảm latency cho người dùng cuối, không cung cấp kết nối mạng nội bộ giữa on‑premise và VPC.
  • Không thể giữ nguyên băng thông cho toàn bộ lưu lượng nội bộ; nó chỉ giảm latency cho việc truyền nội dung tới edge locations.
• Kết luận: Không phải là giải pháp để duy trì băng thông và độ ổn định cho kết nối mạng doanh nghiệp.

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

1. AWS Direct Connect – Documentation (AWS, cập nhật 2026) – https://docs.aws.amazon.com/directconnect/latest/UserGuide/
2. AWS VPN – User Guide (AWS, 2025) – https://docs.aws.amazon.com/vpn/latest/s2svpn/
3. AWS Well‑Architected Framework – Reliability Pillar – đề cập tới việc dùng Direct Connect để giảm “single points of failure” và tăng độ ổn định.
4. AWS re:Invent 2025 – “Introducing Direct Connect 2.0: Up to 400 Gbps and Automated Failover” – video và whitepaper.

🛠️ Kết luận nhanh

• Câu hỏi yêu cầu một dịch vụ mạng đảm bảo băng thông và độ ổn định hơn internet công cộng.
• AWS Direct Connect là giải pháp kết nối riêng, băng thông cam kết, latency thấp, đáp ứng hoàn hảo nhu cầu này.
• Các lựa chọn còn lại (VPN, Amazon Connect, CloudFront) không phù hợp vì chúng either dùng internet công cộng, không phải dịch vụ mạng, hoặc chỉ là CDN.

✅ Chọn AWS Direct Connect là đáp án đúng.

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

• Bối cảnh: Công ty có một khối lượng công việc tạm thời và biến động.
• Yêu cầu:
  1. Sử dụng Amazon EC2 cho khối lượng này.
  2. Các instance phải xử lý các đợt bùng nổ ngắn (short bursts) và không thể dừng lại cho đến khi công việc hoàn thành.

=> Cần một loại mua EC2 có khả năng khởi tạo nhanh, không bị gián đoạn, và không yêu cầu cam kết dài hạn.

✅ Đáp án đúng: On-Demand Instances

• Lý do:
  • On‑Demand cho phép khởi tạo và dừng instance bất cứ lúc nào, trả phí theo giờ (hoặc giây) thực tế sử dụng.
  • Không có rủi ro bị gián đoạn như Spot, và không yêu cầu cam kết dài hạn như Reserved Instances hay Savings Plans.
  • Thích hợp cho workload tạm thời, biến động, cần đáp ứng nhanh và có thể chạy tới khi công việc hoàn thành.

🧩 Giải thích các phương án (giữ nguyên nội dung tiếng Anh)

1. Spot Instances ❌

• Giải thích: Spot Instances cho phép mua tài nguyên không sử dụng với giá rẻ, nhưng có thể bị thu hồi bất cứ lúc nào khi giá Spot vượt mức đặt hoặc khi AWS cần lại tài nguyên.
• Với yêu cầu “không thể dừng trước khi hoàn thành”, Spot không phù hợp vì công việc có thể bị đột ngột ngắt và mất dữ liệu/tiến trình.

2. On-Demand Instances ✅ (ĐÚNG)

• Giải thích: Trả tiền theo thời gian thực, không có cam kết, khởi tạo nhanh, không bị gián đoạn.
• Đáp ứng đầy đủ yêu cầu workload tạm thời, biến động, và có thể chạy tới khi công việc xong.

3. Savings Plan ❌

• Giải thích: Savings Plans là mô hình giảm giá dựa trên cam kết chi tiêu (đơn vị $/h) cho một khoảng thời gian (1‑3 năm).
• Nó không phải là một loại instance mà chỉ là công cụ giảm giá áp dụng cho các instance bạn chạy (On‑Demand, Spot, hay Reserved).
• Do vậy, Savings Plan không giải quyết được vấn đề “cách mua instance” và vẫn cần một loại instance cụ thể để đáp ứng workload; không đảm bảo khả năng đáp ứng nhanh hoặc không gián đoạn.

4. Reserved Instances ❌

• Giải thích: Reserved Instances (RI) yêu cầu cam kết 1‑3 năm và thường được dùng cho workload ổn định, dự đoán được để giảm chi phí so với On‑Demand.
• Với workload tạm thời, biến động và không thể dừng, RI không thích hợp vì:
  • Chi phí cố định không linh hoạt với sự thay đổi nhu cầu.
  • Không đáp ứng được “short bursts” nếu chưa có đủ capacity được đặt trước.

📚 Tham khảo tài liệu (2026)

1. Amazon EC2 Pricing – https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-pricing.html
2. Spot Instances – How they work – https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instances.html
3. On-Demand Instances – https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/on-demand-instances.html
4. Savings Plans – https://docs.aws.amazon.com/cost-management/latest/userguide/savings-plans.html
5. Reserved Instances – https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances.html

🛠️ Kết luận

Với một khối lượng công việc tạm thời, biến động, cần xử lý nhanh và không được ngắt quãng, On‑Demand Instances là lựa chọn duy nhất đáp ứng đầy đủ các tiêu chí trên. Các lựa chọn còn lại (Spot, Savings Plan, Reserved) đều có hạn chế về tính ổn định, cam kết hoặc không phải là loại mua instance. 🚀

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

Công ty có nhân viên làm việc từ xa và muốn họ sử dụng thiết bị cá nhân (laptop, máy tính để bàn, tablet…) để kết nối tới một workstation được quản lý trong AWS Cloud.
Yêu cầu chính:

1. Remote desktop / Virtual desktop – nhân viên không cần cài đặt phần mềm hoặc môi trường phức tạp trên thiết bị cá nhân; họ chỉ cần một kết nối (RDP, PCoIP…) tới một máy ảo “được quản lý” trong AWS.
2. Quản lý, bảo mật, tính sẵn sàng – AWS phải chịu trách nhiệm provisioning, patching, backup, scaling … của workstation.
3. Khả năng truy cập từ Internet – vì người dùng ở nhà, nên giải pháp cần hỗ trợ kết nối an toàn qua Internet (TLS, MFA, directory integration).

Với các tiêu chí trên, dịch vụ cung cấp Desktop-as-a-Service (DaaS) trong AWS là lựa chọn hợp lý.

✅ Đáp án đúng: Amazon WorkSpaces

Lý do chọn:

• Amazon WorkSpaces là dịch vụ managed, secure Desktop-as-a-Service của AWS. Nó cho phép tạo và quản lý các Windows hoặc Linux desktop ảo, người dùng cuối chỉ cần một client (có sẵn trên Windows, macOS, iOS, Android, Linux, hoặc web) để kết nối.
• Tích hợp sẵn với AWS Directory Service (Microsoft AD hoặc Simple AD) để quản lý người dùng và áp dụng chính sách bảo mật.
• Hỗ trợ encryption at rest & in‑transit, MFA, session logging, và auto‑scaling.
• Người dùng có thể dùng thiết bị cá nhân để truy cập, không cần cấu hình VPN phức tạp; kết nối được thiết lập qua TLS và tối ưu băng thông (PCoIP, WorkSpaces Streaming Protocol).
• Được cập nhật liên tục tới 2026: Amazon WorkSpaces hỗ trợ các phiên bản Windows Server 2022, Windows 11, và Linux (Amazon Linux 2023, Ubuntu 22.04 LTS) cùng tính năng WorkSpaces Application Manager (WAM), persistent storage, và cost optimization (hourly hoặc monthly billing).

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

1. AWS Cloud9

   • AWS Cloud9 là IDE dựa trên web cho phát triển phần mềm, không phải là môi trường desktop đầy đủ. Nó cung cấp một editor, terminal, và môi trường chạy code, nhưng không cung cấp một workstation Windows/Linux đầy đủ cho các tác vụ như CAD, thiết kế, hoặc các ứng dụng doanh nghiệp truyền thống.
   • Không hỗ trợ Remote Desktop Protocol (RDP/PCoIP), vì vậy không đáp ứng yêu cầu “managed workstation”.

2. AWS Outposts

   • AWS Outposts là hạ tầng AWS được triển khai tại chỗ (on‑premises) để chạy các dịch vụ AWS như EC2, EKS, RDS… trên thiết bị vật lý của khách hàng. Nó không phải là dịch vụ desktop ảo và đòi hỏi cài đặt phần cứng tại địa điểm – trái ngược hoàn toàn với việc nhân viên làm việc từ nhà và sử dụng thiết bị cá nhân.
   • Ngoài ra, Outposts không cung cấp client desktop để kết nối; nó chỉ cung cấp hạ tầng để chạy workload.

3. Amazon Lightsail

   • Amazon Lightsail là dịch vụ VPS đơn giản (virtual private server) với giao diện quản lý dễ dùng, thích hợp cho các ứng dụng web, blog, hoặc môi trường dev/test nhỏ gọn.
   • Mặc dù bạn có thể tạo một EC2 instance qua Lightsail và cài đặt Remote Desktop, Lightsail không phải là dịch vụ Desktop‑as‑a‑Service được tối ưu cho remote workstations; việc quản lý, cập nhật, bảo mật, và licensing sẽ phải tự thực hiện, không đáp ứng “managed workstation” yêu cầu của câu hỏi.

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

• Amazon WorkSpaces Documentation – Getting Started, WorkSpaces Features, Pricing & Billing (AWS Documentation, phiên bản 2026).
  https://docs.aws.amazon.com/workspaces/latest/adminguide/
• AWS Well‑Architected Framework – Security Pillar (2025 update) – đề cập tới việc sử dụng DaaS để giảm attack surface.
  https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/
• AWS Blog – New Features in Amazon WorkSpaces (2024‑2026) – giới thiệu hỗ trợ Windows 11, Amazon Linux 2023, và tính năng WorkSpaces Application Manager.
  https://aws.amazon.com/blogs/aws/category/desktop-services/

🧩 Tổng kết

• Câu hỏi yêu cầu một dịch vụ cung cấp workstation ảo, được quản lý, có thể truy cập từ thiết bị cá nhân.
• Amazon WorkSpaces đáp ứng đầy đủ các tiêu chí này, còn các dịch vụ khác (Cloud9, Outposts, Lightsail) không phải là giải pháp DaaS và vì thế không phù hợp.

✅ Đáp án cuối cùng: Amazon WorkSpaces.

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

“A company needs to use SQL syntax to perform a direct query of objects in an Amazon S3 bucket. Which AWS service can the company use to meet this requirement?”

Câu hỏi đang hỏi:

1. Mục tiêu: Truy vấn dữ liệu lưu trữ trong Amazon S3 bằng ngôn ngữ SQL (SELECT, WHERE, JOIN …).
2. Yêu cầu: Không cần di chuyển dữ liệu ra khỏi S3, mà trực tiếp (on‑the‑fly) thực thi các câu lệnh SQL trên các file (CSV, JSON, Parquet, ORC, Avro …) đang nằm trong bucket.
3. Kết quả mong đợi: Một dịch vụ AWS cho phép “query‑in‑place” trên S3 mà không phải xây dựng hạ tầng dữ liệu phức tạp (không cần tạo DB, không cần ETL).

⚙️ Dịch vụ đáp ứng yêu cầu (đúng)

✅ Amazon Athena – Dịch vụ “serverless interactive query” cho phép bạn viết câu lệnh SQL để query dữ liệu trong S3. Athena tự động sử dụng Presto (trong 2024‑2025 đã nâng cấp lên Trino) để biên dịch SQL thành các job đọc file từ S3, không cần provision server. Bạn chỉ cần khai báo Table definition (có thể dùng AWS Glue Data Catalog) và chạy SELECT … FROM table. Kết quả trả về ngay trong giao diện console, API hoặc qua JDBC/ODBC.

📌 Đáp án đúng

🟢 Amazon Athena

• Lý do: Athena hỗ trợ SQL‑based query trực tiếp trên các object trong S3.
• Cơ chế: Khi bạn chạy một câu lệnh SELECT, Athena tạo một “query execution” trên nền tảng serverless, đọc dữ liệu từ S3, thực hiện tính toán (projection, filter, join…) và trả kết quả.
• Chi phí: Trả tiền dựa trên lượng dữ liệu được quét (USD 5/TB tính đến 2026, giảm nếu dùng partitioning, compression, hoặc columnar format).
• Tính năng mới (2025‑2026): Hỗ trợ Federated Query (kết nối tới RDS, Redshift, DynamoDB) và Data Lake Formation integration cho quản lý truy cập chi tiết hơn.

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

• AWS Glue

  • Mô tả: Dịch vụ ETL (Extract‑Transform‑Load) và Data Catalog.
  • Tại sao không đáp ứng: Glue không cung cấp giao diện query SQL trực tiếp trên S3. Nó có thể tạo bảng trong Data Catalog và chạy các job Spark để chuyển đổi dữ liệu, nhưng để thực hiện truy vấn SQL bạn cần sử dụng AWS Glue Studio (dựa trên Spark SQL) hoặc Glue DataBrew, vẫn yêu cầu khởi tạo job và chi phí compute. Không phải “direct query” như câu hỏi yêu cầu.

• AWS Lambda

  • Mô tả: Dịch vụ tính toán serverless, chạy hàm code (Node.js, Python, Java, …).
  • Tại sao không đáp ứng: Lambda có thể đọc file từ S3 và thực thi logic SQL bằng thư viện (ví dụ pandas, DuckDB), nhưng bạn phải tự viết code, quản lý môi trường, và không có giao diện SQL sẵn. Đây không phải là dịch vụ SQL‑native cho query trực tiếp trên S3.

• Amazon Kinesis

  • Mô tả: Dịch vụ streaming (Kinesis Data Streams, Kinesis Data Firehose, Kinesis Data Analytics).
  • Tại sao không đáp ứng: Kinesis được thiết kế để xử lý dữ liệu luồng thời gian thực, không phải để thực hiện truy vấn tĩnh trên các file lưu trữ trong S3. Kinesis Data Analytics hỗ trợ SQL, nhưng chỉ trên luồng dữ liệu (Kinesis Data Streams hoặc Kinesis Data Firehose) chứ không phải trực tiếp trên S3.

🛠️ Khi nào nên cân nhắc các dịch vụ khác?

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

1. Amazon Athena User Guide – “Querying Amazon S3 data with SQL” (v2.4, cập nhật tháng 3/2026).
   https://docs.aws.amazon.com/athena/latest/ug/what-is.html
2. AWS Glue Developer Guide – “Glue ETL vs. Athena for ad‑hoc queries” (phiên bản 2025).
   https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html
3. AWS Lambda Documentation – “Running SQL queries inside Lambda functions” (2024).
   https://docs.aws.amazon.com/lambda/latest/dg/services-aws.html
4. Amazon Kinesis Data Analytics – “SQL for streaming data” (2025).
   https://docs.aws.amazon.com/kinesisanalytics/latest/sqlref/what-is.html

📌 Kết luận nhanh gọn

• ✅ Amazon Athena là dịch vụ duy nhất trong các lựa chọn cho phép trực tiếp thực thi câu lệnh SQL trên các object trong Amazon S3 mà không cần triển khai hạ tầng compute.
• Các dịch vụ còn lại (Glue, Lambda, Kinesis) có thể tương tác với S3, nhưng không cung cấp tính năng “SQL query on S3 objects” một cách trực tiếp và serverless như Athena.

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

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

Câu hỏi đặt ra: “A company uses Amazon RDS for a product database. The company wants to ensure the database is highly available. Which feature of Amazon RDS will meet this requirement?”

• “Highly available” (HA) trong ngữ cảnh RDS nghĩa là cơ sở dữ liệu luôn sẵn sàng phục vụ yêu cầu ngay cả khi một thành phần hạ tầng (AZ, phần cứng, mạng…) gặp sự cố.
• AWS cung cấp một số tính năng liên quan đến sao chép, dự phòng và tối ưu chi phí, nhưng chỉ một tính năng đáp ứng yêu cầu “đảm bảo tính sẵn sàng cao” một cách tự động và không cần can thiệp của người dùng: Multi‑AZ deployment.

✅ Đáp án đúng

[ĐÚNG] Multi‑AZ deployment

Lý do chọn:

• Khi bật Multi‑AZ, RDS tự động tạo một bản sao synchronously (đồng bộ) của primary instance ở một Availability Zone (AZ) khác trong cùng Region.
• Nếu AZ chính gặp lỗi, RDS tự động chuyển (fail‑over) sang standby instance trong vài giây, mà không cần thay đổi endpoint – ứng dụng vẫn kết nối được.
• Dịch vụ này được thiết kế để đáp ứng SLA 99.95% (theo AWS) cho tính sẵn sàng.
• Từ 2024‑2026, Multi‑AZ hỗ trợ hầu hết các engine RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora‑MySQL/PostgreSQL) và còn tích hợp Encryption at rest, automated backups, và fail‑over monitoring.

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

1. [SAI] Read replicas

   • Giải thích: Read replica là bản sao asynchronous (bất đồng bộ) chỉ dùng để tăng khả năng đọc (read scalability) hoặc để hỗ trợ migration/backup. Nó không được thiết kế để tự động chuyển đổi (fail‑over) khi primary instance gặp sự cố. Nếu primary ngừng hoạt động, replica vẫn cần được promote thủ công (hoặc thông qua các giải pháp custom) để trở thành primary, vì vậy không đáp ứng yêu cầu HA ngay lập tức.

2. [SAI] Blue/green deployment

   • Giải thích: Blue/green là chiến lược deployment nhằm giảm rủi ro khi thay đổi ứng dụng hoặc cơ sở dữ liệu bằng cách duy trì hai môi trường (blue & green) và chuyển traffic sau khi kiểm thử. Đây không phải là tính năng của RDS để đảm bảo sẵn sàng trong trường hợp lỗi phần cứng hay AZ; nó tập trung vào quản lý thay đổi chứ không phải dự phòng.

3. [SAI] Reserved Instances

   • Giải thích: Reserved Instances (RI) là công cụ tài chính giúp giảm chi phí sử dụng EC2/RDS bằng cách trả trước một mức giá cố định cho một thời gian (1 hoặc 3 năm). RI không cung cấp bất kỳ cơ chế sao lưu, sao chép hay fail‑over nào, do đó không liên quan tới tính sẵn sàng cao của database.

📚 Tham khảo (cập nhật đến năm 2026)

• AWS Documentation – Amazon RDS Multi‑AZ Deployments (v2026): https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html
• AWS Well‑Architected Framework – Reliability Pillar (đối với RDS): https://aws.amazon.com/architecture/well-architected/
• AWS Blog – New Multi‑AZ features for RDS (2025 update): https://aws.amazon.com/blogs/aws/new-multi-az-features-for-amazon-rds/

🛠️ Kết luận

Để đáp ứng yêu cầu đảm bảo tính sẵn sàng cao cho cơ sở dữ liệu sản phẩm trên Amazon RDS, Multi‑AZ deployment là lựa chọn duy nhất phù hợp. Các tùy chọn còn lại (Read replicas, Blue/green deployment, Reserved Instances) phục vụ các mục tiêu khác (đọc mở rộng, quản lý triển khai, tối ưu chi phí) và không cung cấp cơ chế fail‑over tự động cần thiết cho HA. 🚀

🧩 Phân tích câu hỏi
Câu hỏi: “Which AWS service provides serverless compute for use with containers?”
Câu hỏi đang hỏi dịch vụ nào của AWS cho phép chạy container (Docker, OCI …) mà không cần quản lý hay provision các instance EC2 – tức là mô hình “serverless” (trả tiền theo tài nguyên thực tế sử dụng).

✅ Đáp án đúng

🔹 AWS Fargate

Lý do:

• Fargate là dịch vụ run‑time serverless cho Amazon Elastic Container Service (ECS) và Amazon Elastic Kubernetes Service (EKS).
• Khi sử dụng Fargate, người dùng chỉ khai báo task definition (ECS) hoặc pod spec (EKS) và chọn “Fargate launch type”. AWS sẽ tự động provision, scale, và quản lý tài nguyên tính toán (CPU, memory) cho container, không cần tạo, patch, hay quản lý EC2 instance.
• Tính phí dựa trên giờ CPU và GB‑hour memory mà container thực tế tiêu thụ – đúng mô hình “pay‑as‑you‑go” serverless.
• Tính năng này đã được mở rộng tới 2024‑2026 với hỗ trợ Fargate Spot, Fargate on‑demand, và graviton2‑based compute để tối ưu chi phí và hiệu năng.

❌ Các phương án còn lại – Giải thích tại sao sai

• Amazon Simple Queue Service (Amazon SQS)

  • SQS là dịch vụ hàng đợi tin nhắn (message queue) dùng để truyền tải, lưu trữ và bảo đảm giao nhận tin nhắn giữa các thành phần hệ thống.
  • Nó không cung cấp môi trường chạy container hay bất kỳ khả năng compute nào. Do đó không thể đáp ứng yêu cầu “serverless compute for containers”.

• AWS Elastic Beanstalk

  • Elastic Beanstalk là PaaS giúp triển khai nhanh các ứng dụng web (Java, .NET, Node.js, Python, …) trên EC2, RDS, Elastic Load Balancing…
  • Mặc dù Beanstalk hỗ trợ triển khai ứng dụng dưới dạng Docker container, nhưng underlying compute vẫn là EC2 instances mà người dùng phải cấu hình (instance type, autoscaling). Do vậy không phải là “serverless”.

• Amazon SageMaker

  • SageMaker là dịch vụ Machine Learning toàn diện, cung cấp môi trường để xây dựng, huấn luyện và triển khai mô hình ML.
  • Mặc dù SageMaker hỗ trợ SageMaker Containers và SageMaker Serverless Inference, nhưng mục tiêu chính là ML, không phải là một nền tảng serverless chung cho any container. Ngoài ra, “serverless compute for use with containers” trong ngữ cảnh chung thường đề cập tới Fargate, không phải SageMaker.

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

1. AWS Fargate Documentation – “Serverless Compute for Containers”
   https://docs.aws.amazon.com/fargate/latest/userguide/what-is-fargate.html
2. Amazon ECS & EKS launch types – “Fargate Launch Type”
   https://aws.amazon.com/ecs/faqs/ & https://aws.amazon.com/eks/faqs/
3. AWS Compute Services Comparison – “Serverless vs. Managed vs. Self‑Managed”
   https://aws.amazon.com/compute/ (cập nhật 2025‑2026)
4. AWS Well‑Architected Framework – Operational Excellence – phần “Choose the right compute model”.

🛠️ Kết luận:
Trong bốn phương án, AWS Fargate là dịch vụ duy nhất cung cấp môi trường serverless compute cho container (ECS hoặc EKS). Các dịch vụ còn lại (SQS, Elastic Beanstalk, SageMaker) không đáp ứng yêu cầu này vì chúng thuộc các loại dịch vụ khác (messaging, PaaS, ML) hoặc vẫn yêu cầu quản lý instance.