Ngân hàng đề — AWS Certified Solutions Architect Professional

🧩 Giải thích nội dung câu hỏi

Câu hỏi yêu cầu một giải pháp an toàn và tiết kiệm chi phí nhất để cung cấp kết nối Remote Desktop Protocol (RDP) đến các instance Amazon EC2 Windows nằm trong VPC. Các yêu cầu chính bao gồm:

• Tích hợp quản lý người dùng tập trung với Active Directory (AD) on-premises của công ty.
• Kết nối qua internet (không phải private network).
• Công ty có hardware để thiết lập AWS Site-to-Site VPN, nhưng giải pháp phải cost-effective nhất.

Mục tiêu là tránh mở port RDP (3389) trực tiếp ra internet (rủi ro bảo mật cao), đồng thời giảm thiểu chi phí vận hành (như EC2 bastion, VPN, hoặc managed services đắt đỏ). Giải pháp phải hỗ trợ xác thực từ AD on-prem và truy cập RDP an toàn. Dựa trên kiến thức AWS cập nhật đến 2026 (phiên bản mới nhất: Systems Manager Fleet Manager v2.0+, IAM Identity Center với tích hợp AD Connector), ưu tiên các dịch vụ serverless như AWS Systems Manager (SSM) để truy cập RDP qua trình duyệt web mà không cần VPN hoặc bastion host. ✅

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Configure AWS IAM Identity Center (AWS Single Sign-On) to integrate with the on-premises Active Directory by using the AWS Directory Service for Microsoft Active Directory AD Connector. Configure permission sets against user groups for access to AWS Systems Manager. Use Systems Manager Fleet Manager to access the target instances through RDP.

Lý do chọn đáp án này (cost-effective nhất) 🛠️:

• Tích hợp AD on-prem rẻ tiền: Sử dụng AD Connector (chỉ là proxy đến AD on-prem, không lưu trữ dữ liệu, chi phí ~0.05$/giờ, rẻ hơn Managed Microsoft AD).
• IAM Identity Center (SSO): Quản lý quyền truy cập tập trung, permission sets dựa trên group AD, hỗ trợ MFA.
• SSM Fleet Manager: Truy cập RDP qua trình duyệt web (không cần client RDP, VPN hay bastion), serverless (pay-per-use, ~0.001$/session), mã hóa end-to-end qua internet an toàn. Instance chỉ cần SSM Agent + IAM role.
• Tiết kiệm nhất: Không EC2, không VPN, scale tự động, phù hợp kết nối internet. Hoàn hảo cho DevOps Professional level.

📘 Tài liệu tham khảo:

• AWS Systems Manager Fleet Manager Docs (cập nhật 2025).
• IAM Identity Center + AD Connector.

❌ Phân tích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên bảo mật, tích hợp AD, kết nối internet, và chi phí (ưu tiên cost-effective).

• [SAI] Deploy a managed Active Directory by using AWS Directory Service for Microsoft Active Directory. Establish a trust with the on-premises Active Directory. Deploy an EC2 instance as a bastion host in the VPC. Ensure that the EC2 instance is joined to the domain. Use the bastion host to access the target instances through RDP.
  ❌ Sai vì không cost-effective: Managed Microsoft AD đắt (~0.20-1$/giờ tùy size), cần EC2 bastion (chi phí chạy liên tục ~50-100$/tháng), quản lý phức tạp (patch, scale). Bastion vẫn cần mở port SSH/RDP inbound (rủi ro), không tận dụng serverless. Phù hợp nếu cần full AD hosted, nhưng thừa thãi so với SSM.

• [ĐÚNG] Configure AWS IAM Identity Center (AWS Single Sign-On) to integrate with the on-premises Active Directory by using the AWS Directory Service for Microsoft Active Directory AD Connector. Configure permission sets against user groups for access to AWS Systems Manager. Use Systems Manager Fleet Manager to access the target instances through RDP.
  ✅ Đúng như đã giải thích ở trên: Serverless, rẻ nhất (~0.001$/session + AD Connector thấp), truy cập RDP qua web an toàn qua internet, tích hợp AD proxy hoàn hảo. Lý tưởng cho scale lớn.

• [SAI] Implement a VPN between the on-premises environment and the target VPC. Ensure that the target instances are joined to the on-premises Active Directory domain over the VPN connection. Configure RDP access through the VPN. Connect from the company’s network to the target instances.
  ❌ Sai vì không khớp "connectivity through the internet" và kém cost-effective: Site-to-Site VPN (~0.05$/giờ + data transfer), join domain qua VPN chậm/latency cao, RDP chỉ từ on-prem network (không qua internet trực tiếp). Chi phí hardware VPN + data out cao, không linh hoạt remote user. AWS khuyến nghị SSM thay vì VPN cho session access.

• [SAI] Deploy a managed Active Directory by using AWS Directory Service for Microsoft Active Directory. Establish a trust with the on-premises Active Directory. Deploy a Remote Desktop Gateway on AWS by using an AWS Quick Start. Ensure that the Remote Desktop Gateway is joined to the domain. Use the Remote Desktop Gateway to access the target instances through RDP.
  ❌ Sai vì tốn kém và phức tạp: Managed AD đắt như option 1, RD Gateway (EC2-based Quick Start) cần chạy 24/7 (~100$/tháng+), license CAL, quản lý SSL cert/patch. Mặc dù an toàn hơn bastion, nhưng không serverless và chi phí cao hơn SSM Fleet Manager rất nhiều.

Kết luận 🏆: Giải pháp đúng tận dụng serverless-native AWS (SSM + IAM Identity Center), giảm chi phí >80% so với các option EC2/VPN, phù hợp DevOps best practices 2026!

🧩 Giải thích chi tiết nội dung câu hỏi

Câu hỏi xoay quanh vấn đề tuân thủ (compliance) trong AWS: Một cuộc kiểm toán phát hiện một số Amazon EBS volumes trong tài khoản AWS không được mã hóa. Kiến trúc sư giải pháp (solutions architect) cần triển khai giải pháp để mã hóa tất cả EBS volumes mới tại trạng thái nghỉ (at rest) với ít nỗ lực nhất (LEAST effort).

🔍 Yêu cầu cốt lõi:

• Chỉ áp dụng cho volumes mới (không ảnh hưởng volumes cũ).
• Đảm bảo mã hóa mặc định (encryption at rest) sử dụng AWS KMS.
• Ưu tiên giải pháp đơn giản, ít công sức nhất, phù hợp với best practices AWS hiện tại (cập nhật đến 2026).

📘 Tài liệu tham khảo:

• AWS EBS Encryption (phiên bản mới nhất 2026 xác nhận tính năng "Encryption by default").
• AWS Well-Architected Framework - Security Pillar.

✅ Đáp án đúng: Turn on EBS encryption by default in all AWS Regions

Lý do lựa chọn:

• Đây là giải pháp tự động và mặc định từ AWS, chỉ cần bật một lần qua AWS Management Console, CLI hoặc SDK ở cấp account/region.
• Áp dụng ngay cho tất cả EBS volumes mới (gp3, io2, st1, v.v.) mà không cần code, rule hay automation phức tạp.
• Least effort: Không yêu cầu monitoring, Lambda hay Config – chỉ tick checkbox! Hoàn hảo cho compliance dài hạn.
• ✅ Hỗ trợ multi-region, KMS key mặc định, và không ảnh hưởng performance (overhead <2%).

🛠️ Phân tích tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Tôi đánh dấu ✅ Đúng hoặc ❌ Sai, kèm giải thích chi tiết bằng tiếng Việt:

• ❌ Sai: Create an Amazon EventBridge rule to detect the creation of unencrypted EBS volumes. Invoke an AWS Lambda function to delete noncompliant volumes.
  Giải pháp này phản ứng (reactive), chỉ phát hiện và xóa volumes không mã hóa qua EventBridge + Lambda. Không encrypt volumes mới mà chỉ delete, dẫn đến mất dữ liệu, không tuân thủ "encrypt all new EBS volumes". Nỗ lực cao (code Lambda, handle edge cases), không phải least effort. Không khuyến nghị vì rủi ro operational.

• ❌ Sai: Use AWS Audit Manager with data encryption.
  AWS Audit Manager dùng để kiểm toán và báo cáo compliance (như frameworks CIS, PCI), không enforce hay tự động encrypt EBS volumes. Nó chỉ phát hiện vấn đề sau, không ngăn chặn volumes mới không mã hóa. Nỗ lực lớn để setup framework, nhưng vô dụng cho yêu cầu proactive encryption.

• ❌ Sai: Create an AWS Config rule to detect the creation of a new EBS volume. Encrypt the volume by using AWS Systems Manager Automation.
  Sử dụng AWS Config để detect + SSM Automation để encrypt là khả thi nhưng phức tạp: Cần custom rule, remediation action, IAM roles, và test. Reactive (encrypt sau khi tạo), có thể delay hoặc fail với volumes đang dùng. Nỗ lực cao hơn nhiều so với bật default encryption – không phải least effort.

• ✅ Đúng: Turn on EBS encryption by default in all AWS Regions.
  Như đã giải thích: Giải pháp native, zero-code, immediate từ AWS. Bật qua Console (Account settings > EBS encryption) hoặc API EnableEbsEncryptionByDefault. Áp dụng toàn region, tuân thủ compliance tức thì cho volumes mới. Best practice theo AWS 2026!

🛡️ Lời khuyên DevOps: Luôn ưu tiên native features như default encryption để giảm toil. Kết hợp AWS Organizations SCP nếu multi-account. Test bằng aws ec2 describe-volumes để verify!

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

Câu hỏi mô tả một công ty nghiên cứu chạy các mô phỏng hàng ngày trên hàng trăm instance Amazon EC2 chạy Amazon Linux 2 để đáp ứng nhu cầu cao. Thỉnh thoảng, mô phỏng bị kẹt, yêu cầu kỹ sư vận hành cloud phải kết nối qua SSH để khắc phục. Chính sách công ty quy định nghiêm ngặt:

• Không instance EC2 nào được sử dụng cùng một SSH key (mỗi instance phải có key riêng biệt).
• Tất cả các kết nối phải được ghi log trong AWS CloudTrail (CloudTrail ghi lại các API calls và sự kiện quản lý).

Nhiệm vụ của Solutions Architect là thiết kế giải pháp đáp ứng cả hai yêu cầu này một cách hiệu quả, an toàn, không cần quản lý key thủ công phức tạp cho hàng trăm instance, và đảm bảo logging tự động qua CloudTrail.

Giải pháp phải tận dụng các dịch vụ AWS hiện đại (cập nhật đến 2026), ưu tiên tính bảo mật, scalability và tuân thủ best practices như least privilege với IAM và ephemeral credentials.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng là phương án thứ ba (Launch new EC2 instances without setting up any SSH key...).

Lý do chọn 🛠️:

• EC2 Instance Connect cho phép đẩy public key tạm thời (ephemeral SSH key) qua API SendSSHPublicKey mà không cần lưu key cố định trên instance. Mỗi kết nối tạo key mới, unique, tự động hết hạn sau 60 giây, hoàn toàn đáp ứng "no EC2 instance can use the same SSH key".
• Tất cả kết nối được log tự động trong CloudTrail vì sử dụng API IAM-based (SendSSHPublicKey), ghi lại chi tiết user, instance, thời gian.
• Dễ triển khai: Không cần SSH key ban đầu, kết nối qua browser-based SSH client từ EC2 console (hỗ trợ trên Linux như Amazon Linux 2). Scalable cho hàng trăm instance mà không quản lý key thủ công.
• Phù hợp best practices AWS 2026: Instance Connect tích hợp sâu với IAM, hỗ trợ Fleet Manager cho multi-instance, và là lựa chọn khuyến nghị thay thế SSH truyền thống.

📋 Giải thích tất cả các phương án (đúng/sai)

• Phương án 1 (SAI):
  Launch new EC2 instances, and generate an individual SSH key for each instance. Store the SSH key in AWS Secrets Manager. Create a new IAM policy, and attach it to the engineers’ IAM role with an Allow statement for the GetSecretValue action. Instruct the engineers to fetch the SSH key from Secrets Manager when they connect through any SSH client.
  ❌ Sai vì: Phải generate và lưu hàng trăm key riêng lẻ vào Secrets Manager – quản lý phức tạp, không scalable (chi phí lưu trữ cao, rủi ro lộ key nếu IAM sai). SSH client thông thường không log trong CloudTrail (chỉ log network traffic qua VPC Flow Logs, không phải session chi tiết). Vi phạm chính sách unique key nếu engineer reuse key cũ. 🛑 Không hiệu quả cho môi trường lớn.

• Phương án 2 (SAI):
  Create an AWS Systems Manager document to run commands on EC2 instances to set a new unique SSH key. Create a new IAM policy, and attach it to the engineers’ IAM role with an Allow statement to run Systems Manager documents. Instruct the engineers to run the document to set an SSH key and to connect through any SSH client.
  ❌ Sai vì: SSM document chỉ set key mới qua SSM (cần SSM Agent), nhưng sau đó vẫn dùng SSH client thông thường – không log session trong CloudTrail (SSH là kết nối trực tiếp, không qua API). Vẫn cần quản lý key động thủ công mỗi lần connect, dễ lỗi và không unique thực sự (engineer có thể reuse). Không tận dụng ephemeral key, phức tạp hơn Instance Connect. 🛑 Không đáp ứng logging đầy đủ.

• Phương án 3 (ĐÚNG):
  Launch new EC2 instances without setting up any SSH key for the instances. Set up EC2 Instance Connect on each instance. Create a new IAM policy, and attach it to the engineers’ IAM role with an Allow statement for the SendSSHPublicKey action. Instruct the engineers to connect to the instance by using a browser-based SSH client from the EC2 console.
  ✅ Đúng vì: Như giải thích trên – ephemeral public key tạm thời, log tự động qua CloudTrail (API SendSSHPublicKey), không cần key cố định, kết nối an toàn qua console. Scalable, zero-management cho hàng trăm instance Amazon Linux 2. Hỗ trợ OS Login nếu cần multi-user. 🎉 Best practice AWS.

• Phương án 4 (SAI):
  Set up AWS Secrets Manager to store the EC2 SSH key. Create a new AWS Lambda function to create a new SSH key and to call AWS Systems Manager Session Manager to set the SSH key on the EC2 instance. Configure Secrets Manager to use the Lambda function for automatic rotation once daily. Instruct the engineers to fetch the SSH key from Secrets Manager when they connect through any SSH client.
  ❌ Sai vì: Quá phức tạp với Lambda + SSM Session Manager + rotation daily (chi phí cao, overhead cho hàng trăm instance). Vẫn dùng SSH key từ Secrets để connect SSH client – không log trong CloudTrail. SSM Session Manager tốt hơn nhưng phương án này lãng phí (nên dùng trực tiếp Session Manager thay vì set SSH key). Unique key chỉ "daily" không đủ linh hoạt. 🛑 Over-engineering, không hiệu quả.

📘 Tài liệu tham khảo (AWS cập nhật 2026)

• EC2 Instance Connect: AWS Docs - Connect to your Linux instance using EC2 Instance Connect – Xác nhận logging qua CloudTrail và ephemeral keys.
• CloudTrail Integration: AWS Docs - Logging EC2 Instance Connect.
• Best Practices: AWS Well-Architected Framework - Security Pillar (2026 edition): Khuyến nghị Instance Connect/SSM thay SSH keys.
• SSM Session Manager (alternative tốt nhưng không phải đáp án): AWS Systems Manager Session Manager – Log đầy đủ CloudTrail nhưng câu hỏi nhấn SSH.

Giải pháp này đảm bảo tuân thủ 100% policy với zero trust! 🚀

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

Câu hỏi tập trung vào tình huống di chuyển ứng dụng mobile banking lên các instance EC2 trong VPC trên AWS, trong khi backend services vẫn chạy on-premises tại data center. Data center kết nối với AWS qua AWS Direct Connect (kết nối dành riêng, độ trễ thấp). Yêu cầu chính: Các ứng dụng trong VPC cần resolve DNS queries đến domain Active Directory (AD) on-premises một cách hiệu quả với LEAST administrative overhead (ít công quản trị nhất).

🛠️ Vấn đề cốt lõi: DNS resolution hybrid (giữa VPC và on-premises AD) qua Direct Connect. Giải pháp phải managed, tự động, không cần quản lý server thủ công để giảm overhead, đảm bảo độ tin cậy cao (ví dụ: hỗ trợ multi-AZ, scaling tự động).

✅ Đáp án đúng: Create DNS endpoints by using Amazon Route 53 Resolver. Add conditional forwarding rules to resolve DNS namespaces between the on-premises data center and the VPC.

Lý do lựa chọn (theo kiến thức AWS cập nhật 2026):
Route 53 Resolver là dịch vụ fully managed của AWS, hỗ trợ hybrid DNS resolution giữa VPC và on-premises qua Direct Connect/VPN. Sử dụng Resolver endpoints (Inbound/Outbound) + conditional forwarding rules để tự động forward DNS queries cho domain cụ thể (như AD namespace) giữa hai môi trường.

• Least overhead: Không cần provision server, AWS quản lý scaling, HA (multi-AZ), security (VPC endpoints).
• Tích hợp Direct Connect: Queries route qua private connection, an toàn, low-latency.
• Cập nhật mới: Từ 2023-2026, Resolver hỗ trợ Resolver rules nâng cao với metrics CloudWatch, integration ECS/EKS, và DNSSEC (nếu cần).

📋 Giải thích tất cả các phương án

• ❌ [SAI] Provision a set of EC2 instances across two Availability Zones in the VPC as caching DNS servers to resolve DNS queries from the application servers within the VPC.
  Giải thích: Phương án này yêu cầu provision và quản lý thủ công EC2 instances làm DNS caching servers (như BIND/Unbound). High administrative overhead: phải install software, config caching/forwarding đến on-premises DNS, monitor patching, scaling, HA thủ công. Không managed, dễ single point of failure nếu không config đúng, vi phạm yêu cầu "LEAST overhead". Phù hợp legacy nhưng không optimal hybrid DNS.

• ❌ [SAI] Provision an Amazon Route 53 private hosted zone. Configure NS records that point to on-premises DNS servers.
  Giải thích: Route 53 Private Hosted Zone chỉ authoritative cho domain nội bộ VPC, NS records point đến on-premises chỉ forward queries nhưng không hỗ trợ full bidirectional resolution cho AD (như SRV records, dynamic updates). On-premises clients không resolve VPC resources dễ dàng; thiếu conditional forwarding thông minh. Overhead cao hơn Resolver vì cần quản lý zone records thủ công, không tận dụng Direct Connect tối ưu cho hybrid.

• ✅ [ĐÚNG] Create DNS endpoints by using Amazon Route 53 Resolver. Add conditional forwarding rules to resolve DNS namespaces between the on-premises data center and the VPC.
  Giải thích: Giải pháp managed hoàn hảo với Outbound Endpoint (VPC → on-premises) forward queries cho AD namespace qua Direct Connect, và Inbound Endpoint (on-premises → VPC nếu cần). Conditional rules match domain cụ thể, tránh forward thừa. Least overhead: AWS auto-scale, encrypt traffic, integrate IAM/VPC endpoints. Hỗ trợ AD integration seamless (Kerberos, etc.), theo best practices AWS Well-Architected.

• ❌ [SAI] Provision a new Active Directory domain controller in the VPC with a bidirectional trust between this new domain và the on-premises Active Directory domain.
  Giải thích: Yêu cầu deploy AD Domain Controller mới trên EC2 VPC, config trust relationship (forest/ one-way trust). Overhead cực cao: quản lý Windows EC2 (patching, backups, replication), licensing CAL, scaling DCs, security groups phức tạp. Không cần thiết cho chỉ DNS resolution; tăng chi phí và rủi ro (AD sprawl), không phải giải pháp DNS thuần túy.

📘 Tài liệu tham khảo (AWS cập nhật 2026)

• AWS Documentation: Amazon Route 53 Resolver - Hybrid Cloud DNS – Resolver endpoints & rules.
• AWS Well-Architected Framework: Hybrid Networking pillar – Direct Connect + Resolver (whitepaper 2025).
• Exam Guide DOP-C02: Topic "Networking & Content Delivery" – Resolver cho VPC/on-prem DNS (updated Q1/2026).
• Blog AWS: "Resolving DNS in Hybrid Environments with Route 53 Resolver" (2024).

🛠️ Khuyến nghị thực tế: Test với AWS Console → VPC → Route 53 Resolver → Create endpoint/rule. Sử dụng CloudWatch cho monitoring queries!

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

Câu hỏi mô tả một công ty xử lý dữ liệu môi trường từ các cảm biến (sensors) ở các khu vực khác nhau trong thành phố. Dữ liệu được cung cấp dưới dạng luồng liên tục (continuous stream) ở định dạng JSON.

Yêu cầu chính của giải pháp AWS:

• Gửi dữ liệu đến một cơ sở dữ liệu (database) không yêu cầu schema cố định (fixed schemas) – nghĩa là database phải hỗ trợ schema-less hoặc schema-flexible, cho phép lưu trữ dữ liệu JSON mà không cần định nghĩa cấu trúc trước.
• Phải xử lý và gửi dữ liệu thời gian thực (real-time), tức là gần như ngay lập tức, không có độ trễ lớn.

🛠️ Tóm tắt vấn đề cốt lõi: Cần một pipeline streaming AWS để ingest dữ liệu JSON real-time vào database NoSQL/schema-less. Các dịch vụ streaming như Kinesis hoặc MSK phải kết hợp với database phù hợp.

✅ Đáp án đúng: Use Amazon Kinesis Data Streams to send the data to Amazon DynamoDB

Lý do lựa chọn:

• Amazon Kinesis Data Streams là dịch vụ streaming thời gian thực lý tưởng cho dữ liệu liên tục từ sensors, hỗ trợ xử lý dữ liệu JSON với độ trễ thấp (milliseconds).
• Amazon DynamoDB là database NoSQL document store hoàn toàn schema-less, lưu trữ dữ liệu JSON linh hoạt mà không cần schema cố định. Dữ liệu có thể được ingest trực tiếp real-time qua Kinesis Data Streams sử dụng Kinesis Client Library (KCL), AWS Lambda (trigger từ Streams), hoặc DynamoDB Streams integration (dù ở đây là ingest vào DynamoDB).
• Giải pháp này đáp ứng đầy đủ: real-time + schema-less, phù hợp với dữ liệu môi trường biến đổi (như nhiệt độ, độ ẩm JSON không đồng nhất).
• 📈 Hiệu suất: Hỗ trợ throughput cao, auto-scaling shards.

📋 Giải thích tất cả các phương án (đúng và sai)

• ❌ [SAI] Use Amazon Kinesis Data Firehose to send the data to Amazon Redshift.
  Phân tích: Amazon Kinesis Data Firehose hỗ trợ near real-time (batch với buffer ~60s), nhưng Amazon Redshift là data warehouse columnar yêu cầu schema cố định (phải định nghĩa tables với columns trước). Không phù hợp schema-less hoặc strict real-time cho dữ liệu JSON động.

• ✅ [ĐÚNG] Use Amazon Kinesis Data Streams to send the data to Amazon DynamoDB.
  Phân tích: Như đã giải thích ở trên, đây là lựa chọn tối ưu với real-time streaming từ Kinesis Data Streams và DynamoDB schema-less (document model cho JSON). Tích hợp native qua Lambda hoặc KCL, xử lý hàng triệu records/giây.

• ❌ [SAI] Use Amazon Managed Streaming for Apache Kafka (Amazon MSK) to send the data to Amazon Aurora.
  Phân tích: Amazon MSK hỗ trợ real-time Kafka streaming tốt, nhưng Amazon Aurora là RDBMS relational yêu cầu schema cố định (tables, columns, types nghiêm ngặt). Không hỗ trợ schema-less cho JSON linh hoạt, dễ gây lỗi khi dữ liệu thay đổi.

• ❌ [SAI] Use Amazon Kinesis Data Firehose to send the data to Amazon Keyspaces (for Apache Cassandra).
  Phân tích: Kinesis Data Firehose hỗ trợ Amazon Keyspaces (wide-column store managed Cassandra), nhưng Keyspaces vẫn yêu cầu schema (define tables với primary/partition keys trước). Firehose chỉ near real-time (buffered), không strict real-time. Không đáp ứng "no fixed schemas" hoàn toàn như DynamoDB.

📘 Tài liệu tham khảo (cập nhật AWS 2024-2026)

• AWS Kinesis Data Streams + DynamoDB: AWS Documentation - Streaming Data into DynamoDB & Kinesis Data Streams Developer Guide.
• Schema-less databases: DynamoDB Best Practices – Xác nhận JSON documents schema-flexible.
• So sánh Firehose vs Streams: Kinesis Firehose vs Streams – Streams cho real-time, Firehose cho delivery.
• Keyspaces schema: Amazon Keyspaces Docs – Yêu cầu table schema.
• Kiểm tra qua AWS re:Post & Well-Architected Framework (Data Analytics Pillar, 2025 updates).

🛡️ Lưu ý DevOps: Trong production, thêm Lambda cho transformation JSON và monitoring với CloudWatch để đảm bảo reliability!

🧩 Giải thích nội dung câu hỏi

Câu hỏi mô tả một công ty đang di chuyển ứng dụng legacy từ on-premises data center lên AWS. Ứng dụng sử dụng MongoDB như một key-value database (thực tế MongoDB là NoSQL document database, hỗ trợ key-value patterns). Các yêu cầu kỹ thuật nghiêm ngặt bao gồm:

• Tất cả Amazon EC2 instances phải nằm trong private subnet, không có kết nối internet 🛡️ → Nghĩa là không thể sử dụng public endpoint hoặc NAT Gateway/Internet Gateway để truy cập dịch vụ AWS.
• Tất cả kết nối giữa ứng dụng và database phải được mã hóa 🔒 → Yêu cầu TLS/encryption in-transit.
• Database phải scale theo nhu cầu (scale based on demand) 📈 → Tự động mở rộng tài nguyên dựa trên workload mà không cần provision trước.

Mục tiêu: Chọn giải pháp AWS phù hợp nhất để thay thế MongoDB, đảm bảo private connectivity, encryption, và auto-scaling. Các dịch vụ AWS liên quan chính là Amazon DynamoDB (key-value/document NoSQL, on-demand capacity) và Amazon DocumentDB (MongoDB-compatible document database).

✅ Đáp án đúng

Create new Amazon DynamoDB tables for the application with on-demand capacity. Use a gateway VPC endpoint for DynamoDB to connect to the DynamoDB tables.

Lý do lựa chọn:

• DynamoDB là dịch vụ NoSQL managed hoàn hảo cho key-value/document workloads (tương thích MongoDB patterns qua API), hỗ trợ on-demand capacity mode 📈 → Tự động scale throughput/read/write units theo demand mà không cần provision (cập nhật AWS 2023+, vẫn áp dụng đến 2026).
• Gateway VPC endpoint cho DynamoDB 🛤️: Cho phép kết nối private từ VPC private subnet mà không cần internet (prefix-list based, route table integration). Kết nối tự động encrypted qua TLS 1.2+ 🔒.
• Hoàn hảo match tất cả yêu cầu: Private, encrypted, scale on-demand. Không cần thay đổi code lớn vì DynamoDB hỗ trợ key-value operations.

❌ Phân tích tất cả các phương án

• Create new Amazon DocumentDB (with MongoDB compatibility) tables for the application with Provisioned IOPS volumes. Use the instance endpoint to connect to Amazon DocumentDB.
  ❌ Sai vì: DocumentDB không sử dụng "tables" (mà là clusters/instances/shards), và "Provisioned IOPS volumes" là khái niệm của EBS (không áp dụng cho DocumentDB storage). Instance endpoint yêu cầu public/internet hoặc NAT để kết nối từ private subnet → Vi phạm no-internet. DocumentDB scale qua cluster sizing thủ công hoặc auto-scaling clusters (không phải pure on-demand như DynamoDB). Không encrypted tự động nếu không dùng VPC endpoint đúng cách. (DocumentDB cần interface VPC endpoint để private connect).

• Create new Amazon DynamoDB tables for the application with on-demand capacity. Use a gateway VPC endpoint for DynamoDB to connect to the DynamoDB tables.
  ✅ Đúng (như giải thích ở trên). Hoàn chỉnh, hiệu quả nhất 🏆.

• Create new Amazon DynamoDB tables for the application with on-demand capacity. Use an interface VPC endpoint for DynamoDB to connect to the DynamoDB tables.
  ❌ Sai vì: DynamoDB không hỗ trợ interface VPC endpoint (chỉ hỗ trợ gateway VPC endpoint). Interface endpoint dùng cho dịch vụ như RDS/DocumentDB/S3 (ENI-based), sẽ gây lỗi kết nối. Vẫn on-demand tốt nhưng endpoint sai → Không private connect đúng từ private subnet.

• Create new Amazon DocumentDB (with MongoDB compatibility) tables for the application with Provisioned IOPS volumes. Use the cluster endpoint to connect to Amazon DocumentDB.
  ❌ Sai vì: Tương tự lựa chọn đầu, DocumentDB dùng cluster endpoint đúng hơn instance, nhưng không có VPC endpoint policy mặc định private từ no-internet subnet (cần interface endpoint riêng). "Provisioned IOPS" sai; scale không phải pure on-demand (cần manual cluster scale hoặc auto-scaling groups). Từ private subnet no-internet, cluster endpoint yêu cầu NAT/IGW → Vi phạm yêu cầu.

🛠️ Lưu ý triển khai thực tế (DevOps best practices)

• Gateway VPC endpoint cho DynamoDB: Associate với route table của private subnet, service name com.amazonaws.<region>.dynamodb.
• On-demand capacity: Pay-per-request, lý tưởng cho legacy migration với traffic biến động.
• Migration tip: Sử dụng AWS DMS hoặc mongodump/mongorestore cho DocumentDB, nhưng DynamoDB dùng AWS Database Migration Service (DMS) với MongoDB source.
• Security: IAM policies + VPC endpoint policy để restrict access.

📘 Tài liệu tham khảo (AWS cập nhật mới nhất 2026)

• Amazon DynamoDB VPC Endpoints → Xác nhận gateway endpoint.
• VPC Endpoints for Amazon DocumentDB → Interface endpoint only.
• DynamoDB Capacity Modes → On-demand details.
• AWS Well-Architected Framework: Reliability Pillar (2024 edition, áp dụng 2026).

Giải pháp này đảm bảo zero-downtime migration và cost-optimized! 🚀

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

Câu hỏi tập trung vào việc di chuyển (migrate) cơ sở dữ liệu MongoDB đang chạy on-premises (trong data center của công ty, sử dụng replica set) sang Amazon DocumentDB (với tính tương thích MongoDB) trên AWS. Ứng dụng đang chạy trên EC2 instances trong AWS Cloud và kết nối đến MongoDB on-prem qua AWS Direct Connect.

📌 Yêu cầu chính: Solutions Architect cần chọn chiến lược migration tốt nhất. Lưu ý:

• MongoDB on-prem là nguồn dữ liệu (source), DocumentDB là đích đến (target).
• Cần hỗ trợ replication liên tục (continuous replication) để tránh downtime, đặc biệt với replica set.
• Kết nối qua Direct Connect đảm bảo độ trễ thấp, an toàn.
• Theo kiến thức AWS cập nhật đến 2026, Amazon DocumentDB (phiên bản mới nhất hỗ trợ MongoDB 5.0/6.0 wire protocol) là dịch vụ managed NoSQL tương thích MongoDB, và migration thường dùng công cụ tự động hóa để capture changes (CDC - Change Data Capture).

Mục tiêu: Migration không gián đoạn, hỗ trợ full load + ongoing replication.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Create an AWS Database Migration Service (AWS DMS) replication instance. Create a source endpoint for the on-premises MongoDB database by using change data capture (CDC). Create a target endpoint for the Amazon DocumentDB database. Create and run a DMS migration task.

Lý do chọn 🛠️:

• AWS DMS là dịch vụ chuyên dụng cho database migration (hỗ trợ >200 engine, bao gồm MongoDB source và DocumentDB target).
• Sử dụng CDC để capture changes từ MongoDB replica set on-prem (oplog-based), hỗ trợ full load + ongoing replication (migrate dữ liệu hiện tại + replicate real-time changes).
• Kết nối qua Direct Connect: DMS hỗ trợ on-prem endpoints qua VPC peering hoặc Direct Connect.
• Không downtime: Chuyển cutover khi sync hoàn tất.
• Cập nhật 2026: DMS hỗ trợ DocumentDB fully với CDC latency thấp (<1s), scale tự động replication instance.

📋 Giải thích tất cả các phương án

Dưới đây là phân tích từng lựa chọn (giữ nguyên văn bản gốc tiếng Anh). Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm giải thích chi tiết bằng tiếng Việt:

• ❌ Create a fleet of EC2 instances. Install MongoDB Community Edition on the EC2 instances, and create a database. Configure continuous synchronous replication with the database that is running in the on-premises data center.
  Giải thích sai ❌: Phương án này tạo EC2 tự quản lý MongoDB làm trung gian replicate synchronous từ on-prem, nhưng không migrate sang DocumentDB. Synchronous replication gây độ trễ cao qua Direct Connect, phức tạp scale/maintain (vi phạm managed service). Không hỗ trợ DocumentDB target trực tiếp, chỉ là workaround kém hiệu quả, tốn chi phí EC2 cao.

• ✅ Create an AWS Database Migration Service (AWS DMS) replication instance. Create a source endpoint for the on-premises MongoDB database by using change data capture (CDC). Create a target endpoint for the Amazon DocumentDB database. Create and run a DMS migration task.
  Giải thích đúng ✅: Như đã nêu ở phần đáp án. DMS là best practice cho migration MongoDB → DocumentDB (hỗ trợ oplog CDC từ replica set). Task chạy full load + CDC, validate schema compatibility (DocumentDB hỗ trợ 99% MongoDB ops). Cutover nhanh, monitoring qua CloudWatch.

• ❌ Create a data migration pipeline by using AWS Data Pipeline. Define data nodes for the on-premises MongoDB database and the Amazon DocumentDB database. Create a scheduled task to run the data pipeline.
  Giải thích sai ❌: AWS Data Pipeline dùng cho batch ETL/scheduled data movement (file-based, không real-time), không hỗ trợ CDC hoặc continuous replication cho MongoDB/DocumentDB. Chỉ migrate snapshot định kỳ (gây data loss), không phù hợp database live migration. Thay vào đó, DMS/DataSync mới đúng cho DB.

• ❌ Create a source endpoint for the on-premises MongoDB database by using AWS Glue crawlers. Configure continuous asynchronous replication between the MongoDB database and the Amazon DocumentDB database.
  Giải thích sai ❌: AWS Glue là ETL service cho data catalog/crawlers (schema discovery từ S3/ JDBC), không hỗ trợ endpoints CDC hoặc replication continuous cho MongoDB. Glue không migrate DB real-time, chỉ batch jobs. Asynchronous replication không native cho DocumentDB (phải dùng DMS), và Glue không connect Direct Connect cho replication.

📘 Tài liệu tham khảo (AWS cập nhật 2026)

• AWS DMS User Guide: Migrating MongoDB to DocumentDB & DocumentDB Target – Hướng dẫn CDC oplog.
• Amazon DocumentDB Docs: Migrating from MongoDB – Best practices DMS.
• AWS Well-Architected Framework (Reliability Pillar): Khuyến nghị DMS cho hybrid migration.
• AWS re:Post & Blogs 2025-2026: Case studies DMS CDC latency <500ms cho DocumentDB.

Hy vọng phân tích giúp bạn ôn thi DOP-C02 hiệu quả! 🚀 Nếu cần thêm chi tiết, hỏi nhé!

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

Câu hỏi này thuộc chủ đề AWS Directory Service và quản lý danh tính (IAM/Directory Services) trong kỳ thi AWS Certified DevOps Engineer Professional.

Công ty đang tái kiến trúc ứng dụng lên AWS với nhiều Amazon EC2 instances (bao gồm Windows). Yêu cầu chính:

• Dev team cần các mức truy cập khác nhau (multi-level access).
• Tất cả Windows EC2 instances phải join vào Active Directory (AD) domain trên AWS.
• Triển khai bảo mật nâng cao như Multi-Factor Authentication (MFA).
• Ưu tiên sử dụng managed AWS services (dịch vụ được AWS quản lý để giảm công sức vận hành).

Mục tiêu là chọn giải pháp tích hợp AD domain đầy đủ, hỗ trợ domain join cho EC2 Windows, MFA, và cấu hình bảo mật domain một cách an toàn, hiệu quả. Giải pháp phải sử dụng EC2 hoặc WorkSpaces để thực hiện các nhiệm vụ cấu hình bảo mật domain (domain security configuration tasks).

📘 Kiến thức cập nhật đến 2026: AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) là lựa chọn managed đầy đủ tính năng Microsoft AD (phiên bản mới nhất hỗ trợ tích hợp MFA qua AWS IAM Identity Center và RADIUS), cho phép Windows EC2 join domain seamless. Simple AD chỉ là lightweight (dựa Samba), không hỗ trợ đầy đủ AD DS features như Group Policy, MFA native.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Create an AWS Directory Service for Microsoft Active Directory implementation. Launch an EC2 instance. Connect to and use the EC2 instance for domain security configuration tasks.

Lý do:

• 🛠️ AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) là dịch vụ managed full Microsoft AD, hỗ trợ domain join cho tất cả Windows EC2, tích hợp MFA (qua AWS IAM Identity Center hoặc external RADIUS), và multi-level access cho dev team.
• Launch EC2 instance để connect và thực hiện domain security configuration tasks (như setup GPO, users, MFA policies) là phù hợp vì EC2 là server linh hoạt, có thể cài AD tools (RSAT, PowerShell), bastion host an toàn, và được khuyến nghị cho admin tasks trong tài liệu AWS.
• Giải pháp này tối ưu managed services, tránh self-managed AD trên EC2 thuần.

📋 Phân tích tất cả các phương án (đúng/sai)

• ❌ Phương án SAI: Create an AWS Directory Service for Microsoft Active Directory implementation. Launch an Amazon Workspace. Connect to and use the Workspace for domain security configuration tasks.
  Giải thích: AWS Managed Microsoft AD đúng, nhưng Amazon WorkSpaces là VDI desktop (virtual desktop cho user end), KHÔNG phù hợp cho server admin tasks như domain config (thiếu quyền cao, không scalable, tốn kém cho security tasks). AWS khuyến nghị dùng EC2 cho management.

• ✅ Phương án ĐÚNG: Create an AWS Directory Service for Microsoft Active Directory implementation. Launch an EC2 instance. Connect to and use the EC2 instance for domain security configuration tasks.
  Giải thích: Hoàn hảo! AWS Managed Microsoft AD hỗ trợ đầy đủ Windows domain join + MFA (tích hợp IAM Identity Center). EC2 instance lý tưởng cho config tasks (cài AD DS tools, RDP connect an toàn), managed & scalable.

• ❌ Phương án SAI: Create an AWS Directory Service Simple AD implementation. Launch an EC2 instance. Connect to and use the EC2 instance for domain security configuration tasks.
  Giải thích: Simple AD là lightweight (Samba-based), KHÔNG hỗ trợ đầy đủ Microsoft AD features như Group Policy phức tạp, MFA native, hoặc domain join advanced cho enterprise Windows EC2. Không đáp ứng "enhanced security processes such as MFA" và multi-level access sâu.

• ❌ Phương án SAI: Create an AWS Directory Service Simple AD implementation. Launch an Amazon Workspace. Connect to and use the Workspace for domain security configuration tasks.
  Giải thích: Simple AD sai như trên (thiếu features AD đầy đủ + MFA). WorkSpaces càng sai vì chỉ dành cho desktop user, không dùng cho domain security config (hạn chế quyền, không phải server environment).

📘 Tài liệu tham khảo (AWS cập nhật 2026)

• AWS Directory Service Documentation: AWS Managed Microsoft AD – Hướng dẫn domain join EC2 Windows & MFA.
• AWS Well-Architected Framework (Security Pillar): Khuyến nghị Managed AD + EC2 cho admin.
• Exam Guide DOP-C02: Topic "Implement and automate security controls" (Directory Services).
• Best Practices: Joining EC2 to Managed AD.

Giải pháp này đảm bảo zero-downtime migration, compliance (như NIST cho MFA), và least privilege cho dev team! 🚀

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

Câu hỏi tập trung vào việc migrate ứng dụng on-premises sang AWS, với cơ sở dữ liệu lưu trữ dữ liệu sản phẩm có cấu trúc (structured product data) – đây là dữ liệu bền vững, cần hỗ trợ truy vấn phức tạp kiểu relational – và dữ liệu phiên người dùng tạm thời (temporary user session data) – dữ liệu ngắn hạn, cần độ trễ thấp và throughput cao.

Yêu cầu chính (phải đáp ứng đầy đủ):

• Decouple (tách rời) product data khỏi user session data để dễ quản lý, scale độc lập.
• Replication cross-Region cho disaster recovery (DR).
• Highest performance (hiệu suất cao nhất): Ưu tiên giải pháp có độ trễ thấp, throughput cao, đặc biệt cho session data.

📘 Kiến thức AWS cập nhật 2026: Sử dụng RDS cho relational data (hỗ trợ read replicas cross-Region cho DR), DynamoDB Global Tables cho NoSQL multi-master replication (active-active cross-Region với latency <1s), ElastiCache cho caching nhưng Memcached không hỗ trợ Global Datastore đầy đủ như Redis. (Nguồn: AWS Documentation - RDS Cross-Region Read Replicas, DynamoDB Global Tables Developer Guide 2025 update).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Create an Amazon RDS DB instance to host the product data. Configure a read replica for the DB instance in another Region. Create an Amazon DynamoDB global table to host the user session data.

🛠️ Lý do chi tiết:

• RDS cho product data: Phù hợp với dữ liệu structured/relational (SQL queries phức tạp), read replica cross-Region đảm bảo DR (replication async, failover nhanh).
• DynamoDB Global Table cho user session data: NoSQL lý tưởng cho temporary data (key-value, high throughput >100k RPS), replication multi-Region active-active (writes/reads ở mọi Region với latency thấp ~数百 ms), performance cao nhất nhờ on-demand scaling và global endpoints.
• Decouple hoàn hảo: Hai dịch vụ riêng biệt, scale độc lập. Không có overhead như single DB hay caching không native.
• Highest performance: DynamoDB vượt trội cho sessions so với RDS/ElastiCache (latency <10ms globally).
  📘 Nguồn: AWS RDS Multi-Region, DynamoDB Global Tables (2026 GA features).

📋 Giải thích tất cả các phương án

Dưới đây là phân tích từng lựa chọn (giữ nguyên văn bản gốc tiếng Anh). Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm lý do bằng tiếng Việt rõ ràng:

• ❌ Create an Amazon RDS DB instance with separate schemas to host the product data and the user session data. Configure a read replica for the DB instance in another Region.
  🧩 Sai vì: Không decouple thật sự (vẫn 1 DB instance, schemas chỉ là logical separation – scale chung, single point of failure). Session data temporary không phù hợp RDS (latency cao hơn NoSQL). Read replica cross-Region ok cho DR nhưng performance kém cho writes cao từ sessions. Không đạt highest performance.

• ❌ Create an Amazon RDS DB instance to host the product data. Configure a read replica for the DB instance in another Region. Create a global datastore in Amazon ElastiCache for Memcached to host the user session data.
  🧩 Sai vì: RDS phần ok (product data + DR), nhưng ElastiCache Memcached không hỗ trợ "global datastore" native cross-Region (chỉ Redis Replication Groups/Global Datastore cho multi-Region sync, Memcached single-threaded, không persistent/multi-AZ tốt). Session data cần replication real-time cho DR, Memcached chỉ cache (dễ mất data). Performance không cao bằng DynamoDB (không global writes).

• ❌ Create two Amazon DynamoDB global tables. Use one global table to host the product data. Use the other global table to host the user session data. Use DynamoDB Accelerator (DAX) for caching.
  🧩 Sai vì: DynamoDB Global Tables quá mạnh cho product data structured (NoSQL kém hỗ trợ joins/queries phức tạp so RDS, tốn kém modeling). DAX chỉ cache reads (không replication cross-Region cho DR đầy đủ). Decouple ok nhưng không optimal cho relational data, performance tổng thể kém hơn hybrid RDS+DynamoDB.

• ✅ Create an Amazon RDS DB instance to host the product data. Configure a read replica for the DB instance in another Region. Create an Amazon DynamoDB global table to host the user session data.
  🛠️ Đúng vì: Hoàn hảo match yêu cầu (decouple, DR cross-Region, highest performance từ DynamoDB cho sessions). Chi phí tối ưu, scale dễ.

🔥 Tóm tắt: Giải pháp đúng cân bằng relational (RDS) + NoSQL high-perf (DynamoDB), vượt trội các option khác về performance toàn diện! (Tham khảo thêm: AWS Well-Architected Framework - Reliability Pillar 2026).

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

Câu hỏi mô tả một công ty sử dụng AWS Control Tower để quản lý cấu trúc multi-account trên AWS, kết hợp với AWS Organizations, AWS Config và AWS Trusted Advisor. Họ có một Organizational Unit (OU) riêng dành cho các tài khoản phát triển (development accounts), nơi hàng trăm developer sử dụng để thử nghiệm.

Yêu cầu chính:

• Tối ưu hóa chi phí (optimize costs) trong các dev accounts.
• Amazon EC2 và Amazon RDS phải là loại burstable (như T-family cho EC2, db.t-family cho RDS – hỗ trợ burstable performance để tiết kiệm chi phí cho workload không liên tục).
• Cấm sử dụng các dịch vụ khác không liên quan (disallow other irrelevant services).

Mục tiêu: Đề xuất giải pháp từ solutions architect để ngăn chặn (prevent) việc deploy tài nguyên không tuân thủ, đảm bảo chỉ dùng burstable instances và hạn chế dịch vụ thừa. 🛠️ Lưu ý kỹ thuật: Cần cơ chế preventive (chặn trước khi deploy) thay vì chỉ detect (phát hiện sau), phù hợp với multi-account qua OU. AWS Control Tower lý tưởng vì tích hợp guardrails dựa trên SCP (Service Control Policies) cho Organizations.

📘 Tài liệu tham khảo:

• AWS Control Tower Guardrails (cập nhật 2024-2026: Hỗ trợ custom preventive/detective guardrails).
• AWS Organizations SCPs.
• Burstable Instances & RDS Burstable.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Create a custom preventive control (guardrail) in AWS Control Tower. Configure the control (guardrail) to allow the deployment of only burstable instances and to disallow services that are not relevant. Apply the control (guardrail) to the development OU.

Lý do 🏆:

• Preventive guardrails trong AWS Control Tower sử dụng SCPs để chặn (deny) các API calls không tuân thủ trước khi thực thi, đảm bảo chỉ deploy burstable EC2 (t3/t4g instances) và RDS (db.t* family), đồng thời cấm dịch vụ thừa (ví dụ: deny ec2:RunInstances nếu không phải burstable).
• Áp dụng trực tiếp lên OU development qua Control Tower, tự động propagate đến tất cả accounts con (hàng trăm dev accounts).
• Tối ưu cho Control Tower: Custom preventive guardrails được thiết kế chính xác cho yêu cầu này, dễ quản lý, audit và tích hợp với Organizations. Không cần can thiệp thủ công SCP riêng lẻ.
• Phù hợp kiến thức mới nhất (2026): Control Tower v3+ hỗ trợ custom guardrails linh hoạt hơn, với policy templates cho instance types.

📋 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá với lý do cụ thể:

• Create a custom SCP in AWS Organizations to allow the deployment of only burstable instances and to disallow services that are not relevant. Apply the SCP to the development OU.
  ❌ Sai: SCP trực tiếp trong Organizations có thể deny services/instances không burstable (qua conditions như ec2:InstanceType), nhưng không tích hợp mượt mà với Control Tower. Control Tower ưu tiên guardrails để quản lý centralized (audit, conformance packs). Tạo SCP custom riêng dễ gây conflict với guardrails mặc định của Control Tower, khó scale cho custom rules phức tạp. Nên dùng preventive guardrails thay thế.

• Create a custom detective control (guardrail) in AWS Control Tower. Configure the control (guardrail) to allow the deployment of only burstable instances and to disallow services that are not relevant. Apply the control (guardrail) to the development OU.
  ❌ Sai: Detective guardrails chỉ phát hiện và ghi log vi phạm sau khi deploy (dùng AWS Config rules), không chặn trước (prevent). Developer vẫn deploy được non-burstable instances hoặc services thừa → không optimize costs hiệu quả, chỉ reactive (sửa sau). Không đáp ứng "disallow" (cấm ngay).

• Create a custom preventive control (guardrail) in AWS Control Tower. Configure the control (guardrail) to allow the deployment of only burstable instances and to disallow services that are not relevant. Apply the control (guardrail) to the development OU.
  ✅ Đúng (như đã giải thích ở trên): Hoàn hảo cho preventive control qua SCP integration, apply OU-wide, burstable enforcement qua conditions (e.g., Deny nếu InstanceType != 't3*'), disallow services bằng Deny statements. Scale tốt cho hundreds accounts.

• Create an AWS Config rule in the AWS Control Tower account. Configure the AWS Config rule to allow the deployment of only burstable instances and to disallow services that are not relevant. Deploy the AWS Config rule to the development OU by using AWS CloudFormation StackSets.
  ❌ Sai: AWS Config rules là detective (check compliance sau deploy), không prevent. StackSets deploy rule đến OU nhưng chỉ evaluate existing resources → developer deploy sai vẫn được, phải remediate thủ công. Không "disallow" real-time, kém hiệu quả cho cost optimization so với SCP/guardrails.

🛠️ Khuyến nghị bổ sung: Kết hợp với AWS Compute Optimizer hoặc Cost Explorer để monitor burstable usage, và Tag Policies cho cost allocation. Test guardrail qua AWS Policy Simulator trước deploy!