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

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

Đề bài mô tả nhu cầu của một Cloud Practitioner: cần một công cụ giúp xem và quản lý chi phí cùng mức sử dụng AWS theo thời gian.

Cụm từ quyết định đáp án là "viewing and managing AWS costs and usage over time" — nghĩa là nhìn lại dữ liệu chi phí đã phát sinh, phân tích nó theo trục thời gian. Chú ý hai chi tiết trong cụm này:

• "viewing" — trọng tâm là trực quan hoá, xem báo cáo, phân tích. Đây không phải yêu cầu đặt ngưỡng hay nhận cảnh báo.
• "over time" — dữ liệu lịch sử, có xu hướng theo ngày/tháng, chứ không phải một con số tại một thời điểm.

Ràng buộc này rất quan trọng vì nó tách hai phương án dễ nhầm nhất trong danh sách: AWS Cost Explorer và AWS Budgets. Cả hai đều thuộc nhóm AWS Cost Management, cả hai đều nói về chi phí — nhưng một cái để nhìn lại quá khứ, một cái để canh chừng tương lai.

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

B — AWS Cost Explorer là đáp án đúng.

AWS Cost Explorer cung cấp giao diện trực quan cho phép bạn hình dung, hiểu và quản lý chi phí cùng mức sử dụng AWS theo thời gian. Dịch vụ đi kèm sẵn một bộ báo cáo mặc định để bạn bắt đầu phân tích ngay, sau đó dùng khả năng lọc (filtering) và nhóm (grouping) để đào sâu hơn vào dữ liệu chi phí và mức sử dụng, tạo ra những góc nhìn riêng cho tổ chức mình.

Đây chính xác là thứ đề bài mô tả: một công cụ để xem và quản lý chi phí trải dài theo trục thời gian — biểu đồ xu hướng, so sánh giữa các tháng, bóc tách theo dịch vụ hoặc theo tag.

❌ 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, giúp cải thiện tính bảo mật và mức độ tuân thủ của ứng dụng triển khai trên AWS. Nó hoàn toàn không liên quan tới chi phí hay billing — thuộc nhóm Security, không phải Cost Management. Loại ngay.

C — AWS Budgets: Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. AWS Budgets cho phép bạn đặt ngân sách tuỳ chỉnh để theo dõi chi phí và mức sử dụng, từ trường hợp đơn giản đến phức tạp. Điểm hỏng nằm ở chỗ: Budgets hoạt động theo mô hình đặt ngưỡng rồi cảnh báo khi vượt — nó trả lời câu hỏi "tôi có tiêu quá mức đã định không?". Còn đề bài hỏi công cụ để xem và phân tích dữ liệu theo thời gian, tức là "tiền của tôi đã đi đâu?". Budgets không phải công cụ trực quan hoá và phân tích lịch sử chi phí — đó là việc của Cost Explorer.

D — AWS Organizations: Dịch vụ này dùng để tổ chức các tài khoản AWS, tạo tài khoản bằng chương trình, và tận dụng consolidated billing (gộp hoá đơn nhiều tài khoản về một nơi). Chữ "billing" khiến nó trông có vẻ liên quan, nhưng vai trò của Organizations là quản trị cấu trúc tài khoản và gộp hoá đơn — nó không cung cấp giao diện phân tích chi phí theo thời gian. Consolidated billing quyết định hoá đơn được gộp thế nào, chứ không giúp bạn xem và hiểu chi phí đó.

📌 Điểm cần nhớ

• Cost Explorer nhìn về quá khứ, AWS Budgets nhìn về tương lai. Thấy từ khoá "visualize", "analyze", "view", "over time", "trend" → chọn Cost Explorer. Thấy "set a threshold", "alert", "notify when exceeds" → chọn AWS Budgets. Đây là cặp phân biệt xuất hiện rất nhiều trong đề Cloud Practitioner.
• Đừng để chữ "billing" trong mô tả một dịch vụ đánh lừa. AWS Organizations có consolidated billing nhưng bản chất là công cụ quản trị nhiều tài khoản, không phải công cụ phân tích chi phí.
• Phân loại dịch vụ theo nhóm trước khi so chi tiết. Amazon Inspector thuộc nhóm bảo mật; chỉ cần nhận ra nhóm là loại được ngay mà không cần đọc kỹ.
• Giá trị cốt lõi của Cost Explorer là báo cáo mặc định + lọc + nhóm. Nhớ ba từ khoá này thì nhận ra Cost Explorer ở bất kỳ cách diễn đạt nào của đề.

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

Đề bài kể một tình huống: công ty triển khai ứng dụng trên Amazon EC2, và ứng dụng đó cần truy cập low-latency tới các thành phần còn nằm trong data center tại chỗ. Câu hỏi chốt lại bằng một yêu cầu rất cụ thể: dịch vụ hoặc tài nguyên AWS nào cho phép "extend their existing VPC to the on-premises data center".

Cụm từ quyết định là "extend their existing VPC" — mở rộng chính cái VPC đang có xuống tận cơ sở hạ tầng tại chỗ, chứ không phải "kết nối tới" hay "nối mạng giữa hai bên". Đây là chỗ phân biệt hai phương án nghe rất giống nhau trong ngữ cảnh hybrid (C và D). Yêu cầu low-latency chỉ là bối cảnh giải thích vì sao phải làm hybrid, còn từ khoá thực sự lọc đáp án là extend the VPC — tức là muốn chạy hạ tầng AWS, subnet của VPC, và các API AWS ngay tại chỗ.

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

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

AWS Outposts là dịch vụ managed đưa chính hạ tầng AWS, dịch vụ AWS, API và công cụ AWS đặt vào data center của khách hàng, co-location, hay cơ sở on-premises. Nhờ vậy trải nghiệm hybrid là nhất quán: bạn dùng cùng bộ API và cùng cách vận hành ở cả hai phía.

Điểm khớp trực tiếp với đề: với Outposts, bạn mở rộng VPC của mình xuống chỗ đặt Outpost — subnet của VPC hiện có được tạo trên Outpost, và tài nguyên chạy ở đó nằm trong cùng VPC với phần chạy trong Region. Đây đúng nghĩa "extend the existing VPC to the on-premises data center". Vì thành phần ứng dụng tại chỗ và tài nguyên AWS nằm cùng vị trí vật lý, độ trễ giữa chúng rất thấp, thoả nốt yêu cầu low-latency của đề.

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

A. Amazon Workspaces — đây là giải pháp Desktop-as-a-Service (DaaS) được quản lý, cung cấp desktop ảo cho người dùng cuối. Nó không liên quan gì đến việc mở rộng VPC hay xây kiến trúc hybrid cho ứng dụng chạy trên EC2. Đây là phương án gây nhiễu rõ ràng.

B. Amazon Connect — dịch vụ contact center trên cloud, phục vụ trải nghiệm omnichannel gồm thoại, chat và quản lý tác vụ. Hoàn toàn thuộc mảng ứng dụng nghiệp vụ, không phải mảng networking, càng không dính tới VPC.

D. AWS Direct Connect — đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Direct Connect tạo một kết nối riêng, ổn định, độ trễ thấp giữa data center on-premises và AWS, không đi qua Internet công cộng. Nó thoả phần "low-latency access", nên rất dễ bị chọn. Nhưng nó chỉ là đường kết nối mạng giữa hai môi trường tách biệt — nó không đem hạ tầng AWS xuống chỗ bạn và không làm cho VPC hiện có trải rộng vào data center. Nói cách khác, Direct Connect nối tới VPC chứ không mở rộng VPC, nên trượt đúng ở cụm từ then chốt của đề.

📌 Điểm cần nhớ

• Thấy cụm "extend your VPC to on-premises" (đưa subnet, dịch vụ và API AWS xuống tại chỗ) → nghĩ tới AWS Outposts.
• Thấy cụm "private/dedicated connection to on-premises", "không đi qua Internet" → nghĩ tới AWS Direct Connect. Cả hai đều là hybrid và đều nói tới low-latency, nên phải đọc kỹ động từ: extend khác connect.
• Amazon WorkSpaces (DaaS, desktop ảo) và Amazon Connect (contact center) chỉ na ná về tên hoặc hay xuất hiện làm nhiễu; chúng không thuộc nhóm networking và gần như không bao giờ là đáp án cho câu hỏi về kết nối VPC.
• Khi hai phương án cùng thoả một mệnh đề phụ (ở đây là low-latency), hãy tìm mệnh đề còn lại trong đề để phân định — thường chỉ một phương án thoả cả hai.

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

Đề hỏi: những nguyên tắc thiết kế (design principles) nào được AWS Cloud tạo điều kiện để cải thiện việc vận hành workload? Chọn HAI.

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

• "design principles ... enabled by the AWS Cloud" — thứ được chọn phải là một nguyên tắc kiến trúc hệ thống, và phải là thứ đám mây làm cho dễ hơn so với hạ tầng tự dựng. Một ý hay nhưng không liên quan gì tới đặc tính của cloud thì trượt ngay ở vế này.
• "to improve the operation of workloads" — mục tiêu là vận hành workload (độ sẵn sàng, khả năng chịu lỗi, khả năng mở rộng), chứ không phải cách quản lý dự án hay cách phát triển sản phẩm.

Đây chính là bộ lọc tách các phương án gần giống nhau: trong năm lựa chọn có những cụm nghe rất "đúng đắn" trong ngành phần mềm, nhưng chúng thuộc phạm trù quy trình làm sản phẩm, không phải kiến trúc vận hành trên cloud. Câu này lấy ý trực tiếp từ whitepaper AWS Cloud Best Practices (Architecting for the Cloud).

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

Theo tệp, đáp án đúng là B – Remove single points of failure và D – Loose coupling.

B – Remove single points of failure. Loại bỏ điểm hỏng đơn lẻ là cách đạt fault tolerance và high availability: không thành phần nào hỏng mà kéo sập cả hệ thống. AWS Cloud khiến nguyên tắc này dễ áp dụng vì kiến trúc và các tính năng của nền tảng được dựng sẵn cho việc chạy dư thừa nhiều bản — triển khai nhiều bản của cùng một thành phần, đặt sau load balancer, trải ra nhiều vùng khả dụng. Đây đúng là nguyên tắc thiết kế cải thiện việc vận hành workload.

D – Loose coupling. Ghép lỏng là chẻ hệ thống thành các thành phần nhỏ, nối với nhau một cách lỏng lẻo, nhờ đó giảm phụ thuộc lẫn nhau giữa các thành phần. Một thành phần chậm hoặc chết không lan lỗi sang phần còn lại. Trên cloud, điều này đạt được bằng message bus, dịch vụ notification và messaging — thành phần A không gọi thẳng vào thành phần B mà đẩy thông điệp vào hàng đợi/chủ đề, B tự tiêu thụ theo nhịp của nó.

Hai nguyên tắc này bổ trợ nhau: ghép lỏng chặn lỗi lan ra, còn bỏ điểm hỏng đơn lẻ khiến mỗi thành phần vốn đã khó chết.

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

A – Minimum viable product. MVP là khái niệm của phát triển sản phẩm: tung ra bản nhỏ nhất dùng được để lấy phản hồi sớm. Nó nói về việc quyết định làm gì, không nói gì về cách kiến trúc hệ thống chịu lỗi hay mở rộng. Đây không phải một lợi thế vận hành cho workload trên cloud, nên không khớp vế "improve the operation of workloads". Đây là phương án gây nhiễu mạnh nhất vì bản thân MVP là thực hành tốt trong ngành — nhưng tốt ở phạm trù khác.

C – Minimize platform design. Cụm này nghe như "làm nền tảng đơn giản đi", vay mượn hào quang của nguyên tắc chuộng sự đơn giản. Vấn đề: nó không phải một nguyên tắc trong danh sách best practice của AWS, và cũng không phải lợi thế vận hành mà cloud mang lại. Nó không mô tả được hành động cụ thể nào — khác hẳn "bỏ điểm hỏng đơn lẻ" hay "ghép lỏng" vốn chỉ thẳng ra việc phải làm. Gặp phương án chỉ có chữ nghe hay mà không chỉ được việc làm, hãy nghi ngờ.

E – Customized hardware. Sai ở tầng khái niệm: trên cloud bạn không tùy biến phần cứng. Bạn chọn trong danh mục loại máy mà nhà cung cấp đưa ra, còn phần cứng vật lý bên dưới do AWS vận hành — đó chính là nội dung của mô hình trách nhiệm chia sẻ. Hơn nữa, phụ thuộc vào phần cứng riêng là đi ngược tinh thần cloud: nó khóa workload vào một cấu hình cụ thể, làm việc thay thế và mở rộng khó hơn.

📌 Điểm cần nhớ

• Đọc kỹ hai vế của đề: "enabled by the AWS Cloud" (phải là thứ cloud làm cho dễ hơn) và "operation of workloads" (phải thuộc phạm trù kiến trúc – vận hành). Phương án nào rớt một vế là loại.
• Phân biệt nguyên tắc kiến trúc với thực hành quản lý sản phẩm. MVP, agile, sprint... đều là thực hành tốt nhưng không phải nguyên tắc thiết kế workload trên cloud. Đề thi hay trộn chúng vào để gây nhiễu.
• Bộ nguyên tắc kinh điển của AWS Cloud Best Practices đáng thuộc nằm lòng: remove single points of failure, loose coupling, design for failure, scalability/elasticity, automation. Nhiều câu Cloud Practitioner rút thẳng từ danh sách này.
• Bất kỳ phương án nào nói tới việc kiểm soát hay tùy biến phần cứng vật lý đều gần như chắc chắn sai trong ngữ cảnh cloud — phần cứng thuộc trách nhiệm của nhà cung cấp, và phụ thuộc phần cứng riêng làm giảm chứ không tăng khả năng vận hành.

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

Đề hỏi: công ty có thể dùng dịch vụ AWS nào để thu thập thông tin về hoạt động (activity) trong tài khoản AWS của họ — chọn HAI.

Cụm từ quyết định là "gather information about activity in their AWS account". Hai chữ khoá cần tách bạch:

• "gather information" — dịch vụ phải thu thập và lưu lại dữ liệu, chứ không phải chỉ đưa ra lời khuyên hay phục vụ nội dung.
• "activity in their AWS account" — phạm vi là hoạt động ở mức tài khoản: ai gọi API nào, tài nguyên tiêu thụ ra sao, chi phí phát sinh thế nào. Đây không phải hoạt động của người dùng cuối trên ứng dụng.

Vì đề cho chọn hai, cần một dịch vụ ghi lại số liệu vận hành và một dịch vụ ghi lại hành vi gọi API. Đó chính là cặp CloudWatch + CloudTrail.

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

B — Amazon CloudWatch. Đây là dịch vụ giám sát hiệu năng. Các dịch vụ AWS tự gửi metric về mức sử dụng của mình sang CloudWatch, và CloudWatch thu thập lại. Ngoài metric của từng tài nguyên, CloudWatch còn thu thập cả metric ở mức tài khoản — ví dụ thông tin billing — nên nó khớp trực tiếp với vế "gather information about activity in their AWS account".

D — AWS CloudTrail. Đây là dịch vụ kiểm toán (auditing), theo dõi hoạt động API trong tài khoản. Mỗi khi có ai thực hiện một thao tác trong tài khoản, thao tác đó quy về một lời gọi API, và CloudTrail ghi lại để tạo thành một audit trail — biết được ai làm gì, khi nào. Đây đúng nghĩa đen của "activity in their AWS account".

Cặp này bổ sung cho nhau: CloudTrail trả lời "ai đã làm gì", CloudWatch trả lời "hệ thống đang chạy thế nào".

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

A — Amazon Connect. Đây là dịch vụ contact center (tổng đài chăm sóc khách hàng trên cloud). Nó không liên quan gì tới việc quan sát tài khoản AWS. Đây là phương án gây nhiễu bằng chữ "Connect" nghe như kết nối/tích hợp, nhưng bản chất là sản phẩm nghiệp vụ dành cho tổng đài.

C — AWS Trusted Advisor. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất. Trusted Advisor có nhìn vào tài khoản và có đưa ra báo cáo, nên thoạt nghe giống "thu thập thông tin". Nhưng vai trò của nó là đưa ra khuyến nghị (guidance) về việc cấp phát tài nguyên theo best practice — tối ưu chi phí, hiệu năng, bảo mật, khả năng chịu lỗi, hạn mức dịch vụ. Nó đưa ra lời khuyên dựa trên trạng thái cấu hình, chứ không phải cơ chế ghi nhận và lưu trữ hoạt động diễn ra trong tài khoản. Nó không cho bạn biết hôm qua ai đã xoá một tài nguyên.

E — Amazon CloudFront. Đây là CDN (content delivery network), dùng để phân phối nội dung tới người dùng cuối với độ trễ thấp. Tiền tố "Cloud..." khiến nó dễ bị chọn nhầm cùng nhóm với CloudWatch/CloudTrail, nhưng nhiệm vụ của nó là phục vụ nội dung, không phải quan sát tài khoản.

📌 Điểm cần nhớ

• Nhớ cặp đối chiếu kinh điển: CloudTrail = ai gọi API nào (audit, "who did what"), CloudWatch = metric hiệu năng và mức sử dụng ("how is it running"). Rất nhiều câu chỉ xoay quanh việc phân biệt hai dịch vụ này.
• Trusted Advisor là dịch vụ khuyến nghị theo best practice, không phải dịch vụ ghi log hoạt động. Gặp đề nhấn vào "activity", "audit", "who made the change" thì loại Trusted Advisor.
• Đừng chọn theo tiền tố tên. CloudFront dù cùng chữ "Cloud" vẫn thuộc nhóm phân phối nội dung, không thuộc nhóm giám sát.
• Với đề "Select TWO", hãy kiểm xem hai đáp án có bổ sung cho nhau ở hai góc khác nhau không (số liệu vận hành + nhật ký API) — đó thường là dấu hiệu của cặp đáp án đúng, thay vì hai dịch vụ trùng vai trò.

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

Đề hỏi: công ty được lợi gì khi triển khai relational database trên Amazon RDS thay vì trên Amazon EC2 (chọn HAI).

Cụm từ quyết định đáp án là "instead of Amazon EC2" — đề không hỏi "RDS làm được gì", mà hỏi phần việc nào RDS gánh hộ mà nếu tự dựng database trên EC2 thì bạn phải tự làm. Đây chính là ranh giới managed service (dịch vụ được quản lý) so với self-managed (tự quản lý).

Vì vậy, mỗi phương án phải được soi qua đúng một câu hỏi: AWS có làm giúp việc này khi dùng RDS không? Có ba nhóm rơi ra:

• Việc AWS gánh hộ → đúng.
• Việc vẫn thuộc về người dùng dù chạy RDS hay EC2 → sai, vì không phải "lợi ích khi đổi sang RDS".
• Thứ mà chuyển sang RDS bạn mất đi chứ không được thêm → sai, và sai theo chiều ngược hẳn.

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

Đáp án đúng theo tệp là B (Software patching) và E (Automated backups).

B — Software patching. Với RDS, AWS lo việc vá phần mềm cho database engine và hệ điều hành bên dưới, người dùng chỉ chọn thời điểm (maintenance window) và phiên bản. Nếu tự cài database trên EC2, việc theo dõi bản vá, tải về, cài đặt và khởi động lại đúng cách là việc của bạn.

E — Automated backups. RDS có cơ chế sao lưu tự động sẵn có, kèm khả năng khôi phục về một thời điểm trong khoảng thời gian lưu giữ. Trên EC2 bạn phải tự dựng cơ chế đó: viết script dump, lên lịch, quản lý nơi lưu, và tự kiểm tra khôi phục có chạy không.

Cả hai đều là việc vận hành (operational) mà AWS nhận về phía mình — đúng nghĩa "lợi ích khi chọn RDS thay vì EC2".

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

A — Root access to OS. Đây là phương án dễ chọn nhầm nhất vì nghe như một quyền lợi. Nhưng nó ngược chiều đề bài: với RDS, bạn không có quyền root vào hệ điều hành của instance — chính việc AWS giữ quyền đó mới cho phép họ tự vá và tự quản lý. Ngược lại, EC2 mới là nơi bạn có toàn quyền OS. Nếu coi root access là lợi ích, thì đó là lợi ích của EC2 chứ không phải của RDS.

C — Schema management. Thiết kế schema là việc của ứng dụng và của người phát triển: tạo bảng, định nghĩa cột, quan hệ, ràng buộc. RDS không thiết kế schema hộ bạn. Chạy trên RDS hay trên EC2 thì bạn vẫn viết đúng chừng ấy câu DDL — không có gì được gánh hộ, nên không phải lợi ích khi chuyển đổi.

D — Indexing of tables. Cùng loại nhầm lẫn với C, và cũng khá gần đúng ở chỗ nó "thuộc về database". Nhưng quyết định đánh index lên cột nào, dùng loại index gì, đánh đổi tốc độ đọc với chi phí ghi ra sao — đều phụ thuộc vào truy vấn của ứng dụng bạn. Đó là việc tối ưu do người dùng làm, RDS không tự quyết thay. Không phải điểm khác biệt giữa RDS và EC2.

📌 Điểm cần nhớ

• Câu hỏi dạng "managed service X thay vì tự dựng trên EC2" luôn quy về một phép thử: phần việc này AWS làm hay tôi làm? AWS làm → đáp án; tôi vẫn làm → loại.
• Ranh giới của RDS: AWS lo hạ tầng, hệ điều hành, vá phần mềm, sao lưu tự động, khôi phục. Người dùng lo schema, index, truy vấn, dữ liệu — tức là phần logic của database.
• Mất quyền root vào OS là cái giá, không phải lợi ích. Cần cài agent riêng, sửa file cấu hình ở tầng OS, hay dùng phiên bản engine tuỳ biến thì đó là lý do người ta chọn EC2 — và cũng là bẫy quen thuộc trong đề.
• Phương án chỉ nhắc tới thao tác bên trong database (schema, index, tuning truy vấn) gần như luôn sai trong nhóm câu so sánh managed và self-managed, vì chúng giống nhau ở cả hai bên.

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

Đề mô tả một startup làm ứng dụng web cho phép người dùng tìm bài viết theo nhiều tiêu chí khác nhau: từ khoá, tác giả, chủ đề. Câu hỏi cuối là chọn dịch vụ AWS xử lý được chức năng này một cách hiệu quả.

Cụm từ quyết định là "find articles based on various criteria such as keywords, authors, or topics" — tức là chức năng tìm kiếm (search) trên nội dung văn bản, với nhiều trường lọc khác nhau. Thêm chữ "efficiently": đề không hỏi "cách nào làm được" mà hỏi "dịch vụ nào sinh ra để làm việc này".

Đây là kiểu câu rất phổ biến ở mức Cloud Practitioner: đối chiếu mục đích thiết kế của từng dịch vụ với nhu cầu trong đề. Ba trong bốn phương án là những dịch vụ nền tảng rất quen mặt (compute, queue), nhưng không cái nào có chữ "search" trong bản mô tả chức năng của nó.

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

Đáp án đúng theo tệp là D — Amazon OpenSearch Service.

Amazon OpenSearch Service là dịch vụ được AWS xây dựng riêng để triển khai, vận hành và mở rộng các giải pháp search và analytics. Đúng theo lời giải nguồn: nó cung cấp sẵn những chức năng cần thiết để tìm bài viết theo các tiêu chí khác nhau.

Bản chất của nó là một search engine được quản lý: dữ liệu được đánh chỉ mục (index) theo từng trường, nên một truy vấn có thể tìm theo từ khoá trong nội dung, đồng thời lọc theo tác giả hay chủ đề — chính xác ba tiêu chí đề nêu. AWS lo phần dựng cụm, vá lỗi và scale, nên startup chỉ việc dùng, đúng với chữ "efficiently" trong đề.

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

A — AWS Lambda. Đây là dịch vụ compute chạy code theo sự kiện, tự quản lý phần hạ tầng tính toán. Lambda không tự nó cung cấp chức năng tìm kiếm cho nội dung của website. Đây là phương án dễ gây phân vân nhất, vì trong kiến trúc thật Lambda thường đứng ở giữa để nhận request rồi gọi sang một dịch vụ tìm kiếm — nhưng nó là lớp xử lý, không phải nơi lưu chỉ mục và thực hiện truy vấn tìm kiếm. Chọn Lambda là trả lời câu "code chạy ở đâu", không phải câu "search bằng gì".

B — Amazon SQS. Đây là dịch vụ hàng đợi thông điệp, dùng để tách rời (decouple) các thành phần của ứng dụng cloud. SQS giúp một thành phần gửi việc cho thành phần khác xử lý bất đồng bộ; nó hoàn toàn không phục vụ việc dựng chức năng tìm kiếm cho ứng dụng web. Đây là phương án xa đề nhất.

C — Amazon EC2. Đây là máy chủ ảo, dùng để host ứng dụng. Về mặt kỹ thuật thì EC2 có thể host được ứng dụng web này — và đó chính là chỗ gài bẫy. Nhưng EC2 chỉ cho bạn một máy trống: mọi phần search đều phải tự cài, tự cấu hình, tự vận hành và tự scale. EC2 không chuyên cho việc dựng chức năng tìm kiếm bên trong ứng dụng, nên nó thua ở đúng chữ "efficiently" mà đề nhấn mạnh.

📌 Điểm cần nhớ

• Thấy đề nhắc tìm kiếm theo từ khoá / nhiều tiêu chí trên nội dung văn bản, hãy nghĩ ngay tới Amazon OpenSearch Service — đó là dịch vụ được thiết kế cho search và analytics.
• "Làm được" khác "được thiết kế để làm". EC2 host được gần như mọi thứ, nên nếu chọn nó thì câu hỏi trắc nghiệm sẽ chẳng còn đáp án sai nào. Khi đề có chữ "efficiently" hay "specialized", hãy chọn managed service đúng mục đích.
• Phân biệt vai trò từng dịch vụ: Lambda = chạy code theo sự kiện, SQS = hàng đợi để decouple các thành phần, EC2 = máy chủ ảo, OpenSearch Service = tìm kiếm và phân tích.
• Ở mức Cloud Practitioner, phần lớn câu dạng này giải được bằng cách đối chiếu một câu mô tả mục đích của mỗi dịch vụ với nhu cầu trong đề, không cần đi vào chi tiết cấu hình.

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

Đề hỏi: "Which of the following are valid benefits of using the AWS Cloud? (Select TWO.)" — đâu là những lợi ích hợp lệ khi dùng AWS Cloud, chọn hai.

Cụm từ quyết định là "valid benefits" kết hợp với "(Select TWO)". Đây là câu kiểm tra xem người học có thuộc six advantages of cloud computing mà AWS đưa ra trong tài liệu chính thức hay không, và quan trọng hơn: có phân biệt được lợi ích thật với lời hứa phóng đại hay không.

Hai chữ cần soi kỹ trong các phương án là "all" (A, B) và "total control" (E). Bất cứ khi nào một phương án về cloud dùng từ tuyệt đối kiểu all / total / complete, khả năng rất cao đó là bẫy — vì mô hình cloud vận hành trên shared responsibility model, tức trách nhiệm được chia chứ không bao giờ chuyển giao trọn vẹn sang một phía.

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

Theo tệp, đáp án đúng là C và D.

• D — "Fast provisioning of IT resources": khớp trực tiếp với lợi ích "Increase speed and agility". Thay vì đặt mua máy chủ, chờ giao hàng, lắp đặt và cấu hình trong nhiều tuần, bạn gọi API và có tài nguyên trong thời gian rất ngắn. Điều này rút ngắn hẳn vòng thử nghiệm — sai thì bỏ đi, không mất khoản đầu tư phần cứng.
• C — "Ability to go global quickly": khớp với lợi ích "Go global in minutes". AWS đã dựng sẵn hạ tầng ở nhiều Region trên thế giới, nên việc triển khai ứng dụng gần người dùng ở châu lục khác chỉ là chọn Region và deploy, không phải đi thuê data center và ký hợp đồng với nhà mạng địa phương.

Điểm chung của hai phương án đúng: cả hai đều nói về tốc độ — tốc độ có tài nguyên và tốc độ mở rộng phạm vi địa lý. Đó chính là giá trị cốt lõi mà mô hình cloud mang lại.

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

• A — "Outsource all operational risk": đây là phương án gần đúng nhất và cũng là bẫy chính. Đúng là AWS gánh giúp bạn một phần rủi ro vận hành: hỏng ổ cứng, mất điện data center, an ninh vật lý. Nhưng chữ "all" làm câu này sai. Bạn vẫn chịu rủi ro cho phần của mình: lỗi trong mã ứng dụng, cấu hình sai quyền truy cập, dữ liệu không được sao lưu, kiến trúc chỉ đặt ở một chỗ nên chết theo chỗ đó. Bỏ chữ "all" đi thì phương án này có thể chấp nhận được — chính chữ đó khiến nó hỏng.
• B — "Outsource all application development to AWS": sai về bản chất, không phải sai vì mức độ. AWS cung cấp hạ tầng và dịch vụ, không viết ứng dụng thay bạn. Bạn vẫn phải tự thiết kế, lập trình, kiểm thử và bảo trì phần mềm của mình. Đây là nhầm lẫn giữa "thuê hạ tầng" và "thuê đội phát triển" — hai chuyện hoàn toàn khác nhau.
• E — "Total control over data center infrastructure": sai, và sai theo hướng ngược lại với ý nghĩa của cloud. Khi dùng AWS, bạn từ bỏ quyền kiểm soát hạ tầng vật lý — bạn không biết máy chủ đặt ở tủ rack nào, không chọn được model ổ cứng, không vào được phòng máy. Đó chính là cái giá đánh đổi để có được C và D. Nếu bạn thật sự cần toàn quyền kiểm soát data center thì mô hình phù hợp là on-premises, chứ không phải cloud. Người học hay chọn nhầm E vì thấy chữ "control" nghe tích cực.

📌 Điểm cần nhớ

• Thuộc lòng six advantages of cloud computing của AWS — rất nhiều câu Cloud Practitioner chỉ là diễn đạt lại một trong sáu ý đó: đổi chi phí đầu tư thành chi phí vận hành, hưởng lợi từ quy mô lớn, không phải đoán trước dung lượng, tăng tốc độ và độ linh hoạt, thôi tốn tiền vận hành data center, và triển khai toàn cầu trong vài phút.
• Cảnh giác với từ tuyệt đối: all, total, complete, never, 100%. Trong đề AWS, phương án chứa chúng gần như luôn sai, vì shared responsibility model chia trách nhiệm chứ không dồn hết về một bên.
• Mất quyền kiểm soát hạ tầng vật lý là đặc điểm, không phải lợi ích của cloud. Bất kỳ phương án nào hứa cho bạn quyền kiểm soát data center đều đi ngược mô hình.
• AWS bán hạ tầng và dịch vụ, không bán công sức phát triển ứng dụng. Phương án nào nói AWS làm hộ phần code của bạn là sai.

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

Đề đặt ra bối cảnh: một Cloud Practitioner đang phát triển một ứng dụng mới và muốn tích hợp các tính năng của dịch vụ AWS thẳng vào bên trong ứng dụng đó. Câu hỏi yêu cầu chọn công cụ BEST cho mục đích này.

Cụm từ quyết định là "integrate features of AWS services directly into the application" — nghĩa là lời gọi tới AWS phải nằm trong mã nguồn của ứng dụng, do chính chương trình thực thi lúc chạy. Đây là điểm phân biệt then chốt, vì cả bốn phương án đều là công cụ dành cho lập trình viên (nhóm AWS Developer Tools), nhưng chỉ một trong số đó hoạt động ở tầng mã nguồn ứng dụng; ba cái còn lại làm việc ở tầng thao tác vận hành và triển khai, tức là bên ngoài ứng dụng.

Chữ "developing a new application" cũng loại bỏ hướng hiểu "đưa ứng dụng lên môi trường chạy" — đề không hỏi cách build, release hay deploy, mà hỏi cách viết mã gọi được AWS.

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

C. AWS Software Development Kit (SDK) là đáp án đúng.

SDK là một bộ công cụ phát triển phần mềm đóng gói sẵn thành một gói cài đặt được. AWS cung cấp SDK cho nhiều ngôn ngữ lập trình khác nhau, và đúng như mô tả trong đề, chúng dùng để tích hợp tính năng của các dịch vụ AWS trực tiếp vào ứng dụng.

Về mặt cơ chế: lập trình viên thêm SDK vào dự án như một thư viện phụ thuộc, rồi gọi các API của AWS bằng chính ngôn ngữ mình đang viết. Ứng dụng khi chạy sẽ tự nói chuyện với dịch vụ AWS — đó chính xác là "tích hợp trực tiếp vào ứng dụng" mà đề mô tả.

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

A. AWS Command Line Interface (CLI) — đây là phương án gần đúng nhất và cũng là bẫy chính. CLI thật sự gọi được tới cùng những API AWS mà SDK gọi, nên nhiều người nghĩ nó tương đương. Chỗ hỏng nằm ở cách sử dụng: CLI là công cụ để chạy lệnh ở terminal hoặc trong shell script, do con người hoặc script điều khiển từ bên ngoài. Nó không phải là thư viện nhúng vào mã nguồn ứng dụng. Khi đề nhấn mạnh "directly into the application", CLI không phải công cụ tốt nhất cho mục đích đó.

B. AWS CodePipeline — dịch vụ này dùng để tự động hoá vòng đời phát hành mã (code release lifecycle), tức là nối các chặng build, test, deploy lại thành một quy trình chạy tự động. Nó điều phối quá trình đưa ứng dụng ra môi trường chạy, chứ không thêm bất kỳ tính năng AWS nào vào bên trong ứng dụng. Ứng dụng sau khi qua CodePipeline vẫn không tự gọi được dịch vụ AWS nào nếu mã nguồn không có SDK.

D. AWS CodeDeploy — dùng để triển khai mã từ kho mã và thực sự cài đặt ứng dụng lên môi trường đích. Cũng như CodePipeline, đây là công cụ của giai đoạn sau khi đã viết xong mã. Nó trả lời câu hỏi "làm sao đưa ứng dụng này lên chạy", không trả lời câu hỏi "làm sao ứng dụng này gọi được dịch vụ AWS".

📌 Điểm cần nhớ

• Thấy cụm "integrate ... directly into the application", "call AWS from code", hay tên một ngôn ngữ lập trình trong đề → nghĩ ngay tới SDK.
• Phân biệt hai tầng: SDK và CLI là hai cách con người/chương trình gọi API AWS — SDK nhúng trong mã ứng dụng, CLI chạy lệnh từ terminal hay script. Đề nói "trong ứng dụng" thì chọn SDK; đề nói "chạy lệnh", "script tự động hoá tác vụ quản trị" thì chọn CLI.
• CodePipeline và CodeDeploy thuộc giai đoạn phát hành, không thuộc giai đoạn viết mã: CodePipeline điều phối cả vòng đời release, CodeDeploy lo phần cài đặt ứng dụng lên môi trường đích. Chúng không bao giờ là đáp án cho câu hỏi về cách ứng dụng tương tác với dịch vụ AWS lúc chạy.
• Khi cả bốn phương án cùng nằm trong nhóm AWS Developer Tools, hãy hỏi: công cụ này tác động ở thời điểm nào — lúc viết mã, lúc phát hành, hay lúc ứng dụng đang chạy? Trả lời được câu đó thường là loại ngay được ba phương án.

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

Đề hỏi: một người mới dùng AWS nên tìm tới tài nguyên nào để được giúp triển khai các công nghệ phổ biến theo AWS best practices, và gói giúp đỡ đó phải bao gồm cả kiến trúc lẫn hướng dẫn triển khai từng bước ("including architecture and deployment instructions").

Cụm từ quyết định là "architecture and deployment instructions" — tức thứ được hỏi không chỉ là một công cụ để chạy triển khai, mà là một gói tài liệu + bản dựng sẵn do AWS và đối tác biên soạn: có tài liệu mô tả kiến trúc, có hướng dẫn thao tác, và có sẵn khuôn triển khai để chạy. Cụm thứ hai là "popular technologies" — nghĩa là những phần mềm/nền tảng thông dụng đã được đóng gói sẵn, chứ không phải hạ tầng do chính người dùng tự mô tả.

Ràng buộc này tách bạch rất rõ: một bên là giải pháp đóng gói kèm hướng dẫn, bên kia là công cụ để tự làm.

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

D — AWS Partner Solutions là đáp án đúng.

AWS Partner Solutions (trước đây quen gọi là Quick Starts) do solutions architect của AWS và các đối tác xây dựng, nhằm giúp triển khai các công nghệ phổ biến trên AWS theo best practices về bảo mật và tính sẵn sàng cao. Mỗi giải pháp gồm hai phần khớp đúng với chữ trong đề:

• CloudFormation template tự động hoá phần triển khai;
• Deployment guide trình bày kiến trúc và hướng dẫn triển khai theo từng bước.

Nhờ vậy hàng trăm thao tác thủ công rút lại còn vài bước, đúng nhu cầu của một người mới chưa đủ kinh nghiệm để tự thiết kế kiến trúc chuẩn.

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

C — AWS CloudFormation: đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi. CloudFormation đúng là công cụ triển khai hạ tầng từ template — nhưng nó chỉ là cơ chế thực thi, bản thân nó không cung cấp sẵn kiến trúc tham chiếu hay hướng dẫn triển khai cho các công nghệ phổ biến. Người dùng phải tự viết template, tức tự quyết định kiến trúc — đúng thứ mà người mới đang cần được giúp. Quan hệ thật giữa hai phương án là: Partner Solutions dùng CloudFormation làm công cụ bên trong. Chọn C là chọn phần con thay vì chọn thứ được hỏi.

A — AWS Artifact: đây là cổng truy cập theo yêu cầu tới các báo cáo bảo mật và tuân thủ của AWS (ví dụ tài liệu kiểm toán, thoả thuận liên quan tới tuân thủ). Nó phục vụ đội pháp lý/tuân thủ, hoàn toàn không liên quan tới việc triển khai công nghệ hay hướng dẫn kiến trúc.

B — AWS Config: dịch vụ theo dõi và đánh giá cấu hình của tài nguyên AWS, dùng cho mục đích tuân thủ và ghi nhận thay đổi cấu hình theo thời gian. Nó nhìn vào những gì đã tồn tại trong tài khoản để kiểm tra có đúng quy tắc không, chứ không giúp dựng mới một hệ thống theo best practices. Hai chữ "best practices" trong đề dễ khiến liên tưởng tới Config rules, nhưng đề hỏi về triển khai, không phải kiểm tra tuân thủ.

📌 Điểm cần nhớ

• Đề nhắc tới "architecture and deployment instructions" đi kèm nhau → đang hỏi một gói giải pháp có tài liệu, không phải một công cụ triển khai đơn thuần.
• AWS Partner Solutions (Quick Starts) = kiến trúc tham chiếu + hướng dẫn + CloudFormation template dựng sẵn, do AWS và đối tác biên soạn theo best practices.
• Khi hai phương án có quan hệ "cái này dùng cái kia" — như Partner Solutions dùng CloudFormation — hãy chọn lớp phù hợp với mức độ trợ giúp mà đề mô tả; đề nhấn "new user" thì lớp cao hơn thường đúng.
• Phân biệt cặp dễ lẫn: AWS Artifact = tải báo cáo tuân thủ; AWS Config = theo dõi/đánh giá cấu hình tài nguyên hiện có. Cả hai thuộc nhóm governance, không phải nhóm triển khai.

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

Đề hỏi: AWS có thể liên tục giảm giá là nhờ đâu? Cụm từ quyết định nằm ở hai chỗ: "AWS are able to" — chủ ngữ là AWS, tức là hỏi về nguyên nhân phía nhà cung cấp, không phải lợi ích mà khách hàng cảm nhận được; và "continually reduce their pricing" — nói về việc đơn giá thực sự bị hạ xuống theo thời gian, chứ không phải việc khách hàng trả ít tiền hơn nhờ dùng khéo.

Đây chính là ràng buộc phân biệt bốn phương án. Ba trong bốn phương án đều là những thứ giúp hoá đơn của khách hàng nhỏ đi, nhưng chỉ một phương án giải thích được vì sao bảng giá niêm yết của AWS ngày càng rẻ. Đọc lướt mà bỏ qua chữ "their pricing" là rất dễ chọn nhầm sang một trong ba cái kia, vì cái nào cũng "liên quan tới tiết kiệm chi phí".

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

A — Economies of scale (lợi thế kinh tế theo quy mô). Đây là đáp án đúng theo tệp và cũng khớp với tài liệu chính thức của AWS về sáu lợi ích của cloud computing.

Lập luận rất thẳng: khi nhu cầu sử dụng của hàng trăm nghìn khách hàng được gộp lại trong cùng một hạ tầng cloud, AWS mua sắm phần cứng, điện năng, băng thông và vận hành trung tâm dữ liệu ở quy mô rất lớn. Quy mô càng lớn thì chi phí trên mỗi đơn vị tài nguyên càng giảm. Phần chi phí tiết kiệm được đó được AWS chuyển thành giá pay-as-you-go thấp hơn cho khách hàng. Đây là lý do mang tính cấu trúc, nằm ở phía nhà cung cấp — nó giải thích được cái mà đề hỏi: vì sao mức giá cứ hạ dần theo thời gian.

Nói cách khác: economies of scale là nguyên nhân, còn giá thấp là kết quả. Ba phương án còn lại đều nằm ở phía kết quả hoặc phía cách khách hàng tiêu tiền.

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

C — Pay-as-you-go pricing. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì nó xuất hiện ngay trong lời giải thích của đáp án đúng. Nhưng nó bị đảo ngược quan hệ nhân quả: pay-as-you-go là mô hình tính tiền — bạn trả theo lượng dùng thực tế, không phải trả trước một cục. Nó quyết định cách bạn bị tính tiền, chứ không quyết định đơn giá là bao nhiêu. Chính economies of scale mới kéo đơn giá pay-as-you-go xuống. Đây là lợi ích cho khách hàng, không phải lý do AWS hạ giá.

B — Elastic compute services. Elasticity cho phép bạn tăng giảm tài nguyên theo nhu cầu, nhờ đó chi phí bám sát tải thật thay vì phải mua dư để chịu lúc cao điểm. Kết quả là hoá đơn của bạn giảm, nhưng bảng giá của AWS không đổi một đồng nào vì chuyện đó. Nó là công cụ tối ưu chi phí phía người dùng, hoàn toàn không trả lời được câu hỏi "vì sao AWS hạ giá".

D — Compute savings plans. Đây là hình thức cam kết một mức chi tiêu compute nhất định trong một kỳ hạn để đổi lấy mức chiết khấu so với giá on-demand. Điểm hỏng của nó giống hệt hai phương án trên, chỉ khác vẻ ngoài: đó là một cơ chế giảm giá dành cho khách hàng chịu cam kết, tức là bạn được trả rẻ hơn so với giá niêm yết. Bản thân giá niêm yết hạ xuống theo thời gian vẫn là chuyện khác, và savings plans không phải nguyên nhân của việc đó.

📌 Điểm cần nhớ

• Đọc kỹ chủ ngữ của câu hỏi. "Vì sao AWS giảm giá" hỏi về nguyên nhân phía nhà cung cấp; "làm sao tôi trả ít tiền hơn" mới là câu hỏi về công cụ tối ưu chi phí. Cùng một bộ phương án có thể phục vụ hai câu hỏi hoàn toàn khác nhau.
• Economies of scale là câu trả lời chuẩn cho mọi biến thể hỏi "tại sao cloud rẻ hơn tự dựng hạ tầng" hoặc "tại sao giá cloud ngày càng giảm" — gộp nhu cầu của rất nhiều khách hàng kéo chi phí đơn vị xuống.
• Phân biệt ba nhóm dễ lẫn: mô hình tính tiền (pay-as-you-go), cơ chế chiết khấu (savings plans), và kỹ thuật tối ưu (elasticity). Cả ba đều tác động lên hoá đơn, không cái nào là lý do đơn giá bị hạ.
• Khi nhiều phương án cùng "đúng về mặt tiết kiệm chi phí", hãy tìm phương án nằm ở tầng nguyên nhân gốc. Phương án xuất hiện trong lời giải thích của phương án khác (như pay-as-you-go ở đây) thường là hệ quả, không phải nguyên nhân.