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

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

Đề hỏi: loại lưu trữ nào chứa các object được cấu thành từ cặp key–value.

Cụm từ quyết định không phải là "key, value pairs" — nếu chỉ nhìn cụm đó thì cả Amazon S3 lẫn Amazon DynamoDB đều khớp. Cụm quyết định là "stores objects" đứng ngay trước nó, tức là câu hỏi đang định danh object storage (lưu trữ theo đối tượng). Đây là câu phân loại ba mô hình lưu trữ nền tảng mà AWS Certified Cloud Practitioner hỏi đi hỏi lại:

Đọc kỹ hai chữ "object" là loại được ngay ba phương án còn lại.

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

B — Amazon S3.

Amazon Simple Storage Service là dịch vụ object-based storage. Mỗi thứ bạn lưu vào S3 là một object, và object đó chính là một cặp key–value: key là tên định danh duy nhất của object trong bucket, còn value là chính khối dữ liệu (kèm metadata đi cùng). Bạn không mount S3 như một ổ đĩa và không ghi vào nó theo từng block — bạn PUT một object với một key, rồi GET nó ra bằng đúng key đó.

Đây là mô tả khớp từng chữ với đề bài: "stores objects comprised of key, value pairs". S3 được thiết kế cho lưu trữ quy mô web qua giao diện HTTP, và mô hình key–value phẳng chính là thứ cho phép nó mở rộng theo cách đó.

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

A — Amazon EFS. Đây là file-based storage: một hệ thống tệp chia sẻ, có cây thư mục, mount được đồng thời vào nhiều EC2 instance qua giao thức file. Đơn vị dữ liệu là file và directory, không phải object có key. EFS sai ngay ở mô hình lưu trữ, không liên quan gì tới key–value.

C — Amazon DynamoDB. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. DynamoDB đúng là cơ sở dữ liệu NoSQL kiểu key–value, nên nửa sau của đề bài ("key, value pairs") khớp hoàn toàn. Chỗ nó hỏng là ở nửa đầu: DynamoDB lưu item trong bảng, không lưu object. Item gồm các attribute, được định danh bằng primary key — đó là mô hình cơ sở dữ liệu, không phải mô hình object storage. Ngoài ra DynamoDB thuộc nhóm database chứ không thuộc nhóm storage như ba phương án còn lại. Đề bài hỏi "type of storage" và dùng chữ "objects", nên S3 mới là câu trả lời được nhắm tới.

D — Amazon EBS. Đây là block-based storage: volume gắn vào một EC2 instance, hệ điều hành nhìn thấy nó như một ổ đĩa thô và ghi dữ liệu theo từng block. Không có khái niệm key trỏ tới value; muốn dùng thì phải format và tạo file system lên trên. Sai mô hình hoàn toàn.

📌 Điểm cần nhớ

• Nhớ thuộc bộ ba mô hình lưu trữ của AWS: S3 = object, EBS = block, EFS = file. Rất nhiều câu ở mức Cloud Practitioner chỉ là biến thể cách hỏi của đúng bộ ba này.
• Khi đề dùng chữ "object", đáp án gần như luôn là Amazon S3; khi đề dùng chữ "item" hoặc "table", mới nghĩ tới DynamoDB. Cùng có cơ chế key–value nhưng thuật ngữ đơn vị dữ liệu là thứ phân biệt hai dịch vụ.
• Object trong S3 = key (tên định danh duy nhất trong bucket) + value (dữ liệu) + metadata. Nắm định nghĩa này là trả lời được cả những câu hỏi ngược lại kiểu "S3 định danh dữ liệu bằng gì".
• Phân biệt storage và database: DynamoDB nằm ở nhóm database. Khi đề bài mở đầu bằng "which type of storage", hãy ưu tiên các dịch vụ trong nhóm storage trước khi cân nhắc một database chỉ vì nó cũng dùng key–value.

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

Đề đặt ra một tình huống rất ngắn: một Cloud Practitioner đang xây disaster recovery plan và muốn sao chép dữ liệu giữa nhiều khu vực địa lý khác nhau. Câu hỏi là thành phần nào của hạ tầng AWS đáp ứng được yêu cầu đó.

Cụm từ quyết định là "between multiple geographic areas" — giữa nhiều khu vực địa lý. Đây chính là ràng buộc phân biệt bốn phương án, vì trong bốn thứ được nêu chỉ có đúng một thứ được định nghĩa theo vị trí địa lý tách biệt. Cụm "disaster recovery" là gợi ý phụ, củng cố cùng một hướng: mục tiêu của DR là chịu được sự cố ở quy mô lớn, nên bản sao dữ liệu phải nằm đủ xa bản gốc để không cùng chết vì một thảm hoạ.

Cách đọc đề kiểu này rất hay gặp trong bài thi Cloud Practitioner: đề mô tả một phạm vi (một data center, một khu vực trong thành phố, một vùng địa lý, một biên mạng gần người dùng) rồi hỏi thành phần nào khớp phạm vi đó. Việc cần làm là ánh xạ cụm từ mô tả phạm vi sang đúng tầng trong AWS Global Infrastructure.

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

Đáp án đúng theo tệp là D — AWS Regions.

AWS chia hạ tầng toàn cầu thành các Region, mỗi Region là một vùng địa lý riêng biệt trên thế giới. Trong mỗi Region lại có nhiều Availability Zone, là các cụm data center tách biệt về vật lý nhưng vẫn nằm trong cùng vùng địa lý đó. Nói cách khác, Region chính là đơn vị tương ứng với "geographic area" mà đề nhắc tới, còn AZ là đơn vị nhỏ hơn nằm bên trong.

Vì vậy, muốn sao chép dữ liệu giữa nhiều khu vực địa lý đúng như đề yêu cầu, việc cần làm là replicate dữ liệu giữa nhiều Region. Đó cũng là mô hình DR có sức chống chịu cao nhất: một sự cố diện rộng ảnh hưởng cả một Region vẫn không chạm tới bản sao nằm ở Region khác.

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

A — AWS Accounts. Account là ranh giới về quản trị và thanh toán: nó tách biệt quyền truy cập, hoá đơn, hạn mức tài nguyên giữa các nhóm hoặc môi trường. Nó hoàn toàn không phải một vị trí địa lý. Hai account khác nhau vẫn có thể chạy toàn bộ tài nguyên trong cùng một Region, nên tách account chẳng đem lại chút cách ly địa lý nào cho kế hoạch DR. Đây là phương án dễ loại nhất.

B — Availability Zones. Đây là phương án gần đúng nhất và là bẫy chính của câu này. AZ đúng là mang lại khả năng chịu lỗi thật: các AZ tách biệt về vật lý, có nguồn điện và hệ thống làm mát riêng, nên triển khai đa AZ chống được sự cố ở mức một data center. Nhưng chỗ nó hỏng nằm ở đúng cụm từ trong đề: các AZ nằm bên trong một Region, tức cùng một khu vực địa lý. Sao chép dữ liệu giữa các AZ là sao chép trong một vùng địa lý, không phải giữa nhiều vùng địa lý như đề đòi hỏi. Nếu đề chỉ nói "chịu lỗi khi một data center hỏng" thì AZ mới là đáp án; ở đây cụm "multiple geographic areas" loại nó ra.

C — Edge locations. Edge location là các điểm hiện diện đặt gần người dùng cuối, phục vụ chủ yếu cho việc cache nội dung của Amazon CloudFront nhằm giảm độ trễ khi phân phối. Chúng không phải nơi bạn chủ động replicate và lưu trữ dữ liệu của mình để phục hồi sau thảm hoạ — nội dung ở đó là bản sao tạm phục vụ phân phối, không phải bản lưu bền vững do bạn kiểm soát. Đúng là edge location trải rộng về mặt địa lý, nên nghe qua có vẻ khớp với chữ "geographic", nhưng vai trò của chúng là tăng tốc phân phối chứ không phải làm đích đến cho DR.

📌 Điểm cần nhớ

• Thứ tự phạm vi trong AWS Global Infrastructure: Region (vùng địa lý) chứa nhiều Availability Zone (cụm data center tách biệt về vật lý trong cùng vùng). Đề nhắc "geographic area" hay "geographically separate" thì đáp án là Region; đề nhắc "chịu lỗi trong cùng một khu vực", "một data center hỏng" thì đáp án là AZ.
• Disaster recovery ở quy mô lớn ⇒ nghĩ tới nhiều Region. Đa AZ chống được sự cố hạ tầng cục bộ, nhưng chỉ đa Region mới tách được bản sao khỏi một sự cố ảnh hưởng cả vùng địa lý.
• AWS Account là ranh giới quản trị và thanh toán, không phải ranh giới địa lý. Đừng để nó lọt vào các câu hỏi về vị trí hay tính sẵn sàng.
• Edge location gắn với CloudFront và việc cache để giảm độ trễ, không phải nơi lưu bản sao dữ liệu cho DR. Gặp phương án này trong câu hỏi về sao lưu/phục hồi thì gần như luôn là bẫy.

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

Đề hỏi: loại EBS volume nào có thể được mã hoá? Câu hỏi ngắn nhưng cả bốn phương án đều xoay quanh đúng một trục phân biệt: root volume có được mã hoá không, và mã hoá có bị ràng buộc phải tạo từ snapshot hay không.

Cụm từ quyết định nằm ngay ở chỗ "Which type of EBS volumes" — đề không hỏi "mã hoá bằng cách nào", cũng không hỏi "mã hoá lúc nào", mà hỏi phạm vi áp dụng của EBS encryption. Mỗi phương án sai đều dựng lên một giới hạn nhân tạo: chỉ non-root, chỉ non-root tạo từ snapshot, hoặc chỉ root. Đây là kiểu câu kiểm tra xem thí sinh có còn nhớ giới hạn cũ đã bị gỡ bỏ hay không.

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

Đáp án đúng theo tệp là C — "Both non-root and root volumes".

Amazon EBS encryption là giải pháp mã hoá sẵn có cho tài nguyên EBS, không đòi bạn phải tự dựng và vận hành hạ tầng quản lý khoá riêng. Nó dùng customer master key (CMK) của AWS KMS khi tạo volume và snapshot được mã hoá.

Điểm mấu chốt: thao tác mã hoá diễn ra trên chính máy chủ vật lý đang chạy EC2 instance, nên vừa bảo vệ dữ liệu ở trạng thái nghỉ (data-at-rest) vừa bảo vệ dữ liệu truyền giữa instance và EBS volume gắn kèm (data-in-transit). Vì cơ chế nằm ở tầng hạ tầng chứ không nằm ở tầng hệ điều hành hay ứng dụng, nó không quan tâm volume đó là root hay không — với hypervisor thì cả hai đều chỉ là block storage.

Ngoài ra, mọi volume đều có thể được mã hoá ngay tại thời điểm launch, và tài khoản còn có thể đặt mã hoá làm thiết lập mặc định. Root volume vì thế nằm hoàn toàn trong phạm vi — chính là điều phương án C khẳng định.

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

A — "Non-root volumes only": đơn giản là sai. Đây là phương án bẫy dựa vào ký ức về một giới hạn cũ, thời root volume chưa mã hoá trực tiếp được và người ta phải đi vòng qua snapshot rồi copy có mã hoá. Giới hạn đó không còn; root volume mã hoá được như mọi volume khác.

B — "Only non-root volumes created from snapshots": phương án gần đúng nhất và cũng nguy hiểm nhất, vì nó nhắc tới một luồng làm việc có thật — tạo volume mã hoá từ snapshot là chuyện hoàn toàn hợp lệ. Nhưng nó hỏng ở chỗ biến một cách làm thành điều kiện bắt buộc. Bạn mã hoá được mọi EBS volume, bất kể nó có được tạo từ snapshot hay không. Thêm nữa, phương án này còn kèm luôn giới hạn "non-root" đã sai sẵn ở A — sai hai tầng.

D — "Only root volumes can have encryption applied at launch time": đảo ngược A, và cũng sai. Đề cập đúng khái niệm "at launch time" nhưng gán độc quyền cho root volume. Thực tế tất cả volume đều có thể được mã hoá tại thời điểm launch, không riêng gì root. Từ khoá "Only" là chỗ chết của phương án này.

📌 Điểm cần nhớ

• EBS encryption áp dụng cho mọi volume — root lẫn non-root, tạo mới lẫn tạo từ snapshot. Bất kỳ phương án nào dựng lên giới hạn "chỉ loại này, không loại kia" đều đáng nghi ngay từ đầu.
• Mã hoá thực hiện trên máy chủ host EC2 instance, nên bảo vệ cả data-at-rest lẫn data-in-transit giữa instance và EBS volume. Vì nằm dưới tầng OS, nó không phân biệt vai trò của volume.
• Khoá do AWS KMS (CMK) quản lý — đây là lý do bạn không phải tự xây và bảo vệ hạ tầng quản lý khoá.
• Có thể bật mã hoá ngay lúc launch, và đặt làm mặc định cho tài khoản. Gặp phương án nói "at launch time" chỉ dành riêng cho một loại volume thì đó là bẫy.
• Mẹo chung với dạng câu này: cảnh giác với các từ khoá tuyệt đối như only, non-root only, created from snapshots. Chúng thường mô tả một giới hạn cũ đã được AWS gỡ bỏ, hoặc biến một cách làm hợp lệ thành điều kiện bắt buộc.

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

Đề bài hỏi: phát biểu nào là ĐÚNG về Amazon S3 cross-region replication (CRR)?

Đây là dạng câu "chọn phát biểu đúng", không có tình huống kiến trúc nào để suy luận — nên cụm từ quyết định nằm ngay trong từng phương án chứ không nằm trong đề. Ba phương án A, B, C đều được viết theo kiểu đảo ngược một điều kiện thật của CRR: "cannot be in different Regions" (thay vì phải khác Region), "Regions disabled" (thay vì enabled), "versioning disabled" (thay vì enabled). Chỉ có phương án D phát biểu một điều kiện đúng nguyên bản.

Cụm từ chốt của câu này là "cross-region" trong chính tên tính năng, cộng với ba từ phủ định gài trong A, B, C: cannot, disabled, disabled. Chiến thuật làm bài: đọc từng phương án và tự hỏi "đây là điều kiện thật hay là bản đảo ngược của điều kiện thật?".

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

D — "S3 buckets configured for cross-region replication can be owned by a single AWS account or by different accounts".

S3 replication cho phép sao chép object tự động và bất đồng bộ giữa các bucket. Về quyền sở hữu, bucket nguồn và bucket đích có thể thuộc cùng một AWS account, hoặc thuộc hai account khác nhau — cả hai mô hình đều được hỗ trợ.

Đây chính là điều làm cho replication dùng được cho các kịch bản như tách bản sao dữ liệu sang một account riêng biệt phục vụ backup/compliance, chứ không bị giới hạn trong phạm vi một account. Phát biểu ở D mô tả đúng khả năng này, nên nó là đáp án đúng.

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

A — "The source and destination S3 buckets cannot be in different AWS Regions" Sai, và sai ngược hoàn toàn với ý nghĩa của tính năng. Tên gọi cross-region replication đã nói rõ bucket nguồn và bucket đích nằm ở hai Region khác nhau. Ngoài ra S3 replication còn hỗ trợ sao chép trong cùng một Region nữa — tức là cả hai chiều đều được, không hề có ràng buộc cấm khác Region như phương án này khẳng định.

B — "The source S3 bucket owner must have the source and destination AWS Regions disabled for their account" Đây là phương án gần đúng nhất, vì nó chạm vào một điều kiện có thật: chủ sở hữu bucket nguồn đúng là phải quan tâm tới trạng thái của cả Region nguồn lẫn Region đích đối với account của mình. Nhưng nó hỏng ở đúng một từ: phải là enabled, không phải disabled. Region bị disable thì account không dùng được Region đó, nên không thể là nơi nhận bản sao. Tương tự, chủ sở hữu bucket đích cũng phải có Region đích ở trạng thái enabled. Đảo enabled thành disabled biến một điều kiện đúng thành một câu vô nghĩa.

C — "Both source and destination S3 buckets must have versioning disabled" Cũng là kiểu đảo ngược. Điều kiện thật là cả bucket nguồn và bucket đích đều phải BẬT versioning thì replication mới cấu hình được. Lý do nằm ở cơ chế: replication làm việc theo từng object version, nó cần định danh version để biết bản nào đã sao chép và bản nào chưa. Tắt versioning là không có gì để bám vào, và S3 sẽ không cho bật replication. Phương án này giữ đúng vế "both source and destination buckets" nhưng lật ngược trạng thái versioning, nên sai.

📌 Điểm cần nhớ

• Điều kiện bắt buộc của S3 replication: versioning phải được BẬT ở cả bucket nguồn lẫn bucket đích. Đây là chi tiết bị hỏi đi hỏi lại ở nhiều biến thể câu, và cũng là chỗ hay bị gài bằng chữ disabled.
• Quyền sở hữu bucket linh hoạt: cùng một AWS account hoặc hai account khác nhau đều được — replication không giới hạn trong phạm vi một account.
• Replication không chỉ là cross-region: sao chép được giữa hai Region khác nhau và trong cùng một Region. Phương án nào nói "không thể khác Region" hoặc "bắt buộc phải khác Region" đều đáng nghi.
• Region phải ở trạng thái enabled cho account tương ứng — chủ bucket nguồn cần cả Region nguồn và Region đích enabled, chủ bucket đích cần Region đích enabled.
• Mẹo làm bài dạng "phát biểu nào đúng": soi các từ cannot, disabled, must not. Đề thường lấy một điều kiện thật rồi lật phủ định để tạo ra mồi nhử trông rất quen mắt.

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

Đề bài hỏi rất ngắn: "What is an Edge location?" — Edge location là gì trong hạ tầng toàn cầu của AWS.

Cụm từ quyết định ở đây chính là bản thân thuật ngữ Edge location. Đây là câu kiểm tra khái niệm về AWS Global Infrastructure, nơi có ba lớp khái niệm rất dễ lẫn: Region (vùng), Availability Zone (khu vực sẵn sàng) và Edge location. Người học cần nhận ra rằng Edge location không phải nơi đặt tài nguyên tính toán hay lưu trữ của bạn, mà là điểm hiện diện (point of presence) đặt gần người dùng cuối để phân phối nội dung.

Vì đề chỉ có một chỗ trống khái niệm và bốn phương án mô tả bốn thành phần mạng hoàn toàn khác nhau, mấu chốt là gắn đúng Edge location với dịch vụ nào sử dụng nó. Chỉ có một dịch vụ trong danh sách gắn với khái niệm phân phối nội dung: CloudFront.

Đây cũng là câu chọn một đáp án (chonNhieuDapAn: false), nên không cần cân nhắc tổ hợp nhiều phương án.

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

Đáp án đúng theo tệp là C — "A content delivery network (CDN) endpoint for CloudFront".

Edge location chính là các CDN endpoint của Amazon CloudFront. Cách hoạt động: khi người dùng yêu cầu một tài nguyên đã được CloudFront phân phối, request đi tới Edge location gần họ nhất về mặt mạng thay vì đi thẳng tới origin (có thể nằm ở một Region cách nửa vòng trái đất). Nếu nội dung đã có sẵn trong cache tại đó, nó được trả về ngay — giảm độ trễ và giảm tải cho origin.

Điểm đặc trưng cần nhớ: số lượng Edge location nhiều hơn hẳn số lượng Region. Region là nơi AWS đặt các trung tâm dữ liệu đầy đủ (chứa nhiều Availability Zone), còn Edge location là các điểm nhỏ, phân bố dày ở nhiều thành phố, phục vụ đúng mục đích phân phối nội dung và xử lý ở biên mạng.

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

A — "A VPC peering connection endpoint"

VPC peering là kết nối mạng riêng giữa hai VPC, cho phép tài nguyên trong hai VPC gọi nhau bằng địa chỉ IP nội bộ. Đây là chuyện định tuyến nội bộ giữa các mạng riêng của bạn, hoàn toàn không liên quan tới hạ tầng phân phối nội dung ra người dùng cuối. Edge location không tham gia vào đường đi của traffic VPC peering.

B — "A virtual private gateway for VPN"

Virtual private gateway (VGW) là đầu phía AWS của một kết nối VPN site-to-site, dùng để nối mạng on-premises của bạn vào VPC. Phương án này nghe "có vẻ liên quan" vì nó cũng là một điểm đầu cuối mạng nằm ở biên của VPC, nhưng nó phục vụ kết nối lai (hybrid) riêng tư, không phải phân phối nội dung công khai. Nó cũng gắn với một VPC cụ thể trong một Region cụ thể, chứ không phải mạng lưới điểm hiện diện toàn cầu.

D — "A public endpoint for Amazon S3"

Đây là phương án gây nhầm nhiều nhất, vì S3 hay được dùng làm origin cho CloudFront, nên người học dễ ghép hai thứ làm một. Nhưng bản thân S3 endpoint là địa chỉ truy cập tới bucket nằm trong một Region cụ thể — nó là điểm đến của dữ liệu gốc, không phải điểm cache gần người dùng. Edge location đứng phía trước origin và có thể cache nội dung từ S3, nhưng nó không là S3 endpoint. Định nghĩa Edge location không phụ thuộc vào việc origin là S3, EC2, ALB hay một máy chủ ngoài AWS.

📌 Điểm cần nhớ

• Region → Availability Zone → Edge location là ba lớp khác nhau của AWS Global Infrastructure. Region và AZ là nơi bạn chạy tài nguyên; Edge location là nơi nội dung được phục vụ gần người dùng.
• Thấy cụm "Edge location" trong đề, hãy nghĩ ngay tới CloudFront và bài toán giảm độ trễ / cache nội dung, chứ không phải tới VPC, VPN hay lưu trữ.
• Edge location nhiều hơn Region rất nhiều — đó là lý do chúng có thể nằm gần người dùng cuối ở nhiều thành phố.
• Đừng lẫn origin với Edge location: S3 (hoặc EC2, ALB) là nơi chứa dữ liệu gốc; Edge location chỉ đứng trước nó để phân phối. Cùng một Edge location phục vụ được nhiều loại origin khác nhau.
• Các phương án nhắc tới VPC peering và virtual private gateway đều thuộc nhóm kết nối mạng riêng nội bộ/hybrid — chúng là bẫy phổ biến trong các câu hỏi về networking, vì nghe cũng giống "một điểm đầu cuối mạng".

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

Đề hỏi: đâu là lý do chính đáng để chuyển từ on-premises sang AWS Cloud, và yêu cầu chọn HAI.

Cụm từ quyết định nằm ngay trong từng phương án chứ không phải trong câu dẫn — đây là dạng câu "lợi ích của cloud", nên cách phân biệt là soi những từ tuyệt đối hoá trong các lựa chọn: end-to-end (toàn bộ đầu-cuối), free (miễn phí), all (toàn bộ). Ba từ này đều mô tả thứ mà mô hình cloud không hứa hẹn, vì cloud vận hành theo shared responsibility model — AWS lo phần "of the cloud", khách hàng lo phần "in the cloud". Hai phương án còn lại nói về agility, elasticity và right-sizing — đúng những từ khoá trong tài liệu Six Advantages of Cloud Computing của AWS.

Mẹo đọc đề: khi một phương án nghe như "bạn được tất cả mà không mất gì", gần như chắc chắn nó sai.

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

B — Improve agility and elasticity. Trên on-premises, muốn thêm năng lực xử lý phải mua máy, chờ giao hàng, lắp đặt — chu kỳ tính bằng tuần hoặc tháng. Trên AWS, tài nguyên được cấp phát bằng lời gọi API trong vài phút. Các dịch vụ như Auto Scaling, Elastic Load Balancing, và những dịch vụ co giãn sẵn như S3, Lambda cho phép hệ thống tự nở ra khi tải tăng và co lại khi tải giảm. Đó chính là định nghĩa của agility (nhanh chóng thử nghiệm, triển khai) và elasticity (khớp năng lực với nhu cầu thực tế).

D — Reduce costs through easier right-sizing of workloads. Right-sizing là việc chọn đúng cỡ tài nguyên cho khối lượng công việc, không thừa không thiếu. On-premises buộc phải mua dư để dự phòng đỉnh tải, và phần dư đó nằm chết quanh năm. Trên AWS, bạn theo dõi mức sử dụng, rồi đổi loại instance hoặc điều chỉnh cấu hình bằng thao tác lập trình được — chính khả năng elastic computing khiến việc right-sizing trở nên dễ, và tiết kiệm chi phí là hệ quả trực tiếp. Hai phương án này gắn với nhau về mặt nhân quả, nên chúng cùng đúng là hợp lý.

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

A — Gain end-to-end operational management of the entire infrastructure stack. Đây là phương án gần đúng nhất và dễ mắc bẫy, vì chuyển lên cloud đúng là bạn quản lý được nhiều thứ qua console/API. Nhưng nó hỏng ở chữ end-to-end và entire stack: chuyển lên AWS là bớt quyền kiểm soát ở tầng dưới chứ không phải thêm. AWS quản lý phần hạ tầng vật lý — trung tâm dữ liệu, phần cứng, mạng lõi — và với các dịch vụ quản trị (managed services) thì AWS lo luôn cả tầng nền tảng, có khi cả phần chạy ứng dụng. Nghịch lý: chính on-premises mới cho bạn quyền quản lý toàn bộ stack đầu-cuối.

C — Gain access to free technical support services. AWS không cung cấp technical support miễn phí. Support là dịch vụ có các mức trả phí; thứ miễn phí chỉ là tài liệu, diễn đàn và các câu hỏi liên quan tới tài khoản/thanh toán, không phải hỗ trợ kỹ thuật cho kiến trúc hay sự cố vận hành. Chữ free làm phương án này sai.

E — Outsource all security responsibility. Sai vì chữ all. Theo shared responsibility model, AWS chịu trách nhiệm bảo mật của đám mây (hạ tầng vật lý, ảo hoá), còn bạn vẫn chịu trách nhiệm bảo mật trong đám mây: cấu hình ứng dụng, quản lý người dùng và quyền, mã hoá và bảo vệ dữ liệu. Bạn chuyển giao được một phần gánh nặng bảo mật, không phải toàn bộ. Nếu đề viết "reduce some security overhead" thì đã là chuyện khác.

📌 Điểm cần nhớ

• Với câu hỏi về lợi ích cloud, hãy cảnh giác với các từ tuyệt đối: all, entire, end-to-end, free, guaranteed. Chúng gần như luôn đánh dấu phương án sai.
• Shared responsibility model là chìa khoá loại trừ ở nhiều câu: AWS lo security of the cloud, khách hàng lo security in the cloud — dữ liệu, danh tính, cấu hình ứng dụng luôn thuộc về khách hàng.
• Lên cloud nghĩa là đánh đổi quyền kiểm soát tầng thấp lấy tốc độ và độ co giãn, chứ không phải được thêm quyền kiểm soát.
• Bộ từ khoá ăn điểm của nhóm câu này: agility, elasticity, right-sizing, pay-as-you-go, không phải đoán trước dung lượng — gắn với Auto Scaling, Elastic Load Balancing, S3, Lambda.
• Technical support của AWS là dịch vụ có phí theo cấp độ, đừng nhầm với tài liệu và diễn đàn miễn phí.

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

Đề hỏi: những gì nằm trong bộ sản phẩm của Amazon Lightsail? — và bắt chọn HAI phương án.

Cụm từ quyết định là "product set" (bộ sản phẩm) đi kèm với Amazon Lightsail. Đây không phải câu hỏi "AWS có dịch vụ nào", mà là "Lightsail đóng gói sẵn những thứ gì bên trong nó". Rất nhiều phương án dưới đây đều là những thứ AWS chắc chắn có ở dạng dịch vụ riêng — nhưng chúng không nằm trong gói Lightsail. Ai đọc lướt thành "AWS có cái này không?" thì phương án nào cũng thấy đúng.

Lightsail sinh ra để cho người dùng không rành hạ tầng AWS (không muốn tự dựng VPC, subnet, security group…) vẫn chạy được ứng dụng với giá gói cố định, dễ đoán. Vì vậy nó gom lại đúng những khối cơ bản để dựng một website hay ứng dụng nhỏ.

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

C. Virtual Private Server — đây chính là hạt nhân của Lightsail. Lightsail instance là một virtual private server có sẵn hệ điều hành và thường có sẵn cả stack ứng dụng (WordPress, LAMP…), kèm địa chỉ IP, dung lượng lưu trữ và mức truyền dữ liệu gói theo giá tháng. Nếu chỉ được chọn một thứ đại diện cho Lightsail thì chính là cái này.

B. Managed MySQL database — Lightsail cung cấp managed database, và MySQL là engine nằm trong đó. AWS lo phần vá lỗi, sao lưu, cấu hình nền, người dùng chỉ chọn gói rồi kết nối. Điểm mấu chốt: đây là relational database dạng managed, khớp đúng với triết lý "gói sẵn, giá cố định" của Lightsail.

Ngoài hai thứ trên, bộ sản phẩm Lightsail còn có block/object storage, load balancer đơn giản hoá và CDN distribution — nhưng chúng không có trong danh sách phương án dưới dạng đúng nghĩa (xem phần dưới).

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

A. Serverless functions — Lightsail đi theo hướng ngược hẳn với serverless: nó bán cho bạn một máy chủ với tài nguyên cố định, tính tiền theo tháng bất kể bạn dùng nhiều hay ít. Serverless functions trên AWS là địa hạt của một dịch vụ khác hoàn toàn, không được đóng gói vào Lightsail. Đây là phương án dễ loại nhất trong ba phương án sai.

D. NoSQL database — đây là phương án gần đúng và bẫy nhất. Lightsail có managed database thật, nên người học đã nhớ mang máng "Lightsail có database" sẽ chọn cả B lẫn D. Chỗ hỏng nằm ở chữ NoSQL: managed database của Lightsail là relational engine (MySQL, PostgreSQL), không có lựa chọn NoSQL. Muốn NoSQL thì phải dùng dịch vụ riêng ngoài Lightsail. Bài học: khi hai phương án cùng nói về "database", hãy đọc kỹ loại database chứ đừng dừng ở từ "database".

E. File storage — cũng là phương án gần đúng theo kiểu khác. Lightsail có lưu trữ, nhưng là block storage (disk gắn vào instance) và object storage (bucket). "File storage" là một mô hình lưu trữ thứ ba — hệ thống tệp chia sẻ, gắn qua giao thức file, nhiều máy cùng mount một lúc — và mô hình đó không nằm trong bộ sản phẩm Lightsail. Chọn E là đúng ý "Lightsail có chỗ chứa dữ liệu" nhưng sai ở tên gọi kỹ thuật của mô hình lưu trữ.

📌 Điểm cần nhớ

• Lightsail = gói gọn cho người không muốn đụng VPC. Bộ sản phẩm gồm: virtual private server (instance), managed MySQL database, block và object storage, load balancer đơn giản hoá, CDN distribution. Nhớ đúng danh sách này là trả lời được cả họ câu hỏi về Lightsail.
• Phân biệt ba mô hình lưu trữ: block storage (disk gắn vào một máy), object storage (bucket, truy cập qua API), file storage (hệ thống tệp chia sẻ, nhiều máy cùng mount). Đề thi rất hay thay một từ trong ba từ này để tạo phương án sai.
• Managed database ≠ mọi loại database. Khi đề nêu "managed database", hãy hỏi tiếp: relational hay NoSQL? Lightsail chỉ có relational.
• Lightsail và serverless là hai triết lý đối lập: một bên là máy chủ tài nguyên cố định giá tháng, một bên là chạy code theo sự kiện không quản máy chủ. Thấy "serverless" trong phương án của câu hỏi về Lightsail thì gần như chắc chắn là mồi nhử.

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

Đề mô tả một công ty đang chạy nhiều relational database trên Amazon RDS. Hằng tháng, nhà cung cấp phần mềm database phát hành các bản vá bảo mật mới cần được áp dụng. Câu hỏi: cách nào là "MOST efficient" (hiệu quả nhất) để áp các bản vá đó?

Có hai cụm từ trong đề quyết định đáp án:

• "on Amazon RDS" — đây là managed service, không phải database tự cài trên EC2. Ranh giới trách nhiệm (shared responsibility model) đặt việc vá hệ điều hành và database engine về phía AWS, còn khách hàng chỉ điều khiển khi nào việc vá diễn ra.
• "MOST efficient" — mọi phương án ở đây đều nói về patching theo cách nào đó, nên thứ phân biệt chúng là mức độ thủ công và việc dịch vụ nêu ra có thật sự chạm được vào RDS hay không. Phương án đúng phải là cách tốn ít công sức vận hành nhất và dùng đúng cơ chế có sẵn của chính RDS.

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

D — Enable automatic patching for the instances using the Amazon RDS console.

RDS định kỳ thực hiện maintenance trên tài nguyên của nó: cập nhật phần cứng bên dưới, hệ điều hành bên dưới, hoặc phiên bản database engine. Các bản cập nhật cho hệ điều hành thường xuất phát từ vấn đề bảo mật và nên được áp càng sớm càng tốt.

Điểm mấu chốt: những bản vá bắt buộc liên quan tới bảo mật và độ tin cậy của instance được RDS tự lên lịch sẵn. Việc vá loại này diễn ra không thường xuyên và hiếm khi chiếm hết maintenance window.

Vì thế, tất cả những gì khách hàng cần làm là bật automatic patching và chỉ định maintenance window — khoảng thời gian mà việc vá sẽ diễn ra. Việc này khai báo được ngay lúc tạo DB instance, hoặc sửa lại bất cứ lúc nào sau đó, ngay trên Amazon RDS console. Đó chính là cách ít thao tác nhất: cấu hình một lần, sau đó RDS tự lo mọi tháng, không cần ai đụng tay vào từng instance nữa.

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

A — Connect to each database instance on a monthly basis, and download and apply the necessary security patches from the vendor. Đây là cách làm của database tự quản trên máy chủ riêng hoặc trên EC2. Amazon RDS là managed service, bạn không cần làm việc này thủ công. Ngoài ra nó cũng vi phạm trực tiếp yêu cầu "MOST efficient": kết nối vào từng instance, mỗi tháng, để tải và áp bản vá là khối lượng công việc lặp lại lớn nhất trong bốn phương án.

B — In AWS Config, configure a rule for the instances and the required patch level. AWS Config là dịch vụ dùng để audit và đánh giá cấu hình tài nguyên. Một rule của Config nói cho bạn biết instance có ở đúng patch level mong muốn hay không — tức là nó phát hiện sai lệch, chứ bản thân nó không phải cơ chế áp bản vá. Đây là phương án nghe hợp lý vì có nhắc đúng khái niệm "patch level", nhưng nó dừng lại ở việc quan sát: sau khi rule báo không tuân thủ, vẫn cần một cơ chế khác để thực sự vá.

C — Use AWS Systems Manager to automate database patching according to a schedule. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Systems Manager (với Patch Manager và maintenance window) đúng là công cụ tự động hoá việc vá theo lịch — nhưng cho EC2 instances. Nó không dùng để vá RDS instances được, vì với RDS bạn không có quyền truy cập vào hệ điều hành bên dưới để cài agent hay chạy lệnh vá. Phương án này mô tả đúng ý tưởng (tự động, theo lịch) nhưng gắn vào sai dịch vụ; ý tưởng đó với RDS đã có sẵn ngay trong chính RDS rồi.

📌 Điểm cần nhớ

• Với managed service như Amazon RDS, việc vá OS và database engine thuộc phần AWS lo; khách hàng chỉ chọn maintenance window và bật automatic patching. Thấy phương án nào bảo "đăng nhập vào từng instance để vá" cho RDS thì loại ngay.
• Phân biệt vai trò dịch vụ: AWS Config = audit/đánh giá cấu hình (phát hiện), Systems Manager = vận hành và vá EC2 (thực thi, nhưng cho instance bạn có quyền vào OS). Không dịch vụ nào trong hai cái đó là công cụ vá RDS.
• Khi đề hỏi "MOST efficient" mà nhiều phương án đều "làm được việc" trên lý thuyết, hãy chọn cơ chế có sẵn ngay trong chính dịch vụ đang được nhắc tới, thay vì ghép thêm một dịch vụ bên ngoài.
• Bẫy quen thuộc trong đề AWS: một phương án đúng về ý tưởng (tự động hoá theo lịch) nhưng sai về phạm vi áp dụng của dịch vụ. Luôn kiểm tra dịch vụ được nêu có thao tác được lên loại tài nguyên trong đề hay không.

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

Đề hỏi: theo AWS Shared Responsibility Model, việc nào khách hàng KHÔNG chịu trách nhiệm.

Cụm từ quyết định là chữ NOT viết hoa trong đề. Cả bốn phương án đều là những việc có thật trong vận hành AWS, và ba trong số đó là việc khách hàng làm hằng ngày — nếu đọc lướt thành "khách hàng chịu trách nhiệm việc nào" thì có tới ba đáp án đúng và câu hỏi trở nên vô nghĩa. Đây là câu đảo nghĩa: phải tìm việc thuộc về AWS.

Ràng buộc thứ hai nằm ở cụm "host servers" trong phương án C. Shared Responsibility Model chia đôi theo một đường ranh rất rõ: AWS lo security OF the cloud (phần cứng, host, hạ tầng mạng vật lý, lớp ảo hoá, cơ sở vật chất data center), khách hàng lo security IN the cloud (dữ liệu, cấu hình, quyền truy cập, mã hoá, tường lửa mềm). "Host server" là máy chủ vật lý chạy hypervisor — khách hàng không hề có quyền chạm vào nó, nên mọi việc gắn với nó đều nằm bên phía AWS.

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

C. Installing firmware updates on host servers — đúng.

Firmware là phần mềm nhúng trong chính phần cứng của máy chủ vật lý (BIOS/UEFI, firmware của card mạng, của ổ đĩa). Nó nằm bên dưới cả hypervisor, tức là bên dưới ranh giới mà khách hàng nhìn thấy được. Khách hàng thuê EC2 chỉ tiếp cận được tới máy ảo và hệ điều hành guest của mình; không có API nào, không có quyền nào cho phép họ vá firmware của host — và cũng không nên có, vì một host vật lý chạy nhiều khách hàng khác nhau.

Vá firmware, thay ổ hỏng, bảo trì phần cứng, an ninh vật lý của data center đều thuộc security of the cloud: AWS làm, và làm trong suốt với khách hàng.

Lưu ý phân biệt: khách hàng vẫn phải vá hệ điều hành guest trên EC2 instance của mình. Firmware của host và OS patch của guest là hai chuyện khác nhau, đề bài nói rõ "host servers".

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

A. Applying bucket policies to share Amazon S3 data — sai vì đây là việc của khách hàng. AWS đảm bảo hạ tầng S3 bền bỉ và sẵn sàng, nhưng ai được đọc bucket nào là do khách hàng khai trong bucket policy, IAM policy và các thiết lập chặn truy cập công khai. Đây chính là loại cấu hình mà khách hàng làm sai thì dữ liệu lộ ra ngoài — thuộc security in the cloud rõ ràng.

B. Adding firewall rules to security groups and network ACLs — sai vì cũng là việc của khách hàng. AWS cung cấp cơ chế security group và network ACL cùng hạ tầng mạng chạy chúng; còn luật mở cổng nào, cho dải IP nào thì khách hàng tự đặt. Đây là phương án dễ nhầm nhất với đáp án đúng, vì cả hai đều mang chữ "firewall" và nghe như chuyện hạ tầng. Chỗ hỏng của nó: security group là tường lửa mềm, cấu hình được bằng console/API mà khách hàng có toàn quyền — khác hẳn firmware của host mà khách hàng không chạm tới được.

D. Applying encryption to data stored on an EBS volume — sai vì mã hoá dữ liệu là trách nhiệm khách hàng. AWS cung cấp công cụ (mã hoá EBS, khoá quản lý bằng KMS), nhưng quyết định có bật mã hoá hay không, dùng khoá nào, xoay khoá ra sao là do khách hàng. Nguyên tắc chung trong mô hình này: dữ liệu và cách bảo vệ dữ liệu luôn thuộc về khách hàng.

📌 Điểm cần nhớ

• Ranh giới cốt lõi: AWS lo security OF the cloud (phần cứng, host, firmware, hypervisor, data center), khách hàng lo security IN the cloud (dữ liệu, cấu hình, IAM, mã hoá, luật tường lửa).
• Gặp câu Shared Responsibility Model, đọc kỹ chữ NOT / EXCEPT. Dạng đảo nghĩa rất hay xuất hiện ở chứng chỉ này và ba phương án còn lại thường đều đúng theo chiều thuận.
• Bất cứ thứ gì khách hàng không có API hay console để chạm vào thì đó là việc của AWS. Đây là phép thử nhanh và hầu như luôn cho kết quả đúng.
• Phân biệt guest OS patching (khách hàng làm, với EC2) và host firmware/hypervisor patching (AWS làm). Đề rất hay chơi chữ ở cặp này.
• Việc AWS cung cấp công cụ không có nghĩa AWS bật hộ: mã hoá EBS, bucket policy, security group đều là công cụ AWS dựng sẵn nhưng khách hàng phải tự cấu hình.

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

Đề bài rất ngắn: một ứng dụng được triển khai across multiple Availability Zones thì được mô tả bằng đặc tính nào?

Cụm từ quyết định là "deployed across multiple Availability Zones" — và cụ thể hơn nữa là hai chữ multiple AZ, chứ không phải multiple Region, cũng không phải "tự động thêm bớt instance theo tải".

Đây là dạng câu ánh xạ một hành động kiến trúc sang đúng một trong bốn trụ cột/đặc tính hay bị lẫn của AWS: high availability, elasticity, security, global reach. Mỗi phương án ứng với một hành động khác nhau, và đề chỉ mô tả đúng một hành động. Vậy nên cách làm là hỏi ngược: "trải ra nhiều AZ" là biện pháp chống lại rủi ro gì? Câu trả lời là chống lại việc hỏng một AZ — tức là bài toán về tính sẵn sàng.

Cũng để ý đề không nhắc gì tới Auto Scaling, không nhắc tới encryption/IAM/security group, và không nhắc tới nhiều Region hay CDN. Những gì đề không nói cũng quan trọng như những gì nó nói: mỗi từ khoá vắng mặt loại đi đúng một phương án.

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

Đáp án đúng theo tệp là A – Being highly available.

Availability Zone là các nhóm hạ tầng tách biệt về nguồn điện, làm mát và mạng bên trong một Region. Khi ứng dụng chỉ nằm trong một AZ, sự cố ở AZ đó làm ứng dụng ngừng phục vụ. Khi cùng ứng dụng đó chạy trên nhiều AZ, một AZ hỏng thì các AZ còn lại vẫn còn bản chạy được — đúng định nghĩa của high availability: hệ thống tiếp tục phục vụ khi một thành phần hạ tầng gặp sự cố.

Phần giải thích gốc bổ sung một ý đáng nhớ: để tính sẵn sàng đó thực sự phát huy tác dụng, cần có cơ chế điều hướng traffic tới các bản chạy ở từng AZ, điển hình là Elastic Load Balancer đặt trước các EC2 instance trải trên nhiều AZ. Bản thân việc nhân bản ra nhiều AZ là điều kiện cần; ELB là thứ khiến người dùng thực sự được chuyển sang AZ còn sống.

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

B – Having elasticity. Đây là phương án gần đúng nhất và cũng dễ bẫy nhất, vì nhiều kiến trúc thực tế có cả hai đặc tính cùng lúc. Nhưng elasticity nói về thay đổi số lượng tài nguyên theo tải — thêm instance khi tải tăng, bỏ bớt khi tải giảm — và cơ chế đại diện là Auto Scaling. Đề bài không hề nhắc tới Auto Scaling hay việc tăng giảm theo nhu cầu. Trải ứng dụng ra nhiều AZ mà số instance cố định thì vẫn highly available nhưng hoàn toàn không elastic. Hai khái niệm độc lập với nhau, và đề chỉ mô tả cái thứ nhất.

C – Being secure. Việc đặt instance ở AZ nào không phải là một biện pháp bảo mật. Security trên AWS được thể hiện qua những thứ khác hẳn: phân quyền, kiểm soát truy cập mạng, mã hoá dữ liệu. Đề bài không mô tả bất kỳ biện pháp nào trong số đó, nên không thể kết luận gì về tính bảo mật của ứng dụng này. Multi-AZ không làm ứng dụng an toàn hơn trước kẻ tấn công.

D – Having global reach. Phương án này đánh vào chỗ nhiều người lẫn AZ với Region. Global reach nói về việc phục vụ người dùng ở khắp nơi trên thế giới, thường bằng cách triển khai sang nhiều Region khác nhau hoặc đưa nội dung ra gần người dùng. Nhưng các AZ trong cùng một Region nằm gần nhau về mặt địa lý — trải ra nhiều AZ vẫn là ở đúng một Region, không mở rộng phạm vi địa lý phục vụ chút nào. Đề nói "multiple Availability Zones", không nói "multiple Regions", nên đây là đáp án sai vì đọc nhầm đơn vị hạ tầng.

📌 Điểm cần nhớ

• Multiple AZ → high availability. Multiple Region → global reach / disaster recovery diện rộng. Đọc kỹ đề dùng chữ AZ hay Region trước khi chọn; rất nhiều câu chỉ khác nhau đúng ở từ này.
• High availability ≠ elasticity. HA là chịu được hỏng hóc (nhân bản ra nhiều AZ); elasticity là co giãn theo tải (Auto Scaling). Không thấy chữ Auto Scaling hay "theo nhu cầu" trong đề thì đừng chọn elasticity.
• Nhân bản ra nhiều AZ mới là một nửa. Cần thêm cơ chế điều hướng traffic — điển hình là Elastic Load Balancer — thì việc một AZ hỏng mới thực sự không làm gián đoạn dịch vụ.
• Đừng suy diễn thêm đặc tính đề không nói. Đề không nhắc gì tới mã hoá hay kiểm soát truy cập thì không kết luận được về security; kỹ thuật này loại được rất nhanh những phương án "nghe cũng hợp lý".