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

Đáp án

A — Dùng AWS KMS để mã hoá dữ liệu

Vì sao đúng

Trụ Security của Well-Architected Framework có một nguyên tắc là bảo vệ dữ liệu khi lưu và khi truyền, và KMS là dịch vụ chính để làm điều đó trên AWS.

KMS tích hợp sẵn với hầu hết dịch vụ AWS, nên bật mã hoá thường chỉ là một ô tích khi tạo tài nguyên — S3, EBS, RDS, DynamoDB, Lambda đều vậy.

Năm lĩnh vực của trụ Security: quản lý danh tính và truy cập, kiểm soát phát hiện, bảo vệ hạ tầng, bảo vệ dữ liệu, và ứng phó sự cố.

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

Ba phương án còn lại đều dùng dịch vụ có thật nhưng gán cho mục đích thuộc trụ khác:

• C. Dùng CloudFormation để tự động hoá thực hành tốt về bảo mật — CloudFormation thực sự hữu ích cho bảo mật, nhưng nguyên tắc "tự động hoá" thuộc trụ Operational Excellence. Đây là phương án nhiễu tinh vi nhất.
• B. Dùng CloudWatch để đo hiệu quả tổng thể — thuộc trụ Performance Efficiency.
• D. Dùng Cost Explorer để xem và theo dõi mức sử dụng — thuộc trụ Cost Optimization.

Đáp án

C và D — 1 năm và 3 năm

Vì sao đúng

Reserved Instance chỉ có hai kỳ hạn: 1 năm và 3 năm. Không có lựa chọn nào khác.

Kỳ hạn dài hơn cho mức giảm giá cao hơn:

Điểm đáng nhớ: yếu tố kỳ hạn quan trọng hơn yếu tố trả trước. RI 3 năm không trả trước đồng nào vẫn rẻ hơn RI 1 năm trả trước toàn bộ.

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

• E. 6 tháng, B. 2 năm, A. 5 năm — cả ba đều không tồn tại. Chúng là những con số nghe hợp lý được đưa vào làm nhiễu.

Lưu ý về Savings Plans

Savings Plans cũng chỉ có kỳ hạn 1 năm và 3 năm, nhưng linh hoạt hơn RI: bạn cam kết một mức chi tiêu mỗi giờ thay vì cam kết một loại instance cụ thể.

Đáp án

D — Amazon S3 Lifecycle configuration

Vì sao đúng

Lifecycle configuration cho phép khai tập luật tự động chuyển đối tượng giữa các lớp lưu trữ theo tuổi, hoặc xoá hẳn chúng — đúng mô tả trong đề.

Ví dụ một chính sách vòng đời điển hình:

Ngày 0–30    : S3 Standard              (truy cập thường xuyên)
Ngày 31–90   : S3 Standard-IA           (ít truy cập, vẫn lấy ngay được)
Ngày 91–365  : S3 Glacier Flexible      (lưu trữ dài hạn)
Sau 365 ngày : S3 Glacier Deep Archive  (rẻ nhất)
Sau 7 năm    : Xoá

Quy tắc chạy tự động và không mất phí, nên chi phí lưu trữ giảm dần theo tuổi dữ liệu mà không ai phải nhớ làm gì.

Lifecycle cũng dọn được hai nguồn tốn kém âm thầm: các phiên bản cũ khi bật versioning, và phần tải lên dở dang chưa hoàn tất.

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

• C. Bucket Policies — kiểm soát ai được truy cập, không liên quan tới lớp lưu trữ.
• A. S3 Transfer Acceleration — tăng tốc việc tải lên qua mạng biên.
• B. S3 Cross-Region Replication — nhân bản dữ liệu sang Region khác.

Đáp án

A và B — bảo mật trung tâm dữ liệu, và vận hành mạng

Vì sao đúng

Cả hai đều thuộc phần "bảo mật CỦA đám mây" — hạ tầng vật lý mà AWS xây và vận hành:

• A. Bảo mật trung tâm dữ liệu — an ninh vật lý, kiểm soát ra vào, camera, hệ thống chống cháy.
• B. Vận hành mạng — thiết bị định tuyến, chuyển mạch, đường trục nối các trung tâm dữ liệu và Region.

Đây cũng là phần khách hàng không nhìn thấy và không chạm tới được.

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

Ba phương án còn lại đều thuộc "bảo mật TRONG đám mây" — trách nhiệm của khách hàng:

• C. Mã hoá dữ liệu ứng dụng — AWS cung cấp công cụ (KMS, CloudHSM), nhưng quyết định bật mã hoá và chọn khoá là của bạn.
• D. Cài bản vá bảo mật cho hệ điều hành khách — với EC2, mọi thứ bên trong instance là của bạn.
• E. Cấu hình IAM Role — quản lý truy cập luôn thuộc về khách hàng.

Ba thứ luôn thuộc về khách hàng

Dữ liệu, quản lý truy cập (IAM), và quyết định mã hoá — ở mọi dịch vụ, không có ngoại lệ.

Đáp án

C và E — quản lý cấu hình, và cấu hình hệ điều hành

Vì sao đúng

Mô hình trách nhiệm chung của AWS có một nhóm nằm ở giữa — trách nhiệm được chia sẻ — và cả hai phương án đúng thuộc nhóm đó:

Điểm chung của nhóm chia sẻ: ranh giới dịch chuyển theo loại dịch vụ. Với EC2 thì khách hàng lo hệ điều hành; với Lambda thì AWS lo.

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

• D. Bảo mật trung tâm dữ liệu và A. Tiêu huỷ ổ đĩa — thuộc hoàn toàn về AWS; khách hàng không có phần nào.
• B. Dữ liệu khách hàng — thuộc hoàn toàn về khách hàng; AWS không đụng tới.

Đáp án

B — AWS Systems Manager

Vì sao đúng

Chữ khoá của đề là "operational insights" (hiểu biết về vận hành) để nhanh chóng phát hiện vấn đề ảnh hưởng tới ứng dụng. Đó là mô tả của Systems Manager Explorer và OpsCenter:

• Explorer — bảng điều khiển vận hành tổng hợp, gom dữ liệu từ nhiều dịch vụ và nhiều tài khoản về một chỗ: instance chưa tuân thủ chuẩn vá, tài nguyên chưa gắn thẻ, sự kiện đang mở.
• OpsCenter — nơi tập trung các mục việc vận hành (OpsItem), kèm ngữ cảnh và các bước xử lý được đề xuất, nên đội vận hành không phải đi tìm thông tin ở năm chỗ khác nhau.

Systems Manager cũng phủ luôn phần hành động: chạy lệnh, vá lỗi, quản lý cấu hình.

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

• D. AWS Trusted Advisor — đưa khuyến nghị theo thực hành tốt, không phải công cụ vận hành hằng ngày. Đây là phương án nhiễu chính.
• A. AWS Health Dashboard — Your Account Health — báo sự cố phía AWS ảnh hưởng tới tài nguyên của bạn; nó không nói gì về vấn đề do chính cấu hình của bạn gây ra.
• C. Amazon Inspector — quét lỗ hổng bảo mật.

Đáp án

B — AWS CloudFormation

Vì sao đúng

Đề nêu ba yêu cầu, và CloudFormation đáp ứng cả ba:

• Dùng mẫu (template) — mô tả hạ tầng bằng YAML hoặc JSON.
• Triển khai giống nhau ở mọi Region và tài khoản — tính năng StackSets đẩy cùng một mẫu ra hàng loạt tài khoản và Region trong một thao tác.
• Ước tính chi phí — CloudFormation có thao tác EstimateTemplateCost, trả về một liên kết tới AWS Pricing Calculator đã điền sẵn các tài nguyên trong mẫu.

Vế cuối là chi tiết ít người biết, và nó chính là chỗ câu hỏi phân biệt CloudFormation với các công cụ triển khai khác.

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

• C. AWS CodeDeploy — triển khai mã ứng dụng lên máy chủ, không tạo hạ tầng.
• D. Amazon Lightsail — máy chủ ảo đơn giản hoá; không có khái niệm mẫu hạ tầng đa tài khoản.
• A. AWS Managed Microsoft AD — dịch vụ thư mục, hoàn toàn không liên quan.

Đáp án

A và C — ngừng đoán năng lực, và tăng tốc độ cùng tính linh hoạt

Vì sao đúng

Cả hai đều nằm trong danh sách sáu lợi thế của điện toán đám mây mà AWS công bố:

• A. Ngừng đoán năng lực hạ tầng — trước đây bạn phải ước lượng nhu cầu cho vài năm tới: đoán thấp thì hệ thống sập lúc cao điểm, đoán cao thì lãng phí. Trên đám mây, tăng giảm trong vài phút.
• C. Tăng tốc độ và tính linh hoạt — tài nguyên mới có trong vài phút thay vì vài tuần, nên chi phí thử nghiệm gần bằng không.

Sáu lợi thế đầ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

• B. Đổi chi phí vận hành lấy chi phí đầu tư cố định — đảo ngược lợi thế số 1; đám mây làm điều ngược lại.
• D. Khả năng mở rộng bị giới hạn — sai hoàn toàn; mở rộng gần như không giới hạn.
• E. AWS chịu trách nhiệm bảo mật TRONG đám mây — sai giới từ: AWS chịu trách nhiệm bảo mật CỦA đám mây, còn TRONG là của khách hàng. Đây là phương án nhiễu tinh vi nhất.

Đáp án

C — Amazon CodeGuru

Vì sao đúng

CodeGuru dùng học máy để tự động rà soát mã, và nó có hai phần:

• CodeGuru Reviewer — quét mã trong pull request, phát hiện lỗi tiềm ẩn, rò rỉ tài nguyên, vấn đề đồng thời, lỗ hổng bảo mật, và chỗ chưa theo thực hành tốt. Nó bình luận thẳng vào pull request như một người rà soát.
• CodeGuru Profiler — phân tích ứng dụng đang chạy để tìm điểm nghẽn hiệu năng và dòng mã tốn kém nhất, kèm ước tính chi phí tiết kiệm được nếu sửa.

Với đội quản lý 300 microservice, giá trị nằm ở chỗ nó rà nhất quán và không mệt — điều mà việc rà soát thủ công ở quy mô đó không bảo đảm được.

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

• B. AWS CodeBuild — biên dịch và chạy kiểm thử; nó chạy được công cụ phân tích tĩnh nếu bạn tự cấu hình, nhưng bản thân không rà soát mã. Đây là phương án nhiễu chính.
• D. AWS X-Ray — theo dấu yêu cầu qua các dịch vụ để gỡ lỗi hiệu năng; nó nhìn hành vi lúc chạy, không đọc mã nguồn.
• A. AWS Trusted Advisor — khuyến nghị về tài nguyên AWS, không liên quan tới mã.

Đáp án

A — Tạo thẻ (tag) cho từng phòng ban

Vì sao đúng

Chữ khoá của đề là "cách đơn giản nhất", và thẻ là cơ chế nhẹ nhất để phân bổ chi phí.

Cách làm: gắn thẻ Department=Marketing (hoặc tương tự) lên mọi tài nguyên, kích hoạt thẻ đó trong phần Billing, rồi xem chi phí tách theo thẻ trong Cost Explorer hoặc báo cáo phân bổ chi phí.

Ba lý do nó đơn giản nhất: không đổi kiến trúc, không tạo tài khoản mới, và áp được ngay cho tài nguyên đang có.

Một bước rất hay bị quên: thẻ phải được kích hoạt trong Billing preferences mới xuất hiện trong báo cáo, và việc kích hoạt không có hiệu lực hồi tố.

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

• D. Tạo tài khoản riêng cho từng phòng ban — cho kết quả tốt hơn (cách ly hoàn toàn, hoá đơn riêng), nhưng phức tạp hơn nhiều: phải dựng lại hạ tầng, quản lý nhiều tài khoản, thiết lập Organizations. Đề hỏi cách đơn giản nhất. Đây là phương án nhiễu chính.
• B. Tạo VPC riêng cho từng phòng ban — VPC là ranh giới mạng, không phải ranh giới chi phí; hoá đơn không tách theo VPC.
• C. Dùng chung một tài khoản cho mọi phòng ban — đó chính là tình trạng hiện tại, không giải quyết gì.