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

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

Đề mô tả một SysOps administrator thấy lượng request bất thường tới ứng dụng chạy sau Application Load Balancer (ALB), và muốn xác định địa chỉ IP của các client đã truy cập vào ALB. Câu hỏi yêu cầu chọn loại log nào chứa được thông tin đó.

Cụm từ quyết định là "identify the IP addresses of the clients that accessed the ALB". Ở đây có hai ràng buộc chồng lên nhau:

• "IP addresses of the clients" — cần dữ liệu ở mức từng request của người dùng cuối, chứ không phải sự kiện quản trị hay chỉ số tổng hợp.
• "that accessed the ALB" — điểm quan sát nằm ngay tại load balancer. Đây là chi tiết dễ bỏ qua: ALB kết thúc kết nối của client rồi mở kết nối mới tới target, nên IP thật của client chỉ được nhìn thấy đầy đủ ở tầng ALB. Cái gì chạy phía sau ALB thì không còn nhìn thấy IP đó một cách tự nhiên nữa.

Ghép hai ràng buộc lại, đáp án phải là loại log do chính load balancer sinh ra, ghi theo từng request.

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

A — Elastic Load Balancer access logs.

Elastic Load Balancing có tính năng access logs ghi lại thông tin chi tiết về từng request gửi tới load balancer. Mỗi bản ghi chứa những trường như thời điểm nhận request, địa chỉ IP của client, độ trễ (latency), đường dẫn của request và mã phản hồi mà server trả về.

Đúng chính xác nhu cầu trong đề: administrator muốn biết ai đang gửi lượng request bất thường, thì access logs cho ra danh sách IP client kèm đường dẫn và thời điểm — đủ để phân tích mẫu lưu lượng (traffic patterns) và khoanh vùng nguồn gây tải. Đây cũng là công cụ chuẩn để troubleshoot các vấn đề ở tầng ALB.

Access logs là tính năng tuỳ chọn, phải bật trên load balancer; khi bật, các tệp log được ghi ra một bucket S3 do bạn chỉ định.

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

B — Amazon CloudWatch Logs. Đây là phương án gần đúng nhất và cũng là bẫy chính. CloudWatch Logs là nơi chứa log của ứng dụng và của hệ điều hành trên EC2 instance — tức là những gì nằm phía sau ALB. Mà như đã nói ở phần phân tích, thông tin IP của client phải được ghi lại tại tầng ALB, trước khi lưu lượng được chuyển tiếp xuống các EC2 instance. Bản thân CloudWatch Logs không tự động thu thập IP client của ALB; nó chỉ là kho log, không phải nguồn sinh ra dữ liệu này.

C — EC2 Auto Scaling logs. Auto Scaling ghi log thông qua CloudWatch Logs, và nội dung của nó xoay quanh hoạt động co giãn nhóm instance — thêm/bớt instance, kết quả health check, lý do một scaling activity xảy ra. Không có bản ghi nào ở mức từng request của người dùng, nên không hề ghi lại địa chỉ IP của client. Nó trả lời câu hỏi "nhóm instance đã tăng giảm ra sao", không phải "ai đã gọi vào".

D — AWS CloudTrail logs. Cũng gần đúng theo cảm giác, vì CloudTrail thật sự có ghi trường IP nguồn — nhưng đó là IP của người/ứng dụng gọi API của AWS. CloudTrail ghi hoạt động API: ai tạo load balancer, ai sửa target group, ai đổi security group. Lưu lượng HTTP của người dùng cuối đi qua ALB không phải là lời gọi API AWS, nên không xuất hiện trong CloudTrail. Dùng CloudTrail ở đây là nhầm giữa "ai thao tác lên tài nguyên" và "ai truy cập vào ứng dụng".

📌 Điểm cần nhớ

• Đọc kỹ điểm quan sát trong đề. "Accessed the ALB" nghĩa là dữ liệu phải lấy ở tầng load balancer; thứ gì chạy sau ALB đều đã mất tầm nhìn trực tiếp về IP client vì ALB kết thúc kết nối của client và mở kết nối mới tới target.
• ELB access logs = log theo từng request: thời điểm, IP client, latency, request path, mã phản hồi. Đây là câu trả lời mặc định cho mọi câu hỏi kiểu "ai đã gọi vào ứng dụng qua load balancer".
• CloudTrail ≠ access log. CloudTrail trả lời "ai gọi API AWS lên tài nguyên"; access logs trả lời "ai gửi request vào ứng dụng". Thấy đề nói về lưu lượng người dùng cuối thì loại CloudTrail ngay.
• CloudWatch Logs là kho chứa, không phải nguồn. Nó chỉ có những gì được đẩy vào (log ứng dụng, log hệ điều hành, log của Auto Scaling); không tự sinh ra dữ liệu request ở tầng ALB.
• Access logs của ELB là tuỳ chọn phải bật trước, ghi ra S3 — nếu đề hỏi "vì sao không thấy log", hãy nghĩ tới việc tính năng này chưa được bật.

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

Đề mô tả một ứng dụng web stateful chạy trên fleet EC2 phía sau Application Load Balancer, và ALB này lại là origin của một CloudFront distribution. Triệu chứng: người dùng vừa đăng nhập xong nhưng thỉnh thoảng bị bắt đăng nhập lại.

Cụm từ quyết định là "stateful" cộng với "sometimes asked to re-authenticate". Stateful nghĩa là phiên đăng nhập được giữ trên chính instance đang phục vụ, chứ không nằm ở một kho dùng chung. Vì vậy nếu request kế tiếp của cùng một người rơi sang instance khác, instance đó không biết gì về phiên đã có và bắt đăng nhập lại. Chữ "sometimes" cũng rất quan trọng: nếu là lỗi cấu hình xác thực thì phải hỏng mọi lần; hỏng lúc được lúc không đúng là dấu hiệu của việc request bị phân phối sang nhiều target khác nhau.

Chi tiết thứ hai là CloudFront nằm trước ALB. Đây là lý do câu này cần hai hành động chứ không phải một: một ở tầng ALB và một ở tầng CloudFront.

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

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

E — Enable sticky sessions on the ALB target group. Sticky sessions (session affinity) khiến ALB sinh ra một cookie do load balancer quản lý, lưu trên client, để trói client đó vào đúng một EC2 instance trong target group. Với ứng dụng stateful, đây chính là thứ đảm bảo mọi request của một phiên đều quay về instance đang giữ session, nên người dùng không bị mất trạng thái đăng nhập. Lưu ý cấu hình này bật ở cấp target group, đúng như phương án E ghi.

A — Configure the cache behavior to forward cookies. Cơ chế ở E hoàn toàn dựa trên cookie. Nhưng khi có CloudFront đứng trước, mặc định CloudFront không chuyển tiếp cookie xuống origin. Cookie stickiness vì thế bị chặn lại ở tầng CDN, ALB không nhận được nó và coi mỗi request như một client mới → phân phối lại sang instance khác → người dùng bị đăng nhập lại. Sửa cache behavior để forward cookies tới origin là mảnh ghép còn thiếu.

Hai hành động này phụ thuộc nhau: bật E mà không làm A thì cookie không bao giờ tới được ALB; làm A mà không bật E thì chẳng có cookie stickiness nào để chuyển tiếp.

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

B — Configure the cache behavior to forward headers. Đây là phương án gần đúng nhất và cũng là bẫy chính: nó cùng ở tầng CloudFront, cùng là "forward something to origin". Nhưng cơ chế sticky sessions của ALB được hiện thực bằng cookie, không phải header. Forward headers có ích cho những chuyện khác (thay đổi nội dung theo host, theo thiết bị, theo Accept-*…), nhưng nó không mang cookie stickiness đi qua CloudFront, nên triệu chứng vẫn y nguyên.

C — Enable the slow start duration on the ALB target group. Slow start là tính năng cho target mới đăng ký: trong khoảng thời gian cấu hình, target đó nhận dần dần một tỷ lệ request tăng lên cho tới khi bằng phần chia công bằng, để nó kịp khởi động/nạp cache. Đây thuần tuý là chuyện làm ấm target mới, không hề ràng buộc một client vào một instance cụ thể. Bật nó lên thì phiên đăng nhập vẫn văng lung tung như cũ.

D — Enable group-level stickiness on the ALB listener rule. Cũng là bẫy vì có đúng chữ "stickiness". Nhưng group-level stickiness áp dụng khi một listener rule forward tới nhiều target group: nó đảm bảo các request tiếp theo đi về cùng một target group, chứ không đảm bảo về cùng một instance bên trong group đó. Với ứng dụng stateful giữ session trên từng máy, dính đúng group là chưa đủ — request vẫn có thể rơi sang instance khác trong chính group ấy và session vẫn mất. Ngoài ra đề cũng chỉ mô tả một fleet EC2 duy nhất, không nói tới nhiều target group.

📌 Điểm cần nhớ

• "Stateful" + "thỉnh thoảng phải đăng nhập lại" gần như luôn là bài toán session affinity, không phải bài toán xác thực. "Thỉnh thoảng" chứ không phải "luôn luôn" là dấu hiệu request đang bị rải sang nhiều target.
• Sticky sessions của ALB chạy bằng cookie, bật ở target group. Thấy phương án nói "headers" là loại ngay khi đề nói về stickiness.
• CloudFront đứng trước ALB thì mặc định không forward cookie xuống origin. Bất cứ cơ chế nào của origin dựa trên cookie đều phải chỉnh cache behavior cho phù hợp — đây là lý do những câu kiểu này hay yêu cầu chọn hai hành động: một ở CDN, một ở load balancer.
• Phân biệt ba khái niệm dễ lẫn ở ALB: sticky sessions (client ↔ target), group-level stickiness (client ↔ target group), slow start (làm ấm target mới đăng ký). Chỉ cái đầu tiên giữ được session trên một instance.

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

Đề mô tả một EC2 instance nằm trong private subnet của một VPC, và khi instance đó thử kết nối tới https://example.com thì thất bại. Câu hỏi là: SysOps administrator cần sửa gì để kết nối được.

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

• "trying to connect to" — chính instance là bên khởi tạo kết nối, đi ra ngoài. Đây là traffic outbound tính từ góc nhìn của instance, không phải traffic đi vào. Cụm này loại thẳng mọi phương án nói về rule inbound.
• "https://" — giao thức HTTPS, tức cổng đích là 443, không phải 80. Cụm này loại phương án nói về port 80.
• "security group" so với "network ACL" — đề không nói rõ tầng nào hỏng, nên phải chọn thứ chắc chắn cần có để một kết nối ra ngoài port 443 hoạt động. Security group là stateful, còn network ACL là stateless; sự khác biệt này quyết định phương án nào là điều kiện cần trực tiếp.

Lưu ý: đề chỉ hỏi sửa rule nào, không hỏi về NAT gateway hay route table — nên chỉ so sánh trong phạm vi bốn phương án đã cho.

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

Đáp án đúng là A — kiểm tra có outbound security group rule cho phép traffic ra port 443 tới 0.0.0.0/0.

Security group bao quanh instance kiểm soát cả hai chiều bằng hai bộ rule riêng: inbound và outbound. Instance đang chủ động mở kết nối HTTPS ra ngoài, nên gói tin đầu tiên đi ra là outbound tới cổng đích 443. Nếu outbound rule không cho phép port 443 tới đích ngoài Internet, gói tin bị chặn ngay tại security group và kết nối hỏng — đúng triệu chứng đề mô tả.

Vì security group là stateful, chỉ cần chiều đi được phép thì traffic phản hồi tự động được cho về, không cần khai thêm rule inbound nào cho ephemeral port. Nghĩa là rule outbound port 443 là điều kiện đủ ở tầng security group cho luồng kết nối này.

Ở đây còn có một chi tiết hay bị bỏ qua: security group mặc định của VPC cho phép toàn bộ outbound, nên nếu quản trị viên đã siết outbound lại (một việc rất thường làm để tăng bảo mật) mà quên chừa port 443 thì lỗi này xuất hiện. Đó chính là chỗ phải kiểm tra trước tiên.

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

B — outbound network ACL rule cho ephemeral ports 1024-65535 tới 0.0.0.0/0. Đây là phương án gần đúng nhất và cũng là cái bẫy chính. Network ACL là stateless, nên với một kết nối đi vào instance thì đúng là phải mở ephemeral port ở chiều outbound để traffic phản hồi quay ra được. Nhưng ở đây chiều kết nối ngược lại: instance là bên khởi tạo, nên gói đi ra mang cổng đích 443, còn ephemeral port là cổng nguồn của nó — network ACL lọc theo cổng đích, nên rule ephemeral outbound không phải thứ quyết định. (Nếu xét chiều về, ephemeral sẽ nằm ở rule inbound của NACL, mà phương án này lại ghi outbound.) Vấn đề chính vẫn là traffic ra port 443 chưa được phép, và B không giải quyết điều đó.

C — inbound security group rule cho port 443 từ 0.0.0.0/0. Rule inbound chỉ chi phối traffic đi vào instance, tức là trường hợp có ai đó bên ngoài kết nối tới instance. Trong tình huống này chẳng ai gọi vào instance cả — chính instance gọi ra ngoài. Thêm rule inbound port 443 không mở được đường ra, kết nối vẫn hỏng. Tệ hơn, mở port 443 từ 0.0.0.0/0 vào một instance trong private subnet là nới lỏng bảo mật mà chẳng đổi lấy được gì.

D — outbound network ACL rule cho port 80 tới 0.0.0.0/0. Sai ngay ở con số cổng: port 80 là HTTP, còn đề nói rõ https:// tức HTTPS trên port 443. Dù có mở đúng chiều outbound và đúng tầng NACL đi nữa, mở nhầm cổng thì traffic HTTPS vẫn bị chặn. Đây là phương án loại được nhanh nhất chỉ bằng cách đọc kỹ giao thức trong URL của đề.

📌 Điểm cần nhớ

• Xác định ai khởi tạo kết nối trước khi chọn inbound hay outbound. Instance gọi ra ngoài → rule outbound; có người gọi vào instance → rule inbound. Đọc động từ trong đề ("connect to", "access", "receive requests from") là biết ngay.
• Security group stateful, network ACL stateless. Với security group, cho phép chiều đi là traffic về tự động được chấp nhận — không cần khai ephemeral port. Chỉ khi làm việc với network ACL mới phải nghĩ tới ephemeral port 1024-65535, và khi ấy phải đặt đúng chiều.
• Cổng phải khớp giao thức trong đề. https:// → 443, http:// → 80. Nhiều câu chỉ khác nhau đúng ở con số này, và đó là toàn bộ ranh giới đúng/sai.
• Rule của network ACL và security group lọc theo cổng đích của gói tin. Cổng nguồn ephemeral là do hệ điều hành chọn ngẫu nhiên, nó chỉ trở thành cổng đích khi xét gói phản hồi ở chiều ngược lại.

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

Đề mô tả một yêu cầu tuân thủ: AWS CloudTrail phải luôn ở trạng thái bật trong tài khoản, và nếu ai đó tắt nó đi thì phải được bật lại ngay lập tức và tự động.

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

• "if it is disabled, it is immediately and automatically re-enabled" — phản ứng phải bám theo sự kiện thay đổi cấu hình, chứ không phải theo lịch. "Immediately" loại thẳng mọi cơ chế chạy định kỳ.
• "without writing any custom code" — giải pháp phải dùng thành phần dựng sẵn của AWS. Cụm này chính là ràng buộc tách hai phương án B và C, vốn giống hệt nhau ở nửa đầu (cùng dùng AWS Config rule) và chỉ khác ở cách khắc phục.

Bài toán vì thế quy về: dịch vụ nào phát hiện thay đổi cấu hình, và cơ chế nào sửa nó mà không cần code tự viết.

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

Đáp án đúng theo tệp là C — tạo AWS Config rule được kích hoạt khi cấu hình CloudTrail thay đổi, rồi áp dụng automatic remediation action AWS-ConfigureCloudTrailLogging.

AWS Config theo dõi cấu hình tài nguyên trong tài khoản và có managed rule cloudtrail-enabled để kiểm tra CloudTrail có đang bật hay không. Khi rule ở dạng configuration change, nó được đánh giá ngay lúc cấu hình thay đổi — đáp ứng đúng chữ "immediately" của đề, khác hẳn kiểu quét theo chu kỳ.

Phần khắc phục dùng automatic remediation của AWS Config, vốn chạy các Systems Manager Automation document dựng sẵn. AWS-ConfigureCloudTrailLogging là document do AWS cung cấp, làm đúng việc bật lại logging cho CloudTrail. Người quản trị chỉ cần gắn document đó vào rule như một remediation action, không viết một dòng code nào — thoả đúng ràng buộc "without writing any custom code".

Tóm lại, C ghép đủ hai vế mà đề đòi: phát hiện theo sự kiện (Config rule kiểu configuration change) + sửa bằng thành phần dựng sẵn (SSM Automation document của AWS).

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

A. EventBridge rule chạy theo lịch mỗi giờ, gọi SSM Automation document để bật CloudTrail. Phương án này đúng ở chỗ dùng SSM Automation document (không cần code), nhưng hỏng ở cơ chế kích hoạt: nó là schedule pattern, chạy theo giờ chứ không phản ứng với sự kiện. Nghĩa là CloudTrail có thể bị tắt và nằm im cho tới lần chạy kế tiếp — đúng khoảng thời gian mà kẻ tấn công cần để hành động mà không để lại dấu vết. Đề yêu cầu "immediately", nên đây là phương án gần đúng nhưng sai về độ trễ. Việc phát hiện thay đổi cấu hình là việc của AWS Config, còn EventBridge theo lịch chỉ là quét mù đều đặn.

B. AWS Config rule khi cấu hình CloudTrail thay đổi, gọi AWS Lambda để bật lại CloudTrail. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. Nửa đầu hoàn toàn chuẩn — vẫn là Config rule kiểu configuration change, vẫn phản ứng tức thì. Nhưng nửa sau bắt bạn viết một Lambda function để gọi API bật lại CloudTrail, tức là custom code — đúng thứ mà đề cấm bằng câu "without writing any custom code". Khi đã có sẵn document AWS-ConfigureCloudTrailLogging làm đúng việc đó, thêm Lambda vào chỉ là công sức thừa và thêm một thứ phải bảo trì.

D. Amazon Inspector phân tích cấu hình tài khoản rồi gọi Lambda bật lại CloudTrail. Sai ngay từ việc chọn dịch vụ. Amazon Inspector đánh giá lỗ hổng và độ lệch so với best practice trên workload (như EC2 instance), nó không phải công cụ theo dõi thay đổi cấu hình tài nguyên ở cấp tài khoản — đó là vai trò của AWS Config. Ngoài ra phương án này cũng dính lỗi giống B: vẫn phải viết Lambda, tức vẫn là custom code. Sai cả hai vế nên đây là phương án xa nhất.

📌 Điểm cần nhớ

• AWS Config = phát hiện thay đổi cấu hình; SSM Automation document = khắc phục. Cặp đôi này là mẫu chuẩn cho mọi câu hỏi kiểu "tài nguyên phải luôn ở trạng thái X, tự động sửa nếu bị đổi".
• Config rule kiểu configuration change phản ứng theo sự kiện, còn kiểu periodic hoặc EventBridge scheduled rule chạy theo chu kỳ. Thấy chữ "immediately" trong đề thì loại ngay nhóm chạy theo lịch.
• Cụm "without writing any custom code" gần như luôn dùng để loại các phương án có Lambda, và chỉ giữ lại phương án dùng managed rule hoặc AWS-provided automation document (tên bắt đầu bằng AWS-).
• Phân biệt vai trò dịch vụ: AWS Config theo dõi cấu hình tài nguyên, Amazon Inspector quét lỗ hổng trên workload. Đề nói về trạng thái bật/tắt của một dịch vụ thì đó là địa hạt của Config, không phải Inspector.

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

Đề mô tả một công ty đã xác định được năm chỉ số service quota cụ thể của AWS Trusted Advisor trong một Region, và muốn được gửi email cảnh báo khi mức sử dụng vượt 80% hạn mức.

Cụm từ quyết định đáp án nằm ở hai chỗ, phải đọc chung với nhau:

• "Trusted Advisor service quota metrics" — chữ metrics rất quan trọng. Trusted Advisor không chỉ hiển thị kết quả kiểm tra trên giao diện: kết quả các check về service limit được phát ra dưới dạng metric trong CloudWatch. Đề đã ngầm chỉ vào đúng cơ chế đó khi gọi chúng là "metrics".
• "alerted via email when usage surpasses 80%" — đây là yêu cầu về ngưỡng số học trên một metric, tức là mô tả kinh điển của một CloudWatch Alarm: metric + threshold + action.

Vậy đề không hỏi "dịch vụ nào biết được hạn mức", mà hỏi cơ chế nào biến một metric có sẵn thành email khi vượt ngưỡng. Bốn phương án đều nêu một nguồn giám sát ghép với một kênh thông báo; chỉ có một cặp đúng cả hai vế.

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

Phương án C — CloudWatch Alarms trên các service quota metric, gắn với SNS để gửi email.

CloudWatch là nơi thu thập và theo dõi metric, ghi log và đặt alarm theo ngưỡng. Các metric service limit của Trusted Advisor có mặt trong CloudWatch, nên năm chỉ số mà công ty đã chọn hoàn toàn có thể được gắn alarm riêng, mỗi alarm đặt ngưỡng ở mức 80% của hạn mức tương ứng.

Khi alarm chuyển sang trạng thái ALARM, action của nó publish một message vào SNS topic; SNS có sẵn giao thức email, chỉ cần subscribe địa chỉ email vào topic là người vận hành nhận được thư. Đây là chuỗi ghép chuẩn và được hỗ trợ trực tiếp giữa hai dịch vụ, không cần viết code trung gian:

metric (service quota) → CloudWatch Alarm (ngưỡng 80%) → SNS topic → email subscription

Đúng cả hai vế: vế giám sát có cơ chế so ngưỡng, vế thông báo có kênh email.

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

A. AWS Config + Amazon SES. Sai ngay ở vế giám sát. AWS Config dùng để đánh giá, kiểm toán cấu hình của tài nguyên AWS và kiểm tra chúng có tuân thủ quy tắc hay không — nó nhìn cấu hình của tài nguyên, chứ không phải mức tiêu thụ so với hạn mức dịch vụ. Service quota không phải một thuộc tính cấu hình mà Config theo dõi. Vế SES cũng lệch vai trò: SES là dịch vụ gửi email của ứng dụng, không phải kênh thông báo vận hành gắn sẵn vào alarm như SNS.

B. AWS Personal Health Dashboard + AWS Chatbot. Personal Health Dashboard cho biết các sự kiện phía AWS ảnh hưởng tới tài khoản của bạn (bảo trì, sự cố dịch vụ, tình trạng khả dụng nền tảng). Nó không được thiết kế để theo dõi mức sử dụng service quota, nên nguồn dữ liệu sai ngay từ đầu. Ngoài ra AWS Chatbot là kênh đẩy thông báo vào Slack / Chime, tức là kênh chat chứ không phải email — sai luôn cả yêu cầu "alerted via email".

C. Đáp án đúng, đã giải thích ở trên.

D. Trusted Advisor + SNS. Đây là phương án gần đúng nhất và là cái bẫy chính, vì chính đề bài có nhắc tên Trusted Advisor. Trusted Advisor thật sự cung cấp thông tin về service limit — vế "biết được số liệu" thì đúng. Nhưng nó hỏng ở vế kích hoạt: bản thân Trusted Advisor không có cơ chế so sánh với ngưỡng do bạn đặt rồi tự phát hành động hay thông báo, và không nối thẳng vào SNS được. Muốn có email khi vượt 80% thì vẫn phải đi qua CloudWatch để đặt alarm trên metric — tức là phương án D bỏ mất đúng mắt xích mà đề đang hỏi. So với C, D thiếu thành phần đánh giá ngưỡng.

📌 Điểm cần nhớ

• Câu hỏi dạng "cảnh báo khi vượt X%" gần như luôn quy về mẫu CloudWatch Alarm → SNS → email: CloudWatch lo phần so ngưỡng, SNS lo phần phát thông báo. Tách rõ hai vai này khi đọc phương án.
• Trusted Advisor là nguồn dữ liệu, không phải bộ kích hoạt. Nó đưa số liệu service limit ra dưới dạng metric CloudWatch; hành động tự động phải do CloudWatch Alarm phát ra.
• Phân biệt kênh thông báo: SNS là kênh thông báo vận hành, tích hợp sẵn với alarm và hỗ trợ email; SES dành cho email của ứng dụng gửi tới người dùng; AWS Chatbot đẩy vào Slack/Chime, không phải email.
• Nhớ đúng phạm vi của từng dịch vụ giám sát: AWS Config = tuân thủ cấu hình tài nguyên; Personal Health Dashboard = sự kiện và sức khoẻ của chính nền tảng AWS. Cả hai đều không theo dõi mức tiêu thụ hạn mức.

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

Đề mô tả một ứng dụng chạy trên nhiều EC2 instance trong cùng một VPC, và yêu cầu cốt lõi là "very low latency between nodes" — độ trễ rất thấp giữa các node với nhau. SysOps administrator đang thấy độ trễ inter-node không chấp nhận được và cần giảm nó xuống.

Cụm từ quyết định đáp án là "latency for inter-node communications". Đây không phải độ trễ giữa người dùng và ứng dụng, cũng không phải vấn đề thiếu công suất hay thiếu tính sẵn sàng. Nó là bài toán vị trí vật lý của các instance so với nhau bên trong hạ tầng AWS: các node càng nằm gần nhau trong cùng mạng thì đường truyền càng ngắn, băng thông giữa chúng càng cao. Ba phương án còn lại đều đụng tới cách bố trí instance ở mức logic (subnet, AZ, nhóm co giãn), chỉ một phương án tác động tới chỗ đặt thật của chúng.

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

B – Redeploy the application in a placement group là đáp án đúng.

Placement group là cơ chế cho phép bạn tác động tới cách AWS đặt một nhóm instance phụ thuộc lẫn nhau lên hạ tầng bên dưới. Có ba chiến lược:

• Cluster – gom các instance nằm sát nhau bên trong một Availability Zone. Đây chính là chiến lược dành cho workload cần hiệu năng mạng độ trễ thấp, kiểu giao tiếp node-to-node gắn kết chặt (tightly-coupled) thường thấy ở ứng dụng HPC.
• Partition – tách instance ra các phân vùng logic sao cho các nhóm ở phân vùng khác nhau không dùng chung phần cứng bên dưới; hợp với workload phân tán có nhân bản như Hadoop, Cassandra, Kafka.
• Spread – đặt một nhóm nhỏ instance lên các phần cứng riêng biệt để giảm lỗi tương quan.

Với yêu cầu trong đề, cluster placement group là lựa chọn tối ưu: nó là công cụ duy nhất trong danh sách thực sự rút ngắn khoảng cách mạng giữa các node, chứ không chỉ nhóm chúng lại về mặt quản trị.

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

A – Redeploy the application in a dedicated subnet. Đây là phương án gần đúng nhất và dễ mắc bẫy. Một subnet luôn nằm gọn trong một Availability Zone, nên đặt tất cả instance vào cùng subnet đúng là kéo chúng về cùng một AZ. Nhưng nó dừng ở đó: subnet là ranh giới địa chỉ IP và định tuyến, không nói gì về việc các instance nằm ở đâu trong AZ đó. Một AZ có thể rất rộng, và hai instance cùng subnet vẫn có thể ở xa nhau. Cluster placement group mới đảm bảo chúng nằm gần nhau bên trong AZ.

C – Redeploy the application in an Auto Scaling group. Auto Scaling group giải quyết bài toán số lượng instance — tự thêm bớt node theo tải, và duy trì số node mong muốn. Nó không có tác động tích cực nào tới độ trễ giữa các node. Tệ hơn, cấu hình Auto Scaling group thông thường còn trải instance ra nhiều AZ để tăng tính sẵn sàng, tức là đi ngược lại đúng thứ đề đang cần: giao tiếp xuyên AZ có độ trễ cao hơn trong cùng AZ.

D – Redeploy the application in a single Availability Zone. Cùng một điểm hỏng như phương án A, chỉ diễn đạt trực tiếp hơn. Gom về một AZ là điều kiện cần — bạn không thể có độ trễ thấp nhất khi node nằm rải ở các AZ khác nhau — nhưng chưa phải điều kiện đủ. Nó loại bỏ độ trễ xuyên AZ mà không kiểm soát được vị trí bên trong AZ. Đáng chú ý là cluster placement group đã bao hàm việc nằm trong một AZ, nên chọn D là chọn phần yếu hơn của chính đáp án B.

📌 Điểm cần nhớ

• Thấy từ khoá "low latency between nodes" / "inter-node communication" / "tightly-coupled" với EC2 → nghĩ ngay tới cluster placement group.
• Phân biệt ba chiến lược placement group theo mục tiêu: cluster = độ trễ thấp và băng thông cao; partition = tách phần cứng cho workload phân tán nhân bản; spread = giảm lỗi tương quan cho một nhóm nhỏ instance quan trọng.
• Subnet và Availability Zone là ranh giới logic, không phải công cụ điều khiển vị trí vật lý. Chúng thu hẹp phạm vi nhưng không đưa các instance lại gần nhau.
• Auto Scaling group là bài toán công suất và tính sẵn sàng, không phải bài toán độ trễ — và xu hướng trải qua nhiều AZ của nó còn làm độ trễ inter-node xấu đi.

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

Đề mô tả một SysOps administrator đang triển khai nhiều EC2 instance theo từng đợt (batches) cho một ứng dụng phân tán lớn, và ở đợt gần nhất thì nhận lỗi InstanceLimitExceeded. Câu hỏi: phải làm gì để giải quyết lỗi này.

Cụm từ quyết định đáp án là chính tên lỗi InstanceLimitExceeded. Đây không phải lỗi hết capacity của AWS, cũng không phải lỗi mạng hay lỗi subnet hết địa chỉ IP — nó là lỗi chạm hạn mức (quota/limit) số On-Demand instance đang chạy mà tài khoản được phép có. Hai chi tiết đi kèm cần chú ý:

• Hạn mức này áp ở phạm vi Region, không phải phạm vi VPC hay Availability Zone.
• Hạn mức này gắn với EC2, không phải với EBS.

Hai chi tiết đó chính là thứ tách bốn phương án ra: hai phương án đánh vào "đổi chỗ triển khai" (sai phạm vi), một phương án đánh vào "xin tăng quota nhưng nhầm dịch vụ", và một phương án đúng cả phạm vi lẫn dịch vụ.

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

D — Use Service Quotas to request an EC2 quota increase.

Lỗi InstanceLimitExceeded nghĩa là bạn đã chạm trần số lượng On-Demand instance được phép chạy trong Region đó. Cách xử lý đúng bản chất là nâng chính cái trần đó lên, chứ không phải né tránh nó. Service Quotas là dịch vụ chuyên dụng của AWS để xem và yêu cầu tăng hạn mức cho các dịch vụ, trong đó có EC2 — nên yêu cầu tăng quota EC2 qua Service Quotas là hành động trực tiếp giải quyết nguyên nhân gốc.

Lưu ý theo đúng tài liệu tham chiếu: quota EC2 được xin tăng theo từng Region, và có thể thao tác qua Amazon EC2 console hoặc qua Service Quotas. Phương án D nêu đúng cả công cụ lẫn đối tượng cần tăng.

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

A — Launch new EC2 instances in another VPC within the Region. Sai vì đặt nhầm phạm vi. VPC là ranh giới mạng, không phải ranh giới hạn mức. Hạn mức On-Demand instance tính trên Region, nên dù bạn tạo bao nhiêu VPC trong cùng Region đó thì tổng số instance đang chạy vẫn cộng dồn vào cùng một quota — lần launch tiếp theo vẫn nhận đúng lỗi InstanceLimitExceeded. Phương án này chỉ tốn công dựng thêm hạ tầng mạng mà không thay đổi gì.

B — Launch the EC2 instances in a different Availability Zone. Đây là phương án gần đúng nhất và dễ bẫy nhất, vì đổi AZ đúng là cách xử lý cho một lỗi khác: InsufficientInstanceCapacity — khi AWS tạm thời không còn capacity cho loại instance đó trong một AZ cụ thể. Nhưng lỗi trong đề là InstanceLimitExceeded, tức là trần do tài khoản của bạn, không phải capacity của AWS. AZ nằm bên trong Region, nên chuyển sang AZ khác vẫn nằm dưới cùng một quota Region và không hết lỗi. Phân biệt hai thông báo lỗi này là ý chính mà câu hỏi muốn kiểm tra.

C — Use the Amazon EC2 console to request an EBS quota increase. Phương án này đúng một nửa nên cũng dễ chọn nhầm: EC2 console đúng là một nơi hợp lệ để xin tăng quota. Chỗ hỏng nằm ở đối tượng — nó xin tăng quota EBS (dung lượng/số lượng volume, snapshot…), trong khi lỗi đang gặp là về số lượng EC2 instance. Tăng quota EBS lên bao nhiêu cũng không nới được trần số instance đang chạy, nên lỗi vẫn còn nguyên. Đây là kiểu bẫy "đúng hành động, sai tài nguyên".

📌 Điểm cần nhớ

• InstanceLimitExceeded = chạm quota của tài khoản → xử lý bằng cách xin tăng quota, thường qua Service Quotas (EC2 console cũng làm được). Đừng nhầm với InsufficientInstanceCapacity — cái đó là phía AWS hết capacity trong một AZ, và khi ấy đổi AZ / đổi instance type mới là hướng đúng.
• Quota EC2 On-Demand áp theo Region. Mọi phương án kiểu "chuyển sang AZ khác", "dùng VPC khác", "dùng subnet khác" đều không nới được trần, vì AZ, VPC và subnet đều nằm trong Region.
• Đọc kỹ tài nguyên bị giới hạn, không chỉ đọc hành động. Câu hỏi hay đặt một phương án "xin tăng quota" nhưng gắn sai dịch vụ (EBS thay vì EC2) để bẫy người đọc lướt.
• Với dạng câu AWS ném ra một mã lỗi cụ thể, hãy coi chính mã lỗi đó là từ khoá quyết định: nó nói thẳng nguyên nhân gốc, và đáp án đúng gần như luôn là thứ tác động vào nguyên nhân gốc chứ không phải cách đi vòng.

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

Đề mô tả một Amazon Elasticsearch Service (Amazon ES) domain đã tồn tại và đang chạy với public endpoint. Người dùng ở nhiều chi nhánh kết nối tới nó qua các đường AWS Site-to-Site VPN. Yêu cầu là chỉ cho phép truy cập từ các chi nhánh đó.

Cụm từ quyết định đáp án là "while preserving existing data" — phải giữ nguyên dữ liệu đang có. Đây là ràng buộc phân biệt hai nhóm phương án gần giống nhau, vì một domain Amazon ES không chuyển đổi qua lại được giữa public endpoint và VPC access sau khi đã tạo. Muốn đưa domain vào VPC thì phải tạo domain mới rồi reindex hoặc di chuyển dữ liệu sang — nghĩa là dữ liệu không tự nhiên "còn nguyên", phải làm thêm một bước snapshot/migrate mà không phương án nào nhắc tới.

Cụm thứ hai đáng chú ý là "over AWS Site-to-Site VPN connections": lưu lượng từ chi nhánh đi qua VPN nên nó mang địa chỉ IP private của mạng chi nhánh, tức là có thể lọc bằng CIDR block.

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

D — Configure an IP-based domain access policy on Amazon ES, allow các private IP CIDR block của từng chi nhánh.

IP-based access policy là resource-based policy gắn thẳng vào domain, cho phép giới hạn truy cập theo một hoặc nhiều địa chỉ IP hay CIDR block. Vì domain vẫn giữ nguyên public endpoint, không có thao tác tạo lại domain nào xảy ra, nên dữ liệu hiện có được giữ nguyên — đúng ràng buộc của đề.

Về phần chặn truy cập: lưu lượng từ các chi nhánh đến qua Site-to-Site VPN mang CIDR private của mạng chi nhánh, nên liệt kê các CIDR đó vào statement Allow sẽ cho phép đúng những người cần, còn mọi nguồn khác trên Internet không khớp policy sẽ bị từ chối. Đây là cách duy nhất trong danh sách vừa siết được quyền truy cập vừa không đụng tới dữ liệu.

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

A — Identity-based access policy với ARN của từng VPN connection. Sai ở hai tầng. Thứ nhất, identity-based policy được gắn vào user hoặc role trong IAM, không phải là thứ dùng để mô tả nguồn mạng; nó trả lời câu hỏi "danh tính này được làm gì", không phải "gói tin đến từ đâu". Thứ hai, ARN của một VPN connection không phải là một principal — không có "danh tính" nào tên như vậy đi kèm request tới Amazon ES để IAM đối chiếu. Policy viết ra sẽ không khớp với bất kỳ request nào theo cách người ta mong đợi.

B — Đưa domain vào private subnet trong VPC + security group cho phép CIDR chi nhánh. Đây là phương án nghe rất "đúng chuẩn kiến trúc" và về mặt bảo mật thì thật sự chặt hơn D. Nhưng nó hỏng đúng ở ràng buộc của đề: chuyển một domain từ public endpoint sang VPC access không phải là một thao tác cấu hình tại chỗ, phải tạo domain mới, và dữ liệu hiện có không được giữ lại trừ khi làm thêm bước migrate bằng snapshot. Phương án không hề nhắc tới bước đó, nên nó không đáp ứng "preserving existing data".

C — Đưa domain vào private subnet trong VPC + IP-based domain access policy theo CIDR chi nhánh. Hỏng vì đúng cùng một lý do với B: mệnh đề đầu "Reconfigure the Amazon ES domain in private subnets in a VPC" đã kéo theo việc phải tạo lại domain và mất dữ liệu hiện có. Phần thứ hai của C (IP-based policy theo CIDR) thì đúng — nó chính là phần đúng của D — nhưng ghép với việc di chuyển domain vào VPC thì cả phương án vẫn vi phạm ràng buộc. Đây là bẫy kinh điển: một mệnh đề đúng đứng cạnh một mệnh đề vi phạm ràng buộc thì cả phương án vẫn sai.

📌 Điểm cần nhớ

• Amazon ES/OpenSearch Service: chọn public endpoint hay VPC access ngay lúc tạo domain, và không đổi qua lại được. Câu nào có chữ "preserve existing data" mà phương án đòi chuyển domain vào VPC thì loại ngay.
• Resource-based / IP-based policy gắn vào chính domain, lọc theo IP hoặc CIDR nguồn. Identity-based policy gắn vào IAM user/role, lọc theo danh tính. ARN của tài nguyên mạng (VPN connection, subnet…) không dùng làm principal được.
• Với truy cập qua Site-to-Site VPN, request mang IP private của mạng on-premises, nên CIDR block của chi nhánh là thứ dùng để lọc.
• Trong câu trắc nghiệm, đọc kỹ từng mệnh đề của phương án: chỉ cần mệnh đề đầu vi phạm ràng buộc thì phần sau dù đúng hoàn toàn cũng không cứu được — B và C sai đúng theo kiểu đó.

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

Đề mô tả một công ty quản lý nhiều account bằng AWS Organizations. Yêu cầu: dựng một S3 bucket dùng chung ở account trung tâm, cấp quyền read-only cho mọi user thuộc bất kỳ account nào trong Organization, và không được để dữ liệu public. Câu hỏi là nên dùng tham số nào trong bucket policy để đạt mục tiêu MOST efficiently.

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

• "all users in any account within the AWS Organization" — phạm vi cấp quyền là toàn bộ Organization, không phải một account cụ thể. Điều này loại ngay những phương án chỉ trỏ tới một account.
• "MOST efficiently" — đây là ràng buộc phân biệt hai phương án cùng hoạt động được. Liệt kê tay từng account number vẫn chạy đúng, nhưng phải sửa policy mỗi lần Organization thêm account mới, nên nó thua về hiệu quả vận hành.
• "no public access" — cảnh báo rằng dù Principal là "*", quyền truy cập vẫn phải bị siết lại bằng một cơ chế khác, chứ không được để bucket mở ra Internet.

Ba cụm này gộp lại chỉ tới đúng một thiết kế: principal mở, nhưng có điều kiện lọc theo Organization.

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

Đáp án đúng theo tệp là C — Specify '*' as the principal and aws:PrincipalOrgId as a condition.

aws:PrincipalOrgId là condition key của IAM: nó so giá trị Organization ID của principal đang gọi request với giá trị bạn khai trong policy. Trong bucket policy của account trung tâm, cách viết đúng là để Principal là "*" — nghĩa là "bất kỳ principal nào cũng được xét" — rồi dùng block Condition với aws:PrincipalOrgId bằng ID của Organization để chỉ những principal thuộc Organization đó mới thực sự được phép.

Đây chính là chỗ hai yêu cầu tưởng như mâu thuẫn của đề gặp nhau: Principal: "*" không đồng nghĩa với public, vì một request chỉ được cho phép khi thoả mọi điều kiện trong Condition. Người ẩn danh ngoài Internet không mang theo Organization ID nào khớp, nên bị từ chối. Nhờ vậy vẫn giữ được "no public access" trong khi phủ hết mọi user của mọi account.

Về mặt "MOST efficiently": chỉ cần khai một giá trị Organization ID duy nhất. Account mới được thêm vào Organization sau này tự động nằm trong phạm vi mà không phải sửa lại bucket policy — đúng tinh thần của từ efficiently trong đề.

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

A — Specify the organization's master account as the principal. Sai vì phạm vi quá hẹp. Đặt master account (management account) làm principal chỉ cấp quyền cho chính account đó, không lan sang các member account khác trong Organization. Đề yêu cầu rõ "any account within the AWS Organization", nên phương án này không đáp ứng được yêu cầu cơ bản nhất, chưa cần bàn tới chuyện hiệu quả. Việc account này là "master" không tạo ra quyền kế thừa xuống các account con trong bucket policy.

B — Specify aws:PrincipalOrgId as the principal with the organization ID value. Đây là phương án gài bẫy sát nhất, vì nó nhắc đúng tên condition key cần dùng và đúng giá trị cần khai. Chỗ hỏng nằm ở vị trí sử dụng: aws:PrincipalOrgId là một condition key, nó chỉ có nghĩa khi nằm trong block Condition. Trường Principal trong policy chờ đợi một dạng định danh principal (ARN của IAM user/role, account ID, service principal, hoặc "*"), chứ không nhận condition key. Đặt sai chỗ như vậy không tạo ra được policy hợp lệ theo ý định — đúng chất liệu, sai cấu trúc.

D — Specify all account numbers within an array as the principal. Phương án này có hoạt động: liệt kê từng account ID trong mảng Principal thì user thuộc các account đó truy cập được, và bucket cũng không public. Nhưng nó trượt ở đúng chữ MOST efficiently mà đề nhấn mạnh: phải gõ ra toàn bộ account number hiện có, và mỗi lần Organization thêm account mới thì phải quay lại sửa bucket policy. Đây là công việc bảo trì thủ công lặp lại, dễ quên, và càng nhiều account càng cồng kềnh — trong khi C giải quyết bằng một giá trị duy nhất, tự bao phủ cả account tương lai.

📌 Điểm cần nhớ

• Principal: "*" không đồng nghĩa với public khi có block Condition đi kèm. Một request phải thoả cả principal lẫn toàn bộ condition mới được Allow — đây là mẫu chuẩn để "mở cho tất cả rồi lọc lại".
• Phân biệt condition key với principal. Những khoá bắt đầu bằng aws:Principal* (như aws:PrincipalOrgId) là điều kiện mô tả người gọi, luôn nằm trong Condition, không bao giờ nằm trong trường Principal.
• Từ khoá MOST efficiently trong đề thường dùng để tách "chạy được" khỏi "nên dùng". Khi hai phương án cùng đạt kết quả, hãy chọn cái không phải bảo trì thủ công khi hệ thống mở rộng.
• Cấp quyền theo phạm vi AWS Organization thì dùng Organization ID, đừng liệt kê account. Cách này tự động phủ các account được thêm vào sau, giảm rủi ro policy bị lạc hậu.

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

Đề mô tả một web application chạy trên nhiều EC2 instance trong Auto Scaling group, dùng chung một file system trên Amazon EFS. Triệu chứng: trong giai đoạn tải nặng, người dùng báo độ trễ khi lấy file tăng lên.

Cụm từ quyết định đáp án là "the volume of data does not change much" — dung lượng dữ liệu gần như không đổi. Chi tiết này không phải để mô tả cho đủ ý; nó nhắm thẳng vào cách EFS cấp throughput. Với Bursting Throughput, throughput cơ sở mà file system nhận được tỉ lệ với lượng dữ liệu đang lưu trong storage class Standard hoặc One Zone. Một file system không lớn lên thì cũng không bao giờ được cấp thêm throughput cơ sở, dù nhu cầu đọc tăng.

Vế thứ hai cần chú ý: "during periods of heavy utilization" — vấn đề là nhu cầu I/O tăng theo lúc, chứ không phải file system đầy hay cấu hình bảo mật sai. Đọc hai cụm này cùng nhau ra kết luận: cần tách throughput ra khỏi dung lượng dữ liệu.

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

A. Configure the file system for Provisioned Throughput.

EFS có hai throughput mode được nêu trong đề: Bursting và Provisioned. Với Provisioned Throughput, bạn khai báo thẳng mức throughput (MiB/s) mà file system được hưởng, độc lập với lượng dữ liệu đang lưu. Đây đúng là thứ tình huống này cần: dữ liệu không tăng nên không thể trông chờ throughput tự lớn theo, mà nhu cầu đọc lúc cao điểm thì vẫn cao.

Chuyển sang Provisioned Throughput bảo đảm file system luôn có đủ băng thông cho giai đoạn tải nặng, nhờ đó giảm độ trễ khi lấy file — không phụ thuộc vào việc có nhồi thêm dữ liệu vào EFS hay không.

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

B. Configure the file system for Bursting Throughput. Đây là phương án gần đúng nhất và cũng là cái bẫy chính, vì nó cùng họ với đáp án đúng: cũng là throughput mode, cũng liên quan tới hiệu năng. Chỗ nó hỏng nằm ở cơ chế: throughput trong Bursting mode co giãn theo kích thước file system. Đề đã nói rõ dữ liệu gần như không đổi, nên file system nhỏ này sẽ giữ nguyên mức throughput cơ sở thấp và chỉ được burst trong thời gian giới hạn. Đúng lúc heavy utilization kéo dài là lúc khả năng burst cạn dần và độ trễ quay lại. Ngoài ra, rất có thể file system hiện tại đã ở Bursting mode — "đổi sang" chính cái đang gây vấn đề thì không sửa được gì.

C. Enable encryption in transit on the file system. Đây là biện pháp bảo mật, bảo vệ dữ liệu trên đường truyền giữa EC2 instance và EFS. Nó không liên quan gì tới lượng throughput mà file system được cấp, nên không giải quyết được độ trễ. Nếu có ảnh hưởng thì cũng theo hướng thêm việc phải xử lý chứ không phải bớt đi — bật encryption không bao giờ là cách chữa vấn đề hiệu năng.

D. Remove any unused files from the file system. Nghe hợp lý theo trực giác "dọn dẹp cho nhẹ", nhưng với EFS thì logic ngược lại. Nếu file system đang ở Bursting mode, xoá bớt file làm giảm kích thước file system, kéo theo giảm throughput cơ sở — tức là làm hiệu năng tệ hơn chứ không tốt lên. Nếu đã ở Provisioned mode thì throughput không phụ thuộc dung lượng, nên xoá file chẳng thay đổi gì. Thêm nữa, EFS tự co giãn dung lượng, không có chuyện "hết chỗ" khiến chậm như một volume cố định.

📌 Điểm cần nhớ

• Bursting Throughput gắn với kích thước file system; Provisioned Throughput thì không. Đề nào nhấn mạnh "dữ liệu ít / không tăng" mà lại than chậm thì gần như chắc chắn hướng tới Provisioned Throughput.
• Ngược lại, nếu đề mô tả file system rất lớn và chỉ thỉnh thoảng cần thêm băng thông, Bursting mode thường đủ và tiết kiệm hơn — chọn mode là bài toán đánh đổi giữa nhu cầu throughput và dung lượng thật sự đang lưu.
• Encryption in transit là hạng mục bảo mật, không phải hạng mục hiệu năng. Gặp phương án bảo mật trong câu hỏi về latency thì loại ngay, trừ khi đề hỏi về tuân thủ.
• Xoá file trên EFS không phải cách tăng tốc. Trong Bursting mode nó còn phản tác dụng vì làm tụt throughput cơ sở — đây là điểm khác biệt hay bị nhầm giữa EFS và các loại volume dung lượng cố định.