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

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

Đề mô tả một nhu cầu rất cụ thể: cần một automated security assessment report để phát hiện hai thứ trên các Amazon EC2 instance — unintended network access (đường mạng vào instance mà lẽ ra không nên có) và vulnerabilities on those instances (lỗ hổng nằm bên trong chính instance đó).

Ba cụm từ quyết định đáp án:

• "automated ... assessment report" — thứ cần tìm phải là một dịch vụ tự động quét rồi xuất báo cáo phát hiện, chứ không phải một cơ chế cấu hình do người vận hành tự đọc, tự đối chiếu.
• "unintended network access" — không phải "chặn truy cập mạng", mà là phát hiện ra rằng đang có đường truy cập ngoài ý muốn. Đây là hai vai trò khác hẳn nhau: một bên thực thi, một bên đánh giá.
• "vulnerabilities on those instances" — lỗ hổng ở tầng bên trong instance (phần mềm, cấu hình hệ điều hành), chứ không phải cấu hình của resource AWS nhìn từ ngoài.

Một phương án chỉ đúng khi phủ được đồng thời cả hai vế: mạng và lỗ hổng bên trong instance. Đây chính là ràng buộc loại bỏ các phương án còn lại.

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

Đáp án đúng theo tệp là A — Amazon Inspector.

Amazon Inspector là dịch vụ automated security assessment dành cho các ứng dụng triển khai trên AWS. Nó tự động đánh giá workload về mức độ phơi bày (exposure), về vulnerabilities, và về những sai lệch so với best practices — đúng cả hai vế mà đề nêu: đường mạng ngoài ý muốn tới EC2 instance, và lỗ hổng nằm trên chính instance đó.

Sau mỗi lần đánh giá, Amazon Inspector sinh ra danh sách findings được xếp theo mức độ nghiêm trọng (severity). Người dùng xem trực tiếp các findings, hoặc xem dưới dạng assessment report chi tiết, truy cập qua console hoặc API của Amazon Inspector. Đó chính xác là "assessment report" mà đề bài yêu cầu — nên Amazon Inspector là dịch vụ duy nhất trong danh sách khớp cả về chức năng lẫn về hình thức đầu ra.

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

B — Amazon Macie. Đây là dịch vụ bảo vệ dữ liệu và quyền riêng tư dữ liệu, dùng machine learning và pattern matching để phát hiện dữ liệu nhạy cảm đang nằm trong môi trường AWS. Macie đúng là có sinh findings, nhưng đối tượng của nó là nội dung dữ liệu, không phải đường mạng tới EC2 instance cũng không phải lỗ hổng phần mềm trên instance. Sai đối tượng đánh giá.

C — EC2 security groups. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì nó có liên quan trực tiếp tới "network access". Nhưng security group là instance-level firewall — công cụ kiểm soát lưu lượng mạng ra vào EC2 instance. Nó thực thi chính sách, chứ không đánh giá xem chính sách hiện tại có sơ hở gì. Security group không tự quét, không tự chấm điểm, không sinh assessment report, và hoàn toàn không nhìn được vào bên trong instance để tìm vulnerabilities. Nó là đối tượng bị đánh giá, không phải công cụ đánh giá.

D — AWS Config. Cũng gần đúng theo hướng "đánh giá", nhưng lệch phạm vi. AWS Config cho phép assess, audit và evaluate cấu hình của các AWS resource — nó theo dõi cấu hình resource thay đổi ra sao theo thời gian và có tuân thủ quy tắc hay không. Điểm hỏng: Config làm việc ở tầng cấu hình resource AWS, nó không quét vào bên trong instance để tìm vulnerabilities. Vế thứ hai của đề — "vulnerabilities on those instances" — nằm ngoài phạm vi của AWS Config.

📌 Điểm cần nhớ

• Phân biệt thực thi và đánh giá: security group chặn lưu lượng, Amazon Inspector phát hiện rằng đang có đường vào ngoài ý muốn. Đề hỏi "assessment report" thì luôn loại các cơ chế kiểm soát thuần tuý.
• Từ khoá "vulnerabilities" gắn với EC2 instance gần như luôn dẫn tới Amazon Inspector — nó là dịch vụ nhìn được vào bên trong instance, khác với các dịch vụ chỉ nhìn cấu hình resource.
• Ghi nhớ theo đối tượng mà mỗi dịch vụ soi vào: Inspector → workload/instance (exposure + vulnerability); AWS Config → cấu hình của AWS resource; Macie → dữ liệu nhạy cảm.
• Khi đề nêu hai yêu cầu cùng lúc (ở đây: mạng và lỗ hổng), hãy kiểm cả hai vế trước khi chọn. Phương án chỉ phủ được một vế — như AWS Config hay security group — là phương án gần đúng được đặt ra để loại.

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

Đề hỏi: dịch vụ AWS nào dùng để tự động hoá configuration management bằng Puppet?

Cụm từ quyết định đáp án là "using Puppet" — không phải "automate" chung chung, cũng không phải "configuration management" chung chung. Cả bốn phương án đều dính dáng tới việc quản lý và tự động hoá hạ tầng ở mức nào đó, nên nếu chỉ đọc "automate configuration management" thì AWS Systems Manager hay AWS CloudFormation đều nghe hợp lý. Ràng buộc thật nằm ở tên một công cụ bên thứ ba cụ thể: Puppet. Chỉ có đúng một dịch vụ AWS được xây dựng quanh việc chạy Chef và Puppet dưới dạng managed service.

Đây là dạng câu rất hay gặp ở mức Cloud Practitioner: đề gài một từ khoá thương hiệu (Puppet, Chef, Kubernetes, Redis, Kafka…) và người học phải khớp thẳng từ khoá đó với dịch vụ AWS được sinh ra để chạy nó.

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

C — AWS OpsWorks.

OpsWorks là dịch vụ configuration management của AWS, cung cấp managed instance của Chef và Puppet. Chef và Puppet là các nền tảng automation cho phép bạn mô tả cấu hình máy chủ bằng code, rồi để nền tảng đó áp cấu hình lên máy.

Với OpsWorks, bạn dùng Chef hoặc Puppet để tự động hoá việc cấu hình, triển khai và quản lý server — cả trên Amazon EC2 instance lẫn môi trường compute on-premises. Đúng chính xác thứ đề bài mô tả: automate configuration management using Puppet.

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

A — AWS Systems Manager. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất. Systems Manager cho bạn khả năng nhìn thấy và điều khiển hạ tầng trên AWS: một giao diện thống nhất để xem dữ liệu vận hành từ nhiều dịch vụ AWS, và tự động hoá các tác vụ vận hành trên tài nguyên AWS. Nó đúng là làm được nhiều việc kiểu "quản lý cấu hình máy" (chạy lệnh, vá lỗi, quản lý tham số). Chỗ nó hỏng so với đề: Systems Manager có bộ công cụ automation của riêng AWS, nó không phải là nơi AWS cung cấp Puppet dưới dạng dịch vụ được quản lý. Đề không hỏi "tự động hoá vận hành", đề hỏi "tự động hoá bằng Puppet".

B — AWS Config. Tên dịch vụ có chữ "Config" nên rất dễ bị chọn theo phản xạ, nhưng nó thuộc nhóm khác hẳn. AWS Config là dịch vụ giúp bạn đánh giá, audit và thẩm định cấu hình của các tài nguyên AWS — tức là ghi nhận và kiểm tra xem tài nguyên đang ở trạng thái cấu hình nào, có lệch khỏi quy định không. Đó là góc nhìn quan sát và tuân thủ, không phải áp đặt cấu hình lên server. Config không chạy Puppet, không cài phần mềm, không đẩy cấu hình xuống máy.

D — AWS CloudFormation. Đây là infrastructure as code: CloudFormation cung cấp một ngôn ngữ chung để bạn mô tả (model) và cung cấp (provision) tài nguyên AWS cũng như tài nguyên ứng dụng của bên thứ ba trong môi trường cloud. Nó dựng ra hạ tầng — tạo VPC, EC2 instance, security group. Đề bài không hỏi cách tạo tài nguyên, mà hỏi cách quản lý cấu hình bên trong server sau khi đã có, và quan trọng hơn là hỏi bằng Puppet. CloudFormation dùng template của chính nó, không phải Puppet manifest.

📌 Điểm cần nhớ

• Puppet hoặc Chef xuất hiện trong đề → nghĩ ngay tới AWS OpsWorks. Đây là dịch vụ AWS cung cấp hai nền tảng đó dưới dạng managed service, chạy được cho cả EC2 instance lẫn máy on-premises.
• Phân biệt "provision" với "configure". CloudFormation dựng tài nguyên AWS; OpsWorks cấu hình phần mềm bên trong máy chủ. Hai giai đoạn khác nhau của cùng một vòng đời.
• AWS Config nghe giống "configuration management" nhưng thuộc nhóm audit/compliance. Nó đánh giá và ghi nhận cấu hình tài nguyên AWS, không áp cấu hình lên máy. Gặp từ khoá "assess", "audit", "evaluate", "compliance" thì mới là Config.
• Systems Manager là bộ công cụ vận hành của riêng AWS, mạnh về visibility và automation trên tài nguyên AWS — chọn nó khi đề nói về vận hành, vá lỗi, chạy lệnh từ xa; đừng chọn khi đề chỉ đích danh một nền tảng bên thứ ba.

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

Đề hỏi: theo AWS Shared Responsibility Model, công việc nào thuộc trách nhiệm của khách hàng (customer)?

Cụm từ quyết định nằm ngay ở "which task is the customer's responsibility" — tức là phải tìm việc thuộc nhóm security "in" the cloud, chứ không phải security "of" the cloud (phần AWS lo). Ranh giới giữa hai nhóm phụ thuộc vào loại dịch vụ:

• Với dịch vụ managed / serverless (DynamoDB, API Gateway, Lambda), AWS vận hành toàn bộ hạ tầng bên dưới: máy chủ vật lý, ảo hoá, và cả hệ điều hành — khách hàng không có quyền truy cập vào lớp đó.
• Với dịch vụ IaaS như EC2, AWS dừng lại ở lớp hypervisor và hạ tầng; guest operating system chạy bên trong instance là của khách hàng.

Vì vậy từ khoá phân biệt trong các phương án là "guest operating system on EC2" so với hạ tầng/OS của các dịch vụ managed. Cứ thấy tên một dịch vụ managed đi kèm chữ infrastructure hoặc operating system thì gần như chắc chắn đó là phần của AWS.

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

D — Updating the guest operating system on Amazon EC2 instances.

EC2 là dịch vụ hạ tầng: AWS quản lý phần nền mà EC2 chạy trên đó (trung tâm dữ liệu, phần cứng, mạng, lớp ảo hoá), còn khách hàng là người chọn AMI, khởi chạy instance và quản lý hệ điều hành khách bên trong. Từ thời điểm instance chạy, mọi việc như cài bản vá, cập nhật kernel, nâng cấp phiên bản OS, cấu hình tài khoản và dịch vụ trong OS đều nằm trong tay khách hàng. Đây chính là ví dụ kinh điển của security "in" the cloud: AWS không đăng nhập vào instance của bạn để vá lỗi giúp bạn.

Ngoài OS, cùng nhóm trách nhiệm khách hàng với EC2 còn có: dữ liệu, cấu hình security group, IAM, mã hoá dữ liệu và lưu lượng mạng — nhưng câu này chỉ hỏi về OS.

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

A — Maintaining the infrastructure needed to run Amazon DynamoDB. DynamoDB là dịch vụ cơ sở dữ liệu fully managed. Khách hàng chỉ tạo bảng, thiết kế khoá, ghi/đọc dữ liệu và cấu hình quyền truy cập; không hề nhìn thấy máy chủ, đĩa hay OS bên dưới. Toàn bộ hạ tầng chạy DynamoDB do AWS duy trì — đây là security "of" the cloud.

B — Maintaining Amazon API Gateway infrastructure. Tương tự A. API Gateway là dịch vụ managed: khách hàng định nghĩa API, route, authorizer, throttling và tích hợp backend. Không có máy chủ nào để khách hàng vá hay mở rộng — AWS lo phần đó. Đây là phương án dễ loại nếu nhận ra chữ infrastructure gắn với một dịch vụ managed.

C — Updating the operating system of AWS Lambda instances. Đây là phương án gần đúng nhất và hay bẫy người học, vì Lambda có chạy code của khách hàng nên nghe như khách hàng phải lo môi trường thực thi. Nhưng Lambda là serverless: AWS quản lý môi trường chạy, bao gồm cả hệ điều hành bên dưới và việc vá lỗi cho nó. Khách hàng chỉ chịu trách nhiệm về mã hàm, thư viện phụ thuộc đóng gói kèm, biến môi trường, IAM role và cấu hình hàm — chứ không cập nhật OS. Đúng chỗ nó hỏng: nhầm "quản lý code chạy trên nền" thành "quản lý cái nền".

Điểm chung của A, B, C: cả ba đều nói về hạ tầng hoặc hệ điều hành của dịch vụ managed — vùng mà khách hàng thậm chí không có quyền truy cập, nên không thể là trách nhiệm của họ.

📌 Điểm cần nhớ

• Ranh giới của Shared Responsibility Model dịch chuyển theo loại dịch vụ: dịch vụ càng managed thì phần AWS lo càng nhiều, phần khách hàng lo càng ít.
• EC2 là ngoại lệ đáng nhớ: đây là dịch vụ hiếm hoi trong nhóm này mà khách hàng phải tự vá và nâng cấp guest OS. Với DynamoDB, API Gateway, Lambda thì OS và hạ tầng đều là của AWS.
• Mẹo loại nhanh trong đề trắc nghiệm: phương án nào chứa "maintaining infrastructure" hoặc "updating the operating system" đi kèm một dịch vụ managed/serverless thì gần như chắc chắn sai khi câu hỏi hỏi về trách nhiệm khách hàng.
• Câu thần chú phân biệt: AWS chịu trách nhiệm security "of" the cloud, khách hàng chịu trách nhiệm security "in" the cloud — hãy tự hỏi "mình có quyền đăng nhập vào lớp đó không?"; không có quyền thì không phải việc của mình.

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

Đề bài hỏi rất gọn: "Which AWS services offer compute capabilities?" — dịch vụ nào của AWS cung cấp năng lực tính toán (compute). Cụm từ quyết định ở đây là "compute capabilities", cộng thêm ràng buộc "(Select TWO.)" — phải chọn đúng hai phương án.

Câu này không đánh đố về kiến trúc hay chi phí, mà kiểm tra một việc duy nhất: bạn có phân loại được các dịch vụ AWS vào đúng nhóm của nó hay không. Năm phương án được đặt cạnh nhau chính là năm nhóm khác nhau — storage, database, compute, container, security. Mẹo làm bài là với mỗi phương án, tự hỏi: "dịch vụ này có chạy code hoặc tiến trình của tôi trên CPU do AWS quản lý không?" Nếu câu trả lời là "không, nó chỉ giữ dữ liệu của tôi" hoặc "nó chỉ bảo vệ thứ gì đó", thì nó không thuộc nhóm compute.

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

Theo tệp, đáp án đúng là C (AWS Lambda) và D (Amazon ECS).

AWS Lambda là dịch vụ function as a service: bạn nộp lên một hàm, AWS chạy hàm đó để phản hồi các trigger (sự kiện). Bạn không quản lý máy chủ, nhưng thứ chạy vẫn là code của bạn trên CPU do AWS cấp — đó đúng nghĩa là compute. Việc nó không lộ ra máy ảo cho bạn thấy không làm nó bớt là compute; serverless vẫn nằm trong nhóm compute.

Amazon ECS (Elastic Container Service) là dịch vụ chạy Docker container dưới dạng task trên AWS. Cái được thực thi ở đây là image container của bạn — cũng là workload chạy trên CPU. ECS là dịch vụ điều phối container, và trong cách AWS phân nhóm dịch vụ, container service nằm trong họ compute cùng với EC2 và Lambda.

Hai phương án này bao đúng hai kiểu compute phổ biến ngoài EC2: chạy theo hàm/sự kiện (Lambda) và chạy theo container (ECS).

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

A. Amazon EFS — Elastic File System là hệ thống lưu trữ dạng tệp (file storage) gắn được vào nhiều instance cùng lúc. Đây là phương án dễ gây nhầm nhất trong nhóm sai, vì EFS thường xuất hiện cạnh EC2 và Lambda trong các sơ đồ kiến trúc, và người học quen thấy nó trong ngữ cảnh "chạy ứng dụng". Nhưng vai trò của nó là giữ dữ liệu cho compute dùng, chứ bản thân nó không thực thi code nào của bạn. Đi kèm compute ≠ là compute.

B. Amazon DynamoDB — đây là dịch vụ cơ sở dữ liệu (NoSQL, key-value/document). Nó nhận truy vấn và trả về dữ liệu; công việc "tính toán" mà nó làm là công việc nội bộ của chính engine database, không phải nơi bạn triển khai ứng dụng của mình. Phân nhóm của nó là database, không phải compute. Cũng như EFS, DynamoDB hay đứng ngay sau Lambda trong kiến trúc serverless, nên dễ bị kéo nhầm sang nhóm compute vì "quen mặt".

E. Amazon CloudHSM — dịch vụ cung cấp hardware security module để lưu trữ và quản lý khoá mã hoá một cách an toàn. Đúng là bên trong nó có phần cứng thực hiện các phép toán mật mã, nên nếu hiểu "compute" theo nghĩa đen thì trông có vẻ hợp lý — nhưng bạn không triển khai được ứng dụng của mình lên CloudHSM. Nó thuộc nhóm security/identity & compliance, và giá trị của nó là bảo vệ khoá, không phải chạy workload.

📌 Điểm cần nhớ

• Nhóm compute = nơi chạy code hoặc workload của bạn. EC2 (máy ảo), Lambda (hàm theo sự kiện), ECS/EKS/Fargate (container) đều thuộc nhóm này. Hỏi "code của tôi chạy ở đâu?" là cách phân loại nhanh nhất.
• Serverless vẫn là compute. Không nhìn thấy máy chủ không có nghĩa là không có compute — Lambda là ví dụ kinh điển, và câu hỏi kiểu này rất hay dùng nó để thử.
• Đừng nhầm "phục vụ cho compute" với "là compute". EFS (file storage) và DynamoDB (database) luôn xuất hiện cạnh ứng dụng, nhưng vai trò của chúng là lưu trữ dữ liệu.
• Dịch vụ security có làm phép toán nhưng không thuộc nhóm compute. CloudHSM quản lý khoá mã hoá; phân nhóm dịch vụ dựa trên mục đích sử dụng, không dựa trên việc bên trong có bộ xử lý hay không.
• Đọc kỹ "(Select TWO.)" — chọn thiếu hoặc thừa đều bị tính sai toàn bộ câu, kể cả khi những phương án bạn chọn đều đúng.

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

Đề mô tả một người dùng muốn cấu hình AWS CLI để truy cập programmatic vào các dịch vụ AWS, rồi hỏi thành phần credential nào là bắt buộc (chọn HAI).

Cụm từ quyết định là "programmatic access" đi kèm "AWS CLI". Đây là kiểu truy cập bằng chương trình — CLI, SDK hoặc gọi thẳng AWS API — chứ không phải đăng nhập bằng trình duyệt vào AWS Management Console. Console dùng username và password; programmatic access dùng access key, và access key luôn gồm đúng hai mảnh. Chỉ cần bám vào chi tiết đó là loại được ba phương án còn lại, vì chúng thuộc về những cơ chế xác thực khác hẳn.

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

Đáp án đúng theo tệp là A (An access key ID) và B (A secret access key).

Access key là loại long-term credential gắn với một IAM user hoặc với AWS account root user, dùng để ký (sign) các request programmatic gửi tới AWS CLI hoặc AWS API — trực tiếp hoặc thông qua AWS SDK. Một access key gồm hai phần không tách rời:

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

Giống như cặp username và password, bạn phải dùng cả hai cùng lúc thì request mới xác thực được: access key ID cho AWS biết đây là ai, secret access key là thứ dùng để tạo chữ ký chứng minh bạn thực sự là chủ của ID đó. Đó chính là hai giá trị mà aws configure hỏi khi bạn thiết lập AWS CLI. Vì secret access key có sức mạnh tương đương mật khẩu, nó phải được bảo quản cẩn thận đúng như bảo quản mật khẩu.

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

• C — A private key: Private key thuộc về mô hình mã hóa khóa công khai/khóa riêng, và trong AWS nó gắn với key pair dùng để xác thực khi kết nối vào EC2 instance (ví dụ SSH vào một Linux instance). Đây là phương án dễ nhầm vì nó cũng là một "credential" và cũng dùng cho việc truy cập bằng dòng lệnh — nhưng dòng lệnh đó là SSH vào máy ảo, không phải AWS CLI ký request tới AWS API. Cấu hình AWS CLI không bao giờ hỏi bạn file private key.

• E — A public key: Cũng cùng họ với C. Public key là nửa còn lại của cặp khóa, dùng cho mã hóa và cho key pair của EC2 instance. Nó không có vai trò gì trong việc cấu hình credential cho AWS CLI. Việc đề đưa cả C lẫn E vào là một cái bẫy cân đối: nếu ai đó nghĩ "credential thì phải đi theo cặp" mà không nhớ rõ cặp nào, họ rất dễ chọn nhầm public/private key thay vì access key ID/secret access key.

• D — An IAM Role: Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. IAM Role là một identity mang permission, không phải một thành phần credential mà bạn nhập vào khi cấu hình CLI. Role được dùng để ủy quyền (delegate) truy cập cho các dịch vụ AWS và cho truy cập cross-account. Đề hỏi "credential components are required" — tức là những mảnh dữ liệu cụ thể bạn phải có trong tay để ký request — và IAM Role không phải một mảnh dữ liệu như vậy. Ngoài ra, câu hỏi yêu cầu chọn hai thành phần đi cùng nhau; access key ID và secret access key là một cặp có nghĩa, còn IAM Role đứng một mình không ghép được với ai trong danh sách.

📌 Điểm cần nhớ

• Programmatic access (AWS CLI, SDK, API) = access key ID + secret access key. Console access = username + password. Nhìn thấy chữ "programmatic" hay "AWS CLI" trong đề là nghĩ ngay tới cặp access key.
• Access key luôn có đúng hai phần và phải dùng chung. Access key ID định danh, secret access key dùng để ký; thiếu một trong hai thì request không xác thực được.
• Public/private key trong AWS thường là key pair của EC2 instance, phục vụ việc kết nối vào máy ảo — đừng lẫn với credential dùng để gọi AWS API.
• IAM Role là identity mang quyền, không phải credential component bạn khai vào CLI. Vai trò của nó là ủy quyền cho dịch vụ AWS và truy cập cross-account.
• Secret access key có sức mạnh ngang mật khẩu — bảo vệ nó với cùng mức độ cẩn trọng.

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

Đề hỏi: khi thiết kế một kiến trúc highly available (tính sẵn sàng cao) trên AWS, người làm cloud cần bảo đảm điều gì?

Cụm từ quyết định là "highly available architecture". Đây là chỗ dễ nhầm nhất trong nhóm câu hỏi về Well-Architected, vì bốn phương án nói về bốn thuộc tính khác nhau của một hệ thống:

• low-latency, high throughput → performance (hiệu năng)
• đủ server chạy peak load mọi lúc → capacity / scalability, và ở đây là scaling kiểu tĩnh
• một khối monolith lo hết → kiểu kiến trúc, không phải thuộc tính sẵn sàng
• lỗi một thành phần không ảnh hưởng ứng dụng → availability / fault tolerance

Đề không hỏi hệ thống chạy nhanh hay rẻ, mà hỏi hệ thống vẫn phục vụ được khi có thứ hỏng. Chỉ cần bám vào định nghĩa đó là loại được ba phương án còn lại.

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

D — "The failure of a single component should not affect the application" chính là định nghĩa của high availability: loại bỏ single point of failure.

Trong một hệ sẵn sàng cao, nếu một application server chết thì phải có các server khác đang sẵn sàng tiếp quản mà người dùng không cảm nhận được gián đoạn. Trên AWS, đó là lý do ta trải instance qua nhiều Availability Zone, đặt sau load balancer để lưu lượng tự tránh node hỏng, và dùng Auto Scaling để thay thế instance không còn healthy. Availability được đo bằng khả năng chịu hỏng hóc, nên câu trả lời nào nói tới "chịu được lỗi cục bộ" chính là câu trả lời đúng.

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

A — "Servers have low-latency and high throughput network connectivity" Đây là mục tiêu về hiệu năng, không phải sẵn sàng. Một hệ thống có mạng cực nhanh nhưng chỉ chạy trên một instance duy nhất thì instance đó chết là ứng dụng chết. Ngược lại, không phải kiến trúc nào cũng cần độ trễ thấp — nhiều workload xử lý theo lô hoàn toàn không quan tâm. Hai thuộc tính này độc lập với nhau, nên A không bảo đảm được điều đề hỏi.

B — "There are enough servers to run at peak load available at all times" Đây là phương án gần đúng nhất và cũng là bẫy chính. Đúng là muốn sẵn sàng thì phải có dư năng lực để nuốt phần tải của thành phần đã hỏng. Nhưng chỗ hỏng nằm ở cụm "at peak load available at all times": giữ thường trực đủ server cho đỉnh tải là lãng phí tài nguyên và chi phí, và nó đi ngược đúng thứ mà cloud mang lại. Cách làm đúng là chuẩn bị đủ năng lực cho tải hiện tại cộng thêm phần dự phòng để chịu lỗi, rồi để Auto Scaling tự thêm server khi nhu cầu tăng. Ngoài ra, thừa capacity vẫn không cứu được nếu tất cả server nằm chung một điểm hỏng — nên B vừa tốn kém vừa không trả lời trúng câu hỏi.

C — "A single monolithic application component handles all operations" Phương án này không chỉ không giúp, mà còn làm giảm availability. Gom mọi chức năng vào một khối nghĩa là bất kỳ lỗi nào — hay thậm chí chỉ là một lần cập nhật — ở một phần nhỏ cũng có thể kéo sập toàn bộ hệ thống. Đây là mô tả kinh điển của single point of failure, tức là đúng thứ mà thiết kế sẵn sàng cao phải loại bỏ.

📌 Điểm cần nhớ

• High availability = không có single point of failure. Thấy phương án nào nói "lỗi một thành phần không làm hỏng ứng dụng" thì gần như chắc chắn đó là đáp án cho câu hỏi về availability.
• Phân biệt bốn nhóm thuộc tính khi đọc phương án: availability (chịu lỗi), performance (latency/throughput), scalability (co giãn theo tải), cost. Đề hỏi cái nào thì chọn phương án thuộc đúng nhóm đó — phương án nói về nhóm khác luôn là bẫy, dù bản thân nó là điều tốt.
• "Luôn giữ sẵn đủ server cho peak load" là mô hình tư duy của on-premises, không phải cách AWS khuyến khích. Trên AWS, dùng Auto Scaling để mở rộng theo nhu cầu, chỉ giữ dư đủ để chịu lỗi.
• Monolith một khối luôn là phương án sai trong câu hỏi về availability hay resilience; tách thành phần và trải qua nhiều Availability Zone mới là hướng thiết kế đúng.

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

Đề hỏi: "Which of the following statements are security principles within the AWS Well-Architected Framework? (Select TWO.)" — tức là chọn hai phát biểu thuộc Security Pillar (trụ cột Bảo mật) của AWS Well-Architected Framework.

Cụm từ quyết định là "security principles" kết hợp với "within the AWS Well-Architected Framework". Đây là chỗ bẫy: cả năm phương án đều là những phát biểu đúng và quen thuộc trong tài liệu AWS — nhưng chúng nằm rải ở các trụ cột khác nhau (Operational Excellence, Reliability, Performance Efficiency, Cost Optimization, Security). Câu hỏi không hỏi "phát biểu nào đúng", mà hỏi "phát biểu nào thuộc đúng trụ cột Security". Nên cách làm là gán mỗi phương án về trụ cột của nó, rồi giữ lại hai cái rơi vào Security.

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

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

C — "Protect data in transit and at rest." Đây là một trong những design principle được nêu thẳng trong Security Pillar. Dữ liệu tồn tại ở hai trạng thái: đang di chuyển trên đường truyền (in transit) và đang nằm yên trong kho lưu trữ (at rest). Bảo vệ cả hai — bằng mã hoá, phân loại mức nhạy cảm, kiểm soát truy cập — là để bảo đảm không ai không có quyền đọc được dữ liệu. Bỏ sót một trong hai trạng thái là để hở nguyên một mặt.

E — "Monitor, alert, and audit actions and changes to AWS resources." Đây là nguyên tắc traceability của Security Pillar. Giám sát liên tục, cảnh báo và ghi vết mọi hành động cùng mọi thay đổi trên tài nguyên AWS là phần cốt lõi của một thế trận bảo mật mạch lạc: có theo dõi liên tục thì mối đe doạ hay vấn đề bảo mật mới được phát hiện và xử lý càng sớm càng tốt. Không có vết ghi lại thì sự cố xảy ra cũng chẳng biết ai làm, làm lúc nào, đổi cái gì.

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

A — "Perform operations as code." Đây là phương án gần đúng nhất và cũng khó loại nhất. Nó có giúp gián tiếp cho thế trận bảo mật (hạ tầng khai báo bằng mã thì cấu hình lặp lại được, review được, ít lệch tay hơn). Nhưng bản thân phát biểu này không phải một security principle — nó gắn với các trụ cột về vận hành/độ tin cậy, nơi trọng tâm là loại bỏ thao tác thủ công và làm cho thay đổi trở nên nhất quán, hồi phục được. Lợi ích bảo mật ở đây chỉ là hệ quả bên lề, không phải mục đích của nguyên tắc.

B — "Deploy globally in minutes." Đây là một lợi thế của cloud, không phải nguyên tắc thiết kế của trụ cột Security. Nó phục vụ độ tin cậy (reliability), khả năng mở rộng (scalability) và hiệu năng (performance efficiency) — đưa ứng dụng lại gần người dùng hơn, chịu lỗi theo vùng tốt hơn. Khả năng triển khai ứng dụng phân tán toàn cầu không làm thay đổi mức bảo mật của hệ thống theo hướng này hay hướng kia, nên nó không thuộc Security Pillar.

D — "Analyze and attribute expenditures." Phân tích chi phí và quy trách nhiệm chi tiêu về từng nhóm/dự án là nguyên tắc thuộc Cost Optimization — đây là phương án dễ loại nhất vì nó nói về tiền chứ không nói về bảo vệ dữ liệu hay kiểm soát truy cập. Việc gắn nhãn tài nguyên để bóc tách chi phí có trùng công cụ với việc gắn nhãn phục vụ quản trị, nhưng mục đích của nguyên tắc này là kiểm soát chi tiêu, không phải bảo mật.

📌 Điểm cần nhớ

• Với câu hỏi kiểu "principle nào thuộc pillar X" của Well-Architected Framework, chiến thuật là gán từng phương án về pillar của nó rồi loại, thay vì hỏi "phát biểu này có đúng không" — mọi phương án thường đều đúng, chỉ sai chỗ đặt.
• Hai từ khoá nhận diện Security Pillar: bảo vệ dữ liệu (in transit / at rest) và traceability (monitor, alert, audit mọi hành động và thay đổi).
• "Deploy globally in minutes" là lợi thế cloud gắn với reliability/performance, không phải nguyên tắc bảo mật; "analyze and attribute expenditures" luôn là Cost Optimization.
• Cẩn thận với những phương án gián tiếp có lợi cho bảo mật như "perform operations as code" — đề hỏi nguyên tắc thuộc trụ cột nào, không hỏi cái gì có ích cho bảo mật.

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

Đề hỏi: theo shared responsibility model của AWS, nhiệm vụ bảo mật và tuân thủ nào AWS chịu trách nhiệm?

Cụm từ quyết định nằm ở hai chỗ. Thứ nhất là "AWS is responsible for" — đề hỏi phần việc của nhà cung cấp, không phải phần việc của khách hàng. Đây là kiểu câu rất dễ chọn nhầm vì cả bốn phương án đều là việc bảo mật có thật, chỉ khác nhau ở chỗ ai làm. Thứ hai là chữ "host" trong phương án A — nó chỉ máy chủ vật lý chạy bên dưới các EC2 instance, tức là hạ tầng, chứ không phải hệ điều hành nằm trong instance của khách hàng.

Ranh giới cần dùng để lọc: AWS lo security "of" the cloud (phần cứng, hạ tầng, khu vực máy chủ, lớp ảo hoá), còn khách hàng lo security "in" the cloud (dữ liệu, hệ điều hành khách, cấu hình, quyền truy cập). Đọc từng phương án và hỏi "cái này nằm bên dưới hay bên trên lớp ảo hoá?" là đủ tách bạch.

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

A — Updating Amazon EC2 host firmware. Firmware của EC2 host là phần mềm chạy trên chính máy chủ vật lý đặt trong trung tâm dữ liệu của AWS. Khách hàng không có quyền truy cập vào lớp đó, thậm chí không nhìn thấy nó: bạn chỉ nhìn thấy instance của mình, không nhìn thấy máy chủ vật lý đang chứa nó. Vì vậy việc vá và cập nhật firmware thuộc security "of" the cloud và hoàn toàn do AWS thực hiện, cùng nhóm với việc bảo trì phần cứng, mạng nội bộ và an ninh vật lý của trung tâm dữ liệu.

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

B — Encrypting data at rest. Đây là phương án gần đúng nhất, vì AWS có cung cấp sẵn công cụ mã hoá (tuỳ chọn mã hoá của EBS, S3, RDS…). Nhưng cung cấp công cụ khác với chịu trách nhiệm. Quyết định có bật mã hoá hay không, chọn khoá nào, xoay khoá ra sao đều nằm trong tay khách hàng. Để một volume hay một bucket không mã hoá là lựa chọn của khách hàng, và hậu quả cũng thuộc về khách hàng — đó là security "in" the cloud.

C — Updating operating systems. Phương án này bẫy ở chỗ nghe rất giống A: cả hai đều là "cập nhật phần mềm nền". Khác biệt là tầng. Hệ điều hành khách chạy bên trong EC2 instance, khách hàng có quyền quản trị đầy đủ và AWS không đăng nhập vào đó. Vá lỗi hệ điều hành, cài bản cập nhật bảo mật là việc của khách hàng. Lưu ý AWS chỉ vá hệ điều hành nền của các dịch vụ managed nơi khách hàng không truy cập được vào máy chủ — nhưng đề đang nói về EC2, nơi khách hàng nắm hệ điều hành.

D — Granting permissions to users and services. AWS cung cấp IAM làm công cụ, còn việc tạo user, viết policy, gán role cho service là do khách hàng cấu hình. Cấp quyền quá rộng là lỗi cấu hình của khách hàng chứ không phải lỗi của AWS. Quản trị danh tính và truy cập là ví dụ kinh điển của security "in" the cloud.

📌 Điểm cần nhớ

• Câu hỏi về shared responsibility model gần như luôn giải được bằng một câu hỏi duy nhất: việc này nằm bên dưới hay bên trên lớp ảo hoá? Bên dưới (phần cứng, host, firmware, cơ sở vật chất) là AWS; bên trên (hệ điều hành khách, dữ liệu, quyền, cấu hình) là khách hàng.
• AWS cung cấp công cụ ≠ AWS chịu trách nhiệm. Mã hoá và IAM đều là dịch vụ do AWS xây, nhưng việc bật và cấu hình chúng thuộc về khách hàng. Đây là bẫy hay gặp nhất trong nhóm câu này.
• Chú ý từ khoá phân tầng trong phương án: host / hardware / physical / infrastructure thường nghiêng về AWS, còn operating system / data / permissions / configuration nghiêng về khách hàng.
• Với EC2 (dịch vụ IaaS), khách hàng nắm hệ điều hành nên phải tự vá. Mức độ trách nhiệm của khách hàng giảm dần khi chuyển sang các dịch vụ managed, nơi khách hàng không còn truy cập được vào máy chủ.

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

Đề hỏi: dashboard nào của AWS hiển thị thông tin relevant and timely giúp người dùng quản lý các event đang diễn ra, đồng thời gửi thông báo chủ động (proactive notifications) để lên kế hoạch cho các scheduled activities.

Cụm từ quyết định nằm ở hai chỗ:

• "relevant" — tức là thông tin liên quan tới chính tài khoản và tài nguyên của bạn, chứ không phải tình trạng chung của toàn bộ AWS. Đây là chữ tách bạch giữa hai dashboard sức khoẻ dịch vụ.
• "proactive notifications ... for scheduled activities" — báo trước về những việc đã được lên lịch (bảo trì, thay thế phần cứng, thời hạn phải hành động), chứ không phải báo sau khi sự cố đã xảy ra.

Ghép hai ràng buộc lại thì đề đang mô tả một dashboard cá nhân hoá theo tài khoản và hướng sự kiện (event-driven) — chính là ngôn ngữ AWS dùng cho AWS Personal Health Dashboard.

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

D. AWS Personal Health Dashboard.

Personal Health Dashboard đưa ra cảnh báo và hướng dẫn khắc phục khi AWS đang gặp sự cố có khả năng ảnh hưởng tới bạn. Nó cho một góc nhìn được cá nhân hoá về hiệu năng và tính sẵn sàng của các dịch vụ AWS nằm bên dưới tài nguyên bạn đang dùng — đúng nghĩa chữ "relevant" trong đề.

Cảnh báo ở đây được kích hoạt bởi thay đổi về sức khoẻ của chính tài nguyên AWS của bạn, nên bạn thấy được event, kèm hướng dẫn để chẩn đoán và xử lý nhanh. Ngoài event đang diễn ra, dashboard này còn thông báo trước về các hoạt động đã lên lịch để bạn kịp chuẩn bị — vế thứ hai của đề bài. Không phương án nào khác gộp đủ ba yếu tố: cá nhân hoá + event đang diễn ra + thông báo chủ động cho việc đã lên lịch.

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

A. AWS Trusted Advisor dashboard — Trusted Advisor là công cụ online đưa ra khuyến nghị theo best practice của AWS khi bạn provision tài nguyên: tối ưu chi phí, hiệu năng, bảo mật, fault tolerance, hạn mức dịch vụ. Nó soi cấu hình tài khoản của bạn, không soi sự kiện sức khoẻ của hạ tầng AWS. Nó không phải nơi bạn vào để theo dõi một event đang diễn ra hay xem lịch bảo trì sắp tới.

B. AWS Service Health Dashboard — đây là phương án gần đúng nhất và là cái bẫy chính của câu. Nó đúng ở chữ "health", nhưng nó chỉ hiển thị tình trạng chung của các dịch vụ AWS theo từng region, giống một trang trạng thái công khai cho mọi khách hàng. Nó hỏng ở đúng hai ràng buộc của đề: không cá nhân hoá (không biết bạn đang chạy gì, ở đâu), và không gửi thông báo chủ động về scheduled activities, cũng không kèm hướng dẫn xử lý. Hễ đề nhấn chữ "relevant to you", "your resources", hay "proactive notification" thì phải bỏ Service Health Dashboard để lấy Personal Health Dashboard.

C. Amazon CloudWatch dashboard — CloudWatch theo dõi metric, log và alarm về hiệu năng của hạ tầng và tài nguyên bạn tạo ra (CPU, tình trạng ứng dụng, ngưỡng cảnh báo bạn tự đặt). Nó nhìn từ trên xuống phần bạn vận hành, chứ không cho biết các dịch vụ AWS nằm bên dưới đang có sự cố hay sắp có bảo trì hay không. CloudWatch cũng chỉ báo khi ngưỡng bị vượt — đó là phản ứng theo số liệu, không phải thông báo chủ động về hoạt động đã lên lịch của AWS.

📌 Điểm cần nhớ

• Service Health Dashboard = công khai, chung cho mọi người; Personal Health Dashboard = riêng cho tài khoản của bạn. Chữ "personal" trong tên chính là gợi ý; đề nào có "your resources", "relevant to you", "personalized" thì chọn Personal.
• "Proactive notification" + "scheduled activities" là chữ ký của Personal Health Dashboard — nó báo trước việc bảo trì/thay thế sắp tới, kèm hướng dẫn khắc phục (remediation guidance).
• Đừng lẫn ba loại "sức khoẻ": CloudWatch = hiệu năng tài nguyên bạn tạo; Trusted Advisor = khuyến nghị best practice về cấu hình; Health Dashboard = tình trạng dịch vụ AWS ở tầng dưới.
• Khi bốn phương án đều là "dashboard", hãy hỏi: dashboard này nói về hạ tầng của AWS hay về thứ tôi tự dựng, và thông tin có gắn với tài khoản tôi hay không — hai câu hỏi này thường đủ để loại ba phương án.

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

Đề mô tả một công ty đang di chuyển máy ảo (VMs) từ data center của họ lên AWS Cloud, và các máy này sẽ chạy trên Amazon EC2. Câu hỏi: đây là mô hình điện toán đám mây nào?

Cụm từ quyết định đáp án là "migrating virtual machines … deploy these migrated machines on Amazon EC2". Hai chi tiết quan trọng nằm gọn trong đó:

• Đơn vị được đưa lên cloud là máy ảo nguyên khối, tức là cả hệ điều hành khách, chứ không phải một ứng dụng hay một đoạn mã.
• Đích đến là EC2 — dịch vụ cung cấp compute dạng máy chủ ảo, nơi khách hàng tự quản lý OS, bản vá, phần mềm cài trong máy.

Khi đề nhấn vào việc thuê tài nguyên hạ tầng thô (compute, storage, networking) và tự vận hành phần bên trên, đó là dấu hiệu kinh điển của IaaS. Đây cũng chính là lý do các phương án PaaS/FaaS/SaaS bị loại: chúng đều lấy đi quyền kiểm soát OS mà kịch bản "mang nguyên VM sang" bắt buộc phải có.

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

Đáp án đúng theo tệp là B — Infrastructure as a Service (IaaS).

IaaS là mô hình dịch vụ đám mây cung cấp các tài nguyên hạ tầng nền tảng — compute, storage, networking — theo nhu cầu, trả tiền theo mức dùng. Người dùng nhận về một máy chủ ảo và tự chịu trách nhiệm mọi thứ từ hệ điều hành trở lên.

Amazon EC2 đúng là mô tả đó: bạn chọn instance type, chọn AMI, rồi tự cài đặt và bảo trì phần mềm bên trong. Việc "lift and shift" một VM từ data center lên EC2 chỉ đơn giản là đổi nơi đặt máy ảo — mô hình vận hành vẫn giữ nguyên hình dạng cũ, và mô hình dịch vụ tương ứng ở phía cloud chính là IaaS.

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

A — Software as a Service (SaaS). SaaS là mô hình cấp phép và phân phối phần mềm thành phẩm theo dạng thuê bao, được host tập trung; người dùng chỉ mở ra dùng, không đụng tới hạ tầng lẫn mã nguồn. Ở đây công ty không mua một phần mềm dùng sẵn nào cả — họ mang chính máy ảo của mình lên và vẫn tự vận hành nó.

C — Function as a Service (FaaS). FaaS cho phép chạy đoạn mã để phản hồi sự kiện, ví dụ AWS Lambda. Đây là phương án dễ loại nhất về mặt hình dạng: FaaS không có khái niệm máy ảo tồn tại liên tục để mà "di chuyển sang". Muốn dùng FaaS thì phải viết lại ứng dụng thành các hàm, chứ không phải chuyển nguyên VM.

D — Platform as a Service (PaaS). Đây là phương án gần đúng nhất và cũng là bẫy chính, vì PaaS cũng chạy trên hạ tầng cloud và cũng phục vụ ứng dụng của khách hàng. Khác biệt: PaaS là nơi nhà cung cấp giao cho bạn cả phần cứng lẫn bộ công cụ phần mềm qua internet, thường phục vụ việc phát triển ứng dụng — bạn đưa mã ứng dụng vào, nền tảng lo phần OS và runtime. Kịch bản trong đề đi ngược lại: công ty đưa lên máy ảo có sẵn hệ điều hành của họ, không phải đưa mã lên một nền tảng dựng sẵn. Nói cách khác, PaaS hỏng ở chỗ nó che mất lớp OS — mà lớp OS chính là thứ đang được di chuyển.

📌 Điểm cần nhớ

• Ranh giới giữa các mô hình là ai quản lý lớp nào: IaaS bạn quản OS trở lên; PaaS nhà cung cấp lo OS và runtime, bạn chỉ lo ứng dụng; SaaS bạn chỉ dùng phần mềm; FaaS bạn chỉ nộp mã chạy theo sự kiện.
• Thấy đề nhắc EC2, máy ảo, instance, tự cài phần mềm, "lift and shift" → gần như chắc chắn là IaaS.
• Thấy đề nhắc chạy mã theo sự kiện, Lambda, không quản máy chủ → FaaS; thấy phần mềm dùng ngay theo thuê bao → SaaS.
• Chỉ riêng việc "chạy trên cloud" không quyết định được mô hình — phải nhìn xem đơn vị được đưa lên là gì: máy ảo (IaaS), mã ứng dụng (PaaS), hàm (FaaS), hay không đưa gì cả (SaaS).