Ngân hàng đề — AWS Certified SysOps Administrator Associate

Đáp án

D — Auto Scaling group trong môi trường Beanstalk dùng HAI CloudWatch alarm mặc định để kích hoạt co giãn; các alarm này phải được cấu hình theo tham số phù hợp với ứng dụng của bạn.

Vì sao đúng

Đề nói Beanstalk không co giãn như đội ngũ mong đợi. Nguyên nhân gần như luôn là: alarm mặc định không phản ánh tải thật của ứng dụng.

⚠ Điểm mấu chốt: chỉ số mặc định của Beanstalk hiếm khi là chỉ số đúng cho ứng dụng của bạn:

Mặc định: co giãn theo NetworkOut
        ↓
    Hợp với ứng dụng truyền nhiều dữ liệu ra
        ↓
    Nhưng một API tính toán nặng có thể nghẽn CPU mà NetworkOut vẫn thấp
        ↓
    → không bao giờ đạt ngưỡng → không co giãn
    → và ngược lại, một ứng dụng phục vụ tệp lớn có thể co giãn dù CPU rảnh

Cấu hình lại qua console hoặc .ebextensions:

# .ebextensions/autoscaling.config
option_settings:
  aws:autoscaling:trigger:
    MeasureName: CPUUtilization
    Statistic: Average
    Unit: Percent
    UpperThreshold: 70
    LowerThreshold: 30
    BreachDuration: 5

⚠ Ngưỡng trên và ngưỡng dưới quá gần nhau gây co giãn dao động:

UpperThreshold 60, LowerThreshold 55
        ↓
    Tải dao động quanh mức đó
        ↓
    → thêm máy, rồi bớt máy, rồi lại thêm — liên tục
        ↓
    → để khoảng cách đủ rộng, và đặt cooldown hợp lý

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

• B (ASG của Beanstalk dùng SỐ NGƯỜI DÙNG ĐANG ĐĂNG NHẬP làm tiêu chí co giãn) — đây là phương án gần nhất và nó có cùng cấu trúc câu với đáp án đúng, chỉ khác chỉ số. Nhưng "số người dùng đang đăng nhập" không phải chỉ số của AWS — CloudWatch không biết gì về phiên đăng nhập của ứng dụng. Đó là một chỉ số tuỳ chỉnh mà bạn phải tự đẩy lên, không phải mặc định của Beanstalk.

• C (mặc định ASG của Beanstalk dùng ELB health check, hãy đổi sang EC2 status check) — nhầm hai khái niệm: health check quyết định máy nào bị thay thế, còn alarm quyết định khi nào thêm hay bớt máy. Đổi health check không ảnh hưởng tới co giãn. Và đổi sang EC2 là đi lùi về độ nhạy.

• A (IAM role gắn với ASG có thể thiếu quyền để co giãn) — nếu thiếu quyền thì co giãn thất bại với lỗi rõ ràng trong lịch sử hoạt động của ASG, chứ không phải "không co giãn như mong đợi".

Ghi nhớ

⚠ Hai thứ khác nhau trong Auto Scaling — bảng phải thuộc: | Thứ | Quyết định | |---|---| | CloudWatch alarm / scaling policy | KHI NÀO thêm hay bớt máy | | Health check type | máy nào bị coi là hỏng và thay thế |

Từ khoá nhận diện:

"Beanstalk không co giãn như mong đợi" → sửa alarm mặc định "số người dùng đăng nhập" → không phải chỉ số AWS "đổi health check để sửa co giãn" → nhầm khái niệm thiếu quyền IAM → lỗi rõ ràng, không phải co giãn sai nhịp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Alarm nào đang điều khiển co giãn | describe-alarms lọc theo tên môi trường | | Co giãn có kích hoạt không | lịch sử hoạt động của ASG | | Chỉ số có phản ánh tải không | so biểu đồ chỉ số với độ trễ ứng dụng |

Và một lời khuyên: hãy chọn chỉ số phản ánh trải nghiệm người dùng, không phải chỉ số dễ đo nhất. CPUUtilization là mặc định phổ biến vì nó luôn có sẵn, nhưng với một ứng dụng web thì thứ người dùng cảm nhận là thời gian phản hồi, và nó thường tương quan với số request trên mỗi target chặt chẽ hơn nhiều so với CPU. Một ứng dụng chờ cơ sở dữ liệu sẽ có CPU thấp trong khi hàng đợi request dài ra — và co giãn theo CPU sẽ không bao giờ phản ứng, dù người dùng đang chờ.

Đáp án

B — Bạn truy cập riêng tư tới API của AWS Systems Manager từ VPC bằng cách tạo VPC Endpoint.

Vì sao đúng

Đề đòi gọi API của Systems Manager mà không đi qua Internet. Interface VPC endpoint làm đúng việc đó.

⚠ Điểm mấu chốt: Systems Manager cần BA endpoint, không phải một:

com.amazonaws.<region>.ssm          → API chính của Systems Manager
com.amazonaws.<region>.ssmmessages  → Session Manager và kênh dữ liệu
com.amazonaws.<region>.ec2messages  → agent nhận lệnh
        ↓
    Thiếu một trong ba → một phần chức năng không hoạt động
        ↓
    → và triệu chứng thường là instance không xuất hiện trong danh sách managed

for svc in ssm ssmmessages ec2messages; do
  aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
    --vpc-endpoint-type Interface \
    --service-name com.amazonaws.ap-southeast-1.$svc \
    --subnet-ids subnet-a subnet-b --security-group-ids sg-endpoint
done

⚠ Interface endpoint là một ENI — nên nó CÓ security group, và đó là nguyên nhân lỗi số một:

Endpoint tạo xong, trạng thái available
        ↓
    Nhưng security group không cho phép cổng 443 từ dải VPC
        ↓
    → mọi kết nối tới endpoint bị chặn
    → triệu chứng là timeout, không phải lỗi quyền

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

• A (tạo VPN connection để truy cập riêng tư API của Systems Manager) — đây là phương án gần nhất và VPN thật sự tạo ra kênh riêng. Nhưng nó nối mạng tại chỗ với VPC, không phải nối VPC với các API công cộng của AWS. Lưu lượng từ instance trong VPC gọi tới endpoint của Systems Manager sẽ không đi qua VPN đó.

• C (tạo NAT gateway) — NAT gateway cho instance ở private subnet ra Internet. Nó giải quyết được vấn đề kết nối, nhưng vi phạm yêu cầu không dùng Internet của đề.

• D (tạo Internet Gateway) — càng đi ngược yêu cầu hơn: nó phơi tài nguyên ra Internet trực tiếp.

Ghi nhớ

⚠ Hai loại VPC endpoint — bảng phải thuộc: | | Gateway endpoint | Interface endpoint | |---|---|---| | Dịch vụ | chỉ S3 và DynamoDB | hầu hết dịch vụ AWS | | Cơ chế | mục trong route table | ENI có IP riêng, qua DNS | | Chi phí | miễn phí | phí giờ + phí GB | | Security group | không gắn được | gắn được | | Từ on-premises | không dùng được | dùng được qua DX/VPN |

Từ khoá nhận diện:

"gọi API AWS riêng tư từ VPC" → interface VPC endpoint "NAT gateway" khi đề cấm Internet → SAI, NAT vẫn ra Internet "VPN" để gọi API AWS từ VPC → SAI, VPN nối on-premises với VPC Systems Manager → cần ba endpoint: ssm, ssmmessages, ec2messages endpoint tạo xong vẫn timeout → kiểm security group của endpoint

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance có vào Systems Manager chưa | aws ssm describe-instance-information | | Tên có phân giải về IP riêng không | dig ssm.<region>.amazonaws.com từ instance | | Security group của endpoint | describe-vpc-endpoints, xem Groups |

Và một lời khuyên: hãy tạo interface endpoint ở mọi Availability Zone có instance, đừng chỉ một. Endpoint chỉ có ENI ở những AZ bạn khai, và một instance ở AZ không có ENI sẽ hoặc không kết nối được, hoặc đi vòng qua AZ khác — thêm độ trễ và thêm phí truyền dữ liệu chéo AZ. Triệu chứng là "đôi khi chạy, đôi khi không" tuỳ máy nào đang xử lý, và nó gần như không tái hiện được khi bạn thử từ một máy cụ thể.

Đáp án

A, C, E — ba điều đúng về cấu hình VPC:

• E — Khi tạo VPC, bạn phải khai một dải địa chỉ IPv4 dưới dạng khối CIDR.
• A — Theo mặc định, mọi subnet định tuyến được tới nhau, dù là private hay public.
• C — Bất kể loại subnet nào, dải địa chỉ IPv4 nội bộ của subnet luôn là địa chỉ riêng.

Vì sao đúng

Ba mệnh đề này là nền tảng của VPC.

⚠ Điểm mấu chốt: "public subnet" không có nghĩa là địa chỉ trong đó là công cộng:

Instance trong public subnet
        ↓
    Vẫn có một địa chỉ IPv4 RIÊNG từ dải của subnet (ví dụ 10.0.1.5)
        ↓
    Nếu được gán thêm public IP, đó là một địa chỉ ÁNH XẠ từ bên ngoài
        ↓
    Hệ điều hành bên trong máy KHÔNG BAO GIỜ thấy địa chỉ công cộng đó
        ↓
    → chạy `ip addr` chỉ thấy IP riêng

⚠ Ba dải CIDR riêng theo RFC 1918: | Dải | Kích thước | |---|---| | 10.0.0.0/8 | lớn nhất | | 172.16.0.0/12 | trung bình | | 192.168.0.0/16 | nhỏ nhất |

VPC nhận CIDR từ /16 tới /28.

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

• D (private subnet mặc định không có lưu lượng vào từ Internet; bạn tạo route tới internet gateway trong route table của subnet để cho phép truy cập vào private subnet) — đây là phương án gần nhất và vế đầu của nó đúng. Nhưng vế sau tự mâu thuẫn: thêm route tới internet gateway chính là biến subnet đó thành public subnet. Không có cách nào vừa giữ một subnet là private vừa cho nó route tới IGW.

• B (subnet, giống như VPC, có thể trải nhiều Availability Zone nhưng nằm trong một Region) — sai. VPC trải nhiều AZ, nhưng mỗi subnet nằm trong đúng MỘT AZ. Đây là một trong những khác biệt nền tảng nhất giữa hai khái niệm.

• F (nếu subnet có route tới internet gateway cùng với lưu lượng định tuyến tới virtual private gateway cho Site-to-Site VPN thì gọi là VPN-only subnet) — sai định nghĩa. VPN-only subnet là subnet CHỈ có route tới virtual private gateway và KHÔNG có route tới internet gateway. Có cả hai thì nó là public subnet.

Ghi nhớ

⚠ Bốn điều nền tảng về VPC — bảng phải thuộc: | Điều | Nội dung | |---|---| | VPC | trải nhiều AZ, trong một Region | | Subnet | nằm trong đúng một AZ | | Local route | mọi subnet tới được nhau, không xoá được | | Public subnet | định nghĩa bằng route tới internet gateway |

Từ khoá nhận diện:

"subnet trải nhiều AZ" → LUÔN SAI "public subnet có địa chỉ công cộng bên trong" → SAI, địa chỉ nội bộ luôn riêng "route tới IGW trong private subnet" → mâu thuẫn, nó thành public "VPN-only subnet" → chỉ có route tới VGW, KHÔNG có IGW subnet không tới được nhau → kiểm security group và NACL, không phải route

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Subnet ở AZ nào | describe-subnets, xem AvailabilityZone | | Subnet là public hay private | kiểm route table có route tới igw- không | | Còn bao nhiêu IP | AvailableIpAddressCount |

Và một lời khuyên: hãy tính dư địa địa chỉ khi chia subnet, và nhớ AWS giữ 5 địa chỉ mỗi subnet. Một subnet /28 nghe như có 16 địa chỉ nhưng thực tế chỉ dùng được 11 — và với các workload hiện đại như ECS ở chế độ awsvpc hay Lambda trong VPC, mỗi task hay mỗi lời gọi đều tiêu một địa chỉ. Cạn IP trong subnet gây ra lỗi rất khó đọc: task ở mãi trạng thái pending, hoặc Auto Scaling group không khởi động được máy, với thông báo nói về ENI chứ không nói về địa chỉ.

Đáp án

B — Cấu hình Egress-only Internet Gateway, cho phép instance trong VPC liên lạc RA Internet qua IPv6.

Vì sao đúng

Với IPv6, mọi địa chỉ đều có thể định tuyến toàn cầu — không có khái niệm địa chỉ riêng như IPv4. Nên AWS tạo ra một thành phần riêng để giữ tính chất "chỉ đi ra".

⚠ Điểm mấu chốt: egress-only IGW là bản IPv6 của NAT — cho ra, chặn vào, nhưng KHÔNG dịch địa chỉ:

Instance IPv6 mở kết nối ra ngoài
        ↓
    Đi qua egress-only internet gateway
        ↓
    Gói trả về được cho vào (nó CÓ TRẠNG THÁI)
        ↓
    Kết nối do bên ngoài chủ động khởi tạo → BỊ CHẶN
        ↓
    → instance giữ nguyên địa chỉ IPv6 toàn cầu của nó
    → khác NAT: không có việc dịch địa chỉ, chỉ lọc chiều

aws ec2 create-egress-only-internet-gateway --vpc-id vpc-abc

aws ec2 create-route --route-table-id rtb-private \
  --destination-ipv6-cidr-block ::/0 \
  --egress-only-internet-gateway-id eigw-abc

⚠ NAT gateway CHỈ hoạt động với IPv4 — đây là nhầm lẫn phổ biến nhất:

Instance chỉ có IPv6 trong private subnet
        ↓
    NAT gateway không xử lý được IPv6
        ↓
    → phải dùng egress-only internet gateway
        ↓
    (AWS có NAT64/DNS64 nhưng đó là để instance IPv6 gọi dịch vụ chỉ có IPv4 —
     bài toán khác hẳn)

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

• C (dùng internet gateway cho IPv6 và gắn địa chỉ IPv6 với Elastic IP để làm nó công khai) — đây là phương án gần nhất và internet gateway thật sự xử lý IPv6. Nhưng nó cho lưu lượng cả hai chiều — nghĩa là instance phơi ra Internet, vi phạm yêu cầu của đề. Ngoài ra Elastic IP là khái niệm của IPv4; địa chỉ IPv6 không cần và không dùng được với Elastic IP.

• D (dùng internet gateway cho instance ở private subnet; public subnet mặc định đã nối Internet) — thêm route tới IGW biến private subnet thành public subnet, đúng thứ đề muốn tránh.

• A (dùng Carrier gateway cho lưu lượng ra IPv6) — sai công cụ. Carrier gateway chỉ dùng trong AWS Wavelength, để lưu lượng đi tới mạng của nhà mạng viễn thông. Nó không áp dụng cho VPC thông thường.

Ghi nhớ

⚠ Bốn thành phần định tuyến ra Internet — bảng phải thuộc: | Thành phần | Giao thức | Chiều | |---|---|---| | Internet gateway | IPv4 + IPv6 | cả vào lẫn ra | | NAT gateway | chỉ IPv4 | chỉ ra | | Egress-only IGW | chỉ IPv6 | chỉ ra | | Carrier gateway | — | chỉ trong Wavelength |

Từ khoá nhận diện:

"IPv6" + "chỉ ra Internet, không phơi ra" → egress-only internet gateway "NAT gateway cho IPv6" → LUÔN SAI, NAT chỉ IPv4 "Elastic IP cho địa chỉ IPv6" → SAI, EIP là khái niệm IPv4 "Carrier gateway" ngoài Wavelength → SAI thêm route tới IGW trong private subnet → nó thành public

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ra ngoài được không | từ instance: curl -6 https://checkip.amazonaws.com | | Vào có bị chặn không | từ máy ngoài, thử kết nối tới địa chỉ IPv6 của instance | | Security group có rule IPv6 chưa | kiểm Ipv6Ranges, không chỉ IpRanges |

Và một lời khuyên: hãy rà lại toàn bộ security group để thêm rule IPv6 ngay khi bật IPv6. Rule viết cho 0.0.0.0/0 không áp dụng cho lưu lượng IPv6 — nên một rule bạn tưởng đang chặn thì thực ra không chặn gì trên đường IPv6, và một rule bạn tưởng đang cho phép thì lưu lượng IPv6 lại bị từ chối. Không có cảnh báo nào cho sự lệch pha này; hệ thống chỉ đơn giản hành xử khác đi trên một giao thức mà phần lớn công cụ giám sát của bạn chưa được cấu hình để nhìn tới.

Đáp án

D — Lỗi này xảy ra khi Auto Scaling group cố khởi động một instance có EBS volume đã mã hoá, nhưng service-linked role không có quyền dùng customer-managed CMK dùng để mã hoá volume đó.

Vì sao đúng

Thông báo Client.InternalError: Client error on launch là lỗi đặc trưng của thiếu quyền KMS khi Auto Scaling khởi động instance.

⚠ Điểm mấu chốt: Auto Scaling dùng SERVICE-LINKED ROLE để khởi động máy — và role đó cần quyền trên CMK:

ASG khởi động instance từ launch template
        ↓
    Launch template trỏ tới AMI hoặc snapshot đã mã hoá bằng CMK tuỳ chỉnh
        ↓
    Service-linked role AWSServiceRoleForAutoScaling phải giải mã được
        ↓
    Key policy của CMK không cho role đó
        ↓
    → khởi động thất bại với Client.InternalError

Cách chữa là sửa key policy của CMK để cấp quyền cho service-linked role:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling"},
  "Action": ["kms:Decrypt", "kms:GenerateDataKey", "kms:CreateGrant", "kms:DescribeKey"],
  "Resource": "*"
}

⚠ kms:CreateGrant là quyền dễ quên nhất và bắt buộc phải có:

ASG cần tạo grant để EC2 dùng khoá trong suốt vòng đời instance
        ↓
    Thiếu CreateGrant → khởi động vẫn thất bại dù đã có Decrypt
        ↓
    → luôn cấp đủ bốn hành động ở trên

Xem thêm câu #11566 trong cùng bộ đề: nó hỏi cách sửa cho chính tình huống này khi CMK nằm ở tài khoản khác.

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

• A (security group khai trong launch configuration có thể đã bị xoá) — đây là phương án gần nhất và nó thật sự là một nguyên nhân khiến ASG không khởi động được máy. Nhưng nó cho ra một thông báo lỗi khác và rõ ràng hơn, nêu đích danh security group id không tồn tại — không phải Client.InternalError.

• B (cluster placement group chứa loại instance không hợp lệ) — cũng cho thông báo riêng về loại instance không được hỗ trợ trong placement group.

• C (block device mapping chứa tên thiết bị không khả dụng hoặc không được hỗ trợ) — cũng cho lỗi riêng, thường nêu tên thiết bị cụ thể.

Ba phương án này đều là nguyên nhân có thật của việc launch thất bại — nhưng chỉ một trong số đó gắn với đúng thông báo lỗi mà đề nêu.

Ghi nhớ

⚠ Bốn nguyên nhân ASG không khởi động được instance — bảng phải thuộc: | Nguyên nhân | Thông báo | |---|---| | Thiếu quyền KMS | Client.InternalError: Client error on launch | | Security group đã bị xoá | nêu đích danh group id | | AMI không tồn tại hoặc không có quyền | nêu ami id | | Hết dung lượng instance type | InsufficientInstanceCapacity | | Vượt hạn mức vCPU | VcpuLimitExceeded |

Từ khoá nhận diện:

Client.InternalError khi launch → kiểm quyền KMS của service-linked role volume mã hoá bằng CMK tuỳ chỉnh → key policy phải cho ASG dùng thiếu kms:CreateGrant → vẫn thất bại dù đã có Decrypt lỗi nêu đích danh tài nguyên → nguyên nhân khác, không phải KMS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lỗi thật là gì | aws autoscaling describe-scaling-activities --auto-scaling-group-name <ten> | | Key policy có cho ASG không | aws kms get-key-policy | | Volume mã hoá bằng khoá nào | describe-images hoặc describe-snapshots, xem KmsKeyId |

Và một lời khuyên: hãy đọc describe-scaling-activities thay vì đoán từ triệu chứng. Auto Scaling ghi lại nguyên nhân của từng lần khởi động thất bại trong lịch sử hoạt động, kèm thông báo lỗi đầy đủ — nhưng nó không hiện ra ở màn hình chính của ASG, nên rất nhiều người bỏ qua và bắt đầu rà soát launch template, subnet, hạn mức. Một lệnh CLI trả về đúng dòng lỗi và thường kết thúc cuộc điều tra ngay lập tức.

Đáp án

D — AWS Storage Gateway dùng SSL/TLS để mã hoá dữ liệu truyền giữa thiết bị gateway và kho lưu trữ AWS; theo mặc định, Storage Gateway dùng khoá mã hoá do S3 quản lý (SSE-S3) để mã hoá phía máy chủ cho toàn bộ dữ liệu nó lưu trong S3.

Vì sao đúng

Câu hỏi kiểm tra hai điều: giao thức mã hoá khi truyền, và dữ liệu có được mã hoá khi lưu không.

⚠ Điểm mấu chốt: Storage Gateway mã hoá cả hai chiều mà không cần bạn cấu hình gì:

Thiết bị gateway tại chỗ → AWS
        ↓
    SSL/TLS trên đường truyền — mặc định, không tắt được
        ↓
Dữ liệu lưu trong S3
        ↓
    SSE-S3 mặc định — mọi loại gateway, kể cả Tape Gateway
        ↓
    → có thể nâng lên SSE-KMS nếu cần khoá do bạn kiểm soát

⚠ Chọn SSE-KMS khi cần audit và phân quyền riêng cho khoá:

SSE-S3 mặc định: AWS quản lý khoá hoàn toàn, miễn phí
        ↓
SSE-KMS: bạn kiểm soát key policy, có audit trail trong CloudTrail
        ↓
    → cấu hình được cho từng file share hoặc từng volume
    → yêu cầu tuân thủ thường đòi mức này

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

• B (dùng SSL/TLS; dữ liệu của File và Volume Gateway lưu trong S3 được mã hoá; dữ liệu của Tape Gateway KHÔNG mã hoá được khi lưu) — đây là phương án gần nhất và vế giao thức của nó chính xác. Nhưng vế cuối sai: Tape Gateway cũng mã hoá dữ liệu khi lưu, cả trong Virtual Tape Library lẫn khi chuyển sang Glacier. Không có loại gateway nào bị loại trừ khỏi mã hoá at rest.

• A (dùng IPsec; cả ba loại gateway đều mã hoá khi lưu) — vế thứ hai đúng nhưng giao thức sai: Storage Gateway dùng SSL/TLS, không phải IPsec.

• C (dùng IPsec; Tape Gateway không mã hoá được khi lưu) — sai cả hai vế.

Ghi nhớ

⚠ Ba loại Storage Gateway — bảng phải thuộc: | Loại | Phơi ra | Lưu vào | |---|---|---| | File Gateway (S3) | NFS và SMB | object trong S3 | | File Gateway (FSx) | SMB | FSx for Windows | | Volume Gateway | iSCSI | EBS snapshot | | Tape Gateway | VTL (iSCSI) | S3 và Glacier |

Từ khoá nhận diện:

Storage Gateway mã hoá khi truyền → SSL/TLS "IPsec" cho Storage Gateway → SAI "Tape Gateway không mã hoá được" → SAI, mọi loại đều mã hoá mặc định khi lưu → SSE-S3 cần khoá do bạn kiểm soát → chuyển sang SSE-KMS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | File share dùng khoá nào | describe-nfs-file-shares, xem KMSEncrypted và KMSKey | | Object trong S3 mã hoá bằng gì | head-object, xem ServerSideEncryption | | Có audit truy cập khoá không | CloudTrail, sự kiện Decrypt với SSE-KMS |

Và một lời khuyên: hãy chuyển sang SSE-KMS nếu cuộc kiểm toán hỏi ai kiểm soát khoá. Mã hoá mặc định bằng SSE-S3 đáp ứng được câu hỏi "dữ liệu có được mã hoá không", nhưng không đáp ứng được "ai có thể giải mã và bạn chứng minh thế nào". Với SSE-KMS, bạn kiểm soát key policy, xoay vòng khoá theo lịch, và mỗi lần giải mã đều để lại một bản ghi trong CloudTrail — ba thứ mà kiểm toán viên thường hỏi ngay sau câu hỏi đầu tiên.

Đáp án

A, C — hai điều cần nhớ về On-Demand Capacity Reservation:

• C — Capacity Reservation cho phép giữ chỗ cho EC2 instance ở một Availability Zone cụ thể trong khoảng thời gian tuỳ ý.
• A — Capacity Reservation KHÔNG mang lại bất kỳ khoản giảm giá nào.

Vì sao đúng

Đây chính là nhầm lẫn khiến công ty trong đề bất ngờ về hoá đơn: "reservation" trong tên gọi khiến người ta tưởng là giảm giá.

⚠ Điểm mấu chốt: bạn trả tiền cho dung lượng đã giữ, dù có chạy instance hay không:

Tạo Capacity Reservation cho 10 instance
        ↓
    Chỉ chạy 3 instance
        ↓
    → vẫn trả tiền On-Demand cho đủ 10
        ↓
    → đây là lý do hoá đơn cao hơn dự kiến

⚠ Muốn vừa giữ chỗ vừa được giảm giá thì phải KẾT HỢP hai thứ:

Capacity Reservation → đảm bảo có dung lượng
        +
Savings Plans hoặc Reserved Instance → giảm giá
        ↓
    → giảm giá tự động áp cho dung lượng đã giữ
    → đây là cấu hình đúng cho workload quan trọng cần cả hai

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

• B (Capacity Reservation đòi cam kết cố định một hoặc ba năm) — đây là phương án gần nhất và nó mô tả đúng Reserved Instance, nên rất dễ nhầm. Nhưng Capacity Reservation không có cam kết thời gian nào: bạn tạo nó, dùng vài giờ, rồi huỷ. Chính sự linh hoạt đó là lý do nó không có giảm giá.

• D (Capacity Reservation chuyển được từ tài khoản này sang tài khoản khác) — không chuyển được. Nó thuộc về tài khoản tạo ra nó; điều duy nhất làm được là chia sẻ qua AWS RAM cho tài khoản khác dùng.

• E (dùng được với Dedicated Host nhưng không dùng được với placement group) — sai cả hai vế: Capacity Reservation dùng được với cluster placement group, và không áp dụng cho Dedicated Host (Dedicated Host có cơ chế giữ chỗ riêng).

Ghi nhớ

⚠ Bốn cơ chế giá và giữ chỗ của EC2 — bảng phải thuộc: | Cơ chế | Giảm giá | Đảm bảo dung lượng | Cam kết | |---|---|---|---| | On-Demand | không | không | không | | Capacity Reservation | không | có | không | | Reserved Instance (zonal) | có | có | 1 hoặc 3 năm | | Reserved Instance (regional) | có | không | 1 hoặc 3 năm | | Savings Plans | có | không | 1 hoặc 3 năm |

Từ khoá nhận diện:

"đảm bảo có dung lượng khi cần" → Capacity Reservation "giảm chi phí" → Savings Plans hoặc RI "Capacity Reservation cho giảm giá" → LUÔN SAI "cam kết 1–3 năm" → RI hoặc Savings Plans, không phải Capacity Reservation cần cả hai → kết hợp Capacity Reservation với Savings Plans

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dung lượng đã giữ dùng bao nhiêu | describe-capacity-reservations, xem AvailableInstanceCount | | Có đang trả tiền cho chỗ trống không | so số đã giữ với số đang chạy | | Giảm giá có áp không | báo cáo Savings Plans utilization |

Và một lời khuyên: hãy đặt cảnh báo khi Capacity Reservation có dung lượng chưa dùng, và huỷ nó ngay khi hết nhu cầu. Đây chính là sự cố mà công ty trong đề gặp phải: reservation không có cam kết thời gian, nghĩa là nó cũng không tự hết hạn — nó tiếp tục giữ chỗ và tính tiền On-Demand đầy đủ cho tới ngày ai đó nhớ ra và huỷ đi. Không có cảnh báo nào, không có mục nào trên bảng điều khiển EC2 nói rằng bạn đang trả tiền cho phần cứng không chạy gì cả.

Đáp án

A — Cấu hình CloudWatch agent với giao thức StatsD để thu thập chỉ số cần thiết.

Vì sao đúng

Chi tiết quyết định nằm ở một từ trong đề: máy chạy Windows.

⚠ Điểm mấu chốt: collectd không chạy trên Windows — đó là toàn bộ nội dung câu hỏi:

Unified CloudWatch agent hỗ trợ hai giao thức nhận chỉ số tuỳ chỉnh
        ↓
    StatsD  → chạy trên cả Linux lẫn Windows
    collectd → chỉ Linux
        ↓
    Máy chạy Windows → chỉ còn StatsD

{
  "metrics": {
    "metrics_collected": {
      "statsd": {
        "service_address": ":8125",
        "metrics_collection_interval": 60,
        "metrics_aggregation_interval": 60
      }
    }
  }
}

Ứng dụng gửi chỉ số bằng một dòng UDP đơn giản:

so_don_hang:1|c
thoi_gian_xu_ly:250|ms

⚠ StatsD dùng UDP — gửi xong là quên, không có xác nhận:

Ứng dụng gửi gói UDP tới cổng 8125
        ↓
    Nếu agent không chạy, hoặc gói bị mất
        ↓
    → chỉ số biến mất, ứng dụng KHÔNG nhận được lỗi nào
        ↓
    → đó là đánh đổi có chủ ý: nhẹ và không chặn ứng dụng

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

• D (agent cấu hình được với StatsD HOẶC collectd để thu thập chỉ số trên máy chủ Windows) — đây là phương án gần nhất và nó đúng một nửa: StatsD thật sự dùng được. Nhưng nó thêm collectd vào, và collectd không hỗ trợ Windows. Đây là bẫy đòi nhớ chính xác nền tảng nào hỗ trợ giao thức nào.

• B (dùng collectd) — sai vì lý do trên.

• C (unified CloudWatch agent không cấu hình tuỳ chỉnh được) — sai hoàn toàn: agent được cấu hình bằng một tệp JSON rất linh hoạt, khai được chỉ số hệ thống, log, và cả hai giao thức chỉ số tuỳ chỉnh.

Ghi nhớ

⚠ Hai giao thức chỉ số tuỳ chỉnh của CloudWatch agent — bảng phải thuộc: | Giao thức | Nền tảng | Cổng mặc định | |---|---|---| | StatsD | Linux và Windows | 8125 (UDP) | | collectd | chỉ Linux | 25826 (UDP) |

Từ khoá nhận diện:

chỉ số tuỳ chỉnh trên Windows → StatsD "collectd trên Windows" → LUÔN SAI "agent không cấu hình được" → SAI, cấu hình bằng JSON chỉ số hệ thống (RAM, đĩa) → agent thu thập trực tiếp, không cần giao thức nào

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent có nhận StatsD không | kiểm cổng 8125 đang lắng nghe | | Chỉ số có tới CloudWatch không | tìm trong namespace CWAgent | | Có bao nhiêu chỉ số duy nhất | ảnh hưởng trực tiếp tới hoá đơn |

Và một lời khuyên: hãy cẩn thận với dimension khi đẩy chỉ số tuỳ chỉnh — mỗi tổ hợp giá trị là một chỉ số riêng phải trả tiền. Đây là chỗ chi phí CloudWatch bùng lên nhanh nhất và bất ngờ nhất: thêm một dimension customer_id vào một chỉ số nghe rất hữu ích, nhưng với mười nghìn khách hàng thì bạn vừa tạo ra mười nghìn chỉ số riêng biệt, mỗi cái tính tiền hằng tháng. Chỉ số vẫn hoạt động hoàn hảo, biểu đồ vẫn đẹp, và hoá đơn tháng sau tăng gấp nhiều lần mà không có gì trong hệ thống cảnh báo trước.

Đáp án

B — Tạo và gắn Internet Gateway vào VPC, rồi sửa route table của subnet chứa EC2 để định tuyến lưu lượng internet qua Internet Gateway.

Vì sao đúng

Đây là câu hỏi nền tảng nhất về VPC: muốn ra internet thì phải có Internet Gateway, và phải có tuyến đường trỏ tới nó.

⚠ Điểm mấu chốt: một subnet là "public" hay "private" hoàn toàn do route table quyết định, không phải do đặt tên:

Subnet có route 0.0.0.0/0 → Internet Gateway
        ↓
    → đó là public subnet
        ↓
Subnet không có route đó
        ↓
    → đó là private subnet, dù bạn đặt tên nó là "public-subnet-1"

⚠ Đề nói EC2 nằm ở subnet riêng, tách khỏi ELB và RDS — nhưng nó vẫn cần tải bản vá:

Yêu cầu: EC2 tải patch từ internet
        ↓
Cách 1: đặt EC2 ở subnet có tuyến tới IGW  ← đáp án của đề
        + mỗi instance cần IP công cộng
Cách 2: đặt EC2 ở private subnet + NAT Gateway ở public subnet
        + an toàn hơn: chỉ ra được, không ai vào được

Trong thực tế cách 2 là kiến trúc chuẩn cho fleet phía sau ALB, nhưng NAT Gateway không có trong danh sách phương án, nên đáp án đúng của đề là B.

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

• A (tạo ENI và gắn vào public subnet) — đây là phương án gần nhất và nó hiểu sai bản chất của ENI. Elastic network interface luôn thuộc về đúng một subnet, cố định từ lúc tạo; không có chuyện gắn một ENI của instance ở subnet này sang "public subnet" để mượn đường ra. Và kể cả ENI nằm ở public subnet thì thứ cho phép ra internet vẫn là route table + IGW, chứ không phải bản thân ENI.

• C (Egress-only Internet Gateway) — chỉ dành cho IPv6. Nó cho phép ra internet nhưng chặn kết nối vào, nghe rất hợp với "tải bản vá", nhưng không hoạt động với IPv4 — mà đề không nói gì tới IPv6.

• D (carrier gateway) — dành riêng cho AWS Wavelength Zone, để lưu lượng đi tới mạng viễn thông 5G của nhà mạng. Không liên quan gì tới VPC thông thường.

Ghi nhớ

⚠ Bốn loại gateway ra ngoài của VPC — bảng phải thuộc: | Gateway | Dùng cho | Chiều | |---|---|---| | Internet Gateway | IPv4 và IPv6 | hai chiều | | NAT Gateway | IPv4 | chỉ ra | | Egress-only IGW | chỉ IPv6 | chỉ ra | | Carrier Gateway | Wavelength / mạng 5G | hai chiều |

Từ khoá nhận diện:

"cần ra internet", IPv4 → IGW (public) hoặc NAT Gateway (private) "chỉ ra, không cho vào", IPv6 → Egress-only Internet Gateway "chỉ ra, không cho vào", IPv4 → NAT Gateway "Wavelength", "5G" → carrier gateway ENI cho ra internet → SAI, ENI gắn cứng vào một subnet

Ba việc kiểm chứng khi EC2 không ra được internet: | Việc | Cách | |---|---| | Route table | có 0.0.0.0/0 trỏ đúng IGW/NAT không | | IP công cộng | instance ở public subnet có IP public không | | SG và NACL | NACL là stateless, phải mở cả chiều về (cổng tạm 1024–65535) |

Và một lời khuyên: hãy dùng NAT Gateway cho fleet phía sau ALB thay vì cho instance IP công cộng. Đặt IP công cộng lên từng instance nghĩa là mỗi máy trong fleet đều có một địa chỉ mà cả internet gọi tới được, và bảo vệ duy nhất còn lại là Security Group — một luật mở nhầm là toàn bộ fleet phơi ra. Với NAT Gateway thì instance không có địa chỉ nào để gọi tới, nên luật mở nhầm cũng không thành lối vào.

Đáp án

B — Đặt "Retain Until Date" trong Object Lock là 5 năm kể từ ngày tạo đối tượng, ĐỒNG THỜI tạo lifecycle policy xoá đối tượng 5 năm sau khi tạo.

Vì sao đúng

Đề có hai yêu cầu tách bạch, và mỗi tính năng chỉ giải quyết được một:

⚠ Điểm mấu chốt: Object Lock không tự xoá, lifecycle không tự bảo vệ — phải dùng cả hai:

Object Lock  → chặn xoá TRƯỚC hạn
                nhưng hết hạn thì đối tượng vẫn nằm đó, vẫn tính tiền
Lifecycle    → xoá SAU hạn, tự động
                nhưng một mình nó không ngăn ai xoá sớm
        ↓
    → kết hợp cả hai mới vừa an toàn vừa tiết kiệm

⚠ Hai cơ chế đó không đánh nhau — lifecycle tôn trọng Object Lock:

Lifecycle rule tới hạn xoá, nhưng retention chưa hết
        ↓
    → S3 KHÔNG xoá, thử lại sau
        ↓
Retention hết hạn
        ↓
    → lần đánh giá lifecycle kế tiếp mới xoá thật

Đây chính là điều khiến cấu hình này an toàn: kể cả đặt nhầm lifecycle thành 3 năm, Object Lock vẫn giữ đối tượng đủ 5 năm.

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

• D (chỉ tạo lifecycle policy xoá sau 5 năm) — đây là phương án gần nhất và nó xoá đúng hạn thật. Nhưng đề nói đây là báo cáo mật của công ty tài chính; thiếu Object Lock thì bất kỳ ai có quyền s3:DeleteObject đều xoá được ngay hôm nay, và với hồ sơ tài chính thì đó là rủi ro tuân thủ chứ không chỉ là mất dữ liệu.

• A (tắt versioning rồi đặt retention) — sai kỹ thuật: Object Lock BẮT BUỘC phải bật versioning, không thể tắt. Thật ra khi bật Object Lock thì S3 tự bật versioning và không cho tắt lại chừng nào Object Lock còn bật.

• C (đặt "Retain Until Date" mặc định ở cấp bucket) — hiểu sai cách hoạt động. Cấu hình mặc định ở cấp bucket khai bằng khoảng thời gian (ví dụ 1825 ngày, hoặc 5 năm), tính từ lúc mỗi đối tượng được ghi — không phải một mốc ngày cố định cho tất cả. Và quan trọng hơn: nó vẫn không xoá gì cả, nên không giải quyết được vấn đề chi phí của đề.

Ghi nhớ

⚠ Hai chế độ của S3 Object Lock — bảng phải thuộc: | Chế độ | Ai gỡ được trước hạn | |---|---| | Governance | tài khoản có quyền s3:BypassGovernanceRetention | | Compliance | KHÔNG AI — kể cả tài khoản gốc |

Từ khoá nhận diện:

"phải giữ đủ N năm" → Object Lock "xoá tự động cho đỡ tốn" → Lifecycle expiration cả hai yêu cầu → dùng CẢ HAI "Object Lock mà tắt versioning" → LUÔN SAI "không ai được xoá, kể cả root" → chế độ Compliance "tranh chấp pháp lý, chưa biết bao lâu" → Legal Hold

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Object Lock có bật không | get-object-lock-configuration — chỉ bật được lúc tạo bucket (hoặc mở ticket hỗ trợ) | | Retention của một đối tượng | get-object-retention | | Lifecycle có chạy không | S3 đánh giá mỗi ngày một lần, không tức thì |

Và một cảnh báo: chế độ Compliance là không thể đảo ngược. Đặt nhầm Retain Until Date thành 50 năm ở chế độ Compliance thì không có lệnh nào, không có quyền IAM nào, và không có yêu cầu hỗ trợ nào gỡ được nó — cách duy nhất để ngừng trả tiền cho dữ liệu đó là đóng cả tài khoản AWS. Hãy thử ở chế độ Governance trước, và chỉ chuyển sang Compliance khi con số đã được duyệt bằng văn bản.