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

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

Đề mô tả một ứng dụng web dùng Amazon DynamoDB để lưu dữ liệu giao dịch của khách hàng, và SysOps administrator cần thêm khả năng disaster recovery cho bảng này.

Cụm từ quyết định đáp án nằm ở câu thứ hai: "The table should be replicated to another AWS Region." Đây không phải yêu cầu "sao lưu" hay "khôi phục về một thời điểm" — đề nói thẳng là nhân bản (replicate) sang một Region khác. Cụm này loại ngay mọi phương án chỉ tạo bản backup nằm trong cùng Region, và mọi phương án chỉ thêm cách truy vấn dữ liệu trong chính bảng đó.

Khi đề bài DynamoDB nhắc tới "another Region" cùng với "replicated", thì thứ cần nhớ là global tables — tính năng duy nhất trong danh sách phương án thực sự đồng bộ dữ liệu liên tục sang Region khác.

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

D. Enable DynamoDB Streams and add a Global Table Region.

Global tables là dạng bảng DynamoDB được quản lý hoàn toàn, trải trên nhiều Region, cho phép đọc và ghi cục bộ ở từng Region với độ trễ thấp. DynamoDB tự động nhân bản bảng sang các Region mà bạn chọn — đúng yêu cầu "replicated to another AWS Region" của đề.

Điểm mấu chốt về mặt kỹ thuật: global tables dùng DynamoDB Streams làm cơ chế lan truyền thay đổi giữa các bản sao. DynamoDB Streams là dòng thông tin có thứ tự về mọi thay đổi trên item trong bảng; mỗi lần ứng dụng tạo, cập nhật hay xoá item, streams ghi một stream record chứa các thuộc tính khoá chính của item bị thay đổi. Chính vì vậy, quy trình dựng global table gồm hai bước đúng như phương án D mô tả: bật DynamoDB Streams, rồi thêm Region mà bảng cần được nhân bản sang.

Phương án D là phương án duy nhất nêu đủ cả hai bước đó.

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

A. Enable point-in-time recovery to a second AWS Region. — Đây là phương án gần đúng nhất và cũng là bẫy chính. Point-in-time recovery (PITR) là tính năng thật của DynamoDB, nhưng không có tuỳ chọn "bật PITR sang một Region thứ hai". PITR bảo vệ bảng theo trục thời gian, không theo trục địa lý: nó cho phép khôi phục bảng về một thời điểm trong quá khứ. Muốn dữ liệu nằm ở Region khác thì phải thực hiện thao tác restore across Regions — tức là một hành động khôi phục thủ công, chứ không phải một cấu hình nhân bản liên tục như đề yêu cầu.

B. Enable DynamoDB Streams and add a global secondary index (GSI). — Nửa đầu đúng (Streams đúng là thành phần của global table) nên phương án này trông rất giống D, phải đọc kỹ nửa sau. GSI không liên quan gì tới disaster recovery: nó là chỉ mục phụ giúp truy vấn bảng theo khoá khác với khoá chính, và nó nằm trong cùng một bảng, cùng một Region. Thêm GSI không tạo ra bản sao dữ liệu ở Region khác. Chữ "global" trong "global secondary index" nói về phạm vi toàn bảng (khác với local secondary index bị giới hạn theo partition key), hoàn toàn không mang nghĩa "toàn cầu về mặt Region" — đây chính là chỗ dễ nhầm với "global tables".

C. Enable a scheduled on-demand backup. — Backup theo lịch tạo ra bản sao lưu, nhưng dữ liệu vẫn nằm trong cùng Region với bảng gốc. Nếu chính Region đó gặp sự cố, bản backup cũng không truy cập được, nên không có bảo vệ nào cả. Đúng là có thể restore backup sang Region khác, nhưng khi Region đã hỏng thì thao tác đó không thực hiện được — nên phương án này không đáp ứng yêu cầu disaster recovery của đề.

📌 Điểm cần nhớ

• Đề DynamoDB nhắc tới "replicate to another Region" hoặc multi-Region disaster recovery → nghĩ ngay tới global tables; đó là cơ chế nhân bản tự động, liên tục, đa Region.
• DynamoDB Streams là điều kiện tiên quyết của global tables — chúng chính là đường ống lan truyền thay đổi giữa các bản sao. Thấy "Enable DynamoDB Streams" trong phương án thì đọc tiếp nửa sau, vì phần quyết định đúng/sai nằm ở đó.
• Đừng nhầm "global secondary index" với "global table". GSI phục vụ mẫu truy vấn khác nhau trong cùng một Region; global table phục vụ tính sẵn sàng đa Region.
• Backup và PITR bảo vệ theo trục thời gian, không phải trục địa lý. Chúng chống mất dữ liệu do xoá nhầm hay ghi hỏng; muốn chống mất cả Region thì cần nhân bản, vì việc restore sang Region khác chỉ khả thi khi Region gốc còn hoạt động.

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

Đề mô tả một tài khoản Development dùng để kiểm thử một ứng dụng CPU-heavy, và yêu cầu SysOps administrator tìm cách tự động dừng những EC2 instance không còn được dùng để tiết kiệm chi phí.

Cụm từ quyết định đáp án là "CPU-heavy application" kết hợp với "instances that are not in use". Ứng dụng nặng về CPU nghĩa là khi nó thực sự chạy, CPU sẽ cao; ngược lại, CPU thấp kéo dài chính là dấu hiệu đáng tin cậy nhất cho biết instance đang nhàn rỗi. Đề đã chỉ thẳng cho ta biết chỉ số nào phản ánh đúng trạng thái "đang dùng" của workload này — và đó là CPU, không phải I/O của volume, không phải API activity, không phải resource state change.

Điểm phân biệt thứ hai nằm ở chỗ: giải pháp phải tự phát hiện và tự hành động. Nghĩa là cần một cơ chế theo dõi ngưỡng liên tục rồi kích hoạt hành động, chứ không phải một cơ chế tra cứu thủ công hay theo sự kiện.

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

C — CloudWatch alarm theo dõi CPUUtilization, dừng instance khi mức sử dụng dưới 5% trong 30 phút.

CloudWatch alarm hoạt động đúng theo mô hình mà đề cần: nó giám sát một metric, so với ngưỡng đã định trong một khoảng thời gian đã định, và khi điều kiện được thoả thì kích hoạt một action. EC2 nằm trong nhóm action gốc mà CloudWatch alarm hỗ trợ trực tiếp — trong đó có stop instance — nên không cần thêm lớp trung gian nào.

Với ứng dụng CPU-heavy, CPUUtilization là chỉ số phản ánh sát nhất việc instance có đang làm việc hay không. Điều kiện "dưới 5% liên tục 30 phút" cũng được thiết kế đúng cách: có ngưỡng thấp để loại bỏ nhiễu từ các tiến trình nền của hệ điều hành, và có khoảng thời gian đủ dài để tránh dừng nhầm instance đang ở giữa hai pha xử lý. Đây là giải pháp gọn nhất, dùng đúng công cụ cho đúng việc.

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

A — CloudWatch metric với VolumeIdleTime > 1800 giây.

Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì nó vẫn dùng CloudWatch và vẫn dùng ngưỡng 30 phút. Nhưng nó hỏng ở hai chỗ. Thứ nhất, VolumeIdleTime đo khoảng thời gian không có thao tác đọc/ghi nào gửi tới volume — việc hoàn toàn không có một request I/O nào trong suốt 30 phút liên tục là rất khó xảy ra trên một instance đang chạy, nên alarm gần như không bao giờ kích hoạt. Thứ hai, đây là chỉ số về storage, trong khi workload mà đề nêu là CPU-heavy: một tác vụ tính toán thuần có thể chạy hết công suất CPU mà gần như không đụng tới volume, dẫn tới dừng nhầm instance đang bận. Ngoài ra, cách diễn đạt "create a CloudWatch metric" cũng lệch — thứ tạo ra hành động là alarm, không phải metric.

B — Athena tìm trong CloudTrail logs, gọi Lambda để dừng instance khi không có API activity.

Sai ở tín hiệu được dùng làm căn cứ. CloudTrail ghi lại các lời gọi API tới AWS control plane, tức là những thao tác quản lý tài nguyên, chứ không ghi lại việc ứng dụng bên trong instance đang tính toán cái gì. Một instance có thể chạy full CPU nhiều giờ liền mà không phát sinh bất kỳ API call nào — dừng nó theo tiêu chí này là dừng nhầm. Ở chiều ngược lại, thiếu API activity cũng không chứng minh instance đang rảnh. Kiến trúc này cũng nặng và vòng vo hơn hẳn: phải chạy query Athena, phải có cơ chế lên lịch, phải nuôi thêm Lambda — trong khi CloudWatch alarm làm được ngay.

D — AWS Config phát hiện resource state change rồi gọi Lambda để dừng instance.

AWS Config theo dõi thay đổi cấu hình và trạng thái của tài nguyên — ví dụ instance được tạo, bị đổi security group, đổi instance type. Nó trả lời câu hỏi "cấu hình đã thay đổi ra sao", không trả lời câu hỏi "instance này có đang được dùng không". "Nhàn rỗi" không phải là một state change: một instance ngồi không suốt ngày thì cấu hình của nó không đổi gì cả, nên sẽ chẳng có sự kiện nào để kích hoạt Lambda. Phương án cũng không nêu được nó theo dõi loại state change nào, vì thực tế không có loại nào biểu thị được trạng thái nhàn rỗi.

📌 Điểm cần nhớ

• Khi đề hỏi dừng/thu hồi tài nguyên nhàn rỗi, hãy tìm phương án dựa trên metric đo mức sử dụng thật (điển hình là CPUUtilization), không phải dựa trên log quản trị hay sự kiện thay đổi cấu hình.
• CloudWatch alarm có thể trực tiếp thực hiện EC2 action (stop, terminate, reboot, recover). Thấy phương án chèn thêm Lambda chỉ để dừng một instance thì hãy nghi ngờ: nó phức tạp hơn mức cần thiết.
• Phân biệt rõ ba nguồn dữ liệu hay bị trộn lẫn: CloudWatch = hiệu năng và mức sử dụng; CloudTrail = ai gọi API nào; AWS Config = cấu hình tài nguyên thay đổi ra sao. Chọn sai nguồn là sai cả giải pháp dù kiến trúc còn lại hợp lý.
• Hãy để loại workload trong đề dẫn dắt việc chọn metric. Ứng dụng CPU-heavy → nhìn CPU; ứng dụng nặng I/O hoặc mạng mới xét tới metric của volume hay network.
• Một điều kiện dừng tự động tốt luôn có đủ cả ngưỡng lẫn khoảng thời gian duy trì. Phương án chỉ nêu ngưỡng tức thời thường là bẫy, vì nó sẽ dừng nhầm tài nguyên đang ở giữa hai pha xử lý.

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

Đề mô tả một công ty có nhiều production account được quản lý bằng AWS Organizations, và chính sách nội bộ quy định S3 bucket không bao giờ được phép xoá. Câu hỏi yêu cầu tìm cách SIMPLEST để cưỡng chế chính sách đó.

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

• "managed using AWS Organizations" và "all buckets in all accounts" — phạm vi cần chặn là nhiều tài khoản, không phải một tài khoản đơn lẻ. Bất kỳ cơ chế nào chỉ có tác dụng trong ranh giới một account đều tự động rớt.
• "should never be deleted" — yêu cầu là chặn tuyệt đối hành động s3:DeleteBucket, chứ không phải làm cho việc xoá khó hơn hay cần thêm bước xác thực.
• "SIMPLEST" — loại bỏ những cách phải cấu hình lặp lại trên từng bucket hoặc từng account.

Ghép ba ràng buộc lại: cần một cơ chế đặt một lần ở tầng organization, có hiệu lực deny trên toàn bộ account con.

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

Đáp án C — dùng Service Control Policies (SCP) để deny s3:DeleteBucket trên mọi bucket trong mọi account.

SCP là loại organization policy của AWS Organizations, dùng để quản lý quyền tối đa mà các account trong tổ chức có thể có. SCP không tự cấp quyền cho ai; nó đặt trần quyền — một hành động bị SCP deny thì không principal nào trong account đó thực hiện được, kể cả người dùng có IAM policy cho phép, và kể cả root user của account thành viên.

Đúng với đề bài: gắn một SCP deny s3:DeleteBucket ở root của organization (hoặc ở OU chứa các production account) là một thao tác duy nhất phủ lên toàn bộ account con. Đó chính là nghĩa của "SIMPLEST" ở đây — một điểm cấu hình tập trung thay vì nhân bản cấu hình ra từng account, từng bucket. Đây cũng đúng mục đích thiết kế của SCP theo tài liệu AWS Organizations: giữ cho các account luôn nằm trong khuôn khổ access control của tổ chức.

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

A — IAM group với IAM policy deny s3:DeleteBucket: đây là phương án gần đúng nhất và cũng là bẫy chính. Nội dung policy thì hợp lệ, nhưng IAM group là đối tượng nằm trong phạm vi một AWS account. Không có "group xuyên nhiều account" — muốn phủ hết thì phải tạo lại group và policy ở từng account một, rồi phải đảm bảo mọi user đều nằm trong group đó. Vừa không đáp ứng "all accounts" một cách tự nhiên, vừa trái với yêu cầu SIMPLEST, lại còn hở với principal không thuộc group (role, user mới tạo).

B — bật MFA Delete trên tất cả các bucket: hỏng ở hai điểm. Thứ nhất, MFA Delete không cấm xoá, nó chỉ bắt phải có yếu tố xác thực thứ hai — bucket vẫn xoá được, trong khi đề nói "never be deleted". Thứ hai, đây là cấu hình phải bật trên từng bucket, và số bucket trải khắp nhiều production account, nên về mặt vận hành là phương án phức tạp nhất chứ không phải đơn giản nhất. Bucket mới tạo sau này cũng không tự động được bảo vệ.

D — dùng Access Control List để deny s3:DeleteBucket ở tầng organization: sai về mặt khái niệm. Network ACL là cơ chế lọc lưu lượng ở tầng subnet trong VPC, không liên quan tới quyền gọi API. Còn S3 ACL (loại ACL duy nhất có dính tới S3) chỉ cấp quyền đọc/ghi object và bucket ở mức rất thô, không diễn đạt được deny cho một API action như s3:DeleteBucket, và cũng không tồn tại khái niệm ACL áp ở tầng organization. Phương án này ghép ba thứ không khớp nhau.

📌 Điểm cần nhớ

• Đề nhắc AWS Organizations + phạm vi "all accounts" → gần như luôn là SCP. IAM policy, IAM group, IAM role đều chỉ có hiệu lực trong ranh giới một account.
• SCP là giới hạn quyền tối đa, không phải cấp quyền: một hành động bị SCP deny thì IAM policy cho phép cũng vô nghĩa. Đây là điều làm nó thành công cụ cưỡng chế guardrail cấp tổ chức.
• Phân biệt "chặn hẳn" với "làm khó hơn": MFA Delete thuộc nhóm thứ hai. Đề nào dùng chữ never / prevent entirely thì cơ chế chỉ thêm bước xác thực sẽ không đủ.
• ACL không phải công cụ phân quyền API. Network ACL làm việc ở tầng subnet của VPC; S3 ACL chỉ cấp quyền truy cập thô trên bucket/object. Thấy ACL đứng cạnh một tên action IAM như s3:DeleteBucket thì gần như chắc là phương án gài.
• Tiêu chí SIMPLEST trong đề thi thường đồng nghĩa với ít điểm cấu hình nhất và tự động áp cho tài nguyên tạo sau này — ưu tiên giải pháp đặt một lần ở tầng cao thay vì lặp trên từng tài nguyên.

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

Đề mô tả một công ty muốn dùng IAM role kết hợp với một IdP tuân thủ SAML 2.0 để người dùng liên kết (federated users) truy cập được AWS Management Console.

Cụm từ quyết định nằm ở câu thứ hai: "The workflow should open the AWS Management Console on behalf of the user" — luồng phải mở thẳng Management Console thay mặt người dùng. Đây chính là ràng buộc phân biệt các phương án, vì:

• Nếu chỉ cần credentials tạm thời để gọi API hay dùng CLI, thì gọi thẳng AssumeRoleWithSAML là đủ.
• Nhưng để trình duyệt tự nhảy vào Console, cần một thứ trả về URL đăng nhập Console, chứ không phải trả về access key / secret key / session token thô.

Thêm một cụm nữa cần để ý: "SAML 2.0-compliant identity provider". Nó loại ngay những phương án thuộc nhánh web identity federation (Cognito, Login with Amazon, Facebook, Google) — đó là nhánh khác hẳn của federation.

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

Đáp án đúng theo tệp là D — Configure the client to post a SAML assertion and use an AWS SSO endpoint.

Luồng hoạt động: client (trình duyệt của người dùng) post SAML assertion tới AWS SSO endpoint. Endpoint này làm hộ người dùng phần việc còn lại — nó tự gọi API AssumeRoleWithSAML để lấy credentials tạm thời, rồi trả về một URL khiến trình duyệt của người dùng tự động redirect thẳng vào AWS Management Console.

Đúng ràng buộc "open the console on behalf of the user": client không phải tự cầm credentials rồi tự dựng sign-in URL — endpoint gánh toàn bộ chuỗi đó. Đây cũng là lý do phương án nhắc tới cả hai vế: post SAML assertion (đúng chuẩn IdP mà đề nêu) và SSO endpoint (đúng yêu cầu mở Console).

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

B — Configure the client to directly call the AssumeRoleWithSAML API Đây là phương án gần đúng nhất, và cũng là bẫy chính. Đúng ở chỗ: AssumeRoleWithSAML chính là API dùng cho SAML federation, và nó đúng là mắt xích nằm bên trong luồng. Hỏng ở chỗ: API này trả về temporary security credentials, không trả về một phiên Console. Client gọi thẳng API sẽ cầm credentials trong tay và vẫn còn dở dang — chưa mở được Console thay mặt người dùng. Đề đã nói rõ luồng phải mở Console, nên "gọi trực tiếp" là bỏ mất đúng bước mà đề yêu cầu. Chọn B là trả lời cho một câu hỏi khác: "làm sao lấy credentials tạm bằng SAML".

C — Configure the client to directly call the AssumeRoleWithWebIdentity API Sai ở loại federation, không chỉ sai ở cách gọi. AssumeRoleWithWebIdentity dành cho trường hợp người dùng đã xác thực trong ứng dụng web hoặc mobile thông qua một web identity provider (Amazon Cognito, Login with Amazon, Facebook, Google). Đề nói rõ là IdP tuân thủ SAML 2.0 — sai nhánh ngay từ đầu. Ngoài ra nó cũng dính lỗi giống B: gọi trực tiếp thì chỉ ra credentials, không ra Console.

A — Configure the client to post a SAML assertion and use an Amazon Cognito endpoint Phương án này bắt đúng nửa đầu (post SAML assertion) nhưng gửi nhầm chỗ. Amazon Cognito thuộc về web identity federation — dùng cho người dùng của ứng dụng web/mobile, không phải để đưa federated users vào AWS Management Console qua SAML. Nơi cần nhận SAML assertion trong kịch bản này là AWS SSO endpoint, không phải Cognito. Cách bẫy của A rất tinh vi: nó trộn nửa đúng của D với thành phần của nhánh Cognito, nên nếu chỉ nhìn lướt cụm "post a SAML assertion" thì rất dễ chọn nhầm.

📌 Điểm cần nhớ

• Chia hai nhánh federation trước khi so đáp án: IdP theo SAML 2.0 → AssumeRoleWithSAML; IdP kiểu web identity (Cognito, Login with Amazon, Facebook, Google) → AssumeRoleWithWebIdentity. Đề nhắc tên nhánh nào thì loại ngay phương án của nhánh kia.
• Phân biệt "lấy credentials" với "mở Console". API AssumeRole* trả về temporary credentials; muốn trình duyệt vào thẳng AWS Management Console thì cần một endpoint sinh URL đăng nhập và redirect hộ người dùng.
• Cụm "on behalf of the user" trong đề gần như luôn ám chỉ có một endpoint trung gian gánh phần gọi API, chứ không phải client tự gọi trực tiếp.
• Cẩn thận với phương án trộn nửa đúng nửa sai (đúng "SAML assertion" nhưng sai endpoint). Đọc trọn vẹn cả hai vế của mỗi phương án rồi mới chấm.

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

Đề mô tả một SysOps administrator không kết nối được tới EC2 instance, lỗi trả về là "request timed out". Người quản trị kết nối từ public IP 200.10.11.12, instance có private IP 172.31.16.25.

Cụm từ quyết định đáp án nằm ngay trong hai dòng VPC flow log, cụ thể là cặp trạng thái ở gần cuối mỗi dòng:

• Dòng 1: 200.10.11.12 → 172.31.16.25 ... **ACCEPT** — traffic đi vào instance được chấp nhận.
• Dòng 2: 172.31.16.25 → 200.10.11.12 ... **REJECT** — traffic đi ra từ instance bị chặn.

Chiều đi vào đã qua, chiều đi ra bị chặn. Đây chính là ràng buộc phân biệt bốn phương án, vì cả bốn đều xoay quanh hai lớp lọc của VPC (Network ACL và security group) nhân với hai chiều (inbound/outbound). Chỉ cần đọc đúng chiều nào bị REJECT là loại được một nửa, và biết đặc tính stateful/stateless là loại nốt nửa còn lại.

Chi tiết "request timed out" cũng ăn khớp: gói tin đi vào tới nơi nhưng gói trả lời không ra được, nên client ngồi chờ tới khi hết thời gian chứ không nhận được thông báo từ chối tức thì.

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

Đáp án đúng theo tệp là C — Network ACL outbound rules.

Điểm mấu chốt: Network ACL là stateless. Nó không ghi nhớ trạng thái kết nối, nên mỗi chiều traffic được đánh giá độc lập bằng bộ rule tương ứng. Một gói tin được inbound rule cho qua không tự động khiến gói trả lời được đi ra — phải có outbound rule cho phép riêng, kể cả khi đó chỉ là response của kết nối vừa được chấp nhận. Với TCP, response quay về cổng ephemeral của client, nên outbound rule của Network ACL phải mở dải cổng ephemeral thì lưu lượng trả lời mới thoát ra được.

Flow log khớp chính xác với hành vi đó: inbound ACCEPT, outbound REJECT. Cấu hình outbound của Network ACL chưa cho phép traffic trả lời là nguyên nhân hợp lý nhất.

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

A — Network ACL inbound rules. Đây là phương án gần đúng nhất, vì đúng dịch vụ (Network ACL) và bản chất stateless đúng là nguồn gốc rắc rối. Nhưng nó hỏng ở chiều traffic: dòng flow log đầu tiên ghi rõ ACCEPT cho chiều từ 200.10.11.12 vào 172.31.16.25. Inbound rule đã hoạt động đúng, gói tin vào được tới ENI. Vấn đề nằm ở chiều ngược lại, nên sửa inbound rule sẽ không thay đổi được gì.

B — Security group inbound deny rules. Sai ở hai tầng. Thứ nhất, security group không hỗ trợ deny rule — nó chỉ có allow rule, cái gì không được allow thì mặc nhiên bị bỏ qua; nói "security group inbound deny rule" là mô tả một thứ không tồn tại. Thứ hai, kể cả hiểu là "inbound chưa được allow" thì vẫn mâu thuẫn với flow log, vì chiều inbound đang ACCEPT.

D — Security group outbound deny rules. Đúng chiều traffic nhưng vẫn sai vì hai lý do. Một, security group không có deny rule, giống lập luận ở phương án B. Hai, security group là stateful: khi một kết nối đến được chấp nhận ở chiều inbound, traffic trả lời tự động được phép đi ra bất kể outbound rule cấu hình thế nào. Vì vậy, ngay cả khi outbound của security group bị siết chặt, nó cũng không thể là thứ chặn response của một kết nối đã được inbound cho qua.

📌 Điểm cần nhớ

• Network ACL stateless, security group stateful — đây là ranh giới phân biệt được dùng đi dùng lại trong đề thi. Traffic trả lời bị chặn dù chiều vào đã thông thì gần như luôn trỏ về Network ACL, không phải security group.
• Security group chỉ có allow rule. Bất kỳ phương án nào nhắc tới "security group deny rule" đều có thể loại thẳng, không cần đọc phần còn lại.
• Đọc flow log theo cặp địa chỉ nguồn/đích để xác định chiều, rồi mới đọc ACCEPT/REJECT. Chiều nào bị REJECT thì lỗi nằm ở rule của đúng chiều đó.
• Triệu chứng "request timed out" thường gắn với gói tin bị lặng lẽ chặn ở tầng ACL/security group, khác với "connection refused" (thường là không có dịch vụ nghe ở cổng đích).

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

Đề mô tả một EC2 instance chạy ứng dụng tự viết, trong đó có một process lỗi ngốn sạch CPU. Nhóm phát triển chưa vá được, nên giải pháp tạm thời là khởi động lại instance mỗi khi sự cố xảy ra, và việc đó phải tự động.

Cụm từ quyết định nằm ở câu hỏi cuối: "if the issue is experienced for more than 2 minutes". Đây mới là ràng buộc phân biệt, chứ không phải chuyện dùng CloudWatch hay không — vì có tới hai phương án cùng đề xuất "CloudWatch alarm với action reboot", chỉ khác nhau ở loại monitoring. Khi một câu hỏi cho hai phương án giống hệt nhau trừ đúng một chi tiết, chi tiết đó chính là điểm chấm.

Ngưỡng "2 phút" buộc ta phải hỏi: CloudWatch nhận số liệu CPU của EC2 với tần suất bao lâu một lần? Basic monitoring gửi metric theo chu kỳ 5 phút; detailed monitoring gửi theo chu kỳ 1 phút. Một alarm không thể phản ứng nhanh hơn nhịp dữ liệu mà nó đang quan sát.

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

D — CloudWatch alarm với action reboot, dùng detailed monitoring.

CloudWatch alarm hỗ trợ sẵn nhóm alarm actions dành riêng cho EC2: stop, terminate, reboot và recover. Đây là hành động gắn thẳng vào alarm, không cần viết code, không cần Lambda trung gian. Trong đó reboot đúng là hành vi mà nhóm phát triển yêu cầu.

Phần còn lại là chọn nguồn dữ liệu đủ mịn. Với detailed monitoring, metric CPUUtilization được đẩy lên CloudWatch mỗi 1 phút, nên alarm có thể cấu hình period 1 phút và yêu cầu nhiều chu kỳ liên tiếp vượt ngưỡng — tức là diễn đạt được chính xác ý "sự cố kéo dài hơn 2 phút" trước khi kích hoạt reboot. Đây là lý do bản giải thích gốc chốt D: ngưỡng thời gian trong đề nhỏ hơn chu kỳ của basic monitoring, nên chỉ detailed monitoring mới đáp ứng được.

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

A — CloudWatch alarm với action reboot, dùng basic monitoring. Đây là phương án gần đúng nhất, và nó chỉ hỏng ở đúng một chỗ: nguồn dữ liệu quá thưa. Cơ chế alarm action reboot hoàn toàn chính xác, nhưng với basic monitoring, CloudWatch chỉ có một điểm dữ liệu CPU sau mỗi 5 phút. Alarm không thể kết luận "đã vượt ngưỡng hơn 2 phút" khi nó còn chưa có điểm dữ liệu thứ hai. Kết quả là phản ứng luôn chậm hơn yêu cầu của đề — không sai về kiến trúc, mà sai về độ phân giải thời gian.

B — Tạo một "AWS CloudTrail API action" để reboot khi tài nguyên bị dùng hết. Phương án này sai ngay từ vai trò của dịch vụ. CloudTrail là dịch vụ ghi nhận (audit log) các lời gọi API trong tài khoản — nó ghi lại việc ai đã gọi RebootInstances, chứ bản thân nó không phát ra lời gọi API nào. Ngoài ra CloudTrail không quan sát metric hiệu năng như CPU, nên cũng không có cách nào để nó biết "tài nguyên đã bị dùng hết". Khái niệm "CloudTrail API action" trong phương án này không tồn tại.

C — EventBridge rule chạy Lambda theo lịch để reboot instance. Phương án này về mặt kỹ thuật là làm được — EventBridge gọi Lambda, Lambda gọi API reboot. Nhưng nó hỏng ở chữ "on a schedule": reboot sẽ diễn ra theo lịch cố định bất kể instance có đang gặp sự cố hay không. Như vậy vừa reboot thừa khi máy đang khoẻ (gây gián đoạn vô cớ), vừa reboot trễ khi sự cố xảy ra ngay sau một lần chạy. Đề yêu cầu phản ứng theo tình trạng CPU, tức là hành động phải được kích hoạt bởi điều kiện, không phải bởi đồng hồ. Chưa kể giải pháp này còn phải tự viết và tự bảo trì Lambda, trong khi CloudWatch đã có sẵn action reboot.

📌 Điểm cần nhớ

• CloudWatch alarm có sẵn bốn alarm action dành cho EC2: stop, terminate, reboot, recover. Gặp yêu cầu "tự động dừng/khởi động lại/khôi phục EC2 theo điều kiện metric", hãy nghĩ tới alarm action trước khi nghĩ tới Lambda.
• Basic monitoring = chu kỳ 5 phút, detailed monitoring = chu kỳ 1 phút. Bất cứ khi nào đề nêu một ngưỡng thời gian ngắn hơn 5 phút, đó là tín hiệu buộc chọn detailed monitoring.
• Alarm không thể phản ứng nhanh hơn tần suất mà metric được gửi lên. Độ nhạy của cảnh báo bị chặn trên bởi độ mịn của dữ liệu.
• Phân biệt rõ vai trò: CloudTrail ghi lại lời gọi API; CloudWatch quan sát metric và kích hoạt hành động; EventBridge định tuyến sự kiện — và rule theo lịch thì khác hẳn rule theo sự kiện/điều kiện.
• Khi hai phương án chỉ khác nhau đúng một chi tiết, chi tiết đó chính là thứ đề đang chấm — đọc kỹ ràng buộc trong đề để chọn.

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

Đề mô tả một web platform nhiều tầng chạy trên hai EC2 instance nằm trong cùng một Availability Zone ở Region eu-west-1. Nhiệm vụ của SysOps administrator là chuyển một trong hai instance sang một Availability Zone khác, và câu hỏi là: thủ tục nào thực hiện được việc đó.

Cụm từ quyết định đáp án là "migration of one of the EC2 instances to an alternative Availability Zone" — tức là đổi AZ của một instance đã tồn tại. Điểm mấu chốt nằm ở một sự thật kỹ thuật về EC2: Availability Zone là thuộc tính được ấn định lúc launch instance và không sửa được trong suốt vòng đời của nó. Instance luôn nằm trong một subnet, mà subnet thì gắn chặt với đúng một AZ; muốn "sang AZ khác" nghĩa là phải nằm trong subnet khác, và không có thao tác nào đổi subnet/AZ của một instance đang tồn tại.

Vì vậy, bốn phương án thực chất chia làm hai nhóm: nhóm khẳng định có thể "di chuyển trực tiếp" (A, B, D) và nhóm tạo instance mới ở AZ đích rồi bỏ instance cũ (C). Ràng buộc phân biệt chính là ở chỗ đó — không phải công cụ nào (Console hay CLI), mà là có tạo lại instance hay không.

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

Theo tệp, đáp án đúng là C — tạo một Amazon Machine Image (AMI) từ instance hiện có, launch nó trong AZ mới, rồi terminate instance cũ.

AMI là bản chụp toàn bộ cấu hình phần mềm của instance: hệ điều hành, các gói đã cài, cấu hình ứng dụng và nội dung của volume gốc. Sau khi có AMI, ta launch một instance mới từ AMI đó và chọn subnet thuộc AZ đích ngay tại bước launch. Instance mới vì thế giống hệt bản cũ về mặt phần mềm nhưng nằm ở AZ mong muốn. Bước cuối cùng — terminate instance cũ — hoàn tất "migration": kết quả vẫn là hai instance như ban đầu, nhưng nay trải trên hai AZ.

Đây chính là quy trình AWS khuyến nghị cho việc chuyển EC2 instance sang AZ khác: không di chuyển, mà tái tạo. Nó cũng là phương án duy nhất trong danh sách tôn trọng ràng buộc AZ bất biến của EC2.

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

A — "Relocate the EC2 instance to an alternative Availability Zone using AWS Management Console." Đây là phương án dễ nhầm nhất vì Console đúng là nơi làm mọi thứ với EC2. Nhưng Console không có chức năng "relocate"/"move" instance sang AZ khác. Bạn có thể thay đổi instance type, thay đổi security group, gắn/tháo volume — nhưng không có nút nào đổi AZ. Phương án này giả định tồn tại một thao tác không có thật.

B — "Shutdown the EC2 instance, alter the Availability Zone, and subsequently restart the instance." Đây là phương án gần đúng nhất và cũng là cái bẫy tinh vi nhất, vì nó vay mượn từ một hành vi có thật: khi stop rồi start lại một instance, AWS đặt instance lên một host vật lý khác. Nhiều người suy diễn từ đó rằng stop/start "đổi được vị trí". Nhưng nó chỉ đổi host bên trong cùng một AZ, không đổi AZ — bởi ENI và subnet của instance vẫn giữ nguyên, mà subnet thì thuộc một AZ cố định. Ngoài ra, ở trạng thái stopped cũng không có thuộc tính AZ nào để "alter". Bước giữa của phương án này đơn giản là không tồn tại.

D — "Use AWS CLI to directly transfer the EC2 instance to a different Availability Zone." Sai vì cùng một lý do với A, chỉ đổi công cụ. AWS CLI là một giao diện khác gọi vào cùng bộ EC2 API mà Console dùng; không có API/lệnh nào thực hiện việc chuyển trực tiếp instance sang AZ khác. Đổi từ Console sang CLI không tạo ra khả năng mới — nếu API không hỗ trợ thì mọi công cụ đều bó tay như nhau. Đây là dạng bẫy quen thuộc: đề đưa hai phương án giống hệt nhau về bản chất, chỉ khác công cụ, để xem thí sinh có hiểu giới hạn nằm ở tầng API hay không.

📌 Điểm cần nhớ

• Availability Zone của EC2 instance được ấn định lúc launch và không sửa được. Mọi phương án chứa động từ "move", "relocate", "transfer", "change AZ" cho một instance đang tồn tại đều sai, bất kể dùng Console, CLI hay SDK.
• Chuyển EC2 sang AZ khác = tạo AMI → launch từ AMI vào subnet của AZ đích → terminate instance cũ. Đây là mẫu câu trả lời chuẩn cho cả nhóm câu hỏi "move instance across AZ" và, với thao tác tương tự qua AMI copy, cả "move across Region".
• Stop/start chỉ đổi host vật lý, không đổi AZ. Nhớ rạch ròi hai khái niệm này để không rơi vào bẫy như phương án B.
• Console và CLI có cùng tập khả năng vì cùng gọi một bộ API. Khi hai phương án chỉ khác nhau ở công cụ, chúng thường cùng đúng hoặc cùng sai — hãy hỏi "API có hỗ trợ việc này không", chứ đừng chọn theo công cụ nghe có vẻ mạnh hơn.

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

Đề mô tả một ứng dụng nằm sau internet-facing Application Load Balancer (ALB), và người quản trị muốn dùng AWS WAF để implement rate limiting cho ALB nhằm giảm rủi ro DDoS.

Cụm từ quyết định đáp án là "rate limiting" — giới hạn theo tốc độ request. Nó loại ngay mọi phương án dựa trên IP match condition: điều kiện khớp IP là danh sách địa chỉ tĩnh do bạn tự khai, nó không đếm số request trong một khoảng thời gian. Chỉ rate-based rule của AWS WAF mới làm được việc "đếm request từ một IP trong cửa sổ thời gian rồi hành động khi vượt ngưỡng".

Cụm thứ hai là hướng của hành động: mục tiêu là chặn lưu lượng vượt ngưỡng, còn lưu lượng bình thường vẫn phải đi qua. Trong web ACL, hai thứ phải khớp với nhau về logic:

• default action = việc làm với request không khớp rule nào
• action của rule = việc làm với request khớp rule

Vậy lưu lượng bình thường (không khớp rate-based rule) phải rơi vào default action allow, còn rule khớp ngưỡng phải mang action block.

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

Đáp án đúng theo tệp là A — web ACL với default action là allow, cộng một rate-based rule với action block, rồi associate web ACL đó với ALB.

Đúng ở cả ba mặt:

• Rate-based rule là đúng loại rule: nó theo dõi số request đến từ mỗi địa chỉ IP trong một cửa sổ thời gian trượt và áp dụng action khi IP đó vượt ngưỡng bạn đặt. Khi lưu lượng từ IP đó lắng xuống dưới ngưỡng, AWS WAF tự gỡ hành động ra — không cần ai vào sửa danh sách bằng tay.
• Action block trên rule đúng với ý định: "vượt ngưỡng thì chặn".
• Default action allow giữ cho toàn bộ lưu lượng người dùng bình thường tiếp tục tới ứng dụng.
• Associate với ALB là bước bắt buộc — web ACL không có tác dụng gì cho tới khi được gắn vào tài nguyên; AWS WAF hỗ trợ gắn web ACL trực tiếp vào Application Load Balancer.

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

B — default allow + regular rule block theo IP match condition. Đây là phương án gần đúng nhất về hướng logic: default allow, rule block, chiều hành động hoàn toàn hợp lý. Chỗ hỏng nằm ở loại rule. IP match condition chặn một tập địa chỉ IP mà bạn phải biết trước và khai sẵn; nó không đếm tốc độ, nên không phải rate limiting. Với DDoS, IP nguồn thường rất nhiều và thay đổi liên tục, danh sách tĩnh luôn đi sau kẻ tấn công. Đề yêu cầu rate limiting, phương án này không thực hiện rate limiting.

C — default block + rate-based rule allow. Loại rule thì đúng, nhưng chiều hành động bị đảo ngược hoàn toàn. Default action block nghĩa là mọi request không khớp rule nào đều bị chặn — tức là bạn vừa khoá cửa với toàn bộ người dùng hợp lệ. Còn rate-based rule mang action allow lại đi cho phép đúng nhóm lưu lượng đã vượt ngưỡng — ngược hẳn ý định. Kết quả là chặn người dùng thường và mở đường cho lưu lượng bùng phát.

D — default block + regular rule allow theo IP match condition. Sai cả hai điểm cùng lúc: sai loại rule (IP match condition không phải rate limiting, như đã nói ở B) và sai chiều default action (block mặc định làm hỏng lưu lượng hợp lệ, như ở C). Mô hình này chỉ hợp với bài toán allow-list — chỉ cho một nhóm IP đã biết vào — chứ không phải bài toán giảm nhẹ DDoS cho một ứng dụng công khai trên Internet.

📌 Điểm cần nhớ

• "Rate limiting" trong đề bài luôn ánh xạ sang rate-based rule của AWS WAF. Regular rule với IP match condition chỉ xử lý được tập IP tĩnh đã biết, không đếm được tốc độ request.
• Default action và action của rule phải bù nhau. Muốn "chặn cái xấu, cho qua phần còn lại" thì default = allow, rule = block. Muốn "chỉ cho phép danh sách trắng" mới dùng default = block, rule = allow. Thấy default block trên một web ACL bảo vệ ứng dụng công khai là dấu hiệu đáng ngờ ngay.
• Web ACL phải được associate với tài nguyên mới có hiệu lực. AWS WAF gắn được trực tiếp vào Application Load Balancer, nên với ALB không cần chèn thêm lớp nào ở giữa.
• Rate-based rule tự phục hồi. Nó chặn khi IP vượt ngưỡng và tự bỏ chặn khi lưu lượng từ IP đó giảm về dưới ngưỡng, khác hẳn danh sách IP tĩnh phải cập nhật thủ công.

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

Đề mô tả một ứng dụng chạy trên hàng trăm EC2 instance nằm trong private subnet, do EC2 Auto Scaling liên tục launch và terminate trải trên ba Availability Zone. Ứng dụng gọi ra một third-party API qua public internet, và SysOps administrator phải đưa cho bên thứ ba một danh sách địa chỉ IP tĩnh để họ whitelist trong firewall.

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

• "private subnets" — instance không có public IP, muốn ra internet phải đi qua một thành phần trung gian có IP công khai.
• "Auto Scaling ... launches and terminates instances" — tập hợp instance thay đổi liên tục, nên bất kỳ giải pháp nào gắn IP lên từng instance đều tạo ra một danh sách IP luôn biến động, trái ngược với yêu cầu.
• "static IP addresses ... whitelist" — cần một số lượng IP nhỏ, cố định, không đổi theo vòng đời instance.

Ghép ba ràng buộc lại: cần một điểm ra internet dùng chung, có IP tĩnh, và đặt ở mỗi AZ để chịu được sự cố một AZ.

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

Đáp án đúng là C — Configure a NAT gateway in the public subnet of each AZ. Add a route to the NAT gateway to the route table of each private subnet.

NAT gateway khi tạo trong public subnet bắt buộc phải gắn một Elastic IP address. Mọi lưu lượng đi ra từ private subnet qua NAT gateway đều bị network address translation: địa chỉ nguồn IPv4 của kết nối tới third-party API bị đổi thành chính Elastic IP của NAT gateway.

Nhờ vậy bên thứ ba chỉ cần whitelist đúng các Elastic IP của NAT gateway — ở đây là ba cái, mỗi AZ một cái. Đó là những địa chỉ tĩnh, không đổi khi instance sinh ra hay bị huỷ.

Điểm mạnh thứ hai: giải pháp này không đòi thay đổi gì về sau. Instance mới do Auto Scaling launch ra tự động đi theo route table của subnet nó nằm trong, tức là đi qua NAT gateway, nên nó ra internet với đúng IP đã được whitelist mà không cần thao tác thêm. Đặt NAT gateway ở public subnet của từng AZ cũng đúng thực hành: lưu lượng không phải đi chéo AZ và sự cố một AZ không cắt đường ra internet của hai AZ còn lại.

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

A — Attach an Elastic IP address to each EC2 instance. Configure a VPC endpoint for outbound traffic. Sai ở cả hai vế. Elastic IP không nên gán cho instance nằm trong private subnet, và kể cả làm được thì với hàng trăm instance bị Auto Scaling thay liên tục, danh sách IP sẽ đổi mỗi lần scale — đúng thứ mà yêu cầu whitelist không chấp nhận. VPC endpoint cũng không phải công cụ cho lưu lượng internet: nó dùng để tới các dịch vụ AWS mà không ra internet, không giúp gọi một third-party API công cộng.

B — Attach an Elastic IP address to the internet gateway in the public subnet. Add a route to the internet gateway to the route table of each private subnet. Đây là phương án nghe gần đúng nhất vì nó có nhắc tới internet gateway, nhưng hỏng ở hai chỗ. Thứ nhất, không gắn được Elastic IP vào internet gateway — internet gateway không phải là thứ mang địa chỉ IP theo cách đó. Thứ hai, trỏ route ra internet gateway trong route table của private subnet cũng vô nghĩa: instance ở đó không có public IP, nên internet gateway không có gì để dịch địa chỉ và kết nối vẫn không ra được.

D — Attach an Elastic IP address to each AZ. Associate the Elastic IP with the EC2 instances within each AZ. Sai ngay ở khái niệm: Elastic IP không gắn được vào một Availability Zone. Elastic IP gắn vào EC2 instance, NAT gateway và một số network service khác, chứ AZ không phải đối tượng nhận Elastic IP. Vế sau lại quay về gán Elastic IP cho từng instance, gặp lại đúng vấn đề của phương án A với môi trường Auto Scaling.

📌 Điểm cần nhớ

• Đề bài có private subnet + Auto Scaling + yêu cầu IP tĩnh để whitelist thì gần như luôn là NAT gateway: nó gom lưu lượng ra của cả subnet về một Elastic IP cố định, tách IP công khai khỏi vòng đời instance.
• Gắn Elastic IP cho từng instance là mẫu sai kinh điển khi có Auto Scaling — danh sách IP biến động, không whitelist được, lại còn không hợp với instance trong private subnet.
• Phân biệt vai trò: internet gateway cho phép subnet ra internet nhưng cần instance có public IP và không nhận Elastic IP; NAT gateway mới là thứ mang Elastic IP và làm địa chỉ nguồn chung.
• VPC endpoint không dùng cho lưu lượng internet — nó là đường tới dịch vụ AWS mà không cần ra internet, thấy nó trong câu hỏi về third-party API công cộng thì loại được ngay.
• Triển khai NAT gateway ở public subnet của mỗi AZ là mẫu chuẩn cho tính sẵn sàng: một AZ hỏng không kéo theo mất đường ra của các AZ còn lại.

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

Đề mô tả một công ty đang dùng AWS CloudTrail, log file được giao vào S3, và yêu cầu là phải xác định được log file có bị sửa, bị xoá, hay còn nguyên vẹn hay không. Câu hỏi kết thúc bằng "How can a SysOps administrator meet this requirement MOST efficiently?".

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

• "determine if log files are modified, deleted, or unchanged" — đây chính là định nghĩa của tính toàn vẹn (integrity), không phải tính bảo mật (confidentiality). Cụm này loại ngay mọi phương án nói về mã hoá.
• "MOST efficiently" — nghĩa là ưu tiên tính năng có sẵn của dịch vụ, không tự dựng cơ chế riêng. Cụm này loại phương án tự viết code kiểm tra hash.

Còn một chi tiết nhỏ nhưng là bẫy chính của câu này: tính năng log file validation được bật ở trail, chứ không phải ở bucket. Đề cố tình nhắc tới cả CloudTrail lẫn S3 để hai phương án B và D trông giống hệt nhau, chỉ khác ở chỗ bật cờ trên đối tượng nào.

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

D — "Update the trail and enable log file validation" là đáp án đúng theo tệp.

CloudTrail có sẵn tính năng log file integrity validation. Khi bật, ngoài các log file thông thường, CloudTrail còn giao thêm digest file định kỳ vào bucket. Digest file chứa hash SHA-256 của từng log file trong khoảng thời gian đó, và bản thân digest file được ký số bằng SHA-256 with RSA bằng private key do AWS giữ. Mỗi digest file cũng tham chiếu tới digest file trước đó, tạo thành một chuỗi liên tiếp.

Cơ chế này trả lời đúng cả ba trạng thái mà đề hỏi:

• Modified — hash của log file không khớp giá trị ghi trong digest file.
• Deleted — digest file vẫn liệt kê một log file mà thực tế không còn trong bucket.
• Unchanged — hash khớp và chữ ký của digest file hợp lệ.

Vì digest file được ký số, kẻ tấn công không thể vừa sửa log vừa sửa hash cho khớp mà không bị phát hiện. Đây là tính năng gắn với cấu hình của trail, nên thao tác đúng là mở trail ra và bật tuỳ chọn Enable log file validation — chỉ một thay đổi cấu hình, không viết code, không vận hành thêm gì, đúng tiêu chí "MOST efficiently".

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

A — Lambda tính MD5 hash của log file. Đây là phương án gần đúng nhất về mặt ý tưởng: nó đúng hướng tính toàn vẹn. Nhưng nó hỏng ở hai chỗ. Thứ nhất, về vận hành: bạn phải tự dựng event notification, tự viết và bảo trì hàm Lambda, tự chọn nơi lưu hash — mà nơi lưu hash đó lại cần được bảo vệ tiếp, nếu không kẻ tấn công sửa log rồi sửa luôn hash. Chuỗi ký số của CloudTrail giải quyết sẵn vấn đề này. Thứ hai, giải pháp tự dựng chỉ chạy sau khi log đã tới S3, còn khoảng trống giữa lúc CloudTrail giao file và lúc Lambda kịp tính hash. Đề hỏi cách hiệu quả nhất, mà đây là cách tốn công nhất trong danh sách.

B — Update the S3 bucket và bật log file validation. Đây là bẫy chính. Nội dung tính năng thì đúng, nhưng đặt sai chỗ: log file validation là thuộc tính của trail trong CloudTrail, không phải một tuỳ chọn của S3 bucket. Bucket không có công tắc nào tên như vậy. Chọn B nghĩa là nhớ đúng tên tính năng nhưng nhầm dịch vụ cấu hình nó — và trong bài thi thì vẫn là sai.

C — Bật default encryption trên S3 bucket. Nhầm lẫn kinh điển giữa confidentiality và integrity. Mã hoá đảm bảo người không có quyền thì không đọc được nội dung, nhưng hoàn toàn không cho biết file có bị sửa hay xoá hay không. Ai có quyền ghi/xoá trên bucket vẫn xoá được object đã mã hoá, và việc xoá đó không để lại tín hiệu nào cho người kiểm tra. Mã hoá là biện pháp bảo vệ tốt và nên bật, nhưng nó không trả lời được câu hỏi mà đề đặt ra.

📌 Điểm cần nhớ

• Từ khoá "modified, deleted, or unchanged" trong đề luôn trỏ tới CloudTrail log file integrity validation, không phải mã hoá, không phải versioning, không phải giải pháp tự dựng.
• Encryption ≠ integrity. Mã hoá chống đọc trộm; hash và chữ ký số chống sửa/xoá lén. Đề hỏi vế nào thì bám vế đó.
• Log file validation được bật ở trail, không ở bucket. Khi hai phương án chỉ khác nhau ở "update the trail" và "update the S3 bucket", hãy tự hỏi tính năng đó thuộc cấu hình của dịch vụ nào.
• Gặp "MOST efficiently" hoặc "least operational overhead", hãy chọn tính năng có sẵn (managed feature) thay vì phương án tự viết Lambda/script — kể cả khi phương án tự viết về mặt kỹ thuật cũng làm được việc.