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

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

Đề hỏi: loại database nào của AWS hợp nhất cho phân tích dữ liệu (analytics) bằng truy vấn SQL?

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

• "analytics" — phân tích, tổng hợp, quét khối lượng lớn để ra báo cáo. Đây không phải là công việc ghi/đọc từng bản ghi lẻ của ứng dụng nghiệp vụ.
• "using SQL queries" — bắt buộc phải truy vấn được bằng SQL chuẩn.

Nếu chỉ có "SQL queries" thì Amazon RDS cũng đúng; nếu chỉ có "analytics" thì đáp án mở rộng hơn. Chính sự kết hợp của hai ràng buộc — vừa analytics, vừa SQL — mới chỉ về một dịch vụ duy nhất. Thêm một chi tiết nữa: đề nói "type of AWS database", nên phương án nào không phải database thì loại ngay từ vòng đầu.

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

A — Amazon RedShift.

Redshift là data warehouse được quản lý hoàn toàn, sinh ra đúng cho bài toán phân tích: gom dữ liệu từ nhiều nguồn về một chỗ rồi chạy các truy vấn tổng hợp trên tập dữ liệu lớn. Nó dùng SQL chuẩn và ghép được với các công cụ Business Intelligence (BI) sẵn có, nên người phân tích không phải học ngôn ngữ truy vấn mới.

Khớp trọn vẹn cả hai ràng buộc trong đề: nó là một database (đúng nghĩa "type of AWS database"), nó phục vụ analytics, và nó nói SQL. Ở tầm Cloud Practitioner, chỉ cần nhớ liên kết một chiều: thấy data warehouse / analytics / BI / SQL trên dữ liệu lớn → nghĩ tới Redshift.

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

B — Amazon S3. Sai ngay ở loại dịch vụ: S3 là object storage, không phải database. Đây là phương án dễ gây phân vân nhất với người đã nghe qua chuyện "truy vấn dữ liệu trong S3 bằng SQL", nhưng đề hỏi rõ "type of AWS database" — S3 lưu object (tệp) chứ không có mô hình bảng, khoá, quan hệ hay engine truy vấn của riêng nó. Nó là nơi chứa dữ liệu, không phải nơi phân tích dữ liệu.

C — Amazon RDS. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi, vì RDS có dùng SQL — nếu chỉ đọc lướt hai chữ "SQL queries" thì rất dễ chọn. Chỗ hỏng: RDS là transactional database (OLTP), tối ưu cho các thao tác đọc/ghi ngắn, xử lý từng giao dịch của ứng dụng — đăng ký người dùng, đặt hàng, cập nhật hồ sơ. Nó không phải analytics database. Đề đã cài sẵn chữ "analytics" để tách RDS ra khỏi Redshift, nên bỏ qua chữ đó là mất điểm.

D — Amazon DynamoDB. Hỏng ở cả hai ràng buộc. DynamoDB là database kiểu NoSQL, không truy vấn bằng SQL chuẩn, nên riêng vế "using SQL queries" đã loại nó. Ngoài ra nó được thiết kế cho truy cập key-value/document với độ trễ thấp và ổn định, tức là mẫu truy cập của ứng dụng vận hành — không phải mẫu quét và tổng hợp toàn bộ tập dữ liệu của công việc analytics.

📌 Điểm cần nhớ

• Đọc đủ mọi ràng buộc trong đề trước khi chọn. Ở câu này "SQL queries" một mình không đủ để phân biệt Redshift với RDS; chữ "analytics" mới là chỗ chốt.
• Phân biệt hai vai trò: RDS phục vụ giao dịch (transactional/OLTP), Redshift phục vụ phân tích và báo cáo (data warehouse). Cùng nói SQL nhưng khác mục đích hoàn toàn.
• DynamoDB là NoSQL — hễ đề đòi SQL chuẩn thì loại thẳng, không cần cân nhắc thêm.
• S3 là object storage, không phải database. Khi đề hỏi "loại database nào", phương án nào không thuộc nhóm database sẽ bị loại ngay ở bước phân loại, trước cả khi xét tới yêu cầu về SQL hay analytics.

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

Đề hỏi: một database administrator (DBA) có thể làm gì để giảm operational overhead cho một database MySQL.

Cụm từ quyết định đáp án là "reduce operational overhead". Đây là từ khoá kinh điển của kỳ thi: nó không hỏi cách nào chạy được MySQL, cũng không hỏi cách nào rẻ nhất hay nhanh nhất — nó hỏi cách nào đẩy bớt việc vận hành sang cho AWS làm. Việc vận hành ở đây gồm: cài đặt và vá lỗi operating system, cài đặt và nâng cấp bản MySQL, sao lưu, khôi phục, giám sát, thiết lập replication và failover.

Cụm từ thứ hai cần để ý là "a MySQL database" — đáp án phải là thứ thực sự chạy được một database engine MySQL, chứ không phải một dịch vụ chỉ liên quan tới hạ tầng.

Hai ràng buộc này ghép lại loại được cả ba phương án còn lại: một cái chạy được MySQL nhưng không giảm việc vận hành, một cái không chạy được MySQL, và một cái không phải dịch vụ database.

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

C — Migrate the database onto an Amazon RDS instance.

Amazon RDS là managed database service và MySQL là một trong các engine mà RDS hỗ trợ. Khi chuyển sang RDS, AWS đảm nhận phần lớn công việc vận hành phía dưới: quản lý operating system bên dưới (DBA không có quyền và cũng không cần đăng nhập vào máy chủ), vá lỗi engine, sao lưu tự động và khôi phục về thời điểm, cũng như các cơ chế high availability và read replica được bật bằng cấu hình thay vì tự dựng.

Phần việc còn lại cho DBA thu về đúng những thứ thuộc chuyên môn database: thiết kế schema, tối ưu truy vấn, phân quyền người dùng, chọn cỡ instance. Đó chính là định nghĩa của "reduce operational overhead" — cùng một database MySQL, nhưng ít việc tay hơn hẳn.

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

A — Migrate the database onto AWS Lambda. AWS Lambda là dịch vụ compute kiểu functions as a service: chạy đoạn mã ngắn theo sự kiện rồi kết thúc. Nó không phải dịch vụ database và không phải nơi để cài đặt hay chạy một MySQL server. Lambda hoàn toàn có thể kết nối tới một database MySQL, nhưng bản thân nó không lưu trữ và phục vụ database đó. Phương án này sai về loại dịch vụ, không phải sai về mức độ tiện lợi.

B — Migrate the database onto an EC2 instance. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Chạy MySQL trên EC2 hoàn toàn khả thi — nó thực sự là một cách hợp lệ để có MySQL trên AWS. Chỗ nó hỏng là ở đúng yêu cầu của đề: EC2 thuộc mô hình tự quản, nên DBA vẫn phải tự cài và vá operating system, tự cài và nâng cấp MySQL, tự dựng lịch sao lưu, tự thiết lập replication và cơ chế chuyển đổi khi hỏng. Overhead không giảm, chỉ chuyển từ máy chủ dưới đất lên máy ảo trên cloud. Nếu đề hỏi "cách nào cho toàn quyền kiểm soát hệ điều hành và phiên bản engine" thì B mới là đáp án.

D — Use AWS CloudFormation to manage operations. CloudFormation là dịch vụ infrastructure as code: mô tả hạ tầng bằng template rồi tự động tạo, cập nhật, xoá stack. Nó giúp việc triển khai hạ tầng lặp lại được và ít sai sót, nhưng đó là chuyện dựng hạ tầng, không phải chuyện vận hành database hằng ngày. CloudFormation không vá MySQL cho bạn, không sao lưu database, không lo failover. Ngoài ra nó cũng không tự nó thay đổi việc database đang chạy trên nền gì — nếu template dựng ra một EC2 chạy MySQL thì overhead vẫn y nguyên như phương án B.

📌 Điểm cần nhớ

• "Reduce operational overhead" / "minimize management effort" là tín hiệu chọn dịch vụ managed. Với database quan hệ như MySQL, PostgreSQL, MariaDB, Oracle, SQL Server thì đó là Amazon RDS.
• EC2 so với RDS là cặp đối lập kinh điển: EC2 cho toàn quyền kiểm soát nhưng bạn gánh hết việc vận hành; RDS đổi quyền kiểm soát hệ điều hành lấy việc AWS lo vá lỗi, sao lưu và high availability. Đề nhấn "control" thì chọn EC2, nhấn "overhead/managed" thì chọn RDS.
• Đọc kỹ loại dịch vụ trước khi đọc ưu nhược điểm. Lambda là compute, CloudFormation là công cụ triển khai hạ tầng — cả hai đều không phải chỗ để chạy một database, nên loại được ngay mà không cần cân nhắc gì thêm.
• Tự động hoá việc triển khai không đồng nghĩa với giảm việc vận hành. CloudFormation dựng hạ tầng nhanh hơn, nhưng ai vá lỗi và sao lưu database thì vẫn phụ thuộc vào việc database đó chạy trên nền managed hay tự quản.

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

Đề hỏi: người quản trị hệ thống làm cách nào để chỉ định một script chạy trên EC2 instance trong lúc khởi chạy (during launch).

Cụm từ quyết định đáp án là "during launch" — nghĩa là script phải được cung cấp ngay tại thời điểm tạo/khởi động instance, chứ không phải một cơ chế nào đó tác động vào instance sau khi nó đã chạy. Cụm thứ hai cũng quan trọng là "specify a script": thứ cần tìm phải là nơi ta đưa nội dung script vào, chứ không phải nơi đọc thông tin ra hay nơi lưu trạng thái cấu hình.

Bốn phương án đều liên quan tới EC2 hoặc cấu hình AWS, nên nếu chỉ nhớ mang máng "cái nào liên quan tới cấu hình instance" thì rất dễ nhầm. Ràng buộc "during launch" là thứ cắt gọn danh sách xuống còn đúng một đáp án.

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

A. User Data là đáp án đúng.

Khi khởi chạy một instance trong Amazon EC2, bạn có tuỳ chọn truyền user data vào instance. Dữ liệu này được dùng để thực hiện các tác vụ cấu hình tự động thường gặp, và có thể chạy script sau khi instance khởi động. EC2 chấp nhận hai kiểu user data: shell script và cloud-init directive.

Đúng theo mô tả trong đề: user data là dữ liệu do người dùng cung cấp tại thời điểm khởi chạy instance, dưới dạng một script. Nó khớp trọn vẹn cả hai ràng buộc — vừa là nơi đặt script, vừa gắn với thời điểm launch.

Hai điểm nữa cần nhớ về user data: nó có giới hạn dung lượng (mức giới hạn theo tài liệu là 16KB), và user data cùng metadata đều không được mã hoá — nên đừng đặt secret vào đó.

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

B. AWS Config — Sai. Đây là dịch vụ lưu trữ thông tin cấu hình liên quan tới các dịch vụ AWS: nó ghi nhận và theo dõi trạng thái cấu hình của tài nguyên theo thời gian. Nó quan sát và ghi lại, chứ không phải nơi bạn nhét script vào để EC2 thực thi. Bẫy ở đây thuần tuý là chữ "Config" nghe giống "cấu hình instance".

C. Metadata — Đây là phương án gần đúng nhất và cũng nguy hiểm nhất, vì instance metadata đứng ngay cạnh user data trong cùng một cơ chế truy xuất trên instance. Chỗ hỏng của nó: metadata dùng để lấy (retrieve) thông tin về instance — instance id, kiểu instance, IP, thông tin mạng… Đó là chiều đọc ra, do hệ thống sinh ra, chứ không phải chiều đưa script vào để chạy. Đề hỏi "specify a script", nên metadata trượt ngay ở động từ.

D. Run Command — Cũng gần đúng, vì Run Command đúng là chạy được script/lệnh trên EC2 instance thật. Nhưng nó hỏng đúng ở ràng buộc thời điểm: Run Command hoạt động tách biệt với quá trình launch. Nó nhắm tới instance đang chạy để thực thi lệnh, chứ không phải cách bạn "chỉ định script trong lúc khởi chạy". Nếu đề bỏ chữ "during launch" thì phương án này mới có cửa.

📌 Điểm cần nhớ

• "During launch" + "script" ⇒ User Data. Đây gần như là một cặp khoá cố định trong đề thi Cloud Practitioner; thấy cụm này là chọn User Data.
• Phân biệt user data với metadata theo chiều dữ liệu: user data là thứ bạn đưa vào lúc launch (shell script hoặc cloud-init directive); metadata là thứ bạn đọc ra về chính instance đó.
• Phân biệt theo thời điểm tác động: User Data gắn với lúc khởi chạy; Run Command tác động lên instance đã chạy, nằm ngoài tiến trình launch.
• User data không được mã hoá và có giới hạn dung lượng — đừng đặt thông tin nhạy cảm vào đó, và đừng trông đợi nhét được script dài tuỳ ý.

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

Đề mô tả một công ty đang dùng AWS CLI và programmatic access tới tài nguyên AWS từ mạng on-premises của họ, rồi hỏi: đâu là yêu cầu bắt buộc (mandatory requirement) trong tình huống này.

Có hai cụm từ quyết định:

• "programmatic access" — nghĩa là truy cập bằng chương trình/dòng lệnh (CLI, SDK, gọi thẳng AWS API), không phải đăng nhập bằng username/password vào AWS Management Console. Hai kiểu truy cập này dùng hai loại thông tin xác thực khác nhau, và đây chính là chỗ câu hỏi nhắm tới.
• "mandatory requirement" — bắt buộc, không phải "nên có" hay "một trong các cách". Chi tiết "from its on-premises network" là mồi nhử: nó khiến người đọc nghĩ tới kết nối mạng riêng, trong khi thứ bắt buộc ở đây là danh tính để ký request, chứ không phải đường truyền.

Nói gọn: mỗi request gửi tới AWS API đều phải được ký (signed) bằng credentials hợp lệ. Không có credentials thì không có gì chạy được, bất kể mạng nối kiểu gì.

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

B — Using an AWS access key and a secret key.

Access key là long-term credentials của một IAM user (hoặc của AWS account root user). Chúng dùng để ký các request lập trình 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, phải dùng cùng nhau:

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

Cặp này đóng vai trò tương đương username và password, nhưng dành cho máy chứ không dành cho người: thiếu một trong hai thì request không ký được và AWS từ chối. Vì công ty gọi AWS từ mạng on-premises của chính họ — tức là từ ngoài AWS, nơi không có IAM role gắn sẵn vào instance để lấy credentials tự động — thì việc cấu hình access key ID và secret access key cho AWS CLI là điều không thể bỏ qua.

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

A — Using an AWS Direct Connect connection. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì đề có nhắc "on-premises". Nhưng Direct Connect không bắt buộc. AWS API và AWS CLI là các endpoint public, gọi được qua Internet bình thường. Direct Connect chỉ là một trong các lựa chọn khi cần đường truyền riêng hoặc cần tới tài nguyên private — bên cạnh VPN hay bastion host. "Một lựa chọn khả dĩ" khác hẳn "yêu cầu bắt buộc", mà đề hỏi vế thứ hai.

C — Using Amazon API Gateway. API Gateway là dịch vụ để bạn tự publish API của mình cho client bên ngoài gọi vào. Nó hoàn toàn không nằm trên đường đi khi bạn gọi AWS API bằng CLI hay SDK — AWS đã có sẵn endpoint riêng cho từng dịch vụ. Đặt API Gateway vào đây là hiểu ngược chiều: nó phục vụ API của khách hàng, không phải là cổng vào AWS API.

D — Using an Amazon EC2 key pair. Đây là bẫy dễ nhầm nhất về mặt tên gọi, vì cả hai đều có chữ "key". EC2 key pair dùng để đăng nhập an toàn vào chính EC2 instance (khoá SSH cho Linux, hoặc để giải mã mật khẩu administrator cho Windows). Nó không ký request tới AWS API, không liên quan tới IAM identity, và không giúp AWS CLI xác thực được. Ngoài ra tình huống trong đề không hề nói tới EC2 — họ truy cập "AWS resources" nói chung. Đừng lẫn EC2 key pair với access key.

📌 Điểm cần nhớ

• Ba cách xác thực, ba loại credentials khác nhau: Console dùng username + password (kèm MFA); CLI/SDK/API dùng access key ID + secret access key; đăng nhập vào EC2 instance dùng EC2 key pair. Câu hỏi kiểu này gần như luôn xoay quanh việc phân biệt ba thứ đó.
• Cụm "programmatic access" trong đề là tín hiệu gần như chắc chắn dẫn tới access key.
• Phân biệt "bắt buộc" với "có thể dùng": Direct Connect, VPN, bastion host đều là lựa chọn kết nối mạng, còn credentials là điều kiện xác thực không thể thiếu. Đề hỏi mandatory thì loại hết các phương án chỉ mang tính tuỳ chọn.
• Access key luôn đi theo cặp — access key ID (công khai được) và secret access key (phải giữ kín, chỉ hiện đúng một lần lúc tạo). Phương án nào chỉ nhắc một nửa thì đã thiếu.

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

Đề đặt tình huống rất đời thường: sếp yêu cầu bạn trình bày một số tính năng bảo mật trong AWS cloud, và câu hỏi cụ thể là mô tả chức năng của Amazon CloudHSM.

Đây là dạng câu "định nghĩa dịch vụ" — không có tình huống kiến trúc phức tạp, chỉ kiểm tra xem bạn có gắn đúng tên dịch vụ với đúng vai trò hay không. Cụm từ quyết định nằm ngay ở tên dịch vụ: HSM = Hardware Security Module. Đó là thiết bị phần cứng chuyên dụng để sinh, lưu trữ và sử dụng khoá mã hoá trong một ranh giới an toàn. Khi đề chỉ hỏi "function of CloudHSM", phương án đúng phải nói về key management, chứ không phải về việc mã hoá hộ một dịch vụ cụ thể nào, cũng không phải về lọc traffic.

Mẹo làm bài: nhóm "Security, Identity & Compliance" của AWS có nhiều dịch vụ dễ lẫn tên. Cứ neo vào chữ viết tắt trong tên — HSM là module khoá, WAF là firewall cho web app — thì bốn phương án tự tách ra ngay.

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

Đáp án đúng là B — "It can be used to generate, use and manage encryption keys in the cloud".

AWS CloudHSM là hardware security module chạy trên cloud, cho phép bạn thêm khả năng lưu trữ khoá an toàn và thực hiện các phép toán mật mã hiệu năng cao vào ứng dụng chạy trên AWS. Ba động từ trong phương án B — generate, use, manage — phủ đúng vòng đời khoá mà một HSM đảm nhận: tạo khoá bên trong thiết bị, dùng khoá để ký/mã hoá/giải mã mà khoá không rời khỏi ranh giới phần cứng, và quản trị khoá đó.

Ngoài ra CloudHSM là managed service: AWS lo giúp những việc quản trị tốn thời gian như cấp phát phần cứng, vá phần mềm, high availability và backup. Bạn cũng có thể start/stop HSM theo nhu cầu, không phải trả chi phí trả trước, nên cấp thêm năng lực đúng lúc cần.

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

A — "It provides server-side encryption for S3 objects". Đây là phương án gần đúng nhất và cũng là bẫy dễ dính, vì server-side encryption của S3 rõ ràng có dính tới khoá. Nhưng nó hỏng ở chỗ phân vai: CloudHSM làm nhiệm vụ quản lý khoá, chứ bản thân nó không thực hiện việc mã hoá object trong S3. Việc mã hoá object là chuyện của S3, và cơ chế server-side encryption mà S3 phơi ra không phải là chức năng mô tả CloudHSM. Nhận ra ranh giới "quản lý khoá" khác "mã hoá dữ liệu hộ dịch vụ khác" là chìa khoá loại A.

C — "It is a firewall for use with web applications". Sai hoàn toàn về loại dịch vụ — CloudHSM không cung cấp bất kỳ chức năng firewall nào. Mô tả này thuộc về AWS WAF (Web Application Firewall). Phương án kiểu này được đặt vào đề để bắt người học nhầm lẫn giữa các dịch vụ cùng nằm trong nhóm Security.

D — "It is a Public Key Infrastructure (PKI)". Đây là phương án tinh vi nhất, vì nó chạm đúng một phần sự thật: CloudHSM có thể sinh khoá bất đối xứng (asymmetric keys), mà khoá bất đối xứng là nguyên liệu của PKI. Nhưng sinh được khoá không đồng nghĩa với việc là một PKI — PKI là cả một hệ thống phát hành, phân phối, thu hồi và xác thực certificate. CloudHSM chỉ là thành phần lưu giữ và thao tác trên khoá, không phải là PKI. Nó gần đúng ở nguyên liệu, sai ở phạm vi.

📌 Điểm cần nhớ

• CloudHSM = generate, use, manage encryption keys trong một hardware security module được AWS quản lý. Câu nào mô tả CloudHSM mà không nói tới khoá thì gần như chắc chắn sai.
• Phân biệt rạch ròi "quản lý khoá" với "mã hoá dữ liệu": CloudHSM giữ và thao tác trên khoá; việc mã hoá object là do chính dịch vụ lưu trữ (như S3) thực hiện.
• CloudHSM sinh được khoá bất đối xứng nhưng không phải là PKI — sở hữu một thành phần không có nghĩa là đóng vai cả hệ thống. Đây là kiểu bẫy "đúng một nửa" hay gặp ở AWS Certified Cloud Practitioner.
• Với nhóm Security, Identity & Compliance, hãy neo vào chữ viết tắt trong tên dịch vụ: HSM là module khoá phần cứng, WAF mới là firewall cho web application — cách này loại nhanh những phương án mô tả nhầm dịch vụ.

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

Đề hỏi: "Which AWS service can serve a static website?" — dịch vụ AWS nào có thể phục vụ một website tĩnh.

Cụm từ quyết định đáp án là "serve a static website". Hai chữ này ràng buộc rất chặt:

• serve — dịch vụ phải trả nội dung về cho trình duyệt qua HTTP, chứ không phải chỉ phân giải tên miền, phân tích dữ liệu hay theo dõi ứng dụng.
• static — nội dung là các tệp có sẵn: HTML, CSS, JavaScript chạy phía client, ảnh. Không có mã chạy phía máy chủ, không cần môi trường thực thi, không cần cơ sở dữ liệu.

Chính chữ static là thứ tách câu này khỏi các câu hỏi về hosting nói chung: website tĩnh chỉ cần một nơi lưu tệp và trả tệp qua HTTP. Bốn phương án ở đây thuộc bốn nhóm dịch vụ hoàn toàn khác nhau, nên khi đã khoá được yêu cầu "trả tệp qua HTTP" thì chỉ còn đúng một ứng viên.

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

A — Amazon S3. S3 là dịch vụ lưu trữ đối tượng, và nó có sẵn tính năng static website hosting: bật tính năng này trên một bucket, S3 sẽ phục vụ nội dung trong bucket qua một website endpoint.

Các bước cấu hình theo đúng tài liệu:

1. Bật website hosting trên bucket.
2. Đặt permissions cho phép đọc nội dung công khai.
3. Tạo và tải lên index document (trang mặc định).

Ngoài ra, tuỳ nhu cầu còn cấu hình thêm được redirects, web traffic logging và custom error document.

Website tĩnh gồm các trang có nội dung tĩnh, và có thể chứa client-side script — script chạy trong trình duyệt người dùng vẫn là tĩnh với S3, vì S3 chỉ việc trả tệp .js về. Đây chính là điều S3 làm được: lưu tệp và trả tệp qua HTTP, không cần máy chủ ứng dụng nào.

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

B — Amazon QuickSight. Đây là dịch vụ business intelligence chạy trên cloud, dùng để dựng dashboard và đưa insight từ dữ liệu tới mọi người trong tổ chức. Nó có giao diện web và chia sẻ được dashboard, nên thoạt nghe dễ nhầm là "phục vụ nội dung web". Nhưng cái nó phục vụ là báo cáo dữ liệu do chính nó sinh ra, không phải các tệp HTML/CSS/JS mà bạn tự viết và tải lên. Không có khái niệm bucket, index document hay custom error document ở đây.

C — Amazon Route 53. Đây là dịch vụ DNS. Nó trỏ tên miền tới nơi chứa website — và trong thực tế người ta hay dùng Route 53 cùng với S3 để gắn tên miền tuỳ chọn cho website tĩnh. Chỗ hỏng nằm đúng ở đó: Route 53 chỉ trả lời câu hỏi "tên miền này ứng với địa chỉ nào", rồi trình duyệt mới đi lấy nội dung từ nơi khác. Bản thân Route 53 không lưu và không trả về tệp HTML nào. Đề hỏi dịch vụ nào serve website, không hỏi dịch vụ nào phân giải tên miền — đây là phương án gần đúng nhất và cũng là bẫy chính của câu này.

D — AWS X-Ray. Đây là dịch vụ tracing và debugging ứng dụng: theo dõi một request đi qua các thành phần của hệ thống, tìm điểm nghẽn và lỗi. Nó là công cụ quan sát ứng dụng đã chạy sẵn ở nơi khác, hoàn toàn không phải nơi lưu trữ hay phân phối nội dung web.

📌 Điểm cần nhớ

• "Static website" trong đề thi AWS gần như luôn dẫn về Amazon S3 — website tĩnh chỉ cần lưu tệp và trả tệp qua HTTP, đúng bản chất của object storage.
• Phân biệt rạch ròi ba vai trò dễ lẫn: Route 53 = DNS (trỏ tên miền), S3 = nơi chứa và phục vụ nội dung. Trỏ đường và giao hàng là hai việc khác nhau.
• Bật static website hosting trên S3 gồm ba việc bắt buộc: bật hosting, đặt permissions, tạo index document; redirects, logging và custom error document là tuỳ chọn thêm.
• Client-side script vẫn được coi là tĩnh. Trang có JavaScript chạy trong trình duyệt vẫn host trên S3 được; chỉ khi cần mã chạy phía máy chủ thì S3 mới không đủ.
• Đọc động từ trong đề: serve, store, route, trace, analyze — mỗi động từ khoá vào một nhóm dịch vụ khác nhau (QuickSight = analyze, X-Ray = trace).

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

Đề hỏi: công nghệ nào của AWS có thể được gọi là "virtual hard disk in the cloud" (ổ cứng ảo trên mây).

Cụm từ quyết định đáp án là chính phép ẩn dụ "virtual hard disk" — ổ cứng ảo. Một ổ cứng, dù là ổ vật lý hay ổ ảo gắn vào máy ảo, có ba đặc điểm: nó là block storage, nó được attach vào đúng một máy (một instance), và hệ điều hành trên máy đó nhìn thấy nó như một thiết bị khối rồi tự định dạng, tự đặt filesystem lên trên.

Đây chính là chỗ phân biệt bốn phương án: đề không hỏi "lưu trữ dữ liệu ở đâu" (thì cả EBS, EFS, S3 đều đúng), mà hỏi cái nào giống một cái đĩa gắn vào máy ở mức khối. Ai đọc lướt thành "dịch vụ lưu trữ của AWS" sẽ thấy ba phương án đều hợp lý; đọc kỹ chữ hard disk thì chỉ còn một.

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

A. Amazon EBS volume là đáp án đúng.

Amazon Elastic Block Store cung cấp block-level storage volumes gắn vào EC2 instance — đúng y như cách bạn gắn một virtual hard disk vào một máy ảo trong hạ tầng ảo hoá truyền thống. Từ trong instance, một EBS volume hiện ra như một thiết bị khối; bạn tạo partition, định dạng, mount rồi dùng như ổ cứng bình thường. Chính vì sự tương ứng một–một với mô hình đĩa ảo của VMware/Hyper-V mà tài liệu và giáo trình vẫn quen mô tả EBS volume là "ổ cứng ảo trên mây".

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

B. Amazon ENI — Elastic Network Interface là một cấu trúc mạng, không phải cấu trúc lưu trữ. Nó đại diện cho card mạng ảo gắn vào instance (mang IP riêng, security group, MAC address). Điểm dễ gây nhầm là ENI cũng "gắn vào instance" giống EBS volume, nên nếu chỉ nhớ mỗi ý attach mà quên ý disk thì rất dễ chọn nhầm. Nhưng ENI mang gói tin, không mang dữ liệu lưu trữ — nó là card mạng ảo, không phải ổ cứng ảo.

C. Amazon EFS Filesystem — đây là phương án gần đúng nhất, và cũng là bẫy chính. EFS đúng là được mount vào instance, nghe rất giống gắn ổ đĩa. Chỗ nó hỏng: EFS là file-level storage, truy cập qua giao thức NFS. Bạn mount sẵn một filesystem do AWS quản lý, chứ không nhận về một thiết bị khối để tự định dạng — hệ điều hành không thấy "một cái đĩa", nó thấy "một thư mục mạng". So sánh đúng của EFS là ổ đĩa mạng dùng chung (network file share), không phải virtual hard disk.

D. Amazon S3 Bucket — S3 là object-level storage. Nó không được mount và không được attach vào instance nào cả; bạn đọc ghi object qua REST API trên HTTPS. Không có khái niệm thiết bị khối, không có filesystem, không có việc format. Người mới học hay chọn S3 vì đó là dịch vụ lưu trữ nổi tiếng nhất của AWS, nhưng cách truy cập của nó khác hẳn một cái đĩa.

📌 Điểm cần nhớ

• Nhớ ba tầng lưu trữ và phép so sánh tương ứng: EBS = block (ổ cứng gắn vào một instance), EFS = file (thư mục dùng chung qua NFS), S3 = object (kho object gọi qua REST API/HTTPS). Rất nhiều câu Cloud Practitioner chỉ kiểm tra đúng ba dòng này.
• Từ khoá trong đề chỉ đường: thấy hard disk, block, volume, format/partition → nghĩ EBS. Thấy shared, mount by many instances, NFS → nghĩ EFS. Thấy object, API, bucket, key → nghĩ S3.
• Attach vào instance không đồng nghĩa với lưu trữ: ENI cũng attach vào instance nhưng thuộc nhóm networking. Khi phương án trộn lẫn dịch vụ mạng và dịch vụ lưu trữ, hãy phân loại theo bản chất dịch vụ trước khi so từng chi tiết.
• Với câu dạng "cái nào giống X nhất", hãy đối chiếu cách truy cập (block device / mount NFS / REST API) chứ đừng đối chiếu công dụng chung chung "để lưu dữ liệu" — cả ba dịch vụ lưu trữ đều lưu dữ liệu, chỉ cách truy cập mới tách được chúng.

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

Đề hỏi: support plan nào của AWS cho phép truy cập customer service 24x7?

Cụm từ quyết định đáp án là "customer service" — chứ không phải "technical support". Đây chính là chỗ câu này gài bẫy. Trong cách AWS phân chia dịch vụ hỗ trợ, hai khái niệm này hoàn toàn khác nhau:

• Customer service: hỏi về tài khoản, hoá đơn, thanh toán, thay đổi thông tin đăng ký, tăng service limit — những việc không mang tính kỹ thuật.
• Technical support: hỏi về cách dùng dịch vụ, gỡ lỗi kiến trúc, sự cố production — mới là thứ được phân tầng theo gói và theo thời gian phản hồi.

Người học quen với bảng so sánh support plan thường phản xạ ngay rằng "24x7 thì phải là gói trả tiền", rồi chọn Business. Phản xạ đó đúng khi đề hỏi về technical support 24x7, nhưng đề này hỏi customer service — và customer service, cùng với documentation, whitepapers và support forums, là phần AWS mở cho mọi khách hàng, kể cả người chưa mua gói hỗ trợ nào.

Chú ý thêm: đề dùng số nhiều "plans" ("Which AWS support plans"), một tín hiệu nhỏ cho thấy đáp án nhắm tới một tập hợp gói chứ không phải một gói đơn lẻ.

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

Đáp án đúng theo tệp là D — All plans.

Mọi support plan của AWS đều bao gồm quyền truy cập 24x7 tới customer service, cùng với documentation, whitepapers và support forums. Đây là phần nền chung, không phải quyền lợi phải trả thêm tiền mới có. Lý do hợp lý: những việc như thắc mắc về hoá đơn hay khoá tài khoản có thể xảy ra bất cứ lúc nào và ảnh hưởng trực tiếp tới khả năng tiếp tục dùng dịch vụ — AWS không thể chỉ phục vụ nhóm này cho khách hàng trả phí hỗ trợ.

Thứ khác nhau giữa các gói là phần technical support: gói cơ bản không có kênh hỏi kỹ thuật với kỹ sư của AWS, các gói cao hơn mới mở dần kênh này cùng thời gian phản hồi nhanh hơn, phạm vi tư vấn kiến trúc rộng hơn, và ở gói cao nhất là có người đồng hành riêng. Nhưng không quyền lợi nào trong số đó là thứ đề đang hỏi.

Vì đề hỏi đúng phần nền chung, và phần nền chung có ở tất cả các gói, "All plans" là câu trả lời duy nhất bao phủ đủ.

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

• A — Basic. Không sai về nội dung: gói Basic thực sự có customer service 24x7. Nó sai vì thiếu. Chọn Basic là ngầm khẳng định các gói còn lại không có quyền này, trong khi Business và Developer đều có. Đây là kiểu sai "đúng một phần nhưng không đầy đủ" — với câu hỏi dạng "plan nào có X" mà X là quyền lợi phổ quát, mọi phương án nêu tên một gói đơn lẻ đều tự động sai.

• B — Business. Đây là phương án gần đúng và hấp dẫn nhất, vì Business là gói được nhớ tới với cụm "24x7 support". Nhưng cái 24x7 gắn với Business là technical support — quyền mở ticket kỹ thuật bất kể giờ giấc, kèm mức độ ưu tiên cho sự cố production. Nếu đề viết "24x7 access to technical support" thì Business sẽ là hướng đúng. Ở đây đề viết "customer service", nên đặc quyền riêng của Business không liên quan, và giống trường hợp A, chọn nó là loại oan hai gói kia.

• C — Developer. Cũng sai vì cùng lý do thiếu bao phủ. Ngoài ra Developer còn là lựa chọn yếu nhất trong ba tên gói được nêu nếu người học nhầm đề sang technical support: gói này hướng tới môi trường thử nghiệm và phát triển, kênh hỗ trợ kỹ thuật của nó hạn chế hơn hẳn Business cả về thời gian phản hồi lẫn phạm vi. Nhưng dù xét theo hướng nào, Developer cũng không phải gói duy nhất có customer service 24x7.

📌 Điểm cần nhớ

• Trong bảng support plan của AWS, customer service ≠ technical support. Customer service lo tài khoản, hoá đơn, service limit; technical support lo vấn đề kỹ thuật. Đọc đề phải bắt đúng từ nào đang được hỏi.
• Customer service 24x7, documentation, whitepapers và support forums là phần chung của mọi gói, kể cả gói cơ bản. Cái phân tầng theo tiền là technical support.
• Khi một câu hỏi liệt kê vài tên gói cộng thêm phương án "All plans" hoặc "All of the above", hãy kiểm tra xem quyền lợi được hỏi có phải quyền lợi nền hay không — nếu có, phương án bao trùm mới đúng, và mọi phương án nêu một gói đơn lẻ đều sai vì thiếu.
• Đề dùng số nhiều ("Which support plans") là gợi ý đáng chú ý rằng đáp án là một tập hợp, không phải một gói riêng lẻ.

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

Đề hỏi: ưu điểm của việc chạy một database service như Amazon RDS trên cloud so với triển khai on-premise là gì? (Chọn HAI)

Cụm từ quyết định đáp án nằm ở chỗ "advantages ... in the cloud versus deploying on-premise". Đây là câu so sánh: phương án đúng phải là thứ mà cloud làm được còn on-premise thì khó hoặc không làm được. Cụm thứ hai cũng rất quan trọng: "a database service such as Amazon RDS" — RDS là managed service, không phải database bạn tự cài trên EC2. Managed nghĩa là AWS giữ phần hệ điều hành và giới hạn danh sách database engine được hỗ trợ; đó chính là cái bẫy để loại hai phương án nói về "full control" và "any database software you like".

Nói cách khác, phải phân biệt hai nhóm: ưu điểm thật của managed database (khả năng mở rộng, sẵn sàng cao) và những thứ nghe hay nhưng thực chất là điều bạn đánh đổi khi chọn managed service (quyền kiểm soát OS, tự do chọn engine), cộng thêm một phương án nói sai về chi phí.

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

B — High availability dễ triển khai hơn nhờ chức năng có sẵn cho read replica và multi-AZ. RDS có sẵn tính năng Multi-AZ và read replica: bật lên bằng cấu hình, AWS lo phần replicate và failover. Làm điều tương đương on-premise nghĩa là phải có hai trung tâm dữ liệu, tự dựng cơ chế replication, tự viết kịch bản chuyển đổi khi hỏng — công sức và chi phí ở mức hoàn toàn khác.

D — Scalability tốt hơn vì triển khai nhanh và nguồn tài nguyên dồi dào. Trên RDS, muốn mạnh hơn thì đổi instance type; muốn chịu tải đọc lớn hơn thì thêm read replica. On-premise, mở rộng nghĩa là mua phần cứng — qua quy trình mua sắm dài, rồi còn phụ thuộc vào việc hạ tầng riêng của bạn có còn chỗ trống hay không. Bản giải thích gốc nhấn đúng hai điểm này: không phải chờ chu kỳ mua sắm, và không phải lo hạ tầng riêng còn dư năng lực hay không.

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

A — "Không tốn chi phí khi replicate dữ liệu giữa các data center hoặc region". Sai thẳng về mặt sự kiện: việc replicate dữ liệu giữa các AZ và giữa các region có phát sinh chi phí, và phải tính vào bài toán giá. Đây là phương án dễ chọn nhầm nhất với người tin rằng "lên cloud là mọi thứ trong nội bộ AWS đều miễn phí". Bản thân khả năng replicate xuyên region là ưu điểm — nhưng câu này khẳng định miễn phí, và chính chữ đó làm nó sai.

C — "Bạn toàn quyền kiểm soát hệ điều hành và cài được công cụ vận hành của riêng mình". Đây là phương án gần đúng nhưng ngược dấu: với RDS bạn không có quyền truy cập vào hệ điều hành bên dưới — đó là phần AWS quản lý thay bạn. Hơn nữa, "toàn quyền kiểm soát OS" vốn là thứ mô hình on-premise đang có, nên dù có đúng thì nó cũng không phải "ưu điểm của cloud so với on-premise" — nó là điều bạn từ bỏ khi chuyển sang managed service.

E — "Dùng được bất kỳ phần mềm database nào bạn thích, linh hoạt hơn". Cũng ngược dấu như C. RDS chỉ hỗ trợ một danh sách hữu hạn các database engine; muốn chạy một engine ngoài danh sách thì phải tự cài lên EC2 hoặc giữ on-premise. Tự do chọn phần mềm là điểm mạnh của on-premise, không phải của RDS.

📌 Điểm cần nhớ

• Với câu dạng "cloud versus on-premise", hãy loại ngay những phương án mô tả quyền kiểm soát sâu (OS, phần cứng, tự chọn phần mềm) — đó là đặc trưng của on-premise, đồng thời là cái giá phải trả khi chọn managed service.
• Amazon RDS là managed service: bạn không chạm vào hệ điều hành và bị giới hạn trong danh sách engine mà dịch vụ hỗ trợ. Đổi lại bạn được các tính năng vận hành làm sẵn.
• Hai từ khóa nhận diện ưu điểm thật của RDS trong đề thi: Multi-AZ / read replica (high availability và mở rộng khả năng đọc) và đổi instance type nhanh (scalability không cần chu kỳ mua sắm phần cứng).
• Cảnh giác với phương án chứa từ tuyệt đối như "no costs", "any ... you like", "full control". Truyền dữ liệu giữa AZ và giữa region là có tính phí, nên bất kỳ khẳng định "miễn phí" nào ở đây đều sai.

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

Đề mô tả một tổ chức có văn phòng ở nhiều nơi trên thế giới, và một số nhân viên di chuyển giữa các văn phòng ("employees travel between offices"). Câu hỏi: nên thiết lập tài khoản của họ như thế nào?

Cụm từ quyết định là "travel between offices" — tức là cùng một con người sẽ đăng nhập từ nhiều vị trí địa lý khác nhau. Đề đang thăm dò một hiểu lầm rất phổ biến của người mới học AWS: nghĩ rằng mọi thứ trong AWS đều gắn với một region, nên đổi vị trí thì phải có tài khoản khác. Từ khoá còn lại là "accounts be setup" — đề hỏi về cách tạo/tổ chức danh tính, chứ không hỏi về cách bảo vệ danh tính. Đây chính là ranh giới tách phương án đúng khỏi phương án B.

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

Đáp án đúng theo tệp là C — "IAM is a global service, just create the users in one place".

IAM là một global service: các đối tượng IAM (user, group, role, policy) không thuộc về một region nào cả. Bạn tạo một IAM user một lần duy nhất trong AWS account, và danh tính đó có hiệu lực trên toàn bộ account, không phụ thuộc vào region hay vị trí mạng của người đăng nhập. Người dùng đó đăng nhập vào AWS Management Console từ bất kỳ văn phòng nào trên thế giới cũng dùng đúng bộ credentials đó.

Nói cách khác: việc nhân viên di chuyển giữa các văn phòng không phải là một vấn đề cần xử lý trong thiết kế IAM. Không có gì phải làm thêm — tạo user một chỗ là xong. Đó là lý do phương án này là câu trả lời hoàn chỉnh cho đề bài.

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

A — "Set the user account as a 'global' account when created": IAM không có thuộc tính hay tuỳ chọn nào tên là "global" khi tạo user. Phương án này nghe hợp lý vì nó dùng đúng từ khoá "global", nhưng nó đảo ngược nguyên nhân và kết quả: IAM global là bản chất của service, không phải một ô tick bạn bật lên cho từng user. Đây là kiểu phương án bẫy điển hình — lấy đúng thuật ngữ trong đáp án thật rồi biến nó thành một tính năng không tồn tại.

B — "Enable MFA for the accounts": Đây là phương án gần đúng nhất và cũng nguy hiểm nhất, vì bật MFA thực sự là một security best practice mà AWS luôn khuyến nghị. Nhưng nó không trả lời câu hỏi được đặt ra: MFA giải quyết bài toán xác thực mạnh hơn, chứ không giải quyết bài toán đăng nhập được từ nhiều vị trí. Nhân viên có bật MFA hay không thì vẫn đăng nhập từ bất cứ đâu như nhau. Chọn B là trả lời một câu hỏi khác — câu "làm sao cho an toàn hơn" chứ không phải "phải thiết lập tài khoản thế nào cho người hay đi lại".

D — "Create a separate account in IAM within each region in which they will travel": Đây chính là hiểu lầm mà đề đang thử. IAM user không tồn tại "trong một region", nên khái niệm tạo user trong từng region là không khả thi — trong Console cũng không có nơi nào để làm việc đó. Ngay cả nếu tưởng tượng có thể làm, cách này còn tạo ra một người dùng có nhiều bộ credentials rời rạc: vừa khó thu hồi khi họ rời công ty, vừa khó kiểm toán, vừa phải đồng bộ quyền ở nhiều nơi. Một danh tính cho một con người là nguyên tắc cơ bản.

📌 Điểm cần nhớ

• IAM là global service — user, group, role, policy không gắn với region; tạo một lần, dùng ở mọi nơi. Đề nào nhắc tới "nhiều region", "nhiều quốc gia", "nhân viên di chuyển" mà lại gợi ý nhân bản IAM identity thì gần như chắc chắn đó là phương án sai.
• Đọc kỹ đề hỏi cái gì. MFA là thực hành tốt nhưng chỉ đúng khi đề hỏi về bảo vệ danh tính; đề hỏi về cách tổ chức danh tính thì MFA là câu trả lời lệch chủ đề. Một phương án "đúng về mặt an toàn" không tự động là đáp án.
• Cảnh giác với phương án dùng đúng thuật ngữ nhưng bịa ra tính năng. "Set the account as global" mượn từ khoá của đáp án thật để nghe thuyết phục — hãy tự hỏi: tuỳ chọn đó có thật trong service không?
• Một người = một danh tính. Nhân bản tài khoản cho cùng một người theo vị trí, phòng ban hay region luôn làm hỏng khả năng thu hồi quyền và kiểm toán, kể cả trong những đề không nói tới IAM global.