AZ-400 Development Processes & Continuous Integration 2 — Questions and Answers
Question 1: A team wants to enforce that no code is merged into the main branch without at least two reviewers approving the pull request. Where in Azure DevOps is this configured?
- Pipeline YAML triggers
- Branch policies in Azure Repos (Correct answer)
- Service connections settings
- Work item area paths
Correct answer: Branch policies in Azure Repos
Branch policies in Azure Repos allow you to require a minimum number of reviewers before a pull request can be completed.
Question 2: Which Azure Pipelines feature allows you to define reusable pipeline logic that can be called from multiple pipelines?
- Environments
- Templates (Correct answer)
- Artifacts
- Stages
Correct answer: Templates
Templates in Azure Pipelines enable you to define reusable steps, jobs, or stages that can be referenced across multiple pipeline definitions.
Question 3: A developer commits code that breaks a shared library used by five downstream services. What CI practice would catch this regression earliest?
- Scheduled nightly builds of all services
- Feature flags on all downstream services
- Multi-repo pipeline triggers that build dependents on library changes (Correct answer)
- Manual smoke tests after each deployment
Correct answer: Multi-repo pipeline triggers that build dependents on library changes
Multi-repo pipeline triggers automatically build and test downstream services whenever the shared library is updated, catching regressions immediately.
Question 4: What is the primary purpose of a 'quality gate' in a CI pipeline?
- To throttle the number of concurrent builds
- To automatically assign work items to developers
- To enforce minimum quality thresholds before allowing progression (Correct answer)
- To rotate secret credentials between stages
Correct answer: To enforce minimum quality thresholds before allowing progression
Quality gates enforce defined thresholds (e.g., code coverage, test pass rate) and block pipeline progression if the code does not meet them.
Question 5: You need to run integration tests that require a SQL Server database in your Azure Pipeline. What is the recommended approach?
- Use a self-hosted agent with a pre-installed SQL Server instance shared across all builds
- Use service containers in the pipeline YAML to spin up a SQL Server container per build (Correct answer)
- Connect to the production database with read-only credentials
- Skip integration tests in CI and run them only in production
Correct answer: Use service containers in the pipeline YAML to spin up a SQL Server container per build
Service containers in Azure Pipelines spin up Docker-based dependencies like SQL Server for the duration of the job, providing isolation per build.
Question 6: A team uses Git Flow and wants CI to trigger only on feature branches and the develop branch, not on hotfix branches. How should they configure this in Azure Pipelines YAML?
- Use include/exclude filters under the 'branches' key in the trigger block (Correct answer)
- Create separate pipeline files for each branch type
- Use environment approvals to block hotfix pipelines
- Set the pipeline to manual trigger only
Correct answer: Use include/exclude filters under the 'branches' key in the trigger block
The 'branches' key in the trigger block supports include and exclude lists using wildcard patterns to control which branches trigger the pipeline.
Question 7: Which metric best indicates that a team's CI pipeline is providing fast feedback to developers?
- Number of pipeline agents provisioned
- Average build duration from commit to result notification (Correct answer)
- Total lines of code committed per sprint
- Number of work items linked to each build
Correct answer: Average build duration from commit to result notification
Average build duration measures how quickly developers receive feedback after committing, which is the core value proposition of CI.
AZ-400 Development Processes & Continuous Integration 2
A team wants to enforce that no code is merged into the main branch without at least two reviewers approving the pull request.
Where in Azure DevOps is this configured?