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

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

Đề hỏi: làm cách nào để chặn một địa chỉ IP đáng ngờ kết nối tới một Amazon EC2 instance.

Cụm từ quyết định ở đây là "block a suspicious IP address" — tức là từ chối đúng một IP cụ thể — cộng với "from connecting to", nghĩa là lưu lượng đang đi vào (inbound) instance.

Hai chi tiết này chia đôi danh sách phương án:

• "block" loại bỏ security group. Security group là stateful và chỉ hỗ trợ rule cho phép (allow); không có khái niệm rule từ chối trong security group. Bạn có thể liệt kê những IP được vào, chứ không thể nói "riêng IP này thì cấm". Network ACL thì ngược lại: nó stateless và hỗ trợ cả rule ALLOW lẫn DENY, nên đây là chỗ duy nhất trong hai cơ chế này diễn đạt được ý "chặn IP X".
• "from connecting to" loại bỏ hướng outbound. Kết nối đến từ bên ngoài đi vào là inbound rule; outbound là lưu lượng do chính instance/subnet phát ra.

Chỉ có một phương án thoả cả hai ràng buộc.

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

Đáp án đúng theo tệp là C — "Block the IP on the inbound rule of a network ACL."

Network ACL hoạt động ở tầng subnet trong VPC và có luật đánh số theo thứ tự, trong đó mỗi luật có thể là ALLOW hoặc DENY cho một dải CIDR. Muốn cấm một IP đáng ngờ, ta thêm một luật DENY cho IP đó ở inbound, đặt số thứ tự nhỏ hơn luật ALLOW chung, thì mọi gói tin đến từ IP đó bị chặn ngay trước khi vào subnet chứa EC2 instance. Vì network ACL là stateless, luật inbound áp cho chính chiều đi vào, đúng với điều đề bài mô tả.

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

• A — "inbound rule of a security group and network ACL": phần network ACL thì đúng, nhưng phần security group thì không làm được. Đây là phương án gần đúng nhất và cũng là bẫy chính: nó nghe có vẻ "an toàn hơn vì chặn ở cả hai lớp". Vấn đề là security group không có luật deny — bạn không thể tạo một entry nói "cấm IP này" trong security group. Vế thứ hai của câu là một thao tác không tồn tại, nên cả phương án sai.

• B — "outbound rule of a security group and network ACL": sai kép. Thứ nhất, vẫn dựa vào security group để chặn IP, điều không làm được như đã nói ở A. Thứ hai, sai luôn cả hướng: outbound áp cho lưu lượng đi ra khỏi instance/subnet, trong khi đề nói về việc IP kia kết nối tới instance — đó là inbound.

• D — "outbound rule of a security group": sai ở cùng hai điểm với B nhưng không có phần network ACL nào để cứu vãn. Security group không chặn được IP cụ thể, và outbound cũng không phải hướng cần xử lý.

Điểm chung của ba phương án sai: cả ba đều nhờ vào security group để thực hiện việc "chặn", trong khi security group chỉ biết cho phép.

📌 Điểm cần nhớ

• Security group = allow-only, stateful, gắn với ENI/instance. Thấy đề nói "block/deny một IP cụ thể" thì gần như chắc chắn đáp án là network ACL, không phải security group.
• Network ACL = có cả allow và deny, stateless, gắn với subnet. Vì stateless nên khi cần cho phép trao đổi hai chiều thì phải khai cả luật inbound và outbound; còn khi chỉ cần chặn một nguồn đang gọi vào thì inbound là đủ.
• Đọc kỹ hướng lưu lượng. "Connecting to the instance" → inbound. "Instance gọi ra ngoài" → outbound. Nhiều phương án chỉ khác nhau đúng ở từ inbound/outbound.
• Cẩn thận với phương án kiểu "làm cả hai lớp cho chắc". Một phương án ghép hai thành phần chỉ đúng khi cả hai thành phần đều hợp lệ; một vế mô tả thao tác không tồn tại là đủ để loại cả phương án.

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

Đề hỏi: tổ chức muốn theo dõi danh mục tài nguyên (resource inventory) và lịch sử cấu hình (configuration history) phục vụ mục đích bảo mật và tuân thủ quy định.

Cụm từ quyết định đáp án là "resource inventory and configuration history" — tức là "hiện tại tôi đang có những tài nguyên nào, cấu hình của chúng ra sao, và cấu hình đó đã thay đổi thế nào theo thời gian". Đây là câu hỏi về trạng thái của tài nguyên, chứ không phải về hành động của người dùng, không phải về mối đe dọa, và cũng không phải về giấy tờ chứng nhận tuân thủ.

Cụm "security and regulatory compliance" ở cuối câu là phần dễ đánh lừa: cả bốn phương án đều liên quan tới bảo mật hoặc tuân thủ theo một nghĩa nào đó, nên nếu chỉ bám vào từ "compliance" thì không phân biệt được. Ràng buộc thật sự nằm ở hai danh từ đứng trước nó.

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

A. Configure AWS Config with the resource types

AWS Config là dịch vụ được quản lý hoàn toàn, cung cấp đúng ba thứ đề bài đang cần:

• Resource inventory — danh sách các tài nguyên AWS đang tồn tại trong tài khoản.
• Configuration history — lịch sử cấu hình của từng tài nguyên, cho phép nhìn lại tài nguyên đó đã trông như thế nào ở một thời điểm trong quá khứ.
• Configuration change notifications — thông báo khi cấu hình thay đổi.

Chính vì vậy khi cấu hình AWS Config, bạn khai báo resource types (loại tài nguyên) cần ghi nhận — đúng như cách diễn đạt trong phương án. Bộ ba này là nền tảng để chứng minh với bộ phận kiểm toán rằng hạ tầng luôn ở trạng thái được phép, và để phát hiện khi có cấu hình lệch chuẩn.

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

C. Create an Amazon CloudTrail trail — đây là phương án gần đúng nhất và cũng dễ nhầm nhất, vì CloudTrail cũng ghi lại lịch sử và cũng dùng cho kiểm toán. Nhưng CloudTrail theo dõi API activity: ai đã gọi API nào, lúc nào, từ đâu. Nói ngắn gọn, CloudTrail trả lời câu hỏi "ai làm gì", còn AWS Config trả lời câu hỏi "tài nguyên đang ở trạng thái nào và đã đổi ra sao". CloudTrail không cung cấp danh mục tài nguyên, cũng không cung cấp lịch sử cấu hình của tài nguyên. Đề bài hỏi về trạng thái tài nguyên chứ không hỏi về hành vi người gọi API, nên C trượt.

B. Implement Amazon GuardDuty — GuardDuty làm threat detection và giám sát bảo mật liên tục, phát hiện hành vi độc hại hoặc trái phép nhằm bảo vệ tài khoản và workload. Nó cảnh báo về mối đe dọa, không lập danh mục tài nguyên và không lưu lịch sử cấu hình. Nó đúng về nhóm "bảo mật" nhưng sai hoàn toàn về chức năng đề bài yêu cầu.

D. Run a report with AWS Artifact — Artifact là nơi tải báo cáo bảo mật và tuân thủ theo yêu cầu cùng một số thoả thuận trực tuyến, ví dụ các báo cáo SOC hay PCI. Điểm mấu chốt: đó là báo cáo về hạ tầng của chính AWS, dùng để đưa cho kiểm toán viên xem AWS đã đạt những chứng nhận gì. Bạn không dùng Artifact để theo dõi danh mục tài nguyên và lịch sử cấu hình của mình. Từ "compliance" trong đề khiến phương án này trông hợp lý, nhưng hướng của nó ngược lại với yêu cầu.

📌 Điểm cần nhớ

• AWS Config = trạng thái tài nguyên: resource inventory, configuration history, và thông báo khi cấu hình đổi. Thấy hai chữ "configuration history" hoặc "resource inventory" trong đề thì gần như chắc chắn là AWS Config.
• CloudTrail = hành động của người dùng: ghi API activity, trả lời "ai làm gì". Cặp Config ↔ CloudTrail bị hỏi đi hỏi lại; phân biệt bằng câu hỏi "đề đang hỏi về tài nguyên hay về người gọi API".
• GuardDuty = phát hiện mối đe dọa, không phải công cụ kiểm kê hay kiểm toán cấu hình.
• AWS Artifact = báo cáo tuân thủ của AWS (SOC, PCI…), tức tài liệu tải về, không phải công cụ theo dõi tài nguyên của bạn. Từ "compliance" trong đề không tự động dẫn tới Artifact.

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

Đề hỏi: khả năng của một kiến trúc chịu được sự cố (withstand failures) mà thời gian ngừng hoạt động ở mức tối thiểu (minimal downtime) thể hiện lợi ích nào của AWS Cloud.

Cụm từ quyết định đáp án là "withstand failures with minimal downtime". Cả bốn phương án đều là những lợi ích có thật của AWS Cloud và người học rất dễ lẫn, nhưng chúng trả lời bốn câu hỏi khác nhau:

• Hỏng một phần thì hệ thống có tiếp tục phục vụ không? → chuyện của availability
• Bao lâu thì đưa được ý tưởng lên chạy? → agility
• Tải tăng thì hệ thống lớn lên tới đâu? → scalability
• Có lấy thêm và trả lại tài nguyên theo nhu cầu thực không? → elasticity

Đề không hề nhắc tới tải, tới tốc độ triển khai, hay tới chuyện tăng giảm tài nguyên. Nó chỉ nói về hỏng hóc và downtime — đó là dấu hiệu duy nhất cần bám vào.

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

A. High availability — đúng.

High availability là đặc tính của hạ tầng vẫn tiếp tục hoạt động ngay cả khi một số thành phần của nó hỏng. Đây chính là định nghĩa được diễn đạt lại trong đề bài: kiến trúc chịu được sự cố, và người dùng gần như không cảm nhận được gián đoạn.

Lý do lợi ích này quan trọng: các hệ thống mission-critical không chấp nhận được việc dịch vụ bị đứt quãng — mỗi phút downtime đều có thể quy ra thiệt hại kinh doanh hoặc tài chính. Vì vậy AWS đặt high availability thành một lợi ích riêng, tách khỏi các lợi ích về quy mô và tốc độ.

Trên AWS, high availability đạt được bằng cách loại bỏ điểm hỏng đơn lẻ: chạy nhiều bản sao của thành phần, đặt chúng ở những vùng cách ly lỗi khác nhau, và đặt một cơ chế phân phối lưu lượng phía trước để bỏ qua thành phần đã hỏng. Bản chất là dư thừa (redundancy) + chuyển hướng khi hỏng, chứ không phải là chạy được nhiều tải hơn.

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

B. Agility — sai. Agility nói về việc thời gian đưa ứng dụng và dịch vụ ra mắt được rút ngắn cực mạnh: thay vì đặt mua và lắp đặt máy chủ theo tuần hoặc tháng, ta cấp phát tài nguyên trong vài phút, thử nghiệm nhanh, sai thì bỏ đi làm lại với chi phí thấp. Đó là lợi ích về tốc độ đổi mới, hoàn toàn không đề cập tới việc hệ thống ứng xử ra sao khi có thành phần hỏng. Đề bài không có chữ nào về thời gian triển khai.

C. Scalability — sai, và đây là phương án gần đúng nhất nên cần nói rõ nó hỏng ở đâu. Scalability là khả năng hệ thống lớn lên (hoặc nhỏ đi) để phục vụ mức tải thay đổi — thêm instance, dùng máy cấu hình mạnh hơn, mở rộng tầng dữ liệu. Điểm gây nhầm: một kiến trúc scale-out với nhiều instance thường cũng có tính sẵn sàng cao, nên hai khái niệm hay đi cùng nhau trong cùng một sơ đồ. Nhưng scalability trả lời câu hỏi "tải bình thường tăng lên thì sao", không phải "một thành phần chết thì sao". Một hệ thống có thể scale rất tốt mà vẫn sập toàn bộ khi thành phần dùng chung duy nhất của nó hỏng. Đề bài nói về failure và downtime, nên scalability không phải là thứ đang được mô tả.

D. Elasticity — sai. Elasticity là khả năng lấy thêm tài nguyên đúng lúc cần và trả lại khi không cần nữa, tức là bám sát nhu cầu thực để không phải trả tiền cho phần công suất ngồi không. Nó là họ hàng gần của scalability (thêm yếu tố tự động và trả lại), và cũng vì vậy mà nó cũng gắn với nhu cầu tải, không gắn với gián đoạn dịch vụ. Việc thu hồi tài nguyên khi hết tải chẳng nói gì về chuyện hệ thống sống sót qua sự cố.

📌 Điểm cần nhớ

• High availability = chịu được hỏng hóc, giữ downtime ở mức tối thiểu. Thấy trong đề các từ failure, fault, outage, downtime, continues to function → nghĩ ngay tới availability.
• Scalability và elasticity đều là chuyện của tải, không phải chuyện của sự cố. Scalability = lớn lên/nhỏ đi theo nhu cầu; elasticity = lấy thêm rồi trả lại tự động theo nhu cầu thực. Đề nói về lưu lượng tăng vọt hay tiết kiệm chi phí lúc rảnh thì mới chọn hai cái này.
• Agility = tốc độ ra mắt và thử nghiệm, là lợi ích về thời gian đưa sản phẩm ra thị trường, không liên quan tới độ bền của kiến trúc.
• Với dạng câu "đặc điểm này thể hiện lợi ích nào của AWS Cloud", hãy quy mỗi phương án về câu hỏi mà nó trả lời rồi so với câu hỏi mà đề đang đặt ra — cách này tách được các thuật ngữ nghe rất giống nhau.

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

Đề hỏi: "To gain greater discounts, which services can be reserved? (Select TWO.)" — dịch vụ nào cho phép đặt trước (reserve) dung lượng/công suất để đổi lấy mức giá rẻ hơn.

Cụm từ quyết định là "can be reserved", chứ không phải "greater discounts". Đây là điểm bẫy: rất nhiều dịch vụ AWS có cách giảm giá (dùng nhiều thì đơn giá bậc thang, hoặc chuyển sang tầng lưu trữ rẻ hơn), nhưng câu hỏi thu hẹp lại đúng một mô hình giá cụ thể — Reserved Instances / Reserved Capacity: cam kết trước một lượng công suất trong một kỳ hạn (thường 1 hoặc 3 năm), trả trước toàn phần hoặc một phần, đổi lại đơn giá thấp hơn nhiều so với on-demand.

Vậy việc cần làm là tách nhóm dịch vụ có thực thể chạy liên tục để cam kết (node, instance, throughput) khỏi nhóm tính tiền hoàn toàn theo lượng dùng thực tế. Cụm "reserved" là dao mổ, không phải "discount".

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

Theo tệp, đáp án đúng là A (Amazon RedShift) và C (Amazon DynamoDB).

Mô hình reservation của AWS áp dụng cho một nhóm dịch vụ có công suất đặt trước được, trong đó có EC2, RDS, ElastiCache, Redshift và DynamoDB.

• Amazon RedShift: là data warehouse chạy trên cluster gồm các node luôn bật. Vì node là thực thể tồn tại liên tục và bạn biết trước mình cần bao nhiêu, Redshift có Reserved Nodes — cam kết kỳ hạn để đổi lấy đơn giá thấp hơn so với on-demand. Đây đúng là dạng "trả trước cho công suất" mà đề nói tới.
• Amazon DynamoDB: ở chế độ provisioned capacity, bạn khai báo trước throughput (đơn vị đọc/ghi). Vì đã là công suất khai báo trước, nó cam kết trước được — DynamoDB có reserved capacity cho phần throughput đó, giảm giá đáng kể so với trả theo giá provisioned thường.

Điểm chung của cả hai: có một đơn vị công suất định lượng được và duy trì liên tục, nên AWS mới có cái để bạn cam kết.

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

• B. Amazon S3 — đây là phương án gần đúng nhất và dễ bị chọn nhầm. S3 có nhiều cách giảm chi phí: đơn giá giảm theo bậc dung lượng, và các storage class rẻ hơn (chuyển dữ liệu ít truy cập sang tầng khác). Nhưng đó không phải reservation: bạn không cam kết trước một lượng dung lượng để hưởng giá, mà trả đúng theo số byte đang lưu và số request thực phát sinh. Không có "reserved storage" để mua. Sai ở chỗ cơ chế, không phải ở chỗ "có giảm giá hay không".
• D. AWS Lambda — Lambda là dịch vụ serverless: bạn không sở hữu instance nào, tính tiền theo số lần gọi hàm và thời gian chạy. Không có công suất thường trực để đặt trước, nên không có Reserved Instance cho Lambda. (Cẩn thận với từ "reserved concurrency" trong Lambda — nghe rất giống nhưng đó là hạn mức đồng thời để phân bổ tài nguyên giữa các hàm, hoàn toàn không liên quan tới giá và không giảm tiền đồng nào. Đây là bẫy chữ nghĩa hay gặp.)
• E. Amazon CloudWatch — là dịch vụ giám sát. Tính tiền theo số metric, số alarm, dashboard và lượng log ingest/lưu trữ — tất cả đều là "dùng bao nhiêu trả bấy nhiêu". Không có khái niệm node hay instance CloudWatch để mua trước, nên không thể reserve.

📌 Điểm cần nhớ

• "Reserved" là một mô hình giá cụ thể, không phải từ đồng nghĩa với "giảm giá". Đề hỏi reserve thì phải loại mọi dịch vụ chỉ có kiểu giảm giá khác (bậc thang, storage class, free tier).
• Mẹo phân loại nhanh: dịch vụ có instance/node/throughput chạy thường trực thì reserve được (EC2, RDS, ElastiCache, Redshift, DynamoDB provisioned). Dịch vụ serverless hoặc thuần pay-per-use thì không (Lambda, S3, CloudWatch).
• Bản chất của reservation: đánh đổi tính linh hoạt lấy giá rẻ — cam kết kỳ hạn và/hoặc trả trước. Trả trước càng nhiều, kỳ hạn càng dài thì mức giảm càng sâu. Chỉ nên dùng cho workload ổn định, đoán được.
• Coi chừng thuật ngữ trùng chữ nhưng khác nghĩa: Lambda "reserved concurrency" là giới hạn kỹ thuật về đồng thời, còn DynamoDB "reserved capacity" mới thực sự là cam kết giá. Cùng chữ "reserved", hai chuyện khác hẳn nhau.

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

Đề mô tả một website phục vụ static content đặt trong Amazon S3 bucket, và người dùng đến from around the world. Câu hỏi: dịch vụ AWS nào giúp phân phối nội dung đó với low latency?

Cụm từ quyết định đáp án nằm ở chỗ giao nhau của ba chi tiết: "static content from an S3 bucket" + "users from around the world" + "low latency". Nội dung là tĩnh nên nó cache được; người dùng ở khắp nơi nên khoảng cách địa lý mới là nguyên nhân gây độ trễ; và yêu cầu là giảm độ trễ chứ không phải chạy code hay dựng môi trường ứng dụng. Ba chi tiết này gộp lại chỉ đúng vào một mô hình duy nhất: CDN có bộ nhớ đệm đặt gần người dùng. Chỉ cần thiếu một trong ba — ví dụ đề nói nội dung động, hoặc nói về ứng dụng chạy trên nhiều Region — thì đáp án đã có thể khác.

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

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

CloudFront là content delivery network (CDN) của AWS. Nó nhận một origin — ở đây chính là S3 bucket cấu hình làm static website — rồi cache nội dung tại các điểm hiện diện phân bố khắp thế giới. Khi một người dùng ở xa Region chứa bucket gửi yêu cầu, họ được phục vụ từ bản sao cache gần mình thay vì phải đi hết quãng đường tới bucket gốc. Đó chính xác là cơ chế làm giảm độ trễ cho global users mà đề hỏi.

Điểm khớp mấu chốt: nội dung tĩnh là loại nội dung cache hiệu quả nhất — cùng một tệp phục vụ cho mọi người, nên lần đầu lấy về origin xong thì các lần sau trong cùng khu vực được phục vụ ngay từ cache. Cặp S3 + CloudFront vì thế là mô hình chuẩn cho website tĩnh toàn cầu, và trong đề thi Cloud Practitioner, "static content" đi cùng "worldwide/low latency" gần như luôn dẫn tới CloudFront.

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

A — AWS Elastic Beanstalk. Đây là dịch vụ dạng platform as a service: bạn đưa mã ứng dụng lên, Beanstalk lo dựng và quản lý nền tảng chạy ứng dụng đó. Nó thuộc nhóm compute/triển khai ứng dụng, không phải nhóm phân phối nội dung, và không có cơ chế cache tại điểm gần người dùng. Nội dung ở đây đã nằm sẵn trên S3 và là tệp tĩnh — chẳng có ứng dụng nào cần triển khai cả.

B — AWS Global Accelerator. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi, vì nó cũng nói về hiệu năng mạng toàn cầu và cũng dùng mạng lưới toàn cầu của AWS. Chỗ nó hỏng: Global Accelerator định tuyến traffic tới các application endpoint, đưa lưu lượng vào mạng AWS sớm để đường đi ổn định hơn — nhưng nó không cache nội dung. Không có cache nghĩa là mọi yêu cầu vẫn phải đi tới tận nơi lưu nội dung. Ngoài ra nó được thiết kế để đứng trước các endpoint ứng dụng, không phải đứng trước một S3 bucket phục vụ tệp tĩnh. Đề nhấn "static content" chính là để loại phương án này.

D — AWS Lambda. Lambda là dịch vụ compute serverless: chạy đoạn mã khi có sự kiện kích hoạt. Nó giải quyết bài toán "chạy logic mà không quản lý máy chủ", hoàn toàn không liên quan tới việc đưa tệp tĩnh đến gần người dùng ở xa. Dùng Lambda ở đây thì cũng không có gì để cache và không có gì để chạy.

📌 Điểm cần nhớ

• "Static content" + "users around the world" + "low latency" → CloudFront. Bộ ba từ khoá này là chữ ký nhận dạng của một câu hỏi về CDN.
• CloudFront cache, Global Accelerator thì không. Đây là ranh giới phân biệt hai dịch vụ hay bị nhầm: một bên lưu bản sao nội dung gần người dùng, một bên tối ưu đường đi của traffic tới endpoint ứng dụng.
• S3 làm origin cho CloudFront là mô hình chuẩn của website tĩnh toàn cầu — thấy S3 phục vụ tệp cho người dùng nhiều nơi thì nghĩ ngay tới cặp này.
• Đừng để dịch vụ compute lọt vào câu hỏi về phân phối nội dung. Elastic Beanstalk và Lambda đều thuộc nhóm chạy ứng dụng/mã, nên khi đề chỉ nói tới việc giao tệp đã có sẵn, chúng bị loại ngay từ vòng phân loại dịch vụ.

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

Đề mô tả một công ty có nhiều business unit khác nhau, mỗi đơn vị dùng cùng những dịch vụ AWS nhưng cho các ứng dụng riêng. Câu hỏi: dịch vụ hoặc công cụ nào giúp công ty nhận volume discount trên nhiều AWS account?

Cụm từ quyết định là "receive volume discounts across multiple AWS accounts" — hai vế phải cùng thoả:

• volume discount: giá của nhiều dịch vụ AWS (như S3, dữ liệu truyền ra ngoài) tính theo bậc (tiered pricing) — càng dùng nhiều thì đơn giá bậc sau càng rẻ. Muốn hưởng bậc rẻ hơn, mức sử dụng phải được cộng gộp lại thay vì đo lẻ từng account.
• across multiple AWS accounts: việc gộp phải xảy ra ở tầng nhiều account, không phải trong một account.

Đây là ràng buộc phân biệt: ba phương án còn lại đều là công cụ quan sát hoặc kiểm soát chi phí — chúng cho bạn nhìn thấy và cảnh báo về hoá đơn, chứ không thay đổi cách AWS tính giá. Chỉ một phương án tác động lên chính cơ chế thanh toán.

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

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

AWS Organizations có tính năng consolidated billing: gom nhiều AWS account vào một tổ chức, trong đó management account đứng ra trả toàn bộ chi phí của các member account. Hệ quả quan trọng về giá: mức sử dụng của tất cả các account trong tổ chức được cộng dồn khi tính hoá đơn, nên với những dịch vụ có mô hình giá theo bậc, cả tổ chức sẽ chạm tới bậc giá rẻ hơn sớm hơn so với khi từng account tính riêng lẻ.

Đúng với tình huống trong đề: các business unit dùng cùng những dịch vụ AWS ở các account khác nhau — gộp lại thì tổng mức sử dụng của mỗi dịch vụ đủ lớn để hưởng bậc giá tốt hơn, trong khi từng đơn vị vẫn giữ account riêng để cách ly ứng dụng và quyền hạn.

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

A — AWS Cost and Usage Report (AWS CUR). Đây là bộ dữ liệu chi phí và mức sử dụng chi tiết nhất mà AWS cung cấp, xuất ra dạng file để phân tích sâu, phân bổ chi phí (cost allocation) theo tag hay theo account. Nó gần đúng ở chỗ có thể bao trùm nhiều account trong một organization — nhưng nó chỉ báo cáo con số. CUR không tạo ra khoản giảm giá nào; nếu chưa có consolidated billing thì mức sử dụng vẫn không được gộp, và CUR sẽ chỉ trung thực ghi lại hoá đơn đắt hơn đó.

C — Cost Explorer. Công cụ trực quan hoá chi phí theo thời gian: xem xu hướng, lọc theo dịch vụ/account/tag, dự báo chi tiêu, và xem khuyến nghị mua Reserved Instances / Savings Plans. Đây là phương án gây nhầm nhất vì nó có liên quan tới tiết kiệm — nhưng chỉ ở mức gợi ý cho bạn hành động, còn bản thân nó không áp mức giảm giá nào. Phần khuyến nghị đó cũng là chuyện cam kết chi tiêu (commitment), khác hẳn với volume discount theo bậc sử dụng mà đề đang hỏi.

D — AWS Budgets. Cho phép đặt ngưỡng ngân sách theo chi phí, mức sử dụng, hoặc mức phủ của Reserved Instances / Savings Plans, và gửi cảnh báo khi vượt ngưỡng hoặc khi dự báo sẽ vượt. Đây là công cụ kiểm soát và cảnh báo, nó nói cho bạn biết mình sắp tiêu quá tay — nhưng không hề làm hoá đơn rẻ đi, và hoàn toàn không đụng đến chuyện gộp mức sử dụng giữa các account.

📌 Điểm cần nhớ

• Phân biệt dứt khoát ba nhóm công cụ chi phí của AWS: xem lại (Cost Explorer, Cost and Usage Report), cảnh báo/kiểm soát (AWS Budgets), và thay đổi cách tính tiền (AWS Organizations với consolidated billing). Đề hỏi "discount / giảm giá / gộp hoá đơn" thì chỉ nhóm thứ ba trả lời được.
• Từ khoá "multiple AWS accounts" + "billing/discount" gần như luôn dẫn tới AWS Organizations – consolidated billing: một management account trả tiền, mức sử dụng của các member account được cộng dồn để hưởng bậc giá tốt hơn.
• Volume discount ở đây đến từ tiered pricing — dùng nhiều thì đơn giá bậc sau rẻ hơn. Nó khác với việc giảm giá do cam kết trước (Reserved Instances, Savings Plans); đừng nhầm hai cơ chế khi đề mô tả "nhiều đơn vị dùng chung dịch vụ".
• Một công cụ báo cáo dù chi tiết tới đâu (CUR) hay trực quan tới đâu (Cost Explorer) cũng chỉ phản ánh hoá đơn. Khi câu hỏi dùng động từ chủ động như receive, apply, consolidate, hãy loại ngay các phương án chỉ mang tính quan sát.

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

Đề bài hỏi: dịch vụ nào giúp tạo nhiều AWS account một cách dễ dàng ("easily create multiple accounts").

Có hai cụm từ quyết định đáp án, và phải đọc cả hai cùng lúc:

• "accounts" — ở đây là AWS account (tài khoản cấp cao nhất, có ranh giới thanh toán và ranh giới cô lập tài nguyên riêng), không phải IAM user hay IAM role bên trong một account. Đây là bẫy kinh điển của câu này: người học quen nghĩ "tạo tài khoản → IAM".
• "easily" — đề không hỏi "có cách nào làm được không", mà hỏi cách dễ nhất. Ràng buộc này dùng để loại phương án tuy về lý thuyết có thể lách ra kết quả tương tự nhưng phải chắp vá thêm nhiều thứ.

Nắm được hai cụm đó thì câu trả lời gần như hiện ra ngay: dịch vụ nào quản lý nhiều AWS account như một tập hợp, và có sẵn API tạo account.

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

A. AWS Organizations là dịch vụ sinh ra đúng để quản lý nhiều AWS account dưới một tổ chức chung: gom account vào organization, sắp xếp theo OU, áp chính sách chung, gộp hoá đơn.

Quan trọng cho câu hỏi này: Organizations có API tạo account thành viên — bạn gọi API/CLI của Organizations là nó dựng ra một AWS account mới và đưa thẳng vào organization hiện có. Nhờ vậy việc tạo hàng loạt account trở thành thao tác tự động hoá được, không phải ngồi điền form đăng ký từng account một với từng thẻ thanh toán riêng.

Đó chính là nghĩa của chữ "easily" trong đề: một dịch vụ có sẵn chức năng tạo account, không cần ghép nối thêm gì.

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

B. AWS IAM — sai vì nhầm cấp độ. IAM làm việc bên trong một AWS account đã tồn tại: tạo IAM user, group, role, gắn policy phân quyền. IAM không tạo được AWS account mới. Nếu đề hỏi "tạo nhiều người dùng cho nhóm dev" thì IAM đúng; nhưng đề nói accounts theo nghĩa AWS account, nên IAM nằm sai tầng. Đây là phương án gây nhầm nhiều nhất, hãy nhớ ranh giới: Organizations quản account, IAM quản identity trong account.

C. AWS CloudFormation — đây là phương án gần đúng nhất, và cần nói rõ nó hỏng ở đâu. CloudFormation là dịch vụ Infrastructure as Code: khai báo hạ tầng bằng template rồi triển khai thành stack. Về mặt lý thuyết bạn có thể dùng CloudFormation kết hợp thêm script/tự động hoá để dựng account, nhưng bản thân CloudFormation không phải công cụ tạo account — nó là công cụ dựng tài nguyên. Cách làm đó phải ghép nối thêm, tức là vi phạm chính chữ "easily" trong đề. Khi hai phương án cùng "làm được", đề luôn chọn cái làm được trực tiếp.

D. Amazon Connect — hoàn toàn khác lĩnh vực. Đây là contact center dạng cloud, self-service: dựng tổng đài chăm sóc khách hàng, định tuyến cuộc gọi, kịch bản trả lời. Chữ "Connect" dễ khiến người đọc lướt tưởng là "kết nối/liên kết account", nhưng dịch vụ này không dính gì tới quản lý AWS account. Loại ngay.

📌 Điểm cần nhớ

• Khi đề nói "account" trong ngữ cảnh AWS, hãy dừng lại phân biệt: AWS account (Organizations) hay IAM user/role (IAM). Chọn sai tầng là mất điểm dù hiểu bài.
• AWS Organizations = quản lý nhiều AWS account: tạo account thành viên qua API, gom theo OU, áp chính sách chung, gộp thanh toán.
• AWS IAM = phân quyền bên trong một account, không tạo được account mới.
• Các từ như "easily", "least effort", "fully managed" trong đề là ràng buộc thật chứ không phải văn phong — chúng dùng để loại những phương án chỉ làm được khi ghép thêm script, như CloudFormation ở câu này.

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

Đề mô tả một tổ chức vừa chuyển workload sang chạy trên các Amazon EC2 instance, rồi hỏi công ty nên làm gì để đáp ứng yêu cầu đặt ra.

Cụm từ quyết định đáp án là "Cost-effectiveness is the key" — yêu cầu duy nhất được nêu là tối ưu chi phí, và phạm vi được giới hạn rõ ở EC2 instances. Đây chính là ràng buộc phân biệt: cả bốn phương án đều là những việc hợp lý khi vận hành trên AWS, nhưng chỉ có một phương án tác động trực tiếp lên hoá đơn EC2. Các phương án còn lại giải quyết chuyện mã hoá, tự động hoá triển khai, hay gộp hoá đơn — đều tốt, nhưng không phải là thứ đề đang hỏi.

Khi gặp dạng câu này, hãy tự hỏi: "Phương án này có làm giảm số tiền phải trả cho chính tài nguyên đang chạy hay không?" Nếu câu trả lời là "không, nó chỉ đổi cách quản lý", thì đó không phải đáp án.

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

C. Rightsize all the EC2 instances that are used in the deployment

Rightsizing nghĩa là bảo đảm instance type đang dùng vừa khít với nhu cầu thật của workload — không quá lớn mà cũng không quá nhỏ. Điểm mấu chốt về chi phí nằm ở cách EC2 tính tiền: bạn bị tính tiền theo instance type đã cấp phát, chứ không phải theo lượng vCPU hay RAM thực sự dùng đến. Chạy một m5.4xlarge trong khi workload chỉ cần m5.2xlarge nghĩa là bạn trả tiền cho phần công suất không bao giờ chạm tới.

Đây là lý do rightsizing là một trong những đòn bẩy tối ưu chi phí mạnh nhất trên EC2, đặc biệt ngay sau khi migrate — lúc đó instance thường được chọn theo cấu hình máy chủ vật lý cũ, vốn đã được mua dư công suất cho nhiều năm tới.

AWS Compute Optimizer là công cụ hỗ trợ việc này: nó dùng machine learning phân tích số liệu sử dụng để chỉ ra tài nguyên nào đang bị overutilization hoặc underutilization, từ đó cho bạn dữ liệu cần thiết để rightsize thay vì đoán mò.

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

A. Use AWS Key Management Service (AWS KMS)

AWS KMS là dịch vụ quản lý khoá mã hoá, dùng để mã hoá dữ liệu trên khắp hạ tầng. Đây thuần tuý là chuyện bảo mật, không liên quan gì tới tối ưu chi phí. Bật mã hoá không làm hoá đơn EC2 nhỏ đi.

B. Use AWS CloudFormation to deploy the infrastructure

CloudFormation là công cụ infrastructure as code, cho phép khai báo hạ tầng bằng JSON hoặc YAML. Nó cải thiện tính lặp lại, tính nhất quán và tốc độ triển khai — những giá trị thật, nhưng không làm hạ tầng rẻ đi. Template CloudFormation vẫn tạo ra đúng những instance mà bạn khai trong đó; nếu bạn khai một instance quá khổ, CloudFormation sẽ dựng đúng cái quá khổ ấy, chỉ nhanh hơn thôi.

D. Use multiple AWS accounts and consolidated billing

Đây là phương án gần đúng nhất và dễ đánh lừa nhất, nên cần nói rõ nó hỏng ở đâu. Consolidated billing gom hoá đơn của mọi account trong một AWS Organization về một chỗ, giúp việc theo dõi và phân bổ chi phí dễ hơn nhiều. Nhưng bản thân việc gộp hoá đơn không tự nó tạo ra khoản tiết kiệm nào — nó thay đổi cách bạn nhìn chi phí, không thay đổi lượng tài nguyên bạn đang trả tiền. Một fleet EC2 bị cấp phát dư vẫn dư y nguyên sau khi gộp hoá đơn, chỉ là giờ bạn thấy nó trên một hoá đơn thay vì nhiều hoá đơn.

📌 Điểm cần nhớ

• EC2 tính tiền theo instance type đã cấp phát, không theo mức sử dụng thực tế. Đây là nguyên lý gốc khiến rightsizing trở thành đòn bẩy chi phí trực tiếp — mọi vCPU dư đều là tiền đã trả mà không dùng.
• Phân biệt "làm giảm chi phí" với "làm dễ quản lý chi phí": consolidated billing thuộc nhóm thứ hai, rightsizing thuộc nhóm thứ nhất. Đề hỏi cost-effectiveness thì phải chọn nhóm thứ nhất.
• AWS Compute Optimizer là công cụ đi kèm với rightsizing: nó phát hiện tài nguyên overutilized/underutilized để bạn có số liệu mà quyết định, thay vì đổi instance type theo cảm tính.
• Đọc kỹ yêu cầu duy nhất mà đề nêu ra. KMS (bảo mật) và CloudFormation (tự động hoá) đều là câu trả lời đúng cho những câu hỏi khác; trong câu này chúng chỉ là mồi nhử lệch chủ đề.

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

Đề mô tả một ứng dụng Linux mission critical, chạy mỗi thứ Hai từ 6 giờ sáng tới 10 giờ tối, và không được phép bị gián đoạn. Câu hỏi yêu cầu chọn EC2 instance purchasing option đáp ứng yêu cầu đó MOST cost-effectively.

Có ba cụm từ quyết định, phải đọc cùng nhau:

• "cannot be interrupted" — loại thẳng mọi hình thức mua có thể bị AWS thu hồi máy.
• "every Monday from 6 AM until 10 PM" — lịch chạy biết trước, lặp lại, nhưng không phải 24/7. Đây là điểm khiến các lựa chọn cam kết dài hạn kiểu "chạy suốt" không còn hiển nhiên là rẻ nhất.
• "MOST cost-effectively" — không hỏi "an toàn nhất", nên đáp án phải vừa bảo đảm chạy được vừa có cơ chế giảm giá so với giá On-Demand nguyên bản.

Nói cách khác: cần bảo đảm có máy đúng lúc cần cộng với một cơ chế giảm giá.

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

Đáp án đúng là D — On-Demand Capacity Reservation with Savings Plan, và nó ghép đúng hai vế của đề:

• On-Demand Capacity Reservation giữ chỗ năng lực tính toán trong một Availability Zone cụ thể. Khi tới 6 giờ sáng thứ Hai, capacity đã được đặt trước nên việc khởi chạy instance không phụ thuộc vào lượng máy còn trống của AZ tại thời điểm đó. Đây chính là phần đáp ứng "mission critical, cannot be interrupted": máy chạy theo mô hình On-Demand nên AWS không thu hồi, và capacity thì đã được dành sẵn.
• Savings Plan là phần lo chuyện giá: nó áp mức giảm giá dựa trên cam kết chi tiêu theo giờ, giúp workload này rẻ hơn giá On-Demand thuần mà không đánh đổi tính sẵn sàng.

Đúng như phần giải thích gốc nêu: lịch chạy ở đây là dự đoán được, nên việc đặt trước capacity là hợp lý, và Savings Plan giữ cho phương án vừa chắc chắn vừa tiết kiệm — thứ mà Spot Instances không thể cho.

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

A — Dedicated Hosts. Đây là một máy chủ vật lý dành riêng cho bạn, sinh ra để phục vụ các yêu cầu tuân thủ của doanh nghiệp và các bài toán license gắn với phần cứng. Nó không phải cơ chế tối ưu chi phí, và vì là một server đơn lẻ nên bản thân nó không mang lại độ bền/khả năng chịu lỗi mặc định cho workload mission critical. Với một ứng dụng chỉ chạy 16 tiếng mỗi tuần, đây là phương án đắt nhất và lệch mục đích — đề không hề nhắc tới yêu cầu tuân thủ hay license nào.

B — Regional Reserved Instances. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. Reserved Instances có cho giảm giá so với On-Demand, nên thoạt nhìn hợp với chữ "cost-effective". Chỗ nó hỏng nằm ở phạm vi Regional: RI dạng regional cho capacity reservation trong một AZ cụ thể — nó chỉ áp dụng phần giảm giá trên hoá đơn kèm tính linh hoạt giữa các AZ trong Region. Với ứng dụng mission critical cần chắc chắn có máy đúng thời điểm khởi chạy, thiếu bảo đảm capacity là điểm chết. Muốn có bảo đảm đó thì phải dùng đúng thứ mà đáp án D nêu tên: On-Demand Capacity Reservation.

C — Spot Instances. Đây là lựa chọn rẻ nhất trong danh sách, nên nếu chỉ đọc mỗi chữ "MOST cost-effectively" thì rất dễ chọn nhầm. Nhưng Spot capacity có thể bị AWS thu hồi với thông báo hai phút khi cần dùng lại. Điều đó mâu thuẫn trực tiếp với "mission critical" và "cannot be interrupted" trong đề. Spot hợp với các workload chịu được gián đoạn và chạy lại được — batch, xử lý hàng đợi, render — chứ không hợp ở đây.

📌 Điểm cần nhớ

• Khi đề nói "cannot be interrupted" hay "mission critical", gạch Spot Instances ra trước tiên, dù nó luôn là dòng rẻ nhất trên bảng giá. "Rẻ nhất" và "đáp ứng yêu cầu" là hai câu hỏi khác nhau.
• Phân biệt rõ hai thứ hay bị gộp: giảm giá trên hoá đơn (Savings Plans, Reserved Instances) và bảo đảm có capacity (On-Demand Capacity Reservation). Một câu hỏi vừa đòi "guaranteed availability" vừa đòi "cost-effective" thường có đáp án là ghép cả hai.
• Regional Reserved Instances thiên về linh hoạt giữa các AZ trong Region; nếu đề nhấn mạnh phải chắc chắn khởi chạy được ở một AZ vào đúng thời điểm, đó là dấu hiệu cần Capacity Reservation.
• Dedicated Hosts là câu trả lời cho tuân thủ / license gắn phần cứng, không phải cho tối ưu chi phí. Đề không nhắc tới hai từ khoá đó thì gần như chắc chắn không phải đáp án.

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

Đề mô tả một công ty có 50 business unit và yêu cầu xem riêng thông tin chi phí (billing) của từng business unit.

Cụm từ quyết định đáp án là "viewed separately" — đề chỉ đòi nhìn tách bạch được chi phí, chứ không đòi tách bạch về hạ tầng, về quyền truy cập, hay về vị trí địa lý. Đây là yêu cầu thuộc về khâu báo cáo chi phí, không phải khâu thiết kế kiến trúc.

Con số 50 cũng là một gợi ý: giải pháp phải nhân rộng được cho hàng chục đơn vị mà không kéo theo chi phí vận hành khổng lồ. Cứ mỗi phương án, hãy tự hỏi: "cách này có thực sự nhằm mục đích phân tách chi phí không, hay nó là một cơ chế dành cho mục đích khác mà tình cờ cũng chia được chi phí?"

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

C — Gắn tag cho tài nguyên của từng business unit, rồi lọc theo unit trong Cost Explorer.

Tag là metadata dạng cặp khoá–giá trị (ví dụ BusinessUnit = Marketing) gắn lên tài nguyên AWS. Cơ chế này sinh ra chính là để gán nhãn tài nguyên theo ứng dụng, phòng ban, môi trường hay trung tâm chi phí.

Khi tag đã được kích hoạt làm cost allocation tag trong Billing, Cost Explorer cho phép nhóm và lọc chi phí theo giá trị tag đó. Kết quả là mỗi business unit nhìn thấy đúng phần chi phí của mình, dù các tài nguyên nằm chung một account, chung một VPC hay chung một Region.

Đây là cách trực tiếp và ít tốn công nhất trong danh sách: chỉ thêm metadata lên tài nguyên rồi dùng công cụ phân tích chi phí có sẵn, không phải dựng lại hạ tầng theo ranh giới phòng ban.

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

A — Tách account riêng cho từng business unit, rồi lọc theo unit bằng coverage report.

Vế đầu nghe hợp lý (nhiều account đúng là một ranh giới chi phí rõ ràng), nhưng vế sau làm hỏng cả phương án: coverage report là báo cáo thuộc về Savings Plans. Nó cho biết bao nhiêu phần khối lượng sử dụng của bạn đang được Savings Plans bao phủ — tức là công cụ theo dõi hiệu quả của cam kết chi tiêu, không phải công cụ chia chi phí theo phòng ban. Chọn đúng cấu trúc nhưng chọn sai báo cáo thì vẫn không xem được thứ đề yêu cầu.

B — Mỗi business unit một VPC, rồi lọc theo unit bằng AWS Cost and Usage Report.

VPC là ranh giới mạng, sinh ra để cô lập lưu lượng và địa chỉ IP, không phải để phân loại chi phí. Rất nhiều khoản chi tiêu còn không nằm bên trong VPC nào cả (ví dụ các dịch vụ dùng ở mức account), nên lấy VPC làm trục chia tiền là chia không trọn. Dựng 50 VPC chỉ để đọc được hoá đơn là làm phức tạp kiến trúc cho một bài toán báo cáo — trong khi tag giải quyết đúng việc đó nhẹ nhàng hơn nhiều.

D — Đặt mỗi business unit ở một AWS Region khác nhau, rồi lọc theo unit trong Cost Explorer.

Về mặt kỹ thuật thì Cost Explorer có lọc được theo Region, nên phương án này "chạy được" — nhưng nó sai vì không cần thiết và gây hại. Region là các vùng địa lý của hạ tầng toàn cầu AWS, được chọn dựa trên độ trễ tới người dùng, yêu cầu tuân thủ dữ liệu và mức độ sẵn sàng của dịch vụ, không phải để cô lập ứng dụng theo phòng ban. Ngoài ra, số Region là hữu hạn nên cách này không nhân rộng nổi tới 50 đơn vị, và nó ép các business unit rời xa vị trí tối ưu của họ chỉ vì lý do kế toán.

📌 Điểm cần nhớ

• Tag + Cost Explorer là câu trả lời mặc định cho mọi yêu cầu kiểu "chia nhỏ / xem riêng chi phí theo phòng ban, dự án, môi trường, trung tâm chi phí". Nhớ rằng tag phải được kích hoạt làm cost allocation tag thì mới xuất hiện trong báo cáo chi phí.
• Phân biệt ranh giới theo mục đích: VPC = ranh giới mạng; Region = vị trí địa lý; account = ranh giới quản trị và bảo mật; tag = nhãn để phân loại và báo cáo. Đề hỏi về xem chi phí thì đừng chọn ranh giới hạ tầng.
• Đọc kỹ cả vế sau của phương án. Phương án A đúng nửa đầu nhưng gắn sai công cụ — coverage report thuộc về Savings Plans, không phải báo cáo phân bổ chi phí theo đơn vị.
• "Làm được" không đồng nghĩa với "nên làm". Phương án D vẫn cho ra số liệu, nhưng bắt kiến trúc phục vụ nhu cầu báo cáo là đánh đổi sai. Trong đề thi, khi hai phương án cùng ra kết quả, hãy chọn cái ít xáo trộn hệ thống nhất.