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

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

Câu hỏi tập trung vào việc tối ưu hóa hiệu suất truy vấn SQL trên cụm Amazon Redshift mà không được tăng kích thước cụm do hạn chế ngân sách. 🛡️

• Dữ liệu được lưu trữ trong nhiều bảng (multiple tables), tải dữ liệu bằng phân phối EVEN (phân bố đều các hàng ngẫu nhiên lên các node).
• Một số bảng lớn (hundreds of gigabytes), các bảng khác nhỏ (less than 10 MB).
• Mục tiêu: Cải thiện performance query (như JOIN, WHERE) bằng cách chọn distribution style phù hợp, khóa chính/ngoại (PK/FK), mà không cần scale up hardware.
  Redshift phân phối dữ liệu theo distribution style để tránh data skew (dữ liệu lệch) và data shuffle (chuyển dữ liệu giữa node khi JOIN). EVEN phù hợp tables nhỏ/không JOIN thường xuyên, nhưng kém với tables lớn hoặc JOIN nhiều. ✅ Giải pháp cần tập trung vào small tables (dùng ALL để copy toàn bộ lên mọi node, tránh shuffle) và PK/FK để optimize JOIN. Kiến thức dựa trên Redshift RA3/concurrency scaling (cập nhật 2025-2026), ưu tiên sort keys và distribution keys cho large tables.

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

Đáp án đúng: Use the ALL distribution style for rarely updated small tables. Specify primary and foreign keys for all tables.

Lý do:

• ALL style lý tưởng cho small tables (<10MB, rarely updated): Copy toàn bộ bảng lên mọi node, giúp JOIN nhanh (không shuffle), tiết kiệm I/O và CPU. Phù hợp budget vì không cần scale cluster. 🏆
• Specify PK/FK cho tất cả tables: Tạo constraints giúp Redshift zone maps và sort keys tự động, optimize predicate pushdown và compression. Với large tables, FK khớp với PK giúp co-locate data khi dùng KEY style (Redshift tự infer).
• Meet yêu cầu: Optimize query mà không thay đổi cluster size, tận dụng small tables hiệu quả. Theo best practices Redshift 2026.

📋 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). Sử dụng distribution styles (EVEN/ALL/KEY/AUTO) và constraints theo docs AWS mới nhất.

• ❌ [SAI] Keep using the EVEN distribution style for all tables. Specify primary and foreign keys for all tables.
  Giải thích sai: Giữ EVEN cho tất cả tables (bao gồm large hundreds GB) gây data skew và shuffle nặng khi JOIN large tables, làm query chậm. PK/FK tốt nhưng không bù đắp skew. Không optimize hiệu quả cho large data.

• ❌ [SAI] Use the ALL distribution style for large tables. Specify primary and foreign keys for all tables.
  Giải thích sai: ALL cho large tables (hundreds GB) gây bloat memory/CPU (copy toàn bộ lên mọi node), tăng storage chi phí và chậm load/query. Chỉ dùng ALL cho small tables (<1GB, lý tưởng <100MB). Skew query tệ hơn.

• ✅ [ĐÚNG] Use the ALL distribution style for rarely updated small tables. Specify primary and foreign keys for all tables.
  Giải thích đúng: Như phần đáp án trên. ALL cho small/rarely updated tránh shuffle JOIN, PK/FK optimize toàn bộ. Hoàn hảo cho mix large/small tables, budget-friendly.

• ❌ [SAI] Specify a combination of distribution, sort, and partition keys for all tables.
  Giải thích sai: Redshift không có partition keys (như Hive/Parquet); chỉ sort keys và distribution keys. "Partition" không tồn tại ở Redshift (dùng workload management hoặc views thay thế). Gây confusion, không apply được.

📘 Tài liệu tham khảo

• AWS Redshift Docs: Choosing a data distribution style (cập nhật 2025: Ưu tiên ALL cho small tables <1GB).
• Best practices for loading tables (PK/FK giúp auto-optimize).
• Primary key & foreign key constraints (tăng query speed 2-10x).
• AWS re:Post & Well-Architected Framework (DevOps pillar, 2026): Tối ưu Redshift mà không scale hardware. 🛠️

🧩 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 xử lý dữ liệu từ file .csv chứa thông tin địa chỉ vật lý với các cột: Door_No, Street_Name, City, và Zip_Code. Mục tiêu là tạo một cột duy nhất lưu trữ dữ liệu dưới dạng JSON object (một map/object có cấu trúc key-value), ví dụ:

{
"Door_No": "24",
"Street_Name": "AAA street",
"City": "BBB",
"Zip_Code": "111111"
}

Yêu cầu giải pháp phải có LEAST coding effort (ít nỗ lực lập trình nhất), nghĩa là ưu tiên công cụ no-code/low-code để tránh viết code thủ công. Chủ đề thuộc AWS Glue DataBrew – dịch vụ chuẩn bị dữ liệu visual (visual data preparation) trong hệ sinh thái AWS Glue, hỗ trợ transform dữ liệu mà không cần code phức tạp. Kiến thức cập nhật đến 2026: AWS Glue DataBrew (ra mắt 2020, phiên bản mới nhất 2025-2026) vẫn giữ các transformation như NEST_TO_MAP để tạo struct/map từ columns, phù hợp hoàn hảo với định dạng JSON object yêu cầu.

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

Đáp án đúng: Use AWS Glue DataBrew to read the files. Use the NEST_TO_MAP transformation to create the new column.

Lý do:

• AWS Glue DataBrew cho phép read file .csv trực tiếp qua giao diện visual (no-code), sau đó sử dụng NEST_TO_MAP để nest (lồng ghép) các cột riêng lẻ thành một map/object với key là tên cột và value tương ứng – chính xác khớp định dạng JSON object yêu cầu.
• Đây là giải pháp ít coding effort nhất vì toàn bộ quá trình chỉ kéo-thả transformation trong recipe (công thức), export ra Glue Job hoặc S3 mà không viết dòng code nào.
• Hiệu quả cao cho batch processing file .csv lớn, tích hợp AWS Lake Formation và Athena. 🛠️

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

• ❌ [SAI] Use AWS Glue DataBrew to read the files. Use the NEST_TO_ARRAY transformation to create the new column.
  Giải thích sai: NEST_TO_ARRAY chỉ tạo array/list từ các cột (ví dụ: ["24", "AAA street", "BBB", "111111"]), không phải map/object có key-value như JSON yêu cầu. Sử dụng transformation này sẽ không khớp định dạng, buộc phải chỉnh sửa thêm (tăng effort).

• ✅ [ĐÚNG] Use AWS Glue DataBrew to read the files. Use the NEST_TO_MAP transformation to create the new column.
  Giải thích đúng: Như đã nêu ở trên, NEST_TO_MAP trực tiếp tạo map với key là tên cột gốc (Door_No, Street_Name, v.v.), value từ dữ liệu – hoàn hảo cho JSON object. Ít effort nhất nhờ visual recipe trong DataBrew.

• ❌ [SAI] Use AWS Glue DataBrew to read the files. Use the PIVOT transformation to create the new column.
  Giải thích sai: PIVOT dùng để xoay dữ liệu từ rows thành columns (unpivot ngược lại), không tạo nested object. Áp dụng vào .csv này sẽ làm dữ liệu rối loạn (ví dụ: rows thành columns động), không liên quan đến việc nest thành JSON.

• ❌ [SAI] Write a Lambda function in Python to read the files. Use the Python data dictionary type to create the new column.
  Giải thích sai: Viết Lambda Python yêu cầu code thủ công đầy đủ (sử dụng pandas/boto3 đọc .csv, dict comprehension tạo JSON, output ra S3/DynamoDB), mất nhiều effort hơn DataBrew (phải handle error, scaling, trigger). Không phải "LEAST coding effort" vì phải code từ đầu.

📘 Tài liệu tham khảo

• AWS Glue DataBrew Documentation (2025-2026): Transformations in AWS Glue DataBrew – Chi tiết NEST_TO_MAP vs NEST_TO_ARRAY.
• AWS Glue DataBrew User Guide: Handling structured data – Ví dụ nest columns thành map/JSON.
• Exam Prep DOP-C02: Chủ đề DataBrew trong AWS Certified DevOps Engineer Professional (cập nhật blueprint 2026).

Giải pháp này tối ưu cho DevOps pipeline tự động hóa ETL với zero-code! 🚀

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

Câu hỏi tập trung vào bảo mật dữ liệu nhạy cảm lưu trữ trên Amazon S3 (call logs chứa thông tin khách hàng). Yêu cầu chính:

• Mã hóa (encryption) các S3 objects.
• Sử dụng encryption keys mà chỉ specific employees mới truy cập được.
• Giải pháp phải có LEAST effort (ít công sức nhất, nghĩa là đơn giản, ít quản lý thủ công, tận dụng managed services của AWS).

📘 Bối cảnh AWS mới nhất (đến 2026): Amazon S3 hỗ trợ 4 loại server-side encryption (SSE): SSE-S3, SSE-KMS, SSE-C, và client-side. AWS khuyến nghị SSE-KMS cho kiểm soát keys chi tiết qua IAM và KMS key policies, mà không cần quản lý hardware/infrastructure phức tạp.

Dẫn nguồn tham khảo:

• AWS S3 Server-Side Encryption (cập nhật 2024-2026).
• AWS KMS Key Management.
• AWS Well-Architected Framework: Security Pillar (Reliability & Security).

✅ Đáp án đúng

Use server-side encryption with AWS KMS keys (SSE-KMS) to encrypt the objects that contain customer information. Configure an IAM policy that restricts access to the KMS keys that encrypt the objects.

Lý do lựa chọn:

• 🛡️ SSE-KMS là giải pháp managed hoàn toàn bởi AWS, tự động mã hóa/decrypt khi đọc/ghi S3 objects, least effort vì không cần code thêm để gọi encrypt/decrypt.
• 🔑 KMS keys cho phép kiểm soát truy cập granular qua IAM policies và KMS key policies (chỉ specific employees/IAM roles/users được phép kms:Encrypt, kms:Decrypt, kms:DescribeKey).
• ⚡ Tiết kiệm effort: Không cần quản lý keys thủ công, AWS handle rotation, backup, HSM compliance (FIPS 140-3 Level 3 đến 2026).
• Phù hợp nhất cho dữ liệu nhạy cảm, tuân thủ GDPR/HIPAA.

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

• ❌ Use an AWS CloudHSM cluster to store the encryption keys. Configure the process that writes to Amazon S3 to make calls to CloudHSM to encrypt and decrypt the objects. Deploy an IAM policy that restricts access to the CloudHSM cluster.

  • Phân tích sai: CloudHSM là hardware security module (HSM) tự quản lý, yêu cầu provision cluster, install client software, code custom calls (qua PKCS#11 hoặc JCE), rất high effort (setup, scaling, patching). IAM chỉ restrict cluster access, nhưng không integrate native với S3 SSE. Không phải least effort, chỉ dùng khi cần single-tenant HSM (quy định nghiêm ngặt).

• ❌ Use server-side encryption with customer-provided keys (SSE-C) to encrypt the objects that contain customer information. Restrict access to the keys that encrypt the objects.

  • Phân tích sai: SSE-C yêu cầu client tự cung cấp và quản lý keys (gửi keys trong mỗi request S3 PutObject/GetObject), high effort vì phải code xử lý keys an toàn (không lưu S3), handle rotation/loss. AWS không quản lý keys, chỉ "restrict access" khó khăn (keys ở client-side). Không least effort, rủi ro compliance cao.

• ✅ Use server-side encryption with AWS KMS keys (SSE-KMS) to encrypt the objects that contain customer information. Configure an IAM policy that restricts access to the KMS keys that encrypt the objects.

  • Phân tích đúng: Như đã giải thích ở trên. Tích hợp native S3-KMS, chỉ cần config bucket encryption và IAM/KMS policies (ví dụ: kms:Decrypt chỉ cho specific users). Effort thấp nhất: enable SSE-KMS trên bucket policy/S3 console, zero code changes cho app viết S3.

• ❌ Use server-side encryption with Amazon S3 managed keys (SSE-S3) to encrypt the objects that contain customer information. Configure an IAM policy that restricts access to the Amazon S3 managed keys that encrypt the objects.

  • Phân tích sai: SSE-S3 dùng keys managed hoàn toàn bởi S3 (không expose ra), không thể restrict access đến keys qua IAM (S3 tự handle, không cho phép customer control keys). IAM chỉ control S3 bucket access, không chạm đến keys. Vi phạm yêu cầu "keys chỉ specific employees access", dù effort thấp nhưng không meet requirements đầy đủ. AWS vẫn hỗ trợ nhưng recommend SSE-KMS cho control tốt hơn (2026 updates).

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

🧩 Tình huống: Một công ty lưu trữ hàng petabytes dữ liệu trong hàng nghìn bucket Amazon S3 sử dụng lớp lưu trữ S3 Standard. Dữ liệu hỗ trợ các workload phân tích (analytics) với mẫu truy cập dữ liệu không dự đoán được và biến đổi (unpredictable and variable data access patterns).
✅ Yêu cầu chính:

• Một số dữ liệu không được truy cập trong nhiều tháng.
• Phải truy xuất TẤT CẢ dữ liệu trong vòng milliseconds (millisecond retrieval).
• Tối ưu hóa chi phí lưu trữ S3 với ít overhead vận hành nhất (LEAST operational overhead).

🛠️ Mục tiêu: Tìm giải pháp tự động hóa cao, không cần can thiệp thủ công thường xuyên, đảm bảo tốc độ truy xuất nhanh và tiết kiệm chi phí cho dữ liệu ít truy cập.

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

Đáp án đúng: Use S3 Intelligent-Tiering. Use the default access tier.

Lý do chi tiết 🏆:

• S3 Intelligent-Tiering tự động giám sát và di chuyển objects giữa các tier Frequent Access (FA) và Infrequent Access (IA) dựa trên mẫu truy cập thực tế, không cần cấu hình quy tắc thủ công hay theo dõi liên tục → least operational overhead (chỉ enable một lần cho bucket).
• Default access tier chỉ bao gồm FA (truy xuất ms, phí cao hơn) và IA (truy xuất ms, phí lưu trữ thấp hơn cho dữ liệu ít truy cập) → Đáp ứng millisecond retrieval cho tất cả dữ liệu.
• Tiết kiệm chi phí: Phí monitoring nhỏ (0.0025$/1.000 objects/tháng), tự động chuyển dữ liệu ít truy cập sang IA mà không cần dự đoán patterns.
• Phù hợp với petabytes dữ liệu, hàng nghìn buckets và unpredictable access → Không cần refine policies thủ công.

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

• AWS S3 Intelligent-Tiering: docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering-overview.html (cập nhật 2024-2026, default tiers: FA & IA).
• Best Practices S3 Storage Classes: aws.amazon.com/s3/storage-classes/intelligent-tiering.

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

Dưới đây là phân tích từng lựa chọn giữ nguyên văn bản gốc bằng tiếng Anh, đánh dấu ✅/❌ và giải thích chi tiết bằng tiếng Việt:

• [SAI] Use S3 Storage Lens standard metrics to determine when to move objects to more cost-optimized storage classes. Create S3 Lifecycle policies for the S3 buckets to move objects to cost-optimized storage classes. Continue to refine the S3 Lifecycle policies in the future to optimize storage costs.
  ❌ Sai vì: S3 Storage Lens chỉ cung cấp metrics (chuẩn) để phân tích thủ công, sau đó phải tạo và tinh chỉnh Lifecycle policies liên tục → operational overhead cao (monitor metrics, adjust rules thường xuyên cho hàng nghìn buckets). Không tự động hoàn toàn, không phù hợp với "least overhead" và unpredictable patterns.

• [SAI] Use S3 Storage Lens activity metrics to identify S3 buckets that the company accesses infrequently. Configure S3 Lifecycle rules to move objects from S3 Standard to the S3 Standard-Infrequent Access (S3 Standard-IA) and S3 Glacier storage classes based on the age of the data.
  ❌ Sai vì: Dùng activity metrics từ Storage Lens để identify buckets ít truy cập, rồi config Lifecycle rules dựa trên tuổi dữ liệu (age-based) → Overhead cao do phải monitor và setup rules thủ công. Đặc biệt, S3 Glacier chỉ truy xuất trong 3-5 giờ (không phải ms) → vi phạm yêu cầu millisecond retrieval cho tất cả dữ liệu.

• [SAI] Use S3 Intelligent-Tiering. Activate the Deep Archive Access tier.
  ❌ Sai vì: Intelligent-Tiering đúng hướng (tự động), nhưng activate Deep Archive Access tier (tùy chọn) sẽ di chuyển dữ liệu ít truy cập sang Deep Archive (truy xuất 12 giờ, phí phục hồi cao) → KHÔNG đáp ứng millisecond retrieval. Overhead thấp nhưng không meet yêu cầu tốc độ cho "all data".

• [ĐÚNG] Use S3 Intelligent-Tiering. Use the default access tier.
  ✅ Đúng vì: Như giải thích ở trên – Tự động, millisecond access (FA/IA), tiết kiệm chi phí tối ưu với zero management cho unpredictable patterns. Hoàn hảo cho quy mô lớn! 🚀

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

Câu hỏi tập trung vào lỗ hổng bảo mật trong AWS Glue job 📉, nơi credentials (tài khoản truy cập) để kết nối với Amazon Redshift cluster bị hard-code trực tiếp vào script job – một thực hành không an toàn vì dễ bị lộ thông tin nhạy cảm khi code được chia sẻ, audit hoặc khai thác. 🛡️

Yêu cầu chính: Data engineer phải remediate (khắc phục) bằng cách lưu trữ credentials an toàn và chọn KẾT HỢP 2 BƯỚC (combination of steps). Giải pháp cần tuân thủ best practices bảo mật AWS (Principle of Least Privilege, rotation secrets, encryption at rest/transit). AWS Glue (phiên bản mới nhất 2024-2026) hỗ trợ tích hợp IAM roles và Secrets Manager cho các job ETL, đặc biệt với JDBC connections như Redshift. ✅ Không dùng hard-code theo AWS Well-Architected Framework (Security Pillar).

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

Hai đáp án đúng (chọn TWO):

• Store the credentials in AWS Secrets Manager.
• Grant the AWS Glue job IAM role access to the stored credentials.

Lý do chọn:
🔒 AWS Secrets Manager là dịch vụ chuyên lưu trữ, quản lý và rotate secrets (như DB credentials) với encryption AES-256, VPC endpoints, audit logs qua CloudTrail, và tích hợp trực tiếp với AWS Glue (hỗ trợ retrieve secrets trong job script hoặc connection definitions).
🛠️ IAM role của Glue job (GlueServiceRole) được grant policy secretsmanager:GetSecretValue để job truy cập secrets động mà không hard-code, giảm rủi ro. Kết hợp hai bước này đảm bảo zero-trust access, tuân thủ AWS security best practices cho Glue-Redshift integration (cập nhật Glue 4.0+). Đây là giải pháp chuẩn AWS cho production workloads. 🚀

📋 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 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á dựa trên bảo mật, scalability và AWS recommendations (2026 updates: Glue hỗ trợ Secrets Manager cho dynamic credentials retrieval).

• Store the credentials in the AWS Glue job parameters.
  ❌ SAI. Job parameters (--conf hoặc job arguments) vẫn lưu credentials dưới dạng plain text hoặc semi-encoded, dễ bị expose qua CloudWatch Logs, Glue console hoặc API calls. Không hỗ trợ rotation tự động, vi phạm least privilege. AWS khuyên tránh lưu secrets ở đây vì không encrypt/audit tốt như Secrets Manager.

• Store the credentials in a configuration file that is in an Amazon S3 bucket.
  ❌ SAI. Lưu file config (.json/.properties) vào S3 chỉ encrypt at-rest (SSE-S3/KMS), nhưng file dễ bị download/copy nếu bucket public/misconfigured. Glue job cần code để đọc file → vẫn rủi ro hard-code logic truy cập. Không scale cho rotation, kém an toàn hơn Secrets Manager (thiếu fine-grained access/audit).

• Access the credentials from a configuration file that is in an Amazon S3 bucket by using the AWS Glue job.
  ❌ SAI. Tương tự trên, việc job "access" file S3 yêu cầu IAM policy s3:GetObject, nhưng secrets vẫn plain-text trong file → dễ leak qua logs hoặc unauthorized access. AWS docs cảnh báo tránh pattern này cho sensitive data; ưu tiên Secrets Manager để tránh custom logic và rủi ro.

• Store the credentials in AWS Secrets Manager.
  ✅ ĐÚNG. Secrets Manager lưu secrets encrypted, hỗ trợ automatic rotation (Lambda cho Redshift), versioning và caching. Trong Glue, dùng boto3.client('secretsmanager').get_secret_value() hoặc predefined connections. Hoàn hảo cho Redshift JDBC (glueContext.create_dynamic_frame.from_jdbc_conf với secret ARN). Best practice mới nhất! 🏆

• Grant the AWS Glue job IAM role access to the stored secrets.
  ✅ ĐÚNG. Glue job chạy dưới IAM role (tạo qua console/CLI), attach policy SecretsManagerReadWrite hoặc custom policy với secretsmanager:GetSecretValue + resource ARN. Đảm bảo job retrieve secrets runtime mà không cần credentials tĩnh. Kết hợp với bước trên → giải pháp full-stack an toàn. 🔑

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

• AWS Glue Security & Connections: docs.aws.amazon.com/glue/latest/dg/security.html & Glue with Secrets Manager – Hướng dẫn tích hợp Redshift JDBC secrets.
• Secrets Manager Best Practices: docs.aws.amazon.com/secretsmanager/latest/userguide/best-practices.html – Rotation cho DB credentials.
• AWS Well-Architected Security Pillar: aws.amazon.com/architecture/well-architected/security-pillar – Tránh hard-coding.
• Glue Developer Guide (4.0+): docs.aws.amazon.com/glue/latest/dg/redshift-extract-connect.html – Ví dụ code retrieve secrets.

Giải pháp này giúp đạt compliance PCI-DSS, HIPAA và zero-downtime rotation! Nếu cần code sample, hỏi thêm nhé. 🚀

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

Câu hỏi mô tả tình huống một data engineer sử dụng Amazon Redshift provisioned cluster để chạy các quy trình phân tích dữ liệu tài nguyên cao (resource-intensive analytics) một lần mỗi tháng. Mỗi tháng, họ phải:

• Tạo mới một Redshift provisioned cluster (cụm được cung cấp thủ công).
• Chạy quy trình phân tích.
• Unload (xuất) dữ liệu backup sang Amazon S3 bucket trước khi xóa cluster.
• Xóa cluster sau khi hoàn thành.

Vấn đề: Quy trình này tốn công quản lý hạ tầng thủ công (tạo/xóa cluster hàng tháng). Yêu cầu giải pháp tự động hóa hoàn toàn, không cần quản lý infra thủ công, và có operational overhead thấp nhất (least operational overhead).

📘 Mục tiêu chính: Chuyển sang mô hình serverless hoặc tự động hóa cao để chỉ tập trung vào workload phân tích hàng tháng, tận dụng pay-per-use và auto-scaling, phù hợp với workload sporadic (không liên tục). Kiến thức cập nhật đến 2026: Amazon Redshift Serverless (ra mắt 2022, cải tiến liên tục đến 2026 với hỗ trợ tốt hơn cho analytics workloads lớn) là lựa chọn lý tưởng cho các workload không liên tục như thế này.

✅ Đáp án đúng: Use Amazon Redshift Serverless to automatically process the analytics workload.

Lý do lựa chọn:

• Redshift Serverless là dịch vụ serverless của AWS Redshift (cập nhật mới nhất 2026: hỗ trợ base RPU lên đến hàng nghìn, auto-pause/resume sau 5 phút idle, tích hợp seamless với S3 cho unload data).
• Không cần quản lý infra: Tự động provision, scale compute (RPU - Redshift Processing Units), và quản lý cluster. Chỉ cần tạo workgroup và namespace, chạy query trực tiếp.
• Phù hợp workload hàng tháng: Auto-scale cho resource-intensive queries, pause khi idle để tiết kiệm chi phí (chỉ trả cho thời gian chạy), unload data to S3 dễ dàng qua lệnh UNLOAD.
• Least operational overhead: Zero management cho create/delete cluster, chỉ load data từ S3 và chạy analytics. Hoàn hảo cho sporadic workloads.
• Nguồn tham khảo: AWS Redshift Serverless Documentation và Best Practices for Serverless.

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

Dưới đây là phân tích chi tiết từng lựa chọn. Tôi giữ nguyên văn bản gốc bằng tiếng Anh, nhưng giải thích hoàn toàn bằng tiếng Việt với lý do đúng/sai dựa trên best practices AWS DevOps.

• ❌ [SAI] Use Amazon Step Functions to pause the Redshift cluster when the analytics processes are complete and to resume the cluster to run new processes every month.
  Giải thích sai: Step Functions chỉ orchestrate workflow (pause/resume cluster qua API calls), nhưng vẫn yêu cầu provision cluster thủ công ban đầu và quản lý lifecycle (snapshot, unload data). Overhead cao vì phải setup state machine, handle errors, và cluster vẫn tốn phí khi paused (không serverless). Không giải quyết gốc rễ "không quản lý infra thủ công". Không least overhead so với serverless.

• ✅ [ĐÚNG] Use Amazon Redshift Serverless to automatically process the analytics workload.
  Giải thích đúng: Như phần trên, serverless tự động hoàn toàn: Tạo workgroup một lần, load data từ S3, chạy analytics hàng tháng, auto-scale/pause. Zero infra management, unload to S3 native support. Overhead thấp nhất, chi phí chỉ tính theo query duration (cập nhật 2026: hỗ trợ materialized views, auto-optimization).

• ❌ [SAI] Use the AWS CLI to automatically process the analytics workload.
  Giải thích sai: AWS CLI chỉ là command-line tool để script automation (ví dụ: create-cluster, run queries), nhưng vẫn phải viết script thủ công cho toàn bộ lifecycle (create/delete/unload). Overhead cao: maintain scripts, handle failures, scheduling (cần Lambda/EventBridge). Không thay đổi việc quản lý provisioned cluster, chỉ automate manual steps – không least overhead.

• ❌ [SAI] Use AWS CloudFormation templates to automatically process the analytics workload.
  Giải thích sai: CloudFormation là IaC (Infrastructure as Code) để deploy stack provisioned cluster tự động, nhưng vẫn provision thủ công compute/storage, yêu cầu template phức tạp cho unload/S3 integration. Overhead cao: maintain templates, stack updates, deletion scheduling. Không serverless, vẫn tốn phí idle và quản lý lifecycle – không đáp ứng "không quản lý infra thủ công" một cách tối ưu.

🛠️ Khuyến nghị DevOps Professional

• Implement nhanh: Tạo Redshift Serverless namespace/workgroup qua Console/AWS CLI/Terraform, dùng IAM roles cho S3 access.
• Tiết kiệm chi phí: Kết hợp với S3 Intelligent-Tiering cho backups.
• Monitoring: CloudWatch + Redshift Advisor cho auto-tuning.
• Test case: Workload hàng tháng sẽ chạy mượt mà, scale lên hàng TB data mà không lo infra! 🚀

Nguồn bổ sung: AWS Well-Architected Framework - Operational Excellence và Redshift Serverless GA Announcement.

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

Câu hỏi mô tả một tình huống thực tế trên AWS: Một công ty nhận file dữ liệu khách hàng định dạng .xls (khoảng 2 GB) hàng ngày và lưu trữ trên Amazon S3. Data engineer cần ghép (concatenate) cột chứa first names và last names của khách hàng, sau đó đếm số lượng khách hàng distinct (khách hàng duy nhất, tránh trùng lặp).
Yêu cầu chính là 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 dịch vụ serverless, low-code/no-code, dễ thiết lập, không cần viết code phức tạp hay quản lý cluster.
📘 Bối cảnh AWS (cập nhật đến 2026): AWS Glue DataBrew là dịch vụ chuẩn bị dữ liệu trực quan (visual data preparation), hỗ trợ trực tiếp file Excel (.xls/.xlsx) từ S3, với các hàm aggregate như COUNT_DISTINCT, phù hợp cho workload hàng ngày nhỏ đến trung bình mà không cần ETL code.

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

Đáp án đúng: Use AWS Glue DataBrew to create a recipe that uses the COUNT_DISTINCT aggregate function to calculate the number of distinct customers.

Lý do:
🛠️ Glue DataBrew là dịch vụ no-code/low-code (giao diện kéo-thả), được thiết kế chuyên cho data preparation như ghép cột (concatenate), clean data và tính aggregate (COUNT_DISTINCT) trên file từ S3.

• Không cần viết code Spark/SQL, không setup crawler/cluster.
• Hỗ trợ file .xls trực tiếp (từ phiên bản 2023+), xử lý file 2GB dễ dàng với serverless scaling.
• Least operational effort: Tạo "recipe" visual, chạy job hàng ngày tự động qua schedules/EventBridge, export kết quả ra S3/Athena.
• Tiết kiệm chi phí và thời gian so với các dịch vụ code-based.
  📘 Nguồn tham khảo: AWS Glue DataBrew Documentation - Aggregations (cập nhật 2025), hỗ trợ COUNT_DISTINCT trên concatenated columns.

📋 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, với nội dung gốc giữ nguyên bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên operational effort (setup, code, maintenance) và tính phù hợp.

• Create and run an Apache Spark job in an AWS Glue notebook. Configure the job to read the S3 file and calculate the number of distinct customers.
  ❌ Sai: Yêu cầu viết code Spark (Scala/PySpark) trong Glue Studio Notebook để đọc .xls (cần custom parser như Pandas/Spark Excel), ghép cột và dùng countDistinct(). Effort cao: Phát triển code, debug, schedule job. Phù hợp ETL lớn nhưng không least effort cho task đơn giản hàng ngày.

• Create an AWS Glue crawler to create an AWS Glue Data Catalog of the S3 file. Run SQL queries from Amazon Athena to calculate the number of distinct customers.
  ❌ Sai: Cần setup Glue Crawler để infer schema từ .xls (hỗ trợ nhưng không hoàn hảo với Excel binary), catalog hóa, rồi viết SQL query trên Athena (ví dụ: SELECT COUNT(DISTINCT first||last) FROM table). Effort trung bình: Quản lý crawler chạy hàng ngày, schema drift với file .xls, query chi phí theo scan data (2GB/ngày). Không visual, vẫn cần SQL knowledge.

• Create and run an Apache Spark job in Amazon EMR Serverless to calculate the number of distinct customers.
  ❌ Sai: Sử dụng EMR Serverless (Spark engine) yêu cầu viết full Spark job (submit JAR/script), config driver/executor, xử lý .xls (cần library). Effort cao nhất: Quản lý job submission, monitoring, scaling dù serverless. Phù hợp big data nhưng overkill cho 2GB daily, không least effort.

• Use AWS Glue DataBrew to create a recipe that uses the COUNT_DISTINCT aggregate function to calculate the number of distinct customers.
  ✅ Đúng: Như đã giải thích ở trên. Visual recipe: Kéo-thả để concatenate columns (Unpivot/Combine), apply COUNT_DISTINCT, preview real-time. Chạy job serverless, schedule tự động. Least effort hoàn toàn, không code, hỗ trợ xuất kết quả trực tiếp.
  🛠️ Ưu điểm nổi bật: Xử lý 2GB nhanh (parallel sampling), tích hợp S3/Glue Catalog, chi phí thấp (~$0.01/10k rows transformed, cập nhật 2026 pricing).

Kết luận tổng quát 🎯: Glue DataBrew tối ưu cho data analysts/engineers cần quick insights mà không dev ops nặng, phù hợp DOP-C02 blueprint về serverless data pipelines. Nếu scale lớn hơn, có thể kết hợp với Glue ETL.

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

📖 Nội dung câu hỏi được giải thích rõ ràng:
Câu hỏi mô tả một công ty y tế sử dụng Amazon Kinesis Data Streams để thu thập dữ liệu sức khỏe thời gian thực (real-time) từ các thiết bị đeo (wearable devices), thiết bị bệnh viện (hospital equipment) và hồ sơ bệnh nhân (patient records). Một data engineer cần tìm giải pháp xử lý dữ liệu streaming này, lưu trữ vào Amazon Redshift Serverless warehouse, đồng thời hỗ trợ near real-time analytics cho dữ liệu streaming hiện tại lẫn dữ liệu của ngày hôm trước. Giải pháp phải có LEAST operational overhead (chi phí vận hành thấp nhất, nghĩa là ít quản lý thủ công, tự động hóa cao, không cần ETL phức tạp).
🛠️ Yêu cầu chính: Xử lý streaming từ Kinesis → Redshift Serverless, low-latency analytics (gần real-time), kết hợp dữ liệu cũ (previous day's data), ưu tiên đơn giản hóa vận hành theo best practices AWS mới nhất (cập nhật đến 2026).

✅ Đáp án đúng: Use the streaming ingestion feature of Amazon Redshift.
Lý do lựa chọn: Tính năng streaming ingestion của Redshift (ra mắt từ 2022 và được cập nhật liên tục đến 2026) cho phép ingest dữ liệu trực tiếp từ Kinesis Data Streams vào materialized views của Redshift Serverless với độ trễ thấp (seconds), hỗ trợ near real-time analytics. Nó tự động xử lý buffering, partitioning và merging dữ liệu mới với dữ liệu lịch sử (như previous day's data) mà không cần ETL trung gian, Lambda hay dịch vụ khác. Điều này mang lại least operational overhead vì hoàn toàn serverless, managed bởi AWS, không cần quản lý cluster hay pipeline thủ công. Hoàn hảo cho Redshift Serverless!

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

• ✅ [ĐÚNG] Use the streaming ingestion feature of Amazon Redshift.
  🟢 Phương án này đúng vì trực tiếp ingest từ Kinesis vào Redshift materialized views với latency thấp (1-2 giây), tự động merge dữ liệu streaming với dữ liệu cũ. Hỗ trợ Redshift Serverless, zero-management, phù hợp exactly với yêu cầu near real-time và least overhead. Không cần code hay infra thêm!

• ❌ [SAI] Load data into Amazon Kinesis Data Firehose. Load the data into Amazon Redshift.
  🔴 Sai vì Kinesis Data Firehose (KDF) yêu cầu cấu hình delivery stream, buffering (1-15 phút), transformation (optional Lambda), rồi mới load vào Redshift qua S3 staging. Overhead cao hơn do quản lý Firehose config, monitoring error handling, retry logic – không phải least overhead và latency cao hơn streaming ingestion.

• ❌ [SAI] Load the data into Amazon S3. Use the COPY command to load the data into Amazon Redshift.
  🔴 Sai vì cách này là batch processing cổ điển: Từ Kinesis → S3 (qua producer hoặc Firehose), rồi schedule COPY command thủ công/lambda vào Redshift. Không hỗ trợ near real-time (chỉ hourly/daily), cần quản lý partitioning S3, scheduling jobs → operational overhead lớn, không merge tự động dữ liệu cũ/mới.

• ❌ [SAI] Use the Amazon Aurora zero-ETL integration with Amazon Redshift.
  🔴 Sai vì zero-ETL integration của Aurora (cập nhật 2023-2026) chỉ dành cho Aurora PostgreSQL/MySQL → Redshift (incremental data replication), không hỗ trợ ingest từ Kinesis Data Streams. Đây là mismatch nguồn dữ liệu, không áp dụng được và vẫn cần setup Aurora cluster → overhead không thấp.

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

• Amazon Redshift Streaming Ingestion – Chi tiết tính năng chính thức.
• Redshift Serverless Documentation – Xác nhận hỗ trợ streaming.
• AWS re:Invent 2023/2024 sessions về Redshift RAG & Streaming (YouTube AWS Events).
  Giải pháp này tuân thủ AWS Well-Architected Framework: Operational Excellence pillar! 🚀

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

Câu hỏi mô tả tình huống một data engineer đang cố gắng truy cập Amazon QuickSight dashboard, dashboard này dựa trên các truy vấn Amazon Athena thực hiện trên dữ liệu lưu trữ trong Amazon S3 bucket. Khi kết nối vào dashboard, người dùng gặp lỗi "insufficient permissions" (quyền truy cập không đủ).
📌 Vấn đề cốt lõi: Lỗi này liên quan đến quyền IAM (Identity and Access Management) giữa QuickSight, Athena và S3. Athena hoạt động như một engine query serverless, quét dữ liệu trực tiếp từ S3 mà không di chuyển dữ liệu. QuickSight sử dụng Athena làm nguồn dữ liệu (datasource), nên QuickSight cần quyền gián tiếp truy cập S3 qua Athena. Lỗi xảy ra ngay khi kết nối dashboard, chỉ ra vấn đề quyền ở mức service-level, không phải dữ liệu catalog hay kết nối cơ bản.
🛠️ Bối cảnh AWS cập nhật 2026: Theo tài liệu AWS mới nhất (QuickSight phiên bản hỗ trợ Athena V3 với Lake Formation integration), QuickSight yêu cầu service role hoặc namespace delegation để truy cập Athena workgroup, S3 bucket (data/input/output), và KMS nếu dữ liệu mã hóa. Lỗi permissions thường do thiếu policy s3:GetObject, s3:ListBucket trên bucket, hoặc kms:Decrypt nếu dùng SSE-KMS/Server-side encryption.

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

QuickSight does not have access to the S3 bucket.
QuickSight does not have access to decrypt S3 data.

Lý do lựa chọn:
🧩 Đây là hai yếu tố trực tiếp gây lỗi insufficient permissions khi QuickSight cố gắng thực thi truy vấn Athena trên S3. Athena cần quyền đọc dữ liệu từ S3 bucket (qua IAM policy của QuickSight service role hoặc Athena query execution role). Nếu dữ liệu mã hóa (SSE-S3, SSE-KMS hoặc CSE-KMS), QuickSight/Athena cần thêm quyền giải mã. Lỗi xuất hiện ngay khi connect dashboard vì QuickSight preview dữ liệu hoặc refresh dataset. Các yếu tố khác không khớp với lỗi permissions cụ thể này.
📘 Tài liệu tham khảo:

• AWS QuickSight: Connecting to Athena
• IAM Permissions for QuickSight with Athena/S3
• Athena Permissions Best Practices (2024 update)

🔍 Phân tí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 bằng tiếng Anh, đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm giải thích bằng tiếng Việt:

• ❌ There is no connection between QuickSight and Athena.
  Phương án này sai vì nếu không có kết nối giữa QuickSight và Athena, lỗi sẽ là "datasource not found" hoặc "connection failed", không phải insufficient permissions. QuickSight yêu cầu tạo Athena datasource trước (với workgroup), nhưng lỗi permissions xảy ra sau khi kết nối tồn tại, khi thực thi query trên S3.

• ❌ The Athena tables are not cataloged.
  Phương án này sai vì thiếu catalog (Glue Data Catalog hoặc Lake Formation) gây lỗi "table not found" hoặc "invalid schema" khi query Athena, chứ không phải permissions ngay khi connect QuickSight dashboard. Permissions là vấn đề IAM, không liên quan trực tiếp đến catalog metadata.

• ✅ QuickSight does not have access to the S3 bucket.
  Phương án này đúng vì QuickSight (qua Athena) cần IAM policy s3:GetObject, s3:ListBucket, s3:GetBucketLocation trên S3 bucket chứa dữ liệu input và query results (output location). Thiếu quyền này dẫn đến lỗi permissions khi Athena scan S3, và QuickSight báo lỗi khi load dashboard.

• ✅ QuickSight does not have access to decrypt S3 data.
  Phương án này đúng vì nếu dữ liệu S3 dùng encryption (SSE-KMS, CSE-KMS), QuickSight/Athena cần policy kms:Decrypt, kms:GenerateDataKey trên KMS key. Lỗi "AccessDenied" hoặc insufficient permissions xuất hiện cụ thể khi decrypt, phổ biến trong môi trường enterprise (cập nhật AWS 2025 với hybrid KMS support).

• ❌ There is no IAM role assigned to QuickSight.
  Phương án này sai vì QuickSight luôn có IAM service role mặc định khi tạo account/namespace (QuickSightServiceRole). Lỗi permissions xảy ra do policy thiếu trong role đó (ví dụ: thiếu Athena/S3 actions), chứ không phải role không tồn tại. Nếu role missing hoàn toàn, QuickSight không hoạt động từ đầu.

🛡️ Lời khuyên thực hành: Để khắc phục, attach IAM policy đầy đủ vào QuickSight service role (sử dụng AWS console > QuickSight > Manage QuickSight > Security & permissions), và test với Athena query riêng lẻ trước. Sử dụng AWS IAM Access Analyzer để debug permissions!

🧩 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 lưu trữ dữ liệu ở định dạng JSON và CSV trong Amazon S3 bucket. Họ còn có Amazon RDS for Microsoft SQL Server (cơ sở dữ liệu quan hệ), Amazon DynamoDB tables (provisioned capacity mode - NoSQL key-value), và Amazon Redshift cluster (data warehouse). Nhiệm vụ của đội ngũ data engineering là xây dựng giải pháp cho data scientists có thể query tất cả các nguồn dữ liệu này bằng cú pháp tương tự SQL, với yêu cầu quan trọng nhất là LEAST operational overhead (ít chi phí vận hành nhất, nghĩa là ít setup, maintenance, ETL jobs, và tài nguyên nhất).

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

• Hỗ trợ query đa nguồn (S3, RDS SQL Server, DynamoDB, Redshift) mà không cần di chuyển dữ liệu.
• Syntax giống SQL (SQL-like).
• Ưu tiên giải pháp serverless, tự động hóa cao, không cần transform dữ liệu thủ công để giảm overhead.

📘 Kiến thức AWS cập nhật 2026: Giải pháp lý tưởng sử dụng AWS Glue Data Catalog làm unified metadata catalog, kết hợp Amazon Athena với federated queries (ra mắt từ 2021, hỗ trợ đầy đủ RDS SQL Server, DynamoDB, Redshift, và query JSON trực tiếp qua PartiQL). Athena là serverless query service, không cần quản lý cluster, chi phí theo scan dữ liệu.

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

Đáp án đúng: Lựa chọn đầu tiên (Use AWS Glue to crawl the data sources. Store metadata in the AWS Glue Data Catalog. Use Amazon Athena to query the data. Use SQL for structured data sources. Use PartiQL for data that is stored in JSON format.)

Lý do 🏆:

• Glue crawler tự động crawl và lưu metadata vào Glue Data Catalog (unified catalog cho tất cả nguồn: S3, RDS, DynamoDB, Redshift) với overhead thấp (serverless, chạy on-demand).
• Amazon Athena query trực tiếp trên Catalog bằng SQL cho dữ liệu structured (CSV, RDS SQL Server, DynamoDB, Redshift), và PartiQL (SQL-like cho JSON semi-structured) mà không cần transform dữ liệu → least overhead.
• Athena hỗ trợ federated queries (query cross-source mà không copy data), serverless 100%, scale tự động. Không cần ETL jobs hay quản lý cluster.
• Hoàn hảo cho multi-source query với syntax SQL/PartiQL.

Nguồn tham khảo 📚:

• AWS Athena Federated Query Documentation (hỗ trợ RDS SQL Server, DynamoDB, Redshift).
• AWS Glue Data Catalog.
• PartiQL in Athena.

🔍 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 bằng tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng, phù hợp least overhead) hoặc ❌ (sai, overhead cao hơn).

• Use AWS Glue to crawl the data sources. Store metadata in the AWS Glue Data Catalog. Use Amazon Athena to query the data. Use SQL for structured data sources. Use PartiQL for data that is stored in JSON format.
  ✅ Đúng và tối ưu nhất. Glue Catalog làm metadata layer thống nhất. Athena federated query tất cả nguồn (S3 JSON/CSV qua PartiQL/SQL, RDS, DynamoDB, Redshift) serverless, không ETL/transform, syntax SQL-like chuẩn. Overhead thấp nhất vì không quản lý job/transform/cluster.

• Use AWS Glue to crawl the data sources. Store metadata in the AWS Glue Data Catalog. Use Redshift Spectrum to query the data. Use SQL for structured data sources. Use PartiQL for data that is stored in JSON format.
  ❌ Sai. Redshift Spectrum chỉ query external tables trên S3 (JSON/CSV), không hỗ trợ federated query trực tiếp đến RDS/DynamoDB dễ dàng (cần custom Lambda hoặc ETL). Phải dùng Redshift cluster hiện có → overhead cao (quản lý cluster, scale provisioned), không serverless như Athena.

• Use AWS Glue to crawl the data sources. Store metadata in the AWS Glue Data Catalog. Use AWS Glue jobs to transform data that is in JSON format to Apache Parquet or .csv format. Store the transformed data in an S3 bucket. Use Amazon Athena to query the original and transformed data from the S3 bucket.
  ❌ Sai. Yêu cầu Glue jobs ETL để transform JSON sang Parquet/CSV → overhead cao (viết/maintain jobs, schedule, monitor, lưu trữ thêm data). Athena query được nhưng chỉ S3 (không trực tiếp RDS/DynamoDB/Redshift mà không federated đầy đủ), mất tính least overhead vì thêm bước transform không cần thiết.

• Use AWS Lake Formation to create a data lake. Use Lake Formation jobs to transform the data from all data sources to Apache Parquet format. Store the transformed data in an S3 bucket. Use Amazon Athena or Redshift Spectrum to query the data.
  ❌ Sai. Lake Formation tốt cho data lake governance, nhưng yêu cầu jobs transform tất cả nguồn sang Parquet → overhead rất cao (setup Lake Formation permissions/catalog, ETL jobs cross-source, di chuyển data từ RDS/DynamoDB/Redshift). Athena/Spectrum query sau transform vẫn cần quản lý pipeline, không serverless thuần như Athena federated.

Kết luận 🚀: Giải pháp Athena + Glue Catalog là best practice cho unified SQL querying đa nguồn với zero ETL overhead (theo AWS Well-Architected Framework - Data Analytics Lens 2026).