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

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

Đề hỏi: dịch vụ AWS nào cung cấp in-memory data structure store, tương thích Redis, cho độ trễ dưới một phần nghìn giây (sub-millisecond), dùng cho caching, session store và real-time analytics.

Cụm từ quyết định đáp án là "compatible with Redis" và "in-memory data structure store". Đây là ràng buộc phân biệt duy nhất: đề không hỏi "cơ sở dữ liệu nào nhanh", mà hỏi cơ sở dữ liệu nào chạy trong bộ nhớ và nói được giao thức/kiểu dữ liệu của Redis. Cụm "sub-millisecond latency" hỗ trợ thêm — nó loại luôn những dịch vụ mà bản thân AWS mô tả ở mức mili-giây, chứ không phải dưới mili-giây.

Ba từ khoá phụ — caching, session stores, real-time analytics — là bộ ba tình huống kinh điển của Redis. Thấy chúng đi cùng nhau trong một câu Cloud Practitioner thì gần như chắc chắn đáp án nằm ở họ in-memory.

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

B. Amazon MemoryDB là dịch vụ cơ sở dữ liệu in-memory tương thích Redis, dựng trên kiến trúc Redis, cho độ trễ đọc ở mức sub-millisecond. Nó đáp ứng đúng cả ba vế mà đề nêu: in-memory data structure store, Redis-compatible, và sub-millisecond latency — nên là phương án duy nhất khớp trọn ràng buộc.

Nói cách khác, MemoryDB giữ nguyên các kiểu dữ liệu của Redis (string, hash, list, set, sorted set…), nên ứng dụng đang dùng client Redis nói chuyện được với nó mà không phải viết lại tầng truy cập dữ liệu. Ba tình huống đề liệt kê đều là những gì kiến trúc này sinh ra để phục vụ.

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

A. Amazon DynamoDB — đây là phương án gần đúng nhất và là bẫy chính của câu. DynamoDB là NoSQL kiểu key-value và document, cũng rất nhanh, được AWS mô tả ở mức single-digit millisecond (một chữ số mili-giây) ở mọi quy mô. Nó hỏng ở hai chỗ: (1) không phải in-memory data structure store tương thích Redis — nó không nói giao thức Redis và không có các kiểu dữ liệu của Redis; (2) mức hiệu năng chuẩn của nó là mili-giây chứ không phải sub-millisecond như đề đòi. Nhanh không đồng nghĩa với đúng loại; đề khoá bằng chữ "Redis".

C. Amazon RDS — dịch vụ cơ sở dữ liệu quan hệ có quản lý, hỗ trợ nhiều engine. Bản thân nó không cung cấp in-memory data structure store tương thích Redis, và mô hình quan hệ trên đĩa không nhắm tới độ trễ sub-millisecond cho caching hay session store. Chọn RDS là nhầm giữa "cơ sở dữ liệu có quản lý" với "cơ sở dữ liệu in-memory".

D. Amazon Redshift — đây là bẫy chữ nghĩa: tên bắt đầu bằng "Red" giống Redis, nhưng hai thứ không liên quan. Redshift là data warehouse, tối ưu cho truy vấn phân tích trên tập dữ liệu lớn (OLAP), nơi đơn vị thời gian phản hồi là giây chứ không phải phần nghìn giây. Cụm "real-time analytics" trong đề dễ khiến người học nghĩ tới analytics rồi chọn Redshift — nhưng "real-time" ở đây gắn với độ trễ sub-millisecond của tầng in-memory, khác hẳn analytics theo lô của kho dữ liệu.

📌 Điểm cần nhớ

• Thấy "Redis-compatible" hoặc "in-memory data structure store" trong đề thì đáp án nằm ở họ in-memory, không phải DynamoDB, RDS hay Redshift.
• Phân biệt bằng bậc độ trễ: sub-millisecond → in-memory; single-digit millisecond → DynamoDB; truy vấn phân tích lớn → Redshift.
• Bộ ba caching – session store – real-time analytics là dấu hiệu nhận dạng tình huống dùng Redis trong đề thi.
• Đừng chọn theo tên na ná: Redshift ≠ Redis. Redshift là data warehouse cho OLAP, không phải cache.

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

Đề hỏi: IAM entity nào được dùng để gán quyền cho các AWS service? Hai cụm từ quyết định nằm ngay trong câu:

• "IAM entity" — trong IAM, "entity" là đối tượng có thể dùng để xác thực và hành động: IAM user và IAM role. Policy không phải entity, nó là tài liệu đính vào entity.
• "for AWS services" — người nhận quyền ở đây không phải một con người, mà là một dịch vụ (ví dụ EC2, Lambda). Dịch vụ không đăng nhập bằng username/password, cũng không nên cầm credential vĩnh viễn.

Ghép hai ràng buộc lại: cần một entity mà AWS service có thể assume để lấy quyền tạm thời. Đó chính là định nghĩa của IAM Role. Nếu đề chỉ hỏi "cái gì định nghĩa permissions" thì IAM Policy mới là đáp án — chữ entity và chữ services mới là thứ tách hai phương án B và D ra.

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

D — IAM Role là đáp án đúng.

IAM Role cho phép uỷ quyền (delegate) permissions cho người dùng và cho dịch vụ mà không cần dùng credential cố định. Cách làm chuẩn: tạo một role, gắn IAM policy chứa các quyền cần thiết vào role đó, rồi để AWS service assume role. Khi đó service nhận về credential tạm thời và hành động trong đúng phạm vi policy đã gắn.

Nói gọn: policy chứa quyền, role là thứ mang quyền đó tới cho service. Bạn không gắn policy thẳng vào EC2 hay Lambda — bạn gắn policy vào role, rồi gán role cho service.

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

A — IAM Access Key ID và Secret Access Key. Đây là cặp khoá cấp cho IAM user để truy cập theo kiểu lập trình qua API hoặc CLI. Nó là credential, không phải IAM entity dùng để gán quyền, và bản thân nó không chứa permission nào cả — quyền vẫn nằm ở policy gắn vào user. Ngoài ra đây là credential dài hạn, đúng thứ mà mô hình role sinh ra để tránh.

B — IAM Policy. Đây là phương án gần đúng nhất và là bẫy chính của câu này. Policy đúng là tài liệu định nghĩa permissions, nhưng nó áp lên user, group và role chứ không áp thẳng lên một AWS service. Nó cũng không phải "entity" theo cách IAM phân loại. Trình tự đúng là: policy → gắn vào role → role gán cho service. Policy thiếu mất đúng mắt xích mà đề hỏi tới.

C — Security Token Service (STS). STS là dịch vụ cấp credential bảo mật tạm thời, tức là cơ chế phía sau khi một role được assume. Nó phát hành token chứ không phải thứ bạn "gán quyền" vào. Chọn C là nhầm giữa công cụ tạo credential tạm với entity mang permissions.

📌 Điểm cần nhớ

• Entity vs. document: IAM user và IAM role là entity (có identity, hành động được); IAM policy là tài liệu mô tả quyền, luôn phải gắn vào một entity mới có tác dụng.
• Đề nhắc tới AWS service, application chạy trên EC2/Lambda, hoặc cross-account access → phản xạ đầu tiên là IAM Role, vì đó là cách tránh credential vĩnh viễn.
• Access key = credential dài hạn của user, dành cho API/CLI. Thấy phương án này trong câu hỏi về gán quyền cho service thì gần như chắc chắn là bẫy.
• STS là hậu trường của role: nó phát hành credential tạm thời khi role được assume. Nó trả lời câu hỏi "credential tạm ở đâu ra", không trả lời câu hỏi "gán quyền vào đâu".

Đáp án

B — VPC FLOW LOGS.

Vì sao đúng

⚠ VPC Flow Logs làm gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Ghi lại lưu lượng IP VÀO và RA của giao diện mạng | ⚠ đúng nguyên văn đề bài | | ⚠ Bật được ở ba mức: VPC, mạng con, hoặc từng ENI | | | ⚠ Ghi được lưu lượng bị CHẤP NHẬN, bị TỪ CHỐI, hoặc cả hai | | | ⚠ Xuất ra CloudWatch Logs hoặc S3 | | | ⚠ Dùng để làm gì | ⚠ chẩn đoán vì sao kết nối không thông, phát hiện lưu lượng bất thường, phục vụ điều tra bảo mật |

⚠ Công dụng thực tế được dùng nhiều nhất: ⚠ khi hai máy không nối được với nhau, flow log cho biết gói tin bị TỪ CHỐI ở đâu ⚠ — ⚠ nhờ đó xác định được lỗi nằm ở nhóm bảo mật hay ở danh sách kiểm soát mạng.

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

• A (AWS CloudTrail) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ cả hai đều là dịch vụ GHI NHẬT KÝ dùng cho kiểm toán và điều tra bảo mật, nên rất dễ chọn nhầm: ⚠ nhưng ⚠ CloudTrail ghi lại các LỜI GỌI API — ai đã làm gì với tài nguyên AWS, lúc nào, từ đâu ⚠; ⚠ nó hoàn toàn không thấy gói tin mạng đi qua giao diện mạng; ⚠ cách nhớ rõ ràng nhất: CloudTrail ghi hành động của CON NGƯỜI và ứng dụng lên AWS, còn Flow Logs ghi LƯU LƯỢNG MẠNG bên trong VPC — hai tầng hoàn toàn khác nhau.

• C (Amazon CloudWatch) — ⚠ là dịch vụ giám sát chỉ số và lưu trữ nhật ký; ⚠ nó là NƠI NHẬN flow log chứ không phải thứ tạo ra chúng.

• D (AWS Config) — ⚠ theo dõi CẤU HÌNH tài nguyên thay đổi theo thời gian; ⚠ nó trả lời "tài nguyên này có đúng chuẩn không", không phải "gói tin nào đã đi qua".

Ghi nhớ

⚠ Bốn dịch vụ ghi chép của AWS, phân biệt dứt khoát: | Dịch vụ | Ghi lại cái gì | |---|---| | ⚠ CloudTrail | ⚠ LỜI GỌI API — ai làm gì với tài nguyên | | ⚠ VPC FLOW LOGS | ⚠ LƯU LƯỢNG MẠNG vào ra giao diện — ĐÁP ÁN | | ⚠ CloudWatch Logs | ⚠ nhật ký của ứng dụng và hệ thống | | ⚠ AWS Config | ⚠ CẤU HÌNH tài nguyên và lịch sử thay đổi | | ⚠ Câu hỏi phân loại nhanh | ⚠ "ai đã làm" thì CloudTrail; "gói tin nào đã đi" thì Flow Logs; "ứng dụng in ra gì" thì CloudWatch Logs; "cấu hình có đúng chuẩn không" thì Config |

⚠ Một dòng flow log có gì: | Trường | Nội dung | |---|---| | ⚠ IP nguồn và IP đích | | | ⚠ Cổng nguồn và cổng đích | | | ⚠ Giao thức, số gói, số byte | | | ⚠ ACCEPT hoặc REJECT | ⚠ trường quan trọng nhất khi chẩn đoán | | ⚠ Giới hạn cần biết | ⚠ flow log ghi SIÊU DỮ LIỆU về luồng chứ không ghi NỘI DUNG gói tin — muốn xem nội dung thì phải dùng công cụ bắt gói ở tầng khác |

⚠ Quy trình chẩn đoán kết nối không thông: | Bước | Nội dung | |---|---| | ⚠ 1. Bật flow log ở mạng con hoặc ENI liên quan | | | ⚠ 2. Tìm dòng REJECT | | | ⚠ 3. REJECT ở chiều VÀO | ⚠ nghi nhóm bảo mật hoặc network ACL của đích | | ⚠ 4. Không thấy dòng nào cả | ⚠ gói tin chưa từng tới nơi — vấn đề ở định tuyến | | ⚠ Vì sao bước 4 quan trọng | ⚠ sự VẮNG MẶT của bản ghi cũng là một manh mối — nó tách bạch lỗi định tuyến với lỗi tường lửa, hai nguyên nhân rất dễ nhầm lẫn với nhau |

Từ khoá nhận diện:

"ghi lưu lượng IP vào ra giao diện mạng" → ⚠ VPC FLOW LOGS "CloudTrail" → ⚠ lời gọi API, ai đã làm gì "CloudWatch" → ⚠ giám sát chỉ số, nơi NHẬN nhật ký "AWS Config" → ⚠ cấu hình tài nguyên và lịch sử thay đổi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VPC của bạn đã bật flow log chưa | | | Bạn phân biệt được CloudTrail với Flow Logs chưa | | | Nhật ký của bạn có thời hạn lưu phù hợp không | |

Và lý do bật sẵn flow log đáng giá hơn nhiều so với chi phí lưu trữ của nó: khi sự cố xảy ra thì đã quá muộn để bắt đầu ghi — nhật ký chỉ trả lời được những câu hỏi về quá khứ nếu nó đã chạy từ trước đó.

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

Đề hỏi: "Which of the below is an example of an architectural benefit of moving to the cloud?" — đâu là ví dụ về một lợi ích kiến trúc khi chuyển lên cloud.

Cụm từ quyết định đáp án là "architectural benefit of moving to the cloud". Hai chữ này phải đọc cùng nhau:

• "benefit" — phải là thứ có lợi, thứ ta muốn đạt được. Điều này loại ngay những phương án mô tả đặc điểm trung tính hoặc bất lợi.
• "of moving to the cloud" — phải là thứ cloud mang lại, tức là đặc trưng của mô hình cloud chứ không phải thứ đã có sẵn từ thời data center truyền thống.

Một phương án chỉ đúng khi thỏa cả hai vế. Đây chính là cái bẫy của câu: có phương án nghe rất "kỹ thuật hạ tầng" nhưng không phải lợi ích, có phương án là khả năng thật nhưng chẳng riêng gì cloud.

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

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

Elasticity là khả năng hệ thống tự co giãn theo nhu cầu thực tế: tài nguyên được cấp thêm khi lượng truy cập tăng, và được thu hồi khi lượng truy cập giảm. Đây là lợi ích kiến trúc cốt lõi của cloud vì nó thay đổi cách ta thiết kế hệ thống — thay vì mua sẵn hạ tầng cho đỉnh tải rồi để không suốt phần còn lại của năm, ta thiết kế để hệ thống bám sát đường cong nhu cầu.

Hệ quả trực tiếp là chi phí: mô hình cloud tính tiền theo lượng tài nguyên thực dùng, nên co giãn xuống lúc rảnh cũng là giảm hóa đơn. Elasticity thỏa cả hai vế của đề — vừa là lợi ích rõ ràng, vừa là đặc trưng mà mô hình on-premises truyền thống không có được (phần cứng đã mua rồi thì không "trả lại" được vào buổi đêm).

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

A. Vertical scalability — đây là phương án gần đúng nhất và cũng là bẫy chính. Nó là một dạng khả năng mở rộng thật, và trên AWS ta đúng là đổi được sang instance type lớn hơn. Nhưng nó hỏng ở cả hai vế: thứ nhất, vertical scaling (thêm CPU/RAM cho một máy) không phải thứ riêng của cloud — nâng cấp phần cứng cho một server vật lý là việc người ta làm từ lâu trước khi có cloud. Thứ hai, đây không phải hướng kiến trúc mà ta nhắm tới: mở rộng theo chiều dọc luôn đụng trần phần cứng và thường đòi ngừng dịch vụ để đổi cấu hình. Kiến trúc trên cloud ưu tiên horizontal scalability — thêm bớt nhiều instance nhỏ — và chính horizontal scaling mới là thứ tạo ra elasticity ở đáp án D.

B. Proprietary hardware — sai vì đi ngược hẳn mô hình cloud. Khi chạy trên AWS, hạ tầng vật lý bên dưới do AWS sở hữu và vận hành; khách hàng không mang phần cứng riêng của mình vào để chạy dịch vụ. Nói cách khác, "proprietary hardware" không những không phải lợi ích của việc lên cloud, mà còn là thứ ta từ bỏ khi lên cloud. Nó thỏa vế "of moving to the cloud" theo nghĩa ngược, và trượt hoàn toàn vế "benefit".

C. Monolithic services — sai vì đây là kiểu kiến trúc mà việc chuyển lên cloud thường nhằm thoát khỏi, không phải nhằm đạt được. Monolith đóng gói toàn bộ chức năng thành một khối triển khai duy nhất, nên muốn mở rộng một chức năng nhỏ thì phải nhân bản cả khối. Đúng là chạy được một monolith trên cloud, nhưng làm vậy thì bỏ phí phần lớn lợi ích co giãn. Hướng kiến trúc được ưa dùng trên cloud là service-oriented hoặc microservices — tách nhỏ để từng phần co giãn độc lập.

📌 Điểm cần nhớ

• Elasticity ≠ scalability. Scalability là "có mở rộng được không"; elasticity là "có tự động co giãn hai chiều theo nhu cầu không". Đề hỏi lợi ích đặc trưng của cloud thì elasticity là từ khóa cần tìm.
• Horizontal được ưu tiên hơn vertical trong kiến trúc cloud: thêm bớt nhiều instance nhỏ thì không đụng trần phần cứng và co giãn được cả chiều xuống. Thấy "vertical scalability" đứng cạnh một lựa chọn co giãn khác thì nó thường là bẫy.
• Đọc kỹ chữ "benefit". Nhiều phương án trong nhóm câu này (monolithic, proprietary hardware, tightly coupled) là những thứ cloud giúp ta rời bỏ, không phải thứ cloud mang lại.
• Loại phương án bằng hai câu hỏi: Đây có phải thứ ta muốn không? và Cloud có phải nơi duy nhất (hoặc điển hình) cho nó không? Trượt câu nào cũng loại.

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

Đề hỏi: dịch vụ hoặc tính năng nào của AWS dùng để giới hạn từng API action cụ thể mà users và roles trong each member account được phép dùng.

Có hai cụm từ quyết định đáp án, và phải đọc cả hai cùng lúc:

• "member account" — chữ này chỉ có nghĩa trong ngữ cảnh một tổ chức nhiều tài khoản. Tài khoản đứng riêng lẻ không được gọi là member account; từ này gắn liền với mô hình management account + member accounts.
• "restrict the individual API actions" — không phải "cấp quyền", mà là chặn/giới hạn ở tầng trên, áp cho users và roles bên trong tài khoản đó.

Ghép lại: câu hỏi cần một cơ chế kiểm soát tập trung, đặt trần quyền cho toàn bộ principals của một tài khoản thành viên, chứ không phải công cụ cấp quyền bên trong một tài khoản. Đó chính là Service Control Policies (SCPs) của AWS Organizations.

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

D. AWS Organizations là đáp án đúng theo tệp.

AWS Organizations cung cấp Service Control Policies (SCPs) — một loại organization policy dùng để quản lý permissions trong tổ chức. SCPs cho phép kiểm soát tập trung tập quyền tối đa có thể có (maximum available permissions) — tức là những API action nào được phép — cho các tài khoản trong tổ chức.

Điểm mấu chốt: SCP là hàng rào (guardrail), nó định nghĩa trần quyền cho mọi user và role trong member account. Dù trong tài khoản đó có ai gán một IAM policy cho phép rộng đến đâu, action nào bị SCP chặn thì vẫn không dùng được. Nhờ vậy các tài khoản luôn nằm trong khuôn khổ chính sách kiểm soát truy cập của tổ chức.

Một lưu ý cần nhớ: SCPs chỉ khả dụng khi tổ chức đã bật all features (không dùng được ở chế độ chỉ consolidated billing).

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

A. AWS IAM — đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. IAM đúng là nơi khai báo quyền theo từng API action, nhưng nó cấp quyền (assign permissions) bên trong phạm vi một tài khoản, chứ không phải cơ chế đặt trần từ bên ngoài xuống các member account của tổ chức. Nó hỏng ở hai chỗ so với đề: (1) không có khái niệm quản lý tập trung nhiều member account; (2) tác dụng của nó là cho phép, còn đề yêu cầu restrict. Cách phân biệt chuẩn: muốn gọi API thành công thì cần cả hai — IAM phải cấp quyền và SCP phải không chặn action đó. Đề nhấn vào vế thứ hai.

B. Amazon Macie — dịch vụ được quản lý hoàn toàn về data security và data privacy, dùng machine learning và pattern matching để phát hiện và bảo vệ dữ liệu nhạy cảm trong AWS. Nó làm việc với nội dung dữ liệu, hoàn toàn không can thiệp vào việc user hay role được gọi API nào.

C. AWS Shield — dịch vụ bảo vệ workload trước tấn công DDoS. Đây là bảo vệ ở tầng khả dụng của hạ tầng trước lưu lượng độc hại từ bên ngoài, không liên quan gì tới phân quyền API cho principals nội bộ.

📌 Điểm cần nhớ

• Thấy "member account", "toàn tổ chức", "central control", "guardrail" trong đề → nghĩ ngay tới AWS Organizations / SCPs, không phải IAM.
• Phân vai rõ ràng: IAM cấp quyền, SCP đặt trần quyền. Một API call chỉ chạy được khi IAM cho phép và SCP không chặn. Đề nghiêng về từ "restrict/maximum permissions" thì chọn SCP.
• SCPs đòi tổ chức bật all features; chế độ chỉ consolidated billing không dùng được SCP.
• Đừng để tên dịch vụ "nghe có vẻ bảo mật" đánh lạc hướng: Macie là bảo vệ dữ liệu nhạy cảm, Shield là chống DDoS — cả hai không liên quan tới kiểm soát API action.

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

Đề hỏi: Amazon CloudFront dùng thành phần nào của AWS global infrastructure để phân phối nội dung tới người dùng cuối với độ trễ thấp?

Cụm từ quyết định là "deliver content to end users with low latency" kết hợp với "using the AWS global infrastructure". Cả bốn phương án đều là những khối trong hạ tầng toàn cầu của AWS, nên chỉ nhắc "AWS global infrastructure" thôi chưa đủ để loại phương án nào. Thứ chốt lại đáp án là vế phục vụ nội dung cho người dùng cuối ở gần họ nhất: ta cần lớp hạ tầng nằm sát người dùng về mặt địa lý và có nhiệm vụ phục vụ nội dung, chứ không phải lớp dùng để chạy ứng dụng hay kết nối mạng riêng.

Đây là câu chọn một đáp án, không phải chọn nhiều.

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

D. Edge locations — CloudFront là dịch vụ CDN, tăng tốc phân phối cả nội dung tĩnh (.html, .css, .js, hình ảnh) lẫn nội dung động. Nó phân phối thông qua một mạng lưới trung tâm dữ liệu trải khắp thế giới gọi là edge locations.

Cơ chế: khi người dùng yêu cầu một nội dung đang được phục vụ qua CloudFront, request được định tuyến tới edge location cho độ trễ thấp nhất đối với người dùng đó. Nhờ vậy nội dung được trả về với hiệu năng tốt nhất có thể — đúng y vế "low latency" mà đề nhấn mạnh. Edge location cũng là nơi cache nội dung, nên các request sau đó không phải đi ngược về origin ở xa.

Đây chính là quan hệ khái niệm mà kỳ thi Cloud Practitioner muốn kiểm tra: CloudFront ↔ edge locations.

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

A. Availability Zones — AZ là nhóm các data center bên trong một Region, và nhiều AZ hợp lại thành một AWS Region. AZ tồn tại để bạn triển khai ứng dụng có tính sẵn sàng cao (chịu được sự cố của một AZ). Nó không phải là nơi CloudFront phục vụ nội dung cho người dùng cuối. Đây là phương án gần đúng theo kiểu "cũng là hạ tầng vật lý của AWS", nhưng nó nằm sai tầng: AZ phục vụ workload của bạn, edge location phục vụ khách truy cập của bạn.

B. AWS Direct Connect connections — Direct Connect là cách nối môi trường on-premises của bạn vào AWS Cloud bằng một đường cáp vật lý riêng. Nó giải quyết bài toán kết nối mạng riêng giữa data center của doanh nghiệp và AWS, không liên quan gì tới CloudFront hay edge location. Phương án này lạc đề rõ nhất: người dùng cuối trên Internet không đi qua Direct Connect của bạn.

C. AWS Regions — Region là tập hợp các Availability Zones. Region là nơi bạn khởi chạy ứng dụng, không phải nơi phục vụ nội dung CloudFront. Đây là phương án dễ nhầm nhất vì Region đúng là "hạ tầng toàn cầu" và nội dung gốc (origin) thường nằm trong một Region. Nhưng chỗ nó hỏng là: nếu mọi người dùng đều phải về Region chứa origin thì độ trễ sẽ phụ thuộc khoảng cách tới Region đó — chính vấn đề mà CloudFront sinh ra để giải quyết. Region là origin, edge location mới là điểm phục vụ gần người dùng.

📌 Điểm cần nhớ

• Trong đề thi, hễ thấy CloudFront đi cùng "low latency", "cache", hay "deliver content to end users" thì mắt tìm ngay phương án edge locations.
• Ghi nhớ thứ bậc hạ tầng: nhiều data center → Availability Zone; nhiều AZ → AWS Region; edge location nằm riêng ngoài mô hình đó, tách rời và nhiều hơn về số lượng, đặt gần người dùng cuối.
• Phân biệt vai trò: Region/AZ = nơi chạy ứng dụng và lưu dữ liệu gốc; edge location = nơi phục vụ và cache nội dung cho khách truy cập.
• AWS Direct Connect thuộc nhóm kết nối lai (hybrid) giữa on-premises và AWS — thấy nó trong câu hỏi về phân phối nội dung cho người dùng Internet thì gần như chắc chắn là phương án gây nhiễu.

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

Đề hỏi: dịch vụ nào cho phép tổ chức xem dữ liệu vận hành (operational data) từ nhiều dịch vụ AWS trong một giao diện thống nhất và tự động hoá các tác vụ vận hành?

Cụm từ quyết định nằm ở chỗ đề gộp hai yêu cầu vào một câu, nối bằng chữ "and":

1. unified user interface — một chỗ nhìn duy nhất, gom dữ liệu từ nhiều dịch vụ khác nhau;
2. automate operational tasks — không chỉ nhìn mà còn ra tay làm: vá bản, chạy lệnh, khởi động lại, chạy runbook.

Đây chính là ràng buộc phân biệt bốn phương án. Cả bốn dịch vụ đều liên quan tới quản trị/vận hành, nhưng ba trong số đó chỉ đáp ứng được một nửa, hoặc đáp ứng theo phạm vi hẹp hơn hẳn. Câu này chỉ chọn một đáp án (chonNhieuDapAn = false), nên phải tìm dịch vụ phủ cả hai vế.

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

Đáp án đúng theo tệp là B — AWS Systems Manager.

Systems Manager sinh ra đúng để làm việc này: cho bạn khả năng quan sát và điều khiển hạ tầng đang chạy trên AWS. Nó cung cấp một giao diện thống nhất, nơi dữ liệu vận hành từ nhiều dịch vụ AWS được kéo về cùng một chỗ, và từ đó bạn tự động hoá các tác vụ vận hành trên các tài nguyên AWS của mình.

Nói cách khác, Systems Manager là dịch vụ duy nhất trong danh sách ghép được hai vế của đề: vừa là bảng điều khiển vận hành gom dữ liệu nhiều nguồn, vừa là công cụ thi hành hành động trên tài nguyên. Khi đề bài có cả từ "unified user interface" lẫn "automate operational tasks", đó gần như là câu mô tả nguyên văn của Systems Manager.

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

A — AWS Config. Đây là phương án dễ nhầm nhất nếu bạn chỉ bắt được vế "xem dữ liệu". AWS Config là dịch vụ được quản lý hoàn toàn, cung cấp bản kiểm kê tài nguyên AWS, lịch sử cấu hình và thông báo khi cấu hình thay đổi, phục vụ mục tiêu bảo mật và tuân thủ quy định. Nó trả lời câu hỏi "tài nguyên này đang và đã từng được cấu hình thế nào" — tức là thiên về ghi nhận và đối chiếu cấu hình, không phải giao diện vận hành hợp nhất để bạn tự động hoá công việc hằng ngày. Hỏng ở vế thứ hai của đề.

C — Amazon CloudWatch. Cũng rất gần, vì CloudWatch đúng là nơi tập trung dữ liệu từ nhiều dịch vụ AWS. Nhưng CloudWatch là dịch vụ giám sát (monitoring) tài nguyên AWS và ứng dụng chạy trên AWS: metric, log, alarm, theo dõi hiệu năng. Bạn dùng CloudWatch để theo dõi hiệu năng, không phải để tự động hoá tác vụ vận hành. Nó là "cái đồng hồ đo", còn đề bài đòi thêm "cái tay vặn". Hỏng đúng ở vế automate operational tasks.

D — AWS OpsWorks. Tên có chữ "Ops" nên rất hay bị chọn theo cảm giác. Thực chất OpsWorks là dịch vụ quản lý cấu hình (configuration management), cung cấp các phiên bản được quản lý của Chef và Puppet. Nó gắn với một mô hình cụ thể — dùng công thức Chef/Puppet để cấu hình máy chủ — chứ không phải giao diện thống nhất xem dữ liệu vận hành từ nhiều dịch vụ AWS. Phạm vi hẹp hơn và không khớp vế thứ nhất của đề.

📌 Điểm cần nhớ

• Đề nêu hai yêu cầu nối bằng "and" thì phải chọn dịch vụ phủ cả hai; phương án chỉ đúng một nửa là bẫy được cài sẵn.
• Từ khoá nhận diện: "unified user interface" + "automate operational tasks" → AWS Systems Manager.
• Phân vai ba dịch vụ hay bị lẫn: CloudWatch = giám sát hiệu năng (metric/log/alarm); AWS Config = kiểm kê tài nguyên, lịch sử cấu hình và thông báo thay đổi, phục vụ tuân thủ; OpsWorks = quản lý cấu hình bằng Chef/Puppet.
• Đừng chọn theo tên gọi. "OpsWorks" nghe như dịch vụ vận hành tổng quát nhưng lại là công cụ Chef/Puppet; ngược lại "Systems Manager" mới là chiếc ô lớn cho công việc vận hành hằng ngày.

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

Đề hỏi: dịch vụ AWS nào cho phép tải về theo yêu cầu (on-demand) các báo cáo về bảo mật và tuân thủ của AWS.

Cụm từ quyết định là "on-demand downloads of AWS security and compliance reports" — chú ý từng vế:

• "downloads ... reports": thứ cần lấy về là tài liệu, giấy tờ (file PDF), không phải kết quả quét, không phải khuyến nghị trên màn hình.
• "AWS security and compliance reports": đây là báo cáo về chính hạ tầng của AWS do bên kiểm toán độc lập cấp — SOC, PCI, ISO — chứ không phải báo cáo về workload mà bạn triển khai.
• "on-demand": tự vào lấy bất cứ lúc nào, không phải mở ticket xin AWS gửi.

Ràng buộc phân biệt nằm ở chỗ ai là đối tượng được đánh giá: AWS tự chứng minh phần trách nhiệm của mình trong Shared Responsibility Model. Ba phương án còn lại đều là công cụ tác động lên tài nguyên của bạn, nên chỉ cần bám vào vế này là loại được ngay.

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

Đáp án đúng theo tệp là B — AWS Artifact.

AWS Artifact là kho tài liệu tuân thủ tập trung của AWS, cho phép tải về theo yêu cầu các báo cáo bảo mật và tuân thủ của AWS, cùng một số thoả thuận trực tuyến (chẳng hạn thoả thuận liên quan tới xử lý dữ liệu). Các tài liệu có trong Artifact gồm báo cáo SOC (Service Organization Control), báo cáo PCI (Payment Card Industry) và các chứng nhận từ những tổ chức công nhận ở nhiều khu vực địa lý và nhiều mảng tuân thủ khác nhau — chúng xác nhận 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ả.

Đây chính xác là thứ đề bài mô tả: bạn cần đưa bằng chứng tuân thủ cho kiểm toán viên hoặc bộ phận pháp chế, vào Artifact tải file về, không cần liên hệ ai.

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

A — AWS Directory Service. Đây là dịch vụ thư mục do AWS quản lý. Bản AWS Directory Service for Microsoft Active Directory (còn gọi là AWS Managed Microsoft AD) chạy trên Microsoft Active Directory thật, dùng để quản lý người dùng, máy tính và chính sách nhóm, cho phép ứng dụng và tài nguyên tham gia domain. Nó thuộc nhóm Identity, có dính tới "identity" nên đôi khi gây phân vân, nhưng nó quản lý danh tính, hoàn toàn không phát hành hay lưu trữ tài liệu kiểm toán nào.

C — Amazon Inspector. Đây là phương án gần đúng nhất và là bẫy chính của câu này, vì Inspector là dịch vụ đánh giá bảo mật tự động và mô tả chính thức của nó có nhắc tới việc "cải thiện bảo mật và tuân thủ" cho ứng dụng triển khai trên AWS. Chỗ nó hỏng: Inspector quét tài nguyên của bạn (chẳng hạn phát hiện lỗ hổng, cấu hình lệch chuẩn) và sinh ra finding — kết quả quét của riêng môi trường bạn. Đề không hỏi kết quả quét, mà hỏi báo cáo tuân thủ của AWS đã được bên thứ ba chứng thực. Hai loại tài liệu này khác nhau về đối tượng được đánh giá: một bên là workload của bạn, một bên là hạ tầng của AWS.

D — AWS Trusted Advisor. Là công cụ trực tuyến đưa ra khuyến nghị theo thời gian thực giúp bạn cấp phát và cấu hình tài nguyên theo các best practice của AWS (bao gồm cả nhóm khuyến nghị về security). Nó có sinh ra "check" và cảnh báo, nhưng đó là lời khuyên vận hành cho tài khoản của bạn, không phải chứng nhận tuân thủ để nộp cho kiểm toán. Trusted Advisor cũng không cấp bất kỳ file SOC hay PCI nào.

📌 Điểm cần nhớ

• Thấy đề nhắc "compliance reports", "SOC", "PCI", "ISO", "audit artifacts", "agreements" → gần như chắc chắn là AWS Artifact. Đây là từ khoá gần như một-đối-một trong đề thi Cloud Practitioner.
• Phân biệt bằng câu hỏi "đánh giá cái gì?": Artifact = bằng chứng về hạ tầng của AWS (phần trách nhiệm của AWS); Inspector và Trusted Advisor = đánh giá tài nguyên của bạn (phần trách nhiệm của khách hàng). Đây chính là ranh giới Shared Responsibility Model.
• Phân biệt tiếp bằng "đầu ra là gì?": Artifact trả về file tài liệu tải xuống; Inspector trả về finding của bản quét; Trusted Advisor trả về khuyến nghị best practice.
• Đừng để tên dịch vụ thuộc nhóm "Security, Identity & Compliance" đánh lừa — AWS Directory Service nằm cùng nhóm nhưng công việc của nó là quản lý directory, không liên quan gì tới tài liệu tuân thủ.

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

Đề mô tả một công ty cần tối ưu chi phí và mức sử dụng tài nguyên (optimize costs and resource usage) thông qua việc theo dõi tình trạng vận hành (monitoring of operational health) của toàn bộ tài nguyên đang chạy trên AWS.

Cụm từ quyết định là "monitoring of operational health" — tức là quan sát tài nguyên đang hoạt động ra sao ngay lúc này: CPU cao hay thấp, bộ nhớ còn bao nhiêu, có lỗi không, lưu lượng thế nào. Đây là số liệu vận hành (metrics) theo thời gian.

Cụm thứ hai bổ trợ là "optimize costs and resource usage". Ý ở đây không phải là "xuất báo cáo hoá đơn", mà là: nhìn vào số liệu sử dụng thực tế để biết máy đang thừa hay thiếu công suất, từ đó cấp phát vừa đủ (right-sizing).

Bốn phương án đều là dịch vụ thuộc nhóm Management & Governance và rất dễ lẫn nhau, nên phải phân biệt bằng loại dữ liệu mỗi dịch vụ sinh ra: metrics vận hành, bản ghi thay đổi cấu hình, bản ghi lời gọi API, hay bộ khung quản trị nhiều tài khoản.

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

Đáp án đúng theo tệp là B — Amazon CloudWatch.

CloudWatch là dịch vụ giám sát hiệu năng, nhận metrics từ các dịch vụ AWS. Chính dòng dữ liệu đó là thứ trả lời được câu hỏi "tài nguyên của tôi đang khoẻ hay yếu?" — đúng nghĩa operational health mà đề nêu.

Và cũng chính dữ liệu đó phục vụ việc tối ưu chi phí: khi nhìn thấy mức sử dụng thực tế theo thời gian, ta biết tài nguyên nào đang được cấp phát dư và có thể thu nhỏ lại, tài nguyên nào cần thêm. Nghĩa là CloudWatch phủ cả hai vế của đề — vừa theo dõi vận hành, vừa là căn cứ để cấp phát vừa đủ. Ba phương án còn lại, mỗi cái chỉ chạm được một phần rất nhỏ hoặc chẳng chạm phần nào.

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

A — AWS Config. Đây là phương án gần đúng nhất và cũng dễ bẫy nhất, vì Config cũng theo dõi tài nguyên. Nhưng thứ nó theo dõi là cấu hình của tài nguyên và sự thay đổi cấu hình theo thời gian, dùng để quản lý tuân thủ (compliance) — ví dụ "security group này có mở cổng ra Internet không", "bucket này có bật mã hoá không". Config không cho biết CPU của instance đang ở mức nào hay hàng đợi đang tồn đọng bao nhiêu. Nó trả lời "tài nguyên được cấu hình đúng chuẩn chưa", còn đề hỏi "tài nguyên đang chạy khoẻ không". Hai câu hỏi khác nhau.

C — AWS Control Tower. Đây là dịch vụ dựng và quản trị môi trường nhiều tài khoản (multi-account) — thiết lập landing zone, áp guardrail, quản trị ở quy mô tổ chức. Nó nằm ở tầng tổ chức và chính sách, không phải tầng số liệu vận hành của từng tài nguyên. Đề bài không hề nhắc tới nhiều tài khoản hay nhiều nhóm — không có tín hiệu nào dẫn tới Control Tower.

D — AWS CloudTrail. Cũng là một phương án gần đúng vì nó "ghi lại mọi thứ xảy ra". Nhưng CloudTrail là công cụ kiểm toán (auditing): nó ghi lại ai đã gọi API nào, lúc nào, từ đâu. Nó cho biết có người vừa dừng một instance, chứ không cho biết instance đó đang chạy ở mức tải bao nhiêu. Ghi nhận hành động của con người/hệ thống ≠ đo sức khoẻ vận hành của tài nguyên. Ngoài ra dữ liệu kiểm toán không giúp gì cho việc right-sizing.

📌 Điểm cần nhớ

• Bốn dịch vụ này phân biệt bằng loại dữ liệu, học thuộc theo cặp từ khoá: CloudWatch = metrics/hiệu năng/health; CloudTrail = ai làm gì (audit API); Config = cấu hình và compliance; Control Tower = quản trị nhiều tài khoản.
• Thấy chữ "monitoring", "operational health", "performance", "utilization" trong đề Cloud Practitioner thì gần như chắc chắn hướng về CloudWatch.
• Thấy chữ "who did what", "audit", "API call history" → CloudTrail. Thấy "compliance", "configuration change" → Config. Thấy "multi-account", "landing zone", "govern at scale" → Control Tower.
• Tối ưu chi phí không phải lúc nào cũng dẫn tới dịch vụ có chữ "cost/billing" trong tên. Khi đề gắn tối ưu chi phí với mức sử dụng tài nguyên, con đường đi qua dữ liệu giám sát để right-sizing.

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

Đề hỏi: AWS global infrastructure mang lại high availability và fault tolerance cho khách hàng bằng cách nào? Đây là câu kiểm tra xem bạn có nắm đúng thứ tự phân cấp của hạ tầng AWS hay không.

Cụm từ quyết định nằm ở chính cấu trúc mô tả trong từng phương án: cái gì chứa cái gì. Cấu trúc đúng theo tài liệu AWS là Region chứa nhiều Availability Zone, mỗi AZ là một nhóm data center. Ba phương án sai đều đảo hoặc bịa lại quan hệ này: một cái nói AZ nằm trong subnet, một cái nói Region nằm trong AZ, một cái nói người dùng chọn được từng data center. Từ khoá cần bám thêm là isolated / independent — tính cô lập chính là thứ tạo ra fault tolerance, chứ không phải "gần người dùng" hay "ít nguy cơ ngập lụt".

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

Đáp án đúng theo tệp là C: "The AWS infrastructure consists of isolated AWS Regions with independent Availability Zones that are connected with low-latency networking and redundant power supplies."

Phương án này mô tả đúng mô hình mà AWS công bố:

• Region là một vị trí địa lý vật lý, nơi AWS gom cụm các data center. Các Region cô lập với nhau — sự cố ở Region này không lan sang Region khác.
• Mỗi Region gồm nhiều AZ tách biệt về mặt vật lý, mỗi AZ là một nhóm data center logic có nguồn điện, làm mát và mạng riêng — tức là redundant power supplies.
• Các AZ trong cùng Region nối với nhau bằng low-latency networking, nên bạn có thể chạy ứng dụng đồng bộ trên nhiều AZ mà vẫn đủ nhanh.

Đúng thứ tự phân cấp (Region → AZ → data center), đúng cơ chế cô lập, và đúng lý do vì sao khách hàng có được high availability: triển khai qua nhiều AZ thì một AZ hỏng không kéo sập ứng dụng.

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

A — "subnets containing various Availability Zones...": sai ngay ở khái niệm. Subnet không phải là thành phần vật lý của AWS global infrastructure. Subnet là một dải địa chỉ IP bên trong một VPC, dùng để đặt instance — nó là cấu trúc mạng logic do khách hàng tạo ra. Quan hệ thật còn ngược lại: một subnet nằm gọn trong một AZ, chứ không thể "chứa nhiều AZ".

B — "multiple AWS Regions within various Availability Zones...": đây là phương án gần đúng nhất và cũng là bẫy chính. Nó nhắc đúng các chi tiết đáng tin (low-latency network, redundant power supplies, chọn vị trí ít rủi ro thiên tai), nhưng đảo ngược quan hệ chứa đựng: nó nói Region nằm trong AZ. Thực tế Region là tập hợp của các AZ, không phải ngược lại. Chỉ một chữ "within" đặt sai chỗ là cả câu mô tả sai hạ tầng — đây chính là điểm phân biệt B với C.

D — "AWS allows users to choose AWS Regions and data centers...": sai ở mức độ chi tiết mà khách hàng kiểm soát được. Bạn chọn được Region và chọn được AZ, nhưng không chọn được từng data center cụ thể — một AZ gồm nhiều data center và AWS không phơi bày ranh giới đó ra cho người dùng. Ngoài ra, câu này chỉ nói về việc chọn vị trí gần (thiên về độ trễ), không hề giải thích cơ chế nào tạo ra high availability hay fault tolerance — tức là trả lời lệch câu hỏi.

📌 Điểm cần nhớ

• Thứ tự phân cấp bắt buộc thuộc: Region → Availability Zone → data center. Phương án nào đảo chiều quan hệ này thì sai, dù các chi tiết còn lại nghe rất hợp lý.
• Subnet và VPC là khái niệm mạng logic của khách hàng, không phải thành phần của global infrastructure. Thấy "subnet" trong câu hỏi về hạ tầng vật lý thì gần như chắc là phương án sai.
• Khách hàng chọn được Region và AZ, không chọn được data center cụ thể.
• High availability đến từ tính cô lập giữa các AZ/Region cộng với kết nối low-latency giữa các AZ trong cùng Region — nhờ đó chạy được kiến trúc multi-AZ mà vẫn đảm bảo hiệu năng.