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

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

Đề mô tả một SysOps administrator cần tự động gọi một AWS Lambda function, và function này phải chạy vào cuối mỗi ngày để tổng hợp báo cáo từ dữ liệu nằm trong một Amazon S3 bucket.

Có hai cụm từ quyết định đáp án, và phải đọc cả hai cùng lúc:

• "execute at the end of each day" — đây là ràng buộc về thời gian, không phải về sự kiện. Việc chạy hàm không phụ thuộc vào chuyện có ai ghi dữ liệu vào bucket hay không: hết ngày là chạy, kể cả hôm đó bucket không thay đổi gì.
• "most operationally efficient" — trong đề thi AWS, cụm này gần như luôn nghiêng về dịch vụ được quản lý (managed), không có máy chủ để trông coi.

S3 bucket trong đề chỉ là nơi Lambda đọc dữ liệu, không phải nguồn kích hoạt. Đây chính là cái bẫy: đề nhắc tới S3 nên hai phương án gắn với sự kiện S3 trông rất hợp lý, nhưng chúng trả lời sai câu hỏi "khi nào chạy".

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

Đáp án đúng là B — tạo một Amazon EventBridge rule dùng scheduled pattern, đặt Lambda function làm target.

EventBridge hỗ trợ rule theo lịch với cron expression hoặc rate expression, tức là đúng loại kích hoạt mà đề cần: "cuối mỗi ngày" diễn đạt được trực tiếp thành một biểu thức cron chạy một lần mỗi 24 giờ. Lambda function được khai làm target của rule, EventBridge tự gọi nó theo lịch.

Về mặt vận hành, đây là giải pháp không có hạ tầng nào để duy trì: không cài đặt, không vá lỗi hệ điều hành, không lo tiến trình lập lịch chết. Bạn chỉ khai một rule và một target — đúng nghĩa "most operationally efficient".

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

A — Dùng một Amazon EC2 instance chạy cron job để gọi Lambda function. Đây là phương án về mặt kỹ thuật thì chạy được, và đó là lý do nó nguy hiểm. Nhưng nó bắt bạn dựng và nuôi một EC2 instance chỉ để mỗi ngày phát đúng một lời gọi: phải vá hệ điều hành, phải cấp IAM permission cho instance, phải giám sát xem nó còn sống không, và phải trả tiền cho instance suốt 24 giờ. Nếu instance hỏng thì báo cáo im lặng không chạy. Đề hỏi "most operationally efficient" chứ không hỏi "cách nào chạy được", nên A thua B ở đúng tiêu chí mà đề đặt ra.

C — EventBridge rule dùng event pattern cho Amazon S3, đặt Lambda làm target. Đây là phương án gần đúng nhất, và chỗ hỏng nằm ở một chữ: event pattern thay vì scheduled pattern. EventBridge có hai kiểu rule khác nhau — kiểu theo lịch, và kiểu khớp mẫu sự kiện. Event pattern cho S3 sẽ kích hoạt khi có hoạt động xảy ra trên bucket, tức là gắn với hành vi ghi dữ liệu chứ không gắn với mốc thời gian. Chọn đúng dịch vụ (EventBridge) nhưng sai loại rule thì hàm sẽ chạy nhiều lần trong ngày mỗi khi bucket có thay đổi, và không chạy lần nào vào những ngày bucket đứng yên — trái hẳn yêu cầu "cuối mỗi ngày".

D — Cấu hình S3 event notification kích hoạt Lambda mỗi khi object trong bucket bị thay đổi. Sai theo đúng kiểu của C, chỉ đổi cơ chế. S3 event notification là cầu nối trực tiếp từ bucket sang Lambda, kích hoạt theo từng object thay đổi. Kết quả là báo cáo được sinh ra rời rạc, mỗi lần một chút, thay vì một bản tổng hợp cuối ngày; và số lần gọi hàm phụ thuộc vào lưu lượng ghi vào bucket chứ không phụ thuộc vào đồng hồ. Không có cách nào cấu hình S3 event notification để nó phát ra vào một giờ cố định.

📌 Điểm cần nhớ

• Phân biệt "chạy theo lịch" với "chạy theo sự kiện" ngay từ đề bài. Cụm như at the end of each day, every hour, nightly, weekly là tín hiệu của scheduled rule; cụm như whenever an object is uploaded, when a file changes mới là event-driven.
• EventBridge có hai loại rule và đề thi rất hay đánh vào chỗ này. Scheduled pattern dùng cron/rate expression; event pattern khớp theo sự kiện của dịch vụ. Chọn đúng EventBridge mà sai loại pattern vẫn là câu trả lời sai.
• "Operationally efficient" gần như luôn loại phương án có EC2 phải tự quản lý. Một cron job trên EC2 thường chạy được về mặt kỹ thuật, nhưng nó thêm máy chủ để vá, để giám sát và để trả tiền — đề đang so sánh chi phí vận hành, không so sánh tính khả thi.
• Việc S3 xuất hiện trong đề không có nghĩa S3 là nguồn kích hoạt. Hãy tách rõ Lambda đọc dữ liệu từ đâu và Lambda được gọi bởi cái gì; nhiều câu cố tình trộn hai vai này để làm các phương án gắn với S3 trông thuyết phục hơn.

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

Đề mô tả một ứng dụng eCommerce chạy trên Amazon EC2 instances trong một Auto Scaling group (ASG), và ASG này đang scale dựa trên CPU utilization. Triệu chứng: người dùng báo ứng dụng phản hồi chậm vào đầu mỗi ngày làm việc.

Cụm từ quyết định đáp án là "at the beginning of each business day" — chậm lặp lại theo một mốc thời gian biết trước, chứ không phải chậm ngẫu nhiên hay chậm liên tục. Nó nói lên hai điều:

1. Tải tăng đột ngột vào một thời điểm đoán trước được.
2. Ứng dụng có scale (chính sách CPU vẫn hoạt động), nhưng scale không kịp: khi CPU chạm ngưỡng, ASG mới bắt đầu launch instance, rồi instance còn phải boot, chạy user data, đăng ký với load balancer và qua health check. Trong khoảng trễ đó người dùng vẫn phải chờ.

Vấn đề vì thế là độ trễ phản ứng của scaling, không phải sai metric và cũng không phải thiếu tổng công suất. Đây là ràng buộc phân biệt D với ba phương án còn lại.

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

D — Create a scheduled scaling action to scale up in anticipation of the traffic.

Scheduled scaling cho phép khai báo một scheduled action gắn với thời điểm cụ thể (một lần hoặc lặp lại theo lịch). Tại thời điểm đó, EC2 Auto Scaling cập nhật group với các giá trị minimum, maximum và desired capacity mà scheduled action chỉ định.

Điểm mấu chốt: lịch được đặt trước giờ cao điểm, nên instance đã được launch, khởi động xong và sẵn sàng phục vụ trước khi lưu lượng ập tới. Cách này biến vấn đề "phản ứng sau khi đã quá tải" thành "chuẩn bị trước khi quá tải" — đúng với dạng tải có quy luật thời gian rõ ràng như giờ mở cửa hằng ngày. Chính sách CPU vẫn giữ nguyên để lo phần biến động ngoài dự đoán trong ngày.

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

A — Change the launch configuration to launch larger EC2 instance types. Đây là scale up theo chiều dọc. Nó tốn nhiều tiền hơn vì instance lớn chạy suốt 24 giờ trong khi cao điểm chỉ kéo dài một quãng ngắn đầu ngày, và vẫn không chắc xử lý được cú tăng đột biến — nếu mức tải đầu ngày vượt sức instance mới thì ASG lại rơi vào đúng vòng chờ launch như cũ. Cấp thêm công suất chỉ khi cần bằng scheduled scaling là cách hợp lý hơn.

B — Modify the scaling policy to deploy more EC2 instances when scaling up. Đâ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ó có đụng đúng chiều: thêm công suất theo chiều ngang. Nhưng nó vẫn giữ nguyên cơ chế phản ứng — chỉ khi CPU đã vượt ngưỡng thì ASG mới hành động. Launch nhiều instance một lúc không rút ngắn thời gian boot và đưa instance vào phục vụ; trong suốt khoảng trễ đó người dùng vẫn gặp phản hồi chậm. Nó chữa "thêm bao nhiêu", còn cái hỏng ở đây là "thêm vào lúc nào".

C — Change the Auto Scaling group to scale up and down based on memory utilization. Sai ở hai tầng. Thứ nhất, đề không hề nói vấn đề nằm ở memory — không có dấu hiệu nào cho thấy CPU là metric sai. Thứ hai, memory utilization không phải metric mà EC2 gửi sẵn tới CloudWatch, nên không dùng trực tiếp làm cơ sở scaling như CPU được. Và quan trọng nhất: dù có đổi sang metric nào đi nữa thì đây vẫn là reactive scaling, độ trễ launch instance vẫn còn nguyên.

📌 Điểm cần nhớ

• Tải tăng theo lịch đoán trước được (đầu giờ làm việc, cuối tháng, ngày khuyến mãi) → scheduled scaling. Đây gần như là từ khóa nhận diện của cả một họ câu hỏi.
• Phân biệt hai lớp nguyên nhân: thiếu công suất (sửa bằng cách tăng số lượng hoặc kích thước instance) và scale không kịp (sửa bằng cách chuẩn bị trước). Triệu chứng chậm đúng vào một mốc thời gian lặp lại là dấu hiệu của lớp thứ hai.
• Scheduled action đặt lại min, max và desired capacity của ASG tại thời điểm đã hẹn; nó không xung đột mà bổ sung cho dynamic scaling policy đang chạy.
• CPU utilization là metric EC2 báo sẵn cho CloudWatch; memory utilization thì không. Gặp phương án đề nghị scale theo memory mà không nhắc gì tới việc thu thập metric bổ sung thì nên nghi ngờ ngay.
• Scale up (instance to hơn) hầu như luôn thua scale out (thêm instance) trong các câu về ASG, trừ khi đề nêu rõ ràng buộc buộc phải dùng một instance duy nhất.

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

Đề mô tả một ứng dụng chạy hoàn toàn trên EC2 Spot Instances, đặt trong một EC2 Auto Scaling group có cấu hình scheduled scaling. Hai triệu chứng được nêu rõ: dung lượng không phải lúc nào cũng scale được đúng vào khung giờ đã hẹn, và các instance bị thu hồi (terminate) rất nhiều lần trong cùng một ngày. Yêu cầu đặt ra cho SysOps administrator là instance phải khởi chạy đúng lúc và ít bị gián đoạn hơn.

Cụm từ quyết định đáp án là "runs exclusively on Amazon EC2 Spot Instances" ghép với hai vế yêu cầu "timely instance launch" và "with fewer disruptions". Ứng dụng đã chốt là Spot, nên mọi phương án nói tới on-demand allocation strategy đều lệch khỏi bối cảnh mà đề đặt ra. Còn hai vế yêu cầu thì cần hai biện pháp khác nhau: một biện pháp làm giảm tần suất bị thu hồi (chiến lược phân bổ), một biện pháp làm tăng khả năng kiếm ra capacity đúng lúc (mở rộng danh sách instance type). Phương án nào chỉ giải quyết một vế thì chưa đủ.

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

Đáp án C — dùng capacity-optimized allocation strategy cho Spot Instances và mở rộng dải instance type trong Auto Scaling group — khớp cả hai vế:

• capacity-optimized khiến Auto Scaling group khởi chạy Spot Instances vào các Spot pool đang còn nhiều capacity nhất. Pool càng dồi dào thì xác suất AWS phải thu hồi lại capacity đó càng thấp, nên tần suất interruption giảm — đúng với yêu cầu "fewer disruptions".
• Mở rộng dải instance type cho Auto Scaling group nhiều lựa chọn hơn khi cần capacity. Một Spot pool là tổ hợp instance type + Availability Zone; khai báo càng nhiều instance type thì càng nhiều pool để chọn, nên khi scheduled scaling action kích hoạt, nhóm có nhiều cửa hơn để lấy đủ số instance đúng thời điểm — đúng với yêu cầu "timely instance launch".

Hai biện pháp này bổ trợ nhau: chiến lược phân bổ chỉ phát huy tác dụng khi nó có nhiều pool để so sánh và chọn ra pool dồi dào nhất.

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

A — capacity-optimized + tăng maximum size của Auto Scaling group. Đây là phương án gần đúng nhất, vì nửa đầu chính là chiến lược mà đáp án đúng dùng. Chỗ hỏng nằm ở nửa sau: MaxSize chỉ là trần số instance mà nhóm được phép có, nó không nói gì về việc capacity có thực sự kiếm được hay không. Nếu nhóm đang không lấy nổi Spot capacity đúng giờ thì nâng trần lên cũng chẳng làm capacity xuất hiện, và nó cũng không hề làm instance đang chạy bớt bị thu hồi. Nói cách khác, A xử lý được vế "ít gián đoạn" nhưng bỏ trống vế "khởi chạy đúng lúc".

B — on-demand allocation strategy + mở rộng dải instance type. Nửa sau đúng hướng: nhiều instance type hơn thì nhiều lựa chọn hơn. Nhưng nửa đầu sai bối cảnh — đề nói ứng dụng chạy exclusively on Spot, mà chiến lược phân bổ on-demand không phải là thứ điều khiển cách Spot Instances chọn pool. Chọn B là bỏ mất chính cái cần chỉnh để giảm interruption của Spot.

D — on-demand allocation strategy + tăng maximum size. Phương án này gộp đúng hai chỗ yếu của A và B: chiến lược phân bổ không tác động tới hành vi Spot trong tình huống đề nêu, còn nâng MaxSize thì không tạo ra capacity cũng không giảm số lần bị thu hồi. Không vế nào trong hai yêu cầu được giải quyết.

📌 Điểm cần nhớ

• Trong Auto Scaling group chạy Spot, capacity-optimized là chiến lược hướng tới việc giảm tần suất bị interrupt, vì nó ưu tiên pool đang còn nhiều capacity nhất.
• Đa dạng hoá instance type là đòn bẩy chính để lấy đủ capacity đúng thời điểm: mỗi instance type mở thêm Spot pool để nhóm chọn, và cũng là điều kiện để chiến lược phân bổ có chỗ mà tối ưu.
• MaxSize không phải công cụ giải quyết vấn đề capacity. Nó chỉ đặt trần cho quy mô nhóm, không đảm bảo instance được cấp phát, cũng không ảnh hưởng tới việc Spot Instances có bị thu hồi hay không.
• Khi đề chốt sẵn "chỉ chạy Spot", hãy loại ngay các phương án đổi sang chiến lược phân bổ on-demand — chúng không phải là nút chỉnh cho hành vi Spot mà đề đang than phiền.
• Với câu hỏi nêu hai triệu chứng (chậm scale + hay bị terminate), đáp án đúng thường phải chạm vào cả hai; phương án chỉ chữa một vế là bẫy gần đúng.

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

Đề mô tả một VPC mới tạo ở Region us-east-1, bên trong chạy các EC2 instance cho site phát triển, và hỏi cần hai bước nào để những instance đó có kết nối internet.

Cụm từ quyết định đáp án nằm ở câu: "requires both incoming and outgoing connectivity to the internet" — cần kết nối internet theo cả hai chiều, vào lẫn ra. Đây chính là ràng buộc phân biệt hai họ phương án trong danh sách:

• Internet gateway (IGW) + route table trỏ tới nó → hai chiều, miễn là instance nằm ở public subnet và có public IP.
• NAT gateway → chỉ một chiều ra (outbound). Instance phía sau NAT gateway không nhận được kết nối khởi tạo từ internet.

Chỉ cần đọc thấy "incoming", mọi phương án dính đến NAT gateway đã bị loại ngay, không cần cân nhắc thêm.

Chi tiết thứ hai đáng chú ý: VPC mới tạo thì chưa có internet gateway gắn vào, và route table mặc định chỉ có route nội bộ của VPC. Vì vậy phải làm đủ cả hai việc — tạo/gắn IGW và thêm route — chứ không phải một trong hai.

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

Đáp án theo tệp là B và C.

B — Create an internet gateway and attach it to the VPC. Internet gateway là thành phần cho phép lưu lượng đi giữa VPC và internet, hỗ trợ cả chiều vào lẫn chiều ra. Nó là tài nguyên độc lập, sau khi tạo phải attach vào đúng VPC thì mới dùng được. Đây là điều kiện cần: không có IGW gắn vào VPC thì mọi cấu hình phía sau đều vô nghĩa.

C — Add an entry to the route table for the subnet that points to the internet gateway. Có IGW mà không có route trỏ tới thì gói tin ra internet không biết đi đâu. Phải thêm một entry trong route table gắn với subnet (thường là 0.0.0.0/0 → IGW) để biến subnet đó thành public subnet. Đúng như giải thích gốc: cách kết hợp này ngầm định EC2 instance được đặt trong public subnet và có public IP, nhờ đó gửi thẳng lưu lượng qua internet gateway và cũng nhận được lưu lượng từ internet vào.

Hai bước này bổ sung cho nhau — B tạo đường, C chỉ đường — nên đề mới bắt chọn hai.

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

A — Add a NAT Gateway in private subnet. Sai vì hai lý do chồng lên nhau. Thứ nhất, NAT gateway chỉ phục vụ chiều outbound: instance bên trong khởi tạo kết nối ra ngoài được, nhưng internet không khởi tạo kết nối vào được — trái với yêu cầu "incoming". Thứ hai, về mặt triển khai thì NAT gateway (loại public) phải được đặt trong public subnet chứ không phải private subnet; đặt vào private subnet là sai chỗ. Đây là phương án trông "gần đúng" với người chỉ nhớ mang máng "NAT = ra internet", nhưng nó hỏng ở cả chiều lưu lượng lẫn vị trí đặt.

D — Attach an Elastic IP address to the internet gateway. Sai vì internet gateway không nhận Elastic IP. IGW là thành phần do AWS quản lý, được scale ngang và có tính sẵn sàng cao; thao tác duy nhất bạn làm với nó là attach vào VPC. Elastic IP là địa chỉ gán cho instance (qua network interface) hoặc cho NAT gateway, không phải cho IGW. Phương án này đánh vào việc người học hay lẫn "cần public IP để ra internet" thành "cần gán IP cho gateway".

E — Add a NAT gateway to a private subnet. Về bản chất trùng với A, chỉ khác cách diễn đạt. Vẫn là NAT gateway, vẫn chỉ cho outbound, nên không đáp ứng được vế "incoming" của đề. Việc đề đưa ra hai biến thể gần như y hệt là dấu hiệu cho thấy cả hai đều là mồi nhử — nếu NAT gateway là đáp án đúng thì không thể có hai phương án giống nhau cùng đúng trong một câu chọn hai.

📌 Điểm cần nhớ

• Đọc chiều lưu lượng trước tiên. "Inbound/incoming" hoặc "hai chiều" → internet gateway. "Chỉ outbound", "instance ở private subnet cần tải bản vá/gọi API ra ngoài" → NAT gateway. Đây là lằn ranh phân biệt nhanh nhất trong họ câu hỏi về kết nối internet của VPC.
• Kết nối internet luôn cần đủ ba thứ, không chỉ một. IGW gắn vào VPC + route 0.0.0.0/0 trỏ tới IGW trong route table của subnet + public IP trên instance. Thiếu route là lỗi kinh điển: IGW đã có mà instance vẫn không ra được internet.
• NAT gateway nằm ở public subnet, phục vụ cho private subnet. Vị trí đặt và đối tượng phục vụ là hai chuyện khác nhau — phương án nào nói "NAT gateway trong private subnet" đều đáng nghi ngay.
• Elastic IP không gán cho internet gateway. IGW do AWS quản lý, chỉ có thao tác attach/detach với VPC. Elastic IP thuộc về instance/network interface hoặc NAT gateway.

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

Đề mô tả một tình huống rất quen: thông tin đăng nhập database đã được cất dưới dạng secure string parameter trong AWS Systems Manager Parameter Store, và một ứng dụng chạy trên EC2 instance cần đọc chúng để kết nối database.

Câu hỏi chốt bằng một cụm từ: "the MOST secure way to grant the application access" — nghĩa là cả bốn phương án đều có thể "làm cho chạy được", nhưng chỉ một cái an toàn nhất.

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

• "An application running on an Amazon EC2 instance" — chủ thể cần quyền là một máy, không phải một con người. Trong IAM, danh tính gắn được vào EC2 instance chỉ có một loại duy nhất: IAM role (qua instance profile).
• "MOST secure" — loại bỏ mọi cách phải phát sinh và cất giữ long-term access key trên instance.

Nói cách khác, câu này không hỏi "chính sách nào cho phép đọc parameter", mà hỏi gắn quyền đó vào EC2 bằng loại danh tính nào.

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

Đáp án đúng theo tệp là D — Create an IAM role for the EC2 instances and grant the role permission to read the Systems Manager parameters.

Systems Manager chỉ hỗ trợ identity-based policy, tức là quyền phải được gắn vào một identity: user, group hoặc role. Với workload chạy trên EC2, identity đúng là IAM role được attach vào instance thông qua instance profile.

Cơ chế này an toàn nhất vì:

• EC2 nhận temporary credentials từ instance metadata, do AWS tự cấp và tự xoay vòng. Không có access key nào bị ghi vào file cấu hình, biến môi trường hay image trên đĩa.
• Không có bí mật dài hạn nào để rò rỉ qua log, snapshot hay repo mã nguồn.
• Quyền đi theo instance, nên thu hồi hoặc siết lại chỉ cần sửa policy của role, không phải đi luân chuyển khoá trên từng máy.

Đây chính là mô hình delegation mà giải thích gốc nhắc tới: EC2 được "uỷ quyền" assume role thay vì mang sẵn danh tính cố định.

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

A — Create an IAM user for the application. Đây là phương án gần đúng nhất về mặt chức năng: IAM user đọc được Parameter Store, và nếu tạo access key rồi nhét vào ứng dụng thì nó chạy. Nhưng nó hỏng đúng ở chỗ đề nhấn mạnh — MOST secure. IAM user dùng cho ứng dụng đồng nghĩa với long-term access key nằm trên instance: phải tự xoay vòng thủ công, dễ lọt vào code hoặc AMI, và ai đọc được đĩa/snapshot là dùng được ở bất kỳ đâu. Role giải quyết đúng những điểm này, nên A luôn thua khi đề hỏi cách an toàn nhất.

B — Create an IAM group for the application. Sai ở tầng khái niệm, không chỉ ở mức "kém an toàn hơn". Group không phải là một identity có thể assume hay attach vào tài nguyên — group chỉ là bộ chứa để gom IAM user và áp policy chung cho họ. Không có cách nào gán một IAM group cho EC2 instance. Nếu chọn B, bạn vẫn cần một user nằm trong group đó, và lập tức quay về đúng mọi vấn đề của phương án A.

C — Create an IAM policy for the application and grant the policy permission… Đây là phương án bẫy tinh vi nhất, vì nghe rất hợp lý: quyền đọc parameter đúng là được mô tả trong một IAM policy. Chỗ hỏng là policy tự nó không phải một danh tính. Policy chỉ là văn bản mô tả quyền; nó phải được attach vào một user, group hay role thì mới có hiệu lực. Câu hỏi hỏi cách cấp quyền cho ứng dụng trên EC2, và câu trả lời buộc phải nêu ra vật mang policy đó — với EC2 thì vật mang duy nhất là IAM role. Nói cách khác, C mới đi được nửa đường: nó tạo ra quyền nhưng không nối được quyền ấy vào instance.

📌 Điểm cần nhớ

• Compute cần quyền → IAM role, luôn luôn. EC2, Lambda, ECS task, EKS pod: khi chủ thể là máy chứ không phải người, đáp án đúng gần như chắc chắn là role, không phải user.
• IAM group chỉ chứa IAM user. Không attach được vào EC2 instance hay bất kỳ tài nguyên AWS nào — thấy "group" trong một câu hỏi về workload là loại được ngay.
• IAM policy là quyền, không phải danh tính. Policy phải được attach vào user/group/role mới có tác dụng; một phương án chỉ dừng ở "tạo policy" là chưa trả lời xong câu hỏi.
• Từ khoá "MOST secure" thường tương đương "không có long-term credential". Nó tách IAM user (access key tĩnh, phải tự xoay vòng) khỏi IAM role (temporary credential do AWS cấp và tự xoay vòng qua instance metadata).
• Systems Manager dùng identity-based policy, nên quyền đọc secure string parameter phải gắn vào identity gọi API — với ứng dụng trên EC2, identity đó là role trong instance profile.

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

Đề mô tả một công ty đang cho nhân viên IT đăng nhập AWS Management Console bằng IAM user riêng lẻ, quyền gán qua IAM policy và IAM group. Yêu cầu của security team là: nhân viên phải đăng nhập bằng tài khoản Active Directory on-premises thay cho IAM user.

Cụm từ quyết định đáp án là "on-premises Active Directory" kết hợp với "log in ... when accessing the AWS Management Console". Hai chi tiết này ràng buộc lời giải theo hai hướng:

• Directory nằm on-premises, tức là nó không ở trong AWS. Muốn dịch vụ AWS nói chuyện được với domain controller đang chạy dưới trung tâm dữ liệu của công ty thì phải có đường mạng riêng giữa VPC và mạng nội bộ — VPN tunnel (hoặc Direct Connect) là bắt buộc, không phải chi tiết trang trí.
• Yêu cầu là đăng nhập bằng danh tính AD, chứ không phải sao chép người dùng AD thành IAM user. Nghĩa là cần cơ chế federated sign-in: danh tính AD được ánh xạ sang IAM role, người dùng nhận credential tạm thời chứ không có IAM user thường trực.

Phương án nào không đồng thời đáp ứng cả hai điều kiện đó thì loại.

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

Đáp án đúng là C — Implement a VPN tunnel and configure an Active Directory connector.

AD Connector là một directory gateway: nó không lưu bản sao thư mục trong AWS mà chuyển tiếp (proxy) yêu cầu xác thực về thẳng domain controller on-premises. Nhờ vậy mật khẩu và thông tin người dùng vẫn nằm nguyên tại chỗ, đúng ý "đăng nhập bằng tài khoản AD của mình".

Đúng như phần giải thích tiếng Anh của câu hỏi nêu, khi cấu hình AD Connector, quan hệ tin cậy giữa AD và AWS cho phép:

• Đăng nhập các ứng dụng AWS như Amazon WorkSpaces, Amazon WorkDocs, Amazon WorkMail bằng credential Active Directory.
• Tự động join các Windows instance vào domain AD, qua EC2 launch wizard hoặc qua API của Systems Manager.
• Federated sign-in vào AWS Management Console bằng cách ánh xạ danh tính Active Directory sang IAM role — đây chính là điều đề bài yêu cầu.

Vế VPN tunnel giải quyết phần còn lại: AD Connector phải chạm tới được domain controller on-premises, nên cần kết nối mạng riêng giữa VPC và mạng công ty. Ghép hai thứ lại, ta có đúng luồng: nhân viên nhập credential AD → AD Connector chuyển yêu cầu qua VPN về domain controller → xác thực xong thì được federated vào Console dưới một IAM role.

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

A — Use the IAM connector to synchronize the on-premises Active Directory. Sai vì không tồn tại thứ gọi là "IAM connector". Đây là tên bịa, nghe hợp lý vì có chữ IAM và chữ connector đứng cạnh nhau. Ngoài ra hướng "synchronize" cũng ngược với yêu cầu: đồng bộ nghĩa là tạo bản sao người dùng bên phía AWS, trong khi đề muốn nhân viên đăng nhập bằng chính tài khoản AD, không phải bằng bản sao của nó.

B — Enable an Active Directory federation in an Amazon Route 53 private zone. Sai vì nhầm vai trò dịch vụ. Route 53 private hosted zone chỉ làm phân giải tên miền DNS trong phạm vi VPC — nó trả lời "tên này ứng với địa chỉ nào", chứ không xác thực người dùng và không có khái niệm federation. Đúng là một triển khai AD thực tế cần DNS hoạt động chuẩn, nhưng DNS chỉ là điều kiện hạ tầng phụ trợ; bản thân private hosted zone không thể "enable Active Directory federation".

C — đáp án đúng, đã phân tích ở trên.

D — Implement a two-way trust relationship between AWS IAM and Active Directory. Đây là phương án gần đúng nhất và cũng gài bẫy khéo nhất, vì trust relationship là khái niệm có thật trong thế giới Active Directory. Chỗ hỏng nằm ở hai đầu của quan hệ tin cậy: trust là cơ chế giữa directory với directory, ví dụ giữa AD Directory Service (AWS Managed Microsoft AD) và AD on-premises. IAM không phải là một directory kiểu AD — nó là hệ thống quản lý quyền của AWS, không có domain, không tham gia vào mô hình trust của Windows. Vì vậy không thể thiết lập two-way trust "giữa AWS IAM và Active Directory" theo đúng nghĩa đen mà phương án viết. Quan hệ tin cậy trong đáp án C là quan hệ tin cậy do AD Connector tạo ra, bản chất khác hẳn.

📌 Điểm cần nhớ

• AD Connector = proxy, không lưu bản sao. Chọn nó khi đề nói directory phải ở lại on-premises và người dùng đăng nhập bằng credential AD gốc. Nếu đề muốn một directory chạy hẳn trong AWS thì đó là bài toán của AWS Managed Microsoft AD, không phải AD Connector.
• Thấy "on-premises" là phải nghĩ tới đường mạng riêng. Bất kỳ dịch vụ AWS nào cần chạm tới máy chủ trong trung tâm dữ liệu của công ty đều đòi VPN hoặc Direct Connect; phương án thiếu vế kết nối mạng thường là phương án chưa hoàn chỉnh.
• Trust relationship là chuyện giữa directory với directory, không phải với IAM. IAM không đóng vai một domain, nên mọi phương án nói "trust giữa IAM và AD" đều loại được ngay mà không cần đọc tiếp.
• Federation vào Console luôn đi qua IAM role, không qua IAM user. Danh tính bên ngoài được ánh xạ sang role và nhận credential tạm thời; nếu một phương án đề xuất "đồng bộ" người dùng bên ngoài thành IAM user, nó đang đi ngược yêu cầu "đăng nhập bằng tài khoản AD".
• Cảnh giác với tên dịch vụ nghe quen nhưng không có thật (kiểu "IAM connector"), và với việc gán sai vai trò cho dịch vụ có thật (Route 53 là DNS, không phải hệ xác thực).

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

Đề mô tả một công ty có nhiều phòng ban (departments) và đặt ra hai yêu cầu cùng lúc:

1. "each department operates within their own isolated environment" — mỗi phòng ban phải nằm trong một môi trường tách biệt.
2. "only be able to use AWS services that have been pre-approved" — chỉ được dùng các dịch vụ AWS đã được duyệt trước.

Cụm từ quyết định là "isolated environment" đi kèm "pre-approved services". Đây là bộ đôi phân biệt: rất nhiều phương án làm được vế thứ hai (giới hạn dịch vụ) nhưng chỉ một phương án làm được vế thứ nhất (ranh giới cô lập thật sự). Trên AWS, ranh giới cô lập mạnh nhất về mặt quản trị, hạn ngạch, tính tiền và bán kính ảnh hưởng chính là AWS account — không phải VPC, không phải IAM policy. Khi đề nói "isolated environment" cho từng đơn vị tổ chức, hãy nghĩ ngay tới multi-account.

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

C — Dùng AWS Organizations tạo account riêng cho từng phòng ban, rồi áp service control policies (SCPs) để kiểm soát các dịch vụ đã được duyệt.

Phương án này giải quyết cả hai vế, mỗi vế bằng đúng công cụ dành cho nó:

• AWS Organizations cho phép tạo account mới cho từng phòng ban (làm được qua Organizations API nên tạo hàng loạt được). Mỗi account là một ranh giới cô lập tự nhiên: tài nguyên, IAM principal, hạn mức và hoá đơn đều tách bạch.
• SCPs là guardrail ở tầng tổ chức: chúng đặt trần quyền cho mọi principal trong account đó, kể cả người dùng có quyền quản trị. Nhờ vậy có thể cho phép đúng tập dịch vụ đã duyệt và chặn tất cả phần còn lại — và không ai trong account tự nới ra được, vì SCP đứng trên IAM policy chứ không phải ngang hàng.

Đó chính là ý "pre-approved set of services to be accessible whilst denying access to all others": SCP quyết định cái gì được phép tồn tại, IAM trong account quyết định ai được dùng những cái đó.

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

A — IAM policies cho từng phòng ban, gắn vào user accounts. Đây là phương án gần đúng ở vế "giới hạn dịch vụ": IAM policy thật sự chặn được dịch vụ. Nhưng nó hỏng ở hai chỗ. Thứ nhất, không tạo ra môi trường cô lập — mọi phòng ban vẫn ngồi chung một account, chung không gian tài nguyên, chung hạn mức, chung hoá đơn. Thứ hai, nó là gánh nặng quản trị: phải gắn và duy trì policy cho từng user, sót một user hoặc một role mới tạo là thủng ngay. IAM là quyền của từng principal, không phải trần quyền của cả môi trường.

B — AWS Service Catalog chứa danh mục dịch vụ đã duyệt cho mỗi phòng ban. Service Catalog chuẩn hoá được cái gì người dùng được cấp phát, nhưng nó không tạo ra môi trường cô lập cho từng phòng ban — đó chính là vế đầu tiên của đề, và phương án này bỏ trống hoàn toàn. Cần nhớ thêm: Service Catalog là cơ chế cung cấp sản phẩm đã được duyệt, chứ tự nó không phải hàng rào chặn người ta đụng vào dịch vụ ngoài danh mục.

D — VPC riêng cho từng phòng ban, giới hạn dịch vụ bằng IAM roles. Phương án này gần đúng nhất và cũng dễ bẫy nhất, vì nó nhắc tới cả "tách biệt" lẫn "giới hạn dịch vụ". Nhưng hỏng ở cả hai vế:

• VPC chỉ cô lập ở tầng mạng. Các phòng ban vẫn nằm trong cùng một account, dùng chung IAM, chung hạn mức, chung hoá đơn — không phải "isolated environment" theo nghĩa đề hỏi. Nhiều dịch vụ AWS còn không nằm trong VPC nào cả.
• IAM role chỉ có tác dụng khi được assume. Quyền của một người dùng không tự động bị bó lại bởi sự tồn tại của một role; muốn role giới hạn được thì phải ép mọi truy cập đi qua role đó, mà phương án không nói gì tới chuyện ấy.

📌 Điểm cần nhớ

• Đề nhắc "isolated environment" cho từng phòng ban / nhóm / dự án → nghĩ tới multi-account với AWS Organizations. Account là ranh giới cô lập mạnh nhất; VPC chỉ cô lập mạng, IAM chỉ cô lập quyền của principal.
• SCP là trần quyền, IAM là cấp quyền. SCP áp cho toàn bộ principal trong account (kể cả admin) nên phù hợp với yêu cầu "chỉ được dùng dịch vụ đã duyệt trước"; IAM policy thì ai có quyền sửa IAM đều nới ra được.
• Câu hỏi có hai yêu cầu thì loại phương án theo yêu cầu mà ít phương án đáp ứng nhất — ở đây là "isolated environment". A, B, D đều rụng ngay ở vế này.
• Service Catalog trả lời câu hỏi "người dùng được cấp phát sẵn những gì", không trả lời câu hỏi "họ bị chặn khỏi những gì" và cũng không tạo ranh giới cô lập.

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

Đề mô tả một tình huống rất gọn: chuyên gia tư vấn bảo mật đã xác định được những rule thừa trong security group và network ACL, và những rule đó đang tạo ra rủi ro. Câu hỏi là SysOps Administrator phải làm gì để xử lý dứt điểm lỗ hổng.

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

• "has identified" — việc phát hiện đã xong rồi. Mọi phương án chỉ giúp tìm ra vấn đề đều thừa ở bước này, vì thông tin đã nằm trong tay.
• "resolve" (thay vì "detect", "monitor" hay "report") — đề đòi hành động khắc phục thực sự làm biến mất rủi ro, chứ không phải một lớp bảo vệ đắp thêm bên ngoài.

Ngoài ra còn một tầng nữa mà đề ngầm kiểm tra: shared responsibility model. Security group và network ACL là cấu hình do khách hàng tự đặt trong VPC của mình — chúng thuộc phần "security in the cloud". AWS chịu trách nhiệm cho hạ tầng bên dưới, không chịu trách nhiệm cho rule mà khách hàng tự mở.

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

A — Remove the unnecessary security group rules and network ACL rules.

Rủi ro ở đây chính là sự tồn tại của các rule thừa. Security group và network ACL là các bộ lọc traffic do khách hàng cấu hình; sửa chúng là quyền và cũng là nghĩa vụ của SysOps Administrator. Danh sách rule cần bỏ đã có sẵn từ đợt rà soát, nên hành động trực tiếp nhất — và cũng là hành động duy nhất trong bốn phương án thực sự loại bỏ nguyên nhân — là xoá đúng những rule đó đi. Sau khi xoá, bề mặt tấn công thu hẹp lại ngay lập tức, không cần thêm dịch vụ nào khác.

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

B — Use Amazon Inspector to identify security best practices and rectify issues.

Đây là phương án gần đúng nhất và cũng là cái bẫy chính. Amazon Inspector đúng là một dịch vụ đánh giá bảo mật, đưa ra khuyến nghị theo best practice. Nhưng nó hỏng ở hai điểm: thứ nhất, nó làm công việc đánh giá/phát hiện, mà việc phát hiện thì chuyên gia tư vấn đã hoàn thành rồi — chạy Inspector chỉ để nghe lại điều mình đã biết. Thứ hai, và quan trọng hơn, Inspector báo cáo chứ không tự sửa cấu hình cho bạn; chữ "rectify issues" trong phương án là phần được gán thêm chứ không phải điều dịch vụ này làm. Chọn B thì rule thừa vẫn nguyên đó.

C — Contact AWS Support and notify them of the vulnerabilities.

Sai vì hiểu nhầm ranh giới trách nhiệm. Rule trong security group và network ACL do chính khách hàng tạo ra và chỉ khách hàng mới nên thay đổi — AWS Support không can thiệp vào cấu hình bảo mật bên trong tài khoản của bạn theo kiểu này. Báo cho Support là chuyển một việc mình làm được trong vài phút thành một ticket không ai xử lý. Cơ chế báo cáo cho AWS được dùng cho những chuyện khác, ví dụ nghi ngờ vấn đề ở hạ tầng thuộc phần "security of the cloud", không phải cho rule mình tự mở.

D — Create an AWS WAF web ACL that protects resources from web attacks.

Sai vì nhầm tầng bảo vệ. AWS WAF lọc traffic ở tầng ứng dụng web và chỉ gắn được vào một số loại resource nhất định như CloudFront distribution, Application Load Balancer hay API Gateway. Nó hoàn toàn không đụng tới rule của security group hay network ACL — hai thứ này lọc ở tầng mạng, thuộc về VPC. Dựng thêm web ACL là chồng thêm một lớp phòng thủ mới trong khi cửa cũ vẫn mở nguyên; rủi ro ban đầu không hề giảm đi. Cũng lưu ý chữ "ACL" xuất hiện ở cả "network ACL" lẫn "web ACL" nhưng chúng là hai khái niệm khác hẳn nhau — đây là điểm dễ bị đánh lừa khi đọc lướt.

📌 Điểm cần nhớ

• Đọc kỹ thì của động từ trong đề: nếu vấn đề đã được phát hiện, mọi dịch vụ thiên về đánh giá/quét (như Amazon Inspector) đều là bước lùi, không phải bước xử lý.
• Shared responsibility model: cấu hình security group và network ACL là "security in the cloud" — trách nhiệm của khách hàng. Câu nào có lựa chọn "liên hệ AWS Support" cho một thứ nằm trong tài khoản của bạn thì gần như chắc chắn là sai.
• Phân biệt tầng bảo vệ: AWS WAF làm việc với web request trên CloudFront/ALB/API Gateway; security group và network ACL lọc traffic ở tầng mạng trong VPC. Thêm cái này không sửa được cái kia.
• Kỳ thi thường ưu tiên hành động trực tiếp, đơn giản nhất giải quyết đúng nguyên nhân hơn là giải pháp thêm dịch vụ mới — đặc biệt khi nguyên nhân đã được chỉ đích danh.

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

Đề mô tả một Amazon RDS MySQL DB instance chạy trong production account, và mỗi tuần phải sao chép một bản backup của database sang một development account riêng biệt để test. Câu hỏi kết lại bằng: "What is the MOST cost-effective way?"

Hai cụm từ quyết định đáp án nằm ở đây:

• "a separate development account" — dữ liệu phải đi qua ranh giới AWS account. Đây là ràng buộc lọc mạnh nhất: cơ chế nào không hỗ trợ chia sẻ liên account thì loại ngay, bất kể nghe hợp lý tới đâu.
• "a backup ... must be copied" — thứ cần di chuyển là một bản snapshot, chứ không phải một bản sao database đang chạy. Cụm "MOST cost-effective" đẩy tiếp: giải pháp nào phải nuôi thêm một DB instance đang chạy thì tự loại vì tốn tiền compute liên tục, trong khi việc chỉ cần một lần mỗi tuần.

Ghép hai ràng buộc đó: cần một cơ chế snapshot chia sẻ được sang account khác, và không phát sinh tài nguyên chạy thường trực.

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

Đáp án đúng là A — tạo manual RDS snapshot bằng create-db-snapshot, share sang development account, rồi tạo bản copy ở account đó.

RDS cho phép share manual DB snapshot với các AWS account khác được uỷ quyền. Đây là con đường chính thức và duy nhất trong danh sách để đưa một bản backup RDS sang account khác:

• Manual snapshot, dù được mã hoá hay không, đều có thể share để account được uỷ quyền copy lại về phía họ.
• Với manual snapshot không mã hoá, account nhận thậm chí có thể restore thẳng một DB instance từ snapshot đó mà không cần copy trước.
• Một manual snapshot share được cho một số lượng account khác nhất định, và cũng có thể đặt ở chế độ public.

Về chi phí: snapshot chỉ tính tiền lưu trữ, không có compute nào chạy thường trực. Việc chạy mỗi tuần một lần bằng một lệnh CLI đúng với tinh thần "MOST cost-effective" mà đề yêu cầu. Điểm mấu chốt cần nhớ là chữ manual — đó là loại snapshot mà bạn kiểm soát vòng đời và share được.

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

B — Dùng Amazon S3 cross-region replication (CRR) để copy automated backup sang development account. Sai. RDS snapshot được lưu trên S3 ở phía sau hậu trường, nhưng không nằm trong bucket S3 mà bạn nhìn thấy hoặc thao tác được. Bạn không có quyền truy cập trực tiếp vào nơi lưu snapshot, nên không thể gắn CRR hay bất kỳ rule replication nào lên đó. Ngoài ra CRR là cơ chế nhân bản giữa các Region, không phải cơ chế chuyển dữ liệu giữa các account theo cách đề đang cần. Đây là phương án nghe có vẻ có lý vì "snapshot nằm trên S3", nhưng nó vấp đúng chỗ: cái S3 đó không phải của bạn.

C — Tạo Multi-AZ standby của RDS database trong development account rồi chụp manual snapshot. Sai ở hai tầng. Thứ nhất, về mặt kỹ thuật, Multi-AZ standby không thể đặt ở một AWS account khác — Multi-AZ là cấu hình dự phòng giữa các Availability Zone bên trong cùng một DB instance, cùng một account, không phải cơ chế nhân bản liên account. Thứ hai, kể cả nếu làm được thì standby là một instance chạy thường trực, tốn tiền 24/7 chỉ để phục vụ một lần copy mỗi tuần — đối lập hoàn toàn với "MOST cost-effective".

D — Copy một automated RDS snapshot sang development account bằng copy-db-snapshot. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. Lệnh copy-db-snapshot là lệnh đúng, ý tưởng copy snapshot cũng đúng — nhưng nó hỏng ở loại snapshot: bạn không thể share hay copy trực tiếp một automated snapshot sang account khác. Automated backup do RDS tự quản lý theo backup retention period, gắn chặt với DB instance gốc và không share được. Muốn dùng automated snapshot, bạn phải copy nó thành một manual snapshot trong chính account của mình trước đã — mà bước đó không có trong phương án D. So sánh D với A thấy rõ: A đi đúng đường vì bắt đầu bằng create-db-snapshot để tạo ra manual snapshot.

📌 Điểm cần nhớ

• Chỉ manual DB snapshot mới share được sang AWS account khác. Automated snapshot do RDS quản lý, không share và không copy trực tiếp liên account được — gặp từ "automated" trong phương án chia sẻ dữ liệu thì gần như chắc chắn là bẫy.
• RDS snapshot lưu trên S3 nhưng bạn không truy cập được bucket đó. Mọi phương án dùng công cụ S3 (CRR, lifecycle rule, sync trực tiếp) lên RDS snapshot đều sai về nguyên tắc.
• Multi-AZ là cơ chế high availability trong cùng một account, không phải cơ chế sao chép dữ liệu liên account. Đừng nhầm Multi-AZ với read replica hay với snapshot sharing.
• Khi đề hỏi "MOST cost-effective" cho một tác vụ chạy định kỳ thưa (mỗi tuần, mỗi tháng), hãy loại các phương án phải nuôi tài nguyên compute chạy liên tục; snapshot chỉ tính phí lưu trữ nên thường là lựa chọn đúng.

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

Đề mô tả một website đặt tại Singapore, phần lớn nội dung là static content — hình ảnh và video — nằm trong Amazon S3. Người dùng ở xa (Europe, và câu hỏi nhắc thêm Canada, Asia) than phiền tải chậm, trong khi thử nghiệm tại chỗ ở Singapore hoàn toàn không thấy vấn đề gì.

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

• "no performance issues are observed during local testing" — nghĩa là bản thân S3, băng thông origin và ứng dụng đều khoẻ. Vấn đề duy nhất là khoảng cách địa lý: gói tin phải đi nửa vòng trái đất, độ trễ đến từ quãng đường chứ không đến từ hệ thống.
• "large amount of static content, including images and videos" — nội dung tĩnh, không đổi theo từng người dùng, nên cache lại được và phục vụ lại nhiều lần.

Ghép hai điều kiện đó: cần đưa bản sao nội dung tĩnh tới gần người dùng cuối. Đó chính xác là định nghĩa của một CDN.

Một chi tiết nữa cần chú ý: đề hỏi cải thiện trải nghiệm cho người dùng đọc/tải xuống, không phải cho người tải lên. Ràng buộc này chính là thứ loại bỏ phương án gần đúng nhất.

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

B — Create an Amazon CloudFront distribution for the website with an S3 origin.

CloudFront là dịch vụ CDN của AWS. Bạn tạo một distribution, khai S3 bucket làm origin, và CloudFront sẽ phân phối nội dung qua mạng edge location trải khắp thế giới.

Cách nó giải quyết đúng vấn đề trong đề:

• Yêu cầu của người dùng ở Europe/Canada dừng lại ở edge location gần họ thay vì đi thẳng về Singapore. Quãng đường vòng ngắn hơn nhiều lần → thời gian tải ảnh và video giảm hẳn.
• Nội dung tĩnh được cache tại edge, nên từ lượt truy cập thứ hai trở đi không cần chạm tới S3 origin nữa. Với "large amount of static content" thì tỷ lệ cache hit rất cao — đây là kịch bản lý tưởng của CDN.
• Kể cả khi cache miss, CloudFront vẫn kéo nội dung về qua mạng backbone của AWS thay vì đường Internet công cộng, nên vẫn ổn định hơn.
• Đây là giải pháp MOST effective: chỉ cần cấu hình, không phải sao chép dữ liệu sang nhiều Region, không phải đổi kiến trúc lưu trữ.

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

A — Amazon API Gateway ở mỗi Region, bật caching trên stage. API Gateway sinh ra để làm cửa ngõ cho API, tức nội dung động phản hồi theo hành động của người dùng. Ở đây nội dung là ảnh và video tĩnh trong S3 — không có API nào cả. Dựng API Gateway ở nhiều Region cũng chỉ tạo được vài điểm hiện diện theo Region, ít và thưa hơn hẳn mạng edge location, lại còn phải tự lo việc đồng bộ và định tuyến người dùng tới Region gần nhất. Phức tạp hơn, đắt hơn, mà phục vụ file tĩnh cỡ lớn không phải việc của nó.

C — Bật S3 Transfer Acceleration, dùng endpoint s3-accelerate. Đây là phương án gần đúng nhất và cũng là cái bẫy chính, vì nó cũng dùng edge location của CloudFront. Chỗ hỏng nằm ở hướng của luồng dữ liệu: Transfer Acceleration được thiết kế để tăng tốc đưa dữ liệu vào bucket qua khoảng cách xa — nó nhận file ở edge rồi đẩy tiếp về bucket qua mạng nội bộ AWS. Nó không cache nội dung để phục vụ lại người đọc. Trong đề, người dùng ở Europe đang tải xuống ảnh và video, không phải upload. Dùng Transfer Acceleration ở đây là chọn đúng công nghệ nhưng sai chiều.

D — Triển khai AWS Direct Connect cho Amazon S3. Direct Connect là đường truyền riêng nối trung tâm dữ liệu của bạn với AWS. Nó giúp băng thông giữa hạ tầng on-premises và AWS ổn định, dự đoán được. Nhưng người dùng cuối trong đề là khách vào website qua Internet — họ không hề đi qua đường Direct Connect của công ty. Ngoài ra đây là giải pháp cần thời gian thiết lập vật lý và chi phí lớn, hoàn toàn không chạm tới nguyên nhân thật là khoảng cách giữa người đọc và origin.

📌 Điểm cần nhớ

• Static content + người dùng phân tán toàn cầu + latency cao = CloudFront. Nhận ra mẫu này là gần như xong câu hỏi.
• Phân biệt rõ CloudFront (tăng tốc download, có cache tại edge) với S3 Transfer Acceleration (tăng tốc upload vào bucket, không cache). Cả hai đều dùng edge location nên rất dễ nhầm — hãy hỏi "dữ liệu đang chạy theo chiều nào?".
• Direct Connect phục vụ kết nối on-premises ↔ AWS, không bao giờ là câu trả lời cho việc cải thiện trải nghiệm của khách truy cập Internet.
• Chi tiết "local testing bình thường, người dùng ở xa thì chậm" là dấu hiệu kinh điển cho vấn đề địa lý, không phải vấn đề dung lượng hay cấu hình của origin — đừng đi tìm cách nâng cấp storage hay compute.
• API Gateway hợp với nội dung động và API; đừng chọn nó khi đề nói rõ nội dung là file tĩnh.