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

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

Đề mô tả một ứng dụng chạy trên nhiều Amazon EC2 instance nằm sau một Application Load Balancer (ALB), và triệu chứng là "users must log in several times each hour" — người dùng bị bắt đăng nhập lại nhiều lần trong một giờ.

Cụm từ quyết định chính là "must log in several times each hour" kết hợp với "EC2 instances behind an ALB" (số nhiều instance). Đây là mô tả kinh điển của ứng dụng lưu trạng thái phiên (session state) ngay trên từng instance: khi ALB phân phối các request kế tiếp của cùng một người dùng sang instance khác, instance mới không có session của họ nên bắt đăng nhập lại.

Chú ý đề không nói ứng dụng bị lỗi, bị chậm, hay có instance nào chết. Triệu chứng thuần tuý là mất phiên đăng nhập giữa các request — nên phương án đúng phải là thứ tác động tới cách định tuyến request của cùng một client, chứ không phải thứ tăng tính sẵn sàng hay tăng hiệu năng.

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

D. Enable sticky sessions on the Target Group.

Sticky sessions (session affinity) là cơ chế của Elastic Load Balancing dùng để đưa các request của cùng một client về đúng một target trong target group trong suốt thời gian phiên. Load balancer dựa vào cookie để nhận diện client và ghi nhớ target đã phục vụ họ — vì vậy client bắt buộc phải hỗ trợ cookie thì tính năng mới hoạt động.

Áp vào tình huống của đề: bật sticky sessions khiến mọi request của một người dùng đi về đúng instance EC2 đang giữ session đăng nhập của họ. Session không còn bị "lạc" sang instance khác, nên người dùng không bị đá ra đăng nhập lại nhiều lần mỗi giờ. Đây chính là biện pháp trực tiếp giải quyết triệu chứng mà đề nêu.

Một chi tiết đáng để ý về mặt thao tác: sticky sessions được cấu hình ở target group, không phải ở bản thân load balancer — đúng như cách phương án D diễn đạt.

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

A. Configure health checks on the Application Load Balancer. Health check phục vụ việc phát hiện target không lành mạnh để ngừng gửi traffic tới đó. Nó không liên quan gì tới việc session đăng nhập bị mất giữa các instance. Phương án này còn sai ở chỗ mô tả: health check được cấu hình trên target group, không phải cấu hình thẳng trên load balancer. Kể cả có bật đúng chỗ thì người dùng vẫn tiếp tục bị chuyển qua lại giữa các instance và vẫn phải đăng nhập lại.

B. Enable HTTP/2 on the Application Load Balancer. HTTP/2 là chuyện giao thức truyền tải: ghép nhiều luồng trên một kết nối, nén header, giảm độ trễ. Nó cải thiện hiệu năng tải trang chứ không hề can thiệp vào việc request được định tuyến tới target nào. Bài toán ở đây là xác thực và phiên đăng nhập, hoàn toàn nằm ở tầng ứng dụng — đổi phiên bản giao thức không sửa được.

C. Add targets in multiple Availability Zones. Đây là phương án "gần đúng" nhất về mặt cảm giác, vì nó nghe như đang cải thiện độ tin cậy và ai cũng biết trải target qua nhiều AZ là thực hành tốt. Nhưng nó hỏng ở chỗ chẩn đoán sai nguyên nhân: đề không có dấu hiệu nào cho thấy một AZ bị gián đoạn. Nguyên nhân thật là request của cùng một người dùng bị rải sang nhiều instance khác nhau. Tệ hơn nữa, thêm target ở nhiều AZ chỉ làm tăng số instance mà request có thể rơi vào, tức là làm triệu chứng nặng thêm chứ không đỡ đi.

📌 Điểm cần nhớ

• Triệu chứng "người dùng bị bắt đăng nhập lại liên tục" phía sau một load balancer với nhiều target ⇒ nghĩ ngay tới session affinity / sticky sessions, vì đó là dấu hiệu session được lưu cục bộ trên từng instance.
• Sticky sessions và health checks đều cấu hình ở target group, không phải trực tiếp trên load balancer — đề thi hay đánh tráo chỗ này để tạo phương án nhiễu.
• Sticky sessions của ELB dựa trên cookie, nên client phải hỗ trợ cookie thì cơ chế mới có tác dụng.
• Đọc kỹ triệu chứng để tách bạch ba nhóm vấn đề khác nhau: tính sẵn sàng (multi-AZ, health check), hiệu năng truyền tải (HTTP/2), và tính liên tục của phiên (sticky sessions). Một phương án là "thực hành tốt" nói chung không có nghĩa nó trả lời đúng câu hỏi đang được hỏi.

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

Đề kể một tình huống rất ngắn: công ty vừa làm security audit cho các ứng dụng chạy trên AWS, và một ứng dụng dùng Amazon SQS queue bị đánh dấu vì IAM policy gắn vào queue cho phép nhiều quyền hơn mức cần thiết. Câu hỏi không hỏi "sửa thế nào", mà hỏi ai chịu trách nhiệm sửa (Who is responsible for correcting the issue?).

Cụm từ quyết định đáp án là "the IAM policy attached the queue" — tức là một policy do chính khách hàng viết và gắn lên tài nguyên của mình. Đây là dấu hiệu kinh điển của shared responsibility model: mọi thứ nằm trong dịch vụ và do khách hàng cấu hình thì thuộc phần "security in the cloud" — trách nhiệm của khách hàng. Nhận ra được ranh giới này là đủ để loại ba phương án còn lại, vì cả ba đều là một bộ phận nào đó của AWS.

Điểm phụ nhưng cũng đáng chú ý: đề nói "allowed more access than required" — vấn đề ở đây là quyền quá rộng, tức là vi phạm nguyên tắc least privilege, chứ không phải một lỗi kỹ thuật của dịch vụ SQS. Lỗi cấu hình thì người cấu hình phải sửa.

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

Đáp án đúng theo tệp là A — The SysOps Administrator.

Theo shared responsibility model, AWS chịu trách nhiệm "security of the cloud" (hạ tầng vật lý, phần cứng, phần mềm nền tảng chạy các dịch vụ như SQS và IAM), còn khách hàng chịu trách nhiệm "security in the cloud" — trong đó có việc cấu hình quyền truy cập cho tài nguyên của mình. IAM policy gắn lên SQS queue nằm gọn trong phần của khách hàng: chính khách hàng viết nó, chính khách hàng quyết định cho ai được SendMessage, ReceiveMessage, DeleteMessage…

SysOps Administrator ở đây đại diện cho phía khách hàng — người vận hành hệ thống trên AWS. Người này có quyền và có nghĩa vụ sửa lại policy cho khớp least privilege: thu hẹp principal, thu hẹp danh sách action, và giới hạn resource về đúng queue cần thiết. Không có bộ phận nào của AWS làm việc đó thay được, vì AWS không nhìn vào nội dung policy của khách hàng để phán xét nó rộng hay hẹp.

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

B — The Amazon SQS team: đội ngũ vận hành SQS của AWS chịu trách nhiệm giữ cho dịch vụ SQS chạy đúng, bền, sẵn sàng và an toàn ở tầng nền tảng. Họ đảm bảo rằng khi bạn viết một policy, SQS thực thi đúng policy đó. Nhưng nội dung policy là quyết định nghiệp vụ của khách hàng — SQS team không sửa và cũng không nên sửa cấu hình trong tài khoản khách hàng.

C — The AWS IAM team: đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì vấn đề mang chữ "IAM policy". Nhưng cần tách hai thứ: IAM service do AWS vận hành, còn các policy được tạo trong tài khoản của bạn là dữ liệu cấu hình của bạn. AWS IAM team lo cho việc hệ thống IAM đánh giá policy chính xác và luôn khả dụng; họ không biết ứng dụng của bạn thực sự cần những action nào, nên không thể xác định thế nào là "more access than required" trong ngữ cảnh của bạn.

D — AWS Premium Support: Premium Support là dịch vụ hỗ trợ có trả phí — họ tư vấn, gỡ sự cố, giải thích best practice, và có thể chỉ ra rằng policy đang quá rộng. Nhưng vai trò của họ là cố vấn, không phải chủ sở hữu trách nhiệm bảo mật cấu hình. Trách nhiệm sửa vẫn nằm ở khách hàng; Support không tự động vào tài khoản để siết quyền giúp bạn.

📌 Điểm cần nhớ

• Bất cứ khi nào câu hỏi hỏi "ai chịu trách nhiệm" cho một thứ do khách hàng cấu hình (IAM policy, security group, mã hoá dữ liệu, patch hệ điều hành trên EC2), câu trả lời gần như luôn là phía khách hàng — trong đề thi thường xuất hiện dưới tên SysOps Administrator, Solutions Architect hoặc "the company".
• Ranh giới cần thuộc: AWS lo security of the cloud (hạ tầng, phần cứng, phần mềm nền tảng của dịch vụ); khách hàng lo security in the cloud (dữ liệu, quyền truy cập, cấu hình).
• Đề nhắc tên một đội của AWS (SQS team, IAM team) hay Premium Support thường là mồi nhử — chúng nghe hợp lý vì đúng tên dịch vụ đang gặp vấn đề, nhưng AWS không chỉnh sửa cấu hình bên trong tài khoản khách hàng.
• "More access than required" là cách diễn đạt vi phạm least privilege: cách sửa luôn là thu hẹp principal, action và resource trong policy, chứ không phải mở ticket cho AWS.

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

Đề mô tả một ứng dụng production quan trọng chạy trên Amazon RDS MySQL, và SysOps Administrator cần giảm thời gian gián đoạn (downtime) khi database gặp sự cố. Câu hỏi chốt lại: "Which action will make the database MORE highly available?"

Có hai cụm từ quyết định, và phải thoả cả hai thì phương án mới đúng:

1. "in the event of a database failure" + "MORE highly available" — mục tiêu là high availability / failover tự động, không phải tăng hiệu năng đọc, không phải chịu lỗi mạng.
2. "must not impact the customer experience during business hours" — thao tác thay đổi phải làm ngoài giờ làm việc. Đây là ràng buộc lọc bớt phương án: cùng một hành động nhưng không nói "outside of business hours" thì trượt tiêu chí này.

Cụm thứ hai chính là mấu chốt phân biệt các phương án gần giống nhau, vì việc bật Multi-AZ lần đầu sẽ khởi tạo quá trình sao chép dữ liệu sang standby và có thể làm database chính giảm hiệu năng trong lúc đồng bộ.

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

A. Modify the DB instance outside of business hours to be a Multi-AZ deployment.

Khi bật Multi-AZ deployment, Amazon RDS tạo một DB instance chính (primary) và sao chép dữ liệu đồng bộ (synchronous replication) sang một instance dự phòng (standby) đặt ở Availability Zone khác. Khi primary hỏng — hỏng instance, hỏng storage, hoặc cả AZ gặp sự cố — RDS tự động failover sang standby, và endpoint DNS được trỏ lại sang instance mới. Ứng dụng không phải đổi chuỗi kết nối. Đây đúng là định nghĩa "more highly available" mà đề hỏi.

Multi-AZ bật được trên RDS database đang chạy sẵn, không cần dựng lại hay migrate dữ liệu — nên đây là hành động nhẹ nhất thoả yêu cầu.

Phần "outside of business hours" khớp ràng buộc thứ hai: lần đầu cấu hình Multi-AZ, quá trình đồng bộ dữ liệu ban đầu sang standby có thể gây suy giảm hiệu năng trên database chính. Làm ngoài giờ làm việc thì khách hàng không cảm nhận được.

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

B. Modify the instance type to one with redundant Elastic Network Interfaces (ENIs). ENI dự phòng — nếu có — chỉ xử lý được đúng một lớp hỏng hóc rất hẹp: kết nối mạng của instance. Nó không bảo vệ trước database failure theo nghĩa rộng: hỏng phần cứng host, hỏng storage volume, hoặc mất cả Availability Zone. Ứng dụng vẫn nằm trên một instance duy nhất, ở một AZ duy nhất. Mức HA đạt được kém xa Multi-AZ.

C. Create an Amazon RDS DB cluster. Migrate all data to the new cluster. Đây là phương án gần đúng nhất về mặt ý tưởng nhưng hỏng ở hai chỗ. Thứ nhất, mô hình "cluster" không phải cách RDS MySQL tiêu chuẩn cung cấp tính sẵn sàng cao — với RDS, thứ cần bật là Multi-AZ deployment, và nó bật được ngay trên database đang có. Thứ hai, phương án này đòi migrate toàn bộ dữ liệu sang một database mới: đó là việc nặng, rủi ro, kéo theo downtime cắt chuyển và phải đổi endpoint kết nối — đi ngược lại yêu cầu "không ảnh hưởng trải nghiệm khách hàng". Chọn cách phức tạp trong khi có nút bấm sẵn trên chính instance hiện tại là sai hướng.

D. Create a read replica from the existing database outside of business hours. Phương án này thoả ràng buộc thời gian ("outside of business hours") nên rất dễ đánh lừa — nhưng nó trượt mục tiêu chính. Read replica sinh ra để mở rộng khả năng đọc (scale read queries), giảm tải truy vấn cho primary. Nó dùng sao chép bất đồng bộ, nên có độ trễ và có thể mất dữ liệu chưa kịp sao chép. Quan trọng nhất: read replica không tự động failover khi primary hỏng — phải có người can thiệp promote nó lên thành database độc lập, rồi ứng dụng phải đổi endpoint. Như vậy vẫn còn downtime đáng kể, không phải "highly available".

📌 Điểm cần nhớ

• Multi-AZ = high availability / disaster recovery; Read replica = scale khả năng đọc. Đây là cặp phân biệt được hỏi đi hỏi lại. Thấy từ khoá availability, failover, minimize downtime → Multi-AZ. Thấy read performance, offload queries, reporting → read replica.
• Multi-AZ sao chép đồng bộ + failover tự động sang AZ khác, giữ nguyên endpoint; read replica sao chép bất đồng bộ và phải promote thủ công.
• Multi-AZ bật được trên RDS instance đang chạy, không cần tạo mới rồi migrate dữ liệu. Phương án nào bắt "migrate all data" để đạt HA cơ bản thì thường là bẫy.
• Khi đề thêm ràng buộc "không ảnh hưởng khách hàng trong giờ làm việc", hãy tìm phương án nói rõ outside of business hours — thao tác bật Multi-AZ lần đầu có thể làm giảm hiệu năng primary trong lúc đồng bộ ban đầu. Nhưng ràng buộc thời gian chỉ là điều kiện phụ: phương án phải đúng mục tiêu HA trước đã (đó là chỗ D thua).

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

Đề mô tả một tình huống rất quen thuộc: tên miền ourbusiness.com đang được quản lý bằng Amazon Route 53, ứng dụng đã có sẵn một CloudFront distribution, và yêu cầu là người dùng gõ www.ourbusiness.com thì phải đi qua CloudFront.

Có hai cụm từ quyết định đáp án, cần đọc kỹ cả hai:

• "through CloudFront" — lưu lượng bắt buộc phải chạm CloudFront, không được đi thẳng tới máy chủ gốc. Cụm này loại ngay mọi phương án trỏ tới địa chỉ của portal.
• "MOST economical" — giữa những cách chạy được, phải chọn cách rẻ nhất. Route 53 tính phí theo số truy vấn DNS phục vụ được, nhưng truy vấn giải tới một ALIAS record trỏ vào tài nguyên AWS thì không bị tính phí. Đây chính là chỗ chữ "economical" ăn khớp với ALIAS chứ không phải với loại bản ghi nào khác.

Ngoài ra, có một ràng buộc kỹ thuật ngầm mà đề không nói ra nhưng người ra đề trông đợi bạn biết: bản ghi trỏ tới CloudFront phải trỏ tới tên miền của distribution (dạng dxxxx.cloudfront.net), chứ CloudFront không cho bạn một IP tĩnh để mà trỏ A record vào.

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

Đáp án đúng theo tệp là D — Create an ALIAS record in Amazon Route 53 that directs traffic to the CloudFront distribution URL.

ALIAS record là một loại bản ghi riêng của Route 53, không có trong DNS chuẩn. Nó cho phép ánh xạ một tên miền tới một tài nguyên AWS được chọn — trong đó có CloudFront distribution.

Ba lý do khiến nó khớp trọn vẹn với đề:

1. Trỏ được vào CloudFront distribution URL — đúng yêu cầu "đi qua CloudFront". Lưu lượng tới www.ourbusiness.com sẽ được giải về các edge location của CloudFront, không đi thẳng tới origin.
2. Không mất phí cho truy vấn — ALIAS record trỏ tới tài nguyên AWS được phục vụ miễn phí, nên đúng tiêu chí "MOST economical".
3. Tự bám theo thay đổi của tài nguyên đích — Route 53 tự nhận biết khi tập bản ghi mà alias trỏ tới thay đổi, nên bạn không phải cập nhật tay khi hạ tầng phía sau đổi địa chỉ, và thời gian phản hồi truy vấn cũng nhanh hơn.

Có thể hình dung ALIAS như một CNAME "có nội lực hơn": làm được việc mà CNAME làm, nhưng còn trỏ được vào một số tài nguyên AWS mà CNAME không trỏ tới được.

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

A — MX record trỏ tới CloudFront distribution URL. MX (Mail Exchange) là bản ghi khai máy chủ nào chịu trách nhiệm nhận email cho tên miền. Nó chỉ có ý nghĩa với luồng thư điện tử; trình duyệt không bao giờ tra MX khi mở một trang web. Dựng MX trỏ vào CloudFront thì không có gì hỏng ầm ĩ, nhưng www.ourbusiness.com vẫn không giải ra được — sai hoàn toàn về mục đích sử dụng.

B — PTR record trỏ tới CloudFront distribution URL. PTR (Pointer) dùng cho tra cứu DNS ngược: từ một địa chỉ IP tìm ra hostname. Chiều của nó ngược hẳn với việc đang cần làm (từ tên miền tìm ra đích đến). Ngoài ra PTR thường do bên sở hữu dải IP quản lý, không phải thứ bạn dựng trong hosted zone của tên miền để định tuyến người dùng. Đây cũng là phương án sai về bản chất chứ không phải sai vì đắt.

C — A record trỏ tới địa chỉ IP công khai của online portal. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. A record đúng là bản ghi chuẩn để ánh xạ tên miền sang địa chỉ IPv4, và nếu chỉ cần "mở được website" thì nó chạy. Nhưng nó hỏng ở đúng chỗ đề yêu cầu: bản ghi này trỏ thẳng tới portal, tức là bỏ qua hoàn toàn CloudFront — mất cache tại edge, mất mọi lợi ích của CDN, và trái với câu "wants users accessing www.ourbusiness.com to do so through CloudFront". Thêm nữa, nó gắn chặt tên miền vào một IP cụ thể của origin: IP đổi là phải sửa bản ghi bằng tay.

📌 Điểm cần nhớ

• Trỏ tên miền vào CloudFront distribution trong Route 53 thì câu trả lời mặc định là ALIAS record. Cùng khuôn đó áp dụng cho các tài nguyên AWS khác mà Route 53 hỗ trợ alias — bạn trỏ tới tên, không trỏ tới IP.
• Khi đề nhấn "MOST economical" trong ngữ cảnh Route 53 + tài nguyên AWS, hãy nghĩ tới việc truy vấn giải qua ALIAS record không bị tính phí, trong khi các bản ghi thường thì có.
• Loại bản ghi DNS có mục đích riêng, không dùng thay nhau được: A ánh xạ tên → IPv4, MX khai máy chủ nhận email, PTR phục vụ tra cứu ngược. Thấy MX hoặc PTR xuất hiện trong một câu hỏi về định tuyến traffic web thì gần như chắc chắn là phương án gây nhiễu.
• Đọc kỹ ràng buộc về đường đi của lưu lượng. Một phương án "chạy được" (A record tới origin) vẫn sai nếu nó bỏ qua thành phần mà đề yêu cầu traffic phải đi qua.

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

Đề mô tả một website phục vụ dynamic content, và vì licensing restrictions nên nội dung không được để người dùng ở một số quốc gia/khu vực cụ thể truy cập. Câu hỏi: SysOps Administrator làm cách nào để thực thi ràng buộc đó? (Chọn HAI.)

Cụm từ quyết định là "users in specific countries or regions" — tức là tiêu chí chặn được phát biểu theo vị trí địa lý, chứ không phải theo địa chỉ IP, theo port hay theo giao thức. Đây chính là ranh giới phân loại các phương án: cái nào hiểu được khái niệm "quốc gia" thì dùng được, cái nào chỉ làm việc với dải IP hoặc chỉ lo việc khác thì không.

Cụm thứ hai đáng chú ý là "(Choose TWO)" kết hợp với việc đề không nói rõ kiến trúc phía sau (chỉ nói "a new website"). Vì vậy đáp án phải là hai cơ chế chặn theo địa lý ở hai tầng khác nhau của đường đi request — tầng phân giải tên miền (DNS) và tầng phân phối nội dung (CDN) — chứ không phải hai biến thể của cùng một tầng.

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

Theo tệp, đáp án đúng là C (Amazon Route 53 geolocation routing) và E (Amazon CloudFront geo-restriction).

E — CloudFront geo-restriction: CloudFront có tính năng geo restriction (còn gọi là geo blocking), cho phép ngăn người dùng ở những vị trí địa lý nhất định truy cập nội dung phân phối qua distribution. Đây là cơ chế sinh ra đúng cho bài toán này: cấu hình theo danh sách quốc gia, CloudFront tự tra vị trí của người xem và từ chối phục vụ nếu quốc gia đó nằm trong danh sách bị chặn. Việc site phục vụ dynamic content không phải trở ngại — CloudFront đứng trước origin để phân phối cả nội dung động lẫn tĩnh.

C — Route 53 geolocation routing: geolocation routing cho phép chọn tài nguyên nào phục vụ traffic dựa trên vị trí địa lý mà truy vấn DNS xuất phát. Ví dụ trong tài liệu: mọi truy vấn từ châu Âu được định tuyến tới một ELB load balancer ở region Frankfurt. Áp vào bài toán licensing, quản trị viên dùng chính khả năng phân biệt theo vị trí này để điều khiển việc người dùng ở khu vực bị hạn chế được trả về cái gì, thay vì trả về endpoint phục vụ nội dung.

Điểm chung khiến hai phương án này đúng: cả hai đều nhận biết được vị trí địa lý như một tiêu chí cấu hình sẵn có, nên quản trị viên khai báo theo "quốc gia" đúng như cách đề phát biểu ràng buộc.

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

A — AWS Shield geo-restriction: đây là phương án bẫy vì nó ghép tên một dịch vụ có thật với tính năng của dịch vụ khác. AWS Shield dùng để giảm thiểu tấn công DDoS, nó không làm geo-restriction. Không có tính năng nào tên như vậy để bật lên cả.

B — Security group restriction: gần đúng ở chỗ security group đúng là lọc được traffic theo dải IP nguồn. Nhưng nó hỏng ở hai điểm. Thứ nhất, security group chỉ có rule cho phép (allow), không có rule chặn (deny) — nên không thể diễn đạt "chặn nước X". Cách duy nhất để mô phỏng là liệt kê allow toàn bộ dải IP của tất cả các nước được phép, một khối lượng quản trị khổng lồ. Thứ hai, security group không hiểu khái niệm quốc gia; ánh xạ quốc gia → dải IP phải do người vận hành tự duy trì và tự cập nhật.

D — Network ACL restriction: đây là phương án gần đúng nhất trong nhóm sai, vì khác security group, NACL có rule deny nên về lý thuyết diễn đạt được ý "chặn". Nhưng nó vẫn hỏng đúng ở chỗ then chốt: muốn chặn một quốc gia thì phải thêm mọi dải IP bị hạn chế vào rule, việc này khó về mặt quản trị và phải bảo trì liên tục khi dải IP thay đổi. NACL làm việc với CIDR, không làm việc với tên quốc gia.

Nói ngắn gọn: B và D thất bại vì chúng chỉ là bộ lọc IP ở tầng mạng, phải tự dịch "quốc gia" thành "dải IP"; A thất bại vì gán sai tính năng cho dịch vụ.

📌 Điểm cần nhớ

• Đề nêu ràng buộc theo quốc gia/khu vực → hướng thẳng tới các dịch vụ có tính năng geo dựng sẵn: CloudFront geo-restriction và Route 53 geolocation routing.
• Security group không có rule deny — mọi phương án đòi "chặn" bằng security group đều sai ngay từ nguyên lý, không cần bàn tới chuyện khả thi.
• Network ACL có deny nhưng chỉ hiểu CIDR, không hiểu quốc gia; dùng nó để geo-block là tự nhận việc duy trì bản đồ IP–quốc gia bằng tay.
• AWS Shield = chống DDoS, không phải công cụ kiểm soát truy cập theo địa lý. Trong đề trắc nghiệm, tên dịch vụ đúng ghép với tính năng của dịch vụ khác là bẫy rất hay gặp.

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

Đề mô tả một ứng dụng dùng Amazon Aurora DB cluster, với ba đặc điểm được nêu rất có chủ đích:

• "usage is highly variable with unpredictable spikes in traffic" — tải thay đổi thất thường, không đoán trước được, nên giải pháp phải co giãn tự động chứ không phải cấu hình cố định.
• "Much of the load is database queries and the same query is rarely performed multiple times" — phần lớn tải là truy vấn đọc, nhưng cùng một truy vấn hiếm khi lặp lại.
• "performance issues have occurred during peak usage periods when many searches were submitted" — nghẽn xảy ra đúng lúc cao điểm, do khối lượng đọc lớn.

Cụm từ quyết định là "the same query is rarely performed multiple times". Đây là chốt chặn loại thẳng hướng caching: cache chỉ có giá trị khi cùng một kết quả được đọc lại nhiều lần. Cụm thứ hai quyết định phần còn lại là "much of the load is database queries" — tải là đọc, mà đọc trên Aurora thì mở rộng bằng cách thêm Aurora Replica và đẩy truy vấn qua reader endpoint.

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

D — Implement Aurora Auto Scaling to scale the number of replicas and update the application to use the Aurora reader endpoint.

Aurora Auto Scaling điều chỉnh động số lượng Aurora Replica trong một DB cluster. Khi kết nối hoặc khối lượng công việc tăng đột ngột, nó thêm replica; khi tải giảm, nó gỡ bớt replica để không phải trả tiền cho instance không dùng tới. Đó chính là dạng biến động "unpredictable spikes" mà đề mô tả.

Vế thứ hai của phương án cũng bắt buộc: ứng dụng phải được sửa để dùng Aurora reader endpoint. Reader endpoint tự phân phối kết nối đọc sang các replica đang có trong cluster, kể cả những replica vừa được Auto Scaling tạo ra. Nếu ứng dụng vẫn trỏ thẳng vào cluster (writer) endpoint hoặc vào endpoint của từng instance cụ thể, các replica mới sinh ra sẽ nằm không — tiền vẫn mất mà nghẽn vẫn nguyên. Phương án D là phương án duy nhất nêu đủ cả hai nửa của giải pháp.

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

A — Amazon ElastiCache để cache truy vấn. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi: thêm một lớp cache trước cơ sở dữ liệu vốn là cách kinh điển giảm tải đọc. Nhưng nó hỏng ở đúng chỗ đề đã rào trước — "the same query is rarely performed multiple times". Cache chỉ hiệu quả khi tỷ lệ trúng cache (cache hit) cao; ở đây gần như mọi truy vấn đều là truy vấn mới, nên hầu hết lượt đọc vẫn rơi xuống Aurora, còn ứng dụng thì gánh thêm độ trễ tra cache và chi phí vận hành ElastiCache mà chẳng giảm được tải.

B — Tạo RAID 0 array cho các instance của Aurora cluster. Không làm được. Aurora là dịch vụ được quản lý (managed service): tầng lưu trữ do AWS vận hành, người dùng không truy cập vào đĩa nền để tự dựng RAID. Kỹ thuật RAID trên volume là chuyện của EC2 hoặc của một số cấu hình RDS tự quản lý storage, không áp dụng cho Aurora. Ngoài ra, kể cả nếu làm được, vấn đề ở đây là khối lượng đọc đồng thời lúc cao điểm chứ không phải I/O của một đĩa đơn lẻ.

C — Aurora Auto Scaling để scale kích thước (instance size) theo số truy vấn. Phương án này gần đúng vì đã nêu đúng tên dịch vụ, nhưng sai ở cái mà Auto Scaling thực sự điều chỉnh: Aurora Auto Scaling chỉ thay đổi số lượng Aurora Replica, không thay đổi class/kích thước của instance. Nói cách khác, nó làm scale out (thêm bản sao) chứ không làm scale up (nâng cấu hình). Đổi instance class là thao tác modify riêng và kèm gián đoạn, không phải thứ chạy tự động theo tải. Đọc lướt rất dễ chọn C vì thấy chữ "Aurora Auto Scaling" là gật đầu — phải đọc tới phần "scale the database instance size" mới thấy nó sai.

📌 Điểm cần nhớ

• Cache chỉ đáng giá khi dữ liệu được đọc lại. Hễ đề nói "same query is rarely repeated", "unique queries", "mỗi request là dữ liệu khác nhau" thì ElastiCache là bẫy, không phải đáp án.
• Aurora Auto Scaling = số lượng replica, không phải kích thước instance. Đây là ranh giới hay được ra đề để phân biệt hai phương án chỉ khác nhau vài chữ.
• Thêm replica mà không đổi endpoint thì vô nghĩa. Ứng dụng phải dùng reader endpoint thì các replica mới mới nhận được lưu lượng đọc. Phương án nào nêu đủ cả hai vế thường là phương án đúng.
• Aurora là managed service — mọi phương án đụng tới tầng đĩa/hệ điều hành bên dưới (RAID, tuning filesystem, gắn thêm volume) đều loại được ngay mà không cần tính toán gì thêm.

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

Đề mô tả một website chạy trên EC2 instance và nêu rõ ứng dụng cần "both incoming and outgoing connectivity to the internet" — tức là kết nối Internet hai chiều. Đây chính là cụm từ quyết định đáp án.

Cụm từ này lọc thẳng ra hai nhóm phương án: cái nào chỉ cho phép đi ra ngoài (outbound) thì loại, cái nào dựng đường vào lẫn ra thì giữ. Trong VPC, thứ duy nhất cho phép lưu lượng đi vào từ Internet tới instance là internet gateway gắn với VPC, kèm route table của subnet trỏ ra gateway đó — đó là định nghĩa của một public subnet. Câu hỏi yêu cầu chọn hai bước, nên đáp án phải là cặp bước tối thiểu để dựng đường đi hai chiều, chứ không phải mọi thứ liên quan tới networking.

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

Đáp án đúng theo tệp là B và E.

E — Create an internet gateway and attach it to a VPC. Internet gateway là thành phần ở cấp VPC làm cửa ra vào Internet. Tạo không thôi chưa đủ, nó phải được attach vào VPC thì VPC mới có đường thông ra ngoài. Đây là bước đầu tiên và bắt buộc.

B — Add an entry to the route table for the subnet that points to an internet gateway. Có gateway rồi nhưng subnet chứa EC2 instance phải biết đường đi tới nó. Thêm route trỏ lưu lượng ra Internet về phía internet gateway chính là thứ biến subnet đó thành public subnet. Thiếu bước này thì gateway gắn vào VPC vẫn nằm im, gói tin không bao giờ ra tới.

Hai bước này ghép lại cho lưu lượng đi cả chiều vào lẫn chiều ra, đúng yêu cầu của đề. (Phần giải thích gốc có nhắc thêm rằng instance cũng cần public IP, thường bật bằng tuỳ chọn auto-assign public IP của subnet — nhưng đó không phải một phương án trong danh sách, và đề chỉ hỏi hai bước.)

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

A — Attach a private address to the elastic network interface on the EC2 instance. Đây là phương án gần đúng theo kiểu đánh lừa: nó nói đúng về địa chỉ IP nhưng sai loại địa chỉ. Mọi EC2 instance đều đã tự động có private IP trên elastic network interface của nó, nên đây không phải việc phải làm thêm. Quan trọng hơn, private IP chỉ dùng trong phạm vi VPC; muốn kết nối Internet hai chiều thì thứ cần là public IP, không phải private.

C — Attach an Elastic IP address to the internet gateway. Sai vì gắn nhầm chỗ. Elastic IP là public IP gắn cho instance (hoặc network interface, hoặc NAT gateway), không gắn cho internet gateway. Internet gateway được AWS cấp sẵn khả năng kết nối khi tạo ra, người dùng không phải và không thể gán EIP cho nó.

D — Add a NAT gateway to a public subnet and update the route table. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu này. NAT gateway đúng là đặt trong public subnet và đúng là phải sửa route table — nghe rất khớp. Nhưng NAT gateway chỉ phục vụ chiều đi ra: nó cho instance trong private subnet gọi ra Internet mà không cho ai từ Internet chủ động mở kết nối vào. Đề đòi incoming connectivity, mà NAT gateway theo thiết kế chặn đúng chiều đó. Ngoài ra NAT gateway vẫn cần internet gateway phía sau mới hoạt động, nên nó không thay thế được B và E.

📌 Điểm cần nhớ

• Đọc kỹ chiều của lưu lượng trong đề: "incoming and outgoing" (hai chiều) → internet gateway + public subnet; chỉ "outbound" hoặc "instances in private subnet need updates/patches" → NAT gateway.
• Public subnet không phải là một loại subnet riêng — nó chỉ đơn giản là subnet có route trỏ ra internet gateway. Tạo gateway mà quên sửa route table là lỗi hay gặp nhất.
• Internet gateway gắn ở cấp VPC; route trỏ ra nó nằm ở cấp subnet. Hai bước, hai tầng khác nhau, đều bắt buộc.
• Elastic IP / public IP gắn cho instance hoặc network interface, không gắn cho internet gateway. Private IP thì đã có sẵn, không phải bước cấu hình thêm.

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

Đề mô tả một CloudFront distribution lấy origin là S3 bucket, nhưng cụm từ quyết định nằm ở câu thứ hai: "The S3 static website endpoint is used as the origin domain name". Đây là chi tiết phân biệt duy nhất của cả câu.

S3 cho một bucket hai loại endpoint khác nhau:

• REST API endpoint (bucket.s3.region.amazonaws.com) — hiểu được SigV4, nên CloudFront ký request bằng Origin Access Control (OAC) và bucket có thể giữ private hoàn toàn.
• Static website endpoint (bucket.s3-website-region.amazonaws.com) — chỉ nói HTTP thuần, không xác thực request nào cả. CloudFront không có cách nào ký request tới nó, nên nó chỉ phục vụ được nội dung công khai.

Vì đề chọn kiểu endpoint thứ hai, mọi hướng "giữ bucket private rồi cấp quyền cho CloudFront" đều bị loại từ đầu. 403 Access Denied ở đây chỉ có một nghĩa: object trong bucket chưa cho phép đọc công khai.

Chi tiết thứ hai cần để ý là từ "objects" so với "bucket" trong các phương án — hai phương án A và D nghe gần như y hệt, khác nhau đúng ở chỗ quyền được cấp trên tài nguyên nào.

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

D — Create a bucket policy that allows public read access for all objects in the bucket.

Với static website endpoint, CloudFront gửi request ẩn danh tới S3. Để request đó thành công, chính object phải cho phép s3:GetObject ẩn danh. Bucket policy là nơi diễn đạt điều đó, nhưng phần Resource phải trỏ tới nội dung bên trong bucket (dạng arn:aws:s3:::ten-bucket/*) chứ không phải bản thân bucket.

Cách viết như vậy đúng vì s3:GetObject là một action cấp object: nó chỉ có nghĩa khi resource là key trong bucket. Đây cũng chính là điều tài liệu AWS về lỗi 403 giữa S3 website endpoint và CloudFront nói tới — cấp quyền đọc công khai cho toàn bộ object là cách khắc phục.

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

A. Create a bucket policy that allows public read access to the bucket — đây là phương án gần đúng nhất và là bẫy chính của câu. Nó hỏng ở phạm vi resource: cấp quyền "trên bucket" nghĩa là ARN dừng ở arn:aws:s3:::ten-bucket, chỉ áp cho các action cấp bucket (kiểu liệt kê nội dung). Request của CloudFront không đi lấy danh sách bucket — nó đi lấy một file cụ thể bằng s3:GetObject, mà action đó khớp với ARN object. Policy viết theo A sẽ được S3 chấp nhận nhưng không cứu được lỗi 403, vì không statement nào phủ lên object đang bị từ chối. Khác biệt A/D chỉ là dấu /* ở cuối ARN, và đúng dấu đó quyết định câu trả lời.

B. Ensure default encryption using the Amazon S3-managed keys — mã hoá và phân quyền là hai trục hoàn toàn khác nhau; bật SSE-S3 không làm một request ẩn danh trở nên được phép. Ở tình huống này SSE-S3 vốn đã hợp lệ và không gây ra 403. (Ngược lại, mã hoá bằng KMS mới là thứ không dùng được trong kịch bản website endpoint — nhưng đề không hỏi tới hướng đó, và dù sao thì đây cũng không phải nguyên nhân của lỗi.)

C. Remove the default bucket policy that denies read access to the bucket — phương án này dựa trên một tiền đề không tồn tại: S3 không tạo sẵn bucket policy nào cả, càng không có policy mặc định chứa Deny. Bucket mới đơn giản là không có policy, và mặc định là từ chối ngầm (implicit deny) chứ không phải một Deny tường minh nằm trong tài liệu policy. Thứ dễ bị nhầm với "default deny policy" là Block Public Access — nhưng đó là một setting của bucket/tài khoản, không phải policy, nên không có gì để "remove" theo cách đề nói. Người soạn cố tình dựng phương án này để thử xem thí sinh có phân biệt được setting với policy hay không.

📌 Điểm cần nhớ

• Kiểu origin endpoint quyết định mô hình bảo mật. REST endpoint → giữ bucket private, dùng OAC/OAI. Static website endpoint → CloudFront không ký được request, nội dung bắt buộc phải công khai. Đọc kỹ đề xem nó nhắc tới endpoint nào.
• s3:GetObject cần resource ARN có /*. Quyền "trên bucket" và quyền "trên object trong bucket" là hai thứ khác nhau; nhầm chỗ này là kiểu 403 phổ biến nhất với S3.
• S3 không có "default deny policy". Bucket mới không kèm policy nào; thứ chặn public access là setting Block Public Access, và cả hai lớp (setting + policy) đều phải cho phép thì request ẩn danh mới qua.
• Lỗi 403 là vấn đề phân quyền, không phải mã hoá. Đừng để các phương án về SSE-S3/KMS kéo hướng suy nghĩ sang chỗ khác khi triệu chứng là Access Denied.

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

Đề mô tả một công ty chạy nhiều ứng dụng trải trên nhiều AWS Region, dùng đồng thời EC2 On-Demand instances và AWS Lambda functions. Nhóm SysOps phải giảm chi phí, và mức tiêu thụ compute được mô tả là ổn định (stable).

Có hai cụm từ trong đề quyết định đáp án, và cần cả hai mới loại hết được:

• "and AWS Lambda functions" — đây là ràng buộc phân biệt chính. Bốn phương án đều là hình thức cam kết trả trước để lấy giá rẻ, nhưng chỉ một loại cam kết áp được cho Lambda. Reserved Instances là cam kết gắn với EC2 instance, không có khái niệm RI cho Lambda. EC2 Instance Savings Plans, đúng như tên gọi, cũng chỉ phủ EC2.
• "consumption of compute resources is stable" — đây là điều kiện cho phép cam kết dài hạn. Nếu tải lên xuống thất thường thì cam kết một mức chi tiêu cố định theo giờ là rủi ro. Đề nói rõ là ổn định, nên hướng "mua cam kết" là hướng đúng, chứ không phải hướng scaling/rightsizing.

Ngoài ra, cụm "based recommendations in Cost Explorer" so với "based on CloudWatch metrics" cũng là một trục phân biệt: Cost Explorer là công cụ AWS cung cấp sẵn khuyến nghị mua Savings Plans/RI dựa trên lịch sử chi phí và mức dùng thực tế, còn CloudWatch là công cụ giám sát hiệu năng, không sinh ra khuyến nghị mua cam kết.

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

Đáp án đúng theo tệp là D — Purchase Compute Savings Plans based recommendations in Cost Explorer.

Savings Plans là mô hình giá linh hoạt: bạn cam kết một mức chi tiêu cố định tính bằng $/giờ trong thời hạn 1 hoặc 3 năm, đổi lại được đơn giá thấp hơn On-Demand. Trong đó Compute Savings Plans là loại phủ rộng nhất — nó áp cho EC2, AWS Lambda và AWS Fargate, và áp bất kể instance family, kích thước, hệ điều hành, tenancy hay Region nào.

Đối chiếu với đề: workload gồm cả EC2 lẫn Lambda, lại nằm rải trên nhiều Region. Compute Savings Plans là phương án duy nhất trong danh sách phủ được cả hai loại compute đó cùng lúc, và cũng là loại không bị bó vào một Region cụ thể. Cộng thêm mức tiêu thụ ổn định, việc cam kết một mức chi tiêu theo giờ là an toàn.

Phần "based recommendations in Cost Explorer" là cách làm được AWS khuyến nghị: Cost Explorer có mục Savings Plans recommendations, phân tích lịch sử dùng thực tế rồi đề xuất mức cam kết nên mua, thay vì để đội vận hành tự ước lượng.

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

A. Purchase Convertible Reserved Instances based on CloudWatch metrics — Convertible RI là loại RI linh hoạt nhất, cho phép đổi sang instance family/OS/tenancy khác trong thời hạn cam kết, nên nghe rất "gần đúng" với một môi trường đa dạng. Nhưng nó vẫn là cam kết dành cho EC2 instances: không mang lại lợi ích chi phí nào cho Lambda. Vế thứ hai cũng hỏng — CloudWatch cung cấp metric hiệu năng, không phải nơi đưa ra khuyến nghị mua cam kết; đó là việc của Cost Explorer.

B. Purchase EC2 Instance Savings Plans based recommendations in Cost Explorer — đây là phương án gần đúng nhất và là bẫy chính của câu này. Nó đúng loại sản phẩm (Savings Plans), đúng công cụ (Cost Explorer), chỉ sai đúng một chữ: EC2 Instance Savings Plans chỉ phủ EC2, không phủ Lambda. Ngoài ra loại này còn ràng buộc chặt hơn — cam kết gắn với một instance family trong một Region cụ thể — nên với workload trải nhiều Region như đề mô tả thì càng bất lợi. Đổi "EC2 Instance" thành "Compute" là ra đáp án đúng.

C. Purchase Standard Reserved Instances based on CloudWatch metrics — Standard RI cho mức chiết khấu cao nhất nhưng cũng cứng nhắc nhất: gắn chặt vào cấu hình instance đã chọn, không đổi được instance family như Convertible RI. Giống A, nó không áp được cho Lambda, và cũng lấy sai nguồn khuyến nghị (CloudWatch thay vì Cost Explorer). Phương án này sai ở cả ba khía cạnh: phạm vi phủ, độ linh hoạt với môi trường đa Region, và công cụ ra quyết định.

📌 Điểm cần nhớ

• Thấy Lambda (hoặc Fargate) xuất hiện chung với EC2 trong một câu hỏi tối ưu chi phí → nghĩ ngay Compute Savings Plans. Reserved Instances và EC2 Instance Savings Plans đều chỉ phủ EC2; Lambda không có khái niệm "reserved instance".
• Phân biệt hai loại Savings Plans theo phạm vi phủ: Compute Savings Plans linh hoạt nhất (EC2 + Lambda + Fargate, xuyên Region, xuyên instance family) nhưng chiết khấu thấp hơn; EC2 Instance Savings Plans chiết khấu sâu hơn nhưng bó vào một instance family trong một Region.
• Cost Explorer là nơi ra khuyến nghị mua cam kết; CloudWatch là nơi giám sát hiệu năng. Phương án nào nói "mua RI/Savings Plans dựa trên CloudWatch metrics" thì gần như luôn là phương án sai trong đề thi.
• Cụm "usage is stable" là tín hiệu cho phép cam kết dài hạn. Ngược lại, đề nhấn mạnh tải biến động hoặc chạy ngắt quãng thì hướng đúng thường không phải là mua cam kết.

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

Đề mô tả một ứng dụng chạy trong một AWS Region duy nhất ở Mỹ, trên fleet EC2 đứng sau Network Load Balancer, và cung cấp endpoint SFTP cho người dùng. Người dùng ở châu Âu than phiền độ trễ cao và kết nối không ổn định. Yêu cầu: cải thiện hiệu năng và độ ổn định.

Có hai cụm từ quyết định đáp án, và phải đọc cả hai mới loại hết được các phương án:

• "SFTP endpoint" — đây là giao thức chạy trên TCP, không phải HTTP/HTTPS. Cụm này một mình đã đủ loại CloudFront, vì CloudFront là CDN cho nội dung web, phân phối qua HTTP/HTTPS chứ không proxy được luồng SFTP.
• "improve performance and stability" cho người dùng ở xa, trong khi hạ tầng vẫn nằm ở một Region — nghĩa là cần một lớp mạng đưa traffic của người dùng châu Âu vào mạng backbone của AWS sớm nhất có thể, thay vì đi lòng vòng qua public Internet suốt chặng vượt Đại Tây Dương.

Ràng buộc thứ ba, ẩn hơn: các phương án C và D chỉ dựng thêm tài nguyên ở châu Âu mà không nói gì đến cách điều hướng traffic tới tài nguyên đó.

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

Đáp án đúng theo tệp là A — Create an accelerator in AWS Global Accelerator and update the DNS record.

AWS Global Accelerator là dịch vụ mạng làm việc ở tầng TCP/UDP, nên nó hỗ trợ được SFTP — điều mà một CDN tầng HTTP không làm được. Nó cấp một bộ static IP address làm điểm vào cố định cho ứng dụng, và Network Load Balancer là endpoint hợp lệ để accelerator trỏ tới.

Cơ chế cải thiện hiệu năng: người dùng châu Âu kết nối vào edge location gần họ nhất, rồi từ đó traffic đi trên mạng backbone toàn cầu của AWS thay vì đi qua public Internet. Chặng Internet công cộng bị rút ngắn xuống chỉ còn đoạn từ người dùng tới edge, nên vừa giảm latency vừa giảm hiện tượng mất gói và kết nối chập chờn — đúng hai triệu chứng đề nêu.

Global Accelerator cũng liên tục theo dõi sức khoẻ của endpoint và tự động chuyển hướng traffic khi endpoint hỏng, phản ứng theo tình trạng ứng dụng, vị trí người dùng và policy đã cấu hình. Đó là phần "stability". Bước cuối là cập nhật bản ghi DNS để trỏ về accelerator thay vì trỏ thẳng vào NLB — thiếu bước này thì accelerator có dựng xong cũng không ai đi qua nó.

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

B — Create an Amazon CloudFront distribution and update the DNS record. Đây là phương án bẫy hấp dẫn nhất, vì CloudFront cũng dùng mạng edge location và cũng thường được nhắc tới khi nói "người dùng ở xa bị chậm". Nhưng nó hỏng ở chỗ căn bản: CloudFront không dùng được cho giao thức SFTP. Nó phân phối nội dung qua HTTP/HTTPS. Ứng dụng trong đề phơi ra một endpoint SFTP, nên CloudFront không đứng trước được luồng đó. Đúng "vị trí" nhưng sai "tầng giao thức".

C — Create an Auto Scaling group in an AWS Region in Europe. Riêng việc này thì không giải quyết được gì. Auto Scaling group lo chuyện co giãn số lượng EC2 instance theo tải, trong khi vấn đề của đề là khoảng cách địa lý và chất lượng đường truyền, không phải thiếu năng lực xử lý. Hơn nữa, một ASG trần thì vẫn cần có load balancer đứng trước, và vẫn cần một cơ chế điều hướng để traffic của người dùng châu Âu thực sự đi tới đó — cơ chế đó chính là Route 53 routing policy hoặc Global Accelerator. Nghĩa là C giỏi lắm chỉ là một nửa của lời giải, và là nửa không phải nửa quan trọng.

D — Create a new Network Load Balancer in an AWS Region in Europe. Cùng lỗ hổng như C, chỉ khác thành phần. Dựng thêm NLB ở châu Âu mà không có gì điều hướng traffic tới NLB đó thì người dùng châu Âu vẫn phân giải DNS về endpoint cũ ở Mỹ và vẫn chịu đúng độ trễ như trước. Muốn D có tác dụng thì vẫn phải bổ sung một lớp định tuyến động ở trên — quay lại chính đáp án A.

📌 Điểm cần nhớ

• Giao thức là bộ lọc đầu tiên. Đề nhắc SFTP, TCP, UDP, hoặc cổng không phải web → nghĩ Global Accelerator. Đề nhắc HTTP/HTTPS, nội dung tĩnh, video → nghĩ CloudFront. Hai dịch vụ cùng dùng edge location nhưng phục vụ tầng khác nhau.
• Global Accelerator giải quyết "người dùng toàn cầu, hạ tầng một Region" bằng cách rút ngắn chặng đi trên public Internet: vào backbone AWS từ edge gần người dùng, cộng thêm static IP làm điểm vào cố định và health check tự chuyển hướng.
• Thêm tài nguyên ≠ thêm định tuyến. Phương án chỉ nói "dựng ASG/NLB ở Region khác" mà không kèm cơ chế đưa traffic tới đó (Route 53 routing policy hoặc Global Accelerator) thì gần như luôn là phương án thiếu.
• Đừng quên bước cập nhật DNS. Trong loại câu này, phần "update the DNS record" không phải chi tiết thừa — nó là thứ biến hạ tầng vừa dựng thành đường đi thực sự của người dùng.