How many Refer to the Exhibit Practice Questions questions are on this page?

This page has 9 Refer to the Exhibit Practice Questions scenario questions for the PMLE exam, each with detailed explanations and wrong-answer analysis.

How should I approach PMLE scenario questions?

Read the full scenario before looking at the answer options. Identify the constraint or requirement in the scenario, then eliminate options that are generally true but wrong for this specific case. Scenario questions reward careful reading over pattern matching.

← Back to Google Professional Machine Learning Engineer questions

Scenario-based practice

Refer to the Exhibit Practice Questions

Practise Google Professional Machine Learning Engineer practice questions — original exam-style scenarios covering every exam domain, with detailed explanations, wrong-answer analysis, and common exam traps.

Start full practice test Read exam guide

scenario questions

PMLE

exam code

Google Cloud

vendor

Scenario guide

How to approach refer to the exhibit practice questions

Practise exhibit-style questions that ask you to read a topology, table, command output or diagram before choosing the best answer.

Quick answer

Exhibit-style questions test whether you can read a topology, command output, diagram or table before choosing the best answer.

How to extract the relevant detail from an exhibit.

How topology, command output or routing information affects the answer.

How to avoid answering from memory before reading the evidence.

How to map the exhibit back to the exam objective.

Practice scenarios

Question 1hardmultiple choice

Full question →

Refer to the exhibit. An alert policy is configured to trigger when prediction latency exceeds 500 ms for 5 consecutive minutes. The team is experiencing many false positive alerts during brief latency spikes. Which adjustment would most effectively reduce false positives while still detecting prolonged latency issues?

Exhibit

{
  "name": "projects/123/alertPolicies/456",
  "displayName": "High Latency",
  "conditions": [
    {
      "displayName": "Latency > 500ms",
      "conditionThreshold": {
        "filter": "metric.type=\"vertexai.googleapis.com/prediction/latency\"",
        "comparison": "COMPARISON_GT",
        "thresholdValue": 500,
        "duration": "300s"
      }
    }
  ],
  "combiner": "OR"
}

A
Change the comparison to less than
Why it fails: Reversing the comparison to less than would fire alerts when latency drops below 500 ms, inverting the intended condition entirely and missing genuine latency breaches. It is tempting because comparison operators are the visible trigger logic, but the stem's problem is spike duration, which only the sustained evaluation window setting addresses.
B
Add a condition that CPU utilization is also high
Why it fails: Adding a CPU condition might reduce false positives if latency spikes are not CPU-related, but it may also cause missed detections if high latency occurs without high CPU.
C
Increase the duration to 30 minutes
Extending the condition duration to 30 minutes requires latency to remain above 500 ms continuously for longer, filtering out brief spikes while still firing on sustained degradation. This directly reduces false positives without masking prolonged latency issues.
D
Increase the threshold to 1000 ms
Why it fails: Raising the threshold to 1000 ms suppresses brief spikes but also delays detection of genuine sustained latency between 500 and 1000 ms, weakening the prolonged-issue requirement. Threshold tuning is tempting because it directly reduces firing frequency. Widening the evaluation window instead preserves sensitivity to sustained breaches.

Full breakdown with real-world context →

Question 2mediummultiple choice

Full question →

The exhibit shows part of a Vertex AI Pipeline definition. The pipeline fails at the training step with an error: 'Missing required input: train_data'. What is the most likely cause?

Exhibit

Refer to the exhibit.

```
# vertex_ai_pipeline.yaml
components:
  - name: data_processing
    container:
      image: us-central1-docker.pkg.dev/my-project/my-repo/data_processor:v1
      command: ["python", "process.py"]
  - name: training
    container:
      image: us-central1-docker.pkg.dev/my-project/my-repo/trainer:v2
      command: ["python", "train.py"]
    inputs:
      - name: train_data
        type: Dataset
    outputs:
      - name: model
        type: Model
  - name: evaluation
    container:
      image: us-central1-docker.pkg.dev/my-project/my-repo/evaluator:v1
    inputs:
      - name: model
        type: Model
      - name: test_data
        type: Dataset
    outputs:
      - name: metrics
        type: Metrics
```

A
The evaluation step expects a metric output but training does not produce it
Why it fails: A metric-output mismatch would surface as an evaluation-step error about missing metrics, not a training-step error naming train_data. Output wiring matters when chaining evaluation to training, but here the training component never received its declared input, so the fault lies upstream.
B
The training step uses the wrong image tag
Why it fails: A wrong image tag causes an image-pull or entrypoint failure within the training step, not a missing-input message. Image tags matter when the component code itself must change version; here the training component started and reported that train_data was never supplied by its upstream producer.
C
The container command for data_processing is incorrect
Why it fails: An incorrect container command would typically produce a non-zero exit or command-not-found inside the data_processing step, not a missing-input error at training. Command arguments are the right thing to inspect when a step runs but misbehaves, not when an input is absent.
D
The data_processing step does not define any outputs
Vertex AI Pipelines passes data between steps through declared component outputs. If the data_processing component declares no output artifact, no train_data reference exists for the training step, so compilation or runtime reports the missing required input.
E
The pipeline is missing a deployment step
Why it fails: A missing deployment step would leave the model unserved after training, but the failure occurs at the training step itself, before any deployment runs. Deployment steps are added when the pipeline must register or serve a model, which is unrelated to resolving an unpopulated input artefact.

Full breakdown with real-world context →

Question 3mediummultiple choice

Full question →

Refer to the exhibit. A machine learning engineer deployed a model on Vertex AI using this configuration. When testing the endpoint, the engineer receives a 400 error with the message: 'Invalid argument: Explanation metadata missing required field: `outputs`.' What is the most likely cause?

Exhibit

Refer to the exhibit.

```yaml
deploymentResourcePool: projects/my-project/locations/us-central1/deploymentResourcePools/my-pool
disableContainerLogging: false
enableAccessLogging: true
explanationSpec:
  parameters:
    examples:
      exampleGcsSource:
        dataFormat: jsonl
        gcsSource:
          uris:
          - gs://my-bucket/examples/*.jsonl
        neighborCount: 10
      neighborCount: 10
      presampling: true
  metadata:
    inputs:
      input:
        inputTensor: input
        modality: numeric
        name: input
    outputs:
      output:
        outputTensor: output
        modality: numeric
        name: output
machineSpec:
  machineType: n1-standard-2
  acceleratorCount: 1
  acceleratorType: NVIDIA_TESLA_T4
minReplicaCount: 1
maxReplicaCount: 3
model: projects/my-project/locations/us-central1/models/123
trafficSplit:
  '0': 100
```

A
The explanation metadata outputs field is missing the required 'displayName' attribute.
Incorrect. The error is about missing outputs field, not just missing displayName.
B
The explanation metadata needs a 'baseline' configuration for the input.
Why it fails: Incorrect. Missing baseline is a different error.
C
The explanation metadata inputs field should be wrapped inside a 'visualization' block.
Why it fails: Incorrect. Visualization block is not relevant.
D
The explainability method chosen is not supported for the model type.
Why it fails: Incorrect. Unsupported method would give a different error.

Full breakdown with real-world context →

Question 4hardmultiple choice

Full question →

Refer to the exhibit. The team wants to automatically deploy the best-performing model version to production. They have set up a Cloud Function triggered by Model Registry events. Which alias should they use in the function to get the latest champion?

Network Topology

A
'champion'
The 'champion' alias conventionally indicates the best-performing production version.
B
''
Why it fails: An empty alias would not identify any version.
C
'experiment'
Why it fails: This alias is for experimental versions, not production.
D
'latest'
Why it fails: 'latest' is not a standard alias; the Model Registry does not automatically assign it.

Full breakdown with real-world context →

Question 5easymultiple choice

Full question →

Refer to the exhibit. A data scientist notices that predictions from a deployed model are taking longer than expected. Which Cloud Monitoring metric should be inspected first to identify the bottleneck?

Exhibit

Refer to the exhibit.
```
{
  "insertId": "abc123",
  "jsonPayload": {
    "predictions": [0.98, 0.12],
    "modelVersionId": "1",
    "latencyMs": 450,
    "region": "us-central1"
  },
  "resource": {
    "type": "vertex_ai_endpoint",
    "labels": {
      "endpoint_id": "1234",
      "model_id": "model-xyz"
    }
  },
  "severity": "INFO",
  "timestamp": "2024-03-15T10:30:00Z"
}
```

A
Vertex AI - Model - Compute utilization
Why it fails: Compute utilization covers training and batch resources, not the deployed endpoint's request path. It is the metric to inspect when jobs queue or GPUs saturate during training, but online prediction latency is measured at the endpoint, not on model compute.
B
Vertex AI - Endpoint - Prediction latency distribution
Prediction latency distribution reports the spread of response times for online predictions at the endpoint, isolating whether slow inference is the bottleneck. It satisfies the stem's requirement by measuring the deployed model's serving latency directly, rather than CPU, memory or request-count metrics.
C
Vertex AI - Endpoint - Traffic
Why it fails: Traffic reports request volume reaching the endpoint, showing load rather than response time. It is chosen when diagnosing capacity or quota pressure, but high throughput alone does not reveal where prediction latency is spent, so it cannot isolate the bottleneck.
D
Vertex AI - Endpoint - Online prediction errors
Why it fails: Online prediction errors counts failed requests, so it surfaces availability or 4xx/5xx problems rather than latency. It is the right metric when predictions fail outright, but the stem describes slow successful responses, which requires a latency metric.

Full breakdown with real-world context →

Question 6easymultiple choice

Full question →

Refer to the exhibit. A team deploys a model using Cloud Run. They notice that after scaling up, the new instances take about 90 seconds to become ready and serve requests. They want to reduce this startup time. Which configuration change is most likely to help?

Exhibit

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: model-serving
spec:
  template:
    spec:
      containers:
      - image: gcr.io/my-project/model:v2
        resources:
          limits:
            cpu: '2'
            memory: 8Gi
        startupProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 60
          periodSeconds: 10
      containerConcurrency: 80

A
Reduce the startupProbe initialDelaySeconds to 30
Why it fails: initialDelaySeconds delays when the startup probe first runs; it postpones readiness detection rather than shortening actual initialisation. Startup probes exist to tolerate slow-starting containers before liveness checks begin. Cutting the delay risks premature failure, and the 90-second load time remains unchanged.
B
Change the container image to use a smaller base image
A smaller base image reduces the bytes pulled and unpacked at instance start, shortening container initialisation before the model loads. Since the 90-second delay occurs during scale-up readiness, shrinking the image directly targets that startup time.
C
Reduce the memory limit to 4Gi
Why it fails: Lowering the memory limit constrains available RAM, which can slow or crash model loading rather than accelerate readiness. Memory limits exist to cap resource consumption and cost. Reducing startup time requires keeping warm instances or boosting CPU during startup, not shrinking memory.
D
Increase the containerConcurrency to 100
Why it fails: containerConcurrency caps simultaneous requests per instance; it does not shorten the 90-second model load and initialisation. Raising it suits high-throughput, low-latency services wanting fewer instances. Startup latency is addressed by minimum instances, startup CPU boost, or a smaller image.

Full breakdown with real-world context →

Question 7easymultiple choice

Full question →

Refer to the exhibit. A data scientist runs this Vertex AI training job code. What will be the outcome?

Exhibit

Refer to the exhibit.

training_job = aiplatform.CustomTrainingJob(
    display_name='hyperparameter-job',
    script_path='train.py',
    container_uri='gcr.io/cloud-aiplatform/training/tf-cpu.2-6:latest',
    requirements=['tensorflow==2.6'],
    model_serving_container_image_uri='gcr.io/cloud-aiplatform/prediction/tf2-cpu.2-6:latest',
)

hp_job = training_job.run(
    replica_count=1,
    machine_type='n1-standard-4',
    hyperparameter_tuning_job_spec={
        'max_trial_count': 10,
        'parallel_trial_count': 2,
        'metrics': [{'metric_id': 'accuracy', 'goal': 'MAXIMIZE'}]
    }
)

A
The job runs as a regular custom training with 10 replicas.
Why it fails: Hyperparameter tuning jobs with a defined parameter metric and search space run as tuning jobs, not custom training with replicas. It tempts because custom training does support replica counts, but the exhibit's tuning configuration overrides that interpretation.
B
A HyperparameterTuningJob is created and runs trials.
Passing a hyperparameter tuning configuration alongside the training script causes Vertex AI to launch a HyperparameterTuningJob rather than a single CustomJob. The service then runs multiple trials, each training with different hyperparameter values, and selects the best-performing trial.
C
A CustomJob is created with hyperparameters from the spec.
Why it fails: Submitting a training job with a custom training spec creates a CustomJob only when no hyperparameter tuning configuration is present; supplying a hyperparameter tuning spec causes a HyperparameterTuningJob instead. It is tempting because the spec resembles a plain custom job, but tuning parameters change the resource type created.
D
The job fails because parallel_trial_count cannot be less than max_trial_count.
Why it fails: Parallel trial count must be less than or equal to max trial count, not greater, so this constraint is satisfied and no failure occurs. It tempts because reversed limits genuinely trigger validation errors, but here the values comply, so the job proceeds normally.

Full breakdown with real-world context →

Question 8easymultiple choice

Full question →

Refer to the exhibit. The team notices that the pipeline fails to read data from the specified Cloud Storage path. What is the most likely issue?

Exhibit

pipeline:
  execution_config:
    runner: DataflowRunner
    project: my-project
    region: us-central1
  components:
    - component_type: CsvExampleGen
      component_name: example_gen
      arguments:
        input_basedir: gs://my-bucket/data/

A
The bucket does not exist
Why it fails: A nonexistent bucket would produce a not-found error, yet the stem indicates the path itself is misconfigured rather than the bucket absent. It is tempting because typos in bucket names are common, and would be correct if the error explicitly reported the bucket as missing rather than a path read failure.
B
The pipeline runner is incorrect
Why it fails: The runner executes pipeline code and does not govern access to a Cloud Storage path, so an incorrect runner would not cause a read failure at that location. It is tempting because runner misconfiguration breaks pipelines generally, and would be correct if the pipeline failed to start or could not execute its components at all.
C
The region is mismatched
Why it fails: A region mismatch affects latency and data residency, but Cloud Storage buckets are globally addressable by name, so the pipeline can still read the path. It is tempting because region errors do break some Google Cloud services, and would be correct if the resource were regional, such as a Compute Engine instance or BigQuery dataset.
D
The service account lacks `storage.objectViewer` permission
A missing `storage.objectViewer` role on the service account directly prevents the pipeline from listing and reading objects at the Cloud Storage path, satisfying the stem's read-failure constraint. Without this permission, requests return 403 errors, so the pipeline cannot access the data regardless of path correctness.

Full breakdown with real-world context →

Question 9hardmultiple choice

Full question →

Refer to the exhibit. An engineer notices no drift alerts but the model performance has degraded. What is the likely cause?

Exhibit

modelMonitoringConfig:
  objectiveConfig:
    detectionConfig:
      driftThresholds:
        age: 0.3
        income: 0.1
      skewThresholds:
        age: 0.2
        income: 0.05
  featureAttributionConfig:
    enabled: True

A
Feature attribution monitoring is causing too many false positives
Why it fails: Feature attribution monitoring explains which features drive predictions; it neither detects drift nor causes false positives that hide degradation. It is tempting because attribution outputs can look like alerts, and it is the right tool when investigating why a model's behaviour changed after a known data shift, not for diagnosing silent performance loss.
B
Drift threshold for income is too high
Why it fails: Raising the income drift threshold suppresses alerts rather than restoring accuracy; if the degradation stems from a changed feature-target relationship, distribution monitoring never fires regardless of threshold. Threshold tuning is genuinely useful when legitimate seasonal income shifts trigger nuisance alerts, but here it would mask the real signal instead of explaining the performance drop.
C
Skew thresholds are not configured for categorical features
Why it fails: Skew monitoring compares training and serving feature distributions; it does not detect concept drift, where the input-output relationship itself changes, so performance falls silently. It is tempting because skew thresholds genuinely catch categorical encoding mismatches between training and inference pipelines, which would be the correct diagnosis if the exhibit showed serving values diverging from training data.
D
Concept drift is occurring, which is not captured by drift or skew detection
Concept drift changes the input-to-output mapping itself, so incoming feature distributions still match the training baseline and drift or skew detection stays silent. The model's learned relationship is stale, which explains degraded performance without alerts.

Full breakdown with real-world context →

These PMLE practice questions are part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style PMLE questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.

Refer to the Exhibit Practice Questions

How to approach refer to the exhibit practice questions

Quick answer

Related PMLE topic practice pages

Automating and Orchestrating ML Pipelines practice questions

Serving and Scaling Models practice questions

Architecting Low-Code ML Solutions practice questions

Scaling Prototypes into ML Models practice questions

Collaborating Within and Across Teams to Manage Data and Models practice questions

Monitoring ML Solutions practice questions

Collaborating to manage data and models practice questions

PMLE fundamentals practice questions

PMLE scenario practice questions

PMLE troubleshooting practice questions

Practice scenarios

Exhibit

The exhibit shows part of a Vertex AI Pipeline definition. The pipeline fails at the training step with an error: 'Missing required input: train_data'. What is the most likely cause?

Exhibit

Refer to the exhibit. A machine learning engineer deployed a model on Vertex AI using this configuration. When testing the endpoint, the engineer receives a 400 error with the message: 'Invalid argument: Explanation metadata missing required field: `outputs`.' What is the most likely cause?

Exhibit

Refer to the exhibit. The team wants to automatically deploy the best-performing model version to production. They have set up a Cloud Function triggered by Model Registry events. Which alias should they use in the function to get the latest champion?

Refer to the exhibit. A data scientist notices that predictions from a deployed model are taking longer than expected. Which Cloud Monitoring metric should be inspected first to identify the bottleneck?

Exhibit

Refer to the exhibit. A team deploys a model using Cloud Run. They notice that after scaling up, the new instances take about 90 seconds to become ready and serve requests. They want to reduce this startup time. Which configuration change is most likely to help?

Exhibit

Refer to the exhibit. A data scientist runs this Vertex AI training job code. What will be the outcome?

Exhibit

Refer to the exhibit. The team notices that the pipeline fails to read data from the specified Cloud Storage path. What is the most likely issue?

Exhibit

Refer to the exhibit. An engineer notices no drift alerts but the model performance has degraded. What is the likely cause?

Exhibit