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

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

Đề mô tả một tổ chức đang chuyển ứng dụng chạy SQL Server tại chỗ (on-premises) lên AWS, và hỏi dịch vụ cơ sở dữ liệu nào đáp ứng hiệu quả nhất các yêu cầu.

Có hai cụm từ quyết định đáp án, và phải thoả cả hai cùng lúc:

• "reduce operational overhead" — muốn giảm gánh nặng vận hành. Cụm này loại bỏ mọi phương án bắt người dùng tự cài đặt, tự vá lỗi, tự sao lưu hệ quản trị CSDL.
• "lacks the resources to refactor the application" — không có nguồn lực để viết lại ứng dụng. Cụm này khoá chặt loại CSDL đích: ứng dụng vẫn nói chuyện bằng T-SQL với SQL Server, nên bên nhận phải vẫn là SQL Server. Đây là kiểu chuyển đổi cùng loại (homogeneous migration) — không đổi engine, không đổi schema, không đổi câu truy vấn.

Chỉ một trong hai ràng buộc thì đề còn nhập nhằng; ghép lại thì đáp án chỉ còn đúng một.

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

A — Amazon RDS for SQL Server.

RDS là dịch vụ CSDL quan hệ được quản lý (managed), và nó chạy chính engine Microsoft SQL Server. Điều đó khớp cả hai ràng buộc:

• Về mặt ứng dụng: engine không đổi, nên chuỗi kết nối, schema, stored procedure và câu truy vấn T-SQL giữ nguyên. Ứng dụng gần như chỉ cần trỏ sang endpoint mới — không phải refactor.
• Về mặt vận hành: AWS lo phần cài đặt engine, vá bản cập nhật, sao lưu tự động, khôi phục theo thời điểm, giám sát và các tuỳ chọn dự phòng/khả dụng cao. Đội vận hành không còn phải chăm hệ điều hành lẫn phần mềm CSDL bên dưới.

Đây đúng là kịch bản mà bản giải thích gốc gọi là homogeneous migration: chuyển thẳng, không chuyển đổi.

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

B — Microsoft SQL Server on Amazon EC2. Đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi. Nó thoả ràng buộc thứ hai rất tốt: vẫn là SQL Server thật, không cần refactor gì cả, thậm chí còn linh hoạt hơn RDS (toàn quyền trên hệ điều hành, cài được mọi tính năng, mọi phiên bản). Chỗ nó hỏng là ràng buộc thứ nhất: EC2 là mô hình tự quản lý. Bạn vẫn phải tự vá hệ điều hành, tự cài và nâng cấp SQL Server, tự dựng lịch sao lưu, tự lo cấu hình khả dụng cao. So với RDS thì đó là nhiều việc vận hành hơn, đúng thứ đề bài nói muốn giảm. Khi đề nhấn "reduce operational overhead" mà cả hai lựa chọn cùng chạy được, luôn chọn bản được quản lý.

C — Amazon Redshift. Redshift là kho dữ liệu (data warehouse) dùng cho phân tích và truy vấn tổng hợp trên khối lượng lớn, không phải CSDL giao dịch để ứng dụng nghiệp vụ chạy trực tiếp lên. Nó không phải engine SQL Server, nên đây không còn là chuyển đổi cùng loại — đưa một ứng dụng OLTP sang Redshift là đổi cả kiểu tải công việc lẫn phương ngữ SQL, tức là refactor nặng, ngược hẳn yêu cầu của đề.

D — Amazon DynamoDB. DynamoDB là CSDL NoSQL dạng khoá–giá trị/tài liệu. Nó không có bảng quan hệ, không join, không T-SQL. Chuyển từ SQL Server sang DynamoDB bắt buộc phải thiết kế lại mô hình dữ liệu theo mẫu truy cập và viết lại toàn bộ tầng truy cập dữ liệu của ứng dụng — chính là "refactor" mà đề nói tổ chức này không đủ nguồn lực để làm. DynamoDB đúng là dịch vụ được quản lý, nên nó vượt qua ràng buộc thứ nhất, nhưng lại trượt ràng buộc thứ hai.

📌 Điểm cần nhớ

• Trong đề thi AWS, "reduce operational overhead" là tín hiệu chọn dịch vụ được quản lý (RDS) thay vì tự dựng trên EC2, khi cả hai đều chạy được.
• "without refactoring / cannot change the application" là tín hiệu giữ nguyên engine: SQL Server → RDS for SQL Server. Đổi sang engine khác loại (Redshift, DynamoDB) luôn kéo theo viết lại ứng dụng.
• Phân biệt ba nhóm CSDL trong các phương án: RDS/SQL Server on EC2 là quan hệ – giao dịch; Redshift là kho dữ liệu – phân tích; DynamoDB là NoSQL – truy cập theo khoá. Đề nêu ứng dụng nghiệp vụ đang chạy thì đích phải nằm ở nhóm đầu.
• Khi hai phương án cùng thoả một ràng buộc, hãy tìm ràng buộc thứ hai trong đề để tách chúng ra — ở đây EC2 và RDS chỉ khác nhau ở mức độ phải tự vận hành.

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

Đề hỏi: AWS acceptable use policy (chính sách sử dụng chấp nhận được) về penetration testing cho phép điều gì?

Cụm từ quyết định nằm ở hai chỗ trong bốn phương án, và phải đọc cả hai mới chọn đúng:

1. Ai được test — khách hàng test hạ tầng của chính mình, hay một bên thứ ba test hạ tầng của người khác, hay AWS test hạ tầng của khách hàng.
2. Có cần xin phép trước hay không — without prior approval so với after obtaining authorization from AWS.

Đây là kiểu câu đặt hai phương án gần như trùng nhau (A và D chỉ khác nhau vế xin phép) để kiểm tra xem người học có nắm được rằng AWS đã bỏ yêu cầu xin phép trước đối với một danh sách dịch vụ được liệt kê sẵn hay không. Chữ selected services trong phương án A cũng là chi tiết cố ý: quyền tự test không phải là quyền vô hạn với mọi dịch vụ, nó gắn với một danh sách cụ thể.

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

Đáp án đúng theo tệp là A — "Customers to carry out security assessments or penetration tests against their AWS infrastructure without prior approval for selected services".

Chính sách của AWS cho phép khách hàng tự thực hiện đánh giá an ninh hoặc kiểm thử xâm nhập nhắm vào hạ tầng do chính họ vận hành trên AWS, và không cần gửi yêu cầu phê duyệt trước đối với một nhóm dịch vụ được AWS liệt kê rõ. Nhóm này bao gồm những dịch vụ mà khách hàng kiểm soát phần lớn cấu hình và ứng dụng chạy bên trên, ví dụ EC2 instances cùng NAT Gateway và Elastic Load Balancer, RDS, Aurora, CloudFront, API Gateway, Lambda và Lambda@Edge, Lightsail, Elastic Beanstalk.

Phương án A khớp đúng cả hai vế của chính sách: đối tượng là khách hàng, trên hạ tầng của khách hàng, và điều kiện là không cần phê duyệt trước, giới hạn trong các dịch vụ được chọn. Cụm for selected services chính là điểm khiến câu này không bị hiểu thành "muốn test gì cũng được" — các hoạt động nằm ngoài danh sách, hoặc các kỹ thuật bị cấm, vẫn phải liên hệ AWS.

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

B — "Authorized security assessors to perform penetration tests against any AWS customer without authorization": sai ở chỗ căn bản nhất. Không có cơ chế nào của AWS cho phép một bên đánh giá an ninh tấn công hạ tầng của khách hàng khác mà không có sự cho phép của chính khách hàng đó. Việc nới lỏng phê duyệt chỉ áp dụng cho tài nguyên của chính mình; test hệ thống của người khác mà không được uỷ quyền là hành vi bị cấm, bất kể người thực hiện có chứng chỉ hay danh nghĩa gì.

C — "AWS to perform penetration testing against customer resources without notification": sai vì đảo ngược vai trò. AWS chịu trách nhiệm bảo mật của đám mây — hạ tầng vật lý, phần ảo hoá, dịch vụ nền — chứ không đi kiểm thử xâm nhập vào tài nguyên và ứng dụng mà khách hàng triển khai. Theo mô hình trách nhiệm chia sẻ, phần "trong" đám mây thuộc về khách hàng, nên chính khách hàng mới là người tổ chức kiểm thử phần đó. Ngoài ra, một nhà cung cấp tự tấn công tài nguyên khách hàng mà không báo trước là điều chính sách không hề nêu.

D — "Customers to carry out security assessments or penetration tests against their AWS infrastructure after obtaining authorization from AWS": đây là phương án gần đúng nhất và là cái bẫy chính của câu. Vế "khách hàng test hạ tầng của mình" hoàn toàn đúng; chỗ hỏng nằm ở after obtaining authorization from AWS. Với danh sách dịch vụ được phép, khách hàng không phải xin phê duyệt trước — đó chính là điểm mà câu hỏi muốn kiểm tra. D mô tả cách làm cũ, khi mọi lần kiểm thử đều phải gửi biểu mẫu yêu cầu và chờ AWS chấp thuận. Chọn D nghĩa là hiểu đúng "ai được test" nhưng sai "có cần xin phép không" — và đề chỉ khác nhau đúng ở vế đó.

📌 Điểm cần nhớ

• Quyền tự kiểm thử chỉ áp dụng cho hạ tầng của chính bạn trên AWS. Bất kỳ phương án nào nói tới việc test tài nguyên của khách hàng khác đều sai ngay từ đầu, không cần xét thêm điều kiện.
• Với danh sách dịch vụ được AWS liệt kê, khách hàng kiểm thử mà không cần phê duyệt trước. Gặp cặp phương án chỉ khác nhau ở "with/without prior approval", hãy nhớ chính sách hiện tại nghiêng về "không cần xin phép cho các dịch vụ được chọn".
• Chú ý cụm giới hạn như "for selected services": nó không làm phương án yếu đi mà ngược lại, phản ánh đúng chính sách — quyền tự test có phạm vi, không phải giấy phép mở với mọi dịch vụ và mọi kỹ thuật.
• Áp mô hình trách nhiệm chia sẻ để loại nhanh: AWS lo bảo mật của đám mây, khách hàng lo bảo mật trong đám mây. Phương án nào bắt AWS đi pentest tài nguyên khách hàng là đặt sai vai.

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

Đề hỏi: shared responsibility model của AWS được xếp vào trụ cột (pillar) nào của AWS Well-Architected Framework?

Cụm từ quyết định đáp án là "shared responsibility model". Đây là mô hình chia trách nhiệm giữa AWS và khách hàng — AWS lo phần "security of the cloud" (hạ tầng vật lý, lớp ảo hoá, host operating system), còn khách hàng lo phần "security in the cloud" (dữ liệu, cấu hình, quyền truy cập, hệ điều hành khách). Từ khoá cốt lõi ở đây là responsibility for security — nó không nói gì về tốc độ, chi phí hay quy trình vận hành, mà nói về ai bảo vệ cái gì.

Đây là kiểu câu "ánh xạ khái niệm vào đúng trụ cột". Cách làm nhanh: đọc xem khái niệm đang bàn về chủ đề gì, rồi tìm trụ cột có đúng tên chủ đề đó. Với shared responsibility model, chủ đề là bảo mật và tuân thủ, nên trụ cột tương ứng là Security.

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

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

Security và compliance là trách nhiệm dùng chung giữa AWS và khách hàng. Tuỳ dịch vụ triển khai, mô hình này giúp giảm gánh nặng vận hành cho khách hàng: AWS vận hành, quản lý và kiểm soát các thành phần từ host operating system và lớp virtualization trở xuống, cho tới an ninh vật lý của các cơ sở nơi dịch vụ chạy. Phần còn lại — dữ liệu, cấu hình dịch vụ, IAM, mã hoá, guest OS — thuộc về khách hàng.

Vì mô hình này định nghĩa ranh giới trách nhiệm bảo vệ hệ thống và dữ liệu, nó được trình bày trong trụ cột Security của Well-Architected Framework. Trụ cột Security bàn đúng những thứ đó: bảo vệ dữ liệu, hệ thống và tài sản, quản lý danh tính và quyền truy cập, phát hiện và phản ứng sự cố.

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

A — Reliability. Reliability là khả năng workload thực hiện đúng chức năng dự kiến một cách nhất quán khi được yêu cầu — tức là chịu lỗi, phục hồi sau sự cố, co giãn theo nhu cầu. Đây là phương án dễ nhầm nhất với người mới, vì AWS cũng "chịu trách nhiệm" về hạ tầng chạy ổn định. Nhưng shared responsibility model không nói về việc hệ thống có sống sót qua sự cố hay không, nó nói về ai bảo vệ lớp nào. Trách nhiệm ≠ độ tin cậy.

B — Operational excellence. Trụ cột này nói về khả năng hỗ trợ phát triển và vận hành workload hiệu quả, thu được hiểu biết về hoạt động của hệ thống, và liên tục cải tiến quy trình để tạo giá trị kinh doanh. Nghe cũng gần, vì shared responsibility model quả thật "giảm gánh nặng vận hành" cho khách hàng — nhưng đó là hệ quả phụ của mô hình, không phải nội dung của nó. Operational excellence bàn về quy trình, monitoring, automation, chứ không phải phân chia ranh giới bảo mật.

C — Performance efficiency. Trụ cột này tập trung vào việc dùng tài nguyên tính toán một cách hiệu quả để đáp ứng yêu cầu, và duy trì hiệu quả đó khi nhu cầu thay đổi hoặc công nghệ tiến hoá — chọn đúng loại instance, dùng dịch vụ managed, mở rộng hợp lý. Không có liên hệ nào với việc phân chia trách nhiệm bảo mật. Đây là phương án xa đề nhất trong bốn phương án.

📌 Điểm cần nhớ

• Shared responsibility model luôn thuộc trụ cột Security. Bất cứ câu nào hỏi mô hình này nằm ở đâu trong Well-Architected Framework, đáp án là Security.
• Nhớ ranh giới: AWS lo "security of the cloud" — từ host OS và lớp virtualization trở xuống, kể cả an ninh vật lý của data center. Khách hàng lo "security in the cloud" — dữ liệu, guest OS, cấu hình, IAM, mã hoá.
• Với câu hỏi ánh xạ khái niệm vào pillar, bám vào chủ đề chính của khái niệm chứ đừng bám vào hệ quả phụ. "Giảm gánh nặng vận hành" là hệ quả, không đủ để kéo câu trả lời sang Operational excellence.
• Phân biệt nhanh bốn trụ cột xuất hiện trong câu này: Security = bảo vệ dữ liệu và hệ thống, Reliability = chạy đúng và nhất quán, Operational excellence = vận hành và cải tiến quy trình, Performance efficiency = dùng tài nguyên tính toán hiệu quả.

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

Đề hỏi: hành động nào thuộc trách nhiệm của AWS theo AWS shared responsibility model, chọn HAI phương án.

Cụm từ quyết định là "responsibility of AWS" — tức là phần security OF the cloud, chứ không phải security IN the cloud của khách hàng. Ranh giới nằm ở chỗ: AWS lo phần khách hàng không nhìn thấy và không chạm được (phần cứng, mạng vật lý, tầng ảo hoá, phần mềm nền của các managed service); khách hàng lo phần mình cấu hình và điều khiển được qua console/API.

Vì cả năm phương án đều là việc "bảo mật", không thể loại bằng chủ đề. Ràng buộc thật sự để tách chúng là câu hỏi: khách hàng có quyền truy cập vào thứ đó không? Chỗ dễ vấp nhất là hai phương án gần như trùng chữ — patching OS trên RDS và patching OS trên EC2 — khác nhau đúng ở tên dịch vụ, và chính tên dịch vụ mới là mấu chốt.

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

A — Securing the virtualization layer. Tầng ảo hoá là phần hạ tầng vật lý mà AWS vận hành: hypervisor, phần cứng chủ, cách các instance được cô lập với nhau. Khách hàng không có bất kỳ cách nào nhìn vào hay can thiệp vào tầng này, nên nó nằm trọn trong phần AWS chịu trách nhiệm — cùng nhóm với an ninh vật lý của data center và mạng nền.

B — Patching the operating system on Amazon RDS instances. RDS là managed service: AWS quản lý luôn hệ điều hành và phần mềm nền của database engine. Người dùng RDS không có quyền đăng nhập vào máy chủ bên dưới, không SSH được vào đó, nên cũng không thể vá OS kể cả khi muốn. Việc vá OS ở RDS vì thế thuộc về AWS — đây là điểm đánh đổi cốt lõi của mô hình managed: mất quyền truy cập nhưng cũng mất luôn nghĩa vụ bảo trì tầng đó.

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

C — Configuring security groups and network ACLs. Đây là cấu hình của khách hàng. AWS cung cấp cơ chế security group và network ACL, nhưng mở cổng nào, cho dải IP nào vào, chặn gì ở tầng subnet — hoàn toàn do khách hàng quyết định trong VPC của mình. Một security group mở toang cổng ra Internet là lỗi cấu hình của khách hàng, không phải lỗi của AWS. Phương án này "gần đúng" ở chỗ nó nghe như tính năng bảo mật do AWS xây, nhưng cần phân biệt: AWS chịu trách nhiệm cho công cụ hoạt động đúng, khách hàng chịu trách nhiệm cho cách dùng công cụ đó.

D — Patching the operating system on Amazon EC2 instances. Đây là bẫy chính, gài để đối lập với B. EC2 là Infrastructure as a Service: khách hàng có quyền truy cập trực tiếp vào máy ảo, chọn AMI, cài phần mềm, đăng nhập vào OS. Có quyền thì có nghĩa vụ — vá OS trên EC2 là việc của khách hàng. Cùng một hành động "patch OS" nhưng đổi tên dịch vụ là đổi luôn bên chịu trách nhiệm.

E — Enforcing a strict password policy for IAM users. IAM users là tài khoản do khách hàng tạo trong AWS account của mình. AWS cung cấp khả năng đặt password policy, nhưng bật nó lên, đặt yêu cầu độ dài và độ phức tạp ra sao là quyết định của khách hàng. Đây là quản trị danh tính và truy cập — nằm rõ ràng ở phía "security in the cloud".

📌 Điểm cần nhớ

• Quy tắc phân biệt nhanh: khách hàng chạm được thứ gì thì chịu trách nhiệm cho thứ đó. Không đăng nhập vào được (hypervisor, OS của RDS) → AWS lo; đăng nhập vào được hoặc cấu hình được qua console (EC2 OS, security group, network ACL, IAM) → khách hàng lo.
• Cùng một hành động, tên dịch vụ quyết định câu trả lời. "Patch OS" trên EC2 (IaaS) là của khách hàng, trên RDS (managed) là của AWS. Gặp cặp phương án chỉ khác tên dịch vụ, hãy hỏi ngay: dịch vụ này là IaaS hay managed?
• Mọi thứ dạng cấu hình — security group, network ACL, IAM policy, password policy, mã hoá dữ liệu — mặc định thuộc về khách hàng. AWS chỉ đảm bảo cơ chế đó chạy đúng, không đảm bảo bạn cấu hình đúng.
• Dịch vụ càng managed thì phần trách nhiệm của khách hàng càng thu hẹp lại, chỉ còn dữ liệu và quyền truy cập; dịch vụ càng gần hạ tầng thô thì khách hàng càng phải gánh nhiều tầng.

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

Đề nêu một tình huống rất cụ thể: nhân viên làm việc từ xa cần truy cập managed Windows virtual desktops and applications thông qua secure networks, và yêu cầu chọn HAI dịch vụ AWS.

Cụm từ quyết định nằm ở hai vế tách bạch của câu hỏi:

• "managed Windows virtual desktops" — cần một dịch vụ desktop virtualization do AWS quản lý, cấp cho mỗi nhân viên một máy tính để bàn Windows chạy trên cloud.
• "over secure networks" — cần một cơ chế mạng có mã hoá đường truyền giữa mạng của công ty và AWS.

Đây là kiểu câu "hai yêu cầu, hai đáp án": mỗi phương án đúng phục vụ một vế. Sai lầm phổ biến là chọn hai dịch vụ cùng giải quyết vế desktop (Workspaces và AppStream 2.0) rồi bỏ trống vế mạng. Đọc kỹ chữ "secure networks" là chỗ tách được bẫy đó.

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

D — Amazon WorkSpaces là dịch vụ desktop virtualization được AWS quản lý hoàn toàn, cung cấp desktop Windows (và Linux) mà người dùng truy cập được từ nhiều loại thiết bị được hỗ trợ. Nó khớp trực tiếp với cụm "managed Windows virtual desktops": AWS lo phần hạ tầng, công ty chỉ cấp phát desktop cho từng nhân viên.

C — AWS Site-to-Site VPN lo vế còn lại. Site-to-Site VPN thiết lập đường hầm mã hoá giữa mạng của công ty và mạng trên AWS, nên lưu lượng đi qua Internet công cộng vẫn được bảo vệ. Đó chính là "secure networks" mà đề yêu cầu.

Hai dịch vụ này ghép lại tạo thành bộ đôi hoàn chỉnh: WorkSpaces cấp desktop, Site-to-Site VPN bảo vệ đường truyền tới desktop đó.

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

A — Amazon Elastic Container Service (Amazon ECS) là dịch vụ quản lý container: chạy và điều phối container trên AWS. Nó không phát hành desktop Windows cho người dùng cuối, cũng không phải thành phần mạng bảo mật. Hoàn toàn lệch chủ đề của cả hai vế trong đề.

B — Amazon AppStream 2.0 là phương án gần đúng nhất, và cũng là bẫy chính. AppStream 2.0 thật sự có streaming ứng dụng và desktop từ xa, nên thoạt nhìn khớp với "applications". Chỗ nó hỏng: AppStream 2.0 hướng tới mô hình non-persistent — phiên làm việc được tạo mới rồi huỷ đi, không phải một desktop cá nhân bền vững thuộc về từng nhân viên. Với yêu cầu "managed Windows virtual desktops" cho nhân viên làm việc từ xa hằng ngày, đặc tính không lưu trạng thái đó làm nó không phù hợp bằng WorkSpaces. Ngoài ra, kể cả nếu chọn B thì câu hỏi vẫn thiếu vế "secure networks" — mà chỉ Site-to-Site VPN đáp ứng được.

E — Amazon Connect là dịch vụ contact center trên cloud, dùng để dựng tổng đài chăm sóc khách hàng với thoại và định tuyến cuộc gọi. Nó phục vụ nhân viên tổng đài nói chuyện với khách hàng, không phát hành desktop và không mã hoá kết nối mạng giữa hai site. Dễ bị chọn nhầm chỉ vì có chữ "Connect" nghe như kết nối mạng, nhưng đó là kết nối trong nghĩa tổng đài viên – khách hàng.

📌 Điểm cần nhớ

• Câu "(Select TWO)" thường tương ứng với hai yêu cầu tách bạch trong đề. Hãy tách đề thành các mệnh đề rồi gán mỗi đáp án cho một mệnh đề, thay vì chọn hai dịch vụ cùng loại.
• Amazon WorkSpaces = desktop ảo Windows/Linux bền vững, cá nhân hoá cho từng người dùng. Amazon AppStream 2.0 = streaming ứng dụng/desktop theo phiên, non-persistent. Chữ "persistent desktop cho nhân viên" nghiêng về WorkSpaces; "chỉ cần chạy một ứng dụng, không giữ trạng thái" nghiêng về AppStream 2.0.
• AWS Site-to-Site VPN là câu trả lời chuẩn khi đề nhắc tới đường truyền mã hoá giữa mạng on-premises và AWS qua Internet.
• Đừng để tên dịch vụ đánh lừa: Amazon Connect là contact center, không liên quan tới kết nối mạng; Amazon ECS là container, không liên quan tới desktop người dùng cuối.

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

Đề mô tả một công ty đang tính chuyển từ on-premises lên AWS Cloud, và đội IT muốn "offload this heavy lifting as much as possible" — trút bớt phần việc nặng nhọc càng nhiều càng tốt.

Cụm từ quyết định chính là "offload this heavy lifting" (kèm "as much as possible"). Đây là thuật ngữ quen thuộc trong tài liệu AWS: "undifferentiated heavy lifting" chỉ những công việc vận hành không tạo ra khác biệt cạnh tranh — mua sắm phần cứng, cài đặt, vá lỗi, giám sát, backup, xử lý sự cố hạ tầng. Câu hỏi không hỏi "chạy workload bằng công nghệ gì", mà hỏi ai gánh phần vận hành.

Một cụm phụ nhưng cũng quan trọng: đề nói về "the company infrastructure" nói chung, không giới hạn ở một loại workload cụ thể (container, web app, database…). Phương án nào chỉ phục vụ được một nhóm workload hẹp thì đã lệch phạm vi câu hỏi.

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

D — Use AWS Managed Services to provision, run, and support the company infrastructure.

AWS Managed Services (AMS) là dịch vụ trong đó AWS đảm nhận việc vận hành hạ tầng thay cho khách hàng: cấp phát tài nguyên, chạy, giám sát, vá lỗi, backup, xử lý sự cố và áp dụng các thực hành vận hành tốt nhất bằng automation. Đúng nghĩa "offload heavy lifting": phần việc vận hành chuyển sang phía AWS thay vì đội IT tự làm.

Ba động từ trong phương án — provision, run, support — phủ trọn vòng đời vận hành hạ tầng, khớp chính xác với "as much as possible" trong đề. Đây cũng là phương án duy nhất nói về mô hình vận hành, ba phương án còn lại nói về kỹ thuật triển khai hoặc thói quen on-premises.

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

A — Overprovision compute capacity for seasonal events and traffic spikes. Cấp dư công suất để phòng cao điểm chính là cách làm của thời on-premises, đi ngược nguyên tắc scalability và elasticity của cloud. Trên cloud, đúng bài là co giãn tài nguyên theo nhu cầu thực tế chứ không mua sẵn phần đỉnh rồi để nó nằm không phần lớn thời gian. Ngoài ra, overprovision không hề giảm khối lượng công việc vận hành — đội IT vẫn phải quản lý số máy đó, thậm chí còn nhiều hơn.

B — Build hardware refreshes into the operational calendar. Đây là phương án lạc đề rõ nhất: lên lịch thay mới phần cứng là công việc của trung tâm dữ liệu tự vận hành. Cả điểm hấp dẫn của việc lên cloud là không còn phải quản lý vòng đời phần cứng nữa. Chọn phương án này là giữ nguyên gánh nặng thay vì trút bỏ nó, và như giải thích gốc nêu, nó cũng không phải cách chắc chắn để đảm bảo availability.

C — Use Amazon ECS on Amazon EC2 instances. Đây là phương án gần đúng nhất và là cái bẫy chính. ECS đúng là một managed container service, nghe rất hợp với ý "managed". Nhưng nó hỏng ở hai chỗ:

• Phạm vi quá hẹp: ECS chỉ phục vụ workload đã được đóng gói thành container. Đề nói về việc migrate cả hạ tầng công ty từ on-premises, không có dấu hiệu nào cho thấy toàn bộ workload đã container hoá.
• Vẫn còn heavy lifting: chạy ECS on EC2 instances nghĩa là khách hàng vẫn sở hữu và phải quản lý cụm EC2 làm container host — vá hệ điều hành, chỉnh kích cỡ cụm, giám sát instance. Chính chữ "on EC2 instances" trong phương án là chi tiết loại nó ra, vì nó giữ lại đúng phần việc mà đề muốn trút đi.

📌 Điểm cần nhớ

• Thấy cụm "heavy lifting" / "undifferentiated heavy lifting" trong đề, hãy ưu tiên phương án nào chuyển việc vận hành sang phía AWS, chứ không phải phương án nào nghe "hiện đại" hơn về mặt kỹ thuật.
• Overprovisioning hầu như luôn là phương án sai trong đề AWS: nó mâu thuẫn với scalability và elasticity — hai lợi ích cốt lõi của cloud.
• Bất cứ phương án nào nhắc tới quản lý phần cứng vật lý, refresh cycle, hay data center đều thuộc về mô hình on-premises và thường bị loại ngay khi đề nói về lợi ích của cloud.
• Chú ý phần đuôi của phương án: "on EC2 instances" báo hiệu khách hàng vẫn phải quản lý máy chủ. Cùng một dịch vụ nhưng khác lớp hạ tầng bên dưới sẽ cho mức độ "managed" khác nhau.
• Đối chiếu phạm vi của phương án với phạm vi của đề: đề nói "the company infrastructure" (tổng thể) thì một giải pháp chỉ chạy được cho container là chưa đủ rộng.

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

Đề nêu một công ty IT cần "a private, encrypted channel of communication between its on-premises data center and a VPC in the AWS Cloud" — một kênh liên lạc riêng tư và được mã hoá giữa data center tại chỗ và một VPC trên AWS.

Cụm từ quyết định ở đây là "private" đặt cạnh "on-premises data center ↔ VPC". Hai vế này phải đọc cùng nhau:

• Vế "on-premises ↔ VPC" loại ngay những lựa chọn chỉ làm việc bên trong AWS, không với mạng tại chỗ.
• Vế "private" — theo cách chấm của đề — đòi lưu lượng không đi qua public internet, chứ không chỉ đòi "được mã hoá". Đây chính là ràng buộc tách hai phương án gần nhau nhất trong danh sách. Nếu đề chỉ viết "encrypted" thôi thì bài toán đã khác hẳn.

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

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

Cách đề lập luận: AWS PrivateLink cung cấp kết nối riêng tư giữa các VPC, các dịch vụ AWS và mạng on-premises của bạn, mà không để lưu lượng lộ ra public internet. Điểm bán hàng của PrivateLink là lưu lượng đi trên hạ tầng mạng của AWS, tới một endpoint riêng thay vì tới một địa chỉ công cộng — nghĩa là thoả được chữ "private" mà đề nhấn mạnh.

Trong bốn lựa chọn có mặt, đề coi PrivateLink là phương án duy nhất vừa chạm tới được mạng on-premises, vừa giữ lưu lượng ngoài public internet. Đó là lý do nó được chọn.

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

A. VPC endpoints — Đây là phương án gần đúng về mặt "riêng tư": VPC endpoint đúng là cho phép kết nối riêng tư từ VPC tới các dịch vụ AWS được hỗ trợ, không qua internet gateway. Nhưng nó hỏng ở đúng vế thứ hai của đề: VPC endpoint nối VPC ↔ dịch vụ AWS, chứ không nối AWS với mạng on-premises. Đề hỏi kênh giữa data center tại chỗ và VPC, nên phạm vi của VPC endpoint không phủ được yêu cầu.

C. AWS Site-to-Site VPN — Đây là phương án gây nhầm nhiều nhất, vì nó đúng nghĩa là kênh giữa on-premises và VPC và lưu lượng có được mã hoá trong đường hầm. Nó hỏng ở chỗ khác: theo giải thích của đề, đường hầm VPN đó chạy trên public internet, nên tuy đã mã hoá thì vẫn không đáp ứng chữ "private" mà công ty đòi. Nói cách khác, nó qua được tiêu chí "encrypted" nhưng trượt tiêu chí "private" — đúng một nửa yêu cầu, và đề chấm theo nửa còn lại. Hãy nhớ đây là cách đề lập luận để phân biệt A/B/C, và bám theo nó khi gặp lại dạng câu này.

D. AWS Global Accelerator — Sai vì lệch hẳn mục đích. Global Accelerator là dịch vụ mạng nhằm cải thiện hiệu năng lưu lượng của người dùng bằng cách đưa nó vào hạ tầng mạng toàn cầu của AWS: khi internet tắc nghẽn, nó tối ưu đường đi tới ứng dụng để giữ packet loss, jitter và latency ở mức thấp và ổn định. Đó là câu chuyện về tốc độ và độ ổn định, không phải về tính riêng tư hay mã hoá, và nó không phải công cụ để nối VPC với môi trường on-premises.

📌 Điểm cần nhớ

• Đọc câu hỏi networking, hãy tách yêu cầu thành hai phần và soi từng phương án qua cả hai: (1) nối cái gì với cái gì (VPC ↔ dịch vụ AWS? VPC ↔ on-premises? người dùng ↔ ứng dụng?) và (2) tính chất đường truyền (private / encrypted / nhanh).
• "Encrypted" và "private" không đồng nghĩa trong ngôn ngữ của bài thi: mã hoá là nội dung không đọc được, còn "private" ở đây được hiểu là không đi qua public internet. Đề nào nhấn mạnh "without traversing the public internet" thì hướng về các lựa chọn dùng hạ tầng riêng của AWS.
• VPC endpoints gắn với trục VPC ↔ dịch vụ AWS; đề mà nhắc tới on-premises data center thì phạm vi này thường là dấu hiệu loại trừ.
• AWS Global Accelerator luôn là câu chuyện hiệu năng, latency, packet loss, jitter — thấy nó xuất hiện trong câu hỏi về bảo mật hay kết nối lai (hybrid) thì gần như chắc chắn là phương án gây nhiễu.

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

Đề nêu một nhu cầu vận hành: cần thực hiện truy vấn (queries) để tìm kiếm và phân tích log một cách tương tác (interactively) trong nội bộ tổ chức. Câu hỏi thuộc mảng AWS Management & Governance, và cả bốn phương án đều xoay quanh hệ CloudWatch/EventBridge — nên phải đọc kỹ mới tách được.

Cụm từ quyết định nằm gọn trong một câu: "perform queries" và "search and analyze logs interactively". Hai ràng buộc này ghép lại rất hẹp:

• Đối tượng là logs, không phải metrics, không phải events. Điều này loại ngay những phương án làm việc trên số liệu đo (metric) hoặc trên luồng sự kiện.
• Cách làm là truy vấn tương tác, tức là người vận hành gõ câu truy vấn, chạy, xem kết quả, sửa lại rồi chạy tiếp. Đây là hành vi khác hẳn với "lưu trữ log", "chuyển tiếp sự kiện" hay "tự động cảnh báo".

Chỉ có đúng một phương án vừa làm việc trên log, vừa cung cấp ngôn ngữ truy vấn để dùng theo kiểu tương tác.

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

Đáp án đúng theo tệp là D — Amazon CloudWatch Logs Insights.

CloudWatch Logs Insights cho phép tìm kiếm và phân tích dữ liệu log trong Amazon CloudWatch Logs một cách tương tác. Nó có ngôn ngữ truy vấn riêng để lọc, trích trường, tổng hợp và sắp xếp kết quả trên các log group, rồi trả kết quả ngay để người dùng đọc và tinh chỉnh câu truy vấn tiếp.

Đây chính là công cụ dùng khi có sự cố vận hành: chạy truy vấn để khoanh vùng nguyên nhân khả dĩ, rồi sau khi triển khai bản vá thì chạy lại truy vấn để xác nhận là đã sửa được. Ánh xạ với đề bài rất khít — "queries" ↔ ngôn ngữ truy vấn của Logs Insights, "search and analyze logs" ↔ dữ liệu trong CloudWatch Logs, "interactively" ↔ vòng lặp gõ truy vấn – xem kết quả – sửa truy vấn.

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

A — Amazon EventBridge (Amazon CloudWatch Events). EventBridge là một event bus serverless: nó tiếp nhận dữ liệu sự kiện từ ứng dụng của bạn, từ ứng dụng SaaS và từ các dịch vụ AWS, rồi định tuyến sự kiện đó tới các target. Nó thuộc nhóm "phản ứng tự động theo sự kiện", không phải nhóm "tra cứu và phân tích". Người dùng không ngồi gõ truy vấn vào EventBridge để đọc log; nó chạy theo rule đã định nghĩa trước và đẩy sự kiện đi nơi khác.

B — Amazon CloudWatch anomaly detection. Đây là phương án gần đúng nhất về mặt "phân tích", nên cần chỉ rõ chỗ hỏng. Anomaly detection bật trên metric, không phải trên log: CloudWatch áp dụng thuật toán thống kê và machine learning để liên tục phân tích metric, dựng ra đường cơ sở (baseline) coi là bình thường, rồi làm nổi bật những điểm bất thường với rất ít can thiệp của người dùng. Hai điểm lệch so với đề: sai đối tượng (metric chứ không phải log) và sai kiểu tương tác (tự động, chạy nền — trong khi đề đòi người dùng chủ động chạy truy vấn).

C — Amazon CloudWatch Logs streams. Phương án này đúng ở chỗ nó nằm trong CloudWatch Logs, nên rất dễ chọn nhầm. Nhưng log stream chỉ là một chuỗi các log event có chung nguồn phát — mỗi nguồn log riêng biệt trong CloudWatch Logs tạo thành một log stream riêng. Nó là đơn vị tổ chức, nơi chứa dữ liệu, chứ không cung cấp cơ chế truy vấn. Xem log stream nghĩa là cuộn qua các dòng log theo thứ tự — không lọc theo điều kiện phức tạp, không tổng hợp, không đúng với chữ "perform queries" trong đề.

📌 Điểm cần nhớ

• Bám vào cặp danh từ + động từ trong đề: "logs" + "queries/analyze interactively" thì đáp án gần như luôn là CloudWatch Logs Insights. Nếu đề đổi thành "metrics" + "tự động phát hiện bất thường", đáp án chuyển sang CloudWatch anomaly detection.
• Phân biệt nơi chứa log với công cụ truy vấn log: log group và log stream là chỗ dữ liệu nằm; Logs Insights là thứ đọc dữ liệu đó bằng câu truy vấn. Bẫy hay gặp là đưa cả hai vào cùng một câu hỏi.
• "Interactively" là tín hiệu loại bỏ mọi dịch vụ chạy tự động. EventBridge (định tuyến sự kiện theo rule) và anomaly detection (phân tích nền, ít can thiệp) đều tự chạy, nên đều rớt trước ràng buộc này.
• EventBridge thuộc nhóm hành động, không thuộc nhóm quan sát. Nó trả lời câu hỏi "khi có sự kiện X thì làm gì tiếp", chứ không trả lời "chuyện gì đã xảy ra trong log".

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

Đề hỏi: consolidated billing trong AWS Organizations giúp giảm chi phí hằng tháng bằng cách nào.

Cụm từ quyết định là "help lower overall monthly expenses" — tức là làm giảm số tiền phải trả, chứ không phải "giúp quản lý", "giúp theo dõi" hay "giúp nhìn thấy" chi phí. Đây chính là cái bẫy của câu này: consolidated billing có nhiều lợi ích, nhưng chỉ một trong số đó thực sự làm hoá đơn nhỏ đi. Ba phương án còn lại đều mô tả những thứ có thật của AWS Organizations, chỉ là chúng thuộc nhóm tiện lợi/quản trị chứ không thuộc nhóm tiết kiệm tiền.

Khi gặp dạng câu "how does X lower cost", hãy tách các lựa chọn thành hai nhóm: nhóm nói về hiển thị/quản lý/tự động hoá và nhóm nói về giá đơn vị thực sự rẻ đi. Chỉ nhóm thứ hai mới trả lời đúng câu hỏi.

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

C — "By pooling usage across multiple accounts to achieve a pricing tier discount"

Khi các account nằm chung một organization dùng consolidated billing, AWS gộp mức sử dụng (usage) của tất cả account lại và tính giá như thể đó là một người dùng duy nhất. Nhiều dịch vụ AWS có bảng giá theo bậc (tiered pricing) — càng dùng nhiều thì đơn giá của phần dùng thêm càng rẻ. Nếu mỗi account đứng riêng, mỗi account bắt đầu lại từ bậc giá đắt nhất; gộp lại thì tổng usage leo lên bậc rẻ hơn, và cả tổ chức trả ít tiền hơn.

Ngoài volume discount theo bậc, phần usage gộp này còn cho phép chia sẻ Reserved Instance discount và Savings Plans giữa các account trong organization: một cam kết mua ở account này có thể được áp cho usage phù hợp ở account khác, thay vì để trống phần cam kết đã trả tiền. Bản thân consolidated billing không thu thêm phí, nên phần tiết kiệm được là lợi ích ròng.

Đó là lý do C là phương án duy nhất chạm đúng vào chữ lower expenses: nó thay đổi giá, không chỉ thay đổi cách nhìn hoá đơn.

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

A — "By providing a consolidated view of monthly billing across multiple accounts" Đây là phương án gần đúng nhất và cũng nguy hiểm nhất, vì nó mô tả đúng một lợi ích có thật của consolidated billing: một hoá đơn duy nhất, theo dõi chi phí xuyên nhiều account, tải về dữ liệu cost & usage đã gộp. Nhưng nó hỏng ở chỗ nhìn thấy chi phí không làm chi phí giảm đi. Một cái view đẹp giúp bạn phát hiện chỗ lãng phí, còn việc cắt giảm vẫn là hành động thủ công sau đó. Đề hỏi cơ chế tự nó hạ chi phí, nên A trượt.

B — "By leveraging service control policies (SCP) for centralized service management" SCP là tính năng có thật của AWS Organizations, nhưng nó thuộc mảng governance/quyền hạn: SCP đặt trần cho những API action mà account thành viên được phép gọi. Nó không tác động gì tới bảng giá hay cách tính usage. Có thể lập luận vòng vo rằng chặn dịch vụ đắt tiền thì đỡ tốn — nhưng đó là ngăn phát sinh chi tiêu mới, không phải cơ chế của consolidated billing, và đề đang hỏi riêng về consolidated billing chứ không hỏi về SCP.

D — "By automating the creation of new accounts through APIs" AWS Organizations đúng là cho phép tạo account thành viên bằng API. Nhưng tạo account nhanh hơn chỉ là chuyện tiện lợi vận hành; nhiều account hơn thì tiền không tự ít đi — thậm chí nếu không gộp billing thì còn dễ đắt hơn. Phương án này không liên quan gì tới cơ chế tính giá.

📌 Điểm cần nhớ

• Consolidated billing giảm tiền nhờ gộp usage: tổng usage của cả organization được tính chung nên leo lên bậc giá rẻ hơn, đồng thời chia sẻ được Reserved Instance discount và Savings Plans giữa các account.
• Phân biệt rõ ba nhóm lợi ích của AWS Organizations: billing (consolidated billing → tiết kiệm tiền), governance (SCP → giới hạn API action), quản trị account (tạo account bằng API → tiện lợi). Đề hỏi nhóm nào thì trả lời trong nhóm đó.
• "Một hoá đơn duy nhất" và "theo dõi chi phí dễ hơn" là lợi ích hiển thị, không phải lợi ích giảm giá — luôn là mồi nhử trong câu hỏi có chữ lower cost.
• Consolidated billing không tính thêm phí, nên trong đề thi nó luôn được coi là lựa chọn "không mất gì mà có lợi" khi bàn về nhiều account trong một tổ chức.

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

Đề bài hỏi rất gọn: "What AWS service offers managed DDoS protection?" — dịch vụ AWS nào cung cấp khả năng chống DDoS ở dạng dịch vụ quản lý sẵn.

Cụm từ quyết định đáp án là "DDoS protection". Đây là từ khoá phân biệt duy nhất, vì cả bốn phương án đều thuộc nhóm AWS Security, Identity & Compliance và đều là dịch vụ quản lý (managed) — nên chữ "managed" không giúp loại được gì. Điều cần bám vào là loại mối đe doạ mà mỗi dịch vụ xử lý:

• DDoS = tấn công làm cạn kiệt tài nguyên/băng thông để hạ ứng dụng, cần giảm thiểu lưu lượng tấn công theo thời gian thực (mitigation).
• Các nhóm khác trong danh sách chỉ làm phát hiện (detection), đánh giá lỗ hổng (assessment) hoặc quản trị tập trung luật tường lửa (management) — biết được vấn đề, nhưng không tự chặn dòng tấn công.

Câu hỏi thuộc dạng "khớp dịch vụ với nhiệm vụ", nên chỉ cần định vị đúng dịch vụ có chức năng mitigation là xong.

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

Đáp án đúng: C — AWS Shield.

AWS Shield là dịch vụ managed DDoS protection dành riêng cho các ứng dụng chạy trên AWS. Điểm cốt lõi:

• Shield cung cấp always-on detection — luôn giám sát lưu lượng, không cần bật thủ công khi bị tấn công.
• Shield thực hiện automatic inline mitigation — tự động lọc/giảm thiểu lưu lượng tấn công ngay trên đường đi, nhằm giảm thời gian ngừng hoạt động và độ trễ của ứng dụng.
• Người dùng không cần liên hệ AWS Support mới được bảo vệ; cơ chế bảo vệ đã sẵn ở đó.
• Shield có hai mức: Standard và Advanced — Standard là mức nền, Advanced là mức bổ sung dành cho các nhu cầu bảo vệ sâu hơn.

Đây chính xác là mô tả "managed DDoS protection" mà đề yêu cầu, nên C là đáp án duy nhất khớp.

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

A. Amazon GuardDuty — sai. GuardDuty là dịch vụ threat detection: nó liên tục giám sát tài khoản và workload AWS để tìm hoạt động đáng ngờ hoặc độc hại, rồi phát ra các security findings chi tiết để bạn nhìn thấy và xử lý. Đây là phương án gần đúng nhất về mặt "bảo mật chủ động", và nó có thể báo cho bạn biết có dấu hiệu bất thường — nhưng nó dừng ở mức phát hiện và cảnh báo, không chặn hay giảm thiểu lưu lượng tấn công DDoS. Đề hỏi dịch vụ bảo vệ, không hỏi dịch vụ phát hiện.

B. AWS Firewall Manager — sai. Firewall Manager là dịch vụ security management: cho phép cấu hình và quản lý tập trung các luật tường lửa trên nhiều tài khoản. Nó là lớp quản trị nằm trên các dịch vụ bảo vệ khác, giúp áp chính sách đồng nhất — chứ bản thân nó không phải là dịch vụ chống DDoS. Đây là bẫy dễ dính vì chữ "Firewall" gợi liên tưởng tới chặn lưu lượng; nhưng vai trò của nó là quản lý luật, không phải thực thi mitigation DDoS.

D. Amazon Inspector — sai. Inspector là công cụ vulnerability assessment được quản lý hoàn toàn: quét và đánh giá lỗ hổng bảo mật trong workload. Nó trả lời câu hỏi "hệ thống của tôi có điểm yếu nào?", hoàn toàn khác với câu hỏi "làm sao chặn được đợt tấn công đang diễn ra?". Inspector không bảo vệ khỏi tấn công DDoS.

📌 Điểm cần nhớ

• AWS Shield = managed DDoS protection. Ghi nhớ cặp từ khoá "DDoS → Shield"; đây là ánh xạ một-một hay xuất hiện trong đề Cloud Practitioner.
• Phân biệt ba nhóm dịch vụ dễ lẫn trong AWS Security: Shield = mitigation (chặn/giảm thiểu), GuardDuty = detection (phát hiện, sinh findings), Inspector = vulnerability assessment (quét lỗ hổng).
• Firewall Manager là lớp quản trị tập trung luật tường lửa xuyên nhiều tài khoản, không phải lớp thực thi chống DDoS — thấy chữ "Manager" thì nghĩ tới "quản lý chính sách", không phải "bảo vệ trực tiếp".
• AWS Shield có hai mức Standard và Advanced, hoạt động theo cơ chế always-on detection + automatic inline mitigation, nên không cần thao tác thủ công hay mở ticket với AWS Support mới được bảo vệ.