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

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

Câu hỏi tập trung vào việc thiết lập một Amazon EMR cluster được nhiều team sử dụng chung, với các yêu cầu chính sau:

• ✅ Mỗi team's big data workloads chỉ được truy cập các AWS services cần thiết riêng biệt (isolation permissions giữa các team).
• ❌ Không cho phép workloads truy cập Instance Metadata Service Version 2 (IMDSv2) trên các EC2 instances underlying của cluster.

🛠️ Amazon EMR là dịch vụ managed Hadoop/Spark cho big data processing trên EC2. Vấn đề ở đây là cluster chung cần fine-grained access control per team/workload và chặn IMDSv2 (dịch vụ cung cấp metadata như IAM credentials qua http://169.254.169.254, có thể bị exploit nếu workloads độc hại). Giải pháp phải hỗ trợ per-application IAM roles và tự động disable IMDSv2 access từ apps.

Kiến thức cập nhật đến 2026: EMR hỗ trợ Runtime Roles (tính năng từ EMR 6.5+, enhanced 2024-2025) để scoped roles per job/app, tích hợp EMR on EKS và serverless, đảm bảo zero-trust security.

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

Đáp án đúng: Create EMR runtime roles. Configure the cluster to use the runtime roles. Use the runtime roles to submit the big data workloads.

Lý do:

• 🛡️ EMR Runtime Roles (IAM roles scoped per application/job) cho phép mỗi team's workload chỉ dùng permissions riêng, không chia sẻ instance profile chung → isolation hoàn hảo giữa teams.
• 🚫 Tự động chặn IMDSv2: Khi dùng runtime roles, EMR proxy credentials qua runtime context, ngăn apps access metadata endpoint trực tiếp (theo best practices AWS Security 2025).
• 📈 Linh hoạt cho multi-tenant cluster, hỗ trợ submit jobs qua EMR Steps/YARN apps với role-specific.

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

• Configure interface VPC endpoints for each AWS service that the teams need. Use the required interface VPC endpoints to submit the big data workloads.
  ❌ Sai: VPC Interface Endpoints (powered by AWS PrivateLink) chỉ giúp truy cập private AWS services (như S3, Glue) mà không qua internet, nhưng không isolate permissions per team (tất cả workloads vẫn dùng chung IAM role/instance profile). Không chặn IMDSv2, vì IMDSv2 là local metadata trên EC2, không liên quan VPC.

• Create EMR runtime roles. Configure the cluster to use the runtime roles. Use the runtime roles to submit the big data workloads.
  ✅ Đúng: Như giải thích ở trên, đây là giải pháp chính xác nhất, hỗ trợ per-workload IAM scoping và disable IMDSv2 access tự động qua EMR proxy mechanism (từ EMR 6.5+).

• Create an EC2 IAM instance profile that has the required permissions for each team. Use the instance profile to submit the big data workloads.
  ❌ Sai: EC2 Instance Profile gắn chung cho toàn cluster (tất cả nodes dùng 1 role), không hỗ trợ per-team isolation (permissions broad, dễ over-privileged). Vẫn expose IMDSv2 đầy đủ trên EC2, workloads có thể query metadata để steal credentials.

• Create an EMR security configuration that has the EnableApplicationScopedIAMRole option set to false. Use the security configuration to submit the big data workloads.
  ❌ Sai: EMR Security Configuration kiểm soát encryption/Kerberos/S3 guards, nhưng EnableApplicationScopedIAMRole = false tắt tính năng scoped roles (mặc định true từ EMR 5.28+), buộc dùng instance profile chung → không isolate và vẫn cho IMDSv2 access. (Lưu ý: Option này liên quan legacy config, không phải runtime roles).

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

• EMR Runtime Roles: Amazon EMR Runtime Roles Documentation – Chi tiết scoping và IMDSv2 blocking.
• EMR Security Best Practices: AWS EMR Security Guide – Multi-tenant isolation.
• IMDSv2 on EC2: IMDSv2 Best Practices – EMR integration.
• Exam Prep: AWS Certified DevOps Engineer Professional DOP-C02 blueprint (Domain 3: Implementation, EMR sections, updated 2025).

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

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

Câu hỏi mô tả một solutions architect đang thiết kế ứng dụng giúp người dùng điền và gửi đăng ký form. Kiến trúc sử dụng hai tầng (two-tier architecture):

• Tầng web application server: Nhận form từ người dùng.
• Tầng worker: Xử lý form đã gửi.

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

• Xử lý form nhanh chóng (process submitted forms quickly) → Cần cơ chế decoupling (tách biệt) giữa hai tầng để tránh bottleneck.
• Xử lý mỗi form đúng một lần (process each form exactly once) → Tránh duplicate processing (xử lý lặp).
• Không mất dữ liệu (no data is lost) → Độ bền cao (durability), hỗ trợ retry và persistence.

Giải pháp phải dùng cơ chế trung gian giữa web tier và worker tier để store and forward form data (lưu trữ tạm và chuyển tiếp dữ liệu form). Đây là kiến thức cốt lõi trong AWS messaging services, cập nhật đến 2024-2026 với SQS FIFO hỗ trợ exactly-once delivery nhờ message deduplication ID và sequence number (theo AWS Well-Architected Framework - Reliability Pillar).

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

• AWS SQS FIFO: docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html
• AWS Well-Architected: aws.amazon.com/architecture/well-architected

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

Đáp án đúng: Use an Amazon Simple Queue Service (Amazon SQS) FIFO queue between the web application server tier and the worker tier to store and forward form data.

Lý do:

• 🛠️ SQS FIFO queue đảm bảo exactly-once processing nhờ FIFO ordering (xử lý theo thứ tự) và deduplication (loại bỏ tin nhắn trùng lặp dựa trên MessageDeduplicationId và MessageGroupId).
• ⚡ Xử lý nhanh: Low latency (~10ms), hỗ trợ batching lên đến 10 messages.
• 💾 Không mất data: Durability 99.999999999% (11 9's) over 1 year, visibility timeout cho retry tự động.
• Hoàn hảo cho decoupled architecture giữa web và worker tier, phù hợp best practice AWS 2026.

📋 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 (giữ nguyên văn bản gốc). Tôi đánh dấu ✅ đúng / ❌ sai, kèm lý do chi tiết bằng tiếng Việt:

• Use an Amazon Simple Queue Service (Amazon SQS) FIFO queue between the web application server tier and the worker tier to store and forward form data.
  ✅ Đúng hoàn toàn. Như giải thích trên: Hỗ trợ exactly-once (deduplication + FIFO), nhanh, bền vững. Lý tưởng cho form processing không duplicate và không mất data. (Nguồn: AWS SQS FIFO docs).

• Use an Amazon API Gateway HTTP API between the web application server tier and the worker tier to store and forward form data.
  ❌ Sai. API Gateway HTTP API chỉ là API management layer (routing, throttling), không phải queue để store/forward. Không hỗ trợ exactly-once (có thể retry dẫn đến duplicate), không decoupling tốt (synchronous-like), dễ mất data nếu worker down. Không phù hợp store form data bền vững.

• Use an Amazon Simple Queue Service (Amazon SQS) standard queue between the web application server tier and the worker tier to store and forward form data.
  ❌ Sai. SQS standard queue không đảm bảo exactly-once (at-least-once delivery, có thể duplicate do at-least-once semantics). Chỉ best-effort ordering, không FIFO. Vẫn nhanh và bền vững, nhưng vi phạm yêu cầu "exactly once". (So sánh: docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues.html).

• Use an AWS Step Functions workflow. Create a synchronous workflow between the web application server tier and the worker tier that stores and forwards form data.
  ❌ Sai. Step Functions là orchestrator cho workflow phức tạp, synchronous sẽ tightly coupled (web chờ worker, không decoupling → chậm nếu worker overload). Không phải queue store/forward, không native exactly-once cho simple messaging (dù có retry, dễ timeout/mất data). Phù hợp workflow dài, không phải quick form processing. (Nguồn: docs.aws.amazon.com/step-functions/latest/dg/concepts-sync-execution.html).

🧩 Phân tích câu hỏi trắc nghiệm AWS

✅ Nội dung câu hỏi được giải thích chi tiết:
Câu hỏi mô tả một công ty tài chính đang sử dụng ứng dụng tìm kiếm on-premises để thu thập dữ liệu streaming (dữ liệu dòng thời gian thực) từ nhiều nguồn sản xuất (producers). Ứng dụng này cung cấp cập nhật thời gian thực cho các tính năng tìm kiếm (search) và trực quan hóa (visualization). Công ty muốn migrate sang giải pháp native của AWS, nghĩa là sử dụng các dịch vụ AWS được thiết kế sẵn, tối ưu cho streaming data, tìm kiếm nhanh và hiển thị biểu đồ real-time. Yêu cầu chính:

• Ingest và process streaming data một cách real-time.
• Tìm kiếm dữ liệu hiệu quả (search).
• Tạo visualizations (biểu đồ, dashboard) cập nhật liên tục.
  Giải pháp phải native AWS, scalable, serverless ưu tiên, phù hợp với dữ liệu tài chính nhạy cảm và high-throughput (theo best practices AWS 2024-2026, tập trung vào Kinesis family và managed services).

🎯 Đáp án đúng:
Use Amazon Kinesis Data Streams to ingest and process the data streams to Amazon OpenSearch Service. Use OpenSearch Service to search the data. Use Amazon QuickSight to create visualizations.

📝 Lý do chọn đáp án đúng (chi tiết):
✅ Amazon Kinesis Data Streams là dịch vụ native AWS chuyên ingest và process streaming data real-time với độ trễ thấp (milliseconds), hỗ trợ hàng triệu producers/consumers, tích hợp Lambda/Flink cho processing. Dữ liệu được đẩy trực tiếp vào Amazon OpenSearch Service (fork của Elasticsearch, fully managed từ 2021, cập nhật đến 2026 với vector search và ML features).
✅ OpenSearch Service lý tưởng cho full-text search và analytics real-time trên streaming data, hỗ trợ indexing nhanh từ Kinesis via Firehose hoặc Data Streams.
✅ Amazon QuickSight là BI tool native, kết nối trực tiếp OpenSearch để tạo interactive dashboards/visualizations real-time, ML insights, hỗ trợ pay-per-session scaling.
🛠️ Toàn bộ flow serverless, real-time, native, giảm chi phí so với on-premises, phù hợp migrate (AWS Well-Architected Framework: Operational Excellence pillar). Không cần quản lý infra.

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

• Phương án 1: Use Amazon EC2 instances to ingest and process the data streams to Amazon S3 buckets tor storage. Use Amazon Athena to search the data. Use Amazon Managed Grafana to create visualizations.
  ❌ Sai hoàn toàn: EC2 là compute tự quản lý, không native cho streaming real-time (cần tự scale, shard như Kinesis). S3 là object storage batch, Athena query S3 chậm (minutes), không hỗ trợ real-time search. Grafana tốt cho metrics nhưng không kết nối native streaming/search, phải tự config datasource phức tạp. Không đáp ứng "real-time updates".

• Phương án 2: Use Amazon EMR to ingest and process the data streams to Amazon Redshift for storage. Use Amazon Redshift Spectrum to search the data. Use Amazon QuickSight to create visualizations.
  ❌ Sai: EMR dành cho batch/big data processing (Spark/Hadoop), không tối ưu streaming real-time (overkill, tốn kém). Redshift là data warehouse cho analytics SQL, Spectrum query external data chậm, không hỗ trợ real-time ingest/search. QuickSight OK nhưng upstream không real-time. Phù hợp OLAP hơn streaming.

• Phương án 3: Use Amazon Elastic Kubernetes Service (Amazon EKS) to ingest and process the data streams to Amazon DynamoDB for storage. Use Amazon CloudWatch to create graphical dashboards to search and visualize the data.
  ❌ Sai: EKS là container orchestrator, phải tự build app streaming (không native như Kinesis), phức tạp migrate. DynamoDB NoSQL nhanh nhưng không chuyên search/indexing (cần GSI kém hiệu quả cho full-text). CloudWatch dashboards chỉ cho metrics/logs, không phải search/visualization chính (thiếu BI features). Không scalable real-time native.

• Phương án 4 (Đúng): Use Amazon Kinesis Data Streams to ingest and process the data streams to Amazon OpenSearch Service. Use OpenSearch Service to search the data. Use Amazon QuickSight to create visualizations.
  ✅ Đúng 100%: Như giải thích ở trên, full native stack cho streaming → search → viz real-time. Hỗ trợ tích hợp seamless (Kinesis → OpenSearch via integration), zero-ETL với QuickSight (cập nhật 2024+).

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

• AWS Kinesis Data Streams: docs.aws.amazon.com/kinesis/latest/dev/introduction.html (Real-time streaming).
• Amazon OpenSearch Service: aws.amazon.com/opensearch-service (Search & analytics từ streaming).
• Amazon QuickSight integration: docs.aws.amazon.com/quicksight/latest/user/connecting-to-es.html (OpenSearch connector).
• AWS Streaming Data Solution: aws.amazon.com/solutions/implementations/real-time-stream-processing/.
• Exam guide DOP-C02 (DevOps Pro 2024): Nhấn mạnh native managed services cho migration.

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 study, hỏi nhé!

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

Câu hỏi xoay quanh việc modernize một ứng dụng on-premises chạy ASP.NET trên máy Linux, ứng dụng này tốn nhiều tài nguyên và phục vụ khách hàng trực tiếp. Công ty muốn:

• Chuyển sang .NET (có lẽ ám chỉ .NET Core/.NET 6+ hỗ trợ cross-platform và container tốt hơn).
• Chạy trên containers.
• Scale tự động dựa trên Amazon CloudWatch metrics (ví dụ: CPU, memory utilization).
• Giảm thiểu thời gian bảo trì hoạt động (least operational overhead) → ưu tiên serverless hoặc managed services.

Mục tiêu chính: Tìm giải pháp ít overhead nhất để containerize app hiện tại và deploy scalable trên AWS. Kiến thức cập nhật 2026: AWS ưu tiên Fargate (serverless compute cho containers), App2Container (tool miễn phí để containerize apps từ running instances), và ECS với auto-scaling dựa CloudWatch (hỗ trợ target tracking scaling groups từ phiên bản ECS 1.4+).

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

• AWS App2Container Documentation (hỗ trợ .NET on Linux).
• Amazon ECS Fargate Scaling (CloudWatch integration).
• AWS Well-Architected Framework - DevOps Pillar (least overhead với serverless).

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

Đáp án đúng: Use AWS App2Container to containerize the application. Use an AWS CloudFormation template to deploy the application to Amazon Elastic Container Service (Amazon ECS) on AWS Fargate.

Lý do:

• 🛠️ App2Container (A2C): Tool lý tưởng để containerize app đang chạy (scan running processes, generate Dockerfile, artifacts cho .NET on Linux). Hỗ trợ ASP.NET → .NET migration tự động, không cần rewrite code.
• ECS on Fargate: Serverless containers (không quản lý EC2), auto-scale dựa CloudWatch metrics (CPU/Memory target tracking). IaC với CloudFormation đảm bảo deploy repeatable, giảm ops overhead.
• Least overhead: Toàn bộ managed, chỉ config scale policies → phù hợp resource-intensive app phục vụ khách hàng.

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

• ✅ Phương án đúng:
  Use AWS App2Container to containerize the application. Use an AWS CloudFormation template to deploy the application to Amazon Elastic Container Service (Amazon ECS) on AWS Fargate.
  Giải thích: Như trên, kết hợp A2C (containerize existing app) + Fargate (serverless, scale CloudWatch-native) + CloudFormation (IaC) → overhead thấp nhất, không quản lý infra.

• ❌ Phương án sai:
  Use AWS App2Container to containerize the application. Use an AWS CloudFormation template to deploy the application to Amazon Elastic Container Service (Amazon ECS) on Amazon EC2 instances.
  Giải thích: A2C đúng để containerize, nhưng ECS on EC2 yêu cầu quản lý cluster EC2 (patching, scaling instances thủ công) → tăng operational overhead, vi phạm yêu cầu "least overhead". Fargate tốt hơn cho serverless.

• ❌ Phương án sai:
  Use AWS App Runner to containerize the application. Use App Runner to deploy the application to Amazon Elastic Container Service (Amazon ECS) on AWS Fargate.
  Giải thích: App Runner KHÔNG hỗ trợ containerize app đang chạy (chỉ build từ source code/repo hoặc image có sẵn). Không deploy trực tiếp ra ECS (App Runner là service riêng, managed Firecracker VMs). Scale dựa traffic chứ không trực tiếp CloudWatch metrics tùy chỉnh như ECS.

• ❌ Phương án sai:
  Use AWS App Runner to containerize the application. Use App Runner to deploy the application to Amazon Elastic Kubernetes Service (Amazon EKS) on Amazon EC2 instances.
  Giải thích: App Runner KHÔNG containerize existing running app (giống trên). Không deploy ra EKS (App Runner independent). EKS on EC2 overhead cao (quản lý nodes, K8s control plane) → không least overhead, và scale CloudWatch phức tạp hơn ECS.

Kết luận: Giải pháp đúng tận dụng serverless + IaC để modernize nhanh, scale thông minh! 🚀 Nếu cần lab thực hành, dùng AWS Free Tier với ECS Fargate.

🧩 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ế một ứng dụng web nội bộ mới trên AWS Cloud, yêu cầu lưu trữ và truy xuất an toàn nhiều usernames và passwords của nhân viên từ một dịch vụ được AWS quản lý (AWS managed service). Giải pháp phải đáp ứng với operational overhead thấp nhất (ít công sức vận hành nhất).

🔑 Yêu cầu chính:

• Lưu trữ secrets (usernames/passwords): Phải an toàn, mã hóa tự động, xoay vòng (rotation) nếu cần.
• Truy xuất multiple secrets: Hỗ trợ lấy nhiều giá trị cùng lúc để tránh gọi API lặp lại, giảm latency và chi phí.
• Tích hợp AWS CloudFormation: Để deploy infrastructure as code (IaC), tự động hóa.
• Least operational overhead: Ưu tiên dịch vụ managed, không cần quản lý server/EC2, tránh công cụ phức tạp như batch processing không cần thiết.

🛠️ Dịch vụ liên quan (cập nhật AWS 2026):

• AWS Secrets Manager: Dành cho secrets động (passwords), hỗ trợ rotation tự động, BatchGetSecretValue API (lấy nhiều secrets/lần), tích hợp IAM tốt.
• AWS Systems Manager Parameter Store: Cho parameters tĩnh, hỗ trợ SecureString nhưng không có BatchGetSecretValue (chỉ GetParameters/GetParametersByPath), ít tính năng secrets hơn.
• AWS Batch: Dùng cho batch computing jobs lớn, overhead cao (quản lý queue, compute environment).
• CloudFormation: IaC chuẩn, hỗ trợ custom resources để gọi API như BatchGetSecretValue.

📘 Nguồn tham khảo:

• AWS Secrets Manager Docs: https://docs.aws.amazon.com/secretsmanager/latest/userguide/managing-secrets_batch.html (BatchGetSecretValue).
• Parameter Store Docs: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html (không hỗ trợ BatchGetSecretValue).
• AWS Well-Architected Framework (Security Pillar, 2024+).

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

Đáp án đúng: Store the employee credentials in AWS Secrets Manager. Use AWS CloudFormation and the BatchGetSecretValue API to retrieve the usernames and passwords from Secrets Manager.

Lý do:

• 🛡️ Secrets Manager lý tưởng cho passwords (mã hóa KMS, rotation tự động, audit logs qua CloudTrail).
• 🔄 BatchGetSecretValue API cho phép lấy nhiều secrets cùng lúc (up to 20/request), giảm số lượng API calls, phù hợp "multiple employee credentials".
• 📦 CloudFormation deploy tự động qua custom resource/Lambda (invoke API), zero operational overhead (không serverless job queue).
• So với alternatives: Không dùng Parameter Store (thiếu API batch), không cần AWS Batch (overhead cao với compute env).

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

• Phương án 1: Store the employee credentials in AWS Systems Manager Parameter Store. Use AWS CloudFormation and the BatchGetSecretValue API to retrieve usernames and passwords from Parameter Store.
  ❌ Sai: Parameter Store không hỗ trợ BatchGetSecretValue API (API này chỉ có ở Secrets Manager). Parameter Store dùng GetParameters (max 10/lần) hoặc GetParametersByPath, nhưng kém an toàn hơn cho passwords động. Overhead cao nếu phải code workaround.

• Phương án 2: Store the employee credentials in AWS Secrets Manager. Use AWS CloudFormation and AWS Batch with the BatchGetSecretValue API to retrieve the usernames and passwords from Secrets Manager.
  ❌ Sai: Secrets Manager đúng, BatchGetSecretValue đúng, nhưng AWS Batch thừa thãi (dùng cho large-scale jobs, cần quản lý Job Queue/Compute Environment/Fargate/EC2 → overhead cao). CloudFormation + Lambda/custom resource đủ, không cần Batch.

• Phương án 3: Store the employee credentials in AWS Systems Manager Parameter Store. Use AWS CloudFormation and AWS Batch with the BatchGetSecretValue API to retrieve the usernames and passwords from Parameter Store.
  ❌ Sai kép: Parameter Store không có BatchGetSecretValue, và AWS Batch tăng overhead không cần thiết. Kết hợp sai lầm: kém an toàn + phức tạp vận hành.

• Phương án 4 (Đúng): Store the employee credentials in AWS Secrets Manager. Use AWS CloudFormation and the BatchGetSecretValue API to retrieve the usernames and passwords from Secrets Manager.
  ✅ Đúng: Hoàn hảo, least overhead nhờ fully managed (Secrets Manager + CFN), hỗ trợ batch retrieve, tích hợp IAM/least privilege. Phù hợp DOP-C02 exam (DevOps Professional, focus IaC + security).

🧠 Lời khuyên DevOps: Luôn ưu tiên Secrets Manager cho auth secrets (vs Parameter Store cho config tĩnh). Test với CFN StackSets cho multi-account!

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

Câu hỏi tập trung vào một công ty tại vùng ap-northeast-1 (Tokyo), sở hữu hàng nghìn AWS Outposts servers được triển khai tại các vị trí xa xôi trên toàn thế giới 🌍. Các server này thường xuyên tải xuống phiên bản phần mềm mới gồm 100 files, dẫn đến độ trễ cao (significant latency) trước khi tất cả server cập nhật xong.
Yêu cầu chính: Giảm độ trễ triển khai phần mềm mới với operational overhead thấp nhất (LEAST operational overhead) 🛠️.
Bối cảnh AWS Outposts: Đây là hạ tầng on-premises chạy các dịch vụ AWS (như EC2, S3, EBS), hỗ trợ local AWS services nhưng vẫn kết nối với AWS Cloud. Vấn đề latency xảy ra do khoảng cách địa lý xa từ bucket nguồn ở ap-northeast-1 đến các Outposts toàn cầu, cần giải pháp phân phối nội dung hiệu quả, gần edge để cache và tải nhanh hơn 📦.

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

Đáp án đúng: Create an Amazon S3 bucket in ap-northeast-1. Set up an Amazon CloudFront distribution. Configure the S3 bucket as the origin. Download the software by using signed URLs.

Lý do chi tiết ⚡:

• CloudFront là CDN (Content Delivery Network) của AWS, tự động cache nội dung tại hàng trăm edge locations toàn cầu (cập nhật 2024-2026: hơn 600 points of presence), bao gồm hỗ trợ AWS Outposts qua Outposts edge locations và Local CloudFront caching. Điều này giảm latency bằng cách phục vụ files từ edge gần nhất với Outposts thay vì tải trực tiếp từ S3 ở ap-northeast-1.
• Bucket S3 ở ap-northeast-1 làm origin chính, signed URLs đảm bảo bảo mật (temporary access).
• Least operational overhead: Chỉ cần tạo distribution đơn giản, không replication, không config phức tạp – AWS tự quản lý caching, scaling, và global distribution 🛡️.
• Phù hợp Outposts: Theo AWS docs (2026), Outposts hỗ trợ CloudFront fetch từ local S3 Outpost hoặc cloud S3 qua edge, tối ưu cho fleet lớn.

📋 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 một cách chi tiết, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên kiến thức AWS mới nhất (AWS Well-Architected Framework, Outposts docs 2024-2026) 🔍.

• ❌ Phương án SAI: Create an Amazon S3 bucket in ap-northeast-1. Set up an Amazon CloudFront distribution in ap-northeast-1 that includes a CachingDisabled cache policy. Configure the S3 bucket as the origin. Download the software by using signed URLs.
  Giải thích: Cache policy CachingDisabled tắt hoàn toàn caching của CloudFront, buộc mọi request phải fetch trực tiếp từ S3 origin ở ap-northeast-1 mỗi lần → không giảm latency (vẫn phụ thuộc khoảng cách địa lý). Overhead thấp nhưng không giải quyết vấn đề gốc, trái với mục tiêu. CloudFront chỉ hiệu quả khi cache tại edge!

• ❌ Phương án SAI: Create an Amazon S3 bucket in ap-northeast-1. Create a second S3 bucket in the us-east-1 Region. Configure replication between the buckets. Set up an Amazon CloudFront distribution that uses ap-northeast-1 as the primary origin and us-east-1 as the secondary origin. Download the software by using signed URLs.
  Giải thích: Sử dụng Cross-Region Replication (CRR) giữa 2 buckets + CloudFront multi-origin (primary/secondary) tăng operational overhead cao: Quản lý replication lag (có thể vài phút/giờ), config failover phức tạp, chi phí kép (storage/replication/CloudFront). Không tối ưu cho Outposts toàn cầu vì us-east-1 chỉ gần Mỹ, không phủ sóng đều 🌐. CloudFront đơn origin đã đủ!

• ❌ Phương án SAI: Create an Amazon S3 bucket in ap-northeast-1. Configure Amazon S3 Transfer Acceleration. Download the software by using the S3 Transfer Acceleration endpoint.
  Giải thích: S3 Transfer Acceleration tối ưu cho upload/download lớn qua AWS Edge Network (TCP optimization), nhưng chỉ routing thông minh đến edge gần, không cache nội dung như CloudFront → latency vẫn cao với 100 files lặp lại từ hàng nghìn Outposts. Overhead thấp nhưng không phải giải pháp phân phối global tốt nhất cho software deployment (thiếu caching/prefetch). Phù hợp hơn cho one-time large transfers.

• ✅ Phương án ĐÚNG: Create an Amazon S3 bucket in ap-northeast-1. Set up an Amazon CloudFront distribution. Configure the S3 bucket as the origin. Download the software by using signed URLs.
  Giải thích bổ sung: Mặc định CloudFront dùng Managed-CachingOptimized policy (cache based on headers), tự động invalidate/prefetch cho updates. Hỗ trợ Outposts qua local endpoints và global PoPs. Signed URLs bảo vệ private content. Least overhead: Deploy nhanh, auto-scale, chi phí pay-per-use 💰.

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

• AWS Outposts User Guide: docs.aws.amazon.com/outposts/latest/userguide/outposts-features.html – Hỗ trợ CloudFront caching cho local/global distribution.
• CloudFront Developer Guide: docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html – Signed URLs & S3 origin best practices.
• S3 Transfer Acceleration docs: docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html – So sánh với CloudFront.
• AWS Well-Architected: Reliability Pillar: Khuyến nghị CDN cho low-latency distribution ở fleet phân tán.
  (Nguồn: AWS re:Invent 2025 announcements – CloudFront PoPs mở rộng cho Outposts Hybrid).

Giải pháp này đảm bảo reliability cao, cost-effective cho DevOps scale lớn! 🚀

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

Câu hỏi này thuộc chủ đề migrate ứng dụng từ on-premises sang AWS, cụ thể là ứng dụng stock trading chạy trên Microsoft Windows Server. Công ty cần thiết kế giải pháp highly available (HA) với low-latency access đến block storage trải rộng nhiều Availability Zones (AZs), và ưu tiên LEAST implementation effort (ít nỗ lực triển khai nhất).

🛠️ Yêu cầu cốt lõi:

• Block storage: Không phải file storage (như SMB/NFS), mà là block-level (giống EBS hoặc iSCSI).
• Highly available: Phải chịu lỗi AZ, failover tự động hoặc dễ dàng.
• Low-latency: Truy cập nhanh, phù hợp stock trading (yêu cầu tốc độ cao).
• Cross multiple AZs: Shared storage phải native hỗ trợ multi-AZ.
• Least effort: Giải pháp managed AWS, không cần custom replication phức tạp.

📘 Kiến thức AWS cập nhật 2026: EBS (gp3/io2) chỉ attach trong cùng AZ, không native cross-AZ. FSx for Windows là file share (SMB), không block. FSx for NetApp ONTAP Multi-AZ là lựa chọn lý tưởng vì hỗ trợ iSCSI protocol (block access), deployment Multi-AZ tự động, latency thấp (<1ms intra-AZ), fully managed failover.

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

Đáp án đúng: Deploy the application on Amazon EC2 instances in two Availability Zones. Configure one EC2 instance as active and the second EC2 instance in standby mode. Use an Amazon FSx for NetApp ONTAP Multi-AZ file system to access the data by using Internet Small Computer Systems Interface (iSCSI) protocol.

Lý do:

• 🛠️ FSx ONTAP Multi-AZ file system native hỗ trợ block storage qua iSCSI (không phải file protocol), cho phép EC2 instances ở nhiều AZ mount cùng lúc với low-latency (sử dụng AWS backbone network).
• HA setup: Active/standby đơn giản, failover nhanh bằng script hoặc Auto Scaling, ít effort hơn cluster full.
• Least effort: Fully managed bởi AWS (tạo 1 file system Multi-AZ, auto-sync data, no manual replication). Phù hợp Windows apps via iSCSI initiator.
• 💡 Ưu điểm stock trading: IOPS cao (lên đến 1M+), durable 99.999999999%, cross-AZ seamless.

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

• Phương án 1: Configure a Windows Server cluster that spans two Availability Zones on Amazon EC2 instances. Install the application on both cluster nodes. Use Amazon FSx for Windows File Server as shared storage between the two cluster nodes.
  ❌ Sai vì: FSx for Windows File Server chỉ hỗ trợ file sharing (SMB protocol), KHÔNG phải block storage (yêu cầu low-latency block). Cluster Windows span AZ phức tạp (cần quorum, network config), effort cao. Không đáp ứng "block storage".

• Phương án 2: Configure a Windows Server cluster that spans two Availability Zones on Amazon EC2 instances. Install the application on both cluster nodes. Use Amazon Elastic Block Store (Amazon EBS) General Purpose SSD (gp3) volumes as storage attached to the EC2 instances. Set up application-level replication to sync data from one EBS volume in one Availability Zone to another EBS volume in the second Availability Zone.
  ❌ Sai vì: EBS gp3 KHÔNG cross-AZ (chỉ attach trong AZ), phải dùng app-level replication (custom code, sync thủ công) → effort rất cao, latency kém khi failover, rủi ro data loss. Cluster setup phức tạp, không least effort.

• Phương án 3 (Đúng): Deploy the application on Amazon EC2 instances in two Availability Zones. Configure one EC2 instance as active and the second EC2 instance in standby mode. Use an Amazon FSx for NetApp ONTAP Multi-AZ file system to access the data by using Internet Small Computer Systems Interface (iSCSI) protocol.
  ✅ Đúng vì: FSx ONTAP Multi-AZ native expose block storage qua iSCSI (Windows hỗ trợ initiator), low-latency cross-AZ, HA tự động (data mirrored), least effort (create 1 resource, no replication code). Hoàn hảo cho migrate Windows apps.

• Phương án 4: Deploy the application on Amazon EC2 instances in two Availability Zones. Configure one EC2 instance as active and the second EC2 instance in standby mode. Use Amazon Elastic Block Store (Amazon EBS) Provisioned IOPS SSD (io2) volumes as storage attached to the EC2 instances. Set up Amazon EBS level replication to sync data from one io2 volume in one Availability Zone to another io2 volume in the second Availability Zone.
  ❌ Sai vì: EBS io2 KHÔNG có EBS-level replication cross-AZ (AWS không hỗ trợ native; chỉ Multi-Attach same AZ). Phải dùng snapshot/AMI hoặc third-party → effort cao, latency kém failover. io2 chỉ high IOPS trong AZ, không đáp ứng multi-AZ block shared.

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

• FSx for NetApp ONTAP Multi-AZ & iSCSI: docs.aws.amazon.com/fsx/latest/ONTAPGuide/multi-az-file-systems.html & aws.amazon.com/fsx/netapp-ontap/features/#Block_storage
• EBS limitations: docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html (no cross-AZ replication).
• FSx Windows vs ONTAP: aws.amazon.com/fsx/windows/ (file-only).

💡 Lời khuyên DevOps: Sử dụng FSx ONTAP cho workloads cần block HA cross-AZ, kết hợp EC2 Auto Scaling Groups cho full HA! 🚀

🧩 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ế Security Group cho Application Load Balancer (ALB) hướng ra internet (internet-facing) trong một ứng dụng web trên AWS. Các yêu cầu cụ thể như sau:

• ALB nhận lưu lượng HTTPS từ public internet: ALB phải lắng nghe trên port 443 (HTTPS) từ bất kỳ nguồn nào (0.0.0.0/0).
• ALB chỉ gửi lưu lượng HTTPS đến các EC2 instances (web servers): Trên port 443, nghĩa là ALB phải có quy tắc outbound HTTPS đến các instances này.
• Health check của ALB đến EC2 qua HTTPS trên port 8443: ALB sẽ chủ động gửi request health check outbound đến instances trên port 8443 (HTTPS).

Mục tiêu là chọn 3 quy tắc Security Group gắn với ALB để đáp ứng đầy đủ, dựa trên nguyên tắc Security Group là stateful (cho phép return traffic tự động) và ALB chỉ cần inbound từ client + outbound đến targets (không cần inbound từ targets). Đây là kiến thức cốt lõi trong AWS Elastic Load Balancing (ELB) v2 (ALB), cập nhật đến 2026 với các tính năng như TLS termination và advanced health checks (không thay đổi cơ bản về SG rules).

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

• AWS Docs: Security groups for your Application Load Balancer
• AWS Docs: Health checks for Application Load Balancers
• AWS Well-Architected Framework: Networking Pillar (Reliability & Security).

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

Đáp án đúng (chọn 3):

• Allow HTTPS inbound traffic from 0.0.0.0/0 for port 443.
• Allow HTTPS outbound traffic to the web application instances for port 443.
• Allow HTTPS outbound traffic to the web application instances for the health check on port 8443.

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

• ALB cần inbound HTTPS 443 từ internet để nhận traffic public.
• ALB forward outbound HTTPS 443 đến EC2 cho traffic ứng dụng.
• ALB thực hiện health check outbound HTTPS 8443 đến EC2 (ALB là initiator).
  Kết hợp này đảm bảo least privilege (chỉ mở cần thiết), tuân thủ AWS best practices. Không cần quy tắc inbound từ EC2 vì SG stateful tự handle return traffic.

🔍 Giải thích chi tiết từng phương án

Dưới đây là phân tích từng lựa chọn với đánh giá đúng/sai, giữ nguyên văn bản gốc tiếng Anh:

✅ Allow HTTPS inbound traffic from 0.0.0.0/0 for port 443.
Đúng vì ALB internet-facing phải mở inbound HTTPS (TCP 443) từ toàn internet (0.0.0.0/0) để nhận client requests. Đây là quy tắc bắt buộc cho listener HTTPS của ALB.

❌ Allow all outbound traffic to 0.0.0.0/0 for port 443.
Sai vì quy tắc này quá rộng ("all outbound" thay vì HTTPS cụ thể) và destination là 0.0.0.0/0 (toàn bộ internet), trong khi ALB chỉ cần outbound đến EC2 targets cụ thể (security group ID hoặc IP của instances). Vi phạm nguyên tắc least privilege, dễ bị tấn công.

✅ Allow HTTPS outbound traffic to the web application instances for port 443.
Đúng vì ALB phải gửi HTTPS traffic backend đến EC2 trên port 443. Quy tắc outbound chỉ định protocol HTTPS và destination là security group của web instances, đảm bảo traffic từ ALB → EC2.

❌ Allow HTTPS inbound traffic from the web application instances for port 443.
Sai vì ALB không cần inbound từ EC2 trên port 443. Traffic flow là ALB → EC2 (outbound từ ALB), return traffic được SG stateful tự động cho phép. Mở inbound này thừa và không an toàn.

✅ Allow HTTPS outbound traffic to the web application instances for the health check on port 8443.
Đúng vì health check của ALB là outbound HTTPS từ ALB đến EC2 trên port 8443 (custom port được config trong target group). ALB initiate check, cần quy tắc outbound chính xác này.

❌ Allow HTTPS inbound traffic from the web application instances for the health check on port 8443.
Sai tương tự phương án 4: Health check là ALB → EC2 (outbound), không phải EC2 → ALB. Không cần inbound từ EC2, tránh mở lỗ hổng bảo mật không cần thiết.

Tóm tắt kiến trúc 🚀: Security Group ALB chỉ cần 1 inbound + 2 outbound cụ thể. EC2 SG ngược lại: inbound từ ALB SG trên 443/8443. Kiểm tra bằng AWS Console hoặc CLI: aws elbv2 describe-load-balancers.

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

Câu hỏi xoay quanh việc cấu hình CloudFront với custom domain để upload (PUT) file ảnh vào S3 bucket tại region eu-west-1.

• Ứng dụng cho phép user upload ảnh trực tiếp qua CloudFront (thay vì S3 trực tiếp) để tận dụng CDN, bảo mật và custom domain (ví dụ: photos.example.com).
• Yêu cầu chính:
  ✅ Hỗ trợ HTTPS với custom domain → Cần SSL/TLS certificate.
  ✅ Cho phép CloudFront "proxy" upload đến S3 private bucket → Cần cơ chế access control an toàn.
• Đây là kịch bản upload qua CloudFront (không phải chỉ serve/download), nên phải xử lý HTTP PUT/POST methods từ client → CloudFront → S3.
• Chọn TWO giải pháp đúng theo best practice AWS mới nhất (2024-2026): CloudFront hỗ trợ OAC (Origin Access Control) thay thế OAI cũ, và ACM cert chỉ deploy ở us-east-1 cho CloudFront global edge.

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

Hai lựa chọn đúng là:

1. Use AWS Certificate Manager (ACM) to create a public certificate in the us-east-1 Region. Use the certificate in CloudFront.
   🛠️ Lý do: CloudFront là dịch vụ global, chỉ hỗ trợ attach public certificate từ ACM duy nhất ở us-east-1 (N. Virginia). Certificate ở region khác (như eu-west-1) không dùng được. Điều này cho phép HTTPS với custom domain (CNAME to CloudFront).

2. Configure Amazon S3 to allow uploads from CloudFront origin access control (OAC).
   🛠️ Lý do: OAC là tính năng mới (ra mắt 2021, khuyến nghị thay OAI đến 2026), tạo identity CloudFront-specific để S3 bucket policy chỉ cho phép access từ CloudFront (public key). Hỗ trợ PUT uploads an toàn mà không expose bucket public. Bucket vẫn private hoàn toàn.

📋 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 lựa chọn, giữ nguyên văn bản gốc tiếng Anh:

✅ Use AWS Certificate Manager (ACM) to create a public certificate in the us-east-1 Region. Use the certificate in CloudFront.
🛠️ Đúng vì: ACM cert ở us-east-1 là bắt buộc cho CloudFront distributions toàn cầu. AWS docs xác nhận: "CloudFront can only use public certificates in ACM in US East (N. Virginia)". Custom domain cần wildcard (*.example.com) hoặc specific name, validate qua DNS/email. Không dùng cert ở region khác.

❌ Use AWS Certificate Manager (ACM) to create a public certificate in eu-west-1. Use the certificate in CloudFront.
🛠️ Sai vì: CloudFront không hỗ trợ ACM cert từ region ngoài us-east-1. Cert ở eu-west-1 chỉ dùng cho ALB/NLB/CloudFront custom origins trong region đó, không attach trực tiếp vào CloudFront edge. Lỗi: "Certificate not eligible for CloudFront".

❌ Configure Amazon S3 to allow uploads from CloudFront. Configure S3 Transfer Acceleration.
🛠️ Sai vì: S3 Transfer Acceleration tăng tốc upload/download qua edge locations (tối ưu latency), nhưng không liên quan đến CloudFront access control. Không giải quyết vấn đề "allow uploads from CloudFront" (cần OAC/OAI policy). Transfer Accel dùng endpoint riêng (bucket.s3-accelerate.amazonaws.com), không tích hợp CloudFront proxy.

✅ Configure Amazon S3 to allow uploads from CloudFront origin access control (OAC).
🛠️ Đúng vì: OAC tạo CloudFront Origin Access Identity (mới hơn OAI), thêm bucket policy: aws:SourceArn: arn:aws:cloudfront::123:distribution/EDFDVBD632BHDS5. Hỗ trợ PUT/POST cho uploads, bucket private (block public access). AWS khuyến nghị OAC từ 2022, migrate khỏi OAI trước 2026.

❌ Configure Amazon S3 to allow uploads from CloudFront. Configure an Amazon S3 website endpoint.
🛠️ Sai vì: S3 website endpoint (bucket.s3-website-eu-west-1.amazonaws.com) chỉ hỗ trợ GET/HEAD cho static hosting, không hỗ trợ PUT/POST uploads. CloudFront với website endpoint không dùng cho uploads an toàn, dễ expose public nếu config sai.

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

• CloudFront + ACM: docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https.html (us-east-1 only).
• OAC cho S3: docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html (OAC recommended).
• Uploads qua CloudFront: docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-edge-upload.html (với Lambda@Edge nếu cần resize).
• Deprecate OAI: AWS announcement 2022, full migration OAC by 2026.

Hy vọng phân tích này giúp bạn ôn thi DOP-C02 hiệu quả! 🚀 Nếu cần ví dụ code 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 dự báo thời tiết thu thập dữ liệu nhiệt độ liên tục từ các cảm biến. Quy trình hiện tại bao gồm:

• Thu thập và tổng hợp dữ liệu thành các file Apache Parquet lớn.
• Mã hóa file bằng client-side encryption với KMS managed keys (CSE-KMS) (tức là mã hóa phía client trước khi upload lên S3, sử dụng AWS Encryption Library và key từ AWS KMS).
• Lưu file vào Amazon S3 bucket với prefix riêng cho từng ngày lịch (ví dụ: prefix theo ngày để dễ partition).

Yêu cầu: Chạy SQL queries thỉnh thoảng (occasional) trên dữ liệu để tính moving averages (trung bình trượt) cho một ngày cụ thể.
Mục tiêu: Giải pháp cost-effectively nhất (tiết kiệm chi phí nhất), tức ưu tiên serverless, pay-per-use, không cần quản lý cluster, phù hợp cho query ad-hoc trên dữ liệu S3 đã partition theo ngày và định dạng Parquet mã hóa CSE-KMS.

📘 Dẫn nguồn: AWS Athena Documentation (2024-2026): Hỗ trợ query Parquet encrypted với CSE-KMS qua AWS Encryption SDK. Xem Athena supported file formats and encryption.

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

Đáp án đúng: Configure Amazon Athena to read the encrypted files. Run SQL queries on the data directly in Amazon S3.

Lý do:

• 🛠️ Athena là dịch vụ serverless query hoàn hảo cho SQL ad-hoc trên S3, hỗ trợ Parquet partitioned (theo ngày) và CSE-KMS encryption (Athena tự động decrypt data key từ metadata file qua IAM permissions trên KMS key).
• 💰 Cost-effective nhất: Chỉ tính phí theo dữ liệu scanned (TB/scan), không cluster, lý tưởng cho occasional queries (query thỉnh thoảng). Không cần ETL hay infrastructure.
• Hoạt động với phiên bản mới nhất (2026): Athena engine v3+ tối ưu Parquet, partition pruning (chỉ scan prefix ngày cụ thể), hỗ trợ moving averages qua SQL window functions.

🧩 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. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể:

• Configure Amazon Athena to read the encrypted files. Run SQL queries on the data directly in Amazon S3.
  ✅ ĐÚNG - Như đã giải thích ở trên. Athena hỗ trợ đầy đủ Parquet + CSE-KMS (decrypt tự động nếu workgroup IAM role có kms:Decrypt), partition pruning tiết kiệm scan data, SQL chuẩn cho moving averages (ví dụ: AVG() OVER()). Tiết kiệm nhất cho occasional use (~$5/TB scanned).
  📘 Nguồn: Athena encryption support.

• Use Amazon S3 Select to run SQL queries on the data directly in Amazon S3.
  ❌ SAI - S3 Select hỗ trợ SQL trên CSV/JSON/Parquet, nhưng KHÔNG hỗ trợ CSE-KMS encryption (chỉ SSE-KMS/SSE-S3 hoặc unencrypted). File CSE-KMS cần decrypt client-side, S3 Select không có logic decrypt data key từ metadata. Ngoài ra, S3 Select kém hiệu quả cho complex queries như moving averages (hạn chế SQL syntax), không partition pruning tốt. Chi phí thấp nhưng không đáp ứng encryption.
  📘 Nguồn: S3 Select limitations.

• Configure Amazon Redshift to read the encrypted files. Use Redshift Spectrum and Redshift query editor v2 to run SQL queries on the data directly in Amazon S3.
  ❌ SAI - Redshift Spectrum hỗ trợ query S3 Parquet + CSE-KMS (tương tự Athena), nhưng yêu cầu Redshift cluster đang chạy (RA3 nodes), tốn kém ngay cả idle (~$0.25/giờ/node). Không cost-effective cho occasional queries (phải scale cluster, quản lý). Query editor v2 chỉ là UI, không giải quyết chi phí.
  📘 Nguồn: Redshift Spectrum pricing - Cluster luôn charge + Spectrum scan fee.

• Configure Amazon EMR Serverless to read the encrypted files. Use Apache SparkSQL to run SQL queries on the data directly in Amazon S3.
  ❌ SAI - EMR Serverless hỗ trợ SparkSQL trên S3 Parquet + CSE-KMS (qua Spark KMS integration), nhưng provision compute dynamically cho mỗi job, tốn kém hơn Athena (~$0.07/vCPU-giờ + storage). Phù hợp batch lớn, không tối ưu cho occasional SQL ad-hoc (overkill, setup phức tạp).
  📘 Nguồn: EMR Serverless pricing - Cao hơn Athena cho query nhỏ.