Top 30 Advanced MLOps & Infrastructure Interview Questions and Answers

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.

1. Question 1 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?

   • aPrioritize 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.
   • bBuild a custom Kubernetes orchestrator and real-time GPU serving cluster to minimize latency, deferring data lineage tooling until the team grows.
   • cBuild the feature store and model registry in-house to avoid vendor lock-in, using open-source monitoring with minimal configuration to keep costs low.
   • dPurchase managed feature engineering pipelines and model training platforms, but build custom experiment tracking and observability stacks because production visibility is a core differentiator.
   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.

   Read the full bite: Design an MLOps platform for a mid-sized company: components and build-vs-buy trade-offs

2. Question 2 of 30

   Which promotion flow best reflects a robust automated testing strategy for a weekly retrained production model?

   • aOffline 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
   • bOffline accuracy check, then an A-B test on 50% of users, then manual review of predictions before full rollout
   • cData validation on the training set, then shadow deployment on 100% of live traffic, then promotion if prediction distributions match the incumbent model
   • dCanary deployment on 5% of traffic with predictions logged but not served, followed by offline accuracy validation, then rollout based on offline accuracy exceeding the previous version
   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

3. Question 3 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?

   • aKeep separate Spark and Python implementations synchronized through manual code reviews and unit tests before each deployment
   • bUse a shared transformation library for both paths, serve from a versioned feature store, and log features at training time for replay validation
   • cFocus on monitoring data distribution drift between the training warehouse and the live stream, alerting when distributions diverge
   • dRun the same heavy batch ETL pipeline online to ensure identical inputs, accepting higher latency for correctness
   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.

   Read the full bite: How do you guarantee identical feature engineering for training and real-time inference?

4. Question 4 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?

   • aThe 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.
   • bKV stores provide strong consistency guarantees required for monetary billing features, whereas in-memory caches only support at-least-once semantics.
   • cMerging at the serving layer is only possible when the two stores use identical serialization formats such as Flatbuffers; mixing storage types would require expensive transformation logic.
   • dIn-memory caches enforce schema-on-write, preventing training-serving skew, whereas KV stores use schema-on-read for backward compatibility with historical feature versions.
   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

5. Question 5 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?

   • aEnforcing immutable dataset IDs for all training data before it enters the feature store
   • bMigrating the data catalog and model registry into a single shared database
   • cMandating that every team use the same experiment tracking tool for hyperparameter logging
   • dBuilding a unified lineage graph with automated hooks connecting raw sources, transformations, training runs, and deployments
   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

6. Question 6 of 30

   Why is deduplication a critical stage when preparing a massive dataset for foundation-model training?

   • aIt is the only way to detect corrupt media files
   • bDuplicates waste training compute and can skew the model toward over-represented samples
   • cRemoving duplicates eliminates the need for PII filtering
   • dIt guarantees the dataset fits on a single machine
   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

7. Question 7 of 30

   What is the central risk of using one model's embedding as a feature for a downstream model?

   • aEmbeddings are always too high-dimensional to store
   • bEmbeddings remove the need to monitor data drift
   • cUpdating the upstream model shifts the feature space, degrading the downstream model unless versions are pinned and coordinated
   • dDownstream models cannot accept numeric features
   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.

   Read the full bite: Managing model-as-a-feature pipelines

8. Question 8 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?

   • aMatch the most recent profile row with a timestamp less than or equal to 08:50.
   • bRecover the profile table version committed closest to 08:50 using transaction metadata.
   • cMatch the profile row whose timestamp exactly equals 08:50.
   • dMatch the latest profile row for that user without considering event time.
   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

9. Question 9 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?

   • aFeature engineers will need to manually wire dependencies and manage idempotency for every pipeline, increasing toil as headcount grows.
   • bThe team must own the opinionated abstractions for checkpointing, schema evolution, and exactly-once semantics, requiring deep infrastructure expertise.
   • cDeclarative DSLs limit all pipelines to simple transformations, preventing the implementation of custom business logic.
   • dEnd users lose the ability to mix spot instances and targeted instance types, making large-scale batch jobs prohibitively expensive.
   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

10. Question 10 of 30

    Which architecture best detects training-serving skew without impacting serving latency?

    • aSynchronous feature distribution checks on every request with circuit breaking for outliers
    • bVersioned per-feature statistics in the model registry, asynchronous inference feature logging, and periodic statistical tests like PSI or KS against baselines
    • cLogging model predictions and comparing their distribution to training label distributions
    • dSchema validation in the inference pipeline combined with weekly manual SQL audits
    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.

    Read the full bite: How would you design a system to detect training-serving skew using model registry metadata?

11. Question 11 of 30

    Which strategy best satisfies the requirement that no static credential ever be stored in an image layer, on host disk, or exposed via the container's procfs?

    • aUsing a BuildKit secret mount during the Docker image build process
    • bInjecting the secret as an environment variable at runtime via the orchestrator
    • cMounting the host's dot-env file containing the secret as a bind volume
    • dAttaching a cloud IAM role through OIDC-based workload identity integration
    Show the answer

    Answer: d · Attaching a cloud IAM role through OIDC-based workload identity integration

    Cloud IAM integration such as AWS IRSA or GCP Workload Identity eliminates static credentials entirely by issuing temporary OIDC tokens, whereas runtime environment variables still expose static secrets through procfs and cannot be changed without a restart.

    Read the full bite: Describe two secure methods for providing secrets to a running container

12. Question 12 of 30

    Which combination best shrinks a PyTorch serving image while preserving operational rigor and layer hygiene?

    • aPlace rm -rf /root/.cache/pip in a separate RUN after pip install in a single-stage build
    • bUse a single-stage nvidia/cuda:devel image, then run docker squash to flatten layers
    • cBuild in a devel stage, copy artifacts to a runtime stage, and collapse cleanup into the install RUN
    • dSwitch the final stage to python:3.11-alpine and install PyTorch from source
    Show the answer

    Answer: c · Build in a devel stage, copy artifacts to a runtime stage, and collapse cleanup into the install RUN

    The correct approach uses multi-stage builds to exclude devel libraries and collapses cleanup into the installation RUN so intermediate files never commit to a layer. The most tempting distractor, docker squash, merely hides bloat rather than fixing build hygiene, and separate RUN cleanups still preserve deleted files in underlying layers.

    Read the full bite: Strategies to reduce a 5GB ML Docker image size

13. Question 13 of 30

    In the described notebook platform, what happens after 30 minutes of user inactivity to optimize cost while preserving work?

    • aThe user's namespace is deleted and recreated on next login using an S3-backed home directory
    • bThe Notebook Controller migrates the Pod to a spot instance with checkpointed GPU state
    • cAn idle manager scales the notebook Pod to zero, saving state to the persistent volume claim
    • dThe underlying EC2 instance hibernates and container memory is saved to an EBS snapshot
    Show the answer

    Answer: c · An idle manager scales the notebook Pod to zero, saving state to the persistent volume claim

    The card describes an idle manager that scales the Pod to zero after a timeout while saving state to the PVC, avoiding compute costs without destroying user data. Option D reflects a VM-centric misconception that ignores the Kubernetes-native design, while D incorrectly suggests destroying the namespace rather than suspending the Pod.

    Read the full bite: Design on-demand containerized dev environments for data scientists

14. Question 14 of 30

    Which architecture best prevents starvation and noisy-neighbor interference in a multi-tenant GPU cluster?

    • aStatic node pools per team using node labels and the default kube-scheduler
    • bNamespace ResourceQuotas, Kueue fair-share queues, and MIG profiles for hardware isolation
    • cPriorityClass tiering with graceful preemption, MIG partitioning, and the default kube-scheduler with ResourceQuotas
    • dDefault kube-scheduler with PriorityClasses, namespace GPU limits, and time-slicing on all nodes
    Show the answer

    Answer: b · Namespace ResourceQuotas, Kueue fair-share queues, and MIG profiles for hardware isolation

    This pairs namespace governance with fair-share scheduling to prevent starvation and hardware isolation to block memory bandwidth contention. D is tempting because it includes preemption, MIG, and quotas, but the default kube-scheduler lacks fair-share and gang scheduling semantics, so starvation remains likely.

    Read the full bite: Design multi-tenant GPU cluster scheduling and preemption policies

15. Question 15 of 30

    How should a CI/CD pipeline enforce a fairness constraint on a candidate model?

    • aLog subgroup metrics as warnings while always allowing the deploy to proceed
    • bCompute sliced subgroup metrics and exit nonzero to block promotion when a threshold is breached
    • cRun fairness checks manually after deployment
    • dGate solely on aggregate accuracy across the full test set
    Show the answer

    Answer: b · Compute sliced subgroup metrics and exit nonzero to block promotion when a threshold is breached

    Enforcement requires sliced metrics compared to thresholds that fail the build and block deployment. Aggregate accuracy hides subgroup harm, and warning-only or post-deploy checks do not prevent shipping a violating model.

    Read the full bite: Fairness and robustness gates in CI/CD

16. Question 16 of 30

    Which approach best handles a backward-compatible additive enum value in an ML CI pipeline while minimizing manual toil and preventing silent corruption?

    • aFail the CI build and require a manual allow-list update for the new value before downstream processing can resume.
    • bUse a hash-based embedding for the new value but disable structural schema validation to avoid future CI interruptions.
    • cReject the value as a data-quality exception and roll back the upstream deployment to restore the previous schema.
    • dAuto-approve the change under a versioned contract, handle the value with a model-side unknown bucket, and alert without blocking.
    Show the answer

    Answer: d · Auto-approve the change under a versioned contract, handle the value with a model-side unknown bucket, and alert without blocking.

    The correct answer captures the card's core design: versioned contracts auto-approve additive changes, model-side unknown buckets prevent crashes, and non-blocking automation reduces toil. Option B is tempting because hash-based embeddings are a valid resilience tactic, but disabling structural validation invites silent corruption and training-serving skew, which is a major red flag.

    Read the full bite: How would you design safe, automatic schema evolution in CI?

17. Question 17 of 30

    Why is contract testing especially important in a microservice-based ML system?

    • aIt eliminates the need for API versioning
    • bIt replaces the need for any unit tests in each service
    • cIt allows all services to be deployed as a single unit
    • dServices evolve independently, so verifying interface and data-schema expectations catches breaking changes before integration
    Show the answer

    Answer: d · Services evolve independently, so verifying interface and data-schema expectations catches breaking changes before integration

    Independent release cadences make interface and schema drift the main risk; consumer-driven contract tests catch breaks in the producer's pipeline early. It complements, not replaces, unit tests and versioning.

    Read the full bite: CI/CD for microservice-based ML systems

18. Question 18 of 30

    When p95 TTFT exceeds SLO while per-token latency remains healthy, which remediation should you prioritize before changing model architecture?

    • aImmediately deploy a smaller or quantized model variant
    • bIncrease the dynamic batching token limit to maximize throughput
    • cAdd GPU replicas to distribute request load
    • dInspect queuing depth and right-size batching limits based on tracing data
    Show the answer

    Answer: d · Inspect queuing depth and right-size batching limits based on tracing data

    High TTFT with healthy per-token latency signals queuing or batching bottlenecks rather than raw execution speed, so structured debugging targets queue depth and batch limits first. Adding replicas assumes compute saturation without profiling, and increasing batch limits can actually worsen TTFT by delaying first-token delivery.

    Read the full bite: How would you systematically debug an inference API latency breach?

19. Question 19 of 30

    A fleet of ten thousand battery-powered edge cameras needs frequent model updates without mass failures. Which strategy best addresses flash wear and the risk of bricking remote units?

    • aDeploy complete model images during peak solar charging and validate updates using cloud-based test suites before release
    • bPackage updates as delta patches, write them to an inactive A-B partition, and promote the partition only after on-device golden-set validation passes
    • cStream inference outputs continuously to the cloud and perform model retraining centrally, pushing full weights when training converges
    • dQuantize models to INT8 to reduce memory footprint, then rely on synchronous over-the-air pushes whenever Wi-Fi becomes available
    Show the answer

    Answer: b · Package updates as delta patches, write them to an inactive A-B partition, and promote the partition only after on-device golden-set validation passes

    Delta patches minimize flash wear compared to full redeployments, and A-B partitioning with local validation gates prevents a bad update from bricking remote devices. Option D is tempting because INT8 quantization helps fit the model, but synchronous pushes without atomic rollback or battery-aware scheduling still risk mass failures on intermittent networks.

    Read the full bite: Architectural challenges for deploying ML models on resource-constrained edge devices

20. Question 20 of 30

    When using SageMaker shadow tests to validate a new GPU model before a blue/green traffic shift, why is it important to keep the shadow test duration short?

    • aThe blue fleet cannot be terminated until the shadow test ends, delaying the elimination of idle GPU capacity
    • bCloudWatch baking-period alarms are disabled during shadow mode, leaving the deployment without automated rollback protection
    • cRunning both fleets in parallel duplicates inference compute costs while the green fleet processes mirrored requests not served to users
    • dShadow tests prevent the green fleet from auto-scaling, risking insufficient capacity during unexpected spikes
    Show the answer

    Answer: c · Running both fleets in parallel duplicates inference compute costs while the green fleet processes mirrored requests not served to users

    Shadow testing mirrors live requests to the green fleet without serving responses, so both fleets consume GPU compute simultaneously; prolonging this needlessly doubles inference costs. Option A is tempting but wrong because during the shadow test the blue fleet is still actively serving production traffic, so it is not yet idle capacity.

    Read the full bite: Design cost-effective inference for spiky traffic without idle GPUs

21. Question 21 of 30

    Which design best balances cost efficiency and latency for hundreds of infrequently used models sharing limited GPU memory?

    • aMaintain a separate always-on GPU endpoint for every model to guarantee instant availability
    • bLoad the entire model catalog into a single monolithic container at startup
    • cPin a small hot set in VRAM, cache the working set with LRU eviction, and return 202 while loading uncached models asynchronously
    • dScale each model to zero independently and synchronously load weights from remote storage on every request
    Show the answer

    Answer: c · Pin a small hot set in VRAM, cache the working set with LRU eviction, and return 202 while loading uncached models asynchronously

    This uses a shared pool with tiered caching to keep costs low while mitigating cold starts via async loading; D is tempting but wrong because synchronous remote loading on every request imposes severe latency penalties the card explicitly warns against.

    Read the full bite: Design a multi-model serving architecture for infrequently used models

22. Question 22 of 30

    In an automated root-cause system, what does it mean when a frozen baseline and the production model both degrade equally on new labels?

    • aFeature drift has occurred but concept drift has not yet been confirmed
    • bThe performance drop should be remedied by immediately retraining the production model
    • cThe underlying concept has drifted, indicating a shift in the real-world environment
    • dTraining-serving skew is causing the production pipeline to compute features incorrectly
    Show the answer

    Answer: c · The underlying concept has drifted, indicating a shift in the real-world environment

    The card explains that equal degradation between a frozen baseline and the production model indicates concept drift, meaning the world has shifted. Distractor A describes training-serving skew, which the card identifies as the root cause when only the production model degrades, not both.

    Read the full bite: Design an automated system to diagnose model performance drop root causes

23. Question 23 of 30

    Which approach best detects systemic model degradation across a high-cardinality fleet without causing alert fatigue?

    • aMaintain per-customer dashboards with hand-tuned thresholds and daily manual reviews
    • bLog every prediction and trigger immediate pages for any customer whose feature distribution changes
    • cRely on a single global accuracy metric and synchronous retraining of all models monthly
    • dAggregate models into cohorts, baseline against peers, and alert on fleet-wide drift percentages while batching individual outliers into digests
    Show the answer

    Answer: d · Aggregate models into cohorts, baseline against peers, and alert on fleet-wide drift percentages while batching individual outliers into digests

    Cohort-based aggregation and hierarchical alerting surface systemic issues sub-linearly while preventing operator fatigue. A is a common trap because per-customer dashboards feel thorough but do not scale past a few dozen instances.

    Read the full bite: How do you monitor thousands of per-customer models as a fleet?

24. Question 24 of 30

    Which architecture correctly separates drift detection from retraining while embedding safeguards against runaway costs and unstable deployments?

    • aA scheduled daily pipeline retrains on recent data, using drift metrics solely to decide whether to promote the new model.
    • bCloudWatch alarms launch retraining on every drift alert, using the Model Registry to block promotion if the candidate fails validation.
    • cModel Monitor emits drift metrics to CloudWatch; EventBridge triggers retraining only after sustained alarm breaches and cooldowns expire.
    • dModel Monitor directly invokes the SageMaker training pipeline when feature distributions exceed baseline thresholds.
    Show the answer

    Answer: c · Model Monitor emits drift metrics to CloudWatch; EventBridge triggers retraining only after sustained alarm breaches and cooldowns expire.

    The correct answer reflects the required separation of concerns: detection emits metrics, a decision layer enforces sustained thresholds and cooldowns, and only then executes retraining. The most tempting distractor, direct invocation by Model Monitor, removes the intermediate decision layer and risks unstable retraining loops and skyrocketing compute costs.

    Read the full bite: Design concept drift detection with automated retraining safeguards

25. Question 25 of 30

    What is the primary architectural benefit of separating the instance-sizing decision from the actual compute provisioning step in a dynamic training pipeline?

    • aIt guarantees spot instances will not be interrupted during critical training phases
    • bIt reduces cold-start latency by reusing previously provisioned instances across different job types
    • cIt prevents out-of-memory crashes and over-provisioning by matching hardware to workload characteristics before nodes spin up
    • dIt enables the use of serverless functions for lightweight training orchestration
    Show the answer

    Answer: c · It prevents out-of-memory crashes and over-provisioning by matching hardware to workload characteristics before nodes spin up

    Decoupling sizing from provisioning allows a metadata-driven router to match instance families to workload requirements before any hardware is launched, preventing both over-provisioning and out-of-memory crashes. The cold-start distractor is wrong because reusing instances across job types would typically leave workloads on ill-suited hardware, defeating dynamic right-sizing.

    Read the full bite: How would you architect dynamic training resource provisioning?

26. Question 26 of 30

    What is the key principle enabling fast automated rollback after a failed model deployment?

    • aAlways rolling forward with a hotfix instead of reverting
    • bKeeping the previous known-good version available so traffic can be rerouted to it instantly
    • cRequiring an engineer to manually swap the serving model
    • dDeleting the new model version immediately to free resources
    Show the answer

    Answer: b · Keeping the previous known-good version available so traffic can be rerouted to it instantly

    Preserving the last known-good version (via blue-green or canary) lets traffic shift back instantly on failure. Deleting the new model loses lineage, and manual or roll-forward approaches are slower and riskier under an incident.

    Read the full bite: Automated rollback for a failed model deploy

27. Question 27 of 30

    When building a soft-multi-tenant Kubernetes ML platform, which combination best prevents noisy neighbors, blocks lateral movement, and enables accurate chargeback without dedicated infrastructure per tenant?

    • aDedicated node pools per tenant, separate cloud subscriptions, and pod security standards
    • bNamespaces with ResourceQuotas and LimitRanges, network policies blocking cross-namespace traffic, and tenant labels feeding a metering pipeline
    • cNamespace RBAC, resource requests on pods, and user identity labels for cost tracking
    • dA single shared namespace with RBAC, pod security standards, and network policies allowing cross-tenant traffic to shared services
    Show the answer

    Answer: b · Namespaces with ResourceQuotas and LimitRanges, network policies blocking cross-namespace traffic, and tenant labels feeding a metering pipeline

    B correctly combines logical resource boundaries, network segmentation, and labeled metering for cost attribution. A tempts by mentioning RBAC and labels but fails to enforce hard resource limits and conflates user identity with tenant identity; C proposes hard isolation that violates the soft-tenancy constraint; D relies on RBAC-only separation in shared namespaces and permits lateral movement.

    Read the full bite: Design a multi-tenant ML platform with isolation, security, and cost attribution

28. Question 28 of 30

    Which combination of strategies best addresses GPU resource contention when a platform team must support both long-running distributed training and low-latency model serving on the same A100 cluster?

    • aSegmenting workloads by checkpointability and criticality, using PriorityClasses with preemption for training tiers, and reserving MIG slices for serving while keeping full GPUs for distributed training
    • bRouting all training jobs to GPU spot instances without checkpointing logic and using the default Kubernetes scheduler with topology-unaware placement
    • cPlacing all workloads into a single queue with namespace quotas and scaling the cluster horizontally whenever GPU pending pods exceed a threshold
    • dEnabling Multi-Instance GPU for all workloads and disabling preemption to avoid interrupting training jobs
    Show the answer

    Answer: a · Segmenting workloads by checkpointability and criticality, using PriorityClasses with preemption for training tiers, and reserving MIG slices for serving while keeping full GPUs for distributed training

    The correct approach segments workloads by checkpointability and criticality, applies PriorityClasses with preemption for training, and uses MIG only for serving to maximize utilization. Option C is tempting because horizontal scaling and quotas seem like straightforward fixes, but the card explicitly flags buying GPUs without scheduling logic and relying solely on quotas as inadequate solutions that ignore workload heterogeneity.

    Read the full bite: Propose an architectural solution for contended GPU training resources

29. Question 29 of 30

    Which combination of controls best ensures that no single actor can undetectably alter the lineage from an approved dataset to a deployed model?

    • aMerkleizing the dataset and binding the root hash to the model filename with dual-authorization deployment
    • bContent-addressing inputs, append-only provenance logging, build-time signing, and separation of audit duties
    • cEncrypting the dataset and model at rest while versioning all artifacts in Git
    • dStoring dataset and model hashes on a public blockchain and training in a confidential computing environment
    Show the answer

    Answer: b · Content-addressing inputs, append-only provenance logging, build-time signing, and separation of audit duties

    Encryption and Git do not prove lineage or prevent tampering, whereas the correct answer cryptographically binds inputs, uses an append-only log, signs the model, and separates audit duties to stop collusion. The blockchain distractor is tempting but represents the common mistake of choosing a public ledger without considering throughput, cost, or the lack of build-time signing and duty separation.

    Read the full bite: Design a cryptographically verifiable ML audit trail from dataset to deployment

30. Question 30 of 30

    Which approach best embodies a defense-in-depth strategy for protecting a deployed image classifier against adversarial evasion?

    • aRestricting model architecture details to internal teams to prevent attackers from computing effective perturbations
    • bEnforcing strict input format checks such as file extensions and dimension resizing before classification
    • cRelying primarily on adversarial training with PGD to ensure robustness within a known epsilon ball
    • dLayering JPEG preprocessing, embedding anomaly detection, graduated response to a secondary ensemble, and query rate limiting
    Show the answer

    Answer: d · Layering JPEG preprocessing, embedding anomaly detection, graduated response to a secondary ensemble, and query rate limiting

    Defense-in-depth requires combining training-time preprocessing with inference-time behavioral monitoring, graduated response, and operational controls. Option C relies on a single proactive layer that does not address the inference API attack surface, while option A represents security through obscurity and option B relies on superficial validation without anomaly detection or rate limiting.

    Read the full bite: Design a defense-in-depth strategy against adversarial evasion on a deployed image classifier