Skill 1.1.1: Extract data from data sources

Question 1 - SageMaker Feature Store Online Store Latency Requirements

A financial services company is deploying a fraud detection model that requires real-time feature lookups with sub-10 millisecond latency. The data science team has engineered features including transaction velocity, device reputation scores, and account age. The features must be available for both online inference and batch training, and the team must ensure consistency between the feature values used during training and those served during inference.

The company requires minimal operational overhead for managing the feature infrastructure.

Which AWS service should the team use to store and serve these features?

A) Amazon DynamoDB with DynamoDB Accelerator (DAX)
B) Amazon SageMaker Feature Store with both online and offline stores enabled
C) Amazon OpenSearch Service with vector search enabled
D) Amazon RDS for PostgreSQL with multi-AZ deployment

Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

B is Correct: Amazon SageMaker Feature Store provides a purpose-built online store (backed by DynamoDB for low-latency lookups) and an offline store (backed by S3 with Parquet format) from a single feature definition. This ensures training-serving consistency and meets sub-10ms latency requirements.

Distractor Analysis

A is Incorrect: While DynamoDB with DAX can provide low latency, it lacks the built-in offline store and feature definition consistency that SageMaker Feature Store provides natively. The team would need to build and maintain this infrastructure themselves.
C is Incorrect: OpenSearch Service is designed for search and analytics workloads, including vector similarity search, not for low-latency feature lookups with training-serving consistency.
D is Incorrect: RDS for PostgreSQL is a relational database not optimized for sub-10ms online feature lookups, and lacks native feature store capabilities like time-travel queries and training-serving consistency guarantees.

Key Takeaway: SageMaker Feature Store is the AWS-native solution for maintaining consistency between training and inference features while meeting low-latency online lookup requirements.

Question 2 - Streaming Ingestion into Feature Store

An e-commerce company processes millions of clickstream events daily through Amazon Kinesis Data Streams. The ML team needs to ingest aggregated features (e.g., user session duration, pages viewed per session) into Amazon SageMaker Feature Store. The features must be available in the online store within seconds for real-time recommendation generation, while the complete historical data must be preserved in the offline store for model training.

The engineering team prefers a serverless approach with minimal infrastructure management.

Which TWO architectural components should the team use? (Select TWO)

A) An AWS Lambda function triggered by Kinesis Data Streams that computes features and calls the PutRecord API on the Feature Group's online store
B) An Amazon EC2 Auto Scaling group running a custom Flink application that writes directly to the offline store S3 bucket
C) An Amazon EMR cluster running Spark Streaming that ingests from Kinesis and writes features to the Feature Store offline store only
D) The Feature Store's automatic synchronization between online and offline stores after the Lambda writes features to the online store
E) An Amazon Kinesis Data Firehose delivery stream that buffers events and writes them directly to the offline store S3 bucket using Parquet format

Click to reveal Answer & Explanation

Correct Answers: A and D

Correct Options Analysis

A is Correct: AWS Lambda is serverless and integrates natively with Kinesis Data Streams as a consumer. The Lambda function can compute features and use the SageMaker Feature Store PutRecord API to write to the online store.
D is Correct: SageMaker Feature Store automatically synchronizes data from the online store to the offline store with a time-series dimension, maintaining the historical record for training without manual ETL.

Distractor Analysis

B is Incorrect: EC2 Auto Scaling groups require infrastructure management and the offline store is managed by SageMaker Feature Store; writing directly to it bypasses the Feature Store's consistency mechanisms.
C is Incorrect: EMR clusters are not serverless and writing only to the offline store means the online store remains empty, breaking the real-time inference requirement.
E is Incorrect: Kinesis Data Firehose writing directly to S3 bypasses the Feature Store entirely, missing both the online store and the feature definition consistency that the Feature Store provides.

Key Takeaway: SageMaker Feature Store synchronizes online and offline stores automatically; feeding the online store with a serverless consumer like Lambda is the minimal-overhead ingestion pattern.

Question 3 - Offline Store Data Format and Training Query

A machine learning team at a retail company uses Amazon SageMaker Feature Store to manage features for a demand forecasting model. The team needs to retrieve historical feature values for model training, including point-in-time queries to reconstruct what the features looked like at specific timestamps in the past. The offline store must support efficient columnar reads for Spark-based training jobs on Amazon EMR.

Which storage properties correctly describe the SageMaker Feature Store offline store implementation?

A) The offline store uses Amazon S3 with Apache Parquet format and maintains a time-series of feature values
B) The offline store uses Amazon RDS for PostgreSQL with pgvector extension for historical feature queries
C) The offline store uses Amazon EBS volumes attached to feature store instances for high-speed historical access
D) The offline store uses Amazon DynamoDB with TTL settings to manage feature history

Click to reveal Answer & Explanation

Correct Answer: A

Correct Answer Analysis

A is Correct: SageMaker Feature Store offline store is backed by Amazon S3 storing data in Apache Parquet format. This enables columnar reads, point-in-time time-travel queries, and efficient integration with Spark-based training jobs on EMR or SageMaker.

Distractor Analysis

B is Incorrect: The offline store is not backed by RDS. While RDS with pgvector is a valid vector store, it is not how SageMaker Feature Store's offline store is implemented.
C is Incorrect: EBS volumes are block storage attached to individual instances, not used by the managed Feature Store offline store.
D is Incorrect: DynamoDB serves as the online store for SageMaker Feature Store, not the offline store. TTLs are not used for feature history management.

Key Takeaway: The offline store's S3 + Parquet architecture enables cost-effective historical analysis with point-in-time accuracy, while the online store optimizes for low-latency lookups.

Question 4 - Feature Store Ingestion Throughput and Capacity

A healthcare analytics firm is experiencing throttling errors when writing features to their SageMaker Feature Store online store. The feature ingestion pipeline processes 10,000 patient records per minute during peak hours, and the team observes 400-level throttling exceptions from the Feature Store PutRecord API. The write pattern includes 25 individual feature values per record.

The team has verified that the IAM roles and policies are correctly configured, and the feature group exists with an online store enabled.

What is the MOST LIKELY cause of these throttling errors?

A) The feature group's online store is exceeding the DynamoDB throughput limits on the underlying table
B) The IAM role lacks the sagemaker:PutRecord permission
C) The feature group is using an incorrect event time format
D) The offline store S3 bucket has insufficient storage capacity

Click to reveal Answer & Explanation

Correct Answer: A

Correct Answer Analysis

A is Correct: SageMaker Feature Store's online store is backed by Amazon DynamoDB. When the PutRecord volume or the number of feature values per record exceeds the provisioned DynamoDB write capacity units (WCUs), DynamoDB returns throttling exceptions (400-level errors). This is the classic symptom of insufficient write capacity during peak ingestion rates.

Distractor Analysis

B is Incorrect: The scenario specifies that IAM roles are correctly configured. IAM permission issues produce 403 Forbidden errors, not throttling errors.
C is Incorrect: An incorrect event time format would result in validation errors, not throttling. Event time is a required parameter but format errors are rejected with different error codes.
D is Incorrect: The offline store in S3 is not subject to throughput throttling. S3 can scale to multiple petabytes, and insufficient storage capacity is not a typical cause of API throttling.

Key Takeaway: SageMaker Feature Store online store is backed by DynamoDB; throttling indicates insufficient provisioned write capacity, and the solution is to increase WCUs or use on-demand capacity mode.

Question 5 - Feature Store Offline Storage Customization

A large financial institution requires all ML data -- including features stored in Amazon SageMaker Feature Store -- to be encrypted at rest using a customer-managed key (CMK) in AWS KMS. The compliance team also requires that all feature history be stored in a specific S3 bucket controlled by the data governance team, with a retention policy of 7 years.

The ML team is creating feature groups and needs to configure the offline store to meet these requirements.

Which configurations should the team specify when creating the feature group? (Select TWO)

A) The offline store S3 URI pointing to the data governance team's designated bucket
B) The AWS KMS CMK ARN for encrypting the offline store data
C) The DynamoDB table name for the online store encryption configuration
D) The S3 lifecycle policy to expire offline store data after 7 years
E) The feature group description that mentions the compliance requirement for auditing

Click to reveal Answer & Explanation

Correct Answers: A and B

Correct Options Analysis

A is Correct: When creating a feature group with an offline store, you specify the S3 URI where offline store data will be stored. This allows the data governance team to maintain control over the designated bucket.
B is Correct: The offline store encryption can be configured with a customer-managed key by specifying the KMS key ID or ARN during feature group creation. This meets compliance requirements for CMK encryption at rest.

Distractor Analysis

C is Incorrect: The DynamoDB table name is not user-specified; SageMaker Feature Store manages the online store infrastructure internally. Encryption for the online store is managed by SageMaker using AWS-managed keys.
D is Incorrect: S3 lifecycle policies are configured at the bucket level by the S3 bucket owner (the data governance team), not specified during feature group creation. The ML team would not set this as a feature group parameter.
E is Incorrect: Feature group descriptions do not enforce compliance requirements. They are metadata only and cannot be used for auditing or enforcement.

Key Takeaway: SageMaker Feature Store allows you to configure the offline store S3 location and KMS encryption key during feature group creation, but lifecycle policies are managed at the S3 bucket level.

Question 6 - Feature Store Record Expiration and TTL

A logistics company uses Amazon SageMaker Feature Store to track real-time fleet metrics for predictive maintenance. The features include engine hours, vibration amplitude, and temperature. The company's data governance policy mandates that operational metrics older than 90 days be automatically removed to minimize storage costs and reduce data exposure risk.

The team needs to implement this expiration policy with minimal operational overhead.

What is the MOST EFFICIENT approach to implement this requirement?

A) Use the expiration_days parameter when creating the feature group to set a 90-day TTL on feature records
B) Schedule an AWS Lambda function that queries the offline store daily and deletes records older than 90 days
C) Configure an S3 lifecycle policy on the offline store bucket to expire objects after 90 days
D) Create an AWS Glue job that runs weekly to purge old feature records from both online and offline stores

Click to reveal Answer & Explanation

Correct Answer: A

Correct Answer Analysis

A is Correct: SageMaker Feature Store supports an expiration_days parameter when creating a feature group. Setting this to 90 automatically manages record expiration (TTL) from the online store, with records older than 90 days being removed without requiring custom automation.

Distractor Analysis

B is Incorrect: Custom Lambda functions for record deletion introduce unnecessary operational overhead and complexity compared to the native TTL feature in Feature Store. It also requires handling for both online and offline stores.
C is Incorrect: S3 lifecycle policies manage objects in the offline store bucket based on object age, not feature record age. Additionally, this does not address the online store cleanup requirement.
D is Incorrect: AWS Glue jobs are overkill for this requirement and introduce batch-processing latency plus manual orchestration overhead. The native TTL handles expiration automatically.

Key Takeaway: SageMaker Feature Store provides native TTL via expiration_days for automated record expiration, eliminating the need for custom cleanup jobs or lambda functions.

Question 7 - Feature Store Consolidation from Multiple Sources

A media streaming company has feature data scattered across multiple systems: user subscription data in Amazon RDS, watch history in Amazon DynamoDB, content metadata in Amazon S3, and real-time session events in Amazon Kinesis Data Streams. The ML team needs to consolidate these features into SageMaker Feature Store for a content recommendation model.

The team must ensure that features from all sources are ingested consistently with minimal custom code.

Which THREE approaches should the team implement? (Select THREE)

A) Use AWS Glue ETL jobs to extract features from RDS, DynamoDB, and S3, then write to the Feature Store offline store using the PutRecord API
B) Use Amazon Kinesis Data Firehose with a Lambda transformation to write real-time features directly to the Feature Store online store
C) Use Amazon EMR to create custom connectors for reading from RDS, DynamoDB, and S3 simultaneously for a one-time migration only
D) Use the SageMaker Feature Store IngestBatch API to build an automated pipeline with AWS Step Functions orchestrating batch ingestion
E) Configure an AWS DMS (Database Migration Service) task to continuously replicate RDS data into the Feature Store online store

Click to reveal Answer & Explanation

Correct Answers: A, B, and D

Correct Options Analysis

A is Correct: AWS Glue provides managed ETL with built-in connectors for RDS and DynamoDB, and native S3 reading. Writing to the Feature Store using the PutRecord or IngestBatch API ensures features are registered in both online and offline stores.
B is Correct: Kinesis Data Firehose with Lambda can perform streaming ETL to transform events and write real-time features to the Feature Store online store, enabling low-latency feature availability.
D is Correct: The IngestBatch API is designed for batch ingestion scenarios. AWS Step Functions orchestrates the workflow, providing error handling, retries, and monitoring for a consistent ingestion pipeline.

Distractor Analysis

C is Incorrect: EMR is unnecessary for this integration and a one-time migration alone does not satisfy the requirement for consistent ongoing ingestion from all sources.
E is Incorrect: AWS DMS is designed for database replication between databases, not for writing to the SageMaker Feature Store API. It cannot directly integrate with Feature Store's PutRecord endpoint.

Key Takeaway: SageMaker Feature Store supports both streaming (PutRecord) and batch (IngestBatch) APIs, enabling integration with Glue for batch ETL and Kinesis/Lambda for streaming ingestion, orchestrated by Step Functions.

Question 8 - Feature Store Online Store Performance Optimization

An online gaming company uses SageMaker Feature Store to serve player features for a real-time matchmaking model. The feature group contains 50 feature values per player record. The team observes that during peak gaming hours, the online store's read latency degrades significantly, affecting matchmaking quality. The BatchGetRecord API calls return 100 records at a time, and the team has already confirmed that the DynamoDB table is not throttling.

What is the MOST LIKELY issue and solution?

A) The feature values exceed the DynamoDB item size limit, causing partial reads; reduce features per record or split into multiple feature groups
B) The BatchGetRecord API has a hard limit of 50 records per call; reduce the batch size
C) The online store is backing up data to S3, causing latency spikes; disable offline store synchronization
D) The feature group's security configuration is causing encryption overhead; switch to unencrypted mode

Click to reveal Answer & Explanation

Correct Answer: A

Correct Answer Analysis

A is Correct: DynamoDB has a maximum item size of 400KB. With 50 complex feature values (e.g., strings, arrays), the item can approach or exceed this limit. Oversized items cause performance degradation or failed writes/reads. Reducing features per record or splitting into multiple feature groups (one per entity type or domain) solves this.

Distractor Analysis

B is Incorrect: The BatchGetRecord API does not have a 50-record limit. Batch operations typically support up to 100 records or 16MB total size. The scenario states 100 records are returned successfully.
C is Incorrect: Offline store synchronization is asynchronous and does not block online store reads. Disabling offline store would remove historical data for training, which is counterproductive.
D is Incorrect: AWS KMS encryption at rest does not introduce measurable latency at the API level. Disabling encryption would violate compliance and security best practices without resolving the issue.

Key Takeaway: DynamoDB item size limits directly impact SageMaker Feature Store online store performance; if feature records grow beyond 400KB, split them across feature groups or reduce feature values per record.

Question 9 - Feature Store for Model Training Point-in-Time Queries

A credit risk modeling team is building a model to predict default probability. Historical data shows that customer credit scores, income, and debt ratios change over time. The team must ensure that when training the model, they use feature values that were known at the time of each loan application, not current values. This is critical to avoid look-ahead bias in the model.

Which feature store capability specifically addresses this requirement?

A) The offline store's ability to store multiple versions of features with event times and perform point-in-time queries
B) The online store's DynamoDB partition key design that separates feature values by loan ID
C) The Feature Store's integration with AWS Glue Data Catalog for schema versioning
D) The BatchGetRecord API's ability to filter records by customer ID

Click to reveal Answer & Explanation

Correct Answer: A

Correct Answer Analysis

A is Correct: SageMaker Feature Store's offline store maintains a time-series of feature values with event times (timestamps when the feature value was recorded). Point-in-time queries allow retrieval of feature values as they existed at any historical moment, preventing data leakage and ensuring temporal consistency in training datasets.

Distractor Analysis

B is Incorrect: The online store's partition key design is about lookup performance for current feature values, not about reconstructing historical values. It does not provide time-travel capabilities.
C is Incorrect: AWS Glue Data Catalog integration provides schema discovery and metadata management, not point-in-time feature retrieval. It does not address temporal consistency.
D is Incorrect: BatchGetRecord filters by record identifiers to retrieve current feature values from the online store. It does not provide historical point-in-time query capabilities.

Key Takeaway: The offline store's time-series data model enables point-in-time queries, which is critical for preventing look-ahead bias and ensuring that training data matches what would have been available at prediction time.

Question 10 - Feature Store Migration from Legacy System

A global manufacturing company currently stores machine sensor features in a self-managed PostgreSQL database. The CTO wants to migrate to Amazon SageMaker Feature Store to reduce management overhead and enable online/offline store separation for real-time anomaly detection and historical trend analysis.

The migration must occur with minimal disruption to production systems, and the team needs to ensure no data loss during migration. The company's ML workloads run on Amazon SageMaker using PySpark.

What is the BEST migration strategy?

A) Use AWS Glue to read features from PostgreSQL in parallel, transform to Parquet, and batch ingest into Feature Store using the IngestBatch API
B) Use Data Pipeline to export PostgreSQL directly to the Feature Store's internal S3 bucket without using the API
C) Use AWS DMS to perform continuous replication from PostgreSQL to DynamoDB, then import into Feature Store
D) Manually export PostgreSQL to CSV files and use the AWS CLI to upload files to the Feature Store console

Click to reveal Answer & Explanation

Correct Answer: A

Correct Answer Analysis

A is Correct: AWS Glue provides serverless, scalable ETL from PostgreSQL using Spark. After transformation to Parquet format, the IngestBatch API efficiently loads large volumes of features into SageMaker Feature Store, writing to both online and offline stores in a single operation. This minimizes disruption and ensures data integrity during migration.

Distractor Analysis

B is Incorrect: Data Pipeline is deprecated and no longer recommended. Writing directly to Feature Store's internal S3 bucket without going through the API violates the managed service abstraction, potentially corrupting data and breaking online/offline store synchronization.
C is Incorrect: AWS DMS is optimized for database-to-database replication, not for writing to SageMaker Feature Store. The extra step of importing from DynamoDB adds complexity and the continuous replication model is unnecessary for a one-time migration.
D is Incorrect: Manual CSV export is error-prone, slow, and cannot guarantee no data loss at scale. The Feature Store console does not support bulk CSV upload, and this approach does not leverage the IngestBatch API for efficient parallel loading.

Key Takeaway: For large-scale migration into SageMaker Feature Store, use a managed ETL service (AWS Glue) to extract and transform data, then call IngestBatch for parallel, scalable loading into both online and offline stores.