Skip to content

Skill 1.1.1: Extract data from data sources

Question 1 - Selecting Storage for Distributed Training

A financial services company is preparing a large image dataset for a computer vision model that detects fraudulent documents. The dataset totals 40 TB and will be used in a distributed SageMaker training job running across 20 ml.g5.12xlarge instances. The training script expects the images to be available as files on a shared POSIX-compliant mount path that all instances can access simultaneously. The training job completes in 4 hours, after which the dataset must be archived to S3 and the storage released.

Which storage service should the ML engineer select for this training job?

A) Amazon EBS volumes attached to each instance with RAID 0 configuration
B) Amazon EFS with Bursting Throughput mode
C) Amazon FSx for Lustre linked to the S3 bucket containing the images
D) Amazon S3 accessed directly through the SageMaker training data channel
E) Amazon DynamoDB with the images stored as binary items

Click to reveal Answer & Explanation

Correct Answer: C

Correct Options Analysis

  • C is Correct: Amazon FSx for Lustre is purpose-built for high-performance distributed workloads. It provides a POSIX-compliant shared file system that can be mounted by all SageMaker training instances simultaneously, and its S3 synchronization capability means the 40 TB dataset can be lazily loaded from S3 on first access, eliminating a separate copy step.

Distractor Analysis

  • A is Incorrect: EBS volumes cannot be simultaneously attached to multiple instances in read-write mode (except for io2 Multi-Attach, which still has limitations and requires additional configuration). RAID 0 across instances does not create a shared namespace.
  • B is Incorrect: EFS Bursting Throughput mode is limited by burst credits and would not sustain the high throughput needed across 20 instances simultaneously reading large image files. FSx for Lustre is designed for exactly this high-performance scenario.
  • D is Incorrect: While SageMaker training data channels can reference S3 directly, the training script in this scenario expects file paths on a POSIX-compliant shared mount, not S3 object paths. S3 does not present a POSIX file system.
  • E is Incorrect: DynamoDB has a 400 KB item size limit, making it unsuitable for storing large image files. It is also not a file system and cannot be mounted by training instances.

Key Takeaway: FSx for Lustre is the optimal choice when distributed training jobs require POSIX-compliant shared storage with high throughput; EFS is better suited for lower-throughput shared workloads across many instances.

Question 2 - Extracting Data from RDS with Vector Search Integration

A healthcare analytics company runs a patient similarity application on an Amazon RDS for PostgreSQL database that stores structured patient records, including diagnosis codes, lab results, and demographic information. The ML team has generated vector embeddings for each patient record using a SageMaker model and now needs to enable cosine similarity search over these embeddings to identify similar patient cohorts.

The compliance team requires that all patient data, including embeddings, remain in the existing PostgreSQL database with no additional data movement or duplication.

Which approach should the ML engineer take? (Select ONE)

A) Export all patient records from RDS to an Amazon OpenSearch Service domain and perform k-NN vector search there
B) Enable the pgvector extension on the RDS for PostgreSQL instance and create a vector column with an index
C) Store the embeddings in Amazon S3 as JSON files and use Athena to compute cosine similarity
D) Migrate the patient records to DynamoDB and use DynamoDB's built-in vector search capability
E) Create a SageMaker Feature Store online store and perform similarity search through the Feature Store API

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: The pgvector extension is native to RDS for PostgreSQL and adds vector storage with similarity search operators (cosine distance, inner product, L2 distance). It enables embeddings to sit alongside the relational records they describe, with zero data movement—exactly matching the compliance constraint.

Distractor Analysis

  • A is Incorrect: Exporting patient data to OpenSearch Service would create a second copy of data, violating the compliance requirement of "no additional data movement or duplication." OpenSearch is also a separate service to manage.
  • C is Incorrect: Athena does not natively support vector similarity search. Computing cosine similarity across S3 objects would require custom SQL UDFs and would be extremely inefficient for near-real-time similarity queries.
  • D is Incorrect: DynamoDB does not have native built-in vector similarity search functionality. It is a key-value/document store optimized for point lookups and range queries on sort keys.
  • E is Incorrect: SageMaker Feature Store is not designed for vector similarity search. It provides online/offline storage for feature values keyed by record identifier, not nearest-neighbor queries over embedding space.

Key Takeaway: pgvector on Amazon RDS for PostgreSQL provides vector similarity search where your relational data already lives, avoiding data movement, dual-write complexity, and compliance overhead.

Question 3 - Merging Data from Multiple Sources with Conflict Resolution

A retail e-commerce company ingests customer interaction data from two independent source systems: an order management platform (source A) and a marketing campaign platform (source B). Both systems identify customers by key, but the keys differ (order_id vs. customer_id) and several overlapping attributes exist, including email, loyalty_tier, and last_purchase_date.

The ML team must build a unified customer profile dataset for a churn prediction model. Records exist in both systems for the same customer, but the loyalty_tier values sometimes conflict. The data engineering team needs to merge these sources using a serverless approach that is also queryable by downstream analytics tools via the AWS Glue Data Catalog.

Which TWO approaches should the engineer implement? (Select TWO)

A) Define an AWS Glue Studio job that performs a join between source A and source B using a mapping table, with a transformation that applies a resolved conflict rule (e.g., source A wins for loyalty_tier)
B) Use AWS Step Functions to orchestrate both source systems, manually merging records in a custom Lambda function and writing output to a JSON file without cataloging
C) Register the merged output in the AWS Glue Data Catalog using a crawler so Athena can query the dataset directly
D) Use Amazon Kinesis Data Streams to buffer records from both systems and merge them in real time, ignoring the key mismatch
E) Store both raw sources separately in S3 and leave conflict resolution to be computed at inference time by the SageMaker model

Click to reveal Answer & Explanation

Correct Answers: A and C

Correct Options Analysis

  • A is Correct: AWS Glue Studio provides a serverless, visual ETL environment built on Apache Spark. It can perform a join across source systems (using a mapping table to reconcile key differences) and apply deterministic conflict resolution rules—exactly what is needed when fields disagree.
  • C is Correct: Registering the merged output in the Glue Data Catalog via a crawler makes the unified dataset discoverable and queryable by Athena, enabling downstream analytics without manual schema management.

Distractor Analysis

  • B is Incorrect: While Step Functions and Lambda are serverless, custom code to merge records is unnecessary operational overhead compared to Glue's native ETL capabilities. Also, writing output without cataloging means downstream tools cannot query the dataset efficiently via Athena or Redshift Spectrum.
  • D is Incorrect: Kinesis Data Streams is for real-time ingestion, not for batch reconciliation of key mismatches or conflict resolution. Ignoring key mismatches would produce an incorrect, incoherent dataset. Real-time merging also doesn't address the asynchronous, batch nature of the two source systems.
  • E is Incorrect: Leaving conflict resolution to inference time is an anti-pattern. Training data must have deterministic, documented resolution rules applied during dataset preparation. A model cannot reliably resolve which loyalty tier is "true" at inference time.

Key Takeaway: Use AWS Glue to handle source merges and conflict resolution serverlessly, and always register the output in the Glue Data Catalog so downstream analytics can query it without re-discovering the schema.

Question 4 - Choosing the Correct File Format for Analytics

A data platform team at a telecommunications company maintains a raw data lake in Amazon S3 containing call detail records (CDRs) in JSON format. They need to create a curated layer for an ML model that predicts customer churn. The analytics queries that run against this curated layer consistently select only 3–5 columns out of 120 available columns, but scan millions of rows in each query.

The team needs to optimize both query performance and scan cost in Amazon Athena while maintaining a serverless pipeline.

Which action should the data engineer take? (Select ONE)

A) Keep the data in JSON format but enable GZIP compression to reduce scan size
B) Convert the curated layer into Apache Parquet format with columnar compression using AWS Glue
C) Store the curated data in DynamoDB and use a sparse index to reduce columns scanned
D) Store the curated data as CSV files to reduce parsing overhead
E) Use Amazon EFS as the queryable store to improve file read throughput

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Apache Parquet is a columnar storage format that enables column pruning (projection pushdown). Athena queries that read only 3–5 columns will scan only the storage blocks containing those columns, dramatically reducing the amount of data scanned, query time, and cost. AWS Glue can perform this conversion serverlessly.

Distractor Analysis

  • A is Incorrect: GZIP compression on JSON files reduces bytes transferred, but Athena still must parse every row and every field in the selected JSON documents because JSON is row-oriented. Column pruning does not apply, so query performance and scanned data volume remain high compared to Parquet.
  • C is Incorrect: DynamoDB is not designed for analytical queries that scan millions of rows on a fraction of columns. Its pricing also does not align well with large-scale OLAP scans, and it lacks native columnar query optimization.
  • D is Incorrect: CSV is also a row-oriented format. Athena will scan all columns in every row, resulting in the same high scan volume. CSV parsing is also error-prone with mixed data types (no typed schema).
  • E is Incorrect: EFS is a file system, not a queryable analytical store. Even if data were placed there, Athena cannot query EFS directly (only S3 via external locations are supported natively without additional connectors).

Key Takeaway: For analytics and ML feature engineering workloads that read a few columns across many rows, use a columnar format like Parquet or ORC to enable column pruning and reduce Athena scan costs.

Question 5 - Streaming Ingestion with Downstream Bottleneck

An IoT company ingests telemetry data from 50,000 devices into Amazon Kinesis Data Streams. A Kinesis Data Analytics (Apache Flink) application consumes the stream and writes aggregated results into an Amazon RDS for PostgreSQL database. The aggregate table has a write throughput limit of 500 write IOPS.

The operations team notices that the stream's iterator age (consumer lag) increases continuously throughout the day. The incoming stream rate is well below the stream's provisioned shard throughput. The Flink application is scaled to 8 KPUs.

What is the MOST LIKELY root cause and the MOST EFFECTIVE action? (Select ONE)

A) Scale the Kinesis Data Streams shards to increase stream capacity
B) Increase the Flink application KPUs to 32 to consume records faster
C) The RDS PostgreSQL database is the bottleneck; optimize writes or increase database throughput
D) Reduce the number of IoT devices sending data to the stream
E) Replace Kinesis Data Streams with Amazon MSK to improve consumer throughput

Click to reveal Answer & Explanation

Correct Answer: C

Correct Options Analysis

  • C is Correct: The incoming rate is below the stream's provisioned throughput, and the Flink application has 8 KPUs. The increasing iterator age indicates consumers are not keeping up, but since the stream and consumer compute are not the limiting factor, the bottleneck is the downstream write target (RDS PostgreSQL) hitting its 500 IOPS limit. The Flink application is likely blocked on slow writes to RDS, which causes backpressure and prevents consuming records faster.

Distractor Analysis

  • A is Incorrect: Shard scaling addresses stream capacity, but the scenario already states the incoming rate is well below provisioned throughput. Increasing shards would not resolve a downstream database bottleneck.
  • B is Incorrect: Adding KPUs to the Flink application when the downstream writes are already throttled would simply create more tasks contending for the same RDS write bottleneck. It would not clear the backlog and would waste compute resources.
  • D is Incorrect: Reducing device sends is a workaround, not a production solution. The problem is not the producer rate but the pipeline's ability to process and write data downstream.
  • E is Incorrect: Migrating to MSK does not address the write bottleneck in RDS. A different stream transport layer will still hit the same database write limits.

Key Takeaway: In streaming pipelines, always identify the true bottleneck—if the stream and consumer compute have sufficient capacity, look downstream (e.g., database, index, data lake) before scaling consumer resources.

Question 6 - Extracting Data from EBS for ML Training

A genomics research facility processes individual patient genome sequences using a single EC2 instance with a dedicated Amazon EBS gp3 volume containing 2 TB of raw sequencing data. The ML team plans to run a SageMaker training job to train a variant classification model.

The training job requires reading the entire 2 TB dataset from a file system path that is accessible from the training container. The team wants the least operational overhead and no data duplication.

Which action should the engineer take? (Select ONE)

A) Attach the EBS volume to the SageMaker training instance and read the data from the mounted volume path
B) Copy the data from EBS to Amazon EFS and mount EFS on the SageMaker training instance
C) Upload the data from EBS to Amazon S3 and configure the SageMaker training job to ingest from S3
D) Mount the EBS volume as a shared file system across all SageMaker training instances using EBS Multi-Attach
E) Export the EBS data into DynamoDB and query the records from the training container

Click to reveal Answer & Explanation

Correct Answer: C

Correct Options Analysis

  • C is Correct: SageMaker training jobs do not directly access EBS volumes attached to other EC2 instances. The standard, least operational overhead path is to upload data to Amazon S3 and use SageMaker's built-in S3 data channel to stream the data into the training instance's local storage. This avoids any EBS attachment complexities and aligns with SageMaker's native architecture.

Distractor Analysis

  • A is Incorrect: EBS volumes cannot be attached to SageMaker training instances directly. SageMaker abstracts away the underlying compute infrastructure, and you cannot control EC2-level volume attachments. This option is not technically feasible.
  • B is Incorrect: While EFS can be mounted on SageMaker training jobs, copying data from EBS to EFS introduces unnecessary data duplication and additional cost. Direct upload to S3 from EBS is simpler and uses SageMaker's native data channel.
  • D is Incorrect: EBS Multi-Attach is limited to io2 volumes and specific instance/Nitro configurations, and SageMaker training instances do not support custom EBS attachments. This approach is not feasible for SageMaker managed training.
  • E is Incorrect: DynamoDB is a key-value store, not suitable for 2 TB of raw sequencing data. It also has item size limits and would not represent the data as a file system.

Key Takeaway: For SageMaker training, always land data in S3 first. S3 is the native ingestion source for SageMaker data channels, and direct EBS/EFS access is limited to scenarios where the training script requires POSIX mounts.

Question 7 - Extracting Data from DynamoDB for Batch Training

A ride-sharing platform stores real-time trip metadata in Amazon DynamoDB with on-demand capacity. Each trip record is keyed by trip_id and contains attributes including driver_id, rider_id, pickup_geo, dropoff_geo, fare_amount, and surge_multiplier.

The ML team needs to build a training dataset containing all trips from the last 90 days to train a demand forecasting model. The dataset will be written to Amazon S3 as Parquet for use in SageMaker Training.

Which approach is MOST efficient and least operationally complex? (Select ONE)

A) Use Amazon DynamoDB Streams to send every trip event to a Kinesis Data Firehose delivery stream and write directly to S3 as Parquet
B) Run an AWS Glue job (Apache Spark) that reads from DynamoDB via the ETL connector, applies timestamp filtering for the last 90 days, and writes Parquet to S3
C) Create a DynamoDB global table and replicate to an EC2-based HDFS cluster, then export from HDFS to S3
D) Scan the entire DynamoDB table in a Lambda function, filter trips in code, and write to S3 using boto3
E) Enable DynamoDB TTL on trip records older than 90 days and then export remaining items to S3

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: AWS Glue provides a serverless, Spark-based ETL connector for DynamoDB. It parallelizes the read across Spark executors using segments, can apply timestamp filtering, and writes directly to S3 in Parquet. This is the most efficient, scalable, and operationally low-overhead approach for batch extraction from DynamoDB.

Distractor Analysis

  • A is Incorrect: DynamoDB Streams is designed for real-time change data capture, not historical batch extraction. Streams only capture item-level changes after they are enabled, so it would not provide access to the last 90 days of already-existing data. Firehose also only handles records going forward, not retroactively.
  • C is Incorrect: Creating a global table and replicating to HDFS on EC2 is overly complex and expensive. This introduces multi-region replication (unnecessary for the use case) and manual HDFS cluster management. DynamoDB global tables do not natively export to HDFS.
  • D is Incorrect: Lambda has a 15-minute timeout and limited memory/parallelism. Scanning an entire DynamoDB table with millions of items in a Lambda function is inefficient and impractical. For large-scale scans, Glue or DynamoDB export to S3 is preferred.
  • E is Incorrect: TTL deletes data, which is actively destructive. You would lose the last 90 days of data needed for training. TTL is for data retention policies, not for building historical training datasets.

Key Takeaway: For bulk extraction from DynamoDB into S3, use AWS Glue with the DynamoDB ETL connector—it provides serverless parallel scanning and native Parquet output. Avoid using Streams for historical data and never use TTL as an export mechanism.

Question 8 - Vector Store Selection for RAG Application

A legal technology company is building a retrieval-augmented generation (RAG) application on AWS. The application will use Amazon Bedrock with the Titan Embeddings model to embed legal documents and store them for semantic search. The system must support up to 10 million document embeddings and serve queries with less than 50 ms latency at the 99th percentile. The team has expertise in Elasticsearch and wants a managed service.

Which storage service should the ML engineer choose? (Select ONE)

A) Amazon S3 with the S3 Metadata feature for vector indexing
B) Amazon OpenSearch Service (managed) with k-NN vector search
C) Amazon RDS for PostgreSQL with pgvector
D) Amazon DynamoDB with a global secondary index for similarity search
E) Amazon FSx for Windows File Server with a vector index

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Amazon OpenSearch Service is a managed Elasticsearch-compatible search and analytics service with native k-NN vector search capability. It can handle millions of embeddings, provides sub-50 ms query latency when properly sized, and the team's Elasticsearch expertise maps directly to it. It also integrates directly with Bedrock Knowledge Bases.

Distractor Analysis

  • A is Incorrect: Amazon S3 vector buckets (via S3 Metadata or Bedrock Knowledge Bases) are designed for large vector sets that tolerate less frequent querying and higher latency. S3 is object storage, not a low-latency query engine, and does not provide sub-50 ms similarity search.
  • C is Incorrect: While pgvector supports vector similarity search in PostgreSQL, at 10 million embeddings with strict sub-50 ms latency requirements, a dedicated search service like OpenSearch (which uses HNSW algorithms natively) is better suited. pgvector may require extensive tuning and may not meet the latency SLA at this scale.
  • D is Incorrect: DynamoDB does not natively support vector similarity search. You would need to build and maintain custom vector indexing and approximate nearest-neighbor logic, which is operationally complex and not aligned with the team's Elasticsearch skills.
  • E is Incorrect: FSx for Windows File Server is a managed Windows file system, not a vector database or search engine. It cannot perform similarity search over embeddings.

Key Takeaway: For production RAG applications requiring low-latency vector search at scale, Amazon OpenSearch Service is the primary managed choice, especially when teams already have Elasticsearch expertise. S3 vector buckets are for high-latency-tolerant, large-scale archival vector storage.

Question 9 - Extracting and Cataloging Data from Multiple Sources

A media streaming company stores user behavior logs in Amazon S3 (JSON format), subscription metadata in Amazon RDS for MySQL, and content metadata in Amazon DynamoDB. The ML team needs to build a unified recommendation model training dataset that joins these three sources on user_id and content_id.

The engineering team wants a serverless approach that catalogs the final merged dataset so it can be queried by Athena without manual schema definition every time new data is ingested.

Which THREE AWS services should the engineer configure to achieve this? (Select THREE)

A) AWS Glue crawlers to discover and catalog schemas from S3, RDS MySQL, and DynamoDB
B) AWS Glue ETL job (Spark) to join the three data sources and write merged output to S3 in Parquet
C) Another AWS Glue crawler to catalog the merged Parquet output for Athena queries
D) Amazon Kinesis Data Firehose to stream all three sources into a single delivery stream
E) SageMaker Feature Store as the primary data catalog for Athena

Click to reveal Answer & Explanation

Correct Answers: A, B, and C

Correct Options Analysis

  • A is Correct: Glue crawlers can automatically discover schemas from multiple data sources including S3, JDBC-connected RDS databases, and DynamoDB tables, registering them in the Glue Data Catalog.
  • B is Correct: Glue ETL is serverless and built on Apache Spark. It can natively read from S3, JDBC (RDS), and DynamoDB via its connectors, perform the join on user_id and content_id, and write Parquet output to S3.
  • C is Correct: After the merged output exists, a crawler registers the Parquet schema in the Data Catalog, enabling Athena (and other services) to query it directly without manual DDL.

Distractor Analysis

  • D is Incorrect: Kinesis Data Firehose is for streaming real-time data into a single destination (S3, Redshift, OpenSearch, etc.). It cannot natively perform joins across heterogeneous sources with different schemas. RDS and DynamoDB also do not emit streaming records by default without additional configuration (e.g., Debezium for MySQL CDC or DynamoDB Streams).
  • E is Incorrect: SageMaker Feature Store is a purpose-built store for ML features (online and offline), not a general-purpose data catalog for Athena. Athena queries data from the Glue Data Catalog, not from Feature Store.

Key Takeaway: The Glue Data Catalog is the central metadata repository for AWS analytics; use crawlers to register source schemas, Glue ETL to join and transform, and another crawler to catalog the output for Athena.

Question 10 - Troubleshooting Data Ingestion Scalability

An e-commerce company's data engineering team built a batch ingestion pipeline using AWS Glue that reads daily transaction logs from S3, applies transformations, and writes results to a Redshift cluster. The pipeline initially ran in 45 minutes when processing 100 GB per day. Over six months, the daily volume grew to 500 GB and the Glue job now takes 6 hours to complete, causing downstream analytics dashboards to be stale.

The Glue job uses 10 DPUs (Standard worker type). The engineering team needs to reduce the job runtime while maintaining cost efficiency.

Which TWO changes should the engineer make? (Select TWO)

A) Increase the number of DPUs to 50 and enable job bookmarks to reduce reprocessing
B) Convert the transformation logic from Spark SQL to a custom Lambda function for scalability
C) Ensure the source data in S3 is organized with a partitioned prefix (e.g., year/month/day) and configure partition pushdown predicates in the Glue job
D) Change the output format from Parquet to uncompressed CSV to speed up writes
E) Disable the Auto Scaling feature on the Glue job to prevent resource fluctuations

Click to reveal Answer & Explanation

Correct Answers: A and C

Correct Options Analysis

  • A is Correct: Increasing DPUs from 10 to 50 provides more Spark executors and computational parallelism, directly addressing the increased data volume. Job bookmarks help track processed data, avoiding reprocessing of already-ingested data. This is a standard scalability lever in Glue.
  • C is Correct: Organizing source data in S3 with a partition prefix (e.g., year/month/day or dataset date) allows the Glue job to use partition pushdown predicates. Instead of scanning all 500 GB daily, the job only reads the current day's partition, drastically reducing read time and cost.

Distractor Analysis

  • B is Incorrect: Lambda is not suitable for processing 500 GB of data. Lambda's constraints (15-minute timeout, limited disk/memory) make it inappropriate for large-scale batch transformations. Glue with Spark is designed for exactly this workload.
  • D is Incorrect: Changing from Parquet to uncompressed CSV would increase write volume and time. CSV is a row-oriented, uncompressed text format and is significantly slower to serialize than compressed columnar formats like Parquet. This change would worsen performance.
  • E is Incorrect: Auto Scaling in Glue (available with newer worker types) helps optimize resource utilization by dynamically adjusting capacity. Disabling it would not improve performance. The problem is insufficient resources relative to growing data volume, not resource fluctuation.

Key Takeaway: To scale a Glue job as data volume grows, increase execution parallelism (more DPUs) and optimize data layout with S3 partitions and pushdown predicates so the job reads only the data it needs. Always use columnar formats like Parquet for output efficiency.

Question 11 - Extracting Data from OpenSearch for Batch Analytics

A cybersecurity firm uses Amazon OpenSearch Service to store and analyze security events in near real-time. The OpenSearch domain contains 6 months of event logs with an index pattern security-events-*. The ML team needs to build a training dataset for an anomaly detection model using the last 30 days of security events from OpenSearch.

The team wants to extract the data directly from OpenSearch into Amazon S3 in a cost-effective manner without writing custom extraction code or setting up additional streaming infrastructure.

Which approach should the engineer use? (Select ONE)

A) Use OpenSearch snapshots configured to write directly to S3 and restore only the last 30 days of indices
B) Create an AWS Glue ETL job that reads from OpenSearch using the Elasticsearch Spark connector and writes to S3
C) Enable Kinesis Data Firehose on the OpenSearch domain to continuously stream event data to S3
D) Run a script on an EC2 instance that queries the OpenSearch _search API and uploads results to S3
E) Use Amazon SageMaker Data Wrangler to directly import data from OpenSearch into S3

Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: AWS Glue has native connectors for OpenSearch (via the Elasticsearch Spark connector). A Glue ETL job can query the security-events-* index with a date filter, extract the last 30 days of data, and write Parquet/CSV to S3—all serverlessly and without custom code or additional infrastructure.

Distractor Analysis

  • A is Incorrect: OpenSearch snapshots capture entire indices in a proprietary format (not directly usable as a training dataset). Restoring to extract 30 days of data would require creating a new domain, which is operational overhead and costly compared to a query-based extraction.
  • C is Incorrect: Kinesis Data Firehose is for ingesting new data into OpenSearch, not for extracting data out of OpenSearch. OpenSearch also does not natively emit events to Firehose from existing indices.
  • D is Incorrect: Running a custom script on EC2 introduces unnecessary operational overhead (instance management, scheduling, error handling, scaling). Glue provides a managed, serverless solution for this batch extraction with built-in partitioning and format conversion.
  • E is Incorrect: SageMaker Data Wrangler is a visual data preparation tool within SageMaker Studio, not a general-purpose data extraction pipeline. While it has some source connectors, it is not designed as a production ETL tool for large OpenSearch datasets and does not natively support direct OpenSearch-to-S3 pipelines for batch jobs.

Key Takeaway: For batch extraction from OpenSearch to S3, use AWS Glue with the Elasticsearch/OpenSearch connector—it provides serverless querying, filtering, and Parquet output without custom infrastructure. Snapshots are for backup/restore, not for creating training datasets.