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

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

Đề hỏi: theo AWS shared responsibility model, việc nào thuộc trách nhiệm của AWS?

Cụm từ quyết định đáp án là "a responsibility of AWS" — chứ không phải của khách hàng. Cả bốn phương án đều là công việc bảo mật hợp lệ và đều thực sự xảy ra trong một hệ thống chạy trên AWS; điểm phân biệt duy nhất là ai cầm tay làm việc đó.

Cách chia trong shared responsibility model rất gọn:

• AWS chịu trách nhiệm security of the cloud — phần hạ tầng vật lý mà khách hàng không nhìn thấy và không đăng nhập vào được: trung tâm dữ liệu, phần cứng máy chủ, firmware của host, lớp ảo hoá (hypervisor), mạng vật lý.
• Khách hàng chịu trách nhiệm security in the cloud — mọi thứ khách hàng tự bật, tự cấu hình, tự vá: hệ điều hành guest trên EC2, phần mềm cài trong instance, dữ liệu, danh tính, và các cấu hình mạng như security group hay network ACL.

Vậy chỉ cần đặt câu hỏi cho từng phương án: thứ này có nút bấm trong Console/API của khách hàng không? Có nút bấm → khách hàng làm. Không chạm tới được → AWS làm.

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

C. Updating the firmware on the underlying EC2 hosts — đúng.

Từ khoá là "underlying EC2 hosts": đây là các máy chủ vật lý nằm dưới lớp ảo hoá, nơi các EC2 instance của nhiều khách hàng cùng chạy. Khách hàng không có bất kỳ đường nào để truy cập host vật lý — không SSH được vào nó, không có API nào để nâng cấp firmware của nó. Toàn bộ việc bảo trì phần cứng, cập nhật firmware và vá lớp ảo hoá do AWS thực hiện, thuộc đúng vế "security of the cloud".

Đây cũng chính là điều phần giải thích gốc khẳng định: AWS lo firmware trên máy chủ EC2 vật lý; khách hàng lo việc vá hệ điều hành EC2 và mọi phần mềm đã cài lên đó.

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

A. Updating security group rules to enable connectivity — sai, đây là trách nhiệm khách hàng. Security group là firewall ảo ở mức instance, và nó nằm trọn trong tài khoản khách hàng: chính khách hàng quyết định mở cổng nào, cho dải IP nào. AWS cung cấp cơ chế security group, nhưng nội dung luật thì AWS không biết và không được phép sửa. Phương án này gài bẫy vì nghe rất "bảo mật hạ tầng" — nhưng cấu hình được qua Console thì là việc của khách hàng.

B. Patching software running on Amazon EC2 instances — sai, đây là trách nhiệm khách hàng, và là phương án dễ nhầm nhất vì nó chỉ khác đáp án C ở chỗ "patch cái gì". Với mô hình EC2 (IaaS), AWS giao cho bạn một máy ảo và dừng ở đó: guest OS, gói phần mềm, thư viện, ứng dụng bên trong instance đều do bạn vá. So sánh trực tiếp: firmware của host = AWS (C), phần mềm trong instance = khách hàng (B). Ranh giới nằm đúng ở lớp ảo hoá.

D. Configuring network ACLs to block malicious attacks — sai, đây là trách nhiệm khách hàng. Network ACL là bộ lọc ở mức subnet trong VPC của bạn; bạn tự viết luật allow/deny theo kiến trúc mạng của mình. AWS bảo vệ hạ tầng mạng vật lý bên dưới, nhưng luật lọc trong VPC thì AWS không đặt hộ. Giống phương án A, chỉ khác cấp độ áp dụng (subnet thay vì instance) — cả hai đều là cấu hình, nên đều thuộc về khách hàng.

📌 Điểm cần nhớ

• Nguyên tắc phân định nhanh: thứ nào khách hàng bấm/cấu hình được qua Console, CLI hay API thì là trách nhiệm khách hàng; thứ nào khách hàng không chạm tới được (phần cứng, firmware, hypervisor, trung tâm dữ liệu) thì là trách nhiệm AWS.
• AWS = "security of the cloud", khách hàng = "security in the cloud". Nhớ đúng cặp giới từ này là giải được phần lớn câu hỏi cùng chủ đề.
• Mọi cấu hình mạng trong VPC đều thuộc về khách hàng: security group (mức instance) và network ACL (mức subnet) đều do bạn viết luật, dù chúng nghe rất giống "hạ tầng".
• Với EC2, ranh giới nằm ở lớp ảo hoá: từ guest OS trở lên là của bạn (vá OS, vá phần mềm cài thêm); từ host vật lý trở xuống là của AWS (firmware, phần cứng). Ranh giới này dịch chuyển theo loại dịch vụ — dịch vụ càng managed thì AWS càng gánh nhiều, nên hãy đọc kỹ đề nói về dịch vụ nào trước khi chọn.

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

Đề hỏi rất gọn: IAM access key dùng để làm gì?

Cụm từ quyết định đáp án là "access keys" — chứ không phải "credentials" nói chung. Trong IAM, mỗi loại credential phục vụ đúng một kênh truy cập, và đề đang bắt bạn phân biệt kênh nào:

Bốn phương án cố tình trộn lẫn nhiều lĩnh vực khác nhau: một cái nói về API (đúng kênh), một cái nói về Console (nhầm loại credential), hai cái còn lại nói về mã hoá đường truyền và tính toàn vẹn log — hoàn toàn không thuộc phạm vi IAM credential. Chỉ cần bám vào chữ "programmatic" (lập trình) là tách được ngay.

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

A — "Making programmatic calls to AWS from AWS APIs" là đáp án đúng.

Access key là long-term credential gắn với một IAM user hoặc với AWS account root user. Nó gồm hai phần đi kèm nhau:

• Access key ID — phần định danh, dạng AKIAIOSFODNN7EXAMPLE
• Secret access key — phần bí mật, dạng wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Cả hai phải dùng cùng lúc để ký (sign) các programmatic request gửi tới AWS — dù bạn gọi thẳng AWS API, gọi qua AWS CLI, hay gọi qua AWS SDK trong code ứng dụng. Đó chính là định nghĩa của "programmatic call": chương trình tự gọi AWS, không có người ngồi gõ mật khẩu.

Cặp khoá này đóng vai trò tương đương user name + password, chỉ khác là dành cho máy. Vì vậy nguyên tắc bảo vệ cũng ngang bằng: giữ secret access key cẩn thận đúng như giữ mật khẩu, không hard-code vào source code, không đẩy lên repository.

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

B — "Enabling encryption in transit for web servers"

Mã hoá đường truyền cho web server là việc của SSL/TLS certificate, dùng để dựng kênh HTTPS giữa client và server. Đây là hai chuyện tách bạch: certificate lo bảo mật đường truyền, còn access key lo xác thực danh tính người gọi API. Access key không tham gia bắt tay TLS, và cài đặt access key lên web server cũng chẳng làm request nào trở thành HTTPS.

C — "Ensuring the integrity of log files"

Đảm bảo tính toàn vẹn của file log không phải công dụng của access key. Access key chỉ dùng để ký request, hoàn toàn không có chức năng phát hiện log bị sửa đổi sau khi ghi. Phương án này nằm ngoài phạm vi IAM credential.

D — "Logging in to the AWS Management Console"

Đây là phương án gây nhầm nhất và cũng là bẫy chính của câu hỏi, vì nó đúng lĩnh vực IAM, chỉ sai loại credential. Để đăng nhập Console, bạn dùng user name và password (kèm MFA nếu đã bật). Console không có ô nào để dán access key ID và secret access key vào cả. Nói cách khác: access key và mật khẩu Console là hai bộ credential riêng biệt của cùng một IAM user, phục vụ hai kênh khác nhau — sinh access key cho user không giúp user đó đăng nhập được Console, và ngược lại.

📌 Điểm cần nhớ

• Con người dùng password, chương trình dùng access key. Thấy đề nhắc "Management Console" → nghĩ user name + password + MFA. Thấy "programmatic / CLI / SDK / API" → nghĩ access key ID + secret access key.
• Access key luôn là một cặp: access key ID (định danh, không bí mật) và secret access key (bí mật, chỉ hiện đúng một lần lúc tạo). Thiếu một nửa thì không ký được request nào.
• Access key là long-term credential — bảo vệ nó ngang mật khẩu: không nhúng vào source code, xoay vòng định kỳ, vô hiệu hoá ngay khi nghi ngờ lộ. Đặc biệt tránh tạo access key cho root user.
• Với câu hỏi kiểu "X dùng để làm gì", hãy loại trước những phương án lạc hẳn lĩnh vực (mã hoá đường truyền, toàn vẹn log), rồi tập trung phân biệt các phương án cùng lĩnh vực — bẫy thật thường nằm ở đó.

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

Đề hỏi: dịch vụ AWS nào cho phép một nhóm triển khai hạ tầng (deploy infrastructure) trên AWS bằng những ngôn ngữ lập trình quen thuộc.

Cụm từ quyết định là "using familiar programming languages" — tức là viết hạ tầng bằng TypeScript, Python, Java, C#… thay vì viết file mô tả cấu hình. Cụm thứ hai không kém quan trọng là "deploy infrastructure": dịch vụ được hỏi phải tạo ra và triển khai tài nguyên, chứ không phải kiểm tra, lưu trữ hay đánh giá gì đó liên quan tới hạ tầng.

Ghép hai ràng buộc lại thì bài toán rất hẹp: Infrastructure as Code + dùng ngôn ngữ lập trình thật. Bốn phương án đều là các dịch vụ nằm quanh nhóm developer tools nên nhìn thoáng qua thấy "cái nào cũng dính tới code", nhưng chỉ một cái vừa sinh ra hạ tầng vừa nhận đầu vào là ngôn ngữ lập trình.

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

C — AWS Cloud Development Kit (AWS CDK).

AWS CDK là một software development framework mã nguồn mở để định nghĩa tài nguyên cloud bằng các ngôn ngữ lập trình quen thuộc. Người dùng viết code bằng ngôn ngữ mình đã thạo, CDK tổng hợp (synthesize) code đó thành template và triển khai hạ tầng thông qua AWS CloudFormation.

Đây chính là mô tả khớp từng chữ với đề bài: đầu vào là ngôn ngữ lập trình quen thuộc, đầu ra là hạ tầng thật được deploy trên AWS. Không phương án nào khác có đặc điểm "viết bằng programming language để dựng hạ tầng" này.

Điểm đáng nhớ: CDK không thay thế CloudFormation mà đứng trên CloudFormation — nó là lớp trừu tượng giúp bạn dùng vòng lặp, hàm, biến, lớp và kiểu dữ liệu của ngôn ngữ lập trình, thay vì viết tay toàn bộ mô tả tài nguyên.

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

A — AWS Config. Dịch vụ này dùng để quản lý tuân thủ cấu hình (configuration compliance management): ghi nhận cấu hình tài nguyên, theo dõi thay đổi theo thời gian và đánh giá xem tài nguyên có tuân thủ các quy tắc đặt ra hay không. Đây là phương án gần đúng nhất theo kiểu "cũng liên quan tới hạ tầng", và tên "Config" dễ khiến người học liên tưởng tới việc cấu hình hạ tầng. Nhưng nó hỏng ở đúng cả hai ràng buộc của đề: Config quan sát và kiểm tra hạ tầng đã tồn tại chứ không tạo ra hạ tầng, và người dùng không viết code bằng ngôn ngữ lập trình để điều khiển nó.

B — AWS CodeCommit. Đây là dịch vụ source control được quản lý hoàn toàn — nơi lưu trữ kho mã nguồn. Nó có dính tới "programming languages" theo nghĩa chứa file code của bạn, và đó chính là chỗ gây nhầm. Nhưng lưu trữ code hoàn toàn khác với thực thi code để dựng hạ tầng: CodeCommit không hiểu nội dung file bạn cất vào, và bản thân nó không deploy bất cứ tài nguyên AWS nào.

D — Amazon CodeGuru. Dịch vụ này rà soát code và đưa ra khuyến nghị cải thiện một cách thông minh. Nó cũng làm việc trực tiếp với ngôn ngữ lập trình, nên thoạt nghe rất khớp vế "familiar programming languages" của đề. Chỗ hỏng nằm ở vế còn lại: CodeGuru nhận xét về code, kết quả đầu ra là các gợi ý cho lập trình viên, chứ tuyệt nhiên không tạo ra hay triển khai hạ tầng nào cả.

📌 Điểm cần nhớ

• Thấy đề nhắc "infrastructure as code" kết hợp với "familiar programming languages" (TypeScript, Python, Java, C#…) thì gần như chắc chắn là AWS CDK. Nếu đề chỉ nói định nghĩa hạ tầng bằng file mô tả template thì mới là CloudFormation.
• CDK chạy trên nền CloudFormation: code → synthesize thành template → CloudFormation deploy. Hai dịch vụ bổ trợ nhau chứ không loại trừ nhau.
• Phân biệt bằng động từ chính trong đề: deploy hạ tầng → CDK; lưu trữ mã nguồn → CodeCommit; rà soát/đánh giá chất lượng mã nguồn → CodeGuru; theo dõi và kiểm tra tuân thủ cấu hình tài nguyên → AWS Config.
• Cảnh giác với bẫy đặt tên: "Config" nghe như cấu hình hạ tầng nhưng thực chất là compliance, còn CodeCommit/CodeGuru có chữ "Code" nhưng không hề dựng hạ tầng.

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

Đề hỏi: tính năng nào của AWS được dùng để khởi chạy một EC2 instance đã được cấu hình sẵn (pre-configured)?

Cụm từ quyết định là "pre-configured" đi kèm với "launch". Hai chữ này phải đọc cùng nhau:

• "launch" giới hạn phạm vi vào thứ tham gia trực tiếp vào thao tác tạo instance mới, chứ không phải thứ đi kèm hay quản lý instance sau khi nó đã chạy.
• "pre-configured" nghĩa là hệ điều hành, phần mềm và thiết lập đã nằm sẵn trong một khuôn mẫu trước khi bấm nút — không phải cấu hình sau đó bằng script hay công cụ quản trị.

Một tính năng vừa là điều kiện bắt buộc để launch, vừa mang sẵn cấu hình, chỉ có một: template khởi chạy dạng ảnh máy. Các phương án còn lại đều liên quan tới EC2 ở một mức nào đó, nên nếu bỏ qua ràng buộc kép này thì rất dễ chọn nhầm sang công cụ quản trị hoặc lưu trữ.

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

A. Amazon Machine Image (AMI) là đáp án đúng.

AMI cung cấp toàn bộ thông tin cần thiết để khởi chạy một instance: hệ điều hành, phần mềm cài sẵn, và thiết lập đi kèm. Khi launch một EC2 instance, bạn bắt buộc phải chỉ định một AMI — đây không phải lựa chọn tuỳ chọn mà là thành phần không thể thiếu của thao tác launch.

Đúng với chữ "pre-configured": từ một AMI duy nhất bạn khởi chạy được nhiều instance có cấu hình giống hệt nhau, và muốn instance có cấu hình khác thì dùng AMI khác. Đây chính là cơ chế "cấu hình sẵn rồi nhân bản" mà đề đang mô tả.

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

B. Amazon Elastic Block Store (EBS) — Đây là dịch vụ lưu trữ dạng block gắn vào EC2 instance. EBS không phải là thứ bạn chọn để launch instance; nó là ổ đĩa mà instance dùng. Phương án này gần đúng ở chỗ nó có liên quan chặt tới quá trình khởi chạy (AMI thường được sao lưu vào snapshot EBS, và root volume của instance thường nằm trên EBS), nhưng vai trò của nó là chứa dữ liệu, không phải định nghĩa cấu hình để nhân bản instance. Chọn B là nhầm giữa "nơi chứa dữ liệu" và "khuôn mẫu khởi chạy".

C. Amazon EC2 Systems Manager — Đây là phương án gây nhiễu nặng nhất, vì Systems Manager thực sự có khả năng cấu hình máy. Nhưng nó cho bạn khả năng nhìn thấy và điều khiển hạ tầng trên AWS — tức là quản trị các instance đã tồn tại: chạy lệnh, quản lý bản vá, giữ tham số cấu hình. Nó hoạt động sau thời điểm launch, chứ không phải là tính năng dùng để launch ra một instance đã cấu hình sẵn. Đề hỏi thời điểm khởi chạy, nên C lệch pha về mặt vòng đời.

D. Amazon AppStream 2.0 — Đây là dịch vụ được quản lý hoàn toàn dùng để streaming ứng dụng và desktop dạng non-persistent tới người dùng cuối. Nó phục vụ mục tiêu hoàn toàn khác: đưa giao diện ứng dụng qua trình duyệt, chứ không phải cung cấp khuôn mẫu để tạo EC2 instance. Đây là phương án dễ loại nhất vì nó thậm chí không nằm trong luồng làm việc với EC2 instance.

📌 Điểm cần nhớ

• AMI là bắt buộc khi launch EC2 — không có AMI thì không có instance. Câu nào hỏi "thứ cần thiết / khuôn mẫu để khởi chạy instance" thì AMI gần như luôn là đáp án.
• Phân biệt theo thời điểm trong vòng đời: AMI hoạt động lúc launch; Systems Manager hoạt động sau launch để quản trị máy đang chạy. Đề dùng động từ "launch" là tín hiệu chọn vế đầu.
• Phân biệt theo vai trò: EBS là lưu trữ gắn vào instance, AMI là định nghĩa cấu hình của instance. Cả hai đều liên quan tới đĩa nhưng trả lời hai câu hỏi khác nhau.
• Một AMI → nhiều instance giống hệt nhau; cần cấu hình khác thì đổi AMI. Đây là nguyên lý chuẩn hoá cấu hình cần nhớ cho các câu về nhân bản hoặc mở rộng quy mô EC2.
• AppStream 2.0 phục vụ streaming ứng dụng/desktop tới người dùng, không liên quan tới việc tạo EC2 instance — thấy nó trong câu hỏi về EC2 thì thường là mồi nhử.

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

Đề mô tả một tình huống rất hẹp: cần cho một IAM user cụ thể quyền truy cập vào một Amazon S3 bucket, và việc phân quyền này được làm bằng bucket policy. Câu hỏi không hỏi "cấp quyền gì", cũng không hỏi "cấp trên tài nguyên nào", mà hỏi: phần tử (element) nào trong bucket policy dùng để chỉ ra tài khoản người dùng được cấp quyền.

Cụm từ quyết định là "define the user account for which access will be granted" — tức là xác định ai (danh tính được cấp quyền), chứ không phải làm được gì, trên cái gì, hay trong điều kiện nào. Một điểm phụ nhưng quan trọng: đây là bucket policy, tức là resource-based policy. Chính vì policy gắn vào tài nguyên chứ không gắn vào identity, nên nó bắt buộc phải tự khai danh tính người được phép — và phần tử làm việc đó là Principal.

Cả bốn phương án đều là tên phần tử hợp lệ trong một IAM policy JSON, nên mẹo ở đây là ánh xạ đúng từng phần tử với câu hỏi mà nó trả lời.

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

D — Principal là đáp án đúng.

Phần tử Principal chỉ định user, account, service hoặc thực thể khác được cho phép hoặc bị từ chối truy cập tài nguyên. Đây đúng là chỗ khai "tài khoản người dùng nào được cấp quyền" mà đề hỏi.

Trong nhiều bucket policy mẫu, Principal được đặt là * — ký tự đại diện nghĩa là bất kỳ ai. Muốn thu hẹp về đúng một IAM user, ta ghi ARN của user đó:

"Principal": { "AWS": "arn:aws:iam::AWSACCOUNTNUMBER:user/username" }

Đây là dạng viết chuẩn cho tình huống trong đề: một IAM user xác định, được nêu tên ngay trong policy gắn trên bucket.

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

• A — Action: Action liệt kê các quyền/thao tác mà policy cho phép hoặc chặn, ví dụ các thao tác đọc/ghi object trên S3. Nó trả lời câu hỏi "được làm gì", không nói gì về danh tính người gọi. Đây là phương án gây nhiễu mạnh với ai đọc lướt đề và chỉ bắt được chữ "access will be granted" — nhưng đề hỏi rõ là user account, không phải quyền.

• B — Resource: Resource chứa ARN của các tài nguyên mà policy áp dụng lên (ở đây là bucket và/hoặc các object bên trong). Nó trả lời "áp lên cái gì". Phương án này dễ nhầm vì cũng là một chuỗi ARN giống hệt về hình thức với ARN của IAM user trong Principal — nhưng ARN trong Resource trỏ tới tài nguyên S3, còn ARN trong Principal trỏ tới danh tính. Cùng định dạng, khác vai trò hoàn toàn.

• C — Condition: Condition đặt các điều kiện bổ sung phải thoả thì việc cấp quyền mới có hiệu lực, chẳng hạn ràng buộc theo địa chỉ IP nguồn của bên gọi. Đây là phương án gần đúng theo nghĩa "nó cũng thu hẹp được ai truy cập được", và trên thực tế người ta có thể dùng điều kiện để lọc thêm. Nhưng nó lọc theo ngữ cảnh của request, chứ không phải nơi khai báo danh tính chủ thể; bỏ Principal đi mà chỉ có Condition thì bucket policy không xác định được ai là đối tượng của câu lệnh. Condition là lớp lọc thêm, không phải lớp định danh chính.

📌 Điểm cần nhớ

• Ánh xạ nhanh bốn phần tử của policy theo bốn câu hỏi: Principal = ai, Action = làm gì, Resource = trên cái gì, Condition = khi nào / với ràng buộc nào. Đề hỏi câu nào thì chọn phần tử tương ứng.
• Resource-based policy (như S3 bucket policy) có Principal, vì policy nằm trên tài nguyên nên phải tự nêu tên người được phép. Identity-based policy gắn thẳng vào user/role thì không cần phần tử này — thấy đề nhắc "bucket policy" là dấu hiệu mạnh để nghĩ tới Principal.
• Cấp quyền cho một IAM user cụ thể thì viết ARN dạng arn:aws:iam::<account-id>:user/<username> trong Principal; để * nghĩa là mở cho bất kỳ ai — cần rất thận trọng với S3.
• ARN xuất hiện ở cả Principal lẫn Resource, đừng dựa vào hình thức chuỗi mà phân biệt: đọc xem ARN đó trỏ tới danh tính hay tới tài nguyên.

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

Đề nêu một tình huống rất cụ thể: công ty triển khai workload mới, và yêu cầu bản quyền phần mềm (software licensing requirements) buộc workload phải chạy trên một máy chủ vật lý xác định — "must be run on a specific, physical server". Câu hỏi là chọn EC2 instance deployment option nào.

Cụm từ quyết định đáp án là "specific, physical server", đi kèm bối cảnh licensing. Hai chữ này tách bạch hai nhóm phương án hoàn toàn khác nhau:

• Nhóm nói về tính cô lập phần cứng / vị trí đặt máy (tenancy): Dedicated Instances và Dedicated Hosts.
• Nhóm nói về cách mua và trả tiền cho dung lượng (pricing/purchase option): Spot Instances và Reserved Instances.

Nếu đề chỉ nói "phần cứng riêng, không dùng chung với khách khác" thì Dedicated Instances đã đủ. Nhưng chữ "specific" — một máy chủ vật lý cụ thể, nhìn thấy được, gắn được license vào — mới là ràng buộc đẩy đáp án về đúng một lựa chọn.

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

B — Dedicated Hosts.

Một Amazon EC2 Dedicated Host là một máy chủ vật lý được cấp riêng hoàn toàn cho tài khoản của bạn. Điểm mấu chốt: bạn nhìn thấy và điều khiển được chính cái server vật lý đó — bạn biết instance của mình nằm trên host nào, và có thể đặt instance lên đúng host đó một cách chủ định. Nhờ vậy Dedicated Hosts đáp ứng được các yêu cầu tuân thủ của doanh nghiệp gắn với phần cứng.

Đây cũng chính là lý do Dedicated Hosts là lựa chọn chuẩn cho bài toán BYOL (mang license sẵn có sang AWS) với phần mềm của các nhà cung cấp như Microsoft hay Oracle. Những license kiểu này thường tính theo phần cứng vật lý, nên bên cấp license đòi bạn chứng minh phần mềm chạy trên một máy chủ vật lý xác định. Dedicated Hosts cho bạn đúng sự hiển thị đó, trong khi vẫn giữ được tính đàn hồi và đơn giản của việc chạy trên AWS.

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

A — Dedicated Instances. Đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi. Dedicated Instances cũng chạy trên phần cứng dành riêng cho một khách hàng, không dùng chung với tài khoản AWS khác — nên nghe qua rất khớp với chữ "dedicated". Chỗ nó hỏng: bạn không được cấp một máy chủ vật lý cụ thể nào cả. Bạn không thấy host, không chọn được host, và instance có thể nằm trên máy vật lý khác sau khi stop/start. Đề đòi "specific, physical server" — mức cô lập thì có, mức xác định máy nào thì không, nên không dùng để thoả yêu cầu licensing gắn với phần cứng được.

C — Spot Instances. Đây là một purchase option, không phải mô hình tenancy. Nó cho phép tận dụng dung lượng EC2 dư với giá thấp hơn, đổi lại instance có thể bị AWS thu hồi khi cần dung lượng. Nó không hề nói gì tới việc bạn chạy trên máy vật lý nào — hoàn toàn không cung cấp một physical server xác định. Ngoài ra, bản chất có thể bị ngắt giữa chừng cũng ngược hẳn với một workload bị ràng buộc license nghiêm ngặt.

D — Reserved Instances. Cũng là một purchase option: bạn cam kết dùng trong một kỳ hạn để đổi lấy mức giá thấp hơn so với On-Demand. Đây thuần tuý là chuyện tiết kiệm chi phí và cam kết chi tiêu — nó không cấp cho bạn một máy chủ vật lý cụ thể, và cũng không giải quyết yêu cầu BYOL gắn với phần cứng. Chọn D là nhầm "đặt trước / cam kết" với "được cấp riêng phần cứng".

📌 Điểm cần nhớ

• Thấy từ khoá "software licensing" đi cùng "specific physical server" trong đề EC2 → gần như luôn là Dedicated Hosts. Đây là mẫu câu lặp lại rất nhiều trong kỳ thi Cloud Practitioner.
• Phân biệt cho chắc: Dedicated Instances = phần cứng không dùng chung với khách khác, nhưng không xác định host nào; Dedicated Hosts = một máy chủ vật lý cụ thể mà bạn nhìn thấy và kiểm soát được. Chữ specific / visibility / BYOL là dấu hiệu chọn Hosts.
• Đừng lẫn tenancy (Dedicated Instances, Dedicated Hosts — trả lời "chạy trên phần cứng nào") với purchase option (Spot, Reserved — trả lời "trả tiền theo cách nào"). Câu hỏi hỏi về vị trí đặt workload thì Spot và Reserved bị loại ngay từ đầu mà không cần đọc kỹ.
• Spot còn có thêm đặc điểm bị thu hồi khi AWS cần dung lượng, nên nó không bao giờ là đáp án cho các yêu cầu về tuân thủ hay tính ổn định của workload.

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

Đề mô tả một công ty cần publish messages to thousands of subscribers simultaneously using a push mechanism — gửi thông điệp tới hàng nghìn người nhận cùng lúc bằng cơ chế đẩy.

Ba cụm từ trong đề quyết định đáp án, và cần đọc cả ba cùng nhau:

• "publish … to subscribers" — đây là từ vựng của mô hình publisher/subscriber (pub/sub). Chỉ cần thấy cặp từ này là đã loại được nhóm dịch vụ điều phối quy trình.
• "thousands of subscribers simultaneously" — một thông điệp phải tới nhiều người nhận cùng lúc, tức fan-out một–nhiều, chứ không phải một thông điệp cho một consumer xử lý.
• "push mechanism" — hệ thống đẩy thông điệp ra, người nhận không phải hỏi lấy. Đây chính là ràng buộc tách Amazon SNS khỏi Amazon SQS, vì hai dịch vụ này hay bị đặt cạnh nhau trong đề thi.

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

Đáp án đúng theo tệp là B — Amazon Simple Notification Service (Amazon SNS).

Amazon SNS là dịch vụ thông báo theo mô hình publisher/subscriber. Bên gửi publish một thông điệp vào một topic, và SNS đẩy bản sao của thông điệp đó tới toàn bộ subscriber đã đăng ký topic, đồng thời chứ không tuần tự. Đúng cả ba ràng buộc trong đề: pub/sub, fan-out tới nhiều người nhận cùng lúc, và cơ chế push.

SNS còn gửi trực tiếp tới người dùng cuối qua nhiều kênh: SMS (phủ rất nhiều quốc gia), mobile push trên nền tảng Apple, Android và các nền tảng khác, cùng email (SMTP). Đó là lý do nó khớp với ngữ cảnh "thousands of subscribers" của đề — subscriber ở đây có thể là người dùng thật, không chỉ là hệ thống khác.

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

A — Amazon Simple Workflow Service (SWF). SWF là dịch vụ điều phối luồng công việc (workflow orchestration): nó theo dõi trạng thái các bước, giao việc cho worker và bảo đảm mỗi bước chạy đúng thứ tự. Nó không phải dịch vụ messaging pub/sub, không có khái niệm topic để hàng nghìn subscriber đăng ký nhận cùng một thông điệp. Cái tên bắt đầu bằng "Simple" khiến nó dễ bị nhầm với SNS/SQS, nhưng đó là điểm giống duy nhất.

C — Amazon Simple Queue Service (Amazon SQS). Đây là phương án gần đúng nhất và cũng là bẫy chính của câu. SQS đúng là dịch vụ messaging, nhưng nó là hàng đợi dùng để decouple các thành phần ứng dụng, hỏng ở hai điểm so với yêu cầu của đề:

• Nó là pull, không phải push — consumer phải chủ động gọi lấy thông điệp về, ngược hẳn với "push mechanism" mà đề nêu.
• Nó là mô hình một thông điệp cho một consumer xử lý, không phải fan-out một–nhiều tới hàng nghìn subscriber đồng thời như đề yêu cầu.

Chỉ cần thiếu cụm "push mechanism" trong đề thì câu này đã mơ hồ hơn nhiều; chính cụm đó đóng cửa phương án C.

D — AWS Step Functions. Cũng là dịch vụ điều phối luồng công việc theo hướng serverless cho ứng dụng hiện đại: bạn định nghĩa các bước dạng state machine và Step Functions chạy chúng theo thứ tự, xử lý rẽ nhánh, chờ, thử lại. Đây là công cụ dàn dựng quy trình, không phải công cụ phát tán thông điệp. Nó không đẩy một thông điệp tới hàng nghìn người đăng ký.

📌 Điểm cần nhớ

• "Publish / subscribe / topic / push / fan-out" → Amazon SNS. Bốn từ khóa này gần như luôn trỏ về SNS trong đề thi Cloud Practitioner.
• "Queue / decouple / consumer lấy về xử lý / pull" → Amazon SQS. Phân biệt SNS với SQS bằng hai trục: push hay pull, và một–nhiều hay một–một.
• SWF và Step Functions là orchestration, không phải messaging. Thấy đề nói về thứ tự các bước, trạng thái, quy trình nghiệp vụ mới cân nhắc chúng; thấy đề nói về gửi thông điệp thì loại ngay.
• Chữ "Simple" trong tên (SNS, SQS, SWF) không nói lên chức năng — đừng dùng độ giống nhau của tên để suy đoán, hãy bám vào động từ mà đề dùng (publish, queue, orchestrate).

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

Đề hỏi: khách hàng AWS có thể dùng cái gì để launch (khởi tạo) một ElastiCache cluster mới? Chọn HAI phương án.

Cụm từ quyết định là "can an AWS customer use to launch" — tức là công cụ đó phải là giao diện/cơ chế mà chính khách hàng dùng để tạo tài nguyên. Hai chữ đáng chú ý:

• "customer use": loại ngay những thứ không phải công cụ tự phục vụ, ví dụ một đội hỗ trợ của AWS.
• "launch": phải là hành động tạo mới tài nguyên, không phải quản lý, cấu hình hay di chuyển dữ liệu cho tài nguyên đã có.

Đây là câu kiểm tra hiểu biết cơ bản về các lối vào AWS (Management Console, CLI/SDK, Infrastructure as Code) chứ không kiểm tra kiến thức sâu về bản thân ElastiCache. Tên "ElastiCache" ở đây gần như có thể thay bằng bất kỳ dịch vụ nào khác mà đáp án vẫn thế.

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

Đáp án đúng theo tệp là A và B.

A. AWS Management Console — Console là giao diện web chính thức để khách hàng thao tác với AWS. Người dùng đăng nhập, vào trang ElastiCache, bấm tạo cluster, chọn engine và cấu hình. Đây là cách tạo tài nguyên trực tiếp và thủ công nhất, và luôn là một câu trả lời hợp lệ cho câu hỏi dạng "làm sao để tạo X".

B. AWS CloudFormation — CloudFormation là dịch vụ Infrastructure as Code của AWS: bạn mô tả trạng thái hạ tầng mong muốn trong một template viết bằng JSON hoặc YAML, CloudFormation đọc template đó và tạo ra một Stack gồm các tài nguyên tương ứng. ElastiCache cluster là một trong các loại tài nguyên khai báo được trong template, nên CloudFormation launch được cluster mới — theo cách tự động hoá, lặp lại được.

Giải thích gốc nói rõ có nhiều lối để launch tài nguyên trên AWS: Management Console, Command Line Interface (CLI), hoặc tự động hoá bằng công cụ như CloudFormation. Trong danh sách phương án chỉ có hai trong số đó xuất hiện, và đó chính là A và B.

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

C. AWS Concierge — Concierge Support Team là đội hỗ trợ dành cho khách hàng có gói Enterprise Support. Họ tư vấn về billing, tài khoản, tối ưu chi phí. Đây không phải một công cụ kỹ thuật và họ không đứng ra tạo tài nguyên thay bạn. Phương án này sai ngay ở tầng khái niệm: nó là một dịch vụ hỗ trợ con người, không phải một cách để launch cluster.

D. AWS Systems Manager — Đây là phương án gây nhầm nhất, vì tên nghe rất giống "công cụ quản lý mọi thứ" và nó thật sự có nhiều tính năng vận hành. Nhưng Systems Manager tập trung vào quản lý và vận hành các tài nguyên đã tồn tại: chạy lệnh từ xa, quản lý patch, lưu tham số cấu hình (Parameter Store), theo dõi trạng thái. Nó không phải công cụ khai báo hạ tầng để dựng một ElastiCache cluster mới. Chỗ hỏng của nó nằm đúng ở chữ "launch" trong đề: Systems Manager quản lý, không khởi tạo cluster.

E. AWS Data Pipeline — Data Pipeline là dịch vụ giúp xử lý và di chuyển dữ liệu giữa các dịch vụ compute và storage khác nhau của AWS theo lịch. Nó thao tác trên dữ liệu, không thao tác trên hạ tầng. Có thể nó xuất hiện trong danh sách vì chữ "Pipeline" khiến người ta liên tưởng tới tự động hoá triển khai — nhưng tự động hoá ở đây là tự động hoá luồng dữ liệu, không phải tự động hoá việc dựng tài nguyên.

📌 Điểm cần nhớ

• Có nhiều lối vào để tạo tài nguyên AWS: Management Console (web, thủ công), CLI/SDK (dòng lệnh, script), và CloudFormation (Infrastructure as Code bằng template JSON/YAML). Câu hỏi kiểu "cách nào để launch X" gần như luôn nằm trong nhóm này, bất kể X là dịch vụ gì.
• CloudFormation dựng hạ tầng, Data Pipeline chuyển dữ liệu, Systems Manager vận hành tài nguyên đã có. Ba dịch vụ này hay bị xếp cạnh nhau trong cùng một câu để đánh vào chỗ nhầm lẫn giữa tạo ra và quản lý/xử lý.
• AWS Concierge là con người, không phải công cụ. Nó gắn với gói Enterprise Support và làm việc quanh tài khoản, billing — thấy nó trong một câu hỏi kỹ thuật về khởi tạo tài nguyên thì gần như chắc chắn là mồi nhử.
• Khi đề dùng động từ cụ thể như launch / create / provision, hãy soi từng phương án đúng theo động từ đó thay vì theo cảm giác "dịch vụ này nghe có vẻ liên quan".

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

Đề bài rất ngắn: "An Amazon Virtual Private Cloud (VPC) can include multiple: ___" — một VPC có thể chứa nhiều cái gì?

Cụm từ quyết định đáp án là "can include multiple" — gồm hai ý nhỏ phải thoả đồng thời:

• "include": thứ được hỏi phải nằm bên trong phạm vi của VPC, tức là VPC là cái bao ngoài, thứ kia là cái nằm trong. Cái gì lớn hơn VPC hoặc nằm ngoài ranh giới VPC thì loại ngay.
• "multiple": phải là nhiều hơn một. Thứ nào VPC chỉ có được đúng một cũng bị loại, dù nó đúng là thuộc về VPC.

Đây chính là cái bẫy: bốn phương án đều là khái niệm networking gắn với VPC, nhưng mỗi cái hỏng ở một trong hai vế trên. Muốn trả lời đúng phải nhớ đúng thứ tự bao hàm của hạ tầng AWS: Region chứa các Availability Zone; VPC được tạo trong một Region và trải trên các AZ của Region đó; subnet nằm gọn trong một AZ.

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

B — Availability Zones. Một VPC được tạo trong phạm vi một Region, và nó trải rộng trên các Availability Zone của Region đó. Bên trong VPC, bạn tạo subnet, mỗi subnet nằm trong đúng một AZ; bạn có thể tạo subnet ở nhiều AZ khác nhau và phân bố tài nguyên (EC2 instance, database…) ra các subnet đó.

Đây chính là cách AWS làm high availability: nếu một AZ gặp sự cố, tài nguyên ở AZ còn lại trong cùng VPC vẫn chạy, và chúng vẫn nói chuyện với nhau qua mạng riêng của VPC mà không cần đi ra Internet. Nói cách khác, "nhiều AZ" thoả cả hai vế: AZ nằm trong Region mà VPC đang ở, và VPC dùng được nhiều AZ cùng lúc.

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

A — Edge locations. Đây là phương án gây nhiễu về mặt "nghe cũng là hạ tầng mạng". Edge location là hạ tầng phục vụ CloudFront/CDN, nằm độc lập với Region mà VPC được tạo ra. Nó không phải là thành phần bên trong VPC, VPC không "chứa" edge location theo bất kỳ nghĩa nào, và bạn cũng không tạo subnet trong edge location. Sai ở vế "include".

C — AWS Regions. Đây là phương án gần đúng nhất và cũng dễ chọn nhầm nhất, vì nó đảo ngược đúng quan hệ bao hàm. Sự thật là Region chứa VPC, chứ không phải VPC chứa Region. Một VPC bị giới hạn trong đúng một Region — nó không thể trải qua nhiều Region. Muốn có mạng riêng ở Region khác thì phải tạo một VPC khác ở Region đó rồi kết nối hai VPC lại (peering), chứ không phải "mở rộng" VPC cũ. Sai ở cả hai vế: nhầm chiều bao hàm, và không được nhiều Region.

D — Internet gateways. Đây là phương án gần đúng theo kiểu khác: internet gateway đúng là thứ gắn với VPC, đúng là thành phần của VPC — nên vế "include" thì nó qua được. Nó hỏng ở vế "multiple": mỗi VPC chỉ gắn được một internet gateway, và một internet gateway cũng chỉ gắn được cho một VPC tại một thời điểm. Vì là quan hệ một–một, "multiple internet gateways" trong cùng một VPC là điều không diễn ra được. Chọn D là bằng chứng điển hình của việc đọc đúng chữ "include" mà bỏ qua chữ "multiple".

📌 Điểm cần nhớ

• Thuộc lòng thứ tự bao hàm: Region → Availability Zone → subnet, và VPC nằm trong một Region, trải trên nhiều AZ của Region đó. Rất nhiều câu Cloud Practitioner chỉ kiểm tra đúng cây phân cấp này dưới nhiều cách hỏi khác nhau.
• VPC không vượt qua ranh giới Region. Bất kỳ phương án nào ngụ ý một VPC trải nhiều Region đều sai.
• Edge location không thuộc VPC — nó là hạ tầng phân phối nội dung, độc lập với Region và không nằm trong mạng riêng của bạn.
• Internet gateway là quan hệ một–một với VPC: một VPC gắn một internet gateway. Với dạng câu "can include multiple", hãy tách câu hỏi thành hai điều kiện — có nằm trong không và có được nhiều không — rồi loại phương án theo từng điều kiện; phương án gây nhiễu thường chỉ thoả đúng một vế.

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

Đề nêu một nhu cầu rất cụ thể: người dùng cần xác định (identify) những EC2 instance đang bị dùng dưới mức (underutilized) để cắt giảm chi phí.

Cụm từ quyết định đáp án là "identify underutilized Amazon EC2 instances" — chứ không phải "xem chi phí" hay "phân tích chi tiêu". Hai vế này nghe na ná nhau vì đều nằm dưới mục tiêu "reduce costs", nhưng chúng đòi hai loại dữ liệu khác hẳn:

• Underutilized là câu chuyện về mức sử dụng tài nguyên — CPU chạy bao nhiêu phần trăm, network I/O bao nhiêu, trong bao nhiêu ngày.
• Cost là câu chuyện về số tiền đã tiêu — instance nào, dịch vụ nào, tài khoản nào, tốn bao nhiêu đô.

Một instance có hoá đơn rất cao vẫn có thể đang chạy hết công suất (không hề underutilized), và ngược lại một instance nhỏ xíu gần như ngồi không cũng chỉ tốn vài đồng. Vì vậy phương án phải là dịch vụ nhìn vào utilization metrics và đưa ra khuyến nghị, không phải dịch vụ chỉ bóc tách hoá đơn. Đây chính là ràng buộc tách C khỏi D.

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

Đáp án đúng theo tệp là C — AWS Trusted Advisor.

Trusted Advisor là dịch vụ kiểm tra môi trường AWS của bạn dựa trên một tập các best practice checks, trải trên năm nhóm: cost optimization, security, fault tolerance, performance, và service limits. Nó không chỉ hiển thị dữ liệu thô mà đưa ra khuyến nghị hành động.

Đúng vào nhu cầu của đề, Trusted Advisor có sẵn check mang tên "Low Utilization Amazon EC2 Instances" trong nhóm cost optimization. Check này xem xét các EC2 instance đã chạy trong khoảng thời gian gần đây và cảnh báo khi mức sử dụng CPU hằng ngày rất thấp cùng với lưu lượng network I/O rất nhỏ, kéo dài qua nhiều ngày — nghĩa là instance đó gần như ngồi không nhưng vẫn bị tính tiền. Đó chính xác là định nghĩa "underutilized" mà đề đang hỏi, và là gợi ý trực tiếp để người dùng dừng hoặc hạ cỡ (rightsize) instance nhằm giảm chi phí.

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

A — AWS Health Dashboard. Đây là nơi theo dõi tình trạng sức khoẻ của dịch vụ và của tài nguyên bạn đang dùng: sự cố dịch vụ AWS, các sự kiện đã lên lịch ảnh hưởng tới tài nguyên của bạn, thông báo bảo trì. Nó trả lời câu hỏi "có gì đang hỏng / sắp ảnh hưởng tới tôi không", chứ không đánh giá mức sử dụng tài nguyên và không bao giờ cảnh báo rằng một instance đang chạy quá nhàn rỗi. Sai chủ đề hoàn toàn.

B — AWS CodeBuild. Đây là dịch vụ build: biên dịch mã nguồn, chạy test, tạo artifact để triển khai. Nó thuộc nhóm developer tools trong đường ống CI/CD, không liên quan gì tới quản lý chi phí hay giám sát mức sử dụng EC2. Đây là phương án gây nhiễu dễ loại nhất.

D — AWS Cost Explorer. Đây là phương án gần đúng nhất và là bẫy thật sự của câu này, vì nó đúng là công cụ quản lý chi phí, đúng là dùng để giảm tiền, và tên nó có chữ "Cost" khớp với vế "reduce costs" trong đề. Nhưng nó hỏng ở chỗ: Cost Explorer trực quan hoá và bóc tách chi tiêu — theo dịch vụ, theo thời gian, theo tag, theo tài khoản — cùng với dự báo chi phí. Cái nó đưa cho bạn là con số tiền, không phải chỉ số utilization của từng instance. Nhìn vào Cost Explorer bạn biết EC2 tháng này tốn bao nhiêu, nhưng không biết instance nào đang chạy CPU 3% suốt hai tuần. Mà đề hỏi đúng vế sau. Đề dùng động từ "identify underutilized", không phải "phân tích chi phí" — nên D bị loại vì sai loại dữ liệu, dù đúng lĩnh vực.

📌 Điểm cần nhớ

• Tách bạch hai câu hỏi trong đề thi: "tài nguyên nào đang bị lãng phí / dùng dưới mức" → Trusted Advisor; "tiền đã tiêu vào đâu, xu hướng ra sao, dự báo thế nào" → Cost Explorer. Cả hai đều phục vụ mục tiêu tiết kiệm, nhưng chỉ một cái nhìn vào utilization.
• Trusted Advisor = khuyến nghị theo best practice, phủ năm nhóm: cost optimization, security, fault tolerance, performance, service limits. Thấy đề hỏi "recommendation", "best practice", "idle/low utilization", "service limits" thì nghĩ ngay tới nó.
• AWS Health Dashboard nói về sự cố và sự kiện dịch vụ, không nói về hiệu quả sử dụng hay chi phí. Đừng để chữ "Dashboard" đánh lừa thành công cụ giám sát tổng quát.
• Đọc kỹ động từ trong đề. Cùng một bối cảnh "giảm chi phí", nhưng "identify underutilized resources", "view itemized costs", "set a budget alert" và "estimate cost before deploying" dẫn tới bốn dịch vụ khác nhau. Động từ mới là thứ chọn đáp án, không phải cụm mục tiêu chung ở cuối câu.