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

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

Đề hỏi: dịch vụ AWS nào dùng để tạo billing alarm (cảnh báo chi phí). Cụm từ quyết định là "create a billing alarm" — không phải "xem báo cáo chi phí", không phải "kiểm tra khuyến nghị tiết kiệm", không phải "ghi lại ai đã làm gì". Từ alarm ở đây rất quan trọng: nó ám chỉ một ngưỡng được đặt trước, được so với một metric, và khi vượt ngưỡng thì bắn thông báo.

Trong AWS, "alarm dựa trên metric" là khái niệm gắn liền với Amazon CloudWatch. Chi phí ước tính của tài khoản được đẩy sang CloudWatch dưới dạng billing metric, và từ metric đó bạn dựng alarm như dựng alarm cho CPU hay cho độ trễ. Bốn phương án còn lại đều liên quan tới "quan sát tài khoản" theo kiểu nào đó, nên cụm "alarm" chính là ràng buộc tách chúng ra.

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

D — Amazon CloudWatch.

Khi bạn bật theo dõi chi phí ước tính cho tài khoản, AWS tính toán số tiền ước tính và gửi sang CloudWatch dưới dạng metric data, cập nhật nhiều lần trong ngày. Dữ liệu billing metric này nằm ở Region US East (N. Virginia) và đại diện cho chi phí trên toàn thế giới — nó gồm chi phí ước tính của từng dịch vụ bạn đang dùng, cộng thêm tổng ước tính của cả tài khoản.

Có metric rồi thì tạo alarm là việc quen thuộc của CloudWatch: đặt ngưỡng, alarm kích hoạt khi chi phí tài khoản thực sự vượt ngưỡng đó. Lưu ý một điểm hay bị hiểu nhầm: alarm này không dự phóng (project) chi phí cuối tháng dựa trên mức tiêu thụ từ đầu tháng tới giờ — nó chỉ so con số ước tính hiện tại với ngưỡng.

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

C — AWS Trusted Advisor (phương án gần đúng nhất). Trusted Advisor là công cụ trực tuyến đưa ra khuyến nghị theo thời gian thực để bạn triển khai tài nguyên theo best practice của AWS, trong đó có nhóm khuyến nghị về tối ưu chi phí (ví dụ chỉ ra tài nguyên đang nhàn rỗi). Vì có dính tới tiền nên nó dễ bị chọn nhầm. Chỗ nó hỏng: Trusted Advisor đưa lời khuyên về tài nguyên, không phải nơi bạn dựng một alarm theo ngưỡng chi tiêu do bạn tự đặt. Nó trả lời "bạn đang lãng phí ở đâu", chứ không trả lời "báo cho tôi khi hoá đơn vượt X".

B — AWS CloudTrail. CloudTrail ghi lại hoạt động API trong tài khoản — ai gọi lệnh gì, lúc nào, từ đâu. Đây là dịch vụ audit/governance, không phải nơi chứa metric hiệu năng hay metric chi phí, nên không có gì để đặt ngưỡng cảnh báo hoá đơn lên đó. Nó cho biết ai đã bật một instance đắt tiền, chứ không cho biết hoá đơn đã chạm ngưỡng.

A — Amazon QuickSight. QuickSight là dịch vụ business intelligence chạy trên cloud, dùng để dựng dashboard và chia sẻ insight cho mọi người trong tổ chức. Nó có thể trực quan hoá dữ liệu chi phí nếu bạn nạp dữ liệu vào, nhưng bản chất nó là công cụ hiển thị/phân tích, không phải cơ chế cảnh báo theo ngưỡng. Chọn nó là nhầm giữa "nhìn thấy số liệu" và "được báo động khi số liệu vượt mức".

📌 Điểm cần nhớ

• Thấy chữ alarm kèm một ngưỡng (threshold) trong đề thi AWS → nghĩ ngay tới CloudWatch, kể cả khi metric đang nói tới là tiền chứ không phải CPU.
• Billing metric nằm ở Region US East (N. Virginia) và phản ánh chi phí toàn cầu của tài khoản — đây là chi tiết hay bị hỏi riêng thành một câu.
• Billing alarm kích hoạt khi chi phí thực tế ước tính vượt ngưỡng, không dự phóng chi phí cuối tháng.
• Phân biệt bốn vai trò dễ lẫn: CloudWatch = metric và alarm; CloudTrail = nhật ký gọi API; Trusted Advisor = khuyến nghị best practice (gồm cả tối ưu chi phí); QuickSight = BI, dashboard trực quan hoá.

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

Đề hỏi: mô hình giá (pricing model) nào của Amazon EC2 nên dùng để tuân thủ yêu cầu bản quyền phần mềm tính theo lõi CPU — "per-core software license requirements".

Cụm từ quyết định đáp án là "per-core software license". Đây không phải câu hỏi về tiết kiệm chi phí, không phải về độ bền của workload, cũng không phải về thời hạn cam kết. Nó là câu hỏi về khả năng nhìn thấy và kiểm soát phần cứng vật lý bên dưới instance.

Lý do: giấy phép tính theo lõi (hoặc theo socket, theo máy chủ vật lý) của các nhà cung cấp như Microsoft hay Oracle thường yêu cầu bạn phải biết chính xác instance đang chạy trên máy chủ vật lý nào, máy đó có bao nhiêu socket và bao nhiêu lõi. Ở các mô hình giá thông thường, AWS đặt instance của bạn lên phần cứng dùng chung và bạn không thấy được lớp vật lý đó — nên không có cách nào chứng minh cho việc tuân thủ giấy phép. Bốn phương án trong đề chia thành hai nhóm rõ rệt: ba phương án nói về cách trả tiền, một phương án nói về cách bố trí phần cứng. Cụm "per-core license" đẩy câu trả lời sang nhóm thứ hai.

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

D. Dedicated Hosts là đáp án đúng.

Amazon EC2 Dedicated Host là một máy chủ vật lý dành riêng hoàn toàn cho bạn. Vì bạn "sở hữu" cả cỗ máy đó, AWS cho bạn thấy các thuộc tính vật lý của nó (số socket, số lõi vật lý) và cho phép bạn quyết định instance nào đặt lên host nào. Đó chính là thứ mà mô hình cấp phép per-core đòi hỏi.

Nhờ vậy, Dedicated Hosts cho phép bạn mang giấy phép sẵn có của mình lên AWS (mô hình BYOL — Bring Your Own License) với các phần mềm đủ điều kiện của những nhà cung cấp như Microsoft và Oracle: bạn giữ được tính linh hoạt và tiết kiệm của giấy phép đã mua, đồng thời vẫn dùng được sự đơn giản và co giãn của AWS. Vì máy chủ là riêng, Dedicated Hosts cũng thường được dùng để đáp ứng các yêu cầu tuân thủ nội bộ của doanh nghiệp — không chia sẻ phần cứng với khách hàng khác.

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

A. Spot Instances — Đây là cách mua công suất nhàn rỗi của AWS với giá rẻ hơn nhiều, đổi lại AWS có thể thu hồi instance bất cứ lúc nào. Nó dành cho khối lượng công việc ngắn hạn, chịu được gián đoạn (xử lý theo lô, kết xuất, thử nghiệm). Nó chỉ tác động tới giá và tính ổn định, hoàn toàn không liên quan tới việc lộ ra thông tin lõi vật lý — và một máy chủ có thể bị lấy lại bất ngờ lại càng là nền tảng tệ cho phần mềm có giấy phép gắn với phần cứng.

B. On-Demand Instances — Đây là mô hình giá tiêu chuẩn: trả theo thời gian dùng, không cam kết trước. Đây là phương án dễ nhầm nhất theo kiểu "mặc định là an toàn", nhưng nó không cung cấp bất kỳ ưu điểm nào mà đề bài yêu cầu: instance vẫn chạy trên phần cứng dùng chung, bạn không thấy được số lõi vật lý của host và không kiểm soát được chỗ đặt. On-Demand trả lời câu hỏi "trả tiền thế nào", chứ không trả lời "phần cứng bên dưới là gì".

C. Reserved Instances — Đây là cách giảm chi phí bằng cách cam kết sử dụng trong một kỳ hạn (thường 1 hoặc 3 năm). Phương án này gần đúng ở chỗ nó cũng liên quan tới cam kết dài hạn, giống như doanh nghiệp mua giấy phép dài hạn — nhưng nó hỏng ở chỗ bản chất: Reserved Instances là một cam kết thanh toán, không phải một sự phân bổ phần cứng vật lý. Bạn vẫn không được nhìn thấy máy chủ vật lý và số lõi của nó, nên không đáp ứng được yêu cầu cấp phép per-core.

📌 Điểm cần nhớ

• Thấy các từ khoá "per-core / per-socket license", "BYOL", "existing software licenses", hoặc "máy chủ vật lý dành riêng" → nghĩ ngay tới Dedicated Hosts.
• Phân biệt bản chất bốn lựa chọn: On-Demand / Reserved / Spot là ba cách trả tiền, còn Dedicated Hosts là cách bố trí phần cứng (dù nó cũng nằm trong nhóm mô hình giá EC2). Đề hỏi về giấy phép hay tuân thủ phần cứng thì chọn nhóm thứ hai.
• Ghi nhớ đặc trưng một dòng của từng mô hình còn lại: Spot = rẻ nhưng có thể bị thu hồi, hợp với việc chịu được gián đoạn; Reserved = giảm giá đổi lấy cam kết kỳ hạn 1 hoặc 3 năm; On-Demand = tiêu chuẩn, linh hoạt, không cam kết.
• Điểm mấu chốt của Dedicated Hosts là khả năng nhìn thấy socket và lõi vật lý của máy chủ — đó chính là thứ khiến nó (chứ không phải các mô hình kia) đáp ứng được yêu cầu cấp phép tính theo lõi.

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

Đề hỏi: "Which of the following is an architectural best practice recommended by AWS?" — tức là hỏi đâu là một nguyên tắc thiết kế kiến trúc mà AWS chính thức khuyến nghị, chứ không hỏi về một dịch vụ cụ thể nào.

Cụm từ quyết định là "architectural best practice recommended by AWS". Hai chữ recommended by AWS mới là chỗ phân biệt: câu này không hỏi "phương án nào nghe hợp lý", mà hỏi "phương án nào đúng là khẩu hiệu AWS dạy trong tài liệu Architecting for the Cloud / AWS Well-Architected Framework". Ba phương án sai đều được dựng lên theo kiểu đảo ngược hoặc nhại lại một khẩu hiệu thật của AWS, nên nếu chỉ đọc lướt và thấy "nghe cũng xuôi" thì rất dễ chọn nhầm.

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

D — "Design for failure" là đáp án đúng.

Đây là một trong những nguyên tắc kiến trúc nền tảng mà AWS nhấn mạnh xuyên suốt tài liệu Well-Architected. Ý của nó: khi thiết kế hệ thống, luôn phải đặt câu hỏi "nếu thành phần này hỏng thì chuyện gì xảy ra?" và đảm bảo kiến trúc có khả năng chịu lỗi (resilience) trước tình huống đó.

Trên cloud, hạ tầng là thứ có thể hỏng bất cứ lúc nào — một instance chết, một Availability Zone gặp sự cố. AWS không hứa rằng từng thành phần đơn lẻ sẽ không bao giờ hỏng; thay vào đó, AWS trao cho bạn công cụ để dựng kiến trúc mà hỏng một phần không làm sập cả hệ thống. Câu khẩu hiệu đầy đủ thường được trích là "Design for failure and nothing will fail" — chấp nhận trước rằng lỗi sẽ xảy ra thì hệ thống mới sống sót qua lỗi.

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

C — "Design for success": đây là phương án gần đúng nhất và cũng là cái bẫy chính. Nó nghe rất tích cực và hợp lý — ai chẳng muốn ứng dụng của mình thành công. Nhưng chỗ hỏng là: nó không phải nguyên tắc kiến trúc mà AWS khuyến nghị, và về mặt kỹ thuật nó dẫn tới tư duy ngược hẳn với D. Thiết kế theo kịch bản "mọi thứ chạy tốt" nghĩa là bỏ qua đúng phần khó nhất của kiến trúc cloud: chuẩn bị cho lúc thành phần hỏng. Nó là một câu khẩu hiệu động viên, không phải một chỉ dẫn thiết kế.

B — "Think servers, not services": phương án này sai vì bị đảo ngược có chủ ý. Khuyến nghị thật của AWS là "Think services, not servers" — tức ưu tiên dùng các managed service và serverless service thay vì mặc định dựng mọi thứ trên Amazon EC2 rồi tự vận hành. Người học nhớ mang máng khẩu hiệu này rất dễ chọn B vì thấy quen tai. Đọc kỹ thứ tự hai từ servers và services mới thấy nó ngược.

A — "Use manual operational processes": sai rõ ràng nhất. AWS khuyến nghị tự động hoá càng nhiều càng tốt trong vận hành cloud — automation giúp giảm lỗi do con người, khiến thao tác lặp lại được và cho phép hệ thống tự phục hồi. Dựa vào quy trình thủ công là đi ngược lại nguyên tắc đó, và cũng mâu thuẫn trực tiếp với "design for failure": muốn chịu lỗi tốt thì phần phản ứng với lỗi phải chạy tự động chứ không đợi người bấm tay.

📌 Điểm cần nhớ

• "Design for failure" là nguyên tắc kiến trúc cốt lõi của AWS: giả định thành phần sẽ hỏng, rồi dựng resilience vào kiến trúc để hỏng một phần không kéo sập toàn hệ thống.
• Khẩu hiệu đúng là "Think services, not servers" — ưu tiên managed service và serverless thay vì tự dựng và tự vận hành mọi thứ trên EC2. Gặp bản đảo ngược trong đề thì đó là bẫy.
• AWS luôn nghiêng về automation, không bao giờ khuyến nghị manual operational processes. Bất kỳ phương án nào đề cao thao tác thủ công gần như chắc chắn sai trong đề thi.
• Với dạng câu hỏi "best practice recommended by AWS", hãy đối chiếu với đúng câu chữ trong AWS Well-Architected Framework. Phương án sai thường được tạo bằng cách đảo thứ tự từ hoặc thay một từ nghe tích cực hơn ("success" thay cho "failure") — nghe xuôi tai không có nghĩa là AWS có nói vậy.

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

Đề hỏi: đâu là các "architectural best practices" (thực hành kiến trúc tốt) cho AWS Cloud? (Chọn HAI).

Cụm từ quyết định là "architectural best practices" kết hợp với "(Select TWO)". Đây là dạng câu hỏi khái niệm rất phổ biến ở Cloud Practitioner: đề không mô tả một tình huống cụ thể nào, mà kiểm tra xem bạn có nhận ra bộ nguyên tắc thiết kế mà AWS Well-Architected Framework khuyến nghị hay không.

Điểm mấu chốt: năm phương án được cố tình dựng thành các cặp đối lập. Có cặp multiple Availability Zones ↔ single Availability Zone, có cặp loose coupling ↔ close coupling (ở đây chỉ đưa ra vế xấu), và có monolithic ↔ microservices (cũng chỉ đưa vế xấu). Vì vậy cách làm nhanh nhất không phải là đọc từng phương án rồi cân nhắc, mà là hỏi: phương án này làm tăng hay giảm khả năng chịu lỗi? Cái nào làm giảm thì loại thẳng.

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

Theo tệp, đáp án đúng là B — "Design for fault tolerance" và C — "Deploy into multiple Availability Zones".

B – Design for fault tolerance. Nguyên tắc nền tảng của kiến trúc trên cloud là giả định rằng mọi thành phần đều sẽ hỏng vào một lúc nào đó ("design for failure"). Thiết kế có khả năng chịu lỗi nghĩa là khi một tài nguyên hay một phần hạ tầng gặp sự cố, ứng dụng vẫn tiếp tục chạy chứ không sập theo. Đây chính là tinh thần của trụ cột Reliability trong AWS Well-Architected Framework.

C – Deploy into multiple Availability Zones. Đây là cách hiện thực hoá cụ thể nhất của nguyên tắc trên trong hạ tầng AWS. Mỗi Availability Zone là một hoặc nhiều trung tâm dữ liệu tách biệt về nguồn điện, làm mát và kết nối mạng bên trong một Region. Triển khai tài nguyên trải trên nhiều AZ nghĩa là sự cố hạ tầng ở một AZ không kéo đổ toàn bộ ứng dụng.

Hai phương án này bổ trợ nhau: B là nguyên tắc, C là cách áp dụng nguyên tắc đó — nên chúng đi thành cặp rất tự nhiên, khớp với yêu cầu chọn hai.

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

A – Create monolithic architectures. Đây là phương án dễ nhầm nhất với người mới, vì kiến trúc monolithic không hề "sai về kỹ thuật" — nó vẫn chạy được. Nhưng nó hỏng đúng ở chỗ mà câu hỏi quan tâm: trong kiến trúc monolithic, nhiều thành phần của ứng dụng cùng chạy trên một instance, nên chỉ cần một thành phần hỏng là cả ứng dụng hỏng theo. Best practice là hướng tới microservices, nơi các thành phần được tách ra và trải trên nhiều instance, để lỗi của một phần không lan ra toàn hệ thống.

D – Deploy into a single Availability Zone. Đây là vế đối lập trực tiếp của C, đưa vào để bẫy người đọc lướt. Dồn toàn bộ tài nguyên vào một AZ duy nhất nghĩa là bất kỳ sự cố hạ tầng nào ở AZ đó cũng cắt đứt quyền truy cập tới toàn bộ tài nguyên của bạn. Đây là ví dụ điển hình của single point of failure. Lưu ý: C và D không thể cùng đúng — nhận ra một cặp loại trừ nhau như vậy đã giúp bạn khoanh vùng đáng kể.

E – Close coupling. Đây là phương án "gần đúng" nguy hiểm nhất, vì nó chạm đúng một chủ đề nằm trong best practice — nhưng nêu ngược chiều. Best practice là loose coupling, không phải close (tight) coupling. Loose coupling nghĩa là giảm sự phụ thuộc lẫn nhau giữa các thành phần của ứng dụng, thường bằng cách chèn một lớp trung gian như message bus vào giữa. Nhờ đó, một thành phần chậm hoặc chết tạm thời không kéo theo các thành phần khác. Close coupling thì làm điều ngược lại: các thành phần dính chặt vào nhau nên lỗi lan truyền dễ dàng. Đọc lướt thấy chữ "coupling" quen mắt rồi chọn là mắc bẫy.

📌 Điểm cần nhớ

• Với câu hỏi khái niệm về best practice, hãy dùng thước đo "tăng hay giảm khả năng chịu lỗi": mọi phương án làm tăng single point of failure (single AZ, monolithic, close coupling) đều là đáp án sai.
• Các phương án thường được dựng thành cặp đối lập (multiple AZ ↔ single AZ). Hai vế của một cặp không bao giờ cùng đúng — nhận ra cặp này là loại được ngay một phương án.
• Cẩn thận với phương án nêu đúng chủ đề nhưng ngược chiều: best practice là loose coupling và microservices, không phải close coupling và monolithic. Từ khoá quen mắt không đồng nghĩa với đáp án đúng.
• Nhiều AZ là cách hiện thực hoá tính chịu lỗi ở tầng hạ tầng, vì mỗi AZ tách biệt về nguồn điện, làm mát và mạng trong cùng một Region.

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

Đề hỏi: loại lưu trữ nào có thể được mount bằng giao thức NFS lên nhiều EC2 instance cùng lúc?

Cụm từ quyết định nằm ở hai chỗ, và phải thoả cả hai thì phương án mới đúng:

1. "mounted using the NFS protocol" — phải là file storage nói được NFS, tức là hệ điều hành mount vào một thư mục và truy cập theo đường dẫn tệp. Điều này loại ngay mọi thứ là object storage hay block storage thô.
2. "to many EC2 instances simultaneously" — phải cho nhiều instance gắn vào cùng một lúc và cùng nhìn thấy một tập dữ liệu chung.

Đây là mẫu câu kinh điển ép người học phân biệt ba nhóm lưu trữ của AWS: object (S3), block (EBS, Instance Store) và file (EFS). Chỉ cần đọc ra chữ "NFS" là đã đủ khoanh vùng về nhóm file.

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

D — Amazon EFS.

EFS là dịch vụ file storage được quản lý hoàn toàn, dựng sẵn một file system chia sẻ trên AWS. Nó phục vụ đúng bằng giao thức NFS (NFSv4.1), nên EC2 instance chỉ cần chạy lệnh mount như với bất kỳ NFS server nào là dùng được ngay — khớp trực tiếp với vế "mounted using the NFS protocol".

Về vế thứ hai, EFS được thiết kế để rất nhiều EC2 instance kết nối đồng thời vào cùng một file system, và các instance đó có thể nằm ở nhiều Availability Zone khác nhau. Mọi instance đều đọc/ghi trên cùng một kho dữ liệu, thay đổi của instance này instance kia thấy được. Đây chính là kiểu lưu trữ dùng cho web server farm chia sẻ chung thư mục nội dung, hay các workload cần một thư mục dùng chung.

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

A — Amazon S3. Sai vì giao thức. S3 là object storage, truy cập qua API RESTful trên HTTP/HTTPS (GET/PUT object), không phải qua NFS. Đúng là S3 cho rất nhiều client truy cập đồng thời — nên nhiều người bị vế "simultaneously" kéo về đây — nhưng nó không phải thứ hệ điều hành mount thành một thư mục theo giao thức NFS, và cũng không có ngữ nghĩa file system như đề đòi hỏi.

B — Amazon EBS. Đây là phương án gần đúng nhất và cũng là bẫy chính. EBS đúng là lưu trữ bền, gắn vào EC2 được — nhưng hỏng ở cả hai điều kiện: nó là block device (instance nhìn thấy như một ổ đĩa thô, phải tự format rồi mới mount, không nói NFS), và một volume EBS thông thường chỉ gắn vào một EC2 instance tại một thời điểm. Muốn nhiều máy dùng chung một volume là đi ngược lại mô hình của EBS.

C — Amazon Instance Store. Sai nặng hơn EBS ở cả hai mặt. Instance Store là block storage tạm thời (ephemeral) nằm ngay trên phần cứng vật lý của host chạy instance — dữ liệu mất khi instance dừng hoặc bị thu hồi. Vì nó gắn cứng với đúng một máy chủ vật lý, nó chỉ phục vụ một instance duy nhất và hoàn toàn không có khái niệm chia sẻ qua NFS.

📌 Điểm cần nhớ

• Ba nhóm lưu trữ AWS, nhớ theo giao thức truy cập: S3 = object, qua REST API/HTTP; EBS và Instance Store = block, gắn như ổ đĩa; EFS = file, qua NFS. Thấy chữ "NFS" hay "mount" trong đề thì gần như chắc chắn là EFS.
• Từ khoá "many/multiple EC2 instances simultaneously" hay "shared file system" là dấu hiệu loại EBS và Instance Store — cả hai đều theo mô hình một volume phục vụ một instance.
• Phân biệt EBS với Instance Store bằng tính bền: EBS tồn tại độc lập với vòng đời instance, còn Instance Store là ephemeral, mất dữ liệu khi instance dừng. Dữ liệu cần giữ lại thì không đặt trên Instance Store.
• EFS còn có lợi thế truy cập được từ nhiều Availability Zone, trong khi một volume EBS bị ràng buộc trong một AZ — đây là điểm hay bị hỏi kèm ở các câu về tính sẵn sàng.

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

Đề hỏi về đặc điểm của users và groups trong AWS IAM, và yêu cầu chọn HAI phương án (Select TWO).

Cụm từ quyết định nằm ngay ở phần "characteristics of users and groups" — đây không phải câu tình huống mà là câu kiểm tra mô hình quan hệ giữa IAM user và IAM group. Toàn bộ năm phương án đều xoay quanh đúng hai điểm:

• Một user thuộc được bao nhiêu group?
• Group có chứa được group khác không (nested group)?

Vì thế cần nắm chắc hai nguyên tắc: quan hệ user ↔ group là nhiều–nhiều, và cấu trúc group là phẳng (flat), không phân cấp. Bất kỳ phương án nào nói khác hai điều đó đều sai.

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

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

E — "A user can be a member of multiple groups." Trong IAM, một user hoàn toàn có thể thuộc nhiều group cùng lúc. Đây chính là cách người ta gộp quyền: đặt user vào group Developers và đồng thời vào group Billing-ReadOnly, user nhận hợp của các policy gắn trên cả hai group cộng với policy gắn trực tiếp lên chính user đó. Số group tối đa mà một user tham gia có bị giới hạn theo hạn mức của IAM, nhưng điều cần nhớ cho kỳ thi là không bị giới hạn ở một group.

D — "Groups can contain users only and cannot be nested." IAM group là một tập hợp phẳng các user. Group không phải là identity dùng để đăng nhập, không có credential riêng, không đóng vai principal trong sts:AssumeRole, và quan trọng nhất với câu này: group không chứa group khác. Muốn mô phỏng phân cấp quyền, cách làm trong IAM là đặt user vào nhiều group song song (chính là ý E), chứ không phải lồng group vào nhau. Hai phương án D và E vì thế bổ trợ cho nhau và cùng mô tả đúng mô hình quan hệ nhiều–nhiều, phẳng của IAM.

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

A — "All new users are automatically added to a default group." IAM không có khái niệm default group. Khi tạo một IAM user mới, user đó không thuộc group nào cả trừ khi bạn chủ động thêm vào. User hoàn toàn có thể tồn tại độc lập, chỉ mang các policy gắn trực tiếp (inline hoặc managed policy attach thẳng lên user). Phương án này nghe hợp lý vì nhiều hệ thống quản lý người dùng khác có nhóm mặc định, nhưng IAM thì không.

B — "A user can only be a member of a single group at one time." Đây là phương án gần đúng nhất và cũng là bẫy chính, vì nó mâu thuẫn trực tiếp với E. Nó đúng về mặt "user có thể thuộc group", chỉ sai ở con số: giới hạn là nhiều group chứ không phải một. Nếu chọn B thì cũng phải loại E, và khi đó câu hỏi "Select TWO" không còn đủ đáp án hợp lý. Trong một câu chọn nhiều đáp án mà hai phương án phủ định nhau như B và E, gần như chắc chắn một trong hai là đáp án đúng — việc còn lại là nhớ đúng chiều.

C — "Groups can be nested and can contain other groups." Sai vì đúng lý do làm D đúng: IAM group là cấu trúc phẳng, không hỗ trợ nested group. C cũng là cặp phủ định trực tiếp của D. Đây là chỗ hay nhầm với mô hình group lồng nhau của các directory service truyền thống; IAM cố ý không đi theo hướng đó để giữ việc tính quyền đơn giản và dễ suy luận.

📌 Điểm cần nhớ

• Quan hệ IAM user ↔ IAM group là nhiều–nhiều: một group chứa nhiều user, một user thuộc nhiều group. Quyền hiệu lực là hợp của policy từ mọi group cộng policy gắn trực tiếp lên user.
• IAM group không lồng nhau và chỉ chứa user — không chứa group, không chứa role. Cần "phân cấp" thì dùng nhiều group song song.
• Không có default group: user mới tạo không tự động thuộc group nào, và có thể tồn tại mà không thuộc group nào cả.
• Trong câu "Select TWO", hãy soi các cặp phương án phủ định nhau (B ↔ E, C ↔ D). Mỗi cặp chỉ có một vế đúng, nên xác định đúng chiều của hai cặp là ra trọn đáp án.

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

Đề hỏi: "Which of the following are advantages of the AWS Cloud? (Select TWO.)" — đâu là hai lợi ích khi dùng AWS Cloud.

Cụm từ quyết định đáp án nằm ở chữ "advantages of the AWS Cloud" kết hợp với chủ ngữ chung của cả năm phương án: "AWS manages…". Cả năm phương án đều mở đầu giống hệt nhau, nên câu này thực chất không hỏi "lợi ích chung của điện toán đám mây" mà hỏi: trong Shared Responsibility Model, việc nào thuộc về AWS, việc nào vẫn thuộc về khách hàng? Chỉ những việc AWS thật sự gánh mới là lợi ích mà khách hàng được hưởng.

Ranh giới phân biệt: AWS chịu trách nhiệm security OF the cloud — hạ tầng vật lý (data center, physical server, storage, networking equipment); khách hàng chịu trách nhiệm security IN the cloud — ứng dụng, dữ liệu, cấu hình, và cả chi phí mình tiêu. Cứ đọc từng phương án và hỏi "thứ này nằm ở tầng vật lý hay tầng khách hàng tự dựng?" là chọn được.

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

Đáp án đúng theo tệp là C và D.

C — "AWS manages capacity planning for physical servers". Đây là đúng nghĩa lợi ích cốt lõi của cloud: khách hàng không còn phải đoán trước sẽ cần bao nhiêu máy chủ vật lý rồi mua dư cho chắc. AWS lo việc mua sắm, lắp đặt và dự trù công suất cho tầng phần cứng vật lý trong data center. Chú ý chữ physical — nó chốt phương án này nằm hẳn bên phía AWS.

D — "AWS manages the maintenance of the cloud infrastructure". Bảo trì hạ tầng đám mây — thay ổ cứng hỏng, bảo dưỡng thiết bị mạng, vận hành điện/làm mát của data center — hoàn toàn thuộc về AWS. Khách hàng không bao giờ chạm tới lớp này, và cũng chính vì thế mà không phải trả chi phí đội ngũ vận hành phần cứng.

Hai phương án này là hai vế kinh điển của "security of the cloud": AWS lo phần cứng và cơ sở vật chất bên dưới.

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

A — "AWS manages cost planning for virtual servers". Đây là phương án gần đúng nhất và dễ bẫy nhất, vì AWS có cung cấp công cụ giúp nhìn và ước tính chi phí. Nhưng "manages cost planning" nghĩa là AWS đứng ra hoạch định chi phí thay bạn — không phải vậy. Chọn loại instance nào, chạy bao nhiêu, mua On-Demand hay cam kết dài hạn, tắt máy lúc không dùng — tất cả là quyết định của khách hàng, và hoá đơn cũng do khách hàng chịu. Ngoài ra chữ virtual ở đây đối lập với chữ physical ở phương án C: máy ảo là thứ khách hàng tự tạo ra và tự quản.

B — "AWS manages the security of applications built on AWS". Bẫy nằm ở chỗ AWS thật sự có trách nhiệm về bảo mật — nhưng là bảo mật của đám mây, không phải bảo mật của ứng dụng bạn viết chạy trên đám mây. Lỗ hổng trong code, phân quyền sai, dữ liệu để công khai, mật khẩu yếu — đều thuộc về khách hàng. Đây chính là vế "security in the cloud".

E — "AWS manages the development of applications on AWS". Sai rõ ràng nhất. AWS cung cấp dịch vụ và công cụ để bạn xây dựng, nhưng không viết ứng dụng thay khách hàng. Việc phát triển ứng dụng luôn nằm phía khách hàng.

📌 Điểm cần nhớ

• Ranh giới nhớ một lần dùng mãi: security OF the cloud là của AWS (hạ tầng vật lý, data center, phần cứng, mạng); security IN the cloud là của khách hàng (ứng dụng, dữ liệu, cấu hình, quyền truy cập).
• Từ khoá physical thường kéo trách nhiệm về phía AWS; từ khoá virtual, application, data thường kéo về phía khách hàng. Đọc kỹ tính từ trước danh từ trước khi chọn.
• Chi phí là trách nhiệm của khách hàng. AWS đưa công cụ để theo dõi và ước tính, nhưng không "hoạch định chi phí" thay bạn — đừng nhầm "có công cụ hỗ trợ" với "AWS quản lý giúp".
• Khi cả các phương án cùng mở đầu bằng "AWS manages…", câu hỏi thực chất là bài kiểm tra Shared Responsibility Model chứ không phải câu hỏi về lợi ích chung của cloud.

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

Đề hỏi: khả năng horizontally scale các Amazon EC2 instance based on demand là ví dụ của khái niệm nào trong các lợi ích của AWS Cloud.

Cụm từ quyết định đáp án là "based on demand" — tức là năng lực được điều chỉnh theo nhu cầu thực tế tại từng thời điểm. Bốn phương án đều là những từ khoá quen thuộc trong tài liệu AWS Well-Architected, dễ nhầm, nên phải bám vào đúng ý "co giãn theo nhu cầu" chứ không phải "chạy nhanh hơn", "rẻ hơn" hay "không chết".

Cụm thứ hai đáng chú ý là "horizontally scale" — thêm/bớt số lượng EC2 instance. Nó chỉ nói cách mở rộng (theo chiều ngang, đối lập với chiều dọc là tăng kích cỡ instance), chứ không đổi bản chất khái niệm. Cả hai chiều đều thuộc cùng một khái niệm gốc.

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

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

Elasticity là khả năng điều chỉnh năng lực của một dịch vụ hoặc tài nguyên một cách động, theo nhu cầu. Đúng với những gì đề mô tả: nhu cầu tăng thì thêm EC2 instance, nhu cầu giảm thì bớt đi.

Việc mở rộng có thể theo hai chiều, và cả hai đều là biểu hiện của elasticity:

• Vertical — tăng kích cỡ của một instance (ví dụ đổi sang instance type lớn hơn).
• Horizontal — tăng số lượng EC2 instance, đúng như đề nêu.

Vì đề nói rõ "based on demand", việc thêm instance không phải là mở rộng một lần cho xong mà là bám theo tải, nên đây là ví dụ sách vở của elasticity.

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

A — Economy of scale. Đây là lợi ích về giá: AWS mua và vận hành tài nguyên ở quy mô rất lớn, nên chi phí trên mỗi đơn vị thấp hơn và phần tiết kiệm đó được chuyển sang khách hàng. Nó nói về bạn trả bao nhiêu tiền, không nói về hệ thống có tự co giãn theo tải hay không. Đề không nhắc gì tới chi phí hay đơn giá, nên phương án này lạc chủ đề.

B — High availability. Đây là ví dụ của resilience — khả năng hệ thống tiếp tục phục vụ khi có thành phần hỏng. Đây là phương án gần đúng nhất và cũng là bẫy dễ dính, vì trên thực tế người ta hay chạy nhiều EC2 instance để vừa chịu tải vừa dự phòng. Nhưng chỗ nó hỏng là ở động cơ: high availability nói tới việc chạy nhiều bản dự phòng để chống hỏng hóc, còn đề nêu rõ số lượng instance thay đổi theo demand, tức là theo tải chứ không theo sự cố. Nhiều instance là hệ quả chung của cả hai khái niệm, nhưng câu hỏi hỏi khái niệm nào mô tả việc "điều chỉnh theo nhu cầu" — đó là elasticity.

D — Agility. Đây là ví dụ của tính linh hoạt và tốc độ triển khai — khả năng thử nghiệm, dựng và bỏ tài nguyên nhanh, rút ngắn thời gian từ ý tưởng tới sản phẩm. Nó cũng là hệ quả của việc dùng cloud và cũng "nhanh", nên nghe qua có vẻ hợp. Chỗ nó hỏng: agility nói về tốc độ đưa thứ mới vào vận hành, còn đề mô tả một hệ thống đang chạy tự tăng giảm năng lực theo tải. Đó là hai ý khác nhau.

📌 Điểm cần nhớ

• "Based on demand" / "theo nhu cầu" là từ khoá của Elasticity. Thấy cụm này trong đề, gần như chắc chắn đáp án là elasticity chứ không phải ba khái niệm còn lại.
• Horizontal và vertical scaling đều thuộc elasticity. Horizontal = thêm/bớt số lượng instance; vertical = đổi kích cỡ instance. Chiều nào không làm đổi khái niệm gốc.
• Ghép nhanh khái niệm với từ khoá để không lẫn khi bốn phương án cùng xuất hiện: elasticity ↔ theo nhu cầu; high availability ↔ resilience, chịu được hỏng hóc; agility ↔ triển khai nhanh, thử nghiệm nhanh; economy of scale ↔ giá rẻ nhờ quy mô.
• Phân biệt "nhiều instance vì tải" với "nhiều instance vì dự phòng". Cùng một hình ảnh nhưng hai khái niệm khác nhau — đọc kỹ xem đề nhấn vào demand hay vào failure.

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

Đề hỏi: dịch vụ AWS nào dùng machine learning để phân tích lịch sử sử dụng (historical usage patterns) nhằm chỉ ra tài nguyên AWS tối ưu giúp giảm chi phí và cải thiện hiệu năng cho workload.

Cụm từ quyết định đáp án là "uses machine learning to analyze historical usage patterns" kết hợp với "identify the optimal AWS resources". Cả bốn phương án đều nằm trong nhóm chi phí/tối ưu nên rất dễ lẫn, nhưng chỉ có một dịch vụ vừa dựa trên machine learning trên dữ liệu sử dụng quá khứ, vừa trả về khuyến nghị cấu hình tài nguyên cụ thể (chứ không phải cảnh báo ngân sách hay biểu đồ chi tiêu). Đọc kỹ, đề còn thêm chi tiết "improving performance" — nó loại ngay những dịch vụ thuần về tiền bạc.

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

D — AWS Compute Optimizer. Đây đúng là dịch vụ dùng machine learning phân tích các mẫu sử dụng trong quá khứ của workload để đề xuất tài nguyên AWS phù hợp nhất, qua đó vừa giảm chi phí vừa nâng hiệu năng. Điểm khớp từng chữ với đề:

• machine learning: Compute Optimizer xây mô hình từ dữ liệu sử dụng thay vì áp một bộ luật cố định.
• historical usage patterns: đầu vào là số liệu sử dụng đã ghi nhận theo thời gian của tài nguyên, không phải trạng thái tức thời.
• optimal AWS resources: kết quả là khuyến nghị mang tính "nên dùng cấu hình nào", tức là nói về chính tài nguyên chứ không phải về hoá đơn.
• reducing costs and improving performance: hai mục tiêu song song — đúng định vị của dịch vụ này.

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

A — AWS Budgets. Đây là công cụ đặt ngưỡng ngân sách chi phí và mức sử dụng, rồi cảnh báo khi vượt ngưỡng. Nó trả lời câu hỏi "tôi có tiêu quá dự kiến không", chứ không phân tích lịch sử bằng machine learning để nói "nên đổi tài nguyên sang cấu hình nào". Budgets không đưa ra khuyến nghị tối ưu tài nguyên, và hoàn toàn không đụng tới vế "improving performance" của đề.

B — AWS Cost Explorer. Đây là phương án gần đúng nhất và dễ bẫy nhất, vì Cost Explorer đúng là làm việc trên dữ liệu chi tiêu và sử dụng trong quá khứ, có biểu đồ theo thời gian. Nhưng nó hỏng ở vế đầu ra: Cost Explorer giúp trực quan hoá, hiểu và quản lý chi tiêu — nó cho bạn thấy tiền đi đâu, chứ không đưa ra khuyến nghị tối ưu tài nguyên dựa trên phân tích machine learning các mẫu sử dụng như đề mô tả. Nhìn thấy chi phí tăng ở đâu khác hẳn với việc được chỉ đích danh tài nguyên nào nên đổi.

C — AWS Trusted Advisor. Cũng gần đúng vì nó có đưa khuyến nghị và có hạng mục tiết kiệm chi phí lẫn hiệu năng. Chỗ hỏng nằm ở cơ chế: Trusted Advisor đưa hướng dẫn theo thời gian thực dựa trên bộ kiểm tra best practice của AWS — kiểu "tài nguyên này đang nhàn rỗi", "cấu hình này lệch khuyến nghị". Nó không phải là dịch vụ được mô tả bằng cụm "dùng machine learning phân tích historical usage patterns để chỉ ra tài nguyên tối ưu". Đề đã cố ý đặt hai từ khoá machine learning + historical để tách nó khỏi Compute Optimizer.

📌 Điểm cần nhớ

• Gặp cụm "machine learning" + "historical usage" + "right-size / optimal resources" trong đề AWS về chi phí thì đáp án gần như luôn là AWS Compute Optimizer.
• Phân biệt theo đầu ra của dịch vụ: Budgets → cảnh báo khi vượt ngưỡng; Cost Explorer → biểu đồ và phân tích chi tiêu quá khứ; Trusted Advisor → kiểm tra theo best practice; Compute Optimizer → khuyến nghị cấu hình tài nguyên.
• Vế "improving performance" là bộ lọc nhanh: những dịch vụ chỉ nói về tiền (Budgets, Cost Explorer) bị loại trước tiên.
• Trusted Advisor và Compute Optimizer chồng lấn về mục tiêu nhưng khác cơ chế — best-practice checks (thời gian thực) so với mô hình học từ dữ liệu sử dụng quá khứ. Đề nào nhấn vào cơ chế thì cứ bám vào đó mà chọn.

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

Đề hỏi: đội ngũ nào hỗ trợ khách hàng dùng gói Enterprise support plan khi họ gặp account issues (vấn đề về tài khoản)?

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

• "Enterprise support plan" — giới hạn phạm vi vào những quyền lợi chỉ có ở gói cao nhất. Các đội ngũ có mặt ở mọi gói (kể cả Basic/Developer) sẽ không phải là câu trả lời mà đề nhắm tới.
• "account issues" — đây là ràng buộc phân biệt thật sự. Đề không hỏi về sự cố kỹ thuật, kiến trúc hay tối ưu workload; nó hỏi về những chuyện thuộc về tài khoản và hoá đơn: thanh toán, cấu trúc account, thắc mắc về chi phí.

Ghép hai điều kiện lại: cần một đội chuyên billing và account dành riêng cho khách hàng Enterprise. Đó chính là AWS Concierge.

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

Đáp án đúng theo tệp là B — AWS Concierge.

Support Concierge Team là một phần quyền lợi đi kèm gói Enterprise Support. Đây là nhóm chuyên gia về billing và account của AWS, chuyên làm việc với các tài khoản quy mô doanh nghiệp. Khi khách hàng Enterprise có câu hỏi hay vướng mắc liên quan tới tài khoản — cấu trúc account, hoá đơn, các thắc mắc phi kỹ thuật về chi phí — thì Concierge là điểm liên hệ được thiết kế đúng cho việc đó.

Điểm mấu chốt: Concierge được định vị theo loại vấn đề (account/billing), chứ không phải theo mức độ nghiêm trọng kỹ thuật. Đề hỏi "account issues" nên khớp thẳng vào định nghĩa của đội này.

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

A — AWS Technical Support. Sai vì hai lẽ. Thứ nhất, đây không phải tên của một đội ngũ riêng biệt mà đề đang nhắm tới — nó là cách gọi chung cho hoạt động hỗ trợ kỹ thuật. Thứ hai, kể cả hiểu theo nghĩa chung nhất thì phạm vi của nó là vấn đề kỹ thuật, không phải account issues. Đây là phương án đánh vào phản xạ "cứ hỗ trợ thì chọn Technical Support", nhưng nó trượt đúng cụm từ then chốt của đề.

C — AWS Billing and Accounts. Đây là phương án gần đúng nhất và nguy hiểm nhất, vì tên của nó lặp lại gần như nguyên văn cụm "account issues" trong đề. Nó hỏng ở chỗ: đúng chức năng nhưng sai tên đội ngũ. Chính Support Concierge Team mới là đội đảm nhiệm vai trò billing và account cho khách hàng Enterprise. Đề đang hỏi "which team", tức là hỏi tên gọi chính thức, nên một mô tả chức năng chung chung không phải câu trả lời. Đây là dạng bẫy rất hay gặp: một phương án mô tả đúng việc cần làm nhưng không phải tên thực thể mà AWS dùng.

D — AWS Technical Account Manager (TAM). Phương án gần đúng thứ hai, vì TAM cũng là quyền lợi của gói Enterprise — nên nếu chỉ bám vào cụm "Enterprise support plan" mà bỏ qua "account issues" thì rất dễ chọn nhầm. Nó hỏng ở phạm vi công việc: TAM cung cấp monitoring và tối ưu hoá chuyên sâu cho môi trường của khách hàng, đồng thời điều phối việc tiếp cận các chương trình và chuyên gia khác của AWS. Đó là vai trò thiên về kỹ thuật và kiến trúc, không phải xử lý vấn đề tài khoản. Chữ "Account" trong tên gọi dễ gây hiểu lầm — ở đây nó mang nghĩa "khách hàng được phụ trách", chứ không phải "tài khoản/hoá đơn".

📌 Điểm cần nhớ

• Concierge = billing và account; TAM = kỹ thuật và tối ưu hoá. Cả hai đều thuộc gói Enterprise, nên khi thấy đề nhắc Enterprise thì phải đọc tiếp xem vấn đề thuộc loại nào mới phân biệt được.
• Chữ "Account" trong Technical Account Manager không có nghĩa là tài khoản/hoá đơn — đây là bẫy chữ nghĩa được dùng lặp lại nhiều lần trong đề thi.
• Khi đề hỏi "which team", hãy tìm tên gọi chính thức của đội ngũ. Phương án chỉ mô tả chức năng bằng ngôn ngữ thường (kiểu "Billing and Accounts") thường là phương án bịa ra để đánh lừa.
• Chiến thuật đọc đề hỗ trợ AWS: xác định gói support (lọc bớt phương án) rồi xác định loại vấn đề (kỹ thuật hay tài khoản) — hai bước này gần như luôn đủ để chốt đáp án.