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

Đáp án

C và E — AWS Lambda và AWS Fargate

Vì sao đúng

Cả hai đều là dịch vụ tính toán không máy chủ: bạn không cấp phát, không quản lý và không thấy máy chủ nào.

Cả hai đều tự co giãn từ 0, nên không dùng thì không tốn gì.

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

Ba phương án còn lại đều có máy chủ mà bạn nhìn thấy và trả tiền:

• B. AWS Elastic Beanstalk — quản lý hộ việc cấp phát, nhưng bạn vẫn thấy và trả tiền cho EC2 instance bên dưới. Đây là phương án nhiễu chính, và ranh giới cần nhớ là được quản lý khác không máy chủ.
• A. Amazon EC2 — máy chủ ảo, tức là điều ngược lại.
• D. Amazon Lightsail — máy chủ ảo đơn giản hoá với giá gói cố định.

Đáp án

C — Application Load Balancer (ALB)

Vì sao đúng

ALB hoạt động ở tầng 7 (tầng ứng dụng), nên nó hiểu nội dung của yêu cầu HTTP và HTTPS. Đó là điều cho phép nó làm những việc mà bộ cân bằng tải tầng thấp hơn không làm được:

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

• A. Network Load Balancer — hoạt động ở tầng 4; nó nhanh hơn (hàng triệu yêu cầu mỗi giây, độ trễ cực thấp) và giữ được IP tĩnh, nhưng không đọc được nội dung HTTP nên không định tuyến theo đường dẫn hay host. Nó hợp cho TCP, UDP và TLS passthrough. Đây là phương án nhiễu chính.
• B. AWS Auto Scaling — thay đổi số lượng tài nguyên, không phân phối lưu lượng.
• D. "System Load Balancer" — không tồn tại; AWS có ALB, NLB, Gateway Load Balancer và Classic Load Balancer.

Đáp án

A — Dùng Amazon S3 Block Public Access

Vì sao đúng

Block Public Access là tính năng có sẵn của S3, và nó là biện pháp hiệu quả nhất cho yêu cầu này vì hoạt động ở tầng chặn tuyệt đối:

• Áp ở mức tài khoản hoặc mức bucket — bật một lần, phủ mọi đối tượng hiện có và mọi đối tượng sẽ tải lên sau này.
• Ghi đè mọi cấu hình khác — dù ai đó vô tình đặt ACL hoặc bucket policy cho phép công khai, Block Public Access vẫn chặn. Đây là điểm quan trọng nhất: nó không thể bị vô hiệu bởi sai sót ở tầng dưới.
• Không tốn gì và không có độ trễ.

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

• B. Kích hoạt Lambda mỗi khi có đối tượng được tải lên để sửa lại thiết lập — hoạt động được nhưng là biện pháp phản ứng: có một khoảng thời gian đối tượng đang công khai trước khi Lambda kịp chạy. Với dữ liệu khách hàng thì khoảng đó là một sự cố rò rỉ. Nó cũng tốn tiền và phải bảo trì. Đây là phương án nhiễu chính.
• C. Dùng Amazon CloudWatch — giám sát và cảnh báo; nó phát hiện sau khi đã xảy ra, không ngăn chặn.
• D. Lập một hội đồng cấp cao để rà soát thiết lập của từng đối tượng — không thể mở rộng và hoàn toàn phụ thuộc vào con người.

Đáp án

B và D

Vì sao đúng

• D. Lambda chạy mã để phản ứng với sự kiện, ví dụ khi bảng DynamoDB được cập nhật — đúng, và đây là mô hình dùng cốt lõi của Lambda. Nó tích hợp sẵn với hàng chục nguồn sự kiện: DynamoDB Streams, S3, SQS, SNS, API Gateway, EventBridge, Kinesis.
• B. Lambda dùng để tiền xử lý dữ liệu trước khi lưu vào S3 — đúng: làm sạch, biến đổi, kiểm tra hoặc làm giàu dữ liệu trước khi ghi.

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

Ba phương án còn lại đều gán cho Lambda những khả năng trái với bản chất serverless:

• C. Cài cơ sở dữ liệu độ trễ thấp lên Lambda — không được: Lambda không giữ trạng thái, mỗi lần gọi có thể chạy trên môi trường mới, và môi trường bị huỷ sau khi rảnh một thời gian.
• E. Cài Container Services lên Lambda — Lambda hỗ trợ đóng gói hàm bằng image container, nhưng đó khác hẳn việc chạy dịch vụ container; điều phối container là việc của ECS hoặc EKS.
• A. Lambda dùng để lưu các biến môi trường nhạy cảm — Lambda có biến môi trường, nhưng nó không phải nơi lưu bí mật. Bí mật nên để trong AWS Secrets Manager hoặc Systems Manager Parameter Store, rồi hàm đọc ra lúc chạy. Đây là phương án nhiễu tinh vi nhất vì nửa đầu đúng.

Đáp án

A và D — Amazon CloudFront và Amazon EC2

Vì sao đúng

Shield Advanced bảo vệ mở rộng cho các tài nguyên có thể là mục tiêu trực tiếp của tấn công DDoS — tức là những thứ có điểm cuối mạng công khai:

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

• C. Amazon S3 — là dịch vụ được quản lý với năng lực hấp thụ khổng lồ; AWS bảo vệ nó ở tầng hạ tầng, và bạn không khai nó làm tài nguyên được bảo vệ trong Shield Advanced. Đây là phương án nhiễu chính.
• B. AWS IAM — dịch vụ lớp điều khiển, không có điểm cuối phục vụ lưu lượng người dùng.
• E. AWS Elastic Beanstalk — không phải một loại tài nguyên riêng; nó tạo ra EC2 và ELB, và chính những thứ đó mới được bảo vệ.

Ghi nhớ

Shield Standard bảo vệ mọi khách hàng, miễn phí, tự động cho CloudFront, Route 53, ELB và Global Accelerator. Shield Advanced là thuê bao riêng, thêm bảo vệ tầng 7, đội ứng phó DDoS, và bảo vệ chi phí khi bị tấn công.

Đáp án

C — Amazon EC2 Auto Scaling

Vì sao đúng

Auto Scaling theo dõi nhu cầu thực tế và tự thay đổi số lượng instance cho khớp:

• Nhu cầu tăng → scale out, thêm instance.
• Nhu cầu giảm → scale in, bớt instance để khỏi trả tiền thừa.

Nó cũng thay thế instance hỏng: nếu một máy không qua được kiểm tra sức khoẻ, Auto Scaling huỷ nó và tạo máy mới — nên số lượng máy khoẻ luôn được giữ đúng mức.

Ba kiểu chính sách co giãn: target tracking (giữ CPU quanh 50% chẳng hạn), step scaling (theo ngưỡng), và scheduled scaling (theo lịch, cho tải đoán trước được).

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

• B. Application Load Balancer và D. Network Load Balancer — phân phối lưu lượng cho các máy đang có; chúng không thay đổi số lượng máy. ELB và Auto Scaling gần như luôn dùng chung nhưng làm hai việc khác nhau:

  	ELB	Auto Scaling
  Câu hỏi	"Yêu cầu này gửi tới máy nào?"	"Cần bao nhiêu máy?"

• A. Triển khai Multi-AZ — tăng tính sẵn sàng bằng cách trải tài nguyên qua nhiều AZ; nó không điều chỉnh năng lực theo tải.

Đáp án

A — Amazon Simple Storage Service (S3)

Vì sao đúng

S3 Lifecycle configuration cho phép khai quy tắc tự động chuyển đối tượng sang lớp lưu trữ rẻ hơn theo tuổi, hoặc xoá hẳn chúng.

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á

Điều làm nó hiệu quả: 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 quản lý được các phiên bản cũ khi bật versioning, và dọn phần tải lên dở dang — hai nguồn tốn chi phí âm thầm rất hay bị bỏ quên.

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

• B. Amazon EBS — có Data Lifecycle Manager để tự động hoá việc tạo và xoá snapshot, nhưng đó là quản lý bản sao lưu, không phải chuyển volume sang lớp rẻ hơn. Đây là phương án nhiễu chính.
• C. Instance Store — lưu trữ tạm, không có khái niệm vòng đời.
• D. AWS Storage Gateway — cầu nối tới lưu trữ đám mây; dữ liệu nó đẩy lên S3 thì được áp lifecycle, nhưng bản thân gateway không có tính năng đó.

Đáp án

A và E

Vì sao đúng

• *A. S3 lưu dữ liệu theo cấu trúc phẳng, không phân cấp — đúng, và đây là điều dễ hiểu nhầm nhất về S3. Console hiển thị "thư mục", nhưng thực chất mỗi đối tượng chỉ có một khoá là chuỗi ký tự:

  Khoá: "anh/2024/thang-3/logo.png"
  

  Dấu / chỉ là ký tự trong tên, không tạo ra thư mục thật nào. Console dùng nó làm tiền tố để vẽ giao diện dạng cây cho dễ nhìn.

• *E. S3 là dịch vụ lưu trữ đối tượng dựa trên khoá–giá trị — đúng: khoá là đường dẫn, giá trị là nội dung tệp, kèm siêu dữ liệu.

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

• *B. S3 là dịch vụ lưu trữ khối — sai; lưu trữ khối là EBS và Instance Store.
• D. S3 là hệ thống tệp đàn hồi được quản lý — sai; đó là mô tả của EFS.
• C. Cài được cơ sở dữ liệu lên S3 — sai: S3 truy cập qua API HTTP, không mount như ổ đĩa, và đối tượng thì bất biến (sửa nghĩa là ghi đè toàn bộ). Cơ sở dữ liệu cần đọc ghi ngẫu nhiên ở mức khối, nên cần EBS.

Đáp án

B — Vá hạ tầng mạng (networking infrastructure)

Vì sao đúng

Hạ tầng mạng nền — bộ định tuyến, bộ chuyển mạch, đường trục kết nối các trung tâm dữ liệu và Region — thuộc trọn vẹn phần "bảo mật CỦA đám mây".

Đây cũng là phần khách hàng không nhìn thấy và không chạm tới được: bạn làm việc với mạng ảo (VPC, subnet, security group), còn thiết bị vật lý bên dưới do AWS vận hành.

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:

• A. Vá hệ điều hành khách và ứng dụng — với EC2, mọi thứ bên trong instance là của bạn. Đây là phương án nhiễu chính vì cả hai đều có chữ "vá".
• D. Quản lý danh tính và truy cập (IAM) — quản lý truy cập luôn thuộc về khách hàng ở mọi dịch vụ, không có ngoại lệ.
• C. Bảo vệ dịch vụ và truyền thông — nghĩa là cấu hình security group, NACL, mã hoá đường truyền; đều là việc của bạn.

Cách phân biệt nhanh

Hỏi: tôi có nút nào để bấm không? Nếu có thứ để bạn cấu hình, bật tắt hay làm sai, đó là trách nhiệm của bạn. Thiết bị mạng vật lý thì không có nút nào cho bạn.

Đáp án

B và C — Amazon SNS và Amazon CloudWatch

Vì sao đúng

Hai dịch vụ ghép thành mẫu cảnh báo chuẩn, và không cần viết mã nào:

Root user đăng nhập
   ▼  CloudTrail ghi lại sự kiện
CloudWatch Logs  ──metric filter tìm "AwsConsoleSignIn" của root──▶ chỉ số tuỳ chỉnh
   ▼  cảnh báo khi chỉ số > 0
CloudWatch Alarm
   ▼
Amazon SNS  →  email hoặc tin nhắn tới đội bảo mật

• C. CloudWatch — dùng metric filter trên log của CloudTrail để phát hiện sự kiện, rồi tạo cảnh báo.
• B. SNS — nhận thông điệp từ cảnh báo và gửi thông báo.

Đây là một trong những cảnh báo được khuyến nghị mạnh nhất trên AWS: root user có quyền không giới hạn, nên mọi lần nó đăng nhập đều đáng được biết ngay.

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

• E. AWS Lambda — dùng được nếu cần xử lý phức tạp khi có cảnh báo (ví dụ tự động thu hồi phiên), nhưng để gửi thông báo thì SNS làm thẳng được.
• A. Amazon SQS — hàng đợi theo mô hình kéo: người nhận phải chủ động lấy. Gửi cảnh báo cần mô hình đẩy, tức là SNS.
• D. AWS Step Functions — điều phối quy trình nhiều bước; thừa cho việc này.