AZ-400 Configure processes and communications 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.

• ✓

  Allocate time for refactoring in each iteration

  Why this is correct

  Incrementally dedicating a fixed amount of time to refactoring within each sprint or iteration—often called the 'boy scout rule'—prevents technical debt from accumulating and keeps the codebase maintainable. This continuous small-scale design improvement reduces the risk of large-scale rework later, because complexity and coupling are regularly addressed, and it aligns with Agile principles of sustainable pace. It also complements automated tests, which provide the safety net needed to refactor confidently.

• ✗

  Defer unit tests until after deployment

  Why it's wrong here

  Deferring unit tests until after deployment violates the shift-left testing principle, allowing defects to be discovered only in production or late in the lifecycle, where they are significantly more expensive to fix and may already have impacted real users. This practice also creates a risky feedback loop: developers lack immediate verification of their changes, making regression detection and root-cause debugging far harder. Furthermore, post-deployment testing often gets skipped entirely under schedule pressure, leaving the codebase without a reliable safety net.

• ✓

  Automate unit and integration tests

  Why this is correct

  Automating unit and integration tests provides fast, consistent feedback on every code change, enabling early regression detection and making continuous integration pipelines truly viable. This practice is foundational to CI/CD because it allows teams to merge changes frequently with confidence, knowing that behavioral correctness is verified automatically. While static analysis checks code structure, automated tests validate runtime behavior, and together they create the safety net that makes frequent refactoring safe and cost-effective.

• ✓

  Integrate static code analysis into the CI pipeline

  Why this is correct

  Integrating static code analysis into the CI pipeline automatically enforces coding standards, detects security vulnerabilities and anti-patterns early, and acts as a scalable code-quality gate without relying on time-consuming manual review. Because it runs on every commit or pull request, it provides instant, objective feedback to developers, catching issues like unhandled exceptions, security hotspots, or design violations before they reach production. Unlike unit tests, which validate behavior at runtime, static analysis inspects the code's syntax and structure, making it a complementary quality gate in the DevOps workflow.

• ✗

  Ignore low-priority code smells

  Why it's wrong here

  Ignoring low-priority code smells—even those seemingly harmless like duplicated code or overly long methods—lets technical debt compound over time and increases the cognitive load required to understand and safely modify the code. Such smells can mask deeper design flaws, contribute to the 'broken windows' effect where quality gradually degrades, and make future changes riskier and more costly, as each fix must work around accumulated cruft. Unlike trivial stylistic nits that are excluded by static analysis thresholds, genuine smells should be evaluated and groomed.