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

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

Đề hỏi: làm sao bảo vệ dữ liệu Amazon S3 trước một thảm hoạ ở cấp region ("from a regional disaster").

Cụm từ quyết định là "regional disaster". Đây chính là ràng buộc phân biệt bốn phương án gần giống nhau ở chỗ chúng đều là tính năng bảo vệ dữ liệu của S3. Nhưng thảm hoạ cấp region nghĩa là toàn bộ region đó có thể không truy cập được — nên biện pháp duy nhất còn tác dụng là có một bản sao dữ liệu nằm ở region khác. Mọi thứ chỉ thay đổi storage class, thay đổi quyền xoá, hay chuyển sang dịch vụ lưu trữ khác mà vẫn nằm trong cùng region đều không giải quyết được vấn đề đề bài nêu.

Lưu ý bản chất S3: dữ liệu trong một bucket được lưu bền vững qua nhiều Availability Zone trong cùng một region. Đó là lý do S3 chịu được sự cố một AZ nhưng không tự động chịu được sự cố cả region — phải chủ động sao chép ra ngoài.

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

A — Use Cross-Region Replication (CRR) to copy to another region.

CRR là tính năng sao chép object của S3 sang một bucket đặt ở AWS Region khác. Khi bật, các object mới ghi vào bucket nguồn được sao chép tự động và không đồng bộ (asynchronous) sang bucket đích ở region kia.

Đây là phương án duy nhất trong danh sách thực sự đưa dữ liệu ra khỏi region gốc. Nhờ vậy, nếu region nguồn gặp thảm hoạ, bản sao ở region đích vẫn còn nguyên và truy cập được — đúng nghĩa disaster recovery. Bản giải thích gốc cũng chốt đúng điểm này: "The only option here that will help is to use CRR to copy the data to another region."

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

B — Use lifecycle actions to move to another S3 storage class. Lifecycle rule chuyển object giữa các storage class (ví dụ sang lớp truy cập không thường xuyên hoặc lớp lưu trữ lâu dài) để tối ưu chi phí theo tuổi của object. Nhưng việc đổi storage class diễn ra bên trong chính bucket đó, tức trong cùng region. Region sập thì dữ liệu ở mọi storage class trong region đó đều không truy cập được. Đây là công cụ quản lý chi phí, không phải công cụ chống thảm hoạ vùng.

C — Enable Multi-Factor Authentication (MFA) delete. MFA delete là lớp bảo vệ chống thao tác xoá ngoài ý muốn hoặc trái phép: muốn xoá vĩnh viễn một phiên bản object (hoặc tắt versioning) thì phải xuất trình mã MFA. Nó chống con người xoá nhầm/xoá ác ý, hoàn toàn không liên quan tới việc dữ liệu có tồn tại ở nơi thứ hai hay không. Region sập thì MFA delete chẳng giúp gì — dữ liệu vẫn chỉ nằm ở đúng một region.

D — Archive to Amazon Glacier. Đây là phương án dễ chọn nhầm nhất, vì Glacier gợi cảm giác "lưu trữ dài hạn, an toàn, kiểu backup". Nhưng chỗ hỏng nằm ở vị trí địa lý: khi archive sang Glacier, dữ liệu vẫn nằm trong cùng region với bucket S3 nguồn. Nó đổi lớp lưu trữ và mô hình truy xuất (rẻ hơn, lấy ra chậm hơn) chứ không hề nhân bản dữ liệu ra region khác. Bản giải thích gốc nói thẳng: "Moving to Glacier does not copy the data out of the region." Về bản chất, D mắc đúng lỗi giống B — chỉ khác cách diễn đạt.

📌 Điểm cần nhớ

• Thấy từ khoá "regional disaster" / "region failure" / "another region" trong đề S3 → gần như luôn là Cross-Region Replication (CRR). Chỉ phương án nào tạo bản sao ở region khác mới trả lời được câu hỏi này.
• Phân biệt rõ ba nhóm tính năng S3 dễ bị trộn lẫn trong đề trắc nghiệm: storage class / lifecycle = tối ưu chi phí; MFA delete / versioning = chống xoá nhầm hay xoá trái phép; replication = chống mất mát ở phạm vi region.
• Amazon Glacier không phải là "nơi khác" — nó là lớp lưu trữ nằm trong cùng region. Archive ≠ đưa dữ liệu ra khỏi vùng rủi ro.
• S3 vốn đã bền vững qua nhiều Availability Zone trong một region, nhưng ranh giới bảo vệ mặc định dừng ở cấp region. Muốn vượt qua ranh giới đó thì phải chủ động cấu hình sao chép liên region.

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

Đề hỏi: những khoản phí nào áp dụng cho lớp lưu trữ Amazon S3 Standard? — và yêu cầu chọn HAI phương án.

Cụm từ quyết định nằm ngay trong đề: "S3 Standard storage class". Đây không phải câu hỏi chung chung về "S3 tính tiền thế nào", mà hỏi riêng lớp Standard. Năm phương án đưa ra là năm khoản phí có thật trong hệ sinh thái S3, nhưng mỗi khoản gắn với một lớp lưu trữ khác nhau. Ai đọc lướt thành "phí của S3" sẽ thấy phương án nào cũng quen tai và chọn nhầm.

Ràng buộc thứ hai, ít ai để ý: "(Select TWO)". Con số này tự nó loại bớt phân vân — nếu bạn thấy ba, bốn phương án đều hợp lý thì chắc chắn đang nhầm đặc điểm của lớp khác sang Standard.

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

B — Per GB/month storage fee. Đây là khoản phí nền của mọi lớp lưu trữ S3, kể cả Standard: bạn trả tiền theo dung lượng dữ liệu đang nằm trong bucket, tính theo GB trên mỗi tháng. Không có lớp nào miễn khoản này.

E — Data egress. Dữ liệu đi ra khỏi S3 (transfer out) bị tính phí. Đây là mô hình chung của AWS: chuyển dữ liệu ra ngoài là hạng mục có tính tiền, và với S3 Standard thì đó chính là khoản phí thứ hai bên cạnh phí lưu trữ.

Hai khoản này gộp lại cho bức tranh đúng của S3 Standard: trả tiền để giữ dữ liệu, và trả tiền khi lấy dữ liệu ra khỏi AWS. Đơn giản hơn các lớp khác đúng một bậc.

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

A — Minimum capacity charge per object. Đây là đặc điểm của S3 Standard-IA và One Zone-IA, không phải Standard. Ở các lớp infrequent access, một object nhỏ vẫn bị tính như thể nó đạt một dung lượng tối thiểu nhất định — cái giá phải trả để đổi lấy đơn giá lưu trữ rẻ hơn. Standard không có ràng buộc đó: lưu bao nhiêu tính bấy nhiêu. Đây là phương án gài bẫy nặng nhất vì nó đúng với S3, chỉ sai lớp.

C — Retrieval fee. Cũng là bẫy cùng kiểu. Phí truy xuất áp dụng cho Standard-IA, One Zone-IA và các lớp Glacier — bạn trả thêm mỗi lần đọc dữ liệu ra, và đó chính là lý do các lớp này rẻ hơn khi lưu. Standard được thiết kế cho dữ liệu truy cập thường xuyên nên không có phí retrieval. Ai đang nghĩ tới Glacier lúc đọc đề sẽ chọn phương án này.

D — Data ingress. Sai với mọi lớp lưu trữ S3, không riêng Standard: đưa dữ liệu vào S3 không mất phí transfer. Đây là điểm nhất quán trong mô hình giá của AWS — họ không thu tiền để bạn mang dữ liệu vào. Phương án này không "gần đúng" ở bất kỳ lớp nào, nên nếu chọn nó thì đang nhầm về nguyên lý chứ không phải nhầm lớp.

📌 Điểm cần nhớ

• S3 Standard chỉ có hai khoản phí cần nhớ cho kỳ thi: phí lưu trữ theo GB/tháng và phí data transfer out (egress). Không phí truy xuất, không dung lượng tối thiểu mỗi object.
• Minimum capacity charge per object và retrieval fee là dấu hiệu nhận diện các lớp infrequent access và archive (Standard-IA, One Zone-IA, Glacier). Thấy hai cụm này trong phương án mà đề hỏi về Standard thì loại ngay.
• Data ingress luôn miễn phí ở mọi lớp S3 — đây là quy tắc không có ngoại lệ, dùng để loại phương án nhanh mà không cần suy nghĩ về lớp lưu trữ.
• Với câu hỏi so sánh lớp lưu trữ, hãy đọc kỹ tên lớp cụ thể trong đề trước khi xét các phương án; đa số bẫy được dựng bằng cách lấy đặc điểm đúng của một lớp khác gán sang.

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

Đề hỏi: khi thiết kế một VPC, Internet Gateway dùng để làm gì.

Cụm từ quyết định nằm ở chính tên thành phần — "Internet Gateway" — và ở việc bốn phương án cố tình đặt nó cạnh ba thành phần khác của mạng AWS mà người mới rất hay lẫn: NAT Gateway (cho private subnet), bastion host (EC2 để quản trị), và Virtual Private Gateway (cho VPN). Vì vậy câu này không kiểm tra bạn có biết "Internet Gateway liên quan tới Internet" hay không — điều đó quá hiển nhiên — mà kiểm tra bạn có phân biệt được subnet nào được nó phục vụ.

Từ khoá phân biệt thật sự là cặp "public subnets" trong phương án A đối lập với "private subnets" trong phương án B. Một subnet được gọi là public chính vì route table của nó có đường đi trỏ tới Internet Gateway; nếu không có đường đi đó thì subnet là private, và Internet Gateway không giúp gì cho nó cả.

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

A — "Enables Internet communications for instances in public subnets" là đáp án đúng.

Internet Gateway là một thành phần của VPC, được AWS thiết kế theo hướng mở rộng ngang, dự phòng và có tính sẵn sàng cao, nên nó không tạo ra điểm chết hay nút thắt băng thông cho lưu lượng mạng của bạn.

Nó phục vụ đúng hai mục đích:

1. Làm đích đến trong route table của VPC cho lưu lượng đi ra Internet — tức là dòng 0.0.0.0/0 → igw-xxxx chính là thứ biến một subnet thành public subnet.
2. Thực hiện network address translation (NAT) cho các instance đã được gán địa chỉ public IPv4, để địa chỉ private bên trong VPC và địa chỉ public nhìn từ bên ngoài ánh xạ đúng vào nhau.

Ghép hai việc đó lại: instance nằm trong subnet có route tới Internet Gateway và có public IPv4 thì giao tiếp được với Internet theo cả hai chiều. Đó chính xác là mô tả của phương án A.

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

B — "Provides Internet access for EC2 instances in private subnets": đây là phương án gần đúng nhất và cũng là bẫy chính. Nó sai vì bạn không thể cho instance trong private subnet ra Internet bằng Internet Gateway. Muốn instance ở private subnet gọi ra ngoài (ví dụ tải bản vá) mà vẫn không cho ai từ Internet gọi vào, bạn cần NAT Gateway hoặc NAT instance đặt ở public subnet. Lưu ý điểm dễ nhầm: bản thân NAT Gateway vẫn phải dựa vào Internet Gateway để đi tiếp ra ngoài, nhưng vai trò "cấp đường ra cho private subnet" là của NAT chứ không phải của Internet Gateway.

C — "It's a bastion host for inbound management connections": sai hoàn toàn về bản chất. Internet Gateway không phải một máy chủ, bạn không SSH hay RDP vào nó, không cài gì lên nó, không đăng nhập vào nó được. Bastion host là một EC2 instance do bạn triển khai trong public subnet để làm điểm nhảy quản trị vào các máy bên trong. Hai thứ khác hẳn nhau về loại tài nguyên.

D — "It's used for making VPN connections to a VPC": cũng sai. Internet Gateway không thiết lập kết nối VPN. Muốn nối mạng on-premises vào VPC qua VPN thì phía VPC cần Virtual Private Gateway. Phương án này bẫy được người chỉ nhớ mang máng rằng "cả hai đều là gateway gắn vào VPC" — giống tên gọi nhưng khác chức năng.

📌 Điểm cần nhớ

• Định nghĩa public subnet = subnet có route trỏ tới Internet Gateway. Nhớ theo chiều này thì phương án kiểu "Internet Gateway cho private subnet" tự mâu thuẫn ngay, vì hễ có route đó thì subnet đã là public rồi.
• Internet Gateway làm hai việc: làm đích trong route table cho lưu lượng ra Internet, và làm NAT cho instance có public IPv4. Chỉ có route mà instance không có địa chỉ public thì vẫn chưa đủ.
• Phân vai bốn thành phần hay bị trộn lẫn trong đề thi: Internet Gateway cho public subnet — NAT Gateway/NAT instance cho private subnet đi ra — bastion host là EC2 để quản trị đi vào — Virtual Private Gateway cho VPN.
• Internet Gateway là thành phần managed của VPC, không phải một máy. Mọi phương án mô tả nó như một server (đăng nhập, cài đặt, làm điểm nhảy) đều loại được ngay mà không cần suy nghĩ thêm.

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

Đề hỏi: dịch vụ AWS nào cung cấp fully managed third-party file systems, có native compatibility và bộ tính năng phong phú, để dùng cùng nhiều dịch vụ AWS khác.

Cụm từ quyết định là "third-party file systems" kèm "native compatibility". Đây không phải câu hỏi "dịch vụ nào cho tôi một file system chia sẻ" — nếu chỉ vậy thì có tới hai phương án hợp lý. Ràng buộc thật nằm ở chữ third-party: file system đó phải là sản phẩm của bên thứ ba, tồn tại sẵn ngoài thế giới on-premises (Windows File Server, Lustre…), và AWS chỉ đứng ra vận hành hộ chứ không tự thiết kế giao thức mới. "Native compatibility" nghĩa là ứng dụng đang chạy với file system đó ở on-premises chuyển sang không phải sửa gì — vẫn đúng giao thức, vẫn đúng bộ tính năng gốc.

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

B. Amazon FSx đúng vì nó chính là họ dịch vụ AWS dựng riêng để chạy các file system của bên thứ ba dưới dạng fully managed: FSx for Windows File Server và FSx for Lustre là hai ví dụ được nêu thẳng trong lời giải nguồn. Người dùng nhận được đúng file system quen thuộc — cùng giao thức, cùng tập tính năng gốc — nhưng phần vá lỗi, sao lưu, mở rộng dung lượng thì AWS lo. Đó là lý do FSx khớp trọn vẹn cả ba mảnh của đề: fully managed, third-party, native compatibility, và dùng được cùng nhiều dịch vụ AWS khác.

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

A. Amazon EFS — đây là phương án gần đúng nhất và cũng là bẫy chính. EFS đúng là dịch vụ file storage fully managed, đàn hồi, dùng chung được cho nhiều compute cùng lúc. Nhưng nó là file system do chính AWS xây, không phải bản managed của một sản phẩm bên thứ ba nào cả. Nó hỏng đúng ở mảnh "third-party" — mảnh mà đề đặt làm ràng buộc phân biệt. Chọn A là đọc đề thành "dịch vụ file storage managed" và bỏ mất chữ quyết định.

C. Amazon S3 — S3 là object storage, không phải file system. Nó không nói giao thức file, không có cây thư mục thật, không có ngữ nghĩa file locking hay quyền kiểu file server. Ứng dụng đang đọc ghi qua đường dẫn file không thể trỏ thẳng vào S3 mà không sửa gì, nên chữ "native compatibility" không áp dụng được. Đây là phương án xa đề nhất trong bốn cái.

D. AWS Storage Gateway — dịch vụ này giải một bài toán khác: nối môi trường on-premises với storage trên cloud, cho hệ thống cũ tiếp tục dùng giao diện quen thuộc trong khi dữ liệu nằm ở AWS. Nó là cầu nối hybrid, không phải nơi AWS vận hành hộ một file system bên thứ ba với đầy đủ bộ tính năng gốc. Thấy chữ "file" trong mô tả rồi chọn D là nhầm giữa truy cập storage và được cung cấp một file system.

📌 Điểm cần nhớ

• Trong nhóm storage của AWS, FSx = file system của bên thứ ba được AWS quản lý hộ (Windows File Server, Lustre…), còn EFS = file system do chính AWS làm ra. Đề nào nhắc "third-party", "Windows", "Lustre", "native compatibility" thì nghiêng về FSx.
• Phân biệt ba loại storage trước khi so tính năng: object (S3), file (EFS, FSx), hybrid gateway (Storage Gateway). Loại sai thì mọi tính năng phía sau đều không cần xét.
• Storage Gateway trả lời cho câu hỏi "làm sao hệ thống on-premises dùng được storage trên cloud", không trả lời cho câu hỏi "dịch vụ nào cấp cho tôi một file system".
• Với câu trắc nghiệm có nhiều phương án cùng nhóm, hãy tìm tính từ hẹp nhất trong đề (ở đây là third-party) — nó thường là thứ duy nhất loại được phương án gần đúng.

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

Đề hỏi: tính năng nào của Amazon EC2 cho phép quản trị viên tạo ra một "standardized image" dùng để khởi chạy các instance mới.

Cụm từ quyết định là "standardized image ... used for launching new instances" — tức là một khuôn mẫu đóng gói sẵn hệ điều hành, phần mềm và cấu hình đĩa, để mọi instance sinh ra từ nó đều giống hệt nhau. Chú ý hai ràng buộc gộp lại: (1) nó phải là một image, không phải một thao tác gắn ổ đĩa; (2) nó phải là tính năng có thật của AWS, chứ không phải một thuật ngữ chung mà dân kỹ thuật hay dùng.

Ràng buộc thứ hai chính là bẫy của câu này: ba trong bốn phương án là những cái tên nghe rất AWS nhưng không tồn tại trong danh mục dịch vụ. Đây là kiểu câu kiểm tra xem thí sinh có thuộc đúng tên chính thức của tính năng hay không.

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

C. Amazon Machine Image (AMI) — đây đúng là thứ chứa toàn bộ thông tin cần thiết để khởi chạy một instance EC2. Từ một AMI, bạn có thể khởi chạy hàng loạt instance giống hệt nhau từ cùng một khuôn mẫu chuẩn, đúng như đề mô tả "standardized image".

Một AMI thường được tạo từ EBS snapshot của volume gốc, và ngoài dữ liệu đĩa nó còn mang theo:

• launch permissions — quy định tài khoản AWS nào được phép dùng AMI này để khởi chạy instance;
• block device mapping — mô tả các volume sẽ được gắn vào instance khi khởi chạy.

Đúng như bản giải thích gốc lưu ý: quy trình "chuẩn hoá một image rồi nhân bản ra nhiều instance" hay được gọi bằng thuật ngữ chung là Golden Image, nhưng trong AWS, tính năng thực hiện việc đó có tên chính thức là Amazon Machine Image.

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

A. Amazon Block Template — không tồn tại. AWS không có dịch vụ hay tính năng nào mang tên này. Cái tên có vẻ hợp lý vì nó gợi tới block device mapping (một thành phần thật, nằm bên trong AMI) và tới khái niệm "template", nhưng ghép hai mảnh đúng thành một cái tên sai thì vẫn là sai. Block device mapping là một thuộc tính của AMI, không phải một tính năng độc lập để khởi chạy instance.

B. Amazon EBS Mount Point — không phải tính năng của AWS. Bạn có mount EBS volume trong thực tế, nhưng thao tác mount đó diễn ra bên trong hệ điều hành của instance (lệnh của Linux/Windows), không phải một tính năng EC2 do AWS cung cấp. Quan trọng hơn: mount một volume chỉ gắn thêm dung lượng lưu trữ cho một máy đang chạy — nó không tạo ra khuôn mẫu để khởi chạy máy mới, tức là trượt hẳn yêu cầu "launching new instances" của đề.

D. Amazon Golden Image — đây là phương án gây nhiễu mạnh nhất, và cũng là chỗ dễ mất điểm nhất. Golden image là thuật ngữ chung của ngành, mô tả đúng ý tưởng mà đề đang hỏi, nên đọc lướt rất dễ chọn. Nhưng AWS không có tính năng nào tên là "Amazon Golden Image". Đề hỏi rõ "Which AWS feature of Amazon EC2" — hỏi tên tính năng, chứ không hỏi tên khái niệm. Khi một phương án là khái niệm đúng nhưng cái tên không tồn tại, nó vẫn sai.

📌 Điểm cần nhớ

• AMI (Amazon Machine Image) là khuôn mẫu để khởi chạy instance EC2; muốn nhiều instance giống hệt nhau thì chuẩn hoá vào một AMI rồi khởi chạy từ đó.
• Thành phần của một AMI: dữ liệu đĩa (thường từ EBS snapshot), launch permissions, và block device mapping — nhận diện được ba mảnh này thì loại được ngay các cái tên bịa quanh chúng.
• Đề hỏi "which AWS feature" là tín hiệu kiểm tra tên chính thức. Thuật ngữ ngành đúng nghĩa (golden image) không đồng nghĩa với tên tính năng có thật.
• Phân biệt tạo image với gắn ổ đĩa: AMI phục vụ việc khởi chạy máy mới; mount EBS volume chỉ là thao tác trong hệ điều hành của máy đang chạy.

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

Đề hỏi: dịch vụ AWS nào được thiết kế riêng để giảm thiểu downtime và mất mát dữ liệu, phục hồi nhanh và tin cậy các ứng dụng on-premises lẫn trên cloud, mà chỉ tốn storage rẻ và rất ít compute.

Cụm từ quyết định nằm ở vế cuối: "fast, reliable recovery ... using affordable storage, and minimal compute". Đây chính là mô tả kinh điển của mô hình pilot light / warm standby trong disaster recovery: dữ liệu được sao chép liên tục vào vùng lưu trữ giá rẻ, chỉ đến khi có sự cố mới dựng máy chủ đầy đủ. Ba từ khoá cần soi cùng lúc:

• minimize downtime and data loss → nói về RTO và RPO, tức là bài toán disaster recovery, không phải bài toán backup hay lưu trữ.
• on-premises and cloud-based applications → phải phục hồi được cả ứng dụng chạy ngoài AWS, không chỉ tài nguyên trong AWS.
• minimal compute → replication chạy nền không cần dựng sẵn nguyên bộ máy chủ dự phòng đắt tiền.

Đề hỏi "which service is designed to", tức là hỏi dịch vụ có mục đích thiết kế đúng vào việc này, chứ không hỏi dịch vụ nào "có thể dùng để" làm việc đó — nhiều phương án còn lại chạm được một phần nhưng không phải mục đích thiết kế.

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

B — AWS Elastic Disaster Recovery khớp trọn vẹn cả ba từ khoá. Đây là dịch vụ DR chuyên dụng của AWS: nó liên tục nhân bản (replicate) máy chủ nguồn — dù nguồn nằm trong trung tâm dữ liệu riêng hay đang chạy trên cloud — vào một vùng staging chi phí thấp trong AWS. Vùng staging này chỉ tiêu tốn storage và một lượng compute rất nhỏ để duy trì replication, nên chi phí thường trực thấp hơn nhiều so với việc dựng sẵn một bản sao hạ tầng đầy đủ.

Khi xảy ra sự cố, dịch vụ khởi chạy (launch) các instance phục hồi từ dữ liệu đã nhân bản, cho phép đưa ứng dụng trở lại hoạt động nhanh chóng — đúng với yêu cầu "minimize downtime and data loss". Nói theo tên gọi: đây là dịch vụ Disaster Recovery, và đề bài đang mô tả nguyên văn một chiến lược disaster recovery.

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

A — AWS Backup. Đây là phương án gần đúng nhất và cũng dễ bẫy nhất, vì AWS Backup cũng bao phủ được cả tài nguyên trong AWS lẫn on-premises. Nhưng nó là dịch vụ quản lý sao lưu tập trung: đặt chính sách backup, lên lịch, giữ bản sao theo vòng đời, kiểm soát tuân thủ. Backup trả lời câu hỏi "dữ liệu có bản sao chưa?", còn đề bài hỏi "đưa ứng dụng chạy lại nhanh thế nào?". Khôi phục từ backup là quá trình restore rồi dựng lại môi trường — không phải cơ chế nhân bản liên tục rồi launch nhanh như một dịch vụ DR chuyên dụng. Nó thiếu đúng chữ "fast, reliable recovery of applications".

C — Amazon RDS. Đây là dịch vụ cơ sở dữ liệu quan hệ được quản lý, lo việc cài đặt, vá lỗi, mở rộng database. RDS có automated backup và các cơ chế dự phòng riêng, nhưng phạm vi của nó chỉ là database do chính RDS quản lý — không phục hồi được ứng dụng nói chung, và càng không phục hồi máy chủ on-premises. Sai ngay ở phạm vi đối tượng được bảo vệ.

D — Amazon S3 Glacier. Đây là lớp lưu trữ giá rẻ cho dữ liệu ít truy cập, dùng cho backup dài hạn và lưu trữ (archival). Nó khớp được đúng một mảnh của đề — "affordable storage" — và chính mảnh đó là cái bẫy. Nhưng Glacier chỉ là nơi cất dữ liệu, không phải cơ chế phục hồi ứng dụng; hơn nữa các lớp lưu trữ archival vốn được tối ưu cho chi phí thấp chứ không tối ưu cho tốc độ lấy dữ liệu ra, nên nó đi ngược lại yêu cầu "fast recovery".

📌 Điểm cần nhớ

• Phân biệt backup với disaster recovery: backup lo dữ liệu có bản sao, DR lo ứng dụng chạy lại nhanh đến mức nào. Đề nhắc "downtime", "RTO", "recovery of applications" → nghĩ tới Elastic Disaster Recovery; đề nhắc "chính sách sao lưu tập trung", "vòng đời bản sao", "tuân thủ" → nghĩ tới AWS Backup.
• Cụm "on-premises and cloud" loại ngay những dịch vụ chỉ hoạt động trong phạm vi AWS như Amazon RDS.
• Cụm "affordable storage and minimal compute" là mô tả mô hình pilot light: nhân bản liên tục vào vùng staging rẻ, chỉ dựng compute đầy đủ khi thật sự cần failover.
• Storage class rẻ như S3 Glacier phục vụ lưu trữ dài hạn, không phải công cụ phục hồi nhanh — thấy đề đòi "fast recovery" thì đừng chọn dịch vụ archival chỉ vì nó khớp chữ "affordable".

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

Đề mô tả một developer cần tự động provision một tập hợp (collection) các tài nguyên AWS, rồi hỏi dịch vụ AWS nào được dùng chủ yếu để triển khai infrastructure as code.

Cụm từ quyết định là "deploying infrastructure as code", được củng cố thêm bởi "a collection of AWS resources". Hai cụm này gộp lại loại bỏ mọi phương án chỉ lo phần ứng dụng chạy trên hạ tầng, và chỉ chừa lại dịch vụ mà đầu vào của nó là một bản mô tả hạ tầng dạng template — tức bạn khai báo mình muốn có VPC, EC2, S3, IAM role… rồi dịch vụ tự dựng chúng theo đúng thứ tự phụ thuộc.

Cần chú ý thêm một chi tiết nữa trong đề: nó hỏi "Which AWS service". Đây là ràng buộc ngầm nhưng có thật — bất kỳ công cụ nào không phải dịch vụ của AWS đều bị loại ngay, không cần bàn tới chức năng.

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

B — AWS CloudFormation.

CloudFormation cho phép mô tả toàn bộ tài nguyên hạ tầng trong môi trường cloud bằng một ngôn ngữ khai báo chung (template), rồi provision chúng một cách có trật tự và có thể dự đoán được (orderly and predictable). Bạn viết ra trạng thái mong muốn của hạ tầng, CloudFormation lo phần tạo ra nó — bao gồm cả việc tạo các tài nguyên liên quan theo đúng thứ tự phụ thuộc lẫn nhau, gom chúng thành một đơn vị quản lý chung.

Đúng như cách đề diễn đạt: hãy hình dung CloudFormation chính là "deploying infrastructure as code". Đây là câu trả lời chuẩn mực cho mọi câu hỏi Cloud Practitioner có chứa cụm "infrastructure as code".

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

A — Jenkins. Sai vì hai lớp lý do. Thứ nhất và dứt khoát nhất: Jenkins không phải là một dịch vụ AWS, trong khi đề hỏi rõ "Which AWS service" — chỉ riêng điều này đã đủ loại. Thứ hai, Jenkins là công cụ Continuous Integration: nó điều phối build và pipeline, chứ bản thân nó không phải là dịch vụ khai báo hạ tầng của AWS.

C — AWS CodeDeploy. Đây là phương án dễ nhầm nhất vì tên có chữ "Deploy" và nó cũng "triển khai tự động" thật. Nhưng chỗ hỏng nằm ở thứ được triển khai: CodeDeploy là dịch vụ được quản lý hoàn toàn, chuyên tự động hoá việc triển khai phần mềm (software deployments) lên nhiều loại compute khác nhau như Amazon EC2, AWS Lambda và cả máy chủ on-premises. Nó đẩy mã ứng dụng lên hạ tầng đã tồn tại sẵn — nó không tạo ra VPC, subnet hay EC2 instance cho bạn. Đề hỏi provision tài nguyên, không hỏi triển khai ứng dụng.

D — AWS Elastic Beanstalk. Cũng gần đúng, vì Beanstalk có tạo ra tài nguyên AWS thật (EC2, load balancer, Auto Scaling group) khi bạn đưa mã lên. Nhưng nó tập trung vào việc triển khai ứng dụng trên EC2 theo mô hình PaaS: bạn giao mã nguồn, nền tảng tự lo hạ tầng bên dưới theo khuôn có sẵn. Trọng tâm là ứng dụng, và bạn không phải người mô tả hạ tầng. Còn infrastructure as code là chiều ngược lại — chính bạn khai báo tài nguyên nào cần dựng, ở cấu hình nào.

📌 Điểm cần nhớ

• Thấy cụm "infrastructure as code" trong đề thi AWS thì phản xạ đầu tiên là CloudFormation — nó là dịch vụ khai báo hạ tầng bằng template, provision cả một nhóm tài nguyên liên quan một cách có trật tự.
• Phân biệt theo đối tượng được triển khai: CloudFormation dựng hạ tầng; CodeDeploy đẩy mã ứng dụng lên hạ tầng đã có (EC2, Lambda, on-premises); Elastic Beanstalk lo ứng dụng theo kiểu PaaS và giấu hạ tầng đi.
• Khi đề hỏi "Which AWS service", công cụ bên thứ ba như Jenkins bị loại ngay từ chữ "AWS", bất kể nó làm được gì.
• Tên dịch vụ có chữ "Deploy" không đồng nghĩa với "provision tài nguyên" — hãy đọc kỹ danh từ đứng sau động từ trong đề: resources hay application.

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

Đề hỏi: làm thế nào để cấu hình Amazon Route 53 giám sát tình trạng (health) và hiệu năng (performance) của ứng dụng?

Cụm từ quyết định là "configure Amazon Route 53 to monitor" — tức là câu hỏi giới hạn phạm vi vào một tính năng nằm ngay bên trong Route 53, chứ không hỏi "dịch vụ nào của AWS giám sát được ứng dụng nói chung". Đây chính là chỗ bẫy: nếu đọc lướt thành "giám sát ứng dụng bằng gì" thì CloudWatch nghe rất hợp lý, nhưng đề không hỏi vậy.

Cụm thứ hai đáng chú ý là "health and performance" — Route 53 có đúng một cấu phần mang tên và mang chức năng đó: Route 53 health checks. Health check gửi request định kỳ tới endpoint, theo dõi endpoint còn phản hồi hay không, và kết quả đó được Route 53 dùng cho DNS failover (ngừng trả về bản ghi trỏ tới endpoint đã hỏng).

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

Đáp án đúng theo tệp là D — Using Route 53 health checks.

Route 53 health checks là tính năng chuyên dụng để theo dõi tình trạng và khả năng phản hồi của web application, web server và các resource khác. Cơ chế: Route 53 định kỳ gửi request tới endpoint bạn khai báo, đánh giá endpoint là healthy hay unhealthy theo phản hồi nhận được. Khi endpoint bị đánh giá unhealthy, Route 53 có thể tự động thôi trả về bản ghi DNS trỏ tới nó và chuyển lưu lượng sang endpoint dự phòng — đây là nền tảng của DNS failover trong Route 53.

Điểm mấu chốt cho kỳ thi: health check là thứ bạn cấu hình bên trong chính Route 53, đúng với cách đề đặt câu hỏi ("configure Route 53 to monitor"). Ba phương án còn lại đều không phải là một cơ chế giám sát do Route 53 cung cấp.

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

A. Using CloudWatch — đây là phương án gần đúng nhất và là bẫy chính. CloudWatch đúng là dịch vụ giám sát metric và log của AWS, nhưng nó không phải là cách bạn cấu hình Route 53 để giám sát ứng dụng. Quan hệ thực tế ngược lại: Route 53 health check là bên tạo ra tín hiệu, còn CloudWatch là nơi tín hiệu đó được nhìn thấy và dùng để đặt alarm. Chọn CloudWatch là trả lời một câu hỏi khác với câu đề đang hỏi.

B. Using DNS lookups — DNS lookup chỉ là hành vi phân giải tên miền thành địa chỉ: client hỏi, Route 53 trả về bản ghi. Bản thân việc phân giải không kiểm tra endpoint đó có còn sống hay không — Route 53 vẫn trả về bản ghi đã cấu hình bất kể server phía sau đã chết. Đó chính là lý do health check phải tồn tại như một cơ chế riêng: để kết quả DNS lookup phản ánh được tình trạng thật của endpoint.

C. Using the Route 53 API — API là giao diện điều khiển, không phải cơ chế giám sát. Qua API bạn tạo hosted zone, tạo record, và cũng có thể tạo hay đọc trạng thái health check — nhưng thứ thực sự làm việc giám sát vẫn là health check, còn API chỉ là cách bạn nói chuyện với dịch vụ. Nhầm "công cụ cấu hình" với "tính năng được cấu hình" là lỗi phân loại, không phải chi tiết kỹ thuật.

📌 Điểm cần nhớ

• Route 53 health checks = tính năng giám sát tình trạng endpoint nằm trong Route 53, và là điều kiện tiên quyết cho DNS failover. Hễ đề nhắc "Route 53" + "health"/"failover" thì gần như chắc chắn đáp án là health check.
• Đọc kỹ chủ ngữ của câu hỏi: "configure Route 53 to…" thu hẹp đáp án về tính năng nội bộ của Route 53, loại ngay những dịch vụ ngoài như CloudWatch dù chúng liên quan tới giám sát.
• Phân biệt ba lớp khái niệm hay bị trộn trong đề trắc nghiệm: cơ chế giám sát (health check), nơi hiển thị và cảnh báo (CloudWatch), giao diện điều khiển (API/console). Đề hỏi lớp nào thì trả lời lớp đó.
• DNS lookup thuần tuý là phân giải tên, không mang thông tin về sức khoẻ endpoint — Route 53 vẫn trả bản ghi trỏ tới server đã hỏng nếu không có health check.

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

Đề hỏi: một công ty muốn dùng mô hình pay as you go cho toàn bộ ứng dụng của họ, không có CAPEX, và phải highly elastic. Vậy cloud delivery model nào hợp nhất?

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

• "without CAPEX costs" — không bỏ vốn mua sắm trước. Cụm này loại ngay những mô hình mà công ty phải tự mua và sở hữu phần cứng.
• "highly elastic" — co giãn theo nhu cầu, phình lên và thu lại được. Một hạ tầng có kích thước cố định do chính công ty mua thì chỉ co giãn trong giới hạn số máy đã có.
• "for all of their applications" — đây là cụm hay bị bỏ qua nhất, nhưng nó chính là thứ tách Public khỏi Hybrid. "Tất cả ứng dụng" nghĩa là công ty đi hẳn theo một mô hình duy nhất, không chia đôi khối lượng công việc.

Chú ý rằng đề hỏi về delivery model (public / private / hybrid / on-premise), chứ không hỏi về service model (IaaS / PaaS / SaaS).

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

Đáp án đúng theo tệp là B — Public.

Public cloud được cung cấp thuần theo mô hình pay as you go: bạn trả cho phần tài nguyên đã dùng, và trừ khi bạn chủ động chọn hình thức đặt trước (reserve) để đổi lấy giá tốt hơn, thì không có khoản cam kết vốn nào. Nhờ vậy công ty tránh được hoàn toàn CAPEX — không mua server, không mua storage array, không dựng phòng máy.

Public cloud cũng là mô hình elastic nhất trong bốn phương án: tài nguyên đến từ một pool dùng chung rất lớn của nhà cung cấp, nên ứng dụng có thể grow và shrink theo nhu cầu thực tế thay vì bị chặn bởi số phần cứng công ty đã mua. Đúng ba yêu cầu của đề: pay as you go, no CAPEX, highly elastic.

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

A — Private. Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. Private cloud vẫn là "cloud" — vẫn có ảo hoá, tự phục vụ, tự động hoá — và một số nhà cung cấp bên thứ ba thậm chí vận hành hộ và tính tiền theo kiểu OPEX, nên không thể loại nó bằng lý do "private thì không phải cloud". Chỗ nó hỏng là hai điểm còn lại: private cloud thường nặng CAPEX vì hạ tầng dành riêng cho một tổ chức thường do chính tổ chức đó đầu tư, và elasticity bị giới hạn trong dung lượng của khối phần cứng đã có. Hết công suất thì phải mua thêm, tức là quay lại CAPEX và chờ đợi — trái với "highly elastic".

C — On-premise. Về bản chất giống private cloud (và cũng có thể được bên thứ ba quản lý), nên nó thất bại vì cùng hai lý do trên, thậm chí rõ hơn: hạ tầng đặt tại chỗ, do công ty mua và sở hữu, là hình mẫu của CAPEX. Khả năng co giãn bị chặn cứng bởi số máy trong phòng máy.

D — Hybrid. Về mặt kỹ thuật, hybrid có chứa phần public nên nó có mang lại pay as you go và elasticity cho phần chạy trên public. Nhưng hybrid theo định nghĩa là kết hợp public với private/on-premise, nghĩa là công ty vẫn giữ một phần hạ tầng riêng — tức là vẫn còn CAPEX và vẫn còn phần bị giới hạn co giãn. Quan trọng hơn, đề nói rõ công ty muốn dùng mô hình này cho all of their applications, tức là đi trọn vẹn theo một mô hình duy nhất; hybrid mô tả trạng thái chia đôi, không phải trạng thái đó. Đây chính là chỗ cụm "all of their applications" phát huy tác dụng.

📌 Điểm cần nhớ

• "No CAPEX" + "highly elastic" gần như luôn trỏ về public cloud. Hai đặc tính này là điểm bán hàng cốt lõi của mô hình public, và các mô hình còn lại đều vướng ít nhất một trong hai.
• Private và on-premise được coi là gần như tương đương trong các câu hỏi kiểu này: đều thiên về CAPEX, đều có elasticity bị chặn bởi phần cứng sẵn có. Đừng mất thời gian phân biệt hai cái đó khi đề đang nhắm vào chi phí và độ co giãn.
• Hybrid chỉ đúng khi đề mô tả một sự chia đôi. Có dữ liệu bắt buộc giữ tại chỗ vì tuân thủ, có hệ thống cũ chưa chuyển được, muốn burst ra cloud lúc cao điểm — đó là hybrid. Còn "tất cả ứng dụng", "đi hẳn theo một mô hình" thì hybrid là bẫy.
• Phân biệt delivery model với service model. Public / private / hybrid / on-premise trả lời câu hỏi "hạ tầng đặt ở đâu và ai sở hữu"; IaaS / PaaS / SaaS trả lời "bạn quản lý tới tầng nào". Đọc kỹ đề đang hỏi trục nào trước khi chọn.

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

Đề hỏi: dịch vụ nào cho phép tổ chức mang giấy phép phần mềm sẵn có của mình (bring your own licensing – BYOL) lên phần cứng máy chủ vật lý được cô lập vật lý khỏi các AWS account khác?

Có hai cụm từ quyết định, và phải thoả cả hai mới chọn đúng:

• "bring their own licensing" — dùng lại license đã mua theo per-socket, per-core hoặc per-VM (Windows Server, Microsoft SQL Server, SUSE Linux Enterprise Server…). Muốn vậy thì tổ chức phải nhìn thấy và kiểm soát được cấu hình vật lý của máy chủ: bao nhiêu socket, bao nhiêu core — vì đó chính là đơn vị tính license.
• "host hardware that is physically isolated from other AWS accounts" — máy chủ vật lý không dùng chung với account khác.

Cụm thứ hai một mình không phân biệt được A và C, vì cả Dedicated Instances lẫn Dedicated Hosts đều chạy trên phần cứng dành riêng cho một khách hàng. Chính cụm "bring their own licensing" mới là ràng buộc chốt hạ, tách C ra khỏi A. Đây là kiểu bẫy rất hay gặp: hai phương án cùng thoả một nửa đề, nửa còn lại mới là điểm chấm.

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

C – EC2 Dedicated Hosts. Dedicated Host là một máy chủ vật lý với toàn bộ năng lực chạy EC2 instance dành riêng cho bạn sử dụng. Vì bạn thuê nguyên cả cái host, AWS phơi ra cho bạn thông tin về socket và core vật lý của máy đó, và bạn tự quyết định đặt instance nào lên host nào.

Đúng điều kiện đó là thứ mà license per-socket / per-core / per-VM đòi hỏi: nhà cung cấp phần mềm cần biết chính xác phần cứng nào đang chạy sản phẩm của họ để tính phí và để kiểm tra tuân thủ. Nhờ vậy Dedicated Hosts hỗ trợ BYOL cho Windows Server, Microsoft SQL Server, SUSE Linux Enterprise Server và các phần mềm tương tự. Đồng thời host là máy vật lý riêng, nên cũng thoả luôn vế "physically isolated from other AWS accounts" trong đề.

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

A – EC2 Dedicated Instances — đây là phương án gần đúng nhất và là bẫy chính. Dedicated Instances cũng chạy trong VPC trên phần cứng dành riêng cho một khách hàng duy nhất, nên vế "physically isolated" nghe rất khớp. Chỗ nó hỏng là vế còn lại: Dedicated Instances không hỗ trợ BYOL. Bạn được cách ly ở tầng phần cứng, nhưng không được quyền kiểm soát và nhìn vào chính máy chủ vật lý đó — không chọn được instance nằm trên host nào, không làm việc ở mức socket/core. Thiếu đúng thứ mà mô hình license per-socket/per-core cần. Nói ngắn: Dedicated Instances giải quyết bài toán cách ly, Dedicated Hosts giải quyết bài toán cách ly + license.

B – EC2 Spot Instances — đây là mô hình giá, không phải mô hình vị trí đặt máy (placement). Spot cho phép bạn dùng năng lực EC2 còn dư với chi phí thấp hơn nhiều so với On-Demand, đổi lại instance có thể bị thu hồi khi AWS cần lại năng lực đó. Nó không cho BYOL, và cũng không hứa hẹn gì về việc phần cứng có được cô lập khỏi account khác hay không. Sai cả hai vế của đề.

D – EC2 Reserved Instances — cũng là mô hình giá / cam kết chi tiêu, không phải mô hình phần cứng. Bạn cam kết dùng trong một khoảng thời gian (thường là 1 hoặc 3 năm) để đổi lấy mức giảm giá đáng kể so với On-Demand. Reserved Instance là một khoản giảm giá áp lên hoá đơn, không phải một chỗ đứng trên máy chủ vật lý riêng, và không liên quan tới BYOL.

📌 Điểm cần nhớ

• Tách hai nhóm khái niệm ra: Spot và Reserved Instances trả lời câu hỏi "trả tiền thế nào?"; Dedicated Instances và Dedicated Hosts trả lời câu hỏi "chạy trên phần cứng nào?". Đề nào nhắc tới phần cứng, cách ly, hay license thì loại ngay nhóm giá.
• Thấy "bring your own license", "BYOL", "per-socket / per-core licensing", hoặc yêu cầu "nhìn thấy socket/core vật lý" → chọn Dedicated Hosts. Đây gần như là dấu hiệu nhận dạng riêng của Dedicated Hosts trong đề thi.
• Chỉ thấy "dedicated hardware", "không dùng chung phần cứng với khách hàng khác" mà không nhắc gì tới license → Dedicated Instances là đủ, và thường là đáp án rẻ hơn/đơn giản hơn được nhắm tới.
• Khi hai phương án cùng thoả một vế của đề, vế còn lại chính là điểm chấm. Đừng dừng lại khi đã tìm thấy một cụm từ khớp — đọc hết ràng buộc rồi mới chọn.