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

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

Đề hỏi: người dùng có thể làm những việc gì để tối ưu chi phí Amazon EC2? (Chọn HAI.)

Cụm từ quyết định là "optimize Amazon EC2 costs" — tối ưu chi phí thực sự phát sinh của EC2. Đây là chỗ dễ trượt nhất, vì trong năm phương án có tới ba cái nghe rất "liên quan tới tiền" hoặc "liên quan tới kiểm soát": đặt ngân sách, chặn quyền truy cập console, gom tài nguyên về một Region. Nhưng tối ưu chi phí nghĩa là trả ít tiền hơn cho cùng khối lượng công việc — hoặc bằng cách giảm đơn giá, hoặc bằng cách chỉ chạy đúng số máy đang cần. Mọi thứ chỉ theo dõi, cảnh báo hay hạn chế quyền con người đều không làm giảm hoá đơn EC2.

Cách phân loại nhanh: phương án nào tác động vào đơn giá hoặc số lượng/thời lượng instance chạy thì mới là tối ưu chi phí.

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

B — Purchase Amazon EC2 Reserved Instances. Đây là hướng giảm đơn giá. Với những workload chạy ổn định, đoán trước được và kéo dài, việc cam kết dùng trong một kỳ hạn cho phép trả mức giá thấp hơn đáng kể so với On-Demand. Đổi lại là cam kết — nên nó phù hợp cho phần tải nền chạy liên tục, và đúng là biện pháp tối ưu chi phí về dài hạn.

C — Implement Auto Scaling groups to add and remove instances based on demand. Đây là hướng giảm lượng tài nguyên chạy. Auto Scaling thêm instance khi tải tăng và gỡ bớt instance khi tải giảm, nên bạn không phải nuôi sẵn một dàn máy theo mức đỉnh 24/7. Vế "remove instances" mới là vế tiết kiệm tiền — đây chính là mô hình trả theo nhu cầu thật mà cloud hướng tới.

Hai phương án này bổ sung cho nhau: Reserved Instances phủ phần tải nền, Auto Scaling xử lý phần tải biến động.

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

A — Create users in a single Region to reduce the spread of EC2 instances globally. Sai ngay ở tiền đề kỹ thuật: IAM user là tài nguyên global, không tạo "trong một Region" được. Câu này ghép một khái niệm không tồn tại với một lập luận nghe hợp lý (gom tài nguyên lại cho gọn). Kể cả bỏ qua lỗi đó, việc quản lý user cũng không phải là công cụ điều khiển vị trí hay số lượng EC2 instance.

D — Create a policy to restrict IAM users from accessing the Amazon EC2 console. Đây là kiểm soát truy cập, không phải tối ưu chi phí. Nó chặn hoàn toàn khả năng làm việc với EC2 của người dùng — quá tay so với mục tiêu đề ra, và những instance đang chạy vẫn tính tiền y nguyên. Chặn console không tắt được máy nào cả. Đây là phương án dễ bị chọn vì nghe như "ngăn người ta bật thêm máy", nhưng nó giải quyết vấn đề quản trị quyền chứ không giải quyết chi phí.

E — Set a budget to limit spending on Amazon EC2 instances using AWS Budgets. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu. AWS Budgets là công cụ theo dõi và cảnh báo chi tiêu: bạn đặt ngưỡng, khi chi tiêu chạm hoặc dự báo sẽ chạm ngưỡng thì nhận thông báo. Chỗ hỏng nằm ở chữ "limit spending" — bản thân việc đặt budget không tự chặn chi tiêu, không tự tắt instance, hoá đơn vẫn tiếp tục tăng nếu bạn không hành động. Nó giúp bạn biết mình đang tiêu quá, còn việc tiêu ít đi vẫn phải do B và C làm.

📌 Điểm cần nhớ

• Phân biệt rõ ba nhóm khi gặp câu về chi phí: tối ưu (giảm đơn giá hoặc giảm lượng tài nguyên), theo dõi/cảnh báo (AWS Budgets), và kiểm soát quyền (IAM policy). Chỉ nhóm đầu trả lời được câu hỏi "optimize costs".
• AWS Budgets thông báo chứ không chặn. Thấy phương án nào nói Budgets "limit"/"prevent"/"stop" chi tiêu thì cân nhắc loại ngay.
• Hai trục tối ưu chi phí EC2 kinh điển: giá (Reserved Instances cho tải ổn định, đoán trước được) và lượng (Auto Scaling co giãn theo nhu cầu thật). Câu hỏi "Select TWO" về chi phí EC2 rất hay rơi đúng vào cặp này.
• IAM user là tài nguyên global, không thuộc Region nào. Phương án nào nói "tạo user trong một Region" là sai về mặt kiến thức nền, bất kể phần lập luận phía sau nghe hợp lý ra sao.
• Với Auto Scaling, phần tiết kiệm tiền nằm ở khả năng gỡ bớt instance khi hết tải, không chỉ ở khả năng thêm vào khi quá tải.

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

Đề mô tả một công ty thương mại điện tử cần một dịch vụ AWS để gửi transactional email — thư xác nhận đơn hàng, thư đặt lại mật khẩu — tới khách hàng của họ.

Cụm từ quyết định đáp án là "send transactional emails ... to their customers". Có hai chi tiết cần tách bạch trong cụm này:

• "emails" — đầu ra bắt buộc phải là email thật, gửi tới hộp thư của người nhận. Điều này loại ngay những dịch vụ chỉ vận chuyển message giữa các thành phần trong hệ thống.
• "transactional" — mỗi thư gắn với một hành động cụ thể của một người dùng cụ thể: người này vừa đặt đơn hàng, người kia vừa bấm quên mật khẩu. Nội dung riêng cho từng người, gửi one-to-one. Đây chính là chi tiết phân biệt SES với SNS, vốn là mô hình publish tới nhiều subscriber cùng lúc.

Ngoài ra đề hỏi dịch vụ "most appropriate" — tức là dịch vụ chuyên trách đúng việc này, chứ không phải thứ "về lý thuyết cũng làm được".

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

B — Amazon Simple Email Service (Amazon SES) là dịch vụ được thiết kế riêng cho việc gửi email: transactional email, marketing email, và các loại nội dung khác gửi tới khách hàng.

Đúng ba lý do:

• Đúng bản chất công việc. SES là email service, sản phẩm đầu ra của nó là email gửi tới địa chỉ người nhận — khớp trực tiếp với "order confirmations and password resets".
• Đúng mô hình transactional. SES gửi thư tới địa chỉ người nhận được ứng dụng chỉ định trong từng lần gọi, nên mỗi đơn hàng gửi được một thư riêng với nội dung riêng, không cần người nhận đăng ký trước.
• Đúng tiêu chí "most appropriate". SES cung cấp cách gửi email đáng tin cậy và tiết kiệm chi phí cho doanh nghiệp — đúng thứ công ty e-commerce trong đề cần, không phải dựng thêm gì.

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

A — Amazon SNS. Đây là phương án gần đúng nhất, và nó có bẫy thật: SNS có hỗ trợ giao thức email, nên nó gửi được thông báo qua email. Nhưng SNS được thiết kế cho mô hình publish/subscribe — đẩy một message tới một tập người nhận đã đăng ký (distributed set of recipients), thường là nhiều subscriber cùng lúc, và người nhận phải subscribe vào topic trước. Nó không được tối ưu cho transactional email: không phải là nơi để soạn thư xác nhận đơn hàng có định dạng riêng gửi cho đúng một khách vừa mua hàng. Hỏng ở chỗ mô hình gửi (broadcast tới subscriber) không khớp với yêu cầu (one-to-one theo hành động của từng người dùng).

C — Amazon EC2. EC2 là dịch vụ compute — cho thuê máy chủ ảo để chạy ứng dụng. Về lý thuyết bạn có thể tự cài một mail server lên EC2 rồi tự gửi thư, nên nhiều người thấy "không hẳn là không làm được". Nhưng EC2 không cung cấp chức năng chuyên biệt nào cho việc gửi transactional email — toàn bộ phần khó (vận hành mail server, tính tin cậy khi gửi) đều đổ về phía bạn. Với câu hỏi "dịch vụ nào phù hợp nhất", trả lời bằng một nền tảng compute chung là chệch cấp độ trừu tượng.

D — Amazon SQS. SQS là message queue dùng để decouple các thành phần của ứng dụng cần truyền thông tin cho nhau. Message trong SQS nằm trong hàng đợi chờ một thành phần khác trong hệ thống của bạn đến lấy về xử lý — nó không bao giờ tự đi ra ngoài tới hộp thư của khách hàng. Sai hoàn toàn về đầu ra: SQS không phải công cụ gửi email.

📌 Điểm cần nhớ

• Thấy từ khoá "send email to customers" trong đề AWS → nghĩ ngay tới Amazon SES. Đó là dịch vụ chuyên trách gửi email, cả transactional lẫn marketing.
• Phân biệt SES với SNS bằng mô hình gửi: SES gửi email tới địa chỉ người nhận theo từng lần gọi (one-to-one, transactional); SNS là pub/sub, đẩy notification tới các subscriber đã đăng ký topic. SNS gửi được email nhưng không phải để làm thư xác nhận đơn hàng.
• Phân biệt SNS với SQS: cả hai đều là messaging nhưng SNS là push tới subscriber, SQS là hàng đợi để thành phần khác kéo message về xử lý — SQS chỉ giao tiếp bên trong hệ thống, không giao tiếp với khách hàng cuối.
• Câu hỏi dạng "most appropriate service" luôn ưu tiên dịch vụ được thiết kế riêng cho việc đó (managed service) hơn là dịch vụ hạ tầng chung như EC2 mà bạn phải tự dựng mọi thứ lên trên.

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

Đề hỏi: "Which of the following best describes an Availability Zone in the AWS Cloud?" — tức là hỏi định nghĩa của một Availability Zone (AZ) trong hạ tầng toàn cầu của AWS.

Cụm từ quyết định nằm ở chính đối tượng được hỏi: "Availability Zone", chứ không phải Region, không phải subnet, không phải edge location. Cả bốn phương án đều là những khái niệm có thật trong hạ tầng AWS, và chúng nằm cùng một họ nhưng khác cấp. Câu này thực chất kiểm tra xem người học có phân biệt được bốn tầng: Region → Availability Zone → subnet, và một nhánh riêng là edge location.

Thêm một chi tiết đáng chú ý: từ "best describes" báo hiệu đây là câu hỏi định nghĩa thuần tuý, không có tình huống kiến trúc nào để suy luận. Chọn đáp án bằng cách nhớ đúng định nghĩa, đừng cố diễn giải thêm.

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

Đáp án đúng theo tệp là A — "One or more physical data centers".

Một Availability Zone là một hoặc nhiều trung tâm dữ liệu vật lý riêng biệt, mỗi AZ có nguồn điện, hệ thống mạng và kết nối dự phòng riêng, và nằm bên trong một AWS Region. Điểm mấu chốt: AZ không phải lúc nào cũng là đúng một toà nhà — nó có thể gồm nhiều data center, nhưng chúng được nhóm lại thành một đơn vị cách ly về lỗi.

Chính vì vậy AZ là đơn vị mà kiến trúc sư dùng để đạt tính sẵn sàng cao: triển khai ứng dụng và cơ sở dữ liệu trên nhiều AZ cho ra hệ thống chịu lỗi tốt hơn, sẵn sàng hơn và mở rộng dễ hơn so với đặt tất cả trong một data center duy nhất.

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

B — "A subnet for deploying resources into" Đây là phương án gần đúng nhất và dễ gây nhầm nhất, vì trên thực tế bạn có triển khai tài nguyên vào subnet, và subnet có gắn với AZ. Nhưng quan hệ bị đảo ngược: subnet được tạo bên trong một AZ, chứ AZ không phải là subnet. Subnet là khái niệm mạng thuộc về VPC của riêng bạn — một dải địa chỉ IP do bạn định nghĩa. AZ là khái niệm hạ tầng vật lý của AWS, tồn tại độc lập với việc bạn có tạo VPC nào hay không. Một AZ có thể chứa nhiều subnet, thuộc nhiều VPC khác nhau.

C — "A completely isolated geographic location" Đây là mô tả của một AWS Region, không phải AZ. Region là vùng địa lý tách biệt (ví dụ một Region ở Singapore, một Region ở Tokyo), và mỗi Region chứa nhiều AZ bên trong. Phương án này sai vì đặt nhầm cấp: nó lấy định nghĩa của tầng trên gán cho tầng dưới. Các AZ trong cùng một Region không hề "hoàn toàn cách ly về địa lý" với nhau — chúng cách nhau đủ xa để không cùng chịu một sự cố cục bộ, nhưng vẫn nối với nhau bằng đường mạng riêng độ trễ thấp trong cùng một Region.

D — "One or more edge locations based around the world" Edge location thuộc về một nhánh hạ tầng khác hẳn: đó là các điểm hiện diện dùng cho Amazon CloudFront để cache nội dung gần người dùng cuối. Chúng phục vụ mục tiêu giảm độ trễ khi phân phối nội dung, chứ không phải nơi bạn chạy EC2 instance hay đặt cơ sở dữ liệu. Số lượng edge location cũng nhiều hơn hẳn số AZ và phân bố theo nhu cầu phân phối nội dung, không theo cấu trúc Region–AZ.

📌 Điểm cần nhớ

• Nhớ thứ tự lồng nhau: Region chứa nhiều Availability Zone, mỗi AZ chứa một hoặc nhiều data center vật lý, subnet được tạo bên trong AZ. Rất nhiều câu hỏi kiểu này chỉ đơn giản là hoán đổi định nghĩa giữa các tầng.
• Region = vùng địa lý tách biệt; AZ = một hoặc nhiều data center có điện, mạng và kết nối dự phòng riêng. Thấy cụm "isolated geographic location" thì nghĩ Region trước.
• Edge location là nhánh riêng, gắn với CloudFront và việc cache nội dung, không phải nơi triển khai tài nguyên tính toán — đừng trộn nó vào cấu trúc Region/AZ.
• Subnet là khái niệm mạng của bạn bên trong VPC, AZ là hạ tầng vật lý của AWS. Subnet nằm trong AZ, không phải ngược lại — quan hệ này bị đảo ngược rất thường xuyên trong các phương án gây nhiễu.

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

Đề hỏi: triển khai một ứng dụng đang chạy trên nhiều EC2 instances như thế nào để một sự cố mất điện (power failure) không làm ứng dụng ngừng hoạt động.

Cụm từ quyết định đáp án là "a power failure" — chứ không phải "một thảm hoạ diện rộng" hay "thiên tai cấp vùng". Mất điện là sự cố ở mức cơ sở hạ tầng vật lý của một trung tâm dữ liệu. Vì vậy điều cần tìm là ranh giới cách ly nhỏ nhất mà AWS đảm bảo độc lập về nguồn điện. Ranh giới đó chính là Availability Zone (AZ): mỗi AZ có hệ thống điện dự phòng riêng và được cấp từ lưới điện khác nhau.

Cụm thứ hai đáng chú ý là "multiple EC2 instances" — đề đã cho sẵn nhiều instance, nên vấn đề không phải là tạo thêm bao nhiêu máy, mà là đặt chúng ở đâu. Ba phương án sai đều là những cách "phân tán" nghe hợp lý nhưng hoặc không nhắm đúng loại sự cố, hoặc không phải ranh giới hạ tầng vật lý.

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

A — Launch the EC2 instances into different Availability Zones.

Mỗi Availability Zone là một hoặc nhiều trung tâm dữ liệu tách biệt, có nguồn điện dự phòng riêng và được cấp điện từ lưới khác nhau. Do đó một sự cố mất điện ảnh hưởng tới một AZ không lan sang AZ còn lại — chính xác là loại hỏng hóc mà đề bài mô tả.

Ngoài ra, các AZ trong cùng một region được nối với nhau bằng đường mạng độ trễ thấp, nên việc trải instance qua nhiều AZ không làm ứng dụng chậm đi đáng kể. Đây là lý do "multi-AZ" là khuyến nghị mặc định của AWS cho tính sẵn sàng cao: đủ cách ly để chịu được lỗi hạ tầng, mà vẫn đủ gần để các thành phần nói chuyện với nhau bình thường.

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

B — Launch the EC2 instances in separate regions. Đây là phương án gần đúng nhất và cũng là bẫy chính. Đặt ở hai region khác nhau đúng là chống được mất điện — nhưng nó thừa so với yêu cầu: AZ đã có điện dự phòng và lưới điện riêng, nên không cần đi xa tới mức region để giải quyết bài toán này. Cái giá phải trả thì thật: các region cách nhau về địa lý nên độ trễ mạng tăng lên, có thể ảnh hưởng đến ứng dụng; và trong nhiều trường hợp còn vướng vấn đề chủ quyền dữ liệu (data sovereignty) khi dữ liệu bị đặt ở quốc gia khác. Chọn công cụ nặng hơn mức cần thiết là sai trong bối cảnh câu hỏi này.

C — Launch the EC2 instances into different VPCs. Không cần thiết và làm việc triển khai phức tạp hơn. Điểm mấu chốt: VPC là ranh giới logic về mạng, không phải ranh giới vật lý về nguồn điện. Các VPC trong cùng một region vẫn dùng chung hạ tầng bên dưới, nên hai instance nằm ở hai VPC khác nhau hoàn toàn có thể vẫn nằm chung một AZ — và cùng chết khi AZ đó mất điện. Tách VPC giải quyết bài toán cách ly mạng và phân tách môi trường, không giải quyết bài toán độ sẵn sàng của phần cứng.

D — Launch the EC2 instances into Edge Locations. Sai ở mức căn bản hơn: không thể chạy EC2 instance trong Edge Location. Edge Location là hạ tầng phục vụ mạng phân phối nội dung và các dịch vụ biên, không phải nơi để bạn khởi chạy máy ảo. Phương án này mô tả một việc không làm được, nên loại ngay không cần cân nhắc.

📌 Điểm cần nhớ

• Ghép loại sự cố với ranh giới cách ly tương ứng: mất điện / hỏng hạ tầng một trung tâm dữ liệu → nhiều AZ; thảm hoạ ảnh hưởng cả một vùng địa lý hoặc yêu cầu phục vụ người dùng ở châu lục khác → mới tính tới nhiều region.
• AZ là ranh giới vật lý, VPC là ranh giới logic. Tách VPC không đảm bảo tách nguồn điện — hai VPC trong cùng region vẫn có thể rơi vào cùng một AZ.
• Multi-AZ là mặc định cho high availability vì nó cân bằng được hai thứ: cách ly lỗi hạ tầng và độ trễ mạng thấp giữa các AZ.
• Edge Location không chạy EC2. Gặp phương án đề nghị khởi chạy instance ở Edge Location thì loại thẳng.

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

Đề hỏi: dịch vụ lưu trữ lai (hybrid storage) nào của AWS cho phép ứng dụng đang chạy tại chỗ (on-premises) dùng được kho lưu trữ trên AWS Cloud một cách liền mạch?

Cụm từ quyết định đáp án là "hybrid storage service" — ba chữ này phải đúng cả ba:

• hybrid: dịch vụ phải bắc cầu giữa trung tâm dữ liệu tại chỗ và AWS, chứ không phải dịch vụ thuần trong cloud.
• storage: nó phải là dịch vụ lưu trữ, không phải dịch vụ mạng hay dịch vụ nghiệp vụ.
• on-premises applications ... seamlessly use: ứng dụng cũ ở dưới đất phải dùng được kho cloud mà không phải viết lại, tức là dịch vụ phải phơi ra giao thức lưu trữ quen thuộc (file share, iSCSI, băng từ ảo) rồi âm thầm đẩy dữ liệu lên AWS phía sau.

Bốn phương án được dựng để thử xem người học có tách được storage khỏi network, và hybrid khỏi cloud-only hay không.

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

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

AWS Storage Gateway là dịch vụ lưu trữ lai đúng nghĩa: nó cho hệ thống tại chỗ truy cập vào kho lưu trữ trên cloud gần như không giới hạn dung lượng. Điểm mấu chốt khớp với đề là seamlessly: ứng dụng on-premises vẫn nói chuyện với gateway bằng giao thức lưu trữ tiêu chuẩn mà nó vốn đã dùng, còn phần đẩy dữ liệu lên AWS do gateway lo, nên không phải sửa ứng dụng.

Các tình huống dùng điển hình mà tài liệu nêu ra cũng chính là hình dạng của một dịch vụ hybrid storage:

• chuyển sao lưu băng từ (tape backup) lên cloud,
• giảm dung lượng lưu trữ tại chỗ bằng file share có kho nền là cloud,
• cho ứng dụng on-premises truy cập dữ liệu trên AWS với độ trễ thấp (nhờ cache dữ liệu hay dùng ngay tại gateway),
• phục vụ di trú, lưu trữ dài hạn, xử lý dữ liệu và khôi phục sau thảm hoạ.

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

A — Amazon Connect. Đây là dịch vụ tổng đài chăm sóc khách hàng đa kênh (omnichannel contact center) chạy trên cloud, dùng để dựng trung tâm hỗ trợ khách hàng. Nó không liên quan gì tới việc lưu trữ dữ liệu. Phương án này chỉ gây nhiễu vì tên có chữ "Connect", dễ liên tưởng tới việc kết nối tại chỗ với cloud.

B — AWS Direct Connect. Đây là phương án gần đúng nhất và cũng là bẫy chính. Nó đúng phần "hybrid" — Direct Connect thực sự nối trung tâm dữ liệu của bạn với AWS bằng một đường mạng riêng, chuyên dụng, không đi qua Internet công cộng. Nhưng nó hỏng ở phần "storage": Direct Connect là dịch vụ mạng, nó chỉ cung cấp đường truyền. Nó không phơi ra file share, không phơi ra volume iSCSI, không có tape ảo, và không cho ứng dụng on-premises "dùng kho lưu trữ AWS" ở mức giao thức lưu trữ. Đề hỏi hybrid storage service, nên chỉ có đường ống thôi là chưa đủ.

D — AWS Backup. Đây cũng là dịch vụ liên quan tới dữ liệu nên dễ bị chọn. AWS Backup là dịch vụ sao lưu được quản lý hoàn toàn, giúp tập trung và tự động hoá việc sao lưu dữ liệu giữa các dịch vụ AWS với nhau. Nó hỏng ở phần "hybrid" và ở phần "ứng dụng on-premises dùng kho cloud": nó không phải là cầu nối để hệ thống tại chỗ đọc ghi vào kho lưu trữ cloud, mà là công cụ quản trị chính sách sao lưu. Ngoài ra bản chất công việc của nó là sao lưu theo lịch, khác với đề đang mô tả một kho lưu trữ dùng thường xuyên trong lúc ứng dụng chạy.

📌 Điểm cần nhớ

• Thấy đề nêu "hybrid storage" kèm ứng dụng on-premises muốn dùng kho AWS mà không phải sửa code → nghĩ ngay tới AWS Storage Gateway. Đây gần như là câu trả lời mặc định cho mô-típ này ở mức Cloud Practitioner.
• Phân biệt rành mạch Direct Connect (mạng) và Storage Gateway (lưu trữ). Cả hai đều "nối tại chỗ với AWS", nhưng một cái cấp đường truyền, một cái cấp giao diện lưu trữ. Đề hỏi tới lưu trữ thì chọn Storage Gateway; đề hỏi tới đường truyền riêng, không qua Internet công cộng thì mới chọn Direct Connect.
• AWS Backup ≠ hybrid storage. Nó là lớp quản trị chính sách sao lưu, tập trung việc sao lưu cho các dịch vụ AWS, chứ không phải kênh để hệ thống dưới đất đọc ghi vào cloud.
• Cẩn thận với những tên dịch vụ nghe giống chức năng đang hỏi nhưng thuộc lĩnh vực hoàn toàn khác — Amazon Connect là contact center, không dính dáng gì tới lưu trữ. Khi gặp phương án lạ, hãy tự hỏi dịch vụ đó thuộc nhóm nào (storage, network, compute, nghiệp vụ) trước khi cân nhắc.

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

Đề hỏi: dịch vụ AWS nào là fully-managed source control service dùng để host secure Git-based repositories?

Cụm từ quyết định đáp án là "source control" và "Git-based repositories". Đây là câu kiểm tra xem người học có phân biệt được bốn dịch vụ họ "Code*" của AWS hay không — cả bốn phương án đều thuộc bộ AWS Developer Tools, đều là dịch vụ được quản lý hoàn toàn, nên chữ "fully-managed" trong đề không phân biệt được gì. Thứ phân biệt là vai trò trong vòng đời CI/CD: nơi lưu mã nguồn (source control) khác với nơi biên dịch mã, nơi triển khai mã, và nơi điều phối toàn bộ chuỗi.

Nói cách khác, đề đang chỉ đúng vào bước đầu tiên của chuỗi phát triển phần mềm: kho chứa mã. Chữ Git là dấu hiệu rõ nhất — chỉ một dịch vụ trong danh sách nói chuyện được bằng chính các lệnh Git quen thuộc (git clone, git push, git pull).

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

Đáp án đúng theo tệp là C. AWS CodeCommit.

AWS CodeCommit là dịch vụ source control được quản lý hoàn toàn, host các kho Git riêng tư và bảo mật. Nó khớp từng chữ với đề bài:

• Fully-managed: bạn không phải tự dựng và vận hành một máy chủ source control của riêng mình, cũng không phải lo chuyện mở rộng hạ tầng phía dưới khi đội ngũ và mã nguồn lớn dần.
• Git-based: CodeCommit hoạt động liền mạch với các công cụ Git sẵn có của bạn — IDE, dòng lệnh, hay bất kỳ client Git nào — nên đội phát triển không phải đổi thói quen làm việc.
• Secure repositories: kho là riêng tư, và bạn có thể lưu trong đó mọi thứ từ mã nguồn cho tới các tệp binary, trong một môi trường bảo mật và có khả năng mở rộng cao.

Vì vậy CodeCommit chính là mảnh ghép "nơi chứa mã" trong bộ Developer Tools, còn ba dịch vụ kia đứng ở các bước phía sau.

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

A. AWS CodeDeploy — Đây là dịch vụ triển khai (deployment), tự động hoá việc đưa ứng dụng lên Amazon EC2 instances, on-premises instances, Lambda functions hoặc Amazon ECS services. Nó nhận mã/artifact đã sẵn sàng rồi đẩy ra môi trường chạy; nó không lưu trữ mã nguồn và không cung cấp kho Git nào cả. Đây là bước cuối chứ không phải bước đầu.

B. AWS CodePipeline — Đây là phương án gần đúng nhất và dễ gây nhầm, vì CodePipeline có chạm tới kho mã: nó thường lấy source stage từ một kho như CodeCommit. Nhưng CodePipeline là dịch vụ continuous delivery được quản lý hoàn toàn, nhiệm vụ của nó là tự động hoá release pipeline — nối các giai đoạn source → build → test → deploy lại với nhau để cập nhật ứng dụng và hạ tầng nhanh, đáng tin cậy. Nó điều phối chứ không lưu trữ: nó trỏ tới kho Git chứ bản thân nó không host kho Git nào. Đề hỏi "hosts secure Git-based repositories", CodePipeline hỏng đúng ở chữ hosts.

D. AWS CodeBuild — Đây là dịch vụ continuous integration được quản lý hoàn toàn: nó biên dịch mã nguồn, chạy test, và tạo ra các gói phần mềm sẵn sàng để triển khai. CodeBuild có kéo mã về để build, nhưng nó chỉ đọc mã từ một kho bên ngoài rồi trả về artifact; nó không phải nơi mã nguồn cư trú lâu dài, và nó không nói chuyện với bạn qua giao thức Git như một remote repository.

📌 Điểm cần nhớ

• Bốn dịch vụ "Code*" của AWS ánh xạ vào bốn bước khác nhau của một chuỗi CI/CD: CodeCommit = lưu mã (source control, Git), CodeBuild = build và test (continuous integration), CodeDeploy = triển khai ra môi trường chạy, CodePipeline = điều phối cả chuỗi (continuous delivery).
• Từ khoá nhận diện nhanh: thấy "Git", "repository", "source control" → CodeCommit. Thấy "compile", "run tests", "build artifact" → CodeBuild. Thấy "deploy to EC2 / Lambda / ECS" → CodeDeploy. Thấy "automate release pipeline", "orchestrate stages" → CodePipeline.
• Trong câu hỏi kiểu này, "fully-managed" thường là nhiễu chứ không phải manh mối — cả bốn phương án đều fully-managed. Hãy tìm động từ chính của đề (ở đây là hosts ... repositories) rồi khớp với vai trò của dịch vụ.
• Phân biệt host và dùng: một dịch vụ có tương tác với kho mã (CodePipeline lấy source, CodeBuild kéo mã về build) không có nghĩa nó là nơi chứa kho mã.

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

Đề hỏi: một tổ chức làm thế nào để truy cập các báo cáo tuân thủ (compliance reports) một cách natively through the AWS console — tức là lấy ngay trong console của AWS, không phải qua kênh liên hệ bên ngoài hay yêu cầu thủ công.

Cụm từ quyết định đáp án là "compliance reports". Đây là những tài liệu kiểm toán do bên thứ ba cấp cho hạ tầng AWS (kiểu báo cáo SOC, chứng nhận ISO, tài liệu PCI...), tức là bằng chứng về việc bản thân AWS tuân thủ chuẩn, chứ không phải kết quả quét cấu hình trong tài khoản của bạn. Cụm thứ hai, "natively through the AWS console", loại bỏ những cách lấy tài liệu ngoài console.

Đây chính là ràng buộc phân biệt: cả bốn phương án đều thuộc nhóm Security, Identity & Compliance, nhưng chỉ có một dịch vụ đóng vai trò kho tài liệu tuân thủ để tải về; ba dịch vụ còn lại làm việc với tài nguyên trong tài khoản bạn (kiểm tra cấu hình, chứng chỉ TLS, quyền truy cập).

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

B — AWS Artifact.

AWS Artifact là nguồn tài nguyên trung tâm dành cho thông tin liên quan tới compliance. Bạn mở console của AWS Artifact ngay trong AWS Management Console và:

• Tải về các báo cáo kiểm toán, chứng nhận, tài liệu tuân thủ mà AWS có từ các tổ chức đánh giá độc lập.
• Xem, chấp nhận và theo dõi trạng thái các thoả thuận (agreements) với AWS.

Nói cách khác, Artifact là chỗ tổ chức của bạn lấy bằng chứng để đưa cho kiểm toán viên khi họ hỏi "phần hạ tầng chạy trên AWS thì ai bảo đảm?". Nó khớp trọn vẹn cả hai vế của đề: đúng loại tài liệu (compliance reports) và đúng cách truy cập (ngay trong console, tự phục vụ).

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

A — AWS Security Hub. Đây là phương án gần đúng nhất và dễ bẫy nhất, vì Security Hub có màn hình hiển thị mức độ tuân thủ theo các bộ tiêu chuẩn (security standards) và người ta hay gọi nôm na là "compliance dashboard". Nhưng chỗ nó hỏng là: Security Hub là dịch vụ cloud security posture management — nó tự động chạy các kiểm tra theo thông lệ tốt nhất, gom cảnh báo từ nhiều dịch vụ bảo mật và hỗ trợ khắc phục tự động trên chính tài nguyên trong tài khoản bạn. Nó sinh ra phát hiện (findings) về cấu hình của bạn, chứ không phát hành báo cáo kiểm toán của AWS. Đề hỏi lấy compliance reports, không hỏi đánh giá tình trạng bảo mật.

C — AWS Certificate Manager (ACM). ACM cấp phát, lưu trữ và tự động gia hạn chứng chỉ SSL/TLS để gắn vào load balancer, CloudFront và các dịch vụ tích hợp. Từ "certificate" ở đây là chứng chỉ mã hoá cho tên miền, hoàn toàn khác với "certification" theo nghĩa chứng nhận tuân thủ. Đây là bẫy chơi chữ, ACM không liên quan gì tới compliance reports.

D — AWS Identity and Access Management (IAM). IAM lo việc quản trị quyền truy cập cho users, groups và roles trong tài khoản: ai được làm gì trên tài nguyên nào. Đúng là kiểm soát truy cập là một phần của bức tranh tuân thủ, nhưng IAM không lưu trữ và không phát hành bất kỳ báo cáo tuân thủ nào. Nó là công cụ thực thi quyền, không phải nơi tải tài liệu.

📌 Điểm cần nhớ

• Đề nhắc tới compliance reports, audit reports, hoặc agreements với AWS → nghĩ ngay tới AWS Artifact. Đây gần như là phản xạ một-đối-một ở mức Cloud Practitioner.
• Phân biệt rạch ròi hai hướng: Artifact = tài liệu chứng minh AWS tuân thủ chuẩn (bên dưới mô hình trách nhiệm chung), còn Security Hub = đánh giá xem tài nguyên của bạn có cấu hình đúng thông lệ tốt hay không (bên trên mô hình trách nhiệm chung).
• Cẩn thận với chữ "certificate": ACM làm chứng chỉ SSL/TLS cho tên miền, không phải chứng nhận tuân thủ.
• IAM trả lời câu hỏi "ai được làm gì", không trả lời câu hỏi "lấy bằng chứng tuân thủ ở đâu".

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

Đề hỏi: những lợi ích nào một công ty có thể hưởng ngay lập tức khi dùng AWS Cloud (chọn HAI).

Cụm từ quyết định đáp án là "immediately realize" — lợi ích thấy được ngay khi chuyển lên cloud, không cần chờ tối ưu lâu dài. Nhưng thực tế trong câu này, cụm đó không phải thứ khó nhất; ba phương án sai đều sai vì bản thân chúng không phải lợi ích của cloud (thậm chí là phát biểu ngược hoặc sai hoàn toàn), chứ không phải vì "chậm mới có". Vì vậy cách làm nhanh là loại theo tính đúng/sai của mệnh đề, chứ không phải cân đo xem cái nào đến sớm hơn.

Hai cụm cần chú ý thêm trong các phương án: chiều của mệnh đề "capital → variable" hay "variable → capital" (đề cố tình đảo chiều để bẫy), và từ tuyệt đối "No responsibility" (mô hình trách nhiệm chung không cho phép nói "không có trách nhiệm gì").

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

Đáp án theo tệp là A và D.

A — Increased agility. Cloud cho phép cấp phát tài nguyên và triển khai ứng dụng nhanh hơn hẳn so với việc mua sắm, lắp đặt phần cứng. Ứng dụng được deploy, scale và quản lý dễ dàng hơn, nên nhóm kỹ thuật thử nghiệm và ra sản phẩm nhanh hơn. Đây là lợi ích cảm nhận được ngay từ ngày đầu.

D — Capital expenses are replaced with variable expenses. Đây là mệnh đề kinh điển của AWS: thay vì bỏ một khoản đầu tư lớn trả trước (capital expenditure — mua máy chủ, xây trung tâm dữ liệu), doanh nghiệp trả theo mức sử dụng, tức chi phí vận hành biến đổi (variable operational expenditure). Vì trả theo thứ mình dùng nên khoản chi này gắn với nhu cầu thật, có lợi cho dòng tiền của công ty — và nó có tác dụng ngay khi ngừng mua hạ tầng.

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

B — No responsibility for security. Sai. Theo mô hình trách nhiệm chung, AWS chịu trách nhiệm về "security of the cloud" (hạ tầng vật lý, phần cứng, phần mềm nền), còn khách hàng vẫn chịu trách nhiệm về "security in the cloud" — cấu hình quyền truy cập, mã hoá dữ liệu, vá hệ điều hành khách, thiết lập nhóm bảo mật. Trách nhiệm bảo mật được chia lại, chứ không biến mất. Đây là phương án nghe hấp dẫn nhất với người mới, và cũng là chỗ đề hay bẫy nhất.

C — Variable expenses are replaced with capital expenses. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi: nó dùng đúng hai thuật ngữ của đáp án D nhưng đảo ngược chiều. Đọc lướt thấy quen là chọn nhầm ngay. Hỏng ở chỗ nó mô tả đúng mô hình truyền thống on-premises (phải bỏ vốn lớn mua hạ tầng), tức là chiều ngược lại của điều cloud mang lại. Khi gặp cặp phương án đối xứng kiểu này, phải đọc kỹ vế nào đứng trước từ "replaced".

E — User control of physical infrastructure. Sai. Dùng AWS thì khách hàng không có quyền kiểm soát hạ tầng vật lý — trung tâm dữ liệu, máy chủ vật lý, thiết bị mạng đều do AWS vận hành và khách hàng không được vào. Đây thực chất là đặc điểm của mô hình tự vận hành, và trong nhiều tình huống nó bị coi là điều đánh đổi khi lên cloud chứ không phải lợi ích. Người học đôi khi nhầm với việc mình kiểm soát được cấu hình VPC, instance — nhưng đó là kiểm soát tài nguyên logic, không phải phần cứng vật lý.

📌 Điểm cần nhớ

• Capital expense → variable expense, luôn theo chiều này. Đề rất hay đưa cả hai chiều vào cùng một câu để bẫy đọc lướt; nhớ chiều đúng là loại được ngay một phương án.
• Mô hình trách nhiệm chung: AWS lo security of the cloud, khách hàng lo security in the cloud. Bất kỳ phương án nào nói khách hàng "không còn trách nhiệm bảo mật" đều sai.
• Lên cloud đồng nghĩa từ bỏ quyền kiểm soát hạ tầng vật lý. Kiểm soát cấu hình tài nguyên logic không phải là kiểm soát phần cứng.
• Với câu hỏi về lợi ích cloud, các từ khoá an toàn để chọn là agility, elasticity, trả theo mức dùng, không phải đoán trước dung lượng, phạm vi toàn cầu trong vài phút; các từ tuyệt đối như "no responsibility", "unlimited", "never" thường là dấu hiệu của phương án sai.

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

Đề mô tả một công ty cần "a consistent and dedicated connection" giữa tài nguyên trên AWS và hệ thống on-premise, rồi hỏi dịch vụ AWS nào đáp ứng được.

Cụm từ quyết định là "consistent and dedicated" — kết nối riêng và có hiệu năng ổn định. Hai chữ này loại nhau rất rõ:

• dedicated nghĩa là đường truyền vật lý riêng, không dùng chung hạ tầng Internet công cộng.
• consistent nghĩa là độ trễ và băng thông đoán trước được, không phụ thuộc tình trạng Internet lúc đó.

Chỉ cần thiếu một trong hai vế là phương án hỏng. Ngoài ra, đề nói về kết nối mạng (connection giữa hai môi trường), không phải về sao chép dữ liệu hay chăm sóc khách hàng — đây là chỗ hai phương án nhiễu bị lộ.

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

A. AWS Direct Connect là đáp án đúng.

Direct Connect thiết lập một liên kết mạng riêng, chuyên dụng từ trung tâm dữ liệu / văn phòng của khách hàng tới AWS, thông qua một AWS Direct Connect location. Vì lưu lượng không đi qua Internet công cộng, hiệu năng của nó ổn định (consistent) — đúng cả hai yêu cầu mà đề nêu.

Ánh xạ thẳng vào từ khoá đề bài:

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

B. AWS Managed VPN — đây là phương án gần đúng nhất, và đó cũng là chỗ dễ mất điểm. Managed VPN đúng là dịch vụ nối AWS với hệ thống on-premise, nên nếu đề chỉ hỏi "kết nối hai môi trường" thì nó qua được. Nhưng VPN chạy trên Internet công cộng, chỉ mã hoá đường truyền chứ không tạo ra đường riêng. Hệ quả: nó không dedicated, và vì phụ thuộc chất lượng Internet nên hiệu năng cũng không consistent. Đề đòi cả hai tính chất đó nên VPN bị loại — nó hỏng ở đúng cụm từ phân biệt.

C. Amazon Connect — chỉ giống về tên, không liên quan gì tới mạng. Amazon Connect là dịch vụ contact center trên cloud (tổng đài đa kênh, phục vụ chăm sóc khách hàng với chi phí thấp). Đây là bẫy đặt tên kinh điển của kỳ thi: "Connect" trong tên dịch vụ này nói về kết nối với khách hàng, không phải kết nối mạng.

D. AWS DataSync — có dính tới on-premise nên nghe qua cũng có lý, nhưng nó thuộc nhóm di chuyển dữ liệu, không phải nhóm kết nối mạng. DataSync giúp chuyển lượng lớn dữ liệu online giữa kho lưu trữ on-premise và Amazon S3, Amazon EFS hoặc Amazon FSx for Windows File Server. Nó là một công cụ chạy trên đường mạng đã có sẵn, chứ bản thân nó không tạo ra đường kết nối riêng và ổn định giữa hai môi trường.

📌 Điểm cần nhớ

• "Dedicated" + "consistent performance" + on-premise → Direct Connect. Đây là bộ ba từ khoá gần như luôn trỏ về Direct Connect trong đề thi.
• "Encrypted" / "over the internet" / "nhanh, rẻ, dựng ngay" → VPN. VPN và Direct Connect cùng nối AWS với on-premise; phân biệt bằng việc lưu lượng có đi qua Internet công cộng hay không, chứ không phải bằng chuyện có mã hoá hay không.
• Cảnh giác với tên dịch vụ nghe giống chức năng. Amazon Connect là contact center, không phải dịch vụ mạng — hãy đọc theo chức năng thật của dịch vụ chứ đừng đoán theo nghĩa của từ trong tên.
• Tách bạch "kết nối" với "chuyển dữ liệu". DataSync di chuyển dữ liệu giữa on-premise và các dịch vụ lưu trữ của AWS; Direct Connect tạo ra chính đường truyền. Đề hỏi connection thì chọn nhóm mạng, đề hỏi move/copy data mới chọn nhóm chuyển dữ liệu.

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

Đề hỏi: "Which of the following are valid best practices for using the AWS Identity and Access Management (IAM) service? (Select TWO.)" — đâu là hai best practice hợp lệ khi dùng IAM.

Cụm từ quyết định là "valid best practices" kết hợp với "(Select TWO)". Đây không phải câu hỏi tình huống kiến trúc, mà là câu kiểm tra xem bạn có thuộc danh sách khuyến nghị IAM của AWS hay không. Vì vậy cách làm đúng là đối chiếu từng phương án với danh sách best practice chính thức: phương án nào trùng ý thì đúng, phương án nào phát biểu ngược lại một khuyến nghị thì sai.

Điểm bẫy nằm ở chỗ ba phương án sai không phải là chuyện xa lạ — chúng đều lấy đúng chủ đề trong danh sách best practice (access key, inline policy, mức quyền) nhưng đảo chiều lời khuyên. Ai đọc lướt sẽ thấy quen mắt và chọn nhầm.

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

Theo tệp, đáp án đúng là A và D.

• D — "Create individual IAM users": AWS khuyến nghị mỗi người dùng có một IAM user riêng thay vì dùng chung một bộ credential, và đặc biệt là thay vì dùng root user cho công việc hằng ngày. Có danh tính riêng thì mới gán quyền riêng được, mới thu hồi quyền của một người mà không ảnh hưởng người khác, và mới truy ra ai đã làm gì khi soi lại nhật ký hoạt động của tài khoản.
• A — "Use groups to assign permissions to IAM users": thay vì gắn policy trực tiếp lên từng user, ta gom user vào group theo vai trò công việc rồi gắn policy lên group. Khi nhu cầu quyền thay đổi, sửa một chỗ là cả nhóm đổi theo; khi có người mới, chỉ cần thêm họ vào đúng group. Cách này giảm hẳn tình trạng quyền lệch nhau giữa những người cùng vai trò.

Hai phương án này khớp trực tiếp với hai mục trong danh sách best practice mà phần giải thích gốc liệt kê.

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

• B — "Embed access keys in application code": đây là điều best practice khuyên tránh, không phải khuyên làm. Nhúng access key vào mã nguồn nghĩa là bí mật đó đi theo mọi bản sao của mã — kho mã, bản build, log, máy của lập trình viên — và việc xoay vòng khoá trở thành sửa mã rồi triển khai lại. Khuyến nghị đúng cho ứng dụng chạy trên EC2 là dùng IAM role để ứng dụng nhận credential tạm thời, không phải khoá tĩnh nằm trong code.
• C — "Use inline policies instead of customer managed policies": đây là phương án gần đúng nhất vì nó nêu đúng hai khái niệm có thật và có nhắc tới trong danh sách, chỉ có điều nói ngược chiều. Khuyến nghị của AWS là use customer managed policies instead of inline policies. Customer managed policy là một đối tượng độc lập, gắn được cho nhiều identity, xem lại và sửa ở một chỗ; inline policy dính chặt vào đúng một user/group/role, nhân bản ra nhiều bản sao khó theo dõi và biến mất cùng identity khi identity bị xoá. Đảo hai vế lại là hỏng toàn bộ ý nghĩa.
• E — "Grant maximum privileges to IAM users": cũng là bản đảo chiều của một best practice — nguyên tắc đúng là least privilege, cấp đúng mức quyền tối thiểu để người dùng làm được việc của họ, rồi mở thêm khi thực sự cần. Cấp quyền tối đa cho tiện chính là thứ khiến một tài khoản bị lộ kéo theo thiệt hại vượt xa phạm vi công việc của người đó.

📌 Điểm cần nhớ

• Với dạng câu "which are valid best practices", hãy đọc từng phương án và tự hỏi: nó nêu đúng khuyến nghị, hay nêu bản đảo ngược của khuyến nghị? Phương án sai trong dạng này thường là best practice bị lật ngược chứ không phải chủ đề lạ.
• Trục IAM cần thuộc: danh tính riêng cho từng người (individual IAM users) → gán quyền qua group → least privilege.
• Customer managed policy được ưu tiên hơn inline policy vì dùng lại được, quản lý tập trung và dễ rà soát. Nhớ đúng chiều của cặp này.
• Ứng dụng cần quyền thì dùng IAM role, không nhúng access key vào mã. Nguyên tắc chung: credential dài hạn nằm trong code là điều cần loại bỏ, không phải điều cần tối ưu.