MLA-C01 Practice Question: Refer to the exhibit

Exhibit

{
  "MonitoringScheduleName": "data-quality-monitor",
  "MonitoringType": "DataQuality",
  "ScheduleConfig": {
    "ScheduleExpression": "cron(0 * * * ? *)"
  },
  "MonitoringJobDefinition": {
    "BaseliningJobDefinition": {
      "BaselineJobName": "baseline-job-1",
      "BaseliningJobOutputConfig": {
        "MonitoringOutputS3Uri": "s3://my-bucket/baseline/"
      }
    },
    "MonitoringOutputConfig": {
      "MonitoringOutputS3Uri": "s3://my-bucket/monitoring-results/"
    },
    "Environment": {
      "max_runtime_in_seconds": "3600"
    }
  }
}

Refer to the exhibit. A team configured a SageMaker Model Monitor schedule for data quality. The baseline was created from a training dataset. After running for a day, the monitoring results show frequent violations. What is the most likely cause?

⚠ Common exam trap

A common misconception is that frequent monitoring schedules cause violations, but in reality violations stem from baseline-production mismatch, not from the monitoring frequency itself.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The baseline was created from a dataset that does not represent production data.

SageMaker Model Monitor compares production data against a baseline statistics and constraints file. If the baseline was created from a training dataset that does not reflect the actual distribution, patterns, or schema of production data, the monitor will flag frequent violations. This is the most common cause of false-positive alerts in data quality monitoring.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
The baseline was created from a dataset that does not represent production data.
Why this is correct
A baseline derived from training data captures the training distribution, not live inference traffic. When production inputs drift from that reference, Model Monitor's data quality constraints are breached, producing frequent violations. The stem's constraint is that the baseline must statistically represent production data; a training-only baseline cannot, so violations are expected.
✗
The environment variable max_runtime_in_seconds is too low.
Why it's wrong here
max_runtime_in_seconds caps each monitoring job's execution duration, so exceeding it fails the job rather than producing data-quality violations. It is tempting because timeout errors are common in long-running jobs, and raising it would be correct if the schedule's executions were being terminated mid-run.
✗
The schedule runs too often (every hour), causing overload.
Why it's wrong here
Schedule frequency affects how many times statistics are computed, not whether computed statistics breach the baseline thresholds, so hourly runs cannot themselves generate violations. It is tempting because frequent scheduling is a plausible operational concern, and reducing frequency would be correct if monitoring costs or resource contention were the actual issue.
✗
The monitoring output destination is incorrect.
Why it's wrong here
An incorrect output destination prevents results from being written or read, producing missing reports rather than violations against baseline thresholds. It is tempting because destination misconfiguration is a common deployment error, and correcting the S3 path would be the right fix if monitoring results were absent or unreadable.

Go deeper

MLA-C01 Practice Question: Refer to the exhibit

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question