Top 30 Intermediate MLOps & Infrastructure Interview Questions and Answers
30 intermediate multiple-choice MLOps & Infrastructure interview questions, past the definitions: how the pieces fit together, what breaks in practice, and the trade-off behind a choice. They come from 30 bites in the MLOps & Infrastructure library, the middle slice of the 131 MLOps & Infrastructure interview questions in the 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
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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 of 30
You are running JupyterLab in Docker and need to persist both active notebook development and multi-gigabyte datasets across container restarts. Which approach best follows Docker best practices?
Show the answer
Answer: a · Use a bind mount for notebooks and a named volume for datasets, mounting the dataset read-only when appropriate
Bind mounts let host notebook edits sync immediately into the container, while named volumes persist datasets without tying them to a specific host path and remain portable across environments. Swapping them ignores the need for live code syncing, and COPY requires image rebuilds on every change.
Read the full bite: How do you persist notebooks and artifacts in Docker?
Question 15 of 30
In a multi-stage Dockerfile serving both dev and production targets, how should the production stage acquire the built application and its runtime dependencies?
Show the answer
Answer: b · Use COPY --from to pull only built artifacts from an earlier stage into a minimal image.
Multi-stage builds keep production images lean by copying only required artifacts via COPY --from into a minimal final stage. Using separate Dockerfiles or keeping dev tools in the production image bloats the image and increases the attack surface, which is exactly what this pattern aims to avoid.
Read the full bite: How do you build dev and production Docker images from one source?
Question 16 of 30
Which strategy best guarantees that CI and developers use bitwise-identical Docker dev environments without host-specific drift?
Show the answer
Answer: b · Build the image once, push it to a registry with an immutable tag or digest, and have both CI and developers pull that exact image
The card treats the built image—not the Dockerfile—as the immutable artifact to distribute, and pulling an exact tagged or digested image eliminates host dependency and cache variability. Option A is tempting because pinning a base image by digest is correct, but local rebuilds still reintroduce 'works on my machine' discrepancies from host caches and build contexts.
Read the full bite: How do you version and distribute Docker dev environments consistently?
Question 17 of 30
Adding GPU workers yields diminishing throughput gains. What is the most common root cause to investigate first?
Show the answer
Answer: d · Gradient synchronization communication overhead growing with worker count and interconnect limits
Data-parallel training all-reduces gradients each step, and that communication cost grows with workers and is bounded by interconnect speed, capping scaling. Learning rate and parameter count do not explain sublinear scaling.
Read the full bite: Diagnosing poor distributed training scaling
Question 18 of 30
A 10,000-GPU training cluster expects a hardware failure roughly every nine hours. Which checkpointing approach best balances throughput protection with recovery reliability?
Show the answer
Answer: c · Asynchronous checkpoints every tens of minutes using atomic finalization and tiered storage
Asynchronous writes prevent GPU stalls, an MTBF-driven cadence of tens of minutes bounds lost work to an acceptable window, and atomic finalization with tiered storage guarantees valid recoverable states. Option D is a common anti-pattern: synchronous daily checkpoints destroy throughput and risk losing a full day of compute, which is economically untenable at this scale.
Question 19 of 30
A team submits a distributed training job requiring eight GPUs on four nodes to a shared Kubernetes cluster. What is the main reason to use an advanced scheduler like Volcano or Kueue rather than the default Kubernetes scheduler?
Show the answer
Answer: d · It ensures the job waits until all eight GPUs are available before placing any pods, avoiding deadlock from partial allocation
The default scheduler may place only part of a distributed job, causing deadlock while reserved GPUs sit idle; advanced schedulers use gang scheduling to allocate all required resources together. The first distractor confuses the scheduler with the gateway submission abstraction layer described in the card.
Read the full bite: Design training job submission to a shared Kubernetes cluster
Question 20 of 30
In a hybrid ML pipeline, which scenario best justifies choosing Kubeflow over Airflow for a specific stage?
Show the answer
Answer: b · The stage requires distributed GPU autoscaling and native experiment tracking on Kubernetes
Kubeflow is purpose-built for Kubernetes-native distributed GPU training, autoscaling, and built-in experiment tracking. The most tempting distractor claims Airflow cannot run containers, but the card explicitly notes Airflow can orchestrate containerized workloads via KubernetesPodOperator, so that is a common misconception rather than a valid justification.
Read the full bite: Compare Airflow and Kubeflow for ML training pipelines
Question 21 of 30
An event-driven ML pipeline automatically retrains a fraud detection model. Which event is a reactive trigger caused by production model degradation?
Show the answer
Answer: b · A monitoring alert firing when the KS statistic between production and training feature distributions exceeds 0.1
The card classifies a KS drift alert as a reactive model performance event triggered by production degradation, whereas the cron job is proactive, the upstream message is an external completion event, and the regulatory refresh is a manual business trigger.
Read the full bite: What events trigger automatic model retraining beyond code changes?
Question 22 of 30
After shadow-deploying a model for 48 hours, which evidence best supports promoting it to full production traffic?
Show the answer
Answer: a · The shadow variant showed zero critical alarms, p99 latency under SLA, and no prediction drift in offline evaluation
Shadow predictions are never served to users, so measuring live click-through rates is impossible. Promotion is justified only when operational SLAs are met and offline evaluation against delayed ground truth confirms model quality.
Read the full bite: How would you implement shadow deployment and which metrics justify promotion?
Question 23 of 30
A monitoring alert detects data drift in production. What happens next in a properly designed Continuous Training pipeline before serving?
Show the answer
Answer: a · The alert triggers the orchestrator to retrain a candidate, evaluate it against the production baseline in the model registry, and promote it only after passing validation gates.
The card describes the flow as a trigger invoking the orchestrator to retrain and evaluate a candidate against the production baseline in the model registry, with promotion only after validation gates pass. Option C is tempting because it names real infrastructure, but it wrongly conflates CT with CI/CD by focusing on code deployment rather than data-driven model retraining and validation.
Read the full bite: What infrastructure is needed for a Continuous Training pipeline?
Question 24 of 30
A recommendation system shares a heavy user embedding across three models and needs a lightweight real-time inventory join for latency-sensitive requests. Where should each transform live?
Show the answer
Answer: c · Run the embedding lookup in a dedicated upstream service and the inventory join in the serving API
Placing the shared, heavy embedding lookup in a dedicated upstream service centralizes logic and reuse, while keeping the lightweight, latency-sensitive inventory join in the serving API avoids an extra network hop. Putting both in the serving API couples CPU-heavy work to the hot path, and using the client for embeddings risks training-serving skew and version drift.
Question 25 of 30
When designing a nightly pipeline to score millions of records with an XGBoost model, which approach best satisfies cost and reliability requirements?
Show the answer
Answer: a · Partition input in S3 by shard ID, run SageMaker Batch Transform on CPU spot instances, and implement idempotent retries per shard
The card recommends partitioning S3 data, using SageMaker Batch Transform on right-sized CPU spot instances, and designing idempotent shards so retries only reprocess failed batches. Option D is tempting because partitioning is correct, but GPUs are unnecessary for XGBoost and on-demand instances sacrifice the significant cost savings the card highlights.
Read the full bite: Design a system for batch scoring millions of customer records daily
Question 26 of 30
While diagnosing high latency in an online inference service, you see p99 latency rising sharply while GPU utilization remains flat. What is the most appropriate next step?
Show the answer
Answer: b · Inspect queue depth, batch size configuration, and autoscaling behavior
Flat GPU utilization alongside rising tail latency strongly signals a queuing bottleneck rather than a compute-bound model, so you should inspect batching and autoscaling first. Jumping straight to quantization is a common mistake because it assumes the model is saturated when the GPU is not.
Question 27 of 30
Which practice is essential when validating a quantized model before promoting it to production traffic?
Show the answer
Answer: a · Run downstream task benchmarks and shadow A/B against the full-precision model.
Downstream benchmarks and shadow A/B are required to catch inference-time regressions that aggregate metrics miss. File-size reduction alone is tempting because it confirms compression occurred, yet it says nothing about model quality or task performance.
Read the full bite: Explain model quantization, its benefits, drawbacks, and validation approach
Question 28 of 30
When A/B testing two live ML models that use different feature transformations, what is the most critical requirement to ensure a valid causal comparison?
Show the answer
Answer: a · Each model variant must use isolated transformation logic and feature stores to prevent preprocessing differences from confounding results.
Isolating feature stores and transformation logic prevents preprocessing differences from leaking between variants and confounding the experiment. Option B is tempting because identical freshness sounds correct, but sharing caches causes treatment leakage when transformation logic differs.
Read the full bite: How would you design an A/B test for two live ML models?
Question 29 of 30
Which architecture best balances low inference latency with continuous feature drift detection?
Show the answer
Answer: c · Emit feature vectors asynchronously to a stream processor that compares windowed distributions against a versioned training baseline using feature-specific thresholds
Asynchronous streaming keeps inference latency low while enabling continuous monitoring against a versioned baseline, and per-feature thresholds reduce false positives. Running synchronous tests inside the prediction API (A) adds unacceptable latency at scale and is a common anti-pattern.
Read the full bite: Design a system to monitor a real-time prediction service for feature drift
Question 30 of 30
When a model's output score distribution shifts in production, what is the recommended first step in diagnosing the root cause?
Show the answer
Answer: b · Check whether the input feature distribution P(X) has changed
You should check input features first for covariate shift, since output scores cannot change unless inputs or the model change. Immediately retraining without identifying the root cause is a common anti-pattern that treats drift as a monolithic problem.
Read the full bite: Model output distribution shifts. What are root causes and next steps?
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.