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

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

Câu hỏi xoay quanh một công ty đang test ứng dụng trên EC2 Linux instance với một EBS gp2 volume 500GB gắn vào. Khi deploy lên nhiều EC2 instances trong Auto Scaling group (ASG), tất cả các instance đều cần truy cập chung dữ liệu từ volume EBS gốc. Yêu cầu chính là giải pháp highly available (HA - cao khả dụng), resilient (bền vững, chịu lỗi), và không thay đổi đáng kể code ứng dụng (tức là app chỉ cần mount filesystem đơn giản như NFS).

🔑 Vấn đề cốt lõi:

• EBS gp2 là block storage, chỉ gắn cho một instance duy nhất, không share trực tiếp cho multi-instance trong ASG (multi-AZ).
• Cần shared file storage hỗ trợ Linux, multi-AZ, HA, và dễ integrate (như NFS mount).
• Giải pháp phải scale theo ASG, chịu lỗi AZ, và minimal code change (app chỉ cần thay đổi mount point từ EBS sang shared FS).

📈 Kiến thức AWS cập nhật 2026: EBS gp2 đã deprecated từ 2021, thay bằng gp3 (nhưng câu hỏi dùng gp2 legacy). EFS là lựa chọn chuẩn cho shared NFS trên Linux, hỗ trợ multi-AZ replication, automatic scaling, và General Purpose mode cho workload test/low-latency như app này (tối ưu throughput 7000 IOPS/TB).

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

Đáp án đúng: Provision an Amazon Elastic File System (Amazon EFS) file system. Configure the file system to use General Purpose performance mode.

Lý do chọn 🛠️:

• Amazon EFS là fully managed NFS file system dành cho Linux, hỗ trợ thousands of concurrent connections từ multi-EC2 trong ASG (cross-AZ).
• HA & Resilient: Tự động replicate data multi-AZ (regional by default), chịu lỗi AZ/outage, durability 99.999999999% (11 9's).
• General Purpose performance mode: Phù hợp app test (latency-sensitive, <5ms), throughput scale theo usage (7000 IOPS/TB), burst lên 10GB/s.
• No code change: App chỉ mount EFS qua NFS (tương tự EBS), ASG launch template config mount target.
• Scale & Cost: 500GB dễ migrate (rsync từ EBS), auto-scale storage, cheaper long-term so với multi-EBS.

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

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. Mỗi phương án được đánh giá dựa trên yêu cầu HA, resilient, shared access, và minimal code change.

• [SAI] Provision an EC2 instance that uses NFS server software. Attach a single 500 GB gp2 EBS volume to the instance.
  ❌ Lý do sai: Tạo NFS server thủ công trên single EC2 → single point of failure (không HA, nếu EC2 down toàn bộ data inaccessible). Phải quản lý thủ công (patching, scaling), không resilient multi-AZ. Code app cần config NFS client, nhưng vi phạm "no significant changes" do phức tạp failover.

• [SAI] Provision an Amazon FSx for Windows File Server file system. Configure the file system as an SMB file store within a single Availability Zone.
  ❌ Lý do sai: FSx for Windows dùng SMB protocol (không tương thích Linux/EC2 app gốc dùng NFS). Single AZ → không HA/resilient (chỉ 99.99% availability, outage AZ = downtime). Migrate data phức tạp, yêu cầu code change lớn (từ NFS sang SMB mount).

• [SAI] Provision an EC2 instance with two 250 GB Provisioned IOPS SSD EBS volumes.
  ❌ Lý do sai: Vẫn là single EC2 với EBS io1 volumes (RAID 0/1?) → không share cho multi-instance ASG (EBS không multi-attach trừ multi-attach io1/ io2 từ 2019, nhưng chỉ block-level, không file share dễ dàng). Không HA (single instance/AZ), code cần LVM/RAID config phức tạp, vi phạm resilient.

• [ĐÚNG] Provision an Amazon Elastic File System (Amazon EFS) file system. Configure the file system to use General Purpose performance mode.
  ✅ Lý do đúng (như phần trên): Hoàn hảo match yêu cầu – shared NFS multi-AZ, HA 99.99%, resilient replication, General Purpose mode tối ưu app test (low latency, auto-scale IOPS).

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

• EFS Documentation: Amazon EFS User Guide – Chi tiết HA/multi-AZ, performance modes.
• EFS vs EBS/FSx Comparison: AWS Storage Services Matrix – EFS cho shared file Linux.
• ASG with EFS: Best Practices for EFS with EC2/ASG.
• Deprecated gp2: EBS Volume Types – Khuyến nghị gp3/io2.

🛡️ Kết luận: EFS là giải pháp DevOps best practice cho shared storage Linux scale, giảm operational overhead! Nếu cần lab thực hành, dùng AWS Free Tier EFS.

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

Câu hỏi tập trung vào việc triển khai một ứng dụng mới chạy trên nhiều instance Amazon EC2 phân bố qua hai Availability Zones (AZ), với người dùng kết nối qua giao thức TCP. Yêu cầu chính là:

• Highly available (HA): Ứng dụng phải luôn sẵn sàng, tránh downtime bằng cách phân bố tải qua các AZ.
• Tự động scale: Tăng/giảm số lượng instance khi số lượng người dùng thay đổi.
• MOST cost-effectively: Chọn giải pháp tiết kiệm chi phí nhất, ưu tiên các dịch vụ AWS hiệu quả về giá cả và hiệu suất.

Đây là câu hỏi kiểu chọn TWO (kết hợp hai bước), thuộc chủ đề Elastic Load Balancing (ELB) và Auto Scaling trong AWS, phù hợp với kỳ thi AWS Certified DevOps Engineer - Professional ( DOP-C02, cập nhật đến 2024-2026). Giải pháp cần xử lý lưu lượng TCP ở layer 4 (L4), đảm bảo HA qua multi-AZ và scale động mà không lãng phí tài nguyên. 📘

✅ Đáp án đúng (Chọn TWO)

Hai phương án đúng là:

• Add a Network Load Balancer in front of the EC2 instances.
• Configure an Auto Scaling group for the EC2 instances.

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

• Network Load Balancer (NLB) là lựa chọn lý tưởng cho TCP vì hoạt động ở layer 4, hỗ trợ TCP/UDP/TLS với độ trễ thấp, throughput cao (hàng triệu requests/giây), và tự động phân phối tải qua multi-AZ để đảm bảo HA. NLB rẻ hơn ALB (không tính phí L7 features như path-based routing), phù hợp cost-effectively cho app TCP đơn giản.
• Auto Scaling Group (ASG) cho phép tự động thêm/giảm EC2 instances dựa trên metrics (CPU, requests), duy trì HA bằng min/max instances qua multi-AZ. Kết hợp NLB + ASG tạo hệ thống scale động, HA mà không cần can thiệp thủ công.
• Combo này là best practice AWS cho workload TCP HA & scalable, tiết kiệm chi phí vì chỉ trả cho traffic thực tế và instances cần thiết (theo mô hình pay-as-you-go). Không dùng serverless như Lambda vì app chạy trên EC2. ✅

🔍 Giải thích tất cả các phương án (Đúng/Sai)

• ✅ Add a Network Load Balancer in front of the EC2 instances.
  Đúng: NLB hỗ trợ TCP native ở L4, HA multi-AZ, preserve source IP, và chi phí thấp (khoảng 0.0225$/giờ + 0.006$/LCU). Hoàn hảo cho yêu cầu TCP mà không overhead L7. Kết hợp ASG để scale targets động. 🏆

• ✅ Configure an Auto Scaling group for the EC2 instances.
  Đúng: ASG tự động scale EC2 dựa trên CloudWatch alarms (ví dụ: CPU >70%), launch configs/templates, và health checks từ NLB. Đảm bảo HA với min 2 instances/AZ, cost-effective vì terminate idle instances. 🚀

• ❌ Add an Application Load Balancer in front of the EC2 instances.
  Sai: ALB hoạt động ở layer 7 (HTTP/HTTPS), không tối ưu cho TCP thuần (chỉ hỗ trợ qua Network Load Balancer mode hoặc ALB TCP proxy - nhưng kém hiệu quả). ALB đắt hơn (0.0252$/giờ + LCU cao hơn), thêm overhead parsing headers không cần thiết cho TCP. Không phải lựa chọn cost-effective nhất. 💸

• ❌ Manually add more EC2 instances for the application.
  Sai: Thêm instance thủ công không tự động scale, dễ over-provision (tốn kém), không HA thực sự (phụ thuộc admin), và vi phạm yêu cầu "automatically scale". Không dùng ASG là anti-pattern trong AWS. 🙅‍♂️

• ❌ Add a Gateway Load Balancer in front of the EC2 instances.
  Sai: Gateway Load Balancer (GWLB) dành cho virtual appliances như firewall/security (ví dụ: third-party IDS/IPS), sử dụng GENEVE protocol, không phù hợp app TCP thông thường. Không hỗ trợ scale app trực tiếp và chi phí cao hơn NLB cho use case này. 🚫

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

• AWS NLB Docs: Elastic Load Balancing - Network Load Balancers – Xác nhận TCP support & cost model.
• ASG Best Practices: Amazon EC2 Auto Scaling User Guide – HA multi-AZ & dynamic scaling.
• ELB Comparison: Choose a Load Balancer Type – NLB vs ALB/GWLB.
• DOP-C02 Exam Guide: AWS re:Post & A Cloud Guru (patterns cho TCP HA apps).

Giải pháp NLB + ASG là golden standard cost-effective! Nếu cần demo CloudFormation, hỏi thêm nhé! 🌟

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

Câu hỏi xoay quanh việc thiết kế kiến trúc cho một ứng dụng di động mới trên AWS Cloud, sử dụng AWS Organizations với các Organizational Units (OUs) để quản lý tài khoản. Công ty muốn tag các instance Amazon EC2 với khóa tag data sensitivity có giá trị sensitive hoặc nonsensitive. Yêu cầu chính là:

• Bắt buộc tất cả EC2 instances phải có tag này (không cho phép tạo instance mà không có tag).
• IAM identities không được phép xóa tag này hoặc tạo instance thiếu tag.

Mục tiêu là chọn kết hợp 2 bước (Choose two) để đáp ứng yêu cầu, sử dụng các công cụ như Tag Policies, Service Control Policies (SCPs) trong AWS Organizations.
📘 Kiến thức nền tảng (cập nhật 2026): AWS Organizations hỗ trợ Tag Policies để enforce quy tắc tag (bắt buộc key/value trên resources khi tạo/sửa), và SCPs để deny các action IAM dựa trên điều kiện (như thiếu tag). Tag Policies không deny trực tiếp action tạo/delete, nhưng enforce compliance. SCPs linh hoạt hơn cho deny permissions. (Nguồn: AWS Organizations Tag Policies, AWS SCPs).

✅ Đáp án đúng (Chọn 2)

Hai phương án đúng là phương án 1 và phương án 4, vì chúng kết hợp Tag Policy để enforce giá trị tag cụ thể và SCP để deny tạo instance thiếu tag + ngăn xóa tag. Sự kết hợp này đảm bảo compliance toàn diện mà không ảnh hưởng permissions khác.

🛠️ Giải thích chi tiết 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 đầy đủ, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá ✅ Đúng hoặc ❌ Sai, kèm lý do cụ thể dựa trên tính năng AWS mới nhất:

• In Organizations, create a new tag policy that specifies the data sensitivity tag key and the required values. Enforce the tag values for the EC2 instances. Attach the tag policy to the appropriate OU.
  ✅ Đúng. Tag Policy trong AWS Organizations cho phép định nghĩa quy tắc bắt buộc key "data sensitivity" với values "sensitive" hoặc "nonsensitive" trên EC2 instances. Khi attach vào OU, nó enforce tự động tag này lúc tạo/sửa resources (prevent non-compliant tags). Điều này trực tiếp đáp ứng yêu cầu tag bắt buộc, không cần can thiệp thủ công. (Nguồn: AWS Tag Policies docs - hỗ trợ EC2 từ 2021, cập nhật 2025 với multi-value enforcement).

• In Organizations, create a new service control policy (SCP) that specifies the data sensitivity tag key and the required tag values. Enforce the tag values for the EC2 instances. Attach the SCP to the appropriate OU.
  ❌ Sai. SCP không hỗ trợ "enforce tag values" trực tiếp như Tag Policy (SCPs chỉ deny permissions dựa trên điều kiện, không thêm tag tự động). Sử dụng SCP ở đây sẽ không enforce tag mà chỉ có thể deny nếu thiếu, dẫn đến không đáp ứng đầy đủ (thiếu cơ chế thêm tag compliant). Tag Policies mới dành riêng cho việc này.

• Create a tag policy to deny running instances when a tag key is not specified. Create another tag policy that prevents identities from deleting tags. Attach the tag policies to the appropriate OU.
  ❌ Sai. Tag Policy không có cơ chế "deny running instances" hoặc prevent deleting tags (nó chỉ enforce tag lúc tạo/sửa, không deny action như RunInstances/Untag). Không thể dùng nhiều Tag Policy chồng chéo cho cùng mục đích; cần SCP cho deny delete. Phương án này không khả thi theo docs AWS.

• Create a service control policy (SCP) to deny creating instances when a tag key is not specified. Create another SCP that prevents identities from deleting tags. Attach the SCPs to the appropriate OU.
  ✅ Đúng. SCP đầu tiên dùng Deny ec2:RunInstances nếu thiếu tag key "data sensitivity" (sử dụng condition aws:RequestTag/${TagKey} và ec2:CreateTags). SCP thứ hai Deny ec2:DeleteTags/Untag nếu xóa tag required (condition kiểm tra tag tồn tại sau action). Attach vào OU áp dụng cho tất cả accounts/IAM identities trong OU, hoàn hảo cho yêu cầu prevent create/delete. (Nguồn: SCP Examples for Tagging - ví dụ chính thức cho EC2 tags).

• Create an AWS Config rule to check if EC2 instances use the data sensitivity tag and the specified values. Configure an AWS Lambda function to delete the resource if a noncompliant resource is found.
  ❌ Sai. AWS Config + Lambda chỉ phát hiện và remediate sau khi tạo (reactive, không prevent create/delete realtime). Yêu cầu là "must not be able to" (proactive deny), không phải delete sau. Phương án này tốn kém, không scalable, và có thể xóa nhầm resources đang chạy (vi phạm best practices AWS Well-Architected).

📘 Kết luận & Lời khuyên

Kết hợp Tag Policy (enforce tags) + SCPs (deny actions) là cách best practice cho multi-account tagging trong Organizations (Security Pillar). Test bằng AWS Policy Simulator trước triển khai. Nếu cần demo code SCP/Tag Policy JSON, hỏi thêm nhé! 🚀

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

Câu hỏi xoay quanh việc triển khai chính sách lưu trữ backup 30 ngày cho các workload database trên Amazon RDS for PostgreSQL (cụ thể là Multi-AZ cluster). Công ty hiện đang sử dụng hai loại backup RDS:

• Automated backups (tự động, do RDS quản lý với retention policy có thể cấu hình).
• Manual backups (snapshot thủ công, không có retention tự động, phải quản lý tay).

Yêu cầu chính:

• Duy trì cả hai loại backup hiện có nếu chúng ít hơn 30 ngày tuổi.
• Áp dụng chính sách 30 ngày một cách cost-effective nhất (tiết kiệm chi phí nhất), tránh lãng phí storage (vì backup RDS tính phí theo GB lưu trữ).

Vấn đề cốt lõi: Automated backups có thể set retention để tự động xóa sau 30 ngày (native RDS feature, không tốn thêm chi phí). Manual backups không tự xóa, phải xóa thủ công để tránh chi phí tích tụ. Không cần tool phức tạp như AWS Backup hay CloudFormation vì native RDS đã đủ hiệu quả. ✅

✅ Đáp án đúng

Configure the RDS backup retention policy to 30 days for automated backups. Manually delete manual backups that are older than 30 days.

Lý do lựa chọn:

• Đây là giải pháp native RDS, đơn giản, cost-effective nhất (không cần tool ngoài, tránh chi phí AWS Backup).
• Set retention 30 ngày cho automated backups → RDS tự động giữ backup <30 ngày và xóa >30 ngày.
• Manual backups giữ nguyên <30 ngày, xóa tay >30 ngày để tiết kiệm storage.
• Đáp ứng đầy đủ: Giữ backup hiện có <30 ngày, chính sách 30 ngày, chi phí thấp (RDS backup storage ~$0.095/GB/tháng, 2024-2026 pricing). 🛠️

📋 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 bằng tiếng Anh). Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm giải thích bằng tiếng Việt dựa trên tài liệu AWS mới nhất (RDS features đến 2026, hỗ trợ PostgreSQL Multi-AZ).

• ❌ [SAI] Configure the RDS backup retention policy to 30 days for automated backups by using AWS Backup. Manually delete manual backups that are older than 30 days.
  Lý do sai: AWS Backup không dùng để cấu hình retention policy native của RDS automated backups (AWS Backup dùng cho cross-service backup plans, thêm overhead chi phí ~$0.05/GB/tháng + Vault fees). RDS retention phải dùng trực tiếp qua console/CLI/API, không qua AWS Backup. Giải pháp này thừa phức tạp, kém cost-effective. 🗑️

• ❌ [SAI] Disable RDS automated backups. Delete automated backups and manual backups that are older than 30 days. Configure the RDS backup retention policy to 30 days for automated backups.
  Lý do sai: Mâu thuẫn logic – disable automated backups rồi lại config retention cho chúng? Disable sẽ dừng tạo auto backups mới (mất RPO/DR tốt), phải delete thủ công tất cả (tốn công, không tự động). Sau đó config lại retention là thừa, không giữ được backup hiện có một cách mượt mà. Không cost-effective. 🚫

• ✅ [ĐÚNG] Configure the RDS backup retention policy to 30 days for automated backups. Manually delete manual backups that are older than 30 days.
  Lý do đúng: Như đã giải thích ở trên. Tận dụng native RDS features: ModifyDBInstance API/Console set BackupRetentionPeriod=30 (áp dụng ngay, tự động xóa cũ). Manual snapshots xóa qua DeleteDBSnapshot (script Lambda/CLI định kỳ). Giữ backup <30 ngày, chi phí tối ưu. Hoàn hảo! 💯

• ❌ [SAI] Disable RDS automated backups. Delete automated backups and manual backups that are older than 30 days automatically by using AWS CloudFormation. Configure the RDS backup retention policy to 30 days for automated backups.
  Lý do sai: Tương tự lựa chọn B, disable + config lại = vô nghĩa. CloudFormation (IaC) chỉ deploy stack một lần, không tự động xóa backups theo thời gian (không phải scheduler). Cần Lambda + EventBridge hoặc AWS Backup Vault policies cho auto-delete, nhưng phức tạp + tốn kém hơn native RDS. Không hiệu quả. ⚠️

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

• RDS Automated Backups & Retention: Amazon RDS User Guide - Backup retention – Retention 0-35 ngày, tự xóa automatic.
• Manual Snapshots: RDS Snapshots – Không auto-expire, delete manual via API.
• Pricing: RDS Pricing – Backup storage $0.095-$0.21/GB/tháng (US East, tùy region).
• AWS Backup vs Native: AWS Backup for RDS – Không thay thế native retention.
• Best Practices DevOps: AWS Well-Architected Framework - Reliability Pillar (2024).

Giải pháp này align hoàn hảo với DevOps principles: Automate what you can (retention), manual where needed, minimize cost! 🚀

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

Câu hỏi xoay quanh việc migrate một ứng dụng legacy từ on-premises sang AWS. Ứng dụng này sử dụng NFS (Network File System) để giao tiếp với giải pháp lưu trữ on-premises nhằm lưu dữ liệu ứng dụng. Quan trọng nhất: ứng dụng không thể chỉnh sửa để sử dụng bất kỳ giao thức nào khác ngoài NFS.
📌 Yêu cầu chính: Kiến trúc sư giải pháp (Solutions Architect) cần đề xuất giải pháp lưu trữ phù hợp trên AWS sau migration, phải tương thích hoàn toàn với NFS mà không cần thay đổi code ứng dụng. Đây là tình huống phổ biến trong migration, nhấn mạnh tính tương thích protocol (NFSv4) để tránh downtime hoặc rework lớn.
🛠️ Bối cảnh AWS (cập nhật đến 2026): AWS cung cấp nhiều dịch vụ lưu trữ, nhưng chỉ một số hỗ trợ NFS native cho shared file storage đa AZ, phù hợp legacy app cần mount NFS từ nhiều EC2 instances.

✅ Đáp án đúng: Amazon Elastic File System (Amazon EFS)

Lý do lựa chọn:
Amazon EFS là file storage managed hoàn toàn, hỗ trợ NFSv4.0, NFSv4.1 (và NFSv4.2 từ 2023), cho phép ứng dụng legacy mount trực tiếp như NFS on-premises mà không cần thay đổi code. EFS hỗ trợ multi-AZ, scalable throughput, lý tưởng cho ứng dụng cần shared access từ nhiều EC2 instances. Đây là giải pháp chuẩn cho migration NFS-based apps theo best practices AWS Well-Architected Framework (Storage Lens pillar).
📘 Tài liệu tham khảo:

• AWS EFS Documentation - Mounting EFS with NFS (xác nhận NFS protocol).
• AWS Migration Guide for NFS.

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên nội dung gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên tính tương thích NFS, khả năng shared storage, và phù hợp migration:

• ❌ AWS DataSync
  Sai vì: AWS DataSync là dịch vụ transfer data dùng để di chuyển dữ liệu từ on-premises NFS sang AWS (như EFS/S3), KHÔNG phải giải pháp lưu trữ runtime. Nó chỉ hỗ trợ one-time hoặc ongoing sync, không cho phép ứng dụng mount NFS trực tiếp sau migration. Nếu dùng DataSync, app vẫn cần storage khác để mount, vi phạm yêu cầu "không modify protocol".

• ❌ Amazon Elastic Block Store (Amazon EBS)
  Sai vì: Amazon EBS là block storage gắn trực tiếp vào một EC2 instance duy nhất (single-AZ, không shared native). EBS KHÔNG hỗ trợ NFS protocol (chỉ expose qua iSCSI hoặc raw block device), nên ứng dụng legacy không thể mount NFS mà không cần thay đổi lớn (như dùng EBS CSI driver trên EKS). Không phù hợp shared file system cho multi-instance apps.

• ✅ Amazon Elastic File System (Amazon EFS)
  Đúng vì: Như đã giải thích ở trên, EFS hỗ trợ NFSv4 native, shared file system scalable, multi-AZ với performance modes (General Purpose/Provisioned) và storage classes (Standard/Infrequent Access/One Zone) cập nhật 2025. Ứng dụng mount EFS qua NFS mount target, hoàn toàn tương thích legacy NFS mà zero code change. Hỗ trợ encryption, access points IAM cho security.

• ❌ Amazon EMR File System (Amazon EMRFS)
  Sai vì: Amazon EMRFS là file system abstraction dành riêng cho Amazon EMR (big data processing với Hadoop/Spark), tích hợp S3 làm backend. KHÔNG hỗ trợ NFS mount trực tiếp cho ứng dụng thông thường, chỉ dùng trong EMR jobs qua EMRFS gateway. Không phải shared file storage cho legacy app ngoài EMR ecosystem.

🏆 Kết luận & Best Practices

✅ Khuyến nghị: Chọn Amazon EFS kết hợp AWS DataSync cho initial data migration từ on-premises NFS. Test với EFS Access Points để isolate namespaces. Monitor bằng CloudWatch và EFS Intelligent-Tiering (tính năng mới 2024).
🔗 Nguồn bổ sung:

• AWS Storage Gateway for NFS (nếu hybrid migration).
• AWS Exam DOP-C02/SAP-C02 Sample Questions (tương tự câu này).
  Hy vọng phân tích này giúp bạn ôn thi AWS hiệu quả! 🚀

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

Câu hỏi mô tả một hệ thống theo dõi di cư của hàng nghìn rùa biển bằng GPS trackers. Các tracker kiểm tra mỗi 5 phút xem rùa di chuyển quá 100 yards (91.4 mét) không. Nếu có, tracker gửi tọa độ mới đến một web application chạy trên 3 Amazon EC2 instances phân bố đa Availability Zones (AZ) trong một AWS Region.

🌪️ Vấn đề gần đây: Ứng dụng web bị overwhelmed (quá tải) do lượng dữ liệu tracker bất ngờ lớn, dẫn đến mất dữ liệu và không thể replay events (phát lại sự kiện).

🎯 Yêu cầu giải pháp:

• Ngăn chặn vấn đề tái diễn: Cần buffer dữ liệu incoming để tránh overload trực tiếp vào EC2.
• Least operational overhead: Giải pháp đơn giản, ít quản lý (managed service ưu tiên), không cần code phức tạp hay scale thủ công.

🛠️ Bối cảnh AWS cập nhật 2026: Sử dụng các dịch vụ serverless/managed như SQS, API Gateway, Lambda để decoupling producers (trackers) và consumers (EC2 app), đảm bảo durability và scalability. Kiến thức dựa trên AWS Well-Architected Framework (Reliability Pillar) và best practices cho high-throughput ingestion.

✅ Đáp án đúng

Create an Amazon Simple Queue Service (Amazon SQS) queue to store the incoming data. Configure the application to poll for new messages for processing.

Lý do chọn đáp án này (🧠 Phân tích chi tiết):

• SQS là message queue managed service 📨: Decouples trackers (producers) khỏi EC2 app (consumers). Trackers gửi data vào queue, EC2 poll định kỳ để process → buffer spike traffic, tránh overwhelm.
• Durability cao: Messages lưu trữ 1-14 ngày (mặc định 4 ngày), hỗ trợ at-least-once delivery và visibility timeout → replay events nếu EC2 fail (dead-letter queue cho retry).
• Least overhead 💡: Fully managed, auto-scale, multi-AZ, giá rẻ (~$0.40/million requests). EC2 chỉ cần SDK poll (long polling tối ưu), không code phức tạp.
• Phù hợp scenario: High-volume, bursty data từ IoT-like devices; EC2 existing app dễ integrate (poll loop).
• Cập nhật 2026: SQS hỗ trợ FIFO queues cho ordering nếu cần, integration với EventBridge cho advanced routing.

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

• ❌ Create an Amazon S3 bucket to store the data. Configure the application to scan for new data in the bucket for processing.
  Sai vì: S3 là object storage cho durable, scalable lưu trữ lớn 📦, nhưng không phù hợp real-time queue. App phải scan bucket (list objects) → operational overhead cao (polling liên tục tốn API calls, không efficient với prefix scanning). Không có native replay/retry mechanism như queue; data lost nếu upload fail. Phù hợp batch analytics hơn IoT ingestion.

• ❌ Create an Amazon API Gateway endpoint to handle transmitted location coordinates. Use an AWS Lambda function to process each item concurrently.
  Sai vì: API Gateway + Lambda là serverless API 😎, scale concurrent tốt (Lambda auto-scale), nhưng overhead cao hơn (cần thiết kế API schema, auth, throttling; Lambda cold starts với high-volume). Không leverage existing EC2 app (phải migrate logic sang Lambda). Replay khó (cần thêm storage như SQS backend). Không "least overhead" vì refactor lớn so với SQS poll đơn giản.

• ✅ Create an Amazon Simple Queue Service (Amazon SQS) queue to store the incoming data. Configure the application to poll for new messages for processing.
  Đúng vì: Như phân tích trên – ideal decoupling, durable queue với zero-downtime scaling và integrate dễ với EC2. Least ops (no servers to manage).

• ❌ Create an Amazon DynamoDB table to store transmitted location coordinates. Configure the application to query the table for new data for processing. Use TTL to remove data that has been processed.
  Sai vì: DynamoDB là NoSQL DB nhanh ⚡ cho key-value, nhưng không phải queue – query/poll liên tục (scan/query operations) tốn RCU/WCU, overhead cao với unprocessed data tích tụ. TTL cleanup OK nhưng không atomic như SQS delete message. Replay kém (app phải track processed items). Phù hợp persistent store hơn transient buffering.

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

• AWS SQS Documentation: Amazon Simple Queue Service – Decoupling & Reliability.
• AWS Well-Architected Framework (Reliability): Handling Increased Traffic.
• IoT Best Practices: AWS IoT Core + SQS Integration.
• Exam Prep: AWS Certified Solutions Architect Professional (SAP-C02) Sample Questions – Queueing Patterns.

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

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

Câu hỏi xoay quanh việc triển khai một Amazon RDS Multi-AZ cluster làm backend cho ứng dụng desktop client chạy on-premises (tại văn phòng công ty). Đội ngũ phát triển cần kết nối trực tiếp từ client desktop đến RDS cluster khi làm việc tại văn phòng. Yêu cầu chính là chọn giải pháp an toàn nhất (MOST securely) để cung cấp kết nối này.

🔍 Chi tiết vấn đề:

• RDS Multi-AZ cluster yêu cầu ít nhất hai subnets ở các Availability Zones khác nhau để đảm bảo high availability và failover tự động (theo tài liệu AWS RDS mới nhất 2024-2026).
• Client desktop on-premises cần truy cập trực tiếp, không qua proxy hoặc bastion host.
• Ưu tiên bảo mật cao nhất: Tránh expose RDS ra public Internet, sử dụng kết nối riêng tư, mã hóa và kiểm soát truy cập chặt chẽ.
• Không đề cập đến chi phí hoặc hiệu suất, chỉ tập trung vào security.

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

• Amazon RDS VPC Best Practices (khuyến nghị đặt RDS trong private subnets).
• AWS Site-to-Site VPN (hỗ trợ IPsec encrypted tunnel từ on-premises).
• RDS Multi-AZ Deployments (yêu cầu private subnets cho security).

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

Đáp án đúng: Create a VPC and two private subnets. Create the RDS cluster in the private subnets. Use AWS Site-to-Site VPN with a customer gateway in the company's office.

🛠️ Lý do chọn đáp án này:

• Đặt RDS cluster trong private subnets (không có route ra Internet Gateway) đảm bảo RDS không thể truy cập trực tiếp từ public Internet, giảm rủi ro tấn công.
• AWS Site-to-Site VPN tạo tunnel IPsec mã hóa giữa VPC và customer gateway (thiết bị on-premises tại văn phòng), cho phép client desktop kết nối private như mạng nội bộ.
• Hỗ trợ Multi-AZ với hai private subnets ở AZ khác nhau, đảm bảo HA và failover.
• An toàn nhất: Mã hóa end-to-end, kiểm soát CIDR office IP qua VPN, không expose public endpoint.
• Theo best practices AWS 2026: VPN là lựa chọn chuẩn cho hybrid connectivity với RDS private.

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

🧩 Phân tích từng lựa chọn (giữ nguyên text gốc, giải thích bằng tiếng Việt):

• Create a VPC and two public subnets. Create the RDS cluster in the public subnets. Use AWS Site-to-Site VPN with a customer gateway in the company's office.
  ❌ Sai: Đặt RDS trong public subnets (có route ra Internet Gateway) làm RDS endpoint public, dễ bị tấn công từ Internet dù có VPN. VPN chỉ cần thiết nếu RDS private, ở đây thừa thãi và kém an toàn vì expose RDS public. Vi phạm nguyên tắc "least privilege" và RDS security best practices.

• Create a VPC and two private subnets. Create the RDS cluster in the private subnets. Use AWS Site-to-Site VPN with a customer gateway in the company's office.
  ✅ Đúng: Như giải thích trên. Kết hợp private subnets (ẩn RDS khỏi public) + Site-to-Site VPN (tunnel mã hóa private từ office) là giải pháp an toàn tối ưu, hỗ trợ Multi-AZ đầy đủ.

• Create a VPC and two private subnets. Create the RDS cluster in the private subnets. Use RDS security groups to allow the company's office IP ranges to access the cluster.
  ❌ Sai: Security Groups chỉ kiểm soát traffic bên trong VPC hoặc qua kết nối private (như VPN/Direct Connect). Từ office on-premises, traffic phải qua public Internet đến RDS endpoint (dù RDS private), không mã hóa và phụ thuộc IP whitelist – dễ bị spoofing IP, DDoS. Không "secure" bằng VPN encrypted tunnel.

• Create a VPC and two public subnets. Create the RDS cluster in the public subnets. Create a cluster user for each developer. Use RDS security groups to allow the users to access the cluster.
  ❌ Sai: RDS public subnets expose endpoint ra Internet, rủi ro cao dù có security groups + user accounts. Security groups không bảo vệ chống tấn công public; developer cần public IP để connect trực tiếp – kém an toàn nhất, không mã hóa kết nối on-premises. Vi phạm IAM least privilege và RDS VPC recommendations.

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

Câu hỏi này xoay quanh việc tối ưu hóa chi phí chuyển dữ liệu (data transfer costs) cho một ứng dụng xử lý batch dữ liệu lớn trên AWS. Cụ thể:

• Input data được lưu trữ trong một Amazon S3 bucket.
• Output data được lưu vào một S3 bucket khác.
• Ứng dụng sử dụng nhiều Amazon EC2 instances để xử lý, và dữ liệu sẽ được chuyển qua mạng giữa các EC2 instances này (transfer the data over the network between multiple Amazon EC2 instances).
• Mục tiêu chính: Giảm chi phí tổng thể cho việc chuyển dữ liệu, đặc biệt là lưu lượng giữa các EC2 instances, vì S3 vào/ra EC2 trong cùng Region thường miễn phí, nhưng chuyển dữ liệu giữa các EC2 có thể phát sinh phí nếu không cấu hình đúng.

📘 Kiến thức AWS cập nhật (đến 2026): Theo AWS Data Transfer Pricing (phiên bản mới nhất),

• Chuyển dữ liệu S3 → EC2 hoặc EC2 → S3 trong cùng Region: Miễn phí.
• Chuyển dữ liệu giữa các EC2 trong cùng Availability Zone (AZ): Miễn phí.
• Chuyển dữ liệu giữa các EC2 cross-AZ (cùng Region): Có phí (khoảng 0.01 USD/GB outbound từ AZ nguồn).
• Cross-Region: Phí cao hơn nhiều. → Vấn đề cốt lõi: Chuyển dữ liệu between multiple EC2 instances sẽ tốn kém nếu chúng ở các AZ khác nhau.

Nguồn tham khảo:

• AWS EC2 Pricing - Data Transfer 🛠️
• AWS Well-Architected Framework - Cost Optimization Pillar

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

Đáp án đúng: Place all the EC2 instances in the same Availability Zone.

Lý do:

• Việc đặt tất cả EC2 instances vào cùng một AZ đảm bảo lưu lượng dữ liệu between EC2 instances diễn ra trong cùng AZ, nơi miễn phí hoàn toàn cho data transfer nội bộ.
• Input từ S3 và output ra S3 khác vẫn miễn phí nếu cùng Region (S3 là global service).
• Đây là cách tối ưu chi phí nhất cho batch processing với dữ liệu lớn chuyển giữa các instances, tránh phí cross-AZ (0.01 USD/GB).
• 🛠️ Lợi ích thêm: Giảm latency, tăng hiệu suất xử lý batch.

📋 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á ✅ (Đúng) hoặc ❌ (Sai), kèm giải thích bằng tiếng Việt:

• Place all the EC2 instances in an Auto Scaling group.
  ❌ Sai: Auto Scaling group chỉ giúp tự động scale instances dựa trên demand, không ảnh hưởng trực tiếp đến data transfer costs. Nó có thể phân bố instances cross-AZ mặc định (cho HA), dẫn đến phí cross-AZ cao hơn. Không giải quyết vấn đề chuyển dữ liệu giữa instances.

• Place all the EC2 instances in the same AWS Region.
  ❌ Sai: Cùng Region chỉ miễn phí S3 ↔ EC2, nhưng chuyển dữ liệu giữa EC2 instances cross-AZ vẫn tính phí (0.01 USD/GB). Region có nhiều AZ, nên không đủ để giảm chi phí nội bộ giữa instances.

• Place all the EC2 instances in the same Availability Zone.
  ✅ Đúng: Như giải thích ở trên, data transfer within same AZ giữa EC2 là miễn phí, trực tiếp giảm chi phí cho lưu lượng lớn giữa multiple instances. Đây là giải pháp chính xác và hiệu quả nhất cho batch processing.

• Place all the EC2 instances in private subnets in multiple Availability Zones.
  ❌ Sai: Private subnets tăng bảo mật, nhưng multiple AZ sẽ gây phí cross-AZ cao cho data transfer giữa instances (chính là vấn đề câu hỏi nhấn mạnh). Điều này làm tăng chi phí thay vì giảm.

Kết luận tổng quát 🎯: Luôn ưu tiên same AZ cho workloads data-intensive để tránh phí ẩn. Nếu cần HA, cân nhắc EBS multi-attach hoặc EFS thay vì raw network transfer!

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

Câu hỏi tập trung vào việc quản lý credentials (tài khoản truy cập) cho Amazon Aurora MySQL DB cluster trong một ứng dụng web multi-tier. Phần ứng dụng chạy trên Amazon EC2 instances, và lưu trữ dữ liệu trên Aurora MySQL. Yêu cầu bảo mật từ IT security: credentials phải được mã hóa (encrypted) và xoay vòng (rotated) mỗi 14 ngày.

Mục tiêu là Solutions Architect cần chọn giải pháp với LEAST operational effort (ít nỗ lực vận hành nhất), nghĩa là ưu tiên giải pháp tự động hóa cao, tích hợp sẵn với AWS services, giảm thiểu custom code hoặc thủ công quản lý. Đây là chủ đề phổ biến trong AWS Certified DevOps Engineer Professional, liên quan đến bảo mật credentials sử dụng AWS Secrets Manager và AWS KMS (theo cập nhật AWS 2024-2026, Secrets Manager hỗ trợ rotation tự động cho RDS/Aurora với custom period).

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

Đáp án đúng:
Create a new AWS Key Management Service (AWS KMS) encryption key. Use AWS Secrets Manager to create a new secret that uses the KMS key with the appropriate credentials. Associate the secret with the Aurora DB cluster. Configure a custom rotation period of 14 days.

Lý do chọn đáp án này (với LEAST operational effort):
🛠️ AWS Secrets Manager là dịch vụ chuyên dụng để lưu trữ, mã hóa và xoay vòng credentials tự động. Nó tích hợp trực tiếp với Aurora MySQL (hỗ trợ rotation qua Lambda function managed-by-AWS), sử dụng KMS key để mã hóa. Bạn chỉ cần:

• Tạo KMS key mới.
• Tạo secret trong Secrets Manager, associate với DB cluster.
• Set rotation period = 14 ngày (custom lambda rotation tự động cập nhật credentials trên DB và secret).

Không cần code custom Lambda, không cần EC2/ECS quản lý file. Ứng dụng EC2 chỉ cần retrieve secret qua SDK (như boto3). Giảm effort tối đa so với các cách thủ công khác. ✅ (Cập nhật 2026: Secrets Manager hỗ trợ zero-downtime rotation cho Aurora).

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

Dưới đây là phân tích từng phương án giữ nguyên nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể bằng tiếng Việt:

• Create a new AWS Key Management Service (AWS KMS) encryption key. Use AWS Secrets Manager to create a new secret that uses the KMS key with the appropriate credentials. Associate the secret with the Aurora DB cluster. Configure a custom rotation period of 14 days.
  ✅ Đúng – Như đã giải thích ở trên. Giải pháp tích hợp sẵn, tự động hoàn toàn (Secrets Manager rotate credentials Aurora qua managed Lambda). LEAST effort: chỉ config 1 lần, AWS handle rotation/mã hóa. Không downtime, scale tốt.

• Create two parameters in AWS Systems Manager Parameter Store: one for the user name as a string parameter and one that uses the SecureString type for the password. Select AWS Key Management Service (AWS KMS) encryption for the password parameter, and load these parameters in the application tier. Implement an AWS Lambda function that rotates the password every 14 days.
  ❌ Sai – Systems Manager Parameter Store (SSM PS) chỉ lưu trữ parameters, KHÔNG hỗ trợ rotation tự động cho Aurora credentials (không integrate trực tiếp như Secrets Manager). Phải custom Lambda để rotate password trên DB và update PS → tăng effort cao (code, test, schedule Lambda qua EventBridge). Username/password tách biệt cũng phức tạp hơn. Không phải best practice cho DB rotation.

• Store a file that contains the credentials in an AWS Key Management Service (AWS KMS) encrypted Amazon Elastic File System (Amazon EFS) file system. Mount the EFS file system in all EC2 instances of the application tier. Restrict the access to the file on the file system so that the application can read the file and that only super users can modify the file. Implement an AWS Lambda function that rotates the key in Aurora every 14 days and writes new credentials into the file.
  ❌ Sai – Sử dụng EFS + KMS để lưu file credentials: phức tạp, không scale (mount EFS trên tất cả EC2, manage permission superuser). Custom Lambda rotate DB và write file → high effort (xử lý concurrency, sync file, risk downtime nếu write fail). EFS không phải tool chuyên cho secrets, dễ bị attack nếu EC2 compromised. Không tự động như Secrets Manager.

• Store a file that contains the credentials in an AWS Key Management Service (AWS KMS) encrypted Amazon S3 bucket that the application uses to load the credentials. Download the file to the application regularly to ensure that the correct credentials are used. Implement an AWS Lambda function that rotates the Aurora credentials every 14 days and uploads these credentials to the file in the S3 bucket.
  ❌ Sai – S3 + KMS cho file secrets: không an toàn và effort cao. App phải regular download (cron/job, tăng latency/risk cache cũ). Custom Lambda rotate + upload → dễ lỗi (versioning file, sync với tất cả instances, S3 event trigger phức tạp). S3 không hỗ trợ rotation DB native, vi phạm least effort và best practice (credentials nên dynamic retrieve, không static file).

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

• AWS Secrets Manager Rotation for Aurora: docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets_aurora.html – Hướng dẫn chi tiết rotation với custom period.
• RDS/Aurora Security Best Practices: docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.Securing.html – Khuyến nghị Secrets Manager cho credentials.
• Exam Topic DOP-C02: AWS Well-Architected Framework – Security Pillar (Operational Excellence).

Giải pháp đúng giúp đạt zero-trust security với tự động hóa DevOps! 🚀 Nếu cần demo code IAM policy, hỏi thêm nhé!

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

Câu hỏi mô tả một công ty truyền thông streaming đang xây dựng lại hạ tầng để đáp ứng nhu cầu video ngày càng tăng. Yêu cầu chính bao gồm:

• Xử lý video lớn terabyte-sized để chặn một số nội dung (content blocking).
• Thời gian xử lý có thể lên đến 20 phút mỗi video.
• Giải pháp phải scale theo nhu cầu (tự động mở rộng khi demand tăng) và tiết kiệm chi phí (cost-effective).

🛠️ Thách thức cốt lõi: Cần một nền tảng xử lý containerized hoặc serverless linh hoạt, hỗ trợ thời gian chạy dài (>15 phút), lưu trữ metadata đáng tin cậy (relational DB), và lưu video với lớp lưu trữ thông minh để tối ưu chi phí (như S3 Intelligent-Tiering). Giải pháp phải tránh quản lý server thủ công để scale dễ dàng và giảm chi phí vận hành, phù hợp với kiến trúc AWS hiện đại (cập nhật đến 2026: ưu tiên serverless containers như Fargate).

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

Đáp án đúng: Use Amazon Elastic Container Service (Amazon ECS) and AWS Fargate to implement microservices to process videos. Store video metadata in Amazon Aurora. Store video content in Amazon S3 Intelligent-Tiering.

Lý do chọn:

• AWS Fargate là mô hình serverless cho ECS, cho phép chạy container microservices mà không cần quản lý EC2, tự động scale theo demand (qua ECS Auto Scaling). Hỗ trợ thời gian chạy dài (>20 phút), lý tưởng cho xử lý video nặng.
• Amazon Aurora là DB relational managed, scale cao (hàng triệu requests/giây), multi-AZ HA, phù hợp metadata phức tạp.
• S3 Intelligent-Tiering tự động di chuyển dữ liệu giữa các tier (Standard, IA) dựa trên access pattern, cost-effective cho video lớn với truy cập không đều.
  Giải pháp này cân bằng scale, performance và chi phí thấp nhất, phù hợp best practice AWS Media Services (2026).

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

• ❌ Phương án SAI: Use AWS Lambda functions to process videos. Store video metadata in Amazon DynamoDB. Store video content in Amazon S3 Intelligent-Tiering.
  Giải thích sai: AWS Lambda có giới hạn thời gian chạy tối đa 15 phút (không thay đổi đến 2026), không đủ cho xử lý 20 phút/video terabyte. DynamoDB tốt cho metadata NoSQL scale cao, S3 Intelligent-Tiering cũng tối ưu, nhưng Lambda làm toàn bộ giải pháp thất bại về thời gian.

• ✅ Phương án ĐÚNG: Use Amazon Elastic Container Service (Amazon ECS) and AWS Fargate to implement microservices to process videos. Store video metadata in Amazon Aurora. Store video content in Amazon S3 Intelligent-Tiering.
  Giải thích đúng: Như đã nêu ở trên, Fargate serverless scale tự động, không giới hạn thời gian, ECS quản lý microservices dễ dàng. Aurora cung cấp relational DB hiệu suất cao, S3 Intelligent-Tiering tiết kiệm chi phí (tiết kiệm đến 40-95% so với Standard). Hoàn hảo cho workload video streaming scale lớn.

• ❌ Phương án SAI: Use Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB) to process videos. Store video content in Amazon S3 Standard. Use Amazon Simple Queue Service (Amazon SQS) for queuing and to decouple processing tasks.
  Giải thích sai: EC2 ASG + ALB scale tốt nhưng không serverless, yêu cầu quản lý server (patching, scaling thủ công), tốn kém hơn Fargate (chi phí idle cao). S3 Standard không thông minh như Intelligent-Tiering (không auto-tier, đắt hơn cho infrequent access). SQS tốt cho queue/decouple, nhưng tổng thể kém cost-effective.

• ❌ Phương án SAI: Deploy a containerized video processing application on Amazon Elastic Kubernetes Service (Amazon EKS) on Amazon EC2. Store video metadata in Amazon RDS in a single Availability Zone. Store video content in Amazon S3 Glacier Deep Archive.
  Giải thích sai: EKS on EC2 phức tạp, tốn kém quản lý cluster/node (không serverless như Fargate). RDS single AZ thiếu HA (rủi ro downtime). S3 Glacier Deep Archive dành cho lưu trữ dài hạn thấp chi phí nhưng truy xuất chậm (12 giờ), không phù hợp video cần xử lý nhanh/ truy cập thường xuyên.

📘 Tài liệu tham khảo

• AWS Documentation: Amazon ECS & Fargate (serverless containers cho media processing).
• Amazon Aurora (scale relational workloads).
• S3 Intelligent-Tiering (cost optimization 2026).
• AWS Well-Architected Framework: Media & Entertainment Lens (ưu tiên serverless cho streaming).
• Exam Guide DOP-C02 (DevOps Professional, cập nhật 2026): Nhấn mạnh Fargate cho long-running tasks.