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

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

Một công ty IT dùng Amazon S3 rất nhiều cho lưu trữ, hosting, backup và replication phục vụ compliance. Team Lead cần một báo cáo liệt kê tất cả các object đã replication thất bại, và quan trọng nhất: "This process needs to be automated as the Team Lead needs this list daily".

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

• "report that lists all the objects" — thứ cần là một danh sách object đã gom sẵn, kèm trạng thái replication của từng object, chứ không phải số liệu tổng hợp (metrics) hay một sự kiện đơn lẻ.
• "automated ... daily" — cần cơ chế chạy theo lịch có sẵn, không phải thứ phải viết code tự dựng.

Ghép hai ràng buộc lại: đề đang mô tả đúng một tính năng có sẵn của S3 sinh file báo cáo theo lịch ngày, trong đó có cột trạng thái replication cho từng object.

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

B — Amazon S3 Inventory reports là đáp án đúng.

S3 Inventory là công cụ quản lý storage của S3, được thiết kế đúng cho việc audit và báo cáo về trạng thái replication và encryption của các object nhằm phục vụ nhu cầu nghiệp vụ, compliance và quy định — đúng bối cảnh "compliance specific replication" mà đề nêu.

Nó khớp cả hai ràng buộc:

• Ra danh sách object kèm metadata: file output dạng CSV, ORC hoặc Parquet, liệt kê object trong một bucket (hoặc một prefix chung) cùng metadata tương ứng — trong đó có trạng thái replication, nên lọc ra những object thất bại là việc đọc file báo cáo.
• Tự động theo lịch: cấu hình sinh báo cáo theo chu kỳ hằng ngày hoặc hằng tuần. Chọn daily là đáp ứng thẳng yêu cầu "needs this list daily", không phải viết thêm dòng code nào.

Ngoài ra S3 Inventory còn là phương án thay thế theo lịch cho List API đồng bộ của S3, nên với môi trường dùng S3 "extensively" thì nó là cách lấy danh sách hợp lý hơn là quét bucket. Cấu hình được nhiều inventory list cho một bucket, chọn metadata muốn đưa vào, liệt kê mọi version hay chỉ version hiện tại, nơi lưu file output, và có mã hoá file kết quả hay không.

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

A — Amazon S3 Storage Lens. Đây là phương án gần đúng nhất vì Storage Lens cũng xuất được dữ liệu ra CSV/Parquet và cũng có tính "báo cáo". Chỗ nó hỏng: Storage Lens tổng hợp usage và activity metrics rồi hiển thị trên một dashboard tương tác trong S3 console. Nó cho bạn con số ở mức tập hợp (bucket, prefix, tài khoản, tổ chức), không cho bạn danh sách từng object cụ thể đã replication thất bại. Đề hỏi "list all the objects", không hỏi metrics — sai ở đơn vị dữ liệu, không phải ở định dạng file.

C — Amazon S3 Select. S3 Select cho phép dùng biểu thức SQL đơn giản để lấy chỉ phần dữ liệu bạn quan tâm bên trong nội dung một object, thay vì phải tải cả object về. Nó thao tác bên trong object, không phải thao tác trên danh sách object và cũng không đọc được trạng thái replication. Không có cách nào dùng S3 Select để liệt kê object đã replication thất bại. (Nếu đã có sẵn file inventory thì S3 Select là công cụ đọc file đó — nhưng bản thân nó không tạo ra danh sách, nên đứng một mình vẫn sai.)

D — SQS queue gắn với CloudWatch metrics cho S3 replication + code tự gom. Phương án này hỏng ở ba chỗ chồng lên nhau. Thứ nhất, CloudWatch metrics cho replication chỉ có khi bật S3 Replication Time Control (S3 RTC) — một điều kiện tiên quyết mà đề không hề nói tới. Thứ hai, metrics được sinh ra theo hành động trên từng object riêng lẻ, trong khi thứ cần là một danh sách đã gom lại. Thứ ba, nó bắt bạn viết và duy trì custom code để tổng hợp, tức là tự dựng lại bằng tay đúng thứ S3 Inventory đã làm sẵn — vừa tốn công vừa thêm chỗ hỏng.

📌 Điểm cần nhớ

• S3 Inventory = danh sách từng object + metadata, theo lịch daily/weekly. Đề nào yêu cầu liệt kê object kèm trạng thái replication hoặc encryption cho audit/compliance thì đây là câu trả lời mặc định.
• S3 Storage Lens = metrics tổng hợp trên dashboard. Phân biệt bằng câu hỏi: đề hỏi "bao nhiêu / xu hướng thế nào" (Storage Lens) hay "những object nào" (Inventory)?
• S3 Select đọc bên trong một object, không phải công cụ liệt kê object. Thấy "SQL" đừng vội chọn nếu đề đang cần danh sách object.
• CloudWatch metrics cho S3 replication phụ thuộc S3 RTC. Phương án nào cần bật thêm tính năng tiền đề mà đề không nhắc, lại còn kèm "custom code", thường là bẫy — AWS gần như luôn ưu tiên tính năng có sẵn, chạy theo lịch, không cần viết code.

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

Đề mô tả một công ty bán lẻ đa quốc gia muốn dựng môi trường hybrid cloud, và yêu cầu nối data center của họ với AWS Cloud. Bốn tính từ trong đề chính là bộ lọc: kết nối phải dedicated, encrypted, low latency và high throughput.

Cụm từ quyết định là hai chữ đứng cạnh nhau: "dedicated" và "encrypted". Không phương án đơn lẻ nào thoả cả hai — đường riêng thì không tự mã hoá, còn đường mã hoá qua Internet thì không riêng. Đó là dấu hiệu đề đang chờ một phương án kết hợp.

Câu còn cài thêm một mệnh đề để chặn đường thoát quen thuộc: "has set aside sufficient time to account for the operational overhead". Người soạn đề biết rằng lý do thường được viện ra để loại AWS Direct Connect là "dựng lâu, thủ tục nhiều"; câu này nói thẳng rằng thời gian và công sức vận hành không phải ràng buộc, nên không được dùng lý do đó để chọn phương án nhanh gọn hơn.

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

Đáp án đúng theo tệp là C — AWS Direct Connect plus VPN.

AWS Direct Connect cho phép dựng một đường mạng riêng từ cơ sở của bạn tới một AWS Direct Connect location, tức là lưu lượng không đi qua Internet công cộng. Nhờ vậy nó cho độ trễ thấp hơn, băng thông lớn hơn và quan trọng là ổn định hơn so với đường Internet — đây chính là phần "dedicated + low latency + high throughput" mà đề đòi.

Phần còn thiếu là mã hoá, và đó là việc của VPN. Khi ghép một hoặc nhiều kết nối AWS Direct Connect với Amazon VPC VPN, bạn có một đường private đã được mã hoá bằng IPsec chạy trên nền hạ tầng riêng thay vì trên Internet. Kết quả là gộp được ưu điểm của cả hai: tính bảo mật đầu-cuối và tính managed của VPN, cộng với độ trễ thấp, băng thông cao và trải nghiệm mạng nhất quán của Direct Connect. Đúng bốn yêu cầu của đề bằng một kiến trúc.

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

A — VPC transit gateway. Transit gateway là một network transit hub dùng để nối nhiều VPC và mạng on-premises lại với nhau. Nó giải bài toán topology (đỡ phải nối chằng chịt từng cặp), chứ bản thân nó không tạo ra đường vật lý nào tới data center. Muốn có đường, vẫn phải cắm Direct Connect hoặc VPN vào nó. Nói cách khác, transit gateway đứng một mình không đem lại low latency hay high throughput cho tuyến data center → AWS.

B — AWS Direct Connect (đơn thuần). Đây là phương án gần đúng nhất và là bẫy chính của câu. Nó thoả "dedicated", "low latency", "high throughput" — ba trên bốn. Chỗ hỏng nằm đúng ở tiêu chí thứ tư: Direct Connect tự nó không mã hoá lưu lượng. Đường riêng không đồng nghĩa với đường được mã hoá; muốn có "encrypted" thì phải phủ thêm một lớp mã hoá lên trên, và đó là lý do phương án C tồn tại. Chọn B là bỏ sót một chữ trong đề.

D — Site-to-site VPN. AWS Site-to-Site VPN dùng IPsec để tạo kết nối mã hoá giữa mạng nội bộ và Amazon VPC, nên nó thoả "encrypted". Nhưng nó chạy trên Internet công cộng, thừa hưởng toàn bộ tính biến động vốn có của đường Internet. VPN là lựa chọn tốt khi bạn cần dùng ngay, nhu cầu băng thông từ thấp tới trung bình, và chấp nhận được độ trễ dao động — mô tả đó ngược hẳn với "low latency và high throughput" trong đề. Thêm nữa, chi tiết "có đủ thời gian cho operational overhead" trong đề đã cố ý vô hiệu hoá ưu thế "dựng nhanh" của VPN.

📌 Điểm cần nhớ

• "Dedicated" và "encrypted" là hai tiêu chí khác nhau. Direct Connect lo vế đầu, VPN lo vế sau. Đề đòi cả hai thì đáp án gần như chắc chắn là phương án ghép Direct Connect + VPN.
• Đọc kỹ mệnh đề nói về thời gian và công sức vận hành. Khi đề khẳng định công ty chấp nhận operational overhead, người soạn đang chủ động loại bỏ lý do "VPN dựng nhanh hơn" khỏi bàn cân.
• Transit gateway là hub định tuyến, không phải phương tiện kết nối. Nó nối các mạng đã có sẵn đường; đứng một mình nó không tạo ra đường tới data center.
• VPN qua Internet = biến động. Hễ đề nhấn mạnh "consistent", "predictable", "low latency" hay "high throughput" thì site-to-site VPN đơn thuần thường là phương án bị loại.

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

Một công ty bán lẻ chạy fleet EC2 với Amazon RDS Multi-AZ làm cơ sở dữ liệu. Nhà cung cấp database engine vừa phát hành phiên bản mới, và công ty muốn thử nghiệm phiên bản đó với dữ liệu và cấu hình y hệt production trước khi nâng cấp instance production.

Cụm từ quyết định nằm gọn trong một câu: "test the release with production data and configurations before upgrading the production instance". Ba ràng buộc bị nén vào đó:

1. Production data — phải là bản sao đúng dữ liệu thật, không phải một database rỗng dựng theo cùng cấu hình.
2. Production configurations — cùng engine version, cùng tham số, cùng trạng thái xuất phát như production đang chạy.
3. Before upgrading the production instance — việc thử nghiệm không được đụng tới hệ thống đang phục vụ khách.

Ghép lại, thứ cần diễn tập không chỉ là "database phiên bản mới trông thế nào", mà là chính thao tác upgrade — chạy trên một bản sao rồi mới chạy trên bản thật.

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

B — tạo DB snapshot của instance hiện tại, restore snapshot thành một DB instance mới, rồi khởi động version upgrade trên instance mới đó.

Cách này thoả cả ba ràng buộc trên theo đúng thứ tự:

• Snapshot mang theo dữ liệu production. Restore từ snapshot cho ra một DB instance chạy được, mang đúng dữ liệu tại thời điểm chụp — không phải môi trường trống.
• Instance restore ra vẫn đang ở phiên bản engine cũ, tức cùng điểm xuất phát với production. Đây là điểm mấu chốt: sau đó ta initiate a version upgrade trên nó, nghĩa là chính bước upgrade được diễn tập thật, chứ không chỉ kiểm thử kết quả sau upgrade.
• Instance mới hoàn toàn tách khỏi production, nên có hỏng cũng chỉ hỏng bản sao — "safely experiment". Thử xong thấy ổn thì mới upgrade instance gốc, thấy có trục trặc thì xoá bản sao đi.

Đây đúng là quy trình AWS khuyến nghị để trial test một engine version mới trước khi áp lên production.

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

A — kiếm sẵn một instance đã cài phiên bản engine mới, rồi restore snapshot vào instance đó. Đây là phương án gần đúng nhất và đáng bóc kỹ. Nó vẫn có dữ liệu production, nhưng đảo ngược thứ tự: đích đến là một instance vốn đã ở phiên bản mới, nên bước upgrade — chính là thứ rủi ro nhất và là thứ cần diễn tập — bị bỏ qua hoàn toàn. Cái ta muốn biết là "chạy upgrade trên dữ liệu này có trục trặc gì không", chứ không phải "dữ liệu này nằm trên bản mới thì trông ra sao". Ngoài ra RDS restore-from-snapshot tạo ra một DB instance mới chứ không phải đổ dữ liệu vào một instance có sẵn, nên cách mô tả thao tác cũng không khớp với cách RDS làm việc.

C — tạo read replica của RDS production rồi upgrade replica lên phiên bản mới. Sai ở hai điểm. Thứ nhất, read replica chỉ nhận kết nối read-only, nên không kiểm thử được luồng ghi của ứng dụng — mà lỗi tương thích sau khi đổi engine version thường lộ ra đúng ở phần ghi. Thứ hai, read replica gắn liền với instance production qua luồng replication, nên đây không phải là môi trường tách bạch để "safely experiment"; nghịch trên nó là nghịch với một thành phần đang bám vào hệ thống thật. Snapshot thì đã cắt đứt hẳn sợi dây đó.

D — dựng cấu hình tương tự production bằng CloudFormation template. CloudFormation tái tạo được hạ tầng và cấu hình, và tái tạo được bao nhiêu lần cũng được, kể cả sang account khác — nhưng nó không mang theo dữ liệu. Kết quả là một database rỗng đúng hình dáng production. Đề bài đòi production data, và một bản test không có dữ liệu thật thì không phát hiện được đúng lớp vấn đề mà upgrade hay gây ra: lỗi trên dữ liệu cũ, trên schema đã tích luỹ, trên khối lượng bản ghi thật.

📌 Điểm cần nhớ

• Đề nhắc "production data" → nghĩ ngay tới DB snapshot + restore. CloudFormation clone cấu hình, snapshot clone dữ liệu — đọc kỹ đề đang đòi cái nào.
• Muốn diễn tập một thao tác (upgrade, migration) thì bản sao phải xuất phát ở trạng thái giống production, rồi mới chạy thao tác đó lên bản sao. Bắt đầu từ trạng thái "đã xong" là bỏ qua đúng phần rủi ro cần kiểm.
• Read replica không phải môi trường test: read-only nên không thử được luồng ghi, và vẫn nối với production nên không cô lập.
• Multi-AZ trong đề chỉ là bối cảnh về high availability, không phải cơ chế test — đừng để nó kéo hướng suy nghĩ sang chuyện failover.

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

Đề mô tả một nhà cung cấp giải pháp video streaming chuyển hạ tầng lên AWS để phục vụ người dùng toàn cầu, đứng sau là một EC2 server farm. Câu hỏi yêu cầu chọn loại Elastic Load Balancer phù hợp.

Cụm từ quyết định nằm ở câu thứ nhất: "supports at least a million requests per second" — hàng triệu request mỗi giây. Ngoài ra, bối cảnh video streaming ngụ ý yêu cầu độ trễ thấp và throughput cao, chứ không phải nhu cầu định tuyến theo nội dung HTTP.

Đây chính là ràng buộc phân biệt các phương án: cả ba loại load balancer có thật trong danh sách đều đứng trước EC2 được, nên "chạy được hay không" không phải tiêu chí. Tiêu chí là quy mô connection và độ trễ, và đó là điểm mà loại hoạt động ở tầng kết nối vượt trội hơn hẳn loại phải phân tích từng request ở tầng ứng dụng.

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

A — Network Load Balancer.

Network Load Balancer hoạt động ở tầng kết nối (Layer 4), định tuyến kết nối tới target — EC2 instance, microservice, container — bên trong Amazon VPC dựa trên dữ liệu giao thức IP. Vì nó không cần mở gói tin ra đọc header HTTP, đường dẫn xử lý ngắn hơn nhiều so với một load balancer tầng 7.

Hệ quả là NLB được thiết kế đúng cho lớp bài toán mà đề nêu: workload độ trễ thấp, throughput cao, mở rộng tới hàng triệu request mỗi giây. Đề bài không đòi hỏi bất kỳ tính năng tầng ứng dụng nào (định tuyến theo path, theo host, theo header), nên việc chọn tầng 4 vừa đủ chức năng vừa đạt yêu cầu quy mô.

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

C — Application Load Balancer. Đây là phương án gần đúng nhất và cũng dễ chọn nhầm nhất, vì ALB là lựa chọn mặc định cho hầu hết ứng dụng web trên EC2. ALB hoạt động ở tầng request (Layer 7), định tuyến traffic tới EC2 instance, container, IP address và Lambda function dựa trên nội dung của request. Nó lý tưởng cho HTTP/HTTPS với định tuyến nâng cao, phục vụ kiến trúc microservice và container.

Chỗ nó hỏng: chính việc phân tích nội dung từng request khiến ALB không phù hợp với kịch bản độ trễ thấp – throughput cao mà đề mô tả. Đề không hề yêu cầu định tuyến theo nội dung, nên toàn bộ thế mạnh của ALB không được dùng đến, trong khi ràng buộc quy mô thì lại không đáp ứng được.

D — Classic Load Balancer. CLB cung cấp cân bằng tải cơ bản giữa nhiều EC2 instance và hoạt động ở cả tầng request lẫn tầng kết nối. Nghe qua thì "cả hai tầng" có vẻ là điểm cộng, nhưng đây là thế hệ cũ với tính năng cơ bản, và cũng không phù hợp với kịch bản độ trễ thấp – throughput cao trong đề. Trong một bài toán migration mới lên AWS, CLB gần như không bao giờ là câu trả lời đúng.

B — Infrastructure Load Balancer. Không tồn tại loại load balancer nào tên như vậy trong Elastic Load Balancing. Đây thuần tuý là phương án gây nhiễu, đặt tên nghe rất "hạ tầng" để đánh vào cảm giác rằng bài toán quy mô lớn thì phải cần một thứ gì đó ở tầng hạ tầng. Gặp một cái tên lạ trong danh sách ELB thì loại ngay.

📌 Điểm cần nhớ

• Từ khoá "millions of requests per second", "low latency", "high throughput" trong đề gần như luôn chỉ thẳng tới Network Load Balancer (Layer 4).
• Từ khoá định tuyến theo nội dung request — path, host, header, hoặc target là Lambda function — thì mới chỉ tới Application Load Balancer (Layer 7).
• Classic Load Balancer là thế hệ cũ, hoạt động ở cả hai tầng nhưng chỉ ở mức cơ bản; trong đề thi nó hầu như luôn là phương án sai đối với hệ thống mới.
• Cảnh giác với tên dịch vụ không tồn tại trong danh sách phương án — "Infrastructure Load Balancer" là distractor thuần tuý, loại ngay mà không cần cân nhắc.

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

Đề mô tả một tình huống rất quen thuộc khi quản lý hạ tầng bằng CloudFormation: hạ tầng bị chia thành hai stack riêng biệt — một network stack chứa VPC và các subnet, một web application stack chứa EC2 và RDS. Yêu cầu là stack ứng dụng phải tham chiếu được tới VPC do stack mạng tạo ra.

Cụm từ quyết định nằm ngay ở chỗ "reference the VPC created in the network stack into its web application stack" — tức là dữ liệu phải đi xuyên qua ranh giới giữa hai stack. Đây chính là bài toán cross-stack reference, không phải tham chiếu trong nội bộ một template.

Bốn phương án được ghép từ hai biến số, và mỗi biến là một cái bẫy riêng:

1. Bên stack nguồn dùng trường nào để "flag" giá trị: Export hay Outputs?
2. Bên stack đích dùng hàm nào để lấy giá trị: Fn::ImportValue hay Ref?

Phải chọn đúng cả hai vế thì phương án mới đúng.

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

Đáp án đúng là A: dùng trường Export để đánh dấu giá trị VPC ở stack mạng, rồi dùng hàm nội tại Fn::ImportValue để nhập giá trị đó vào stack ứng dụng.

Đây đúng là quy trình chuẩn mà tài liệu CloudFormation mô tả cho cross-stack reference: để tạo cross-stack reference, dùng trường Export của output để gắn cờ giá trị cần xuất, sau đó dùng hàm nội tại Fn::ImportValue để nhập giá trị. Nhờ vậy, chủ sở hữu của web application stack không phải tự tạo hay tự bảo trì các tài nguyên và quy tắc mạng — họ chỉ việc tiêu thụ những gì network stack đã công bố ra ngoài.

Ý nghĩa kiến trúc: Export biến một giá trị cục bộ của stack thành một giá trị được công bố ở phạm vi account/region, có tên riêng, để các stack khác tra cứu được. Còn Fn::ImportValue là hàm duy nhất biết cách đọc những giá trị đã export đó.

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

B — Outputs + Fn::ImportValue: Đây là phương án gần đúng nhất và cũng dễ bẫy nhất, vì nửa sau (Fn::ImportValue) hoàn toàn chính xác. Cái hỏng nằm ở nửa đầu: Outputs là section chứa các output của template, nhưng bản thân việc khai một output không làm nó hiển thị ra ngoài stack. Giá trị chỉ trở nên khả dụng cho stack khác khi có trường Export bên trong output đó. Không Export thì output vẫn chỉ là thông tin hiển thị của riêng stack, và Fn::ImportValue bên kia sẽ không tìm thấy gì để nhập.

C — Export + Ref: Nửa đầu đúng — giá trị đã được export ra ngoài. Nhưng nửa sau sai: không thể dùng Ref để nhập giá trị đã export. Ref chỉ tham chiếu tới tài nguyên hoặc parameter được khai bên trong chính template đang chạy; nó không có cơ chế nào để nhìn sang stack khác. Đây chính là điểm mà giải thích của đề nhấn mạnh thẳng: "You cannot use the Ref intrinsic function to import the value."

D — Outputs + Ref: Sai cả hai vế, gộp đúng hai lỗi đã nêu ở B và C. Không có Export nên chẳng có gì được công bố ra ngoài, và Ref thì vốn không đọc được giá trị từ stack khác. Đây là phương án xa đáp án nhất trong cả bốn.

📌 Điểm cần nhớ

• Cross-stack reference luôn là cặp Export ↔ Fn::ImportValue. Thấy đề nói tới việc chia hạ tầng thành nhiều stack và stack này cần tài nguyên của stack kia, hãy tìm ngay cặp từ khoá này trong các phương án.
• Ref chỉ hoạt động trong phạm vi một template. Nó tham chiếu tài nguyên hoặc parameter khai trong chính template đó, không bao giờ vượt ranh giới stack. Phương án nào ghép Ref với chuyện lấy dữ liệu từ stack khác là loại được ngay.
• Outputs không đồng nghĩa với Export. Outputs là nơi khai báo; Export mới là thứ công bố giá trị ra phạm vi rộng hơn. Đề thi rất hay đánh tráo hai từ này để tạo phương án "gần đúng".
• Với câu hỏi ghép hai biến số (chỗ này dùng gì × chỗ kia dùng gì), hãy loại theo từng vế thay vì đọc cả câu một lượt — sai một vế là loại cả phương án, cách này nhanh và ít nhầm hơn nhiều.

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

Một công ty mạng xã hội chạy hơn 100 instance c4.large ở region us-west-1, workload là các thuật toán nặng. Quản trị viên muốn theo dõi CPU utilization thường xuyên tới mức mỗi 10 giây.

Cụm từ quyết định đáp án là "as frequently as every 10 seconds" — chu kỳ 10 giây. Toàn bộ câu hỏi xoay quanh đúng một trục: độ phân giải (resolution) của metric trong CloudWatch. Khi đã khoá vào con số 10 giây, mọi phương án dựa trên metric mà EC2 tự đẩy sang CloudWatch đều bị loại, vì các mức đó thô hơn nhiều. Chữ "BEST" cũng ngầm nói rằng có phương án gần đúng nhưng không đạt yêu cầu tần suất — chứ không phải hoàn toàn vô lý.

Lưu ý thêm: đề nói CPU utilization, tức là một metric mà EC2 vốn đã cung cấp sẵn — nên cái thiếu ở đây không phải là "có số liệu hay không", mà là lấy được số liệu ở mức chi tiết theo giây hay không.

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

A. Create a high-resolution custom metric and push the data using a script triggered every 10 seconds

CloudWatch hỗ trợ high-resolution custom metric: ứng dụng tự publish metric lên CloudWatch ở độ phân giải tới mức 1 giây, thay vì phụ thuộc vào chu kỳ mà EC2 tự gửi. Đi kèm là high-resolution CloudWatch Alarm, đánh giá được ở chu kỳ ngắn cỡ 10 giây, hỗ trợ đúng những action mà alarm chu kỳ 1 phút thông thường vẫn hỗ trợ.

Đây là con đường duy nhất trong danh sách đưa được dữ liệu CPU vào CloudWatch ở mức 10 giây: chạy một script trên instance, lấy CPU utilization rồi push lên CloudWatch dưới dạng custom metric có StorageResolution ở mức high-resolution, kích hoạt mỗi 10 giây. Vì là metric do mình tự publish nên mình toàn quyền quyết định tần suất — điều mà metric do EC2 phát ra không cho phép.

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

C. Enable EC2 detailed monitoring — đây là phương án gần đúng nhất và cũng là bẫy chính. Detailed monitoring có thật, đúng là làm metric dày hơn so với mặc định, và có tính thêm phí. Nhưng nó chỉ đưa chu kỳ từ mức mặc định (khoảng 5 phút) xuống mức 1 phút — đó là trần của nó. Yêu cầu 10 giây nằm dưới trần này cả một bậc lớn, nên bật detailed monitoring vẫn không đáp ứng được. Nó hỏng ở chỗ: giải quyết đúng loại vấn đề (tăng độ chi tiết) nhưng không đủ mức vấn đề.

B. Simply get it from the CloudWatch Metrics — lấy thẳng metric có sẵn trong CloudWatch thì vẫn ra CPU utilization, nhưng dữ liệu đó chỉ tồn tại ở đúng hai mức mà EC2 phát ra: khoảng 5 phút với basic monitoring, và 1 phút nếu đã bật detailed monitoring. Không có nút nào để ép nó xuống 10 giây. Phương án này thực chất là "không làm gì cả", và nó bỏ qua hoàn toàn ràng buộc quan trọng nhất của đề.

D. Open a support ticket with AWS — đây là distractor thuần tuý. Độ phân giải metric là một tính năng có sẵn của CloudWatch, người dùng tự bật và tự publish được; không có chuyện AWS Support mở khoá một chu kỳ lấy mẫu riêng cho tài khoản của bạn. Trong đề thi, phương án "mở ticket với AWS" gần như luôn sai khi vấn đề nằm trong tầm cấu hình của chính khách hàng.

📌 Điểm cần nhớ

• Thấy yêu cầu theo dõi dưới 1 phút (10 giây, 30 giây, theo giây) → nghĩ ngay tới high-resolution custom metric do ứng dụng tự publish, không phải metric mặc định của EC2.
• Ghi nhớ ba bậc độ phân giải để phân biệt phương án: EC2 basic monitoring (mức phút, thô nhất) → EC2 detailed monitoring (1 phút, có phí) → high-resolution custom metric (xuống tới mức giây).
• Detailed monitoring là bẫy kinh điển cho mọi câu hỏi tần suất dưới phút: nó cải thiện độ chi tiết nhưng dừng ở 1 phút, không đi xa hơn được.
• High-resolution metric kéo theo high-resolution alarm — cảnh báo đánh giá ở chu kỳ ngắn, dùng chung tập action với alarm thường; đây là lý do phương án này "BEST" chứ không chỉ đơn thuần là khả thi.
• Phương án dạng "mở support ticket" thường là distractor khi bài toán vốn nằm trong phạm vi tự cấu hình của khách hàng.

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

Một dịch vụ ngân hàng chạy trên Amazon EC2 và Amazon RDS. CTO yêu cầu lấy granular OS level metrics từ dịch vụ database để làm benchmarking. Câu hỏi: SysOps Administrator cung cấp thông tin đó bằng cách nào?

Cụm từ quyết định là "OS level metrics ... from the database service" cộng với "granular". Hai vế này khoá chặt đáp án:

• OS level — nghĩa là số liệu của hệ điều hành mà DB instance đang chạy trên đó: bộ nhớ trống, bộ nhớ đang dùng, swap, số tiến trình đang chạy, dung lượng file system đã dùng. Đây không phải số liệu của database engine (query, wait event, load), cũng không phải sự kiện vòng đời của instance.
• granular — đòi mức chi tiết tới từng tiến trình/thread trên máy, chứ không phải một con số tổng hợp nhìn từ bên ngoài.

Ai đọc lướt sẽ thấy cả bốn phương án đều "liên quan tới monitoring RDS", nên phải dùng đúng hai vế này để tách chúng ra.

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

B — Enable Enhanced Monitoring for your RDS DB instance.

Enhanced Monitoring là tính năng của Amazon RDS cung cấp metric thời gian thực của hệ điều hành mà DB instance đang chạy trên đó. Nó lấy số liệu từ một agent chạy ngay trên instance, nên nhìn được vào bên trong máy: Free Memory, Active Memory, Swap Free, Processes Running, File System Used — đúng loại "OS level metrics" mà đề đòi.

Chính vì lấy từ agent bên trong, Enhanced Monitoring thấy được từng process/thread dùng CPU ra sao — đó là mức "granular" mà đề nhấn mạnh, rất hợp cho việc benchmarking.

Kết quả của Enhanced Monitoring được đưa vào CloudWatch Logs dưới dạng bản ghi JSON (khác với CloudWatch metrics thông thường), xem được trên console hoặc đẩy sang hệ thống giám sát khác; từ đó cũng có thể dựng custom metric và alarm trong CloudWatch.

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

A — Subscribe to CloudWatch metrics that track CPU utilization of the instances the RDS is hosted on. Đây là phương án gần đúng nhất và cũng là bẫy chính. CloudWatch thu CPU utilization của DB instance từ tầng hypervisor, tức là nhìn từ bên ngoài máy ảo. Hai hệ quả: (1) nó chỉ cho một con số CPU tổng, không phân rã được theo process/thread, cũng không có memory/swap/file system — không đạt yêu cầu "granular OS level"; (2) số đo có thể lệch so với Enhanced Monitoring, vì bản thân tầng hypervisor cũng tiêu tốn một phần công việc. Độ lệch này thường rõ hơn với các instance class nhỏ, khi nhiều VM cùng nằm trên một máy vật lý. Dùng cho benchmarking thì đây đúng là chỗ không nên chọn.

C — Subscribe to Amazon RDS events. RDS event subscription báo cho bạn khi có thay đổi xảy ra với DB instance, DB snapshot, DB parameter group hay DB security group, thông báo gửi qua Amazon SNS. Nó thuộc nhóm thông báo sự kiện vòng đời, không phải nhóm đo lường hiệu năng: nó nói "instance vừa failover / snapshot vừa xong", chứ không đưa ra con số nào về memory hay CPU. Hoàn toàn lạc yêu cầu của đề.

D — Enable Performance Insights. Đây là phương án dễ nhầm thứ hai, vì Performance Insights đúng là tính năng monitoring nâng cao của RDS và cũng dùng để phân tích hiệu năng. Nhưng nó thu metric từ database engine, để đo load thực tế lên database: câu lệnh nào nặng, chờ ở đâu, session nào chiếm tài nguyên. Nó trả lời câu hỏi "database đang bận vì cái gì", chứ không cung cấp OS level metrics như free memory, swap hay file system used. Đề hỏi mức OS, nên D hỏng ở đúng chỗ ranh giới engine ↔ OS.

📌 Điểm cần nhớ

• Với RDS, phân biệt ba tầng quan sát: CloudWatch metrics = nhìn từ hypervisor (bên ngoài, tổng hợp); Enhanced Monitoring = agent trên OS (memory, swap, process, file system, CPU theo process); Performance Insights = bên trong database engine (query, wait, DB load).
• Thấy từ khoá "OS level", "process/thread", "free memory", "swap", "file system" trong đề → nghĩ ngay tới Enhanced Monitoring.
• Thấy từ khoá về truy vấn chậm, DB load, wait event → đó là địa hạt của Performance Insights, không phải Enhanced Monitoring.
• RDS event subscription thuộc nhóm thông báo thay đổi/sự kiện qua SNS; gặp câu hỏi về đo lường thì loại nó ra sớm.
• Kết quả Enhanced Monitoring nằm ở CloudWatch Logs chứ không phải CloudWatch metrics thường — chi tiết này hay bị hỏi kèm.

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

Đề dựng một tình huống chạy fleet EC2 EBS-optimized cho ứng dụng thương mại điện tử, nhưng phần EC2 chỉ là bối cảnh — không có phương án nào nói về EC2 cả. Yêu cầu thật nằm ở hai câu cuối, và trong đó có ba cụm từ quyết định:

• "any secret strings ... to be encrypted to prevent exposing values as clear text" — bí mật phải được mã hoá khi lưu, không được để dạng chữ thường.
• "decryption events be audited" — phải ghi lại được sự kiện giải mã, tức là log ở tầng API call của dịch vụ mã hoá.
• "API calls to be simple" — đây là ràng buộc phân biệt quan trọng nhất. Nó tồn tại chỉ để loại phương án C, vốn cũng mã hoá được nhưng bắt ứng dụng phải gọi hai lần.

Câu hỏi ghi rõ (Select two), nên phải chọn một phương án cho việc lưu trữ và một phương án cho việc audit.

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

D — Store the secret as SecureString in SSM Parameter Store

Tham số kiểu SecureString của SSM Parameter Store có tên tham số ở dạng plaintext nhưng giá trị thì được mã hoá bằng KMS. Việc mã hoá và giải mã do Parameter Store tự lo thông qua KMS, nên ứng dụng chỉ cần một lời gọi API duy nhất (GetParameter với WithDecryption) là nhận về giá trị đã giải mã — khớp chính xác với ràng buộc "API calls to be simple". Nếu dùng customer-managed CMK, bạn còn dùng được IAM policy và key policy để quản lý riêng quyền mã hoá/giải mã.

E — Audit using CloudTrail

CloudTrail ghi lại hoạt động ở tầng API trên toàn bộ tài khoản AWS: thao tác từ Management Console, SDK, CLI hay từ các dịch vụ AWS khác. Vì việc giải mã ở đây diễn ra qua lời gọi API tới SSM và KMS, CloudTrail chính là nơi thấy được ai giải mã bí mật nào, lúc nào — đúng yêu cầu "decryption events be audited" phục vụ mục tiêu compliance.

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

C — Encrypt first with KMS then store in SSM Parameter store: đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Về mặt bảo mật nó chạy được — giá trị vẫn được mã hoá bằng KMS trước khi lưu. Nhưng nó hỏng ở đúng ràng buộc thứ ba: ứng dụng phải gọi Parameter Store để lấy chuỗi ciphertext, rồi gọi thêm KMS Decrypt để mở ra — hai API call thay vì một, cộng thêm phần mã tự viết để ghép hai bước. Đề đã nói thẳng "API calls to be simple", nên C bị loại vì lý do vận hành chứ không phải vì lý do bảo mật.

B — Store the secret as PlainText in SSM Parameter Store: vi phạm trực tiếp yêu cầu đầu tiên. Tham số kiểu plaintext (String) không được mã hoá giá trị, đúng bằng cái mà đề bảo phải tránh — "prevent exposing values as clear text". Loại ngay.

A — Audit using SSM Audit Trail: không có dịch vụ nào tên như vậy trong AWS. Đây là distractor được bịa ra bằng cách ghép tên "SSM" (dịch vụ đang dùng trong câu) với "Trail" (lấy từ CloudTrail) để nghe có vẻ quen tai. Dịch vụ audit ở tầng API call của AWS là CloudTrail, không phải một "audit trail" riêng của Systems Manager.

📌 Điểm cần nhớ

• Trong Parameter Store, SecureString = giá trị mã hoá bằng KMS + giải mã ngay trong một lời gọi lấy tham số. Đó là lựa chọn mặc định khi đề vừa đòi mã hoá vừa đòi đơn giản.
• Khi hai phương án đều mã hoá đúng, hãy đếm số lượt gọi API và số dòng code phải tự viết: đề thi AWS thường dùng "simple API calls", "minimal operational overhead", "least effort" làm tiêu chí phân biệt duy nhất.
• Hễ đề nói tới audit / governance / compliance ở tầng lời gọi API (ai gọi gì, lúc nào) thì câu trả lời gần như luôn là CloudTrail — đừng nhầm với CloudWatch, vốn thiên về metric và log của ứng dụng.
• Cảnh giác với tên dịch vụ nghe hợp lý nhưng không tồn tại. Nếu một phương án ghép tên hai dịch vụ thật lại với nhau ("SSM Audit Trail"), rất có thể đó là distractor.

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

Một công ty dịch vụ tài chính cần chạy ứng dụng trên single-tenant hardware để đáp ứng yêu cầu bảo mật. Câu hỏi yêu cầu chọn cách MOST cost-effective để cô lập các EC2 instance về một tenant duy nhất.

Đề có hai ràng buộc chồng lên nhau, và phải thoả cả hai:

1. "single-tenant hardware" — phần cứng vật lý không được dùng chung với khách hàng AWS khác. Ràng buộc này loại thẳng mọi lựa chọn chạy trên shared tenancy mặc định.
2. "MOST cost-effective" — trong số những phương án còn lại sau bước 1, chọn cái rẻ hơn.

Cụm quyết định chính là "MOST cost-effective". Nếu đề chỉ hỏi "cách nào cô lập phần cứng", cả Dedicated Instances lẫn Dedicated Hosts đều đúng và câu hỏi sẽ không có đáp án duy nhất. Chính từ "MOST cost-effective" mới tách được hai phương án gần giống nhau này ra. Ngược lại, nếu đề nhắc tới việc mang license sẵn có lên EC2 (BYOL) hoặc kiểm soát vị trí đặt instance trên server vật lý, đáp án sẽ đảo sang Dedicated Hosts.

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

A – Dedicated Instances. Đây là các EC2 instance chạy trong VPC trên phần cứng dành riêng cho một khách hàng. Dedicated Instances thuộc các AWS account khác nhau được cô lập vật lý ở mức phần cứng, kể cả khi các account đó cùng nằm dưới một payer account trong AWS Organizations. Như vậy yêu cầu "single-tenant hardware" của công ty tài chính được đáp ứng.

Điểm còn lại là chi phí: Dedicated Instances tính tiền theo từng instance đang chạy, trong khi Dedicated Hosts tính tiền theo cả máy chủ vật lý bất kể bạn dùng bao nhiêu dung lượng trên đó. Với một yêu cầu chỉ nêu "cần cô lập phần cứng" mà không nói gì tới BYOL hay quyền kiểm soát vị trí đặt instance, Dedicated Instances cho cùng mức cô lập với chi phí thấp hơn — đúng tiêu chí "MOST cost-effective".

Một lưu ý về phạm vi cô lập: Dedicated Instances có thể dùng chung phần cứng với các instance khác của chính account đó nếu những instance kia không phải Dedicated. Đây là giới hạn cần biết, nhưng nó không phá yêu cầu của đề vì đề nói về cô lập khỏi tenant khác.

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

B – Dedicated Hosts. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. Dedicated Host là một máy chủ vật lý dành hoàn toàn cho bạn, nên nó thoả hoàn toàn yêu cầu single-tenant — thậm chí còn chặt hơn Dedicated Instances. Nó hỏng ở vế thứ hai: bạn trả tiền cho toàn bộ host, nên nó đắt hơn Dedicated Instances khi mục tiêu duy nhất chỉ là cô lập phần cứng. Dedicated Hosts xứng đáng với chi phí đó khi bạn cần đúng hai thứ mà Dedicated Instances không có: khả năng dùng license sẵn có (BYOL) gắn theo socket/core/máy chủ vật lý, và khả năng nhìn thấy cùng kiểm soát instance được đặt ở đâu trên server. Đề không nhắc tới cả hai, nên trả thêm tiền là thừa.

C – On-Demand Instances. On-Demand là một mô hình mua (trả theo giây, không cam kết dài hạn), không phải một mô hình tenancy. Mặc định On-Demand chạy trên shared tenancy, tức phần cứng có thể dùng chung với khách hàng khác — trượt ngay yêu cầu single-tenant. Ngoài ra On-Demand cũng là một trong những cách trả tiền cho compute đắt nhất, nên nó hỏng ở cả hai vế của đề.

D – Spot Instances. Spot dùng dung lượng EC2 đang dư, giá thấp hơn On-Demand đáng kể — nên riêng tiêu chí "cost-effective" thì Spot ăn đứt mọi phương án khác. Nhưng đây đúng là bẫy "chọn cái rẻ nhất mà quên đọc hết đề": Spot cấp cho bạn bất kỳ dung lượng dư nào đang có, không hề đảm bảo phần cứng dành riêng, và instance còn có thể bị thu hồi khi AWS cần lại dung lượng. Không thoả single-tenant thì rẻ đến mấy cũng bị loại.

📌 Điểm cần nhớ

• Tenancy và purchase option là hai trục khác nhau. Dedicated Instances / Dedicated Hosts trả lời câu hỏi "chạy trên phần cứng của ai"; On-Demand / Reserved / Spot trả lời câu hỏi "trả tiền theo cách nào". Đề hỏi về cô lập phần cứng thì chỉ trục thứ nhất mới có cửa.
• Lọc theo ràng buộc cứng trước, tối ưu chi phí sau. Với đề dạng "MOST cost-effective way of doing X", hãy gạch trước mọi phương án không làm được X — rồi mới so giá trong phần còn lại. Làm ngược lại là rơi vào Spot.
• Dedicated Instances vs Dedicated Hosts: cùng cho cô lập vật lý khỏi khách hàng khác. Chọn Hosts khi đề nhắc tới BYOL / license theo socket hoặc core, hoặc kiểm soát vị trí đặt instance; chọn Instances khi đề chỉ cần cô lập và nhấn mạnh chi phí.
• Dedicated Instances vẫn có thể dùng chung phần cứng với instance không phải Dedicated trong cùng account — cần cô lập tuyệt đối tới mức đó thì mới phải lên Dedicated Hosts.

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

Đề mô tả một công ty viễn thông chạy EC2 và S3, người dùng thỉnh thoảng nhận 500 Internal Error khi truy cập bucket. Đội vận hành muốn hai thứ: theo dõi tần suất lỗi và khắc phục nó.

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

• "intermittently" — lỗi lúc có lúc không. Một vấn đề cấu hình (thiếu object, sai IAM, thiếu quyền KMS) thì sai một cách nhất quán: cùng một người, cùng một object, lần nào cũng hỏng. Lỗi chập chờn chỉ ra vấn đề phía server chứ không phải phía cấu hình.
• "500 Internal Error" — mã lỗi thuộc dải 5xx, tức là lỗi của phía máy chủ. Mọi vấn đề về quyền hay object không tồn tại đều rơi vào dải 4xx (403 Access Denied, 404 Not Found).

Chỉ cần đọc đúng con số 500 là loại được ba phương án còn lại, vì cả ba đều đang mô tả nguyên nhân gây lỗi 4xx.

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

B — Enable Amazon CloudWatch metrics that include a metric for 5xx server errors. Retrying generally fixes this error.

Phương án này trả lời đúng cả hai vế mà đề yêu cầu:

• Theo dõi: S3 có nhóm CloudWatch request metrics ở mức bucket, trong đó có metric đếm riêng 5xx server errors. Bật nhóm metric này lên là đo được tần suất lỗi 500 theo thời gian, thay vì chỉ nghe người dùng phàn nàn.
• Khắc phục: lỗi 500 Internal Error của S3 là hiện tượng hiếm nhưng vẫn có thể xảy ra trong quá trình sử dụng bình thường. Cách xử lý được khuyến nghị là thử lại request (retry), tốt nhất là kèm exponential backoff để không dồn tải khi dịch vụ đang có vấn đề. Các AWS SDK đã có sẵn cơ chế retry tự động kèm exponential backoff, nên phần lớn trường hợp chỉ cần đảm bảo ứng dụng dùng SDK đúng cách hoặc bổ sung logic retry.

Nói cách khác, đây không phải lỗi "cần sửa cấu hình" mà là lỗi "cần chịu đựng đúng cách" — thiết kế ứng dụng để tự phục hồi trước các lỗi tạm thời của dịch vụ.

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

A — Check if the S3 bucket has all the objects users are trying to access. Object không tồn tại thì S3 trả 404 NoSuchKey, không phải 500. Ngoài ra phương án này chỉ nói tới việc kiểm tra thủ công, hoàn toàn không đáp ứng yêu cầu "theo dõi tần suất lỗi" của đề. Và nếu thiếu object thật thì lỗi phải xảy ra ổn định với đúng những object đó, mâu thuẫn với từ "intermittently".

C — Người dùng không đủ quyền, kiểm tra IAM Role trong logic ứng dụng. Đây là phương án dễ chọn nhầm nhất vì "sai quyền" là nguyên nhân rất phổ biến khi truy cập S3. Nhưng thiếu quyền IAM cho ra 403 Access Denied, thuộc dải 4xx. Nó cũng không giải thích được tính chập chờn: cùng một IAM Role, cùng một bucket policy thì kết quả đánh giá quyền là như nhau ở mọi lần gọi. Phương án hỏng ở chỗ chẩn đoán sai lớp lỗi — sửa quyền không làm lỗi 500 biến mất.

D — Object mã hoá bằng AWS KMS không truy cập được nếu thiếu quyền dùng KMS key. Bản thân câu mô tả về KMS là đúng: đọc object mã hoá bằng SSE-KMS thì caller phải có quyền trên chính KMS key, và nhiều người vấp đúng bẫy này. Nhưng hệ quả vẫn là 403 Access Denied, chứ không phải 500. Thêm nữa, đề không hề nhắc tới mã hoá KMS — phương án này tự đưa vào một tình huống không có trong đề, và vẫn bỏ trống vế "theo dõi tần suất".

Điểm chung của A, C, D: cả ba đều mô tả các dạng lỗi truy cập (4xx), trong khi đề hỏi về 500 (5xx).

📌 Điểm cần nhớ

• Đọc mã lỗi trước khi đọc phương án. 4xx = lỗi phía client (403 quyền, 404 không tìm thấy); 5xx = lỗi phía server. Câu hỏi nêu rõ mã lỗi thì mã lỗi chính là bộ lọc mạnh nhất.
• Từ "intermittent" loại gần hết các nguyên nhân cấu hình. IAM policy, bucket policy, quyền KMS, object thiếu — tất cả đều gây lỗi lặp lại đều đặn, không chập chờn.
• Cách xử lý chuẩn cho lỗi 5xx và throttling của S3 là retry với exponential backoff, và AWS SDK đã tích hợp sẵn cơ chế này.
• S3 CloudWatch request metrics (phải bật riêng, không có sẵn mặc định) là nơi đếm được 4xx và 5xx errors ở mức bucket — nhớ nó khi đề hỏi "làm sao đo tần suất lỗi của S3".