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

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

Đề hỏi: dịch vụ nào dùng để monitor, store and access log files do EC2 instances và các máy chủ on-premises sinh ra.

Cụm từ quyết định là "log files generated by EC2 instances and on-premises servers". Cần tách bạch hai loại "log" mà AWS hay đem ra đánh đố nhau trong đề Cloud Practitioner:

• Log do hệ điều hành và ứng dụng sinh ra bên trong máy chủ — /var/log/messages, log của Apache/Nginx, log ứng dụng. Đây chính là thứ đề đang nói tới.
• Log ghi lại lời gọi API tới chính tài khoản AWS — ai gọi API nào, lúc nào, từ đâu. Đây là chuyện khác hẳn.

Thêm một chi tiết nữa: đề nhắc cả on-premises servers, nghĩa là dịch vụ được chọn phải nhận được log từ máy nằm ngoài AWS chứ không chỉ từ tài nguyên AWS. Và động từ bộ ba monitor – store – access cho thấy đây phải là một nơi lưu trữ và truy vấn log, chứ không phải một đường ống dữ liệu chỉ chảy qua.

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

B — Amazon CloudWatch Logs.

Đây đúng là dịch vụ được thiết kế để tập trung, lưu trữ và truy cập log file từ EC2 instances, từ AWS CloudTrail, từ Route 53 và các nguồn khác — trong đó có cả máy chủ on-premises. Log được đẩy lên bằng agent cài trên máy (CloudWatch agent), gom vào log group / log stream, giữ lại theo chính sách lưu trữ ta đặt, và lấy ra lại được khi cần tra cứu.

CloudWatch Logs khớp trọn cả ba động từ trong đề: monitor (đặt metric filter và alarm trên nội dung log), store (giữ log tập trung, không nằm rải rác trong từng máy), access (mở ra xem và truy vấn lại dữ liệu log). Việc nó nhận được log từ máy ngoài AWS chính là điểm khiến nó thoả cả vế "on-premises servers" của đề.

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

A — AWS CloudTrail. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì tên nó có chữ "trail" và nó cũng sinh ra log. Nhưng CloudTrail ghi lịch sử các API action thực hiện trên tài khoản AWS — ai tạo instance, ai sửa security group. Nó không thu thập log của hệ điều hành hay của ứng dụng chạy bên trong EC2, và càng không thu log từ máy chủ on-premises. Chỗ hỏng của nó nằm đúng ở loại log: quản trị tài khoản, không phải log máy chủ.

C — AWS OpsWorks. Đây là dịch vụ configuration management (quản lý cấu hình, dựa trên Chef/Puppet) — dùng để cài đặt và cấu hình phần mềm trên các máy chủ theo công thức định sẵn. Nó có đụng tới cả EC2 lẫn on-premises servers nên nghe qua có vẻ hợp với vế "on-premises" trong đề, nhưng việc của nó là đưa cấu hình xuống máy, không phải thu log từ máy lên. Đáp án này sai ở chính chức năng cốt lõi.

D — Amazon Kinesis. Đây là nhóm dịch vụ cho streaming data: thu thập, xử lý và phân tích dữ liệu theo dòng thời gian thực. Kinesis có thể nhận dữ liệu log trong một kiến trúc lớn hơn, nên nó không hoàn toàn xa lạ với chủ đề — nhưng bản thân nó là đường ống truyền dữ liệu, không phải nơi lưu trữ và tra cứu log file có sẵn giao diện xem. Nó không đáp ứng vế store và access log files theo cách đề mô tả.

📌 Điểm cần nhớ

• Gặp đề nói tới log của EC2, của ứng dụng, của hệ điều hành, hoặc log từ on-premises servers → nghĩ ngay CloudWatch Logs.
• Gặp đề nói tới ai đã gọi API nào, hành động nào trên tài khoản, phục vụ audit → đó là CloudTrail. Đây là cặp bị hoán đổi nhiều nhất trong đề Cloud Practitioner.
• OpsWorks thuộc nhóm configuration management, cùng họ với công cụ quản lý cấu hình — đừng để chữ "on-premises" trong đề kéo mình chọn nó.
• Kinesis là streaming data (thu — xử lý — phân tích dòng dữ liệu), không phải kho lưu trữ và tra cứu log.

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

Đề hỏi: dịch vụ nào chạy code của ứng dụng chỉ khi cần, mà không phải vận hành server?

Cụm từ quyết định nằm ở hai vế ghép lại: "only when needed" (chỉ chạy khi có việc) và "without needing to run servers" (không phải duy trì server). Cả bốn phương án đều là dịch vụ compute của AWS, đều "chạy được code" — nên chỉ đọc mỗi vế "chạy code" thì phương án nào cũng có vẻ đúng. Vế phân biệt thật sự là mô hình chạy theo sự kiện, không có gì nằm chờ: cái gì phải luôn bật để đợi request thì bị loại, dù bạn có tự quản trị nó hay không.

Nói cách khác, đề đang mô tả đúng định nghĩa serverless.

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

Đáp án đúng theo tệp là C — AWS Lambda.

Lambda là dịch vụ serverless: bạn nạp lên một đơn vị code gọi là function, và AWS chỉ thực thi nó khi có sự kiện kích hoạt (một request, một message, một file mới trong bucket, một lịch chạy…). Giữa các lần kích hoạt thì không có instance nào của bạn đang bật.

Điều đó khớp trọn vẹn hai vế của đề:

• "only when needed" — code chỉ chạy khi có sự kiện, đúng nghĩa "chạy theo nhu cầu";
• "without needing to run servers" — hạ tầng vẫn tồn tại ở phía dưới, nhưng bạn không thấy và không quản lý nó: không chọn instance type, không vá OS, không lo scale.

Hệ quả đúng như phần giải thích nguồn nêu: giảm cả chi phí (không trả tiền cho thời gian nằm không) lẫn operational overhead (không có server để chăm).

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

A — Amazon EC2. Đây là dịch vụ chạy server instance theo đúng nghĩa đen: bạn chọn cấu hình máy ảo, cài đặt, vá lỗi, và instance chạy liên tục cho tới khi bạn tắt. Nó vi phạm thẳng vế "without needing to run servers", và cũng không phải "chạy khi cần" vì máy vẫn bật kể cả lúc không có request nào.

B — Amazon ECS. Đây là phương án gần đúng nhất và là chỗ dễ mất điểm. ECS chạy Docker container, mà container thì nghe có vẻ "nhẹ và bật tắt nhanh" giống Lambda. Nhưng như phần giải thích nguồn chỉ ra, container trong ECS vẫn phải chạy và nằm đợi request — nó là một tiến trình sống liên tục, không phải một function được đánh thức bởi sự kiện. Đó là điểm hỏng của nó so với vế "only when needed". Bạn vẫn phải nghĩ về việc có bao nhiêu task đang chạy và chúng chạy trên nền tảng nào.

D — AWS LightSail. Cũng là chạy virtual instance và database, chỉ khác EC2 ở chỗ được đóng gói qua một giao diện đơn giản hơn cho người mới, giá cũng rẻ hơn. Nhưng "dễ dùng hơn" không đồng nghĩa với "không có server" — bên dưới vẫn là một máy ảo bật suốt do bạn sở hữu. Đề hỏi mô hình vận hành, không hỏi độ dễ dùng, nên LightSail trượt ở đúng chỗ EC2 trượt.

📌 Điểm cần nhớ

• Thấy cụm "without managing/running servers", "only when needed", "run code in response to events" hay "pay only for what you use" trong đề compute → phản xạ đầu tiên là AWS Lambda.
• Phân biệt ba tầng compute của AWS theo mức độ bạn phải quản lý: EC2 / LightSail = bạn quản lý máy ảo; ECS = bạn quản lý container đang chạy; Lambda = bạn chỉ quản lý code.
• Container không phải là serverless một cách mặc nhiên. ECS vẫn có thứ nằm chờ request — đây là cái bẫy hay gặp nhất khi phân biệt ECS với Lambda.
• LightSail chỉ là EC2 được đơn giản hoá, không phải một mô hình vận hành khác. Đừng để chữ "dễ dùng / rẻ hơn" kéo bạn sang nhóm serverless.

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

Đề hỏi: mô tả nào SAI khi nói về thiết kế của Availability Zone (AZ)? Cụm từ quyết định là "is incorrect" — đây là câu hỏi phủ định, ba phương án còn lại đều là những phát biểu đúng về AZ, chỉ một phương án là phát biểu sai. Đọc lướt rồi chọn "câu nghe hợp lý nhất" là hỏng ngay, vì đúng-nghe-hợp-lý chính là đáp án cần loại.

Cụm từ thứ hai cần bám vào nằm trong phương án D: "Each subnet in a VPC is mapped to all AZs" — quan hệ giữa subnet và AZ trong một VPC. Đây là chỗ duy nhất trong bốn phương án nói về VPC chứ không nói về bản thân hạ tầng AZ, và cũng là chỗ dễ nhầm nhất giữa hai khái niệm "phạm vi của VPC" và "phạm vi của subnet".

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

Đáp án là D — "Each subnet in a VPC is mapped to all AZs in the region", vì đây chính là phát biểu sai.

Trong một VPC, subnet được tạo bên trong đúng một AZ và nằm mãi trong AZ đó; nó không trải ra nhiều AZ. Ranh giới đúng là:

• VPC có phạm vi region — nó trải trên các AZ của region đó.
• Subnet có phạm vi một AZ duy nhất — khi tạo subnet bạn phải chọn AZ cho nó.

Chính vì thế, muốn một kiến trúc chịu được sự cố mất một AZ thì bạn phải tạo nhiều subnet, mỗi subnet ở một AZ khác nhau, rồi trải tài nguyên ra các subnet đó. Nếu subnet thật sự "mapped to all AZs" như D mô tả thì việc thiết kế multi-AZ sẽ chẳng cần làm gì cả — mà thực tế nó là việc bắt buộc phải làm.

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

Ba phương án dưới đây "sai" theo nghĩa chúng là phát biểu đúng, nên không phải là thứ câu hỏi phủ định đang tìm.

A — "AZ's have direct, low-latency, high throughput and redundant network connections between each other". Đây là mô tả đúng về thiết kế AZ: các AZ trong cùng một region được nối với nhau bằng đường mạng riêng, độ trễ thấp, băng thông cao và có dự phòng. Chính đặc tính này khiến việc chạy replication đồng bộ giữa các AZ (ví dụ Multi-AZ database) trở nên khả thi. Phát biểu đúng ⇒ không chọn.

B — "AZs are physically separated within a typical metropolitan region and are located in lower risk flood plains". Cũng là mô tả đúng. AZ được đặt tách biệt về mặt vật lý trong cùng một vùng đô thị, có tính đến rủi ro thiên tai như ngập lụt khi chọn vị trí. Mục đích là để một sự cố vật lý cục bộ không hạ cùng lúc nhiều AZ, trong khi khoảng cách vẫn đủ gần để giữ độ trễ thấp như A mô tả. Phát biểu đúng ⇒ không chọn.

C — "Each AZ is designed as an independent failure zone". Đây là nguyên tắc thiết kế cốt lõi của AZ: mỗi AZ được xây dựng như một vùng lỗi độc lập, có hạ tầng điện, làm mát và mạng riêng, để hỏng hóc trong một AZ không lan sang AZ khác. Phát biểu đúng ⇒ không chọn.

Lưu ý phương án gần đúng nhất về mặt bẫy là D chứ không phải A/B/C: D nghe rất giống câu đúng "a VPC spans all AZs in the region" — chỉ khác một từ, đổi VPC thành subnet. Người học nhớ mang máng "VPC trải khắp region" rất dễ đọc lướt D rồi coi nó là phát biểu đúng và đi tìm chỗ sai ở A, B hoặc C.

📌 Điểm cần nhớ

• Đọc kỹ từ phủ định trong đề (incorrect, NOT, EXCEPT): ba phương án đúng thì bị loại, phương án sai mới là đáp án cần chọn.
• Phạm vi khác nhau, đừng lẫn: VPC theo region, subnet theo một AZ duy nhất. Muốn multi-AZ thì phải tự tạo nhiều subnet ở nhiều AZ.
• Ba đặc tính chuẩn của AZ: tách biệt vật lý trong cùng vùng đô thị và chọn vị trí ít rủi ro thiên tai, là vùng lỗi độc lập, và nối với nhau bằng đường mạng riêng độ trễ thấp – băng thông cao – có dự phòng. Câu nào nói ngược lại ba ý này thì đáng nghi.
• Cảnh giác với phương án chỉ khác một danh từ so với một phát biểu đúng quen thuộc — "subnet" thay cho "VPC" là kiểu bẫy thường gặp nhất ở mảng networking.

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

Đề hỏi rất ngắn: "Which service is used for caching data?" — dịch vụ nào được dùng để cache (lưu đệm) dữ liệu.

Cụm từ quyết định ở đây chính là "caching data". Đây là câu kiểm tra khả năng nhận diện mục đích chính của từng dịch vụ AWS, chứ không phải câu tình huống có ràng buộc phức tạp. Bốn phương án thuộc bốn nhóm hoàn toàn khác nhau: quản lý khoá mã hoá, lưu trữ tệp, hàng đợi thông điệp, và tăng tốc cơ sở dữ liệu. Chỉ cần khoá vào từ "cache" là loại được ba phương án còn lại.

Lưu ý thêm: câu này nằm trong lĩnh vực AWS Database, nên "caching" ở đây được hiểu theo nghĩa cache trước một database — giảm độ trễ đọc, không phải cache nội dung tĩnh ở tầng edge.

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

D — Amazon DynamoDB DAX là đáp án đúng.

DAX (DynamoDB Accelerator) là in-memory cache được quản lý hoàn toàn, đặt trước DynamoDB. Ứng dụng gọi vào DAX thay vì gọi thẳng DynamoDB; nếu dữ liệu đã có trong cache thì DAX trả về ngay từ bộ nhớ, không cần chạm tới bảng DynamoDB.

Giá trị mang lại:

• Giảm độ trễ đọc từ mức mili-giây xuống mức micro-giây — đây là con số AWS nêu chính thức cho DAX.
• Chịu được khối lượng rất lớn request đọc mỗi giây mà vẫn giữ độ trễ thấp.
• Highly available: cụm DAX chạy nhiều node, có thể trải trên nhiều Availability Zone.
• Tương thích API với DynamoDB, nên phần lớn trường hợp chỉ cần đổi client chứ không phải viết lại logic cache thủ công.

Trong danh sách bốn phương án, DAX là dịch vụ duy nhất mà caching chính là lý do nó tồn tại — tên đầy đủ "Accelerator" đã nói lên điều đó.

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

A — AWS Key Management Service (KMS) KMS là dịch vụ tạo và quản lý khoá mã hoá, kiểm soát việc dùng mã hoá trên nhiều dịch vụ AWS và trong ứng dụng của bạn. Nó xử lý bảo mật dữ liệu (encryption at rest, quản lý vòng đời khoá, phân quyền dùng khoá), hoàn toàn không liên quan tới tốc độ đọc hay lưu đệm dữ liệu. Đây là phương án xa đề nhất.

B — Amazon Elastic File System (EFS) EFS là file system dùng chung, co giãn được, cho workload Linux, gắn được đồng thời vào nhiều EC2 instance. Đây là phương án dễ gây nhầm nhất trong ba phương án sai, vì nó cũng là nơi lưu dữ liệu. Chỗ nó hỏng: EFS là persistent storage trên đĩa, không phải in-memory cache. Mục đích của nó là chia sẻ tệp giữa nhiều máy và lưu bền, chứ không phải rút ngắn độ trễ truy vấn xuống micro-giây. Lưu trữ ≠ caching.

C — Amazon Simple Queue Service (SQS) SQS là hàng đợi thông điệp được quản lý, dùng để decouple (tách rời) và scale microservices, hệ thống phân tán và ứng dụng serverless. Có người nhầm vì SQS "giữ message lại một thời gian", trông giống lưu tạm. Nhưng bản chất khác hẳn: message trong SQS được tiêu thụ rồi xoá đi, luồng dữ liệu đi một chiều từ producer sang consumer. Cache thì ngược lại — cùng một dữ liệu được đọc lại nhiều lần để tiết kiệm thời gian. SQS giải bài toán ghép nối lỏng, không giải bài toán độ trễ đọc.

📌 Điểm cần nhớ

• Thấy từ khoá "cache" / "in-memory" / "giảm latency đọc" đi kèm DynamoDB thì nghĩ ngay tới DAX; đó là cache chuyên dụng đặt trước DynamoDB.
• Phân biệt rõ ba khái niệm hay bị gộp: caching (đọc lại nhanh, in-memory), storage (lưu bền — EFS, S3, EBS), và queuing (chuyển message rồi xoá — SQS). Ba bài toán khác nhau, đừng để chữ "lưu" đánh lừa.
• KMS luôn thuộc nhóm bảo mật/mã hoá, không bao giờ là đáp án cho câu hỏi về hiệu năng hay lưu trữ dữ liệu.
• Với câu hỏi một dòng kiểu này, chiến thuật nhanh nhất là hỏi ngược: "dịch vụ này sinh ra để làm gì?" — chỉ một phương án có mục đích cốt lõi trùng với từ khoá trong đề.

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

Đề mô tả một Cloud Practitioner cần triển khai nhanh một giải pháp IT phổ biến và dùng được ngay lập tức ("rapidly deploy a popular IT solution and start using it immediately").

Cụm từ quyết định nằm ở ba mảnh ghép lại:

• "popular IT solution" — không phải ứng dụng do chính người dùng viết, mà là một công nghệ quen thuộc đã có sẵn kiến trúc mẫu (kiểu Active Directory, SAP, WordPress, cụm database…).
• "rapidly deploy" — cần thứ thực sự dựng ra hạ tầng, không phải tài liệu để đọc rồi tự làm.
• "start using it immediately" — dựng xong là chạy được, không phải mang code của mình vào rồi mới có gì để dùng.

Ba ràng buộc này đủ để loại từng phương án còn lại theo đúng ba lý do khác nhau: một cái chỉ là tài liệu, một cái không phải công cụ triển khai, một cái thì có triển khai nhưng đòi người dùng cung cấp ứng dụng.

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

C. AWS Quick Start reference deployments.

Quick Start là các bản triển khai tham chiếu do solutions architect của AWS và các đối tác xây sẵn, nhằm đưa những công nghệ phổ biến lên AWS theo best practice của AWS về bảo mật và tính sẵn sàng cao. Mỗi Quick Start gồm:

• Các template AWS CloudFormation tự động hoá toàn bộ việc dựng hạ tầng;
• Một tài liệu hướng dẫn mô tả kiến trúc và các bước triển khai.

Nhờ đó, hàng trăm thao tác thủ công được rút lại còn vài bước, môi trường dựng xong là dùng được ngay — khớp chính xác với "rapidly deploy… and start using it immediately" trong đề. Điểm mấu chốt: Quick Start vừa có sẵn nội dung giải pháp (không cần người dùng mang gì vào), vừa thực sự tạo ra tài nguyên.

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

A. AWS Well-Architected Framework documentation. Đây là tài liệu — bộ nguyên tắc và best practice hướng dẫn cách thiết kế kiến trúc tốt. Nó rất hữu ích cho việc đánh giá và cải thiện thiết kế, nhưng bản thân nó không triển khai bất cứ thứ gì. Đọc xong vẫn phải tự tay dựng, tức là ngược hẳn với yêu cầu "dùng được ngay".

B. Amazon CloudFront. CloudFront là một content delivery network (CDN), làm nhiệm vụ cache nội dung tại các edge location để cải thiện hiệu năng phân phối. Nó là một dịch vụ hạ tầng cụ thể, không phải công cụ triển khai giải pháp, và không liên quan gì tới việc dựng nhanh một "IT solution phổ biến".

C. (đáp án đúng — xem mục trên).

D. AWS Elastic Beanstalk. Đây là phương án gần đúng nhất và đáng phân tích kỹ. Elastic Beanstalk đúng là giúp triển khai ứng dụng web dễ dàng: bạn chỉ đưa code lên, nó lo phần provisioning, load balancing, scaling. Nhưng nó hỏng ở đúng chỗ đề nhấn mạnh:

• Bạn vẫn phải tự cung cấp code ứng dụng. Đề nói tới một "popular IT solution" có sẵn, chứ không phải ứng dụng do người dùng viết — Beanstalk không mang sẵn giải pháp nào cho bạn dùng ngay.
• Phạm vi của nó giới hạn ở việc chạy ứng dụng trên EC2 instance với các platform được hỗ trợ, chứ không dựng ra một kiến trúc giải pháp hoàn chỉnh nhiều tầng như Quick Start.

Nói ngắn gọn: Beanstalk trả lời câu hỏi "làm sao triển khai ứng dụng của tôi cho nhanh", còn đề đang hỏi "làm sao có một giải pháp phổ biến chạy ngay".

📌 Điểm cần nhớ

• Phân biệt "tài liệu" với "công cụ triển khai". Well-Architected Framework là guidance để thiết kế/đánh giá; hỏi "deploy" mà chọn documentation là sai ngay từ loại đối tượng.
• Quick Start = giải pháp dựng sẵn theo best practice, chạy bằng CloudFormation. Từ khoá nhận diện trong đề: popular / common technology, reference deployment, deploy quickly following AWS best practices.
• Elastic Beanstalk yêu cầu bạn mang code của mình. Khi đề nhấn "start using it immediately" mà không hề nhắc tới ứng dụng của người dùng, Beanstalk gần như luôn là bẫy.
• Đọc kỹ cái được triển khai là của ai. Ứng dụng tự viết → Elastic Beanstalk; giải pháp phổ biến có kiến trúc mẫu → Quick Start. Cùng chữ "deploy" nhưng chủ thể khác nhau dẫn tới hai đáp án khác nhau.

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

Đề hỏi: tên của cổng thông tin (portal) trực tuyến, tự phục vụ (self-service) mà AWS cung cấp để khách hàng xem các báo cáo — ví dụ báo cáo PCI — và chấp nhận (accept) các thỏa thuận.

Cụm từ quyết định đáp án nằm ngay trong đề: "view reports, such as PCI reports, and accept agreements". Đây là mô tả gần như nguyên văn chức năng của một dịch vụ AWS duy nhất. Hai vế này rất quan trọng:

• "reports ... such as PCI reports" — không phải tài liệu hướng dẫn kỹ thuật, mà là báo cáo tuân thủ do bên kiểm định độc lập cấp (PCI, SOC, và các chứng nhận từ các tổ chức kiểm định khác).
• "accept agreements" — người dùng không chỉ đọc, mà còn ký/chấp nhận các thỏa thuận pháp lý ngay trên portal, chẳng hạn BAA (Business Associate Addendum) và NDA.

Một cổng chỉ để đọc tài liệu thì không thỏa vế thứ hai. Đây chính là ràng buộc tách đáp án đúng khỏi những cái tên nghe rất hợp lý còn lại.

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

A. AWS Artifact là đáp án đúng.

AWS Artifact là nguồn tài nguyên tập trung, tự phục vụ, cho mọi thông tin liên quan đến compliance. Nó khớp cả hai vế của đề:

• Xem báo cáo theo yêu cầu (on-demand): các báo cáo bảo mật và tuân thủ của AWS, bao gồm báo cáo SOC (Service Organization Control), báo cáo PCI, cùng các chứng nhận từ nhiều tổ chức kiểm định ở các khu vực địa lý và lĩnh vực tuân thủ khác nhau. Những tài liệu này chứng minh rằng các biện pháp kiểm soát bảo mật của AWS đã được triển khai và vận hành hiệu quả.
• Chấp nhận thỏa thuận: AWS Artifact cho phép khách hàng xem xét và chấp nhận một số thỏa thuận trực tuyến, ví dụ BAA (Business Associate Addendum, phục vụ các yêu cầu liên quan tới HIPAA) và NDA (Nondisclosure Agreement).

Đề nhắc đúng cả "PCI reports" lẫn "accept agreements" — đó là chữ ký nhận dạng của AWS Artifact.

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

B. AWS Compliance Portal — sai vì đây không phải là một dịch vụ có thật của AWS. Đây là phương án gây nhiễu nguy hiểm nhất trong câu này: tên gọi mô tả đúng chức năng mà đề đang cần (một "cổng tuân thủ"), nên người học chỉ đọc lướt đề rất dễ chọn nó theo cảm giác ngữ nghĩa. Bài học ở đây là AWS đặt tên dịch vụ thường không mô tả trực tiếp chức năng — "Artifact" nghe chẳng liên quan gì tới compliance, nhưng đó mới là tên thật. Đừng chọn phương án chỉ vì tên nó nghe khớp với đề bài.

C. AWS DocuFact — sai vì không tồn tại dịch vụ nào tên như vậy. Đây là một cái tên bịa được ghép từ "Docu-" (tài liệu) và "-fact", cố tình nghe na ná "Artifact" để đánh vào người mới chỉ nhớ mang máng tên dịch vụ. Nếu bạn nhớ đúng "Artifact" thì phương án này bị loại ngay lập tức.

D. AWS Documentation Portal — sai vì cũng không phải một dịch vụ AWS. Ngoài ra, ngay cả khi bỏ qua việc cái tên này không tồn tại, ý nghĩa của nó vẫn lệch hướng: "documentation" gợi tới tài liệu kỹ thuật, hướng dẫn sử dụng, tài liệu tham chiếu API — tức là tài liệu hướng dẫn dùng dịch vụ, hoàn toàn khác với báo cáo kiểm định tuân thủ và thỏa thuận pháp lý cần ký. Phương án này không đáp ứng được vế "accept agreements" của đề.

📌 Điểm cần nhớ

• AWS Artifact = báo cáo tuân thủ (SOC, PCI, các chứng nhận kiểm định) + chấp nhận thỏa thuận (BAA, NDA), theo cơ chế tự phục vụ, on-demand. Thấy từ khóa "compliance report", "PCI", "SOC", "audit report" hay "accept agreement" trong đề thì nghĩ ngay tới Artifact.
• Đừng chọn phương án chỉ vì tên nó mô tả đúng chức năng. Trong câu này, ba phương án sai đều là tên bịa được đặt cho nghe hợp lý. Kỳ thi Cloud Practitioner rất hay dùng chiêu này, nên hãy nhớ tên thật của dịch vụ thay vì suy đoán từ ngữ nghĩa.
• Phân biệt "documentation" với "compliance artifacts". Tài liệu kỹ thuật hướng dẫn bạn dùng dịch vụ; báo cáo tuân thủ chứng minh AWS đã được kiểm định — hai loại nội dung khác nhau, đề hỏi loại thứ hai.
• Chú ý vế thứ hai của đề. Khi câu hỏi mô tả hai chức năng (ở đây là xem báo cáo và chấp nhận thỏa thuận), hãy kiểm tra phương án thỏa cả hai — vế bị bỏ qua thường chính là chỗ loại bớt các lựa chọn gần đúng.

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

Đề hỏi: dịch vụ AWS nào cho phép các thiết bị đã kết nối (connected devices) tương tác một cách dễ dàng và an toàn với ứng dụng trên cloud và với các thiết bị khác?

Cụm từ quyết định là "connected devices" — tức là thiết bị vật lý ngoài đời (cảm biến, thiết bị gia dụng, máy móc công nghiệp) kết nối lên mạng. Cụm thứ hai bổ trợ là "interact with cloud applications and other devices": không chỉ gửi dữ liệu lên cloud một chiều, mà còn phải nói chuyện được thiết bị ↔ thiết bị.

Hai cụm này gộp lại chính là định nghĩa sách vở của IoT (Internet of Things). Ngay khi nhận ra đề đang mô tả IoT, việc còn lại chỉ là tìm phương án nào thuộc nhóm IoT — và trong bốn phương án chỉ có đúng một cái mang chữ IoT trong tên.

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

D — AWS IoT Core là đáp án đúng.

AWS IoT Core là dịch vụ managed đóng vai trò cửa ngõ giữa các thiết bị và AWS Cloud. Nó làm đúng ba việc mà đề bài mô tả:

• Kết nối thiết bị: thiết bị kết nối vào IoT Core qua các giao thức quen thuộc của thế giới IoT (MQTT, HTTPS, WebSocket).
• Bảo mật ("securely"): mọi kết nối đều được xác thực và mã hoá, mỗi thiết bị có danh tính riêng và được phân quyền — đây là lý do IoT Core khác với việc tự dựng một server nhận dữ liệu.
• Định tuyến thông điệp ("interact with cloud applications and other devices"): IoT Core nhận thông điệp rồi chuyển tiếp tới các endpoint AWS khác và tới các thiết bị khác, nên hai thiết bị nói chuyện với nhau qua IoT Core mà không cần kết nối trực tiếp.

Dịch vụ được thiết kế cho quy mô rất lớn — hàng tỉ thiết bị và lượng thông điệp cực lớn — nên nó là câu trả lời chuẩn cho mọi câu hỏi kiểu "dịch vụ nào dành cho thiết bị IoT" ở mức Cloud Practitioner.

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

A — AWS Server Migration Service (SMS): là dịch vụ agentless giúp di chuyển hàng nghìn workload từ on-premises lên AWS. Đối tượng của nó là máy chủ ảo/workload, không phải thiết bị IoT; và mục đích là chuyển một lần rồi thôi, chứ không phải duy trì kết nối thường trực để trao đổi thông điệp. Chữ "Server" dễ gây nhầm với "device", nhưng server ở đây nghĩa là máy chủ trong data center của bạn.

B — AWS Directory Service: cung cấp Microsoft Active Directory được quản lý trên AWS Cloud (AWS Managed Microsoft AD), để các workload và tài nguyên AWS "directory-aware" dùng chung một thư mục. Đây là phương án gần đúng một nửa — nó cũng liên quan tới danh tính và xác thực, nên nếu chỉ bắt được chữ "securely" trong đề thì rất dễ chọn nhầm. Nhưng danh tính mà Directory Service quản lý là người dùng và máy tính trong domain, không phải certificate của thiết bị IoT, và nó hoàn toàn không có cơ chế định tuyến thông điệp giữa các thiết bị.

C — Amazon WorkSpaces: là dịch vụ cloud desktop (máy tính để bàn ảo) được quản lý và bảo mật. Nó phục vụ con người ngồi làm việc từ xa, không phục vụ thiết bị tự động. Ở đây cái bẫy là chữ "WorkSpaces" trông giống thứ gì đó liên quan tới thiết bị đầu cuối — thật ra thiết bị đầu cuối chỉ là màn hình để truy cập vào desktop ảo, còn bản thân dịch vụ chẳng có gì dính tới IoT.

📌 Điểm cần nhớ

• Thấy các từ khoá "connected devices", "sensors", "telemetry", "device-to-device" trong đề Cloud Practitioner thì gần như chắc chắn đáp án nằm ở nhóm IoT, và AWS IoT Core là dịch vụ nền tảng của nhóm đó.
• Phân biệt rõ ba khái niệm hay bị trộn lẫn trong cùng một bộ phương án: device (thiết bị vật lý → IoT Core), server/workload (máy chủ cần di chuyển → Server Migration Service), và user desktop (người dùng cuối → WorkSpaces).
• Chữ "securely" trong đề không đủ để suy ra một dịch vụ về danh tính như Directory Service — hầu hết dịch vụ AWS đều quảng cáo là bảo mật. Phải bám vào đối tượng mà dịch vụ phục vụ, chứ đừng bám vào tính từ.
• IoT Core không chỉ thu thập dữ liệu lên cloud mà còn định tuyến thông điệp qua lại giữa các thiết bị; đề nào nhấn mạnh vế "and other devices" là đang chỉ thẳng vào đặc điểm này.

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

Đề hỏi: hai phát biểu nào là ĐÚNG về AWS Organizations khi bật consolidated billing (Select TWO).

Cụm từ quyết định nằm ở chính chữ "consolidated billing" — nghĩa đen là gộp hoá đơn. Mọi phương án phải được soi qua đúng ống kính này: cái gì thuộc về thanh toán/chi phí thì mới nằm trong phạm vi câu hỏi; cái gì nói về quyền quản trị tài khoản hay cấu hình dịch vụ logging thì hoặc sai, hoặc lạc đề.

Mô hình cần nắm: trong một organization có một paying account (management account) và các linked accounts (member accounts). Consolidated billing kéo chi phí của tất cả linked accounts về paying account.

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

Đáp án đúng theo tệp là B và D.

D — "One bill provided for multiple accounts": đây chính là định nghĩa của consolidated billing. Nhiều tài khoản trong cùng organization được gộp lại thành một hoá đơn duy nhất gửi cho paying account. Chi tiết chi tiêu của từng linked account vẫn tách bạch để theo dõi, nhưng hoá đơn phải trả thì chỉ có một.

B — "Volume pricing discounts applied across multiple accounts": đây là lợi ích tài chính đi kèm. Nhiều dịch vụ AWS có bậc giá giảm dần theo mức sử dụng (tiered pricing). Khi gộp billing, mức sử dụng của tất cả tài khoản trong organization được cộng lại rồi mới tính bậc giá, thay vì mỗi tài khoản tính riêng. Kết quả là cả nhóm dễ chạm ngưỡng giảm giá hơn so với khi từng tài khoản đứng lẻ.

Hai điểm này bổ sung cho nhau và cùng thuộc phạm vi billing — đúng như cụm từ khoá trong đề.

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

A — "CloudTrail can be configured per organization": đây là phương án gần đúng nhất và cũng là bẫy chính. CloudTrail vốn hoạt động theo từng account và từng region. Điều làm được là gom log của nhiều account về một bucket S3 chung đặt ở paying account để tiện lưu trữ và soi lại. Nhưng "gom log về một chỗ" khác với "cấu hình ở cấp organization", và quan trọng hơn: CloudTrail là dịch vụ audit/logging, không phải billing — nó nằm ngoài phạm vi mà cụm từ "consolidated billing" giới hạn.

C — "Multiple bills are provided per organization": đây là phát biểu ngược hẳn với D. Nếu mỗi tài khoản vẫn nhận hoá đơn riêng thì consolidated billing không còn ý nghĩa gì. Đúng một hoá đơn cho cả organization, không phải nhiều.

E — "Linked accounts lose their management independence": sai ở chỗ nhầm lẫn giữa gộp tiền và mất quyền tự quản. Consolidated billing chỉ gộp phần thanh toán; các linked account vẫn giữ quyền quản trị độc lập — vẫn có IAM users, roles, resources riêng, vẫn tự vận hành tài nguyên của mình. Ranh giới tài khoản (account boundary) vẫn là ranh giới cô lập.

📌 Điểm cần nhớ

• Consolidated billing = một hoá đơn + gộp mức sử dụng để hưởng bậc giá tốt hơn. Hai ý này gần như luôn là đáp án đúng cho mọi câu hỏi dạng "lợi ích của consolidated billing".
• Gộp hoá đơn không đồng nghĩa với gộp quyền quản trị. Linked account vẫn tự quản tài nguyên của nó; đây là bẫy lặp đi lặp lại trong đề thi.
• CloudTrail bản chất là per-account, per-region, chỉ gom log về một bucket chung được — đừng đọc thành "cấu hình ở cấp organization".
• Khi đề khoá phạm vi bằng một cụm từ như "consolidated billing", hãy loại thẳng những phương án nói về dịch vụ khác lĩnh vực trước, rồi mới cân nhắc các phương án còn lại.

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

Đề hỏi: mô hình định giá EC2 nào cho phép khách hàng dùng lại giấy phép phần mềm hiện có gắn với máy chủ vật lý ("existing server-bound software licenses").

Cụm từ quyết định là "server-bound licenses" — giấy phép tính theo máy chủ vật lý, tức theo socket, theo core vật lý, hoặc theo từng máy chủ, chứ không tính theo instance ảo. Các giấy phép kiểu này (Windows Server, SQL Server, Oracle Database…) yêu cầu người dùng phải nhìn thấy và kiểm soát được phần cứng vật lý đang chạy phần mềm, để chứng minh với nhà cung cấp là số socket/core đã mua khớp với số socket/core đang dùng.

Đây chính là chỗ phân biệt: ba phương án còn lại đều là các mô hình giảm giá theo cách cam kết hoặc theo mức độ chấp nhận gián đoạn, không đụng gì tới việc lộ ra phần cứng vật lý bên dưới. Đề không hỏi "mô hình nào rẻ nhất" hay "mô hình nào linh hoạt nhất" — hỏi mô hình nào phục vụ nhu cầu mang giấy phép của mình lên (BYOL).

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

D. Dedicated Hosts là đáp án đúng.

Một Amazon EC2 Dedicated Host là một máy chủ vật lý được dành riêng hoàn toàn cho bạn. Vì bạn thuê nguyên cái máy chủ, AWS cho bạn nhìn thấy các thuộc tính vật lý của nó — số socket, số core vật lý — và cho bạn quyết định instance nào đặt lên host nào. Đó chính xác là thứ mà một giấy phép server-bound đòi hỏi: bạn chứng minh được phần mềm chỉ chạy trên đúng phần cứng đã được cấp phép.

Nhờ vậy, Dedicated Hosts là mô hình cho phép mang giấy phép đủ điều kiện của các hãng như Microsoft và Oracle lên EC2 (BYOL): giữ được giá trị khoản đầu tư vào giấy phép đã mua, nhưng vẫn hưởng độ bền, sự đơn giản và tính co giãn của AWS. Việc thuê riêng nguyên máy chủ vật lý cũng giúp đáp ứng các yêu cầu tuân thủ nội bộ của doanh nghiệp về việc không dùng chung phần cứng với khách hàng khác.

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

A. Reserved Instances — Đây là cơ chế giảm giá bằng cam kết sử dụng theo kỳ hạn (thường 1 năm hoặc 3 năm) để đổi lấy mức giá thấp hơn On-Demand. Nó chỉ tác động tới hoá đơn, không thay đổi việc bạn có được nhìn thấy hay kiểm soát máy chủ vật lý bên dưới hay không. Đây là phương án gây nhầm nhiều nhất vì cả nó lẫn Dedicated Hosts đều nằm trong nhóm "cam kết dài hạn" — nhưng cam kết chi phí khác hẳn với quyền kiểm soát phần cứng, và chỉ vế sau mới thoả mãn giấy phép server-bound.

B. Spot Instances — Dùng để mua công suất còn dư với mức giá chiết khấu sâu, đổi lại instance có thể bị thu hồi/gián đoạn khi AWS cần lại công suất. Nó hợp với khối lượng công việc ngắn hạn, chịu được gián đoạn. Hoàn toàn không liên quan tới chuyện cấp phép phần mềm, và đặc tính hay bị thu hồi càng khiến nó là chỗ tệ để đặt một hệ thống có giấy phép ràng buộc theo phần cứng.

C. On-Demand Instances — Mô hình tính tiền tiêu chuẩn: trả theo mức sử dụng, không cam kết trước, không trả trước. Đây là mặc định, không mang lại bất kỳ lợi thế nào mà đề đang hỏi tới — không giảm giá theo cam kết, và cũng không cho bạn quyền kiểm soát máy chủ vật lý để dùng lại giấy phép.

📌 Điểm cần nhớ

• Thấy từ khoá "existing licenses" / "BYOL" / "server-bound" / "per-socket, per-core" trong đề EC2 thì hướng trả lời là Dedicated Hosts — đó là mô hình duy nhất trong nhóm cho bạn thấy và kiểm soát máy chủ vật lý.
• Phân biệt hai trục khác nhau: Reserved Instances / Spot / On-Demand là trục giá (cam kết, gián đoạn, trả theo dùng), còn Dedicated Hosts là trục quyền sở hữu phần cứng — câu hỏi hỏi trục nào thì trả lời theo trục đó.
• Dedicated Hosts còn là câu trả lời cho các yêu cầu tuân thủ doanh nghiệp đòi không dùng chung phần cứng vật lý với khách hàng khác, không chỉ cho chuyện cấp phép.
• Spot gắn liền với khả năng bị gián đoạn; hễ đề nhấn mạnh tính ổn định, tuân thủ hay ràng buộc giấy phép thì Spot gần như chắc chắn sai.

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

Đề hỏi: làm sao để một công ty kết nối từ mạng on-premises của họ tới các VPC nằm ở nhiều region, bằng private connections.

Có ba ràng buộc chồng lên nhau, và phải thoả cả ba mới đúng:

1. "from their on-premises network" — điểm xuất phát là trung tâm dữ liệu riêng của công ty, không phải một VPC khác. Ràng buộc này một mình đã loại được phương án chỉ nối VPC với VPC.
2. "VPCs in multiple regions" — đích đến không nằm gọn trong một region, nên thứ được chọn phải bắc được sang nhiều region chứ không phải dựng lại từng đường một cho mỗi region.
3. "using private connections" — cụm từ quyết định. "Private" ở đây có nghĩa lưu lượng không đi qua public Internet. Đây chính là ràng buộc tách hai phương án nghe rất giống nhau về mục đích (nối on-premises vào AWS): một cái chạy trên đường riêng, một cái chạy trên Internet.

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

C — AWS Direct Connect Gateway.

AWS Direct Connect cung cấp đường kết nối vật lý riêng từ mạng on-premises vào AWS, không đi qua public Internet — thoả ràng buộc "private connections". Nhưng bản thân một private virtual interface của Direct Connect gắn trực tiếp thì bị bó vào phạm vi hẹp.

Direct Connect Gateway chính là thành phần gỡ nút đó: nó cho phép dùng một Direct Connect connection, qua một private virtual interface, để nối tới một hoặc nhiều VPC trong tài khoản của bạn, nằm ở cùng region hoặc ở các region khác nhau. Nghĩa là công ty không phải mua một đường Direct Connect riêng cho từng region — một đường vật lý, một private virtual interface, rồi Direct Connect Gateway đứng giữa phân phối tới các VPC ở nhiều region.

Ghép lại: private (Direct Connect) + nhiều region (Gateway) + xuất phát từ on-premises → đúng cả ba ràng buộc của đề.

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

A — Inter-Region VPC Peering. Đây là phương án gần đúng nhất về mặt "multiple regions", và người đọc vội rất dễ chọn nó vì thấy đúng chữ "Inter-Region". Nhưng nó hỏng ở ràng buộc thứ nhất: VPC peering nối VPC với VPC, cả hai đầu đều nằm trong AWS. Nó không có đầu nào cắm vào mạng on-premises, nên không đáp ứng được yêu cầu "connect from their on-premises network". Đây là lỗi đọc thiếu một nửa đề bài — chọn đúng vế "multiple regions" mà bỏ mất vế "on-premises".

B — Amazon CloudFront. Sai hoàn toàn về chủng loại dịch vụ. CloudFront là một content delivery network dùng để cache và phân phối nội dung tới người dùng cuối, hoạt động trên public Internet. Nó không phải là cơ chế kết nối mạng giữa on-premises và VPC, và không tạo ra private connection theo nghĩa câu hỏi đang hỏi.

C — (đáp án đúng, xem mục trên).

D — AWS Managed VPN. Đây là phương án bẫy chính, và là chỗ dễ mất điểm nhất. Nó đúng ở chỗ nối được mạng on-premises vào AWS, và lưu lượng bên trong tunnel có được mã hoá. Nhưng nó hỏng đúng ở cụm từ quyết định: AWS Managed VPN chạy trên public Internet — tunnel được dựng đè lên đường truyền Internet công cộng. Mã hoá không đồng nghĩa với "private connection" theo cách bài thi dùng từ này: private nghĩa là không đi qua public Internet, và điều đó chỉ Direct Connect mới cho. Nhớ tách bạch encrypted (VPN) khác private/dedicated (Direct Connect).

📌 Điểm cần nhớ

• Trong từ vựng thi AWS, "private connection" từ on-premises = Direct Connect, còn "encrypted over the Internet" = VPN (Site-to-Site / Managed VPN). Thấy chữ "private", "dedicated", "not over the Internet" thì nghiêng về Direct Connect; thấy "encrypted", "over the Internet", "quick to set up" thì nghiêng về VPN.
• Direct Connect Gateway là thứ mở rộng một Direct Connect connection ra nhiều VPC ở nhiều region, thay vì phải dựng đường riêng cho từng region. Đề nào ghép "Direct Connect" với "multiple regions" hoặc "multiple VPCs" thì gần như chắc chắn đang trỏ tới Gateway.
• VPC Peering — kể cả Inter-Region — chỉ nối VPC với VPC, không bao giờ là câu trả lời cho một đề có mặt chữ "on-premises". Đọc đủ cả hai vế của đề trước khi chọn.
• CloudFront là CDN, không phải dịch vụ kết nối mạng lai (hybrid networking). Gặp nó trong danh sách của một câu hỏi về kết nối on-premises thì đó là phương án gây nhiễu.