Top 30 MLOps & Infrastructure Interview Questions and Answers
30 multiple-choice questions on MLOps & Infrastructure, of the kind that come up in a technical interview, drawn from 30 bites in the MLOps & Infrastructure library. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.
Model deployment, training infra, experiment tracking
30 questions. Pick an answer, or open “Show the answer” to read it.
Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.
Question 1 of 30
How should a healthy production ML lifecycle be structured from start to finish?
Show the answer
Answer: c · As an iterative loop starting with business problem framing and continuing through post-deployment monitoring
The correct answer is B because the card describes the lifecycle as an end-to-end engineering process that begins with business goal definition and requires continuous monitoring and feedback loops after deployment. The most tempting distractor is D because treating packaging as the final step omits critical monitoring, retraining, and validation stages that keep a production model healthy.
Read the full bite: Describe the key stages of a typical ML lifecycle
Question 2 of 30
Which scenario would trigger an automated MLOps deployment but typically not a traditional DevOps pipeline?
Show the answer
Answer: b · Production monitoring detecting drift in input data distributions
The card states that MLOps deployments add triggers like data drift detection, unlike DevOps pipelines that react to code commits, dependency patches, or infrastructure changes. The GPU driver update is a tempting distractor because a common misconception is that MLOps is simply DevOps plus GPUs.
Read the full bite: What are the primary differences between traditional DevOps and MLOps?
Question 3 of 30
A deployed fraud model degrades. Using immutable lineage best practices, what is the most reliable way to isolate data drift from a code bug?
Show the answer
Answer: a · Reproduce the exact training run by combining the manifest's commit SHA, dataset hash, and locked dependencies, then verify the metrics match production logs
Reproducing the full training context from the manifest proves the model still yields the same metrics, confirming that production degradation is due to data drift rather than a code bug. Option B is tempting because it uses the exact dataset, but swapping in the latest code introduces a new variable and breaks the lineage chain needed for a valid comparison.
Read the full bite: Why version code, data, and models in MLOps?
Question 4 of 30
An e-commerce company notices prediction accuracy dropping on a model whose serving code hasn't changed. What is the most appropriate first step in a mature MLOps setup?
Show the answer
Answer: a · Trigger the CT pipeline to validate data, train, evaluate against the champion, and promote if blessed
When model performance decays but serving code is unchanged, the CT pipeline should validate data, retrain, and evaluate before promotion. Option D is wrong because it bypasses evaluation gates and data validation, and B is wrong because models are separate deployable units from serving code.
Read the full bite: Explain ML pipelines and typical CI/CD/CT components
Question 5 of 30
Which event should trigger an automated CI/CD retraining pipeline rather than just an alert or manual review?
Show the answer
Answer: c · Sustained accuracy drop of 5% over a rolling window or business metric degradation past a predefined cost threshold
The card specifies that automated retraining launches on sustained accuracy drops of 5% or more or business metric degradation exceeding a cost threshold, whereas latency spikes and missing features should page an on-call engineer for infrastructure issues. Weekly manual reviews and overly sensitive single-hour drift alerts are red flags that signal immature operational practices.
Read the full bite: What production metrics and auto-thresholds trigger model retraining?
Question 6 of 30
When scoping an MLOps platform for a mid-sized company with 5-15 engineers, which approach best demonstrates mature build-vs-buy reasoning?
Show the answer
Answer: a · Prioritize data governance, feature store, model registry, CI/CD/CT, and monitoring before the serving layer; buy commodity tools like orchestration and monitoring while investing engineering effort only in proprietary feature engineering and model architectures.
This option correctly sequences foundational components before serving and applies the buy-commodity, build-differentiator rule. Option C is tempting because avoiding vendor lock-in feels engineering-savvy, but maintaining a custom feature store and registry would consume two to three full-time engineers and ignores total cost of ownership.
Question 7 of 30
Which promotion flow best reflects a robust automated testing strategy for a weekly retrained production model?
Show the answer
Answer: a · Offline per-slice thresholds and bias checks, data validation for training-serving skew and drift, shadow deployment comparing latency and prediction distributions, then canary gated on business metrics with automatic rollback
This option captures the four-layer strategy from the card: offline statistical validation, data validation, shadow deployment, and canary gated on business metrics with automatic rollback. Option D is the most tempting distractor because it uses correct terminology but reverses the order and incorrectly uses offline accuracy as the final promotion gate rather than live business metrics.
Read the full bite: Design a robust automated testing strategy for ML models before production
Question 8 of 30
A model is trained on batch aggregates computed in Spark and served via a Python microservice using real-time streams. What is the most robust way to prevent training-serving skew?
Show the answer
Answer: b · Use a shared transformation library for both paths, serve from a versioned feature store, and log features at training time for replay validation
A shared transformation library and versioned feature store guarantee both paths execute identical logic from a single source of truth. Relying on manual code reviews is insufficient because separate implementations inevitably diverge under operational pressure.
Question 9 of 30
Why should batch product metadata and streaming click events typically use different physical storage formats?
Show the answer
Answer: c · Row-oriented formats minimize write overhead for high-velocity events, while columnar formats improve projection and compression for batch analytics
Row-oriented formats minimize write overhead for streaming ingestion while columnar formats allow efficient projection and compression for batch training data. Choosing columnar for both is tempting but adds unnecessary write overhead to high-velocity events.
Read the full bite: Design ingestion for clickstream and batch product metadata
Question 10 of 30
Why does ELT better support iterative ML experimentation than ETL?
Show the answer
Answer: d · It allows repeated transformations of raw data within the warehouse without re-extraction
ELT loads raw data into the target warehouse first, so data scientists can run and revise transformations repeatedly without rebuilding external pipelines or re-extracting source data. Option C describes ETL, which transforms data on a secondary server before loading and requires pipeline changes for new logic.
Question 11 of 30
Which upstream strategy best prevents a categorical encoder from crashing when new values appear in training data?
Show the answer
Answer: a · Enforce a locked schema that rejects batches with out-of-domain categories before encoding
Enforcing a locked schema upstream acts as a hard gate that stops bad batches before they reach the encoder and forces explicit review for domain changes. Relying solely on an OOV bucket is wrong because the card treats it only as a last-resort safety net, not a primary data-quality strategy, and using it alone can mask upstream data bugs.
Question 12 of 30
How does a tool like DVC let you version a 10TB dataset without duplicating it per version?
Show the answer
Answer: d · It stores content-addressed objects so unchanged files are shared across versions and only deltas are added
Content-addressed hashing means identical files are stored once and reused across versions, so a new version costs only changed objects. Putting binaries in Git or sampling would defeat reproducibility.
Question 13 of 30
Which architectural element of a feature store most directly prevents training-serving skew for a precomputed feature?
Show the answer
Answer: a · Running identical transformation logic in offline training pipelines and online serving paths
Training-serving skew is eliminated when the exact same transformations generate features for both training backfills and live inference. Option C is tempting but wrong because offline and online stores are separate, workload-optimized layers rather than a single shared database.
Read the full bite: Describe feature store architecture and training-serving skew
Question 14 of 30
What is the primary reason that complex feature computations on a 1 TB pandas DataFrame are riskier in Dask than in Apache Spark?
Show the answer
Answer: b · Dask lacks an advanced query planner like Spark's Catalyst, making complex shuffles and global aggregations less efficient
The card highlights that Dask can struggle with complex shuffles, while Spark's optimized query planner and Catalyst optimizer make it more resilient at terabyte scale. B is tempting because it reverses the actual API trade-off: the card emphasizes that Dask offers a pandas-like API with minimal changes, whereas Spark demands a heavier rewrite.
Read the full bite: How would you scale 1TB Pandas feature computation across machines?
Question 15 of 30
Which combination of techniques should anchor a production drift detection pipeline to catch both feature-level and interaction-level shifts without alert fatigue?
Show the answer
Answer: c · Chunk live traffic into periods, run separate univariate tests per feature type, add multivariate detection, and rank threshold alerts
Chunking, type-specific univariate tests, multivariate layering, and ranked thresholds together catch individual and interaction shifts while controlling noise and fatigue. Option A sounds maximally vigilant but is computationally infeasible and statistically noisy, as comparing every single row against the full training set generates excessive alerts and misses stable period patterns.
Read the full bite: How would you design automatic data drift detection for production inference?
Question 16 of 30
Why is it architecturally necessary to keep batch historical features in a KV store while maintaining session-level streaming features in a separate in-memory cache?
Show the answer
Answer: a · The batch path produces terabyte-scale pre-aggregated profiles that are updated infrequently, while the streaming path handles high-velocity session events with natural TTL decay; a single storage system cannot optimize for both access patterns under the 50ms SLA.
The card states that batch and streaming data have fundamentally different latency, volume, and freshness requirements, so one storage system cannot handle both optimally without breaking the sub-50ms SLA. Distractor A sounds plausible because the follow-ups mention exactly-once semantics for billing, but the card never cites billing consistency as the reason for the dual-store split.
Read the full bite: Design a sub-50ms real-time bidding feature pipeline
Question 17 of 30
An ML platform team still spends days debugging accuracy drops because they must manually cross-reference spreadsheets, data catalogs, and model registries across hundreds of models. Which architectural change most directly fixes this?
Show the answer
Answer: d · Building a unified lineage graph with automated hooks connecting raw sources, transformations, training runs, and deployments
A unified lineage graph with automated hooks treats lineage as a connected graph problem, enabling traversal from a deployed model back to raw data and transformations. Options A and B address only fragments of the pipeline, while D merges storage without guaranteeing the relationships or automated capture needed for root-cause analysis.
Read the full bite: How to establish data lineage and reproducibility for hundreds of ML models
Question 18 of 30
Why is deduplication a critical stage when preparing a massive dataset for foundation-model training?
Show the answer
Answer: b · Duplicates waste training compute and can skew the model toward over-represented samples
Duplicate and near-duplicate samples inflate compute and bias the model toward repeated content. Corruption detection and PII filtering are separate stages with their own purposes.
Read the full bite: Scalable multi-modal data quality pipeline
Question 19 of 30
A model degrades in production because separate batch and streaming pipelines produce slightly different values for the same feature. What does a feature store primarily solve here?
Show the answer
Answer: b · It ensures identical transformation logic is used for both training and real-time serving
A feature store prevents training-serving skew by governing the same transformations and definitions across batch and real-time contexts. Describing it as merely a cache or database misses its core consistency and governance role.
Read the full bite: What problems does a Feature Store solve in ML systems?
Question 20 of 30
When would you choose an online feature store over an offline store for a production system?
Show the answer
Answer: d · When you need millisecond-scale lookups for real-time inference on fresh data
Online feature stores are optimized for millisecond-scale lookups and real-time serving, while offline stores handle batch training and large historical datasets. Treating the offline store as a slower interchangeable backup or using a single database ignores the latency and access-pattern trade-offs that make the architectures distinct.
Read the full bite: Online vs offline feature store architecture and use cases
Question 21 of 30
Which approach best detects training-serving skew for a critical numerical feature requiring sub-hour detection?
Show the answer
Answer: b · Compute distribution divergence metrics like PSI over sliding windows, with severity-based tiered alerting and minimum sample size guards
The card emphasizes comparing aggregate distributions via PSI or KS over sliding windows, not raw values, and advocates tiered alerts with sample size checks. Option D is tempting because row-level validation seems rigorous, but it cannot detect population drift and contradicts the card's red flag of comparing individual values instead of distributions.
Read the full bite: Design a system to detect training-serving skew for a numerical feature
Question 22 of 30
What design choice most directly enables meeting a sub-20ms p99 for online feature serving?
Show the answer
Answer: c · Precomputing features via streaming and serving them as in-memory key-value lookups
Turning the request path into a simple in-memory lookup over precomputed features keeps latency tight. Warehouse or columnar queries at request time are far too slow for a 20ms p99.
Question 23 of 30
When backfilling a 90-day feature for millions of users, which strategy best protects production while ensuring the backfilled data matches live logic?
Show the answer
Answer: d · Reuse the live feature pipeline on a separate batch cluster, process bounded daily partitions, stage the results, validate them, and promote atomically.
Reusing the live pipeline on isolated compute with bounded partitions prevents both resource contention and logic drift, while staging and validation ensure correctness before atomic promotion. Option B is tempting because off-peak hours feel safer, but duplicating logic creates silent drift and direct production access can still impact serving.
Read the full bite: Backfill a complex feature for millions of users without impacting production
Question 24 of 30
To guarantee exact reproducibility of a historical training dataset after both schema and data have evolved in the feature store, what should a pipeline pin?
Show the answer
Answer: d · Both the schema version and the data timestamp or commit ID
Reproducibility requires pinning both the schema version and the data snapshot because schema evolution and data history are independent dimensions; pinning only the schema version would retrieve current data rather than the exact historical state used for training.
Read the full bite: How would you implement versioning for feature definitions in a feature store?
Question 25 of 30
What is the central risk of using one model's embedding as a feature for a downstream model?
Show the answer
Answer: c · Updating the upstream model shifts the feature space, degrading the downstream model unless versions are pinned and coordinated
The downstream model is tied to a specific embedding version's geometry, so an unpinned upstream change causes silent skew and degradation. Dimensionality and feature type are not the core problem.
Question 26 of 30
A transaction event at 08:50 must be joined to a user profile table where the user upgraded to premium at 09:00. Which join behavior preserves point-in-time correctness for the training row?
Show the answer
Answer: a · Match the most recent profile row with a timestamp less than or equal to 08:50.
An AS OF join retrieves the latest dimension record known at or before the event timestamp, so the 08:50 event correctly sees the pre-upgrade standard tier. Option D is the most tempting distractor because joining on user_id alone and taking the latest record silently leaks future state into the training set.
Read the full bite: Design system ensuring point-in-time correctness for training data joins
Question 27 of 30
A platform team advocates for a declarative feature platform to reduce boilerplate. Which risk best illustrates why this choice could fail without the right organizational maturity?
Show the answer
Answer: b · The team must own the opinionated abstractions for checkpointing, schema evolution, and exactly-once semantics, requiring deep infrastructure expertise.
Declarative platforms centralize ownership of checkpoints, schema evolution, and exactly-once semantics within the platform team, so adopting one without that infrastructure maturity fails; option A describes imperative platforms, and D wrongly assumes declarative means no-code.
Read the full bite: Argue for declarative or imperative feature platforms with trade-offs
Question 28 of 30
Which scenario best illustrates the key operational advantage of using a model registry instead of dated pickle files for production deployment?
Show the answer
Answer: c · A serving system references an alias that is atomically switched to a validated version while keeping the previous version available for rollback.
A registry alias like @champion decouples promotion from code changes and enables atomic rollback, whereas dated pickle files require manual path updates and risk serving stale artifacts. Distractor D is wrong because treating the registry as merely a faster database for pickles misses the lifecycle abstraction entirely.
Read the full bite: Why use a Model Registry over dated pickle files?
Question 29 of 30
What should an automated pipeline validate after a model is tagged Staging but before it receives production traffic?
Show the answer
Answer: c · Data drift, performance regression, bias thresholds, schema compatibility, and security scanning
Before any traffic exposure, the pipeline must automatically validate data drift, performance regression, bias, schema compatibility, and security against production baselines. Option B is tempting because it mentions holdout metrics and model cards, but a signed card is a trigger rather than a validation gate, and holdout metrics alone omit critical production-specific checks like drift and bias.
Question 30 of 30
Which architecture best detects training-serving skew without impacting serving latency?
Show the answer
Answer: b · Versioned per-feature statistics in the model registry, asynchronous inference feature logging, and periodic statistical tests like PSI or KS against baselines
The correct design uses the model registry as a source of truth for immutable training statistics and asynchronously logs production feature vectors to compare distributions via PSI or KS without adding P99 latency. Option A is tempting because circuit breaking is a valid severe response, but performing distribution checks synchronously on every request would directly violate the latency constraint that the logging layer is meant to avoid.
Could you explain these out loud?
That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.