Skill 1.1.9: Ingest data into SageMaker Feature Store

Question	Answer & Explanation
### Question 1 - Online vs. Offline Store Configuration A retail company wants to use Amazon SageMaker Feature Store to manage customer purchase behavior features. A real-time fraud detection application requires sub-millisecond latency to retrieve the latest customer features, while the data science team needs to query historical feature data for batch model training. The team wants to use a single feature definition to serve both requirements. Which configuration BEST meets these requirements? - A) Enable only the offline store for the feature group. - B) Enable both the online and offline stores for the feature group. - C) Enable only the online store for the feature group. - D) Use Amazon S3 directly for online lookups and enable only the offline store in Feature Store.	Correct Answer: B Correct Option Analysis: - B is Correct: Enabling both the online and offline stores ensures that the same feature definitions are used for both low-latency, real-time inference (via the online store, backed by DynamoDB) and historical, batch training queries (via the offline store, backed by S3). This eliminates training-serving skew. Distractor Analysis: - A is Incorrect: The offline store is optimized for batch reads and historical queries, not for low-latency, sub-millisecond real-time lookups. - C is Incorrect: The online store only keeps the latest record per entity and does not retain the historical time-series data required for model training. - D is Incorrect: Using S3 directly for online lookups introduces high latency compared to a database-backed online store, and bypassing the Feature Store breaks the single feature definition paradigm. > Exam Tip: SageMaker Feature Store provides a unified feature definition by simultaneously maintaining an online store (for low-latency inference) and an offline store (for historical training).
### Question 2 - Batch Ingestion via SageMaker SDK A data scientist has engineered a large Pandas DataFrame containing customer churn features within a SageMaker notebook. They need to ingest this data into a SageMaker Feature Store with the least operational overhead and without writing custom API loops. Which method should the data scientist use to ingest the data? - A) Use the SageMaker Python SDK's `FeatureStore.ingest` method on the Pandas DataFrame. - B) Export the DataFrame to CSV and use a boto3 `PutRecord` API call loop in a Python script. - C) Write the DataFrame to Amazon S3 and run an AWS Glue crawler to update the Feature Store schema. - D) Use Amazon Athena to run an `INSERT INTO` query directly into the Feature Group.	Correct Answer: A Correct Option Analysis: - A is Correct: The SageMaker Python SDK provides a built-in `ingest` method for Feature Groups that accepts a Pandas DataFrame directly. It automatically batches the data and handles the ingestion into the online and offline stores, requiring minimal code and operational overhead. Distractor Analysis: - B is Incorrect: Using a boto3 `PutRecord` loop is highly inefficient for large DataFrames and introduces unnecessary custom code and operational overhead. - C is Incorrect: AWS Glue crawlers are used to infer schemas and populate the Glue Data Catalog, not to ingest data directly into SageMaker Feature Store. - D is Incorrect: While Athena can query the offline store, it cannot be used to ingest new records into the feature group, especially not into the online store. > Exam Tip: For batch ingestion from a notebook or processing job, use the SageMaker Python SDK's built-in DataFrame `ingest` method rather than manual API loops.
### Question 3 - Real-Time Ingestion from Kinesis An online gaming platform needs to ingest real-time player telemetry data (session duration, score, level) into SageMaker Feature Store as it arrives. The data is currently flowing through Amazon Kinesis Data Streams. The ingestion pipeline must be highly scalable, serverless, and maintain near real-time updates to the online store with the least operational overhead. Which architecture BEST meets these requirements? - A) Use an AWS Lambda function triggered by Kinesis Data Streams to process records and invoke the SageMaker Feature Store `PutRecord` API. - B) Use Amazon Managed Service for Apache Flink to continuously read from Kinesis and write to the Feature Store via JDBC. - C) Configure Kinesis Data Firehose to deliver the stream to an S3 bucket, then use a scheduled AWS Glue job to batch ingest into Feature Store. - D) Deploy a long-running Amazon EC2 instance running a custom Python script to poll Kinesis and call `PutRecord`.	Correct Answer: A Correct Option Analysis: - A is Correct: AWS Lambda can be triggered directly by Kinesis Data Streams, providing a serverless, highly scalable architecture. The Lambda function can parse the telemetry and use the boto3 `PutRecord` API to write to the online store with low latency. Distractor Analysis: - B is Incorrect: Apache Flink is better suited for complex stream processing and stateful computations. For simple record ingestion into Feature Store, it introduces unnecessary operational overhead and does not use a standard JDBC connector for this purpose. - C is Incorrect: Firehose to S3 followed by a scheduled Glue job introduces significant latency (batch processing) and fails the near real-time requirement. - D is Incorrect: An EC2 instance requires operational overhead to manage, scale, and patch, violating the "serverless" and "least operational overhead" constraints. > Exam Tip: For serverless, near real-time ingestion into Feature Store from streaming sources, use AWS Lambda triggered by Kinesis or EventBridge.
### Question 4 - Mandatory Feature Definitions An ML engineer is defining a new feature group in Amazon SageMaker Feature Store. The engineer must ensure that records can be uniquely identified and ordered based on exactly when the event occurred, which is critical for time-travel queries during model training. Which TWO features must be explicitly defined during the creation of the feature group? (Select TWO) - A) RecordIdentifierFeatureName - B) EventTimeFeatureName - C) FeatureNamePrefix - D) OnlineStoreKmsKeyId - E) TargetAttributeName	Correct Answers: A and B Correct Options Analysis: - A is Correct: The `RecordIdentifierFeatureName` specifies the column in the dataset that uniquely identifies a record (e.g., `customer_id`). This is mandatory for entity resolution. - B is Correct: The `EventTimeFeatureName` specifies the column that indicates the timestamp of the event. This is mandatory for time-travel queries and ensuring data consistency. Distractor Analysis: - C is Incorrect: `FeatureNamePrefix` is not a required parameter for feature group creation. - D is Incorrect: `OnlineStoreKmsKeyId` is an optional security parameter, not a mandatory identifier feature. - E is Incorrect: `TargetAttributeName` is used in SageMaker Autopilot or training jobs, not a required field for Feature Store group definitions. > Exam Tip: Creating a Feature Group strictly requires an identifier feature (unique key) and an event time feature (timestamp) to support online lookups and offline time-travel.
### Question 5 - Distributed Ingestion with Spark An enterprise needs to ingest petabytes of historical user interaction data into SageMaker Feature Store's offline store. The data is currently stored in an Amazon S3 data lake. The ingestion process must be highly distributed, fault-tolerant, and leverage existing AWS Glue infrastructure. Which approach is the MOST appropriate for this workload? - A) Use the SageMaker Python SDK `ingest` method within a SageMaker Processing Job using a single instance. - B) Use AWS Glue Studio to run a Spark job that writes directly to the Feature Store using the SageMaker Feature Store Spark connector. - C) Use Amazon EMR with custom code to invoke `PutRecord` API for each row sequentially. - D) Use Amazon Athena to run `INSERT INTO` queries directly into the offline store S3 bucket.	Correct Answer: B Correct Option Analysis: - B is Correct: AWS Glue runs Apache Spark natively, making it ideal for petabyte-scale distributed ingestion. The SageMaker Feature Store Spark connector allows Spark DataFrames to be written directly to the Feature Store's offline (and online) stores efficiently across multiple worker nodes. Distractor Analysis: - A is Incorrect: The SageMaker Python SDK `ingest` method is excellent for DataFrames in a single instance, but it is not optimized for petabyte-scale distributed processing compared to a Spark cluster. - C is Incorrect: Sequential `PutRecord` API calls from EMR are incredibly slow and do not leverage the parallel processing power of Spark. - D is Incorrect: Amazon Athena cannot perform direct `INSERT INTO` operations into SageMaker Feature Store's underlying S3 buckets in a way that registers them correctly with the Feature Store metadata and online store. > Exam Tip: For massive-scale batch ingestion, use AWS Glue or EMR with the SageMaker Feature Store Spark connector rather than the standard Python SDK `ingest` method.
### Question 6 - Offline Store Data Format A data engineering team is configuring a feature group in SageMaker Feature Store. The data scientists will frequently query the offline store using Amazon Athena, specifically selecting specific feature columns and filtering by time ranges. The team wants to optimize query performance and reduce Athena costs. Which data format should be configured for the offline store? - A) JSON lines (.jsonl) - B) CSV (.csv) compressed with GZIP - C) Apache Parquet (.parquet) - D) Avro (.avro)	Correct Answer: C Correct Option Analysis: - C is Correct: Apache Parquet is a columnar storage format. When Athena queries the offline store, Parquet allows for column pruning (reading only the requested features) and predicate pushdown (filtering by time ranges efficiently), minimizing I/O and reducing query costs. Distractor Analysis: - A is Incorrect: JSON is a row-based text format. Athena must scan the entire file to find the required columns, leading to higher costs and slower performance. - B is Incorrect: CSV is also a row-based format. Even compressed with GZIP, it lacks the columnar indexing required for efficient analytic queries. - D is Incorrect: Avro is a row-based format optimized for serialization, not for analytical columnar queries in Athena. > Exam Tip: When configuring the offline store in Feature Store, always choose Parquet as the data format to optimize Athena query performance and cost via column pruning.
### Question 7 - Time-Travel Queries A data scientist is training a credit scoring model and needs to query the offline store to retrieve the exact feature values for a specific customer as they existed at the precise timestamp of their loan application. This must be done to ensure no future data leaks into the training set. How should the data scientist retrieve this data? - A) Query the online store using `GetRecord` with the latest timestamp. - B) Query the offline store using Amazon Athena with a time-travel `as_of_time` condition in the SQL query. - C) Re-run the ingestion job to fetch the latest features for the historical transactions. - D) Export the offline store to S3 and use Pandas to merge on the RecordIdentifier only.	Correct Answer: B Correct Option Analysis: - B is Correct: SageMaker Feature Store offline store supports time-travel queries. By using Athena and specifying an `as_of_time` condition (e.g., `WHERE event_time <= '2023-10-01 12:00:00'`), the query retrieves the exact feature state at that historical moment, preventing data leakage. Distractor Analysis: - A is Incorrect: The online store only contains the latest feature values for a record. Querying it would return current data, not historical data, causing severe data leakage. - C is Incorrect: Re-running ingestion will overwrite or append new records; it does not retrieve historical point-in-time states. - D is Incorrect: Exporting to S3 and merging in Pandas requires complex custom logic to implement time-travel manually, which is natively supported by Athena and Feature Store. > Exam Tip: To prevent training-serving skew and data leakage, use Athena time-travel queries (`as_of_time`) against the offline store to get point-in-time accurate features.
### Question 8 - Handling Ingestion Failures During a batch ingestion of 5 million records into SageMaker Feature Store using the SageMaker Python SDK, the job fails midway due to a transient network timeout. The ML engineer needs to resume the ingestion seamlessly without duplicating records that were already successfully written to the online store. Which approach should the engineer take? - A) Re-run the `ingest` method with the entire DataFrame; Feature Store automatically deduplicates all records based on EventTime without any extra steps. - B) Utilize the returned `IngestionManager` object to handle the failure and automatically resume the ingestion from the point of failure. - C) Delete the feature group, recreate it, and re-run the full ingestion job. - D) Filter the DataFrame manually using Pandas and re-run the `ingest` method with only the remaining rows.	Correct Answer: B Correct Option Analysis: - B is Correct: The `ingest` method in the SageMaker Python SDK returns an `IngestionManager` object. If the ingestion fails, the engineer can use this object's `wait` method or internal state to handle failures and resume the ingestion from the exact point of failure without re-writing successfully processed records. Distractor Analysis: - A is Incorrect: While Feature Store uses EventTime for offline store time-travel, blindly re-running the entire DataFrame might overwrite or create duplicate event records in certain offline configurations, and it wastes compute on already ingested rows. - C is Incorrect: Deleting and recreating the feature group destroys all previously ingested data and is a highly destructive, inefficient operational choice. - D is Incorrect: Manually filtering the DataFrame is error-prone and requires external tracking of what was written, whereas the `IngestionManager` handles this natively. > Exam Tip: When using the SageMaker Python SDK for batch ingestion, rely on the `IngestionManager` object to gracefully handle transient failures and resume ingestion.
### Question 9 - Security and KMS Encryption A financial services company is ingesting sensitive PII features into a SageMaker Feature Store. Compliance regulations mandate that data at rest in both the online and offline stores must be encrypted using a customer-managed key (CMK). The ML engineer must ensure the CMK is explicitly tied to the Feature Store resources. What should the engineer do to meet these compliance requirements? - A) Configure SSE-KMS with a default AWS managed key on the S3 bucket for the offline store, and rely on DynamoDB default encryption for the online store. - B) Specify the customer-managed KMS key ARN for both the `OnlineStoreConfig` and `OfflineStoreConfig` when creating the feature group. - C) Enable client-side encryption in the SageMaker Python SDK before calling the `ingest` method. - D) Use an AWS Lambda function to encrypt the records using a KMS key before calling `PutRecord`.	Correct Answer: B Correct Option Analysis: - B is Correct: During `CreateFeatureGroup`, you can pass `OnlineStoreConfig(SecurityConfig=KmsKeyId)` and `OfflineStoreConfig(SecurityConfig=KmsKeyId)`. Specifying the CMK ARN here ensures both the underlying DynamoDB table (online) and S3 bucket (offline) are encrypted at rest with the customer's key. Distractor Analysis: - A is Incorrect: Compliance specifically requires a customer-managed key (CMK), not an AWS managed key. Relying on default encryption violates the explicit CMK constraint. - C is Incorrect: Client-side encryption encrypts the payload in transit or before it reaches the SDK, but Feature Store expects raw data to index and query. It does not fulfill the "at rest" encryption requirement natively. - D is Incorrect: Pre-encrypting the data via Lambda before `PutRecord` would make the features unreadable in the Feature Store, breaking downstream queries and lookups. > Exam Tip: Always pass the KMS CMK ID explicitly in the `OnlineStoreConfig` and `OfflineStoreConfig` SecurityConfig when creating a Feature Group for compliance-driven at-rest encryption.
### Question 10 - SageMaker Pipelines Integration An ML engineer is building an automated retraining pipeline using Amazon SageMaker Pipelines. A specific step in the pipeline must ingest the latest processed batch of features from an S3 bucket into a SageMaker Feature Store before the model training step begins. The pipeline must remain fully automated and serverless. Which step type is the MOST appropriate to achieve this? - A) Use a SageMaker Processing step with a custom Python script that utilizes the SageMaker Feature Store SDK to ingest the data. - B) Use an AWS Lambda step to read from S3 and call `PutRecord` for each feature iteratively. - C) Configure an Amazon EventBridge rule to trigger a standalone SageMaker Processing job outside the pipeline. - D) Use a SageMaker Training step with an estimator that writes to the Feature Store during the `fit` method.	Correct Answer: A Correct Option Analysis: - A is Correct: A SageMaker Processing step can run a custom Python container or script that reads the processed data from S3 into a Pandas DataFrame and uses the SageMaker Python SDK `ingest` method to load it into the Feature Store. This keeps the ingestion orchestrated within the pipeline. Distractor Analysis: - B is Incorrect: While AWS Lambda can be used in pipelines, using it to iteratively call `PutRecord` for a batch of data is inefficient and prone to timeouts (Lambda has a 15-minute limit). A Processing step is better suited for batch ingestion. - C is Incorrect: Triggering a standalone job via EventBridge breaks the orchestrated flow of the SageMaker Pipeline, making it harder to manage state and pass artifacts between steps. - D is Incorrect: A SageMaker Training step is designed to train models, not to perform data ingestion tasks. Mixing ingestion logic into the training script violates separation of concerns and pipeline best practices. > Exam Tip: Use a SageMaker Processing step within SageMaker Pipelines to orchestrate feature ingestion into the Feature Store using custom Python scripts.