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.

• ✗

  All microservices should be deployed using a single pipeline to ensure consistency.

  Why it's wrong here

  A single pipeline that deploys all microservices creates tight coupling between teams and services, forcing them to align on the same build, test, and release cadence. This increases the blast radius of failures—one service's failed test blocks unrelated services—and effectively prevents independent, on-demand deployment of individual services. In a microservices architecture, each service should have its own pipeline to enable autonomous team ownership and safe, granular releases.

• ✓

  Include automated integration tests that validate service-to-service interactions.

  Why this is correct

  Automated integration tests that exercise real interactions between services (for example, using contract tests or a dedicated test environment) catch API mismatches, schema changes, and network configuration errors before production. By running these tests early in the CI/CD pipeline, you shift left defect detection, reduce the cost of fixes, and increase confidence that independently deployed services will interoperate correctly.

• ✗

  Use manual approval gates at every stage to ensure quality.

  Why it's wrong here

  Placement of manual approval gates at every stage is antithetical to CI/CD's goal of fast, automated feedback. Manual checkpoints introduce wait time and human variability, making release cycles unnecessarily long and error-prone. Automated quality gates (e.g., unit tests, static analysis, security scans) should be used for all non-production stages, with manual approval reserved only for the final production deployment where business judgment is required.

• ✓

  Each microservice should have its own pipeline to enable independent deployment.

  Why this is correct

  Having a dedicated CI/CD pipeline per microservice allows each team to build, test, and deploy its service independently at its own cadence, which is essential in a microservices architecture. This reduces cross-team coordination overhead, minimizes the impact of one service's pipeline failure on others, and supports safe, frequent releases. Independent pipelines also enable per-service versioning, rollback, and scaling of deployment frequency based on business needs.

• ✓

  Implement blue/green deployments to reduce downtime and allow quick rollback.

  Why this is correct

  Blue/green deployment involves running two identical production environments (blue and green) and routing traffic between them, which enables zero-downtime releases and an instant rollback by simply switching traffic back to the previous environment. This pattern is especially valuable when deploying independently scheduled microservices because it decouples deployment from release—you can fully vet the new version in the green environment before switching over, and if issues arise, rollback is a single routing change. It also reduces the risk of long recovery times during failed deployments.

Go deeper

Related to this question