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

Đáp án

D — AWS Pricing Calculator

Vì sao đúng

Chi tiết quyết định: công ty chưa dùng AWS, nên chưa có dữ liệu chi phí nào. Chỉ có một công cụ ước tính được hoá đơn trước khi phát sinh chi tiêu.

Pricing Calculator cho bạn khai cấu hình dự kiến — bao nhiêu instance EC2, loại gì, bao nhiêu GB S3, lưu lượng ra bao nhiêu — rồi tính ra chi phí ước tính hằng tháng và hằng năm. Kết quả lưu lại và chia sẻ được bằng một liên kết.

Với việc so sánh giữa tại chỗ và AWS, đây là con số phía AWS; phía tại chỗ bạn tự cộng các khoản mà đám mây loại bỏ: phần cứng, điện và làm mát, mặt bằng, an ninh vật lý, và nhân sự vận hành.

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

Ba phương án còn lại đều làm việc với chi tiêu đã phát sinh, nên vô dụng với công ty chưa lên đám mây:

• C. AWS Cost Explorer — phân tích chi phí trong quá khứ; dự báo của nó cũng dựa trên lịch sử.
• B. AWS Budgets — đặt ngưỡng và cảnh báo khi vượt.
• A. AWS Trusted Advisor — khuyến nghị tối ưu cho tài nguyên đã có trên AWS.

Đáp án

B — Amazon S3 Standard

Vì sao đúng

Thời gian lưu trữ tối thiểu là ràng buộc kèm theo các lớp lưu trữ giá rẻ: xoá đối tượng sớm hơn thời hạn đó thì vẫn bị tính đủ tiền cho cả kỳ.

Hệ quả thực tế rất đáng nhớ: nếu dữ liệu sống ngắn (vài ngày rồi xoá), chuyển nó sang lớp IA để "tiết kiệm" thực ra tốn hơn — vì bạn vẫn trả đủ 30 ngày.

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

• D. S3 Standard-IA và A. S3 One Zone-IA — cả hai đều có 30 ngày tối thiểu.
• C. S3 Glacier Flexible Retrieval — 90 ngày.

Ghi chú

S3 Intelligent-Tiering cũng không có thời gian tối thiểu, nhưng nó không nằm trong bốn phương án. Đó là lý do nó là lựa chọn an toàn khi bạn không đoán được vòng đời của dữ liệu.

Đáp án

C — AWS Budgets

Vì sao đúng

AWS Budgets có riêng loại reservation budget, chuyên theo dõi mức tận 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ì RI là cam kết trả tiền dù có dùng hay không: mua rồi để đó 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 độ 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

• A. 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 riêng và nhận cảnh báo. Đây là phương án nhiễu chính.
• D. AWS Cost Explorer — hiển thị biểu đồ tận dụng RI rất chi tiết, nhưng bạn phải chủ động vào xem; nó không gửi cảnh báo.
• B. AWS Systems Manager — quản lý và vận hành máy chủ.

Ghi nhớ

Hễ câu hỏi có chữ "nhận cảnh báo khi vượt ngưỡng" trong ngữ cảnh chi phí, câu trả lời gần như luôn là AWS Budgets.

Đáp án

D — U2F security key

Vì sao đúng

U2F security key là thiết bị nhỏ cắm vào cổng USB — YubiKey là loại phổ biến nhất. Bạn chỉ cần cắm vào và chạm nhẹ để xác thực; không có mã số nào phải gõ.

Đây cũng là hình thức MFA an toàn nhất vì nó chống được tấn công lừa đảo (phishing): khoá U2F chỉ ký cho đúng tên miền đã đăng ký, nên một trang giả mạo dù trông giống hệt cũng không lấy được gì.

Ba loại MFA mà AWS hỗ trợ

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

• C. Hardware MFA device — cũng là thiết bị vật lý, nhưng nó hiển thị mã số để bạn gõ vào, không cắm vào máy tính. Đây là phương án nhiễu chính, và điểm phân biệt nằm ở chữ "cắm vào cổng USB".
• B. Virtual MFA device — ứng dụng trên điện thoại, không có thiết bị vật lý nào.
• A. MFA qua tin nhắn SMS — AWS đã ngừng hỗ trợ hình thức này cho IAM, vì SMS dễ bị tấn công tráo đổi SIM.

Đáp án

A — Amazon CloudWatch

Vì sao đúng

Chữ khoá của đề là "billing alarm" (cảnh báo thanh toán), và đó là tính năng của CloudWatch Alarms dựa trên chỉ số EstimatedCharges.

Cách làm: bật Receive Billing Alerts trong phần Billing preferences, rồi tạo một CloudWatch alarm trên chỉ số đó với ngưỡng bạn muốn. Alarm kích hoạt thì gửi thông báo qua SNS.

Một chi tiết vận hành rất hay gây bối rối: chỉ số thanh toán chỉ nằm ở Region us-east-1, bất kể tài nguyên của bạn ở đâu. Không chuyển Console sang Region đó thì bạn sẽ tìm mãi không thấy chỉ số nào.

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

• B. AWS Cost Explorer — phân tích và trực quan hoá chi phí; nó không gửi cảnh báo.
• C. AWS CloudTrail — ghi lại lời gọi API, không liên quan tới chi phí.
• D. AWS Organizations — quản lý nhiều tài khoản và thanh toán hợp nhất.

Lưu ý về hai cách làm

AWS Budgets cũng cảnh báo chi phí và linh hoạt hơn (đặt được ngân sách theo dịch vụ, theo thẻ, theo tài khoản, và cảnh báo cả trên chi phí dự báo). Nhưng câu hỏi dùng đúng thuật ngữ "billing alarm", vốn là tên gọi của cơ chế bên CloudWatch.

Đáp án

B — Amazon EC2 instance user data

Vì sao đúng

User data là nơi bạn đặt script chạy tự động khi instance khởi động lần đầu — thường gọi là bootstrap script.

Ví dụ điển hình:

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd

Ba điều đáng nhớ về user data:

• Chạy với quyền root, mặc định chỉ chạy một lần khi khởi động đầu tiên.
• Nội dung xem lại được qua dịch vụ metadata tại http://169.254.169.254/latest/user-data.
• Không lưu bí mật ở đây — bất kỳ ai truy cập được instance đều đọc được. Bí mật thuộc về Secrets Manager hoặc Parameter Store.

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

• A. Instance metadata — dữ liệu về chính instance (ID, loại máy, địa chỉ IP, IAM role); bạn đọc nó chứ không chạy nó. Đây là phương án nhiễu chính, và cặp này rất dễ lẫn:

  	User data	Instance metadata
  Là gì	Script bạn cung cấp	Thông tin về instance
  Hướng	Bạn ghi vào	Bạn đọc ra

• C. "AMI data" và D. "Configuration data" — không tồn tại với tư cách khái niệm của EC2.

Đáp án

D — Massive economies of scale (quy mô kinh tế khổng lồ)

Vì sao đúng

Đề mô tả đúng cơ chế của lợi thế này: nhu cầu của hàng trăm nghìn khách hàng được gộp lại trên đám mây, nên AWS mua phần cứng, điện và băng thông ở quy mô mà không tổ chức đơn lẻ nào đạt được — và chuyển phần tiết kiệm đó vào giá trả theo mức dùng.

Bằng chứng thực tế: AWS đã giảm giá hơn 100 lần kể từ khi ra mắt, và phần lớn các đợt giảm giá đó đến từ chính hiệu ứng quy mô.

Sáu lợi thế của điện toán đám mây

1. Đổi chi phí đầu tư cố định lấy chi phí biến đổi
2. Hưởng lợi từ quy mô kinh tế khổng lồ
3. Ngừng đoán năng lực hạ tầng
4. Tăng tốc độ và tính linh hoạt
5. Ngừng chi tiền vận hành trung tâm dữ liệu
6. Vươn ra toàn cầu trong vài phút

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

Ba phương án còn lại đều là lợi thế thật nhưng cơ chế khác:

• A. Đổi chi phí đầu tư cố định lấy chi phí biến đổi — nói về cách trả tiền, không nói về vì sao đơn giá thấp. Đây là phương án nhiễu chính.
• B. Tăng tốc độ và tính linh hoạt — nói về tốc độ phát triển.
• C. Vươn ra toàn cầu trong vài phút — nói về phạm vi địa lý.

Đáp án

C và E — cho phép truy cập công khai vào bucket S3, và chưa bật ghi nhật ký hoạt động người dùng (CloudTrail)

Vì sao đúng

Cả hai đều là kiểm tra có thật trong hạng mục bảo mật của Trusted Advisor:

• C. Bucket S3 mở công khai — đây là một trong những nguyên nhân rò rỉ dữ liệu phổ biến nhất trên đám mây; Trusted Advisor rà mọi bucket và cảnh báo cái nào đang cho phép đọc hoặc ghi công khai.
• E. Chưa bật CloudTrail — không có nhật ký hoạt động thì khi có sự cố bạn không truy vết được gì; đây là kiểm tra cơ bản về khả năng kiểm toán.

Vài kiểm tra bảo mật khác của Trusted Advisor: security group mở cổng nhạy cảm ra 0.0.0.0/0, tài khoản root chưa bật MFA, khoá truy cập IAM chưa xoay vòng, chứng chỉ ACM sắp hết hạn.

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

• A. Khi bạn chia sẻ thông tin đăng nhập IAM với người khác — Trusted Advisor không thể biết điều này; chia sẻ mật khẩu là hành vi diễn ra ngoài AWS.
• B. Khi bạn không bật mã hoá dữ liệu trên S3 Glacier — dữ liệu trên Glacier luôn được mã hoá mặc định, nên không có gì để cảnh báo.
• D. Khi bạn không gắn thẻ cho đối tượng trong bucket S3 — thẻ là chuyện quản lý chi phí và tổ chức, không phải cấu hình sai về bảo mật.

Đáp án

C và D — khả năng chịu lỗi và tính sẵn sàng cao

Vì sao đúng

Cả hai lợi ích đều đến từ cùng một cơ chế: ELB liên tục kiểm tra sức khoẻ của từng đích và chỉ gửi lưu lượng tới đích khoẻ.

• C. Khả năng chịu lỗi — một instance chết thì ELB ngừng gửi lưu lượng tới nó; người dùng không nhận ra gì.
• D. Tính sẵn sàng cao — ELB phân phối lưu lượng qua nhiều Availability Zone, nên mất trọn một AZ thì các AZ còn lại vẫn phục vụ. Bản thân ELB cũng chạy dư thừa trên nhiều AZ.

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

• E. Ít tốn kém hơn — ELB tính phí riêng (theo giờ và theo đơn vị năng lực sử dụng); nó là chi phí thêm vào, không phải cách tiết kiệm. Đây là phương án nhiễu chính vì người ta hay gộp ELB với Auto Scaling và nghĩ tới tiết kiệm — nhưng tiết kiệm là công của Auto Scaling.
• A. Agility (tính linh hoạt) — nói về tốc độ phát triển và ra mắt sản phẩm; ELB không tác động tới điều đó.
• B. Storage (lưu trữ) — ELB là dịch vụ mạng, không lưu trữ gì.

Đáp án

C — Theo dõi thay đổi cấu hình — đây là việc Amazon Inspector KHÔNG làm

Vì sao đây là câu trả lời

Theo dõi thay đổi cấu hình theo thời gian là chức năng của AWS Config, không phải Inspector.

Hai dịch vụ nhìn vào hai thứ khác nhau:

Vì sao các phương án khác đều là việc Inspector làm

• A. Quét hệ điều hành đang chạy để tìm lỗ hổng đã biết — đối chiếu phần mềm đã cài với cơ sở dữ liệu CVE.
• B. Phân tích khả năng tiếp cận mạng ngoài ý muốn — xét qua toàn bộ security group, NACL, bảng định tuyến và gateway để tìm cổng đang phơi ra Internet.
• D. Tự động hoá việc đánh giá bảo mật — quét liên tục và tự động; tài nguyên mới là tự đưa vào diện quét.

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