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 cho phép thu thập dữ liệu về cấu hình, mức sử dụng và hành vi của các data center tại chỗ (on-premises) nhằm phục vụ việc lập kế hoạch di chuyển (migration) lên AWS.

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

• "on-premises data centers" — nguồn dữ liệu nằm ngoài AWS, ở trung tâm dữ liệu của công ty. Bất kỳ dịch vụ nào chỉ nhìn thấy tài nguyên đã nằm sẵn trong tài khoản AWS đều bị loại ngay từ đây.
• "to assist in planning a migration" — mục đích là khảo sát trước khi chuyển, tức là giai đoạn discovery / assessment, chưa phải vận hành hay quản trị.

Ghép hai ràng buộc lại: cần một dịch vụ chuyên khám phá (discover) hạ tầng tại chỗ và xuất ra dữ liệu để lên phương án migration. Chú ý thêm rằng đề nhấn mạnh cả ba loại dữ liệu — configuration, usage, behavior — nghĩa là không chỉ liệt kê máy chủ mà còn đo tải và mối liên hệ giữa các máy, đúng phần việc của bước khảo sát tiền di chuyển.

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

A – AWS Application Discovery Service là đáp án đúng.

Đây là dịch vụ được thiết kế đúng cho mục đích trong đề: thu thập thông tin cấu hình và mức sử dụng của các máy chủ on-premises để giúp bạn lập kế hoạch di chuyển lên AWS. Tên dịch vụ đã nói lên vai trò của nó — Discovery, tức là khám phá hiện trạng hạ tầng bạn đang có trước khi quyết định chuyển cái gì, chuyển thế nào.

Nó nằm trong nhóm AWS Migration & Transfer — đúng lĩnh vực mà câu hỏi này thuộc về — và là bước đầu tiên trong quy trình migration: khảo sát trước, rồi mới tới lập kế hoạch và thực thi.

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

B – AWS Resource Groups. Dịch vụ này dùng để nhóm và tổ chức các tài nguyên AWS lại với nhau, giúp quản lý và tự động hoá thao tác trên nhiều tài nguyên cùng lúc. Điểm hỏng nằm ở phạm vi: nó chỉ làm việc với tài nguyên đã nằm trong AWS, trong khi đề nói rõ dữ liệu cần thu thập nằm ở data center tại chỗ. Một hệ thống chưa được migrate thì không hề tồn tại dưới dạng resource của AWS để mà nhóm lại.

C – AWS Systems Manager. Đây là phương án gần đúng nhất và dễ nhầm nhất, vì Systems Manager có làm việc được với môi trường lai (hybrid), tức là có chạm tới máy chủ on-premises, và cũng thu thập được thông tin về máy. Nhưng nó hỏng ở mục đích: Systems Manager cung cấp console vận hành và API để quản lý tập trung ứng dụng và tài nguyên — vá lỗi, chạy lệnh, quản lý cấu hình đang vận hành. Đó là công cụ operations, không phải công cụ khảo sát phục vụ migration. Đề hỏi "assist in planning a migration", và Systems Manager không phải công cụ dành cho việc đó.

D – AWS Service Catalog. Cho phép tổ chức tạo và quản lý danh mục các dịch vụ IT đã được phê duyệt để dùng trên AWS — tức là kiểm soát xem nhân viên được phép triển khai những gì. Hoàn toàn không liên quan tới migration, cũng không thu thập dữ liệu từ data center tại chỗ. Chữ "Catalog" ở đây là danh mục sản phẩm được phép dùng, đừng nhầm với "danh mục kiểm kê hạ tầng hiện có".

📌 Điểm cần nhớ

• Thấy cụm "on-premises" + "planning a migration" đi cùng nhau thì nghĩ ngay tới nhóm Migration & Transfer, và bước khảo sát đầu tiên là AWS Application Discovery Service.
• Phân biệt theo mục đích chứ không chỉ theo phạm vi: Systems Manager cũng chạm tới máy on-premises, nhưng để vận hành, không phải để khảo sát tiền di chuyển. Nhiều câu bẫy đúng ở chỗ này.
• Resource Groups chỉ tổ chức tài nguyên đã có trong AWS — bất cứ đề nào nói về hệ thống chưa lên cloud đều loại được nó.
• Service Catalog là quản trị/kiểm soát danh mục dịch vụ được phép dùng, không phải công cụ kiểm kê hay migration. Tên nghe giống "danh mục tài sản" nhưng không phải.

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

Đề hỏi: dịch vụ AWS nào cho phép lưu trữ kiểu hybrid cloud giữa môi trường on-premises và AWS Cloud?

Cụm từ quyết định đáp án là "hybrid cloud storage between on-premises and the AWS Cloud". Hai chữ khoá phải đọc cùng nhau:

• hybrid — phải có cả hai đầu: hạ tầng đang chạy tại chỗ và storage trên AWS, nối liền thành một khối cho ứng dụng sử dụng.
• storage — phải là dịch vụ lưu trữ, không phải dịch vụ phân phối nội dung hay sao chép dữ liệu.

Chỉ cần một phương án thiếu một trong hai vế là loại được. Đây là kiểu câu rất phổ biến ở Cloud Practitioner: mọi phương án đều liên quan tới dữ liệu, nhưng chỉ một cái được thiết kế đúng cho cầu nối giữa trung tâm dữ liệu của bạn và AWS.

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

D. AWS Storage Gateway là đáp án đúng.

Storage Gateway sinh ra đúng cho bài toán hybrid cloud storage. Nó chạy như một thiết bị (ảo hoặc phần cứng) đặt tại chỗ trong trung tâm dữ liệu của bạn, và trình bày ra cho các ứng dụng nội bộ những giao thức lưu trữ tiêu chuẩn của ngành — file, volume dạng block, tape ảo — trong khi dữ liệu thật ở phía sau được đẩy lên các dịch vụ lưu trữ object và block của AWS.

Nhờ vậy ứng dụng cũ trong nhà không cần sửa gì vẫn dùng được storage trên cloud: nó tưởng mình đang gắn một file share hay một ổ đĩa bình thường. Gateway còn giữ bộ nhớ đệm cục bộ (local cache) cho phần dữ liệu hay dùng, nên độ trễ khi truy cập vẫn ở mức chấp nhận được dù dữ liệu gốc nằm trên cloud. Đúng cả hai vế mà đề yêu cầu: có mặt tại on-premises, và nối thẳng vào AWS Cloud.

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

A. Amazon CloudFront — đây là một content delivery network (CDN). Việc của nó là cache nội dung tại các điểm hiện diện gần người dùng cuối để giảm độ trễ khi phân phối. Nó tối ưu đường truyền tới người xem, chứ không phải nơi lưu trữ dữ liệu, và không dựng cầu nối nào giữa trung tâm dữ liệu của bạn với AWS. Sai cả vế "storage" lẫn vế "hybrid".

B. Amazon EFS — đây là phương án gần đúng nhất và cũng là cái bẫy chính. EFS là dịch vụ file system dùng giao thức NFS, và bạn có thể mount nó từ máy chủ on-premises. Nghe qua rất giống hybrid. Nhưng EFS không được thiết kế cho mục đích đó: nó không có local cache đặt tại chỗ, và không cung cấp cơ chế đưa dữ liệu từ on-premises lên cloud như một sản phẩm hoàn chỉnh. Mount từ xa qua NFS chỉ là truy cập một file system trên cloud từ nơi khác — mọi thao tác đọc/ghi đều phải đi qua đường mạng tới AWS. Đó là truy cập từ xa, không phải hybrid storage theo nghĩa đề hỏi.

C. Amazon S3 Cross-Region Replication (CRR) — CRR sao chép object từ một S3 bucket sang một S3 bucket khác ở region khác. Cả hai đầu đều nằm trong AWS. Không có mặt nào chạm tới on-premises, nên đây không phải ví dụ về hybrid cloud. Nó giải quyết bài toán khác hẳn: dự phòng theo vùng địa lý, đưa dữ liệu gần người dùng ở khu vực khác, hoặc đáp ứng yêu cầu tuân thủ về nơi lưu dữ liệu.

📌 Điểm cần nhớ

• Thấy chữ "hybrid" trong đề, hãy tìm dịch vụ có thành phần chạy tại on-premises. Một dịch vụ mà cả hai đầu đều nằm trong AWS (như S3 CRR) tự động bị loại.
• AWS Storage Gateway là câu trả lời mặc định cho "hybrid cloud storage": thiết bị tại chỗ, giao thức lưu trữ tiêu chuẩn, local cache, dữ liệu nằm trên AWS.
• "Mount được từ xa" không đồng nghĩa với "hybrid". EFS mount được từ on-premises nhưng thiếu local cache và cơ chế chuyển dữ liệu — đây là điểm phân biệt EFS với Storage Gateway trong đề thi.
• Phân biệt rõ nhóm dịch vụ theo mục đích: CloudFront = phân phối nội dung tới người dùng cuối; S3 CRR = sao chép giữa các region trong AWS; Storage Gateway = cầu nối on-premises ↔ AWS.

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

Đề mô tả một tài khoản AWS đang dùng Business-level AWS Support plan và cần được hỗ trợ khi production service bị gián đoạn. Câu hỏi: người dùng nên làm gì?

Cụm từ quyết định là "Business-level AWS Support plan" — nó không nói về việc sự cố nghiêm trọng đến đâu, mà giới hạn người dùng được phép dùng những kênh hỗ trợ nào. Cụm thứ hai là "production service disruption", nó khớp đúng tên một mức độ nghiêm trọng (severity) trong hệ thống support case của AWS.

Bốn phương án cố tình trộn lẫn hai nhóm: hai phương án là kênh liên hệ dành riêng cho gói Enterprise (TAM, Concierge), hai phương án còn lại là mức severity của support case — trong đó một mức chỉ có ở Enterprise. Nhận ra được "cái nào thuộc gói nào" là xong câu này.

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

Đáp án đúng theo tệp là D — Open a production system down support case.

Gói Business cho phép mở support case ở mức production system down, và AWS cam kết một mức phản hồi rất nhanh cho severity này (theo tài liệu nguồn là dưới một giờ). Đây chính là mức severity cao nhất mà một khách hàng Business được chọn, và mô tả trong đề — dịch vụ production đang bị gián đoạn — khớp chính xác định nghĩa của nó.

Nói cách khác: người dùng đã trả tiền cho đúng công cụ cần dùng trong tình huống này, việc phải làm chỉ là mở case và chọn đúng mức nghiêm trọng, chứ không phải đi tìm một kênh liên hệ mà gói của họ không bao gồm.

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

A — Contact the dedicated Technical Account Manager. TAM là người phụ trách kỹ thuật được chỉ định riêng cho một khách hàng, nhưng đây là quyền lợi của gói Enterprise Support, không có trong gói Business. Khách hàng Business đơn giản là không có TAM để mà liên hệ. Phương án này nghe rất hợp lý về mặt "ai giúp tôi lúc sự cố", nhưng hỏng ở chỗ nó mô tả một nguồn lực không tồn tại trong gói đang dùng.

B — Open a business-critical system down support case. Đây là phương án gài bẫy nặng nhất, vì chữ "business" trùng với tên gói trong đề, và vì đúng là có tồn tại severity tên như vậy. Nhưng business-critical system down là mức severity chỉ dành cho Enterprise Support. Khách hàng Business khi mở case sẽ không thấy lựa chọn này trong danh sách. Mức cao nhất họ chọn được là production system down — tức phương án D. Đây là điểm phân biệt duy nhất giữa B và D: cả hai đều là support case, cả hai đều mô tả hệ thống chết, nhưng chỉ một mức nằm trong gói đã mua.

C — Contact the dedicated AWS Concierge Support team. Concierge là đội hỗ trợ chuyên về các câu hỏi billing và quản trị tài khoản, và cũng chỉ đi kèm gói Enterprise Support. Ngoài chuyện không có trong gói Business, nó còn sai cả về bản chất: sự cố ở đây là kỹ thuật (production bị gián đoạn), không phải vấn đề hoá đơn hay tài khoản.

📌 Điểm cần nhớ

• Câu hỏi về AWS Support gần như luôn xoay quanh một câu: quyền lợi này thuộc gói nào? Đọc kỹ tên gói trong đề trước khi đọc phương án.
• Technical Account Manager (TAM) và Concierge Support là hai dấu hiệu nhận biết gói Enterprise. Thấy chúng trong phương án mà đề đang nói gói thấp hơn thì loại ngay.
• Phân biệt production system down (mức severity cao nhất mà Business dùng được) với business-critical system down (mức chỉ Enterprise mới có). Chữ "business" trong tên severity không liên quan gì tới gói Business.
• Cẩn thận với những phương án dùng lại đúng từ ngữ xuất hiện trong đề — ở đây "business" được đặt vào phương án B chỉ để tạo cảm giác quen thuộc, không phải để chỉ đúng đáp án.

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

Đề bài hỏi: dịch vụ nào có thể dùng để cải thiện hiệu năng cho người dùng trên khắp thế giới (improve performance for users around the world).

Cụm từ quyết định là "around the world" — tức là người dùng nằm rải rác khắp các châu lục, cách xa nơi đặt hạ tầng gốc. Nếu đề chỉ hỏi "cải thiện hiệu năng" chung chung thì nhiều phương án đều có lý (cache database cũng là cải thiện hiệu năng). Nhưng khi thêm ràng buộc phạm vi toàn cầu, câu hỏi chuyển thành: dịch vụ nào rút ngắn khoảng cách địa lý giữa nội dung và người dùng cuối? Đó chính là định nghĩa của một CDN.

Nói cách khác, vấn đề ở đây là độ trễ do khoảng cách mạng, không phải nghẽn ở tầng database hay ở tầng compute.

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

C – Amazon CloudFront.

CloudFront là content delivery network (CDN) của AWS. Nó lưu bản sao (cache) nội dung tại các Edge Location phân bố trên khắp thế giới. Khi một người dùng ở xa origin gửi yêu cầu, họ được phục vụ từ edge location gần mình nhất thay vì phải đi vòng tới máy chủ gốc.

Kết quả: nội dung nằm gần người dùng hơn về mặt địa lý và mạng, nên độ trễ giảm và hiệu năng tăng — đúng y ràng buộc "users around the world" mà đề đặt ra. Đây là dịch vụ duy nhất trong bốn phương án được thiết kế với mục đích phân phối toàn cầu.

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

A – Amazon ElastiCache — đây là phương án gần đúng nhất và cũng là bẫy chính của câu này. ElastiCache đúng là một dịch vụ caching, và nó đúng là cải thiện hiệu năng đọc cho các truy vấn database. Chỗ nó hỏng là ở chữ "around the world": ElastiCache là caching cho database, phục vụ ứng dụng backend nằm cùng khu vực với nó, chứ không phải một dịch vụ toàn cầu đặt nội dung gần người dùng cuối. Nó giải quyết nghẽn ở tầng dữ liệu, không giải quyết độ trễ do khoảng cách địa lý. Đọc lướt thấy chữ "cache" mà chọn ngay là rơi vào bẫy.

B – Amazon Connect — không liên quan gì tới hiệu năng. Đây là dịch vụ contact center (tổng đài chăm sóc khách hàng) trên nền cloud, kiểu self-service, giúp doanh nghiệp dựng bộ phận hỗ trợ khách hàng với chi phí thấp hơn. Tên nghe giống "kết nối" nên dễ gây nhầm, nhưng nó thuộc mảng dịch vụ khách hàng, không phải mảng networking/content delivery.

D – AWS Lightsail — đây là dịch vụ compute, một lựa chọn rẻ hơn và dễ dùng hơn Amazon EC2, dành cho người muốn dựng nhanh một máy chủ ảo mà không phải cấu hình nhiều. Lightsail cho bạn máy chủ chạy ứng dụng, nhưng bản thân nó không phân phối nội dung ra các điểm gần người dùng khắp thế giới. Chọn máy chủ mạnh hơn không xóa được độ trễ của một yêu cầu phải đi nửa vòng trái đất.

📌 Điểm cần nhớ

• Thấy trong đề các cụm "around the world", "global users", "reduce latency for end users", "distribute content" → nghĩ ngay tới Amazon CloudFront, vì đó là dịch vụ CDN dùng Edge Location để đưa nội dung tới gần người dùng.
• Phân biệt hai loại "cache": CloudFront cache nội dung ở biên mạng, gần người dùng cuối, phạm vi toàn cầu; ElastiCache cache dữ liệu của database, phục vụ ứng dụng backend trong cùng khu vực. Đề nhấn phạm vi toàn cầu thì chọn CloudFront.
• Đừng chọn theo từ khóa lẻ ("cache" → ElastiCache). Hãy đọc ràng buộc phạm vi trong đề — nó mới là thứ tách các phương án gần giống nhau.
• Nhớ đúng nhóm dịch vụ để loại nhanh: Amazon Connect thuộc mảng contact center, AWS Lightsail thuộc mảng compute. Cả hai không nằm trong nhóm networking & content delivery mà câu hỏi này đang nhắm tới.

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

Đề bài hỏi: khi cần lưu trữ mật khẩu trên AWS, đâu là cách an toàn nhất.

Cụm từ quyết định đáp án là "MOST secure method" — chữ most cho biết đây không phải câu hỏi "cách nào chạy được", mà là "cách nào an toàn nhất". Điều này rất quan trọng vì trong bốn phương án, có ít nhất hai nơi về mặt kỹ thuật vẫn cất được một chuỗi mật khẩu (S3 và CloudFormation parameters). Chúng không phải là bất khả thi — chúng chỉ kém an toàn hơn.

Cụm từ thứ hai đáng chú ý là "storing passwords" — tức là đối tượng cần cất giữ là credential, thứ cần được mã hoá, phân quyền chặt chẽ, xoay vòng định kỳ và lấy ra bằng lời gọi API thay vì hardcode trong mã nguồn. Khi đề nói về credential/API key/database password, câu trả lời gần như luôn là một dịch vụ chuyên dụng cho secret, chứ không phải một dịch vụ lưu trữ chung.

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

B — Store passwords in AWS Secrets Manager.

AWS Secrets Manager là dịch vụ được thiết kế đúng cho mục đích này: bảo vệ các secret mà ứng dụng, dịch vụ và hạ tầng IT cần dùng để truy cập lẫn nhau. Nó quản lý trọn vòng đời của database credential, API key và các loại secret khác — lưu trữ, phân quyền, xoay vòng (rotate) và truy xuất.

Điểm mấu chốt khiến nó "an toàn nhất" trong danh sách:

• Secret được lưu ở dạng đã mã hoá, không phải văn bản thuần.
• Ứng dụng lấy secret bằng lời gọi API tới Secrets Manager tại thời điểm chạy, nhờ đó không cần hardcode thông tin nhạy cảm dưới dạng plain text trong mã nguồn hay file cấu hình.
• Có khả năng xoay vòng và quản lý secret theo vòng đời — thứ mà không phương án nào khác trong đề cung cấp.

Ba phương án còn lại đều là dịch vụ lưu trữ hoặc cấu hình dùng cho mục đích khác; chỉ Secrets Manager là dịch vụ chuyên trách secret.

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

A — Store passwords as AWS CloudFormation parameters. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất. CloudFormation có cho phép truyền tham số vào lúc triển khai stack, nên về mặt kỹ thuật bạn có thể nhét mật khẩu vào đó. Nhưng nó hỏng ở chỗ: parameter của CloudFormation là cơ chế tham số hoá template hạ tầng, không phải kho secret. Nó không phải cách lưu mật khẩu an toàn nhất và không có các chức năng bổ sung mà Secrets Manager cung cấp — quản lý vòng đời, xoay vòng, truy xuất qua API chuyên dụng. Chọn A là nhầm giữa "chỗ truyền giá trị vào" với "chỗ cất giữ và bảo vệ giá trị đó".

C — Store passwords in an Amazon S3 bucket. Cũng là một phương án gần đúng. S3 có mã hoá — bạn hoàn toàn có thể mã hoá dữ liệu bên trong bucket của mình. Nhưng S3 là dịch vụ lưu trữ object đa dụng, không được thiết kế riêng cho secret, nên vẫn không an toàn bằng AWS Secrets Manager. Nó thiếu các khả năng đặc thù cho credential như xoay vòng và quản lý theo vòng đời secret. Đề hỏi "an toàn nhất", và giữa một kho object có mã hoá với một dịch vụ chuyên trách secret, đáp án là dịch vụ chuyên trách.

D — Store passwords in AWS Storage Gateway. Sai rõ ràng nhất. Storage Gateway là dịch vụ hybrid storage — nối hạ tầng lưu trữ tại chỗ (on-premises) với kho lưu trữ trên AWS. Mục đích của nó là mở rộng và tích hợp dung lượng lưu trữ, hoàn toàn không phù hợp để cất giữ mật khẩu. Đây là phương án nhiễu dựa trên chữ "Storage" trong tên dịch vụ.

📌 Điểm cần nhớ

• Khi đề nhắc tới password, database credential, API key cùng yêu cầu "most secure", hãy tìm ngay AWS Secrets Manager trong danh sách phương án — đó là dịch vụ chuyên trách secret, không phải dịch vụ lưu trữ đa dụng.
• Chữ MOST trong đề đổi bản chất câu hỏi: nhiều phương án làm được, nhưng chỉ một phương án an toàn nhất. Đừng dừng lại ở phương án đầu tiên nghe hợp lý.
• Giá trị lớn nhất của Secrets Manager là ứng dụng lấy secret qua lời gọi API lúc chạy, nhờ đó loại bỏ việc hardcode thông tin nhạy cảm dưới dạng plain text — cộng thêm khả năng xoay vòng và quản lý vòng đời secret.
• Mã hoá được ≠ phù hợp để lưu secret. S3 mã hoá được nhưng vẫn kém an toàn hơn; CloudFormation parameters truyền được giá trị nhưng thiếu chức năng quản lý secret. Cẩn thận với các phương án nhiễu chỉ giống nhau ở chữ "Storage" trong tên.

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

Đề bài đặt ra một tình huống rất gọn: cần giảm độ trễ (latency) và tăng hiệu năng cho người dùng phân bố khắp toàn cầu (globally distributed users). Cụm từ quyết định đáp án nằm ở đúng hai chữ "globally distributed users" — nó ép ta chọn những dịch vụ có khả năng phục vụ nội dung gần với người dùng về mặt địa lý, chứ không phải những dịch vụ chỉ tăng tốc bên trong một Region.

Đây là điểm phân biệt then chốt. Rất nhiều dịch vụ AWS "làm nhanh hơn" theo nghĩa nào đó, nhưng chúng tăng tốc ở tầng backend, trong cùng một Region, và người dùng ở châu Âu gọi tới ứng dụng đặt ở Mỹ vẫn phải chịu nguyên độ trễ đường truyền xuyên đại dương. Chỉ có nhóm dịch vụ gắn với Edge Location mới xử lý được vấn đề khoảng cách vật lý đó.

Ngoài ra đề ghi rõ (Select TWO) — phải chọn đúng hai phương án, và hai phương án đó nên phối hợp được với nhau thành một kiến trúc hoàn chỉnh chứ không phải hai lựa chọn rời rạc.

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

Đáp án đúng theo tệp là C — Amazon CloudFront và E — Amazon S3.

Amazon CloudFront là dịch vụ CDN (content delivery network) của AWS. Nó lưu bản sao nội dung tại các Edge Location trải khắp thế giới. Người dùng ở Tokyo hay São Paulo sẽ lấy nội dung từ Edge Location gần mình thay vì đi vòng về origin ở tận Region gốc — quãng đường mạng ngắn lại thì độ trễ giảm và hiệu năng cảm nhận được tăng lên. Đây chính xác là dịch vụ được thiết kế cho yêu cầu "global users".

Amazon S3 là kho lưu trữ dạng đối tượng (object storage), dùng để chứa các nội dung cần phục vụ như tệp, hình ảnh, video, tài nguyên tĩnh. S3 bucket còn có thể cấu hình làm static website.

Hai dịch vụ này ghép với nhau thành một cặp kinh điển: S3 bucket đóng vai trò origin cho CloudFront distribution. Nội dung nằm ở S3, CloudFront phân phát bản cache của nội dung đó ra các Edge Location toàn cầu. Người dùng ở bất cứ đâu cũng kéo được nội dung từ điểm gần mình, với độ trễ thấp hơn và hiệu năng tốt hơn. Đó là lý do đề hỏi hai phương án chứ không phải một — chúng là hai nửa của cùng một giải pháp.

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

A — Amazon ElastiCache. Đây là phương án gần đúng nhất và cũng là bẫy nặng nhất, vì tên nó có chữ "cache" nên dễ liên tưởng tới CloudFront. Nhưng ElastiCache là bộ nhớ đệm in-memory đặt trước cơ sở dữ liệu: nó giữ kết quả truy vấn trong RAM để ứng dụng khỏi phải hỏi lại database. Chỗ nó rút ngắn là độ trễ giữa ứng dụng và database, và cụm ElastiCache nằm trong VPC, trong một Region cụ thể. Người dùng ở nửa kia địa cầu vẫn phải vượt quãng đường mạng y hệt để tới được ứng dụng. Nó không có mặt ở Edge Location, nên không giải quyết được ràng buộc "globally distributed".

B — Amazon AppStream 2.0. Đây là dịch vụ streaming ứng dụng desktop tới máy người dùng — chạy ứng dụng trên hạ tầng AWS rồi truyền giao diện xuống trình duyệt. Nó thuộc nhóm end-user computing, hoàn toàn khác bài toán phân phối nội dung. Chọn nó là hiểu nhầm "streaming" thành "phân phối nội dung nhanh"; hai chuyện không liên quan.

D — Amazon ECS. Elastic Container Service dùng để chạy container Docker trên AWS. Nó là dịch vụ điều phối compute — quyết định container chạy ở đâu, bao nhiêu bản. Nó không làm gì để giảm khoảng cách mạng giữa người dùng toàn cầu và ứng dụng, cũng không cache nội dung ở biên. Việc bạn đóng gói ứng dụng bằng container hay bằng máy ảo không thay đổi độ trễ mà người dùng ở xa phải chịu.

Điểm chung của cả ba phương án sai: chúng đều hoạt động bên trong một Region, còn đề bài đang hỏi về vấn đề khoảng cách địa lý toàn cầu.

📌 Điểm cần nhớ

• Thấy từ khoá "global users", "worldwide", "distributed users" đi kèm yêu cầu giảm latency → nghĩ ngay tới nhóm dịch vụ Edge, mà đại diện quen thuộc nhất trong đề Cloud Practitioner là CloudFront.
• Phân biệt hai loại cache: CloudFront cache nội dung ở Edge Location cho người dùng cuối; ElastiCache cache dữ liệu in-memory cho ứng dụng đọc database. Cùng chữ "cache" nhưng khác tầng, khác mục đích, khác phạm vi địa lý.
• Cặp S3 + CloudFront (S3 làm origin, CloudFront làm CDN) là kiến trúc chuẩn để phục vụ nội dung tĩnh toàn cầu — gặp câu hỏi chọn hai đáp án về phân phối nội dung thì đây là cặp cần cân nhắc đầu tiên.
• ECS là compute (chạy container), AppStream 2.0 là streaming ứng dụng desktop. Cả hai đều không thuộc nhóm networking & content delivery, nên loại sớm để thu hẹp lựa chọn.

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

Đề hỏi: thông tin nào bắt buộc phải nhập vào AWS TCO Calculator?

Cụm từ quyết định là "must be entered" — tức là dữ liệu đầu vào mà công cụ yêu cầu người dùng khai báo, chứ không phải mọi thông tin liên quan đến hệ thống hiện tại. Cụm thứ hai cần chú ý là chính tên công cụ: TCO (Total Cost of Ownership) Calculator dùng để so sánh chi phí giữa môi trường on-premises / hosting truyền thống với AWS.

Muốn so sánh chi phí kiểu đó thì phải mô tả được hạ tầng đang chạy: bao nhiêu máy chủ (vật lý hoặc máy ảo), mỗi máy có bao nhiêu CPU, bao nhiêu RAM, là máy chạy database hay không. Đơn vị tính chi phí của TCO Calculator là server, chứ không phải người dùng cuối, không phải ứng dụng, cũng không phải "hệ thống lưu trữ".

Giữ chặt ý này thì bốn phương án tự phân loại ngay: chỉ có một phương án nói về đơn vị hạ tầng mà công cụ thực sự đếm.

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

D — The number of servers in your company.

TCO Calculator hỏi số lượng server đang chạy on-premises, gồm cả máy vật lý lẫn máy ảo. Sau khi khai số lượng, người dùng còn khai tiếp tài nguyên của từng server (CPU, RAM) và đánh dấu server đó là DB hay non-DB — vì máy chạy database sẽ được ánh xạ sang một dạng dịch vụ và mức chi phí khác với máy ứng dụng thông thường.

Từ mô tả cấu hình đó, công cụ dựng ra bảng so sánh chi phí chi tiết giữa môi trường hiện tại và AWS. Nói cách khác, server là đơn vị đầu vào gốc của phép tính — thiếu nó thì không có gì để quy đổi, nên đây chính là thông tin bắt buộc.

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

A — The number of storage systems in your company. Đây là phương án gần đúng nhất và cũng là cái dễ mắc bẫy nhất, vì storage rõ ràng có trong phép tính TCO. Chỗ nó hỏng nằm ở đơn vị: công cụ không hỏi bạn có bao nhiêu hệ thống lưu trữ (bao nhiêu tủ SAN, bao nhiêu NAS), mà hỏi dung lượng thô (raw capacity). Đếm số thiết bị lưu trữ không nói lên chi phí, còn dung lượng thì quy đổi thẳng sang chi phí storage trên AWS được. Đúng chủ đề, sai đại lượng.

B — The number of applications in your company. Không phải đầu vào của công cụ. TCO Calculator làm việc ở tầng hạ tầng, không ở tầng ứng dụng. Một ứng dụng có thể trải trên hàng chục server, và nhiều ứng dụng có thể dùng chung một server — nên số ứng dụng không ánh xạ được sang tài nguyên hay chi phí. Bạn mô tả server, công cụ tự suy ra chi phí; nó không cần biết những server đó phục vụ ứng dụng nào.

C — The number of end users in your company. Cũng không phải đầu vào. Số người dùng cuối là chỉ số nghiệp vụ, không phải chỉ số hạ tầng. Mô hình tính giá của AWS trong bối cảnh này dựa trên tài nguyên được cấp phát (compute, storage, network), không dựa trên đầu người theo kiểu license phần mềm tính theo user. Hai công ty cùng 1.000 nhân viên có thể có quy mô hạ tầng chênh nhau rất xa, nên con số này không đủ để tính ra thứ gì.

📌 Điểm cần nhớ

• AWS TCO Calculator so sánh chi phí on-premises / hosting truyền thống với AWS, và đơn vị đầu vào của nó là server — số lượng server, CPU, RAM, và server đó là DB hay non-DB.
• Với storage, công cụ quan tâm dung lượng thô, không quan tâm bạn có bao nhiêu thiết bị lưu trữ. Gặp phương án đếm "số hệ thống lưu trữ" thì nhớ rằng sai ở đơn vị đo, không phải sai chủ đề.
• Các chỉ số tầng nghiệp vụ (số ứng dụng, số người dùng cuối) không phải đầu vào của TCO Calculator — chi phí AWS gắn với tài nguyên hạ tầng được cấp phát, không gắn với đầu người.
• Mẹo làm bài chung cho nhóm câu về công cụ chi phí: hỏi "công cụ này quy đổi cái gì thành tiền?". Trả lời được câu đó là ra ngay đầu vào bắt buộc của nó.

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

Đề hỏi: loại backup tự động nào của Amazon RDS cho phép khôi phục database với độ mịn nhỏ tới 5 phút.

Cụm từ quyết định đáp án là "granularity of as little as 5 minutes" — độ mịn 5 phút. Đây chính là ràng buộc phân biệt bốn phương án, vì cả bốn đều là những khái niệm sao lưu quen thuộc, nhưng chỉ có một cơ chế trong RDS cho phép chọn một thời điểm bất kỳ để khôi phục về, thay vì chỉ khôi phục về đúng lúc bản sao lưu được tạo.

Cần chú ý thêm chữ "automated backup": RDS phân biệt bản sao lưu tự động (do RDS quản lý theo backup window, kèm transaction log) với snapshot thủ công do người dùng bấm tạo. Chính phần transaction log của automated backup mới sinh ra khả năng khôi phục theo mốc thời gian.

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

D. Point-in-time recovery là đáp án đúng.

Amazon RDS liên tục đẩy transaction log của database lên Amazon S3 song song với các bản sao lưu tự động. Khi khôi phục, RDS lấy bản sao lưu nền gần nhất rồi phát lại (replay) transaction log tới đúng mốc thời gian bạn chỉ định. Nhờ cơ chế log này, bạn không bị bó buộc vào những thời điểm rời rạc mà bản sao lưu được tạo — bạn chọn được một mốc rất gần thời điểm sự cố, với độ mịn nhỏ tới 5 phút như đề nêu.

Đây đúng là kịch bản kinh điển: ai đó chạy nhầm một câu DELETE lúc 14:32, bạn khôi phục database về 14:31 thay vì mất nguyên nửa ngày dữ liệu.

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

A. Full backup — Đây chỉ là mô tả chung về việc sao lưu toàn bộ database, thường do phần mềm backup thực hiện. Nó không phải là một loại "automated backup" mang tên riêng trong RDS, và quan trọng hơn: một bản full backup chỉ cho bạn khôi phục về đúng thời điểm nó được tạo ra. Không có transaction log đi kèm thì không có chuyện chọn mốc 5 phút.

B. Snapshot backup — Đây là phương án gần đúng nhất và dễ gây nhầm, vì snapshot thật sự là cơ chế sao lưu của RDS. Nhưng nó hỏng ở chỗ: snapshot là ảnh chụp trạng thái database tại một thời điểm cố định. Khôi phục từ snapshot nghĩa là quay về đúng lúc chụp, không sớm hơn không muộn hơn. Muốn có mốc 14:31 mà snapshot gần nhất chụp lúc 03:00 thì bạn mất toàn bộ dữ liệu trong khoảng đó. Snapshot là thành phần nền của point-in-time recovery, nhưng bản thân nó không cung cấp độ mịn 5 phút.

C. Incremental backup — Mô tả kỹ thuật sao lưu chỉ lấy phần dữ liệu đã thay đổi kể từ lần sao lưu trước. Đây là một thuộc tính về hiệu quả lưu trữ (tiết kiệm dung lượng và thời gian backup), không phải một thuộc tính về độ mịn khôi phục. Backup incremental chạy mỗi giờ thì bạn vẫn chỉ khôi phục được về các mốc mỗi giờ. Nhầm lẫn ở đây là gán cho "incremental" một khả năng mà thực chất do transaction log mang lại.

📌 Điểm cần nhớ

• Thấy đề nhắc "restore to a specific point in time" hay "granularity of 5 minutes" với RDS → nghĩ ngay tới point-in-time recovery, không phải snapshot.
• Điểm mấu chốt phân biệt: snapshot cho bạn các mốc rời rạc, transaction log cho bạn một dải liên tục. Point-in-time recovery = snapshot nền + replay transaction log.
• Automated backup trong RDS bao gồm cả transaction log; đó là lý do nó làm được point-in-time recovery, còn snapshot thủ công thì không.
• Đừng nhầm thuật ngữ mô tả cách sao lưu (full, incremental — nói về lượng dữ liệu chép đi) với thuật ngữ mô tả khả năng khôi phục (point-in-time — nói về việc chọn mốc thời gian nào).

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

Đề bài mô tả một công ty muốn "centrally configure and manage firewall rules across their AWS environment" — cấu hình và quản lý tập trung các luật tường lửa cho toàn bộ môi trường AWS. Câu hỏi yêu cầu chọn hai dịch vụ giúp áp dụng luật tường lửa một cách nhất quán trên nhiều VPC và nhiều account.

Cụm từ quyết định nằm ở hai chỗ, và phải đọc cả hai mới chọn đúng:

• "centrally … across VPCs and accounts" — loại ngay những dịch vụ chỉ bảo vệ một tài nguyên đơn lẻ, hoặc chỉ làm việc trong phạm vi một account.
• "firewall rules" — phải là dịch vụ tường lửa thật sự (hoặc lớp quản lý tường lửa), chứ không phải dịch vụ quét lỗ hổng hay dịch vụ chống DDoS.

Đây là kiểu câu rất hay gặp: các phương án đều nằm trong nhóm AWS Security, đều "liên quan tới bảo mật mạng", nhưng chỉ một tiêu chí duy nhất — quản lý tập trung nhiều account — mới phân loại được chúng.

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

Theo tệp, đáp án đúng là D — AWS Firewall Manager và E — AWS Network Firewall.

AWS Firewall Manager chính là dịch vụ sinh ra để trả lời đúng cụm "centrally configure and manage". Nó hoạt động ở tầng trên, gắn với AWS Organizations, cho phép định nghĩa chính sách bảo mật một lần rồi áp xuống toàn bộ account và tài nguyên trong tổ chức. Nó điều phối được luật của AWS WAF, AWS Shield Advanced và AWS Network Firewall — tức là bản thân nó là lớp quản lý tập trung, và các account mới tham gia tổ chức cũng được áp chính sách theo, nhờ đó có tính "nhất quán" mà đề bài đòi hỏi.

AWS Network Firewall là dịch vụ tường lửa mạng có quản lý (managed), triển khai bảo vệ ở mức mạng cho các Amazon VPC. Đề bài nói rõ phạm vi là VPC, và đây chính là dịch vụ đặt luật tường lửa ở tầng VPC. Kết hợp với Firewall Manager, luật của Network Firewall được rải đồng loạt ra nhiều VPC thay vì phải cấu hình thủ công từng cái.

Nói gọn: Firewall Manager là bộ điều khiển tập trung, Network Firewall là tường lửa được điều khiển ở tầng VPC. Cặp này khớp trọn vẹn với đề bài.

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

A — Amazon Inspector. Đây là dịch vụ đánh giá bảo mật tự động: tìm lỗ hổng đã biết và các sai lệch so với thực hành tốt trên workload (ví dụ EC2 instances). Nó báo cáo vấn đề chứ không đặt hay thực thi luật tường lửa nào. Sai ngay từ chữ "firewall rules" trong đề, chưa cần xét tới yếu tố tập trung.

B — AWS Web Application Firewall (AWS WAF). Đây là phương án gần đúng nhất và cũng là cái bẫy chính. WAF đúng là tường lửa thật (tầng ứng dụng, lọc HTTP/HTTPS), và nó có tích hợp với Firewall Manager. Nhưng chỗ hỏng là: WAF gắn với từng tài nguyên cụ thể (như CloudFront distribution, Application Load Balancer, API Gateway) trong phạm vi account của nó; tự thân nó không phải là giải pháp quản lý tập trung xuyên account và xuyên VPC. Chính Firewall Manager mới là thứ đứng trên để rải luật WAF ra nhiều nơi. Chọn B là nhầm "thứ được quản lý" với "thứ đi quản lý".

C — AWS Shield. Cũng là phương án gần đúng theo kiểu tương tự: Shield bảo vệ chống tấn công DDoS, và bản Shield Advanced có thể được điều phối qua Firewall Manager. Nhưng Shield là dịch vụ chống DDoS, không phải nơi bạn viết và quản lý bộ luật tường lửa; và giống WAF, bản thân nó không cung cấp khả năng cấu hình tập trung trên nhiều account và nhiều VPC.

📌 Điểm cần nhớ

• Thấy cụm "centrally manage across accounts" kèm chữ firewall trong đề AWS thì gần như chắc chắn phải có AWS Firewall Manager trong đáp án — đó là dịch vụ định nghĩa bằng chính khả năng đó, gắn với AWS Organizations.
• Phân biệt tầng của tường lửa: AWS WAF lọc lưu lượng web ở tầng ứng dụng cho từng tài nguyên; AWS Network Firewall đặt luật ở tầng mạng cho VPC. Đề nhắc "VPC" thì nghiêng về Network Firewall.
• Phân biệt "bị quản lý" và "đi quản lý": WAF, Shield Advanced, Network Firewall đều có thể nằm dưới quyền điều phối của Firewall Manager. Việc một dịch vụ tích hợp được với Firewall Manager không biến nó thành công cụ quản lý tập trung.
• Amazon Inspector thuộc nhóm phát hiện, không thuộc nhóm phòng vệ: nó tìm lỗ hổng và sai lệch cấu hình, không chặn lưu lượng. Gặp Inspector trong câu hỏi về "áp luật tường lửa" thì loại được ngay.

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

Đề hỏi: dịch vụ AWS nào thuộc nhóm "serverless" và chạy code dưới dạng function (runs code as functions).

Cụm từ quyết định nằm ở hai vế nối với nhau bằng "and", phải thoả cả hai:

1. "serverless" — người dùng không quản lý, không vá, không chọn kích thước máy chủ nào cả;
2. "runs code as functions" — đơn vị triển khai là một function, chứ không phải một container image hay một cụm máy.

Vế thứ hai là chỗ phân biệt sắc nhất. Ba phương án còn lại đều là dịch vụ có thật và đều liên quan tới việc đưa code lên chạy, nhưng không có cái nào lấy function làm đơn vị chạy. Đọc lướt chỉ thấy chữ "serverless" là dễ phân vân giữa các dịch vụ container; đọc kỹ vế "as functions" thì câu trả lời chỉ còn một.

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

A. AWS Lambda. Đây là dịch vụ compute serverless: bạn nộp lên đoạn code, AWS lo toàn bộ hạ tầng bên dưới — cấp phát tài nguyên, mở rộng theo lượng gọi, vá hệ điều hành. Bạn không tạo, không quản lý, không trả tiền cho một máy chủ nào đang chờ sẵn.

Quan trọng hơn cho câu này: đơn vị bạn triển khai lên Lambda được gọi đúng bằng tên "Lambda function". Code chạy để phản hồi sự kiện (event) — một object mới trong S3, một request qua API Gateway, một message trong hàng đợi — chứ không chạy thường trực. Đúng khít với cả hai vế của đề: serverless, và chạy code as functions.

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

B. Amazon ECS — Elastic Container Service, dịch vụ điều phối container (ví dụ container Docker). Đây là phương án gần đúng nhất và cũng là bẫy chính, vì ECS chạy được ở chế độ không phải quản lý máy chủ. Nhưng nó vẫn hỏng ở vế thứ hai của đề: thứ bạn đóng gói và triển khai lên ECS là một container image, đơn vị chạy là task/container, không phải function. Đề hỏi thẳng "runs code as functions", nên ECS bị loại bằng chính chữ đó.

C. Amazon EKS — Elastic Kubernetes Service, dịch vụ quản lý Kubernetes để chạy container. Sai vì cùng lý do với ECS, và còn xa đề hơn một bậc: mô hình làm việc ở đây là Kubernetes với pod, deployment, cụm (cluster) — bạn phải hiểu và vận hành cả một hệ điều phối. Đơn vị triển khai vẫn là container, không phải function.

D. AWS CodeCommit — dịch vụ quản lý mã nguồn được quản lý hoàn toàn, host các repository dựa trên Git một cách bảo mật. Nó là nơi cất giữ code, không phải nơi chạy code. Đây là phương án sai rõ rệt nhất: nó nằm ở nhóm developer tools, không thuộc nhóm compute. Chữ "code" trong tên dịch vụ dễ khiến người mới bị hút vào, nhưng lưu trữ code và thực thi code là hai việc hoàn toàn khác nhau.

📌 Điểm cần nhớ

• "Function" là từ khoá chỉ đích danh Lambda. Trong đề thi Cloud Practitioner, hễ thấy "runs code as functions", "run code without provisioning servers", hay "chạy code theo sự kiện" thì gần như chắc chắn đáp án là AWS Lambda.
• Function ≠ container. ECS và EKS đều là dịch vụ chạy container: ECS là bộ điều phối riêng của AWS, EKS là Kubernetes được quản lý. Chúng cùng nhóm compute với Lambda nhưng khác đơn vị triển khai — đây là ranh giới hay bị dùng để ra bẫy.
• Đọc đủ mọi ràng buộc trong đề, đừng dừng ở từ khoá đầu tiên. Chỉ dựa vào chữ "serverless" là còn nhiều phương án hợp lý; thêm vế "as functions" mới cắt xuống còn đúng một.
• Phân biệt dịch vụ chứa code với dịch vụ chạy code. CodeCommit thuộc nhóm quản lý mã nguồn (Git repository), không hề thực thi code — tên có chữ "Code" không có nghĩa nó là dịch vụ compute.