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

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

Đề mô tả một ứng dụng dùng relational database triển khai trên AWS, kèm hai ràng buộc đặt cạnh nhau:

1. "requires access to the database instance's operating system in order to run scripts" — tầng ứng dụng phải vào được hệ điều hành của máy chạy database để chạy script.
2. "prefer to keep management overhead to a minimum" — muốn tốn ít công quản trị nhất có thể.

Cụm quyết định là ràng buộc thứ nhất: truy cập hệ điều hành của database instance. Ràng buộc thứ hai nghe như đang dẫn ta về phía dịch vụ managed, nhưng nó chỉ là "prefer" — một mong muốn, không phải điều kiện bắt buộc. Còn quyền truy cập OS là yêu cầu kỹ thuật cứng: không có nó thì script không chạy được và giải pháp vô dụng. Khi một câu hỏi đặt "yêu cầu bắt buộc" cạnh "sở thích", yêu cầu bắt buộc luôn thắng — đây chính là bẫy của câu này.

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

D — Amazon EC2. EC2 cho bạn một virtual machine mà bạn có toàn quyền: SSH/RDP vào được, cài đặt phần mềm tuỳ ý, và chạy script trực tiếp trên hệ điều hành. Bạn tự cài engine relational database lên instance đó, nên vừa có database quan hệ, vừa có quyền OS mà đề đòi hỏi.

Đúng là chọn EC2 nghĩa là bạn phải tự lo vá lỗi OS, cài đặt, sao lưu, cập nhật engine — tức management overhead cao hơn một dịch vụ managed. Nhưng khi phương án ít việc quản trị nhất lại không đáp ứng nổi yêu cầu bắt buộc, thì lựa chọn đúng là phương án khả thi tiếp theo. EC2 là phương án duy nhất trong danh sách vừa chạy được relational database vừa mở quyền OS.

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

B — Amazon RDS (phương án gần đúng nhất, và là cái bẫy chính). RDS đáp ứng hoàn hảo vế "quản trị tối thiểu": AWS lo vá lỗi, sao lưu, failover. Nhưng RDS là dịch vụ managed — AWS giữ quyền kiểm soát máy chủ bên dưới, khách hàng không truy cập được hệ điều hành của DB instance. Bạn chỉ nối tới database qua endpoint và chỉnh cấu hình qua parameter group, không có shell để chạy script OS. Yêu cầu cứng của đề bị vi phạm, nên RDS bị loại dù nó thắng ở vế còn lại.

C — Amazon DynamoDB. DynamoDB là NoSQL / non-relational database. Đề nói rõ ứng dụng cần relational database, nên phương án này sai ngay từ mô hình dữ liệu — chưa cần bàn tới chuyện OS (nó cũng là dịch vụ managed hoàn toàn, không có OS để truy cập).

A — Amazon S3. S3 là object storage, không phải database. Nó lưu tệp dưới dạng object trong bucket, không có query engine quan hệ, không có schema, không có bảng và join. Đây là phương án sai xa nhất trong bốn phương án.

📌 Điểm cần nhớ

• Cần truy cập hệ điều hành của database → phải dùng EC2 tự quản, không dùng RDS. Đây là ranh giới trách nhiệm của shared responsibility model: dịch vụ càng managed thì AWS càng giữ nhiều tầng, và tầng OS là tầng đầu tiên bạn mất khi chuyển từ EC2 sang RDS.
• Yêu cầu bắt buộc thắng sở thích. Đề thi hay ghép "phải làm được X" với "muốn ít công quản trị"; hãy lọc theo yêu cầu bắt buộc trước, rồi mới chọn phương án ít overhead nhất trong số còn sống sót.
• Đọc kỹ từ relational. Nó loại thẳng DynamoDB (non-relational) và S3 (object storage) mà không cần suy nghĩ thêm — thu hẹp bốn phương án xuống còn hai chỉ bằng một từ.
• RDS đổi quyền kiểm soát lấy sự tiện lợi. Bạn được endpoint, backup tự động và patching tự động; bạn mất shell. Biết rõ mình đánh đổi cái gì là chìa khoá cho cả nhóm câu hỏi so sánh EC2 với RDS.

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

Đề hỏi: "Which task can a user complete using the AWS Cost Management tools?" — tức là trong bốn việc được liệt kê, việc nào thực sự nằm trong phạm vi của bộ công cụ AWS Cost Management.

Cụm từ quyết định là "using the AWS Cost Management tools". Đây không phải câu hỏi "việc nào giúp tiết kiệm chi phí" — nếu đọc theo hướng đó thì cả B (chọn Spot thay vì On-Demand) và C (chuyển S3 Standard sang lớp lưu trữ archive) đều giảm được tiền, và câu trở nên có nhiều đáp án. Ràng buộc thật nằm ở chỗ: công cụ nào thực hiện việc đó. Ba phương án nhiễu đều là việc tiết kiệm chi phí có thật, nhưng được làm bằng công cụ khác (EC2 console, S3 lifecycle management), chứ không phải bằng AWS Cost Management.

Nói ngắn gọn: đề đang phân biệt giữa "theo dõi, kiểm soát và lập kế hoạch chi phí" (đúng vai trò của Cost Management) và "thao tác trực tiếp lên tài nguyên" (vai trò của chính dịch vụ đó).

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

A — Create budgets and receive notifications if current or forecasted usage exceeds the budgets.

Bộ AWS Cost Management gồm các dịch vụ và công cụ để tổ chức, theo dõi dữ liệu chi phí và mức sử dụng, tăng khả năng kiểm soát thông qua consolidated billing cùng quyền truy cập, và hỗ trợ lập kế hoạch tốt hơn nhờ budgeting và forecasting.

Đặt ngân sách rồi nhận cảnh báo khi mức dùng hiện tại hoặc dự báo vượt ngưỡng rơi đúng vào phần "budgets và forecasts" đó. Chú ý chi tiết "or forecasted" trong phương án — nó không chỉ so với con số đã tiêu, mà còn dựa trên dự báo, và dự báo chi phí chính là một năng lực đặc trưng của nhóm công cụ này. Đây là hành động quan sát và cảnh báo về tiền, không đụng gì tới tài nguyên — đúng bản chất của Cost Management.

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

B — Launch either EC2 Spot instances or On-Demand instances based on the current pricing. Đây là phương án gần đúng nhất, vì chọn Spot thay cho On-Demand đúng là một quyết định về chi phí. Nhưng nó hỏng ở động từ "launch": các công cụ Cost Management không tích hợp với công cụ khởi chạy EC2 và không tự chọn giúp bạn mô hình giá tốt nhất. Chúng báo cho bạn biết tiền đang đi đâu và có thể gợi ý tối ưu, còn việc bấm khởi chạy instance theo mô hình giá nào vẫn là thao tác ở phía EC2.

C — Move data stored in Amazon S3 Standard to an archiving storage class to reduce cost. Cũng là một việc tiết kiệm chi phí có thật, nên rất dễ chọn nhầm. Nhưng việc chuyển dữ liệu sang storage class dùng để lưu trữ dài hạn được thực hiện bằng lifecycle management của chính Amazon S3, không phải bởi công cụ Cost Management. Cái bẫy ở đây giống hệt B: đúng mục tiêu, sai công cụ.

D — Delete all of your AWS resources with a single click. Đây là phương án xa nhất. Không có nút "xoá sạch mọi tài nguyên" như vậy trong console; việc dọn dẹp hàng loạt kiểu đó phải nhờ công cụ của bên thứ ba, và dù có thì nó cũng là thao tác quản lý tài nguyên chứ không phải quản lý chi phí. Ngoài ra một hành động phá huỷ toàn bộ chỉ bằng một cú nhấp là điều nền tảng cố tình không cung cấp.

📌 Điểm cần nhớ

• Khi đề hỏi "can be done using <tên bộ công cụ>", hãy đọc thành "công cụ nào làm việc này", đừng đọc thành "việc nào có ích". Phương án nhiễu thường là việc đúng đắn nhưng thuộc dịch vụ khác.
• Phạm vi của AWS Cost Management: tổ chức và theo dõi cost/usage, kiểm soát qua consolidated billing và quyền truy cập, lập kế hoạch bằng budgets và forecasts, cùng các gợi ý tối ưu chi phí — quan sát và lập kế hoạch, không thao tác trực tiếp lên tài nguyên.
• Việc thay đổi storage class của dữ liệu trong Amazon S3 thuộc về lifecycle management của S3; việc chọn On-Demand hay Spot thuộc về lúc khởi chạy EC2. Cả hai đều ảnh hưởng chi phí nhưng không nằm trong bộ công cụ Cost Management.
• Cảnh giác với phương án chứa "with a single click" hoặc mô tả một hành động phá huỷ diện rộng cực kỳ dễ dàng — đó thường là dấu hiệu của phương án bịa.

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

Đề hỏi: trong danh sách năm dịch vụ AWS, hai dịch vụ nào thuộc nhóm compute.

Cụm từ quyết định là "compute services" — đây không phải câu hỏi về việc dịch vụ nào hữu ích hay liên quan tới ứng dụng đang chạy, mà là câu hỏi về phân loại dịch vụ theo đúng danh mục AWS đặt cho nó. Cả năm phương án đều là dịch vụ AWS thật và đều có thể xuất hiện quanh một ứng dụng chạy trên EC2, nên nếu đọc lướt thì phương án nào trông cũng "có lý". Ràng buộc phân biệt nằm ở chỗ: dịch vụ đó có cấp phát và chạy tài nguyên tính toán (chạy mã của bạn) hay không, hay nó chỉ giám sát, ghi vết, hoặc lưu trữ cho phần tính toán do dịch vụ khác đảm nhiệm.

Thêm một dấu hiệu ở đề: (Select TWO.) — phải chọn đúng hai, nên cần một tiêu chí đủ sắc để loại ba phương án còn lại, chứ không thể chọn theo cảm giác "gần gũi với compute".

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

Đáp án đúng theo tệp là C (AWS Elastic Beanstalk) và D (AWS Batch).

• AWS Elastic Beanstalk: dịch vụ triển khai và mở rộng ứng dụng web viết bằng Java, .NET, PHP, Node.js, Python, Ruby, Go và Docker, chạy trên các web server quen thuộc như Apache, Nginx, Passenger, IIS. Bạn đưa mã lên, Beanstalk lo phần dựng và vận hành hạ tầng chạy mã đó — tức là nó cung cấp năng lực tính toán, nên nằm trong nhóm compute.
• AWS Batch: dịch vụ chạy các batch computing job trên AWS, quy mô lên tới hàng trăm nghìn job, tự lo việc cấp phát tài nguyên tính toán phù hợp với khối lượng công việc. Bản chất công việc của nó là thực thi job, nên cũng là compute.

Điểm chung: cả hai đều nhận mã hoặc job của bạn rồi chạy nó trên tài nguyên do AWS cấp phát.

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

• A — Amazon Inspector: là dịch vụ đánh giá bảo mật tự động, giúp cải thiện mức độ bảo mật và tuân thủ của ứng dụng đã triển khai trên AWS. Đây là phương án dễ nhầm nhất theo kiểu "nó có liên quan tới workload đang chạy" — nhưng liên quan không có nghĩa là cùng nhóm: Inspector kiểm tra thứ đang chạy chứ không chạy mã của bạn. Nó thuộc nhóm security, identity & compliance.
• B — AWS CloudTrail: dùng cho auditing — ghi lại các lời gọi API và hoạt động trong tài khoản để phục vụ kiểm toán và điều tra. Nó ghi vết về việc bạn tạo tài nguyên compute, nhưng bản thân nó không cấp phát hay chạy tài nguyên nào. Thuộc nhóm management & governance.
• E — Amazon EFS: Elastic File System dùng để lưu trữ dữ liệu và được mount bởi các EC2 instance. Đây là phương án gần đúng thứ hai vì nó gắn trực tiếp vào instance compute — nhưng chính mô tả đó cho thấy vai trò của nó: EFS là file system cho máy tính toán, phần tính toán vẫn do EC2 làm. Thuộc nhóm storage.

📌 Điểm cần nhớ

• Câu hỏi phân loại dịch vụ nên hỏi lại: dịch vụ này có chạy mã / job của tôi không? Có → compute. Chỉ theo dõi, ghi vết, hay giữ dữ liệu → thuộc nhóm khác.
• Gắn liền với compute ≠ là compute. EFS được EC2 mount, Inspector quét ứng dụng đang chạy, CloudTrail ghi mọi thao tác API — cả ba đều đứng cạnh compute nhưng không thuộc nhóm đó.
• Nhớ theo cặp "dịch vụ ↔ nhóm" cho các tên hay xuất hiện: Elastic Beanstalk và Batch (compute), EFS (storage), CloudTrail (management & governance, auditing), Inspector (security).
• Với đề ghi (Select TWO.), hãy tìm một tiêu chí duy nhất tách được đúng hai phương án; nếu tiêu chí của bạn cho ra ba hoặc một, gần như chắc chắn tiêu chí đó chưa đúng.

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

Đề hỏi: AWS cloud giúp khách hàng tăng "speed and agility" (tốc độ và sự linh hoạt) khi triển khai bằng cách nào? (Chọn HAI)

Cụm từ quyết định đáp án là "speed and agility of execution". Đây không phải câu hỏi "AWS có lợi ích gì" chung chung — nếu vậy thì cả năm phương án đều đúng ở mức nào đó, vì bảo mật, chi phí và kết nối riêng đều là lợi ích thật của cloud. Ràng buộc ở đây hẹp hơn: chỉ những lợi ích liên quan tới thời gian có được tài nguyên và khả năng thay đổi tài nguyên nhanh khi nhu cầu đổi.

Trong tài liệu Six Advantages of Cloud Computing của AWS, "Increase speed and agility" là một mục riêng, tách bạch với "Trade capital expense for variable expense" (chi phí) và với phần nói về bảo mật. Câu hỏi này đang kiểm tra xem người học có phân loại đúng từng lợi ích vào đúng mục hay không — đó là kiểu bẫy rất hay gặp ở đề Cloud Practitioner: mọi phương án đều là điều tốt, chỉ một số ít thuộc đúng nhóm mà đề hỏi.

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

Đáp án đúng là B — Scalable compute capacity và E — Fast provisioning of resources.

E — Fast provisioning of resources là ví dụ kinh điển nhất của speed. Trên AWS, tài nguyên đã sẵn sàng ở đó, chỉ cần gọi API là có; không phải đặt mua phần cứng, chờ giao hàng, lắp đặt vào rack rồi cấu hình. Việc rút ngắn khoảng cách từ "muốn thử một ý tưởng" tới "hệ thống đang chạy" chính là định nghĩa của speed trong tài liệu AWS.

B — Scalable compute capacity là ví dụ của agility. Agility không chỉ là bắt đầu nhanh, mà còn là đổi ý nhanh: cần thêm compute thì thêm, hết nhu cầu thì bớt, mà không bị khoá vào một lượng phần cứng đã mua. Khả năng cấu hình lại tài nguyên theo nhu cầu cho phép thử nghiệm với rủi ro thấp — thử sai thì trả tài nguyên về, không ôm một đống máy chủ thừa.

Hai phương án này bổ trợ nhau: E là tốc độ lấy tài nguyên lần đầu, B là sự linh hoạt điều chỉnh về sau.

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

A — Secured data centers. Data center được bảo vệ là lợi ích có thật của AWS, nhưng nó thuộc nhóm bảo mật, không thuộc nhóm speed and agility. Bảo mật vật lý không làm bạn triển khai nhanh hơn hay đổi cấu hình dễ hơn.

C — Lower cost of deployment. Đây là phương án gần đúng và dễ chọn nhầm nhất, vì chi phí thấp thường đi kèm với việc dùng cloud. Nhưng nó hỏng ở chỗ: chi phí là một trục lợi ích khác — trong tài liệu AWS nó nằm ở mục đánh đổi chi phí đầu tư ban đầu lấy chi phí biến đổi và lợi thế quy mô. Rẻ hơn không có nghĩa là nhanh hơn; một hệ thống có thể rẻ mà vẫn mất hàng tuần để dựng. Khi đề đã ghi rõ "speed and agility", phải loại mọi phương án nói về tiền.

D — Private connections to data centers. Kết nối riêng (dạng đường truyền chuyên dụng thay vì đi qua Internet công cộng) giúp ổn định và có thể giúp bảo mật, nhưng bản thân nó là một hạng mục kết nối mạng phải thiết lập — không phải thứ làm bạn triển khai tài nguyên nhanh hơn hay thay đổi quy mô linh hoạt hơn. Nó thuộc nhóm networking/bảo mật, không thuộc nhóm mà đề hỏi.

📌 Điểm cần nhớ

• Đọc kỹ nhóm lợi ích mà đề nêu tên. Đề Cloud Practitioner thường cho nhiều phương án đều là lợi ích đúng của cloud, và chỉ chọn được đáp án khi phân loại chúng vào đúng nhóm.
• Speed and agility = lấy tài nguyên nhanh (fast provisioning) + thay đổi quy mô tài nguyên dễ (scalability/elasticity). Đó là trục thời gian và trục thay đổi.
• Phương án nói về chi phí thuộc trục khác ("trade capital expense for variable expense"), phương án nói về data center an toàn hay kết nối riêng thuộc trục bảo mật/hạ tầng — đừng gộp chúng vào speed and agility.
• Với câu "Select TWO", hãy kiểm tra xem hai đáp án chọn ra có cùng thuộc nhóm đề hỏi không; nếu hai đáp án của bạn thuộc hai nhóm khác nhau thì gần như chắc chắn một trong hai sai.

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

Đề hỏi: hai phát biểu nào mô tả đúng nhất khái niệm agility (tính linh hoạt, nhanh nhạy) trong điện toán đám mây trên AWS.

Cụm từ quyết định đáp án là "the concept of agility" — chứ không phải "cost saving", không phải "elasticity", cũng không phải "reliability". Đây là câu kiểm tra xem người học có phân biệt được các lợi ích của cloud mà AWS liệt kê trong tài liệu Six Advantages of Cloud Computing hay không. Bốn trên năm phương án đều là điều tốt đẹp và có thật về AWS; cái bẫy nằm ở chỗ chúng thuộc nhóm lợi ích khác.

Định nghĩa agility mà AWS dùng: tài nguyên IT mới chỉ cách một cú click, thời gian để có được tài nguyên rút từ hàng tuần xuống còn vài phút. Nhờ vậy chi phí và thời gian để thử nghiệm giảm mạnh — tổ chức dám thử, dám sai, dám bỏ đi làm lại. Vậy agility gồm hai vế: tốc độ tạo tài nguyên và khả năng thử nghiệm nhanh. Bám vào hai vế đó là chọn được đáp án.

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

A. The speed at which AWS resources can be created — đây chính là vế thứ nhất trong định nghĩa. Trong mô hình on-premises, muốn có một server phải duyệt ngân sách, đặt mua, chờ giao, lắp đặt, cấu hình — tính bằng tuần hoặc tháng. Trên AWS, cùng việc đó chỉ mất vài phút qua console, CLI hay API. Chính việc rút ngắn độ trễ cung cấp tài nguyên này là định nghĩa gốc của agility.

E. The ability to experiment quickly — vế thứ hai, và là hệ quả trực tiếp của vế thứ nhất. Khi tạo tài nguyên nhanh và rẻ, chi phí của một thí nghiệm thất bại gần như bằng không: dựng môi trường thử, chạy, đo, rồi xoá đi. Tổ chức không còn phải "chọn đúng ngay từ đầu" vì đã lỡ mua phần cứng. Tài liệu AWS nói thẳng: the cost and time it takes to experiment and develop is significantly lower.

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

B. The elimination of wasted capacity — phương án gần đúng nhất và dễ nhầm nhất. Nó có thật, nhưng nó là right-sizing, tức là chuyện chi phí: bạn không còn phải mua thừa phần cứng cho lúc cao điểm rồi để nó nằm không suốt phần còn lại của năm. Loại bỏ dung lượng lãng phí trả lời câu hỏi "tốn bao nhiêu tiền", còn agility trả lời câu hỏi "mất bao lâu để bắt đầu". Hai trục khác nhau — nó hỏng ở chỗ đo bằng đồng tiền chứ không đo bằng tốc độ.

C. The speed at which AWS rolls out new features — nghe rất hợp lý vì có chữ "speed", nhưng đó là tốc độ của AWS với tư cách nhà cung cấp, không phải tốc độ của khách hàng. Agility là thuộc tính của tổ chức đang dùng cloud: khả năng bạn di chuyển nhanh. AWS ra tính năng mới nhanh hay chậm không mô tả được năng lực đó. Đây là bẫy khớp từ khoá thuần tuý.

D. The ability to automatically scale capacity — cũng rất gần, và cũng có thật. Nhưng đây là elasticity (auto scaling): đảm bảo bạn luôn có đúng lượng capacity cần thiết, co giãn theo tải. Elasticity nói về khớp cung với cầu tại thời điểm chạy; agility nói về tốc độ từ ý tưởng tới tài nguyên sẵn sàng. Một hệ thống có thể auto scale rất tốt mà quy trình xin cấp môi trường mới vẫn mất hàng tuần — khi đó có elasticity nhưng không có agility. Chính vì D và B đều đúng-về-sự-thật mà câu này khó: phải loại theo nhãn khái niệm, không loại theo tính đúng sai.

📌 Điểm cần nhớ

• Agility = tốc độ + khả năng thử nghiệm. Cứ thấy phương án nói về "tạo tài nguyên trong vài phút" hoặc "thử nghiệm nhanh, thất bại rẻ" thì đó là agility.
• Phân biệt ba khái niệm hay bị trộn lẫn: agility (nhanh có tài nguyên để thử), elasticity / auto scaling (capacity co giãn khớp tải), right-sizing / eliminate wasted capacity (lợi ích về chi phí). Đề Cloud Practitioner rất thích đặt cả ba cạnh nhau.
• Agility là thuộc tính của khách hàng, không phải của AWS. Phương án mô tả việc AWS làm gì (ra tính năng, mở Region) không bao giờ là định nghĩa agility.
• Trong câu hỏi định nghĩa khái niệm, "đúng sự thật" chưa đủ để được chọn — phải đúng khái niệm mà đề đang hỏi tên. Đọc kỹ danh từ then chốt trong đề trước khi so từng phương án.

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

Đề mô tả một batch job chạy trên một EC2 instance, mất 6 giờ. Điểm mấu chốt nằm ở hai cụm từ:

• "double in volume each month with a proportional increase in processing time" — khối lượng tăng gấp đôi mỗi tháng, và thời gian xử lý tăng theo tỉ lệ. Đây là tăng trưởng theo cấp số nhân, không phải tăng nhẹ một lần.
• "most efficient cloud architecture" — câu hỏi không hỏi "cách nhanh nhất ngay bây giờ", mà hỏi kiến trúc nào chịu được đà tăng đó lâu dài.

Ràng buộc phân biệt các phương án chính là tăng gấp đôi mỗi tháng. Bất kỳ giải pháp nào chỉ nới thêm một mức tài nguyên cố định đều chỉ mua được vài tháng, rồi lại đụng trần. Ngoài ra, đây là công việc CPU-bound (batch processing tốn thời gian xử lý), nên phải nhìn vào năng lực tính toán chứ không phải I/O.

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

C — Run the batch workload in parallel across multiple Amazon EC2 instances.

Chạy song song trên nhiều EC2 instance chính là horizontal scaling (scale out): thay vì làm một máy to hơn, ta chia công việc ra nhiều máy cùng làm. Với batch job, khối lượng vốn chia nhỏ được thành nhiều phần độc lập, nên đây là mô hình phù hợp tự nhiên.

Điểm quan trọng: khi khối lượng gấp đôi, ta chỉ cần gấp đôi số instance thì thời gian xử lý giữ nguyên. Đà tăng của workload được đáp lại bằng đà tăng của số máy — mô hình này đi theo mãi được, đúng tinh thần "elasticity" của cloud mà AWS Well-Architected Framework nhấn mạnh. Đây cũng là lý do đề dùng chữ architecture: câu trả lời phải là thay đổi cách thiết kế, không phải chỉnh thông số một máy.

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

A — Larger EC2 instance type with more CPU. Đây là phương án gần đúng nhất, và nó có giải quyết đúng nút thắt (CPU). Ban đầu đổi sang instance lớn hơn sẽ rút ngắn thời gian thật. Nhưng đó là vertical scaling — mỗi instance family chỉ lên tới một cỡ lớn nhất, trong khi workload gấp đôi mỗi tháng. Sau vài chu kỳ, không còn cỡ nào to hơn để nhảy lên, và job sẽ kéo dài nhiều ngày. Nó chữa triệu chứng một lần, không phải kiến trúc chịu được tăng trưởng.

B — Đổi volume sang Provisioned IOPS SSD. Phương án này cải thiện hiệu năng của EBS volume, tức là tốc độ đọc/ghi đĩa. Nhưng đề không hề nói job bị nghẽn ở I/O — nó là tác vụ xử lý cần thêm năng lực tính toán. Tăng IOPS cho một workload CPU-bound thì tốn thêm tiền mà thời gian chạy gần như không đổi. Đây là kiểu bẫy "chọn đúng loại tài nguyên nhưng sai nút thắt".

D — Bare metal EC2 instance. Bare metal instance phục vụ những nhu cầu rất riêng: ứng dụng cần truy cập trực tiếp tập tính năng phần cứng, cần chạy trong môi trường không ảo hoá vì lý do license hoặc hỗ trợ, hoặc khách hàng muốn dùng hypervisor của chính mình. Batch job trong đề không có nhu cầu nào như vậy. Và về bản chất nó vẫn là một máy đơn — vẫn vấp đúng bức tường mà phương án A vấp phải.

📌 Điểm cần nhớ

• Thấy cụm "tăng gấp đôi / tăng liên tục theo thời gian" trong đề thì đáp án gần như luôn là scale out (horizontal), không phải scale up (vertical).
• Vertical scaling có trần, horizontal scaling thì không — đó là điểm phân biệt cốt lõi giữa hai lựa chọn nghe đều "mạnh hơn".
• Trước khi chọn, xác định nút thắt là CPU hay I/O: tăng IOPS chỉ có ích khi nghẽn nằm ở đĩa.
• Bare metal không phải là "EC2 mạnh nhất" mà là EC2 cho nhu cầu đặc biệt (truy cập phần cứng, license, hypervisor riêng) — thấy nó xuất hiện trong câu hỏi về hiệu năng thuần thì thường là phương án nhiễu.

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

Đề mô tả một database PostgreSQL đang chạy trên một Amazon EC2 instance duy nhất, và yêu cầu tăng tính sẵn sàng (availability) cho database.

Cụm từ quyết định là "automatic recovery in the case of a failure" — tự động phục hồi khi có sự cố, không cần người vào can thiệp. Cụm thứ hai không kém quan trọng là "the database": thứ cần được bảo vệ là tầng dữ liệu, chứ không phải tầng ứng dụng hay tầng mạng.

Hai ràng buộc này loại ngay những phương án chỉ bảo toàn dữ liệu mà không tự khôi phục dịch vụ, và những phương án xử lý ở tầng sai.

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

A — Migrate the database to Amazon RDS and enable the Multi-AZ feature.

Chuyển database sang Amazon RDS là chuyển từ mô hình tự quản trên EC2 sang dịch vụ managed, và nhờ đó dùng được tính năng Multi-AZ có sẵn. Multi-AZ dựng một standby instance nằm ở Availability Zone khác và sao chép đồng bộ dữ liệu sang đó.

Khi sự cố xảy ra với primary instance, RDS tự thực hiện failover — standby được đưa lên làm primary và database hoạt động trở lại. Đúng nghĩa "automatic recovery" mà đề đòi: cơ chế nằm trong dịch vụ, không phải quy trình thủ công.

Điểm mấu chốt: đây là phương án duy nhất trong danh sách vừa xử lý đúng tầng (database), vừa có khả năng tự động đưa dịch vụ trở lại chứ không chỉ giữ lại dữ liệu.

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

B — Configure an Elastic Load Balancer in front of the EC2 instance. Sai ở tầng. Elastic Load Balancer phân phối lưu lượng tới các target ở tầng ứng dụng/mạng, không dùng để phân phối truy cập tới một database engine như PostgreSQL. Ngoài ra, load balancer chỉ có ý nghĩa khi phía sau có nhiều target lành mạnh để chuyển hướng sang; ở đây chỉ có đúng một instance, nên dù có đặt ELB vào thì instance đó hỏng là hết, chẳng còn gì để cân bằng tải sang.

C — Set the DeleteOnTermination value to false for the EBS root volume. Đây là phương án dễ gây phân vân nhất vì nghe có vẻ "an toàn hơn". Nhưng nó chỉ làm đúng một việc: giữ lại EBS root volume khi instance bị terminate, thay vì xoá volume đi cùng. Đó là bảo toàn dữ liệu, không phải phục hồi dịch vụ. Sau khi instance chết, database vẫn ngừng chạy và ai đó phải vào tạo instance mới rồi gắn volume lại bằng tay — hoàn toàn thủ công, trái với chữ "automatic" trong đề.

D — Configure EC2 Auto Recovery to move the instance to another Region. Phương án này đúng một nửa nên rất bẫy: EC2 Auto Recovery là một tính năng tự động có thật, nó phục hồi instance khi hạ tầng bên dưới gặp sự cố. Cái sai nằm ở phần mô tả phạm vi: Auto Recovery khôi phục instance sang host khác, giữ nguyên instance ID và cấu hình, chứ không chuyển sang Region khác. Phương án mô tả sai bản chất tính năng, nên bị loại — dù ý tưởng "tự động phục hồi" của nó là đúng hướng.

📌 Điểm cần nhớ

• Đề đòi high availability tự động cho database → phản xạ đầu tiên là Amazon RDS Multi-AZ: standby ở AZ khác, replication đồng bộ, tự động failover.
• Phân biệt cho rõ giữ lại dữ liệu và khôi phục dịch vụ. DeleteOnTermination=false hay snapshot thuộc nhóm đầu; chỉ nhóm sau mới thoả mãn yêu cầu "automatic recovery".
• Elastic Load Balancer không phải công cụ HA cho database, và load balancer đặt trước một target duy nhất thì không tăng được tính sẵn sàng.
• EC2 Auto Recovery hoạt động trong phạm vi một Region — nó dời instance sang host khác, không sang Region khác. Mọi phương án nào gắn Auto Recovery với "another Region" đều là mô tả sai.

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

Đề nêu tình huống rất gọn: một công ty cần cấp quyền truy cập tài nguyên AWS cho nhân viên của mình, và hỏi nên theo security practices nào. Cụm từ quyết định nằm ở hai chỗ.

Thứ nhất là "for their employees" — người dùng ở đây là con người, có danh tính lâu dài, đăng nhập bằng tài khoản riêng. Điều này định hướng câu trả lời về phía IAM users, password policy và MFA, chứ không phải cơ chế cấp quyền tạm thời cho ứng dụng hay dịch vụ.

Thứ hai là "security practices" ở dạng số nhiều kèm (Select TWO) — đề không hỏi cách làm cho chạy được, mà hỏi đâu là thực hành tốt về bảo mật theo tài liệu best practices của AWS IAM. Vì vậy mọi phương án chỉ đơn thuần "khả thi về kỹ thuật" nhưng không nằm trong khuyến nghị bảo mật đều bị loại. Đây chính là ràng buộc phân biệt các phương án nghe na ná nhau: có phương án sai vì bất khả thi về mặt kiến trúc IAM, có phương án sai vì đi ngược lại khuyến nghị bảo mật.

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

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

A — Create IAM policies based on least privilege principles. Least privilege là nguyên tắc nền của IAM: chỉ cấp đúng những quyền cần thiết để hoàn thành công việc, không hơn. Khi cấp quyền cho nhân viên, ta viết IAM policy mô tả chính xác action và resource họ cần, thay vì gắn quyền rộng cho tiện. Nhờ đó, nếu một thông tin đăng nhập bị lộ hoặc một người thao tác nhầm, phạm vi thiệt hại bị giới hạn lại đúng bằng phần quyền đã cấp.

E — Enable multi-factor authentication for users. MFA bổ sung yếu tố xác thực thứ hai bên cạnh mật khẩu. Mật khẩu có thể bị đoán, bị dùng lại từ dịch vụ khác, hoặc bị lấy qua phishing; khi đó yếu tố thứ hai vẫn chặn được kẻ tấn công đăng nhập. Đây là một trong những khuyến nghị được nhắc đến sớm nhất trong tài liệu IAM best practices, đặc biệt với tài khoản của người dùng thật và các tài khoản có quyền cao.

Hai phương án này bổ trợ nhau: A giới hạn kẻ đăng nhập được thì làm được gì, E giới hạn ai đăng nhập được.

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

B — Create IAM users in different AWS Regions. Sai vì không thực hiện được: IAM là dịch vụ global, không phải dịch vụ theo Region. IAM user, group, role và policy tồn tại ở cấp tài khoản và dùng chung cho mọi Region. Không có thao tác "tạo IAM user ở Region này thay vì Region kia", nên đây không thể là một thực hành bảo mật.

C — Create IAM Roles and apply them to IAM groups. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi, vì cả IAM role lẫn IAM group đều là khái niệm có thật và đều liên quan tới phân quyền. Chỗ nó hỏng là quan hệ gắn kết sai: cái gắn vào group là policy, không phải role. Group là tập hợp các IAM user để gắn policy chung; còn role là danh tính được assume bởi user, dịch vụ hoặc danh tính liên kết. Không có cơ chế "áp role lên group". Câu này viết đúng tên hai thành phần nhưng ghép sai cách chúng hoạt động.

D — Disable password policies and management console access. Sai vì đi ngược khuyến nghị. Password policy chính là công cụ để ép độ mạnh mật khẩu và các yêu cầu liên quan; tắt nó là bỏ đi một lớp bảo vệ chứ không phải tăng cường. Còn quyền truy cập management console là thứ nhân viên cần để làm việc — đề đang yêu cầu cấp quyền truy cập, nên chặn console vừa mâu thuẫn với yêu cầu vừa không mang lại lợi ích bảo mật nào tương xứng.

📌 Điểm cần nhớ

• IAM là dịch vụ global. Bất kỳ phương án nào nói tới việc tạo IAM user/group/role "theo Region" đều loại được ngay mà không cần đọc tiếp.
• Policy gắn vào user, group hoặc role; role thì được assume, không "áp lên group". Nhớ đúng chiều quan hệ này là gỡ được rất nhiều bẫy dạng ghép sai thuật ngữ.
• Least privilege + MFA là cặp câu trả lời mặc định cho mọi câu hỏi kiểu "security best practices khi cấp quyền cho người dùng" ở mức Cloud Practitioner.
• Cảnh giác với phương án chứa động từ "disable". Tắt một cơ chế bảo vệ (password policy, logging, mã hoá) gần như không bao giờ là best practice trong đề thi AWS.

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

Đề mô tả một công ty có nhiều compute resource on-premises đang bị "underutilized" — tức là máy chủ đã mua, đã trả tiền, nhưng chỉ chạy ở một phần nhỏ công suất. Câu hỏi yêu cầu chọn đặc tính (feature) của AWS Cloud giúp xử lý tình trạng đó.

Cụm từ quyết định là "underutilized" (dùng dưới mức, thừa công suất). Đây không phải bài toán về hỏng hóc, không phải bài toán về khoảng cách địa lý tới người dùng, cũng không phải bài toán về thời gian ngừng hoạt động. Vấn đề duy nhất được nêu là lượng tài nguyên cấp phát không khớp với lượng tài nguyên thực sự dùng. Ba trong bốn phương án đều là những đặc tính "nghe rất AWS" và đều đúng khi nói về cloud nói chung, nhưng chỉ một phương án nói đúng về việc khớp cung với cầu.

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

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

Elasticity là khả năng tăng hoặc giảm lượng tài nguyên compute một cách dễ dàng và tự động, bám theo mức sử dụng thực tế. Khi nhu cầu tăng thì cấp thêm, khi nhu cầu giảm thì thu về — nên bạn luôn giữ đúng lượng tài nguyên cần thiết và không phải trả tiền cho phần thừa.

Đó chính xác là thứ giải quyết tình huống trong đề: với hạ tầng on-premises, công ty phải mua sẵn phần cứng cho mức tải đỉnh và phần dư nằm không suốt phần lớn thời gian; chuyển lên cloud với elasticity, lượng tài nguyên co giãn theo tải nên phần "underutilized" biến mất. Đây cũng là nền tảng của việc right-sizing chi phí mà AWS nhấn mạnh trong tài liệu về cost optimization.

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

• A – Global deployment: nói về khả năng triển khai workload ở nhiều vùng địa lý trên thế giới, phục vụ mục tiêu giảm độ trễ cho người dùng ở xa hoặc đáp ứng yêu cầu lưu trú dữ liệu. Nó trả lời câu hỏi "đặt tài nguyên ở đâu", không trả lời câu hỏi "cấp bao nhiêu tài nguyên". Triển khai toàn cầu mà vẫn cấp thừa công suất thì chỉ làm tình trạng underutilization nhân lên ở nhiều vùng.

• B – Fault tolerance: khả năng hệ thống vẫn tiếp tục hoạt động khi một thành phần hỏng, thường đạt được bằng dự phòng. Đây là phương án gần đúng dễ gây nhầm nhất, vì fault tolerance cũng liên quan tới việc chạy thêm tài nguyên. Nhưng nó hỏng ở chỗ đi ngược hướng của đề: dự phòng nghĩa là cố ý giữ thêm năng lực dự trữ, tức là tạo ra tài nguyên chạy dưới mức chứ không loại bỏ nó. Nó xử lý rủi ro hỏng hóc, không xử lý việc dùng thừa.

• D – High availability: mục tiêu là giảm thời gian gián đoạn dịch vụ, giữ hệ thống truy cập được ở mức cao, thường bằng cách phân bổ tài nguyên qua nhiều Availability Zone. Cũng là một phương án nghe hợp lý vì nó liên quan tới cách bố trí compute, nhưng thước đo của nó là uptime, không phải mức sử dụng tài nguyên. Một hệ thống high availability hoàn toàn có thể có mọi instance chạy ở 5% CPU — vấn đề trong đề vẫn nguyên vẹn.

📌 Điểm cần nhớ

• Từ khoá "underutilized" / "over-provisioned" / "trả tiền cho phần không dùng" → nghĩ ngay tới elasticity (và khái niệm liên quan là right-sizing), chứ không phải các đặc tính về độ tin cậy.
• Phân biệt bốn đặc tính theo vấn đề mà chúng giải quyết: elasticity ↔ khớp cung với cầu; high availability ↔ giảm downtime; fault tolerance ↔ chịu được lỗi thành phần; global deployment ↔ vị trí địa lý và độ trễ.
• Fault tolerance và high availability làm tăng lượng tài nguyên dự phòng, nên chúng không bao giờ là câu trả lời cho bài toán tiết kiệm do dùng thừa.
• Với đề Cloud Practitioner, mọi phương án thường đều là ưu điểm có thật của AWS Cloud; chọn đáp án bằng cách bám vào triệu chứng cụ thể mà đề nêu, không chọn theo phương án "nghe hay nhất".

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

Đề hỏi: dịch vụ hay tính năng nào của AWS có thể dùng để cung cấp root storage volume cho EC2 instance.

Cụm từ quyết định ở đây là "root storage volumes" — không phải "lưu trữ dữ liệu nói chung", cũng không phải "nơi chứa ảnh khởi tạo". Root volume là ổ đĩa mà hệ điều hành được cài lên và instance khởi động từ đó. Muốn làm root volume, thứ đó bắt buộc phải là block storage gắn trực tiếp vào instance và hiện ra với hệ điều hành như một ổ đĩa khối (block device), để bootloader và kernel làm việc được với nó.

Ba trong bốn phương án đều là dịch vụ hợp lệ và rất quen thuộc trong hệ sinh thái EC2, nên nếu đọc lướt thành "cái nào lưu được dữ liệu cho EC2" thì cả A, B, C đều nghe có lý. Ràng buộc "root" mới là thứ loại bỏ chúng.

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

C — Amazon Elastic Block Store (EBS) là block storage cho EC2: mỗi volume gắn vào instance và xuất hiện dưới dạng một block device, hệ điều hành định dạng và mount như ổ đĩa vật lý. Vì thế EBS volume dùng làm root volume được — đây chính là kiểu instance phổ biến nhất, "EBS-backed instance", với hệ điều hành nằm trên volume EBS đó.

Một chi tiết đáng biết đi kèm: root volume có thể là EBS volume hoặc instance store volume, tuỳ loại instance và AMI. Nhưng instance store không nằm trong danh sách phương án, nên trong bốn lựa chọn này EBS là câu trả lời duy nhất.

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

A — Amazon Machine Image (AMI). Đây là phương án gần đúng nhất và cũng là bẫy chính. AMI đúng là thứ chứa nội dung của root volume và cả block device mapping mô tả volume nào sẽ được tạo khi khởi động instance. Nhưng AMI là một khuôn mẫu (template), không phải bản thân ổ đĩa: nó cung cấp thông tin để tạo ra root volume chứ không đóng vai trò lưu trữ đang chạy. Sau khi instance khởi động, cái mà hệ điều hành đọc ghi là volume EBS được tạo từ AMI, không phải AMI.

B — Amazon Elastic File System (EFS). EFS là file storage (NFS), mount vào instance qua mạng để nhiều instance cùng dùng chung dữ liệu. Nó hoạt động ở tầng file chứ không phải tầng block, và chỉ mount được sau khi hệ điều hành đã khởi động và có mạng — mà root volume thì phải sẵn sàng trước thời điểm đó. Vì vậy EFS dùng để chứa dữ liệu thì tốt, làm root volume thì không.

D — Amazon Simple Storage Service (S3). S3 là object storage, truy cập qua REST API bằng khoá đối tượng, không gắn (attach) vào EC2 instance dưới dạng ổ đĩa theo bất kỳ cách nào. Không phải block device thì càng không thể là root volume.

📌 Điểm cần nhớ

• Root volume phải là block storage gắn trực tiếp: chỉ EBS volume hoặc instance store volume làm được việc này. File storage (EFS) và object storage (S3) đều không.
• Phân biệt ba tầng lưu trữ khi gặp câu hỏi kiểu này: block (EBS, instance store — hệ điều hành thấy như ổ đĩa), file (EFS — mount qua NFS, chia sẻ được giữa nhiều instance), object (S3 — chỉ truy cập qua API).
• AMI là khuôn mẫu, không phải kho lưu trữ. Nó mô tả root volume sẽ được tạo ra sao (block device mapping) chứ không phải nơi hệ điều hành đọc ghi lúc chạy. Gặp phương án AMI trong câu hỏi về "storage volume", hãy coi đó là bẫy.
• Đọc kỹ chữ "root" trong đề. Bỏ chữ đó đi thì EFS và cả S3 đều thành lựa chọn hợp lệ cho việc lưu dữ liệu của EC2 — chính một chữ đó thu hẹp đáp án xuống còn EBS.