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

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

Đề hỏi: những tác vụ nào bắt buộc phải dùng AWS account root user (chọn HAI).

Cụm từ quyết định là "require the use of" — bắt buộc, chứ không phải có thể làm được. Đây là điểm bẫy chính: root user là chủ tài khoản, nó làm được mọi thứ trong tài khoản, nên nếu đọc thành "root làm được việc gì" thì cả năm phương án đều đúng và câu hỏi trở nên vô nghĩa. Ràng buộc thật nằm ở chỗ: tác vụ đó có nằm trong nhóm việc mà IAM user/role không thể được cấp quyền để làm thay, dù có gắn policy rộng đến đâu.

Từ khoá thứ hai là "(Select TWO)" — phải tìm đúng hai việc thuộc nhóm "chỉ root", chứ không phải hai việc "nhạy cảm" hay "cần quyền cao". Nhóm việc chỉ-root trong AWS xoay quanh cấu hình cấp tài khoản (account-level settings) và quan hệ với AWS với tư cách khách hàng: thông tin định danh tài khoản, thanh toán/hợp đồng hỗ trợ, đóng tài khoản. Còn các việc thao tác trên tài nguyên (S3, CloudTrail, EC2...) thì đều điều khiển được bằng IAM.

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

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

A — Changing AWS Support plans. Đổi gói AWS Support (Basic / Developer / Business / Enterprise) là thay đổi quan hệ hợp đồng và thanh toán giữa tài khoản với AWS, không phải thao tác trên tài nguyên trong tài khoản. Nó thuộc nhóm tác vụ cấp tài khoản mà AWS dành riêng cho root user, đúng như tài liệu "AWS Tasks that Require Root User Credentials" nêu.

C — Changing the account name. Tên tài khoản là thuộc tính định danh của chính tài khoản AWS, nằm trong trang Account Settings chứ không phải trong bất kỳ service nào. Cùng nhóm với email liên hệ và mật khẩu của root, đây là thứ chỉ root user được sửa — logic ở đây rất dễ nhớ: IAM quản trị người dùng và tài nguyên bên trong tài khoản, nó không quản trị bản thân tài khoản.

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

B — Viewing AWS CloudTrail logs. Sai. CloudTrail là một service bình thường, việc xem log được điều khiển bằng IAM policy (cloudtrail:LookupEvents, quyền đọc S3 bucket chứa trail...). Đây là phương án "nghe có vẻ nhạy cảm nên chắc cần root", nhưng tính nhạy cảm về bảo mật không đồng nghĩa với yêu cầu root — trên thực tế AWS khuyến nghị ngược lại: cấp quyền đọc log cho một IAM role kiểm toán riêng, chứ không ai đăng nhập root để đọc log hằng ngày.

D — Enabling encryption for S3. Sai. Bật mã hoá cho bucket S3 là cấu hình trên tài nguyên, làm được bằng IAM user/role có quyền tương ứng trên bucket đó. Phương án này bẫy theo cùng kiểu B: mã hoá thuộc phạm trù bảo mật, nhưng nó vẫn chỉ là một API call của S3.

E — Changing payment currency. Đây là phương án gần đúng nhất và khó loại nhất, vì nó thuộc khu vực Billing — đúng vùng mà nhiều tác vụ chỉ-root cư trú (như đổi gói Support ở A). Điểm hỏng của nó: các thiết lập thanh toán thông thường trong Billing and Cost Management có thể uỷ quyền cho IAM — root chỉ cần bật quyền truy cập Billing cho IAM user một lần, sau đó IAM user có policy phù hợp thao tác được. Nói cách khác, đây là việc root có thể làm và thường do root bật khoá đầu tiên, nhưng không phải việc chỉ mình root làm được — nên nó trượt ràng buộc "require".

📌 Điểm cần nhớ

• Đọc kỹ động từ trong đề: "require root" khác hẳn "root can do". Root làm được mọi thứ, nên câu hỏi luôn nhắm vào tập nhỏ chỉ root mới làm được.
• Ranh giới dễ nhớ: việc động tới chính tài khoản (tên tài khoản, email/mật khẩu root, gói Support, đóng tài khoản) → root; việc động tới tài nguyên bên trong (S3, CloudTrail, EC2...) → IAM lo được.
• Nhạy cảm về bảo mật ≠ cần root. CloudTrail và mã hoá S3 là hai mồi nhử kinh điển theo hướng này.
• Các mục Billing như đổi loại tiền thanh toán nằm ở vùng xám: root bật quyền Billing cho IAM một lần, sau đó IAM thao tác được — nên đừng mặc định cứ "billing là root".

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

Đề hỏi: một Cloud Practitioner dùng cái gì để phân loại (categorize) và theo dõi (track) chi phí AWS theo project?

Cụm từ quyết định đáp án là "by project" — theo dự án, chứ không phải theo tài khoản, theo dịch vụ hay theo region. Đây chính là ràng buộc phân biệt bốn phương án: cả bốn thứ được nêu đều ít nhiều liên quan tới chi phí hoặc tổ chức tài nguyên, nhưng chỉ một thứ cho phép bạn tự định nghĩa chiều phân loại của riêng mình. "Project" không phải là một khái niệm có sẵn trong AWS — AWS không biết resource nào thuộc dự án nào trừ khi bạn tự gắn nhãn cho nó. Cụm từ thứ hai đáng chú ý là "categorize and track": đề đòi cả hai vế — vừa gán nhãn phân loại, vừa xem được chi phí theo nhãn đó.

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

Đáp án đúng theo tệp là A — Cost Allocation Tags.

Tag là cặp key–value bạn gắn lên tài nguyên AWS (ví dụ Project = website-v2, Department = marketing). Khi bạn kích hoạt một tag làm cost allocation tag trong phần Billing, AWS bắt đầu dùng tag đó làm một chiều phân tách chi phí: bạn xem được trong Cost Explorer và trong cost allocation report, lọc và nhóm chi phí theo đúng giá trị tag đó.

Đây chính là cơ chế duy nhất trong bốn phương án cho phép ánh xạ một khái niệm nghiệp vụ do bạn tự đặt ra ("project") vào dữ liệu chi phí. Vì tag do bạn định nghĩa, cùng một cơ chế dùng được cho phòng ban, môi trường (dev/prod), khách hàng, hay bất cứ chiều nào bạn cần — khớp trọn vẹn cả hai vế "categorize" và "track" của đề.

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

B — AWS Trusted Advisor. Đây là dịch vụ khuyến nghị best practice khi bạn cấp phát tài nguyên: nó soi hạ tầng rồi gợi ý về tối ưu chi phí, hiệu năng, bảo mật, khả năng chịu lỗi và giới hạn dịch vụ. Chỗ khiến nhiều người phân vân là Trusted Advisor có nhóm kiểm tra về cost optimization — nhưng nó chỉ nói "chỗ này đang lãng phí, nên sửa", chứ không phân loại chi phí theo chiều do bạn định nghĩa. Nó không biết "project" của bạn là gì và không xuất được báo cáo chi phí theo project.

C — Consolidated billing. Gần đúng nhất trong ba phương án sai, vì nó thật sự là công cụ về chi phí và thật sự có tính chất "gom nhóm": nó gộp hoá đơn của nhiều tài khoản trong một tổ chức về một chỗ trả tiền, và cho bạn thấy mức dùng theo từng account. Nhưng chiều phân tách của nó là account, không phải project. Nếu một account chứa nhiều project, hoặc một project trải trên nhiều account, con số nó đưa ra không trả lời được câu hỏi của đề. Nó hỏng ở chỗ: đơn vị phân loại là cố định (account), không phải do bạn đặt.

D — Multiple accounts. Đây là cách lách để đạt mục tiêu: tách mỗi project ra một account riêng thì hoá đơn từng account chính là chi phí từng project. Nhưng nó hỏng ở hai điểm. Thứ nhất, đề hỏi dùng cái gì để phân loại và theo dõi chi phí, còn "nhiều tài khoản" là một quyết định về cấu trúc tổ chức, không phải một công cụ theo dõi chi phí. Thứ hai, bạn không cần phải chia nhỏ mức sử dụng ra nhiều account chỉ để tách chi phí theo project — cost allocation tags làm được việc đó ngay trong một account. Chọn D là trả giá bằng gánh nặng vận hành lớn để giải một bài toán đã có sẵn công cụ nhẹ hơn nhiều.

📌 Điểm cần nhớ

• Hễ đề nói phân bổ hoặc theo dõi chi phí theo một chiều do người dùng tự định nghĩa (project, team, department, môi trường, khách hàng) → nghĩ ngay tới cost allocation tags. AWS không tự biết những khái niệm này.
• Phân biệt chiều phân tách: tag cho chiều tự đặt, consolidated billing cho chiều account. Đề nhắc "by account" hay "per account" thì mới tới lượt consolidated billing.
• Trusted Advisor thuộc nhóm khuyến nghị / best practice, không thuộc nhóm báo cáo chi phí theo nhãn. Có đụng tới cost optimization nhưng không phân loại chi phí.
• Tag phải được kích hoạt trong phần Billing thì mới xuất hiện như một chiều lọc trong Cost Explorer và cost allocation report — gắn tag lên resource thôi là chưa đủ.

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

Đề hỏi: dịch vụ AWS nào đưa ra khuyến nghị (recommendations) về cách tối ưu hiệu năng cho các dịch vụ AWS.

Cụm từ quyết định đáp án là "provides recommendations" — chứ không phải "monitors", không phải "records" hay "detects". Đây là chỗ dễ trượt nhất của câu này: cả bốn phương án đều ít nhiều liên quan tới việc "biết chuyện gì đang xảy ra trong tài khoản", nhưng chỉ một trong số đó chủ động nói cho bạn nên sửa gì. Ba dịch vụ còn lại đưa cho bạn dữ liệu (số đo, nhật ký, phát hiện lỗ hổng) và để bạn tự kết luận.

Cụm thứ hai đáng chú ý là "optimize performance" — hiệu năng, không phải bảo mật, không phải kiểm toán. Cụm này dùng để loại tiếp trong nhóm còn lại.

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

A. AWS Trusted Advisor.

Trusted Advisor quét cấu hình tài khoản của bạn rồi trả về một danh sách khuyến nghị, chia theo nhiều nhóm — trong đó có hẳn một nhóm Performance. Những gì nó kiểm ở nhóm này đúng khớp với từ khoá của đề:

• Service limits / quotas: cảnh báo khi bạn đang tiến sát hạn mức của một dịch vụ, vì chạm trần hạn mức là một nguyên nhân làm hệ thống nghẽn.
• Provisioned throughput: nhắc bạn đang không tận dụng hết throughput đã trả tiền để cấp phát.
• Over-utilized instances: chỉ ra instance đang bị dùng quá tải, tức là ứng cử viên cần nâng cấp hoặc mở rộng.

Điểm mấu chốt: đầu ra của Trusted Advisor là lời khuyên kèm hành động nên làm, đúng nghĩa "recommendations" mà đề hỏi. Đây là dịch vụ duy nhất trong bốn phương án có tính chất tư vấn như vậy.

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

B. Amazon CloudWatch — phương án gần đúng nhất, và cũng là cái bẫy chính.

CloudWatch đúng là dịch vụ về performance: nó thu thập metric (CPU, network, latency…), lưu log, vẽ dashboard, bắn alarm khi vượt ngưỡng. Vậy nên nếu chỉ đọc lướt hai chữ "performance" thì rất dễ chọn B.

Chỗ nó hỏng nằm đúng ở từ khoá còn lại: CloudWatch giám sát hiệu năng nhưng không đưa ra khuyến nghị tối ưu. Nó nói với bạn "CPU đang 95%", chứ không nói "bạn nên đổi sang loại instance khác" hay "bạn sắp chạm hạn mức dịch vụ". Ngưỡng cảnh báo cũng do chính bạn định nghĩa — tức là bản thân bạn phải biết trước đâu là bất thường. Trusted Advisor thì ngược lại: bộ luật đánh giá nằm sẵn ở phía AWS.

C. AWS CloudTrail.

Đây là dịch vụ kiểm toán (auditing). Nó ghi lại các lời gọi API trong tài khoản: ai gọi, gọi cái gì, lúc nào, từ đâu. Công dụng là điều tra sự cố, truy vết thay đổi và đáp ứng yêu cầu tuân thủ. CloudTrail hoàn toàn không đụng tới chuyện hiệu năng, và cũng không sinh ra khuyến nghị nào — nó chỉ là cuốn nhật ký. Sai cả hai từ khoá của đề.

D. Amazon Inspector.

Inspector là dịch vụ đánh giá bảo mật tự động, giúp cải thiện tính bảo mật và tuân thủ của ứng dụng chạy trên AWS. Nó có sinh ra kết quả dạng "phát hiện" (findings) nên thoạt nhìn cũng giống "đưa ra khuyến nghị" — nhưng nội dung khuyến nghị là về lỗ hổng và rủi ro bảo mật, không phải về tối ưu hiệu năng. Đề hỏi performance, nên D lệch chủ đề.

📌 Điểm cần nhớ

• Gặp từ khoá "recommendations" / "best practices" / "optimize" trong đề AWS Cloud Practitioner, phản xạ đầu tiên nên là Trusted Advisor — nó là dịch vụ tư vấn, khác hẳn nhóm dịch vụ chỉ cung cấp dữ liệu.
• Phân biệt rạch ròi ba động từ: CloudWatch = monitor (đo và cảnh báo theo ngưỡng bạn đặt), CloudTrail = audit (ghi lại ai gọi API gì), Trusted Advisor = advise (chấm điểm cấu hình rồi khuyên nên sửa gì).
• CloudWatch và Trusted Advisor cùng nói về hiệu năng nhưng ở hai vai khác nhau: một bên báo hiện trạng, một bên báo nên làm gì. Đề nghiêng về vế nào thì chọn theo vế đó.
• Inspector thuộc nhóm bảo mật, không thuộc nhóm hiệu năng — đừng để chữ "assessment/findings" kéo bạn sang nhầm chủ đề.

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

Đề hỏi: trong bốn cách triển khai được liệt kê, cách nào thuộc về reliability pillar (trụ cột độ tin cậy) của AWS Well-Architected Framework.

Cụm từ quyết định là "the reliability pillar". Đây là câu phân loại: cả bốn phương án đều là những việc làm hợp lý trên AWS, không có phương án nào "sai kỹ thuật" cả. Cái duy nhất tách chúng ra là mỗi phương án phục vụ một trụ cột khác nhau của Well-Architected Framework. Vì vậy đọc đề mà chỉ hỏi "cái nào tốt?" thì cả bốn đều tốt và bạn sẽ chọn bừa; phải hỏi "cái này giải quyết vấn đề gì?" rồi ánh xạ vấn đề đó sang đúng trụ cột.

Reliability nói về khả năng hệ thống tiếp tục thực hiện đúng chức năng khi có sự cố, và tự phục hồi sau hỏng hóc — một trong các nguyên tắc thiết kế của trụ cột này chính là "Automatically recover from failure". Chú ý phân biệt với performance efficiency (dùng tài nguyên đúng mức để đạt hiệu năng mong muốn), security (bảo vệ dữ liệu và hệ thống), operational excellence (vận hành, tự động hoá quy trình).

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

C. Amazon RDS Multi-AZ deployment.

Multi-AZ nghĩa là RDS duy trì một bản standby ở Availability Zone khác với instance chính. Khi instance chính hoặc cả AZ chứa nó gặp sự cố, RDS tự động failover sang standby mà không cần con người can thiệp — endpoint kết nối giữ nguyên, ứng dụng nối lại và chạy tiếp.

Đây đúng là mô tả của reliability: chịu được hỏng hóc ở mức hạ tầng, và tự phục hồi khỏi sự cố thay vì chờ người khắc phục thủ công. Cần nhớ Multi-AZ được thiết kế cho tính sẵn sàng và độ bền, không phải để tăng hiệu năng đọc — bản standby không phục vụ truy vấn.

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

A. Attach a WebACL to a CloudFront distribution — WebACL là cấu phần của AWS WAF, gắn vào CloudFront để lọc request độc hại (SQL injection, cross-site scripting, các mẫu tấn công theo rule). Việc này bảo vệ ứng dụng khỏi kẻ tấn công, nên nó thuộc security pillar. Đây là phương án dễ gây nhầm nhất vì chặn tấn công thì "trang web đỡ sập", nghe cũng giống độ tin cậy. Nhưng cách phân loại của Well-Architected dựa trên mục đích chính của biện pháp: WAF bảo vệ trước hành vi thù địch, còn reliability lo trước hỏng hóc của chính hệ thống.

B. Use CloudFormation to deploy infrastructure — CloudFormation là infrastructure as code: mô tả hạ tầng bằng template, triển khai lặp lại được, tránh thao tác tay. Đây là chuyện quy trình vận hành và tự động hoá, tức operational excellence pillar. Cũng khá gần đúng, vì hạ tầng dựng lại được từ template thì phục hồi sau thảm hoạ nhanh hơn. Chỗ nó hỏng: bản thân việc dùng CloudFormation không làm cho hệ thống chịu lỗi tốt hơn — nếu template mô tả một EC2 đơn lẻ trong một AZ thì triển khai bằng CloudFormation vẫn là kiến trúc mong manh y hệt. Nó cải thiện cách bạn triển khai, không phải khả năng chịu lỗi của cái được triển khai.

D. Amazon EBS provisioned IOPS volume — Provisioned IOPS là loại volume cho phép đặt trước mức IOPS cần thiết, dành cho workload nhạy với độ trễ và cần thông lượng I/O ổn định như cơ sở dữ liệu giao dịch. Mục đích ở đây là đạt hiệu năng theo yêu cầu, nên nó thuộc performance efficiency pillar. Nó hoàn toàn không thêm khả năng chống chịu khi hỏng: một volume nhanh vẫn là một volume, hỏng là mất — chọn nhầm vì thấy chữ "provisioned" nghe như cam kết chất lượng dịch vụ.

📌 Điểm cần nhớ

• Reliability = chịu được sự cố và tự phục hồi. Dấu hiệu nhận biết trong đề: Multi-AZ, failover tự động, nhiều bản sao ở nhiều AZ, backup và khôi phục.
• Ánh xạ nhanh các từ khoá hay gặp: WAF / WebACL / mã hoá / IAM → security; CloudFormation / tự động hoá triển khai / runbook → operational excellence; provisioned IOPS / chọn đúng loại instance → performance efficiency; còn Reserved Instance / Spot / tắt tài nguyên nhàn rỗi → cost optimization.
• Khi hai phương án nghe đều "làm hệ thống ổn hơn", hãy hỏi mục đích chính của biện pháp đó là gì, đừng hỏi tác dụng phụ. WAF có tác dụng phụ là giữ site sống, nhưng mục đích chính là chống tấn công.
• RDS Multi-AZ phục vụ tính sẵn sàng, không phục vụ hiệu năng đọc — đừng lẫn với read replica khi đề hỏi về mở rộng khả năng đọc.

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

Đề mô tả một công ty đang thiết kế dịch vụ mới và muốn tuân theo operational excellence pillar của AWS Well-Architected Framework, rồi hỏi design principles nào nên áp dụng (chọn HAI).

Cụm từ quyết định là "operational excellence pillar". Well-Architected Framework có năm trụ cột, mỗi trụ cột kèm một bộ nguyên tắc thiết kế riêng, nên câu hỏi không hỏi "cái nào tốt nói chung" mà hỏi "cái nào nằm trong danh sách nguyên tắc của trụ cột vận hành xuất sắc". Đây là dạng câu nhận diện thuật ngữ chính thức: các phương án sai được viết bằng cách lấy nguyên tắc thật rồi đảo ngược nó — "large-scale" đảo của "small", "manual" đảo của "as code", "static" đảo của "refine frequently". Nhận ra thủ thuật đảo ngược này là đủ để loại ba phương án mà không cần thuộc lòng từng chữ.

Bộ nguyên tắc của operational excellence gồm: perform operations as code; make frequent, small, reversible changes; refine operations procedures frequently; anticipate failure; learn from all operational failures.

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

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

C — Perform operations as code. Đây là nguyên tắc đầu tiên của trụ cột. Ý tưởng: coi toàn bộ hạ tầng và quy trình vận hành như mã nguồn — định nghĩa bằng file, đưa vào version control, kiểm thử và triển khai bằng cùng kỹ thuật dùng cho application code. Làm vậy thì thao tác vận hành trở nên lặp lại được, hạn chế lỗi do con người gõ tay, và mỗi thay đổi đều có lịch sử để truy vết hoặc quay lui.

E — Anticipate failure. Cũng nằm nguyên văn trong danh sách. Ý tưởng: chủ động giả định hỏng hóc sẽ xảy ra, diễn tập các kịch bản đó ("pre-mortem", tập dượt quy trình xử lý sự cố), tìm ra điểm yếu trước khi nó xảy ra trong môi trường thật, và kiểm tra xem quy trình ứng phó có thực sự chạy được không.

Hai phương án này là hai mục được chép thẳng từ danh sách chính thức, nên chúng đúng bất kể cách diễn giải.

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

A — Make large-scale changes. Đây là bản đảo ngược của nguyên tắc thật: make frequent, small, reversible changes. Đây là phương án gần đúng nhất vì nó có hình dạng của một nguyên tắc thật và chỉ sai đúng một chữ. Nhưng chữ đó đổi hẳn nghĩa: thay đổi quy mô lớn gộp nhiều thứ vào một lần triển khai, làm bán kính ảnh hưởng rộng, khó xác định thành phần nào gây lỗi và khó quay lui. Trụ cột vận hành xuất sắc khuyến nghị đúng chiều ngược lại — thay đổi nhỏ, thường xuyên, đảo ngược được.

B — Perform manual operations. Đối lập trực tiếp với C. Thao tác thủ công không lặp lại được chính xác, không có bản ghi thay đổi dạng mã, và mỗi lần thực hiện lại là một cơ hội gây lỗi mới. Không thể vừa chọn C vừa chọn B — hai phương án này loại nhau, đó cũng là gợi ý cho thấy một trong hai là đáp án.

D — Create static operational procedures. Đảo ngược của refine operations procedures frequently. Nghe có vẻ hợp lý vì "quy trình ổn định" thường được xem là tốt, nhưng chỗ hỏng nằm ở chữ static: workload thay đổi theo thời gian, nên quy trình vận hành phải được xem lại và cập nhật đều đặn cho khớp. Quy trình đóng băng sẽ dần lệch khỏi hệ thống thật, và đến lúc cần dùng trong sự cố thì không còn đúng nữa.

📌 Điểm cần nhớ

• Câu hỏi Well-Architected thường tạo mồi nhử bằng cách đảo ngược một nguyên tắc thật — gặp các từ manual, large-scale, static, one-time thì gần như chắc chắn là phương án sai.
• Năm nguyên tắc của operational excellence: perform operations as code; frequent, small, reversible changes; refine operations procedures frequently; anticipate failure; learn from all operational failures.
• Khi hai phương án loại nhau về nghĩa (as code ↔ manual), nhiều khả năng một trong hai là đáp án; chọn cái khớp với thực hành được khuyến nghị.
• Mỗi trụ cột có bộ nguyên tắc riêng — đọc kỹ tên trụ cột trong đề trước khi chọn, vì một nguyên tắc đúng ở trụ cột khác vẫn là đáp án sai ở đây.

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

Đề hỏi: dịch vụ hoặc tính năng nào của AWS có thể giúp bảo vệ một website được host BÊN NGOÀI AWS.

Cụm từ quyết định là "hosted outside of AWS" — website không chạy trên EC2, không nằm trong VPC, không phải tài nguyên AWS. Ngay khi đọc được cụm này, cách sàng lọc trở nên rất máy móc: bất kỳ phương án nào là thành phần bên trong VPC hoặc gắn vào tài nguyên AWS cụ thể đều tự loại, vì đơn giản là không có gì để gắn vào. Chỉ còn lại phương án hoạt động ở tầng ứng dụng và có thể đặt trước một backend nằm ngoài AWS.

Cụm phụ đáng chú ý là "protecting a website" — bảo vệ website, tức lưu lượng HTTP/HTTPS ở tầng ứng dụng, chứ không phải lọc gói tin theo IP/port thuần tuý.

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

Đáp án đúng theo tệp là C — AWS Web Application Firewall (WAF).

AWS WAF là web application firewall hoạt động ở tầng ứng dụng: nó gắn một WebACL vào một điểm phân phối lưu lượng của AWS (ví dụ Application Load Balancer) và kiểm tra từng request HTTP/HTTPS theo các rule trước khi cho đi tiếp.

Điểm mấu chốt làm nó dùng được cho website ngoài AWS: Application Load Balancer hỗ trợ target group kiểu IP address. Nghĩa là bạn có thể khai báo chính các máy chủ web on-premises (theo địa chỉ IP) làm target của ALB. Lúc này lưu lượng của người dùng đi vào ALB, đi qua WebACL của WAF để được lọc, rồi mới chuyển tiếp xuống website đang chạy ngoài AWS. Website nằm ngoài AWS vẫn được che chắn, dù bản thân nó không phải tài nguyên AWS nào cả.

Đây chính là lý do WAF là dịch vụ duy nhất trong danh sách vượt qua được ràng buộc "outside of AWS": nó bảo vệ luồng request, không bảo vệ một máy ảo hay một subnet.

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

A. Amazon VPC network ACLs — network ACL là bộ lọc stateless gắn vào subnet của một VPC, chỉ kiểm soát lưu lượng ra/vào ranh giới subnet đó. Một website chạy ngoài AWS không nằm trong subnet nào của VPC, nên không có subnet nào để gắn ACL vào. Ngoài ra network ACL chỉ lọc theo IP/port/protocol, không hiểu nội dung request HTTP nên kể cả về mặt chức năng cũng không phải công cụ "bảo vệ website" theo nghĩa tầng ứng dụng.

B. Amazon EC2 security groups — đây là phương án dễ nhầm nhất vì security group đúng là một cơ chế bảo vệ phổ biến. Nhưng nó hỏng ở chỗ phạm vi gắn kết: security group chỉ đính vào ENI của các tài nguyên trong VPC (EC2 instance và các dịch vụ dùng ENI). Website on-premises không có ENI trong VPC của bạn, nên không cách nào áp security group lên nó. Cũng giống network ACL, security group lọc theo IP/port chứ không phân tích nội dung request web.

D. Amazon VPC route tables — route table hoàn toàn không phải cơ chế bảo mật; nó chỉ quyết định gói tin trong VPC đi theo hướng nào (internet gateway, NAT, VPC peering...). Nó không chấp nhận hay từ chối lưu lượng theo tiêu chí bảo mật, và cũng chỉ có ý nghĩa bên trong VPC. Với tài nguyên ngoài AWS thì cả hai lý do đều đúng: sai chức năng và sai phạm vi.

Nhìn chung, ba phương án sai đều là thành phần networking bên trong VPC. Đề cố tình xếp chúng cạnh nhau để kiểm tra xem người học có nhận ra ràng buộc "outside of AWS" hay không.

📌 Điểm cần nhớ

• Gặp cụm "outside of AWS" / "on-premises" trong đề bảo mật: loại ngay mọi phương án là thành phần của VPC (security group, network ACL, route table, subnet) — chúng không có gì để gắn vào khi tài nguyên nằm ngoài.
• Phân biệt phạm vi gắn kết: security group gắn vào tài nguyên trong VPC; network ACL gắn vào subnet; còn WAF gắn WebACL vào điểm phân phối lưu lượng, nên backend nằm ở đâu không quan trọng.
• Phân biệt tầng hoạt động: security group và network ACL lọc theo IP/port (tầng mạng/vận chuyển); AWS WAF kiểm tra nội dung request HTTP/HTTPS (tầng ứng dụng). Đề nhắc "website" là gợi ý nghiêng về tầng ứng dụng.
• Route table không phải công cụ bảo mật — nó chỉ định tuyến. Thấy nó trong câu hỏi về "protect/secure" thì gần như luôn là phương án gây nhiễu.
• Cầu nối kỹ thuật đáng nhớ: ALB hỗ trợ target group theo địa chỉ IP, nhờ đó lưu lượng đã qua WAF có thể chuyển tiếp xuống máy chủ nằm ngoài AWS.

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

Một công ty chạy nhiều ứng dụng trên Amazon EC2, mỗi ứng dụng phục vụ một phòng ban khác nhau. Yêu cầu là tách chi phí của từng ứng dụng ra và phân bổ về đúng phòng ban.

Cụm từ quyết định nằm ở chỗ này: "break out the costs of these applications and allocate them to the relevant department". Đề không hỏi cách xem tổng chi phí, cũng không hỏi cách được báo khi chi phí vượt ngưỡng — đề hỏi cách gán chi phí cho từng nhóm tài nguyên do mình tự định nghĩa (ở đây là phòng ban). Trong AWS, khái niệm ánh xạ thẳng vào yêu cầu đó là cost allocation tags.

Một cụm nữa cũng có ý đồ: "The EC2 instances run in a single VPC". Câu này được thêm vào để gài phương án C — nó khiến người đọc nghĩ rằng "cùng một VPC nên không tách được, vậy phải tách VPC ra". Thực tế ranh giới VPC không phải là chiều phân bổ chi phí, nên chi tiết này chỉ là mô tả hiện trạng chứ không phải vấn đề cần sửa.

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

D — Create tags by department on the instances and then run a cost allocation report.

Tag là cặp key–value gắn lên tài nguyên AWS, ví dụ Department = Sales. Sau khi gắn tag lên các EC2 instance, tag đó phải được kích hoạt làm cost allocation tag trong phần Billing thì nó mới xuất hiện trong báo cáo chi phí. Khi đã kích hoạt, cost allocation report sẽ nhóm và cộng chi phí theo giá trị của tag — tức là ra đúng con số "phòng ban A tốn bao nhiêu, phòng ban B tốn bao nhiêu".

Đây chính là cơ chế AWS thiết kế riêng cho bài toán chargeback/showback: bạn tự định nghĩa chiều phân bổ (phòng ban, dự án, môi trường) bằng tag, rồi báo cáo chi phí cộng theo chiều đó. Không cần đổi kiến trúc mạng, không cần tách tài khoản.

Lưu ý theo hướng nguyên lý: tag chỉ có hiệu lực trong báo cáo kể từ lúc được kích hoạt trở đi, nên nên gắn và kích hoạt sớm thay vì đợi tới kỳ quyết toán.

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

A — Enable billing alerts through Amazon CloudWatch and Amazon SNS. Billing alert chỉ làm một việc: khi chi phí chạm ngưỡng đã đặt, gửi thông báo qua SNS. Đó là cơ chế cảnh báo, không phải cơ chế phân bổ. Nó cho bạn biết "đã tiêu tới mức X" chứ không nói được X đó gồm bao nhiêu của phòng ban nào. Yêu cầu của đề là chia nhỏ chi phí, hoàn toàn không liên quan tới ngưỡng.

B — Enable billing access for IAM users and view the costs in Cost Explorer. Đây là phương án gần đúng nhất và cũng là bẫy chính. Cost Explorer đúng là công cụ xem và phân tích chi phí, nhưng vấn đề nằm ở chỗ: nếu chưa có tag phòng ban, Cost Explorer không có căn cứ nào để tách chi phí theo phòng ban. Nó chỉ chia được theo những chiều mà AWS biết sẵn — dịch vụ, region, loại instance, tài khoản. "Phòng ban" là khái niệm của doanh nghiệp, AWS không tự đoán ra được. Nói cách khác, phương án B thiếu đúng bước tạo ra thông tin cần thiết; phần "enable billing access for IAM users" chỉ là chuyện cấp quyền xem hoá đơn, chẳng giải quyết gì.

C — Add additional Amazon VPCs and launch each application in a separate VPC. Phương án này bám vào chi tiết "single VPC" trong đề nhưng hiểu sai vai trò của nó. Hoá đơn AWS không được bóc tách theo VPC — chi phí EC2 tính theo instance, theo giờ chạy và loại instance, chứ không gắn nhãn VPC nào trong báo cáo. Tách VPC ra thì vẫn không có cách nào đọc được chi phí từng phòng ban. Ngoài ra đây là thay đổi kiến trúc mạng rất nặng tay, kéo theo việc di chuyển toàn bộ instance, chỉ để phục vụ một nhu cầu báo cáo — sai cả về kết quả lẫn về chi phí thực hiện.

📌 Điểm cần nhớ

• Hễ đề nhắc tới phân bổ chi phí theo phòng ban / dự án / môi trường / nhóm tự định nghĩa, đáp án gần như luôn là tag kết hợp với cost allocation report. Đó là chiều phân loại duy nhất do người dùng tự đặt ra.
• Phân biệt rõ ba nhóm công cụ billing: billing alert (CloudWatch + SNS) để cảnh báo vượt ngưỡng, Cost Explorer để xem và phân tích, cost allocation tags + report để bóc tách và quy trách nhiệm chi phí. Đề hỏi việc nào thì chọn công cụ của việc đó.
• Cost Explorer chỉ mạnh khi dữ liệu đã được gắn tag. Không có tag thì nó chỉ chia được theo các chiều AWS biết sẵn (service, region, account), không có "phòng ban".
• Ranh giới hạ tầng như VPC không phải là ranh giới tính tiền. Đề cố tình nhắc "single VPC" để gài; đừng đổi kiến trúc mạng để giải một bài toán báo cáo.

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

Đề hỏi: dịch vụ AWS nào giúp một công ty discover and protect sensitive data đang nằm trong Amazon S3 buckets.

Cụm từ quyết định là "discover ... sensitive data" — tức là phát hiện ra dữ liệu nhạy cảm, chứ không phải phát hiện hành vi tấn công. Đây chính là ranh giới tách bốn phương án: cả GuardDuty lẫn Detective đều là dịch vụ bảo mật có liên quan tới S3, nhưng chúng làm việc trên log và hành vi (ai truy cập, có bất thường không), còn đề bài hỏi về nội dung bên trong dữ liệu (trong bucket này có số thẻ tín dụng, số căn cước, thông tin cá nhân hay không).

Cụm thứ hai đáng chú ý là "stored in Amazon S3 buckets" — phạm vi giới hạn vào dữ liệu ở trạng thái lưu trữ (data at rest) trong S3, chứ không phải luồng traffic hay sự kiện quản trị.

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

D. Amazon Macie là dịch vụ được quản lý hoàn toàn (fully managed) chuyên về data security và data privacy. Macie dùng machine learning và pattern matching để quét chính nội dung các đối tượng trong S3 và chỉ ra chỗ nào có dữ liệu nhạy cảm, điển hình là PII (personally identifiable information).

Ngoài việc quét nội dung, Macie còn tự động dựng bản kiểm kê (inventory) các S3 bucket: bucket nào chưa mã hoá, bucket nào đang public, bucket nào được chia sẻ với tài khoản AWS nằm ngoài phạm vi AWS Organizations mà bạn đã khai. Sau đó nó áp phân tích lên những bucket bạn chọn và cảnh báo khi tìm thấy dữ liệu nhạy cảm.

Đúng hai vế mà đề bài yêu cầu: discover (tự động tìm ở quy mô lớn) và protect (cảnh báo, chỉ ra rủi ro cấu hình để bạn xử lý), đều gắn thẳng với Amazon S3.

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

A. Amazon Detective — sai. Detective xử lý khối lượng lớn dữ liệu sự kiện: bản ghi IP traffic, các thao tác quản trị AWS, và hoạt động độc hại/trái phép. Mục đích của nó là giúp điều tra nguyên nhân gốc của một phát hiện bảo mật — dựng lại chuỗi sự việc, xem entity nào liên quan. Nó phân tích sự kiện, không mở đối tượng S3 ra đọc xem bên trong có PII hay không, nên không đáp ứng chữ "discover sensitive data".

B. Amazon GuardDuty — đây là phương án gần đúng nhất và cũng là bẫy chính. GuardDuty là dịch vụ threat detection, giám sát liên tục để tìm hoạt động độc hại và hành vi trái phép nhằm bảo vệ tài khoản, workload và cả dữ liệu lưu trong Amazon S3. Vì mô tả của nó có nhắc tới S3 nên rất dễ chọn nhầm. Chỗ nó hỏng: GuardDuty phát hiện mối đe doạ — ví dụ truy cập bất thường vào bucket, gọi API từ nguồn đáng ngờ — chứ không phân loại nội dung để nói cho bạn biết dữ liệu nào là nhạy cảm. Đề hỏi "discover sensitive data", không hỏi "discover threats".

C. AWS Policy Generator — sai. Đây là một công cụ tạo policy, giúp bạn soạn ra các policy kiểm soát quyền truy cập vào sản phẩm và tài nguyên AWS. Nó nằm ở khâu cấp/chặn quyền, hoàn toàn không quét và cũng không biết gì về nội dung dữ liệu bên trong bucket. Nó có thể là một phần của việc "protect" sau khi đã biết vấn đề, nhưng không hề "discover".

📌 Điểm cần nhớ

• Nghe thấy "sensitive data", "PII", "data privacy", "data classification" gắn với S3 → Amazon Macie. Đây là dịch vụ duy nhất trong nhóm bảo mật AWS làm việc trên nội dung của dữ liệu.
• Phân biệt ba dịch vụ dễ nhầm theo thứ mà chúng đọc: Macie đọc dữ liệu trong S3; GuardDuty đọc tín hiệu đe doạ để phát hiện hành vi độc hại; Detective đọc log sự kiện để điều tra nguyên nhân một phát hiện đã có.
• GuardDuty có nhắc tới S3 trong mô tả chính thức, nên đừng chỉ dựa vào từ khoá "S3" để chọn — phải đọc kỹ động từ trong đề: discover data hay detect threats.
• AWS Policy Generator là công cụ soạn policy về quyền truy cập, không phải dịch vụ giám sát hay quét dữ liệu; gặp nó trong danh sách phương án của câu hỏi về phát hiện/giám sát thì gần như luôn là phương án loại.

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

Đề mô tả một công ty có nhiều AWS account và đang dùng AWS Organizations với consolidated billing, rồi hỏi họ được lợi gì. Cụm từ quyết định là "consolidated billing" — không phải AWS Organizations nói chung.

Đây là điểm phân biệt quan trọng: AWS Organizations có nhiều tính năng (SCP, quản lý account, phân nhóm OU...), nhưng đề chỉ hỏi về phần gộp hoá đơn. Vì vậy mọi phương án nói về hạn mức dịch vụ hay gói hỗ trợ đều nằm ngoài phạm vi của tính năng đang được hỏi.

Cụm từ thứ hai cần soi kỹ là các định lượng trong từng phương án: "may benefit" (có thể được lợi) so với "fixed discount for all usage" (giảm giá cố định cho mọi mức dùng). Hai cách diễn đạt này mô tả hai mô hình giá hoàn toàn khác nhau, và đó chính là chỗ đề gài.

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

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

D — "They will receive one bill for the accounts in the Organization": đây đúng là công dụng cốt lõi và hiển nhiên nhất của consolidated billing. Account quản lý (management account) nhận một hoá đơn duy nhất cho toàn bộ các account thành viên, đồng thời theo dõi được chi phí phát sinh ở từng account. Bản thân tính năng này không thu thêm phí.

A — "They may benefit from lower unit pricing for aggregated usage": AWS cộng gộp mức sử dụng của tất cả account trong Organization lại rồi mới tính giá. Nhiều dịch vụ AWS áp dụng biểu giá bậc thang (dùng càng nhiều thì đơn giá bậc sau càng rẻ), nên khi gộp lại, tổng mức dùng có thể chạm bậc giá thấp hơn so với việc từng account tính riêng lẻ. Ngoài ra, Reserved Instance và Savings Plans mua ở một account cũng được chia sẻ lợi ích trong phạm vi Organization. Chữ "may" trong phương án là chính xác: có lợi hay không còn tuỳ vào việc mức dùng gộp lại có vượt ngưỡng bậc giá hay không.

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

B — "They will receive a fixed discount for all usage across accounts": đây là phương án gần đúng nhất và cũng dễ bẫy nhất, vì nó cũng nói về giảm giá. Chỗ hỏng nằm ở chữ "fixed" và "all usage". Consolidated billing không áp một tỷ lệ giảm giá cố định cho mọi mức tiêu dùng. Cơ chế thực tế là gộp usage rồi áp biểu giá theo bậc — nếu mức dùng gộp lại vẫn nằm ở bậc đầu tiên thì công ty không được giảm gì cả. So sánh trực tiếp với A: A nói "may benefit from lower unit pricing" (có điều kiện, theo bậc), B nói "fixed discount" (vô điều kiện, cố định) — chỉ cách diễn đạt của A mới khớp với cách AWS tính tiền.

C — "The default service limits in all accounts will be increased": sai vì consolidated billing chỉ động tới hoá đơn, không động tới hạn mức dịch vụ (service quotas). Mỗi account vẫn giữ hạn mức mặc định riêng của nó; muốn nâng thì vẫn phải mở yêu cầu cho từng account. Đây là lỗi trộn lẫn hai khái niệm khác nhau: gộp chi phí không có nghĩa là gộp hay nới năng lực kỹ thuật.

E — "They will be automatically enrolled in a business support plan": sai vì gói hỗ trợ (support plan) là dịch vụ trả phí riêng, phải chủ động đăng ký và trả tiền, không tự động có chỉ vì đã bật consolidated billing. Việc dùng Organizations không tự nâng cấp mức hỗ trợ cho bất kỳ account nào.

📌 Điểm cần nhớ

• Consolidated billing = một hoá đơn + gộp usage để hưởng giá bậc thấp hơn + chia sẻ lợi ích Reserved Instances/Savings Plans + không tính thêm phí. Bốn ý này gần như luôn là đáp án đúng cho dạng câu hỏi này.
• Cảnh giác với các phương án ghi "fixed discount" hay "automatic discount" — giá AWS vận hành theo bậc thang phụ thuộc mức dùng, không theo tỷ lệ cố định. Phương án nào diễn đạt có điều kiện ("may", "depending on usage") thường sát thực tế hơn.
• Gộp hoá đơn không đồng nghĩa với gộp hạn mức. Service quotas vẫn tính riêng theo từng account, và phải yêu cầu nâng riêng cho từng account.
• Support plan luôn phải mua riêng, không đi kèm miễn phí với Organizations hay consolidated billing. Bất kỳ phương án nào nói được "tự động" có gói hỗ trợ đều sai.

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

Đề hỏi: "Which of the following represents a value proposition for using the AWS Cloud?" — đâu là một giá trị mà AWS Cloud mang lại cho khách hàng.

Cụm từ quyết định là "value proposition". Đây không phải câu hỏi kỹ thuật về dịch vụ nào cả, mà là câu hỏi khái niệm về lợi ích của mô hình điện toán đám mây so với việc tự dựng hạ tầng tại chỗ (on-premises). Vì vậy phương án đúng phải là một điều AWS thực sự cung cấp và là một cải thiện so với mô hình truyền thống.

Ràng buộc phụ ẩn phía sau: ba phương án còn lại đều mô tả những điều AWS không làm — hoặc vì lý do bảo mật vật lý, hoặc vì mô hình chia sẻ trách nhiệm (Shared Responsibility Model). Nhận ra rằng đề đang trộn "lợi ích thật" với "điều nghe có vẻ hấp dẫn nhưng AWS không hứa" là chìa khoá loại nhanh ba phương án sai.

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

A. "It is not necessary to enter into long term contracts."

Đúng, và đây chính là một trong những lợi ích cốt lõi được AWS nêu trong tài liệu Six Advantages of Cloud Computing. Mô hình của AWS là pay-as-you-go: bạn trả tiền cho phần tài nguyên thực sự dùng, bật một EC2 instance lên rồi tắt đi thì chỉ trả cho khoảng thời gian nó chạy. Không có cam kết tối thiểu bắt buộc, không phải ký hợp đồng nhiều năm trước khi được dùng dịch vụ.

Điều này đối lập trực tiếp với mô hình on-premises, nơi bạn phải mua máy chủ trước (capital expenditure), hoặc thuê chỗ đặt máy theo hợp đồng dài hạn với nhà cung cấp data center.

Lưu ý sắc thái quan trọng mà giải thích gốc nhấn mạnh: không bắt buộc ký hợp đồng dài hạn, nhưng bạn được phép làm vậy nếu muốn tiết kiệm chi phí. Reserved Instances và Savings Plans cho phép cam kết 1 năm hoặc 3 năm để đổi lấy mức giá thấp hơn đáng kể so với On-Demand. Đó là lựa chọn, không phải điều kiện tham gia — và chính tính "tùy chọn" ấy mới là value proposition.

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

B. "AWS provides full access to their data centers."

Sai hoàn toàn, và đây là phương án dễ loại nhất. AWS không bao giờ cho khách hàng vào trong data center của mình. Vị trí vật lý của các data center thậm chí không được công bố công khai; an ninh vật lý là một phần trách nhiệm AWS giữ cho riêng mình trong Shared Responsibility Model. Cái khách hàng nhận được thay thế là các báo cáo kiểm toán độc lập (SOC, ISO, PCI…) qua AWS Artifact — bạn tin vào bên thứ ba kiểm toán, chứ không tự vào xem.

C. "Customers can request specialized hardware."

Nghe hợp lý nên đây là bẫy gần đúng nhất, nhưng vẫn sai ở chỗ chữ "request". Khách hàng chọn trong danh mục instance type mà AWS đã định sẵn (có GPU, có bộ nhớ lớn, có CPU tối ưu tính toán…), chứ không đặt hàng một cấu hình phần cứng riêng theo ý mình. Bạn không có tiếng nói nào về việc AWS dùng phần cứng gì bên dưới. Chính việc AWS chuẩn hoá phần cứng ở quy mô cực lớn mới tạo ra được lợi thế chi phí — cho phép đặt hàng riêng là phá vỡ mô hình đó.

D. "AWS is responsible for securing your applications."

Sai vì hiểu ngược Shared Responsibility Model. AWS chịu trách nhiệm bảo mật "of the cloud" — hạ tầng vật lý, mạng lõi, lớp ảo hoá. Khách hàng chịu trách nhiệm bảo mật "in the cloud" — mã ứng dụng, cấu hình IAM, dữ liệu, vá lỗi hệ điều hành khách (với các dịch vụ như EC2). Ứng dụng của bạn nằm gọn ở vế thứ hai. Đây là phương án nguy hiểm nhất vì nếu tin nó ngoài đời thật, bạn sẽ để lại lỗ hổng mà không ai vá hộ.

📌 Điểm cần nhớ

• "Value proposition" của AWS Cloud thường quy về nhóm lợi ích kinh tế và vận hành: pay-as-you-go, không cam kết dài hạn bắt buộc, đổi CapEx thành OpEx, co giãn theo nhu cầu, triển khai toàn cầu trong vài phút. Thấy phương án nào nằm ngoài nhóm này thì cân nhắc kỹ.
• Không bắt buộc ký hợp đồng dài hạn ≠ không có hợp đồng dài hạn. Reserved Instances và Savings Plans tồn tại như một lựa chọn giảm giá khi bạn cam kết 1 hoặc 3 năm.
• Shared Responsibility Model là bộ lọc loại phương án cực nhanh. Bất kỳ phương án nào nói AWS bảo mật ứng dụng, dữ liệu, hay cấu hình của bạn đều sai; AWS chỉ lo bảo mật của đám mây, bạn lo bảo mật trong đám mây.
• Khách hàng không tiếp cận data center và không đặt phần cứng riêng. Đổi lại, AWS cung cấp báo cáo tuân thủ qua AWS Artifact và một danh mục instance type rộng để chọn.