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

Đáp án

A — Hybrid Cloud (đám mây lai)

Vì sao đúng

Đề mô tả đúng mô hình lai: dữ liệu nhạy cảm giữ tại trung tâm dữ liệu riêng vì lý do tuân thủ, trong khi vẫn triển khai tài nguyên trên AWS.

Đây là lý do phổ biến nhất khiến các tổ chức chọn mô hình lai: quy định bắt dữ liệu phải nằm trong lãnh thổ hoặc trong hạ tầng do chính họ kiểm soát, nhưng phần còn lại vẫn muốn hưởng lợi từ đám mây.

Các dịch vụ AWS hỗ trợ mô hình này: Direct Connect và VPN để nối mạng, Storage Gateway để truy cập lưu trữ đám mây từ tại chỗ, Outposts để chạy hạ tầng AWS ngay trong trung tâm dữ liệu của bạn.

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

• B. Private Cloud — toàn bộ hạ tầng là riêng, không dùng đám mây công cộng nào; đề nói rõ công ty vẫn triển khai trên AWS.
• C. On-premises — cũng chỉ có hạ tầng tại chỗ.
• D. Public Cloud — toàn bộ trên đám mây công cộng; đề nói rõ dữ liệu nhạy cảm phải ở lại.

Đáp án

C — Customer gateway

Vì sao đúng

AWS Site-to-Site VPN cần một đầu kết thúc ở mỗi phía, và câu hỏi hỏi phần thuộc về công ty:

Trung tâm dữ liệu                        AWS
┌────────────────────┐              ┌──────────────────────┐
│ CUSTOMER GATEWAY   │══ đường hầm ═│ VIRTUAL PRIVATE      │
│ (thiết bị của bạn) │    IPsec     │ GATEWAY (phía AWS)   │
└────────────────────┘              └──────────────────────┘

Customer gateway có hai nghĩa cần phân biệt: thiết bị VPN thật đặt tại trung tâm dữ liệu (router hoặc tường lửa hỗ trợ IPsec), và tài nguyên trong AWS mô tả thiết bị đó — địa chỉ IP công cộng và số ASN dùng cho BGP.

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

• D. Virtual private gateway — là đầu kết thúc phía AWS, gắn vào VPC. Đúng thành phần nhưng sai phía; đây là phương án nhiễu chính.
• A. Security group — lớp lọc lưu lượng cho instance, không phải thành phần của VPN.
• B. VPC endpoint interface — cho phép truy cập riêng tư tới dịch vụ AWS từ bên trong VPC.

Lưu ý

Thay cho virtual private gateway, bạn dùng được Transit Gateway làm đầu kết thúc phía AWS — hợp khi cần nối VPN tới nhiều VPC cùng lúc.

Đáp án

A — AWS Partner Solutions (tên cũ là Quick Starts)

Vì sao đúng

AWS Partner Solutions là các mẫu triển khai tự động do AWS và các đối tác xây dựng, cho những công nghệ phổ biến — Microsoft SharePoint, SAP HANA, Jenkins, Kubernetes, Active Directory, và hàng trăm thứ khác.

Mỗi bộ gồm ba phần: mẫu CloudFormation dựng sẵn theo thực hành tốt của AWS, tài liệu hướng dẫn giải thích kiến trúc, và ước tính chi phí.

Giá trị: triển khai một hệ thống phức tạp trong khoảng một giờ, thay vì vài ngày đọc tài liệu và tự ghép các mảnh — và kiến trúc đã được rà soát về tính sẵn sàng và bảo mật.

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

• B. AWS Whitepapers — tài liệu kỹ thuật để đọc; chúng giải thích cách làm nhưng không tự triển khai gì. Đây là phương án nhiễu chính.
• C. AWS Forums — nơi thảo luận và hỏi đáp cộng đồng.
• D. AWS CodeDeploy — triển khai mã ứng dụng của bạn, không phải phần mềm bên thứ ba.

Đáp án

C — Amazon Cognito

Vì sao đúng

Cognito quản lý danh tính cho người dùng cuối của ứng dụng — khách hàng dùng ứng dụng web hoặc di động của bạn. Nó cung cấp sẵn: đăng ký, đăng nhập, quên mật khẩu, xác minh email và số điện thoại, MFA, và đăng nhập qua bên thứ ba (Google, Facebook, Apple, SAML, OIDC).

Cognito có hai thành phần:

• User Pool — thư mục người dùng; lo phần xác thực (bạn là ai).
• Identity Pool — cấp thông tin xác thực AWS tạm thời để ứng dụng gọi thẳng dịch vụ AWS.

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

• B. AWS IAM — quản lý danh tính cho người và ứng dụng truy cập tài nguyên AWS, không dành cho hàng triệu người dùng cuối. IAM có giới hạn số user và không có luồng đăng ký cho người dùng. Đây là phương án nhiễu chính, và ranh giới rất rõ:

  	IAM	Cognito
  Dành cho	Người vận hành AWS	Người dùng ứng dụng của bạn
  Quy mô	Hàng chục tới hàng trăm	Hàng triệu

• D. IAM Identity Center — đăng nhập một lần cho nhân viên truy cập nhiều tài khoản AWS.

• A. AWS Organizations — quản lý nhiều tài khoản AWS.

Đáp án

A và C — Provisioned IOPS và loại volume

Vì sao đúng

Giá của EBS volume tính theo ba yếu tố, và hai trong số đó nằm trong đáp án:

• C. Loại volume — mỗi loại có đơn giá khác nhau: gp3 và gp2 (SSD đa dụng), io1 và io2 (SSD hiệu năng cao), st1 (HDD thông lượng cao), sc1 (HDD chi phí thấp).
• A. Provisioned IOPS — với io1, io2 và cả gp3, bạn đặt trước mức IOPS và trả tiền cho mức đó, tách riêng khỏi dung lượng.
• (Yếu tố thứ ba: dung lượng đã cấp phát, tính theo GB mỗi tháng.)

Điểm quan trọng: bạn trả tiền cho dung lượng đã cấp phát, không phải dung lượng đang dùng. Volume 500 GB chỉ chứa 10 GB dữ liệu vẫn tính đủ 500 GB.

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

• D. Loại EC2 instance mà volume gắn vào — không ảnh hưởng tới giá volume; hai thứ tính tiền độc lập. (Instance loại nào thì ảnh hưởng tới băng thông EBS tối đa, nhưng đó là giới hạn hiệu năng chứ không phải yếu tố giá.) Đây là phương án nhiễu chính.
• E. Dữ liệu truyền vào — dữ liệu đi vào luôn miễn phí trên AWS.
• B. Loại dữ liệu — EBS không phân biệt nội dung dữ liệu.

Đáp án

B — AWS Health Dashboard — Service Health

Vì sao đúng

Chữ khoá của đề là RSS feed và "tất cả dịch vụ bị gián đoạn" — tức là thông tin công khai và toàn cục.

Service Health Dashboard cung cấp RSS feed riêng cho từng dịch vụ ở từng Region, nên bạn đăng ký theo dõi đúng những dịch vụ mình dùng bằng bất kỳ trình đọc RSS nào.

Nó cũng truy cập được không cần đăng nhập — hữu ích khi bạn nghi ngờ chính việc đăng nhập đang gặp sự cố.

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

• A. Your Account Health — hiển thị sự cố ảnh hưởng tới tài nguyên cụ thể của bạn, và nó cần đăng nhập; nó phát sự kiện qua EventBridge chứ không có RSS feed. Đây là phương án nhiễu chính:

  	Service Health	Your Account Health
  Phạm vi	Mọi dịch vụ, mọi Region	Chỉ tài nguyên của bạn
  Cần đăng nhập	Không	Có
  Cách nhận thông báo	RSS feed	EventBridge

• D. Amazon SNS — gửi thông báo, nhưng nó là cơ chế truyền tải; nó không phải nguồn thông tin về tình trạng dịch vụ.

• C. AWS Lambda — chạy mã, không liên quan.

Đáp án

C — Thay thế các EC2 instance không khoẻ

Vì sao đúng

Khả năng chịu lỗi (fault tolerance) nghĩa là hệ thống vẫn hoạt động khi một thành phần hỏng, và đây là năng lực của Auto Scaling khớp chính xác với định nghĩa đó.

Cách hoạt động: Auto Scaling liên tục kiểm tra sức khoẻ của từng instance — dựa trên EC2 status check hoặc health check của ELB. Máy nào không đạt thì bị huỷ và thay bằng máy mới, nên số lượng máy khoẻ luôn được giữ đúng mức mong muốn.

Nhờ vậy sự cố phần cứng hay lỗi ứng dụng làm treo một máy tự được xử lý, không cần ai can thiệp.

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

Ba phương án còn lại đều là năng lực có thật của Auto Scaling nhưng phục vụ mục tiêu khác:

• B. Có đúng lượng năng lực tính toán cần thiết — thuộc về khả năng mở rộng (scalability). Đây là phương án nhiễu chính vì nó là chức năng nổi tiếng nhất của Auto Scaling.
• A. Giảm chi phí bằng cách điều chỉnh số lượng instance — thuộc về tối ưu chi phí.
• D. Phân phối tải cho các instance — đó là việc của Elastic Load Balancing, không phải Auto Scaling.

Đáp án

A — AWS Glue

Vì sao đúng

Đề nêu hai điều kiện: không máy chủ (serverless) và chuẩn bị dữ liệu cho phân tích. Glue là dịch vụ ETL không máy chủ của AWS, làm đúng việc đó:

• Crawler — tự quét nguồn dữ liệu, suy ra lược đồ, và ghi vào Data Catalog.
• ETL jobs — trích xuất, biến đổi và nạp dữ liệu; viết bằng Python hoặc Scala trên nền Spark.
• DataBrew — giao diện trực quan để làm sạch và chuẩn hoá dữ liệu không cần viết mã.

Glue Data Catalog là thành phần đáng chú ý nhất: nó là kho siêu dữ liệu dùng chung mà Athena, Redshift Spectrum và EMR đều đọc được — nên định nghĩa bảng chỉ khai một lần.

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

• C. Amazon Athena — cũng không máy chủ, nhưng nó truy vấn dữ liệu đã sẵn sàng chứ không chuẩn bị dữ liệu. Nó thường là bước sau Glue. Đây là phương án nhiễu chính.
• B. Amazon Redshift — kho dữ liệu; đòi cấp phát cụm (trừ bản Serverless), và cũng là nơi phân tích chứ không phải nơi chuẩn bị.
• D. Amazon EMR — cụm Hadoop và Spark; không phải serverless ở dạng cổ điển, bạn quản lý cụm.

Đáp án

B và E — hiệu năng ứng dụng và mức sử dụng tài nguyên

Vì sao đúng

CloudWatch là dịch vụ giám sát và quan sát cho tài nguyên và ứng dụng của bạn:

• E. Mức sử dụng tài nguyên — chỉ số có sẵn cho hầu hết dịch vụ AWS: CPU của EC2, IOPS của EBS, số kết nối của RDS, thời lượng của Lambda.
• B. Hiệu năng ứng dụng — qua chỉ số tuỳ chỉnh do ứng dụng đẩy lên, CloudWatch Logs cho log ứng dụng, và CloudWatch Application Insights để phát hiện vấn đề.

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

• *C. Hiệu năng và tính khả dụng của chính các dịch vụ AWS — đó là AWS Health Dashboard. CloudWatch giám sát tài nguyên của bạn, không giám sát tình trạng dịch vụ của AWS. Đây là phương án nhiễu chính, và đó là ranh giới rất đáng nhớ.
• A. Truy cập API — ai gọi API nào là việc của CloudTrail.
• D. Quản lý tài khoản — thuộc về IAM và Organizations.

Ghi nhớ ba dịch vụ hay bị lẫn

Đáp án

B và E — tạo tài khoản AWS riêng cho từng phòng ban, và giới hạn quyền bằng Service Control Policy

Vì sao đúng

Cả hai đều là thực hành tốt được AWS khuyến nghị khi dùng Organizations:

• B. Tài khoản riêng cho từng phòng ban — tài khoản là ranh giới cách ly mạnh nhất trên AWS: cách ly hoàn toàn về quyền, hạn mức dịch vụ riêng, và chi phí tách bạch tự nhiên. Sự cố ở một tài khoản không lan sang tài khoản khác.
• E. Dùng Service Control Policy để giới hạn quyền — SCP đặt trần quyền tối đa cho cả tài khoản, kể cả root user. Đây là cách duy nhất giới hạn được root, và nó áp cho mọi người trong tài khoản đó dù chính sách IAM có cho phép gì.

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

Ba phương án còn lại đều là phản thực hành được phát biểu thẳng:

• A. Tắt CloudTrail ở một số tài khoản — mất khả năng kiểm toán ở đúng những chỗ đó; khuyến nghị là bật organization trail phủ toàn bộ tổ chức.
• C. Không bao giờ dùng thẻ cho việc tính chi phí — thẻ là công cụ chính để phân bổ chi phí.
• D. Không dùng Organizations để tự động tạo tài khoản — ngược lại; tự động hoá việc tạo tài khoản (qua Control Tower Account Factory) chính là thực hành tốt.