Ngân hàng đề — AWS Certified CloudOps Engineer Associate

🧩 Phân tích nội dung câu hỏi

Đội phát triển triển khai và co giãn ứng dụng web bằng AWS Elastic Beanstalk. Môi trường đã dựng xong, nhưng Beanstalk không co giãn theo cách họ mong đợi, khiến ứng dụng không bám kịp biến động lưu lượng. Câu hỏi: cấu hình môi trường thế nào để tận dụng đúng khả năng auto-scaling của Beanstalk?

Cụm từ quyết định đáp án là "is not handling the scaling activities the way they expected" — tức là scaling vẫn chạy, chỉ là chạy không đúng ý. Đây không phải tình huống "không có instance nào được tạo ra" (lỗi quyền), cũng không phải "instance bị đánh giá sức khoẻ sai". Nó là tình huống ngưỡng kích hoạt scaling không phù hợp với ứng dụng. Thêm một chi tiết nữa: "impacted the application's ability to respond to the variations in traffic" — nhấn mạnh sự lệch pha giữa tiêu chí đo và thứ thực sự tạo tải cho ứng dụng này.

✅ Vì sao đáp án đúng là đúng

Đáp án D: Auto Scaling group trong môi trường Elastic Beanstalk dùng hai CloudWatch alarm mặc định để kích hoạt thao tác scale — một alarm scale-out và một alarm scale-in. Mặc định, Beanstalk gắn trigger vào chỉ số NetworkOut (lưu lượng mạng đi ra trung bình mỗi instance) đo trên một cửa sổ thời gian ngắn: vượt ngưỡng trên thì thêm instance, xuống dưới ngưỡng dưới thì bớt instance.

Đây chính là gốc rễ của triệu chứng trong đề. NetworkOut là mặc định chung cho mọi loại workload, nó không nói lên điều gì về ứng dụng cụ thể này. Một ứng dụng web nghẽn ở CPU, ở độ trễ (latency), ở disk I/O hay ở số request đồng thời hoàn toàn có thể quá tải trong khi NetworkOut vẫn nằm êm trong khoảng mặc định — nên alarm không bắn, Auto Scaling group không làm gì cả, và người vận hành thấy "scaling không như mong đợi".

Cách sửa đúng là cấu hình lại trigger cho phù hợp với ứng dụng, loại instance và yêu cầu dịch vụ. Beanstalk cho chọn nhiều chỉ số khác nhau cho trigger — CPU utilization, latency, disk I/O, request count, ngoài NetworkIn/NetworkOut — cùng với ngưỡng trên/dưới, chu kỳ đo và số instance thêm/bớt mỗi lần. Đổi từ chỉ số mặc định sang chỉ số thực sự phản ánh tải của ứng dụng là việc phải làm sau khi dựng môi trường, không phải thứ Beanstalk đoán giúp được.

❌ Vì sao các phương án còn lại sai

A — IAM Role gắn với Auto Scaling group thiếu quyền để tạo instance on-demand: Đúng là nếu IAM Role gắn với Beanstalk không đủ quyền thì Auto Scaling group không tạo nổi EC2 instance nào cả. Nhưng đó là một triệu chứng khác hẳn: scaling thất bại hoàn toàn, kèm lỗi trong sự kiện của môi trường. Đề mô tả scaling có xảy ra nhưng không đúng nhịp với lưu lượng — vấn đề tốc độ/thời điểm, không phải vấn đề quyền. Đây là phương án gần đúng theo kiểu "cũng là một nguyên nhân làm scaling hỏng", nhưng không khớp với triệu chứng đề nêu.

B — Auto Scaling group dùng số người dùng đang đăng nhập làm tiêu chí kích hoạt: Vế thứ hai của câu này ("phải cấu hình alarm theo tham số phù hợp với ứng dụng") thì đúng và giống hệt đáp án D — đây là bẫy cố ý. Nhưng vế đầu sai về sự thật: tiêu chí mặc định của Beanstalk là chỉ số mạng, không phải số người dùng đăng nhập. "Số người dùng đang đăng nhập" là khái niệm ở tầng ứng dụng, CloudWatch không tự biết được — muốn có thì phải tự đẩy lên làm custom metric. Sai tiền đề thì cả phương án sai, dù phần kết luận nghe hợp lý.

C — Mặc định Auto Scaling group của Beanstalk dùng Elastic Load Balancing health checks, hãy chuyển sang EC2 status checks: Sai ở cả hai vế. Thứ nhất, mặc định thì ngược lại — Auto Scaling group do Beanstalk tạo ra dùng Amazon EC2 status checks, còn ELB health check là thứ ta phải bật thêm nếu muốn. Thứ hai, dù có đảo lại cho đúng chiều thì health check không quyết định khi nào scale: nó chỉ quyết định instance nào bị coi là unhealthy để thay thế. Đổi kiểu health check không làm môi trường phản ứng nhanh hơn với biến động lưu lượng.

📌 Điểm cần nhớ

• Auto Scaling group của Elastic Beanstalk dùng hai CloudWatch alarm (một scale-out, một scale-in), và trigger mặc định gắn vào chỉ số NetworkOut — một mặc định chung chung, hiếm khi khớp với nút thắt thật của ứng dụng.
• Triệu chứng "scaling chạy nhưng không đúng nhịp" → nghĩ tới ngưỡng/chỉ số trigger sai. Triệu chứng "scaling không chạy chút nào, có lỗi" → mới nghĩ tới IAM permission.
• Beanstalk cho đổi trigger sang CPU utilization, latency, disk I/O, request count… Chọn chỉ số phản ánh đúng chỗ ứng dụng nghẽn là bước cấu hình bắt buộc sau khi dựng môi trường.
• Phân biệt rạch ròi hai khái niệm: health check (EC2 status check là mặc định của Beanstalk; ELB health check là tuỳ chọn) quyết định instance nào bị thay thế; scaling trigger quyết định khi nào thêm/bớt instance. Đề hỏi về co giãn thì đừng đi sửa health check.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một công ty ô tô chạy hạ tầng hybrid: một phần máy nằm ở on-premises, một phần nằm trên AWS, và trong Amazon VPC có vài managed instance của AWS Systems Manager. Câu hỏi là làm sao để các máy này gọi được Systems Manager APIs.

Cụm từ quyết định đáp án nằm ở đúng một chỗ: "wants to avoid using the internet for accessing AWS Systems Manager APIs from this VPC" — nghĩa là lưu lượng tới Systems Manager phải không đi qua Internet, ở lại hoàn toàn trong mạng của AWS.

Từ đó suy ra hai điều để lọc phương án:

• Đích đến là một dịch vụ AWS (Systems Manager), không phải mạng on-premises. Nên mọi giải pháp nối VPC với datacenter riêng đều lệch mục tiêu.
• Yêu cầu là riêng tư, không phải chỉ "kết nối được". Nên những thứ vẫn dẫn gói tin ra Internet — dù có che giấu IP hay chặn chiều vào — đều không thoả.

Chỉ có một cơ chế trong danh sách vừa nối tới AWS service API vừa giữ lưu lượng trong mạng AWS: VPC endpoint (interface endpoint, chạy trên AWS PrivateLink).

✅ Vì sao đáp án đúng là đúng

B — tạo VPC Endpoint.

Managed instance là bất kỳ máy nào đã được cấu hình cho AWS Systems Manager — có thể là EC2 instance, cũng có thể là máy on-premises trong môi trường hybrid như đề đang mô tả.

Cấu hình Systems Manager dùng interface VPC endpoint trong Amazon VPC sẽ tạo ra một điểm vào của dịch vụ ngay bên trong VPC, mang private IP address. Interface endpoint hoạt động nhờ AWS PrivateLink, công nghệ cho phép truy cập riêng tư tới Amazon EC2 và Systems Manager APIs bằng địa chỉ IP nội bộ.

Điểm mấu chốt: PrivateLink giới hạn toàn bộ lưu lượng mạng giữa managed instance, Systems Manager và Amazon EC2 ở trong mạng của Amazon. Instance của bạn không cần có đường ra Internet nữa. Khi đã dùng PrivateLink thì không cần internet gateway, không cần NAT device, cũng không cần virtual private gateway — đúng y yêu cầu "avoid using the internet" mà đề đặt ra. Ngoài mục tiêu riêng tư, đây còn là cách cải thiện security posture cho các managed instance, kể cả những máy thuộc phần hybrid.

❌ Vì sao các phương án còn lại sai

A — tạo VPN connection. Đây là phương án gần đúng nhất và cũng dễ nhầm nhất, vì môi trường trong đề là hybrid nên "VPN" nghe rất hợp cảnh. Nhưng nó giải quyết sai bài toán: mặc định, instance khởi chạy trong Amazon VPC không liên lạc được với mạng remote của chính bạn; AWS Site-to-Site VPN sinh ra để mở đường tới mạng đó, kèm cấu hình routing đẩy lưu lượng qua kết nối. Tức là VPN nối VPC ↔ datacenter on-premises, còn thứ đề cần là VPC ↔ Systems Manager API endpoint của AWS. Dựng VPN không tự nhiên biến lời gọi Systems Manager thành riêng tư.

C — tạo NAT gateway. NAT gateway cho phép instance nằm trong private subnet kết nối ra Internet hoặc tới các dịch vụ AWS khác, đồng thời chặn Internet chủ động mở kết nối vào những instance đó. Nghe có vẻ "an toàn" nên hay bị chọn, nhưng chiều bảo vệ của nó là chiều vào, còn chiều ra thì lưu lượng vẫn đi qua Internet. Đề yêu cầu tránh Internet chứ không phải tránh kết nối đến từ Internet — nên NAT gateway không đáp ứng.

D — tạo Internet Gateway. Đây là phương án trái ngược hẳn với yêu cầu. Internet gateway là thành phần của VPC, mở rộng theo chiều ngang, dư thừa và có tính sẵn sàng cao, cho phép instance trong VPC giao tiếp với Internet; nó không tạo ra rủi ro về availability hay giới hạn băng thông. Nhưng nó phải đặt ở public subnet và cần thêm route tương ứng trong route table — và bản chất của nó là đưa lưu lượng ra Internet, đúng thứ đề bảo phải tránh.

📌 Điểm cần nhớ

• Thấy cụm "private / without using the internet" đi kèm việc gọi API của một dịch vụ AWS → nghĩ ngay tới VPC endpoint / PrivateLink, không phải NAT hay Internet gateway.
• Phân biệt rõ hướng kết nối: VPN nối VPC với mạng on-premises của bạn; VPC endpoint nối VPC với dịch vụ AWS. Đề hybrid không tự động có nghĩa là đáp án phải là VPN.
• NAT gateway ≠ riêng tư. Nó chỉ ngăn Internet khởi tạo kết nối vào; lưu lượng đi ra vẫn qua Internet.
• Dùng PrivateLink cho Systems Manager thì không cần internet gateway, NAT device hay virtual private gateway — đây là câu chốt hay được lấy làm điểm phân biệt đáp án.

🧩 Phân tích nội dung câu hỏi

Đề đặt bối cảnh một trường đại học vừa mở tài khoản AWS và cần người giải thích những kiến thức nền tảng về VPC cho đội kỹ thuật. Phần bối cảnh Big Data chỉ là lớp vỏ — không có yêu cầu kiến trúc nào cần cân nhắc.

Cụm từ quyết định nằm ở câu hỏi cuối: "which of these would you identify as the correct options regarding VPC configurations? (Select three)". Đây không phải câu chọn giải pháp tốt nhất, mà là câu kiểm tra phát biểu đúng/sai. Mỗi phương án là một mệnh đề độc lập về cách VPC và subnet hoạt động; việc cần làm là đối chiếu từng mệnh đề với định nghĩa chuẩn, không phải so sánh các phương án với nhau.

Ba khái niệm bị đem ra thử ở đây: phạm vi của subnet (Region hay Availability Zone), cách phân loại public / private / VPN-only subnet (dựa vào route table), và dải địa chỉ IPv4 của VPC và subnet.

✅ Vì sao đáp án đúng là đúng

A — Mặc định mọi subnet trong cùng VPC route được tới nhau, dù là private hay public. Khi tạo VPC, AWS tạo sẵn một main route table chứa route local cho toàn bộ CIDR của VPC. Mọi subnet chưa gắn route table riêng đều dùng bảng này, nên liên lạc nội bộ giữa các subnet là hành vi mặc định — chính route local đó tạo ra khả năng này. (Lưu ý: đây là nói về routing; security group và network ACL vẫn có thể chặn lưu lượng ở tầng trên.)

C — Dải IPv4 nội bộ của subnet luôn là địa chỉ private, bất kể subnet thuộc loại nào. "Public subnet" không có nghĩa là instance trong đó mang IP private khác kiểu. Địa chỉ nội bộ mà instance nhận vẫn nằm trong CIDR riêng của VPC, và AWS không bao giờ quảng bá các khối địa chỉ này ra Internet. Việc một instance ra được Internet là nhờ public IP / Elastic IP được ánh xạ và nhờ route ra Internet Gateway, chứ không phải vì dải nội bộ đổi thành public.

E — Khi tạo VPC bắt buộc phải chỉ định dải IPv4 dưới dạng khối CIDR. Ví dụ 10.0.0.0/16. Đây là primary CIDR block của VPC — không có tuỳ chọn tạo VPC mà bỏ trống dải IPv4 rồi để AWS tự chọn.

❌ Vì sao các phương án còn lại sai

B — "Subnet, giống VPC, có thể trải qua nhiều Availability Zone nhưng nằm gọn trong một Region". Vế sau đúng, vế đầu sai — và đây là phương án gần đúng nhất, dễ mất điểm nhất. VPC thì đúng là trải trên nhiều AZ trong một Region, nhưng một subnet phải nằm trọn trong đúng một AZ. Đó chính là lý do muốn kiến trúc chịu lỗi thì phải tạo nhiều subnet, mỗi cái ở một AZ. Phương án này lấy đặc tính của VPC gán nhầm sang subnet.

D — "Private subnet mặc định không nhận traffic 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". Câu đầu đúng, nhưng câu sau tự mâu thuẫn với định nghĩa: private subnet được định nghĩa chính bằng việc không có route tới Internet Gateway. Thêm route đó vào thì nó trở thành public subnet, chứ không phải "mở đường vào private subnet". Cách để workload trong private subnet đi ra Internet là qua NAT Gateway đặt ở public subnet — và đó là chiều đi ra, không mở chiều đi vào.

F — "Subnet có route tới Internet Gateway, đồng thời có traffic route được tới virtual private gateway cho Site-to-Site VPN, gọi là VPN-only subnet". Phương án này đảo ngược định nghĩa. VPN-only subnet là subnet không có route tới Internet Gateway mà chỉ có route tới virtual private gateway. Có route tới Internet Gateway thì theo định nghĩa nó đã là public subnet rồi.

📌 Điểm cần nhớ

• VPC trải nhiều AZ, subnet nằm trong đúng một AZ. Bất kỳ phương án nào nói subnet span qua nhiều AZ đều sai.
• Loại subnet do route table quyết định, không do tên gọi: có route tới Internet Gateway → public; không có → private; không có IGW nhưng có route tới virtual private gateway → VPN-only.
• Địa chỉ IPv4 nội bộ luôn private ở mọi loại subnet; ra được Internet là nhờ public IP cộng route, không phải nhờ dải nội bộ đổi kiểu.
• Mọi subnet cùng VPC route được tới nhau theo mặc định nhờ route local trong main route table — muốn tách biệt thì phải chủ động dùng security group hoặc network ACL.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một ứng dụng web chạy trên các EC2 instance nằm ở private subnet thuộc hai Availability Zone, và điểm mấu chốt: ứng dụng giao tiếp bằng IPv6. Yêu cầu là các instance này phải ra được Internet để tải bản cập nhật phần mềm, nhưng câu hỏi chốt lại bằng cụm quyết định: "without exposing the instances to the outside world" — không được để bên ngoài chủ động mở kết nối vào.

Vậy có hai ràng buộc phải thỏa cùng lúc, và chính cặp ràng buộc này phân biệt bốn phương án:

1. IPv6, không phải IPv4 — nên NAT gateway (thứ thường dùng cho tình huống này) không phải là câu trả lời, và những gateway chỉ hỗ trợ IPv4 bị loại ngay.
2. Chỉ ra, không cho vào (outbound-only) — nên một Internet Gateway thuần túy, vốn cho phép lưu lượng hai chiều, cũng không đáp ứng.

Thành phần VPC duy nhất trong danh sách vừa dành riêng cho IPv6 vừa mang tính một chiều là egress-only internet gateway.

✅ Vì sao đáp án đúng là đúng

Đáp án B — Egress-only Internet Gateway.

Đây là một thành phần của VPC được thiết kế đúng cho tình huống trong đề: nó cho phép instance trong VPC khởi tạo kết nối ra Internet qua IPv6, đồng thời ngăn Internet khởi tạo kết nối IPv6 vào instance. Đó chính là định nghĩa của "ra được nhưng không bị lộ ra ngoài" mà đề yêu cầu.

Về vận hành, egress-only internet gateway là thành phần được AWS quản lý, mở rộng theo chiều ngang, dư thừa và sẵn sàng cao, nên nó phù hợp với kiến trúc trải trên hai AZ như trong đề mà người vận hành không phải tự dựng thêm gì.

Một điểm cần ghi nhớ kèm theo: egress-only internet gateway chỉ dùng cho lưu lượng IPv6. Nếu bài toán là outbound-only trên IPv4 thì thành phần tương ứng là NAT gateway. Đề bài nêu rõ ứng dụng dùng IPv6, nên B là lựa chọn khớp.

❌ Vì sao các phương án còn lại sai

A — Carrier gateway. Đây là phương án gây nhiễu bằng cách chép lại nguyên văn mô tả của egress-only gateway ("allows outbound communication over IPv6..."), nhưng mô tả đó không đúng với carrier gateway. Carrier gateway chỉ tồn tại cho VPC có subnet nằm trong Wavelength Zone; nó nối Wavelength Zone với mạng của nhà mạng viễn thông và các thiết bị trên mạng đó. Ngoài ra carrier gateway hỗ trợ lưu lượng IPv4, nên nó sai cả về ngữ cảnh triển khai lẫn về họ địa chỉ. Đề bài không hề nhắc tới Wavelength Zone hay mạng nhà mạng.

C — Internet Gateway + gắn địa chỉ IPv6 vào Elastic IP. Phần "Elastic IP" là chỗ hỏng rõ nhất: địa chỉ IPv6 vốn đã là địa chỉ toàn cầu duy nhất và mang tính public, không cần và cũng không được gắn với Elastic IP để "làm cho nó public". Elastic IP là khái niệm của IPv4. Ngay cả khi bỏ qua chi tiết đó, việc dùng Internet Gateway thuần túy vẫn mở đường hai chiều, tức là vi phạm ràng buộc "without exposing the instances to the outside world" của đề.

D — Internet Gateway cho instance trong private subnet. Đây là phương án gần đúng nhất theo kiểu "nghe hợp lý", nhưng nó mâu thuẫn ngay trong chính câu chữ của mình. Internet Gateway được gắn vào VPC và phát huy tác dụng thông qua route table của public subnet — nó không được cấu hình trực tiếp cho private subnet. Nói cách khác, subnet nào có route trỏ ra Internet Gateway thì theo định nghĩa subnet đó trở thành public. Vế thứ hai của phương án ("public subnet mặc định đã nối Internet, không cần cấu hình thêm") cũng là mô tả sai lệch, và quan trọng hơn là nó lạc đề: đề đang hỏi về instance nằm ở private subnet.

📌 Điểm cần nhớ

• Bài toán outbound-only trong VPC có hai lời giải song song theo họ địa chỉ: IPv6 → egress-only internet gateway, IPv4 → NAT gateway. Thấy đề nhấn mạnh "IPv6" là gần như đã khoanh vùng được đáp án.
• Internet Gateway là hai chiều. Hễ đề có cụm "không để lộ instance ra ngoài" / "không cho Internet khởi tạo kết nối vào" thì Internet Gateway trần bị loại, bất kể IPv4 hay IPv6.
• Địa chỉ IPv6 đã là public sẵn; mọi phương án nói phải gắn Elastic IP cho IPv6 để "làm nó public" đều là bẫy.
• Carrier gateway gắn liền với Wavelength Zone. Đề không nhắc tới Wavelength Zone hay mạng nhà mạng thì carrier gateway không phải đáp án, dù mô tả trong phương án có được viết cho giống thứ khác đến đâu.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một tình huống vận hành rất cụ thể: quản trị viên đã cấu hình xong Amazon EC2 Auto Scaling, nhưng khi Auto Scaling Group cố khởi chạy instance thì nhận về đúng một chuỗi lỗi:

Client.InternalError: Client error on launch

Câu hỏi yêu cầu chỉ ra nguyên nhân và cách khắc phục.

Cụm từ quyết định đáp án chính là bản thân mã lỗi Client.InternalError: Client error on launch. Đây là dạng câu hỏi "khớp thông điệp lỗi với nguyên nhân": cả bốn phương án đều là những lý do có thật khiến instance launch failure trong Auto Scaling, nhưng mỗi lý do lại sinh ra một thông điệp lỗi khác nhau. Vì vậy không được đọc lướt kiểu "cái nào nghe cũng hợp lý", mà phải ghép đúng nguyên nhân với đúng chuỗi lỗi mà Auto Scaling ghi vào activity history.

Điểm nhận dạng của Client.InternalError là nó không nêu tên tài nguyên nào bị sai — không nói security group nào, không nói device name nào, không nói instance type nào. Đó là dấu hiệu lỗi nằm ở tầng quyền truy cập trong quá trình launch chứ không phải ở một tham số cấu hình sai chính tả.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là D: lỗi xảy ra khi Auto Scaling group cố khởi chạy một instance có encrypted EBS volume, nhưng service-linked role của Auto Scaling không có quyền truy cập customer-managed CMK (KMS key) đã dùng để mã hoá volume đó.

Cơ chế: khi launch, Auto Scaling hành động thay mặt bạn thông qua service-linked role. Để gắn được một EBS volume đã mã hoá bằng customer-managed CMK, role này phải được phép gọi các thao tác KMS trên chính key đó (giải mã và tạo grant). Nếu key policy — hoặc grant — chưa cho phép role đó, thao tác launch bị KMS từ chối và Auto Scaling trả về Client.InternalError: Client error on launch.

Cách khắc phục là cấu hình thêm quyền trên CMK cho service-linked role của Auto Scaling. Tài liệu AWS tách thành hai kịch bản:

1. CMK và Auto Scaling group nằm trong cùng một AWS account — chỉnh key policy để cấp quyền cho service-linked role.
2. CMK và Auto Scaling group nằm ở hai account khác nhau — phải cấp quyền cross-account trên key rồi tạo grant tương ứng cho role bên account chứa Auto Scaling group.

Lưu ý: điều này chỉ áp dụng với customer-managed CMK. Volume mã hoá bằng AWS managed key mặc định của EBS không đòi bước cấu hình thêm này.

❌ Vì sao các phương án còn lại sai

A. Security group trong launch configuration đã bị xoá — Đây là một nguyên nhân launch failure có thật, nên nó rất dễ được chọn. Nhưng khi security group không còn tồn tại, Auto Scaling báo lỗi có nêu đích danh tên group, đại ý: "The security group <tên> does not exist. Launching EC2 instance failed." Thông điệp này khác hẳn Client.InternalError — nó cụ thể và tự nói ra tài nguyên bị thiếu, nên không khớp đề.

B. Cluster placement group chứa instance type không hợp lệ — Cũng là nguyên nhân thật: không phải mọi họ instance đều dùng được với cluster placement group. Nhưng lỗi sinh ra nêu rõ loại instance vi phạm, đại ý: "Placement groups may not be used with instances of type 'm1.large'. Launching EC2 instance failed." Lại là một thông điệp có tên tài nguyên, không phải Client.InternalError.

C. Block device mappings chứa block device name không khả dụng hoặc không được hỗ trợ — Đây là phương án gần đúng nhất về mặt "chủ đề", vì nó cũng liên quan tới EBS giống đáp án D, dễ khiến người học nhầm rằng "lỗi EBS thì chọn cái nói về block device". Chỗ hỏng của nó là: sai device name là lỗi cú pháp/cấu hình tham số, được EC2 phát hiện và trả về thông điệp chỉ thẳng vào cái tên sai, đại ý "Invalid device name ... Launching EC2 instance failed." Còn D là lỗi phân quyền KMS xảy ra trong lúc thực thi launch — cùng dính EBS nhưng ở hai tầng hoàn toàn khác nhau, và chỉ tầng phân quyền mới sinh ra Client.InternalError.

📌 Điểm cần nhớ

• Client.InternalError: Client error on launch là chữ ký riêng của tình huống encrypted EBS volume + customer-managed CMK + service-linked role thiếu quyền trên key. Thấy đúng chuỗi này thì hướng suy nghĩ đầu tiên là KMS key policy, không phải cấu hình instance.
• Với dạng câu hỏi troubleshooting Auto Scaling, hãy ghép thông điệp lỗi với nguyên nhân, đừng đánh giá phương án theo mức độ "nghe hợp lý". Các nguyên nhân sai cấu hình (security group đã xoá, device name sai, instance type không hợp với placement group) đều trả về lỗi nêu đích danh tài nguyên; lỗi chung chung không nêu tên thường là vấn đề quyền.
• Auto Scaling launch instance thay mặt bạn bằng service-linked role, nên mọi tài nguyên được bảo vệ bằng policy riêng — điển hình là customer-managed CMK — đều cần cấp quyền tường minh cho role đó, kể cả khi người quản trị tự tay tạo được instance đó bình thường.
• Phân biệt hai kịch bản CMK: cùng account thì sửa key policy; khác account thì cần cấp quyền cross-account rồi tạo grant. Đề thi hay hỏi vế thứ hai vì nó dễ bị bỏ sót.

🧩 Phân tích nội dung câu hỏi

Một công ty ngành khách sạn chạy ứng dụng tại on-premises nhưng đẩy dữ liệu khách hàng lên AWS thông qua AWS Storage Gateway. Kiểm toán viên hỏi hai chuyện tách bạch nhau, và đề bài nói rất rõ: dữ liệu có được bảo vệ "while in-transit and at rest in the Cloud" hay không.

Cụm từ quyết định chính là cặp in-transit / at rest — mỗi phương án là một tổ hợp giao thức mã hoá đường truyền + tình trạng mã hoá lưu trữ, nên phải chấm đúng cả hai vế thì phương án mới đúng:

• Vế in-transit: giữa gateway appliance và AWS storage dùng SSL/TLS hay IPsec?
• Vế at rest: cả ba loại gateway (File, Volume, Tape) đều mã hoá được, hay Tape Gateway là ngoại lệ không mã hoá được?

Chỉ cần một trong hai vế sai là loại cả phương án. Hai vế này chia bốn phương án thành đúng bốn tổ hợp, đây là dạng câu "ma trận" điển hình.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là D.

• In-transit: AWS Storage Gateway dùng SSL/TLS để mã hoá dữ liệu truyền giữa gateway appliance và AWS storage. Đây là kênh HTTPS ra endpoint dịch vụ, không phải đường hầm IPsec.
• At rest: mặc định Storage Gateway dùng SSE-S3 (Amazon S3-Managed Encryption Keys) để server-side encrypt toàn bộ dữ liệu nó ghi vào Amazon S3. Nghĩa là công ty không phải bật thêm gì cũng đã có mã hoá at-rest — mặc định đã an toàn.

Ngoài mặc định đó, có thể dùng Storage Gateway API để chuyển sang SSE-KMS với CMK do AWS KMS quản lý: cấu hình được cho file share, cho cached/stored volume, và cho cả virtual tape. Vì vậy vế "Tape không mã hoá được" trong các phương án khác là sai.

❌ Vì sao các phương án còn lại sai

A — IPsec + cả ba loại gateway đều mã hoá at-rest. Vế at-rest của phương án này thực ra khớp với thực tế (File, Volume, Tape đều mã hoá được), nên nhìn thoáng qua rất dễ chọn. Nhưng vế in-transit hỏng: Storage Gateway không dùng IPsec giữa appliance và AWS storage, mà dùng SSL/TLS. Một vế sai là loại.

B — SSL/TLS + Tape Gateway không mã hoá được at-rest. Đây là phương án gần đúng nhất, và là bẫy chính của câu. Vế in-transit đúng hoàn toàn (SSL/TLS). Chỗ hỏng nằm ở vế at-rest: dữ liệu của Tape Gateway cũng nằm trên Amazon S3 (và có thể chuyển xuống lớp lưu trữ Glacier), nên nó cũng được mã hoá — hơn nữa còn cấu hình được SSE-KMS cho virtual tape qua Storage Gateway API. Khẳng định "Tape Gateway data cannot be encrypted at-rest" là sai sự thật.

C — IPsec + Tape Gateway không mã hoá được at-rest. Sai cả hai vế cùng lúc: IPsec không phải giao thức được dùng cho đường truyền gateway ↔ AWS storage, và Tape Gateway vẫn mã hoá được at-rest. Đây là phương án dễ loại nhất.

Lưu ý phần thứ hai của câu hỏi — "công ty cần thay đổi gì để đáp ứng yêu cầu bảo mật?". Với D, câu trả lời hàm ý là không cần thay đổi gì, vì cả in-transit lẫn at-rest đều đã được bảo vệ theo mặc định. Các phương án còn lại ngầm bảo rằng có một lỗ hổng cần vá, và chính vì thế chúng lệch với câu hỏi.

📌 Điểm cần nhớ

• AWS Storage Gateway dùng SSL/TLS cho in-transit giữa gateway appliance và AWS storage. Thấy "IPsec" trong ngữ cảnh Storage Gateway thì gần như chắc chắn là phương án mồi — IPsec thuộc về VPN kiểu Site-to-Site, không phải kênh này.
• At-rest mặc định đã bật: Storage Gateway server-side encrypt dữ liệu ghi vào Amazon S3 bằng SSE-S3, không cần người dùng làm gì thêm. Muốn kiểm soát khoá chặt hơn thì đổi sang SSE-KMS qua Storage Gateway API.
• Cả ba loại gateway đều lưu dữ liệu trong Amazon S3 — File, Volume và Tape — nên không có loại nào "không mã hoá được at-rest". SSE-KMS cấu hình được cho file share, volume và virtual tape.
• Với dạng câu ghép hai mệnh đề (giao thức + tình trạng lưu trữ), hãy chấm từng vế riêng rồi mới loại; phương án bẫy thường đúng một vế để trông thuyết phục.

🧩 Phân tích nội dung câu hỏi

Một startup đã đặt On-Demand Capacity Reservations cho các EC2 instance chạy phân tích dữ liệu, rồi ngạc nhiên khi hóa đơn cao hơn dự kiến. Đề hỏi: đâu là hai điểm quan trọng cần nhớ về On-Demand Capacity Reservations.

Cụm từ quyết định nằm ngay ở tình huống: "costs were much higher than expected" — công ty tưởng "reservation" thì đương nhiên được giảm giá. Đó chính là ngộ nhận mà câu hỏi muốn đánh vào: chữ reserved trong "Capacity Reservation" nói về năng lực tính toán (capacity), không nói về giá. Cụm thứ hai đáng chú ý là "On-Demand" — nó ngụ ý mô hình trả theo mức dùng, không cam kết, khác hẳn Reserved Instances hay Savings Plans.

Hai từ khóa này đủ để tách năm phương án: cái nào nói về tiền và cái nào nói về chỗ chạy máy.

✅ Vì sao đáp án đúng là đúng

A — Capacity Reservations do not offer any billing discounts. Đây là điểm mấu chốt lý giải hóa đơn cao. Capacity Reservation chỉ giữ chỗ năng lực trong một Availability Zone; bạn vẫn trả theo giá On-Demand cho phần năng lực đã giữ — kể cả khi không chạy instance nào trong đó, năng lực đã đặt vẫn bị tính tiền. Muốn có giảm giá thì phải kết hợp Capacity Reservation với Savings Plans hoặc Regional Reserved Instances; bản thân reservation không mang lại chiết khấu nào.

C — On-Demand Capacity Reservations enable you to reserve capacity for your Amazon EC2 instances in a specific Availability Zone for any duration. Đây là định nghĩa chuẩn của tính năng: giữ năng lực trong một AZ cụ thể, với thời lượng tùy ý. Chính vì tách rời khỏi phần chiết khấu mà bạn tạo và quản lý Capacity Reservation độc lập với Savings Plans hay Regional Reserved Instances.

❌ Vì sao các phương án còn lại sai

B — require a fixed one-year or three-year commitment. Sai vì lẫn sang mô hình khác. Cam kết 1 năm / 3 năm là đặc trưng của Savings Plans và Reserved Instances, không phải của On-Demand Capacity Reservations. Loại reservation này không đòi cam kết thời hạn nào — tạo lúc cần, hủy lúc không cần. Đây là phương án gần đúng nhất về mặt "nghe quen tai", và nó mâu thuẫn trực tiếp với phương án C (thời lượng tùy ý), nên hai cái này không thể cùng đúng.

D — transferable from one AWS account to another. Sai ở động từ. Capacity Reservation không chuyển nhượng được sang tài khoản AWS khác. Cái có thật là chia sẻ (share) Capacity Reservation với các tài khoản AWS khác — quyền sở hữu vẫn nằm ở tài khoản gốc, tài khoản kia chỉ được dùng năng lực đã giữ. Phương án này đúng một nửa ý tưởng nhưng dùng sai khái niệm, và trong đề trắc nghiệm thì "transfer" ≠ "share".

E — can be used with Dedicated Hosts, however, they can't be used with placement groups. Sai ở vế đầu. Theo tài liệu, Capacity Reservation không dùng được với cả Dedicated Hosts lẫn placement groups. Phương án cố tình chỉ phủ nhận một trong hai để người học đọc lướt sẽ gật đầu với phần "can't be used with placement groups" (phần này đúng) mà bỏ qua vế "can be used with Dedicated Hosts" (phần này sai). Một mệnh đề ghép chỉ đúng khi cả hai vế đều đúng.

📌 Điểm cần nhớ

• "Reservation" trong Capacity Reservation là giữ chỗ, không phải giữ giá. Muốn giảm giá phải chồng thêm Savings Plans hoặc Regional Reserved Instances lên trên; hai thứ này hoàn toàn độc lập nhau.
• Năng lực đã đặt bị tính tiền dù có chạy instance hay không — đây là nguyên nhân kinh điển của hóa đơn cao bất ngờ trong các câu hỏi Domain Cost Optimization.
• Cam kết 1 năm / 3 năm là dấu hiệu nhận biết Savings Plans và Reserved Instances, không phải On-Demand Capacity Reservations — loại này không cam kết, tạo và hủy tự do, phạm vi là một AZ cụ thể.
• Phân biệt "share" với "transfer": Capacity Reservation chia sẻ được với tài khoản khác nhưng không chuyển quyền sở hữu. Với phương án ghép hai mệnh đề (kiểu "X được, nhưng Y không được"), phải soi từng vế — chỉ cần một vế sai là cả phương án sai.

🧩 Phân tích nội dung câu hỏi

Đề mô tả hạ tầng EC2 của một công ty bán lẻ, và điểm mấu chốt nằm ở cụm "run on Windows OS" kết hợp với "custom metrics that need to be collected by the unified CloudWatch agent".

Hai chi tiết này khoá chặt đáp án:

• "custom metrics" — không phải metric hệ thống mặc định (CPU, memory, disk) mà unified CloudWatch agent tự thu, mà là metric do chính ứng dụng của development team đẩy ra. Muốn agent nhận được loại này thì phải cấu hình một giao thức thu metric tùy biến.
• "Windows OS" — đây chính là ràng buộc phân biệt A với B và D. Unified CloudWatch agent hỗ trợ hai giao thức để nhận custom metrics là StatsD và collectd, nhưng phạm vi hệ điều hành của chúng khác nhau.

Câu hỏi thực chất chỉ kiểm tra một điều: bạn có nhớ giao thức nào chạy được trên Windows Server hay không.

✅ Vì sao đáp án đúng là đúng

A — Configure the CloudWatch agent with StatsD protocol.

Unified CloudWatch agent lấy custom metrics từ ứng dụng hoặc service thông qua StatsD và collectd. Trong đó:

• StatsD được hỗ trợ trên cả Linux server lẫn server chạy Windows Server.
• collectd chỉ được hỗ trợ trên Linux server.

Vì hạ tầng trong đề là Windows, StatsD là giao thức duy nhất trong danh sách dùng được. Cấu hình agent lắng nghe StatsD, ứng dụng đẩy custom metrics tới cổng đó, agent gom lại và gửi lên CloudWatch dưới dạng metric — đúng yêu cầu của development team.

❌ Vì sao các phương án còn lại sai

B — Configure the CloudWatch agent with collectd protocol.

Đây là phương án gần đúng nhất và cũng là bẫy chính. collectd thật sự là một trong hai giao thức mà unified CloudWatch agent hỗ trợ để thu custom metrics, nên nếu chỉ đọc lướt phần "custom metrics" thì nó nghe rất hợp lý. Chỗ hỏng nằm ở nền tảng: collectd là daemon của thế giới Linux/Unix và agent chỉ hỗ trợ nó trên Linux server. Đưa lên Windows là không dùng được. Phương án này đúng về khái niệm nhưng sai về hệ điều hành mà đề đã nêu rõ.

C — Unified CloudWatch agent cannot be custom configured.

Sai hoàn toàn và mang tính distractor thuần tuý. Unified CloudWatch agent vốn được thiết kế để cấu hình được: nó dùng một file cấu hình mô tả metric nào cần thu, log nào cần đẩy, namespace nào, khoảng thời gian bao nhiêu, và có mục riêng cho StatsD/collectd. Nếu mệnh đề này đúng thì cả A lẫn B đều không thể tồn tại — chỉ cần thấy nó mâu thuẫn với ba phương án còn lại là loại được ngay.

D — CloudWatch agent can be configured with either StatsD protocol or collectd protocol ... on windows servers.

Đây là phương án nguy hiểm hơn B, vì nó đúng một nửa. Câu "agent cấu hình được với StatsD hoặc collectd" là đúng nếu nói chung chung, nhưng phần đuôi "on windows servers" phá hỏng nó: trên Windows chỉ còn StatsD, collectd không có mặt. Chọn D nghĩa là bỏ qua đúng cái ràng buộc mà đề cố tình đặt vào. Loại phương án "cả hai đều được" kiểu này rất hay xuất hiện khi đề đã nêu một điều kiện thu hẹp — điều kiện đó tồn tại chính là để loại nó.

📌 Điểm cần nhớ

• Unified CloudWatch agent thu custom metrics qua hai giao thức: StatsD và collectd. Metric hệ thống thông thường thì agent tự thu, không cần hai giao thức này.
• StatsD: Linux + Windows Server. collectd: chỉ Linux. Đây là cặp đối lập được hỏi đi hỏi lại; thấy đề nhắc "Windows" là gần như chắc chắn đáp án nghiêng về StatsD.
• Khi đề nêu rõ hệ điều hành, nền tảng hay region, đó không phải chi tiết trang trí — nó là ràng buộc dùng để loại phương án gần giống.
• Phương án dạng "cả A lẫn B đều dùng được" và phương án phủ định tuyệt đối ("không thể cấu hình") thường là distractor; kiểm tra chúng với chính điều kiện đề nêu trước khi cân nhắc.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một kiến trúc quen thuộc: Application Load Balancer ở trước, một fleet EC2 nằm trong Auto Scaling Group, phía sau là RDS, và cả ba nằm ở các subnet khác nhau trong cùng một VPC. Câu hỏi cuối cùng chỉ hỏi đúng một việc: cấu hình nào tốt nhất để giúp các EC2 instance kết nối ra Internet?

Hai cụm từ trong đề quyết định đáp án:

• "need internet access to be able to download the patches" — nhu cầu là truy cập Internet thông thường, không nêu giới hạn gì về chiều kết nối hay về giao thức địa chỉ.
• "subnets of the VPC" — bối cảnh là một VPC bình thường, không phải Wavelength Zone, không phải mạng nhà mạng viễn thông.

Cần chú ý: đề không nói instance chạy IPv6, cũng không nói phải chặn kết nối đến từ Internet. Thiếu hai ràng buộc đó thì mọi phương án chỉ giải quyết trường hợp đặc biệt (IPv6-only, mạng carrier) đều rơi ra ngoài. Phần lớn các phương án ở đây là những cổng gateway "họ hàng" của Internet Gateway, mỗi cái phục vụ một tình huống hẹp hơn — việc phải làm là so nhu cầu trong đề với phạm vi áp dụng của từng loại gateway.

✅ Vì sao đáp án đúng là đúng

B — Create and attach an Internet Gateway to the VPC. Update the route table of the subnet that hosts the EC2 instances, to route internet traffic via the Internet Gateway.

Internet Gateway là thành phần VPC được scale theo chiều ngang, dự phòng và có tính sẵn sàng cao, cho phép VPC giao tiếp với Internet. Nó phục vụ hai mục đích:

• Làm target trong route table của VPC cho lưu lượng đi ra Internet.
• Thực hiện NAT cho các instance đã được gán địa chỉ IPv4 public.

Internet Gateway hỗ trợ cả IPv4 lẫn IPv6, không gây rủi ro về tính sẵn sàng cũng như không tạo nút thắt băng thông cho lưu lượng mạng, và bản thân việc gắn Internet Gateway vào tài khoản không phát sinh phí riêng.

Điểm quan trọng là B mô tả đủ cả hai bước: gắn Internet Gateway vào VPC và sửa route table của subnet chứa EC2 để trỏ lưu lượng Internet qua nó. Chỉ gắn gateway mà không sửa route table thì subnet vẫn không ra được Internet — đây chính là lỗi hay bị hỏi trong đề thi.

❌ Vì sao các phương án còn lại sai

A — Elastic network interface gắn vào public subnet. Đây là distractor về mặt khái niệm. ENI là network interface ảo mang các thuộc tính như private IPv4 chính, các private IPv4 phụ, Elastic IP, public IPv4, địa chỉ IPv6, security group, MAC address, cờ source/destination check, mô tả. ENI được tạo, gắn vào một instance, tháo ra rồi gắn sang instance khác — khi chuyển ENI, lưu lượng mạng được chuyển hướng sang instance mới. Nhưng không có chuyện "attach một ENI vào public subnet": ENI gắn vào instance, còn subnet chỉ là nơi ENI được tạo ra. Và kể cả có đặt interface ở subnet nào đi nữa, thứ quyết định lưu lượng ra được Internet vẫn là Internet Gateway cộng route table, chứ không phải bản thân interface.

C — Egress-only Internet Gateway. Đây là phương án gần đúng nhất nên phải nói rõ nó hỏng ở đâu. Egress-only Internet Gateway cũng là thành phần scale ngang, dự phòng, sẵn sàng cao, và cũng cho phép lưu lượng đi ra Internet đồng thời chặn Internet chủ động mở kết nối vào instance — nghe rất hợp với việc "tải patch". Vấn đề nằm ở chỗ khác: nó chỉ dùng cho lưu lượng IPv6. Đề không hề nói fleet EC2 chạy IPv6, nên áp Egress-only Internet Gateway vào đây là giả định một điều kiện đề không cho.

D — Carrier gateway. Carrier gateway cho phép lưu lượng vào từ mạng nhà mạng ở một địa điểm cụ thể, và cho phép lưu lượng ra tới mạng nhà mạng và Internet. Nhưng nó chỉ khả dụng với VPC có subnet nằm trong Wavelength Zone, và không có cấu hình kết nối vào từ Internet tới Wavelength Zone qua carrier gateway. Kiến trúc trong đề là ALB + ASG + RDS trong VPC thường, hoàn toàn không có Wavelength Zone, nên carrier gateway không áp dụng được.

📌 Điểm cần nhớ

• Ra Internet trong VPC luôn cần hai thứ: Internet Gateway gắn vào VPC và route table của subnet trỏ lưu lượng Internet qua nó. Phương án nào chỉ nói một nửa là phương án thiếu.
• Internet Gateway hỗ trợ cả IPv4 và IPv6; Egress-only Internet Gateway chỉ dành cho IPv6 và chỉ cho chiều đi ra. Đề không nhắc IPv6 thì đừng chọn nó.
• Carrier gateway gắn liền với Wavelength Zone — thấy từ khoá "carrier" mà đề không nói gì tới Wavelength/5G thì loại ngay.
• ENI gắn vào instance, không gắn vào subnet. Bất kỳ phương án nào nói "attach ENI to a subnet" đều là distractor dựng từ một khái niệm không tồn tại.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một công ty phân tích tài chính lưu confidential reports trong một Amazon S3 bucket, với hai yêu cầu đi kèm nhau:

1. Báo cáo phải được giữ (preserved) đủ 5 năm — đây là dữ liệu nhạy cảm, không được mất trước hạn.
2. Sau 5 năm chúng vô giá trị, mà "manual deletion is often delayed which results in higher storage costs" — xoá tay bị trễ nên tốn tiền lưu trữ.

Cụm từ quyết định là "preserved for 5 years" đặt cạnh "delete the expired reports on-time to save costs". Đề hỏi giải pháp simplest nhưng phải phủ cả hai vế: một cơ chế bảo vệ không cho xoá trong 5 năm, và một cơ chế xoá tự động ngay khi hết 5 năm. Nếu chỉ đọc vế "save costs" thì phương án D trông đủ; nếu chỉ đọc vế "preserved" thì A hoặc C trông đủ. Ràng buộc thật là hai vế cùng lúc, và trong danh sách chỉ có đúng một phương án ghép cả hai.

Chi tiết thứ hai đáng để ý: đề nói về "Retain Until Date" — đây là cách khai báo retention theo từng object version, khác với cách khai báo default retention theo bucket. Phân biệt được hai kiểu khai báo này là chìa khoá loại phương án C.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng là B: đặt "Retain Until Date" trong object lock settings ở mốc 5 năm kể từ ngày tạo object, và tạo một lifecycle policy để xoá object sau 5 năm kể từ ngày tạo.

Cơ chế hoạt động như sau:

• Retention period bảo vệ một object version trong một khoảng thời gian cố định. Khi bạn đặt retention period lên một object version, Amazon S3 lưu một timestamp trong metadata của chính version đó để đánh dấu thời điểm retention hết hạn. Trong suốt thời gian đó, object version không thể bị ghi đè hoặc xoá — kể cả xoá nhầm. Đây là vế "preserved for 5 years".
• Khi retention period hết hạn, object version trở lại trạng thái có thể bị ghi đè hoặc xoá (trừ khi còn legal hold trên nó). Đúng thời điểm đó, lifecycle policy vào cuộc và xoá object 5 năm sau ngày tạo. Đây là vế "delete on-time to save costs", thay cho việc xoá tay hay bị trễ.

Hai cấu hình này được đặt trùng mốc thời gian nên chúng nối tiếp nhau chứ không đánh nhau: object được khoá cứng suốt vòng đời hữu ích, rồi tự biến mất ngay khi khoá mở ra.

Cách khai báo cũng khớp với đề: bạn có thể đặt retention period lên một object version explicitly — tức là chỉ định một Retain Until Date cụ thể cho version đó — hoặc thông qua bucket default setting. Phương án B dùng cách explicit, đúng với thuật ngữ "Retain Until Date" mà đề nêu.

❌ Vì sao các phương án còn lại sai

A — Tắt versioning rồi đặt retention period 5 năm trong object lock settings. Đây là phương án sai về mặt kỹ thuật ngay từ tiền đề. Object Lock chỉ hoạt động trên bucket đã bật versioning; retention period và legal hold áp lên từng object version riêng lẻ. Khi bạn khoá một object version, S3 lưu thông tin khoá trong metadata của version đó, và việc đặt retention hay legal hold chỉ bảo vệ đúng version được nêu trong request. Tắt versioning thì không còn nền tảng cho Object Lock hoạt động — ý tưởng "tắt versioning để khỏi phải tạo retention cho mọi version" nghe có vẻ gọn gàng nhưng nó phá luôn thứ mình định dùng. Ngoài ra phương án này cũng không có cơ chế xoá tự động, nên vế tiết kiệm chi phí vẫn bỏ ngỏ.

C — Cấu hình bucket default settings để chỉ định "Retain Until Date" cho mọi object trong bucket. Đây là phương án gần đúng nhất và là bẫy chính của câu này. Bucket default retention là một tính năng có thật và hoàn toàn hợp lệ, nhưng nó hỏng ở chỗ cách khai báo: khi dùng bucket default settings, bạn không chỉ định một Retain Until Date. Thay vào đó bạn chỉ định một khoảng thời gian (duration), tính bằng ngày hoặc năm, áp cho mọi object version được đặt vào bucket. "Retain Until Date" là một mốc ngày tuyệt đối, chỉ dùng khi đặt retention explicitly trên từng object version — dùng nó ở tầng bucket default là mô tả sai tính năng. Và giống A, phương án này vẫn thiếu hẳn cơ chế xoá tự động sau khi retention hết hạn, nên vấn đề chi phí mà đề nêu vẫn còn nguyên.

D — Chỉ tạo lifecycle policy để xoá object 5 năm sau ngày tạo. Phương án này giải quyết đúng vế chi phí: xoá tự động đúng hạn, không phụ thuộc vào việc ai đó nhớ xoá tay. Nhưng nó chỉ làm được một nửa. Lifecycle policy không ngăn được việc object bị xoá nhầm hay bị ghi đè trong 5 năm đầu — mà đây là confidential reports của một công ty phân tích tài chính, đề nói rõ chúng "should be preserved for 5 years". Không có Object Lock thì bất kỳ ai có quyền xoá đều có thể làm mất báo cáo trước hạn, và lifecycle policy không nói gì về chuyện đó. Đây là kiểu bẫy "đọc đúng một nửa đề bài".

📌 Điểm cần nhớ

• Object Lock đòi hỏi versioning được bật. Retention period và legal hold luôn áp lên object version, không phải lên "object" chung chung. Bất kỳ phương án nào bảo tắt versioning để dùng Object Lock đều loại ngay không cần đọc tiếp.
• Phân biệt hai cách khai báo retention: đặt explicitly trên từng object version thì dùng Retain Until Date (một mốc ngày cụ thể); đặt qua bucket default setting thì khai một duration tính bằng ngày hoặc năm. Đề bài nhắc "Retain Until Date" là gợi ý bạn đang ở tầng object version.
• Object Lock giữ, lifecycle policy xoá — chúng bù nhau chứ không thay nhau. Object Lock ngăn xoá/ghi đè trong thời hạn nhưng không tự dọn dẹp khi hết hạn; lifecycle policy dọn dẹp tự động nhưng không bảo vệ gì trong thời gian còn hiệu lực. Yêu cầu "giữ đủ N năm rồi xoá đúng hạn" cần cả hai.
• Khi đề nêu hai yêu cầu trong hai câu khác nhau (một câu về bảo toàn dữ liệu, một câu về chi phí do xoá trễ), hãy nghi ngờ những phương án chỉ trả lời một câu — chúng thường là các distractor được dựng sẵn để bắt người đọc lướt.
• Sau khi retention period hết hạn, object version có thể bị ghi đè hoặc xoá trừ khi còn legal hold trên nó. Legal hold không có thời hạn và phải được gỡ tường minh — nếu một câu hỏi khác thêm chi tiết này vào, nó sẽ chặn lifecycle policy xoá object.