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

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

Đề hỏi: mô hình giá EC2 nào tiết kiệm chi phí nhất cho một database server phục vụ dự án kéo dài 1 năm.

Ba cụm từ trong đề quyết định đáp án, và phải đọc cả ba mới loại hết được:

• "always-up" — máy chạy liên tục, không tắt, không co giãn theo giờ. Đây là điều kiện lý tưởng để cam kết dài hạn, vì mọi giờ đã trả trước đều được dùng hết.
• "right-sized" — instance đã được chọn đúng kích thước rồi, tức là không cần đổi họ instance, đổi OS hay đổi tenancy về sau. Đây chính là cụm từ dùng để tách A khỏi B.
• "will last 1 year" — thời hạn dự án khớp đúng với kỳ hạn cam kết của Reserved Instance (1 hoặc 3 năm), nên cam kết 1 năm không bị lãng phí phần cuối.

Thiếu bất kỳ cụm nào thì đáp án sẽ khác: nếu tải chạy phập phù → On-Demand; nếu công việc gián đoạn được → Spot; nếu kích thước còn phải thay đổi → Convertible.

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

B — Standard Reserved Instances.

Reserved Instances cho mức giảm giá đáng kể so với On-Demand để đổi lấy cam kết sử dụng theo kỳ hạn 1 hoặc 3 năm. Trong hai loại RI thì Standard RI cho mức tiết kiệm sâu nhất — bạn từ bỏ quyền linh hoạt đổi cấu hình để lấy giá tốt hơn.

Bài toán ở đây khớp hoàn hảo: database server chạy 24/7 nên tận dụng được toàn bộ giờ đã cam kết; đã right-sized nên không cần quyền đổi họ instance; dự án dài đúng 1 năm nên chọn kỳ hạn 1 năm là vừa khít, không trả tiền cho khoảng thời gian không dùng. Trong bốn phương án, đây là mô hình duy nhất vừa rẻ hơn On-Demand vừa đảm bảo máy không bị lấy đi giữa chừng.

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

A — Convertible Reserved Instances. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Convertible RI cũng là cam kết 1 hoặc 3 năm, cũng giảm giá so với On-Demand, nên nó thoả điều kiện "always-up" và "1 year". Điểm hỏng nằm ở chỗ: quyền linh hoạt đổi instance family, OS type và tenancy trong kỳ hạn không phải miễn phí — nó được đánh đổi bằng mức giảm giá thấp hơn Standard RI. Đề đã nói rõ server right-sized, tức là bạn không có nhu cầu đổi gì cả. Trả thêm tiền cho một quyền không dùng đến thì không còn là "most cost-effective" nữa.

C — On-Demand Instances. On-Demand không có giảm giá nào, đó là mức giá gốc theo giờ/giây. Ưu điểm của nó là không cam kết — phù hợp khi tải khó đoán, ngắn hạn hoặc đang thử nghiệm. Ở đây tải đã biết chắc là chạy liên tục suốt 1 năm, nên sự linh hoạt "muốn tắt lúc nào cũng được" hoàn toàn vô dụng, trong khi cái giá phải trả là đắt nhất trong nhóm các lựa chọn khả thi.

D — Spot Instances. Spot rẻ hơn cả RI nếu chỉ nhìn đơn giá, nên rất dễ bị chọn khi đọc lướt chữ "most cost-effective". Nhưng Spot dùng dung lượng dư của AWS, và AWS có thể thu hồi instance khi cần dung lượng lại, kèm cảnh báo rất ngắn. Đề yêu cầu always-up cho một database server — loại workload có trạng thái, bị gián đoạn là mất kết nối và có nguy cơ hỏng dữ liệu. Spot chỉ hợp với công việc chịu được gián đoạn: xử lý theo lô, render, worker phân tán có thể chạy lại. Rẻ mà không đáp ứng được yêu cầu thì không phải câu trả lời.

📌 Điểm cần nhớ

• Bốn mô hình giá EC2 tách nhau bằng hai câu hỏi: workload có chạy liên tục và đoán trước được không (→ Reserved), và có chịu được gián đoạn không (→ Spot). Trả lời hai câu này trước khi so đơn giá.
• "Right-sized" là từ khoá loại Convertible RI. Convertible chỉ đáng tiền khi đề nói rõ có khả năng phải đổi instance family, OS hoặc tenancy trong kỳ hạn. Không có tín hiệu đó thì Standard RI luôn tiết kiệm hơn.
• Spot rẻ nhất nhưng bị loại ngay khi đề nói "always-up", "production database", "stateful" hay "cannot be interrupted". Đừng để đơn giá thấp che mất ràng buộc về tính sẵn sàng.
• On-Demand là mốc giá gốc, không giảm giá — nó chỉ thắng khi đề nhấn mạnh tải ngắn hạn, thất thường, hoặc không thể cam kết trước.
• Kỳ hạn dự án phải khớp kỳ hạn cam kết: đề ghi 1 năm thì chọn RI kỳ hạn 1 năm; nếu đề nói dự án chỉ vài tuần thì mọi loại RI đều sai vì phần cam kết thừa là tiền bỏ đi.

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

Đề mô tả một tổ chức vừa chuyển vài máy chủ lên AWS và không rõ mình còn phải tự quản lý những gì. Câu hỏi chốt lại: chi phí nào là trách nhiệm trực tiếp của công ty (the company's direct responsibility)?

Cụm từ quyết định là "direct responsibility" đặt cạnh bối cảnh migrated several servers into AWS. Ở đây có hai lớp cần tách bạch theo Shared Responsibility Model:

• AWS chịu trách nhiệm of the cloud — phần hạ tầng vật lý: nhà máy điện, làm mát, an ninh vật lý data center, phần cứng máy chủ, mạng lõi.
• Khách hàng chịu trách nhiệm in the cloud — mọi thứ khách hàng đặt lên trên: hệ điều hành khách (với EC2), ứng dụng, dữ liệu, cấu hình, và bản quyền phần mềm mà họ mang lên chạy.

Chỉ cần hỏi "khoản chi này nằm ở lớp hạ tầng hay lớp ứng dụng?" là ba trên bốn phương án tự loại.

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

A — Cost of application software licenses.

Bản giải thích nguồn nói rõ: chi phí bản quyền cho ứng dụng vẫn thuộc về khách hàng, vì AWS chỉ lo phần hạ tầng mà ứng dụng chạy trên đó. Lớp ứng dụng do khách hàng quản lý hoàn toàn — không phải AWS.

Điều này rất hợp với bối cảnh "migrated several servers": khi bê máy chủ lên EC2, công ty mang theo cả stack phần mềm của mình — database engine thương mại, middleware, ứng dụng nghiệp vụ. AWS không hề biết bên trong instance đang chạy phần mềm gì, nên cũng không thể chịu chi phí license cho nó. Đây là khoản chi công ty phải trực tiếp trả và trực tiếp quản lý (theo dõi số license, tuân thủ điều khoản nhà cung cấp phần mềm).

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

B — Cost of physical security for the AWS data center. An ninh vật lý của data center là ví dụ kinh điển của security of the cloud — phần AWS chịu. Khách hàng không được vào data center, không chọn được nhà thầu bảo vệ, không quyết định quy trình kiểm soát ra vào. Không kiểm soát thì cũng không chịu chi phí trực tiếp. Đây là phương án dễ gây phân vân nhất vì có chữ "security", mà "security" là từ khách hàng cũng có phần — nhưng phần của khách hàng là security in the cloud (IAM, mã hoá, security group, vá lỗi OS), không phải hàng rào và camera ở data center.

C — Cost of power for the AWS servers. Điện cấp cho máy chủ AWS thuộc hạ tầng vật lý. Bản giải thích nguồn nói thẳng: AWS lo hạ tầng vật lý, khách hàng không có tiếng nói nào trong việc nó được vận hành ra sao. Khách hàng trả tiền theo giờ chạy instance hoặc theo lượng tài nguyên tiêu thụ — tiền điện đã nằm sẵn trong giá dịch vụ đó, chứ không phải một khoản công ty tự quản lý và tự trả cho công ty điện lực. Đề hỏi trách nhiệm trực tiếp, nên "gián tiếp trả qua giá dịch vụ" không tính.

D — Cost of the hardware infrastructure on AWS. Bản giải thích nguồn gọi đây là khoản nằm hẳn về phía AWS trong Shared Responsibility Model. Chính lý do người ta lên cloud là để khỏi mua và thay thế phần cứng: máy chủ, ổ đĩa, thiết bị mạng đều do AWS mua sắm, bảo trì và thay khi hỏng. Phương án này còn dễ bẫy vì có chữ "on AWS" nghe như "cái mà tôi đang dùng trên AWS" — nhưng "hardware infrastructure" là tài sản vật lý của AWS, không phải của khách hàng.

📌 Điểm cần nhớ

• Khẩu quyết phân loại nhanh: AWS lo security of the cloud, khách hàng lo security in the cloud. Điện, làm cứng nhà xưởng, an ninh vật lý, phần cứng → AWS. Ứng dụng, dữ liệu, cấu hình, license → khách hàng.
• Không kiểm soát được thì không chịu trách nhiệm. Khách hàng không được vào data center, không chọn nguồn điện — nên mọi phương án nói về data center vật lý gần như luôn là đáp án sai trong dạng câu này.
• Chi phí trả gián tiếp qua giá dịch vụ ≠ trách nhiệm trực tiếp. Điện và phần cứng đã được tính vào giá EC2; đề hỏi "direct responsibility" nên chúng bị loại.
• Với câu hỏi dạng "migrate máy chủ lên cloud rồi còn phải tự lo gì", hãy nghĩ theo lớp: càng lên cao (OS khách → runtime → ứng dụng → dữ liệu) càng thuộc về khách hàng. Software license luôn nằm ở lớp trên cùng, nên luôn là của khách hàng.

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

Đề đặt ra tình huống: một manager đang lên kế hoạch migrate ứng dụng lên AWS Cloud và cần lấy các báo cáo tuân thủ (compliance reports) của AWS. Câu hỏi là: những báo cáo này được lấy ra bằng cách nào?

Cụm từ quyết định nằm ở chính đối tượng cần lấy: "AWS compliance reports" — tức là báo cáo do chính AWS phát hành về hạ tầng của họ (SOC, PCI, các chứng nhận từ tổ chức kiểm định), chứ không phải báo cáo về workload của khách hàng. Cụm thứ hai đáng chú ý là "How can these reports be generated" — đề hỏi cơ chế lấy báo cáo, và mấu chốt phân biệt các phương án là: đây là thứ tự tải về được ngay (self-service, on-demand), hay là thứ phải liên hệ người của AWS mới có.

Nắm được hai điểm đó thì bốn phương án tách làm hai nhóm rất rõ: hai phương án "hỏi người AWS" (A, D) và hai phương án "tải từ một dịch vụ" (B, C). Việc còn lại chỉ là biết dịch vụ nào chứa compliance report.

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

C — Download the reports from AWS Artifact.

AWS Artifact là nơi tập trung mọi thông tin liên quan đến compliance mà khách hàng cần, cung cấp truy cập on-demand tới các báo cáo bảo mật và tuân thủ của AWS cùng một số thỏa thuận pháp lý trực tuyến.

Những gì có trong AWS Artifact:

• Báo cáo: Service Organization Control (SOC), Payment Card Industry (PCI), và các chứng nhận từ những tổ chức kiểm định (accreditation bodies) ở 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 security control của AWS đã được triển khai và vận hành hiệu quả.
• Thỏa thuận: Business Associate Addendum (BAA) và Nondisclosure Agreement (NDA).

Đúng với tình huống trong đề: manager chỉ cần vào AWS Artifact và tải báo cáo về, không cần chờ ai xử lý yêu cầu.

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

A — Create a support ticket with AWS Support. Đây là phương án "gần đúng theo trực giác": mở ticket là cách hợp lý để xin nhiều thứ khác từ AWS. Nhưng nó hỏng ở chỗ compliance report không cần ai ở AWS can thiệp — thông tin này đã được đưa sẵn ở dạng self-service để tải trực tiếp. Mở ticket là đi vòng cho một việc vốn không cần trung gian.

B — Download the reports from AWS Secrets Manager. Phương án này bắt đúng nửa đầu ("download the reports") nên trông cũng có lý, nhưng chọn sai dịch vụ. AWS Secrets Manager dùng để lưu trữ secret — thông tin xác thực database, license code và các bí mật tương tự. Nó không phải nơi chứa báo cáo tuân thủ. Tên có chữ "Secrets" khiến nhiều người liên tưởng tới "tài liệu nhạy cảm", nhưng đó là hai thứ hoàn toàn khác nhau.

D — Contact the AWS Compliance team. Sai theo đúng lý do của phương án A: không cần liên hệ với ai ở AWS cả, thông tin này tải xuống được trực tiếp. Về mặt kiến thức thi cử, đây là dạng "phương án nghe rất đúng nghiệp vụ" — nghe như quy trình chuẩn của một tổ chức lớn — nhưng lại mâu thuẫn với bản chất self-service của AWS Artifact.

📌 Điểm cần nhớ

• AWS Artifact = nơi tự tải compliance report và agreement của AWS. Thấy đề nhắc "compliance report", "SOC", "PCI", "ISO certification", "BAA", "NDA" thì gần như luôn là AWS Artifact.
• Phân biệt theo tên dịch vụ, đừng đoán theo từ khóa gợi cảm giác: AWS Secrets Manager quản lý credential/secret, không quản lý tài liệu tuân thủ.
• Các phương án kiểu "mở ticket" hay "liên hệ team X của AWS" thường là mồi nhử khi tồn tại một dịch vụ self-service làm đúng việc đó. AWS thiết kế theo hướng khách hàng tự phục vụ.
• Compliance report trong Artifact là báo cáo về hạ tầng của AWS — phần "AWS chịu trách nhiệm" trong shared responsibility model — dùng để đưa cho auditor khi migrate workload lên cloud.

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

Đề hỏi: dịch vụ nào có thể dùng để di chuyển exabyte dữ liệu vào AWS một cách tiết kiệm chi phí.

Cụm từ quyết định đáp án là "exabytes of data" — chính con số quy mô này phân biệt các phương án gần giống nhau. Trong họ dịch vụ truyền dữ liệu của AWS, mỗi dịch vụ được định vị theo một bậc dung lượng khác nhau, và AWS đặt tên bậc đó ngay trong mô tả sản phẩm: có dịch vụ ở mức terabyte/petabyte, có dịch vụ ở mức exabyte. Ngoài ra còn hai cụm phụ cũng lọc bớt phương án: "into AWS" (đưa dữ liệu từ ngoài vào AWS, chứ không phải copy giữa các nơi đã nằm sẵn trong AWS) và "cost-effectively" (loại các cách truyền qua đường mạng Internet, vốn vừa chậm vừa đắt ở quy mô này).

Gặp câu dạng này, thao tác đúng là đọc con số dung lượng trước, rồi mới ghép với dịch vụ tương ứng.

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

Đáp án đúng theo tệp là D — AWS Snowmobile.

AWS Snowmobile là dịch vụ truyền dữ liệu ở quy mô exabyte — chính AWS gọi nó là "Exabyte-scale data transfer service". Đây là một container vận chuyển kéo bằng xe đầu kéo, mỗi Snowmobile chở được khối lượng dữ liệu ở bậc hàng trăm petabyte, nên nhiều Snowmobile ghép lại mới đạt tới mức exabyte mà đề nêu.

Cách làm là dữ liệu được ghi vào thiết bị tại chỗ của khách hàng rồi vận chuyển vật lý về AWS để nạp vào S3 — không phải đẩy qua đường truyền Internet. Đó cũng là lý do nó đáp ứng được yêu cầu cost-effectively: ở quy mô exabyte, chi phí và thời gian của đường truyền mạng trở nên không thực tế, còn chuyển vật lý thì thời gian phụ thuộc chủ yếu vào quãng đường vận chuyển chứ không phụ thuộc băng thông.

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

C — AWS Snowball (phương án gần đúng nhất): cùng họ dịch vụ, cùng nguyên lý chuyển dữ liệu bằng thiết bị vật lý, nên nó thoả được vế "into AWS" và "cost-effective". Chỗ hỏng nằm đúng ở quy mô: Snowball là thiết bị mang dung lượng ở bậc terabyte, và AWS định vị nó là "petabyte-scale data transfer service". Muốn chuyển exabyte bằng Snowball thì phải dùng một số lượng thiết bị lớn tới mức phi lý về vận hành. Snowball là câu trả lời đúng khi đề ghi terabyte hoặc petabyte — không phải exabyte.

B — S3 Transfer Acceleration: đây là tính năng tăng tốc upload lên Amazon S3 qua Internet, bằng cách cho client đi vào edge location gần nhất của CloudFront rồi đi tiếp trên mạng nội bộ AWS. Nó cải thiện tốc độ cho truyền tải đường dài, nhưng vẫn là truyền qua mạng — hoàn toàn không phù hợp với khối lượng exabyte, cả về thời gian lẫn chi phí đường truyền. Nó giải bài toán "độ trễ khi upload từ xa", không giải bài toán "khối lượng khổng lồ".

A — S3 Cross-Region Replication (CRR): sai ở hai điểm. Thứ nhất, sai về hướng dữ liệu — CRR sao chép object giữa các bucket S3 ở hai region khác nhau, tức là dữ liệu đã nằm trong AWS rồi, trong khi đề yêu cầu đưa dữ liệu vào AWS từ bên ngoài. Thứ hai, nó cũng không phải công cụ để dịch chuyển một khối dữ liệu exabyte; CRR là cơ chế nhân bản phục vụ dự phòng và đưa dữ liệu tới gần người dùng, không phải dịch vụ migration ban đầu.

📌 Điểm cần nhớ

• Nhớ theo bậc dung lượng mà AWS tự đặt cho từng dịch vụ: Snowball được mô tả ở mức petabyte-scale, Snowmobile ở mức exabyte-scale. Đề nêu đơn vị nào thì chọn dịch vụ mang đúng nhãn đó.
• Hễ đề nhấn "cost-effectively" kèm khối lượng rất lớn, đó là tín hiệu loại các phương án truyền qua mạng và chọn phương án vận chuyển vật lý.
• Phân biệt "đưa dữ liệu vào AWS" với "sao chép dữ liệu trong AWS": S3 Cross-Region Replication thuộc vế thứ hai, nên gần như luôn sai ở các câu hỏi về migration ban đầu.
• S3 Transfer Acceleration là công cụ tăng tốc upload đường dài qua edge location của CloudFront — chọn nó khi đề nói về độ trễ hoặc khoảng cách địa lý, không phải khi đề nói về khối lượng khổng lồ.

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

Đề hỏi: "Which AWS tools can be used for automation? (Select TWO.)" — công cụ AWS nào dùng để tự động hoá.

Cụm từ quyết định là "automation" (tự động hoá), và ràng buộc đi kèm là "tools" — tức là công cụ điều phối, dựng và triển khai thay cho thao tác tay, chứ không phải một tài nguyên hạ tầng đơn lẻ mà bạn dùng để chạy workload.

Đây là kiểu câu rất dễ trượt vì ở mức Cloud Practitioner, người học hay hiểu "automation" theo nghĩa rộng — "cái gì chạy tự động thì là automation". Với cách hiểu đó thì Lambda (chạy code tự động khi có sự kiện), ELB (tự động phân phối kết nối), thậm chí EFS (tự động co giãn dung lượng) đều có vẻ hợp lệ. Nhưng đề đang phân loại dịch vụ theo vai trò chính thức của nó trong AWS, và ở góc nhìn đó, "automation" nghĩa là tự động hoá việc dựng và quản lý hạ tầng/ứng dụng. Nắm được cách đọc này là chọn đúng ngay.

Ngoài ra, chữ "(Select TWO)" cũng là một tín hiệu: phải có đúng hai phương án cùng thuộc chung một nhóm khái niệm, ba phương án còn lại thuộc các nhóm khác hẳn nhau (compute, storage, networking).

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

Đáp án theo tệp là C — AWS CloudFormation và D — AWS Elastic Beanstalk.

AWS CloudFormation là dịch vụ Infrastructure as Code: bạn mô tả toàn bộ kiến trúc trong một template, CloudFormation tự dựng, cập nhật và gỡ bỏ các tài nguyên theo đúng mô tả đó. Đây chính là định nghĩa gốc của automation trong AWS — thay vì bấm tay từng bước trong console để tạo VPC, EC2, security group, bạn khai một lần rồi để dịch vụ tự làm, và làm lại y hệt bao nhiêu lần cũng được.

AWS Elastic Beanstalk cũng là automation, nhưng ở mức cao hơn: bạn chỉ đưa mã ứng dụng lên, Beanstalk tự lo phần provisioning và cấu hình hạ tầng bên dưới. Điểm mấu chốt mà giải thích gốc nêu rõ: Beanstalk vận dụng chính khả năng tự động hoá của CloudFormation để dựng kiến trúc ứng dụng. Hai dịch vụ này vì thế có quan hệ thẳng hàng với nhau — cùng một họ automation, khác nhau ở mức trừu tượng.

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

A — AWS Lambda. Đây là phương án gần đúng nhất và cũng gây tranh cãi nhiều nhất, vì trong thực tế người ta rất hay dùng Lambda để viết script tự động hoá theo sự kiện. Nhưng nó hỏng ở chỗ phân loại: Lambda được AWS xếp vào nhóm compute — nó là nơi chạy code không cần quản lý máy chủ. Bản thân Lambda không dựng hạ tầng cho bạn; nó chỉ thực thi đoạn code bạn viết. Câu hỏi đang hỏi công cụ dành cho automation, và theo giải thích gốc, Lambda là compute service chứ không phải automation service.

B — Amazon Elastic File System (EFS). Đây đơn giản là một file system — hệ thống tệp chia sẻ, dùng chung được cho nhiều EC2 instance. Nó là nơi chứa dữ liệu, hoàn toàn không liên quan tới việc dựng hay điều phối hạ tầng. Phương án này bị loại dễ nhất trong cả năm.

E — Elastic Load Balancing. ELB phân phối kết nối đến cho các Amazon EC2 instance phía sau. Có thể nó "tự động" theo nghĩa bạn không phải chia lưu lượng bằng tay, nhưng đó là load balancing, một chức năng networking, chứ không phải automation. Giải thích gốc nói thẳng: "This is not an example of automation; it is load balancing."

📌 Điểm cần nhớ

• Trong đề thi AWS, "automation" gần như luôn trỏ tới nhóm dịch vụ dựng và quản lý hạ tầng/ứng dụng — CloudFormation và Elastic Beanstalk là hai cái tên kinh điển của nhóm này.
• CloudFormation là nền, Elastic Beanstalk là lớp phủ lên trên nó. Beanstalk dùng chính CloudFormation để dựng kiến trúc, nên hai dịch vụ này thường xuất hiện cùng nhau trong một câu hỏi.
• Đừng lẫn "chạy tự động" với "dịch vụ automation". Lambda và ELB đều hoạt động mà không cần bạn can thiệp, nhưng chúng được phân loại là compute và networking. Câu hỏi loại này chấm theo danh mục dịch vụ, không theo cảm nhận về mức độ tự động.
• Với câu "(Select TWO)", hãy tìm hai phương án cùng một nhóm khái niệm. Nếu các lựa chọn còn lại rơi vào những nhóm khác hẳn nhau (storage, compute, networking), khả năng cao chúng là nhiễu.

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

Đề bài đặt ra một bối cảnh rất cụ thể: một công ty muốn nối trung tâm dữ liệu on-premises của họ vào AWS Cloud, và yêu cầu "consistent bandwidth and performance" — băng thông và hiệu năng ổn định, đều đặn.

Cụm từ quyết định đáp án ở đây là "consistent bandwidth and performance", đi kèm ngữ cảnh "connect their on-premises data center to the AWS Cloud". Hai mảnh này phải đọc chung với nhau:

• Mảnh thứ nhất ("connect on-premises data center to AWS") loại ngay những dịch vụ không thuộc nhóm kết nối lai (hybrid connectivity).
• Mảnh thứ hai ("consistent") mới là ràng buộc phân biệt tinh tế: nó tách một đường kết nối chuyên dụng, riêng biệt khỏi một đường kết nối đi qua Internet công cộng. Nếu đề chỉ nói "kết nối riêng tư, được mã hoá" thì đáp án đã có thể khác; nhưng chữ consistent nói về chất lượng đường truyền có thể dự đoán được, chứ không phải về tính riêng tư.

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

Đáp án đúng là A — AWS Direct Connect.

Direct Connect là dịch vụ thiết lập một đường kết nối mạng chuyên dụng (dedicated network connection) từ cơ sở của khách hàng — data center, văn phòng, hay môi trường colocation — vào AWS. Kết nối này không đi qua Internet công cộng, mà chạy trên đường vật lý riêng qua một Direct Connect location.

Vì lưu lượng không phải chen chúc với phần còn lại của Internet, nó tránh được đúng những thứ làm hiệu năng dao động: nghẽn cổ chai ở các nhà mạng trung gian, độ trễ thay đổi theo giờ, đường đi (route) thay đổi bất thường. Kết quả là thông lượng cao hơn và trải nghiệm mạng nhất quán hơn so với kết nối dựa trên Internet — đúng chữ consistent mà đề yêu cầu. Ngoài ra, với lưu lượng lớn và đều, Direct Connect thường còn giúp giảm chi phí truyền dữ liệu ra ngoài.

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

B — Amazon Connect: đây là cái bẫy đặt tên. Tên nghe rất giống Direct Connect, nhưng Amazon Connect là giải pháp contact center / tổng đài chăm sóc khách hàng trên cloud, hoàn toàn không phải công nghệ mạng. Nó không nối data center nào vào VPC cả. Gặp cặp "Direct Connect" và "Amazon Connect" trong cùng một danh sách thì gần như chắc chắn Amazon Connect chỉ là mồi nhử.

C — Amazon CloudFront: đây là CDN, dùng để cache và phân phối nội dung tới người dùng cuối từ các edge location đặt gần họ. CloudFront tối ưu chiều AWS → người dùng Internet, chứ không phải chiều data center của công ty → AWS. Nó cũng không tạo ra đường kết nối riêng tới hạ tầng on-premises. Sai cả về mục đích lẫn về hướng lưu lượng.

D — AWS VPN: đây là phương án gần đúng nhất, và cần nói rõ nó hỏng ở đâu. VPN đúng là một dịch vụ kết nối lai — nó nối được on-premises vào VPC, và còn cung cấp đường hầm được mã hoá, riêng tư về mặt logic. Nếu đề hỏi "kết nối riêng tư, mã hoá, dựng nhanh, chi phí thấp" thì VPN sẽ là đáp án. Nhưng VPN chạy trên nền Internet công cộng. Đường đi thực tế vẫn qua các nhà mạng trung gian, nên băng thông và độ trễ phụ thuộc vào tình trạng Internet tại thời điểm đó — không cam kết được sự nhất quán. Đúng chữ consistent trong đề là thứ loại VPN ra.

📌 Điểm cần nhớ

• "Consistent / predictable / dedicated bandwidth" → Direct Connect. Đây là từ khoá nhận diện gần như tuyệt đối trong đề thi. Ngược lại, "encrypted / quick to set up / low cost" thường trỏ về AWS VPN.
• Direct Connect và AWS VPN cùng nhóm hybrid connectivity, khác nhau ở đường vật lý: một bên là link chuyên dụng, một bên đi qua Internet công cộng. Mã hoá và tính nhất quán là hai thuộc tính khác nhau — đừng gộp làm một.
• Amazon Connect ≠ AWS Direct Connect. Amazon Connect là contact center. Đọc kỹ tiền tố "Amazon" hay "AWS" và cả cụm tên, đừng nhìn lướt chữ "Connect".
• CloudFront phục vụ chiều đi ra người dùng cuối (cache nội dung ở edge), không phải chiều nối hạ tầng on-premises vào cloud. Khi đề nói về data center của công ty, CDN gần như luôn nằm ngoài phạm vi.

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

Đề hỏi: những dịch vụ AWS nào gắn với Edge Locations? — và yêu cầu chọn hai phương án (Select TWO).

Cụm từ quyết định là "Edge Locations". Đây không phải Region cũng không phải Availability Zone, mà là mạng lưới điểm hiện diện (PoP) trải khắp thế giới, đặt gần người dùng cuối. Vì vậy câu hỏi thực chất là: dịch vụ nào chạy tại tầng biên (edge), chứ không phải trong Region?

Cách sàng lọc rất gọn: đọc từng phương án và tự hỏi "dịch vụ này chạy ở đâu?". Nếu nó là dịch vụ lưu trữ gắn với một AZ, hay dịch vụ quản trị/giám sát trong Region, hay dịch vụ kết nối tại một điểm cố định giữa data center của bạn và AWS — thì nó không thuộc Edge Locations.

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

D. Amazon CloudFront — CloudFront chính là CDN của AWS, và Edge Locations là hạ tầng của CloudFront. Nội dung được cache tại các điểm biên này để đưa dữ liệu tới gần người dùng cuối hơn, giảm độ trễ và cải thiện hiệu năng. Nói tới Edge Location mà không nhắc CloudFront là thiếu — hai khái niệm gắn liền nhau.

E. AWS Shield — Shield là dịch vụ chống tấn công DDoS, và nó hoạt động trên chính các Edge Locations của CloudFront, ở phạm vi toàn cầu. Đặt lớp phòng thủ ở biên là hợp lý về nguyên lý: lưu lượng tấn công bị hấp thụ và lọc ngay tại điểm gần nguồn phát, thay vì để nó dồn hết vào hạ tầng trong Region. Đó là lý do Shield được xếp vào nhóm dịch vụ edge.

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

A. Amazon EBS — EBS là dịch vụ lưu trữ khối gắn vào EC2 instance. Volume EBS nằm trong một Availability Zone cụ thể và chỉ dùng được bởi instance trong cùng AZ đó. Nó là dịch vụ "sâu trong Region" nhất trong cả danh sách — hoàn toàn không liên quan gì tới mạng biên.

B. AWS Config — Config là dịch vụ quản trị/tuân thủ: nó ghi lại và đánh giá trạng thái cấu hình của tài nguyên AWS theo thời gian, phát hiện thay đổi và kiểm tra tài nguyên có tuân thủ quy tắc không. Đây là công cụ governance chạy trong Region, không phục vụ lưu lượng người dùng cuối nên không có vai trò gì tại Edge Location.

C. AWS Direct Connect — Đây là phương án dễ nhầm nhất, vì Direct Connect cũng là dịch vụ networking và cũng có "điểm hiện diện vật lý" phân tán về mặt địa lý. Nhưng nó là dịch vụ kết nối hybrid: tạo đường truyền riêng, chuyên dụng từ data center on-premises của bạn tới AWS Cloud, không đi qua Internet công cộng. Vị trí vật lý của nó là Direct Connect location — một khái niệm khác hẳn Edge Location. Direct Connect phục vụ một khách hàng nối vào hạ tầng của họ, còn Edge Location phục vụ người dùng cuối trên toàn cầu truy cập nội dung. Cùng là "điểm phân tán" nhưng mục đích và cơ chế khác nhau, nên chọn C là rơi đúng bẫy của câu hỏi.

📌 Điểm cần nhớ

• Edge Location = hạ tầng của CloudFront. Thấy "Edge Location" trong đề thì CloudFront gần như chắc chắn nằm trong đáp án.
• AWS Shield chạy tại biên, cùng chỗ với CloudFront — đây là cặp đôi kinh điển của câu hỏi kiểu này. Phòng thủ DDoS đặt ở biên để chặn lưu lượng xấu trước khi nó chạm tới Region.
• Đừng nhầm Direct Connect location với Edge Location. Direct Connect là kết nối riêng cho mô hình hybrid (on-premises ↔ AWS); Edge Location là điểm phân phối nội dung cho người dùng cuối.
• Phân loại dịch vụ theo phạm vi hoạt động là mẹo làm bài nhanh ở mức Cloud Practitioner: gắn với AZ (EBS), gắn với Region (AWS Config), hay toàn cầu tại biên (CloudFront, Shield). Xác định được phạm vi là loại được phần lớn phương án sai mà không cần nhớ chi tiết từng dịch vụ.

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

Đề hỏi: lợi ích của việc chuyển một database on-premises sang Amazon RDS là gì.

Cụm từ quyết định nằm ở chính bản chất của RDS: đây là managed service — AWS lo phần hạ tầng bên dưới, còn khách hàng lo phần dữ liệu bên trên. Cả bốn phương án đều mô tả một dạng "đỡ việc" hoặc "linh hoạt hơn", nên phải đọc kỹ xem ranh giới trách nhiệm giữa AWS và khách hàng nằm ở đâu.

Điểm phân biệt là mấy chữ tuyệt đối trong các phương án: "any" (bất kỳ engine nào), "without downtime" (không gián đoạn), "no database administration required" (không cần quản trị database gì cả). Với managed service, AWS gỡ đúng một lớp trách nhiệm — lớp hệ điều hành và hạ tầng — chứ không gỡ hết mọi thứ. Phương án nào phóng đại quá ranh giới đó thì sai.

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

Đáp án đúng là C — "There is no need to manage operating systems".

RDS là managed service: AWS chịu trách nhiệm cài đặt, vá lỗi, nâng cấp và bảo trì hệ điều hành chạy bên dưới database engine, cũng như phần cứng, mạng và cơ sở vật chất. Khách hàng không có quyền truy cập vào OS đó và cũng không cần đụng tới nó.

Đây chính là khác biệt lớn nhất so với chạy database on-premises (hoặc tự cài database trên EC2), nơi bạn phải tự vá OS, tự lo bản cập nhật bảo mật, tự xử lý sự cố phần cứng. Bỏ được gánh nặng đó là lý do câu hỏi mô tả bằng chữ benefit — nó cắt trực tiếp chi phí vận hành.

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

A — "You can run any database engine": RDS chỉ hỗ trợ một danh sách engine cố định — MySQL, Microsoft SQL Server, MariaDB, Oracle, PostgreSQL và Aurora. Chữ any làm phương án này sai. Nếu bạn cần một engine ngoài danh sách đó, RDS không phục vụ được.

B — "You can scale vertically without downtime": đây là phương án gần đúng nhất và cũng là bẫy chính. RDS thật sự cho scale vertical rất dễ — chỉ cần đổi instance type. Nhưng nó hỏng ở chỗ "without downtime": đổi instance type đòi hỏi instance khởi động lại, nên vẫn có một khoảng gián đoạn ngắn. Dễ chứ không phải không gián đoạn — hai chuyện khác nhau.

C là đáp án đúng, đã giải thích ở trên.

D — "There is no database administration required": phương án này gần đúng nhưng đi quá xa. RDS gỡ phần quản trị hệ điều hành và hạ tầng, không gỡ phần quản trị database. Bạn vẫn phải tự thiết kế và quản lý bảng, chỉ mục, dữ liệu, phân quyền người dùng trong database, tối ưu truy vấn. Nói cách khác, vai trò DBA vẫn còn — chỉ là nhẹ đi ở phần sysadmin. Đây chính là cặp đối lập cần phân biệt với C: C nói về OS (đúng), D nói về database administration (sai).

📌 Điểm cần nhớ

• Managed service = AWS lo lớp dưới, bạn lo lớp trên. Với RDS, ranh giới nằm đúng ở hệ điều hành: AWS quản OS, hạ tầng, phần cứng; bạn quản schema, dữ liệu, truy vấn, người dùng trong DB.
• Cảnh giác với các chữ tuyệt đối trong phương án: any, no ... required, without downtime. Trong đề AWS, chúng thường là dấu hiệu của phương án phóng đại lợi ích của dịch vụ.
• RDS chỉ chạy một tập engine cố định (MySQL, SQL Server, MariaDB, Oracle, PostgreSQL, Aurora). Cần engine ngoài danh sách thì đây không phải chỗ.
• Scale vertical trên RDS là đổi instance type, thao tác đơn giản nhưng kéo theo một lần khởi động lại — nên nó không phải là scale "không gián đoạn".

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

Đề hỏi: lợi ích của việc dùng Amazon Rekognition với các tệp ảnh (image files) là gì?

Cụm từ quyết định ở đây là "benefits of using Amazon Rekognition" — tức là câu hỏi kiểm tra bạn có biết Rekognition làm việc gì hay không, chứ không hỏi chung chung về "xử lý ảnh trên AWS". Bốn phương án đều nhắc tới ảnh hoặc media, nên nếu chỉ nhớ mang máng "Rekognition liên quan tới ảnh" thì rất dễ chọn nhầm sang nén ảnh hay đổi kích thước ảnh.

Ràng buộc phân biệt nằm ở bản chất dịch vụ: Rekognition là dịch vụ phân tích, nhận dạng nội dung trong ảnh và video dựa trên deep learning — nó đọc hiểu ảnh và trả về thông tin về những gì có trong ảnh. Nó không phải công cụ biến đổi tệp (transform): không nén, không resize, không đổi định dạng. Hễ phương án nào nói về việc thay đổi chính tệp media thì phương án đó không phải Rekognition.

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

A. Can be used to identify objects in an image — đúng.

Rekognition Image nhận dạng được objects (đồ vật), scenes (bối cảnh), và faces (khuôn mặt) trong ảnh. Ngoài ra nó còn trích xuất chữ trong ảnh, nhận diện người nổi tiếng, phát hiện nội dung không phù hợp, và cho phép tìm kiếm/so khớp khuôn mặt.

Điểm chung của tất cả các khả năng trên: đầu vào là ảnh, đầu ra là nhãn/thông tin mô tả nội dung ảnh — chứ đầu ra không phải một tệp ảnh mới. Đó chính xác là điều phương án A mô tả: dùng Rekognition để xác định các đối tượng có trong ảnh.

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

B. Can help with image compression — sai. Rekognition không nén ảnh. Đây là phương án dễ gây phân vân nhất vì nó cũng nói về ảnh và nghe như "tối ưu ảnh". Nhưng nén ảnh là thao tác biến đổi tệp để giảm dung lượng, hoàn toàn khác với phân tích nội dung. Rekognition đọc ảnh vào để suy luận, nó không trả về cho bạn một tệp ảnh nhỏ hơn.

C. Can be used to transcode audio — sai, và sai ở hai tầng. Thứ nhất, đề bài nói rõ là image files, còn phương án này nói về audio — lệch hẳn loại dữ liệu. Thứ hai, việc transcode media trên AWS thuộc về Elastic Transcoder, không phải Rekognition. Đây là phương án dễ loại nhất nếu bạn đọc kỹ đề.

D. Can be used to resize images — sai. Bạn không thể dùng Rekognition để đổi kích thước ảnh. Phương án này cùng một loại bẫy với B: nó mô tả một thao tác chỉnh sửa tệp ảnh, trong khi Rekognition chỉ phân tích tệp ảnh. Rekognition có thể cho bạn biết trong ảnh có con chó ở vị trí nào (bounding box), nhưng nó không cắt, không phóng to, không thu nhỏ ảnh giúp bạn.

📌 Điểm cần nhớ

• Rekognition = phân tích nội dung, không phải biến đổi tệp. Đầu ra của nó là nhãn, khuôn mặt, chữ, mức độ tin cậy — không phải một tệp ảnh mới. Gặp phương án nói "compress", "resize", "convert format" thì loại ngay.
• Bộ khả năng cần thuộc của Rekognition Image: nhận dạng objects và scenes, phát hiện và so khớp khuôn mặt, trích xuất text trong ảnh, nhận diện celebrities, phát hiện nội dung không phù hợp (content moderation).
• Elastic Transcoder mới là dịch vụ transcode media. Đừng nhầm nó với Rekognition chỉ vì cả hai đều "làm việc với media".
• Đọc kỹ loại dữ liệu trong đề. Đề nói "image files" thì mọi phương án nói về audio đã tự loại mình, không cần biết dịch vụ đó làm gì.

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

Đề hỏi: "Which of the following is an advantage of AWS Cloud computing?" — đâu là một lợi thế của điện toán đám mây AWS.

Cụm từ quyết định nằm ở chính chữ "an advantage" (một lợi thế), đặt cạnh cấu trúc "Trade X for Y" (đánh đổi X lấy Y) mà cả bốn phương án đều dùng. Đây là mấu chốt: câu hỏi không hỏi "đám mây có gì hay", mà bắt người học phân biệt giữa một sự đánh đổi thật sự có lợi và những sự đánh đổi bịa ra giữa hai thứ vốn đều là lợi thế.

Nói cách khác, muốn chọn đúng thì phải nhận ra: trong sáu lợi thế kinh điển của cloud computing mà AWS nêu, chỉ có một cặp là đánh đổi thật — bỏ chi phí đầu tư cố định để lấy chi phí vận hành biến đổi. Còn security, elasticity, performance, operational excellence đều nằm cùng phía "được", không có chuyện phải hy sinh cái này để lấy cái kia.

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

Đáp án đúng: B — "Trade fixed expenses for variable expenses."

Đây đúng là lợi thế đầu tiên trong danh sách sáu lợi thế của cloud computing mà AWS công bố. Mô hình truyền thống buộc doanh nghiệp bỏ tiền trước để mua máy chủ, thiết bị mạng, chỗ đặt trong data center — tức chi phí đầu tư cố định (capital expenditure), phải trả bất kể sau này dùng hết công suất hay không.

Với AWS, khoản đó chuyển thành chi phí vận hành biến đổi (operational expenditure): trả theo mức tài nguyên thực sự tiêu thụ, thanh toán theo chu kỳ thay vì trả trước một cục. Bạn không phải đoán trước nhu cầu vài năm tới rồi mua dư cho chắc; dùng nhiều trả nhiều, dùng ít trả ít, dừng dùng thì ngừng trả.

Chữ "trade" ở đây là đánh đổi thật và có lợi rõ ràng: cái bị bỏ đi (chi phí cố định trả trước) là gánh nặng, cái nhận lại (chi phí biến đổi theo mức dùng) là thứ mong muốn.

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

A — "Trade security for elasticity." Sai vì nó đề xuất hy sinh security để lấy elasticity. Trong AWS, security là ưu tiên số một, không bao giờ là thứ đem ra đánh đổi. Hơn nữa hai thứ này hoàn toàn không loại trừ nhau: kiến trúc trên AWS vừa co giãn theo tải vừa giữ nguyên các kiểm soát bảo mật — thêm hay bớt instance không làm yếu đi IAM policy, security group hay việc mã hoá dữ liệu.

C — "Trade operational excellence for agility." Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì agility (tăng tốc độ triển khai, thử nghiệm nhanh) đúng là một lợi thế thật của cloud, nên đọc lướt sẽ thấy vế sau quen tai. Chỗ hỏng nằm ở vế trước: operational excellence cũng là điều đáng mong muốn — nó là một trong các trụ cột của AWS Well-Architected Framework — nên không có lý do gì phải vứt nó đi. Cả hai đều là lợi thế, đặt chúng ở hai đầu một phép đánh đổi là sai ngay về logic, dù từng chữ trong câu đều là thuật ngữ đúng.

D — "Trade elasticity for performance." Hỏng theo đúng cùng một kiểu với C: elasticity và performance efficiency đều là lợi thế, không cái nào phải trả giá cho cái nào. Thực tế còn ngược lại — khả năng co giãn tài nguyên theo nhu cầu chính là thứ giúp giữ hiệu năng ổn định khi tải tăng, chứ không phải kẻ thù của hiệu năng. Phương án này biến hai thứ bổ trợ nhau thành hai thứ xung khắc.

📌 Điểm cần nhớ

• Với dạng câu "trade X for Y", hãy kiểm tra vế X trước: nếu X vốn là một điều tốt (security, elasticity, performance, operational excellence) thì phương án đó sai ngay, bất kể vế Y nghe hấp dẫn tới đâu. Đánh đổi hợp lệ phải là bỏ thứ dở lấy thứ hay.
• Lợi thế kinh điển và hay bị hỏi nhất của cloud: chuyển chi phí đầu tư cố định trả trước thành chi phí biến đổi trả theo mức dùng. Nhớ đúng cặp từ này (fixed/capital ↔ variable/operational) là ăn trọn nhóm câu về AWS Cloud Benefits.
• Các lợi thế của cloud cộng dồn với nhau, không loại trừ nhau. Đề thi hay dựng phương án nhiễu bằng cách lấy hai lợi thế thật rồi ép chúng vào thế đối đầu — nghe rất kỹ thuật nhưng vô nghĩa.
• Security trong AWS không bao giờ là biến số đem ra mặc cả. Bất kỳ phương án nào hàm ý giảm bảo mật để đổi lấy một thuộc tính khác đều loại được ngay từ vòng đầu.