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

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

Đề mô tả một EBS volume đang gắn vào EC2 chạy database, được mã hoá bằng customer-managed CMK của AWS KMS. SysOps Administrator muốn xoay vòng khoá bằng automatic key rotation.

Cụm từ quyết định nằm ở vế cuối: "needs to ensure that the EBS volume encrypted with the current key remains readable" — dữ liệu đã mã hoá bằng khoá hiện tại phải đọc được tiếp. Cụm thứ hai cũng quan trọng: "using automatic key rotation" — đề đã chỉ định sẵn cơ chế, nên việc còn lại chỉ là bật đúng cơ chế đó lên chứ không phải nghĩ ra cách xoay khoá thủ công.

Hai cụm này loại được các phương án "tạo mới": bất cứ thứ gì tạo ra khoá mới và gán cho volume đều phá vỡ khả năng giải mã dữ liệu cũ, hoặc ít nhất là không phải điều mà automatic rotation làm.

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

C — Enable automatic key rotation of the customer master key in KMS.

Với customer-managed CMK, automatic key rotation mặc định tắt; người quản trị phải bật thủ công. Khi bật, KMS tự sinh backing key (vật liệu mã hoá) mới cho CMK theo chu kỳ định sẵn.

Điểm mấu chốt trả lời đúng yêu cầu "remains readable": rotation chỉ đổi backing key, còn CMK vẫn là cùng một logical resource — cùng key ID, cùng ARN, cùng key policy, cùng alias. KMS giữ lại toàn bộ backing key cũ vĩnh viễn để giải mã dữ liệu đã mã hoá bằng chúng, và không xoá vật liệu khoá đã xoay vòng cho tới khi bạn xoá hẳn CMK. Vì vậy EBS volume đang gắn vào EC2 vẫn giải mã được bình thường, không cần thao tác nào thêm, không cần dừng instance.

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

A — Create a new data key in KMS and assign the key to Amazon EBS. Nhầm tầng khoá. Trong mô hình envelope encryption, EBS dùng data key để mã hoá dữ liệu, còn CMK dùng để mã hoá chính data key đó. Thứ cần xoay vòng là backing key của CMK, không phải data key. Gán một data key mới cho volume nghĩa là dữ liệu đang nằm trên volume — vốn được mã hoá bằng data key cũ — không còn giải mã được nữa, tức là vi phạm thẳng yêu cầu "remains readable". Ngoài ra data key gắn với volume không phải thứ người dùng đi "assign" thủ công như vậy.

B — Create a new customer master key in KMS and enable rotation. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì nó có nhắc tới rotation. Chỗ hỏng là ở mệnh đề đầu: không cần tạo CMK mới. CMK hiện tại đã tồn tại và đang bảo vệ volume; chỉ cần bật rotation cho chính nó. Tạo CMK mới rồi bật rotation trên CMK mới đó không giúp gì cho volume đang chạy — volume vẫn bị buộc vào CMK cũ, và CMK cũ thì vẫn chưa được xoay vòng. Muốn volume thực sự dùng CMK mới thì phải re-encrypt (snapshot + copy sang key khác), một việc hoàn toàn khác với "automatic key rotation" mà đề yêu cầu.

D — Back up the current KMS data key and enable automatic key rotation. Vế sau ("enable automatic key rotation") đúng, nhưng vế trước thừa và sai khái niệm. Không cần sao lưu data key, vì AWS KMS tự động giữ lại mọi backing key cũ của CMK — đó chính là cơ chế đảm bảo dữ liệu cũ vẫn đọc được, người dùng không phải tự lo việc lưu trữ. Hơn nữa, đối tượng cần quan tâm khi rotation là backing key của CMK chứ không phải data key. Một phương án có thao tác thừa dựa trên giả định sai về cách dịch vụ hoạt động thì vẫn là phương án sai.

📌 Điểm cần nhớ

• Phân biệt ba tầng khoá trong KMS: CMK (logical resource, có ID/ARN/policy) → backing key (vật liệu mã hoá bên trong CMK, thứ bị rotation thay đổi) → data key (thứ thực sự mã hoá dữ liệu như EBS volume). Đề thi rất hay tráo "data key" vào chỗ đáng ra phải là "CMK".
• Automatic key rotation không phá dữ liệu cũ: KMS lưu backing key cũ vô thời hạn và tự chọn đúng backing key khi giải mã. Thấy phương án nào bắt bạn backup, export hay gán lại khoá để "giữ dữ liệu đọc được" thì gần như chắc chắn sai.
• Automatic rotation là tính năng bật/tắt trên CMK có sẵn, không phải lý do để tạo CMK mới. Với customer-managed CMK, mặc định là tắt — nên hành động đúng thường chỉ đơn giản là "enable".
• Đổi CMK khác hẳn xoay vòng CMK: muốn volume dùng CMK khác thì phải re-encrypt qua snapshot/copy; đó là câu trả lời cho một dạng câu hỏi khác, không phải câu hỏi về key rotation.

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

Đề mô tả một công ty đã dùng AWS Service Catalog để quản lý các dịch vụ được duyệt, tài nguyên hiện đang được tạo và quản lý qua một portfolio có sẵn. Nay có thêm một AWS account mới, và SysOps Administrator cần dựng lại bản sao của hạ tầng đó trong account mới.

Cụm từ quyết định nằm ở câu hỏi cuối: "MOST efficient way" — hiệu quả nhất, tức tốn ít công sức dựng lại và ít công bảo trì về sau nhất. Cả bốn phương án đều làm được việc "có portfolio ở account mới"; chúng chỉ khác nhau ở lượng công phải bỏ ra và ở chỗ bản sao có tự đồng bộ với bản gốc hay không.

Ràng buộc ngầm thứ hai, quan trọng không kém: portfolio đã tồn tại. Đề không hỏi cách thiết kế hệ thống từ đầu, mà hỏi cách đưa thứ đang có sang một account khác. Khi Service Catalog vốn có sẵn cơ chế chia sẻ portfolio giữa các account, mọi phương án đi dựng lại từ đầu đều là làm thủ công một việc dịch vụ đã làm sẵn.

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

C — Share portfolio sang account kia rồi import vào account đó.

Service Catalog hỗ trợ chia sẻ portfolio giữa các account, theo kiểu account-to-account hoặc qua AWS Organizations. Điểm mấu chốt: khi share, thứ được chia sẻ là một tham chiếu (reference) tới portfolio gốc, không phải một bản sao độc lập. Portfolio được import ở account nhận sẽ giữ đồng bộ với portfolio gốc — sửa product hay constraint ở bên gốc thì bên nhận thấy ngay.

Bên nhận không được sửa product và constraint của portfolio đã import, nhưng vẫn gán được quyền IAM cho end user của mình. Đó chính xác là mô hình quản trị mà đề mô tả: một nơi duyệt và giữ chuẩn dịch vụ, các account khác dùng lại chuẩn đó. Về công sức, đây là vài thao tác cấu hình, không phải một dự án dựng lại hạ tầng — nên nó thắng ở tiêu chí "MOST efficient".

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

A — Chạy Lambda tạo portfolio mới dựa trên output của DescribePortfolio. Đây là phương án "gần đúng" nhất về mặt kỹ thuật: DescribePortfolio đọc được thông tin portfolio, và về nguyên tắc có thể viết code dựng lại. Nhưng nó hỏng ở chỗ bạn phải tự viết và tự bảo trì đoạn code đó, tự lo phần product và constraint đi kèm, tự lo quyền cho Lambda. Kết quả cũng chỉ là một bản sao rời rạc, không có liên hệ gì với bản gốc. Bỏ công lập trình để làm lại một việc dịch vụ đã cung cấp sẵn thì không thể là cách hiệu quả nhất.

B — Viết CloudFormation template để redeploy portfolio ở account mới. Cũng là cách làm hợp lệ và có tính lặp lại, nhưng vẫn đòi bạn soạn ra template — mô tả lại portfolio, các product và các constraint. Đó là công việc phát sinh mà phương án C không cần đến. Và giống A, kết quả là một portfolio độc lập: bản gốc đổi thì bản này không tự đổi theo, phải cập nhật template rồi deploy lại ở từng account.

D — Tạo tay portfolio ở account mới rồi dựng lại portfolio gốc. Đây là phương án tốn công nhất và cũng dễ loại nhất. Toàn bộ thao tác đều thủ công, dễ sai sót khi chép lại product và constraint, không lặp lại được nếu sau này có thêm account nữa, và hoàn toàn không có đồng bộ. Chính đề đã hỏi "MOST efficient", nên một quy trình làm tay từ đầu là đối cực của yêu cầu.

📌 Điểm cần nhớ

• Với Service Catalog, khi cần dùng lại một portfolio ở account khác, phản xạ đầu tiên là share + import, không phải dựng lại. Đây là tính năng có sẵn của dịch vụ.
• Portfolio được share là tham chiếu, không phải bản sao: bên nhận luôn thấy phiên bản mới nhất của bản gốc, không sửa được product/constraint, nhưng gán được quyền IAM cho end user của mình.
• Khi đề hỏi "MOST efficient" mà nhiều phương án đều khả thi, hãy loại theo lượng công phải tự làm: làm tay < viết template < viết code < dùng tính năng có sẵn — xếp ngược lại chính là thứ tự ưu tiên chọn đáp án.
• Chú ý thêm tiêu chí bảo trì lâu dài: phương án tạo ra bản sao độc lập sẽ sinh ra công việc đồng bộ về sau, còn phương án chia sẻ thì không.

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

Đề mô tả một kiến trúc đã có sẵn tính sẵn sàng cao: EC2 nằm trong Auto Scaling group phía sau Application Load Balancer, còn tầng dữ liệu là Amazon RDS Multi-AZ. Công ty vừa chạy thử một đợt failover, và nhiệm vụ được giao rất hẹp.

Cụm từ quyết định đáp án là "reducing the failover time of the RDS database" — giảm thời gian failover, chứ không phải "tăng hiệu năng", "giảm chi phí" hay "tăng mức bền vững". Kèm theo đó là hai ràng buộc ngầm nhưng rất quan trọng:

• Hệ thống đã là Multi-AZ rồi, nên mọi phương án đề nghị đổi cấu hình sẵn sàng cao đều đi ngược lại mục tiêu ban đầu của kiến trúc.
• Thứ cần rút ngắn là khoảng thời gian ứng dụng không dùng được database trong lúc chuyển sang standby, không phải tốc độ xử lý truy vấn lúc bình thường.

Đọc kỹ cụm này thì ba trong bốn phương án tự loại: chúng nói về capacity hoặc về phạm vi triển khai, không nói gì tới quá trình chuyển đổi kết nối lúc failover.

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

Đáp án đúng theo tệp là D — Create an RDS Proxy and direct the application towards the proxy endpoint.

RDS Proxy đứng chen giữa ứng dụng và database, giữ một pool kết nối dùng chung. Ứng dụng không còn nối thẳng tới instance nữa mà nối tới proxy endpoint. Khi failover xảy ra, proxy tự động nối lại sang instance database mới trong khi vẫn giữ nguyên các kết nối mà ứng dụng đang mở tới proxy.

Điểm mấu chốt nằm ở đây: với kết nối trực tiếp, sau failover ứng dụng phải phát hiện kết nối đã chết, đợi DNS của endpoint trỏ sang instance mới, rồi thiết lập lại toàn bộ connection pool — chính chuỗi việc đó chiếm phần lớn thời gian ứng dụng bị gián đoạn. RDS Proxy gánh việc đó thay, nên rút ngắn được khoảng thời gian ứng dụng có thể không khả dụng trong một số kiểu failover. Đúng chính xác thứ đề bài yêu cầu.

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

A — Add more CPU and memory to the RDS database instance. Đây là phương án gần đúng theo kiểu "cứ mạnh hơn thì cái gì cũng nhanh hơn", nhưng nó nhắm sai chỗ. Thời gian failover phụ thuộc vào việc standby tiếp quản nhanh tới đâu và ứng dụng nối lại nhanh tới đâu, không phụ thuộc vào việc instance có bao nhiêu CPU hay RAM. Nâng cấu hình cải thiện hiệu năng truy vấn lúc chạy bình thường — một mục tiêu khác hẳn với mục tiêu đề bài nêu.

B — Configure the RDS DB to operate within a single Availability Zone. Phương án này không chỉ không giúp gì mà còn phá bỏ chính thứ đang bảo vệ hệ thống. Bỏ Multi-AZ nghĩa là không còn standby sẵn sàng tiếp quản; khi một AZ có sự cố thì không phải là failover nhanh hơn mà là không có failover nào cả, và rủi ro downtime tăng lên. Đề nói rõ đây là "resilient system architecture" — đáp án làm hệ thống kém bền vững hơn thì mâu thuẫn trực tiếp với bối cảnh.

C — Configure the RDS Multi-AZ deployment to run across AWS Regions. Nghe hợp lý với người mới vì "nhiều Region thì càng an toàn", nhưng nó sai ngay ở mặt kỹ thuật: Multi-AZ deployment là cơ chế trong phạm vi một Region, không cấu hình để trải qua nhiều Region được. Availability Zone là đơn vị con của Region, nên "Multi-AZ across Regions" tự nó đã là một cấu hình không tồn tại. Và kể cả nếu bỏ qua điều đó, việc mở rộng khoảng cách địa lý cũng không phải hướng đi làm failover nhanh hơn.

📌 Điểm cần nhớ

• Khi đề hỏi "giảm thời gian failover" cho RDS mà kiến trúc đã là Multi-AZ, hãy nghĩ ngay tới RDS Proxy: nó giữ kết nối của ứng dụng và tự nối lại sang instance mới, cắt bớt phần thời gian dành cho việc dựng lại connection pool.
• Phân biệt rõ hai nhóm mục tiêu dễ lẫn: nâng CPU/RAM giải quyết bài toán hiệu năng, còn RDS Proxy / Multi-AZ giải quyết bài toán tính sẵn sàng và thời gian phục hồi. Đề hỏi cái nào thì loại thẳng phương án thuộc nhóm kia.
• Multi-AZ nằm gọn trong một Region. Bất kỳ phương án nào ghép "Multi-AZ" với "across Regions" đều là bẫy dựa trên một cấu hình không tồn tại.
• Phương án nào hạ thấp tính sẵn sàng (gom về một AZ, bỏ standby) gần như chắc chắn sai khi đề đang mô tả một kiến trúc resilient và yêu cầu cải thiện khả năng chịu lỗi.

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

Đề mô tả một kiến trúc quen thuộc: Auto Scaling group chứa EC2 instances đứng sau Application Load Balancer, phía dưới là RDS MySQL và một ElastiCache for Memcached cluster. Người quản trị phải thực hiện system patching vào 22h thứ Tư.

Câu hỏi thật sự là: "Which resources require the configuration of a maintenance window?" — chọn hai.

Cụm từ quyết định là "maintenance window", hiểu theo đúng nghĩa hẹp của AWS: một khoảng thời gian hằng tuần mà AWS tự thực hiện việc vá lỗi / cập nhật cho dịch vụ được quản lý (managed service). Đây là một thuộc tính cấu hình có sẵn của tài nguyên, không phải một cơ chế lập lịch chung chung.

Bẫy của đề nằm ở chỗ nó nói "system patching" — nghe như liên quan tới hệ điều hành trên EC2. Nhưng câu hỏi không hỏi "bạn vá ở đâu", mà hỏi tài nguyên nào có thứ gọi là maintenance window để cấu hình. Chỉ những dịch vụ mà AWS chịu trách nhiệm vá phần nền tảng mới có tuỳ chọn này.

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

A – Amazon ElastiCache cluster và B – Amazon RDS instance.

Cả hai đều là managed service: AWS quản lý engine bên dưới (MySQL với RDS, Memcached với ElastiCache) và định kỳ áp bản vá, cập nhật engine, thay phần cứng lỗi. Vì các thao tác đó có thể gây gián đoạn, AWS cho mỗi tài nguyên một maintenance window.

Điểm quan trọng: cả hai dịch vụ đều đã có sẵn một maintenance window mặc định do AWS chọn khi tạo tài nguyên. Người quản trị không tạo mới từ con số không, mà cấu hình lại cho khớp với lịch của mình — ở đây là 22h thứ Tư. Đó chính là lý do đề dùng chữ "require the configuration of": mặc định không nằm đúng chỗ mình muốn, nên phải chỉnh.

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

C – Elastic Load Balancer. ELB (bao gồm ALB trong đề) là dịch vụ được quản lý hoàn toàn, nhưng nó không phơi ra khái niệm maintenance window cho người dùng. AWS vá và thay thế node của load balancer một cách trong suốt, không gây gián đoạn đáng kể nên không cần bạn chọn giờ. Không có ô nào để cấu hình cả — đây là phương án sai vì thứ được hỏi đơn giản không tồn tại trên tài nguyên này.

D – Amazon EC2 instances. Đây là phương án gần đúng nhất và là bẫy chính, vì "system patching" gợi ngay tới việc vá OS trên EC2. Nhưng theo mô hình trách nhiệm chung, hệ điều hành trên EC2 là việc của khách hàng, không phải của AWS — nên bản thân EC2 instance không có thuộc tính maintenance window để bạn đặt. Việc lên lịch vá EC2 được làm bằng công cụ khác chứ không phải bằng một maintenance window gắn trên instance. Lưu ý phân biệt với scheduled events của EC2 (AWS báo trước khi phải retire hoặc reboot một instance) — đó là thông báo bạn nhận, không phải cửa sổ bạn cấu hình.

E – Amazon EC2 Auto Scaling. Auto Scaling group chỉ là cơ chế điều phối: nó theo dõi sức khoẻ, thêm/bớt instance theo chính sách. Nó không có bản vá nào để áp, cũng không có maintenance window. ASG có scheduled scaling actions — lên lịch thay đổi số lượng instance vào giờ định trước — nhưng đó là lịch co giãn, hoàn toàn khác với cửa sổ bảo trì để vá lỗi. Nhầm hai khái niệm này là lý do phổ biến khiến người học chọn E.

📌 Điểm cần nhớ

• Maintenance window là đặc trưng của managed data service. Trong phạm vi đề này: RDS và ElastiCache có, ELB / EC2 / Auto Scaling không có. Gặp câu hỏi kiểu "tài nguyên nào cần cấu hình maintenance window", hãy lọc ra những dịch vụ mà AWS tự vá engine bên dưới.
• Đọc kỹ "configuration of a maintenance window" chứ không phải "patching". Đề cố tình dùng chữ "system patching" để kéo bạn về EC2; câu hỏi thật là tài nguyên nào có tính năng đó.
• Mô hình trách nhiệm chung là kim chỉ nam. AWS vá phần nền tảng của managed service → cần cửa sổ bảo trì. Khách hàng vá OS trên EC2 → không có cửa sổ bảo trì trên instance.
• Đừng nhầm scheduled scaling của Auto Scaling với maintenance window, cũng đừng nhầm scheduled events của EC2 (thông báo từ AWS) với cửa sổ bảo trì do bạn cấu hình. Cả hai đều là lịch, nhưng chỉ maintenance window mới là khoảng thời gian bạn chọn cho AWS áp bản vá.

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

Người dùng báo lỗi khi kết nối tới một application server chạy trên Amazon EC2 instance, dùng DNS hostname và một custom port (8121). DNS name phân giải ra private IP nằm trong VPC. Câu hỏi: loại log nào xác nhận được người dùng có đang gõ đúng port hay không?

Cụm từ quyết định đáp án là "connect to the correct port" — thứ cần nhìn thấy trong log là destination port của gói tin đi tới network interface của EC2 instance. Cụm thứ hai đáng chú ý là "resolves to a private IP address within the Amazon VPC": kết nối diễn ra thuần tuý ở tầng mạng bên trong VPC, tới thẳng instance, chứ không đi qua một dịch vụ tầng ứng dụng nào. Đề cũng không nhắc tới load balancer hay S3 — đây là lời nhắc ngầm rằng những log gắn với hai dịch vụ đó không tồn tại trong kịch bản này.

Vậy bài toán quy về: chọn loại log ghi lại thông tin IP traffic ở mức network interface, có trường port đích.

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

Đáp án đúng theo tệp là B — VPC Flow Logs.

VPC Flow Logs ghi lại thông tin về IP traffic đi vào và đi ra khỏi các network interface trong VPC. Dữ liệu flow log có thể đẩy sang Amazon CloudWatch Logs hoặc Amazon S3, sau đó truy vấn ở đích đã chọn.

Điểm mấu chốt nằm ở định dạng bản ghi mặc định — một chuỗi các trường ngăn cách bằng dấu cách:

<version> <account-id> <interface-id> <srcaddr> <dstaddr> <srcport> <dstport> <protocol> <packets> <bytes> <start> <end> <action> <log-status>

Bản ghi có sẵn dstaddr và dstport. Chỉ cần lọc flow log của network interface thuộc EC2 instance đó rồi nhìn cột dstport: nếu thấy 8121 thì người dùng gõ đúng port và vấn đề nằm ở chỗ khác (security group, ứng dụng chưa lắng nghe…); nếu thấy một giá trị khác — ví dụ 80 hay 443 — thì đúng là họ đang kết nối sai port. Đây chính là bằng chứng trực tiếp mà đề bài yêu cầu.

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

A. AWS CloudTrail logs — CloudTrail ghi lại hoạt động API trong tài khoản AWS: ai gọi lệnh gì, lúc nào, từ đâu, với tham số nào. Nó thấy được việc ai đó gọi API để tạo hay sửa EC2 instance, security group, VPC… nhưng không thấy được luồng traffic mạng giữa người dùng và instance. Người dùng cuối mở kết nối TCP tới port 8121 không hề sinh ra lời gọi API nào, nên CloudTrail hoàn toàn im lặng về chuyện này. Đây là phương án dễ nhầm nếu chỉ nhớ "CloudTrail là log kiểm toán" mà quên rằng phạm vi của nó là control plane chứ không phải data plane.

C. Elastic Load Balancer access logs — Access log của ELB đúng là ghi chi tiết từng request, bao gồm cả port, và trong một kiến trúc có load balancer thì đây sẽ là nguồn dữ liệu rất hợp lý. Nhưng nó hỏng ở chỗ đề bài không hề nhắc tới ELB nào cả: người dùng kết nối bằng DNS hostname phân giải thẳng ra private IP của instance trong VPC. Không có load balancer đứng trước thì không có access log để đọc. Đây là phương án gần đúng nhất — nó chỉ sai vì thành phần sinh ra log ấy không tồn tại trong kịch bản.

D. Amazon S3 access logs — Server access logging của S3 ghi lại các request tới bucket S3: ai đọc/ghi object nào, kết quả ra sao. Nó gắn với một dịch vụ lưu trữ object hoàn toàn khác, không quan sát traffic mạng chạy tới một EC2 server. Lưu ý một điểm dễ gây rối: S3 có thể là đích lưu trữ của VPC Flow Logs, nhưng "flow log được lưu trong S3" khác hẳn "S3 access log" — hai thứ này ghi hai loại sự kiện khác nhau.

📌 Điểm cần nhớ

• Cần dữ liệu ở tầng mạng (source/destination IP, source/destination port, protocol, accept/reject) trong VPC → nghĩ ngay tới VPC Flow Logs; đây là loại log duy nhất trong nhóm này nhìn thấy dstport.
• CloudTrail = API activity (control plane), không phải traffic. Câu hỏi hỏi "ai gọi API gì" mới chọn CloudTrail; hỏi "gói tin đi đâu, tới port nào" thì không.
• Access log luôn gắn chặt với dịch vụ sinh ra nó: ELB access logs chỉ tồn tại khi có ELB, S3 access logs chỉ ghi request tới bucket. Dịch vụ không xuất hiện trong đề thì log của nó cũng không phải nguồn dữ liệu hợp lệ.
• Đừng lẫn đích lưu trữ với loại log: VPC Flow Logs có thể xuất sang CloudWatch Logs hoặc S3, nhưng điều đó không biến chúng thành S3 access logs.

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

Đề mô tả một môi trường Elastic Beanstalk được triển khai kèm configuration file chạy một loạt lệnh trên instance. Kết quả trả về là: "Create environment operation is complete, but with command timeouts".

Cụm từ quyết định đáp án chính là "command timeouts" — không phải "environment creation failed", cũng không phải "out of memory" hay "instance unhealthy". Môi trường đã tạo xong, chỉ có điều các lệnh trong configuration file chưa kịp chạy hết trong khoảng thời gian mà Elastic Beanstalk cho phép. Cụm thứ hai cần chú ý là "a series of commands": càng nhiều lệnh, càng lâu — và câu hỏi là làm sao để những lần deploy sau không gặp lại chuyện này.

Khi đề nêu thẳng ra một loại timeout cụ thể, ràng buộc bài toán là thời gian, không phải năng lực xử lý hay kiến trúc. Đây là chìa khoá để loại ba phương án còn lại.

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

B — Increase the command timeout period.

Elastic Beanstalk đặt một giới hạn thời gian cho các lệnh chạy trên instance trong quá trình deploy. Ứng dụng có thể mất rất lâu để triển khai nếu bạn dùng configuration file để chạy lệnh trên instance, tải về các tệp lớn, hoặc cài đặt package. Khi vượt quá giới hạn đó, Elastic Beanstalk báo command timeout — đúng thông điệp trong đề.

Cách chữa trực tiếp là nâng command timeout lên, cho ứng dụng thêm thời gian để chạy xong các lệnh và khởi động trong lúc deploy. Giá trị này chỉnh được trong cấu hình deployment của environment (phần rolling/deployment settings). Vì đây là cấu hình gắn với environment, nó có hiệu lực cho các lần deploy sau — đúng như đề yêu cầu.

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

A — Use the high availability preset. Preset này dựng environment theo hướng sẵn sàng cao: chạy nhiều instance sau load balancer, có Auto Scaling. Nó thay đổi kiến trúc của môi trường chứ không đụng gì tới giới hạn thời gian chạy lệnh. Các lệnh trong configuration file vẫn phải chạy trên từng instance với đúng timeout cũ — thậm chí giờ chạy trên nhiều instance. Vấn đề timeout không được giải quyết.

C — Use a larger instance type with more CPU. Đây là phương án gần đúng nhất và cũng là bẫy chính: nghe hợp lý vì "chạy chậm thì cho máy mạnh hơn". Nhưng nó hỏng ở chỗ giả định sai về nguyên nhân chậm. Đề chỉ nói các lệnh chạy quá lâu, không nói CPU bị nghẽn. Độ trễ rất có thể đến từ việc tải tệp lớn về, cài package từ repository, hoặc gọi ra dịch vụ bên ngoài — những việc bị chặn bởi mạng và bởi phía đầu kia, thêm CPU không rút ngắn được. Chỉ khi nào có bằng chứng CPU bão hoà thì nâng instance mới là hướng đúng; ở đây không có bằng chứng đó.

D — Configure a worker environment. Worker environment là một kiểu môi trường khác, dùng cho tác vụ nền xử lý message từ hàng đợi, tách khỏi luồng request của web tier. Nó giải quyết bài toán "tác vụ dài của ứng dụng làm nghẽn request", chứ không liên quan tới các lệnh chạy trong lúc deploy. Đổi sang worker environment là thay đổi bản chất môi trường mà vẫn không làm command timeout dài thêm một giây nào.

📌 Điểm cần nhớ

• Thông điệp lỗi "command timeout" trong Elastic Beanstalk trỏ thẳng vào một nút chỉnh cụ thể: command timeout period trong cấu hình deployment. Gặp lỗi nêu đích danh một loại timeout, hãy tìm phương án chỉnh đúng timeout đó trước.
• Configuration file chạy lệnh trên instance (cài package, tải tệp lớn, gọi dịch vụ ngoài) là nguyên nhân phổ biến khiến deploy vượt thời gian cho phép.
• Đừng suy ra "chậm ⇒ thiếu CPU". Nâng instance type chỉ đúng khi có dấu hiệu nghẽn tài nguyên; chậm do I/O mạng hay do phía bên ngoài thì máy to hơn không cứu được.
• Phân biệt rõ hai lớp vấn đề: web/worker environment và high availability preset thuộc về kiến trúc môi trường; command timeout thuộc về quy trình deploy. Đổi kiến trúc không sửa được lỗi của quy trình deploy.

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

Một website chạy trên Amazon EC2 và dùng Amazon RDS bị chậm vào giờ cao điểm. SysOps Administrator nghi ngờ nguyên nhân là CPU usage cao ở một trong các thành phần, và câu hỏi là: phải điều tra bằng cách nào để biết thành phần nào đang gây nghẽn.

Cụm từ quyết định đáp án là "high CPU usage" đi kèm "which component is causing the performance bottleneck". Đây không phải câu hỏi về bảo mật, cũng không phải câu hỏi "ai đã gọi API nào". Nó hỏi về số đo hiệu năng của tài nguyên (resource utilization metrics) và cần so sánh giữa các thành phần (EC2 với RDS) để khoanh vùng.

Một chi tiết nữa cần bám: đề nói "investigate" — tức là dữ liệu đó phải đã có sẵn để tra cứu, chứ không phải một thứ ta phải dựng lên rồi chờ. Đây chính là ràng buộc loại bớt các phương án nghe có vẻ hợp lý.

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

Đáp án đúng là C — Use Amazon CloudWatch metrics to examine the resource usage of each component.

Amazon CloudWatch metrics là nơi lưu trữ và hiển thị dữ liệu hiệu năng của hệ thống. Theo phần giải thích gốc: mặc định nhiều dịch vụ AWS tự động phát metrics miễn phí cho tài nguyên của chúng — trong đó có chính hai thành phần trong đề bài là Amazon EC2 instances và Amazon RDS DB instances (kèm cả Amazon EBS volumes). Nghĩa là dữ liệu CPU utilization của cả EC2 lẫn RDS đã nằm sẵn trong CloudWatch mà không cần cấu hình gì thêm.

Ngoài metrics mặc định, còn có thể bật detailed monitoring cho một số tài nguyên như EC2 instances để lấy dữ liệu ở độ phân giải dày hơn, hoặc publish metrics của chính ứng dụng lên CloudWatch. CloudWatch nạp toàn bộ metrics trong tài khoản — cả metrics của tài nguyên AWS lẫn metrics do ứng dụng gửi lên — để search, vẽ đồ thị (graphing) và đặt alarm.

Đúng là thứ SysOps Administrator cần: mở CloudWatch, vẽ chồng đường CPU của EC2 và của RDS lên cùng khoảng thời gian "busy periods", rồi nhìn xem đường nào vọt lên. Thành phần nào có CPU tăng khớp với lúc website chậm chính là thành phần gây nghẽn.

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

A — Use Amazon CloudWatch Logs and Amazon Athena to search for utilization data. Đây là phương án gần đúng nhất và cũng là cái bẫy chính, vì nó có chữ "CloudWatch". Nhưng nó hỏng ở chỗ nhầm CloudWatch Logs với CloudWatch metrics — hai thứ khác nhau trong cùng một dịch vụ. Như giải thích gốc nêu: dữ liệu utilization không được ghi vào log file trong CloudWatch Logs. CloudWatch Logs chứa các dòng log do ứng dụng hay hệ điều hành sinh ra, còn số đo CPU là dạng time-series nằm ở phần metrics. Athena thì là công cụ truy vấn dữ liệu, nhưng có truy vấn giỏi tới đâu cũng không moi ra được thứ chưa hề được ghi vào đó.

B — Use Amazon Inspector to view the detailed resource usage for each component. Sai về bản chất dịch vụ. Amazon Inspector là dịch vụ đánh giá bảo mật tự động (automated security assessment), giúp cải thiện mức độ bảo mật và tuân thủ của ứng dụng triển khai trên AWS. Nó tìm lỗ hổng và vấn đề an ninh, không đo CPU utilization. Cụm "detailed resource usage" trong phương án nghe rất khớp với đề, nhưng đó là câu chữ được gài vào chứ không phải chức năng thật của Inspector.

D — Use AWS CloudTrail to review the API usage metrics for each component. Cũng là bẫy chữ nghĩa: "API usage metrics" nghe như một loại số đo. Nhưng CloudTrail ghi lại các hành động API (API actions) — ai gọi gì, lúc nào, từ đâu — chứ không ghi metrics hiệu năng. CloudTrail trả lời câu hỏi kiểm toán ("ai đã reboot instance này?"), không trả lời câu hỏi "CPU của instance này đang bao nhiêu phần trăm". Dùng CloudTrail để tìm nghẽn CPU là tra sai loại dữ liệu ngay từ đầu.

📌 Điểm cần nhớ

• Hiệu năng → CloudWatch metrics; kiểm toán ai gọi API → CloudTrail. Đây là cặp phân biệt xuất hiện đi xuất hiện lại trong đề thi. Thấy từ khoá CPU, memory, disk, latency, utilization thì nghĩ tới metrics; thấy "who did what", "audit", "API call history" thì mới là CloudTrail.
• CloudWatch Logs khác CloudWatch metrics. Cùng một dịch vụ nhưng hai kho dữ liệu khác nhau: Logs chứa dòng văn bản do ứng dụng/OS ghi ra, metrics chứa số đo time-series. Số liệu utilization của tài nguyên AWS nằm ở metrics, nên đưa Athena vào để "search log tìm CPU" là hướng sai.
• EC2 và RDS đều phát metrics mặc định lên CloudWatch. Nhờ vậy có thể so sánh nhiều thành phần trên cùng một trục thời gian để khoanh vùng nghẽn, không cần cài thêm gì. Muốn dữ liệu dày hơn cho EC2 thì bật detailed monitoring; muốn số đo cấp ứng dụng thì tự publish custom metrics.
• Đọc kỹ tên dịch vụ, đừng đọc lướt phần mô tả đi kèm. Phương án hay ghép một dịch vụ sai với một mô tả đúng ý đề ("Inspector — detailed resource usage", "CloudTrail — usage metrics"). Cách chống bẫy là tự hỏi dịch vụ này sinh ra để làm gì trước khi đọc vế mô tả: Inspector là security assessment, thế là đủ để loại.

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

Đề mô tả một môi trường quen thuộc: vài EC2 Linux instance chạy trong VPC, dùng RDS làm cơ sở dữ liệu, và đi ra Internet qua một NAT gateway. Nhưng toàn bộ phần mô tả đó chỉ là bối cảnh — thứ quyết định đáp án nằm ở vế sau: "Based on the shared responsibility model, AWS is responsible for managing which element".

Hai cụm từ phải bám chặt:

• "shared responsibility model" — câu hỏi không hỏi cái gì tốt hơn về kỹ thuật, mà hỏi ai chịu trách nhiệm. Ranh giới ở đây là: AWS lo security of the cloud (hạ tầng vật lý, phần cứng, phần mềm nền của các managed service), khách hàng lo security in the cloud (dữ liệu, cấu hình, hệ điều hành, quyền truy cập).
• "AWS is responsible" — chiều của câu hỏi. Ba trong bốn phương án là việc của khách hàng; chỉ cần xác định phương án nào rơi vào phần hạ tầng do AWS vận hành.

Điểm gài của câu này là NAT gateway xuất hiện ở hai phương án (A và D) với hai khía cạnh khác nhau của cùng một dịch vụ: tính sẵn sàng của bản thân dịch vụ và việc cấu hình dịch vụ đó vào kiến trúc. Hai thứ này nằm ở hai phía khác nhau của đường ranh giới.

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

Đáp án đúng là A — Ensuring high availability of the NAT gateway.

NAT gateway là một AWS managed device. Khách hàng không cài đặt phần mềm NAT, không vá lỗi, không tự dựng cụm dự phòng, không thay phần cứng khi hỏng. AWS xây dựng NAT gateway sao cho nó dư thừa và có tính sẵn sàng cao trong phạm vi Availability Zone mà nó được đặt — đó là phần "of the cloud" thuộc trách nhiệm AWS.

Nói cách khác: khách hàng quyết định có dùng NAT gateway hay không và đặt nó ở đâu, còn việc bản thân dịch vụ NAT gateway đó có chạy ổn định hay không là việc AWS phải bảo đảm. Đó chính xác là điều phương án A phát biểu.

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

B — Configuring encryption settings for RDS database data. Đây là phương án dễ nhầm nhất với người mới, vì RDS là managed service nên phản xạ đầu tiên là "vậy AWS lo hết". Không đúng. AWS lo tầng dưới của RDS: máy chủ vật lý, hypervisor, cài đặt và vá engine, sao lưu tự động ở mức hạ tầng. Nhưng dữ liệu là của khách hàng, và cấu hình mã hoá — bật encryption at rest khi tạo instance, chọn KMS key nào, bật bắt buộc SSL/TLS cho kết nối — là quyết định và thao tác của khách hàng. Động từ trong phương án là "configuring", tức là hành vi cấu hình, luôn nằm ở phía khách hàng.

C — Managing the health of the Linux operating systems. Sai rõ ràng nhất. Với EC2, ranh giới trách nhiệm nằm ngay dưới hệ điều hành: AWS chịu trách nhiệm phần cứng và lớp ảo hoá, còn từ guest OS trở lên là của khách hàng — vá lỗi kernel, cập nhật gói, cấu hình firewall trong máy, theo dõi tình trạng OS. EC2 là dịch vụ IaaS, khác hẳn RDS ở chỗ khách hàng có quyền và có nghĩa vụ với hệ điều hành. Chọn C là nhầm EC2 với một dịch vụ managed.

D — Configuring the route table với NAT gateway ID. Đây là phương án gần đúng nhất và là bẫy chính của câu. Nó nhắc đúng NAT gateway — cùng dịch vụ với đáp án A — nên rất dễ tưởng cũng thuộc AWS. Nhưng nó hỏng ở chỗ nói về việc cấu hình: dù NAT gateway là AWS managed device, khách hàng vẫn phải tự tạo nó cho đúng, đặt vào public subnet, rồi thêm route 0.0.0.0/0 trỏ tới NAT gateway ID trong route table của private subnet. AWS không biết và không được phép quyết định lưu lượng nào trong VPC của bạn đi đường nào. Cấu hình VPC, subnet, route table, security group — tất cả đều là security "in" the cloud. So sánh trực tiếp: A nói về bản thân dịch vụ có sẵn sàng không (AWS), D nói về dịch vụ đó được gắn vào kiến trúc ra sao (khách hàng).

📌 Điểm cần nhớ

• Ranh giới của shared responsibility model: AWS lo security of the cloud, khách hàng lo security in the cloud. Gặp câu dạng này, việc đầu tiên là xác định câu hỏi đang hỏi chiều nào.
• Động từ trong phương án là manh mối rất mạnh. "Configuring", "managing settings", "choosing", "enabling" gần như luôn thuộc về khách hàng; "ensuring availability", "patching the hypervisor", "physical security" thuộc về AWS.
• Một dịch vụ managed như NAT gateway hay RDS có thể xuất hiện ở cả hai phía: AWS bảo đảm dịch vụ chạy, khách hàng chịu trách nhiệm cấu hình và dữ liệu đưa vào đó. Đừng thấy tên dịch vụ managed là kết luận ngay.
• Với EC2, mọi thứ từ guest OS trở lên — vá lỗi, cập nhật, tình trạng hệ điều hành, ứng dụng — là của khách hàng. Đây là khác biệt cốt lõi giữa IaaS (EC2) và các dịch vụ managed như RDS.

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

Đề mô tả một ứng dụng chạy trên EC2 instances trong Auto Scaling group, và Auto Scaling group được cấu hình terminate EC2 instances khi có scale-in event. Yêu cầu: SysOps Administrator phải giữ lại được application logs của những instance đã bị terminate.

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

• "application logs" — không phải log hệ thống, không phải log mạng. Đây là log do chính ứng dụng ghi ra file trên ổ đĩa của instance.
• "instances that have been terminated" — instance bị xoá thì volume gốc (root EBS volume mặc định là DeleteOnTermination = true) và toàn bộ file bên trong biến mất theo. Nghĩa là log phải được đẩy ra khỏi instance từ trước lúc terminate, và phải liên tục — không phải hành động chạy tại thời điểm terminate.

Scale-in xảy ra bất kỳ lúc nào Auto Scaling quyết định thu nhỏ nhóm; không có mốc nào để "chờ đến khi sắp chết mới gom log". Vậy nên đây là bài toán streaming log ra ngoài liên tục (log shipping), chứ không phải bài toán sao lưu theo sự kiện.

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

B — Configure the unified CloudWatch agent to stream the logs to Amazon CloudWatch Logs.

Unified CloudWatch agent là agent cài trên chính EC2 instance, đọc các file log được khai báo trong cấu hình và đẩy chúng lên CloudWatch Logs gần như theo thời gian thực. Vì log đã nằm ở CloudWatch Logs — một dịch vụ hoàn toàn tách khỏi vòng đời của instance — nên khi instance bị terminate:

• Log stream đã cập nhật tới sát thời điểm terminate, phần lớn dữ liệu đã an toàn ở ngoài.
• Log vẫn còn nguyên trong log group để troubleshooting và phân tích về sau, dù instance không còn tồn tại.

Đây đúng là cơ chế mà bản giải thích gốc chỉ ra: agent bắt log (và cả custom metrics) rồi giao cho CloudWatch Logs, nên trạng thái log không phụ thuộc vào việc instance còn sống hay không.

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

A — VPC Flow Logs cho subnet, publish sang Amazon S3. Sai vì nhầm loại log. VPC Flow Logs ghi lại metadata của lưu lượng mạng đi vào/ra network interface trong subnet: địa chỉ nguồn, đích, cổng, giao thức, chấp nhận hay bị chặn. Nó không hề đọc được file log do ứng dụng ghi trên instance. Đúng là dữ liệu này tồn tại độc lập với instance thật, nhưng nội dung nó giữ lại không phải thứ đề yêu cầu.

C — CloudWatch Events rule chuyển log sang Amazon S3 khi EC2 đổi trạng thái sang terminated. Đây là phương án gần đúng nhất và cũng là bẫy chính, hỏng ở hai điểm:

1. CloudWatch Events (EventBridge) chỉ phát ra một sự kiện và kích hoạt target; không có kiểu target nào "sao chép file log" từ bên trong instance ra S3. Muốn làm được thì phải có thứ chạy bên trong instance để đẩy file đi — mà chính thứ đó mới là lời giải, không phải cái rule.
2. Ngay cả khi ghép thêm cơ chế chạy lệnh từ xa, sự kiện terminated chỉ đến khi instance đã terminate rồi — lúc đó ổ đĩa và hệ điều hành không còn để mà lấy log ra. Bắt đúng khoảnh khắc này là chạy đua với vòng đời instance, không phải một thiết kế đáng tin.

D — Script gom log chạy mỗi giờ bằng cron. Về nguyên tắc thì hướng đi đúng (đẩy log ra khỏi instance trước khi nó chết), nhưng hỏng ở tần suất và công sức vận hành. Chu kỳ một giờ để lại một khoảng trống: mọi log sinh ra sau lần chạy cuối cùng và trước lúc scale-in sẽ mất theo instance — mà đó thường là đúng đoạn log cần nhất khi điều tra sự cố. Ngoài ra đây là giải pháp tự viết, tự bảo trì trong khi unified CloudWatch agent đã làm sẵn việc này ở dạng liên tục.

📌 Điểm cần nhớ

• Log cần sống lâu hơn instance thì phải stream ra dịch vụ bên ngoài liên tục, không đợi đến sự kiện terminate mới xử lý — instance trong Auto Scaling group có thể bị thu hồi bất kỳ lúc nào.
• Phân biệt rõ ba loại log hay bị trộn trong đề thi: VPC Flow Logs = lưu lượng mạng; CloudTrail = lời gọi API; application/system log trên instance = phải có unified CloudWatch agent mới lấy ra được.
• CloudWatch Events / EventBridge phản ứng với sự kiện, chứ không tự di chuyển file từ bên trong instance. Thấy phương án kiểu "khi trạng thái đổi thì copy log sang S3" thì nên nghi ngờ ngay.
• Giải pháp thủ công theo chu kỳ (cron) luôn để lại khoảng trống dữ liệu bằng đúng chu kỳ chạy; khi đề nhấn mạnh "retain logs from terminated instances", cơ chế gần thời gian thực là lựa chọn được ưu tiên.

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

Bối cảnh: một ứng dụng web chạy trên một EC2 instance duy nhất. Người dùng than phiền chậm vào giờ cao điểm, và CloudWatch metrics cho thấy CPU của instance đó thường xuyên vượt 90% đúng trong những khung giờ đó.

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

• "during peak business hours" — tải không cao đều mà dao động theo thời điểm. Vấn đề không phải "máy yếu" mà là "công suất cố định gặp tải biến thiên". Thứ giải quyết được kiểu tải này là năng lực co giãn theo nhu cầu, không phải một lần nâng cấp cứng.
• "MOST operationally efficient" — tiêu chí chấm không phải "cái nào có tác dụng", mà cái nào tốn ít công vận hành nhất về sau. Cụm này loại thẳng mọi phương án cần con người can thiệp hoặc cần code tự viết để duy trì.

Ghép hai ràng buộc lại: đề đang hỏi cách để hệ thống tự thêm/bớt công suất theo CPU mà không cần ai trực.

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

A — Auto Scaling group gắn với Application Load Balancer, dùng target tracking scaling policy theo average CPU utilization của group.

Phương án này xử lý cả hai vế của bài toán:

• Application Load Balancer phân phối traffic ra nhiều instance, nên tải không còn dồn hết vào một máy. Đây là điều kiện cần: có nhân bản thì mới có chỗ để đổ tải sang.
• Auto Scaling group thay đổi số lượng instance theo nhu cầu — thêm máy khi vào giờ cao điểm, bớt máy khi hết giờ. Đây là horizontal scaling.
• Target tracking scaling policy là phần trả lời trực tiếp cho "operationally efficient": người vận hành chỉ khai một con số mục tiêu (ví dụ average CPU utilization mong muốn), phần còn lại — theo dõi metric, quyết định thêm bớt bao nhiêu, khi nào — do chính chính sách lo. Không phải viết logic scaling, không phải chỉnh ngưỡng lên xuống bằng tay, không ai phải thức đêm.

Ngoài ra, tổ hợp ALB + Auto Scaling group còn xử lý được cả trường hợp một instance chết, chứ không chỉ chuyện chậm — nhưng điểm chính vẫn là nó tự điều chỉnh công suất mà không cần thao tác vận hành lặp lại.

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

B — AWS Site-to-Site VPN để người dùng nối thẳng tới private IP của EC2 instance. Sai về bản chất vấn đề. Site-to-Site VPN tạo kết nối bảo mật giữa mạng on-premises và VPC; nó thuộc phạm trù kết nối mạng và bảo mật, không liên quan gì tới CPU. Instance vẫn chỉ có một, CPU vẫn vượt 90% vào giờ cao điểm, và độ trễ ở đây sinh ra từ máy quá tải chứ không phải từ đường truyền. Thay đổi đường đi của gói tin không làm CPU bớt bận.

C — Bật CloudWatch logs và đặt CloudWatch alarm báo khi CPU vượt 90%. Đây là phương án gần đúng nhất về mặt "đúng metric, đúng ngưỡng" — nó nhìn vào chính con số mà đề nêu ra. Nhưng nó hỏng ở chỗ: alarm chỉ thông báo, không hành động. Sau khi cấu hình xong, ứng dụng vẫn chậm y như cũ; khác biệt duy nhất là bây giờ SysOps administrator biết là nó đang chậm. Với tiêu chí "most operationally efficient", phương án này còn đi ngược lại: nó tạo ra công việc thủ công lặp lại mỗi giờ cao điểm thay vì loại bỏ công việc đó.

D — CloudWatch alarm ở ngưỡng 80% kích hoạt Lambda function để vertical scaling instance. Đây là bẫy tinh vi nhất, vì nó có hành động chứ không chỉ báo động. Nhưng nó hỏng ở ba chỗ:

• Vertical scaling đòi thay đổi kích thước instance, mà đổi instance type là thao tác gây gián đoạn dịch vụ — đúng lúc cao điểm lại làm ứng dụng đứt quãng, tức là chữa bệnh bằng cách gây thêm bệnh.
• Kiến trúc vẫn là một instance duy nhất: không có dự phòng, và có một trần cứng — đến kích thước lớn nhất thì hết đường lên. Horizontal scaling không có trần kiểu đó.
• Lambda function tự viết là code phải bảo trì: xử lý lỗi, tránh chạy chồng, quyết định khi nào scale xuống. Toàn bộ phần đó đã có sẵn và được AWS vận hành hộ trong target tracking scaling policy. Tự dựng lại nghĩa là kém "operationally efficient" hơn hẳn.

📌 Điểm cần nhớ

• "MOST operationally efficient" = ít việc thủ công và ít code tự viết nhất về sau. Gặp cụm này, ưu tiên tính năng có sẵn được quản lý (managed) hơn là script/Lambda tự dựng, dù cả hai đều chạy được.
• Tải dao động theo giờ → horizontal scaling, không phải vertical. Auto Scaling group + load balancer là cặp đôi mặc định; vertical scaling gây gián đoạn khi resize, có trần cứng và không tạo dự phòng.
• Alarm chỉ báo, không sửa. CloudWatch alarm đứng một mình gần như luôn là phương án sai khi đề hỏi "giải quyết vấn đề" — nó chỉ đúng khi đề hỏi "làm sao biết được".
• Đọc kỹ vấn đề thuộc tầng nào. CPU cao là bài toán compute; các phương án về kết nối mạng như Site-to-Site VPN đưa ra để đánh lạc hướng bằng chữ "latency", nhưng không chạm tới nguyên nhân.