Ngân hàng đề — AWS Certified Security Specialty

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

Câu hỏi tập trung vào chính sách bảo mật mạng của một công ty, yêu cầu mã hóa tất cả dữ liệu trong quá trình truyền (data in transit). Cụ thể, cần giải pháp để mã hóa dữ liệu được gửi giữa các Amazon EC2 instances và Amazon Elastic Block Store (EBS) volumes.

📌 Chi tiết kỹ thuật:

• Dữ liệu giữa EC2 và EBS di chuyển qua mạng nội bộ AWS (block storage traffic, thường qua NVMe/iSCSI protocol).
• Theo kiến thức AWS mới nhất (đến 2026), hầu hết EC2 instances hiện đại dựa trên Nitro System, nơi mã hóa in-transit được xử lý tự động nếu volume EBS được mã hóa.
• Mục tiêu: Đảm bảo traffic EBS được bảo vệ bằng mã hóa (TLS), mà không ảnh hưởng hiệu suất. Không phải mã hóa at-rest (dữ liệu lưu trữ).

🛠️ Bối cảnh DevOps: Là DevOps Engineer Professional, chúng ta ưu tiên giải pháp native AWS, tự động, scalable, sử dụng KMS cho key management.

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

Đáp án đúng: Configure Amazon EBS to enable volume encryption with AWS Key Management Service (AWS KMS) for data at rest. (Phương án B)

Lý do chi tiết:

• Khi kích hoạt volume encryption trên EBS với AWS KMS, dữ liệu at-rest được mã hóa, VÀ AWS tự động mã hóa data in-transit giữa EC2 instance (Nitro-based) và EBS volume bằng TLS 1.2.
• Đây là tính năng built-in từ Nitro System (ra mắt 2017, chuẩn đến 2026), không cần config thủ công TLS hay cert. Chỉ cần chọn "Encrypt this volume" khi tạo/modify volume và dùng KMS key.
• ✅ Hoàn toàn đáp ứng yêu cầu "encryption for all data in transit" cho EC2-EBS, hỗ trợ tất cả Nitro instances (cR3+, m5+, etc.), chiếm >99% instances hiện nay.
• Hiệu suất không giảm đáng kể nhờ hardware acceleration.

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

Dưới đây là phân tích từng phương án, giữ nguyên văn bản gốc tiếng Anh. Mỗi phân tích sử dụng kiến thức AWS cập nhật nhất (Nitro Enclaves, Graviton4, 2026 features không thay đổi core logic này).

• Configure Amazon EC2 to enable encryption in the EC2 network interface properties.
  ❌ Sai: Không tồn tại tùy chọn "encryption" trực tiếp trong EC2 network interface properties (như ENI) để mã hóa traffic EBS. Elastic Network Adapter (ENA) hỗ trợ encryption cho traffic giữa instances (ví dụ: ENA Express với TLS cho inter-instance), nhưng không áp dụng cho EBS block traffic. Sử dụng sai sẽ không ảnh hưởng EBS.

• Configure Amazon EBS to enable volume encryption with AWS Key Management Service (AWS KMS) for data at rest.
  ✅ Đúng: Như giải thích trên, enable encryption trên EBS volume (qua Console/CLI/API, chọn KMS key) sẽ tự động mã hóa in-transit cho Nitro instances. Dù mô tả nhấn "data at rest", đây chính là cách AWS implement in-transit encryption. Hỗ trợ multi-attach volumes và bursting.

• Configure Amazon EBS to enable TLS encryption in the volume configuration properties.
  ❌ Sai: EBS không có tùy chọn "TLS encryption" trong volume configuration (CreateVolume, ModifyVolume API). EBS là block storage, không expose TLS config thủ công – tất cả transparent qua Nitro. Tính năng này không tồn tại, sẽ lỗi nếu thử.

• Configure Amazon EC2 to enable TLS encryption with certificates that are stored in AWS Certificate Manager (ACM).
  ❌ Sai: EC2 instance không hỗ trợ enable TLS cho EBS traffic qua ACM certificates. ACM dành cho layer 7 (HTTPS/TLS termination) trên ALB/NLB/API Gateway/CloudFront, không phải block-level EBS traffic. Không có API hoặc property trên EC2 để attach ACM cert cho EBS – traffic EBS dùng AWS-managed TLS keys nội bộ.

📘 Tài liệu tham khảo

• AWS EBS Encryption Docs (cập nhật 2025): https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-encryption.html – Xác nhận "Data in transit between the instance and the volume is encrypted when using Nitro-based instances."
• Nitro System Security: https://aws.amazon.com/ec2/nitro/ – Chi tiết TLS in-transit cho EBS.
• AWS Whitepaper: VPC Security (2026 ed.): Nhấn mạnh EBS encryption cho in-transit compliance (PCI DSS, HIPAA).
• Exam Prep: AWS Certified DevOps Engineer Professional DOP-C02 blueprint, Domain 3: Implementation (Security configs).

🛡️ Lời khuyên DevOps: Trong thực tế, luôn dùng IAM policies + CloudTrail audit enable encryption. Test với lsblk và KMS logs để verify!

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

Câu hỏi xoay quanh việc triển khai một giải pháp tự động hóa để phát hiện và phản hồi với các mẫu lưu lượng truy cập bất thường (anomalous traffic patterns) đối với ứng dụng web chạy trên nhóm EC2 instances trong Auto Scaling group (ASG). Các EC2 này nằm trong cùng một VPC subnet với các workload khác.

• Bối cảnh: Công ty đã triển khai Amazon GuardDuty detector trong cùng Region với EC2, và tích hợp AWS Security Hub với GuardDuty. GuardDuty sẽ phát hiện các findings liên quan đến traffic bất thường (ví dụ: Behavior:EC2/TrafficVolumeUnusual hoặc các finding tương tự về anomalous traffic).
• Yêu cầu chính:
  • Tự động detect và respond phù hợp.
  • Tuân thủ AWS best practices cho initial response to security incidents: Bao gồm isolate nhanh chóng instance nghi ngờ để ngăn chặn lan rộng (containment), không terminate ngay để giữ bằng chứng điều tra, và minimize disruption (giảm thiểu gián đoạn cho app web và các workload khác trong subnet).
  • Minimize disruption: Không ảnh hưởng đến toàn bộ subnet hoặc app đang chạy.

Giải pháp phải sử dụng EventBridge (trước là CloudWatch Events) để trigger dựa trên GuardDuty findings, kết hợp Lambda cho automation. Theo AWS Well-Architected Framework (Security Pillar, cập nhật 2024-2026), initial response ưu tiên isolation per-instance thay vì block toàn subnet hoặc kill instance.

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

Đáp án đúng:
Create an Amazon EventBridge rule that invokes an AWS Lambda function when GuardDuty detects anomalous traffic. Program the Lambda function to disassociate the identified instance from the Auto Scaling group and to isolate the instance by using a new restricted security group.

Lý do lựa chọn 🛠️:

• Phù hợp best practices:
  • EventBridge rule trigger chính xác khi GuardDuty detect anomalous traffic (qua findings gửi đến Security Hub/EventBridge).
  • Lambda function thực hiện disassociate instance khỏi ASG (sử dụng DetachInstances API) → ASG sẽ tự động launch instance mới để thay thế, đảm bảo high availability và minimize disruption cho app web.
  • Isolate bằng new restricted SG: Attach SG mới chỉ cho phép traffic cần thiết (ví dụ: SSH từ bastion, không outbound/inbound suspicious), không ảnh hưởng đến các instance khác trong subnet/ASG. Instance bị isolate vẫn chạy để incident investigation (forensics).
• Automated & compliant: Tuân thủ AWS Incident Response Playbooks (cập nhật 2025), ưu tiên containment mà không terminate (terminate sẽ mất logs/bằng chứng).
• Không disrupt subnet: Chỉ target instance cụ thể qua Instance ID từ GuardDuty finding.

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

• Create an Amazon EventBridge rule that detects the Behavior:EC2/TrafficVolumeUnusual GuardDuty finding. Configure the rule to invoke an AWS Lambda function to disable the EC2 instance profile access keys.
  ❌ Sai: Việc disable IAM role access keys chỉ chặn API calls từ instance, không ngăn anomalous traffic (traffic là network-level, không liên quan IAM). Có thể gây disruption cho app hợp pháp cần IAM (như S3 access), và không isolate network. Không phải best practice isolation (AWS khuyến cáo network isolation trước).

• Create an Amazon EventBridge rule that invokes an AWS Lambda function when GuardDuty detects anomalous traffic. Program the Lambda function to disassociate the identified instance from the Auto Scaling group and to isolate the instance by using a new restricted security group.
  ✅ Đúng: Như phân tích ở trên. Đây là response tối ưu, kết hợp ASG recovery + SG isolation per-instance, minimize disruption và enable investigation.

• Create a Security Hub automated response that updates the network ACL that is associated with the subnet of the EC2 instances. Configure the response to update the network ACL to deny traffic from the source of detected anomalous traffic.
  ❌ Sai: NACL là stateless, apply toàn subnet → block traffic từ source suspicious sẽ disrupt tất cả workloads khác trong subnet (vi phạm minimize disruption). Nguồn anomalous traffic có thể động/multiple IPs, khó block chính xác. Không phải best practice (AWS ưu tiên SG/EC2-level isolation thay vì NACL-wide).

• Create an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the security engineer’s email address to the SNS topic. Configure GuardDuty to send all findings to the SNS topic.
  ❌ Sai: Chỉ notify email là manual response, không automated như yêu cầu. Không có action containment/isolation, vi phạm "appropriately respond" và best practices (initial response phải tự động để giảm MTTR - Mean Time To Respond).

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

• AWS GuardDuty Documentation: GuardDuty Findings (Behavior:EC2/TrafficVolumeUnusual cho anomalous traffic).
• AWS Security Hub: Automated Insights & Responses (tích hợp EventBridge/Lambda).
• AWS Best Practices: Incident Response on AWS & Well-Architected Security Pillar (isolate via SG/ASG, không NACL-wide).
• EventBridge + GuardDuty: Sample Automation.
• ASG APIs: DetachInstances cho non-terminating detach.

Giải pháp này đảm bảo zero-downtime cho app nhờ ASG! 🚀

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

Câu hỏi mô tả một tình huống thực tế trong AWS: Một công ty có ứng dụng cần đọc object từ Amazon S3 bucket. Họ đã cấu hình IAM policy và gắn nó vào IAM role mà ứng dụng sử dụng. Tuy nhiên, khi ứng dụng cố gắng đọc dữ liệu, nó gặp lỗi AccessDenied.

📌 Yêu cầu chính: Security engineer phải khắc phục vấn đề mà không làm giảm tính bảo mật (security) của S3 bucket hoặc ứng dụng. Nghĩa là không được thêm quyền rộng rãi, không expose bucket ra public, không thay đổi môi trường deployment một cách không cần thiết.

🛠️ Vấn đề cốt lõi: Lỗi AccessDenied thường do IAM policy không đúng (thiếu quyền s3:GetObject, sai resource ARN, điều kiện sai) hoặc ứng dụng không assume role thành công (STS assume-role thất bại). Giải pháp phải tập trung kiểm tra và sửa policy/role mà không ảnh hưởng bucket.

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

Đáp án đúng: Review the IAM policy by using AWS Identity and Access Management Access Analyzer to ensure that the policy grants the right permissions. Validate that the application is assuming the role correctly.

Lý do chi tiết 🏆:

• IAM Access Analyzer (cập nhật mới nhất đến 2026) là công cụ mạnh mẽ của AWS IAM để phân tích policy, phát hiện quyền thừa/thiếu, unused permissions, và external access risks. Nó giúp xác nhận policy có grant đúng quyền s3:GetObject cho resource S3 bucket mà không cần thay đổi bucket.
• Validate assume role: Kiểm tra ứng dụng có gọi STS AssumeRole đúng (qua AWS SDK/CLI) không, ví dụ kiểm tra temporary credentials.
• Phương án này không giảm security: Chỉ review và sửa policy/role hiện tại, giữ nguyên bucket policy/resource policy. Đây là best practice theo AWS Well-Architected Framework (Security Pillar).

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

• AWS Docs: IAM Access Analyzer (phiên bản 2026 hỗ trợ AI-powered analysis).
• AWS Well-Architected: Security Pillar - IAM Best Practices.

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

Dưới đây là phân tích từng phương án một cách chi tiết, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm lý do bằng tiếng Việt rõ ràng.

• Phương án A: Attach a resource policy to the S3 bucket to grant read access to the role.
  ❌ Sai: Bucket policy (resource policy) gắn trực tiếp vào S3 bucket sẽ grant quyền read cho role cụ thể, nhưng điều này làm giảm security vì expose bucket policy rộng hơn (có thể ảnh hưởng nhiều principal khác nếu không cẩn thận). Vấn đề gốc là ở IAM policy/role của app, không cần sửa bucket. Không phải giải pháp tối ưu, vi phạm yêu cầu "không giảm security của S3 bucket".

• Phương án B: Launch a new deployment of the application in a different AWS Region. Attach the role to the application.
  ❌ Sai: Deploy lại app ở Region khác không giải quyết AccessDenied, vì IAM role và S3 access là region-agnostic (S3 cross-region replication riêng biệt). Role IAM global, chỉ cần ARN đúng. Việc deploy mới tốn kém, không cần thiết, và không kiểm tra root cause (policy hoặc assume role).

• Phương án C: Review the IAM policy by using AWS Identity and Access Management Access Analyzer to ensure that the policy grants the right permissions. Validate that the application is assuming the role correctly.
  ✅ Đúng: Như đã giải thích ở phần trên. Sử dụng Access Analyzer để audit policy (kiểm tra quyền s3:GetObject, resource matching), và validate assume role qua CloudWatch Logs hoặc STS response. An toàn, hiệu quả, theo best practice AWS mới nhất (tích hợp với IAM Policy Simulator).

• Phương án D: Ensure that the S3 Block Public Access feature is disabled on the S3 bucket. Review AWS CloudTrail logs to validate that the application is assuming the role correctly.
  ❌ Sai: Block Public Access chỉ chặn public ACL/policy (không liên quan đến IAM role-based access private). Disable nó giảm security bucket (tăng rủi ro public exposure), vi phạm yêu cầu. CloudTrail hữu ích để log assume-role, nhưng không phải giải pháp chính – Access Analyzer tốt hơn cho policy review.

🛠️ Khuyến nghị thực tế: Sau khi fix, dùng IAM Access Analyzer policy generation để tạo policy tối thiểu (least privilege). Test với IAM Policy Simulator trước deploy! 🚀

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

Câu hỏi tập trung vào việc thiết kế giải pháp end-to-end encryption (mã hóa đầu-cuối) giữa clients (máy khách) và Docker containers chạy trên Amazon Elastic Container Service (Amazon ECS). Giải pháp phải xử lý volatile traffic patterns (lưu lượng truy cập biến động mạnh, tăng/giảm đột ngột). Yêu cầu chính là chọn giải pháp có MOST scalability (khả năng mở rộng cao nhất) và LOWEST latency (độ trễ thấp nhất).

🔑 End-to-end encryption ở đây nghĩa là lưu lượng TLS phải được mã hóa từ client đến tận container, không bị terminate (kết thúc mã hóa) ở giữa để tránh lộ dữ liệu. Đồng thời, giải pháp phải chịu tải cao với traffic biến động (nhờ auto-scaling của ECS), ưu tiên hiệu suất cao theo kiến trúc AWS mới nhất (2024-2026), nơi Network Load Balancer (NLB) vượt trội về throughput và low-latency so với ALB.

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

Đáp án đúng: Configure a Network Load Balancer with a TCP listener to pass through TLS traffic to the containers.

Lý do:

• 🛠️ NLB với TCP listener hỗ trợ TLS passthrough (chuyển tiếp TLS mà không decrypt/encrypt lại), đảm bảo end-to-end encryption thực sự từ client đến container trên ECS.
• 📈 Scalability cao nhất: NLB xử lý millions of requests per second (theo AWS 2026), hỗ trợ volatile traffic nhờ integration với ECS auto-scaling, và target groups trực tiếp chỉ đến containers (qua IP hoặc instance mode).
• ⚡ Latency thấp nhất: Không có overhead decrypt/re-encrypt, chỉ forward TCP packets ở L4 (Layer 4), giảm độ trễ xuống mức microseconds so với ALB (L7).
• Phù hợp ECS với Fargate/EC2, hỗ trợ IPv6 và static IP cho scalability.

📋 Giải thí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 nội dung gốc bằng tiếng Anh:

• ❌ Configure a Network Load Balancer to terminate the TLS traffic and then re-encrypt the traffic to the containers.
  Phương án này sai vì NLB terminate TLS (decrypt ở LB) sẽ phá vỡ end-to-end encryption (dữ liệu lộ ở LB). Việc re-encrypt tạo overhead cao, tăng latency (decrypt + encrypt lại) và giảm scalability với traffic volatile. NLB ưu tiên passthrough hơn terminate cho low-latency.

• ❌ Configure an Application Load Balancer to terminate the TLS traffic and then re-encrypt the traffic to the containers.
  Phương án này sai vì ALB hoạt động ở L7 (HTTP/HTTPS), luôn terminate TLS (không hỗ trợ passthrough native như NLB). Re-encrypt gây latency cao hơn (content inspection + transformation), kém scalability với volatile traffic (ALB giới hạn ~100k connections/sec so với NLB). Không đảm bảo end-to-end encryption.

• ✅ Configure a Network Load Balancer with a TCP listener to pass through TLS traffic to the containers.
  Phương án này đúng như đã giải thích ở trên: TLS passthrough qua TCP listener ở L4, giữ nguyên mã hóa end-to-end, scalability tối đa (hàng triệu req/s), latency thấp nhất (forward trực tiếp), lý tưởng cho ECS containers với traffic biến động.

• ❌ Configure Amazon Route 53 to use multivalue answer routing to send traffic to the containers.
  Phương án này sai vì Route 53 chỉ là DNS routing (multivalue answer trả về nhiều IP), không phải load balancer. Không hỗ trợ TLS handling, health checks kém cho containers động (ECS tasks thay đổi IP thường xuyên), dẫn đến scalability thấp, latency cao (DNS lookup + no L4/L7 balancing), và không đảm bảo end-to-end encryption.

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

• AWS NLB Documentation: Elastic Load Balancing - Network Load Balancers – Xác nhận TLS passthrough với TCP/UDP listeners cho low-latency.
• ECS Load Balancing Best Practices: Amazon ECS Developer Guide - Load Balancing – Khuyến nghị NLB cho TCP traffic và scalability.
• ALB vs NLB Comparison: Choosing the Right Load Balancer – NLB vượt trội về performance cho volatile workloads.
• Route 53 Limitations: Amazon Route 53 Routing Policies – Multivalue chỉ là DNS cơ bản, không thay thế LB.

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

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

Câu hỏi tập trung vào việc triển khai remote access an toàn cho một fleet lớn các instance Amazon EC2 chạy Amazon Linux 2, xử lý dữ liệu nhạy cảm với các yêu cầu tuân thủ nghiêm ngặt (compliance requirements) từ công ty:
🔒 Không expose bất kỳ remote access management ports (như SSH port 22 hoặc RDP port 3389) ra internal hoặc external network.
📝 Tất cả hoạt động remote session phải được ghi log audit đầy đủ.
🛡️ Tất cả remote access phải được authenticate và authorize qua AWS IAM Identity Center (trước đây là AWS SSO, nay tích hợp sâu với IAM).

Đội DevOps team chỉ cần occasionally connect để troubleshoot issues, không phải access thường xuyên. Giải pháp phải meet all requirements mà không vi phạm bất kỳ quy định nào.

🛠️ Thách thức chính: Cần cơ chế kết nối không yêu cầu mở port (zero-trust model), ghi log tự động, và tích hợp IAM Identity Center cho authorization – phù hợp với best practices AWS DevOps Professional (dựa trên kiến thức cập nhật đến 2026, SSM Session Manager là giải pháp chuẩn cho secure bastionless access).

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

Đáp án đúng: Assign an EC2 instance role that allows access to AWS Systems Manager. Create an IAM policy that grants access to Systems Manager Session Manager. Assign the policy to an IAM role of the DevOps team.

Lý do chọn:

• 🛡️ Authentication & Authorization: SSM Session Manager sử dụng IAM roles trên instance và user, tích hợp trực tiếp với IAM Identity Center (permission sets) để authorize DevOps team. Không cần username/password hoặc key.
• 🔒 Không expose ports: Kết nối qua AWS API endpoints (HTTPS), không cần mở SSH/RDP ports trên security group hoặc NACL.
• 📝 Audit logging: Tất cả session tự động ghi log vào Amazon CloudTrail (API calls) và S3/CloudWatch Logs (session data nếu enable), dễ audit.
• 🛠️ Phù hợp troubleshoot: DevOps team start session qua AWS Console/CLI với aws ssm start-session, hỗ trợ interactive shell trên Linux.
• ✅ Hoàn hảo meet all requirements, scalable cho large fleet, no bastion host cần thiết (zero-trust). Đây là recommended solution trong AWS Well-Architected Framework (Security Pillar, cập nhật 2026).

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

• ❌ Phương án SAI: Grant access to the EC2 serial console at the account level. Create an IAM policy that allows an IAM role of the DevOps team to access the EC2 serial console.
  Giải thích sai: EC2 Serial Console chỉ access account-level (không per-instance granular), yêu cầu enable tại account và có thể expose qua console. Không ghi log session đầy đủ (chỉ metadata, không capture input/output). Không tích hợp IAM Identity Center native cho session auth, và không hỗ trợ interactive troubleshooting mượt mà cho Linux (chỉ serial output cơ bản). Vi phạm yêu cầu no ports exposed gián tiếp vì console access có rủi ro.

• ❌ Phương án SAI: Enable EC2 instance Connect on the AMI of the EC2 instances. Configure the appropriate security group rules. Grant EC2 console access to the DevOps team for access to EC2 instance Connect.
  Giải thích sai: EC2 Instance Connect yêu cầu mở security group rules tạm thời cho port 22 (inbound ephemeral ports), vi phạm trực tiếp no remote ports exposed. Session không ghi log audit tự động đầy đủ (chỉ SSH logs trên instance, không centralized). Auth qua temporary SSH keys từ IAM, nhưng không tích hợp IAM Identity Center seamless (cần console access). Không phù hợp compliance strict.

• ✅ Phương án ĐÚNG: Assign an EC2 instance role that allows access to AWS Systems Manager. Create an IAM policy that grants access to Systems Manager Session Manager. Assign the policy to an IAM role of the DevOps team.
  Giải thích đúng: Như đã phân tích ở phần đáp án đúng – full compliance: IAM Identity Center → IAM policy/role → SSM agent trên instance (pre-installed Amazon Linux 2) → session qua AWS network. Logs tự động, no ports, secure & auditable. Hỗ trợ tagging/inventory cho fleet lớn.

• ❌ Phương án SAI: Use AWS Systems Manager Automation runbooks to open remote access ports to the EC2 instances. Attach a role to the EC2 instances to allow the runbooks to run.
  Giải thích sai: Sử dụng SSM Automation để mở ports (ví dụ modify security group cho SSH) vi phạm trực tiếp yêu cầu no ports exposed. Đây là giải pháp tạm thời, không secure (tạo attack surface), và không ghi log session native. Runbooks chỉ automate tasks, không thay thế interactive access; IAM Identity Center không liên quan trực tiếp đến session auth ở đây.

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

• AWS Systems Manager Session Manager: docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html – Chi tiết về no-port access, logging với CloudTrail/S3.
• IAM Identity Center integration with SSM: docs.aws.amazon.com/singlesignon/latest/userguide/integrations-ssm.html.
• EC2 Instance Connect limitations: docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-connect-methods.html.
• AWS Well-Architected Security Pillar: aws.amazon.com/architecture/well-architected/security-pillar – Recommend SSM cho secure access.
• Exam prep DOP-C02: AWS Certified DevOps Engineer Professional guide (2024-2026 blueprint, domain 3: Automation & Orchestration).

Hy vọng phân tích giúp bạn nắm vững! 🚀 Nếu cần demo CLI hoặc policy sample, hỏi thêm nhé!