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

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

Đề mô tả một ứng dụng chạy trên EC2 trong Auto Scaling group, còn cơ sở dữ liệu là MySQL tự cài trên một EC2 instance — tức là database không nằm trong dịch vụ quản lý nào cả. Yêu cầu: tăng availability và durability của tầng database, đồng thời hạn chế tối đa việc phải sửa ứng dụng.

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

• "MySQL running on an Amazon EC2 instance" — mọi phương án nói tới tính năng của RDS (Multi-AZ, read replica) áp thẳng lên database hiện tại đều sai, vì đó là tính năng của RDS chứ không phải của một MySQL do bạn tự cài trong EC2.
• "minimizing application changes" — buộc phải giữ nguyên engine MySQL. Đổi sang engine khác nghĩa là đổi SQL dialect, driver, chuỗi kết nối, và rất nhiều thứ trong code.

Ghép hai ràng buộc lại: đáp án phải chuyển sang một dịch vụ database được quản lý, và dịch vụ đó phải tương thích MySQL.

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

Đáp án đúng theo tệp là B — migrate sang Amazon RDS Aurora và tạo một Aurora Replica ở Availability Zone khác.

Aurora Replica là một endpoint độc lập trong Aurora DB cluster, dùng cho hai việc: mở rộng khả năng đọc và tăng availability. Một cluster có thể có nhiều Aurora Replica trải trên các Availability Zone mà cluster đó bao phủ trong cùng một Region.

Điểm mấu chốt về availability: Aurora Replica đóng vai trò failover target. Khi primary instance hỏng, một Aurora Replica được promote lên làm primary — quá trình này do dịch vụ tự lo, ứng dụng không phải viết thêm logic chuyển đổi. Về durability, lớp lưu trữ của Aurora là storage layer riêng, tách khỏi compute instance, nhân bản qua nhiều Availability Zone — khác hẳn một ổ đĩa gắn vào một EC2 instance duy nhất như hiện trạng.

Còn ràng buộc "ít sửa ứng dụng": Aurora có phiên bản tương thích MySQL, nên ứng dụng đang nói chuyện với MySQL phần lớn chỉ cần đổi endpoint kết nối chứ không phải viết lại truy vấn.

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

A — Bật Multi-AZ cho database instance hiện tại. Đây là phương án bẫy gần nhất, vì Multi-AZ đúng là cách tăng availability và nó cũng đúng là "không đổi engine". Chỗ hỏng nằm ở chữ "existing database instance": database đang chạy MySQL tự cài trong EC2, mà Multi-AZ là một tính năng của Amazon RDS. Không thể bật Multi-AZ cho một database chạy trên EC2. Muốn có nó thì trước hết phải migrate sang RDS đã — mà bước migrate đó chính là thứ phương án này không hề nói tới.

C — Tạo RDS Microsoft SQL instance có Multi-AZ rồi backup và import dữ liệu sang. Phần hạ tầng thì hợp lý: RDS là dịch vụ quản lý, Multi-AZ cho availability, và đây thực sự là một cuộc migrate chứ không phải ảo tưởng như A. Nhưng nó đổi engine từ MySQL sang Microsoft SQL Server — đây là một thay đổi kiến trúc, kéo theo đổi dialect SQL, đổi driver, gần như chắc chắn phải sửa ứng dụng. Nó vi phạm thẳng ràng buộc "minimizing application changes", nên không phải đáp án tốt nhất.

D — Tạo read replica của database hiện tại và đặt một Application Load Balancer để chia đều kết nối. Sai ở cả hai vế. Vế một: read replica cũng là tính năng của RDS, không tạo được read replica cho một database chạy trên EC2. Vế hai: không dùng Elastic Load Balancer để phân phối kết nối tới database — ALB làm việc với HTTP/HTTPS, còn việc điều hướng giữa primary và replica là chuyện của endpoint database và logic kết nối, không phải của một load balancer ứng dụng. Ngoài ra read replica trước hết là công cụ mở rộng đọc, không tự nó giải quyết được durability.

📌 Điểm cần nhớ

• Multi-AZ và read replica là tính năng của Amazon RDS, không phải của một database engine tự cài trên EC2. Thấy đề nói "MySQL on an EC2 instance" mà phương án lại rủ bật Multi-AZ "cho instance hiện tại" thì đó là bẫy — phải migrate trước đã.
• Cụm "minimize application changes" gần như luôn là ràng buộc loại bỏ những phương án đổi database engine. Aurora MySQL-compatible tồn tại chính là để giữ được ràng buộc này khi rời khỏi MySQL tự quản lý.
• Aurora Replica vừa là read endpoint vừa là failover target: primary hỏng thì replica được promote lên. Đây là lý do nó được tính vào availability chứ không chỉ là chuyện mở rộng đọc.
• Load balancer không đứng trước database. ELB/ALB dành cho tầng ứng dụng; phương án nào bắt ALB chia kết nối tới các DB instance thì loại ngay không cần đọc tiếp.

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

Đề mô tả một SysOps Administrator đã có sẵn một CloudWatch alarm cấu hình gửi thông báo qua SNS khi CPU chạm 70% utilization. Việc cần làm không phải là tạo alarm, cũng không phải là đo CPU cho chính xác, mà là kiểm tra xem thông báo có được gửi đi thành công hay không.

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

• "needs to test ... to ensure the notification is delivered successfully" — mục tiêu là kiểm thử đường đi của thông báo (alarm → SNS → người nhận), chứ không phải kiểm thử ngưỡng đo lường.
• "How should the Administrator test that the alarm triggers the notification?" — cần một cách chủ động ép alarm đổi trạng thái, thay vì ngồi chờ tải thật vượt ngưỡng.

Khi đã xác định được rằng ta chỉ cần đẩy alarm vào trạng thái ALARM một cách nhân tạo, thì mọi phương án nói về việc tác động vào CPU thật hay đẩy dữ liệu sang một service không liên quan đều bị loại. Ràng buộc thứ hai là service nào sở hữu lệnh đó — CloudWatch hay CloudTrail — và chính điểm này phân biệt hai phương án nhìn rất giống nhau.

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

C. Use the set-alarm-state command in the AWS CLI for CloudWatch.

set-alarm-state là lệnh của CloudWatch trong AWS CLI, sinh ra đúng cho mục đích kiểm thử: nó cho phép đặt trạng thái của một alarm bằng tay (OK, ALARM, INSUFFICIENT_DATA) mà không cần metric thật thay đổi.

Điểm mấu chốt: khi trạng thái mới khác trạng thái trước đó, CloudWatch sẽ kích hoạt action đã cấu hình cho trạng thái đó. Với alarm trong đề — action là gửi message tới một SNS topic — thì việc tạm thời chuyển alarm sang ALARM sẽ khiến SNS message được gửi thật. Nhờ vậy Administrator xác nhận được toàn bộ chuỗi: alarm có gọi đúng action không, SNS topic có subscription đúng không, và người nhận có thật sự nhận được thư/tin nhắn không.

Đây là cách kiểm thử đúng bản chất: giữ nguyên cấu hình production của alarm, chỉ giả lập tín hiệu đầu vào, không phải đụng vào hạ tầng EC2 hay hạ ngưỡng 70% xuống cho dễ chạm.

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

A. Send custom metrics reporting that the CPU is running at 80% utilization to AWS CloudTrail. Sai ở đích đến. CloudTrail là service ghi lại API activity — ai gọi API nào, lúc nào, từ đâu — chứ không phải nơi nhận dữ liệu đo hiệu năng. Custom metric phải được đẩy vào CloudWatch mới có ý nghĩa. Gửi metric sang CloudTrail đơn giản là không tồn tại như một thao tác hợp lệ, nên alarm sẽ không bao giờ thấy con số 80% đó.

B. Use the set-alarm-state command in AWS CloudTrail to invoke the Amazon SNS notification. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. Ý tưởng thì chuẩn — dùng set-alarm-state để ép alarm chuyển trạng thái — nhưng gán nhầm service. set-alarm-state là lệnh thuộc CloudWatch, không phải CloudTrail. CloudTrail không quản lý alarm nên cũng không có lệnh đổi trạng thái alarm. Nói cách khác, B đúng động từ nhưng sai chủ ngữ, và trong đề thi thì như vậy là sai hoàn toàn. Bài học rút ra: khi hai phương án chỉ khác nhau ở tên service, hãy đọc kỹ lệnh đó thuộc về namespace nào.

D. Manually configure the CPU to 80% utilization using the EC2 Management Console. EC2 Management Console không có tuỳ chọn nào cho phép "đặt" mức CPU utilization của một instance. CPU utilization là giá trị quan sát được do workload thực tế sinh ra, không phải một thiết lập có thể chỉnh. Muốn đẩy CPU lên cao thì phải chạy tải thật bên trong instance, và ngay cả khi làm được thì cách đó vẫn chậm, tốn kém, và không kiểm thử được trực tiếp đường đi của notification bằng cách ép trạng thái alarm.

📌 Điểm cần nhớ

• set-alarm-state là lệnh CloudWatch dành riêng cho việc kiểm thử alarm. Nó ép alarm sang trạng thái mong muốn và kích hoạt action tương ứng — dùng để xác minh SNS notification, không cần chờ metric thật.
• Action chỉ chạy khi trạng thái thay đổi. Đặt alarm sang đúng trạng thái nó đang có sẽ không kích hoạt gì; muốn thử lại thì phải đưa về OK rồi đẩy lên ALARM lần nữa.
• CloudWatch ≠ CloudTrail. CloudWatch lo metric, alarm và monitoring; CloudTrail lo audit log của các lời gọi API. Metric và alarm không bao giờ thuộc về CloudTrail — đây là cặp bẫy xuất hiện rất thường xuyên trong đề AWS.
• CPU utilization là số đo, không phải nút gạt. Không có cách nào "đặt" nó từ EC2 Console; mọi phương án nói tới việc chỉnh trực tiếp giá trị metric qua console đều loại được ngay.

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

Đề mô tả một tình huống rất cụ thể: AWS Personal Health Dashboard báo có scheduled maintenance sắp tác động lên một EC2 instance EBS-backed đang chạy việc quan trọng. Yêu cầu là instance phải sẵn sàng trong giờ làm việc và không được gián đoạn dịch vụ.

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

• "EBS-backed" — root volume nằm trên EBS, tách rời khỏi host. Nhờ vậy instance stop rồi start lại được mà dữ liệu root vẫn còn. Nếu là instance store-backed thì stop là mất sạch, và cả câu sẽ có lời giải khác.
• "available during business hours" — không phải "không bao giờ được dừng", mà là "không được dừng trong giờ làm việc". Ràng buộc này mở ra khả năng chủ động dừng máy vào lúc khác.

Ghép lại: câu hỏi không tìm cách tránh việc instance phải rời khỏi host đang bảo trì, mà tìm cách tự chọn thời điểm cho việc đó xảy ra, thay vì để AWS chọn hộ và rơi đúng giờ làm việc.

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

Đáp án đúng theo tệp là D — Stop and start the EC2 instance during a maintenance window outside of normal business hours.

Cơ chế đứng sau: khi bạn stop rồi start lại một EBS-backed instance, AWS thường đặt nó lên một host vật lý khác. Đây là điểm mấu chốt — scheduled maintenance được lên lịch cho một host cụ thể, nên khi instance đã không còn nằm trên host đó nữa, sự kiện bảo trì kia không còn liên quan tới nó.

Từ đó lời giải trở nên hiển nhiên: quản trị viên tự chủ động stop/start vào một maintenance window ngoài giờ làm việc. Có gián đoạn, nhưng là gián đoạn ngắn, do mình chọn thời điểm, và rơi vào lúc không ai dùng. Đúng yêu cầu "không gián đoạn trong giờ làm việc" của đề.

Lưu ý phân biệt với reboot: reboot giữ nguyên instance trên chính host cũ, nên không thoát khỏi lịch bảo trì. Chỉ có chu trình stop → start mới đưa instance sang phần cứng khác.

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

A. Tạo AMI rồi dùng AMI đó launch instance mới sau khi instance hiện tại đã shut down.

Đây là phương án gần đúng nhất và đáng phân tích kỹ. Nó có tạo ra một instance chạy trên host khác, nên về mặt kỹ thuật cũng thoát được đợt bảo trì. Chỗ hỏng nằm ở mệnh đề "after the current instance is shut down" — tức là chờ tới lúc máy bị tắt rồi mới dựng máy mới. Nếu máy bị tắt bởi chính đợt bảo trì thì cú tắt đó rơi vào giờ làm việc, và khoảng thời gian tạo AMI + launch instance mới hoàn toàn nằm trong giờ làm việc. Thêm nữa, instance mới có ID mới, private IP mới, phải gắn lại Elastic IP, đăng ký lại vào target group — nhiều việc và nhiều rủi ro hơn hẳn so với một chu trình stop/start đơn giản. Nó giải quyết vấn đề bằng con đường dài hơn mà vẫn không tránh được gián đoạn trong giờ làm.

B. Dùng EC2 Management Console để chuyển instance sang host hardware khác.

Sai vì không tồn tại chức năng đó. EC2 Management Console không có nút "move to another host". Đây là phương án bẫy kiểu "mô tả đúng kết quả mong muốn bằng một thao tác không có thật" — kết quả (đổi host) chính là điều đáp án D đạt được, nhưng cách đạt tới nó là stop/start chứ không phải một lệnh di chuyển trong console. Ai đọc lướt và thấy "different host hardware" khớp với trực giác sẽ chọn nhầm ở đây.

C. Cấu hình CloudWatch Events rule để restart instance khi nó bị stopped.

Đây là phương án phản ứng sau sự việc, không phải phòng ngừa. Đợt bảo trì vẫn diễn ra đúng lịch, instance vẫn bị dừng đúng trong giờ làm việc, và rule chỉ khởi động lại nó sau khi gián đoạn đã xảy ra. Yêu cầu của đề là "an interruption in service is unacceptable" — một cơ chế tự phục hồi vẫn để lại khoảng thời gian downtime, nên không thoả. Nó rút ngắn thời gian chết chứ không loại bỏ nó.

📌 Điểm cần nhớ

• Stop → start một EBS-backed instance thường đưa nó sang host vật lý khác, nên đây là cách chuẩn để né scheduled maintenance đã lên lịch cho host cũ. Reboot thì không — reboot giữ nguyên host.
• Chữ "EBS-backed" trong đề không phải chi tiết trang trí: nó là điều kiện cho phép stop/start mà không mất dữ liệu root.
• Khi đề nói "không được gián đoạn trong giờ làm việc", hãy tìm phương án chủ động chọn thời điểm gián đoạn, đừng tìm phương án "hoàn toàn không gián đoạn".
• Cảnh giác với phương án mô tả đúng kết quả mong muốn nhưng bằng một thao tác console không tồn tại — EC2 Management Console không có chức năng chuyển instance sang host khác.
• Cơ chế tự động phục hồi (CloudWatch Events restart) là giảm thiểu hậu quả, không phải phòng ngừa; với đề yêu cầu zero interruption thì loại.

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

Đề mô tả một chuỗi sự kiện rất cụ thể: "A network administrator made a change to the networking configuration of an Amazon VPC. After the change..." — một thay đổi cấu hình mạng trong VPC, và ngay sau đó EC2 application server không kết nối được tới RDS MySQL. Câu hỏi là SysOps Administrator nên phân tích cái gì để tìm root cause.

Cụm từ quyết định đáp án nằm ở hai chỗ ghép lại:

• "change to the networking configuration" — nguyên nhân nghi ngờ nằm ở tầng mạng (security group, network ACL, route table, subnet), không phải ở tầng ứng dụng hay tầng database engine.
• "After the change" — mối quan hệ nhân quả theo thời gian. Sự cố xuất hiện đúng sau thay đổi mạng, nên hướng điều tra phải bám vào chính thứ vừa bị đổi.

Nói cách khác, đề không hỏi "log nào ghi lại lỗi kết nối", mà hỏi "log nào cho thấy traffic giữa EC2 và RDS có bị chặn ở tầng mạng hay không". Đó là ràng buộc phân biệt bốn phương án.

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

A. VPC Flow Logs là đáp án đúng.

VPC Flow Logs ghi lại thông tin về IP traffic đi vào và đi ra các network interface trong VPC. Mỗi bản ghi cho biết source/destination IP, port, protocol, hướng của traffic, và — quan trọng nhất với ca này — traffic đó được ACCEPT hay REJECT.

Áp vào tình huống của đề: bật flow logs trên ENI của EC2 instance hoặc của RDS instance, rồi tìm các bản ghi tới cổng MySQL. Kết quả đọc ra ngay:

• Có bản ghi REJECT → traffic đã tới nơi nhưng bị security group hoặc network ACL chặn. Đây chính là điều mà một thay đổi cấu hình mạng vừa gây ra.
• Không có bản ghi nào ở phía RDS → gói tin thậm chí không đi tới được, gợi ý vấn đề định tuyến (route table, subnet).

Tài liệu AWS nêu thẳng các công dụng của flow logs, trong đó có chẩn đoán security group rule quá chặt, giám sát traffic đang tới instance, và xác định hướng của traffic — đúng ba thứ cần để lần ra một thay đổi mạng vừa làm hỏng kết nối.

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

B. Amazon Elastic Load Balancing logs — Sai vì không có load balancer nào nằm giữa application server và RDS database. ELB đứng trước một nhóm compute target để phân phối traffic đến từ client; đường EC2 → RDS là kết nối trực tiếp tới database endpoint, không đi qua ELB. Log của một thành phần không nằm trên đường đi của kết nối bị lỗi thì không thể chứa manh mối về kết nối đó. Đây là phương án dễ loại nhất vì nó hỏng ngay ở mức "sai kiến trúc", chứ không phải "kém hiệu quả".

C. Amazon Auto Scaling logs — Sai. Auto Scaling lo việc tăng giảm số lượng instance theo tải; nó không phải nguyên nhân hợp lý cho một sự cố xuất hiện ngay sau khi ai đó đổi cấu hình mạng. Kể cả có xem hoạt động scaling đi nữa, thứ tìm được cũng chỉ là instance được thêm hay bớt lúc nào — không nói gì về việc gói tin tới cổng MySQL bị chặn hay không. Đề đã chỉ rõ tầng cần điều tra là tầng mạng, phương án này nhìn sang tầng khác.

D. Amazon RDS MySQL error logs — Đây là phương án gần đúng nhất và cần cẩn thận. Nó sai không phải vì log này vô dụng nói chung, mà vì nó hỏng ở đúng chỗ mấu chốt: khi một thay đổi mạng chặn traffic, gói tin không bao giờ tới được database engine, nên MySQL không có gì để ghi lại. Error log của MySQL hữu ích cho các lỗi phát sinh sau khi kết nối đã thiết lập — sai credential, hết max connections, lỗi truy vấn, sự cố của engine. Với sự cố tầng mạng, log này thường im lặng hoàn toàn, và sự im lặng đó lại rất dễ khiến người điều tra đi lạc hướng. Ngoài ra RDS là managed service nên góc nhìn dưới tầng database bị giới hạn — càng phải quan sát từ phía VPC.

📌 Điểm cần nhớ

• Bám vào thứ vừa thay đổi. Đề nêu rõ "sau khi đổi cấu hình mạng" thì công cụ điều tra phải là công cụ quan sát tầng mạng. Đây là mẫu ra đề rất phổ biến: một mệnh đề chỉ ra tầng bị tác động, và đáp án đúng là log/tool của đúng tầng đó.
• VPC Flow Logs là công cụ mặc định cho "tại sao A không kết nối được tới B trong VPC". Nó trả lời được cả hai câu hỏi: gói tin có tới nơi không, và tới nơi rồi thì bị ACCEPT hay REJECT — đủ để phân biệt lỗi security group/NACL với lỗi routing.
• Log của tầng ứng dụng im lặng không có nghĩa là ứng dụng ổn. Traffic bị chặn ở tầng mạng thì RDS MySQL error log sẽ trống trơn. Đừng suy ra "database không có vấn đề gì" rồi bỏ qua hướng điều tra đúng.
• Loại phương án bằng cách vẽ đường đi của kết nối. Thành phần nào không nằm trên đường EC2 → RDS thì log của nó không liên quan — ELB và Auto Scaling bị loại theo đúng nguyên tắc này.

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

Đề đặt ra một yêu cầu tuân thủ cụ thể: khoá mã hoá phải được xoay (rotate) ít nhất mỗi 365 ngày để phục vụ kỳ audit. Sau đó hỏi cách nào đáp ứng được yêu cầu này với "the LEAST amount of operational overhead".

Có hai cụm từ quyết định đáp án, và phải đọc cả hai cùng lúc:

• "encryption keys must be rotated ... once every 365 days" — đây là ràng buộc bắt buộc phải đạt được, tức phương án nào không thực sự xoay khoá thì loại thẳng.
• "LEAST amount of operational overhead" — đây là ràng buộc phân biệt giữa những phương án đều đúng về mặt kỹ thuật. Automatic key rotation của KMS là cơ chế do AWS lo hoàn toàn, không cần code, không cần lịch chạy, không cần ai theo dõi; còn tự viết Lambda thì phải nuôi thêm hàm, thêm quyền, thêm giám sát.

Ngoài ra còn một chi tiết ngầm rất hay bị bỏ qua: đề nói công ty phải chứng minh mình kiểm soát được chính sách xoay khoá. Điều đó đẩy lựa chọn về phía customer-managed CMK thay vì AWS-managed CMK, vì chỉ loại đầu mới cho phép bật/tắt và cấu hình rotation.

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

Đáp án đúng theo tệp là B — Use customer-managed customer master keys (CMKs) in AWS KMS and enable automatic key rotation.

Với customer-managed CMK trong AWS KMS, automatic key rotation mặc định tắt. Khi bạn bật (hoặc bật lại), AWS KMS sẽ tự xoay key material của CMK đó sau 365 ngày kể từ ngày bật, và lặp lại mỗi 365 ngày sau đó. Đúng bằng chu kỳ mà yêu cầu tuân thủ đòi hỏi.

Ba điểm khiến đây là phương án tốn ít công vận hành nhất:

• Chỉ là một thao tác cấu hình bật cờ trên CMK, không có mã nguồn nào phải viết và bảo trì.
• AWS KMS giữ lại key material cũ nên dữ liệu mã hoá trước đó vẫn giải mã được bình thường, không phải làm chiến dịch mã hoá lại.
• Key ID và ARN không đổi, nên các ứng dụng, policy và tài nguyên đang trỏ tới CMK này không cần sửa gì.

Vì là customer-managed CMK, đội vận hành cũng nắm quyền cấu hình và có bằng chứng rõ ràng về chính sách rotation để đưa cho auditor.

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

A. Use AWS-managed CMKs and enable automatic key rotation. Đây là phương án gần đúng nhất và cũng dễ bẫy nhất. Đúng là AWS KMS có tự xoay AWS-managed CMK theo chu kỳ hằng năm. Chỗ hỏng nằm ở vế "enable automatic key rotation": với AWS-managed CMK, bạn không quản lý được rotation — không bật, không tắt, không chỉnh. Việc xoay khoá do AWS lo và bạn chỉ là người nhận kết quả. Nghĩa là hành động mà phương án A mô tả không phải thứ bạn thực hiện được, nên nó không phải "action should be taken" hợp lệ.

C. Import key material into CMKs in AWS KMS. Create an AWS Lambda function to rotate the keys. Phương án này có thể đạt được mục tiêu tuân thủ, nhưng thua hẳn ở tiêu chí đề ra. Khi bạn import key material của mình vào KMS, tính năng automatic key rotation của KMS không dùng được cho khoá đó — chính vì vậy mới phải viết Lambda để tự xoay. Kết quả là bạn gánh thêm: một hàm Lambda phải viết và bảo trì, lịch chạy phải cấu hình, IAM permission phải cấp, lỗi phải giám sát, và bản thân key material phải tự quản lý vòng đời bên ngoài. Đó chính là "operational overhead" mà đề bảo phải giảm thiểu.

D. Use customer-managed CMKs in AWS KMS and enforce key rotation with AWS Trusted Advisor. Nửa đầu đúng (customer-managed CMK), nhưng nửa sau sai về bản chất công cụ. AWS Trusted Advisor không enforce được key rotation. Trusted Advisor là công cụ đưa ra khuyến nghị theo các hạng mục như tối ưu chi phí, hiệu năng, bảo mật, khả năng chịu lỗi và service limit — nó quan sát và gợi ý, chứ không phải cơ chế thực thi chính sách trên KMS. Chọn D thì yêu cầu 365 ngày sẽ không bao giờ được thực hiện, dù cấu hình trông có vẻ hợp lý.

📌 Điểm cần nhớ

• AWS-managed CMK vs customer-managed CMK: cả hai đều có rotation, nhưng chỉ customer-managed CMK mới cho bạn bật/tắt và cấu hình automatic key rotation. Đề nào có động từ "enable", "configure", "control" rotation thì đáp án gần như chắc chắn là customer-managed.
• Import key material là đánh đổi: được toàn quyền với key material, nhưng mất automatic key rotation của KMS và phải tự dựng cơ chế xoay khoá. Trong đề thi, cụm này gần như luôn báo hiệu "nhiều operational overhead".
• Trusted Advisor chỉ khuyến nghị, không enforce. Bất kỳ phương án nào ghép Trusted Advisor với động từ mang nghĩa cưỡng chế (enforce, prevent, block, require) đều đáng nghi.
• Đọc kỹ tiêu chí phân biệt trong đề. Khi đề nói "LEAST operational overhead", hãy ưu tiên tính năng có sẵn (managed feature) hơn giải pháp tự viết bằng Lambda — kể cả khi cả hai đều đạt được mục tiêu kỹ thuật.

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

Đề mô tả một EC2 instance chạy application server bị sập vì EBS volume hết dung lượng, và hỏi cách ngăn chuyện đó tái diễn. Đây là câu hỏi về giám sát chủ động: phải phát hiện dung lượng đĩa sắp cạn trước khi nó cạn thật.

Cụm từ quyết định đáp án là "EBS volume running out of space" — tức là disk space / disk utilization, mức sử dụng dung lượng bên trong file system. Đây chính là điểm phân biệt: dung lượng đĩa còn trống là thứ chỉ hệ điều hành bên trong instance mới biết. Hypervisor của EC2 nhìn thấy CPU, network, disk I/O của instance, nhưng không nhìn được file system đã dùng bao nhiêu phần trăm — nó không biết instance định dạng volume bằng gì, mount ở đâu, còn bao nhiêu inode.

Vì vậy mọi phương án chỉ dựa vào metric mặc định của EC2, vào status check, hay vào API phía dịch vụ đều trượt. Chỉ phương án nào đưa được một agent vào bên trong instance mới lấy được con số đó.

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

Đáp án đúng là A — cài Amazon CloudWatch agent lên EC2 instance để thu thập disk metrics, rồi tạo CloudWatch alarm báo cho quản trị viên khi dung lượng đĩa xuống thấp.

CloudWatch agent chạy như một tiến trình trong hệ điều hành của instance, nên nó đọc được những thứ mà hypervisor không thấy: mức sử dụng file system trên từng mount point, dung lượng còn trống, và cả memory. Agent đẩy các giá trị này lên CloudWatch dưới dạng custom metrics; từ đó tạo alarm với ngưỡng phù hợp (ví dụ dung lượng đã dùng vượt một mức nhất định) và gắn hành động thông báo.

Đây đúng là mẫu hình chuẩn cho bài toán "giám sát disk space trên EC2": muốn có metric disk utilization thì phải dùng CloudWatch agent, không có đường tắt nào khác.

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

B — Bật detailed monitoring cho EC2 rồi tạo CloudWatch alarm. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. Detailed monitoring chỉ thay đổi tần suất báo cáo metric — đưa metric từ mức thưa hơn về mức dày hơn — chứ không thêm loại metric mới nào. Tập metric mặc định của EC2 vẫn không có disk utilization của file system. Bật detailed monitoring xong, ta có metric CPU và network dày đặc hơn, còn ô "disk space còn lại" vẫn trống trơn nên chẳng có gì để đặt alarm. Muốn có metric đó vẫn phải dùng CloudWatch agent.

C — Dùng CloudWatch Events theo dõi EC2 status checks để biết trạng thái EBS volume. Sai ở chỗ EC2 status checks không cho biết trạng thái của EBS volume. Status check của EC2 kiểm tra sức khoẻ của hạ tầng bên dưới và khả năng phản hồi của bản thân instance — hoàn toàn khác chuyện file system còn bao nhiêu chỗ trống. Ngoài ra, phương án này thiên về phát hiện thiết bị hỏng ("impaired"), tức là phản ứng sau khi có sự cố, trong khi đề yêu cầu ngăn sự cố xảy ra. Đĩa đầy không làm volume "impaired"; volume vẫn khoẻ mạnh về mặt hạ tầng, chỉ là không còn chỗ ghi.

D — Viết Lambda function đọc disk space metrics qua Amazon EBS API. Sai ở tiền đề: không thể lấy mức sử dụng dung lượng của một EBS volume qua EBS API. API của EBS làm việc ở tầng thiết bị khối — tạo, gắn, tách, snapshot, xem kích thước và loại volume — chứ không nhìn vào nội dung file system nằm trên volume đó. EBS chỉ thấy các block, còn "còn trống bao nhiêu" là khái niệm của file system do hệ điều hành quản lý. Lambda có gọi API bao nhiêu lần cũng không lấy ra được con số cần thiết, chưa kể phương án này còn dựng thêm hạ tầng tự viết để làm việc mà CloudWatch agent đã làm sẵn.

📌 Điểm cần nhớ

• Disk space và memory trên EC2 luôn cần CloudWatch agent. Metric mặc định do hypervisor sinh ra chỉ thấy được thứ ở ngoài hệ điều hành; bất cứ câu hỏi nào nhắc đến disk utilization hay memory utilization thì đáp án gần như chắc chắn có chữ "CloudWatch agent".
• Detailed monitoring = dày hơn, không phải nhiều loại hơn. Nó chỉ đổi tần suất báo cáo metric có sẵn, không bổ sung metric mới. Đây là bẫy quen thuộc, đặt cạnh phương án CloudWatch agent để đánh lừa.
• EC2 status checks nói về sức khoẻ instance và hạ tầng, không nói về EBS volume hay dung lượng còn trống. Đừng dùng chúng để suy ra tình trạng lưu trữ.
• Phân biệt tầng block và tầng file system. EBS API làm việc với volume như một thiết bị khối; mức sử dụng file system chỉ hệ điều hành bên trong instance mới biết. Nắm ranh giới này thì loại được ngay các phương án gọi API phía dịch vụ để đo disk space.

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

Đề đặt ra một tình huống rất cụ thể: dùng một CloudFormation template duy nhất để tạo và quản lý stack across multiple AWS accounts and regions, và làm điều đó with a single operation.

Cụm từ quyết định đáp án nằm gọn ở đây: "across multiple AWS accounts and regions with a single operation". Không phải "tái sử dụng template", không phải "xem trước thay đổi", không phải "bảo vệ tài nguyên khỏi bị sửa" — mà là phạm vi triển khai trải rộng nhiều account và nhiều region, gom vào một thao tác.

Đây là điểm phân biệt sống còn, vì cả bốn phương án đều là feature có thật của CloudFormation và đều nghe hợp lý với người mới. Chỉ có đúng một feature được thiết kế để mở rộng phạm vi ra ngoài ranh giới một account, một region — vốn là giới hạn mặc định của một stack thông thường.

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

Đáp án đúng theo tệp là C — StackSets.

Một stack set mở rộng khái niệm stack: thay vì một stack sống trong một account tại một region, stack set cho phép bạn khai báo template một lần rồi triển khai nó thành nhiều stack instance ở các account và region mục tiêu do bạn chỉ định. Toàn bộ tài nguyên trong mỗi stack đều được định nghĩa bởi chính template của stack set; khi tạo stack set bạn khai template, các parameter và các capability mà template đó cần.

Sau khi stack set đã được định nghĩa, bạn có thể tạo, cập nhật hoặc xoá stack ở các target account và region chỉ bằng thao tác trên stack set — đúng nghĩa "a single operation" mà đề nhắc tới. StackSets còn cho khai operation preferences: thứ tự region thực hiện, ngưỡng chịu lỗi (failure tolerance) mà vượt qua đó thì thao tác dừng lại, và số lượng account được xử lý đồng thời. Những tuỳ chọn này chính là dấu hiệu cho thấy feature được sinh ra cho bài toán triển khai diện rộng, chứ không phải cho một stack đơn lẻ.

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

A — Nested stacks. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì nó cũng liên quan tới "nhiều stack". Nhưng nested stack là stack được tạo như một phần của một stack khác: template cha khai một resource kiểu AWS::CloudFormation::Stack trỏ tới template con. Nó giải quyết bài toán tái sử dụng và chia nhỏ template cho khỏi phình to, chứ không đụng gì tới ranh giới account hay region — cả cây nested stack vẫn nằm trong đúng một account và đúng một region. Đề hỏi về phạm vi triển khai, không hỏi về cấu trúc template.

B — Stack policies. Sai hẳn hướng. Stack policy là một tài liệu JSON định nghĩa những hành động update nào người dùng CloudFormation được phép thực hiện và áp dụng lên những resource nào trong stack. Nó là cơ chế bảo vệ: chặn việc vô ý thay thế hay xoá một resource nhạy cảm (chẳng hạn database) khi update stack. Đây là chuyện kiểm soát thay đổi bên trong một stack, không phải chuyện nhân bản stack ra nhiều nơi.

C — StackSets. Đáp án đúng, đã phân tích ở trên.

D — Change sets. Cũng là phương án nghe "quản trị" nên dễ chọn nhầm. Change set cho phép bạn xem trước những thay đổi sẽ xảy ra với một stack trước khi thực sự áp dụng chúng — CloudFormation liệt kê resource nào bị thêm, sửa, hay thay thế để bạn duyệt rồi mới execute. Giá trị của nó là giảm rủi ro khi update, hoàn toàn không liên quan tới việc trải template qua nhiều account và region.

📌 Điểm cần nhớ

• Thấy cụm "multiple accounts and/or multiple regions" đi kèm CloudFormation trong đề thi → gần như chắc chắn đáp án là StackSets. Đây là feature duy nhất trong nhóm này vượt ra khỏi giới hạn một-account-một-region của stack thường.
• Phân biệt bốn feature theo bài toán chúng giải, không theo tên nghe giống nhau: StackSets = phạm vi triển khai; Nested stacks = cấu trúc và tái sử dụng template; Change sets = xem trước thay đổi; Stack policies = bảo vệ resource khi update.
• Nested stacks là bẫy kinh điển vì cũng có chữ "nhiều stack". Hãy tự hỏi: các stack đó nằm ở đâu? Nested stack luôn nằm cùng account, cùng region với stack cha.
• StackSets có sẵn operation preferences (thứ tự region, failure tolerance, số account chạy song song) — chi tiết này thường xuất hiện trong các câu hỏi nâng cao về kiểm soát rủi ro khi rollout diện rộng.

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

Đề mô tả một static website chạy trên Amazon S3, và bucket đang nhận tỷ lệ read operations rất cao. Câu hỏi yêu cầu tìm cách làm hai việc cùng lúc: minimize latency (giảm độ trễ cho người dùng) và reduce the load on the S3 bucket (giảm tải cho chính bucket).

Cụm từ quyết định đáp án chính là liên từ "and" trong "minimize latency and reduce the load on the S3 bucket". Rất nhiều phương án ở đây chạm được một vế — đưa dữ liệu tới gần người dùng hơn — nhưng chỉ một phương án làm được cả vế thứ hai: chặn bớt request trước khi chúng đến S3.

Ràng buộc phụ, cũng quan trọng không kém: nội dung là static (static website). Dữ liệu tĩnh là thứ cache được ở biên mạng mà không sợ lệch dữ liệu. Và đề không nói người dùng ở đâu — không có câu nào chỉ ra họ tập trung tại một khu vực, nên mọi giải pháp giả định "người dùng ở gần vùng X" đều đang thêm thông tin mà đề không cho.

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

D — Create an Amazon CloudFront distribution with the S3 bucket as the origin.

CloudFront là CDN của AWS. Khi tạo một distribution lấy S3 bucket làm origin, nội dung tĩnh được cache tại các Edge Location trải khắp thế giới.

Điều này giải quyết trọn vẹn cả hai yêu cầu của đề:

• Giảm latency: request của người dùng kết thúc tại edge location gần họ nhất về mặt mạng, thay vì phải đi tới tận vùng chứa bucket. Vì edge location có mặt ở nhiều nơi, cách này phục vụ được cả người dùng phân tán toàn cầu — không cần biết trước họ ở đâu.
• Giảm tải cho bucket: đây là điểm mấu chốt. Khi một object đã nằm trong cache ở edge, các request tiếp theo cho object đó được trả lời ngay tại edge, không đi ngược về S3. Origin chỉ bị gọi khi cache miss hoặc khi nội dung hết hạn. Với static website — nội dung ít đổi, tỷ lệ cache hit cao — lượng read operations chạm tới bucket giảm rất mạnh.

Cấu hình S3 làm origin cho CloudFront là mẫu triển khai chuẩn cho static website, và nó không đòi hỏi thay đổi gì trong cách tổ chức dữ liệu trên bucket.

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

A — Use Amazon ElastiCache Redis to cache the static data from the S3 bucket. ElastiCache là cache in-memory đặt trước database, phục vụ ứng dụng của bạn qua giao thức Redis/Memcached bên trong VPC. Nó không cắm được vào giữa client và S3: nó không tự lấy object từ bucket, và người dùng cuối duyệt web không nói chuyện với Redis. Ngoài ra ElastiCache nằm trong một vùng cụ thể, nên nó cũng không giải quyết được vế latency cho người dùng phân tán.

B — Use cross-region replication (CRR) to replicate the data to another region. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất. CRR đúng là tạo ra một bản sao dữ liệu ở vùng khác, tức là dữ liệu có nằm gần một nhóm người dùng nào đó hơn. Nhưng nó hỏng ở chỗ: CRR chỉ sao chép dữ liệu, nó không định tuyến người dùng. Bản sao ở vùng thứ hai có endpoint riêng, và phải có thêm một cơ chế nữa mới đẩy được người dùng sang đó — thứ mà phương án này hoàn toàn không nhắc tới. Chưa kể CRR chỉ nhân đôi số bucket chứ không loại bỏ request nào: mỗi lượt đọc vẫn là một read operation trên một bucket S3 nào đó, nên vế "reduce the load" không được đáp ứng.

C — Migrate to a bucket in an AWS Region that is closer to the end users. Phương án này ngầm giả định người dùng tập trung ở một nơi — nhưng đề không hề nói vậy, họ hoàn toàn có thể phân tán toàn cầu. Khi đó "gần hơn với nhóm này" đồng nghĩa "xa hơn với nhóm kia". Quan trọng hơn: dời bucket sang vùng khác chỉ đổi khoảng cách, chứ số lượng read operations đập vào bucket vẫn y nguyên. Tải không giảm một chút nào.

📌 Điểm cần nhớ

• Câu hỏi có cụm "reduce the load on the origin/bucket" hầu như luôn dẫn tới một lớp cache, không phải một bản sao dữ liệu. Nhân bản dữ liệu (CRR) làm dữ liệu ở nhiều nơi hơn, nhưng không xoá đi request nào.
• CloudFront = giảm latency + giảm tải origin cùng một lúc; CRR và đổi Region chỉ chạm được vế latency, và chỉ chạm được khi biết người dùng ở đâu.
• Cặp S3 + CloudFront là mẫu chuẩn cho static website. Thấy "static content" và "high read rate" trong cùng một đề thì CloudFront gần như luôn là đáp án.
• CRR không tự định tuyến người dùng. Một phương án nhân bản dữ liệu mà không kèm cơ chế đưa người dùng tới bản sao là phương án chưa hoàn chỉnh.
• ElastiCache cache cho database và ứng dụng trong VPC, không phải cache cho S3 hay cho lưu lượng web của người dùng cuối. Đây là bẫy quen thuộc: nghe thấy "cache" là chọn ElastiCache, nhưng cache ở biên mạng cho web tĩnh là việc của CloudFront.

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

Đề mô tả một ứng dụng đang thử tải: EC2 chạy trong Auto Scaling group, database là RDS Multi-AZ, còn static content nằm trong một S3 bucket. Khi chạy performance testing, thời gian phản hồi tăng lên rõ rệt. Câu hỏi là làm sao tăng performance và scalability.

Cụm từ quyết định đáp án là "Static content is hosted in an Amazon S3 bucket" cộng với "expected to receive a large amount of traffic". Đề đã cố ý kể ra ba tầng của kiến trúc, trong đó hai tầng đã có sẵn cơ chế co giãn: EC2 nằm trong Auto Scaling group, RDS chạy Multi-AZ. Tầng duy nhất được nêu ra mà chưa có lớp tăng tốc nào là static content. Đó là chỗ đề muốn bạn động vào.

Thêm một chi tiết nữa: đề nói "increase the performance and scalability" — hai yêu cầu cùng lúc. Phương án nào chỉ đổi chỗ lưu trữ mà không giảm tải hay không rút ngắn quãng đường tới người dùng thì trượt ở vế thứ hai.

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

B — Use Amazon CloudFront to cache the static content.

CloudFront là CDN của AWS: nó đặt bản sao nội dung ở các edge location trải khắp thế giới, người dùng lấy nội dung từ edge gần mình thay vì đi thẳng về Region chứa S3 bucket. Với static content — ảnh, CSS, JS, video — đây đúng là dạng dữ liệu hợp với cache nhất: nó không đổi theo từng người dùng nên một bản cache phục vụ được cho rất nhiều request.

Hai tác dụng khớp đúng hai yêu cầu của đề:

• Performance: quãng đường mạng ngắn lại, độ trễ giảm, đặc biệt với người dùng ở xa Region đang host dữ liệu — đây chính là điều bản giải thích tiếng Anh của nguồn nhấn mạnh.
• Scalability: request static được phục vụ ngay tại edge, không chạm tới origin. Lưu lượng lớn ập vào cũng không dồn hết về S3 và về hạ tầng phía sau.

CloudFront tích hợp sẵn với S3 làm origin, nên đây là cách gắn thêm lớp cache mà không phải sửa kiến trúc đang có.

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

A — Serve the static content from the EC2 instances backed by an Amazon EFS filesystem.

Đây là phương án đi lùi. Static content đang nằm trên S3 — một object store được thiết kế để phục vụ nội dung tĩnh ở quy mô lớn. Chuyển nó sang EFS rồi bắt EC2 phục vụ nghĩa là bạn đẩy thêm tải lên chính tầng EC2 đang chậm: mỗi request ảnh, CSS, JS giờ đều tiêu tốn CPU và băng thông của instance, thay vì được S3 gánh hộ. Người dùng vẫn phải đi về đúng Region đó, độ trễ không đổi. Không cải thiện performance, cũng không cải thiện scalability.

C — Move the database from Amazon RDS to Amazon ElastiCache for Memcached.

Phương án này hỏng ở chữ "Move". Memcached là in-memory cache, không phải kho lưu trữ bền vững — dữ liệu trong đó có thể mất khi node khởi động lại hoặc bị thay thế. "Chuyển database sang ElastiCache" là bỏ đi tính bền vững của dữ liệu, một chuyện không ai làm.

Cần nói rõ vì đây là phương án gần đúng nhất trong ba cái sai: đặt ElastiCache ở phía trước RDS để cache kết quả truy vấn là một cách hợp lệ và phổ biến để giảm tải database. Nhưng đó là một phương án khác, không phải cái đề viết. Đề viết là "move the database from RDS to ElastiCache", tức thay thế chứ không phải bổ sung. Đọc đúng động từ mới loại được nó.

D — Use Amazon Route 53 with geolocation routing.

Geolocation routing định tuyến người dùng tới endpoint khác nhau dựa trên vị trí địa lý của họ. Nó chỉ có ý nghĩa khi bạn đã triển khai ứng dụng ở nhiều Region và muốn hướng khách tới bản gần nhất — hoặc muốn phục vụ nội dung khác nhau theo quốc gia. Trong tình huống này đề chỉ mô tả một triển khai duy nhất: một Auto Scaling group, một RDS Multi-AZ (Multi-AZ là nhiều Availability Zone trong cùng một Region, không phải nhiều Region). Route 53 sẽ trỏ tất cả mọi người về đúng cái endpoint duy nhất đó, bất kể họ ở đâu — không có gì thay đổi về tốc độ hay khả năng chịu tải.

📌 Điểm cần nhớ

• Static content chậm dưới tải lớn → nghĩ tới CloudFront trước tiên. Cặp S3 + CloudFront là mẫu kiến trúc chuẩn: S3 làm origin, CloudFront cache ở edge, giảm cả latency lẫn tải lên origin.
• ElastiCache đứng trước database, không thay thế database. Đề bài dùng động từ "move"/"replace" với ElastiCache gần như luôn là phương án sai, vì cache không bền vững.
• Multi-AZ ≠ Multi-Region. Multi-AZ lo tính sẵn sàng trong một Region. Mọi phương án dựa trên định tuyến đa Region (như Route 53 geolocation) chỉ đúng khi đề thực sự nói có nhiều Region.
• Khi đề liệt kê từng tầng của kiến trúc, hãy tìm tầng chưa được tối ưu. EC2 đã có Auto Scaling, RDS đã có Multi-AZ — tầng còn lại là chỗ câu hỏi nhắm tới.

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

Đề mô tả một tình huống rất cụ thể: quản lý muốn Developer trong một testing account chỉ được dùng đúng instance type t2.micro. SysOps Administrator đã tạo một SCP trong AWS Organizations và gắn đúng OU rồi, nhưng Developer vẫn launch được các instance type khác. Câu hỏi là: cần sửa gì trong policy statement của SCP đó.

Cụm từ quyết định nằm ở chính đoạn ảnh chụp policy kèm theo và ở ba chữ trong đề: SCP hiện tại dùng Effect: Deny, nhưng lại kèm một Condition so khớp kiểu StringEquals với ec2:InstanceType là t2.micro. Ghép hai thứ đó lại thì ý nghĩa thực tế của policy là: "cấm launch khi instance type bằng t2.micro" — tức là cấm đúng cái loại duy nhất đáng lẽ phải được phép, và mọi loại khác thì policy không nói gì nên vẫn chạy bình thường. Logic bị đảo ngược, chứ không phải policy chưa được áp dụng.

Điểm cần nhìn ra: khi Effect là Deny, Condition mô tả trường hợp bị chặn, không phải trường hợp được cho phép. Đây là chỗ hầu hết người làm bài đọc lướt và trượt.

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

Đáp án đúng theo tệp là C — Change the Condition statement to StringNotEquals.

Đổi toán tử so khớp từ StringEquals sang StringNotEquals sẽ khiến câu lệnh đọc thành: deny mọi request ec2:RunInstances mà trong đó ec2:InstanceType khác t2.micro. Kết quả đúng bằng yêu cầu của quản lý: t2.micro không rơi vào điều kiện deny nên vẫn launch được, còn m5.large, c5.xlarge hay bất kỳ loại nào khác đều khớp điều kiện và bị chặn.

Đây cũng là cách viết chuẩn mà tài liệu AWS Organizations dùng cho ví dụ giới hạn instance type: giữ Effect: Deny và dùng phủ định trong Condition, thay vì cố diễn đạt bằng Allow. Với SCP thì cách này càng hợp lý vì SCP là guardrail — nó đặt trần quyền cho account, và một Deny có điều kiện phủ định sẽ áp cho mọi principal trong OU, kể cả người có quyền admin trong account đó.

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

A — Change the Effect statement from Deny to Allow. Đây là phương án gần đúng nhất và cũng là bẫy chính. Đọc thoáng thì "allow t2.micro" nghe đúng ý quản lý, nhưng nó hỏng ở chỗ: một statement Allow trong SCP không cấm bất cứ điều gì. SCP hoạt động như bộ lọc quyền tối đa; một Allow chỉ mở cửa cho hành động nằm trong danh sách chứ không đóng cửa những hành động còn lại — và mặc định của SCP gắn vào OU thường đã là FullAWSAccess nên các instance type khác vẫn nằm trong vùng cho phép. Đúng như bản giải thích gốc nói: đổi sang Allow sẽ không hề chặn được việc launch các instance type khác. Vấn đề là logic điều kiện, không phải chọn sai Effect.

B — Change the Resource statement to arn:aws:ec2:*:*:t2.micro/*. Sai về cú pháp ARN. Instance type không phải là một resource có ARN riêng trong EC2; phần sau ARN phải là loại tài nguyên như instance/*, và bản thân t2.micro là một thuộc tính của request, không phải một đối tượng để trỏ tới. Đặc tính "loại máy nào" chỉ diễn đạt được qua condition key ec2:InstanceType trong khối Condition, đúng như policy hiện có đang làm. Viết ARN kiểu này thì statement sẽ không khớp với request nào cả.

C là đáp án đúng, đã phân tích ở trên.

D — Change the date in the version statement to the current date. Version trong policy JSON không phải ngày tháng do người viết tự đặt; nó là định danh phiên bản ngữ pháp của policy language mà AWS quy định, và giá trị hiện hành đã dùng nhiều năm nay. Sửa nó không đổi hành vi đánh giá policy, thậm chí điền một giá trị không được công nhận còn khiến policy bị từ chối khi lưu. Phương án này không liên quan gì tới triệu chứng đề nêu.

📌 Điểm cần nhớ

• Với Effect: Deny, khối Condition mô tả khi nào bị chặn. Muốn "chỉ cho phép một giá trị", công thức là Deny + StringNotEquals giá trị đó, chứ không phải Deny + StringEquals.
• SCP chỉ đặt trần quyền. Một statement Allow trong SCP không tự nó cấm hành động khác; muốn ngăn chặn thật sự thì phải dùng Deny.
• Thuộc tính của request (instance type, region, tag, có mã hoá hay không) diễn đạt bằng condition key, không nhét vào Resource ARN được.
• Khi đề nói "policy đã được gắn đúng OU nhưng vẫn không có tác dụng", hãy soi logic bên trong statement (Effect ↔ Condition có nhất quán không) trước khi nghi ngờ chuyện gắn sai chỗ.