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

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

Đề hỏi: dịch vụ AWS nào giám sát liên tục các tài khoản AWS để phát hiện hoạt động độc hại và hành vi trái phép.

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

• "monitors ... continuously" — dịch vụ phải chạy nền liên tục, không phải quét theo yêu cầu hay theo lịch do người dùng bấm.
• "malicious activity and unauthorized behavior" — đây là ngôn ngữ của threat detection (phát hiện mối đe doạ), tức là có kẻ đang tấn công hoặc đã chiếm được quyền. Nó khác hẳn với "đánh giá cấu hình" hay "tìm lỗ hổng".

Cả bốn phương án đều là dịch vụ thuộc nhóm Security, Identity & Compliance, và cả bốn đều "giám sát" theo nghĩa nào đó — nên chữ "continuously" một mình chưa đủ phân biệt. Thứ chốt hạ là đối tượng bị giám sát: hành vi của kẻ xấu (GuardDuty), dữ liệu nhạy cảm (Macie), lỗ hổng phần mềm (Inspector), hay cấu hình tài nguyên (AWS Config).

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

A — Amazon GuardDuty là dịch vụ threat detection của AWS. Nó liên tục theo dõi tài khoản và workload của bạn để phát hiện hoạt động độc hại, rồi phát ra các security findings chi tiết để bạn nhìn thấy và xử lý.

Điểm khớp chính xác với đề bài:

• GuardDuty hoạt động liên tục, không cần người dùng khởi động từng lượt quét.
• Nó nhắm vào hành vi: đăng nhập bất thường, gọi API lạ, dấu hiệu tài khoản bị chiếm quyền, liên lạc tới hạ tầng đáng ngờ — đúng nghĩa "malicious activity and unauthorized behavior".
• Phạm vi của nó là AWS account, đúng như đề nêu, chứ không bó vào một loại tài nguyên cụ thể.

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

B — Amazon Macie. Đây là phương án dễ nhầm nhất vì Macie cũng chạy liên tục và cũng phát ra findings. Nhưng việc của Macie là phát hiện dữ liệu nhạy cảm (PII) nằm trong S3 bucket — nó trả lời câu "dữ liệu nhạy cảm của tôi đang nằm ở đâu và có bị phơi ra không", chứ không phát hiện mối đe doạ. Macie chỉ ra rủi ro về dữ liệu, không chỉ ra kẻ tấn công.

C — Amazon Inspector. Cũng rất gần, vì Inspector là công cụ bảo mật được quản lý hoàn toàn. Chỗ nó hỏng: Inspector làm vulnerability assessment — tìm lỗ hổng đã biết trong phần mềm và cấu hình của workload. Lỗ hổng là điểm yếu có thể bị khai thác, còn đề hỏi về hành vi độc hại đang thực sự diễn ra. Đây là hai giai đoạn khác nhau: Inspector nói "cửa này chưa khoá", GuardDuty nói "có người đang mở cửa".

D — AWS Config. Config cho phép bạn đánh giá, kiểm toán và thẩm định cấu hình của tài nguyên AWS. Nó liên tục giám sát và ghi lại cấu hình, và tự động so cấu hình đã ghi với cấu hình mong muốn. Đúng là có chữ "liên tục", nhưng đối tượng là trạng thái cấu hình, không phải hành vi độc hại — Config báo "security group này bị mở ra 0.0.0.0/0", chứ không báo "có kẻ đang dùng lỗ hổng đó". Nó không phát hiện threat.

📌 Điểm cần nhớ

• "Threat detection" trong đề AWS gần như luôn ánh xạ thẳng sang GuardDuty. Thấy cụm "malicious activity", "unauthorized behavior", "compromised account" thì nghĩ tới GuardDuty trước.
• Phân biệt bốn dịch vụ theo đối tượng, không theo chữ "monitor": GuardDuty → hành vi/mối đe doạ; Macie → dữ liệu nhạy cảm trong S3; Inspector → lỗ hổng của workload; Config → cấu hình tài nguyên.
• "Lỗ hổng" ≠ "tấn công". Inspector tìm điểm yếu có thể bị khai thác; GuardDuty phát hiện việc khai thác đang xảy ra. Câu hỏi nào nhấn vào "đang diễn ra" thì chọn GuardDuty.
• Chữ "continuously" một mình không đủ để loại phương án, vì Macie và Config đều chạy liên tục. Luôn tìm thêm ràng buộc thứ hai trong đề để chốt.

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

Đề hỏi: dịch vụ nào dùng được cho asynchronous integration giữa các thành phần của ứng dụng, chọn HAI phương án.

Cụm từ quyết định là "asynchronous integration between application components". Nó gồm hai ràng buộc chồng lên nhau, phải thoả cả hai:

• Integration between application components — dịch vụ phải nằm trên đường đi của dữ liệu/lời gọi giữa các thành phần ứng dụng, tức là làm nhiệm vụ truyền yêu cầu hoặc điều phối luồng xử lý. Dịch vụ chỉ lo hạ tầng, lo mạng hay lo triển khai thì không tính.
• Asynchronous — bên gửi không phải đứng chờ bên nhận xử lý xong. Bên gửi đẩy yêu cầu đi, nhận về một xác nhận "đã ghi nhận", rồi làm việc khác; bên nhận xử lý sau, theo nhịp của nó.

Đây chính là hình thái loose coupling: hai thành phần không cần cùng sống, cùng tốc độ, hay cùng thời điểm. Mô hình này hợp với mọi tương tác không cần phản hồi ngay lập tức, chỉ cần biết yêu cầu đã được ghi nhận là đủ.

Bốn trong năm phương án đều là dịch vụ AWS phổ biến, nên cái bẫy ở đây là chọn theo "dịch vụ này có quen thuộc không" thay vì soi đúng hai ràng buộc trên.

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

A — Amazon SQS. SQS là một message bus có tính bền (durable). Thành phần gửi đặt message vào queue và nhận ngay xác nhận đã ghi nhận; thành phần nhận lấy message ra xử lý sau đó, hoàn toàn độc lập về thời điểm. Đây là dạng asynchronous integration kinh điển: bên gửi và bên nhận không bao giờ nói chuyện trực tiếp với nhau, chỉ nói chuyện qua queue.

C — Amazon Step Functions. Step Functions là dịch vụ orchestrated workflow — nó điều phối một chuỗi bước xử lý giữa các thành phần khác nhau. Luồng công việc chạy theo thời gian của nó chứ không buộc bên khởi động phải giữ kết nối chờ tới khi toàn bộ workflow kết thúc, nên nó cũng thuộc nhóm asynchronous integration giữa các thành phần ứng dụng.

Hai dịch vụ này đại diện cho hai kiểu asynchronous integration khác nhau nhưng đều hợp lệ: SQS là kiểu truyền message, Step Functions là kiểu điều phối luồng.

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

B — AWS Route 53. Đây là dịch vụ DNS, việc của nó là phân giải tên miền thành địa chỉ IP. Nó nằm ở tầng tra cứu địa chỉ, trước cả khi lời gọi giữa hai thành phần bắt đầu — và bản thân việc tra cứu DNS là đồng bộ, bên hỏi phải chờ câu trả lời mới đi tiếp. Route 53 không truyền dữ liệu nghiệp vụ, không lưu giữ yêu cầu hộ ai, nên không phải asynchronous integration.

D — Amazon EC2 Auto Scaling. Đây là phương án gần đúng nhất và cũng dễ nhầm nhất, vì Auto Scaling thường xuất hiện chung với SQS trong các kiến trúc loose coupling (queue dài ra thì scale thêm instance). Nhưng việc của Auto Scaling là horizontal scaling — tăng giảm số lượng EC2 instance. Nó điều chỉnh số lượng tài nguyên chạy, chứ không phải kênh mà hai thành phần trao đổi yêu cầu với nhau. Nó là hệ quả của kiến trúc bất đồng bộ, không phải cơ chế tạo ra tính bất đồng bộ. Đề hỏi "service used for asynchronous integration", tức là hỏi cái đóng vai trò tích hợp — Auto Scaling không đóng vai đó.

E — AWS CloudFormation. CloudFormation tự động hoá việc triển khai hạ tầng theo template. Nó chạy lúc dựng/cập nhật stack, không tham gia gì vào đường đi của request khi ứng dụng đang phục vụ. Có thể dùng CloudFormation để tạo ra một SQS queue, nhưng cái tích hợp bất đồng bộ là queue kia chứ không phải công cụ đã tạo ra nó.

📌 Điểm cần nhớ

• Asynchronous integration = loose coupling: bên gửi chỉ cần một xác nhận "đã ghi nhận" là đi tiếp, không cần phản hồi cuối cùng ngay lập tức.
• Phân loại dịch vụ theo vai trò trong kiến trúc, không theo mức độ quen thuộc: SQS/Step Functions là application integration; Auto Scaling là compute/scaling; CloudFormation là deployment/provisioning; Route 53 là networking/DNS. Câu hỏi kiểu này hầu như luôn giải được chỉ bằng bước phân loại đó.
• Cẩn thận với những dịch vụ hay đi kèm kiến trúc bất đồng bộ mà bản thân không bất đồng bộ — EC2 Auto Scaling là ví dụ điển hình, nó phản ứng theo độ dài queue chứ không phải là queue.
• Câu "Select TWO" mà có hai dịch vụ khác nhau về bản chất (message bus và workflow orchestration) vẫn có thể cùng đúng, miễn cả hai đều nằm trên đường trao đổi giữa các thành phần.

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

Đề hỏi: lợi ích của việc dùng fully managed service so với việc tự cài phần mềm bên thứ ba lên EC2 là gì.

Cụm từ quyết định nằm ở hai vế được đem ra so sánh: "fully managed services" và "deploying 3rd party software on EC2". Đây chính là hai đầu của thang trách nhiệm trong shared responsibility model:

• Với EC2, bạn tự lo hệ điều hành, bản vá, cài đặt phần mềm, cấu hình, nâng cấp, giám sát, mở rộng.
• Với fully managed service (đề nêu ví dụ Amazon Aurora, Amazon ElastiCache), AWS lo không chỉ lớp hạ tầng mà cả lớp dịch vụ nằm trên nó.

Đổi từ vế đầu sang vế sau nghĩa là bạn giao bớt việc vận hành cho AWS. Vậy lợi ích phải là thứ nói về khối lượng việc vận hành, chứ không phải về quyền điều khiển hay về việc bạn hết trách nhiệm với dữ liệu. Chỉ có một phương án nói đúng điều đó.

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

D. Reduced operational overhead — đúng.

Fully managed service làm giảm operational overhead vì AWS quản lý luôn cả lớp dịch vụ phía trên hạ tầng: cài đặt, vá lỗi, nâng cấp phiên bản, thay thế node hỏng, mở rộng. Với Aurora bạn không phải tự cài engine database lên EC2 rồi tự tune hệ điều hành cho nó; với ElastiCache bạn không phải tự dựng và duy trì cụm cache. Nhân sự của bạn được giải phóng khỏi những việc lặp lại đó để làm việc gần với sản phẩm hơn. Đây chính là điểm bán hàng cốt lõi của mọi managed service và là câu trả lời chuẩn cho dạng câu "managed vs. self-hosted on EC2".

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

A. You have greater control and flexibility — sai, và thực tế là ngược lại. Chính EC2 mới cho bạn nhiều quyền điều khiển hơn: bạn vào được hệ điều hành, chỉnh mọi tham số, cài phần mềm sao lưu hay phần mềm vận hành của riêng mình. Khi dùng fully managed service, AWS nhận nhiều trách nhiệm hơn nên bạn có ít lựa chọn hơn — chẳng hạn có những tham số hiệu năng của database bạn không chỉnh tới được. Đây là cái giá phải trả để đổi lấy đáp án D, và câu hỏi dạng này rất hay bẫy bằng cách đảo chiều đúng chỗ này.

B. Improved security — sai, đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. Vấn đề không phải AWS bảo mật kém — AWS làm rất tốt việc bảo vệ dịch vụ của họ, và có thể lập luận rằng khả năng để lộ lỗ hổng còn thấp hơn so với một khách hàng tự triển khai ứng dụng của mình. Nhưng "improved security" không phải là lợi ích được bảo đảm và cũng không phải điểm khác biệt định nghĩa giữa managed service và tự cài lên EC2. Bảo mật vẫn phụ thuộc vào cách bạn cấu hình, phân quyền và mở kết nối. Nói cách khác: B có thể xảy ra trong một số trường hợp, còn D thì luôn đúng theo định nghĩa của managed service. Trắc nghiệm chọn phương án đúng theo định nghĩa, không chọn phương án "có khi cũng đúng".

C. You don't need to back-up your data — sai, và sai theo kiểu nguy hiểm nhất vì nó nghe rất giống "AWS lo hết". Dùng managed service không miễn cho bạn trách nhiệm với dữ liệu. Ví dụ đề nêu: với Amazon ElastiCache, việc cấu hình sao lưu ra S3 vẫn là việc của bạn. Managed nghĩa là AWS lo phần vận hành hạ tầng và dịch vụ, không có nghĩa là chiến lược sao lưu — giữ bao lâu, khôi phục về mốc nào — tự nhiên biến mất khỏi phần trách nhiệm của khách hàng.

📌 Điểm cần nhớ

• Câu hỏi so managed service với tự cài lên EC2 thì đáp án gần như luôn xoay quanh reduced operational overhead — AWS gánh thêm lớp vận hành phía trên hạ tầng.
• Đánh đổi của managed service là mất bớt control và flexibility. Thấy phương án nói managed cho nhiều quyền điều khiển hơn thì loại ngay, vì nó đảo chiều sự thật.
• Managed không đồng nghĩa với "hết trách nhiệm": sao lưu, cấu hình, phân quyền dữ liệu vẫn thuộc phần của khách hàng trong shared responsibility model.
• Phân biệt "lợi ích theo định nghĩa" và "lợi ích có thể xảy ra": improved security thuộc nhóm sau, nên nó thua reduced operational overhead khi cả hai cùng có mặt trong danh sách.

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

Đề hỏi: dịch vụ AWS nào hướng dẫn (guides you through) việc chọn kích cỡ tài nguyên (sizing), cấu hình (configuration) và triển khai (deployment) ứng dụng trên AWS, và hỗ trợ các ứng dụng bên thứ ba như SQL Server Always On và SAP on AWS.

Cụm từ quyết định là "guides you through the sizing, configuration, and deployment" đi kèm với "applications like SQL Server always-on and SAP". Đây là hai ràng buộc chồng lên nhau:

1. Không chỉ là "triển khai được", mà phải là quy trình có hướng dẫn từng bước, trong đó dịch vụ tự đề xuất kích cỡ tài nguyên thay cho người dùng.
2. Đối tượng triển khai là phần mềm doanh nghiệp của bên thứ ba với kiến trúc tham chiếu định sẵn (SQL Server Always On, SAP), chứ không phải mã ứng dụng do người dùng tự viết.

Rất nhiều dịch vụ AWS "triển khai được ứng dụng", nên nếu chỉ đọc chữ deployment thì cả bốn phương án đều có vẻ hợp. Chính hai chữ guided và SQL Server Always On / SAP mới cắt danh sách xuống còn một.

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

A — AWS Launch Wizard. Đây đúng là dịch vụ được thiết kế cho đúng kịch bản trong đề: nó đưa ra một luồng hướng dẫn (guided experience), hỏi người dùng về yêu cầu của ứng dụng bên thứ ba, rồi tự đề xuất kích cỡ tài nguyên AWS phù hợp, sinh cấu hình và triển khai — thay vì bắt người vận hành tự tay xác định và cấp phát từng tài nguyên riêng lẻ. Launch Wizard hỗ trợ đúng các workload mà đề nêu tên: SQL Server Always On và SAP on AWS. Việc đề gọi thẳng tên hai ứng dụng này gần như là chữ ký nhận dạng của Launch Wizard trong đề thi.

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

B — AWS App Runner. Dịch vụ này tự động build và chạy ứng dụng container / web service từ mã nguồn hoặc image, rất nhanh và ít phải quản trị hạ tầng. Nhưng nó nhắm vào ứng dụng do chính bạn viết và đóng gói, không có luồng hướng dẫn chọn sizing cho phần mềm doanh nghiệp bên thứ ba, và hoàn toàn không phải nơi để dựng SQL Server Always On hay SAP.

C — AWS Elastic Beanstalk. Đây là phương án dễ nhầm nhất, vì Beanstalk đúng là lo phần cấp phát hạ tầng và triển khai giúp bạn. Chỗ nó hỏng: Beanstalk là dịch vụ điều phối triển khai cho ứng dụng web của chính bạn (Java, .NET, Node.js, Python…), bạn nộp mã nguồn và nó dựng môi trường chạy. Nó không cung cấp luồng hướng dẫn riêng cho các ứng dụng bên thứ ba như SQL Server Always On hay SAP — đó là những kiến trúc nhiều tầng, có yêu cầu về cụm và tính sẵn sàng riêng, nằm ngoài mô hình môi trường của Beanstalk.

D — AWS CloudFormation. Cũng gần đúng ở nghĩa "triển khai tài nguyên tự động". CloudFormation cho phép mô tả hạ tầng bằng tệp văn bản (template) hoặc bằng ngôn ngữ lập trình rồi cấp phát tài nguyên một cách tự động, lặp lại được. Nhưng nó là công cụ infrastructure as code, không phải trải nghiệm có hướng dẫn: chính bạn phải biết trước cần bao nhiêu instance, loại gì, cấu hình ra sao rồi viết vào template. Nó không tư vấn sizing và không có logic riêng cho SQL Server Always On hay SAP. Nói cách khác, CloudFormation là thứ thực thi việc tạo tài nguyên, còn phần "hướng dẫn và đề xuất" mà đề hỏi thì thiếu.

📌 Điểm cần nhớ

• Thấy đề nhắc SQL Server Always On hoặc SAP on AWS kèm chữ guided / sizing thì nghĩ ngay tới AWS Launch Wizard — đó là dịch vụ chuyên cho phần mềm doanh nghiệp bên thứ ba.
• Phân biệt theo ai quyết định kích cỡ tài nguyên: Launch Wizard đề xuất giúp bạn, còn CloudFormation đòi bạn khai sẵn mọi thứ trong template.
• Phân biệt theo loại ứng dụng: Elastic Beanstalk và App Runner phục vụ ứng dụng do bạn viết (mã nguồn / container), không phải phần mềm thương mại bên thứ ba.
• Trong câu hỏi kiểu "dịch vụ nào triển khai ứng dụng", đừng dừng ở chữ deploy — hãy tìm tính từ bổ nghĩa (guided, sizing, containerized, source code), vì đó mới là chỗ tách các phương án.

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

Đề hỏi: một tổ chức cần làm gì trong IAM để người dùng truy cập được các dịch vụ vừa được triển khai ở một region mới.

Cụm từ quyết định đáp án là "in Amazon IAM" kết hợp với "new region". Đề không hỏi về quyền (permission) nào cần cấp, cũng không hỏi về việc bật dịch vụ ở region đó — nó chỉ hỏi riêng phần IAM có phải làm thêm việc gì khi phạm vi hoạt động mở rộng sang region mới hay không.

Điểm mấu chốt cần nắm: IAM là dịch vụ global, không phải dịch vụ theo region. User, group, role và policy trong IAM tồn tại ở phạm vi tài khoản AWS, không gắn với bất kỳ region cụ thể nào. Vì thế câu trả lời nằm ở chỗ nhận ra rằng "region mới" không tạo ra công việc nào cho IAM cả — cả ba phương án còn lại đều dựng lên một thao tác không tồn tại, dựa trên giả định sai rằng IAM có ranh giới theo region.

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

A — "Nothing, IAM is global" là đáp án đúng.

IAM dùng để kiểm soát quyền truy cập của từng người dùng và từng nhóm tới tài nguyên AWS, và nó có phạm vi universal/global: identity đã tạo trong tài khoản là dùng được ở mọi region mà tài khoản đó hoạt động. Khi tổ chức bắt đầu triển khai dịch vụ ở một region mới, các user hiện có mang theo nguyên vẹn identity và các policy đã gắn — không cần tạo lại, không cần đồng bộ, không cần "mở khoá" region.

Nói cách khác, tính global của IAM chính là lý do khiến việc mở rộng sang region mới không phát sinh thao tác nào ở tầng identity. Đây là điều tài liệu AWS về IAM nêu rõ và cũng là ý mà phần giải thích tiếng Anh kèm theo câu hỏi khẳng định.

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

B — "Create new user accounts in the new region" Sai vì user của IAM không thuộc region nào. Không có khái niệm "user trong region us-east-1" hay "user trong region ap-southeast-1" để mà tạo mới. Đây là phương án dễ chọn nhất với người quen mô hình hạ tầng theo region (như EC2 instance hay VPC — những thứ thực sự phải tạo lại ở từng region), rồi áp nhầm mô hình đó sang identity. Tạo thêm user chỉ làm sinh ra bộ credential trùng lặp phải quản lý, chứ không giải quyết vấn đề nào cả.

C — "Enable global mode in IAM to provision the required access" Sai vì trong IAM không tồn tại thứ gọi là "global mode". Phương án này nghe hợp lý ở chỗ nó dùng đúng từ khoá "global" — mà "global" đúng là bản chất của IAM — nhưng nó biến một thuộc tính mặc định thành một công tắc phải bật. Đây là kiểu bẫy hay gặp: lấy đúng khái niệm rồi gói vào một thao tác cấu hình không có thật. IAM đã global sẵn, không có gì để bật.

D — "Update the user accounts to allow access from another region" Đây là phương án gần đúng nhất và cũng đáng nói kỹ nhất. Nó gần đúng ở chỗ: trong IAM có thật cơ chế giới hạn theo region bằng điều kiện aws:RequestedRegion trong policy. Nhưng phương án này hỏng ở chỗ nó mô tả việc cập nhật user như một bước bắt buộc mặc định khi có region mới. Thực tế thì mặc định IAM không chặn theo region, nên user không cần được "cho phép" thêm gì. Việc sửa policy chỉ cần thiết khi tổ chức đã chủ động đặt ràng buộc giới hạn region từ trước — đó là một tình huống đặc biệt, không phải điều đề bài mô tả. Đề chỉ nói "mở dịch vụ ở region mới", không nói gì tới ràng buộc sẵn có.

📌 Điểm cần nhớ

• IAM là dịch vụ global: user, group, role, policy có phạm vi toàn tài khoản, không nhân bản theo region. Câu hỏi nào hỏi "làm gì với IAM khi sang region mới" thì hướng trả lời gần như luôn là "không cần làm gì".
• Phân biệt dịch vụ global với dịch vụ theo region: IAM là global; phần lớn dịch vụ hạ tầng như EC2 hay VPC thì phải dựng riêng ở từng region. Nhầm lẫn hai nhóm này là nguồn sai phổ biến ở đề Cloud Practitioner.
• Cảnh giác với phương án mô tả một "chế độ" hay "công tắc" phải bật cho thứ vốn đã là hành vi mặc định (như "enable global mode"). Đề hay dùng đúng từ khoá của khái niệm để làm phương án nhiễu trông đáng tin.
• Việc giới hạn quyền theo region trong IAM là tuỳ chọn chủ động, không phải yêu cầu mặc định. Chỉ khi đề nói rõ tổ chức đang áp ràng buộc region thì mới cần nghĩ tới chuyện sửa policy.

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

Đề hỏi: "What are two components of Amazon S3?" — hai thành phần cấu tạo nên Amazon S3.

Cụm từ quyết định là "components of Amazon S3": câu này không hỏi S3 dùng để làm gì, cũng không hỏi so sánh với dịch vụ lưu trữ khác, mà hỏi đúng những thứ tạo nên mô hình dữ liệu của S3. Danh sách phương án cố tình trộn lẫn từ vựng của ba mô hình lưu trữ khác nhau:

• object storage — mô hình của S3
• block storage — mô hình của ổ đĩa khối
• file storage — mô hình của hệ thống tệp có cây thư mục

Ai nhận ra S3 là object-based storage, truy cập qua RESTful API trên HTTP(S), sẽ loại ngay ba phương án mang từ vựng của hai mô hình còn lại. Thêm dấu hiệu (Select TWO.) cho biết phải chọn đúng hai — cặp thuật ngữ đi liền nhau của mô hình object.

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

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

Amazon S3 là hệ thống lưu trữ dạng object và cấu trúc của nó chỉ gồm hai tầng khái niệm:

• Bucket là thùng chứa ở mức gốc — nơi bạn đặt tên, chọn Region và gắn cấu hình cho toàn bộ dữ liệu bên trong.
• Object là chính dữ liệu bạn tải lên: tệp tin, ảnh, video, bản sao lưu… mỗi object gồm phần nội dung, khoá định danh và metadata đi kèm.

Bạn tạo bucket trước, sau đó đưa object vào bucket đó. Đây đúng là mô tả "buckets, which are root level folders, and objects, which are the files, images etc. that you upload" trong phần giải thích gốc. Hai khái niệm này là bộ đôi tối thiểu để nói về S3 — không có bucket thì không có chỗ đặt object, và không có object thì bucket rỗng.

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

A. Block devices — thuộc từ vựng của block storage, nơi dung lượng được chia thành các khối và hệ điều hành nhìn thấy như một ổ đĩa thô để tự định dạng. S3 không hề trình bày dữ liệu ra dưới dạng ổ đĩa khối; bạn không "gắn" một bucket vào máy như gắn ổ đĩa rồi format nó. Đây là phương án dễ chọn nhầm nếu người học đang gộp chung mọi dịch vụ lưu trữ của AWS thành một khái niệm — nhưng "block device" mô tả một mô hình lưu trữ khác hẳn, không phải thành phần của S3.

B. Directories — đây là phương án gần đúng nhất và bẫy nhất. Giao diện console của S3 có hiển thị dạng "folder", và khoá của object thường chứa dấu gạch chéo trông y hệt đường dẫn thư mục. Nhưng đó chỉ là cách trình bày cho dễ nhìn: về bản chất, không gian tên của bucket là phẳng, dấu gạch chéo chỉ là ký tự nằm trong khoá object chứ không tạo ra một thực thể "directory" thật sự có cấu trúc cây như trong hệ thống tệp. Vì vậy directory không phải một component của S3 — nó là ảo giác về mặt hiển thị.

E. File systems — thuộc từ vựng của file storage, nơi dữ liệu được tổ chức theo cây thư mục có phân cấp và truy cập qua giao thức chia sẻ tệp, gắn (mount) vào máy chủ như một ổ đĩa mạng. S3 không được truy cập theo kiểu đó: bạn thao tác với nó qua RESTful API trên HTTP(S) bằng các lời gọi lên object. Nói S3 gồm "file systems" là gán nhầm mô hình lưu trữ.

Tóm lại: A thuộc mô hình block, B và E thuộc mô hình file — cả ba đều là thuật ngữ không áp dụng cho Amazon S3, đúng như phần giải thích gốc nêu rõ.

📌 Điểm cần nhớ

• Amazon S3 = object storage, và mô hình dữ liệu của nó chỉ có hai tầng: bucket (thùng chứa mức gốc) và object (dữ liệu bạn tải lên kèm metadata). Thấy câu hỏi về "components of S3" thì cặp này là câu trả lời.
• Không gian tên trong bucket là phẳng. "Folder" trên console chỉ là cách hiển thị dựa vào dấu gạch chéo trong khoá object; S3 không có directory thật.
• Khi các phương án trộn lẫn block device / file system / object, hãy xác định trước dịch vụ trong đề thuộc mô hình lưu trữ nào rồi loại thẳng từ vựng của hai mô hình còn lại — mẹo này giải được rất nhiều câu về lưu trữ.
• S3 được truy cập bằng RESTful API qua HTTP(S), không phải bằng cách mount hay format như ổ đĩa — đây là dấu hiệu phân biệt nhanh nhất với các phương án mang tính "ổ đĩa" hay "hệ thống tệp".

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

Đề hỏi: khi một Amazon EC2 instance bị stopped, dịch vụ AWS nào giúp xác định người dùng đã dừng nó.

Cụm từ quyết định là "identify the user who stopped it" — tức là truy ra danh tính người/principal đã thực hiện hành động, chứ không phải biết instance đang ở trạng thái nào, hay nó tiêu tốn bao nhiêu tài nguyên. Dừng một EC2 instance là một API call (StopInstances) gửi tới AWS. Vậy câu hỏi thực chất là: dịch vụ nào ghi nhật ký các API call trong tài khoản AWS cùng với danh tính người gọi.

Đây chính là ranh giới hay bị lẫn trong bài thi: audit ai làm gì (CloudTrail) khác với theo dõi tài nguyên chạy ra sao (CloudWatch), khác với quét lỗ hổng (Inspector), và khác với ghi lưu lượng mạng (VPC Flow Logs).

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

A – AWS CloudTrail là đáp án đúng.

CloudTrail ghi lại các API call thực hiện trong một tài khoản AWS. Mỗi bản ghi sự kiện chứa những thông tin cần thiết cho việc điều tra: API nào được gọi, địa chỉ IP nguồn, thời điểm, và quan trọng nhất là IAM principal nào khởi tạo hành động đó. Khi ai đó dừng một EC2 instance — dù qua Console, CLI hay SDK — thao tác này vẫn quy về một API call và được CloudTrail ghi nhận kèm danh tính người gọi.

Vì vậy, để trả lời câu "ai đã dừng instance này?", ta tra sự kiện tương ứng trong CloudTrail và đọc phần thông tin về identity của người gọi. Đây đúng là bài toán mà CloudTrail sinh ra để giải: governance, audit và điều tra hoạt động trong tài khoản.

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

B – Amazon Inspector. Đây là dịch vụ đánh giá lỗ hổng bảo mật được quản lý hoàn toàn: nó rà soát workload để tìm các lỗ hổng phần mềm đã biết và các vấn đề về mức độ phơi bày ngoài mạng. Kết quả nó trả về là danh sách finding về điểm yếu, không hề chứa thông tin về việc ai đã gọi API nào. Inspector nói với bạn "hệ thống này có điểm yếu", chứ không nói "người này đã thao tác".

C – VPC Flow Logs. Đây là phương án nghe có vẻ hợp lý vì nó cũng là một dạng "log". Nhưng nó ghi thông tin về lưu lượng IP đi vào và đi ra các network interface trong VPC — tức là dữ liệu tầng mạng: địa chỉ nguồn/đích, cổng, giao thức, gói tin được chấp nhận hay bị từ chối. Việc dừng instance là một lệnh quản trị gửi tới control plane của AWS, không phải một luồng traffic đi qua network interface của instance. Flow Logs có thể cho bạn biết instance ngừng nhận traffic, nhưng không bao giờ cho bạn biết danh tính IAM của người ra lệnh dừng.

D – Amazon CloudWatch. Đây là phương án gần đúng nhất và cũng là bẫy chính. CloudWatch là dịch vụ monitoring và observability: nó thu thập metric, log ứng dụng, đặt alarm khi ngưỡng bị vượt. Nó có thể cho bạn thấy instance đã ngừng phát metric từ thời điểm nào — tức là biết sự việc xảy ra khi nào, nhưng không truy được ai gây ra. CloudWatch không phải nơi ghi nhật ký các API call trong tài khoản; đó là vai trò của CloudTrail. Điểm hỏng của phương án này nằm ở chữ "who" trong đề: CloudWatch trả lời what/when, CloudTrail trả lời who.

📌 Điểm cần nhớ

• Câu hỏi có chữ "who", "which user", "audit", "API call" → phản xạ đầu tiên là AWS CloudTrail. Câu hỏi về metric, ngưỡng, alarm, hiệu năng → Amazon CloudWatch.
• CloudTrail = ai làm gì (API call + IAM principal + IP nguồn). CloudWatch = tài nguyên đang chạy thế nào. Hai dịch vụ bổ sung nhau chứ không thay thế nhau.
• VPC Flow Logs chỉ ghi lưu lượng mạng ở mức network interface, không ghi thao tác quản trị. Đừng vì cả hai đều là "log" mà chọn nhầm khi đề hỏi về hành vi của người dùng.
• Amazon Inspector là công cụ quét lỗ hổng, thuộc nhóm đánh giá điểm yếu — không liên quan đến việc truy vết hành động của người dùng.

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

Đề hỏi: phát biểu nào là đúng về dữ liệu được lưu bên trong một AWS Region?

Cụm từ quyết định nằm ở chính các phương án chứ không nằm ở đề: bốn phương án đều nói về việc dữ liệu tự động được làm gì đó — tự động lưu trữ (archive), tự động sao chép sang Region khác, tự động sao chép sang Availability Zone khác — chỉ trừ một phương án nói ngược lại: "unless you configure it" (trừ khi bạn tự cấu hình).

Đây là dạng câu kiểm tra hai nguyên tắc nền của AWS Global Infrastructure: ranh giới Region là ranh giới cứng về dữ liệu, và khách hàng là người quyết định dữ liệu của mình đi đâu. Hễ thấy phương án chứa chữ always automatically gắn với hành vi di chuyển dữ liệu ra khỏi phạm vi bạn chọn, hãy nghi ngờ ngay.

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

D — "Data is not replicated outside of a region unless you configure it".

Dữ liệu lưu trong một Region không tự động được sao chép ra ngoài Region đó. AWS giữ dữ liệu nằm yên trong Region bạn đã chọn; muốn có bản sao ở Region khác thì chính khách hàng phải bật lên — ví dụ cấu hình cross-region replication, hoặc chủ động sao chép sang Region đích.

Lý do thiết kế như vậy rất trực tiếp: tuân thủ pháp lý (compliance) và độ trễ mạng (network latency). Nhiều quốc gia và ngành nghề yêu cầu dữ liệu phải nằm trong biên giới địa lý nhất định; nếu AWS tự ý nhân bản dữ liệu sang Region khác thì khách hàng sẽ vi phạm quy định mà không hề hay biết. Ngược lại, sao chép liên Region cũng tốn băng thông và làm tăng độ trễ, nên đó phải là quyết định có ý thức của người dùng.

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

A — "Data is automatically archived after 90 days" Sai hoàn toàn. AWS không bao giờ tự chuyển dữ liệu của bạn sang tầng lưu trữ lạnh sau một mốc thời gian nào cả. Việc archive là thứ bạn phải cấu hình, và con số 90 ngày ở đây chỉ là số bịa ra cho có vẻ cụ thể. Đây là phương án dễ loại nhất trong bốn cái.

B — "Data is always replicated to another region" Đây chính là mệnh đề ngược hẳn với đáp án đúng, và là bẫy chính của câu hỏi. Người học hay nhầm vì nghe quen câu "AWS rất bền vững, dữ liệu được nhân bản nhiều nơi" rồi suy rộng ra thành nhân bản liên Region. Không đúng: nhân bản liên Region luôn là lựa chọn do khách hàng bật, không phải mặc định. Nếu B đúng thì mọi yêu cầu về chủ quyền dữ liệu (data residency) đều không thể đáp ứng được trên AWS.

C — "Data is always automatically replicated to at least one other availability zone" Đây là phương án gần đúng nhất, và cũng là chỗ nhiều người mất điểm. Nó gần đúng ở chỗ: rất nhiều dịch vụ AWS thực sự có nhân bản dữ liệu qua nhiều Availability Zone trong cùng một Region để đạt độ bền và độ sẵn sàng cao. Nhưng nó hỏng ở chữ "always" (luôn luôn): hành vi này phụ thuộc từng dịch vụ cụ thể, không phải là một quy tắc chung áp cho mọi dữ liệu lưu trong Region. Có dịch vụ và cấu hình mà dữ liệu chỉ nằm trong một AZ duy nhất. Vì thế người dùng phải tự kiểm tra từng dịch vụ mình dùng lưu dữ liệu ra sao, mức độ availability và durability có chấp nhận được không — chứ không được mặc định giả sử là đã có bản sao ở AZ khác.

Nói cách khác: C mô tả một khuôn mẫu phổ biến nhưng phát biểu nó như một bảo đảm tuyệt đối, và chính chữ "always" biến nó thành sai.

📌 Điểm cần nhớ

• Region là ranh giới dữ liệu. Dữ liệu không rời khỏi Region trừ khi khách hàng tự cấu hình sao chép ra ngoài — đây là nền tảng để đáp ứng compliance và data residency.
• Cảnh giác với các phương án chứa "always" / "automatically" gắn với việc di chuyển hay biến đổi dữ liệu. AWS hiếm khi tự làm gì với dữ liệu của bạn mà không được bật.
• Nhân bản qua nhiều AZ là đặc tính của từng dịch vụ, không phải quy tắc chung của Region. Phải tra tài liệu của đúng dịch vụ đang dùng để biết durability và availability thực tế.
• Archive/chuyển tầng lưu trữ theo thời gian là thứ do người dùng cấu hình, không bao giờ tự xảy ra theo một mốc ngày mặc định.

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

Đề hỏi: dịch vụ AWS fully managed nào cho phép người dùng bring their own machine learning algorithms — tức là mang thuật toán machine learning do chính mình viết vào để huấn luyện và triển khai.

Cụm từ quyết định đáp án là "bring your own machine learning algorithms", đi kèm ràng buộc phụ "fully managed". Hai vế này lọc theo hai bước khác nhau:

• Vế "fully managed AWS service" loại những dịch vụ mà bạn phải tự dựng và tự quản lý hạ tầng.
• Vế "bring your own algorithms" mới là vế phân biệt thật sự, vì nó tách nhóm dịch vụ machine learning có sẵn mô hình dùng ngay ra khỏi nhóm nền tảng để bạn tự xây mô hình. Trong danh sách phương án có đúng một dịch vụ ML dạng nền tảng và một dịch vụ ML dạng dùng ngay — bẫy nằm ở chỗ đó, không nằm ở chỗ "dịch vụ nào liên quan tới ML".

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

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

Amazon SageMaker là dịch vụ machine learning được AWS quản lý, đóng vai trò nền tảng cho toàn bộ vòng đời mô hình: chuẩn bị dữ liệu, huấn luyện, tinh chỉnh, rồi triển khai thành endpoint suy luận. Điểm khớp thẳng với câu hỏi là SageMaker không bắt bạn phải dùng thuật toán có sẵn của nó: bạn đóng gói thuật toán của riêng mình (dưới dạng container theo chuẩn mà SageMaker quy định) rồi đưa vào huấn luyện và triển khai ngay trong môi trường SageMaker. AWS lo phần cấp phát máy huấn luyện, chạy job, quản lý endpoint — nên nó vừa là "fully managed", vừa là dịch vụ duy nhất trong bốn phương án cho phép "bring your own algorithm".

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

A — AWS Artifact. Đây là nơi tra cứu tập trung các tài liệu về compliance của AWS: báo cáo kiểm toán, chứng nhận tuân thủ, thoả thuận với AWS. Nó không dính dáng gì tới machine learning, không huấn luyện và không chạy thuật toán nào cả. Phương án này chỉ tồn tại để làm nhiễu bằng cái tên nghe mơ hồ.

B — AWS Data Pipeline. Là dịch vụ web giúp xử lý và di chuyển dữ liệu giữa các dịch vụ compute và storage của AWS, cũng như từ nguồn dữ liệu on-premises, theo lịch định sẵn. Nó thuộc mảng điều phối luồng dữ liệu, không phải machine learning — bản thân nó không huấn luyện mô hình và không có khái niệm "thuật toán của bạn". Có thể nó xuất hiện trong một quy trình chuẩn bị dữ liệu trước khi đưa vào ML, nhưng đó không phải điều đề hỏi.

D — Amazon Forecast. Đây là phương án gần đúng nhất và là bẫy chính của câu này. Forecast thật sự là dịch vụ dựa trên machine learning, được AWS quản lý, dùng cho dự báo chuỗi thời gian trên các chỉ số kinh doanh. Nhưng nó thuộc nhóm dịch vụ ML "dùng ngay": bạn nạp dữ liệu lịch sử vào, dịch vụ tự lo phần mô hình bên trong và trả về kết quả dự báo. Chỗ nó hỏng so với đề là bạn không đưa thuật toán của riêng mình vào được — phạm vi của nó cố định ở bài toán forecasting. Đúng vế "machine learning" và vế "fully managed", nhưng trượt đúng cái vế phân biệt: "bring your own algorithms".

📌 Điểm cần nhớ

• Trong các phương án của AWS ML, hãy tách hai nhóm: nền tảng để tự xây mô hình (Amazon SageMaker) và dịch vụ ML dùng ngay cho một bài toán cụ thể (Amazon Forecast cho dự báo chuỗi thời gian). Đề hỏi "bring your own algorithm/model", "train your own model", "custom model" thì gần như luôn rơi về SageMaker.
• Đọc kỹ cụm ràng buộc cuối câu hỏi. Ở đây "fully managed" không đủ để chọn, vì Amazon Forecast cũng fully managed; chỉ có "bring your own machine learning algorithms" mới loại được nó.
• Đừng để tên dịch vụ đánh lừa. AWS Artifact là compliance, AWS Data Pipeline là di chuyển và xử lý dữ liệu theo lịch — cả hai đều không thuộc mảng machine learning, dù đứng chung danh sách với hai dịch vụ ML thật.
• Một phương án "có liên quan tới machine learning" chưa chắc là đáp án; phải khớp đúng khả năng mà đề yêu cầu, không chỉ khớp lĩnh vực.

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

Đề mô tả một tổ chức có nhiều AWS account, dùng lẫn on-demand instance và reserved instance (RI), trong đó một account đang thừa khá nhiều RI chưa dùng hết. Câu hỏi: làm sao giảm chi phí? Chọn HAI đáp án.

Cụm từ quyết định là "multiple AWS accounts" đi kèm "one account has a considerable amount of unused reserved instances". Vấn đề ở đây không phải là mua sai loại instance, cũng không phải là kiến trúc chạy chưa tối ưu — tiền đã trả rồi cho các RI đó, chỉ là phần giảm giá bị nhốt trong một account trong khi các account khác lại đang trả giá on-demand đầy đủ. Vậy thứ cần tìm là cơ chế gom các account lại để chia sẻ quyền lợi RI, chứ không phải cơ chế thay đổi cách chạy workload. Cụm "(Select TWO)" cũng gợi ý hai đáp án đúng sẽ là hai mặt của cùng một việc.

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

A — Create an AWS Organization configuration linking the accounts và B — Setup consolidated billing between the accounts.

AWS Organizations cho phép gom nhiều AWS account vào một tổ chức do bạn tạo và quản lý tập trung. Khi các account nằm chung một tổ chức có consolidated billing, phần reserved instance chưa dùng hết ở một account sẽ được áp cho các instance đủ điều kiện ở những account khác trong cùng nhóm. Nhờ đó các instance vốn đang bị tính giá on-demand sẽ hưởng mức giá RI, và chi phí tổng của tổ chức giảm xuống — đúng như phần giải thích gốc của câu hỏi nêu.

Hai đáp án này không mâu thuẫn mà bổ trợ nhau: Organizations là khung tổ chức các account, còn consolidated billing là cơ chế gộp hoá đơn để quyền lợi RI được chia sẻ trong khung đó. Đó là lý do đề yêu cầu chọn hai.

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

C — Switch to using placement groups. Placement group chỉ quyết định EC2 instance được đặt ở đâu về mặt vật lý trong hạ tầng — cụm gần nhau để giảm độ trễ mạng, hay trải ra để giảm rủi ro hỏng cùng lúc. Nó không phải một cấu trúc giá và không làm giảm hoá đơn, càng không giúp RI thừa ở account này dùng được cho account kia.

D — Use Spot instances instead. Đây là phương án dễ nhầm nhất vì Spot đúng là hướng tiết kiệm chi phí. Nhưng nó hỏng ở hai chỗ. Thứ nhất, giá Spot biến động nên không có gì bảo đảm sẽ rẻ hơn. Thứ hai, Spot instance có thể bị AWS thu hồi bất ngờ nên không hợp với workload không chịu được gián đoạn. Quan trọng nhất: chuyển sang Spot không hề giải quyết vấn đề mà đề nêu — đống RI đã mua vẫn nằm đó không ai dùng, tiền vẫn mất.

E — Redeem their reserved instances. Nghe rất hợp lý vì đúng là muốn "xử lý" chỗ RI thừa, nhưng AWS không có thao tác đổi/hoàn (redeem) reserved instance. Điều bạn có thể làm là rao bán chúng trên AWS Marketplace — đó là một hành động khác hẳn, và cũng không phải thứ mà phương án này viết. Sai vì mô tả một tính năng không tồn tại.

📌 Điểm cần nhớ

• Đề nhắc tới nhiều AWS account + RI dùng không hết thì gần như chắc chắn hướng về AWS Organizations / consolidated billing — quyền lợi RI được chia sẻ trong phạm vi tổ chức có gộp hoá đơn.
• Phân biệt rõ: placement group là chuyện đặt máy ở đâu, không phải chuyện giá. Thấy nó xuất hiện trong câu hỏi về chi phí thì thường là mồi nhử.
• Spot rẻ nhưng giá biến động và có thể bị thu hồi — chỉ chọn khi đề nói workload chịu được gián đoạn, đừng chọn chỉ vì thấy chữ "tiết kiệm".
• RI không redeem được; nếu thừa thì hoặc chia sẻ qua consolidated billing, hoặc bán lại trên AWS Marketplace.
• Với câu "(Select TWO)", hãy thử xem hai đáp án có phải hai mảnh của cùng một giải pháp không — rất hay gặp kiểu đó.