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

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

Đề mô tả một tình huống rất cụ thể: lập trình viên gọi lệnh xoá một CloudFormation stack, nhưng kết quả trả về không có lỗi, cũng không có thông báo thành công, và stack thì vẫn còn nguyên.

Cụm từ quyết định đáp án nằm ở chỗ: "returned without any error or a success message. The stack was not deleted either." — tức là thao tác xoá không để lại dấu vết gì trong trạng thái stack.

Đây chính là điểm phân biệt, vì cả bốn phương án đều mô tả những lý do có thật khiến việc xoá stack không thành công. Nhưng ba trong số đó thuộc nhóm lỗi xảy ra trong quá trình xoá — mà bất kỳ lỗi nào phát sinh khi CloudFormation đã bắt đầu tháo dỡ tài nguyên đều đẩy stack sang trạng thái DELETE_FAILED kèm thông điệp lỗi. Còn tình huống trong đề là việc xoá bị chặn ngay từ đầu, stack giữ nguyên trạng thái cũ. Nhận ra sự khác nhau giữa "xoá thất bại giữa chừng" và "xoá bị từ chối ngay từ đầu" là chìa khoá của câu này.

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

Đáp án D — termination protection đang bật.

CloudFormation không cho phép xoá một stack đã bật termination protection. Khi cơ chế này bật, yêu cầu xoá bị từ chối, và stack cùng trạng thái của nó giữ nguyên không đổi — không chuyển sang DELETE_IN_PROGRESS, cũng không sang DELETE_FAILED. Đó chính xác là triệu chứng đề mô tả: không lỗi rõ ràng về tình trạng stack, không thành công, stack vẫn nằm đó.

Cách sửa: tắt termination protection trên stack rồi thực hiện lại thao tác xoá.

Điều này áp dụng cho cả nested stack có root stack đang bật termination protection — muốn xoá thì phải tắt bảo vệ ở root stack. Ngoài ra, AWS khuyến nghị mạnh là không xoá nested stack trực tiếp, mà chỉ xoá chúng như một phần của việc xoá root stack cùng toàn bộ tài nguyên của nó.

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

A. Người dùng không đủ quyền. Đây là nguyên nhân có thật khiến xoá stack hỏng, nhưng triệu chứng khác hẳn. Khi thiếu quyền, AWS hiển thị lỗi giải thích rõ ràng và stack rơi vào trạng thái DELETE_FAILED. Đề nói rõ là không có lỗi nào và stack không đổi trạng thái — nên loại.

B. Một số tài nguyên phải rỗng mới xoá được. Vế đầu của phương án này hoàn toàn đúng về mặt kỹ thuật: bạn phải xoá hết object trong một S3 bucket, hoặc gỡ hết instance khỏi một EC2 security group, trước khi xoá được bucket hay security group đó. Chỗ hỏng nằm ở vế sau — nó khẳng định việc xoá "thất bại mà không có lỗi nào". Thực tế thì stack chuyển sang DELETE_FAILED và có thông báo. Đây là phương án gài bẫy khéo nhất: kiến thức đúng, nhưng triệu chứng gắn vào thì sai.

C. Phải xoá tài nguyên phụ thuộc trước. Cũng hỏng ở đúng chỗ như B: nó tuyên bố việc sai thứ tự khiến stack deletion "fails without an error". Nguyên tắc chung là bất kỳ lỗi nào trong quá trình xoá stack cũng đưa stack về DELETE_FAILED. Không có chuyện thất bại im lặng ở đây. Thêm nữa, việc quản lý thứ tự phụ thuộc vốn là việc của chính CloudFormation, không phải thứ người dùng phải tự tay làm trước.

📌 Điểm cần nhớ

• Phân biệt hai loại thất bại: xoá bị từ chối ngay từ đầu (termination protection → stack và trạng thái không đổi) so với xoá thất bại giữa chừng (thiếu quyền, tài nguyên chưa rỗng, ràng buộc phụ thuộc → DELETE_FAILED kèm lỗi).
• Quy tắc gọn để nhớ: mọi lỗi phát sinh trong lúc xoá stack đều dẫn tới DELETE_FAILED. Đề mà nói "không có lỗi, stack không đổi" thì gần như chắc chắn là termination protection.
• Cách sửa termination protection là tắt nó rồi xoá lại, chứ không phải dùng force hay xoá thủ công từng tài nguyên.
• Với nested stack: termination protection phải tắt ở root stack, và nên xoá nested stack thông qua việc xoá root stack chứ không xoá trực tiếp.
• Tài nguyên phải rỗng trước khi xoá (S3 bucket còn object, EC2 security group còn instance) là kiến thức đúng và hay được hỏi — chỉ cần nhớ nó gây ra DELETE_FAILED có lỗi, không phải thất bại im lặng.

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

Đề mô tả một công ty phân tích dữ liệu, quy định nội bộ đòi mã hoá dữ liệu trên mọi kênh liên lạc, và hỏi phải cấu hình thế nào cho kênh giữa người xem – CloudFront – S3.

Cụm từ quyết định nằm ở câu: "An Amazon S3 bucket is configured as a website endpoint and this is now being added as a custom origin for CloudFront". Chi tiết này mới là mấu chốt, không phải phần nói về compliance.

Có hai cách dùng S3 làm origin cho CloudFront, và chúng cư xử khác hẳn nhau:

• REST endpoint (bucket.s3.amazonaws.com), khai báo dưới dạng S3 origin: hỗ trợ HTTPS, CloudFront chuyển tiếp bằng đúng giao thức mà viewer đã dùng.
• Website endpoint (bucket.s3-website-<region>.amazonaws.com), khai báo dưới dạng custom origin: S3 static website hosting chỉ phục vụ HTTP, không có HTTPS.

Đề đã nói rõ là trường hợp thứ hai. Vì vậy đoạn CloudFront → origin không thể là HTTPS, và câu hỏi thực chất kiểm tra xem thí sinh có nhận ra giới hạn đó hay không, thay vì kiểm tra kiến thức về compliance.

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

Đáp án đúng theo tệp là C — cấu hình CloudFront bắt buộc viewer dùng HTTPS, còn CloudFront và S3 vẫn liên lạc bằng HTTP.

Đây là điều duy nhất có thể làm được trong tình huống đề đưa ra:

• Phần viewer → CloudFront hoàn toàn nằm trong tầm kiểm soát: đặt Viewer Protocol Policy thành Redirect HTTP to HTTPS hoặc HTTPS Only. Đây cũng là đoạn đi qua Internet công cộng, tức đoạn thực sự cần được bảo vệ.
• Phần CloudFront → S3 website endpoint thì không có lựa chọn nào khác ngoài HTTP, vì bản thân website endpoint của S3 không nhận kết nối HTTPS. Với custom origin, Origin Protocol Policy chỉ có thể để HTTP Only; chọn HTTPS Only hay Match Viewer sẽ khiến CloudFront không kết nối được tới origin và trả lỗi.

Nói cách khác, C không phải là "phương án lười" mà là mô tả đúng hành vi bắt buộc của kiến trúc này. Đề hỏi "how will you secure this channel" — câu trả lời trung thực là: siết HTTPS ở phía viewer, và chấp nhận HTTP ở đoạn trong AWS vì cấu hình origin hiện tại không cho phép gì hơn.

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

A — "Liên lạc giữa CloudFront và S3 luôn là HTTP vì mạng nội bộ AWS vốn đã an toàn"

Phương án này đúng một nửa về kết quả (đoạn đó đúng là HTTP trong trường hợp này) nhưng sai ở lý do, và quan trọng hơn là nó không đề xuất bất kỳ hành động nào cho phía viewer. Đề yêu cầu mã hoá mọi kênh; trả lời "không cần làm gì vì mạng AWS an toàn" là bỏ luôn đoạn Internet công cộng. Ngoài ra khẳng định "luôn là HTTP" cũng sai: nếu origin là S3 REST endpoint hỗ trợ HTTPS thì CloudFront hoàn toàn dùng HTTPS được.

B — "Bắt viewer dùng HTTPS, đồng thời cấu hình S3 bucket chỉ hỗ trợ HTTPS để ép CloudFront cũng dùng HTTPS"

Đây là phương án gần đúng nhất và là bẫy chính. Nó hỏng ở vế thứ hai: khi bucket được cấu hình làm website endpoint, S3 không hỗ trợ kết nối HTTPS tại endpoint đó, nên không có cách nào "cấu hình bucket chỉ hỗ trợ HTTPS" để ép CloudFront. Chọn B tức là giả định có thể bật một công tắc không tồn tại trong cấu hình mà đề mô tả.

D — "CloudFront luôn chuyển tiếp request tới S3 bằng đúng giao thức viewer đã dùng, nên chỉ cần bắt viewer dùng HTTPS"

Câu mô tả này đúng — nhưng chỉ đúng khi origin là S3 bucket hỗ trợ HTTPS (REST endpoint). Áp vào website endpoint thì sai, vì không có giao thức HTTPS để chuyển tiếp. D nguy hiểm ở chỗ nó dẫn tới kết luận sai: người làm bài tưởng rằng chỉ cần siết phía viewer là tự động có HTTPS đầu-cuối, trong khi thực tế đoạn sau vẫn là HTTP. Phần hành động của D trùng với C, nhưng lời giải thích đi kèm mô tả sai hành vi hệ thống.

📌 Điểm cần nhớ

• S3 có hai loại endpoint và chúng không thay thế nhau được: REST endpoint (S3 origin) hỗ trợ HTTPS; website endpoint (khai báo dưới dạng custom origin) chỉ phục vụ HTTP. Thấy chữ "website endpoint" trong đề là phải loại ngay mọi phương án đòi HTTPS ở đoạn CloudFront → S3.
• Kênh viewer → CloudFront và kênh CloudFront → origin cấu hình độc lập: Viewer Protocol Policy và Origin Protocol Policy là hai nút riêng. Siết HTTPS ở phía viewer không tự động tạo ra HTTPS ở phía origin.
• "CloudFront chuyển tiếp bằng đúng giao thức của viewer" là mệnh đề có điều kiện, chỉ áp dụng khi origin thực sự hỗ trợ HTTPS. Các đề trắc nghiệm hay lấy nguyên câu này làm distractor.
• Khi hai phương án đề xuất cùng một hành động nhưng kèm hai lời giải thích khác nhau (như C và D ở đây), hãy chấm điểm phần giải thích — phương án mô tả đúng hành vi hệ thống mới là đáp án.

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

Đề đặt bạn vào vai SysOps Administrator và yêu cầu lập báo cáo về tất cả các API call đã thực hiện cho Elastic Load Balancer, phát sinh từ AWS Management Console.

Cụm từ quyết định là "all API calls made ... from the AWS Management Console". Ba chữ này khoanh vùng rất hẹp:

• API calls — tức là các hành động quản trị lên chính load balancer (tạo, sửa listener, đổi target group, xoá LB), chứ không phải các HTTP request của người dùng cuối đi qua load balancer.
• from the AWS Management Console — nhấn mạnh nguồn gốc của thao tác là con người bấm nút trên Console, chứ không phải lưu lượng ứng dụng.

Bẫy nằm ở chỗ ba phương án còn lại đều là những cơ chế quan sát rất quen thuộc của ELB, nhưng chúng đều nhìn vào lưu lượng đi qua load balancer hoặc hiệu năng của nó, không nhìn vào ai đã cấu hình gì trên nó. Phân biệt được "traffic plane" và "control plane" là xong câu này.

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

D — CloudTrail logs. Elastic Load Balancing được tích hợp sẵn với AWS CloudTrail, dịch vụ ghi lại hồ sơ các hành động do một user, một role hay một dịch vụ AWS thực hiện. CloudTrail bắt mọi API call của Elastic Load Balancing dưới dạng event, bao gồm cả lời gọi phát sinh khi người quản trị thao tác trên AWS Management Console lẫn lời gọi trực tiếp tới ELB API bằng code — đúng khớp với yêu cầu của đề.

Về mặt vận hành: nếu bạn tạo một trail, CloudTrail có thể liên tục chuyển event xuống một S3 bucket, kể cả event của Elastic Load Balancing — rất tiện cho việc tổng hợp thành báo cáo. Nếu không cấu hình trail, bạn vẫn xem được các event gần đây trong mục Event history của CloudTrail console.

Thông tin CloudTrail thu được cho phép xác định: request nào đã gửi tới Elastic Load Balancing, gửi từ địa chỉ IP nào, ai gửi, gửi khi nào, cùng các chi tiết khác. Đó chính là bộ dữ liệu cần có cho một báo cáo audit về API call.

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

A — CloudWatch metrics. CloudWatch cho phép lấy số liệu thống kê về load balancer và các target dưới dạng chuỗi thời gian có thứ tự (metrics), dùng để kiểm chứng hệ thống có đang chạy đúng như kỳ vọng hay không. Đây là dữ liệu số đo tổng hợp về hiệu năng và tình trạng, không phải bản ghi từng hành động quản trị. Metric không cho biết ai đã sửa listener lúc mấy giờ.

B — Load Balancer Request tracing. Request tracing dùng để theo dõi các HTTP request: load balancer chèn thêm một header chứa trace identifier vào mỗi request nó nhận được. Đây là công cụ lần vết một request cụ thể xuyên qua hệ thống khi gỡ lỗi, hoàn toàn thuộc về lưu lượng ứng dụng — không liên quan gì tới API call quản trị từ Console.

C — Load Balancer Access logs. Đây là phương án gần đúng nhất và cũng dễ chọn nhầm nhất, vì nó có chữ "logs" và cũng ghi ra file trong S3. Nhưng access logs bắt thông tin chi tiết về các request gửi tới load balancer — tức là traffic của client — để phân tích mẫu lưu lượng và gỡ lỗi phía target. Chỗ nó hỏng so với đề: đề hỏi API call lên dịch vụ ELB phát sinh từ Management Console, còn access log hoàn toàn không ghi nhận việc một quản trị viên đăng nhập Console rồi thay đổi cấu hình.

📌 Điểm cần nhớ

• Hỏi "ai đã làm gì, khi nào, từ đâu" với một dịch vụ AWS → nghĩ ngay tới CloudTrail. Đây là phản xạ dùng được cho hầu hết các câu về audit, không riêng ELB.
• Phân biệt hai mặt phẳng: CloudTrail = control plane (thao tác quản trị lên dịch vụ), còn access logs / request tracing = data plane (lưu lượng của người dùng cuối đi qua load balancer).
• CloudWatch metrics trả lời "hệ thống chạy thế nào", CloudTrail trả lời "ai đã đụng vào". Từ khoá "API calls", "who made the request", "audit" nghiêng về CloudTrail; "latency", "request count", "healthy hosts" nghiêng về CloudWatch.
• Thao tác trên AWS Management Console cũng là API call — Console chỉ là lớp giao diện gọi xuống API, nên CloudTrail vẫn ghi nhận đầy đủ. Đừng nghĩ CloudTrail chỉ bắt được lời gọi từ CLI hay SDK.
• Muốn giữ log lâu dài và tổng hợp thành báo cáo thì tạo trail đẩy về S3; chỉ xem Event history trong console thì chỉ có các event gần đây.

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

Đề mô tả một SysOps Administrator bật versioning trên một S3 bucket sau khi lập trình viên lỡ tay xoá vài object. Câu hỏi: khi một developer xoá object trong bucket đã bật versioning thì điều gì thực sự xảy ra? (Chọn hai)

Cụm từ quyết định đáp án là "versioning-enabled bucket" kết hợp với động từ "deletes an object" — tức là một lệnh DELETE đơn giản, không kèm version ID. Đây chính là ranh giới phân biệt:

• DELETE không kèm versionId trên bucket bật versioning → S3 không xoá dữ liệu, chỉ đặt thêm một delete marker làm version mới nhất (current version).
• DELETE có kèm versionId → mới là xoá vĩnh viễn đúng version đó.

Đề chỉ nói "deletes an object" nên phải hiểu theo vế đầu. Bốn phương án còn lại đều xoay quanh bản chất của delete marker: nó chứa gì, và một GET thường có lấy được nó không. Vậy để chọn đúng, phải nắm chính xác delete marker là placeholder — một thứ gần như rỗng, chứ không phải một bản sao của object.

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

Theo trường dapAnDung, hai phương án đúng là D và E.

D — "A delete marker is set on the deleted object, but the actual object is not deleted": đúng theo đúng định nghĩa của Amazon S3. Delete marker là một placeholder cho một versioned object bị nêu tên trong một simple DELETE request. Vì bucket đang bật versioning, object không bị xoá; delete marker chỉ khiến S3 hành xử như thể nó đã bị xoá. Dữ liệu cũ vẫn nằm nguyên dưới dạng các version trước đó, và xoá delete marker đi là object hiện ra trở lại. Đây chính là lý do việc bật versioning giải quyết được đúng sự cố nêu trong đề (xoá nhầm).

E — "GET requests do not retrieve delete marker objects": cũng đúng. Một GET thông thường trên key đó sẽ không trả về delete marker như một object có nội dung — S3 trả về lỗi "không tìm thấy" (404 Not Found, kèm header cho biết version hiện tại là một delete marker) đối với GET không chỉ định version. Cách duy nhất để liệt kê delete marker cùng các version khác là dùng versions subresource trong request GET Bucket versions (ListObjectVersions).

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

A — "The delete marker has the same data associated with it, as the actual object": sai ở chỗ căn bản nhất. Delete marker không có data gắn với nó — nó là marker, không phải bản sao object. Nếu nó mang cùng dữ liệu thì mỗi lần xoá sẽ nhân đôi dung lượng lưu trữ, điều đó không xảy ra.

B — "A delete marker has a key, version ID and Access Control List (ACL) associated with it": đây là phương án gần đúng nhất và cũng là bẫy chính. Hai phần ba câu này đúng: delete marker có key name và có version ID như bất kỳ object nào khác — chính nhờ version ID mà bạn xoá được riêng delete marker để khôi phục object. Chỗ hỏng nằm ở vế cuối: delete marker không gắn với giá trị ACL nào. Chỉ cần một mệnh đề sai là cả phương án sai — kiểu bẫy "đúng một phần" rất hay gặp trong đề AWS, phải đọc hết câu chứ không dừng ở đoạn nghe quen.

C — "GET requests can retrieve delete marker objects": mâu thuẫn trực tiếp với E, và C với E không thể cùng đúng. Một GET thường không lấy được delete marker; muốn thấy nó phải liệt kê version qua versions subresource. Người chọn C thường nhầm giữa "GET object" và "list object versions" — hai thao tác khác nhau hoàn toàn.

📌 Điểm cần nhớ

• Trên bucket versioning-enabled, DELETE không kèm version ID chỉ tạo delete marker; DELETE có kèm version ID mới xoá vĩnh viễn version đó. Đọc đề xem có nhắc version ID hay không trước khi chọn.
• Delete marker có key và version ID, nhưng không có data và không có ACL. Ba tính chất này là nguồn gốc của hầu hết phương án nhiễu trong nhóm câu về versioning.
• GET thường không trả về delete marker; muốn nhìn thấy delete marker và các version cũ phải dùng versions subresource (GET Bucket versions / ListObjectVersions).
• Khi hai phương án phát biểu ngược nhau (như C và E), chắc chắn một trong hai sai — dùng cặp đó để rút ngắn vùng lựa chọn.
• Cảnh giác phương án "đúng một phần": liệt kê ba thuộc tính mà chỉ hai cái đúng vẫn là phương án sai.

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

Đề mô tả một ứng dụng chạy trên Amazon EC2 đọc message từ Amazon SQS, và team muốn cấu hình Auto Scaling group co giãn dựa trên CloudWatch metrics của SQS queue. Câu hỏi thật sự nằm ở vế cuối: "which feature or dimension of an SQS queue will you pick to collect SQS data from CloudWatch metrics?"

Cụm từ quyết định là "dimension". Đây không phải câu hỏi về chính sách scaling, về ApproximateNumberOfMessagesVisible hay về công thức backlog-per-instance — mà là câu hỏi rất hẹp: trong CloudWatch, muốn lọc ra số liệu của đúng một queue cụ thể thì phải lọc theo chiều (dimension) nào.

Trong CloudWatch, "dimension" là cặp tên/giá trị dùng để định danh duy nhất một luồng metric trong cùng một namespace. Namespace ở đây là AWS/SQS, và điều cần biết là namespace này công bố metric theo chiều nào. Bốn phương án chính là bốn ứng viên cho chiều đó, nên chỉ cần nhớ đúng một sự thật là loại được cả ba phương án còn lại.

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

Đáp án đúng là D — Queue name of the SQS queue should be used to fetch the necessary data from CloudWatch metrics.

QueueName là dimension duy nhất mà Amazon SQS gửi sang CloudWatch. Mọi metric của SQS — ApproximateAgeOfOldestMessage, ApproximateNumberOfMessagesVisible, ApproximateNumberOfMessagesDelayed, NumberOfMessagesDeleted… — đều được phát ra kèm đúng chiều này, nghĩa là mọi thống kê có sẵn đều được lọc theo QueueName. Khi dựng scaling policy cho Auto Scaling group, bạn trỏ CloudWatch alarm vào namespace AWS/SQS với dimension QueueName = <tên queue của bạn>, chọn metric phản ánh độ tồn đọng, rồi cho alarm kích hoạt scaling policy.

Cũng đáng ghi nhớ một lưu ý đi kèm trong tài liệu: một số metric của SQS được tính từ góc nhìn của dịch vụ và có thể bao gồm cả các lần retry, nên AWS khuyến cáo không dựa vào giá trị tuyệt đối của chúng để suy ra trạng thái tức thời của queue. Điều đó không đổi được câu trả lời về dimension, nhưng giải thích vì sao các metric mang tên Approximate….

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

• C — Queue ID: đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì nó nghe rất giống thói quen "định danh bằng ID" ở các dịch vụ khác (instance ID, volume ID, DB identifier). Nhưng SQS không phát ra chiều nào tên là QueueID; CloudWatch chỉ nhận QueueName. Alarm cấu hình theo một dimension không tồn tại sẽ đơn giản là không có datapoint nào, alarm rơi vào trạng thái INSUFFICIENT_DATA và Auto Scaling group không bao giờ co giãn — hỏng im lặng, rất khó lần ra.

• B — key-value pair dạng name:<queue name> và value:<value>: phương án này mô tả đúng hình thức của một CloudWatch dimension (dimension quả thật là cặp tên–giá trị), nhưng sai ở chỗ nó bịa ra một chiều tên là name với một value tuỳ ý. Tên chiều không do người dùng đặt: nó do chính dịch vụ phát metric quy định, và với SQS thì tên đó cố định là QueueName. Nói cách khác, phương án này lấy đúng cái vỏ cú pháp rồi điền sai nội dung.

• A — composite key "Queue Name - Queue ID": CloudWatch cho phép một metric mang nhiều dimension, nên ý tưởng "khoá ghép" nghe hợp lý về mặt kỹ thuật chung. Vấn đề là điều đó phụ thuộc vào từng namespace, và SQS chỉ gửi một chiều duy nhất. Ghép thêm một chiều thứ hai — mà chiều đó lại còn không tồn tại — thì cũng không khớp được với bất kỳ luồng metric nào.

Cả ba phương án sai đều mâu thuẫn với cùng một sự thật: SQS chỉ có duy nhất dimension QueueName.

📌 Điểm cần nhớ

• Namespace AWS/SQS chỉ phát ra một dimension duy nhất: QueueName. Mọi metric SQS đều lọc theo chiều đó, không có Queue ID, không có khoá ghép.
• Dimension trong CloudWatch do dịch vụ phát metric quy định, không phải nhãn tuỳ ý người dùng đặt. Gặp câu hỏi dạng "lọc metric của dịch vụ X theo gì", hãy nhớ lại chiều mà chính dịch vụ đó công bố.
• Alarm trỏ vào dimension sai không báo lỗi — nó chỉ không nhận được datapoint và nằm ở INSUFFICIENT_DATA, khiến Auto Scaling group đứng yên. Đây là kiểu hỏng âm thầm cần kiểm tra khi scaling theo SQS không hoạt động.
• Metric SQS mang tiền tố Approximate vì được tính từ góc nhìn dịch vụ và có thể tính cả retry; dùng chúng để nhận biết xu hướng tồn đọng, đừng coi là số đếm chính xác tại một thời điểm.

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

Đề mô tả một ứng dụng chạy dạng container, đọc/ghi tệp trên một NFS dùng chung. Ứng dụng sinh báo cáo cho từng khách hàng và các báo cáo này phải nằm trong thư mục riêng của từng client, và quan trọng nhất: mỗi thư mục chỉ được truy cập bởi đúng IAM role đã định nghĩa cho thư mục đó.

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

• "client-specific directories" — cần cơ chế ràng buộc từng ứng dụng/từng phiên mount vào một thư mục gốc riêng, chứ không phải mount cả file system rồi tin vào việc ứng dụng tự giữ kỷ luật đường dẫn.
• "accessible only to the IAM roles defined for these directories" — cần một điểm vào (entry point) mà IAM policy có thể trỏ đích danh vào nó, đồng thời áp được identity POSIX cho mọi request đi qua.

Chỉ có một tính năng trong danh sách gộp được cả hai điều kiện đó: Amazon EFS access points.

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

A — Configure Amazon EFS access points.

EFS access point là điểm vào dành riêng cho từng ứng dụng vào một EFS file system, sinh ra đúng để quản lý việc nhiều ứng dụng cùng dùng chung một kho dữ liệu. Nó cho hai thứ mà đề đang cần:

1. Ép root directory riêng. Khi tạo access point bạn chỉ định một thư mục làm gốc; client mount qua access point đó chỉ nhìn thấy thư mục ấy và các thư mục con của nó. Đây chính là cách hiện thực "client-specific directories" — mỗi client một access point, dữ liệu client này không nằm trong tầm nhìn của client kia.
2. Ép user identity POSIX. Access point có thể áp cố định user/group (và các POSIX group của user) cho mọi request đi qua nó, bất kể tiến trình phía client đang chạy dưới danh nghĩa nào.

Phần IAM: bạn viết IAM policy buộc một ứng dụng chỉ được dùng đúng một access point cụ thể. Kết hợp IAM policy với access point chính là cách AWS khuyến nghị để cấp quyền an toàn tới từng tập dữ liệu riêng — khớp nguyên văn yêu cầu "chỉ IAM role đã định nghĩa cho thư mục đó mới truy cập được".

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

C — Configure Amazon EFS mount targets. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì nó cũng thuộc EFS. Nhưng mount target chỉ là địa chỉ IP cho endpoint NFSv4 trong một subnet của VPC — nơi để client "chạm" tới file system. Nó trả lời câu hỏi mount ở đâu, không trả lời ai được thấy thư mục nào. Mount target không ép root directory, không ép identity POSIX, và không phải đối tượng để IAM policy phân quyền theo từng thư mục client. Lưu ý thêm: khi mount qua access point bạn vẫn dùng EFS mount helper — tức mount target và access point không loại trừ nhau, nhưng chỉ mount target thì không đáp ứng được yêu cầu cô lập của đề.

B — Implement Amazon EBS Multi-Attach. Multi-Attach cho phép gắn một volume Provisioned IOPS SSD (io1/io2) vào nhiều instance trong cùng một Availability Zone. Vấn đề gốc: EBS là block storage, không phải file system dùng chung — đề đã nói rõ ứng dụng đang truy cập tệp qua NFS. Muốn nhiều máy cùng ghi lên một volume block như vậy còn phải có cluster-aware file system, và dù có thì nó vẫn không cho bạn phân quyền thư mục theo IAM role. Sai ngay ở tầng loại lưu trữ, chưa cần bàn tới phân quyền.

D — Use Amazon VPC Gateway endpoints. VPC endpoint là chuyện kết nối riêng tư giữa VPC và dịch vụ AWS, không phải chuyện phân quyền thư mục. Hơn nữa Gateway endpoint là loại VPC endpoint chỉ hỗ trợ Amazon S3 và DynamoDB — nó thậm chí không áp dụng được cho EFS. Phương án này lạc hẳn khỏi bài toán.

📌 Điểm cần nhớ

• Đề nhắc NFS / shared file storage → nghĩ EFS; đề nhắc block volume gắn nhiều instance cùng AZ → EBS Multi-Attach. Đừng đổi chỗ hai thứ này.
• Trong EFS: mount target = nơi mount (địa chỉ IP trong subnet), access point = ai được mount và thấy được gì (root directory + POSIX identity + IAM). Câu hỏi nào có chữ "chỉ thư mục này", "chỉ role này" thì đáp án là access point.
• Access point mạnh nhất khi kết hợp với IAM policy: policy buộc ứng dụng dùng đúng một access point, access point ép sẵn thư mục gốc và identity — hai lớp khoá cùng lúc.
• Gateway endpoint chỉ dùng cho S3 và DynamoDB. Thấy nó xuất hiện cạnh một bài toán về EFS hay về phân quyền dữ liệu thì gần như chắc chắn là phương án nhiễu.

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

Đề mô tả một công ty muốn bảo vệ dữ liệu lưu trên S3, và đặt ra hai yêu cầu rất cụ thể về key material dùng để mã hoá:

• lifecycle management cho khoá — tạo, xoay vòng (rotate), vô hiệu hoá khoá;
• audit — ghi lại và tra được ai đã dùng khoá nào, lúc nào.

Cụm từ quyết định nằm ở cuối: "the best solution with the least development and maintenance effort". Đây là ràng buộc phân biệt bốn phương án. Cả bốn đều mã hoá được dữ liệu trên S3, nhưng chỉ một phương án vừa cho vòng đời khoá và vết kiểm toán, vừa để AWS gánh phần vận hành thay vì bắt công ty tự viết và tự bảo trì.

Nói cách khác, đề không hỏi "cách nào mã hoá an toàn nhất", mà hỏi "cách nào quản trị được khoá mà tốn ít công nhất".

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

C — Use AWS Key Management Service (SSE-KMS) for encrypting objects in Amazon S3 buckets.

Với SSE-KMS, S3 mã hoá phía server nhưng khoá do KMS quản lý. Bạn dùng được AWS managed CMK mặc định, hoặc tạo trước một customer-managed CMK rồi trỏ bucket vào đó.

Chọn customer-managed CMK là chỗ hai yêu cầu của đề được đáp ứng trọn vẹn:

• Lifecycle management: tạo, xoay vòng, vô hiệu hoá khoá đều là thao tác có sẵn của KMS — đúng nghĩa quản lý vòng đời của key material bên trong AWS.
• Audit: KMS cho phép đặt access control trên khoá và kiểm toán việc sử dụng những CMK đang bảo vệ dữ liệu của bạn.

Và vì đây là dịch vụ được quản lý, phần công sức của đội kỹ thuật gần như chỉ là cấu hình — không phải viết code mã hoá, không phải dựng kho lưu khoá, không phải tự làm sổ ghi truy vết. Đó chính là "least development and maintenance effort".

Một chi tiết đáng nhớ kèm theo: khi bật SSE-KMS, có thể cấu hình bucket dùng S3 Bucket Keys, làm giảm mạnh lưu lượng request từ S3 sang KMS và do đó giảm chi phí request của KMS.

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

A — Customer-Provided Keys (SSE-C). Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. SSE-C vẫn là mã hoá phía server: bạn gửi kèm khoá trong request, S3 dùng khoá đó mã hoá khi ghi xuống đĩa rồi xoá khoá khỏi bộ nhớ; lúc đọc lại bạn phải gửi đúng khoá đó, S3 đối chiếu rồi mới giải mã. Vấn đề nằm ở chỗ AWS không giữ khoá — toàn bộ việc lưu trữ, xoay vòng và ghi vết sử dụng khoá đổ hết lên phía khách hàng. Bạn có thể tự xây một hệ thống lifecycle + audit cho key material, nhưng đó đúng là phần "development and maintenance" mà đề bảo phải tối thiểu hoá. Trượt vì ràng buộc công sức, không phải vì không mã hoá được.

B — Client-side encryption. Với mã hoá phía client, bạn mã hoá dữ liệu trước rồi mới tải bản đã mã hoá lên S3; bạn tự lo quy trình mã hoá, tự lo khoá, tự lo công cụ. Đây là phương án tốn công nhất trong bốn phương án, ngược hẳn yêu cầu của đề. Ngoài ra tình huống trong đề đặt việc mã hoá ở phía S3, nên hướng client-side bị loại.

D — S3-Managed Keys (SSE-S3). Đây là phương án dễ bị chọn nhầm vì nó rất ít công: S3 mã hoá từng object bằng một khoá riêng, rồi mã hoá chính khoá đó bằng một khoá khác mà S3 tự xoay vòng định kỳ, dùng AES-256; không phát sinh phí riêng cho việc mã hoá. Nhưng đúng chỗ đề hỏi thì nó không đáp ứng: key material do S3 nắm hoàn toàn, bạn không có quyền quản lý vòng đời khoá và không có vết kiểm toán cho việc sử dụng khoá. Mã hoá thì đạt, quản trị khoá thì không — mà đề hỏi cả hai.

📌 Điểm cần nhớ

• Bốn cách mã hoá dữ liệu S3 xếp theo mức độ bạn kiểm soát khoá: SSE-S3 (AWS lo hết) → SSE-KMS (bạn quản lý khoá qua KMS) → SSE-C (bạn cấp khoá theo từng request) → client-side (bạn lo toàn bộ). Càng sang phải càng nhiều quyền kiểm soát và càng nhiều việc phải tự làm.
• Đề nhắc tới audit trail hoặc quản lý vòng đời khoá (tạo / rotate / disable / phân quyền trên khoá) thì mặc định nghĩ tới SSE-KMS; SSE-S3 không cho những thứ này.
• Cụm "least development and maintenance effort" là bộ lọc mạnh nhất: nó loại client-side và SSE-C ngay cả khi về mặt kỹ thuật chúng vẫn làm được điều đề yêu cầu.
• Khi đã chọn SSE-KMS, nhớ S3 Bucket Keys như một tuỳ chọn giảm lưu lượng request từ S3 sang KMS — chi tiết hay xuất hiện ở các câu hỏi về chi phí của SSE-KMS.

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

Đề mô tả một tình huống rất cụ thể: developer đã mở cổng cần thiết ở chiều inbound cho cả Security Group của EC2 instance lẫn Network ACL của subnet, nhưng vẫn không kết nối được tới service đang chạy trên instance.

Cụm từ quyết định nằm ở chỗ nói rõ chỉ cấu hình inbound ở cả hai lớp. Đề không nói gì tới outbound. Đó chính là đầu mối: nếu cả hai lớp đều hoạt động giống nhau thì mở inbound là đủ và câu hỏi sẽ không tồn tại. Vấn đề nằm ở chỗ hai lớp lọc traffic này có bản chất khác nhau — một cái stateful, một cái stateless — và bốn phương án chỉ đơn giản là bốn cách gán nhãn hai tính chất đó (hoặc hai câu đánh lạc hướng hoàn toàn).

Một chi tiết ngầm nữa: traffic trả về từ server đi ra ephemeral port của client (dải cổng cao, không phải cổng service). Nên "đã mở đúng cổng service" không có nghĩa là chiều về đã được phép đi.

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

Đáp án đúng là A — Security Groups là stateful nên mở inbound là đủ; Network ACLs là stateless nên phải mở cả inbound lẫn outbound.

• Security Group stateful: nó ghi nhớ trạng thái kết nối. Khi một request được cho phép đi vào, traffic phản hồi tương ứng tự động được cho ra, bất kể rule outbound viết thế nào. Vì vậy chỉ cần allow inbound trên cổng service là kết nối làm việc được.
• Network ACL stateless: nó xét từng gói tin độc lập, không nhớ gì về kết nối trước đó. Chiều vào và chiều ra được đánh giá bằng hai bộ rule tách rời.

Cụ thể trong tình huống của đề: client mở kết nối, hệ điều hành của client chọn ngẫu nhiên một cổng nguồn trong dải ephemeral (theo tài liệu AWS trích trong câu này là 1024–65535). Khi service trả lời, cổng ephemeral đó trở thành cổng đích của gói tin đi ra. Network ACL đang chỉ allow inbound cổng service, còn chiều outbound tới dải ephemeral thì không được phép → gói phản hồi bị chặn tại biên subnet, và người dùng thấy kết nối "treo"/không thành công dù cấu hình inbound trông hoàn toàn đúng.

Cách sửa: bổ sung rule outbound trên Network ACL cho phép traffic đi ra dải ephemeral port. Mặc định Network ACL cho phép mọi chiều; chỉ khi ai đó siết chặt nó lại thì mới cần khai báo tường minh như vậy.

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

D — "Network ACLs stateful, Security Groups stateless, nên phải mở cả hai chiều": đây là phương án nguy hiểm nhất vì nó đúng về mặt cấu trúc câu, chỉ đảo ngược vai trò hai dịch vụ. Nó là bẫy kinh điển kiểm tra xem thí sinh có thực sự nhớ cái nào stateful hay chỉ nhớ mang máng rằng "một trong hai cái phải mở hai chiều". Thực tế ngược lại hoàn toàn: Security Group mới là lớp stateful, Network ACL mới là lớp stateless. Nếu làm theo D — đi mở outbound trên Security Group — thì sự cố vẫn nguyên vẹn, vì nút thắt nằm ở Network ACL.

B — "IAM Role khai trong Security Group khác với IAM Role được cấp quyền trong Network ACLs": hoàn toàn bịa. Security Group và Network ACL lọc traffic theo protocol, port và dải địa chỉ IP — chúng không có khái niệm IAM Role bên trong rule. IAM điều khiển ai được phép gọi API để tạo/sửa các resource này, chứ không tham gia vào quyết định cho phép một gói tin đi qua hay không. Đây là kiểu đánh lạc hướng bằng cách trộn lẫn hai tầng khác nhau: identity/authorization với network filtering.

C — "Không được sửa rule của Network ACL từ command line, sửa vậy sẽ khoá rule và gây hành vi thất thường": cũng bịa. Network ACL sửa được bằng CLI/SDK/CloudFormation y hệt như sửa trong Console — Console thực chất cũng gọi cùng các API đó. Không có chuyện một rule bị "khoá" hay chạy thất thường vì được tạo từ dòng lệnh. Phương án này còn tự tố cáo mình bằng cách mô tả một hành vi mơ hồ, không xác định ("erratic behavior") — dấu hiệu quen thuộc của distractor.

📌 Điểm cần nhớ

• Security Group = stateful, Network ACL = stateless. Nhớ đúng chiều này giải được cả một họ câu hỏi troubleshooting kết nối trong VPC.
• Với Network ACL, mở inbound cổng service là chưa đủ: traffic trả về đi ra ephemeral port, nên phải có rule outbound cho dải cổng đó.
• Triệu chứng "SG và NACL đều đã mở inbound mà vẫn không kết nối được" gần như luôn trỏ về rule outbound của NACL. Network ACL mặc định cho phép mọi chiều — sự cố kiểu này chỉ xuất hiện khi ai đó đã siết NACL lại.
• Security Group và Network ACL lọc theo protocol/port/IP, không dính dáng gì tới IAM Role. Phương án nào ghép IAM vào rule của hai lớp này đều loại được ngay.
• Với câu trắc nghiệm dạng "hai định nghĩa hoán đổi cho nhau", đọc kỹ xem tên dịch vụ nào gắn với tính chất nào — cả hai phương án đều nghe hợp lý nếu chỉ lướt qua.

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

Đề đặt bạn vào vai SysOps Administrator quản lý môi trường AWS của công ty, và yêu cầu theo dõi các AWS event có thể ảnh hưởng tới môi trường của bạn hoặc các vấn đề vận hành cụ thể ảnh hưởng tới các AWS account bạn đang quản lý.

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

• "might affect your environment" / "affect the AWS accounts you manage" — đây không phải câu hỏi về tình trạng chung của dịch vụ AWS trên toàn cầu, mà là tình trạng liên quan tới chính tài nguyên và account của bạn. Cụm này loại ngay những công cụ chỉ báo trạng thái chung chung.
• "specific operational issues" — cần dữ liệu sự kiện vận hành có tính cá nhân hoá, đủ chi tiết để hành động, chứ không phải một bản tóm tắt định kỳ.

Ngoài ra, ba trong bốn phương án nhắc tới việc tích hợp với công cụ quản lý nội bộ sẵn có (in-house management tools) — dấu hiệu cho thấy điểm phân biệt nằm ở chỗ: cách nào lấy được dữ liệu health theo kiểu lập trình được, và cách nào chỉ là màn hình để người xem.

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

D — Use the AWS Health API, to integrate health data and notifications with your existing in-house management tools.

AWS Personal Health Dashboard cho bạn góc nhìn được cá nhân hoá về sức khoẻ của đúng những dịch vụ đang chạy workload của bạn: nó chủ động báo khi AWS gặp sự cố có thể ảnh hưởng tới bạn, và báo trước các thay đổi đã lên lịch như bảo trì phần cứng.

AWS Health API chính là lối truy cập bằng chương trình vào đúng dữ liệu đang hiển thị trên Personal Health Dashboard. Bạn gọi các API operation để lấy thông tin về những event có thể ảnh hưởng tới dịch vụ và tài nguyên AWS của mình — đúng cả hai vế mà đề đòi: sự kiện ảnh hưởng tới môi trường của bạn, và vấn đề vận hành trên các account bạn quản lý. Vì là API nên dữ liệu và thông báo đưa thẳng được vào hệ thống quản lý nội bộ.

Một lưu ý theo tài liệu nguồn: dùng AWS Health API đòi hỏi Support plan mức Business hoặc Enterprise. Gọi từ account không có plan đó sẽ nhận lỗi SubscriptionRequiredException.

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

A — Service Health Dashboard. Đây là phương án gần đúng nhất và cũng là bẫy chính. Service Health Dashboard cho biết trạng thái tổng thể của từng dịch vụ AWS, nhưng nó không nói được sức khoẻ đó đang tác động ra sao tới tài nguyên cụ thể của bạn. Nó bỏ lỡ đúng ràng buộc "affect your environment / the accounts you manage" trong đề — bạn thấy một dịch vụ có sự cố, nhưng không biết instance hay account nào của mình dính.

B — Chạy diagnostics trực tiếp bên trong Personal Health Dashboard bằng Lambda. Phương án này bắt trúng đúng dịch vụ (Personal Health Dashboard) nên nghe rất thuyết phục, nhưng hỏng ở cơ chế: không chạy diagnostics trực tiếp bên trong Personal Health Dashboard được. Cái làm được là gắn một script diagnostics để Lambda thực thi khi có event xảy ra, với điều kiện event được nối dây phù hợp — tức là một kiến trúc khác hẳn với mô tả trong phương án.

C — Trusted Advisor notification. Tính năng thông báo của Trusted Advisor gửi email hằng tuần khi bạn opt-in, giúp bạn nắm tình hình triển khai tài nguyên của mình (theo các khuyến nghị về cost, security, fault tolerance, performance, limits). Nhưng nội dung đó nói về trạng thái triển khai tài nguyên, không phải trạng thái hiện thời của tài nguyên và cũng không phải các AWS event vận hành — đúng thứ mà đề yêu cầu. Chu kỳ hằng tuần cũng không hợp với việc theo dõi sự cố đang diễn ra.

📌 Điểm cần nhớ

• Service Health Dashboard = trạng thái chung của dịch vụ AWS; Personal Health Dashboard = ảnh hưởng cụ thể tới account và tài nguyên của bạn. Thấy đề nhấn "your environment", "your resources", "accounts you manage" thì nghiêng về Personal Health / AWS Health.
• Cần đưa dữ liệu health vào công cụ quản lý nội bộ ⇒ AWS Health API, vì API là lối truy cập bằng chương trình vào chính dữ liệu của Personal Health Dashboard; dashboard chỉ để người xem.
• AWS Health API yêu cầu Support plan Business hoặc Enterprise, thiếu thì trả SubscriptionRequiredException — chi tiết này hay được hỏi kèm.
• Trusted Advisor không phải công cụ theo dõi sự kiện vận hành: nó khuyến nghị về cách triển khai tài nguyên và báo theo email định kỳ, không phản ánh sự cố đang diễn ra.

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

Đề mô tả một công ty đang dùng nhiều loại thiết bị AWS Snow Family và muốn chuyển sang một dịch vụ quản lý các thiết bị này dễ dàng hơn, thay cho CLI mà họ đang dùng. Câu hỏi chốt lại: dịch vụ AWS nào dùng để quản lý thiết bị AWS Snowball?

Cụm từ quyết định đáp án là "unlike the CLI that is used to work with the AWS Snow family" — tức là người ta cần một công cụ có giao diện đồ hoạ thay cho dòng lệnh, và nó phải làm việc trực tiếp với thiết bị Snow Family. Cụm "manage AWS Snowball devices" loại ngay mọi dịch vụ quản trị tài khoản, quản trị cấu hình máy chủ hay môi trường nghiên cứu — chúng không hề chạm tới thiết bị Snow.

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

B. AWS OpsHub là công cụ chính thức của AWS dành riêng cho Snow Family. Nó lấy toàn bộ thao tác vốn có trong Snowball API và trình bày lại dưới dạng giao diện đồ hoạ, đúng thứ đề bài đang tìm khi nói "unlike the CLI".

Cách dùng thực tế: khi thiết bị Snow được giao tới nơi, bạn tải và cài AWS OpsHub lên một máy client (chẳng hạn laptop), rồi từ đó mở khoá thiết bị (unlock), cấu hình một thiết bị đơn lẻ hoặc cả cụm (cluster), truyền tệp, và khởi chạy – quản lý các instance đang chạy trên thiết bị. OpsHub có dashboard tóm tắt các chỉ số quan trọng như dung lượng lưu trữ và số instance đang hoạt động, đồng thời liệt kê các dịch vụ AWS được hỗ trợ chạy tại chỗ trên thiết bị.

OpsHub quản lý được cả loại Storage Optimized lẫn Compute Optimized, và bản thân ứng dụng không tính thêm phí. Nó phục vụ cả hai kịch bản điển hình của Snow Family: di chuyển dữ liệu lên AWS Cloud và triển khai ứng dụng edge computing ngay trên thiết bị.

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

A. AWS Control Tower — Đây là dịch vụ thiết lập và quản trị môi trường AWS nhiều tài khoản (landing zone). Nó dựng landing zone dựa trên AWS Organizations, giúp cấp phát tài khoản mới nhanh chóng và áp các quy tắc quản trị toàn công ty. Phạm vi của nó là tài khoản và governance, hoàn toàn không liên quan tới phần cứng Snow đặt tại chỗ. Đây là bẫy "nghe giống quản lý" nhưng sai đối tượng được quản lý.

C. Service Workbench on AWS — Là giải pháp giúp đội IT cung cấp quyền truy cập an toàn, lặp lại được vào dữ liệu, công cụ và năng lực tính toán cho các nhà nghiên cứu. Nó tự động hoá việc dựng môi trường nghiên cứu, đơn giản hoá truy cập dữ liệu và minh bạch chi phí. Ngữ cảnh là môi trường nghiên cứu khoa học, không phải quản lý thiết bị Snowball.

D. AWS OpsWorks — Đây là phương án gần đúng nhất về mặt tên gọi: cả "OpsHub" lẫn "OpsWorks" đều bắt đầu bằng "Ops", rất dễ chọn nhầm khi đọc lướt. Nhưng OpsWorks là dịch vụ configuration management cung cấp bản quản lý của Chef và Puppet, dùng để viết code tự động hoá việc cấu hình, triển khai và quản lý server — trên Amazon EC2 hoặc môi trường on-premises. Nó thao tác trên máy chủ và cấu hình phần mềm, chứ không có khái niệm mở khoá thiết bị Snow, truyền tệp vào thiết bị hay xem dung lượng lưu trữ của thiết bị. Chỗ nó hỏng chính là đối tượng quản trị: server chứ không phải thiết bị Snow Family.

📌 Điểm cần nhớ

• Snow Family + "thay cho CLI" / "giao diện đồ hoạ" ⇒ AWS OpsHub. Đây là cặp từ khoá – đáp án gần như cố định trong đề thi AWS.
• Phân biệt hai cái tên dễ lẫn: OpsHub quản lý thiết bị Snow, còn OpsWorks là configuration management với Chef/Puppet cho server.
• Khi câu hỏi nói "quản lý", hãy xác định rõ quản lý cái gì: tài khoản (Control Tower), cấu hình server (OpsWorks), môi trường nghiên cứu (Service Workbench), hay thiết bị vật lý (OpsHub).
• Ghi nhớ các thao tác đặc trưng của OpsHub — unlock thiết bị, cấu hình cụm, truyền tệp, chạy và quản lý instance tại chỗ — vì đề thường mô tả hành vi thay vì gọi thẳng tên dịch vụ.