AZ-400 Practice Question: Refer to the exhibit

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 web app reached its scaling limit and could not handle the increased load.

  Why this is correct

  The correct explanation is that the App Service plan reached its maximum configured instance count, causing a capacity bottleneck. As request volume steadily increased throughout the morning, CPU/RAM utilization and the request queue grew until hitting the scaling ceiling at 10:30 AM. At that point, the service could not spawn additional instances, and Azure began responding with HTTP 500/503 errors and severe latency, which matches the sharp degradation in the exhibit.

• ✗

  A deployment of new code at 10:30 AM introduced a bug.

  Why it's wrong here

  This is incorrect because there is no evidence of a deployment event; the request count increases gradually before 10:30 AM, not as a sudden step-change typical of a release. A code bug introduced at that exact time would likely cause an immediate, spiky error rate or a behavior shift, regardless of traffic volume, rather than a load-dependent slowdown that escalates as requests rise. Additionally, the metrics show the app handled normal traffic fine until requests exceeded the instance capacity, pointing to a resource limit rather than a regression.

• ✗

  A DDoS attack started at 10:30 AM.

  Why it's wrong here

  A DDoS attack usually produces a sudden, high-bandwidth spike from many distributed IPs, not the gradual and sustained request ramp seen in the exhibit. Azure App Service integrated DDoS protection would absorb or filter such malicious traffic, and the observed errors are consistent with request saturation rather than packet flooding. Attack traffic also tends to cause immediate resource exhaustion with a sharp, discontinuity at the start time, whereas here the requests climbed for hours before failures, indicating organic load growth.

• ✗

  A database outage caused the errors and slow responses.

  Why it's wrong here

  A database outage would typically generate errors irrespective of request volume, causing immediate failures across the entire application rather than a load-correlated degradation. The exhibit shows errors and slow responses only after the request count reached a threshold, which implies the bottleneck is in the app tier's compute capacity (CPU, memory, instance count) and not a downstream dependency failure. There are also no database-specific metrics or error patterns (e.g., connection timeouts, deadlocks) to substantiate that claim, so this is not the most plausible root cause.

Go deeper

Related to this question