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

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

Đề hỏi: khi một công ty chuyển website đang chạy on-premises, hướng ra Internet, lên AWS Cloud thì họ nhận được lợi ích gì (chọn HAI).

Cụm từ quyết định là "what benefits does it obtain" đi kèm bối cảnh "moves an on-premises, internet-facing website to the AWS Cloud". Hai chữ khoá cần bám:

• "benefits ... obtain" — phải là thứ tự bản thân mô hình cloud mang lại, chứ không phải thứ khách hàng còn phải tự bật, tự cấu hình, hoặc thứ nằm ngoài phạm vi AWS.
• "internet-facing website" — website hướng Internet thì lưu lượng lên xuống thất thường, đó là cái nhử để bạn nhận ra khái niệm elasticity.

Cái bẫy của câu này nằm ở chữ "automatically" trong hai phương án nhiễu: nghe rất giống lợi ích thật, nhưng AWS không tự động làm hộ những việc đó.

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

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

A — "Website capacity can expand or contract as website traffic changes": đây chính là định nghĩa của elasticity — lấy thêm tài nguyên khi cần và trả lại khi không cần nữa. Với một website hướng Internet, lượng truy cập thay đổi theo giờ, theo chiến dịch, theo mùa; hạ tầng on-premises phải mua sẵn theo đỉnh và ngồi nhìn nó nhàn rỗi phần lớn thời gian. Đây là một trong những lợi ích được nêu ngay trong tài liệu six advantages of cloud computing của AWS.

D — "The company can take advantage of the pay-as-you-go pricing model": chuyển lên cloud nghĩa là bỏ khoản chi trả trước cho phần cứng (CAPEX) để sang mô hình OPEX — chỉ trả cho phần tài nguyên thực sự dùng. Hai đáp án này ăn khớp nhau: elasticity co giãn tài nguyên, còn pay-as-you-go biến việc co giãn đó thành tiết kiệm chi phí thật.

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

B — "AWS automatically provides the company with the lowest-cost pricing model": sai vì đơn giản là không đúng sự thật. Giá phụ thuộc rất nhiều yếu tố và AWS có nhiều mô hình mua khác nhau; việc chọn mô hình rẻ nhất cho khối lượng công việc của mình là trách nhiệm của khách hàng, không có cơ chế nào tự động đặt bạn vào mức giá thấp nhất. Đây là phương án gần đúng nhất với D — cả hai đều nói về giá — nhưng D nói về mô hình thanh toán bạn được dùng, còn B hứa AWS tự tối ưu chi phí hộ bạn. Chữ "automatically" là chỗ nó hỏng.

C — "Data that is stored in the AWS Cloud is automatically encrypted": sai vì mã hoá dữ liệu nằm ở phía khách hàng trong Shared Responsibility Model — khách hàng chịu trách nhiệm bảo vệ dữ liệu của mình. AWS cung cấp sẵn công cụ để mã hoá, nhưng đó là thứ bạn bật và cấu hình, không phải thứ bật sẵn cho mọi trường hợp. Lại là chữ "automatically" làm phương án này sai.

E — "The website shows up with higher priority in internet search engines": sai vì SEO nằm hoàn toàn ngoài phạm vi của AWS. Thứ hạng tìm kiếm do các công cụ tìm kiếm quyết định dựa trên nội dung, liên kết, trải nghiệm người dùng — đổi nhà cung cấp hạ tầng không tự đẩy website lên cao hơn. Đây là phương án dễ loại nhất.

📌 Điểm cần nhớ

• Elasticity = lấy tài nguyên khi cần, trả lại khi không cần. Thấy đề mô tả tải thay đổi lên xuống, hoặc "expand or contract", gần như chắc chắn đang hỏi khái niệm này.
• Chuyển lên cloud là chuyển từ CAPEX sang OPEX: không trả trước cho phần cứng, chỉ trả theo mức dùng (pay-as-you-go).
• Cảnh giác với chữ "automatically" trong các phương án ở đề Cloud Practitioner. Mã hoá dữ liệu, tối ưu chi phí, cấu hình bảo mật đều là phần khách hàng phải tự làm theo Shared Responsibility Model — AWS cho công cụ chứ không bật hộ.
• Những gì AWS không đụng tới thì không thể là lợi ích của việc lên cloud. SEO là ví dụ điển hình: nó thuộc về nội dung và công cụ tìm kiếm, không thuộc về hạ tầng.

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

Đề hỏi rất ngắn: "How does 'elasticity' benefit an application design?" — elasticity mang lại lợi ích gì cho thiết kế ứng dụng.

Cụm từ quyết định là chính thuật ngữ "elasticity". Đây là loại câu kiểm tra xem thí sinh có phân biệt được bốn khái niệm nền tảng của AWS Cloud hay không, vì cả bốn phương án đều là lợi ích có thật của cloud — chỉ có một cái đúng tên gọi "elasticity". Ba phương án còn lại lần lượt mô tả loose coupling, reservations (Reserved Instances) và right-sizing.

Chi tiết thứ hai đáng để ý: đề hỏi về cách nó mang lại lợi ích ("how does it benefit"), nên đáp án phải mô tả đúng cơ chế — tự động thêm/bớt tài nguyên — chứ không phải một kết quả tài chính chung chung như "giảm chi phí".

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

A. By automatically scaling resources based on demand — đúng theo tệp.

Elasticity là khả năng tự động co giãn tài nguyên theo nhu cầu thực tế tại từng thời điểm. Ứng dụng chỉ cấp phát đúng lượng tài nguyên cần dùng: nhu cầu tăng thì thêm capacity, nhu cầu giảm thì trả bớt về.

Lợi ích với thiết kế ứng dụng có hai mặt, đúng như phần giải thích gốc nêu:

• Tối ưu chi phí — không phải trả tiền cho phần capacity ngồi không trong giờ thấp điểm.
• Hấp thụ được các đợt tăng đột biến (spikes) — kiến trúc sư không cần dự đoán trước đỉnh tải rồi mua dư phòng hờ như mô hình on-premises truyền thống.

Đây chính là điểm khác biệt căn bản giữa cloud và data center tự vận hành: ở data center, capacity là một quyết định mua sắm cố định; trên cloud, nó là một tham số thay đổi theo thời gian chạy.

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

B. By reducing interdependencies between application components — Giảm sự phụ thuộc lẫn nhau giữa các thành phần là mô tả của loose coupling, một nguyên tắc kiến trúc hoàn toàn khác. Đây là phương án dễ nhầm nhất với người đã đọc qua Well-Architected Framework, vì loose coupling và elasticity thường được nhắc cạnh nhau — loose coupling tạo điều kiện để scale từng thành phần độc lập. Nhưng "tạo điều kiện cho" không phải là "định nghĩa của". Bản thân elasticity không hề làm các component bớt phụ thuộc vào nhau.

C. By reserving capacity to reduce cost — Đặt trước capacity để giảm giá là mô tả của reservations, ví dụ EC2 Reserved Instances. Phương án này thực ra ngược hướng với elasticity: reservation là cam kết một mức capacity cố định trong thời hạn dài để đổi lấy đơn giá rẻ hơn, còn elasticity là để mức capacity tự do dao động. Cả hai đều giảm chi phí nhưng bằng hai cơ chế trái nhau, và chữ "reserving" là dấu hiệu nhận diện rõ ràng.

D. By selecting the correct storage tier for your workload — Chọn đúng storage tier cho workload là ví dụ của right-sizing: chọn đúng loại và đúng cỡ tài nguyên cho nhu cầu. Right-sizing là một quyết định con người đưa ra dựa trên đặc tính workload, mang tính tĩnh; elasticity là điều chỉnh tự động theo tải, mang tính động. Ngoài ra phương án này chỉ nói về storage, trong khi elasticity áp dụng cho tài nguyên nói chung.

📌 Điểm cần nhớ

• Elasticity = tự động co giãn theo demand. Thấy chữ "automatically" và "based on demand" trong phương án là dấu hiệu gần như chắc chắn.
• Bốn khái niệm hay bị hoán đổi trong đề thi Cloud Practitioner: elasticity (co giãn tự động), loose coupling (giảm phụ thuộc giữa component), reservations (cam kết capacity để lấy giá rẻ), right-sizing (chọn đúng loại/cỡ tài nguyên). Học thuộc nhãn của từng cái là gỡ được cả một nhóm câu hỏi.
• Đừng chọn theo "lợi ích nghe hợp lý" — cả bốn phương án đều là lợi ích thật của cloud. Câu hỏi kiểm tra tên gọi, không kiểm tra tính đúng đắn của phát biểu.
• Reservation và elasticity giải quyết chi phí theo hai hướng đối lập: một bên cam kết capacity cố định, một bên để capacity dao động. Chữ "reserve/commit/1-year/3-year" luôn thuộc nhóm reservation, không bao giờ là elasticity.

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

Đề bài đặt bối cảnh phân tích TCO (total cost of ownership) khi so sánh giữa hạ tầng on-premises và AWS Cloud, rồi hỏi: yếu tố nào chỉ liên quan tới on-premises (Select TWO).

Cụm từ quyết định đáp án là "only relevant to on-premises deployments". Chữ only mới là điểm phân biệt, chứ không phải "on-premises". Rất nhiều phương án đúng là chi phí có thật trong trung tâm dữ liệu riêng — nhưng nếu chi phí đó vẫn còn tồn tại sau khi lên AWS, nó xuất hiện ở cả hai vế của phép so sánh và vì thế không phải thứ đề đang hỏi.

Nói cách khác, câu hỏi thực chất là: khoản nào biến mất hoàn toàn khi bạn không còn tự vận hành phần cứng và toà nhà nữa? Bài toán TCO chỉ có ý nghĩa khi ta gom đúng những khoản một bên có mà bên kia không, để thấy được cái giá thật của việc tiếp tục ở lại data center của mình.

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

Đáp án là A – Facility operations costs và C – Hardware procurement teams.

• A. Facility operations costs — chi phí vận hành cơ sở vật chất: mặt bằng, điện, làm mát, nguồn dự phòng, an ninh vật lý, nhân sự trực trung tâm dữ liệu. Khi chạy trên AWS, toàn bộ lớp này thuộc trách nhiệm của AWS và đã nằm trong giá dịch vụ; khách hàng không còn khoản chi riêng nào cho nó. Đây đúng nghĩa là chi phí chỉ có ở phía on-premises.
• C. Hardware procurement teams — đội ngũ mua sắm phần cứng: khảo sát nhà cung cấp, đàm phán, đặt hàng máy chủ và thiết bị mạng, chờ giao, lắp đặt, thay thế khi hỏng, dự báo nhu cầu vài năm tới. Trên AWS, tài nguyên được cấp phát theo yêu cầu nên chu trình mua sắm này không còn, kéo theo cả chi phí nhân sự làm việc đó.

Cả hai đều thuộc nhóm chi phí hạ tầng vật lý — đúng phần mà mô hình chia sẻ trách nhiệm chuyển sang cho AWS.

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

• B. Database administration — đây là phương án gần đúng nhất và cũng dễ bẫy nhất. Đúng là các dịch vụ managed giảm bớt việc quản trị, nhưng công việc DBA không biến mất: vẫn phải thiết kế schema, đánh index, tối ưu truy vấn, phân quyền, theo dõi hiệu năng, lập kế hoạch dung lượng. Nó tồn tại ở cả hai mô hình, nên không thoả điều kiện "only". Chỗ nó hỏng là ở chữ only, không phải ở chỗ nó có phải chi phí hay không.
• D. Application licensing — bản quyền phần mềm ứng dụng gắn với chính phần mềm bạn chạy, không gắn với nơi đặt máy. Chuyển ứng dụng lên AWS thì vẫn phải trả bản quyền cho nó (mua riêng, hoặc mang giấy phép sẵn có sang, hoặc tính gộp trong giá dịch vụ). Có ở cả hai vế → không phải đáp án.
• E. Operating system licensing — cùng lý do như D. Chạy hệ điều hành có bản quyền trên EC2 thì chi phí bản quyền vẫn phát sinh, chỉ khác cách trả: thay vì mua rời, nó thường nằm luôn trong giá theo giờ của instance. Người học hay nhầm "đã nằm trong giá instance" thành "không còn chi phí" — nhưng nằm trong giá vẫn là đang trả tiền, và khoản đó xuất hiện ở cả hai phía của phép so sánh.

Điểm chung của B, D, E: chúng là chi phí phần mềm và con người vận hành phần mềm, thứ đi theo workload chứ không đi theo trung tâm dữ liệu.

📌 Điểm cần nhớ

• Với câu TCO kiểu này, hãy dịch câu hỏi thành: "khoản nào biến mất hoàn toàn sau khi chuyển lên AWS?" — nếu khoản đó vẫn còn dù ít hơn, nó không phải đáp án.
• Chi phí cơ sở vật chất và phần cứng (mặt bằng, điện, làm mát, mua sắm và thay thế thiết bị, đội ngũ lo việc đó) là nhóm đặc trưng chỉ có ở on-premises.
• Chi phí bản quyền phần mềm (application licensing, operating system licensing) và quản trị phần mềm (database administration) tồn tại ở cả hai mô hình — chỉ đổi cách thanh toán, không mất đi.
• Đọc kỹ các từ giới hạn trong đề: only, always, never, primarily. Trong câu này chỉ một chữ only đã loại được ba phương án vốn đều là chi phí có thật.

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

Đề hỏi: một tổ chức cần làm gì để bắt đầu dùng thêm một AWS region khác.

Cụm từ quyết định nằm ngay ở động từ "move to another AWS region" — tức là chuyển sang / mở rộng sang một region khác, chứ không phải mở thêm một tổ chức mới, không phải xin thêm quyền, không phải dựng lại danh tính. Ba phương án A, B, C đều giả định rằng region là một ranh giới hành chính cần thủ tục đăng ký hoặc cần bản sao tài khoản/danh tính riêng. Phương án D giả định region chỉ là một ranh giới vật lý trong cùng một tài khoản.

Đây chính là điểm phân biệt: trong AWS, một tài khoản đã tồn tại thì mặc nhiên dùng được các region, và IAM là dịch vụ global — không gắn với region nào cả.

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

D — "Just start deploying resources in the additional region".

Đúng theo phần giải thích gốc: không cần làm gì thêm ngoài việc bắt đầu triển khai tài nguyên trong region mới. Với AWS cloud, tổ chức có thể dùng region ở bất kỳ đâu trên thế giới, bất cứ lúc nào, trên chính tài khoản đang có. Không cần tài khoản riêng, và cũng không cần dựng danh tính riêng vì IAM là dịch vụ global — user, group, role và policy đã có sẵn hiệu lực khi làm việc ở region mới.

Về mặt thao tác thực tế, người dùng chỉ cần đổi region đang chọn trên console (hoặc đổi tham số region trong CLI/SDK) rồi tạo tài nguyên. Chi phí và hạn mức vẫn nằm trong cùng một tài khoản, hoá đơn vẫn là một.

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

A — "Apply for another AWS account in that region" Sai vì tài khoản AWS không thuộc về một region. Một tài khoản duy nhất truy cập được các region, và IAM dùng chung xuyên region nên không có lý do kỹ thuật nào bắt phải mở tài khoản thứ hai. Đây là phương án "gần đúng" duy nhất theo nghĩa: tổ chức có thể chọn tách tài khoản vì lý do quản trị, cách ly môi trường hay tách hoá đơn — nhưng đề hỏi tổ chức cần làm gì để dùng region khác, mà việc tách tài khoản không phải điều kiện cần. Nó hỏng ở chỗ biến một lựa chọn quản trị tuỳ ý thành một yêu cầu bắt buộc.

B — "Submit an application to extend their account to the additional region" Sai vì không tồn tại thủ tục "xin mở rộng tài khoản sang region". Không có đơn từ, không có quy trình duyệt của AWS cho việc này. Phương án này mô tả mô hình đăng ký kiểu nhà cung cấp hạ tầng truyền thống — phải ký hợp đồng cho từng trung tâm dữ liệu — chứ không phải mô hình self-service của cloud. Đúng ra điểm mấu chốt của mô hình cloud mà kỳ thi Cloud Practitioner muốn kiểm tra chính là: dùng ngay, không qua thủ tục.

C — "Create a separate IAM account for that region" Sai vì IAM là dịch vụ global. IAM user, group, role và policy không được tạo "trong một region"; chúng có hiệu lực trên toàn tài khoản. Đây là phương án dễ bẫy nhất, vì người học hay nhớ rằng "nhiều dịch vụ AWS mang tính region" rồi suy rộng cho cả IAM. Nó hỏng ngay ở tiền đề: không có khái niệm "IAM account của một region" để mà tạo.

📌 Điểm cần nhớ

• IAM là dịch vụ global, không gắn region. Danh tính và quyền đã cấp có hiệu lực khi làm việc ở mọi region trong cùng tài khoản — gặp phương án nào nói "tạo IAM riêng cho region" thì loại ngay.
• Region không phải ranh giới hành chính. Một tài khoản AWS dùng được các region mà không cần đơn từ, hợp đồng hay tài khoản bổ sung; chỉ cần chọn region rồi triển khai.
• Trong đề thi, các phương án chứa động từ mang màu thủ tục — apply, submit an application, request approval — gần như luôn sai khi câu hỏi nói về việc bắt đầu dùng một region. Tinh thần của cloud là self-service.
• Phân biệt hai nhóm dịch vụ: global (IAM, và một số dịch vụ hạ tầng chung) so với theo region (nơi tài nguyên tính toán, lưu trữ thực sự nằm). Sai lầm thường gặp là áp tính chất theo-region lên các dịch vụ global.

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

Đề hỏi: lợi ích chính của nguyên tắc "loose coupling" (ghép nối lỏng) là gì.

Cụm từ quyết định ở đây là "main benefit" đi kèm chính thuật ngữ "loose coupling". Bốn phương án đều mô tả những điều tốt đẹp trong kiến trúc cloud — giảm phức tạp vận hành, tự động co giãn, giảm phụ thuộc lẫn nhau, tự động triển khai hạ tầng bằng code. Nhưng mỗi mô tả đó lại là định nghĩa của một nguyên tắc khác nhau. Câu này thực chất là bài kiểm tra ghép tên nguyên tắc ↔ định nghĩa nguyên tắc, chứ không phải kiểm tra "cái nào có lợi hơn".

Vì vậy cách làm đúng là: đọc định nghĩa gốc của loose coupling trong AWS Well-Architected Framework — hệ thống được chia thành các thành phần nhỏ, giảm sự phụ thuộc lẫn nhau (interdependencies), sao cho một thay đổi hoặc một sự cố ở thành phần này không lan sang thành phần khác — rồi tìm phương án nào chép đúng ý đó.

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

C. Reduce interdependencies so a failure in one component does not cascade to other components.

Đây chính là định nghĩa của loose coupling. Khi các thành phần giao tiếp qua ranh giới rõ ràng (interface, hàng đợi, sự kiện) thay vì gọi thẳng vào nhau và phụ thuộc vào trạng thái nội bộ của nhau, thì:

• Một thành phần chết không kéo theo thành phần gọi nó chết theo — lỗi bị chặn lại tại chỗ thay vì lan thành phản ứng dây chuyền (cascading failure).
• Một thành phần được sửa đổi, thay thế hay triển khai lại mà không buộc các thành phần khác phải đổi theo.

Cụm "does not cascade to other components" bám sát nguyên văn tài liệu AWS ("a change or a failure in one component should not cascade to other components"), nên đây là phương án khớp định nghĩa nhất.

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

A. Reduce operational complexity — Đây là phương án gần đúng nhất và cũng là bẫy chính. Nó nghe hợp lý vì "tách nhỏ ra cho dễ quản lý". Nhưng thực tế loose coupling không làm giảm độ phức tạp vận hành; nó thường làm tăng: nhiều thành phần chạy độc lập hơn, nhiều điểm giao tiếp giữa chúng hơn, nhiều thứ phải theo dõi và gỡ lỗi hơn. Cái loose coupling đánh đổi lấy là khả năng chịu lỗi (resilience), không phải sự đơn giản khi vận hành.

B. Enables applications to scale automatically based on current demand — Đây là mô tả của elasticity (tính co giãn), một nguyên tắc khác. Đúng là loose coupling tạo điều kiện để từng thành phần co giãn riêng, nhưng bản thân việc tự động thêm/bớt tài nguyên theo tải là chuyện của cơ chế auto scaling, không phải "lợi ích chính" định nghĩa nên loose coupling. Đề hỏi lợi ích chính, nên phương án mô tả một nguyên tắc khác bị loại.

D. Automate the deployment of infrastructure using code — Đây là Infrastructure as Code, thực hiện bằng những dịch vụ như CloudFormation. Nó nói về cách tạo ra hạ tầng, hoàn toàn không liên quan tới cách các thành phần trong ứng dụng phụ thuộc vào nhau lúc chạy. Phương án này lạc đề rõ nhất trong bốn phương án.

📌 Điểm cần nhớ

• Loose coupling = giảm phụ thuộc lẫn nhau để lỗi không lan dây chuyền. Nhớ đúng cụm "does not cascade" là nhận ra đáp án ngay.
• Với dạng câu hỏi "lợi ích chính của nguyên tắc X", các phương án sai thường là định nghĩa đúng của một nguyên tắc khác (elasticity, Infrastructure as Code, high availability...). Hãy gắn nhãn từng phương án xem nó thuộc nguyên tắc nào, thay vì cân nhắc cái nào "tốt hơn".
• Đừng nhầm loose coupling với "đơn giản hoá vận hành". Nó đánh đổi: tăng số thành phần và số điểm giao tiếp phải quản lý, đổi lấy khả năng chịu lỗi và thay đổi độc lập.
• Loose coupling hỗ trợ cho scaling độc lập từng thành phần, nhưng scaling tự động theo tải là elasticity — quan hệ hỗ trợ không đồng nghĩa với định nghĩa.

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

Đề mô tả một công ty muốn workload của mình: resilient (chịu được sự cố), perform correctly, consistently (chạy đúng và nhất quán), và recover from errors in a timely manner (phục hồi sau lỗi kịp thời). Sau đó hỏi: những yêu cầu này thuộc pillar nào của AWS Well-Architected Framework?

Cụm từ quyết định là "recover from errors in a timely manner" kết hợp với "perform correctly, consistently". Đây không phải câu hỏi về dịch vụ nào, mà là câu hỏi ánh xạ mô tả yêu cầu → tên pillar. Chìa khoá phân biệt: đề nói về khả năng workload làm đúng chức năng của nó khi được kỳ vọng, và tự phục hồi khi có lỗi — chứ không nói gì về việc chống tấn công, về quy trình vận hành hằng ngày, hay về việc chọn đúng loại/kích cỡ tài nguyên.

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

B. Reliability là đáp án đúng.

Pillar Reliability nói về khả năng của một workload thực hiện đúng chức năng đã định, một cách nhất quán, vào đúng lúc nó được kỳ vọng phải chạy. Nó bao trùm luôn khả năng vận hành và kiểm thử workload trong suốt vòng đời của nó.

Ba vế trong đề khớp gần như từng chữ với định nghĩa này:

• "resilient" → khả năng chịu và vượt qua sự cố hạ tầng/dịch vụ;
• "perform correctly, consistently" → đúng chức năng, nhất quán;
• "recover from errors in a timely manner" → phục hồi sau lỗi, vốn là trọng tâm của Reliability.

Khi đề bài trộn chung ba ý resilience + correctness + recovery, đó là chữ ký của Reliability chứ không phải pillar nào khác.

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

A. Security — Security nói về việc bảo vệ workload và hạ tầng khỏi bị tấn công hoặc khai thác: bảo vệ dữ liệu, quản lý danh tính và quyền truy cập, phát hiện sự kiện bảo mật. Đề bài không hề nhắc tới kẻ tấn công, quyền truy cập hay dữ liệu nhạy cảm — "errors" ở đây là lỗi vận hành, không phải sự cố an ninh. Loại.

C. Operational excellence — Đây là phương án gần đúng nhất và dễ bẫy nhất, vì nó cũng dính tới chuyện "hệ thống chạy tốt". Nhưng trọng tâm của nó là chạy và giám sát hệ thống, rồi liên tục cải tiến quy trình và thủ tục: tự động hoá thay đổi, phản ứng với sự kiện, đặt chuẩn để quản lý vận hành hằng ngày. Nó nói về cách tổ chức làm việc với hệ thống, chứ không bao gồm bản thân tính resilience và khả năng phục hồi của workload. Đề bài mô tả thuộc tính của chính workload, không mô tả quy trình của đội vận hành — nên rơi vào Reliability.

D. Performance efficiency — Pillar này nói về việc cấp phát tài nguyên IT và tính toán một cách có cấu trúc và tinh gọn: chọn đúng loại và kích cỡ tài nguyên cho nhu cầu workload, theo dõi hiệu năng, và duy trì hiệu quả khi nhu cầu kinh doanh thay đổi. Chữ "perform" trong đề dễ khiến người học nhảy sang đây, nhưng đề nói "perform correctly, consistently" — tức là đúng, không phải nhanh hay tiết kiệm tài nguyên. Performance efficiency quan tâm tốc độ và độ phù hợp của tài nguyên, không quan tâm chuyện phục hồi sau lỗi.

📌 Điểm cần nhớ

• Đọc kỹ tính từ đi kèm động từ: "perform correctly/consistently" → Reliability, còn "perform fast / with the right resource type and size" → Performance efficiency. Một chữ "correctly" đủ đổi đáp án.
• Bất cứ khi nào đề nhắc tới recovery, resilience, chịu lỗi, khôi phục sau sự cố → nghĩ Reliability trước tiên.
• Operational excellence là về con người và quy trình (tự động hoá, giám sát, cải tiến thủ tục), Reliability là về thuộc tính của workload. Đây là cặp hay bị nhầm nhất trong đề Cloud Practitioner.
• Với dạng câu "mô tả yêu cầu → tên pillar", đừng đọc lướt rồi chọn theo từ khoá đơn lẻ; hãy soi cả cụm ràng buộc, vì đề cố tình cài từ dễ gây nhiễu (như "perform") thuộc về pillar khác.

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

Đề hỏi: công cụ nào dùng để tạo cảnh báo (alerts) khi chi phí thực tế hoặc dự báo của các dịch vụ AWS vượt một ngưỡng nhất định.

Cụm từ quyết định đáp án là "create alerts ... exceed a certain threshold" — tức là cần một công cụ chủ động gửi thông báo khi chạm ngưỡng, chứ không phải công cụ để xem lại hay xuất báo cáo chi phí. Cụm phụ "or forecasted" càng siết chặt thêm: công cụ phải biết dự báo chi phí cuối kỳ và cảnh báo trước khi con số thực tế kịp vượt ngưỡng.

Cả bốn phương án đều liên quan tới việc "nhìn thấy" thứ gì đó trong tài khoản AWS, nhưng chỉ một cái có cơ chế đặt ngưỡng + bắn cảnh báo.

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

C. AWS Budgets là đáp án đúng.

AWS Budgets cho phép bạn đặt ngân sách tuỳ chỉnh (custom budget) theo chi phí hoặc mức sử dụng, rồi nhận cảnh báo khi con số thực tế vượt ngưỡng, hoặc khi con số dự báo được cho là sẽ vượt ngưỡng đó. Đây chính xác là hai vế "actual or forecasted" mà đề nêu — không phương án nào khác có vế dự báo.

Ngoài ngân sách chi phí và mức sử dụng, AWS Budgets còn đặt được mục tiêu về reservation utilization / coverage và cảnh báo khi tỷ lệ tụt xuống dưới ngưỡng bạn định. Cảnh báo dạng reservation này hỗ trợ các dịch vụ có mô hình đặt trước như Amazon EC2, Amazon RDS, Amazon Redshift, Amazon ElastiCache và Amazon Elasticsearch. Chi tiết này không cần cho việc chọn đáp án, nhưng nó cho thấy Budgets là dịch vụ được thiết kế xoay quanh ngưỡng và thông báo.

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

A. AWS CloudTrail — sai và lệch hẳn chủ đề. CloudTrail ghi lại hoạt động API trong tài khoản: ai gọi, gọi gì, lúc nào, từ đâu. Nó phục vụ kiểm toán và điều tra bảo mật, không theo dõi số tiền và không cảnh báo dựa trên mức sử dụng dịch vụ. Thấy CloudTrail trong một câu hỏi về chi phí thì gần như chắc chắn nó là mồi nhử.

B. AWS Cost Explorer — đây là phương án gần đúng nhất và là bẫy chính của câu này. Cost Explorer đúng là công cụ của mảng cost management, có biểu đồ, lọc theo dịch vụ/tag, và cũng có phần dự báo chi phí. Nhưng vai trò của nó là trực quan hoá và phân tích để bạn hiểu tiền đi đâu — bạn phải chủ động mở ra xem. Nó không phải nơi bạn khai báo ngưỡng để hệ thống tự bắn thông báo. Đề hỏi "create alerts", nên việc thiết lập ngưỡng và cảnh báo thuộc về AWS Budgets. Cách phân biệt gọn: Cost Explorer = xem, AWS Budgets = báo.

D. AWS Cost and Usage Report — cũng là công cụ mảng chi phí nên dễ bị chọn nhầm. CUR là bộ báo cáo chi tiết nhất về chi phí và mức sử dụng, chia nhỏ theo dịch vụ và nhiều chiều phân loại, xuất ra để bạn tự phân tích sâu. Vấn đề vẫn y hệt phương án B: nó là dữ liệu tĩnh để bạn đọc và xử lý, hoàn toàn thụ động — không có khái niệm ngưỡng, không có cơ chế gửi cảnh báo khi vượt ngưỡng.

📌 Điểm cần nhớ

• Trong nhóm công cụ chi phí của AWS, hãy tách theo hành vi: AWS Budgets đặt ngưỡng và cảnh báo, Cost Explorer trực quan hoá để phân tích, Cost and Usage Report xuất dữ liệu chi tiết nhất để tự xử lý.
• Từ khoá "alert", "notify", "threshold", "forecasted" trong đề bài về chi phí gần như luôn trỏ tới AWS Budgets.
• AWS CloudTrail thuộc mảng ghi log hoạt động API (kiểm toán, bảo mật), không liên quan tới theo dõi chi phí — dù nó hay xuất hiện làm mồi nhử.
• Cost Explorer có dự báo chi phí, nhưng có dự báo khác với cảnh báo dựa trên dự báo; chỉ AWS Budgets làm vế thứ hai.

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

Đề bài mô tả một công ty cần data warehouse để chạy analytical tasks, và bắt buộc kho dữ liệu đó phải hỗ trợ standard SQL queries.

Cụm từ quyết định là "data warehouse" — không phải "SQL". Bốn phương án trong đề đều dính dáng tới SQL ở mức nào đó, nên nếu chỉ bám vào chữ "standard SQL" thì câu này có tới ba đáp án nghe hợp lý. Ràng buộc thật nằm ở chỗ đề đòi đúng một data warehouse: nơi lưu trữ dữ liệu đã tổ chức sẵn cho phân tích, tức là hệ thống thiết kế cho OLAP (online analytics processing) chứ không phải OLTP (online transaction processing), cũng không phải công cụ truy vấn ngoài hay nền tảng xử lý dữ liệu lớn.

Cách đọc đúng: "data warehouse" chọn ra dịch vụ, "standard SQL" chỉ là điều kiện xác nhận thêm.

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

Đáp án đúng theo tệp là C — Amazon Redshift.

Amazon Redshift chính là dịch vụ data warehouse của AWS. Nó dùng SQL để phân tích dữ liệu có cấu trúc và bán cấu trúc trải trên data warehouse, operational database và data lake, chạy trên phần cứng do AWS thiết kế riêng kết hợp machine learning để tối ưu tỷ lệ giá/hiệu năng ở mọi quy mô.

Điểm mấu chốt cho kỳ thi: data warehouse được xây trên các cơ sở dữ liệu thiết kế cho tình huống OLAP. Redshift là dịch vụ duy nhất trong danh sách mang đúng danh xưng "data warehouse" của AWS, và nó đáp ứng luôn yêu cầu standard SQL. Cả hai vế của đề đều thoả.

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

A — Amazon Athena. Đây là phương án gần đúng nhất về mặt SQL: Athena là dịch vụ truy vấn serverless, cho phép bạn truy vấn dữ liệu nằm trên S3 bằng standard SQL. Nó hỏng ở vế còn lại của đề — Athena không phải một data warehouse. Nó không lưu trữ và không tổ chức dữ liệu; nó là lớp truy vấn đọc dữ liệu để nguyên chỗ cũ trên S3. Đề đòi "a data warehouse", tức là một hệ thống lưu trữ phân tích, chứ không đòi "một cách chạy SQL lên dữ liệu có sẵn".

B — Amazon RDS. RDS hỗ trợ standard SQL rất tốt nên dễ bị chọn nhầm, nhưng nó thường được dùng làm cơ sở dữ liệu OLTP chứ không phải OLAP. OLTP tối ưu cho nhiều giao dịch nhỏ, đọc/ghi từng bản ghi — mô hình của ứng dụng nghiệp vụ. Data warehouse cần mô hình ngược lại: quét khối lượng lớn để tổng hợp, phân tích. Đề nói rõ "in order to perform analytical tasks", nên RDS lệch mục đích.

D — Amazon EMR. EMR là nền tảng big data trên cloud để chạy các job xử lý dữ liệu phân tán quy mô lớn, truy vấn SQL tương tác, và ứng dụng machine learning, dựa trên các framework analytics mã nguồn mở như Apache Spark, Apache Hive và Presto. Nó có chạy được SQL (qua Hive, Presto), nhưng nó là một cluster xử lý chứ không phải một data warehouse: bạn phải tự dựng cụm, tự chọn và vận hành framework. Đề chỉ cần một data warehouse hỗ trợ SQL chuẩn, không cần đến bộ máy xử lý phân tán mã nguồn mở.

📌 Điểm cần nhớ

• Trong đề thi AWS, gặp cụm "data warehouse" thì gần như mặc định là Amazon Redshift — đây là ánh xạ một–một cần thuộc lòng.
• Phân biệt OLAP và OLTP là chìa khoá tách Redshift khỏi RDS: phân tích, tổng hợp, báo cáo → OLAP → Redshift; giao dịch của ứng dụng → OLTP → RDS.
• "Hỗ trợ SQL" không đủ để chọn đáp án. Athena, EMR, RDS và Redshift đều chạy được SQL; phải đọc thêm ràng buộc còn lại (nơi lưu trữ, kiểu tải công việc, mức vận hành) mới phân biệt được.
• Nhớ đúng vai của từng dịch vụ trong nhóm này: Athena truy vấn dữ liệu tại chỗ trên S3 theo kiểu serverless, EMR là cụm xử lý phân tán với Spark/Hive/Presto, Redshift là kho dữ liệu phân tích, RDS là cơ sở dữ liệu quan hệ cho ứng dụng.

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

Đề mô tả một công ty cần dịch vụ lưu trữ file với ba tính chất: có khả năng mở rộng, độ tin cậy cao, và fully managed. Nhưng ràng buộc quyết định đáp án không nằm ở ba tính từ đó — cả mấy dịch vụ lưu trữ của AWS đều mở rộng được và đều được quản lý.

Cụm từ chốt là: "runs on the Server Message Block (SMB) protocol".

SMB là giao thức chia sẻ file của thế giới Windows. Chỉ cần đọc thấy "SMB", "Windows file share", "Active Directory integration" hay "NTFS" là đề đang trỏ thẳng vào một dịch vụ duy nhất trong họ storage của AWS. Cụm thứ hai đáng chú ý là "file storage" — nó loại trước một nhóm phương án ngay cả khi chưa xét tới giao thức, vì có phương án là block storage và có phương án là object storage.

Nói gọn: câu này kiểm tra hai lớp phân loại — kiểu lưu trữ (block / object / file) rồi mới tới giao thức (NFS hay SMB).

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

Đáp án đúng theo tệp là D — Amazon FSx for Windows File Server.

FSx for Windows File Server là dịch vụ file server Windows được AWS quản lý hoàn toàn, chạy trên nền một file system Windows thật sự (Windows Server + NTFS), chứ không phải một lớp mô phỏng. Vì thế nó hỗ trợ native giao thức SMB — đúng thứ đề bài yêu cầu — cùng các tính năng đặc thù của file system Windows mà workload doanh nghiệp trông đợi.

Khớp từng chữ với đề:

• fully managed — AWS lo phần cài đặt, vá lỗi, sao lưu, thay thế phần cứng; khách hàng không quản trị máy chủ Windows.
• scalable, highly reliable — dung lượng và thông lượng điều chỉnh được, dữ liệu được lưu dự phòng.
• SMB protocol — hỗ trợ gốc, đây chính là lý do phương án này thắng ba phương án còn lại.

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

A. Amazon Elastic Block Store (Amazon EBS) — Đây là block storage, không phải file storage. EBS cung cấp một volume thô gắn vào EC2 instance; hệ điều hành phải tự format và mount nó rồi mới có file system. SMB là giao thức file-based, hoạt động ở tầng cao hơn hẳn tầng block, nên EBS không đáp ứng yêu cầu. Ngoài ra, một EBS volume vốn thiết kế để phục vụ cho một instance chứ không phải làm kho file chia sẻ cho nhiều máy trong mạng.

B. Amazon S3 — Đây là object storage, truy cập qua API HTTP/HTTPS chứ không phải qua giao thức file share. S3 rất mở rộng và rất bền, nên nếu chỉ đọc lướt hai tính từ "scalable, highly reliable" thì nó trông rất hấp dẫn — đó chính là cái bẫy của câu này. Nhưng S3 không nói SMB: ứng dụng không thể mount một bucket như một ổ đĩa mạng Windows theo cách thông thường, cũng không có khái niệm file system với thư mục thật, quyền NTFS hay file locking.

C. Amazon Elastic File System (Amazon EFS) — Đây là phương án gần đúng nhất và nguy hiểm nhất. EFS đúng là file storage, đúng là fully managed, đúng là scalable, đúng là mount được cho nhiều máy cùng lúc. Nó thoả ba trên bốn yêu cầu của đề. Chỗ hỏng nằm ở đúng cụm từ quyết định: EFS là file system cho Linux/UNIX và dùng giao thức NFS, không phải SMB. Nếu đề chỉ ghi "shared file storage" mà không nêu giao thức thì EFS hoàn toàn có thể là đáp án — nhưng đề đã nêu rõ SMB, nên EFS bị loại.

📌 Điểm cần nhớ

• Phân ba nhóm lưu trữ trước khi xét gì khác: EBS = block, S3 = object, EFS và FSx = file. Đề nói "file storage" là gạch ngay hai nhóm đầu.
• Trong nhóm file storage, giao thức là dấu hiệu nhận dạng: NFS → EFS (Linux), SMB → FSx for Windows File Server (Windows). Thấy SMB, Windows, Active Directory hay NTFS trong đề thì chọn FSx for Windows File Server.
• Các tính từ chung như "scalable", "highly reliable", "fully managed" thường đúng với nhiều phương án cùng lúc, nên chúng gần như không có giá trị phân biệt. Hãy tìm ràng buộc cụ thể — tên giao thức, tên hệ điều hành, kiểu truy cập — vì đó mới là thứ đề dùng để chọn ra một đáp án duy nhất.
• S3 hay bị chọn nhầm ở những câu chỉ nhấn mạnh độ bền và khả năng mở rộng. Nhớ rằng S3 truy cập qua API, không mount được như một file share theo giao thức mạng truyền thống.

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

Đề hỏi: dịch vụ AWS nào dùng machine learning để cung cấp khả năng natural language search trong ứng dụng, giúp tìm ra câu trả lời chính xác cho câu hỏi của người dùng bên trong một tập tài liệu lớn.

Cụm từ quyết định nằm ở ba mảnh ghép, phải thoả cả ba mới đúng:

• "natural language search" — người dùng gõ câu hỏi bằng ngôn ngữ đời thường, không phải cú pháp truy vấn hay từ khoá.
• "find the precise answer to your questions" — kết quả trả về là câu trả lời, chứ không phải một danh sách tài liệu để người dùng tự đọc.
• "within a large set of documents" — đối tượng làm việc là kho tài liệu, không phải log, không phải hội thoại.

Ba phương án còn lại đều dính một trong ba mảnh (đều liên quan tới ngôn ngữ hoặc tìm kiếm) nhưng trượt ở những mảnh còn lại. Đó chính là chỗ để phân biệt.

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

B — Amazon Kendra. Kendra là dịch vụ enterprise search dựa trên machine learning, được thiết kế đúng cho bài toán trong đề: đánh chỉ mục một kho tài liệu nội bộ, rồi cho phép người dùng đặt câu hỏi bằng ngôn ngữ tự nhiên và nhận về đoạn trả lời chính xác trích ra từ tài liệu, thay vì chỉ nhận một danh sách link theo độ khớp từ khoá.

Cả ba mảnh ghép của đề đều rơi đúng vào mô tả của Kendra: ML sẵn có (không cần tự huấn luyện mô hình), truy vấn bằng natural language, và phạm vi là tập tài liệu lớn. Vì vậy đây là đáp án duy nhất khớp trọn vẹn.

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

A — Amazon Comprehend. Đây là dịch vụ NLP để phân tích văn bản: trích xuất thực thể, cụm từ khoá, ngôn ngữ, sắc thái (sentiment), phân loại tài liệu. Nó có dùng ML và có làm việc với văn bản — nên trông rất gần đề. Chỗ nó hỏng: Comprehend phân tích tài liệu chứ không phải một search engine. Không có giao diện đặt câu hỏi bằng ngôn ngữ tự nhiên để lấy về câu trả lời chính xác trong kho tài liệu. Nó có thể là bước tiền xử lý làm giàu metadata, nhưng bản thân nó không trả lời câu hỏi của người dùng.

C — Amazon Lex. Lex dùng để xây conversational interface — chatbot, trợ lý thoại — với intent, slot, và luồng hội thoại. Nó cũng hiểu ngôn ngữ tự nhiên, nên dễ bị chọn nhầm. Nhưng mục tiêu của Lex là nhận diện ý định để kích hoạt một hành động trong một luồng hội thoại đã định nghĩa trước, không phải tìm kiếm trong một kho tài liệu. Đề nói rõ nguồn tri thức là "a large set of documents"; Lex không có cơ chế đánh chỉ mục và truy vấn tài liệu.

D — Amazon ElasticSearch (Amazon OpenSearch Service). Đây là phương án gần đúng nhất và cũng là bẫy chính, vì nó thực sự là công cụ search. Nhưng nó là search engine kiểu truyền thống: truy vấn theo từ khoá và cú pháp truy vấn, trả về danh sách tài liệu khớp kèm điểm số. Nó không mặc định cung cấp lớp natural-language question answering để rút ra câu trả lời chính xác — đó đúng là điểm khác biệt mà Kendra sinh ra để giải quyết. Ngoài ra, đúng như đề gợi ý về ngữ cảnh, dịch vụ này thường được dùng cho log analytics, quan sát hệ thống và phân tích dữ liệu vận hành, chứ không phải làm cổng hỏi–đáp trên kho tài liệu doanh nghiệp.

📌 Điểm cần nhớ

• "Search trong tài liệu + hỏi bằng ngôn ngữ tự nhiên + trả về câu trả lời chính xác" → Amazon Kendra. Đây là mẫu câu gần như cố định trong đề thi.
• Phân biệt "search" với "analyze": Kendra tìm và trả lời; Comprehend phân tích văn bản (entity, sentiment, phân loại). Cùng là ML trên text nhưng khác hẳn mục đích.
• Phân biệt "search" với "converse": Lex hội thoại và nhận diện intent; nếu đề nói tới chatbot, voice, luồng hội thoại thì mới là Lex. Đề nhắc tới kho tài liệu thì không phải.
• Phân biệt "keyword search" với "question answering": ElasticSearch/OpenSearch trả về danh sách tài liệu theo từ khoá và mạnh ở log analytics; Kendra trả về câu trả lời. Cứ thấy chữ "precise answer" là nghiêng về Kendra.