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

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

Đề mô tả một EC2 instance vốn nằm ở public subnet, nay bị chuyển sang private subnet để tăng độ an toàn. Từ lúc chuyển, instance không tự cập nhật (automatic update) được nữa.

Cụm từ quyết định đáp án là "unable to automatically update" — tức là instance cần gọi ra Internet để tải gói cập nhật về. Đây là lưu lượng outbound do chính instance khởi tạo, không phải lưu lượng inbound từ ngoài vào.

Cụm thứ hai cần chú ý là "moved to a private subnet". Theo định nghĩa, private subnet là subnet mà route table không có đường ra internet gateway. Nên vấn đề nằm ở định tuyến (routing), chứ không phải ở firewall hay ở khả năng phân phối tải.

Vậy đề đang hỏi: cách nào cho phép instance ở private subnet đi ra Internet mà không biến nó thành thứ Internet đi vào được.

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

A — Set up a NAT gateway in a public subnet and add a route to the private subnet route table.

NAT gateway sinh ra đúng để giải quyết bài toán này. Hai vế của phương án đều phải có mặt:

• NAT gateway đặt ở public subnet: bản thân NAT gateway cần đi ra Internet được, nên nó phải nằm trong subnet có route trỏ tới internet gateway. Đặt sai chỗ thì chính nó cũng không ra ngoài được.
• Thêm route vào route table của private subnet: đây mới là thứ chữa được triệu chứng. Route cho lưu lượng Internet của private subnet trỏ tới NAT gateway, gói tin của instance đi qua đó và được dịch địa chỉ nguồn thành địa chỉ công khai của NAT gateway.

Điểm mấu chốt về bảo mật: NAT gateway chỉ cho kết nối đi ra và cho phản hồi của chính kết nối đó quay về. Không ai từ Internet mở được kết nối vào instance. Nghĩa là instance vẫn giữ nguyên mức an toàn mà việc chuyển sang private subnet mang lại, đồng thời cập nhật lại chạy được — đúng cả hai yêu cầu ngầm của đề.

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

B — Modify the instance security group to allow traffic from the internet into the private subnet.

Sai ở hai tầng. Thứ nhất, security group hoạt động ở mức instance (ENI), không ở mức subnet — thứ lọc theo subnet là Network ACL, nên chính cách diễn đạt "allow traffic into the private subnet" bằng security group đã không đúng cơ chế. Thứ hai, kể cả có mở thì cũng vô ích: security group là stateful, lưu lượng ra đã được cho phép sẵn và phản hồi tự động quay về; cái đang thiếu là route ra Internet, không phải quyền. Ngoài ra phương án này mở chiều inbound từ Internet — đi ngược hẳn lý do người ta chuyển instance vào private subnet.

C — Add a Network Load Balancer to a public subnet and configure the EC2 instance as a target.

Đây là phương án dễ chọn nhầm vì nó có nhắc "public subnet" và có vẻ nối được instance với Internet. Nhưng load balancer phân phối kết nối đi vào tới các target — nó giải bài toán "làm sao người dùng ngoài truy cập được ứng dụng". Đề đang cần chiều ngược lại: instance chủ động gọi ra để tải bản cập nhật. Đặt NLB trước instance không tạo ra đường outbound nào cho instance cả, cập nhật vẫn hỏng nguyên như cũ.

D — Set up a NAT gateway in a private subnet and add a route to the public subnet route table.

Đây là phương án gần đúng nhất, và cũng là bẫy chính của câu hỏi — nó dùng đúng dịch vụ nhưng đảo ngược cả hai vế. NAT gateway nằm trong private subnet thì bản thân nó không có đường ra internet gateway, nên chẳng dịch được gói tin đi đâu. Còn thêm route vào route table của public subnet là sửa nhầm chỗ: public subnet vốn đã ra Internet được rồi, subnet đang kẹt là private subnet. Nhớ quy tắc: NAT gateway ở public subnet, route sửa ở private subnet.

📌 Điểm cần nhớ

• Phân biệt chiều lưu lượng trước khi chọn: instance cần đi ra → NAT gateway; người dùng ngoài cần đi vào → load balancer hoặc internet gateway. Chọn nhầm chiều là loại được ngay một nửa phương án.
• Công thức NAT gateway: đặt ở public subnet, sửa route table của private subnet. Mọi biến thể đảo hai vế đều là phương án sai được dựng cố ý.
• Security group ở mức instance và stateful; Network ACL ở mức subnet và stateless. Phương án nào nói security group lọc theo subnet là sai ngay từ cách diễn đạt.
• "Private subnet" nghĩa là route table không có đường tới internet gateway. Triệu chứng "mất kết nối sau khi chuyển subnet" gần như luôn là vấn đề định tuyến, không phải vấn đề quyền.

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

Đề mô tả một tình huống rất quen: số lượng IAM policy trong tài khoản ngày một phình ra, và security team muốn biết hiện đang dùng bao nhiêu policy so với mức tối đa cho phép. Câu hỏi chốt lại ở một dòng duy nhất: dùng dịch vụ nào để "compare the current IAM policy usage against the existing service limits".

Cụm từ quyết định đáp án là "service limits" (hạn mức dịch vụ), đi kèm với động từ "compare against". Đây không phải câu hỏi về việc ai đã tạo policy nào, cũng không phải về việc policy đang cấu hình ra sao — mà là câu hỏi về mức tiêu thụ so với trần hạn mức. Ba phương án còn lại đều là những dịch vụ hợp lệ và hay xuất hiện trong đề thi AWS, nhưng không dịch vụ nào trong số đó có khái niệm "trần hạn mức" trong đầu ra của nó. Bắt được chữ service limits là gần như chọn xong đáp án.

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

A — AWS Trusted Advisor.

Trusted Advisor đưa ra khuyến nghị theo thời gian thực dựa trên best practice của AWS, và các check của nó được nhóm theo nhiều hạng mục: chi phí, hiệu năng, bảo mật, khả năng chịu lỗi, và service limits. Chính nhóm check cuối cùng là thứ đề bài đang cần: nó liệt kê mức sử dụng hiện tại của một tài nguyên bên cạnh hạn mức áp cho tài khoản, và cảnh báo khi mức dùng tiến gần trần.

Với tình huống trong đề, quản trị viên mở Trusted Advisor, xem check thuộc nhóm service limits liên quan tới IAM, và đọc được ngay hai con số cần so sánh: số policy đang tồn tại và số policy tối đa. Không phải viết truy vấn, không phải tự đếm — đó đúng là điều Trusted Advisor sinh ra để làm. Đây cũng là lý do trong đề thi, hễ thấy vế "usage vs. limit" thì Trusted Advisor gần như luôn là câu trả lời.

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

B — AWS Service Catalog. Cái bẫy nằm ở chữ "Service" trong tên dịch vụ và chữ "track service usage" trong phương án — đọc lướt rất dễ tưởng nó theo dõi hạn mức dịch vụ. Thực tế Service Catalog là nơi tổ chức tạo và quản lý danh mục các sản phẩm/IT service đã được phê duyệt để người dùng nội bộ tự khởi tạo theo chuẩn. Nó quản trị cái gì được phép triển khai, hoàn toàn không báo cáo mức sử dụng so với hạn mức của IAM policy.

C — AWS CloudTrail. Đây là phương án gần đúng nhất và đáng nói kỹ. CloudTrail có ghi lại lịch sử hoạt động của tài khoản, gồm cả các lời gọi API tạo/sửa/xoá IAM policy, nên về lý thuyết bạn có thể lần theo log để biết policy được tạo lúc nào và bởi ai. Nhưng nó hỏng ở hai chỗ: (1) CloudTrail cho sự kiện, không cho trạng thái hiện tại — muốn ra con số tổng phải tự cộng trừ các sự kiện tạo và xoá, một cách làm vừa vòng vo vừa dễ sai; (2) quan trọng hơn, CloudTrail không hề biết hạn mức tối đa là bao nhiêu, nên vế thứ hai của phép so sánh mà đề yêu cầu vẫn bỏ trống. Từ khoá "audit" trong phương án chính là dấu hiệu nó đang trả lời cho câu hỏi "ai đã làm gì", không phải "còn bao nhiêu chỗ trống".

D — AWS Config. Cũng là phương án gần đúng theo một kiểu khác. Config đánh giá và ghi nhận cấu hình của tài nguyên AWS, có thể theo dõi IAM policy như một loại tài nguyên và giữ lịch sử thay đổi cấu hình. Nghĩa là nó có nắm trạng thái hiện tại — mạnh hơn CloudTrail ở điểm này. Nhưng nó vẫn hỏng đúng ở chỗ đề hỏi: Config không mang thông tin về service limit. Nó trả lời "policy hiện đang cấu hình thế nào, có tuân thủ quy tắc không", chứ không trả lời "đã dùng bao nhiêu phần trên tổng số được phép".

📌 Điểm cần nhớ

• Thấy "service limit", "quota", "usage vs. limit" trong đề → nghĩ ngay tới Trusted Advisor (nhóm check service limits). Đây là mẫu câu lặp đi lặp lại trong các đề CloudOps/SysOps.
• Phân biệt ba dịch vụ hay bị nhầm bằng câu hỏi mà mỗi cái trả lời: CloudTrail = "ai đã làm gì, lúc nào" (sự kiện, audit trail); Config = "tài nguyên hiện đang cấu hình ra sao, có tuân thủ không" (trạng thái + lịch sử cấu hình); Trusted Advisor = "tôi có đang làm đúng best practice, và còn cách trần bao xa" (khuyến nghị + hạn mức).
• Service Catalog không liên quan gì tới giám sát hay hạn mức — nó quản lý danh mục sản phẩm được phê duyệt cho người dùng nội bộ triển khai. Chữ "Service" trong tên là bẫy đọc lướt.
• Một phương án có thể chạm tới đối tượng trong đề (CloudTrail và Config đều "thấy" IAM policy) mà vẫn sai, vì nó không cung cấp được đại lượng mà đề yêu cầu. Khi hai phương án đều nghe hợp lý, hãy hỏi: phương án này có trả ra đúng con số đề cần so sánh không?

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

Đề mô tả một người dùng không SSH được vào một instance Amazon Linux, trong khi SysOps Administrator đã kiểm tra key pair, security group và network ACL, và xác nhận người dùng đó vẫn kết nối được tới các instance khác trong cùng subnet. Câu hỏi: bước tiếp theo để chẩn đoán sâu hơn là gì?

Cụm từ quyết định đáp án là "can connect to other instances in the same subnet" (kết nối được tới instance khác trong cùng subnet). Cụm này loại sạch mọi nguyên nhân ở tầng mạng dùng chung: route table, internet gateway, network ACL, cấu hình gán public IP của subnet — nếu bất kỳ thứ nào trong số đó sai thì mọi instance trong subnet đều không vào được, chứ không riêng một cái. Thêm mệnh đề thứ hai — key pair và security group đã kiểm rồi — chốt luôn phần cấu hình riêng của instance ở phía AWS.

Còn lại đúng một vùng chưa ai chạm tới: bên trong hệ điều hành của chính instance đó — sshd không chạy, cấu hình /etc/ssh/sshd_config hỏng, sai quyền trên ~/.ssh/authorized_keys, filesystem đầy hoặc lỗi. Đề đang hỏi công cụ nào soi được vùng đó.

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

A — Run the AWSSupport-TroubleshootSSH automation.

AWSSupport-TroubleshootSSH là một automation runbook dựng sẵn của AWS Systems Manager. Nó cài công cụ EC2Rescue lên instance mục tiêu, rồi kiểm tra và tự sửa những lỗi phía hệ điều hành thường gây hỏng kết nối SSH tới máy Linux — đúng lớp mà administrator chưa kiểm được từ bên ngoài.

Đây là công cụ duy nhất trong bốn phương án thực sự nhìn được vào trong instance. Ba phương án kia đều thao tác ở tầng ngoài, mà tầng ngoài thì dữ kiện trong đề đã chứng minh là đang hoạt động bình thường. Chạy runbook này qua Systems Manager Automation là bước chẩn đoán hợp lý tiếp theo.

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

B — Attach an Elastic IP address to the instance. Đây là phương án gần đúng nhất nếu bỏ qua mệnh đề "cùng subnet", vì thiếu địa chỉ public thì đúng là không SSH được từ Internet. Nhưng nó hỏng ở hai chỗ: thứ nhất, instance không nhất thiết cần Elastic IP — một public IP thường (do subnet tự gán) là đủ; thứ hai, các instance khác trong cùng subnet vẫn liên lạc được, nghĩa là subnet đó đã được cấu hình gán địa chỉ public. Ngoài ra gắn EIP là thay đổi cấu hình, không phải chẩn đoán — đề hỏi "further troubleshoot".

C — Use Trusted Advisor to check the SSH configuration. Trusted Advisor kiểm tra tài khoản ở mức khuyến nghị tổng thể (chi phí, hiệu năng, bảo mật, giới hạn, khả năng chịu lỗi). Về phía bảo mật nó có thể cảnh báo kiểu security group mở cổng SSH quá rộng ra Internet, nhưng đó là chuyện phơi bày rủi ro, không phải chẩn đoán vì sao một phiên SSH cụ thể thất bại. Trusted Advisor không đọc sshd_config, không kiểm quyền file khoá, không biết sshd còn chạy hay không.

D — Check that there is an internet gateway attached to the VPC. Đây là bước chẩn đoán chính đáng — nhưng đã bị chính đề bài loại. Internet gateway gắn ở mức VPC và route table áp cho cả subnet; thiếu nó thì không instance nào trong subnet ấy nhận được kết nối từ ngoài vào, mà người dùng lại đang vào được các instance khác. Kiểm tra lại thứ đã được dữ kiện chứng minh là hoạt động chỉ tốn thời gian.

📌 Điểm cần nhớ

• Trong câu hỏi troubleshooting, mệnh đề kiểu "các instance/tài nguyên khác cùng subnet (hoặc cùng VPC) vẫn hoạt động bình thường" là dấu hiệu loại toàn bộ nguyên nhân ở tầng dùng chung: internet gateway, route table, network ACL, cấu hình subnet. Lỗi nằm ở riêng một instance.
• Khi key pair, security group và network ACL đều đã kiểm mà vẫn hỏng, nghi vấn còn lại là hệ điều hành bên trong: sshd, sshd_config, quyền authorized_keys, dung lượng đĩa.
• AWSSupport-TroubleshootSSH là runbook của Systems Manager Automation, cài EC2Rescue để kiểm tra và sửa lỗi SSH ở phía OS. Ghi nhớ họ runbook AWSSupport-* — chúng thường là đáp án cho các câu "chẩn đoán sâu hơn" trên EC2.
• Phân biệt công cụ chẩn đoán với hành động thay đổi cấu hình: đề hỏi "further troubleshoot" thì phương án gắn thêm EIP, đổi security group… thường sai về bản chất, kể cả khi nghe có vẻ hợp lý.
• Trusted Advisor đưa khuyến nghị ở mức tài khoản (chi phí, bảo mật, hạn mức), không phải công cụ gỡ lỗi kết nối cho một instance cụ thể.

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

Đề mô tả một ứng dụng web nội bộ chạy sau Application Load Balancer, phía sau là các EC2 instance nằm trong một Auto Scaling group. Chi tiết quyết định nằm ở cụm "constrained to a single Availability Zone" — Auto Scaling group hiện chỉ được cấu hình cho đúng một Availability Zone.

Cụm từ thứ hai định hướng câu trả lời là "To ensure high availability". Đề không hỏi làm sao cho ứng dụng nhanh hơn, không hỏi giảm độ trễ giữa các instance, cũng không hỏi chống thảm hoạ ở quy mô Region. Nó hỏi đúng một việc: loại bỏ điểm hỏng đơn lẻ (single point of failure) đang tồn tại.

Ghép hai cụm lại, bài toán rất rõ: điểm hỏng đơn lẻ ở đây chính là cái AZ duy nhất đó. AZ gặp sự cố là toàn bộ instance của ứng dụng biến mất cùng lúc, ALB không còn target nào khoẻ mạnh để chuyển tiếp lưu lượng. Vậy phương án đúng phải là phương án trực tiếp gỡ bỏ ràng buộc một-AZ này, chứ không phải phương án thêm một dịch vụ mới vào kiến trúc.

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

Đáp án đúng là B — cấu hình Auto Scaling group để khởi chạy instance ở Availability Zone thứ hai.

Availability Zone là các vùng hạ tầng tách biệt nhau bên trong cùng một Region, có nguồn điện, làm mát và mạng riêng, được thiết kế để sự cố ở zone này không lan sang zone kia. Khi Auto Scaling group được khai báo nhiều AZ (thông qua các subnet thuộc những AZ khác nhau), nó sẽ phân bổ instance trải đều ra các AZ đó. Lúc đó một AZ gặp vấn đề thì các instance ở AZ còn lại vẫn chạy và vẫn phục vụ ứng dụng — đúng định nghĩa high availability.

Phần còn lại của kiến trúc đã sẵn sàng cho việc này: Application Load Balancer vốn là dịch vụ hoạt động ở phạm vi Region và có thể phân phối lưu lượng tới target ở nhiều AZ, chỉ cần bật AZ tương ứng trên load balancer. Health check của ALB sẽ tự ngừng gửi lưu lượng tới các target không khoẻ, còn Auto Scaling group sẽ thay thế những instance đã hỏng. Đây là thay đổi cấu hình trên chính tài nguyên đang có, không phải dựng lại kiến trúc.

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

A — Triển khai một cụm Amazon ElastiCache cho ứng dụng. ElastiCache là cache in-memory, giúp ứng dụng lấy dữ liệu nhanh hơn thay vì luôn phải đọc từ cơ sở dữ liệu trên đĩa. Đó là bài toán hiệu năng, không phải bài toán tính sẵn sàng của tầng web. Thêm ElastiCache cũng không làm các EC2 instance thoát khỏi cái AZ duy nhất — AZ đó hỏng thì không còn instance nào để phục vụ, cache có nhanh đến mấy cũng vô nghĩa.

C — Tạo cluster placement group cho các EC2 instance trong cùng một Availability Zone. Đây là phương án gây nhầm lẫn nhất vì nghe rất "hạ tầng". Nhưng cluster placement group được sinh ra để đặt các instance sát nhau về mặt vật lý, nhằm giảm độ trễ mạng và tăng thông lượng giữa chúng — dùng cho workload kiểu HPC. Nó đi ngược hoàn toàn hướng cần đi: thay vì phân tán để chịu lỗi, nó gom chặt lại. Chú ý cụm cuối phương án — "in a single Availability Zone" — nó giữ nguyên đúng cái ràng buộc mà đề đang bảo phải gỡ bỏ.

D — Cấu hình Auto Scaling group để khởi chạy instance ở một Region thứ hai. Ý tưởng "trải rộng ra" thì đúng hướng, nhưng cách diễn đạt không khả thi về mặt kỹ thuật: một Auto Scaling group là tài nguyên thuộc một Region, chỉ khởi chạy instance trong chính Region nơi nó được tạo, và Application Load Balancer cũng chỉ phân phối lưu lượng tới target trong Region của nó. Muốn chạy đa Region thì phải dựng ASG và load balancer riêng ở Region kia rồi điều phối ở tầng DNS — đó là một kiến trúc khác hẳn, không phải thứ mà một dòng cấu hình trên ASG hiện có làm được. Ngoài ra, với yêu cầu chỉ là high availability, nhảy sang đa Region là mức phức tạp vượt xa nhu cầu.

📌 Điểm cần nhớ

• Trong đề thi AWS, "high availability" gần như luôn quy về việc trải tài nguyên qua nhiều Availability Zone trong cùng một Region; còn "disaster recovery" ở quy mô lớn mới bàn tới nhiều Region.
• Đọc kỹ để phát hiện điểm hỏng đơn lẻ mà đề đã cài sẵn (ở đây là "a single Availability Zone"), rồi chọn phương án gỡ đúng điểm đó — thay vì chọn phương án thêm dịch vụ mới vào.
• Cluster placement group ≠ tính sẵn sàng. Nó tối ưu độ trễ mạng giữa các instance bằng cách gom chúng lại gần nhau, tức là làm tăng rủi ro cùng hỏng chứ không giảm.
• Auto Scaling group và Application Load Balancer đều là tài nguyên phạm vi Region: chúng làm việc với nhiều AZ được, nhưng không tự vươn sang Region khác.
• ElastiCache thuộc nhóm giải pháp hiệu năng/giảm tải cho database; đừng chọn nó khi câu hỏi nói về khả năng chịu lỗi của tầng compute.

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

Đề bài mô tả một công ty cần chuyển hơn 80 TB dữ liệu lên Amazon S3, và câu hỏi là cách chuyển hiệu quả nhất (MOST efficient).

Cụm từ quyết định đáp án không nằm ở "80 TB" mà nằm ở vế mô tả đường truyền: "a 50-Mbps internet connection that is heavily utilized" — đường Internet chỉ 50 Mbps và đã bị dùng gần hết. Đây chính là ràng buộc phân biệt bốn phương án, vì ba trong bốn phương án đều là những cách chuyển dữ liệu đi qua đường mạng sẵn có hoặc đòi hỏi dựng một đường mạng mới.

Ghép hai dữ kiện lại: khối lượng dữ liệu rất lớn, băng thông rất nhỏ và còn đang bị chia sẻ với công việc khác. Bất kỳ phương án nào phải đẩy 80 TB qua ống 50 Mbps đó đều mất thời gian ở mức không chấp nhận được, đồng thời còn bóp nghẹt lưu lượng nghiệp vụ đang chạy. Vì vậy hướng đi đúng là tránh hẳn đường Internet, chứ không phải tìm cách tối ưu nó.

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

Đáp án đúng theo tệp là A — AWS Snowball.

AWS Snowball là thiết bị vật lý: AWS gửi thiết bị tới chỗ khách hàng, khách hàng nạp dữ liệu vào thiết bị qua mạng nội bộ (LAN, tốc độ cao, không đụng tới đường Internet ra ngoài), rồi gửi thiết bị trả lại AWS để nạp dữ liệu vào Amazon S3. Dữ liệu được mã hoá trong suốt quá trình vận chuyển.

Điểm mấu chốt là Snowball chuyển bài toán từ băng thông sang vận chuyển vật lý. Với 80 TB trên một đường 50 Mbps đang bị dùng nhiều, thời gian truyền qua mạng là bài toán không có lời giải chấp nhận được; còn thời gian gửi và nhận một thiết bị vật lý thì gần như không phụ thuộc vào khối lượng dữ liệu. Đây đúng là kịch bản mẫu mà Snowball được thiết kế để giải: khối lượng lớn, băng thông hạn chế, và là một đợt di chuyển dữ liệu một lần chứ không phải nhu cầu kết nối lâu dài.

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

B — Amazon S3 Transfer Acceleration. Đây là phương án gần đúng nhất và dễ chọn nhầm, vì tên dịch vụ có chữ "acceleration" nghe rất hợp với đề. Nhưng nó chỉ tăng tốc việc tải lên S3 bằng cách đưa dữ liệu vào edge location của Amazon CloudFront gần người dùng rồi đi tiếp qua mạng nội bộ của AWS — nghĩa là nó cải thiện chặng đường sau khi dữ liệu đã rời khỏi công ty. Nó vẫn phải đi qua chính đường Internet 50 Mbps đang bị dùng hết ở chặng đầu tiên, nên nút thắt cổ chai không hề được gỡ. Ngoài ra dịch vụ này còn tính thêm phí so với upload thường, nên vừa không giải quyết vấn đề vừa đắt hơn.

C — AWS Direct Connect. Đây là đường kết nối vật lý riêng từ trung tâm dữ liệu của công ty tới AWS, và về mặt băng thông thì đúng là nó vượt xa đường 50 Mbps. Chỗ hỏng là thời gian và mục đích: thiết lập Direct Connect cần làm việc với đối tác, kéo đường truyền, cấu hình — một quá trình dài, không phù hợp cho một nhu cầu chuyển dữ liệu một lần. Direct Connect đáng đầu tư khi công ty có nhu cầu lâu dài về băng thông ổn định và độ trễ nhất quán tới AWS, không phải khi chỉ cần chuyển xong 80 TB rồi thôi.

D — AWS Managed VPN. Phương án này sai rõ nhất. VPN tạo một đường hầm mã hoá tới VPC, nhưng đường hầm đó chạy trên chính kết nối Internet sẵn có. Nó không thêm được một bit băng thông nào — thực tế còn tốn thêm chút overhead vì mã hoá và đóng gói. Nó giải bài toán bảo mật đường truyền, không giải bài toán thiếu băng thông, mà đề bài lại đang hỏi về hiệu quả chuyển dữ liệu.

📌 Điểm cần nhớ

• Khi đề nêu khối lượng dữ liệu lớn kèm băng thông hạn chế, hãy đọc kỹ con số băng thông — đó thường là cụm từ quyết định, và hướng trả lời là tránh đường mạng chứ không phải tối ưu nó.
• AWS Snowball hợp với việc di chuyển dữ liệu khối lượng lớn, một lần, khi mạng không đủ; thời gian hoàn thành phụ thuộc vào vận chuyển vật lý chứ không phụ thuộc băng thông.
• S3 Transfer Acceleration tối ưu chặng bên trong mạng AWS sau edge location; nó không làm rộng thêm đường Internet của khách hàng, nên vô dụng khi nút thắt nằm ở chính đường ra Internet.
• Phân biệt Direct Connect (nhu cầu băng thông/độ trễ lâu dài, cần thời gian thiết lập) với VPN (mã hoá qua Internet, không tăng băng thông) — cả hai đều không phải lời giải cho một đợt migration lớn diễn ra một lần.

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

Đề mô tả một web application phân phối qua Amazon CloudFront, và người dùng phàn nàn về việc nhận 4XX và 5XX errors. Một SysOps Administrator muốn theo dõi tỷ lệ lỗi tăng cao (monitor for elevated error rates) trong CloudFront. Câu hỏi yêu cầu chọn metric phù hợp.

Cụm từ quyết định đáp án là "elevated error rates" — kết hợp với "4XX and 5XX". Hai chi tiết này ràng buộc rất chặt:

• Phải là một metric về lỗi, không phải về hiệu năng hay lưu lượng.
• Phải bao trùm cả hai họ mã lỗi 4xx và 5xx, chứ không chỉ một trong hai.
• Phải là rate (tỷ lệ phần trăm), vì "error rate tăng cao" chỉ có nghĩa khi so lỗi với tổng lượng request — số lỗi thô tăng có thể chỉ vì traffic tăng.

Trong bốn phương án, chỉ có một cái vừa mang nghĩa "lỗi", vừa mang nghĩa "tỷ lệ", vừa gộp cả 4xx lẫn 5xx.

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

C. TotalErrorRate là đáp án đúng.

TotalErrorRate là metric CloudFront đẩy sang CloudWatch, cho biết phần trăm trong tổng số viewer request mà CloudFront trả về response có HTTP status code thuộc nhóm 4xx hoặc 5xx. Đúng cả ba yêu cầu rút ra từ đề:

• Nó nói về lỗi, đúng thứ người dùng đang phàn nàn.
• Nó gộp cả 4xx và 5xx vào một con số — khớp chính xác với cách đề mô tả sự cố, nên chỉ cần một metric là bao được cả hai họ lỗi.
• Nó là tỷ lệ chứ không phải số đếm, nên dựng CloudWatch alarm trên nó sẽ phản ánh đúng "elevated error rate" bất kể lượng truy cập lên xuống.

Sau khi phát hiện tỷ lệ tăng bằng metric này, quản trị viên mới đi sâu tiếp; nhưng thứ dùng để phát hiện đúng như đề hỏi thì là TotalErrorRate.

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

A. OriginLatency — Đây là metric gần đúng nhất theo nghĩa "có liên quan tới sự cố", nên đáng nói rõ nó hỏng ở đâu. OriginLatency đo tổng thời gian tính bằng mili-giây, từ lúc CloudFront nhận request đến lúc bắt đầu trả response ra mạng, và chỉ tính cho những request được phục vụ từ origin chứ không phải từ cache. Nó là metric hiệu năng, không phải metric lỗi: origin chậm có thể dẫn tới lỗi 5xx do timeout, nhưng bản thân con số latency không nói được tỷ lệ request bị lỗi là bao nhiêu, và hoàn toàn không đụng tới nhóm 4xx. Theo dõi nó là theo dõi một triệu chứng có thể liên quan, không phải thứ đề yêu cầu.

B. CacheHitRate — Metric này đo phần trăm các cacheable request mà CloudFront phục vụ được từ cache của nó. Nó là chỉ số về hiệu quả caching, dùng để tối ưu chi phí và tốc độ. Cache hit rate thấp nghĩa là nhiều request phải đi về origin, không hề đồng nghĩa với việc có lỗi — request đi về origin vẫn có thể trả 200 hoàn toàn bình thường. Chữ "Rate" trong tên khiến nó trông giống đáp án đúng, nhưng đó là tỷ lệ hit, không phải tỷ lệ error.

D. Requests — Metric này đếm tổng số viewer request mà CloudFront nhận được, cho mọi HTTP method và cho cả HTTP lẫn HTTPS. Đây thuần tuý là số đo lưu lượng: nó không phân biệt request thành công với request lỗi. Một con số Requests tăng vọt chẳng nói được điều gì về lỗi, và ngay cả khi kết hợp thủ công thì nó cũng chỉ là mẫu số của một tỷ lệ lỗi chứ không phải bản thân tỷ lệ đó.

📌 Điểm cần nhớ

• Với CloudFront, khi đề hỏi về tỷ lệ lỗi gộp cả 4xx lẫn 5xx, metric cần nhớ là TotalErrorRate. CloudFront còn tách riêng metric cho từng họ mã lỗi, nên khi đề chỉ nói tới một họ thì hãy đọc kỹ xem có phương án chuyên biệt hơn không.
• Phân loại metric theo thứ nó đo trước khi so tên: TotalErrorRate đo lỗi, OriginLatency đo hiệu năng, CacheHitRate đo hiệu quả cache, Requests đo lưu lượng. Chỉ nhóm "đo lỗi" mới trả lời được câu hỏi về lỗi.
• Chữ "rate" trong đề là một ràng buộc thật, không phải cách nói suồng sã: tỷ lệ chuẩn hoá theo lượng truy cập, còn số đếm thô thì tăng theo traffic và dễ gây báo động giả khi dựng alarm.
• Đừng chọn metric chỉ vì nó có thể là nguyên nhân của triệu chứng (origin chậm → 5xx). Đề hỏi metric nào dùng để theo dõi/phát hiện triệu chứng thì phải chọn metric đo trực tiếp chính triệu chứng đó.

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

Đề nêu một tình huống rất ngắn: công ty đang chạy một database instance Amazon Aurora, và hỏi theo AWS Shared Responsibility Model thì hành động nào thuộc trách nhiệm của khách hàng.

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

• "Amazon Aurora" — đây là một managed service. Với dịch vụ được quản lý, đường ranh giới trách nhiệm bị đẩy lên rất cao: AWS lo toàn bộ phần hạ tầng vật lý, hệ điều hành máy chủ, phần mềm database engine và cả việc thi hành các bản vá. Khách hàng chỉ còn lại phần cấu hình và dữ liệu.
• "responsibility of the customer" — đề hỏi phần của khách hàng, không phải phần của AWS. Ba trong bốn phương án mô tả những việc AWS làm; chỉ cần đọc kỹ vế này là loại được phần lớn nhiễu.

Điểm phân biệt tinh tế nhất nằm ở cặp phương án A và B: chúng nói về cùng một hoạt động (maintenance, patches, updates) nhưng khác nhau đúng một động từ — executing (thi hành) so với scheduling (lên lịch). Cả câu hỏi xoay quanh sự đối lập của hai động từ này.

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

B — "Scheduling maintenance, patches, and other updates."

Aurora là managed service nên AWS chịu trách nhiệm thực hiện việc bảo trì, vá lỗi và cập nhật. Nhưng AWS không tự ý chọn thời điểm áp dụng chúng lên instance của bạn — khách hàng là người khai báo maintenance window, tức khung thời gian mà các thao tác bảo trì được phép diễn ra. Việc chọn khung giờ ít người dùng, quyết định khi nào chấp nhận một khoảng gián đoạn ngắn, là quyết định vận hành thuộc về phía khách hàng vì chỉ khách hàng mới biết đặc thù tải và yêu cầu nghiệp vụ của mình.

Nói gọn theo đúng tinh thần Shared Responsibility Model: AWS làm việc, khách hàng chọn lúc làm. Đó là một ví dụ điển hình cho ranh giới "security of the cloud" (AWS) so với "security in the cloud" (khách hàng) — phần cấu hình luôn nghiêng về phía khách hàng.

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

A — "Executing maintenance, patches, and other updates." Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. Nội dung hoạt động thì đúng, nhưng động từ sai. Với Aurora, khách hàng không có quyền truy cập vào hệ điều hành máy chủ hay bản thân database engine để tự cài bản vá — chính AWS là bên thi hành các bản vá đó. Nếu đây là một database bạn tự cài trên EC2 thì A sẽ đúng, nhưng đề đã nói rõ là Aurora. Đọc lướt, thấy chữ "maintenance, patches" quen thuộc rồi chọn ngay là rơi vào bẫy.

C — "Provisioning the underlying server hardware." Phần cứng máy chủ nằm ở tầng thấp nhất của mô hình, thuộc hoàn toàn về AWS. Khách hàng dùng Aurora thậm chí không nhìn thấy máy chủ vật lý nào — không có khái niệm cung cấp hay lắp đặt hardware ở phía khách hàng. Đây là phương án dễ loại nhất vì nó nằm rõ ràng trong nhóm "security of the cloud".

D — "Managing network infrastructure for the database." Hạ tầng mạng phục vụ cho việc chạy và đưa database ra sử dụng do AWS quản lý và vận hành. Phương án này có vẻ hợp lý với ai nhớ rằng khách hàng vẫn cấu hình một số thứ liên quan tới mạng, nhưng cần phân biệt: cấu hình ở tầng người dùng khác hẳn với quản lý bản thân hạ tầng mạng. Phương án dùng chữ "managing network infrastructure" — tức là vận hành thiết bị mạng và hệ thống mạng nền — và phần đó thuộc AWS.

📌 Điểm cần nhớ

• Với managed service (như Aurora), ranh giới trách nhiệm bị đẩy lên rất cao: AWS gánh hardware, hệ điều hành, database engine và việc thi hành bản vá; khách hàng còn lại phần cấu hình, dữ liệu và quyền truy cập.
• Khi hai phương án mô tả cùng một hoạt động nhưng khác động từ (executing so với scheduling, managing so với configuring), chính động từ đó là chỗ đề cài bẫy — đọc kỹ động từ trước khi đọc danh từ.
• Công thức gợi nhớ cho nhóm câu Shared Responsibility Model: AWS chịu trách nhiệm "of the cloud" (hạ tầng, phần cứng, mạng nền, thực thi bảo trì), khách hàng chịu trách nhiệm "in the cloud" (thiết lập, lịch bảo trì, dữ liệu, phân quyền).
• Cùng một công việc có thể đổi chủ tuỳ mô hình dịch vụ: vá lỗi database do khách hàng làm nếu tự cài trên EC2, nhưng do AWS làm nếu dùng Aurora. Luôn xác định dịch vụ trong đề trước khi quy trách nhiệm.

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

Đề mô tả một ứng dụng bespoke (viết riêng, không phải phần mềm thương mại) cần cài lên một fleet EC2 instances, và hỏi: làm sao để ứng dụng đó được triển khai on new EC2 instances — tức là trên những instance vừa được tạo ra.

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

• "is updated frequently" — ứng dụng thay đổi liên tục. Cụm này loại bỏ mọi giải pháp dựa trên việc "đóng cứng" ứng dụng vào một artifact tĩnh, vì artifact sẽ lạc hậu ngay sau lần cập nhật kế tiếp.
• "can be installed automatically" — bản thân ứng dụng có cơ chế cài đặt không cần tương tác. Cụm này mở đường cho một script chạy tự động lúc khởi động.

Ghép lại, câu hỏi cần một cơ chế chạy tại thời điểm instance mới boot lên, kéo về phiên bản mới nhất rồi cài. Đây chính là mô tả của EC2 user data.

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

C — Create a script that downloads and installs the application using EC2 user data.

EC2 user data là đoạn script gắn vào instance và được thực thi trong quá trình khởi động lần đầu. Vì script chỉ tham chiếu tới nơi chứa bản cài (chứ không chứa sẵn bản cài), mỗi instance mới boot lên sẽ tải về binaries mới nhất tại thời điểm đó rồi cài. Ứng dụng cập nhật thường xuyên bao nhiêu cũng không cần sửa lại script hay dựng lại gì cả — đúng như giải thích gốc: "This will ensure that all new instances have the latest software installed."

Cách này cũng khớp với chữ fleet trong đề: user data đi kèm launch template/launch configuration nên mọi instance sinh ra đều chạy cùng một script, không cần thao tác thủ công trên từng máy.

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

A — Use AWS Config to detect application updates and trigger an update process. AWS Config theo dõi và ghi lại cấu hình của AWS resources, đánh giá chúng theo rule rồi có thể kích hoạt hành động khắc phục. Vấn đề nằm ở thứ tự: hướng này để instance khởi động lên trong trạng thái thiếu ứng dụng, rồi mới phát hiện ra và đi chữa. Cài luôn lúc khởi động đơn giản hơn hẳn so với dò tìm rằng nó đang thiếu. Ngoài ra AWS Config hướng tới cấu hình tài nguyên chứ không phải phiên bản phần mềm bên trong hệ điều hành.

B — Create an AWS CloudFormation stack and use a change set to deploy to EC2. Đây là phương án dễ nhầm nhất vì CloudFormation đúng là công cụ provisioning EC2. Nhưng change set là cơ chế xem trước những thay đổi mà một stack update sẽ gây ra cho tài nguyên hạ tầng, rồi thực thi thay đổi đó — nó không phải cơ chế đẩy ứng dụng vào các instance vừa được tạo. Change set thao tác ở mức resource của stack, không ở mức phần mềm chạy bên trong instance.

D — Use AWS Systems Manager to inject the application into an AMI. Cũng gần đúng vì Systems Manager thật sự có liên quan tới việc bảo trì AMI — patch AMI là việc làm được. Nhưng "inject the application into an AMI" không phải là việc Systems Manager làm. Và ngay cả khi bỏ qua điều đó, hướng bake ứng dụng vào AMI mâu thuẫn thẳng với ràng buộc "updated frequently" trong đề: mỗi lần ứng dụng ra bản mới lại phải dựng lại AMI và cập nhật tham chiếu AMI cho toàn fleet.

📌 Điểm cần nhớ

• Khi đề nói ứng dụng thay đổi thường xuyên, hãy nghiêng về cơ chế kéo bản mới lúc boot (user data) thay vì đóng cứng vào một image dựng sẵn — image tĩnh nghĩa là thêm một chu trình dựng lại mỗi lần ứng dụng đổi.
• EC2 user data là câu trả lời mặc định cho dạng "chạy gì đó tự động khi instance mới khởi động", đặc biệt khi đề khẳng định việc cài đặt có thể tự động hoá.
• CloudFormation change set phục vụ việc xem trước và áp dụng thay đổi hạ tầng của stack; đừng đọc nó thành công cụ phân phối ứng dụng.
• Phân biệt ranh giới: AWS Config đánh giá cấu hình tài nguyên (phát hiện lệch chuẩn sau khi đã xảy ra), còn cài đặt lúc khởi động là hành động phòng ngừa — đề yêu cầu triển khai thì chọn phòng ngừa.

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

Đề mô tả một Auto Scaling group (ASG) không tạo được EC2 instance, kèm thông báo lỗi rất cụ thể: "The AMI ID ami-0c23bcf3g31a58706 does not exist". Câu hỏi yêu cầu tìm hành động khắc phục để ASG lại tạo được instance mới.

Cụm từ quyết định nằm ở hai chỗ:

• "does not exist" — AMI được tham chiếu đã bị deregister/xoá sau khi cấu hình được tạo, nên mọi lần scale-out đều thất bại. Vấn đề không nằm ở quyền, ở subnet hay ở instance type, mà nằm ở tham chiếu AMI trong cấu hình khởi chạy.
• "launch configuration" trong các phương án — đây là ràng buộc phân biệt B, C và D. Launch configuration là đối tượng bất biến (immutable): tạo xong thì không sửa được. Ai không nhớ đặc tính này sẽ chọn D vì nghe "cập nhật cho đúng" là hợp lý nhất.

Nói cách khác, đề không hỏi "làm sao có AMI hợp lệ" mà hỏi "làm sao đưa AMI hợp lệ vào ASG", và câu trả lời bị chi phối bởi tính bất biến của launch configuration.

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

C — Create a new launch configuration using a valid AMI.

Theo giải thích gốc: AMI nhiều khả năng đã bị xoá sau khi launch configuration được tạo, và không thể sửa một launch configuration đã tồn tại. Do đó cách duy nhất trong danh sách để ASG có AMI hợp lệ là tạo một launch configuration mới trỏ tới AMI còn tồn tại, rồi gán nó cho Auto Scaling group. Từ lúc đó, mọi instance ASG khởi chạy đều dùng cấu hình mới và lỗi biến mất.

Đây chính là quy trình khắc phục AWS ghi trong tài liệu troubleshooting Auto Scaling cho lỗi AMI: thay cấu hình khởi chạy chứ không "sửa" nó.

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

A — Add an alias for the AMI ID pointing to a valid AMI. Sai vì AMI không có cơ chế alias. AMI được tham chiếu bằng chính AMI ID; không tồn tại một lớp trỏ tên (name pointer) do người dùng tự tạo để ánh xạ một ID cũ sang image mới. Phương án này mô tả một tính năng không có thật, nên không cần bàn tiếp.

B — Create a new AMI with the same AMI ID. Đây là phương án nghe gần đúng nhất về mặt ý tưởng: nếu tái tạo được đúng ID cũ thì cấu hình cũ vẫn chạy. Nhưng nó hỏng ở một điểm không vượt qua được: AMI ID do AWS sinh ra, người dùng không chọn được. Bạn tạo lại image từ cùng một instance thì vẫn ra một ID mới hoàn toàn. Ý tưởng đúng, cơ chế bất khả thi.

D — Update the launch configuration with a valid AMI ID. Đây là bẫy chính của câu hỏi, và cũng là lựa chọn trực giác nhất. Nó hỏng ở đúng một chỗ: launch configuration là immutable — không sửa được sau khi tạo. Muốn đổi bất kỳ thuộc tính nào (AMI, instance type, key pair, security group) đều phải tạo bản mới. Nội dung mong muốn của D và của C là như nhau ("dùng AMI hợp lệ"), nhưng chỉ C diễn đạt bằng thao tác thực sự làm được.

📌 Điểm cần nhớ

• Launch configuration không sửa được. Mọi thay đổi cấu hình khởi chạy của ASG đều là "tạo mới rồi gán lại", không bao giờ là "update". Gặp phương án có động từ update/modify gắn với launch configuration thì gần như chắc chắn là bẫy.
• AMI ID do AWS cấp, không đặt được và không alias được. Bất kỳ phương án nào giả định bạn kiểm soát được AMI ID hoặc trỏ tên tuỳ ý sang AMI khác đều là tính năng không tồn tại.
• Lỗi "AMI does not exist" trong ASG = tham chiếu image chết, thường do AMI bị deregister sau khi cấu hình được tạo. Hướng xử lý luôn là đưa ASG sang cấu hình trỏ tới một AMI còn hiệu lực.
• Khi hai phương án cùng nói một ý ("dùng AMI hợp lệ"), hãy chọn theo thao tác nào API thực sự cho phép, chứ không theo cách diễn đạt nào nghe gọn hơn.

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

Đề mô tả một website tĩnh nằm trên Amazon S3 (us-east-1), phân phối qua Amazon CloudFront, và cần chống DDoS. Nhưng vế chống DDoS chỉ là bối cảnh — cụm từ quyết định đáp án là:

"...while having the capacity to manage the rate limit at which DDoS protections are activated"

Nghĩa là người vận hành phải tự đặt được ngưỡng số request, và khi vượt ngưỡng đó thì hành động chặn mới kích hoạt. Đây không phải yêu cầu "có bảo vệ DDoS" chung chung, mà là "bảo vệ DDoS có ngưỡng do tôi cấu hình". Chỉ một dịch vụ trong danh sách cho phép khai báo ngưỡng đó như một tham số của rule.

Chi tiết phụ cũng đáng để ý: nội dung nằm trên S3 + CloudFront, không có máy chủ ứng dụng nào. Chi tiết này tự loại bỏ phương án nào gắn với EC2.

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

B — Implement AWS WAF on the CloudFront distribution and define rate-based rules.

AWS WAF gắn trực tiếp được vào một CloudFront distribution, tức là lọc ngay ở tầng biên, trước khi request chạm tới origin S3. Trong AWS WAF có loại rule tên đúng như thứ đề bài mô tả: rate-based rule. Rule này đếm số request đến từ mỗi địa chỉ IP nguồn trong một cửa sổ thời gian; khi số đếm của một IP vượt ngưỡng do bạn khai báo, hành động của rule (block, count, CAPTCHA…) được áp lên IP đó cho tới khi lưu lượng của nó tụt xuống dưới ngưỡng.

Đúng theo giải thích gốc: ngưỡng ở đây là configurable threshold — chính là "the rate limit at which DDoS protections are activated" mà đề đòi. Vừa giảm nhẹ tấn công ở tầng ứng dụng, vừa để quyền chỉnh ngưỡng trong tay SysOps administrator. Đây là phương án duy nhất khớp cả hai vế.

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

A — AWS Macie. Sai hoàn toàn về mục đích dịch vụ. Macie dùng machine learning để phát hiện và phân loại dữ liệu nhạy cảm (thường là dữ liệu trong S3), phục vụ bài toán bảo vệ dữ liệu và tuân thủ. Nó không đứng trên đường đi của request, không lọc lưu lượng, không có khái niệm rate limit. Việc đề nhắc tới S3 có thể khiến người học liên tưởng tới Macie — đó là bẫy liên tưởng, không phải manh mối.

C — Amazon Inspector trên các EC2 instance. Sai ở hai tầng. Thứ nhất, Inspector là dịch vụ đánh giá lỗ hổng và cấu hình của workload, nó báo cáo rủi ro chứ không chặn lưu lượng đang đến, nên không liên quan gì tới DDoS hay rate limit. Thứ hai, đề nói rõ website nằm trên S3 + CloudFront — trong kiến trúc này không hề có EC2 instance nào để bật Inspector lên. Phương án tự mâu thuẫn với đề bài.

D — AWS Shield Advanced và đặt "DDoS protection rate limit". Đây là phương án gần đúng nhất và là chỗ dễ mất điểm. Shield Advanced đúng là dịch vụ chống DDoS cao cấp của AWS, gắn được với CloudFront, có phát hiện và giảm nhẹ tấn công tinh vi hơn cùng đội hỗ trợ chuyên trách. Nhưng nó hỏng ở đúng vế mà đề nhấn mạnh: cơ chế giảm nhẹ của Shield vận hành tự động dựa trên hồ sơ lưu lượng, không phải nơi bạn ngồi gõ một con số ngưỡng request/IP. Cái nút chỉnh ngưỡng mà đề mô tả nằm ở rate-based rule của AWS WAF chứ không nằm ở Shield. Nói cách khác: Shield trả lời được "chống DDoS", nhưng không trả lời được "quản lý được rate limit kích hoạt bảo vệ" — mà đề hỏi cả hai.

📌 Điểm cần nhớ

• Thấy cụm "rate limit", "threshold", "số request từ mỗi IP" trong đề chống tấn công → nghĩ ngay tới AWS WAF rate-based rule, đó là nơi duy nhất ngưỡng được khai báo tường minh.
• Phân vai cho gọn: Shield lo DDoS ở tầng mạng/vận chuyển và chạy tự động; WAF lo tầng ứng dụng (HTTP) với rule do bạn viết. Đề đòi điều khiển được → WAF; đề chỉ đòi chống DDoS mạnh hơn, có hỗ trợ chuyên gia → Shield Advanced.
• WAF gắn được vào CloudFront, nên kiến trúc S3 tĩnh + CloudFront vẫn lọc được request ở biên dù không có máy chủ ứng dụng nào.
• Loại nhanh bằng mục đích dịch vụ: Macie = phát hiện dữ liệu nhạy cảm, Inspector = quét lỗ hổng workload. Cả hai đều quan sát/báo cáo, không nằm trên đường đi của lưu lượng nên không bao giờ là đáp án cho câu hỏi chặn request.
• Đọc kỹ kiến trúc trong đề: phương án nhắc tới thành phần không tồn tại trong đề (ở đây là EC2) gần như luôn sai.