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

Đáp án

C — AWS Budgets

Vì sao đúng

AWS Budgets có riêng loại ngân sách gọi là reservation budget, chuyên theo dõi mức sử dụng Reserved Instance và Savings Plans. Bạn đặt ngưỡng — ví dụ 80% — và nhận cảnh báo qua email hoặc SNS khi tỷ lệ tận dụng rơi xuống dưới mức đó.

Đây là việc rất đáng làm vì Reserved Instance là cam kết trả tiền dù có dùng hay không: mua RI rồi để đó không dùng là mất tiền hoàn toàn, mà không có tín hiệu nào tự báo cho bạn ngoài cơ chế này.

Budgets cũng theo dõi được độ phủ (coverage) — tỷ lệ mức sử dụng thực tế đang được RI che phủ — để biết khi nào nên mua thêm.

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

• D. AWS Trusted Advisor — có kiểm tra về Reserved Instance sử dụng thấp, nhưng nó đưa khuyến nghị theo chu kỳ chứ không cho bạn đặt ngưỡng và nhận cảnh báo như Budgets. Đây là phương án nhiễu chính.
• B. AWS Pricing Calculator — ước tính chi phí trước khi dùng.
• A. AWS CloudTrail — ghi lại lời gọi API, không liên quan tới chi phí.

Đáp án

D và E — dùng AWS Partner Network để xây giải pháp riêng, và tận dụng AWS Professional Services để đẩy nhanh việc di trú

Vì sao đúng

Cả hai đều là nguồn lực chuyên môn có con người, đúng thứ cần cho một dự án di trú:

• E. AWS Professional Services — đội ngũ tư vấn của chính AWS, làm việc cùng đội của bạn để lập kế hoạch và thực hiện di trú.
• D. AWS Partner Network — mạng lưới đối tác bên thứ ba được AWS chứng nhận; Consulting Partner xây dựng giải pháp riêng cho bạn.

Khác biệt để chọn: Professional Services là người của AWS, hiểu sâu dịch vụ AWS; đối tác APN thường có hiểu biết ngành nghề và có mặt ở địa phương.

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

• B. Dùng AWS Trusted Advisor để tự động hoá việc di trú — Trusted Advisor chỉ đưa khuyến nghị về tài nguyên bạn đã có trên AWS; nó không di chuyển gì và cũng chẳng biết gì về trung tâm dữ liệu của bạn. Đây là phương án nhiễu chính.
• A. Mở ticket với AWS Support — hỗ trợ kỹ thuật xử lý sự cố cụ thể, không thực hiện dự án di trú; và gói Basic còn không mở được ticket kỹ thuật.
• C. Hỏi người kiểm duyệt trên diễn đàn AWS Developer — diễn đàn là nơi thảo luận, không phải kênh triển khai dự án.

Đáp án

C — Tài khoản AWS phải có khả năng hoạt động độc lập thì mới gỡ khỏi AWS Organizations được

Vì sao đúng

Khi một tài khoản được tạo bên trong Organizations, nó không có đủ thông tin để tự tồn tại. Vì vậy trước khi gỡ ra, bạn phải bổ sung:

• Thông tin thanh toán hợp lệ — phương thức thanh toán riêng.
• Thông tin liên hệ đầy đủ — địa chỉ, số điện thoại.
• Xác minh số điện thoại.
• Chấp nhận Thoả thuận Khách hàng AWS với tư cách tài khoản độc lập.
• Trong nhiều trường hợp: đặt lại mật khẩu cho tài khoản gốc, vì tài khoản tạo bởi Organizations không có mật khẩu gốc.

Lý do rất thẳng thắn: sau khi rời tổ chức, tài khoản phải tự trả hoá đơn của mình — nên nó phải có sẵn phương thức thanh toán.

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

• B. Phải gỡ hết Service Control Policy trước — không đúng; SCP tự động ngừng áp dụng khi tài khoản rời tổ chức. Đây là phương án nhiễu chính.
• D. Phải mở ticket với AWS Support — không cần; thao tác gỡ tài khoản làm được ngay trong Console của Organizations.
• A. Gỡ tài khoản từ AWS Systems Manager — sai dịch vụ hoàn toàn.

Đáp án

A — Dùng AWS Organizations để quản lý tài khoản của mọi bộ phận, rồi chia sẻ Reserved Instance giữa chúng

Vì sao đúng

Vấn đề trong đề: bộ phận này dùng thừa RI trong khi bộ phận kia thiếu — nhưng mỗi bộ phận có tài khoản riêng nên RI bị "khoá" trong từng tài khoản.

AWS Organizations giải bằng thanh toán hợp nhất (consolidated billing), và nó mang theo hai lợi ích cộng dồn:

• Chia sẻ Reserved Instance — khi bật RI sharing, mức giảm giá của RI ở một tài khoản áp được cho mức sử dụng phù hợp ở bất kỳ tài khoản nào trong tổ chức. RI thừa của bộ phận A tự động che phủ cho bộ phận B.
• Giá bậc thang gộp chung — mức sử dụng của tất cả tài khoản được cộng lại để tính bậc giá, nên cả tổ chức đạt bậc rẻ hơn.

Đây là cách tối ưu chi phí không cần thay đổi gì về kiến trúc.

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

Ba phương án còn lại đều gán cho một dịch vụ khả năng quản lý tài khoản mà nó không có:

• B. AWS Cost Explorer — phân tích và trực quan hoá chi phí; nó cho bạn thấy tình trạng RI bị dùng thiếu, nhưng không chia sẻ được gì. Đây là phương án nhiễu chính.
• C. AWS Trusted Advisor — đưa khuyến nghị, không quản lý tài khoản.
• D. AWS Systems Manager — quản lý và vận hành máy chủ, không quản lý tài khoản AWS.

Đáp án

D — AWS Identity and Access Management (IAM)

Vì sao đúng

IAM là nền tảng bảo mật của toàn bộ AWS, vì nó trả lời hai câu hỏi mà mọi lời gọi API đều phải đi qua: bạn là ai (xác thực) và bạn được làm gì (phân quyền).

Điểm khiến nó khác các dịch vụ bảo mật khác: mọi hành động trên AWS đều bị IAM kiểm tra, không có ngoại lệ. Mở một EC2 instance, đọc một đối tượng S3, gọi một hàm Lambda — tất cả đều phải qua đánh giá chính sách IAM.

IAM cũng miễn phí và không tắt được, nên nó là lớp bảo vệ duy nhất luôn hiện diện.

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

Ba phương án còn lại là dịch vụ bảo mật chuyên biệt, mỗi cái lo một mặt và không cái nào là nền tảng:

• A. AWS WAF — lọc lưu lượng web ở tầng 7.
• C. AWS Shield — chống tấn công từ chối dịch vụ.
• B. Amazon CloudWatch — giám sát và cảnh báo; nó phát hiện bất thường chứ không kiểm soát truy cập.

Ghi nhớ

Nếu câu hỏi dùng từ "nền tảng", "thiết yếu" hay "cơ bản" cho bảo mật AWS, câu trả lời gần như luôn là IAM.

Đáp án

D — Performance and capacity management (quản lý hiệu năng và năng lực)

Vì sao đúng

Góc nhìn Operations của AWS Cloud Adoption Framework lo việc vận hành hệ thống hằng ngày: bảo đảm dịch vụ chạy đúng mức cam kết, phát hiện và xử lý sự cố, dự phòng năng lực cho tương lai.

Quản lý hiệu năng và năng lực nằm gọn trong đó: theo dõi hệ thống có đáp ứng được yêu cầu không, và có đủ tài nguyên cho nhu cầu sắp tới không.

Sáu góc nhìn của AWS CAF và năng lực tiêu biểu

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 CAF, nhưng thuộc góc nhìn khác:

• A. Platform engineering — góc nhìn Platform.
• C. Vulnerability management — góc nhìn Security.
• B. Application portfolio management — góc nhìn Governance.

Đáp án

C và D — Amazon CloudWatch và Amazon SNS

Vì sao đúng

Hai dịch vụ ghép thành một giải pháp giám sát chuẩn, và không cần viết dòng mã nào:

EC2 instances
   ▼  đẩy chỉ số CPUUtilization
Amazon CloudWatch
   ▼  cảnh báo kích hoạt khi vượt 80%
CloudWatch Alarm
   ▼  gửi thông điệp
Amazon SNS  →  email tới quản trị viên

• D. CloudWatch — thu thập chỉ số CPUUtilization (có sẵn, không phải cài agent) và cho bạn đặt cảnh báo theo ngưỡng.
• C. SNS — nhận thông điệp từ cảnh báo và gửi email tới người đăng ký.

Đây là mẫu ghép đôi rất phổ biến trên AWS: CloudWatch phát hiện, SNS thông báo.

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

• E. AWS Lambda — dùng được nếu bạn cần xử lý phức tạp khi có cảnh báo, nhưng ở đây chỉ cần gửi email nên SNS làm thẳng được, không cần thêm mã.
• B. Amazon SQS — hàng đợi thông điệp theo mô hình kéo: người nhận phải chủ động lấy. Gửi email cần mô hình đẩy, tức là SNS.
• A. AWS CloudTrail — ghi lại lời gọi API, không thu thập chỉ số hiệu năng.

Đáp án

B và E — Cost Optimization và Reliability

Vì sao đúng

AWS Well-Architected Framework có sáu trụ:

(Trụ Sustainability được thêm vào cuối năm 2021, nên tài liệu cũ hơn chỉ ghi năm trụ.)

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

Ba phương án còn lại đều là khái niệm kỹ thuật có thật, nhưng không phải tên trụ — chúng là những thuộc tính nằm bên trong các trụ:

• A. Elasticity và C. Scalability — là nguyên tắc thiết kế được nhắc tới trong trụ Reliability và Performance Efficiency.
• D. Availability — là chỉ số đo thuộc phạm vi trụ Reliability.

Đây là kiểu bẫy đáng chú ý: các phương án sai nghe rất "đúng chủ đề", nên phải nhớ đúng sáu cái tên chứ không suy luận theo cảm giác.

Đáp án

A — AWS Local Zones

Vì sao đúng

Local Zone là phần mở rộng của một AWS Region đặt ngay tại các thành phố lớn, nơi tập trung đông người dùng. Nó cho phép chạy tài nguyên tính toán và lưu trữ thật sự — EC2, EBS, ELB — chỉ cách người chơi vài mili giây.

Với game trực tuyến thì đó là điều kiện bắt buộc: máy chủ game phải xử lý logic trận đấu theo thời gian thực, không thể chỉ cache nội dung.

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

• D. AWS Wavelength — cũng đưa tính toán tới gần người dùng, nhưng nhúng vào mạng 5G của nhà mạng viễn thông, dành riêng cho thiết bị di động kết nối qua 5G. Đề nói người dùng ở nhiều vị trí khác nhau, không giới hạn ở người dùng 5G. Đây là phương án nhiễu chính.
• B. AWS Edge Locations — thuộc mạng CloudFront, dùng để cache nội dung tĩnh; chúng không chạy được máy chủ game.
• C. AWS Direct Connect — kết nối riêng giữa trung tâm dữ liệu của bạn và AWS; không liên quan tới độ trễ của người dùng cuối.

Ghi nhớ ba hạ tầng biên của AWS

Đáp án

C, D và E — AWS SDK, AWS Management Console và AWS CLI

Vì sao đúng

Đây là ba cách chính thức để truy cập và quản lý dịch vụ AWS, mỗi cách phục vụ một tình huống:

Cả ba đều gọi tới cùng một tập REST API bên dưới, nên năng lực tương đương nhau — chỉ khác cách bạn tương tác.

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

Ba phương án còn lại là dịch vụ AWS cụ thể, không phải cơ chế truy cập chung:

• A. AWS Systems Manager — quản lý và vận hành máy chủ (EC2 và máy tại chỗ); nó không quản lý được mọi dịch vụ AWS.
• B. Amazon API Gateway — dịch vụ để bạn xây API cho ứng dụng của mình, không phải cổng vào các dịch vụ AWS.
• F. AWS Secrets Manager — lưu và xoay vòng bí mật.