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

Đáp án

*D — Security group là tường lửa ở mức instance, network ACL là tường lửa ở mức subnet

Vì sao đúng

Hai lớp lọc hoạt động ở hai tầng khác nhau, và đây là kiến trúc phòng thủ nhiều lớp của VPC:

Subnet  ← NETWORK ACL lọc ở biên subnet (mọi thứ ra vào subnet)
 └── EC2 instance  ← SECURITY GROUP lọc ở network interface

Ngoài chỗ gắn, chúng còn khác nhau ở ba điểm quan trọng:

Dòng "trạng thái" là nguồn gốc của rất nhiều lỗi khó chẩn đoán: NACL cho vào mà quên cho ra thì kết nối vẫn hỏng, dù nhìn luật thấy có vẻ đúng.

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

• A — đảo ngược hai mức; đây là phương án nhiễu chính.
• B và C — đặt chúng ở mức Availability Zone hoặc VPC; không có lớp lọc nào hoạt động ở hai mức đó.

Đáp án

A và C — AWS IAM và AWS Auto Scaling

Vì sao đúng

Cả hai đều là dịch vụ luôn miễn phí:

• A. AWS IAM — quản lý người dùng, vai, nhóm và chính sách; không tính phí ở bất kỳ quy mô nào. Điều này có chủ đích: AWS không muốn chi phí trở thành lý do khiến ai đó bỏ qua bảo mật.
• C. AWS Auto Scaling — bản thân dịch vụ miễn phí; bạn chỉ trả tiền cho tài nguyên mà nó tạo ra.

Điểm chung của hai cái: chúng là lớp điều khiển, không phải tài nguyên tiêu thụ.

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

Ba phương án còn lại đều là dịch vụ tính phí, dù có bậc miễn phí:

• B. DynamoDB, D. S3, E. EC2 — đều có AWS Free Tier với hạn mức nhất định trong 12 tháng đầu (hoặc mãi mãi ở mức nhỏ), nhưng vượt hạn mức là tính tiền.

Đây là chỗ dễ nhầm: "có bậc miễn phí" khác "luôn miễn phí".

Vài dịch vụ luôn miễn phí khác

IAM, Auto Scaling, CloudFormation, Elastic Beanstalk, OpsWorks, VPC, Consolidated Billing — bạn chỉ trả cho tài nguyên bên dưới mà chúng tạo ra.

Đáp án

A và B

Vì sao đúng

• A. Thông tin đăng nhập của root user là địa chỉ email và mật khẩu dùng để tạo tài khoản AWS — đúng; root user được sinh ra cùng lúc với tài khoản và danh tính của nó chính là email đó.
• B. Rất nên bật xác thực đa yếu tố (MFA) cho root user — đúng, và đây là khuyến nghị bảo mật quan trọng nhất với AWS. Root user có quyền không giới hạn, nên nếu mật khẩu bị lộ mà không có MFA thì kẻ tấn công kiểm soát trọn tài khoản.

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

• E. Root user có quyền không giới hạn khi tạo tài khoản, nhưng có thể hạn chế bằng chính sách IAM — sai và là điểm quan trọng: chính sách IAM không áp được cho root user. Cách duy nhất giới hạn nó là Service Control Policy trong AWS Organizations. Đây là phương án nhiễu chính.
• D. Chỉ nên chia sẻ thông tin root với các quản lý cần trách nhiệm quản trị — sai; không bao giờ chia sẻ thông tin root. Ai cần quyền quản trị thì cấp IAM user với chính sách phù hợp.
• C. Mật khẩu root không đổi được sau khi đã đặt — sai; đổi được bất cứ lúc nào.

Thực hành tốt với root user

Sau khi tạo tài khoản: bật MFA, tạo một IAM user quản trị để dùng hằng ngày, xoá mọi khoá truy cập của root, rồi khoá thông tin root lại và chỉ dùng cho vài thao tác bắt buộc (đổi gói hỗ trợ, đóng tài khoản).

Đáp án

C — Amazon Elastic Container Registry (ECR)

Vì sao đúng

ECR là kho lưu trữ image container được quản lý của AWS. Nó làm đúng ba việc đề nêu: lưu trữ, quản lý (phiên bản, quét lỗ hổng, chính sách vòng đời) và triển khai image tới các dịch vụ chạy container.

Ba đặc điểm đáng chú ý: image được mã hoá khi lưu, phân quyền bằng chính sách IAM, và ECR tự quét lỗ hổng trong image mỗi khi bạn đẩy phiên bản mới.

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

• B. Amazon ECS — chạy container; nó lấy image từ ECR. Hai dịch vụ nối tiếp nhau, và đây là phương án nhiễu chính:

  	ECR	ECS
  Làm gì	Lưu image	Chạy container từ image
  Tương đương	Docker Hub riêng của bạn	Bộ điều phối container

• A. Amazon EC2 — máy chủ ảo; nó có thể chạy Docker nhưng không phải kho image.

• D. AWS Lambda — chạy hàm; nó hỗ trợ đóng gói bằng image container, nhưng image đó vẫn phải nằm trong ECR.

Đáp án

A — Amazon Rekognition

Vì sao đúng

Rekognition là phần mềm dùng ngay: bạn gọi API, gửi ảnh vào, nhận kết quả phân tích. Bạn không quản lý gì cả — không hạ tầng, không mô hình, không huấn luyện. Đó là mô tả của SaaS.

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

• C. Amazon EC2 — IaaS điển hình: bạn chọn hệ điều hành, cài phần mềm, tự vá lỗi.
• D. AWS Elastic Beanstalk — PaaS: bạn tải mã lên, AWS lo triển khai, nhưng bạn vẫn thấy và chỉnh được EC2 bên dưới.
• B. Elastic Load Balancing — thành phần hạ tầng bạn cấu hình và tích hợp, không phải phần mềm dùng ngay.

Ghi nhớ

Các dịch vụ AI dựng sẵn của AWS — Rekognition, Comprehend, Polly, Transcribe, Translate, Textract — đều thuộc nhóm SaaS: gọi API là có kết quả, không có gì để quản lý.

Đáp án

B — Amazon Elastic Compute Cloud (EC2)

Vì sao đúng

Đề nêu ba đặc điểm, và chỉ EC2 có đủ cả ba:

• Năng lực tính toán thay đổi được — đổi loại instance, tăng giảm số lượng bất cứ lúc nào.
• Tính tiền theo giây — với Linux, tối thiểu 60 giây.
• Truy cập được hệ điều hành bên dưới — SSH vào, cài gì cũng được, toàn quyền quản trị.

Vế cuối là điểm phân biệt quyết định trong câu này.

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

• D. Amazon Lightsail — cũng cho truy cập hệ điều hành, nhưng tính tiền theo gói cố định hằng tháng chứ không theo giây, và năng lực kém linh hoạt hơn (chọn trong vài gói dựng sẵn). Đây là phương án nhiễu chính vì Lightsail nổi tiếng là "dễ nhất".
• A. AWS Lambda — không cho truy cập hệ điều hành; bạn chỉ viết hàm.
• C. Amazon ECS — chạy container; với launch type Fargate thì không có hệ điều hành nào để truy cập, còn với EC2 launch type thì bạn quản lý EC2 chứ ECS không phải dịch vụ tính toán trực tiếp.

Đáp án

A — Amazon MQ

Vì sao đúng

Chi tiết quyết định trong đề: công ty đã dùng message broker tại chỗ và muốn chuyển sang AWS dễ dàng nhất.

Amazon MQ là dịch vụ được quản lý cho Apache ActiveMQ và RabbitMQ — hai broker phổ biến nhất trong doanh nghiệp. Điểm mấu chốt: nó hỗ trợ các giao thức chuẩn của ngành như JMS, AMQP, MQTT, STOMP, OpenWire.

Nhờ đó ứng dụng hiện có kết nối được mà gần như không phải sửa mã — chỉ đổi địa chỉ endpoint.

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

• D. Amazon SQS — hàng đợi thông điệp rất tốt và rẻ hơn, nhưng nó dùng API riêng của AWS, không hỗ trợ JMS hay AMQP. Chuyển sang SQS nghĩa là viết lại phần messaging của ứng dụng. Đây là phương án nhiễu chính, và ranh giới chọn lựa là:

  	Amazon MQ	SQS / SNS
  Hợp với	Di trú ứng dụng có sẵn	Xây mới trên AWS
  Giao thức	Chuẩn ngành (JMS, AMQP…)	API riêng của AWS
  Quản lý	Có broker, có phiên bản	Hoàn toàn không máy chủ

• C. Amazon SNS — mô hình xuất bản và đăng ký, cũng dùng API riêng.

• B. Kinesis Data Streams — dựng cho luồng dữ liệu thời gian thực, không phải message broker.

Đáp án

B — Multi-AZ nâng cao tính sẵn sàng của cơ sở dữ liệu

Vì sao đúng

RDS Multi-AZ duy trì một bản chờ (standby) được nhân bản đồng bộ ở một Availability Zone khác. Khi bản chính gặp sự cố — hỏng hạ tầng, mất AZ, hoặc trong lúc bảo trì — RDS tự chuyển sang bản chờ, thường trong 1–2 phút.

Endpoint không đổi, vì RDS cập nhật bản ghi DNS trỏ sang bản chờ. Ứng dụng dùng nguyên chuỗi kết nối cũ.

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

• A. Cải thiện hiệu năng cho workload nặng về đọc — sai và là hiểu lầm phổ biến nhất: bản chờ trong Multi-AZ không phục vụ truy vấn nào, nó chỉ đứng đó chờ. Muốn chia tải đọc thì dùng read replica, một tính năng khác. Đây là phương án nhiễu chính.
• C. Bảo vệ khỏi sự cố toàn Region — sai về phạm vi: Multi-AZ bảo vệ trong một Region. Muốn chịu được mất trọn Region thì cần cross-region read replica hoặc Aurora Global Database.
• D. Giảm chi phí — ngược lại: Multi-AZ tăng gấp đôi chi phí instance vì bạn trả cho cả bản chờ.

Ghi nhớ cặp hay bị lẫn

Đáp án

A — High Availability (tính sẵn sàng cao)

Vì sao đúng

Triển khai Multi-AZ nghĩa là đặt tài nguyên ở nhiều Availability Zone — mỗi AZ có nguồn điện, làm mát và mạng riêng, cách nhau đủ xa để một sự cố cục bộ không ảnh hưởng cả hai.

Mục đích duy nhất của việc đó là hệ thống vẫn chạy khi một AZ gặp sự cố, tức là tính sẵn sàng cao.

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

• C. Scale up và D. Scale out — đều là mở rộng quy mô, tức là tăng năng lực phục vụ:

  	Mục đích
  Multi-AZ	Chịu được sự cố
  Scale up	Máy mạnh hơn
  Scale out	Nhiều máy hơn

  Điểm dễ nhầm: scale out có thể tình cờ tạo ra tính sẵn sàng nếu các máy nằm ở nhiều AZ — nhưng đó là hệ quả, không phải định nghĩa. Còn Multi-AZ với RDS thì bản chờ không phục vụ gì cả, nên rõ ràng không phải mở rộng quy mô.

• B. Performance Efficiency — một trụ của Well-Architected Framework, nói về việc dùng tài nguyên hiệu quả; không phải mục đích của Multi-AZ.

Đáp án

C — Mã hoá cơ sở dữ liệu

Vì sao đúng

Với dịch vụ được quản lý như RDS, AWS gánh phần lớn công việc vận hành — nhưng dữ liệu và các quyết định về bảo mật dữ liệu luôn thuộc về khách hàng.

Một chi tiết thực hành đáng nhớ về mã hoá RDS: phải bật lúc tạo instance, không bật được sau đó. Quên là phải khôi phục từ snapshot sang một instance mới.

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

• A. Vá cơ sở dữ liệu và B. Vá hệ điều hành bên dưới — đều là việc của AWS; đó chính là lý do người ta chọn RDS thay vì tự chạy cơ sở dữ liệu trên EC2. Đây là hai phương án nhiễu chính.
• D. Quản lý phần cứng máy chủ — luôn là việc của AWS ở mọi dịch vụ.