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

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

Đề mô tả một S3 bucket chứa dữ liệu nhạy cảm và yêu cầu SysOps Administrator giám sát mọi hoạt động upload và download object của bucket đó, kèm bốn thông tin: AWS account của người gọi, IAM user/role của người gọi, thời điểm gọi API, và IP nguồn.

Cụm từ quyết định là "object upload and download activity" — tức là các lời gọi API ở mức object (PutObject, GetObject), chứ không phải các thao tác lên chính cái bucket (tạo bucket, đổi policy, bật versioning). Trong từ vựng của AWS CloudTrail, đây chính là ranh giới giữa hai loại sự kiện:

• Management events (control plane): thao tác lên tài nguyên — CreateBucket, PutBucketPolicy, DeleteBucket.
• Data events (data plane): thao tác bên trong tài nguyên — GetObject, PutObject, DeleteObject.

Cụm từ thứ hai đáng chú ý là danh sách bốn trường cần ghi lại (account, IAM identity, thời gian, IP nguồn). Đó đúng là bộ trường chuẩn của một bản ghi CloudTrail (userIdentity, eventTime, sourceIPAddress) — nó chỉ thẳng rằng câu trả lời phải là CloudTrail, và phần còn lại chỉ là chọn đúng loại event.

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

A — Enable data event logging in AWS CloudTrail.

Data events là loại sự kiện ghi lại các thao tác data plane, trong đó có object-level API của Amazon S3: GetObject (download), PutObject (upload), DeleteObject. Bật data event logging cho bucket này là cách duy nhất trong bốn phương án để thấy được từng lượt upload/download.

Mỗi bản ghi CloudTrail đi kèm sẵn userIdentity (AWS account ID và IAM user/role đã gọi API), eventTime và sourceIPAddress — khớp trọn vẹn bốn yêu cầu của đề, không cần cấu hình gì thêm.

Một chi tiết đáng nhớ: data events không được bật mặc định khi tạo trail, vì lượng sự kiện data plane thường rất lớn. Người quản trị phải chỉ định rõ tài nguyên (hoặc loại tài nguyên) muốn theo dõi — chính vì phải bật thủ công nên đề mới dùng động từ "Enable".

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

C — Enable management event logging in AWS CloudTrail. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi: đúng dịch vụ, sai loại event. Management events chỉ ghi các thao tác control plane trên tài nguyên trong tài khoản — với S3 nghĩa là tạo/xoá bucket, sửa bucket policy, đổi cấu hình. Chúng không ghi GetObject/PutObject, nên nhật ký sẽ không có một dòng nào về upload hay download. Ngoài ra management events vốn đã được ghi mặc định, nên nếu đó là câu trả lời thì bài toán đã tự giải quyết mà chẳng cần làm gì.

B — Configure Amazon Inspector user event logging. Amazon Inspector là dịch vụ đánh giá bảo mật, quét lỗ hổng và cấu hình rủi ro trên workload; nó không phải là dịch vụ ghi nhật ký lời gọi API. Không có chức năng nào tên "user event logging" trong Inspector, và Inspector cũng không sinh ra bản ghi chứa IAM identity + IP nguồn của từng request tới S3. Sai cả dịch vụ lẫn tên tính năng.

D — Configure Amazon Inspector bucket event logging. Sai theo đúng cách như B, chỉ đổi chữ "user" thành "bucket" cho có vẻ liên quan tới S3 hơn. Inspector không theo dõi hoạt động API trên bucket; muốn có nhật ký API thì phải dùng CloudTrail. Hai phương án B và D được đặt cạnh nhau để kiểm tra xem thí sinh có bị hút theo từ khoá quen thuộc mà quên vai trò thật của Inspector hay không.

📌 Điểm cần nhớ

• Với S3, hễ đề nói tới object-level (GetObject, PutObject, DeleteObject, upload, download) thì cần CloudTrail data events; hễ nói tới thao tác trên chính bucket (tạo, xoá, đổi policy) thì đó là management events.
• Data events không bật mặc định — phải chỉ định rõ tài nguyên cần theo dõi trên trail. Ngược lại, management events được ghi mặc định.
• Bộ bốn thông tin "ai gọi (account + IAM identity), gọi lúc nào, gọi từ IP nào" là chữ ký nhận dạng của một bản ghi CloudTrail. Thấy bộ này trong đề thì nghĩ ngay tới CloudTrail.
• Amazon Inspector = đánh giá bảo mật/quét lỗ hổng, không phải nhật ký API. Đừng chọn nó cho bất kỳ yêu cầu "ai đã gọi API nào" nào.

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

Đề mô tả một website thương mại điện tử chạy Amazon RDS Multi-AZ deployment, đã xảy ra automated failover, và SysOps Administrator cần tìm nguyên nhân gốc. Câu hỏi: điều kiện nào có thể khiến database failover? (Chọn HAI).

Cụm từ quyết định là "automated failover" trong ngữ cảnh Multi-AZ. Nó thu hẹp phạm vi về đúng một danh sách: những sự kiện mà chính RDS tự phát hiện ở tầng hạ tầng/instance rồi tự chuyển sang standby replica. Cụm thứ hai đáng chú ý là "root cause" — người quản trị đang đi tìm sự kiện kích hoạt failover, chứ không phải triệu chứng hiệu năng đi kèm.

Với ràng buộc đó, mọi phương án phải trả lời được một câu duy nhất: RDS có coi đây là tín hiệu để tự chuyển đổi dự phòng hay không? Multi-AZ standby là bản sao đồng bộ dùng cho tính sẵn sàng, không phải cơ chế giảm tải hay sửa dữ liệu — nên các phương án nói về tranh chấp tài nguyên hay hỏng dữ liệu sẽ rơi ra ngoài.

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

Theo tệp, đáp án đúng là C và E.

E — A storage failure on the primary database. Đây là hỏng hóc ở tầng hạ tầng của chính primary DB instance. Multi-AZ sinh ra chính là để chống lại kiểu sự cố này: khi primary không còn phục vụ được, RDS tự động chuyển DNS endpoint sang standby replica ở AZ khác. Ứng dụng giữ nguyên chuỗi kết nối, chỉ cần kết nối lại. Đây là kịch bản failover kinh điển nhất của Multi-AZ.

C — The database instance type was changed. Đổi instance class (scale up/scale down) đòi hỏi thay đổi phần cứng bên dưới. Trên Multi-AZ, RDS áp dụng thay đổi lên standby trước, rồi failover sang standby đó, rồi mới sửa nốt instance cũ. Cách làm này rút ngắn thời gian gián đoạn so với việc dừng hẳn primary để đổi. Đây là điểm rất hay bị bỏ sót khi truy nguyên nhân: failover không nhất thiết là dấu hiệu sự cố — một thao tác bảo trì đã lên kế hoạch (đổi instance type, patch hệ điều hành, hoặc Reboot with failover) cũng tạo ra đúng sự kiện failover trong log.

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

A — Read contention on the secondary database. Sai ngay ở tiền đề. Trong RDS Multi-AZ (khác với Multi-AZ DB cluster hoặc read replica), standby replica không phục vụ traffic đọc — nó chỉ nhận bản sao đồng bộ và chờ. Không có ai đọc từ nó thì không thể có "read contention". Và kể cả nếu standby gặp vấn đề, chuyện đó cũng không làm primary chuyển đổi — failover là chuyển khỏi primary, không phải chuyển vì standby.

B — Write contention on the primary database. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Tranh chấp ghi trên primary là vấn đề hiệu năng thật, có thể gây chậm, timeout, khoá — nhưng RDS không failover dựa trên chỉ số hiệu năng. Instance vẫn đang chạy, vẫn phản hồi health check, chỉ là chậm. Chuyển sang standby cũng chẳng giải quyết được gì: standby có cùng cấu hình, cùng workload sẽ tranh chấp y hệt. Cách xử lý đúng cho tình huống này là tối ưu truy vấn hoặc đổi instance type — và lưu ý, chính thao tác đổi instance type mới là thứ gây failover (phương án C), chứ không phải bản thân sự tranh chấp.

D — Database corruption errors. Cũng là phương án nghe rất hợp lý nhưng hỏng ở chỗ: hỏng dữ liệu xảy ra ở tầng logic bên trong database, còn cơ chế failover của RDS theo dõi tình trạng của instance và hạ tầng. RDS không dò tìm corruption trong dữ liệu để rồi tự chuyển đổi. Tệ hơn, standby được đồng bộ từ primary, nên dữ liệu hỏng nhiều khả năng đã được nhân bản sang đó — failover không sửa được gì. Đường xử lý cho corruption là point-in-time recovery hoặc khôi phục từ snapshot, không phải Multi-AZ.

📌 Điểm cần nhớ

• Multi-AZ = tính sẵn sàng (availability), không phải khả năng mở rộng (scalability) cũng không phải bảo vệ dữ liệu. Gặp phương án nói về giảm tải đọc, tranh chấp ghi, hay sửa dữ liệu hỏng — gần như chắc chắn sai trong câu hỏi về failover.
• RDS failover phản ứng với sự kiện hạ tầng/instance, không phản ứng với chỉ số hiệu năng. Chậm, tranh chấp, tải cao đều không kích hoạt failover.
• Failover không đồng nghĩa với sự cố. Đổi instance type, patch hệ điều hành, hay Reboot with failover thủ công đều tạo ra failover có chủ đích — khi truy root cause, hãy kiểm tra lịch sử thao tác bảo trì trước khi kết luận là hỏng hóc.
• Standby trong RDS Multi-AZ không nhận traffic đọc. Ghi nhớ điều này để loại ngay những phương án nói về hoạt động đọc trên standby.

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

Một công ty chạy ứng dụng trên nhiều EC2 instance Linux nằm trong một Auto Scaling group, khởi tạo bằng launch template, ổ chính là EBS gp3. Yêu cầu: tất cả EC2 instance đều truy cập được cùng một bộ tệp nền (base files) và dữ liệu phải nhất quán.

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

• "all EC2 instances can access the same base files" — đây là nhu cầu chia sẻ tệp giữa nhiều máy cùng lúc, tức là cần một file system dùng chung gắn được đồng thời lên nhiều instance, chứ không phải nơi lưu đối tượng hay bộ nhớ đệm.
• "ensure data consistency" — nhiều instance cùng đọc/ghi thì phải có ngữ nghĩa file system (POSIX) lo việc khoá và nhất quán, chứ không thể dựa vào đồng bộ định kỳ.

Thêm một chi tiết cài sẵn trong đề để loại phương án: ổ hiện tại là gp3. Chi tiết này chỉ có tác dụng khi bạn xét tới phương án EBS Multi-Attach.

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

Đáp án đúng theo tệp là A — tạo Amazon EFS file system, ra phiên bản launch template mới có user data mount EFS, rồi cho Auto Scaling group dùng template mới và thay dần các instance cũ.

Amazon EFS là file system đàn hồi, do AWS quản lý hoàn toàn, tự co giãn theo lượng dữ liệu mà không phải cấp phát trước. Điểm mấu chốt: EFS được thiết kế để nhiều EC2 instance mount đồng thời qua giao diện file system, giữ nguyên ngữ nghĩa file system chuẩn. Nhờ vậy mọi instance nhìn thấy cùng một cây thư mục, cùng một nội dung tệp — đúng cả hai vế "same base files" và "data consistency" mà đề đòi.

Cách triển khai cũng khớp mô hình Auto Scaling: instance trong Auto Scaling group sinh ra và biến mất liên tục, nên việc mount phải tự động hoá trong launch template qua user data, để mọi instance mới đều tự nối vào EFS ngay lúc khởi động mà không cần ai can thiệp thủ công.

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

B — Dùng Amazon S3 rồi "mount S3" lúc khởi tạo. Đây là phương án gần đúng nhất về mặt ý tưởng: S3 đúng là kho lưu trữ dùng chung, mọi instance đều gọi tới được. Nhưng nó hỏng ở đúng chữ "mount": S3 là object storage, truy cập qua API chứ không phải file system mount được lên EC2 theo cách một ổ đĩa hay NFS làm được. Nó phù hợp để lưu và lấy về khối lượng lớn dữ liệu tĩnh, không phải để ứng dụng đọc/ghi như tệp cục bộ với ngữ nghĩa file system.

C — Dựng cụm Amazon ElastiCache. Sai về bản chất dịch vụ. ElastiCache là giải pháp caching, phục vụ đọc nhanh dữ liệu dạng key-value trong bộ nhớ. Nó không phải file system, không cung cấp cách chia sẻ tệp giữa các EC2 instance, và cũng không sinh ra để bảo đảm tính nhất quán dữ liệu tệp như đề yêu cầu. Thấy chữ "shared access" trong phương án mà tưởng là chia sẻ tệp là mắc bẫy.

D — EBS Multi-Attach cộng Lambda đồng bộ định kỳ. Đây là phương án được dựng lên để dụ người đọc lướt qua, và nó hỏng ở hai chỗ:

• Multi-Attach chỉ áp dụng cho volume Provisioned IOPS io1, trong khi đề nói rõ hệ thống đang dùng gp3. Chi tiết gp3 ở đầu đề chính là để loại phương án này.
• Ngay cả khi loại volume có hợp lệ, Multi-Attach không tự lo tính nhất quán khi nhiều máy cùng ghi — muốn an toàn phải có file system hỗ trợ nhiều node ở tầng trên. Việc vá bằng một Lambda chạy theo lịch để "đồng bộ định kỳ" càng lộ ra rằng dữ liệu sẽ lệch nhau giữa hai lần chạy, tức là ngược hẳn với yêu cầu "ensure data consistency".

📌 Điểm cần nhớ

• Đề nói nhiều instance cùng đọc/ghi chung một bộ tệp → nghĩ ngay tới file system chia sẻ dạng EFS, không phải object storage hay cache.
• S3 không mount được như file system trên EC2 theo nghĩa thông thường; phương án nào ghép chữ "S3" với chữ "mount" thì gần như chắc chắn là mồi nhử.
• EBS Multi-Attach giới hạn ở io1 và không tự bảo đảm nhất quán giữa nhiều writer — chú ý loại volume mà đề nêu (ở đây là gp3), nó thường là chìa khoá loại phương án.
• Với Auto Scaling group, mọi cấu hình phải nằm trong launch template + user data để instance mới tự thiết lập; phương án nào cần thao tác tay trên từng máy là sai mô hình vận hành.
• Phân biệt vai trò dịch vụ: ElastiCache = caching, không phải nơi chia sẻ tệp hay nguồn dữ liệu nhất quán.

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

Đề mô tả các EC2 instance nằm trong private subnet của một VPC, cần upload object lên S3 bucket. Có hai ràng buộc phải thoả cùng lúc:

1. "data must not traverse the public network" — đường đi của dữ liệu phải nằm trong mạng AWS, không ra Internet công cộng.
2. "access to the bucket to be restricted to the EC2 instances in the private network" — bản thân bucket chỉ được nhận request đến từ mạng riêng đó, chứ không phải "instance của tôi truy cập được là xong".

Cụm từ quyết định là vế thứ hai: "access to the bucket to be restricted". Chủ thể bị siết ở đây là bucket, không phải instance. Đây chính là chỗ phân biệt hai phương án B và C — hai phương án giống nhau y hệt ở nửa đầu (đều tạo VPC endpoint), chỉ khác nhau ở việc đặt điều kiện lọc vào IAM policy hay bucket policy.

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

Đáp án đúng: C — tạo VPC endpoint cho S3 và viết một S3 bucket policy giới hạn mọi S3 action theo điều kiện nguồn là VPC endpoint đó.

Hai vế của C khớp đúng hai ràng buộc:

• VPC endpoint cho S3 tạo đường đi riêng từ private subnet tới S3 bên trong mạng AWS. Traffic đi qua endpoint là traffic riêng, không đi ra public network — thoả ràng buộc thứ nhất, và cũng là lý do instance trong private subnet không cần Internet vẫn gọi được S3.
• Bucket policy là resource-based policy gắn thẳng vào bucket, nên nó áp cho mọi request tới bucket bất kể người gọi là ai. Dùng điều kiện so khớp aws:sourceVpce với id của VPC endpoint, ta chặn được toàn bộ request không đến từ endpoint đó. Đây mới là cách "restrict access to the bucket" theo đúng nghĩa đề nêu — thoả ràng buộc thứ hai.

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

A. Tạo AWS VPN tunnel giữa private subnet và S3 public endpoint. Không dựng được. AWS VPN dùng để nối VPC với mạng on-premises hoặc mạng ngoài có thiết bị đầu cuối VPN; S3 là dịch vụ quản lý, không phải đầu cuối để bạn thiết lập một tunnel tới. Ngoài ra bản thân câu chữ đã tự mâu thuẫn: đích của tunnel là public endpoint của S3, tức là vẫn hướng ra mạng công cộng, đi ngược yêu cầu của đề.

B. Tạo VPC endpoint + IAM policy giới hạn theo nguồn là VPC endpoint. — Đây là phương án gần đúng nhất, và cũng là bẫy chính. Nửa đầu hoàn toàn đúng: VPC endpoint giải quyết được vế "không đi qua public network". Chỗ hỏng nằm ở nửa sau. IAM policy là identity-based policy — nó phải được gắn vào một identity (user/group/role) thì mới có hiệu lực, và nó chỉ ràng buộc đúng những identity được gắn. Kết quả: bucket vẫn có thể bị truy cập bởi bất kỳ principal nào khác không dính IAM policy đó, đi bằng đường khác. Đề yêu cầu siết ở phía bucket, nên phải là policy gắn vào chính bucket. Nói cách khác, B kiểm soát "ai được đi", còn đề đòi "bucket chỉ nhận từ đâu".

D. Tạo NAT gateway và định tuyến traffic đi S3 qua NAT gateway. NAT gateway đúng là cách phổ biến để instance trong private subnet gọi ra ngoài, và về mặt kết nối thì nó chạy được — nhưng chạy theo cách sai. NAT gateway đặt trong public subnet và đẩy traffic ra Internet để tới public endpoint của S3. Dữ liệu vì thế vẫn đi qua public network, vi phạm thẳng ràng buộc rõ ràng nhất của đề. Thêm nữa, D không có bất kỳ cơ chế nào giới hạn quyền truy cập ở phía bucket, nên cả hai yêu cầu đều trượt.

📌 Điểm cần nhớ

• "Không đi qua public network" ⇒ nghĩ tới VPC endpoint. NAT gateway và Internet gateway đều đưa traffic ra Internet, chỉ khác ở chiều khởi tạo kết nối — chúng không bao giờ là câu trả lời cho yêu cầu "private traffic".
• Phân biệt IAM policy và bucket policy theo đối tượng bị siết. Đề nói "restrict access to the bucket" → resource-based policy (bucket policy). Đề nói "cho phép role/user này làm gì" → identity-based policy (IAM policy). Khi hai phương án chỉ khác nhau ở chỗ này, hãy đọc lại chủ ngữ trong câu yêu cầu.
• Bucket policy áp cho mọi request tới bucket, kể cả từ principal bạn không quản lý; IAM policy chỉ áp cho identity được gắn. Vì thế chỉ bucket policy mới tạo ra được rào chặn theo kiểu "không đến từ đây thì từ chối".
• VPC endpoint và policy là hai việc tách biệt. Tạo endpoint chỉ mở đường đi riêng, tự nó không chặn ai truy cập bucket qua Internet. Muốn khoá lại phải thêm điều kiện so khớp VPC endpoint (aws:sourceVpce) trong bucket policy — câu trả lời đủ phải có cả hai phần.
• AWS VPN không nối tới các dịch vụ managed như S3. Thấy phương án dựng VPN tới một dịch vụ AWS là có thể loại ngay.

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

Đề mô tả một công ty có nhiều tài khoản AWS được quản lý chung trong một organization của AWS Organizations, vừa gộp thêm 10 tài khoản nữa. SysOps administrator phải gom (aggregate) cảnh báo từ AWS Health Dashboard của từng tài khoản về một chỗ để xem.

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

• "part of an organization within AWS Organizations" — đã có sẵn quan hệ tổ chức giữa các tài khoản. Đây chính là điều kiện tiên quyết để dùng được tính năng gom dữ liệu Health ở cấp organization; nếu các tài khoản rời rạc thì câu trả lời sẽ khác hẳn.
• "the most efficient approach" — đề không hỏi "cách nào chạy được", mà hỏi cách tốn ít công nhất. Cả bốn phương án đều có thể ra được kết quả gom cảnh báo ở mức nào đó; thứ phân biệt chúng là lượng code phải viết, hạ tầng phải dựng và công bảo trì về sau. Thêm nữa, "recently integrated 10 more accounts" ngầm nhắc rằng số tài khoản còn tăng — giải pháp nào phải cấu hình lặp lại trên từng tài khoản sẽ càng ngày càng đắt.

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

C — Activate organizational view in AWS Health.

AWS Health có sẵn chế độ organizational view: bật lên từ tài khoản quản lý (management account) của organization, và từ đó Health Dashboard hiển thị sự kiện của toàn bộ tài khoản thành viên trong một giao diện duy nhất, thay vì phải đăng nhập lần lượt vào từng tài khoản. Đúng như phần giải thích nguồn nêu: đây là cách gom sự kiện Health của mọi tài khoản trong organization về một nơi với công sức ít nhất.

Điểm mạnh của nó khớp trọn vẹn với đề:

• Là tính năng có sẵn, chỉ cần bật — không phải viết code, không dựng thêm database, không quản lý hạ tầng.
• Hoạt động ở cấp organization, nên 10 tài khoản mới gộp vào sẽ được bao phủ mà không cần cấu hình riêng cho từng cái. Đây là điều đáng nhớ nhất khi so với các phương án phải làm thủ công trên mỗi account.
• Vẫn truy cập được theo hai đường: giao diện AWS Health Dashboard và AWS Health API cho các thao tác phạm vi organization.

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

A — Lambda gọi AWS Health API rồi ghi sự kiện vào Amazon Aurora.

Đây là phương án về mặt kỹ thuật thì làm được, và cũng là phương án dễ chọn nhầm nhất vì nghe rất "kỹ sư". Nhưng nó hỏng ở đúng tiêu chí đề nêu — most efficient: phải viết Lambda function, thiết kế schema, vận hành một cụm Aurora, xử lý phân trang khi gọi API, lo lỗi và retry, rồi bảo trì tất cả những thứ đó về lâu dài. Bạn tự dựng lại bằng tay đúng thứ AWS Health đã cung cấp sẵn qua một nút bật, cộng thêm chi phí chạy Aurora liên tục.

B — Dùng AWS Health API để ghi sự kiện vào một S3 bucket.

Cũng là giải pháp tự xây, chỉ khác chỗ lưu trữ: nhẹ hơn A vì S3 rẻ và không phải quản lý database, nhưng bản chất vấn đề không đổi — vẫn phải có thành phần chủ động gọi API, lên lịch chạy, xử lý lỗi, rồi tự dựng cách đọc/hiển thị dữ liệu đã đổ ra S3. Vẫn nhiều việc hơn hẳn so với việc bật organizational view. Ngoài ra, dữ liệu nằm thô trong bucket không cho bạn cái mà administrator thực sự cần: một dashboard xem được ngay.

D — Cấu hình CloudWatch Events ở từng tài khoản để bắt sự kiện Health và chuyển về CloudWatch Logs tập trung.

Phương án này sai ở hai tầng. Thứ nhất, theo giải thích nguồn, sự kiện AWS Health không chuyển thẳng sang CloudWatch Logs được — nên đường ống mô tả trong đáp án không dựng đúng như câu chữ. Thứ hai, kể cả bỏ qua chi tiết đó, phương án yêu cầu cấu hình lặp lại trên mỗi tài khoản: 10 tài khoản mới gộp vào là 10 lần cấu hình nữa, và mỗi tài khoản tương lai lại thêm một lần. Đó chính xác là kiểu công việc mà organizational view sinh ra để loại bỏ, nên nó thua ở tiêu chí "most efficient" ngay cả khi chạy được.

📌 Điểm cần nhớ

• Khi đề nhắc AWS Organizations kèm nhu cầu "gom/xem tập trung", hãy tìm trước tính năng có sẵn ở cấp organization của chính dịch vụ đó — với AWS Health đó là organizational view.
• Cụm "most efficient" / "least effort" / "least operational overhead" là tiêu chí loại: phương án tự viết Lambda + tự lưu vào Aurora/S3 gần như luôn thua một tính năng bật-là-xong, dù nó chạy được.
• Cảnh giác với mọi phương án có chữ "in each account" (cấu hình trên từng tài khoản). Trong bối cảnh số tài khoản đang tăng, đó là dấu hiệu của giải pháp không mở rộng được.
• AWS Health API tồn tại thật và dùng được, nhưng trong bài thi nó là công cụ để tự động hoá, không phải câu trả lời cho nhu cầu "chỉ cần nhìn thấy tất cả ở một chỗ".

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

Đề bài mô tả một người quản lý muốn xem chi phí trong một AWS account, tách nhỏ theo từng project, và muốn xem ngay trong AWS Cost Explorer. Câu hỏi yêu cầu chọn HAI thay đổi cấu hình.

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

• "in an AWS account" (số ít) — toàn bộ câu chuyện nằm gọn trong một tài khoản. Mọi phương án nói về việc gộp nhiều tài khoản lập tức lệch đề.
• "on a project by project basis" — "project" không phải là một khái niệm có sẵn trong hoá đơn AWS. AWS chỉ biết service, region, resource, account… Muốn hoá đơn hiểu được "project" thì phải tự gắn nhãn cho resource. Đây chính là ràng buộc dẫn thẳng tới tag.
• "view this information in Cost Explorer" — yêu cầu là xem/phân tích chi phí, không phải cảnh báo khi vượt ngân sách, không phải ghi log truy cập.

Ghép lại: cần một chiều (dimension) mới trong dữ liệu chi phí tên là "project". Con đường duy nhất là tag, và tag đó phải đi qua hai bước tách bạch — đúng bằng số phương án đề yêu cầu chọn.

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

Đáp án theo tệp là B và E, và hai phương án này là hai nửa bắt buộc của cùng một quy trình:

B — Create and apply resource tags. Tag là cặp key-value (ví dụ Project = Alpha) gắn lên chính các resource. Đây là bước tạo ra thông tin: nếu không có resource nào mang tag Project, thì Cost Explorer chẳng có gì để nhóm. Lưu ý một chi tiết mà bản giải thích gốc nhấn mạnh: tag không tự áp ngược lên resource đã tạo trước đó — resource cũ vẫn phải được gắn tag thủ công.

E — Activate cost allocation tags. Gắn tag lên resource chưa đủ. Tag key phải được kích hoạt riêng trong phần Billing/Cost Management thì nó mới trở thành một chiều lọc/nhóm trong Cost Explorer và trong báo cáo phân bổ chi phí. Đây là bước biến metadata quản trị thành metadata tính tiền.

Nói cách khác: B tạo dữ liệu, E mở đường cho dữ liệu đó chảy vào Cost Explorer. Bỏ bước nào cũng ra kết quả rỗng — thiếu B thì tag key không có giá trị nào để nhóm, thiếu E thì tag tồn tại nhưng Cost Explorer không nhìn thấy. Chính vì thế đề bài mới hỏi "combination" và yêu cầu chọn TWO.

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

A — Activate consolidated billing. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì nó đúng là một tính năng thuộc mảng quản lý chi phí. Nhưng consolidated billing giải quyết bài toán gộp nhiều account vào một hoá đơn duy nhất, tức là chia chi phí theo account. Đề bài chỉ có một account và muốn chia theo project — hai trục hoàn toàn khác nhau. Kể cả khi bật, nó không tạo ra bất kỳ chiều "project" nào trong Cost Explorer.

C — Enable server access logging. Đây là tính năng của Amazon S3, ghi lại các request truy cập vào bucket và object. Nó thuộc mảng audit / bảo mật / phân tích truy cập, không sinh ra dữ liệu chi phí và không xuất hiện trong Cost Explorer dưới bất kỳ dạng nào. Phương án này lạc hẳn chủ đề.

D — Enable AWS Budgets. Cũng là dịch vụ trong mảng cost management nên trông hợp lý, nhưng sai ở mục đích: Budgets dùng để đặt ngưỡng ngân sách và gửi thông báo khi chi phí có nguy cơ vượt ngưỡng. Đó là hành động phản ứng với chi phí, còn đề bài yêu cầu xem và bóc tách chi phí. Ngoài ra, Budgets tự nó không hề tạo ra khái niệm "project" — muốn đặt budget riêng cho từng project thì vẫn phải có cost allocation tag trước đã. Nó là hệ quả có thể làm sau, không phải điều kiện cần.

📌 Điểm cần nhớ

• Bất cứ khi nào đề hỏi bóc tách chi phí theo một chiều do người dùng tự định nghĩa (project, team, department, environment, cost center), câu trả lời gần như chắc chắn là tag. AWS không có sẵn những chiều này.
• Tag phục vụ billing luôn là hai bước: gắn tag lên resource, rồi kích hoạt tag key trong phần Cost Allocation Tags. Đề dạng "Select TWO" rất hay khai thác đúng cặp này.
• Phân biệt vai trò trong nhóm dịch vụ chi phí: Cost Explorer để xem/phân tích, AWS Budgets để cảnh báo khi vượt ngưỡng, consolidated billing để gộp hoá đơn nhiều account. Đề hỏi "view/breakdown" thì chọn nhánh Cost Explorer + tag.
• Đọc kỹ số lượng account trong đề: "an AWS account" (một) loại ngay các phương án xoay quanh nhiều tài khoản như consolidated billing.
• Tag không hồi tố — resource tạo trước khi tag ra đời sẽ không tự có tag, và chi phí phát sinh trước thời điểm kích hoạt tag cũng không được gán nhãn lại.

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

Đề mô tả một dịch vụ chạy ở nhiều Region, mỗi Region có một Auto Scaling group đứng sau một Application Load Balancer (ALB) riêng, và hỏi cấu hình Route 53 nào thoả hai yêu cầu cùng lúc.

Hai cụm từ quyết định nằm ở câu cuối phần mô tả:

• "guide users towards the Region closest to them" → đây là yêu cầu về routing policy, tức chọn chính sách định tuyến của Route 53 dựa trên vị trí người dùng.
• "while also supporting automated failover" → đây là yêu cầu về health check + DNS failover, tức Route 53 phải tự biết Region nào hỏng để ngừng trả bản ghi đó.

Vì là câu Select TWO, mỗi đáp án đúng lo một vế: một đáp án về routing policy, một đáp án về health check. Cụm thứ ba cần chú ý là "an ALB per region" — nó nói cho ta biết điểm vào của mỗi Region là ALB chứ không phải một EC2 instance cụ thể, và đó chính là thứ dùng để phân biệt A với B và D.

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

A — CloudWatch alarm theo dõi ALB ở mỗi Region + Route 53 DNS failover với health check gắn vào alarm đó. ALB là điểm đại diện cho toàn bộ Region: phía sau nó là Auto Scaling group với số lượng instance thay đổi liên tục. Theo dõi ALB nghĩa là theo dõi đúng thứ mà người dùng thực sự truy cập, và một EC2 instance đơn lẻ chết cũng không làm cả Region bị đánh dấu hỏng — Auto Scaling sẽ thay thế nó. Route 53 hỗ trợ loại health check "state of CloudWatch alarm", nên gắn health check vào alarm rồi bật DNS failover cho phép Route 53 tự động ngừng trả về Region hỏng. Đó chính là phần "automated failover".

E — Route 53 geolocation routing, khai báo Region tương ứng với hạ tầng. Geolocation routing chọn bản ghi trả về dựa trên vị trí địa lý của người truy vấn, nên người dùng ở châu Âu nhận endpoint châu Âu, người dùng ở châu Á nhận endpoint châu Á. Đó đúng là yêu cầu "hướng người dùng tới Region gần họ nhất" mà đề nêu.

Kết hợp A + E: geolocation quyết định gửi đi đâu, health check + failover quyết định có được gửi tới đó nữa hay không.

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

B — CloudWatch alarm theo dõi tình trạng các EC2 instance ở từng Region. Đây là phương án gần đúng nhất, và nó hỏng ở đối tượng bị theo dõi. Instance nằm trong Auto Scaling group nên chúng được tạo ra và bị huỷ liên tục; một alarm buộc vào tập instance là thứ vừa khó giữ đúng vừa gây báo động giả — một instance bị thay thế theo đúng thiết kế cũng có thể kích hoạt failover cả Region. Ngược lại, ALB mới là thành phần phân phối lưu lượng tới các instance đó, nên tình trạng của ALB mới phản ánh đúng việc Region còn phục vụ được hay không. Ý tưởng (CloudWatch alarm + Route 53 health check) là đúng; chỉ chọn sai chỗ để đo.

C — Weighted routing, khai báo continent / country / state. Phương án này tự mâu thuẫn: weighted routing chia lưu lượng theo tỷ trọng số do bạn đặt, hoàn toàn không quan tâm người dùng ở đâu — nó dùng cho thử nghiệm A/B hoặc dịch chuyển dần lưu lượng. Việc liệt kê châu lục / quốc gia / bang lại là cách khai báo của geolocation routing, tức là mô tả một chính sách khác với chính sách được nêu tên. Và bản thân weighted routing cũng không đáp ứng vế "closest Region".

D — Health check theo dõi private IP của một EC2 instance trong mỗi Region. Sai ở hai tầng. Thứ nhất, health check của Route 53 xuất phát từ các checker ngoài Internet, nên địa chỉ private IP không tiếp cận được từ ngoài VPC. Thứ hai, kể cả có tiếp cận được thì nó chỉ đo một instance, trong khi yêu cầu là failover ở mức Region — một instance khoẻ không có nghĩa là Region còn phục vụ được, và ngược lại. Ngoài ra phương án này chỉ giải quyết vế failover, hoàn toàn không nói gì tới việc định tuyến theo vị trí người dùng.

📌 Điểm cần nhớ

• Câu hỏi Route 53 thường tách làm hai vế: routing policy (gửi đi đâu) và health check + failover (khi hỏng thì sao). Đọc đề, khoanh riêng từng vế rồi chọn một đáp án cho mỗi vế.
• Geolocation định tuyến theo vị trí người truy vấn; weighted chia theo tỷ trọng số và không biết gì về địa lý. Đáp án nào ghép tên chính sách này với cách khai báo của chính sách kia là đáp án nhiễu kinh điển.
• Health check nên trỏ vào điểm vào ổn định của kiến trúc (ALB), không trỏ vào thành phần bị Auto Scaling thay thế liên tục (EC2 instance).
• Route 53 health check chạy từ ngoài Internet, nên mọi mục tiêu chỉ có private IP đều là đáp án sai — muốn dùng, phải qua loại health check dựa trên trạng thái CloudWatch alarm.

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

Đề mô tả một công ty dùng AWS Organizations với consolidated billing cho nhiều tài khoản. CEO thấy chi phí tăng và yêu cầu SysOps Administrator tìm ra nguyên nhân gây tăng.

Cụm từ quyết định đáp án là "MOST comprehensive tool" đi kèm với "determine what is causing the increase". Hai vế này phải đọc chung với nhau:

• "what is causing the increase" — cần phân tích dữ liệu chi phí theo thời gian, chia nhỏ theo dịch vụ / tài khoản / khu vực để thấy khoản nào phình lên. Đây là việc báo cáo và phân tích, không phải việc gắn nhãn hay khuyến nghị.
• "MOST comprehensive" — trong bốn phương án có những thứ góp phần vào việc theo dõi chi phí, nhưng chỉ một thứ tự nó là công cụ phân tích đầy đủ. Từ "most comprehensive" chính là cái loại bỏ các phương án chỉ giải quyết một mảnh của bài toán.

Bối cảnh consolidated billing cũng là gợi ý: dữ liệu chi phí của tất cả tài khoản thành viên được gom về tài khoản quản lý, nên cần công cụ đọc được bức tranh chi phí gộp đó.

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

A — AWS Cost Explorer.

Cost Explorer là công cụ để xem và phân tích chi phí cùng mức sử dụng. Nó cung cấp biểu đồ chính, các báo cáo cost and usage, và báo cáo về Reserved Instances.

Nó khớp đúng yêu cầu của đề:

• Xem được dữ liệu của khoảng thời gian đã qua (theo tài liệu là tới 12 tháng gần nhất), nên so sánh được kỳ này với kỳ trước — chính là cách phát hiện khoản nào tăng.
• Dự báo mức chi cho giai đoạn sắp tới, giúp trả lời câu hỏi của CEO không chỉ ở hiện tại.
• Đưa ra khuyến nghị mua Reserved Instances.
• Quan trọng nhất với đề này: dùng để khoanh vùng những chỗ cần đào sâu thêm và nhìn ra xu hướng để hiểu chi phí của mình.

Với consolidated billing, tài khoản quản lý trong AWS Organizations dùng Cost Explorer để nhìn xuyên suốt chi phí của các tài khoản thành viên — đúng nghĩa "comprehensive" mà đề đòi.

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

B — AWS Trusted Advisor. Đây là phương án gần đúng nhất và dễ chọn nhầm, vì Trusted Advisor có hẳn một nhóm kiểm tra về cost optimization (tài nguyên nhàn rỗi, tận dụng chưa hết…). Chỗ nó hỏng: Trusted Advisor đưa ra hướng dẫn thời gian thực theo best practice, tức là gợi ý "bạn nên sửa chỗ này" — nó không cho cái nhìn về từng khoản chi phí để theo dõi. CEO hỏi "chi phí tăng vì cái gì", cần một biểu đồ chi tiêu theo thời gian bóc tách được, chứ không phải một danh sách khuyến nghị tối ưu. Trusted Advisor là công cụ cải thiện, Cost Explorer là công cụ chẩn đoán.

C — Resource groups. Resource groups chỉ để gom nhóm tài nguyên lại theo tiêu chí nào đó cho tiện quản lý và thao tác. Nó không có phần báo cáo chi phí mà đề yêu cầu. Gom nhóm xong vẫn không biết nhóm đó tốn bao nhiêu, và càng không biết tháng này tốn hơn tháng trước bao nhiêu.

D — Cost allocation tags. Phương án này có dính tới chi phí nên cũng gây phân vân. Cost allocation tags hữu ích để theo dõi mức sử dụng và chi phí gắn với từng tài nguyên riêng lẻ. Nhưng bản thân tag chỉ là dữ liệu phân loại đầu vào — nó gắn nhãn để chi phí có thể được nhóm lại, chứ tự nó không phải công cụ phân tích và không vẽ ra xu hướng. Muốn thấy chi phí theo tag, vẫn phải mở một công cụ báo cáo. Vì vậy nó là một mảnh của giải pháp, không phải "the MOST comprehensive tool". Thêm nữa, tag chỉ có tác dụng từ lúc được bật và áp dụng, nên nó không tự động giải thích được phần chi phí đã phát sinh trước đó.

📌 Điểm cần nhớ

• Câu hỏi kiểu "chi phí tăng vì đâu / phân tích xu hướng chi tiêu / dự báo chi phí" → AWS Cost Explorer. Đây là phản xạ mặc định cho nhóm câu về AWS Cost Management.
• Phân biệt vai trò: Cost Explorer = phân tích và báo cáo chi phí; Trusted Advisor = khuyến nghị best practice (bao gồm tiết kiệm chi phí) chứ không phải công cụ theo dõi chi tiêu; Cost allocation tags = cơ chế gắn nhãn để phân loại chi phí; Resource groups = gom nhóm tài nguyên để quản lý, không liên quan tới báo cáo chi phí.
• Từ khoá "MOST comprehensive" trong đề thường loại các phương án chỉ là một thành phần hỗ trợ (tag, group) và giữ lại công cụ đứng một mình đã giải quyết trọn bài toán.
• Với AWS Organizations + consolidated billing, dữ liệu chi phí của các tài khoản thành viên được nhìn từ tài khoản quản lý — nên hãy chọn công cụ đọc được bức tranh nhiều tài khoản, đừng chọn thứ chỉ soi được một tài nguyên đơn lẻ.

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

Đề mô tả một công ty dùng AWS CloudFormation để triển khai hạ tầng bằng template, và việc triển khai trải qua nhiều environment ở nhiều Region khác nhau. Câu hỏi yêu cầu chọn cách làm được khuyến nghị để đạt yêu cầu đó.

Cụm từ quyết định nằm ở câu: "plans to write a single template that can be reused for each environment deployment" — một template duy nhất, dùng lại được cho từng environment.

Hai chi tiết này khoá chặt đáp án:

• "a single template" loại ngay mọi giải pháp phải tách ra nhiều template hoặc nhiều stack.
• "reused for each environment" nghĩa là nội dung template giữ nguyên, chỉ có giá trị đầu vào thay đổi theo từng môi trường (dev, staging, prod) và từng Region.

Vấn đề thực chất mà đề đặt ra là: làm sao tham số hoá các khác biệt giữa các môi trường (loại instance, kích thước, tên, AMI theo Region…) mà không phải sửa hoặc nhân bản template.

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

D — Use parameters to provision the resources.

Section Parameters của CloudFormation cho phép khai báo các giá trị đầu vào và truyền vào mỗi lần tạo hoặc cập nhật stack. Trong template, ta tham chiếu tới chúng bằng hàm nội tại Ref (dùng được ở cả section Resources lẫn Outputs), và CloudFormation lấy giá trị được truyền vào để provision stack.

Đây đúng là cơ chế biến một template thành template dùng lại được: cùng một file, chạy cho dev thì truyền vào instance type rẻ tiền, chạy cho production thì truyền vào instance type lớn hơn, còn toàn bộ cấu hình và thiết lập khác giữ nguyên. Parameters thường đi kèm Mappings và Conditions — ba thứ này là bộ công cụ chuẩn để tuỳ biến stack lúc tạo, và cũng chính là điều tài liệu best practices của CloudFormation nói tới ở mục tái sử dụng template.

Với yêu cầu nhiều Region, Parameters (kết hợp Mappings) cũng là cách xử lý những giá trị vốn khác nhau theo Region, ví dụ AMI ID.

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

A — Use change sets to provision additional environments. Sai vì change set không phải công cụ triển khai môi trường mới. Change set chỉ giúp xem trước những thay đổi sẽ xảy ra trước khi bạn thực sự update một stack đang tồn tại — nó là bước kiểm tra an toàn khi sửa stack, không liên quan gì tới việc làm cho template tái sử dụng được cho nhiều environment.

B — Use nested stacks to provision the resources. Đây là phương án gần đúng nhất và dễ chọn nhầm, vì nested stacks thật sự có liên quan tới tái sử dụng. Nhưng nó hỏng ở đúng chỗ ràng buộc của đề: nested stacks phục vụ việc định nghĩa các mẫu dùng chung nằm ở những template riêng biệt — tức là bạn phải có nhiều template, một stack cha gọi các stack con. Đề lại nói rõ quản trị viên muốn viết một template duy nhất. Nested stacks giải quyết bài toán "tái sử dụng một khối tài nguyên giữa nhiều template", còn bài toán ở đây là "tái sử dụng cùng một template cho nhiều môi trường" — hai chuyện khác nhau, và cái sau thuộc về Parameters, Mappings, Conditions.

C — Use cross-stack references to provision the resources. Sai vì cross-stack reference chỉ là cách export giá trị đầu ra từ một stack để stack khác dùng lại (Export trong Outputs và Fn::ImportValue ở phía nhận). Nó giải quyết chuyện chia sẻ tài nguyên giữa các stack — ví dụ stack mạng export VPC ID cho stack ứng dụng — chứ không làm cho một template tuỳ biến được theo từng environment. Ngoài ra bản thân cơ chế export/import cũng lại đòi hỏi nhiều stack, đi ngược yêu cầu "một template" của đề.

📌 Điểm cần nhớ

• Parameters = tuỳ biến một template cho nhiều môi trường. Thấy đề nói "single template", "reusable", "same template for dev/test/prod" thì nghĩ ngay tới Parameters, thường đi kèm Mappings và Conditions.
• Nested stacks = tái sử dụng một khối tài nguyên giữa các template khác nhau. Nó cần nhiều template, nên bất kỳ đề nào nhấn mạnh "một template duy nhất" là nested stacks bị loại, dù nghe cũng có mùi "reuse".
• Cross-stack references = chia sẻ giá trị giữa các stack qua Export/Fn::ImportValue, dùng khi tài nguyên của stack này cần được stack khác tham chiếu — không phải công cụ tham số hoá.
• Change sets = xem trước thay đổi trước khi update stack. Đây là cơ chế an toàn khi vận hành, không bao giờ là đáp án cho câu hỏi về thiết kế hay tái sử dụng template.

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

Đề mô tả một ứng dụng nội bộ chạy trên các EC2 instance đứng sau một Application Load Balancer (ALB), và việc xác thực người dùng được xử lý ngay tại từng EC2 instance chứ không phải ở tầng tập trung nào. Câu hỏi yêu cầu chọn tính năng của Elastic Load Balancing để điều khiển hành vi được mô tả.

Cụm từ quyết định nằm ở câu: "Once a user is authenticated; all requests from that user must go to the same EC2 instance." — mọi request tiếp theo của cùng một người dùng phải rơi trúng đúng instance đã xác thực họ. Cụm này nói lên rằng ứng dụng stateful: trạng thái phiên đăng nhập nằm trong bộ nhớ của một instance cụ thể, không chia sẻ sang instance khác. Cần một cơ chế ràng buộc client ↔ target, chứ không phải cơ chế phân phối tải hay cơ chế rút target ra khỏi vòng phục vụ.

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

C — Sticky sessions đúng theo tệp. Sticky sessions (session affinity) là cơ chế của Elastic Load Balancing dùng để định tuyến các request của cùng một client tới cùng một target trong target group. Đây chính xác là thứ ứng dụng giữ trạng thái cần, để người dùng có trải nghiệm liền mạch sau khi đã xác thực.

Cách hoạt động: bật stickiness ở cấp target group, load balancer phát một cookie cho client; các request sau mang cookie đó và ALB dựa vào nó để gửi về đúng target cũ. Vì cơ chế dựa trên cookie nên client bắt buộc phải hỗ trợ cookie. Thời hạn của cookie do load balancer sinh ra có thể cấu hình, và thời hạn được đặt lại theo mỗi request — nghĩa là chừng nào client còn gửi request trước khi hết hạn thì phiên dính vẫn tiếp tục.

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

A — Cross-zone load balancing: đây là tính năng phân phối request đều ra các target ở nhiều Availability Zone, thay vì chỉ chia đều theo AZ rồi mới chia trong AZ. Nó liên quan tới cách rải tải, hoàn toàn không ràng buộc một người dùng với một instance. Bật nó lên còn khiến request của người dùng có khả năng đi lung tung sang AZ khác nhiều hơn, tức là đi ngược yêu cầu của đề.

B — Deregistration delay: đây là khoảng thời gian load balancer ngừng gửi request mới tới target đang được gỡ đăng ký (deregistering) và chờ các kết nối đang mở kết thúc. Đây là phương án dễ nhầm nhất vì nó cũng đụng tới chuyện "kết nối đang dở không bị cắt", nhưng nó chỉ áp dụng trong quá trình rút một target ra khỏi target group, và nó không có bất kỳ khái niệm nào về người dùng nào thuộc về instance nào trong lúc hệ thống chạy bình thường.

D — TCP listeners: listener kiểu TCP dùng với Network Load Balancer để lắng nghe yêu cầu kết nối ở tầng 4. Nó chỉ là cấu hình cổng/giao thức mà load balancer tiếp nhận, không quyết định request đi tới target nào. Ngoài ra đề đang nói tới ALB — vốn làm việc ở tầng HTTP/HTTPS — nên nhắc tới TCP listener đã lệch loại load balancer.

📌 Điểm cần nhớ

• Đề bài nói "cùng một người dùng phải về cùng một instance/server" hay "ứng dụng giữ session tại chỗ" → nghĩ ngay tới sticky sessions / session affinity.
• Sticky sessions cấu hình ở target group, không phải ở listener hay ở load balancer nói chung; cơ chế dựa trên cookie nên client phải chấp nhận cookie.
• Phân biệt rõ ba nhóm tính năng của ELB: cross-zone load balancing = rải tải giữa các AZ, deregistration delay = xử lý êm khi rút target ra, sticky sessions = ràng buộc client với target. Chúng giải quyết ba bài toán khác nhau.
• Listener quyết định load balancer nghe cái gì, không quyết định request đi về đâu; TCP listener còn gắn với NLB chứ không phải ALB.