I85PREP
⌘ K
DE MLO study materials
DE MLO study resources

DE MLO practice questions

One question at a time. Build your DE MLO understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Experiment Tracking and Model Lifecycle

In an MLflow Tracking setup, which component stores the actual metric values, parameters, and artifacts for a run, while the tracking server exposes the API used by clients?

  1. The experiment description field on the tracking server
  2. The conda environment file committed with the project
  3. The backend store and artifact store configured for the tracking server Correct answer.
  4. The model signature saved alongside the logged model

Explanation

MLflow Tracking separates metadata from files: the backend store holds runs, params, metrics, and tags, while the artifact store holds files such as model weights. The tracking server is only the API layer in front of those two stores. An experiment description, a conda file, and a model signature are metadata or packaging details, not the run data store.

Question 2Experiment Tracking and Model Lifecycle

A team wants every training run to record the exact Git commit and the dataset version used. Which MLflow practice achieves this most directly?

  1. Rely on the experiment name to encode the branch and dataset version
  2. Enable autologging and assume the framework captures both values
  3. Store the commit hash only in the local shell history of the engineer
  4. Log the commit hash and dataset version as run tags or params at the start of each run Correct answer.

Explanation

Run tags and params are queryable metadata attached to a specific run, so logging the commit hash and dataset version there makes provenance explicit and searchable. Encoding values in an experiment name is not queryable per run and easily drifts. Autologging captures framework-level details but does not know which dataset version or commit your pipeline used.

Question 3Experiment Tracking and Model Lifecycle

What is the primary purpose of an MLflow Model Registry stage such as Staging or Production?

  1. To define the hyperparameter search space for tuning
  2. To store the raw training data used to fit a model version
  3. To track the lifecycle position of a registered model version for deployment decisions Correct answer.
  4. To replace the need for a version number on each model

Explanation

The registry assigns versions to models and lets you move them through lifecycle stages, which supports promotion and rollback decisions. Stages are labels for deployment readiness, not data storage or tuning configuration. Each registered model version still has a distinct numeric version regardless of stage.

Question 4Experiment Tracking and Model Lifecycle

Which statement correctly distinguishes an MLflow experiment from an MLflow run?

  1. An experiment and a run are synonyms and differ only in the UI tab used to view them
  2. An experiment stores only artifacts; a run stores only parameters
  3. An experiment is a single execution; a run is the named grouping of experiments
  4. An experiment is a named grouping of runs; a run is a single execution that records params, metrics, and artifacts Correct answer.

Explanation

MLflow organizes tracking around experiments, which are containers, and runs, which are individual executions logged inside an experiment. Each run holds its own params, metrics, tags, and artifacts. They are distinct entities, not synonyms, and runs can store all metadata types rather than only one.

Question 5Experiment Tracking and Model Lifecycle

A metric is logged repeatedly during training with MLflow's step argument. What does the step value enable?

  1. Encrypting the metric value before it is written to the backend store
  2. Grouping runs into the same experiment automatically
  3. Ordering and plotting the metric history along the training progression Correct answer.
  4. Overwriting earlier metric values so only the final one is kept

Explanation

The step argument timestamps each metric entry so the UI can render a history curve in the intended order. It does not encrypt values, and it preserves history rather than collapsing to a single value. Experiment membership is set when the run is created, not by step numbers.

Question 6Experiment Tracking and Model Lifecycle

Which artifact logging approach is appropriate for a large model checkpoint that should not be committed to the same storage as the run metadata database?

  1. Log the checkpoint to a configured artifact store such as object storage Correct answer.
  2. Write the checkpoint into the experiment description
  3. Encode the checkpoint in the run name string
  4. Insert the checkpoint bytes into a metric value field

Explanation

Artifacts are designed for files and are written to the artifact store, which is often object storage separate from the backend database. Metric values, run names, and descriptions are metadata fields with size and type limits unsuited to binary checkpoints. Keeping large files out of the metadata database also keeps queries fast.

Question 7Experiment Tracking and Model Lifecycle

In MLflow, what does logging a model with a signature accomplish?

  1. It selects the best hyperparameters from prior runs
  2. It automatically promotes the model to Production
  3. It compresses the model weights to reduce artifact size
  4. It records the expected input and output schema so the model can be validated and served consistently Correct answer.

Explanation

A model signature captures input and output column names and types, which lets serving validate requests and lets consumers understand expected data. It is schema metadata, not compression, tuning, or promotion logic. Promotion is a separate registry action.

Question 8Experiment Tracking and Model Lifecycle

Which practice best supports reproducibility when a run depends on a random seed?

  1. Record the seed only in a local notebook cell that is later cleared
  2. Assume the framework default seed is always identical across versions
  3. Store the seed in a comment inside the training script
  4. Log the seed value as a run parameter Correct answer.

Explanation

Logging the seed as a parameter makes it queryable and visible next to the resulting metrics, so a run can be recreated. Local notebook state, script comments, and default assumptions are not tracked with the run. Framework defaults can change across versions, so they cannot be trusted implicitly.

Question 9Experiment Tracking and Model Lifecycle

A data scientist wants to compare validation accuracy across fifty runs of the same experiment. Which MLflow capability is designed for this?

  1. Filtering and sorting runs in the experiment using logged metrics Correct answer.
  2. Renaming each run to include its accuracy in the title
  3. Reading the backend database schema directly with SQL joins
  4. Opening each run individually and copying values by hand

Explanation

The tracking UI and API support filtering and sorting runs by metric values, which is the intended way to compare many runs. Manual copying does not scale, and encoding values in run names duplicates data that should be a logged metric. Direct database access bypasses the supported interface and risks inconsistency.

Question 10Experiment Tracking and Model Lifecycle

An engineer registers a new model version, but the previous Production version must remain recoverable if the new one underperforms. What is the correct registry workflow?

  1. Delete the old version before promoting the new one
  2. Overwrite the old version's artifacts with the new weights
  3. Transition the new version to Production and archive the old version so it can be restored Correct answer.
  4. Create a new registered model name for every version to avoid conflicts

Explanation

Registry transitions are reversible, so archiving the prior version preserves it for rollback while the new version takes the Production stage. Deleting or overwriting the old version destroys the fallback. Creating a new model name per version fragments lineage and defeats version tracking.

Question 11Experiment Tracking and Model Lifecycle

When logging a metric with the same key and step multiple times in one run, what behavior should you expect from the tracking store?

  1. All values are summed into a single aggregate
  2. The run is automatically terminated on the second log
  3. The latest logged value for that key and step is retained as the recorded value Correct answer.
  4. The first logged value is locked and later ones are rejected

Explanation

For a given metric key and step, the store keeps the most recent value, so repeated logging at the same step overwrites rather than aggregates. Values are not summed, and the run is not terminated by logging. To preserve distinct points, use different step values.

Question 12Experiment Tracking and Model Lifecycle

A pipeline logs params before training and metrics after each epoch. Midway through a long run the process crashes. What is preserved in the tracking store?

  1. Only the artifacts are preserved because they are written last
  2. Nothing is preserved because the run never reached a terminal status
  3. Params and any metrics already logged before the crash remain recorded Correct answer.
  4. The entire run is rolled back to remove partial data

Explanation

Tracking writes are persisted as they occur, so params and metrics logged before the crash remain queryable even though the run has no terminal status. Artifacts are not special-cased to survive while metadata is lost. There is no automatic rollback that erases partial run data.

Question 13Experiment Tracking and Model Lifecycle

Which use of MLflow tags versus params is most consistent with their intended semantics?

  1. Store the learning rate as a tag and the architecture family as a param
  2. Store the model architecture family as a tag and the learning rate as a param Correct answer.
  3. Store both the learning rate and architecture as params only
  4. Store both the learning rate and architecture as tags only

Explanation

Params are the input settings that define a run's configuration, such as learning rate, while tags are flexible metadata labels useful for grouping and search, such as architecture family. Either value could technically be stored in both, but the intended split keeps configuration queryable as params and descriptive labels as tags.

Question 14Experiment Tracking and Model Lifecycle

A team uses a shared tracking server with a SQL backend and an object store for artifacts. Which configuration issue most likely explains why metrics appear in the UI but artifact downloads fail?

  1. The backend database has too many experiments
  2. The metric step values are non-monotonic
  3. Clients cannot reach or authenticate to the configured artifact store location Correct answer.
  4. The run names contain spaces

Explanation

Metadata and artifacts travel through different paths, so metrics appearing while downloads fail points to the artifact store being unreachable or misconfigured for credentials. Experiment count, run naming, and step ordering affect the UI experience but not artifact transport.

Question 15Experiment Tracking and Model Lifecycle

What is the effect of calling MLflow's start_run with an existing run_id?

  1. It deletes the existing run and starts fresh
  2. It resumes logging into that existing run rather than creating a new one Correct answer.
  3. It creates a duplicate run that shares the same metrics
  4. It clones the run into a different experiment

Explanation

Passing an existing run_id reopens that run so additional params, metrics, or artifacts can be logged to it. It does not create a duplicate, delete, or move the run. This supports multi-process or resumed workflows.

Question 16Experiment Tracking and Model Lifecycle

A reviewer asks why a model version's source run should be linked in the registry. Which answer best reflects the lifecycle benefit?

  1. The link automatically retrains the model when data changes
  2. The link enforces a fixed learning rate at serving time
  3. The link connects the deployed artifact to its training run so params, metrics, and code context can be audited Correct answer.
  4. The link reduces the storage cost of the model artifact

Explanation

Registering a model from a run records the source run, giving an audit trail back to the parameters, metrics, and environment that produced the artifact. It is a provenance link, not a storage optimization, retraining trigger, or serving constraint.

Question 17Experiment Tracking and Model Lifecycle

Which scenario most clearly calls for creating a new experiment rather than reusing an existing one?

  1. Logging one more epoch to an existing training run
  2. Adding a tag to a completed run
  3. Starting a distinct research question whose runs should be grouped separately Correct answer.
  4. Downloading artifacts from a prior run

Explanation

Experiments group runs that belong to the same line of investigation, so a distinct research question merits its own experiment to keep comparisons meaningful. Adding epochs, tagging, and downloading artifacts are operations on existing runs and do not require a new experiment.

Question 18Experiment Tracking and Model Lifecycle

A model is logged with MLflow and includes a requirements file and a sample input. What do these two additions primarily enable?

  1. Conversion of the model to a different framework
  2. Reproducible environment reconstruction and validation of expected input format at load or serve time Correct answer.
  3. Compression of the artifact store
  4. Automatic hyperparameter tuning of the model

Explanation

The requirements file records dependencies so the environment can be rebuilt, while the sample input documents and validates the expected input shape. Neither performs tuning, compression, or framework conversion. They support reproducibility and correct usage.

Question 19Experiment Tracking and Model Lifecycle

Two engineers log to the same experiment name from different machines but see separate run lists. Which cause is most plausible?

  1. They chose different artifact subdirectories
  2. Their runs have different step counts
  3. They used different metric names
  4. They are pointed at different tracking URIs or backend stores Correct answer.

Explanation

Runs appear in the same experiment only when both clients talk to the same tracking server and backend store, so divergent tracking URIs or stores explain separate run lists. Metric names, step counts, and artifact subdirectories affect content within runs but not which store the runs land in.

Question 20Experiment Tracking and Model Lifecycle

What distinguishes archiving a registered model version from deleting it?

  1. Archiving hides the version from active use while preserving its artifacts and history Correct answer.
  2. Archiving permanently removes artifacts while deleting only changes the stage
  3. Archiving moves the version to a different experiment
  4. Archiving and deleting are identical operations with different labels

Explanation

Archiving is a reversible lifecycle state that keeps the version and its artifacts intact while marking it inactive. Deleting removes the version and can destroy associated artifacts. They are not equivalent, and archiving does not relocate a version between experiments.

Question 21Experiment Tracking and Model Lifecycle

A team wants to enforce that only models with a passing evaluation metric can be promoted to Production. Which approach fits the model lifecycle best?

  1. Log the metric after promotion so it can be checked later
  2. Gate the stage transition in CI on the logged metric threshold for the candidate version Correct answer.
  3. Store the threshold in the model signature
  4. Rely on reviewers to remember the threshold when clicking promote

Explanation

Automated gating in CI checks the logged metric before allowing a registry transition, which makes the policy enforceable and repeatable. Manual memory is unreliable, and checking after promotion defeats the purpose. The signature describes schema, not promotion policy.

Question 22Experiment Tracking and Model Lifecycle

A run logs loss at steps 1 through 10, then the job restarts and logs loss again at steps 1 through 10 with new values. What does the tracking store most likely show for that metric history?

  1. The metric key is renamed automatically to avoid collision
  2. The store rejects the second set because steps must be unique forever
  3. Both sets are kept and summed at each step
  4. The later values replace the earlier ones at matching steps, so the history reflects the restarted values Correct answer.

Explanation

Because the store keeps the latest value per metric key and step, re-logging the same steps overwrites the earlier points. It does not sum duplicates, permanently lock steps, or rename keys. To preserve both attempts, the job should use distinct step ranges or separate runs.

Question 23Experiment Tracking and Model Lifecycle

Why is storing large datasets as run artifacts generally discouraged in favor of referencing an external data version?

  1. Run artifacts are deleted automatically at the end of each day
  2. Artifact stores are optimized for model and file outputs, and duplicating datasets inflates storage and slows metadata operations Correct answer.
  3. Artifacts cannot store files larger than one megabyte
  4. Referencing external data prevents any reproducibility

Explanation

Copying full datasets into every run multiplies storage and burdens the artifact path, while a versioned external reference records provenance without duplication. Artifacts can hold large files, so the one-megabyte claim is false. External references support reproducibility when the version is immutable, and artifacts are not auto-deleted daily.

Question 24Experiment Tracking and Model Lifecycle

A registered model has versions 1 and 2 in Production because two engineers transitioned concurrently. What is the most robust lifecycle fix?

  1. Move both versions to Staging and stop using Production
  2. Delete version 1 to force a single Production version
  3. Allow multiple Production versions and rely on clients to pick the newest
  4. Serialize promotions through a single automated pipeline step that transitions the prior version out before promoting the new one Correct answer.

Explanation

Concurrent manual transitions create ambiguous Production state, so a single serialized promotion step that demotes the prior version keeps exactly one Production version. Letting clients guess the newest version pushes ambiguity downstream. Deleting history or abandoning Production removes useful lifecycle signals.

Question 25Experiment Tracking and Model Lifecycle

An audit requires proving which code, data version, and hyperparameters produced a deployed model six months ago. Which combination of lifecycle records best satisfies this?

  1. The model's output signature, which records prediction types
  2. The current experiment description, which lists the team's general approach
  3. The serving logs, which show request volumes over time
  4. The registry version linked to its source run, whose params, tags, and logged environment capture code and data references Correct answer.

Explanation

The registry version points to the source run, and that run's params, tags, and environment artifact record the configuration, commit, and data version used at training time. A general description, serving traffic logs, and output schema do not identify the exact inputs and code. This chain is what makes the deployment auditable.

Question 26Experiment Tracking and Model Lifecycle

In MLflow, what is the primary purpose of the run ID?

  1. To uniquely identify a single execution of an experiment Correct answer.
  2. To specify the Python environment for the run
  3. To set the storage location for artifacts
  4. To name the experiment that groups related runs

Explanation

A run ID is a unique identifier automatically assigned when a run is created, used to reference that specific execution for logging, querying, and linking to model versions. It is not related to environment specification, experiment naming, or artifact storage paths, which are handled by other parameters.

Question 27Experiment Tracking and Model Lifecycle

An engineer wants to record the learning rate used in a training run so that it can be filtered and compared across runs later. Which MLflow logging method is appropriate?

  1. mlflow.log_artifact
  2. mlflow.set_tag
  3. mlflow.log_metric
  4. mlflow.log_param Correct answer.

Explanation

Parameters are intended for configuration values such as hyperparameters that are constant for a run and support filtering and comparison in the MLflow UI. Metrics are for numeric time-series values, artifacts for files, and tags for metadata not used as primary comparison axes.

Question 28Experiment Tracking and Model Lifecycle

Which MLflow component provides a centralized registry to manage model versions and their lifecycle stages?

  1. MLflow Model Registry Correct answer.
  2. MLflow Tracking
  3. MLflow Recipes
  4. MLflow Projects

Explanation

The Model Registry is the component that stores registered models, their versions, and stage transitions such as Staging and Production. Tracking records runs and metrics, Projects packages code, and Recipes provides predefined templates.

Question 29Experiment Tracking and Model Lifecycle

A data scientist wants to log the confusion matrix of a classifier as a file so that it can be viewed later in the MLflow UI. Which method should they use?

  1. mlflow.log_input
  2. mlflow.log_param
  3. mlflow.log_artifact Correct answer.
  4. mlflow.log_metric

Explanation

log_artifact stores a file or directory in the run's artifact store, making it accessible from the MLflow UI. Metrics and params store scalar values, and log_input records dataset metadata rather than arbitrary files.

Question 30Experiment Tracking and Model Lifecycle

A team wants to compare runs from two different experiments side by side in the MLflow UI. What is the most direct way to achieve this?

  1. Use the compare feature in the MLflow UI to select runs from multiple experiments Correct answer.
  2. Copy all runs into a single experiment using the API
  3. Tag each run with the experiment name and filter by tag
  4. Export both experiments to CSV and compare externally

Explanation

The MLflow UI's compare view allows selecting runs across experiments for side-by-side metric and parameter comparison. Copying runs or exporting data is unnecessary and loses the integrated comparison view.

Question 31Experiment Tracking and Model Lifecycle

When logging a metric with the same key and step multiple times within a single run, what is the default behavior in MLflow?

  1. The last logged value overwrites the previous one
  2. Both values are stored and the UI shows the latest Correct answer.
  3. The values are averaged automatically
  4. An error is raised for duplicate step

Explanation

MLflow stores all metric values with their timestamps and steps; when the same key and step are logged multiple times, the UI typically displays the most recent value, but history is retained. It does not overwrite or average by default, and duplicate steps are allowed.

Question 32Experiment Tracking and Model Lifecycle

An engineer wants to link a specific dataset version to a run for reproducibility. Which MLflow feature is designed for this?

  1. mlflow.set_tag with the dataset path
  2. mlflow.log_artifact with the dataset file
  3. mlflow.log_param with the dataset hash
  4. mlflow.log_input with a Dataset object Correct answer.

Explanation

mlflow.log_input records dataset metadata, including source and digest, directly on the run, enabling lineage tracking. Logging the file as an artifact stores a copy but does not create structured dataset lineage; tags and params are less structured for this purpose.

Question 33Experiment Tracking and Model Lifecycle

A model version in the registry is moved to the Archived stage. What is the effect on the model version?

  1. It is automatically transitioned to Staging
  2. It is removed from the registry but its artifacts are kept
  3. It is permanently deleted from the registry
  4. It remains in the registry but is hidden from default views and cannot be transitioned to other stages without unarchiving Correct answer.

Explanation

Archiving hides a model version from default listings and prevents stage transitions until it is unarchived, but the version and its artifacts are retained. It is not deleted, and it is not automatically moved to another stage.

Question 34Experiment Tracking and Model Lifecycle

What is the role of the source run when registering a model version in MLflow?

  1. It links the model version to the run that produced it, enabling traceability to code, parameters, and metrics Correct answer.
  2. It determines the storage location of the model artifacts
  3. It provides the environment for serving the model
  4. It sets the default stage for the model version

Explanation

The source run creates a link between the registered model version and the run that generated it, allowing users to trace back to the code, parameters, and metrics logged in that run. It does not define the serving environment, artifact storage, or default stage.

Question 35Experiment Tracking and Model Lifecycle

A team wants to ensure that every model version promoted to Production has a corresponding evaluation metric logged in its source run. Which approach is most aligned with MLflow's capabilities?

  1. Rely on the model registry's built-in metric validation
  2. Manually check the metric before transitioning the model version
  3. Use a CI/CD pipeline that queries the run's metrics via the MLflow API and only transitions if the metric meets criteria Correct answer.
  4. Log the metric as a tag on the model version and filter in the UI

Explanation

MLflow does not enforce metric-based promotion natively, so automation via API queries in a CI/CD pipeline is the standard approach to gate transitions. Manual checks are error-prone, the registry lacks built-in metric validation, and tags do not enforce promotion rules.

Question 36Experiment Tracking and Model Lifecycle

An engineer wants to log a plot generated during a run so that it appears in the MLflow UI. Which method should they use?

  1. mlflow.set_tag
  2. mlflow.log_metric
  3. mlflow.log_param
  4. mlflow.log_figure Correct answer.

Explanation

mlflow.log_figure saves a matplotlib figure as an artifact and links it to the run, making it viewable in the UI. Metrics, params, and tags store scalar or text values, not figures.

Question 37Experiment Tracking and Model Lifecycle

A run is started with mlflow.start_run() and the code inside the with block raises an exception. What is the default status of the run after the exception is handled?

  1. RUNNING
  2. KILLED
  3. FINISHED
  4. FAILED Correct answer.

Explanation

When an exception propagates out of the with block, MLflow marks the run as FAILED. FINISHED is set on normal completion, KILLED is for manually terminated runs, and RUNNING would only apply if the run were not properly closed.

Question 38Experiment Tracking and Model Lifecycle

A data scientist wants to search for all runs in an experiment where the metric 'accuracy' is greater than 0.9. Which MLflow feature should they use?

  1. Exporting all runs to a CSV and filtering in a spreadsheet
  2. Tagging runs with 'high_accuracy' and filtering by tag
  3. Manually inspecting each run's metrics
  4. The filter query syntax in the MLflow UI or API Correct answer.

Explanation

MLflow supports a filter query syntax that allows searching runs by metric values, parameters, and tags directly in the UI or API. Manual inspection or exporting is inefficient, and tagging is a manual workaround not based on actual metric values.

Question 39Experiment Tracking and Model Lifecycle

An MLflow tracking server is configured with a SQL backend and an artifact store. A user reports that metrics are visible in the UI but artifacts are missing. Which configuration issue is most likely?

  1. The SQL backend is not running
  2. The run ID is incorrect
  3. The metric logging is failing silently
  4. The artifact store URI is misconfigured or inaccessible Correct answer.

Explanation

If metrics (stored in the backend store) are visible but artifacts are not, the artifact store URI is likely misconfigured or the storage location is inaccessible. A failed SQL backend would affect metrics, and an incorrect run ID would prevent viewing the run at all.

Question 40Experiment Tracking and Model Lifecycle

A team wants to enforce that only model versions with a specific tag 'approved' can be transitioned to Production. Which approach is most effective within MLflow?

  1. Implement a custom validation step in the deployment pipeline that checks the tag before calling the transition API Correct answer.
  2. Log the tag as a metric and set a threshold in the UI
  3. Use the model registry's stage transition rules to require the tag
  4. Rely on engineers to manually check the tag before transitioning

Explanation

MLflow does not natively enforce tag-based conditions for stage transitions, so the most effective approach is to add a validation step in the deployment pipeline that queries the tag and only proceeds if it is present. Manual checks are unreliable, and metrics cannot enforce tag conditions.

Question 41Model Development, Training, and Tuning

In PyTorch, which construct makes a model's parameters available to an optimizer while also enabling gradient computation during the training loop?

  1. A plain Python list holding tensors with requires_grad=False
  2. A frozen model exported with torch.jit.trace
  3. torch.nn.Module with parameters registered as torch.nn.Parameter Correct answer.
  4. A NumPy array wrapped in torch.as_tensor

Explanation

Parameters registered on an nn.Module via torch.nn.Parameter are discovered by model.parameters() and are automatically tracked by autograd, so an optimizer can update them. Tensors with requires_grad=False, NumPy arrays, and traced frozen graphs do not expose trainable parameters to the optimizer in the normal training loop.

Question 42Model Development, Training, and Tuning

A team wants each training example to be seen once per epoch with shuffling and mini-batches. Which PyTorch component provides this directly?

  1. torch.autograd.grad
  2. torch.utils.data.DataLoader Correct answer.
  3. torch.optim.lr_scheduler
  4. torch.nn.functional

Explanation

DataLoader wraps a Dataset and handles batching, shuffling, and iteration order per epoch. Optimizers, schedulers, and autograd utilities operate on parameters or gradients rather than on dataset iteration.

Question 43Model Development, Training, and Tuning

Which statement correctly describes the role of a loss function during supervised training?

  1. It selects the mini-batch size for each epoch
  2. It defines the scalar objective whose gradient drives parameter updates Correct answer.
  3. It stores the optimizer state between steps
  4. It normalizes input features before the first layer

Explanation

The loss reduces model output and targets to a scalar that quantifies error; backpropagation differentiates this scalar with respect to parameters. Feature normalization, optimizer state, and batch sizing are handled by other components.

Question 44Model Development, Training, and Tuning

During training you call optimizer.zero_grad() before loss.backward(). What problem does this prevent?

  1. Dead ReLU activations in hidden layers
  2. Mismatch between batch size and learning rate
  3. Overflow of the learning rate schedule
  4. Gradient accumulation across iterations from previous backward passes Correct answer.

Explanation

PyTorch accumulates gradients into .grad by default, so without zeroing, gradients from prior iterations are added to the current ones. zero_grad() clears those buffers before the new backward pass. It has no effect on activation behavior or hyperparameter matching.

Question 45Model Development, Training, and Tuning

What is the primary purpose of splitting data into training, validation, and test sets?

  1. To increase the total number of available examples
  2. To reduce the number of parameters that must be learned
  3. To guarantee the model reaches zero training loss
  4. To estimate generalization on unseen data while tuning with a separate held-out set Correct answer.

Explanation

The validation set guides model selection and hyperparameter tuning, while the test set provides an unbiased estimate of performance on unseen data. Splitting does not create new examples, guarantee zero loss, or change parameter counts.

Question 46Model Development, Training, and Tuning

Which TensorFlow/Keras call configures a model for training with a given optimizer, loss, and metrics?

  1. model.predict()
  2. model.evaluate()
  3. model.fit()
  4. model.compile() Correct answer.

Explanation

compile() attaches the optimizer, loss, and metric objects that define the training objective and reporting. fit() then runs the training loop using that configuration, while evaluate() and predict() perform inference.

Question 47Model Development, Training, and Tuning

A model trained for many epochs shows training loss decreasing while validation loss rises. Which interpretation is most accurate?

  1. The learning rate is too low and must be reduced further
  2. The optimizer has stopped updating parameters
  3. The model is overfitting and early stopping or regularization should be considered Correct answer.
  4. The validation set is too large and should be merged into training

Explanation

Diverging training and validation curves are the classic signature of overfitting, where the model memorizes training data and loses generalization. Early stopping, weight decay, dropout, or more data are typical remedies. A stalled optimizer would not produce a steadily falling training loss.

Question 48Model Development, Training, and Tuning

Which technique reduces overfitting by randomly setting a fraction of activations to zero during training?

  1. Batch normalization
  2. Dropout Correct answer.
  3. Gradient clipping
  4. Weight initialization

Explanation

Dropout stochastically zeroes activations during training, which discourages co-adaptation and acts as a regularizer. Batch normalization stabilizes activations, initialization sets starting weights, and gradient clipping controls update magnitude.

Question 49Model Development, Training, and Tuning

You want to fine-tune a pretrained image classifier for a new dataset with 10 classes instead of the original 1000. What change is required on the final layer?

  1. Increase the input image resolution to 1000 pixels
  2. Freeze every layer including the classifier head
  3. Replace the output layer with a new layer producing 10 logits Correct answer.
  4. Remove the loss function and use accuracy directly

Explanation

The final layer's output dimension must match the new number of classes, so a fresh 10-unit layer is initialized and trained. Freezing all layers would leave the head untrained, resolution is unrelated, and training still requires a differentiable loss.

Question 50Model Development, Training, and Tuning

Which optimizer adapts a separate learning rate per parameter using estimates of first and second moments of the gradients?

  1. L2 weight decay
  2. Adam Correct answer.
  3. Learning rate warmup
  4. Stochastic gradient descent with momentum

Explanation

Adam maintains running estimates of the gradient mean and squared gradient, using them to scale per-parameter updates. Momentum SGD uses only a velocity term, warmup is a schedule, and weight decay is a regularization term.