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.

• ✗

  Increase the build timeout to the maximum allowed value of 8 hours.

  Why it's wrong here

  Raising the CodeBuild timeout limit to the maximum (8 hours) merely delays the execution cutoff; it does not eliminate the underlying cause of intermittent timeouts. If the test suite is genuinely slow or resource-constrained, the build will still exceed even an extended limit, and you remain exposed to higher compute costs while the pipeline stays in a failed state longer. The issue should be resolved by reducing test execution time, not by adjusting a threshold.

• ✗

  Use AWS CodeDeploy to run the unit tests on EC2 instances with more CPU and memory.

  Why it's wrong here

  AWS CodeDeploy is designed to automate application deployments to EC2 instances, on-premises instances, or Lambda functions; it is not a test execution service and cannot run your unit tests directly. Even if you used a custom deployment lifecycle hook to invoke tests, provisioning more CPU/memory on an EC2 instance is a vertical scaling workaround that fails to address why the test suite is slow or non-deterministic, and it introduces infrastructure management overhead that CodeBuild already abstracts. The appropriate fix is to optimize the build/test process within CodeBuild, not to repurpose a deployment service.

• ✗

  Modify the unit tests to be non-flaky by adding retries for network calls.

  Why it's wrong here

  Adding retries to network calls can mask flaky network behavior, but it does not reduce the total time required for the test suite to complete; in fact, retries and backoff attempts can lengthen execution and increase the chance of hitting the CodeBuild timeout. The scenario points to a timeout on the entire CodeBuild project, which is most directly caused by test execution exceeding the configured limit, not necessarily by a few unstable network-dependent tests. Simply patching individual tests does not structurally shorten the test suite or prevent slow tests from overwhelming the build timeout.

• ✓

  Configure the CodeBuild project to run tests in parallel by using separate build environments or test splits.

  Why this is correct

  CodeBuild supports batch builds and test splitting (e.g., dividing the test suite into shards and running them across multiple concurrent build environments), which can dramatically reduce wall-clock time and keep the build under the timeout threshold. With Amazon CodeBuild's batch configuration, you can define a buildspec that splits tests by file, directory, or using tools like pytest-xdist, and CodeBuild orchestrates concurrent execution. This directly addresses the root cause by parallelizing CPU-intensive work rather than extending the deadline or masking flaky tests.

Go deeper

Related to this question