DOP-C02 SDLC Automation Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  An external dependency became unavailable after the deployment.

  Why it's wrong here

  An unavailable external dependency (e.g., a third-party API or downstream service) typically produces an immediate, binary failure pattern: once the dependency drops, every request that touches it starts failing at the same moment, causing a sharp step-function increase in the error rate rather than a slow, monotonic climb. Even with retry backoff, the error curve would plateau near the dependency's request share, not drift upward for hours as if internal state were gradually accumulating badness.

• ✓

  A bug in the new release causes errors to accumulate over time.

  Why this is correct

  A bug in the new release that causes errors to accumulate over time fits the exhibit's steady upward slope perfectly. For example, a memory leak, unreleased file descriptor, or growing goroutine/thread count raises resource pressure with every additional request, so failure probability increases as a function of cumulative traffic. This pattern is distinct from an immediate fault because the defect is latent, and the error rate worsens as the application's internal state becomes progressively corrupted or exhausted.

• ✗

  The database connection limit was reached immediately after deployment.

  Why it's wrong here

  Reaching the database connection limit immediately after deployment would cause an instant spike in 'too many connections' errors from the very first request, followed by a near-constant or sawtooth plateau as existing connections time out and new ones are attempted. The exhibit shows a gradual rise over time, which contradicts an immediately exhausted pool—if the pool were capped, the error rate would start high and stay high, not build gradually as traffic accumulates.

• ✗

  The deployment triggered a scaling event that overloaded the application.

  Why it's wrong here

  A deployment-triggered scaling event that overloads the application would produce a rapid jump in errors as soon as CPU, memory, or network saturation occurs, then typically either level off once autoscaling adds capacity or oscillate as instances are recycled. That non-monotonic, sudden pattern does not match the steady linear increase in the exhibit, which more strongly indicates an in-process resource leak or progressive defect than a transient overload condition.

Go deeper

Related to this question