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

Đáp án

A — SỐ LƯỢNG PHIÊN BẢN EC2 (mở rộng theo chiều NGANG).

Vì sao đúng

⚠ EC2 Auto Scaling làm gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Tự động THÊM phiên bản khi tải tăng | ⚠ scale out | | ⚠ Tự động BỚT phiên bản khi tải giảm | ⚠ scale in | | ⚠ Duy trì số phiên bản khoẻ mạnh theo mong muốn | ⚠ thay thế phiên bản hỏng | | ⚠ Điều khiển bằng chính sách dựa trên chỉ số hoặc lịch | | | ⚠ Kết luận | ⚠ nó thay đổi SỐ LƯỢNG máy, không thay đổi kích cỡ từng máy |

⚠ Đây là mở rộng theo chiều NGANG ⚠ — ⚠ triết lý cốt lõi của đám mây: nhiều máy nhỏ thay vì một máy khổng lồ, vì nhiều máy nhỏ vừa rẻ hơn vừa chịu lỗi tốt hơn.

Vì sao các phương án khác sai

• B (kích cỡ của phiên bản EC2) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đổi kích cỡ máy CŨNG là một cách tăng năng lực xử lý, và đó chính là cách quen thuộc của thời máy chủ vật lý: ⚠ nhưng ⚠ đó là mở rộng theo chiều DỌC, và Auto Scaling không làm việc đó ⚠; ⚠ muốn đổi loại phiên bản thì phải DỪNG máy, đổi loại, rồi khởi động lại — tức là có gián đoạn dịch vụ; ⚠ phân biệt hai chiều mở rộng là một trong những khái niệm nền tảng hay bị hỏi nhất: NGANG là thêm máy, DỌC là làm máy to hơn.

• C (dung lượng ổ EBS) — ⚠ đó là việc thay đổi thủ công hoặc bằng công cụ khác; ⚠ Auto Scaling không đụng tới dung lượng ổ đĩa.

• D (băng thông mạng) — ⚠ băng thông đi kèm loại phiên bản; ⚠ không phải thứ Auto Scaling điều chỉnh.

Ghi nhớ

⚠ Hai chiều mở rộng, phân biệt dứt khoát: | Chiều | Nghĩa | Đặc điểm | |---|---|---| | ⚠ NGANG (scale out/in) | ⚠ thêm hoặc bớt SỐ MÁY | ⚠ không gián đoạn, chịu lỗi tốt — ĐÁP ÁN | | ⚠ DỌC (scale up/down) | ⚠ làm máy TO hơn hoặc nhỏ đi | ⚠ phải dừng máy, có trần vật lý | | ⚠ Vì sao đám mây ưa chiều ngang | ⚠ chiều dọc luôn đụng trần ở loại phiên bản lớn nhất, còn chiều ngang thì gần như không có trần; ngoài ra một máy to hỏng là mất tất cả, còn mất một trong mười máy nhỏ thì dịch vụ vẫn chạy |

⚠ Ba giá trị của một nhóm Auto Scaling: | Giá trị | Nội dung | |---|---| | ⚠ Minimum | ⚠ số phiên bản tối thiểu luôn giữ | | ⚠ Desired | ⚠ số phiên bản mong muốn hiện tại | | ⚠ Maximum | ⚠ trần để chi phí không vượt kiểm soát | | ⚠ Vai trò của Maximum | ⚠ đây là van an toàn về CHI PHÍ — không có nó thì một đợt tấn công hoặc một vòng lặp lỗi có thể tự động sinh ra hàng trăm máy |

⚠ Auto Scaling và Load Balancer đi cùng nhau: | Thành phần | Vai trò | |---|---| | ⚠ Auto Scaling | ⚠ quyết định có bao nhiêu máy | | ⚠ Elastic Load Balancer | ⚠ phân phối lưu lượng tới các máy đó | | ⚠ Kiểm tra sức khoẻ | ⚠ máy hỏng bị gỡ khỏi vòng phục vụ và được thay thế | | ⚠ Vì sao cần cả hai | ⚠ thêm máy mà không có ai chia lưu lượng cho chúng thì máy mới nằm không — hai dịch vụ này gần như luôn xuất hiện cùng nhau trong các kiến trúc mẫu |

Từ khoá nhận diện:

"EC2 Auto Scaling co giãn cái gì" → ⚠ SỐ LƯỢNG phiên bản "kích cỡ phiên bản" → ⚠ mở rộng theo chiều DỌC, phải dừng máy "scale out / scale in" → ⚠ chiều ngang "scale up / scale down" → ⚠ chiều dọc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng của bạn có chạy được trên nhiều máy song song không | | | Nhóm Auto Scaling của bạn đã đặt Maximum chưa | | | Có Load Balancer đứng trước nhóm đó không | |

Và điều mà mở rộng theo chiều ngang đòi hỏi ở chính ứng dụng, chứ không phải ở hạ tầng: máy có thể bị thêm vào hoặc gỡ đi bất cứ lúc nào, nên ứng dụng không được giữ trạng thái riêng trên máy nào cả.

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

Đề mô tả một chủ doanh nghiệp nhỏ không rành công nghệ ("not tech-savvy"), cần làm một dự án ngắn hạn ("short-term project"), và muốn một dịch vụ giúp họ kết nối với chuyên gia AWS được chứng nhận để nhận tư vấn và triển khai giải pháp nhanh chóng.

Cụm từ quyết định là "find AWS certified experts" kết hợp với "connect with professionals who can offer advice and help implement". Đây không phải nhu cầu mua phần mềm, không phải nhu cầu mở ticket kỹ thuật, cũng không phải nhu cầu tự đi học. Nhu cầu ở đây là thuê người — tìm, trao đổi và ký hợp đồng với một chuyên gia bên thứ ba cho một khối lượng công việc có giới hạn. Chỉ có một phương án trong danh sách làm đúng việc "ghép khách hàng với chuyên gia".

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

B — AWS IQ là đáp án đúng. AWS IQ là dịch vụ được thiết kế đúng cho mục đích này: kết nối khách hàng với các chuyên gia bên thứ ba đã có chứng chỉ AWS để nhận hỗ trợ theo yêu cầu (on-demand). Qua AWS IQ, chủ doanh nghiệp có thể tìm kiếm chuyên gia, trao đổi trực tiếp với họ, và thuê họ một cách nhanh chóng và an toàn để triển khai giải pháp hoặc dự án trên AWS.

Đây là điểm khớp hoàn hảo với tình huống: người dùng không rành kỹ thuật (nên cần người làm hộ chứ không cần công cụ), dự án ngắn hạn (nên cần thuê theo việc chứ không cần hợp đồng dài hạn), và cần cả tư vấn lẫn thực thi — đúng phạm vi mà AWS IQ phục vụ.

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

A — AWS Marketplace. Đây là gian hàng số để tìm, mua, triển khai và quản lý phần mềm, dịch vụ và dữ liệu của bên thứ ba. Phương án này gần đúng ở chỗ nó cũng là nơi giao dịch với bên thứ ba, nhưng thứ được giao dịch là sản phẩm phần mềm, không phải con người. Chủ doanh nghiệp trong đề không biết mình cần phần mềm gì — họ cần ai đó nghe nhu cầu rồi tự chọn và dựng giải pháp. Marketplace không làm việc ghép người và không thẩm định chứng chỉ AWS của cá nhân chuyên gia.

C — AWS Support. Đây là phương án dễ nhầm nhất, vì Support cũng là "được AWS giúp". Nhưng AWS Support cung cấp tài nguyên và công cụ để hỗ trợ khách hàng xây dựng, triển khai và vận hành ứng dụng — chủ yếu qua kênh hỗ trợ kỹ thuật (mở case, hỏi về sự cố, hướng dẫn kiến trúc tùy gói). Nó không phải nơi để kết nối trực tiếp với chuyên gia AWS được chứng nhận cho một dự án riêng. Nói cách khác, Support trả lời câu hỏi về dịch vụ AWS chứ không nhận làm dự án cho bạn. Với người "không rành công nghệ", việc mở case hỗ trợ cũng không giải được vấn đề vì họ không biết phải hỏi gì.

D — AWS Training and Certification. Đây là chương trình đào tạo và thi lấy chứng chỉ. Nó giúp người dùng học và hiểu các dịch vụ AWS tốt hơn — tức là biến chính người đó thành chuyên gia. Nhưng đề nói rõ hai điều đối nghịch: người này không rành công nghệ và cần làm việc nhanh chóng. Đi học không giải quyết được một dự án ngắn hạn. Quan trọng hơn, Training and Certification là nơi tạo ra chuyên gia, không phải nơi tìm và thuê chuyên gia — đó là vai trò của AWS IQ.

📌 Điểm cần nhớ

• AWS IQ = thuê người. Bất cứ khi nào đề nhắc tới "find/hire AWS certified experts", "third-party experts", "on-demand help" cho một dự án cụ thể, đáp án gần như chắc chắn là AWS IQ.
• AWS Marketplace = mua sản phẩm, không phải mua dịch vụ tư vấn cá nhân. Phân biệt bằng câu hỏi: đề đang cần phần mềm hay cần người?
• AWS Support = hỗ trợ vận hành chính tài khoản AWS của bạn (mở case, xử lý sự cố), không phải dịch vụ nhận triển khai dự án thay khách hàng.
• AWS Training and Certification = tự học, phù hợp khi đề nhấn mạnh nâng cao kỹ năng nội bộ, chứ không phù hợp khi đề nhấn mạnh nhanh và người dùng không có chuyên môn.

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

Đề nêu bối cảnh: công ty có global user base (người dùng rải khắp thế giới) và muốn triển khai dịch vụ AWS để giảm network latency cho những người dùng đó. Chọn HAI dịch vụ.

Cụm từ quyết định đáp án là "global user base" ghép với "decrease network latency". Chỉ một trong hai vế thôi là chưa đủ để loại phương án:

• Nếu chỉ xét "giảm latency", AWS Direct Connect cũng giảm latency thật — nhưng nó giảm cho một đường nối riêng từ trung tâm dữ liệu của công ty tới AWS, không giúp gì cho người dùng cuối phân tán toàn cầu.
• Nếu chỉ xét "global", Amazon VPC có mặt ở mọi Region nhưng bản thân nó không phải cơ chế rút ngắn quãng đường mạng.

Vậy phương án đúng phải là dịch vụ dùng mạng biên (Edge locations) trải toàn cầu để đưa điểm tiếp nhận lưu lượng lại gần người dùng cuối.

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

Theo tệp, đáp án là C — AWS Global Accelerator và E — Amazon CloudFront.

Amazon CloudFront là một content delivery network (CDN). Nó cache nội dung — tệp, ảnh, video — tại các Edge location đặt khắp thế giới. Người dùng ở xa origin sẽ được phục vụ từ Edge location gần mình thay vì phải đi tới tận Region chứa origin, nên quãng đường mạng ngắn lại và latency giảm.

AWS Global Accelerator đưa người dùng tới Region gần nhất có endpoint của ứng dụng. Lưu lượng đi vào mạng AWS ngay tại Edge location gần người dùng, rồi được chuyển tiếp trên AWS global network thay vì đi lòng vòng qua Internet công cộng. Hai bước này đều cắt bớt latency: rút ngắn chặng công cộng, và phần còn lại chạy trên hạ tầng mạng riêng của AWS.

Điểm chung: cả hai đều khai thác Edge location, tức là kiến trúc sinh ra để phục vụ đúng bài toán "người dùng ở khắp nơi".

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

A — Application Auto Scaling. Đây là dịch vụ tự động co giãn năng lực tính toán theo tải công việc. Nó giải quyết chuyện thiếu tài nguyên khi tải tăng, chứ không rút ngắn quãng đường gói tin phải đi. Có thể gián tiếp giữ thời gian phản hồi ổn định khi hệ thống quá tải, nhưng đó là vấn đề khác với network latency mà đề đang hỏi.

B — Amazon VPC. VPC là mạng ảo cô lập để bạn đặt tài nguyên vào. Nó là nơi chứa hạ tầng, không phải cơ chế tăng tốc. Triển khai ứng dụng trong VPC không làm người dùng ở châu Âu tới gần Region ở Bắc Mỹ hơn chút nào. Đây là phương án dễ chọn nhầm vì nó có chữ "network", nhưng không có thành phần biên toàn cầu nào ở đây.

D — AWS Direct Connect. Đây là phương án gần đúng nhất và đáng cảnh giác nhất. Direct Connect thực sự giảm latency: nó tạo kết nối mạng riêng, ổn định từ cơ sở của khách hàng tới AWS, bỏ qua Internet công cộng. Nhưng nó chỉ phục vụ một điểm đầu cuối cố định — trung tâm dữ liệu hoặc văn phòng của công ty. Người dùng toàn cầu không đi qua đường nối đó. Nó hỏng đúng ở vế "global user base" của đề, chứ không hỏng ở vế "giảm latency".

📌 Điểm cần nhớ

• Thấy "global users" + "latency" trong đề AWS thì hai cái tên cần nghĩ tới trước tiên là CloudFront và Global Accelerator — cả hai đều dựa trên Edge location.
• Phân biệt hai đáp án đúng: CloudFront cache nội dung ở biên (hợp với nội dung tĩnh, media); Global Accelerator định tuyến lưu lượng vào mạng AWS và tới Region gần nhất (hợp với ứng dụng động, không phải TCP/UDP nào cũng cache được).
• Direct Connect giảm latency cho kết nối doanh nghiệp ↔ AWS, không phải cho người dùng cuối phân tán. Đọc kỹ ai là người được hưởng lợi trước khi chọn.
• Auto Scaling giải bài toán năng lực xử lý, không giải bài toán khoảng cách mạng. Đừng lẫn "chậm vì quá tải" với "chậm vì ở xa".
• VPC là ranh giới mạng, không phải công cụ tăng tốc — nó xuất hiện trong rất nhiều câu như một phương án gây nhiễu có vẻ liên quan tới networking.

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

Đề hỏi: dịch vụ hoặc tính năng nào của AWS cho phép một công ty nhận một hoá đơn duy nhất hằng tháng khi dùng nhiều AWS account.

Cụm từ quyết định là "a single monthly AWS bill" kết hợp với "when using multiple AWS accounts". Đây là hai vế phải thoả cùng lúc:

• nhiều account — nên câu trả lời phải là thứ hoạt động ở phạm vi liên account, không phải trong một account đơn lẻ;
• một hoá đơn — nên câu trả lời phải làm việc gộp thanh toán, chứ không phải xem, phân tích hay báo cáo chi phí.

Đây chính là chỗ phân biệt: ba trong bốn phương án đều nằm trong nhóm "cost management" nghe rất giống nhau, nhưng chỉ một cái thực sự hợp nhất việc trả tiền. Những cái còn lại giúp bạn nhìn thấy tiền đi đâu — chúng không thay đổi việc bạn nhận bao nhiêu hoá đơn.

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

A. Consolidated billing là tính năng trong AWS Organizations cho phép gộp hoá đơn và thanh toán của nhiều AWS account (hoặc nhiều account AISPL) vào một chỗ. Mỗi organization có một master account (payer account) đứng ra trả toàn bộ chi phí của các member account (linked account).

Đúng như đề yêu cầu, lợi ích đầu tiên của consolidated billing là one bill — một hoá đơn cho nhiều account. Ngoài ra còn ba lợi ích thường được hỏi kèm:

• Easy tracking — theo dõi chi phí xuyên suốt các account và tải về dữ liệu cost & usage đã gộp;
• Combined usage — gộp mức sử dụng của tất cả account trong organization để cùng hưởng volume pricing discount, Reserved Instance discount và Savings Plans, nhờ đó tổng chi phí có thể thấp hơn so với để các account đứng riêng lẻ;
• No extra fee — bản thân consolidated billing không tính thêm phí.

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

B. Amazon Cloud Directory — sai và sai rõ nhất trong bốn phương án. Đây là dịch vụ tạo directory trên cloud (lưu trữ dữ liệu phân cấp kiểu thư mục, quan hệ nhiều chiều), hoàn toàn không liên quan đến billing. Chữ "Directory" có thể gợi cảm giác "quản lý tổ chức, nhiều account", nhưng nó là directory dữ liệu, không phải cấu trúc tổ chức account để thanh toán.

C. AWS Cost and Usage Report — đây là phương án gần đúng nhất và cũng là bẫy chính. Nó có liên quan trực tiếp đến chi phí, và consolidated billing quả thật cho phép tải về dữ liệu cost & usage đã gộp. Nhưng Cost and Usage Report chỉ liệt kê mức sử dụng theo từng service category của một account và các IAM user của nó, dưới dạng dòng chi tiết theo giờ hoặc theo ngày, kèm các tag đã bật cho cost allocation. Nói cách khác nó là báo cáo, không phải cơ chế thanh toán — nó mô tả chi phí đã phát sinh chứ không làm cho nhiều account cùng ra một hoá đơn. Bật report này mà không có consolidated billing thì mỗi account vẫn nhận hoá đơn riêng.

D. AWS Cost Explorer — cũng gần đúng, cũng thuộc nhóm cost management. Cost Explorer cung cấp giao diện trực quan để visualize, hiểu và quản lý chi phí cùng mức sử dụng AWS theo thời gian, có biểu đồ và bộ lọc. Chỗ nó hỏng đúng ở từ khoá của đề: Cost Explorer không centralize việc billing. Nó là công cụ phân tích để nhìn dữ liệu chi phí — kể cả khi nhìn được chi phí của nhiều account, việc trả tiền và số lượng hoá đơn vẫn do consolidated billing quyết định, chứ không do Cost Explorer.

📌 Điểm cần nhớ

• Gặp từ khoá "single bill" / "one bill" / "multiple accounts" trong đề thi → nghĩ ngay tới consolidated billing trong AWS Organizations, với mô hình payer account trả cho các linked account.
• Phân biệt ba lớp công cụ chi phí thường bị nhầm: Consolidated billing = gộp thanh toán, Cost Explorer = xem và phân tích trực quan, Cost and Usage Report = báo cáo chi tiết dạng dòng. Chỉ cái đầu tiên thay đổi cách bạn nhận hoá đơn.
• Ngoài "one bill", consolidated billing còn được hỏi ở khía cạnh combined usage — gộp mức dùng để chia sẻ volume discount, Reserved Instance và Savings Plans — và ở chỗ nó không tính thêm phí.
• Đừng để một cái tên nghe "có vẻ liên quan đến tổ chức" đánh lừa: Amazon Cloud Directory là dịch vụ directory dữ liệu, không dính gì tới billing hay quản lý account.

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

Đề hỏi: công cụ nào của Amazon EC2 đóng vai trò "virtual firewall" để kiểm soát traffic vào (inbound) và ra (outbound) của một EC2 instance?

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

• "to an EC2 instance" — phạm vi áp dụng là từng instance, không phải subnet, không phải toàn bộ ứng dụng web.
• "virtual firewall ... inbound and outbound" — thứ được hỏi là một bộ lọc traffic hai chiều, gắn trực tiếp vào tài nguyên.

Đây là kiểu câu cố tình xếp cạnh nhau bốn thứ đều "liên quan tới chặn traffic" trong AWS. Cả security group lẫn network ACL đều là virtual firewall và đều lọc hai chiều, nên chữ "EC2 instance" mới là ràng buộc phân biệt: nó chỉ ra tầng (instance-level hay subnet-level) mà đề muốn.

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

Đáp án đúng theo tệp là C — Security group.

Security group hoạt động đúng như mô tả trong đề: nó là một virtual firewall kiểm soát traffic được phép đến và rời khỏi các tài nguyên mà nó được gắn vào. Khi bạn associate một security group với một EC2 instance, chính security group đó quyết định inbound và outbound traffic của instance ấy.

Hai điểm khớp chính xác với từ ngữ của đề:

• Nó gắn vào instance (thực chất là gắn vào network interface của instance) — đúng tầng mà đề nêu.
• Nó có cả inbound rules và outbound rules — đúng chiều mà đề nêu.

Security group cũng nằm bên trong VPC, tức là một thành phần networking của chính EC2/VPC, khớp với cách đề gọi nó là "Amazon EC2 tool".

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

A — AWS Shield. Đây là dịch vụ managed bảo vệ khỏi tấn công DDoS. Nó phát hiện và giảm thiểu lưu lượng tấn công quy mô lớn, chứ không phải công cụ để bạn khai báo luật "cho phép port này, chặn IP kia" trên một instance. Shield không phải firewall theo nghĩa quản trị viên tự đặt rule inbound/outbound, nên trượt ngay ở định nghĩa.

B — Network access control list (ACL). Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Network ACL đúng là một virtual firewall, đúng là kiểm soát cả inbound lẫn outbound, và đúng là nằm trong VPC. Chỗ nó hỏng là tầng áp dụng: Network ACL hoạt động ở mức subnet, lọc traffic ra vào subnet cho mọi tài nguyên bên trong subnet đó. Nó không gắn vào một EC2 instance cụ thể. Đề hỏi thẳng "to an EC2 instance", nên Network ACL sai phạm vi chứ không sai bản chất.

D — AWS WAF. Là Web Application Firewall, đặt phía trước ứng dụng web để lọc request ở tầng ứng dụng theo các luật kiểu SQL injection, cross-site scripting, chuỗi ký tự trong request. Nó không phải công cụ gắn vào EC2 instance trong VPC để mở/đóng traffic ra vào instance đó. Chữ "firewall" trong tên khiến nó trông hợp lý, nhưng loại firewall và vị trí triển khai đều khác thứ đề đang hỏi.

📌 Điểm cần nhớ

• Trong VPC có hai virtual firewall lọc hai chiều: security group ở tầng instance, network ACL ở tầng subnet. Khi cả hai cùng xuất hiện trong phương án, hãy tìm trong đề chữ chỉ phạm vi — "instance" → security group, "subnet" → network ACL.
• AWS Shield = chống DDoS, không phải nơi bạn viết rule cho phép/chặn traffic.
• AWS WAF = firewall tầng ứng dụng web, đặt trước ứng dụng, lọc nội dung HTTP request — khác hẳn firewall lọc traffic ra vào instance.
• Chữ "firewall" xuất hiện trong tên dịch vụ (WAF) không có nghĩa nó là đáp án; hãy đối chiếu loại traffic được lọc và vị trí đặt với mô tả trong đề.

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

Đề hỏi: mô hình giá EC2 nào cần TRÁNH nếu khối lượng công việc không chấp nhận được việc bị gián đoạn khi capacity tạm thời không còn khả dụng?

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

• "cannot accept interruption" — workload không chịu được gián đoạn.
• "if capacity becomes temporarily unavailable" — gián đoạn xảy ra vì AWS cần lại phần capacity đang dư thừa.

Đây chính là mô tả nguyên văn cơ chế của Spot Instances. Cũng lưu ý đề hỏi ngược: hỏi cái nào nên tránh, chứ không phải cái nào nên dùng. Đọc lướt rất dễ đi chọn On-Demand vì đó là câu trả lời quen thuộc cho "workload cần chạy ổn định".

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

Đáp án đúng là C – Spot Instances.

Spot Instances cho phép tận dụng phần capacity EC2 đang nhàn rỗi trong AWS cloud, đổi lại được mức giá rẻ hơn On-Demand rất nhiều (theo tài liệu AWS, mức chiết khấu có thể lên tới khoảng 90%).

Cái giá phải trả nằm ở chỗ: phần capacity đó không thuộc về bạn, bạn chỉ đang mượn lúc AWS chưa dùng đến. Khi capacity trở nên tạm thời không khả dụng — tức AWS cần lại nó — instance của bạn có thể bị terminate. Đúng với ràng buộc "cannot accept interruption" trong đề, nên Spot chính là mô hình phải tránh.

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

A – Standard Reserved Instances. Reserved Instances là một cam kết sử dụng dài hạn để đổi lấy giá thấp hơn. Nó không bị gián đoạn khi capacity tạm thời không khả dụng. Standard RI có hạn chế thật, nhưng hạn chế đó nằm ở tính linh hoạt — bị ràng buộc vào cấu hình đã cam kết, không đổi sang họ instance khác được — chứ hoàn toàn không phải rủi ro bị ngắt giữa chừng. Đề hỏi về gián đoạn, nên điểm yếu về tính linh hoạt không liên quan.

B – On-Demand Instances. Đây là phương án dễ chọn nhầm nhất, vì On-Demand là mô hình đắt nhất trong bốn cái nên nhiều người phản xạ "cái đắt là cái nên tránh". Nhưng tiêu chí của đề là gián đoạn, không phải chi phí. On-Demand trả tiền theo mức sử dụng, không cam kết, và không bị terminate vì lý do capacity tạm thời không khả dụng. Nó chính là lựa chọn an toàn cho workload không chịu được gián đoạn — tức là ngược hẳn với thứ đề đang hỏi.

D – Convertible Reserved Instances. Cũng là Reserved Instances, chỉ khác Standard ở chỗ cho phép đổi sang cấu hình instance khác trong thời gian cam kết (đánh đổi bằng mức chiết khấu thấp hơn Standard). Điểm khác biệt đó thuần tuý về khả năng thay đổi cấu hình, không dính gì tới việc bị ngắt. Reserved Instances nói chung không chịu rủi ro gián đoạn do capacity, nên D sai cùng lý do với A.

📌 Điểm cần nhớ

• Spot Instances là mô hình EC2 duy nhất có thể bị gián đoạn. Thấy từ khoá "interruption", "may be terminated", "capacity becomes unavailable", "fault-tolerant workload" trong đề là gần như chắc chắn đang nói tới Spot.
• Phân biệt hai trục đánh đổi khác nhau: Spot đánh đổi độ tin cậy lấy giá rẻ; Reserved đánh đổi tính linh hoạt (cam kết dài hạn) lấy giá rẻ. On-Demand không đánh đổi gì cả nên đắt nhất.
• Standard RI và Convertible RI chỉ khác nhau ở khả năng đổi cấu hình instance, không khác nhau về rủi ro gián đoạn. Khi cả hai cùng xuất hiện trong đáp án và đề đang hỏi về gián đoạn, loại được cả hai một lượt.
• Đọc kỹ chiều của câu hỏi: "should be avoided" đảo ngược logic chọn so với "which should be used". Cùng một dữ kiện nhưng đáp án nằm ở hai đầu đối lập.

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

Đề hỏi: Service Control Policy (SCP) — thứ dùng để quản lý "maximum available permissions" — gắn liền với cái gì trong số bốn lựa chọn.

Cụm từ quyết định là "manage the maximum available permissions" (quản lý mức quyền tối đa có thể có). Đây là mô tả kinh điển của một permission guardrail — một hàng rào chặn trên, áp cho tài khoản (account). Cụm này lập tức loại bỏ mọi thứ thuộc về nơi chốn vật lý của hạ tầng, vì quyền hạn là khái niệm quản trị/danh tính, không phải khái niệm địa lý.

Điểm cần chú ý thứ hai: SCP là một loại organization policy. Chỉ cần nhớ chữ "organization" trong định nghĩa là đã trỏ thẳng tới dịch vụ có tên chứa đúng chữ đó trong danh sách phương án.

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

D. AWS Organizations — theo đáp án trong tệp và phần giải thích gốc.

SCP là một dạng chính sách của AWS Organizations, dùng để kiểm soát tập trung mức quyền tối đa cho các tài khoản nằm trong organization. Ba ý cần nắm:

• SCP không cấp quyền, nó chỉ đặt trần. Một hành động chỉ thực hiện được khi vừa được IAM policy trong tài khoản cho phép, vừa không bị SCP chặn. Đây chính là nghĩa của "maximum available permissions".
• SCP gắn vào các thực thể trong cây quản trị của AWS Organizations: root, Organizational Unit (OU), hoặc từng account — tức là các đối tượng chỉ tồn tại khi có AWS Organizations.
• SCP giúp bảo đảm các tài khoản luôn nằm trong khuôn khổ chính sách kiểm soát truy cập của tổ chức, và chỉ dùng được khi organization đã bật all features (không dùng được ở chế độ chỉ hợp nhất hoá đơn).

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

• A. Availability Zones — AZ là một hoặc nhiều trung tâm dữ liệu tách biệt bên trong một Region, phục vụ mục tiêu độ sẵn sàng và chịu lỗi. Bạn triển khai tài nguyên vào một AZ, chứ không "gắn chính sách quyền" vào AZ. SCP không hề có khái niệm attach vào AZ.

• B. AWS Global Infrastructure — đây là tên gọi chung cho toàn bộ hạ tầng vật lý của AWS (Regions, AZ, edge locations), không phải một dịch vụ hay một thực thể mà bạn có thể attach chính sách vào. Phương án này nghe "to tát" nên dễ gây phân vân, nhưng nó không phải đối tượng quản trị — bạn không thể mở console lên và gắn SCP vào "global infrastructure".

• C. AWS Regions — đây là phương án gần đúng nhất và bẫy nhất. Lý do bẫy: SCP thật sự có thể hạn chế theo Region thông qua điều kiện trong nội dung chính sách (ví dụ chặn hành động ngoài một số Region). Nhưng đề không hỏi "SCP có thể hạn chế cái gì", mà hỏi SCP được associated với cái gì. Region ở đây chỉ là nội dung có thể viết bên trong chính sách; còn nơi chính sách được gắn vào vẫn là root/OU/account của AWS Organizations. Nhầm giữa "điều kiện trong policy" và "đối tượng attach policy" là chỗ hỏng của phương án này.

📌 Điểm cần nhớ

• SCP = organization policy của AWS Organizations, attach vào root / OU / account — không attach vào bất cứ thành phần hạ tầng vật lý nào.
• SCP đặt trần quyền, không cấp quyền. Quyền thực tế = phần giao nhau giữa IAM policy trong account và trần do SCP quy định; account quản trị gốc (management account) không bị SCP ràng buộc theo cách như các member account.
• Phân biệt "gắn vào cái gì" với "hạn chế cái gì". SCP có thể viết điều kiện nhắc tới Region hay dịch vụ, nhưng đối tượng được gắn chính sách vẫn nằm trong cây AWS Organizations.
• Với đề Cloud Practitioner: hễ thấy Region / Availability Zone / Global Infrastructure trong câu hỏi về quyền hạn hay chính sách, gần như chắc chắn chúng là phương án nhiễu — đó là khái niệm về vị trí hạ tầng, không phải về kiểm soát truy cập.

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

Đề bài hỏi: AWS có thể liên tục giảm giá là nhờ đâu? — nghĩa là hỏi về nguyên nhân gốc khiến đơn giá đi xuống theo thời gian, chứ không hỏi "mô hình giá nào giúp khách hàng tiết kiệm".

Cụm từ quyết định là "are able to continue to reduce their pricing" — hai chữ đáng chú ý:

• "reduce": giá giảm xuống theo thời gian, tức là đơn giá của cùng một dịch vụ hôm nay rẻ hơn trước.
• "continue to": đây là xu hướng lặp đi lặp lại, không phải một chương trình khuyến mãi hay một lựa chọn mua hàng cụ thể.

Đây chính là ràng buộc phân biệt bốn phương án. Ba trong bốn phương án đều là những thứ có thật và có lợi cho khách hàng, nhưng chúng trả lời câu hỏi khác: "khách hàng trả tiền theo cách nào" hoặc "nền tảng gồm những gì". Chỉ một phương án trả lời đúng câu hỏi "vì sao AWS có khả năng hạ giá".

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

D — Economies of scale (hiệu quả nhờ quy mô).

Đây là lập luận nằm ngay trong tài liệu nền tảng của AWS về lợi ích của cloud computing: khi nhu cầu sử dụng của hàng trăm nghìn khách hàng được gộp chung lại trên cùng một hạ tầng, AWS đạt được quy mô mua sắm và vận hành rất lớn — mua phần cứng, điện, băng thông với chi phí trên mỗi đơn vị thấp hơn nhiều so với việc từng tổ chức tự dựng trung tâm dữ liệu riêng. Chi phí trên mỗi đơn vị giảm thì AWS chuyển phần tiết kiệm đó thành đơn giá pay-as-you-go thấp hơn cho khách hàng.

Điểm mấu chốt: economies of scale là nguyên nhân phía nhà cung cấp, nên nó giải thích được cả chữ "continue" — càng nhiều khách hàng dùng, quy mô càng lớn, chi phí đơn vị càng có dư địa giảm tiếp. Các phương án còn lại đều là kết quả hoặc cách bán hàng, không phải nguyên nhân.

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

A — Pay-as-you-go pricing. Đây là mô hình trả tiền theo mức dùng thực tế, giúp khách hàng tránh đầu tư trước và chỉ trả cho phần đã tiêu thụ. Nó là một lợi ích thật sự, và cũng chính là kênh mà việc giảm giá được truyền tới khách hàng. Nhưng bản thân cách tính tiền theo mức dùng không làm cho đơn giá rẻ đi: bạn vẫn trả theo bảng giá hiện hành, chỉ khác là trả theo lượng dùng. Đây là phương án gần đúng nhất và hay bị chọn nhầm — cần tách bạch "cách thu tiền" với "nguyên nhân giá đơn vị giảm".

B — The AWS global infrastructure. Hạ tầng toàn cầu (các Region, Availability Zone, edge location) là nền tảng của platform, mang lại độ sẵn sàng cao, khả năng chịu lỗi và độ trễ thấp cho người dùng ở gần. Nó là điều kiện để AWS đạt quy mô, nhưng bản thân việc có nhiều Region không phải lý do giá tiếp tục giảm — mở thêm hạ tầng còn là khoản đầu tư tốn kém. Chọn B là nhầm giữa "AWS có gì" với "vì sao AWS hạ giá được".

C — Reserved instance pricing. Đây là mô hình cam kết dùng trong thời hạn nhất định để đổi lấy mức giá thấp hơn so với On-Demand. Nó giúp một nhóm khách hàng cụ thể tiết kiệm trên một số dịch vụ cụ thể, và khoản tiết kiệm đó đến từ việc khách hàng chấp nhận cam kết trước, chứ không phải từ việc bảng giá chung được hạ xuống. Reserved instance là lựa chọn mua hàng, không giải thích được xu hướng giảm giá trên toàn bộ danh mục dịch vụ.

📌 Điểm cần nhớ

• Khi đề hỏi "vì sao AWS có thể giảm giá", hãy tìm nguyên nhân phía nhà cung cấp (economies of scale), đừng chọn tên một mô hình giá dành cho khách hàng.
• Phân biệt ba nhóm khái niệm hay bị trộn lẫn trong đề Cloud Practitioner: mô hình giá (pay-as-you-go, Reserved instance), thành phần nền tảng (global infrastructure), và lợi ích kinh tế của cloud (economies of scale).
• Economies of scale = gộp nhu cầu của rất nhiều khách hàng → chi phí trên mỗi đơn vị thấp hơn → truyền lại thành đơn giá pay-as-you-go thấp hơn. Chuỗi nhân quả này là câu trả lời chuẩn cho cả nhóm câu hỏi về lợi thế chi phí của cloud.
• Pay-as-you-go trả lời câu hỏi "trả tiền như thế nào"; economies of scale trả lời "vì sao đơn giá rẻ đi". Đọc kỹ động từ trong đề để biết đang hỏi vế nào.

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

Đề mô tả một người dùng có ít kiến thức về AWS nhưng muốn triển khai nhanh một ứng dụng Node.js có khả năng mở rộng (scalable) bên trong một Amazon VPC. Câu hỏi: nên dùng dịch vụ nào để triển khai ứng dụng đó?

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

• "limited knowledge of AWS services" — loại bỏ các lựa chọn đòi hỏi người dùng tự dựng và tự cấu hình hạ tầng.
• "quickly deploy … scalable" — cần một dịch vụ tự lo phần cấp phát tài nguyên, load balancing và auto scaling, chứ không phải người dùng tự ghép từng mảnh.
• "in an Amazon VPC" — đây là ràng buộc phân biệt quan trọng nhất, vì nó loại đúng phương án dễ nhầm nhất trong danh sách.

Chỉ cần bỏ qua một trong ba cụm này là chọn nhầm ngay: bỏ "limited knowledge" thì EC2 nghe hợp lý, bỏ "in a VPC" thì Lightsail nghe hợp lý.

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

Đáp án đúng theo tệp là C — AWS Elastic Beanstalk.

Elastic Beanstalk là dịch vụ dễ dùng để triển khai và mở rộng web application, hỗ trợ sẵn nhiều nền tảng trong đó có Node.js (cùng với Java, .NET, PHP, Python, Ruby, Go, Docker) chạy trên các web server quen thuộc như Apache, Nginx, Passenger, IIS.

Điểm khớp trực tiếp với đề: người dùng chỉ cần tải mã nguồn lên, còn Elastic Beanstalk tự động lo toàn bộ phần triển khai — cấp phát capacity, load balancing, auto scaling và giám sát tình trạng ứng dụng. Đó chính là "quickly deploy" và "scalable" mà không đòi hỏi kiến thức AWS sâu.

Đồng thời, Elastic Beanstalk vẫn dựng tài nguyên AWS thật bên dưới (EC2, load balancer…) trong tài khoản của bạn, đặt trong VPC, và người dùng giữ toàn quyền kiểm soát cũng như truy cập được các tài nguyên đó bất cứ lúc nào. Nhờ vậy nó thoả luôn ràng buộc "in an Amazon VPC" — vừa đơn giản cho người mới, vừa chạy đúng trong môi trường mạng mà đề yêu cầu.

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

A — AWS CloudFormation. CloudFormation dùng để tự động hoá việc triển khai hạ tầng trong AWS: bạn mô tả tài nguyên bằng template rồi để nó dựng lên. Nó không phải công cụ "đưa mã Node.js lên là chạy". Ngược lại, muốn viết template thì bạn phải biết trước mình cần những tài nguyên nào và cấu hình chúng ra sao — tức là đòi hỏi kiến thức AWS nhiều hơn, đi ngược hẳn với "limited knowledge".

B — Amazon EC2. Đây là phương án về mặt kỹ thuật thì làm được: bạn tự khởi tạo instance trong VPC, tự cài Node.js, tự gắn load balancer và Auto Scaling group. Vấn đề là cách này đòi hỏi chuyên môn cao hơn nhiều so với Elastic Beanstalk. Đề nói rõ người dùng ít kinh nghiệm và muốn triển khai nhanh, nên EC2 "thô" không phải lựa chọn phù hợp nhất. Lưu ý: đây chính là thứ Elastic Beanstalk dựng giúp bạn ở bên dưới — nên chọn EC2 là chọn phần việc thủ công của cùng một kết quả.

D — Amazon Lightsail. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất. Lightsail đúng là dịch vụ tốt cho người chưa rành AWS — nó gói sẵn máy chủ với giá đơn giản, đúng vế "limited knowledge". Nhưng nó hỏng ở vế còn lại của đề: bạn không triển khai được một ứng dụng Node.js có khả năng mở rộng vào trong một Amazon VPC theo cách đề yêu cầu. Cụm "in an Amazon VPC" trong đề tồn tại chính là để loại phương án này. Nếu đề chỉ dừng ở "người mới, muốn nhanh" mà không nhắc VPC và scalable, Lightsail đã là ứng viên rất mạnh.

📌 Điểm cần nhớ

• Elastic Beanstalk = "upload code, AWS lo phần còn lại": nền tảng lo capacity, load balancing, auto scaling, health monitoring, nhưng tài nguyên bên dưới vẫn là của bạn và vẫn truy cập được.
• Phân biệt vai trò: Elastic Beanstalk triển khai ứng dụng, CloudFormation triển khai hạ tầng bằng template, EC2 là tài nguyên thô cần bạn tự ghép. Đề nhấn "ứng dụng" và "nhanh" thì hướng về Elastic Beanstalk.
• Khi đề vừa nói "người dùng ít kinh nghiệm" vừa nói "trong VPC / scalable", Lightsail bị loại bởi vế VPC chứ không phải bởi vế đơn giản — nhớ cặp phân biệt này vì nó lặp lại ở nhiều câu Cloud Practitioner.
• Chiến thuật chung: câu hỏi loại "chọn dịch vụ" hầu như luôn có hai ràng buộc, một về mức độ dễ dùng và một về kỹ thuật. Phương án gần đúng thường chỉ thoả một trong hai.

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

Đề hỏi: lợi thế (advantage) của việc chạy workload trên AWS Cloud so với on-premises, và yêu cầu chọn HAI.

Cụm từ quyết định ở đây là "advantage ... vs on-premises". Đây là dạng câu hỏi khái niệm nền tảng, không hỏi về dịch vụ cụ thể nào — nên cách lọc phương án nhanh nhất là kiểm tra chiều của mỗi mệnh đề: nó mô tả điều gì đó tốt lên hay xấu đi khi chuyển sang cloud. Ba trong năm phương án được viết theo chiều ngược (higher costs, increased time to market, lower utilization) — chúng là mô tả nhược điểm hoặc mô tả sai, nên bị loại bằng chính chiều của từ ngữ, chưa cần bàn tới kỹ thuật.

Lưu ý một cái bẫy ngôn ngữ: "increased time to market" nghe tích cực vì có chữ "increased", nhưng time to market là khoảng thời gian — tăng nó lên nghĩa là ra mắt chậm hơn. Đây gần như chắc chắn là phương án gài của câu này.

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

Đáp án theo tệp là C và E.

C — Increased productivity for application development teams. Khi hạ tầng do AWS cung cấp sẵn, đội phát triển không còn phải dành thời gian cho tầng hạ tầng: mua sắm, lắp đặt, đi dây, cài đặt hệ điều hành, vá lỗi phần cứng. Thời gian đó được trả lại cho việc viết tính năng cho ứng dụng — tức là năng suất của đội phát triển tăng lên. Đây chính là ý mà AWS gọi là "stop spending money running and maintaining data centers" và "focus on projects that differentiate your business".

E — Less staff time is required to launch new workloads. Trên on-premises, mở một workload mới nghĩa là phải qua chu trình mua sắm và lắp đặt phần cứng trước đã. Trên AWS không có tầng phần cứng nào để cấu hình, và việc triển khai ứng dụng có thể tự động hoá được — nên công sức nhân sự bỏ ra để đưa một workload mới lên chạy giảm đi đáng kể.

Hai đáp án này thực chất là hai mặt của cùng một lợi ích (bỏ được gánh nặng hạ tầng), nên chúng cùng đúng là hợp lý trong câu "Select TWO".

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

A — Higher acquisition costs to support elastic workloads. Sai vì mô tả ngược chiều. Với on-premises, để phục vụ workload co giãn thì phải mua sẵn phần cứng đủ cho lúc cao điểm, và số tiền đó bỏ ra trước. Trên AWS, chi phí đi theo hướng thấp hơn vì trả theo mức dùng thực tế thay vì mua trước cho đỉnh tải. Chi phí cao hơn không phải là "advantage" dưới bất kỳ cách đọc nào.

B — Increased time to market for new application features. Đây là phương án gần đúng nhất và cũng là bẫy chính. Ý tưởng nền — cloud liên quan tới tốc độ ra mắt tính năng — là đúng, nhưng chiều bị viết ngược. AWS làm giảm time to market, không làm tăng. Nếu phương án ghi "decreased time to market" thì nó đã là một đáp án đúng. Chỗ hỏng nằm đúng ở một từ.

D — Lower overall utilization of server and storage systems. Cũng ngược chiều, và ngược ở chỗ tinh hơn A. Utilization thấp nghĩa là tài nguyên đã trả tiền nhưng nằm không — đó chính là vấn đề của on-premises khi phải mua dư cho đỉnh tải. Cloud giúp nâng mức tận dụng lên nhờ cấp phát đúng nhu cầu. Utilization thấp hơn không phải lợi ích, nó là lãng phí.

📌 Điểm cần nhớ

• Với câu hỏi "advantage của cloud vs on-premises", hãy kiểm chiều của mệnh đề trước khi kiểm nội dung: higher cost, lower utilization, increased time to market đều là chiều xấu và bị loại ngay.
• "Time to market" là một khoảng thời gian, không phải một điểm tốt. "Increased time to market" = chậm hơn. Đây là bẫy ngôn ngữ lặp lại rất nhiều trong đề Cloud Practitioner.
• Lợi ích cốt lõi của cloud ở tầng khái niệm là bỏ được tầng hạ tầng: từ đó suy ra năng suất đội phát triển tăng, thời gian nhân sự để mở workload mới giảm, và thời gian ra mắt tính năng rút ngắn.
• Utilization cao là tốt, không phải thấp. On-premises buộc phải mua dư cho đỉnh tải nên phần lớn thời gian tài nguyên nằm không; cloud cấp phát theo nhu cầu nên tận dụng tốt hơn.