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

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

Đề mô tả một công ty media chạy Amazon EC2 với EBS volume làm ổ lưu trữ, có lịch backup định kỳ theo quy định bảo trì. Một volume rơi vào trạng thái error. Câu hỏi: với vai trò SysOps Administrator, làm sao khôi phục dữ liệu và đưa EBS volume hoạt động trở lại.

Cụm từ quyết định là chính từ trạng thái: error status. Đây không phải một trạng thái mơ hồ mà là một giá trị cụ thể trong vòng đời của EBS volume, và nó mang đúng một ý nghĩa: phần cứng bên dưới volume đã hỏng, AWS coi volume là mất. Nó khác hẳn các trạng thái như creating, available, in-use, hay tình huống volume vẫn lành nhưng OS không mount được. Cụm từ thứ hai đáng chú ý là "scheduled backups" — đề cố ý đặt sẵn dữ kiện rằng đã có bản backup, tức đường thoát duy nhất đã nằm sẵn trong đề.

Ràng buộc phân biệt: phương án nào coi error là sự cố tạm thời, sửa được (restart, nối lại kênh liên lạc) thì sai; phương án nào coi error là hỏng vĩnh viễn, chỉ khôi phục từ backup sang volume mới thì đúng.

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

Đáp án đúng theo tệp là D: trạng thái error cho biết phần cứng bên dưới EBS volume đã hỏng; volume đó không cứu được, nhưng dữ liệu có thể khôi phục từ backup sang một EBS volume mới.

Theo tài liệu AWS mà phần giải thích tiếng Anh dẫn lại: khi volume vào trạng thái error, dữ liệu gắn với volume đó là unrecoverable và Amazon EBS xử lý volume như đã mất. Một thông báo sẽ xuất hiện trên Personal Health Dashboard của tài khoản khi volume rơi vào trạng thái này. Không có thao tác nào từ phía người quản trị đưa volume đó trở lại — cách duy nhất là dựng lại dữ liệu:

• Nếu có EBS snapshot của volume, tạo volume mới từ snapshot đó.
• Nếu không có snapshot, tạo một EBS volume mới rồi phục hồi dữ liệu bằng giải pháp backup thủ công đang dùng.

Đây chính là lý do đề nhấn mạnh "scheduled backups": kịch bản này là bài kiểm tra xem thí sinh có hiểu rằng backup là biện pháp duy nhất chống mất dữ liệu khi phần cứng EBS hỏng hay không. AWS khuyến nghị duy trì backup định kỳ cho volume quan trọng bằng Amazon Data Lifecycle Manager, AWS Backup, hoặc EBS snapshot thông thường.

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

A — error nghĩa là kênh liên lạc giữa EBS volume và instance bị đứt, restart instance để sửa. Phát biểu này sai ngay ở phần định nghĩa. Phần giải thích gốc nói thẳng đây là câu bịa đặt đưa vào làm distractor: EBS không định nghĩa error theo kiểu "mất kết nối tạm thời". Nếu chỉ là vấn đề attach/mount ở tầng instance thì volume vẫn ở trạng thái bình thường chứ không chuyển sang error.

B — Khôi phục volume từ Amazon Data Lifecycle Manager bằng cách chuyển volume sang EC2 instance khác có cấu hình DLM. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì Data Lifecycle Manager đúng là công cụ backup liên quan. Nhưng DLM chỉ tự động hoá việc tạo, giữ và xoá EBS snapshot cùng EBS-backed AMI. Nó không phải công cụ "sửa" volume, và nó không có khả năng phục hồi chính cái volume đang ở trạng thái error. Ngoài ra, "shifting the volume to another EC2 instance" là vô nghĩa ở đây: volume đã mất thì không attach sang đâu được. Cái dùng được từ DLM là snapshot mà nó đã tạo trước đó, và khi ấy ta vẫn tạo volume mới — tức quay về đúng đáp án D.

C — Restart instance đang gắn volume; nếu dữ liệu không hiện ra thì khôi phục từ scheduled backups. Vế sau của câu này đúng, nên nó trông hợp lý. Chỗ hỏng nằm ở vế đầu và ở thứ tự ưu tiên mà nó gợi ý: vấn đề nằm ở phần cứng bên dưới, restart instance không sửa được gì. Coi restart là bước chẩn đoán đầu tiên là hiểu sai bản chất trạng thái error — nó không phải trục trặc phần mềm tạm thời. Phương án D nói đúng nguyên nhân và đi thẳng tới hành động đúng, còn C dẫn người vận hành mất thời gian vào một thao tác không có tác dụng.

📌 Điểm cần nhớ

• Trạng thái error của EBS volume = phần cứng bên dưới đã hỏng, volume không phục hồi được; dữ liệu chỉ lấy lại từ snapshot hoặc backup, và phải đưa vào một volume mới.
• Khi volume vào trạng thái error, AWS gửi thông báo lên Personal Health Dashboard của tài khoản — đây là tín hiệu phân biệt sự cố phía AWS với sự cố cấu hình phía mình.
• Restart instance chỉ chữa được vấn đề ở tầng OS/instance. Bất kỳ phương án nào đề xuất restart để sửa một trạng thái hỏng ở tầng volume đều là distractor.
• Amazon Data Lifecycle Manager, AWS Backup và EBS snapshot là công cụ phòng ngừa, không phải công cụ cứu hộ. Giá trị của chúng nằm ở bản backup đã tạo trước sự cố; sau sự cố chúng không sửa được volume hỏng.

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

Đề mô tả một công ty dùng Amazon EFS để chia sẻ không gian lưu trữ cho nhiều instance của cùng một ứng dụng, và bạn — với vai trò SysOps Administrator — dùng EFS mount helper để mount file system. Câu hỏi: những tuỳ chọn nào có sẵn với EFS mount helper? (Chọn hai)

Cụm từ quyết định đáp án là "EFS mount helper" — chứ không phải "mount EFS nói chung". EFS mount helper là một công cụ trong gói amazon-efs-utils, và gói này là tập hợp công cụ cho Linux. Chính chi tiết đó loại thẳng mọi phương án nhắc tới Windows, bất kể là EC2 Windows hay Windows on-premises. Ràng buộc thứ hai nằm ở chữ "options are available with" — nghĩa là hỏi danh sách tính năng mà công cụ này hỗ trợ, nên phải đối chiếu từng phương án với danh sách tính năng thật của mount helper, chứ không suy đoán theo cảm giác "nghe hợp lý".

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

B — Auto-mounting when an EC2 instance reboots. Mount helper hỗ trợ tự động mount lại thư mục EFS mỗi khi EC2 instance khởi động lại. Cách làm là khai một dòng cho file system trong file /etc/fstab — file chứa thông tin về các file system cần mount lúc boot. Đây là một trong những tuỳ chọn được liệt kê chính thức của mount helper.

D — Mounting with IAM authorization. Mount helper cho phép mount EFS file system trên các Linux instance bằng uỷ quyền IAM, tức dùng danh tính IAM của instance để chứng minh quyền truy cập file system thay vì chỉ dựa vào network và POSIX permission.

Danh sách đầy đủ các tuỳ chọn của EFS mount helper gồm: mount trên các EC2 instance được hỗ trợ, mount với IAM authorization, mount với EFS access points, mount từ Linux client on-premises, tự động mount khi EC2 instance reboot, và mount khi một EC2 instance mới được khởi chạy. Hai phương án B và D nằm gọn trong danh sách này.

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

A — Mounting from Amazon EC2 Windows instances. Đây là phương án gần đúng nhất về mặt "nghe quen", vì EC2 là dịch vụ đúng và mount helper đúng là dùng để mount lên EC2. Chỗ hỏng nằm ở chữ Windows: Amazon EFS không hỗ trợ mount từ EC2 Windows instance. Mount helper thuộc gói amazon-efs-utils, được xây cho client Linux, nên tuỳ chọn này không tồn tại.

E — Mounting from on-premises Windows instances. Cùng một lỗi với A, và còn thêm một cái bẫy tinh vi hơn: mount helper thật sự có hỗ trợ mount từ client on-premises — nhưng là on-premises Linux client. Người học đọc lướt thấy "on-premises" quen mắt là chọn ngay. Từ khoá làm hỏng phương án vẫn là Windows, không phải "on-premises".

C — Mounting with Amazon Cognito authentication. Cognito là dịch vụ quản lý danh tính cho người dùng ứng dụng (web, mobile), không phải cơ chế uỷ quyền cho việc mount một file system ở tầng hệ điều hành. Amazon Cognito không dùng để bảo vệ truy cập dữ liệu lưu trên EFS file system. Phương án này được đặt vào để đối chọi với D — cả hai đều nói về "authentication/authorization", nhưng chỉ IAM mới là dịch vụ mà mount helper tích hợp.

📌 Điểm cần nhớ

• EFS mount helper = amazon-efs-utils = công cụ phía Linux client. Hễ phương án nào gắn EFS với Windows (EC2 Windows hay Windows on-premises) thì loại ngay, không cần đọc tiếp phần còn lại của câu.
• Danh sách tuỳ chọn của mount helper cần thuộc: EC2 instance được hỗ trợ, IAM authorization, EFS access points, Linux client on-premises, auto-mount khi reboot (qua /etc/fstab), và mount khi instance mới khởi chạy.
• Trong hệ sinh thái AWS, uỷ quyền cho hạ tầng và tài nguyên (mount file system, gọi API) là việc của IAM; Cognito dành cho danh tính người dùng cuối của ứng dụng. Thấy Cognito xuất hiện trong câu hỏi về quyền truy cập tầng lưu trữ hoặc hệ điều hành thì gần như chắc chắn là phương án nhiễu.
• Với câu "Select two", hãy tìm từ khoá làm hỏng trong từng phương án (ở đây là Windows, Cognito) thay vì cố xếp hạng phương án nào "đúng hơn" — các phương án sai thường sai vì một chi tiết duy nhất bị đổi.

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

Một công ty đang có sẵn hệ relational database cũ (legacy) chạy hàng loạt báo cáo cho kế toán và vận hành. Giờ họ muốn dùng thêm Amazon DynamoDB cho các ứng dụng hướng khách hàng cần độ trễ mức mili-giây. Câu hỏi: cách tối ưu nhất để tích hợp hệ relational sẵn có với DynamoDB.

Cụm từ quyết định là "integrate the existing relational system with DynamoDB" — và quan trọng hơn, đề không nói bỏ hệ cũ đi. Hai hệ sẽ song song tồn tại, nghĩa là dữ liệu phải chảy hai chiều: relational → DynamoDB (khi quy trình nội bộ đổi giá, đổi tồn kho) và DynamoDB → relational (khi khách hàng thay đổi dữ liệu trên ứng dụng). Một cụm quan trọng thứ hai là "reports needed for accounting and operations" — báo cáo vẫn nằm ở hệ relational, nên hệ đó phải luôn nhận được thay đổi phát sinh từ phía DynamoDB.

Bám vào hai ràng buộc đó thì bài toán không phải là "làm DynamoDB nhanh hơn" (đó là chuyện cache), mà là bắt sự kiện thay đổi và lan truyền nó sang hệ còn lại.

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

Đáp án đúng theo tệp là B — DynamoDB Streams + AWS Lambda.

DynamoDB Streams ghi lại theo thứ tự mọi thay đổi ở mức item trong bảng (thêm, sửa, xoá). AWS Lambda đọc stream đó và chạy mã tuỳ ý — trong đó có việc ghi ngược vào hệ relational. Đây chính là mô hình hybrid mà tài liệu AWS mô tả, gồm ba kiểu tương tác:

1. Nạp dần cache DynamoDB — truy vấn tìm item trong DynamoDB trước; không thấy thì đọc từ hệ SQL và nạp vào DynamoDB.
2. Write-through qua DynamoDB — khách hàng đổi một giá trị trong DynamoDB, Lambda được kích hoạt và ghi dữ liệu mới ngược về hệ SQL.
3. Cập nhật DynamoDB từ hệ SQL — các quy trình nội bộ (quản lý tồn kho, đổi giá) thay đổi giá trị trong SQL, một stored procedure được kích hoạt để đẩy thay đổi sang materialized view trên DynamoDB.

Điểm mấu chốt: cặp Streams + Lambda là thứ duy nhất trong danh sách cung cấp được cơ chế phản ứng theo sự kiện xuất phát từ phía DynamoDB, nên nó khép được vòng hai chiều mà đề đòi hỏi.

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

A — Amazon ElastiCache làm in-memory caching để tích hợp. ElastiCache là tầng cache trong bộ nhớ, giúp cải thiện đáng kể độ trễ và thông lượng cho workload đọc nhiều hoặc tính toán nặng, bằng cách giữ dữ liệu quan trọng trong RAM. Nhưng nó chỉ là nơi chứa dữ liệu tạm, hoàn toàn không có cơ chế đồng bộ dữ liệu giữa relational database và DynamoDB. Đây là câu trả lời cho bài toán hiệu năng, không phải bài toán tích hợp.

C — Kinesis Data Streams mang cập nhật thời gian thực từ hệ relational sang DynamoDB. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất. KDS thực sự là dịch vụ streaming thời gian thực, quy mô rất lớn, thu nhận liên tục dữ liệu từ vô số nguồn kể cả database event streams, và dữ liệu sẵn sàng trong mili-giây. Chỗ nó hỏng nằm ngay trong cách phương án tự phát biểu: "from the relational system to DynamoDB" — tức là chỉ một chiều. Thay đổi do khách hàng tạo ra trên DynamoDB sẽ không bao giờ quay lại hệ relational, mà hệ relational lại chính là nơi chạy báo cáo kế toán và vận hành. Giải pháp một chiều để lại báo cáo thiếu dữ liệu.

D — DynamoDB Accelerator (DAX). DAX là cache tương thích DynamoDB, cho hiệu năng in-memory rất cao: DynamoDB thường trả lời ở mức mili-giây một chữ số, còn với những use case cần tới mức micro-giây thì DAX phục vụ dữ liệu eventually consistent nhanh hơn nữa. Nhưng DAX chỉ nằm trước DynamoDB, nó không biết gì về relational database và không thể tích hợp hai hệ với nhau. Cụm "millisecond latencies" trong đề là mồi nhử kéo người làm bài về hướng cache — trong khi câu hỏi thực sự là về tích hợp.

📌 Điểm cần nhớ

• Đọc kỹ hướng của luồng dữ liệu: phương án ghi rõ "from X to Y" là tự nhận mình một chiều. Nếu đề hàm ý hai hệ cùng tồn tại và cùng sinh ra thay đổi, một chiều là không đủ.
• DynamoDB Streams + Lambda là mẫu hình chuẩn cho mọi bài "phản ứng khi dữ liệu DynamoDB thay đổi": đồng bộ sang hệ khác, ghi write-through, kích hoạt xử lý hạ nguồn.
• DAX và ElastiCache đều là cache, không phải công cụ tích hợp. DAX chỉ đứng trước DynamoDB; ElastiCache là cache dùng chung. Cả hai giải bài toán độ trễ, không giải bài toán đồng bộ dữ liệu.
• Cụm từ chỉ độ trễ trong đề (mili-giây, micro-giây) thường là mô tả bối cảnh, không phải yêu cầu cần giải — hãy tìm động từ chính của câu hỏi (ở đây là integrate) rồi mới đối chiếu các phương án.

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

Đề mô tả một công ty muốn tự động hoá cấu hình mạng sao cho có thể nhân bản y nguyên hạ tầng mạng để dựng các môi trường development và staging theo yêu cầu (on-demand).

Cụm từ quyết định đáp án là "seamless network infrastructure duplication for on-demand environments" — tức là: mô tả hạ tầng một lần, rồi dựng lại nhiều lần, ở nhiều nơi, ra kết quả giống hệt nhau. Đây chính là định nghĩa của Infrastructure as Code: hạ tầng được khai báo trong một file mẫu, và file đó là nguồn sự thật duy nhất để tạo/cập nhật/xoá.

Chú ý thêm hai chi tiết: đối tượng cần nhân bản là network infrastructure (VPC, subnet, route table, security group…) chứ không phải ứng dụng; và người thực hiện là SysOps Administrator tự dựng môi trường, không phải end-user chọn sản phẩm từ một danh mục có sẵn.

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

D — AWS CloudFormation templates.

CloudFormation cho phép mô tả một tập hợp tài nguyên AWS (và cả tài nguyên bên thứ ba) cùng quan hệ phụ thuộc giữa chúng trong một template JSON/YAML, rồi provision toàn bộ chúng như một stack duy nhất — tạo, cập nhật, xoá cả cụm trong một thao tác thay vì quản lý từng tài nguyên riêng lẻ.

Đúng ba yêu cầu của đề:

• Duplication: cùng một template chạy lại luôn cho ra cùng một cấu trúc mạng — đúng nghĩa "seamless duplication".
• On-demand: dựng stack khi cần môi trường dev/staging, xoá stack khi xong; không có bước thủ công nào ở giữa.
• Parameters cho phép biến đổi những phần khác nhau giữa các môi trường (CIDR, tên môi trường, kích cỡ) mà vẫn dùng chung một template. Ngoài ra StackSets còn triển khai được cùng lúc qua nhiều account và nhiều Region trong một thao tác.

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

A — AWS Elastic Beanstalk. Đây là dịch vụ PaaS để deploy và scale ứng dụng web (Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker) trên Apache/Nginx/IIS. Bạn đẩy code lên, Beanstalk lo capacity provisioning, load balancing, auto scaling và health monitoring. Nó trừu tượng hoá đi lớp hạ tầng bên dưới — trọng tâm là ứng dụng, không phải mô hình hoá mạng. Ngược lại, chính CloudFormation mới là thứ có thể tạo ra hai environment Beanstalk (production và staging) cùng các tài nguyên khác trong một template.

B — AWS Service Catalog. Đây là phương án gần đúng nhất và cũng là bẫy chính. Service Catalog dùng để tập trung hoá chính sách: quản trị viên tạo danh mục sản phẩm cho tổ chức, end-user chỉ được chọn và triển khai những sản phẩm đã được duyệt. Nhưng bản thân sản phẩm trong Service Catalog chính là các CloudFormation template được import vào — nó là lớp governance nằm trên CloudFormation, không thay thế CloudFormation. Với đề bài này, nhu cầu nêu ra là tự động hoá và nhân bản hạ tầng, không hề nói tới kiểm soát quyền truy cập hay chuẩn hoá sản phẩm cho nhiều người dùng. Chọn B là thêm một lớp trung gian mà đề không đòi hỏi, và việc tạo tài nguyên vẫn phải đi qua template.

C — AWS Config. Config là dịch vụ đánh giá, audit và ghi lại lịch sử cấu hình tài nguyên AWS. Nó liên tục theo dõi và ghi nhận thay đổi cấu hình, cho phép so sánh cấu hình thực tế với cấu hình mong muốn, và giao file lịch sử cấu hình vào S3. Điểm mấu chốt: Config quan sát và báo cáo, nó không provision tài nguyên nào cả. Dùng Config bạn biết được VPC hiện tại trông ra sao và đã đổi những gì, nhưng không dựng thêm được một bản sao của VPC đó.

📌 Điểm cần nhớ

• Đề nhắc tới nhân bản hạ tầng, dựng môi trường lặp lại, tự động hoá provisioning → nghĩ ngay CloudFormation (Infrastructure as Code).
• Phân biệt bốn vai trò rất dễ lẫn: CloudFormation tạo hạ tầng, Service Catalog kiểm soát ai được tạo cái gì, Config ghi lại và đánh giá cấu hình, Elastic Beanstalk deploy ứng dụng.
• Service Catalog được xây trên nền CloudFormation — khi đề chỉ nói tới tự động hoá mà không nói tới governance/phân phối sản phẩm cho end-user, hãy chọn lớp thấp hơn.
• Từ khoá "audit", "compliance", "configuration history" → Config; từ khoá "upload code and deploy" → Elastic Beanstalk; từ khoá "template", "stack", "multiple accounts/Regions" → CloudFormation (và StackSets).

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

Đề nói về CloudFormation StackSets dùng để triển khai stack sang nhiều target account nằm ở nhiều Region, và hỏi "Which of the following statements are correct for creating and configuring the StackSets (Select two)?".

Đây là kiểu câu "chọn hai phát biểu đúng" về khái niệm nền, nên không có tình huống nghiệp vụ nào để suy luận — thứ quyết định đáp án là hai cụm từ trong chính các phương án:

• "self-managed" so với "service-managed" — hai mô hình phân quyền của StackSets khác nhau ở chỗ ai tạo IAM role. Đây là ranh giới tách B khỏi E, và cũng là chỗ A cài bẫy bằng cách thêm một mô hình thứ ba không tồn tại.
• "trust relationship between the administrator and target accounts" — quan hệ tin cậy giữa administrator account (nơi tạo stack set) và target account (nơi stack thực sự được tạo) là điều kiện bắt buộc trước khi triển khai, ở cả hai mô hình phân quyền.

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

B — "For stack sets created with service-managed permissions, you don't have to create the necessary IAM roles"

Với mô hình service-managed permissions, stack set triển khai vào các account do AWS Organizations quản lý. Ở mô hình này StackSets tự tạo IAM role thay cho bạn, người vận hành không phải dựng role bằng tay. Đây cũng là mô hình cho phép bật automatic deployments: account được thêm vào organization sau này sẽ tự động nhận stack instance mà không cần thao tác thêm.

D — "You must set up a trust relationship between the administrator and target accounts before creating stacks in target accounts"

Administrator account là account nơi bạn tạo stack set — với service-managed permissions thì đó là management account của organization hoặc một delegated administrator account. Target account là account nơi stack được tạo, cập nhật hoặc xoá. Trước khi stack set có thể tạo stack trong một target account, phải thiết lập quan hệ tin cậy giữa administrator account và target account. Không có quan hệ này thì administrator account không có đường để tác động sang target account.

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

A — "Stack sets can be created using either self-managed, service-managed or resource-managed permissions"

Sai ở đúng một chữ, và đó là kiểu bẫy khó chịu nhất: StackSets chỉ có hai mô hình phân quyền — self-managed và service-managed. "Resource-managed permissions" không phải là một mô hình phân quyền của StackSets; nó được ghép vào cho nghe có vẻ hợp lý. Đọc lướt hai chữ đầu thấy đúng là dễ tick nhầm.

C — "When you delete stacks from your stack set but save them to run independently, such stacks need to be maintained at individual resource level and are unavailable in CloudFormation"

Phần đầu mô tả đúng tuỳ chọn Retain Stacks: khi xoá stack khỏi stack set, bạn có thể chọn giữ lại stack để nó tiếp tục chạy độc lập với stack set. Nhưng kết luận thì ngược: stack được giữ lại (retained stacks) vẫn được quản lý trong CloudFormation, chỉ là nằm ngoài phạm vi stack set. Chúng không rơi xuống mức "quản lý từng resource một" và cũng không biến mất khỏi CloudFormation. Đây là phương án gần đúng nhất trong nhóm sai — mô tả thao tác chuẩn rồi bẻ cong hệ quả.

E — "For stack sets created using self-managed permissions, you don't have to create the necessary IAM roles"

Đây chính là B bị đảo mô hình. Với self-managed permissions, bạn phải tự tạo các IAM role mà StackSets cần để triển khai xuyên account và xuyên Region. Chính các role đó thiết lập quan hệ tin cậy giữa account đang quản trị stack set và account nhận stack instance. B và E không thể cùng đúng — chúng phát biểu cùng một điều cho hai mô hình đối lập, nên nhận ra cặp này là loại được ngay một phương án.

📌 Điểm cần nhớ

• StackSets có đúng hai mô hình phân quyền: self-managed và service-managed. Mọi tên mô hình thứ ba trong đề trắc nghiệm đều là bịa.
• Phân biệt bằng câu hỏi "ai tạo IAM role": self-managed → bạn tự tạo; service-managed → StackSets tự tạo (đi kèm AWS Organizations và khả năng automatic deployment cho account mới).
• Trust relationship giữa administrator account và target account là điều kiện tiên quyết để tạo stack trong target account — nhớ luôn cặp thuật ngữ administrator account / target account.
• Tuỳ chọn Retain Stacks tách stack khỏi stack set nhưng vẫn để nó trong CloudFormation; "xoá khỏi stack set" không đồng nghĩa với "hết được CloudFormation quản lý".
• Khi hai phương án nói cùng một điều cho hai chế độ đối lập (như B và E), gần như chắc chắn một cái là đáp án và cái kia là bẫy — xác định đúng chế độ là xong cả hai.

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

Kiến trúc trong đề: người dùng → CloudFront → ALB → fleet EC2. ALB đã bật sticky sessions, nhưng người dùng vẫn bị bắt đăng nhập lại liên tục. Câu hỏi yêu cầu chỉ ra nguyên nhân và cách khắc phục.

Cụm từ quyết định nằm ở chỗ "The ALB is configured as the origin for Amazon CloudFront distribution" đặt cạnh "ALB has sticky sessions enabled". Sticky sessions của ALB hoạt động bằng cookie (AWSALB/AWSALBAPP, hoặc cookie ứng dụng nếu dùng application-based stickiness): ALB đặt cookie trong response, và ở request sau nó đọc cookie đó để gửi người dùng về đúng EC2 instance đang giữ phiên đăng nhập. Cơ chế này chỉ chạy được nếu cookie đi trọn vòng từ trình duyệt tới ALB.

Điểm mấu chốt: giữa trình duyệt và ALB giờ có thêm CloudFront, và mặc định CloudFront không chuyển tiếp cookie tới origin. Cookie bị cắt ở edge → ALB không thấy cookie stickiness → mỗi request rơi vào một instance khác → phiên đăng nhập lưu trên instance cũ không còn → re-authentication. Vậy chỗ hỏng không nằm ở ALB mà nằm ở cache behavior của CloudFront.

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

C — CloudFront cache behavior needs to be configured to forward all cookies to origin.

Theo mặc định, CloudFront không xét đến cookie khi xử lý request/response và khi cache object ở edge location. Hai request chỉ khác nhau ở header Cookie sẽ bị CloudFront coi là giống hệt nhau và trả về cùng một object.

Sửa bằng cách cập nhật cache behavior của distribution để chuyển tiếp cookie về origin. Mỗi cache behavior có ba lựa chọn:

1. Forward all cookies — CloudFront gửi kèm mọi cookie của viewer khi chuyển request tới origin, và cache response theo tên + giá trị cookie trong request.
2. Forward a whitelist — chỉ giữ những cookie có trong danh sách, phần còn lại bị gỡ trước khi chuyển đi; cache theo các cookie trong whitelist.
3. Don't forward cookies — CloudFront gỡ cookie trước khi chuyển request đi và gỡ luôn header Set-Cookie khỏi response trả về viewer. Đây chính là hành vi mặc định gây ra lỗi trong đề.

Chọn phương án 1, cookie stickiness của ALB đi tới nơi, ALB định tuyến đúng instance, phiên đăng nhập được giữ.

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

A — Dùng CloudFront Origin Shield để chuyển tiếp thông tin xác thực tới ALB. Origin Shield là một lớp cache bổ sung trong hạ tầng CloudFront, đặt trước origin. Lợi ích của nó là tăng cache hit ratio, giảm tải cho origin và cải thiện hiệu năng mạng — hoàn toàn thuộc nhóm tối ưu tải/hiệu năng. Nó không phải cơ chế chuyển tiếp cookie hay thông tin xác thực, nên không giải quyết được vấn đề đăng nhập lại. Mô tả trong phương án gán cho Origin Shield một chức năng nó không có.

B — Bật sticky sessions trên CloudFront distribution. Đây là phương án gài bẫy thuần tuý: CloudFront không có tính năng tên là sticky sessions. Sticky sessions là khái niệm của load balancer (ALB/CLB), nơi có nhiều target để chọn. CloudFront không phải load balancer chọn giữa các EC2 instance; nó chỉ chuyển request tới origin đã khai. Nghe hợp lý vì đề vừa nhắc "sticky sessions", nhưng không tồn tại nút nào như vậy để bật.

D — Cấu hình CloudFront cache request tại edge location để giảm nhu cầu re-authentication. Đây là phương án gần đúng về mặt nghe xuôi tai nhất và cũng sai nguy hiểm nhất. Thứ nhất, cache tại edge là bản chất sẵn có của CloudFront — không có gì để "cấu hình thêm", mục đích của nó là giảm số request phải về origin và giảm độ trễ. Thứ hai, và quan trọng hơn: cache không hề đụng đến cơ chế xác thực. Nội dung sau đăng nhập là nội dung riêng theo từng người dùng; đẩy mạnh cache mà không phân biệt cookie thì hoặc vẫn mất phiên, hoặc tệ hơn — một người dùng nhận nhầm object đã cache của người khác. Cache nhiều hơn xử lý sai triệu chứng (số request về origin), không xử lý nguyên nhân (cookie bị cắt).

📌 Điểm cần nhớ

• Mặc định CloudFront không forward cookie, header hay query string tới origin — và cũng không dùng chúng làm cache key. Bất kỳ cơ chế nào ở phía sau (sticky sessions của ALB, session ứng dụng, giỏ hàng) mà dựa vào cookie đều gãy khi đặt CloudFront lên trước.
• Sửa hành vi chuyển tiếp cookie là việc của cache behavior trong distribution, với ba mức: all / whitelist / none. Whitelist an toàn hơn cho cache hit ratio vì cache key hẹp hơn; "all cookies" là cách chắc ăn nhất khi cần mọi cookie đi qua.
• Sticky sessions là khái niệm của load balancer, không phải của CloudFront. Thấy phương án bảo "bật sticky sessions trên CloudFront" thì loại ngay.
• Phân biệt hai nhóm tính năng khi đọc phương án: Origin Shield và caching ở edge thuộc nhóm hiệu năng/giảm tải, không phải nhóm định danh, phiên hay xác thực. Triệu chứng "người dùng bị đăng nhập lại" gần như luôn dẫn về đường đi của cookie/session, không dẫn về tối ưu cache.

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

Đề cho một CloudFormation template và hỏi "What does this template represent? (Select three)" — tức là chọn ba mô tả đúng về những gì template này khai báo. Đây không phải câu hỏi thiết kế kiến trúc, mà là câu đọc hiểu template: mọi đáp án phải suy ra trực tiếp từ chữ có trong đoạn YAML.

Ba cụm từ trong template quyết định toàn bộ câu trả lời:

• WebsiteConfiguration với IndexDocument/ErrorDocument cộng với AccessControl: PublicRead → bucket được dựng để hosting website tĩnh.
• DeletionPolicy: Retain gắn trên resource S3Bucket → đây là ràng buộc phân biệt mạnh nhất, vì hai phương án D và F nói ngược nhau hoàn toàn về đúng một thuộc tính này.
• Section Outputs với WebsiteURL lấy bằng !GetAtt S3Bucket.WebsiteURL → giá trị này được trả ra ngoài khi stack chạy xong.

Nhận ra DeletionPolicy: Retain là xong hơn nửa câu: nó ép chọn F và loại D ngay lập tức.

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

A — This template creates a bucket as a website. Resource AWS::S3::Bucket khai WebsiteConfiguration với IndexDocument: index.html và ErrorDocument: error.html, tức bật chế độ static website hosting. AccessControl: PublicRead là canned ACL cấp quyền đọc công khai — điều kiện cần để website tĩnh trên S3 phục vụ được khách vô danh. Kèm theo đó là AWS::S3::BucketPolicy cho Principal: '*' thực hiện s3:GetObject trên arn:aws:s3:::<bucket>/*, đúng khuôn mẫu bucket policy của một website tĩnh.

F — AWS CloudFormation will not delete this bucket when it deletes the stack. Thuộc tính DeletionPolicy: Retain đặt ngay trên resource S3Bucket. Với Retain, khi stack bị xoá CloudFormation giữ lại resource đó thay vì xoá; bucket tiếp tục tồn tại trong tài khoản và từ đó do bạn tự quản lý.

E — When run from AWS CLI, URL of the website hosted on S3 will be displayed as output. Section Outputs khai WebsiteURL với Value: !GetAtt S3Bucket.WebsiteURL. Giá trị trong Outputs được CloudFormation trả về cùng thông tin stack, nên khi tạo stack và xem stack qua AWS CLI, URL website sẽ hiện ra trong phần outputs. Output thứ hai, S3BucketSecureURL, ghép https:// với !GetAtt S3Bucket.DomainName theo đúng cách đó.

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

B — bucket lưu object từ "PublicRead API của Amazon RDS". Sai từ gốc. PublicRead không phải API, nó là canned ACL của S3 — một tập quyền đặt sẵn. Trong template cũng không có resource nào thuộc RDS, và RDS là dịch vụ CSDL quan hệ, không ghi object vào S3 theo cơ chế được mô tả ở đây. Phương án này chỉ mượn đúng chữ PublicRead trong template rồi gán cho nó một ý nghĩa không tồn tại.

C — section output chuyển website URL và bucket URL sang stack khác, thuộc cấu hình nested stack. Đây là phương án gần đúng nhất và cũng là bẫy chính. Outputs đúng là cơ chế để đưa giá trị ra ngoài, nhưng bản thân việc khai Outputs không biến template thành một phần của nested stack. Trong template không có resource AWS::CloudFormation::Stack nào — mà đó mới là dấu hiệu của nested stack. Hai output ở đây cũng không khai Export, nên chúng chỉ là giá trị hiển thị của chính stack này chứ không được chuyển giao cho stack nào khác. Đề bài hỏi template đại diện cho cái gì, và những gì không có trong template thì không suy ra được.

D — CloudFormation sẽ xoá bucket khi xoá stack. Đây là hành vi mặc định của CloudFormation khi resource không khai DeletionPolicy, nên nó nghe rất hợp lý nếu người làm bài đọc lướt qua đoạn YAML. Nhưng template này khai rõ DeletionPolicy: Retain, và thuộc tính đó ghi đè hành vi mặc định. D mâu thuẫn trực tiếp với F — hai cái không thể cùng đúng, và chữ Retain trong template chỉ ra bên nào thắng.

📌 Điểm cần nhớ

• DeletionPolicy: Retain giữ resource lại sau khi stack bị xoá; không khai DeletionPolicy thì mặc định là xoá theo stack. Hễ thấy hai phương án nói ngược nhau về chuyện xoá resource, việc đầu tiên là tìm DeletionPolicy trong template.
• PublicRead là canned ACL của S3, không phải API và không dính gì tới RDS. Phương án hay lấy một chữ có thật trong đề rồi gắn sai dịch vụ — kiểm tra xem dịch vụ đó có xuất hiện trong template không.
• Bucket làm static website cần đủ hai phần: WebsiteConfiguration (index/error document) để bật chế độ website, và quyền đọc công khai — ở đây là AccessControl: PublicRead cộng bucket policy s3:GetObject cho Principal: '*'.
• Có Outputs không đồng nghĩa với nested stack hay cross-stack reference. Nested stack cần resource AWS::CloudFormation::Stack; chia sẻ giá trị sang stack khác cần khai Export trong output rồi bên kia dùng Fn::ImportValue. Thiếu những thứ đó thì Outputs chỉ là giá trị đọc được của chính stack, ví dụ khi xem stack qua AWS CLI.

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

Đề mô tả một web application được host trên Amazon S3 bucket ở chế độ static website hosting, và bản ghi DNS trong Route 53 đã được trỏ tới static website đó. Vấn đề: domain không phân giải được (not resolving), gây lỗi. Câu hỏi yêu cầu chọn nguyên nhân hợp lý nhất.

Cụm từ quyết định nằm ở chỗ ghép hai vế: "hosted on an Amazon S3 bucket" + "the DNS record in Amazon Route 53 has been configured to point to the static website". Nghĩa là phần cấu hình bản ghi đã làm rồi, cái còn lại phải sai là quan hệ giữa tên bucket và tên bản ghi DNS. Đây là ràng buộc rất riêng của S3 static website hosting: khác với hầu hết các đích khác của Route 53, S3 website endpoint phân biệt tên bucket phải trùng tên domain — đó là điểm mà câu hỏi nhắm vào, chứ không phải chuyện chứng chỉ hay IP.

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

D — "You must give the S3 bucket the same name as the record that you want to use to route traffic to the bucket"

Khi cấu hình một S3 bucket cho website hosting và muốn Route 53 định tuyến traffic của một domain tới bucket đó, tên bucket phải trùng đúng với tên bản ghi DNS. Ví dụ, muốn định tuyến example.com tới một S3 bucket đang bật website hosting thì bucket phải tên là example.com.

Lý do là S3 website endpoint dùng chính Host header của request để xác định phục vụ bucket nào. Nếu tên bucket không khớp tên domain, S3 không tìm ra bucket tương ứng và request không được phục vụ đúng — đây là nguyên nhân điển hình được ghi trong tài liệu khắc phục sự cố của Route 53 cho trường hợp S3 website hosting. Trong đề, phần bản ghi DNS đã được cấu hình, nên điều kiện tiền đề còn lại chưa thỏa mãn chính là quy tắc đặt tên bucket này.

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

A — "Amazon S3 website endpoints need SSL certificate for supporting HTTPS requests. Check the certificate expiry and validation" Sai ngay ở tiền đề: S3 website endpoint không hỗ trợ HTTPS. Vì vậy không có chuyện đi kiểm tra hạn hay trạng thái validation của certificate trên website endpoint — không tồn tại certificate nào ở đó để hỏng cả. Đây là phương án đánh vào phản xạ "lỗi truy cập web thì nghĩ tới TLS", nhưng đặt sai ngữ cảnh.

B — "Confirm that the HOSTNAME record for the domain is pointing to the correct website endpoint" Đây là phương án gần đúng nhất về mặt ý tưởng — kiểm tra bản ghi có trỏ đúng website endpoint là việc hợp lý. Nhưng nó hỏng ở thuật ngữ: Route 53 không có loại bản ghi nào tên là HOSTNAME. Loại bản ghi dùng để trỏ domain tới S3 website endpoint là alias record (hoặc CNAME cho subdomain), không phải "HOSTNAME record". Trong đề trắc nghiệm, một loại bản ghi không tồn tại là đủ để loại phương án, dù phần diễn đạt còn lại nghe xuôi tai.

C — "The domain should resolve to the same IP address every time, check if this works" Sai về nguyên lý hoạt động của S3 và DNS. Địa chỉ IP mà một S3 website endpoint phân giải ra không cố định — nó thay đổi theo thời gian. Điều quan trọng là truy vấn DNS phải được gửi tới đúng tập name server có thẩm quyền trả lời, chứ không phải kết quả IP luôn giống nhau. Lấy "IP phải ổn định" làm tiêu chí chẩn đoán là kỳ vọng sai ngay từ đầu, nên không thể là nguyên nhân của lỗi.

📌 Điểm cần nhớ

• Với S3 static website hosting + Route 53: tên bucket phải trùng khớp tên bản ghi DNS muốn dùng để định tuyến. Đây là ràng buộc bắt buộc, và là nghi phạm số một khi domain không resolve.
• S3 website endpoint không hỗ trợ HTTPS. Mọi phương án đề cập certificate/SSL gắn trực tiếp vào website endpoint đều sai tiền đề.
• Route 53 trỏ tới S3 website endpoint bằng alias record (hoặc CNAME cho subdomain) — hãy cảnh giác với các phương án bịa ra tên loại bản ghi không có thật.
• IP mà endpoint phân giải ra không tĩnh; chẩn đoán DNS phải nhìn vào việc truy vấn có tới đúng name server có thẩm quyền hay không, không nhìn vào tính ổn định của IP.

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

Đề mô tả một bucket S3 dùng chung: nhiều ứng dụng, nhiều nhóm, nhiều cá nhân cùng đọc một tập dữ liệu để phân tích. Vấn đề không nằm ở tốc độ truyền dữ liệu hay ở khối lượng object cần xử lý, mà nằm ở cách quản lý quyền truy cập.

Cụm từ quyết định đáp án là: "a single bucket policy that controls access for dozens to hundreds of applications with different permission levels" và "changes to the bucket policy don't have an unexpected impact on another application".

Đọc kỹ hai cụm này là ra ngay bản chất bài toán: hiện tại mọi quyền dồn vào một bucket policy duy nhất, nên nó phình to và mọi ứng dụng dùng chung một tài liệu chính sách. Sửa một dòng cho ứng dụng này có thể vô tình đổi hành vi của ứng dụng khác — đúng nghĩa "unexpected impact". Thứ cần tìm là cơ chế tách chính sách ra thành nhiều đơn vị độc lập, mỗi ứng dụng một chính sách riêng, để phạm vi ảnh hưởng khi sửa bị giới hạn lại.

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

C — Configure Amazon S3 Access Points on S3 buckets.

S3 Access Points sinh ra đúng cho tình huống shared data set này. Mỗi access point là một hostname riêng gắn với một bucket, và mang theo access policy riêng của nó. Thay vì một bucket policy khổng lồ liệt kê hàng trăm ứng dụng, ta tạo hàng trăm access point — mỗi ứng dụng một cái, tên riêng, quyền riêng, đặt theo đúng nhu cầu của ứng dụng đó.

Điều này giải quyết thẳng yêu cầu trong đề: sửa access point policy của ứng dụng A chỉ ảnh hưởng ứng dụng A, vì ứng dụng B đi qua access point khác với chính sách khác. Ranh giới thay đổi được cô lập theo từng access point thay vì trải chung một tài liệu.

Ngoài ra mỗi access point còn có network origin control và Block Public Access control riêng: có thể giới hạn một access point chỉ nhận yêu cầu từ trong VPC, hoặc giới hạn chính sách chỉ cho phép truy cập object có prefix nhất định (ví dụ finance). Mức độ tuỳ biến theo từng ứng dụng vì thế cao hơn hẳn cách dùng một bucket policy chung.

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

A — Configure S3 Batch Operations. S3 Batch Operations là công cụ quản lý dữ liệu, không phải quản lý quyền: nó chạy một thao tác lên hàng loạt object — copy giữa các bucket, thay tag set, khôi phục object từ S3 Glacier, sửa thuộc tính và metadata. Đúng là danh sách thao tác của nó có cả việc thay đổi access control trên object, nên phương án này nghe gần đúng; nhưng đó là thao tác hàng loạt một lần lên object, không phải một mô hình phân quyền lâu dài cho hàng trăm ứng dụng. Nó không tạo ra ranh giới chính sách nào cả, và bucket policy khổng lồ vẫn nguyên vẹn với đúng vấn đề cũ.

B — Configure S3 Acceleration. S3 Transfer Acceleration là tính năng hiệu năng truyền dữ liệu, giúp upload/download object lớn qua khoảng cách địa lý xa nhanh và ổn định hơn bằng cách đi qua hạ tầng edge. Nó hoàn toàn không đụng gì tới phân quyền. Đề bài không hề than phiền về tốc độ — đây là phương án lạc đề rõ nhất trong bốn phương án.

D — Configure Amazon S3 VPC Endpoints. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì nó có liên quan tới bảo mật truy cập: VPC endpoint cho phép instance trong VPC gọi tới S3 qua đường riêng, không cần internet gateway, NAT hay public IP. Nhưng nó kiểm soát đường đi mạng, tức là "truy cập từ đâu", chứ không chia nhỏ được ai được làm gì với dữ liệu nào. Dựng VPC endpoint xong, ta vẫn còn nguyên một bucket policy duy nhất cho hàng trăm ứng dụng, và sửa nó vẫn có nguy cơ ảnh hưởng chéo. Đáng chú ý: khía cạnh network này đã nằm sẵn trong Access Points dưới dạng network origin control, nên C bao trùm được điểm mạnh của D chứ không ngược lại.

📌 Điểm cần nhớ

• Đề nói tới shared data set trên S3 + nhiều ứng dụng + bucket policy quá lớn/khó sửa thì gần như chắc chắn đáp án là S3 Access Points. Đây là dấu hiệu nhận dạng rất ổn định.
• Access Point = hostname riêng + access policy riêng + network origin control + Block Public Access riêng, tất cả gắn vào một bucket. Giá trị cốt lõi là cô lập phạm vi thay đổi chính sách.
• Phân biệt rạch ròi ba lớp vấn đề khi đọc phương án S3: quyền truy cập (Access Points, bucket policy, IAM), đường đi mạng (VPC endpoint), hiệu năng truyền (Transfer Acceleration). Chọn theo đúng lớp mà đề đang than phiền.
• S3 Batch Operations luôn là câu trả lời cho "thao tác hàng loạt trên rất nhiều object", không bao giờ là mô hình phân quyền — dù trong danh sách thao tác của nó có việc sửa access control.

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

Đề đặt bạn vào vai SysOps Administrator, cần thiết lập kết nối mạng riêng (private) giữa một File Gateway và Amazon S3 để truy cập an toàn, và câu hỏi chốt lại bằng: "How will you configure this requirement cost-effectively?"

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

• "between a File Gateway and Amazon S3" — hai đầu của kết nối là File Gateway (thành phần AWS Storage Gateway, phần chạy trong AWS đặt trong VPC của bạn) và Amazon S3 (dịch vụ AWS, nằm ngoài VPC, thường truy cập qua endpoint công khai). Đây không phải bài toán nối on-premises với AWS. Đọc lướt rất dễ tưởng là nối trung tâm dữ liệu với đám mây, và ba phương án sai đều được viết đúng để dụ vào cách hiểu đó.
• "cost-effectively" — loại bỏ những giải pháp hạ tầng mạng nặng nề, phải dựng thêm và trả phí liên tục.

Ghép hai ràng buộc: cần một cơ chế cho phép traffic từ trong VPC đi tới S3 mà không ra Internet, và rẻ. Đó chính xác là mô tả của VPC endpoint.

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

Đáp án C — Setup the private connection within an Amazon VPC by using VPC endpoints.

VPC endpoint là cơ chế của AWS để tài nguyên bên trong VPC gọi tới dịch vụ AWS (ở đây là S3) mà lưu lượng không rời khỏi mạng AWS, không cần Internet gateway, NAT hay địa chỉ IP công khai. Đúng như tài liệu AWS mô tả, để dựng kết nối riêng này trong VPC bạn làm hai bước:

1. Tạo VPC endpoint cho Amazon S3;
2. Tạo file gateway sử dụng VPC endpoint đó.

Kết nối vì thế nằm gọn trong VPC, đúng phạm vi mà đề yêu cầu, và không phải dựng thêm đường truyền vật lý hay hub mạng nào — nên nó cũng là lựa chọn tiết kiệm nhất trong bốn phương án.

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

A. VPC Peering giữa on-premises và AWS Cloud — sai ngay ở định nghĩa. VPC peering là kết nối giữa hai VPC (cùng tài khoản hoặc khác tài khoản), cho phép các instance định tuyến cho nhau bằng địa chỉ IP riêng như trong cùng một mạng. Nó không dùng để nối on-premises với đám mây, và quan trọng hơn: S3 không phải một VPC, nên không có gì để peer tới. Không thể dùng VPC Peering làm kết nối riêng giữa File Gateway và S3.

B. AWS Transit Gateway — đây là phương án "gần đúng" nhất về mặt cảm giác, vì Transit Gateway đúng là thứ nối nhiều VPC và mạng on-premises qua một hub trung tâm, thay cho mạng lưới peering rối rắm. Nhưng nó hỏng ở hai chỗ: (1) bản thân Transit Gateway không tạo ra đường tới on-premises — bạn vẫn cần thêm VPN hoặc Direct Connect; (2) nó định tuyến giữa các mạng, chứ không phải cơ chế truy cập riêng tới một dịch vụ AWS như S3. Dùng nó ở đây vừa không giải quyết được yêu cầu, vừa đắt hơn hẳn.

D. AWS Direct Connect — Direct Connect lập một đường mạng dành riêng, vật lý từ trung tâm dữ liệu, văn phòng hay colocation của bạn tới AWS. Về kỹ thuật nó thật sự cho traffic đi riêng, nên nhiều người chọn phương án này. Nhưng nó trả lời sai câu hỏi: đề cần kết nối riêng giữa File Gateway và S3, tức là bên trong AWS, chứ không phải giữa cơ sở của bạn và AWS. Cộng thêm ràng buộc "cost-effectively", Direct Connect là giải pháp quá tay: chi phí và công sức dựng lớn hơn nhiều so với việc chỉ tạo một VPC endpoint.

📌 Điểm cần nhớ

• Xác định đúng hai đầu của kết nối trước khi chọn dịch vụ mạng. "Từ VPC tới dịch vụ AWS" → VPC endpoint. "Từ VPC tới VPC" → VPC Peering. "Từ on-premises tới AWS" → Direct Connect hoặc VPN. "Nhiều mạng nối qua một hub" → Transit Gateway.
• File Gateway triển khai trong VPC, nên đường tới S3 là bài toán trong AWS, không phải bài toán lai on-premises — dù cái tên "gateway" gợi ý ngược lại.
• Transit Gateway không tự nó nối được on-premises; vẫn cần VPN hoặc Direct Connect bên dưới. Phương án nào nói Transit Gateway "thay thế" đường tới trung tâm dữ liệu thì đáng ngờ.
• Từ khoá "cost-effective" thường loại Direct Connect khi bài toán có thể giải bằng cấu hình sẵn có trong VPC; Direct Connect chỉ xứng đáng khi đề nhấn mạnh băng thông ổn định, độ trễ nhất quán hoặc khối lượng dữ liệu lớn kéo dài.