Skip to content

Skill 1.2.2: Create and manage features by using AWS tools (for example, SageMaker Feature Store)


Question Answer & Explanation
### Question 1 - Real-Time Feature Retrieval for Fraud Detection


An e-commerce company is building a real-time fraud detection system. During the online checkout process, the model must retrieve historical user purchase behavior features (e.g., average order value, failed payment count) with single-digit millisecond latency.


The architecture must prioritize the lowest possible retrieval latency while managing these features centrally.


Which AWS service configuration meets these requirements? (Select ONE)


- A) Query the SageMaker Feature Store Offline Store using Amazon Athena.


- B) Ingest and retrieve features from the SageMaker Feature Store Online Store.


- C) Store features in an Amazon S3 bucket and retrieve them using S3 Select.


- D) Use Amazon Redshift as the feature repository and query it during inference. | Correct Answer: B


Correct Answer Analysis:


- B is Correct: The SageMaker Feature Store Online Store is specifically designed for low-latency, real-time feature retrieval (single-digit millisecond latency) during online inference, making it ideal for real-time fraud detection.


Distractor Analysis:


- A is Incorrect: The Offline Store is backed by S3 and queried via Athena; it is optimized for batch training data retrieval, not low-latency online inference.


- C is Incorrect: Amazon S3 is an object store with high latency (tens to hundreds of milliseconds) for individual object retrieval, making it unsuitable for real-time feature serving.


- D is Incorrect: Amazon Redshift is a data warehouse optimized for analytical queries over large datasets, not for single-row, single-digit millisecond key-value lookups required in real-time inference.


> Exam Tip: Use the SageMaker Feature Store Online Store for low-latency inference and the Offline Store for batch training dataset creation. | | ### Question 2 - Mitigating Training-Serving Skew


A machine learning team is experiencing model degradation in production. Investigation reveals that feature engineering logic written in the training script differs slightly from the logic implemented in the production inference container, causing training-serving skew.


The team needs a solution that ensures the exact same feature definitions and transformations are used for both training and inference, with the least operational overhead.


Which approach fulfills this requirement? (Select ONE)


- A) Duplicate the feature engineering code into a shared Python library and import it in both the training and inference scripts.


- B) Use AWS Glue DataBrew to compute features and write them to Amazon S3, then read from S3 in both environments.


- C) Use SageMaker Feature Store to centralize feature definitions, and retrieve features from the same feature group for both training and inference.


- D) Deploy an AWS Lambda function to compute features on-the-fly during inference and a SageMaker Processing job for training. | Correct Answer: C


Correct Answer Analysis:


- C is Correct: SageMaker Feature Store provides a central repository for features. By writing engineered features to a Feature Group, both training pipelines and inference endpoints retrieve the exact same pre-computed features, eliminating training-serving skew.


Distractor Analysis:


- A is Incorrect: While sharing code reduces duplication, it still requires maintaining custom code and introduces risk of discrepancies if data environments differ. It does not guarantee the exact same feature values are consumed.


- B is Incorrect: Reading from S3 for real-time inference introduces high latency and does not provide a feature management framework or online serving capability.


- D is Incorrect: Using separate compute engines (Lambda for inference, Processing for training) increases operational overhead and still risks divergence in the transformation logic between the two environments.


> Exam Tip: Centralizing features in SageMaker Feature Store ensures that training and serving share a single source of truth, natively preventing training-serving skew. | | ### Question 3 - Near Real-Time Feature Ingestion


An IoT company collects sensor data from manufacturing equipment via Amazon Kinesis Data Streams. The data science team needs to update feature groups in Amazon SageMaker Feature Store in near real-time so that predictive maintenance models have the most recent sensor readings.


The solution must minimize operational overhead and avoid managing servers.


Which AWS architecture achieves this? (Select ONE)


- A) Use AWS Lambda functions triggered by Kinesis Data Streams to ingest records into the SageMaker Feature Store Online Store.


- B) Deploy an Amazon EMR cluster with Spark Streaming to read from Kinesis and write to Feature Store.


- C) Use AWS Glue DataBrew to create a streaming recipe that writes directly to Feature Store.


- D) Configure Kinesis Data Firehose to deliver data to S3, then trigger a SageMaker Processing job to load data into Feature Store. | Correct Answer: A


Correct Answer Analysis:


- A is Correct: AWS Lambda is an event-driven, serverless compute service that can be triggered by Kinesis Data Streams. It can use the SageMaker Feature Store SDK to put records into the Online Store with low latency and zero server management.


Distractor Analysis:


- B is Incorrect: Deploying an Amazon EMR cluster introduces significant operational overhead (cluster management, scaling) compared to a serverless Lambda function.


- C is Incorrect: AWS Glue DataBrew is primarily a visual data preparation tool for batch ETL, not designed for near real-time stream processing ingestion into Feature Store.


- D is Incorrect: Delivering to S3 via Firehose and triggering a batch processing job introduces latency (minutes to hours) and does not meet the near real-time requirement.


> Exam Tip: For near real-time feature ingestion from streaming sources, AWS Lambda paired with the SageMaker Feature Store PutRecord API offers a serverless, low-latency path. | | ### Question 4 - Offline Store Encryption with Customer Managed Keys


A financial services company is using SageMaker Feature Store to manage highly sensitive customer transaction features. The security team mandates that all data at rest in the Offline Store (backed by Amazon S3) must be encrypted using a Customer Managed Key (CMK) stored in AWS KMS.


How should the ML engineer configure the Feature Group to meet this compliance requirement? (Select ONE)


- A) Enable SSE-KMS encryption on the Amazon S3 bucket manually after the Feature Group is created.


- B) Specify the KMS Key ARN in the S3StorageConfig when creating the Feature Group using the SageMaker SDK or boto3.


- C) Configure client-side encryption in the ingestion pipeline before writing data to the Offline Store.


- D) Use AWS Glue DataBrew to encrypt the data before it lands in the SageMaker Feature Store. | Correct Answer: B


Correct Answer Analysis:


- B is Correct: When creating a Feature Group, you can define the S3StorageConfig for the Offline Store. You can specify a KmsKeyId within this configuration to ensure the S3 bucket used by Feature Store is encrypted with the specified CMK.


Distractor Analysis:


- A is Incorrect: Manually altering the encryption settings of the S3 bucket created by SageMaker Feature Store is not a supported best practice and may break the service's access to the data.


- C is Incorrect: Client-side encryption adds unnecessary complexity to the ingestion pipeline and does not fulfill the requirement for native at-rest encryption managed by AWS KMS.


- D is Incorrect: Glue DataBrew is for data preparation, not for managing the at-rest encryption configuration of the Feature Store's underlying S3 storage.


> Exam Tip: Always configure KMS keys at the time of resource creation (e.g., within S3StorageConfig for offline store, OnlineStoreConfig for online store) rather than modifying underlying resources post-creation. | | ### Question 5 - GDPR Compliance and Data Deletion


An enterprise ML platform uses SageMaker Feature Store to manage user behavior profiles. Due to GDPR compliance requirements, the platform must be able to completely remove a specific user's feature data from the Online Store upon request.


Which method correctly achieves this specific data deletion? (Select ONE)


- A) Delete the entire Feature Group and recreate it without the user's data.


- B) Use the DeleteRecord API provided by SageMaker Feature Store.


- C) Manually delete the user's record from the underlying DynamoDB table used by the Online Store.


- D) Use the UpdateRecord API to overwrite the user's features with null values. | Correct Answer: B


Correct Answer Analysis:


- B is Correct: SageMaker Feature Store provides a native DeleteRecord API that allows you to delete a specific record from the Online Store based on the record identifier, fulfilling GDPR right-to-be-forgotten requirements.


Distractor Analysis:


- A is Incorrect: Deleting the entire Feature Group removes all data for all users, causing massive data loss and system downtime, which is disproportionate to a single user deletion request.


- C is Incorrect: Manually interacting with the underlying DynamoDB table is not supported, bypasses audit logs, and can corrupt the Feature Store's metadata.


- D is Incorrect: Overwriting with null values does not delete the data; the record still exists and may violate strict GDPR deletion mandates.


> Exam Tip: Use the native DeleteRecord API to remove individual records from the Online Store for compliance. Note that the Offline Store (S3) is immutable, so offline deletions require dropping the feature group or using Athena/Glue to filter and rewrite. | | ### Question 6 - Preventing Data Leakage with Point-in-Time Queries


A data scientist is building a training dataset for a churn prediction model. The features are stored in a SageMaker Feature Store Offline Store. To ensure the model accurately simulates production conditions, the training dataset must only include features that were known at the exact time of the historical prediction event.


Which Feature Store capability prevents data leakage in this scenario? (Select ONE)


- A) Using Amazon Athena to query the Offline Store with a point-in-time as_of_date condition.


- B) Querying the Online Store at the moment of training.


- C) Sorting the Offline Store data by event time and dropping the last 10% of rows.


- D) Using AWS Glue DataBrew to duplicate the latest feature values across all historical rows. | Correct Answer: A


Correct Answer Analysis:


- A is Correct: The Offline Store supports point-in-time queries. By joining the feature group with an event dataset and specifying an as_of_date or event_time in Athena or the SageMaker SDK, the query returns only the feature values that existed prior to the event time, strictly preventing future data leakage.


Distractor Analysis:


- B is Incorrect: The Online Store only contains the latest feature values. Querying it during training would use current features for historical events, causing severe data leakage.


- C is Incorrect: Simply sorting and dropping rows does not guarantee that individual feature values precede the corresponding label's event time, especially with irregular update frequencies.


- D is Incorrect: Duplicating the latest values across historical rows is the exact definition of data leakage (using future data to predict the past).


> Exam Tip: Point-in-time queries (as_of_date) in the Offline Store are the standard mechanism for generating leakage-free training datasets from feature groups. | | ### Question 7 - Mandatory Feature Group Configuration


A machine learning engineer is programmatically creating a new Feature Group in Amazon SageMaker Feature Store using the boto3 SDK. The group will store user profile features.


Which TWO attributes must be specified during the creation of the Feature Group? (Select TWO)


- A) The Record Identifier feature name.


- B) The Online Store provisioned read capacity units (RCUs).


- C) The Event Time feature name.


- D) The embedding model ID used to generate the features.


- E) The maximum number of records allowed in the Offline Store. | Correct Answer: A and C


Correct Answer Analysis:


- A is Correct: The Record Identifier is a required parameter; it is the unique key used to identify a record within the feature group.


- C is Correct: The Event Time feature name is mandatory. Feature Store uses this timestamp to track the validity of features, enable point-in-time queries, and manage data expiration.


Distractor Analysis:


- B is Incorrect: SageMaker Feature Store Online Store is serverless. You do not manually provision RCUs like you would for a raw DynamoDB table.


- D is Incorrect: Embedding model IDs are not a configuration parameter of a Feature Group; Feature Store simply stores the numerical arrays if provided.


- E is Incorrect: There is no limit on the number of records in the Offline Store; it scales automatically via S3.


> Exam Tip: Creating a Feature Group always requires defining the Feature Definitions, a Record Identifier, and an Event Time feature. | | ### Question 8 - Automating Feature Ingestion in MLOps


An MLOps team is building an automated pipeline to reprocess and ingest user clickstream features into SageMaker Feature Store every night. The pipeline must be orchestrated natively within Amazon SageMaker, keeping operational overhead to a minimum.


Which orchestration approach is the most appropriate? (Select ONE)


- A) Use AWS Step Functions to orchestrate AWS Lambda functions that run the feature engineering code and ingest into Feature Store.


- B) Use SageMaker Pipelines with a Processing Step that runs a custom Python script to engineer features and ingest them into the Offline and Online Stores.


- C) Use Amazon EventBridge to trigger an AWS Glue streaming job that writes to Feature Store.


- D) Use an Amazon EC2 instance with a cron job to execute the SageMaker SDK ingestion script. | Correct Answer: B


Correct Answer Analysis:


- B is Correct: SageMaker Pipelines is the native MLOps orchestration tool for SageMaker. Using a Processing Step allows the team to run feature engineering code in a managed container and seamlessly use the Feature Store SDK to ingest data, all within a single, serverless workflow.


Distractor Analysis:


- A is Incorrect: While Step Functions can orchestrate Lambda, this introduces custom infrastructure and higher operational overhead compared to using SageMaker's native pipeline features.


- C is Incorrect: EventBridge triggering a Glue streaming job is suited for real-time or near real-time streaming data, not scheduled nightly batch processing.


- D is Incorrect: Running an EC2 instance with a cron job requires managing servers, OS patching, and scaling, which directly violates the least operational overhead constraint.


> Exam Tip: For automated, scheduled ML workflows involving SageMaker services (like Feature Store, Processing jobs, Training jobs), SageMaker Pipelines is the preferred native orchestrator. | | ### Question 9 - Optimizing Offline Store Query Performance


A data science team frequently queries the Offline Store of their SageMaker Feature Store using Amazon Athena to generate training datasets. The queries are taking longer than expected and consuming large amounts of data scanned in Athena, leading to high costs.


The team wants to optimize query performance and reduce Athena costs. What is the default storage format used by the Offline Store that inherently helps with this, and what feature of Athena should they leverage? (Select ONE)


- A) The Offline Store uses CSV format; the team should partition the data by day in Athena.


- B) The Offline Store uses Apache Parquet format; the team should use Athena partition projection on the automatically created time partitions.


- C) The Offline Store uses JSON format; the team should compress the data using Snappy.


- D) The Offline Store uses Avro format; the team should convert the data to Parquet using a Glue job. | Correct Answer: B


Correct Answer Analysis:


- B is Correct: SageMaker Feature Store Offline Store automatically saves data in the Apache Parquet format, which is a columnar format that heavily optimizes Athena query performance and reduces scanned data. Furthermore, Feature Store automatically partitions the S3 data by event time, and Athena partition projection can be configured to speed up these partitioned queries.


Distractor Analysis:


- A is Incorrect: The Offline Store does not use CSV; Parquet is used specifically for its performance and cost benefits over CSV.


- C is Incorrect: The Offline Store does not use JSON as its default storage format.


- D is Incorrect: The data is already in Parquet format, so no Glue conversion job is needed.


> Exam Tip: SageMaker Feature Store Offline Store automatically uses Apache Parquet and partitions data by event time in S3, natively optimizing for Athena queries. | | ### Question 10 - Managing Feature Expiration


A gaming company uses SageMaker Feature Store to manage real-time user session features (e.g., current game mode, last login timestamp) for dynamic difficulty adjustment. These session features become irrelevant and stale 2 hours after the user logs out.


To optimize storage costs and ensure the model does not consume stale features, the team wants these records to be automatically deleted from the Online Store after 2 hours. Which configuration achieves this with the least operational overhead? (Select ONE)


- A) Write an AWS Lambda function triggered by Amazon EventBridge every 5 minutes to scan and delete records older than 2 hours.


- B) Enable Time-to-Live (TTL) on the Online Store configuration of the Feature Group, setting the TTL to 2 hours.


- C) Configure a Glue crawler to drop partitions older than 2 hours in the Offline Store.


- D) Use SageMaker Model Monitor to detect stale features and trigger a Lambda deletion script. | Correct Answer: B


Correct Answer Analysis:


- B is Correct: SageMaker Feature Store supports Time-to-Live (TTL) for the Online Store. By setting a TTL value (e.g., 7200 seconds), records are automatically expired and deleted from the Online Store after the specified duration, requiring zero custom code or operational overhead.


Distractor Analysis:


- A is Incorrect: Creating a custom Lambda function and EventBridge schedule introduces unnecessary operational overhead to manage and monitor, compared to the native TTL feature.


- C is Incorrect: A Glue crawler manages metadata in the Glue Data Catalog for S3 (Offline Store), it does not automatically delete records from the Online Store's low-latency database.


- D is Incorrect: Model Monitor is used to track model drift and data quality, not to manage the lifecycle or deletion of records in the Feature Store.


> Exam Tip: For ephemeral or short-lived features, enable Time-to-Live (TTL) on the SageMaker Feature Store Online Store to automatically manage data expiration without custom scripting. | |