MLA-C01 Practice Question 2: Feature Store Online Offline
AWS Certified Machine Learning Engineer – Associate (MLA-C01) · Test 1 · question 2 of 10
A fraud detection model is served from a real-time endpoint that must look up roughly 40 customer features by customer ID in single-digit milliseconds. The same features are needed to build training datasets, and today two separate code paths compute them: a Spark job for training data and application code for inference. The two implementations have drifted, and offline accuracy no longer matches production accuracy.
Which solution removes the duplicated logic and supports both access patterns?
Show answer and explanation
Answer:
A Feature Store feature group can be configured as online, offline, or both. The online store keeps only the latest record per record identifier and is built for low-millisecond reads and high throughput writes, the real-time inference path. The offline store is an append-only historical store in your S3 bucket, written in Parquet and queryable through Athena, which is what you use to assemble training and batch inference datasets. Because a single PutRecord ingestion path populates both, the transformation logic exists once. AWS calls this out explicitly as the way to reduce training-serving skew, which is precisely the symptom described.
Option A fails on latency. Athena is an interactive query service with query startup measured in seconds; it cannot serve a per-request feature lookup in single-digit milliseconds.
Option C solves only half the problem. DynamoDB is a perfectly good low-latency key-value store, but keeping the separate Spark job means the two implementations can still drift, the actual cause of the mismatch.
Option D is worse on both counts: a nightly refresh makes online features up to 24 hours stale, and a Redis cache holding only current values has no history from which to reconstruct what a feature looked like at the time of a past event.
Reference: Create, store, and share features with Feature Store