AZ-400 Design and implement build and release pipelines Practice Test 1 — 15 Questions

Question 1

A team uses Azure Pipelines to build a .NET Core application. The build pipeline runs successfully, but the release pipeline fails when deploying to Azure App Service with the error: 'ERROR_FILE_IN_USE'. What is the most likely cause?

Accepted Answer

The 'Take App Offline' setting is not enabled in the deployment task.. The 'ERROR_FILE_IN_USE' error occurs when the deployment process tries to overwrite files that are currently locked by the running application. Enabling the 'Take App Offline' setting in the Azure App Service deploy task places an app_offline.htm file in the wwwroot directory, which gracefully shuts down the application and releases all file locks before the new binaries are copied. Without this setting, the running process holds locks on the DLLs, causing the deployment to fail.

Answer

The deployment slot is not configured correctly.

Answer

The Azure App Service plan is not scaled appropriately.

Answer

The build configuration is set to Release instead of Debug.

Question 2

A development team is designing a build pipeline for a microservices application. They want to ensure that each service is built and tested independently, but they also need to run integration tests that span multiple services. What is the recommended approach?

Accepted Answer

Create individual build pipelines for each service, and a separate release pipeline that deploys all services to an integration environment for testing.. Option C is correct because it aligns with microservices best practices: each service has its own build pipeline for independent compilation, unit testing, and artifact generation, while a separate release pipeline orchestrates deployment of all services to a shared integration environment for cross-service testing. This decouples build concerns from deployment concerns, enabling parallel development and faster feedback loops.

Answer

Use a single release pipeline that triggers manual deployment for each service.

Answer

Create a single build pipeline that builds all services together to ensure consistency.

Answer

Build each service separately, but skip integration tests to avoid complexity.

Question 3

A company uses Azure Pipelines with YAML-based pipelines stored in a Git repository. The pipeline triggers on every push to the main branch, but the team wants to reduce unnecessary builds when only documentation files are changed. What is the best way to achieve this?

Accepted Answer

Use path filters in the trigger section to exclude 'docs/*' and '*.md' files.. Option D is correct because using path filters with exclude patterns on the main branch trigger prevents builds for specific file changes. Option A is wrong because branch policies do not filter file changes. Option B is wrong because skipping CI entirely is not desirable. Option C is wrong because conditions evaluate after the pipeline starts, not before.

Answer

Configure branch policy to require a pull request for documentation changes.

Answer

Add a 'condition' to the pipeline that checks if changed files are documentation.

Answer

Disable CI trigger and rely on scheduled builds.

Question 4

A team is implementing a release pipeline for a Node.js application. They want to run integration tests against a temporary environment that is destroyed after the tests complete. Which strategy should they use?

Accepted Answer

Use a release pipeline that deploys to a new Azure App Service instance, runs tests, and then removes the instance.. Option D is correct because it provisions a dedicated, isolated Azure App Service instance for integration testing, runs the tests against the real environment, and then destroys the instance to avoid ongoing costs. This aligns with the ephemeral environment pattern, ensuring tests validate actual deployment behavior without contaminating shared resources.

Answer

Use a separate release pipeline that deploys to a production environment for testing.

Answer

Use a single release pipeline that deploys to a staging slot and runs tests on the slot.

Answer

Run integration tests in the build pipeline using a mock environment.

Question 5

Which TWO actions should be taken to secure secrets in Azure Pipelines? (Choose two.)

Accepted Answer

Use secret variables with the 'secret' input type to mask them in logs.. Option A is correct because Azure Pipelines allows you to mark variables as 'secret' by using the 'secret' input type in the pipeline settings UI or by setting `isSecret: true` in YAML. This ensures the variable's value is masked with asterisks in all logs and output, preventing accidental exposure during build or release execution.

Answer

Use a variable group without Key Vault integration for easier management.

Answer

Store secrets directly in the YAML pipeline file.

Answer

Disable CI triggers to reduce exposure.

Question 6

You are reviewing an Azure Policy definition applied to an Azure DevOps project. The project has a build pipeline that deploys to production. What is the effect of this policy on the build pipeline?

Accepted Answer

The policy audits the pipeline but does not enforce any mandatory reviewers.. Azure Policy definitions applied to Azure DevOps projects use the 'audit' effect by default for policy types that do not support 'deny' or 'enforce' on build pipelines. Since the policy in question does not specify a mandatory reviewer requirement with enforcement, it only audits the pipeline's compliance without blocking execution. Therefore, the pipeline runs regardless, and the policy logs a compliance state.

Answer

The policy blocks the pipeline from running if fewer than two reviewers approve.

Answer

The policy requires two reviewers and blocks the pipeline if not met.

Answer

The policy does not apply to build pipelines because the field type is teamProjects.

Question 7

Your company has a large monorepo with multiple microservices. You have a single YAML-based Azure Pipeline that builds the entire solution on every commit to the main branch. The pipeline takes over an hour to complete, causing long feedback loops. Developers often submit changes to only one service, but the whole pipeline runs. You need to reduce build time while maintaining quality. You are considering splitting the pipeline into multiple pipelines, each for a service, and using path triggers. However, some services have dependencies on shared libraries that are updated infrequently. You also need to ensure that integration tests that span multiple services still run when necessary. What should you do?

Accepted Answer

Create separate pipelines for each service with path triggers, and create an additional comprehensive pipeline that triggers only when shared libraries change.. Option A is correct because it uses path triggers to run only the pipeline for the changed service, drastically reducing build time. The additional comprehensive pipeline, triggered only when shared libraries change, ensures that integration tests spanning multiple services still run when dependencies are updated, maintaining quality.

Answer

Keep the single pipeline but add caching for dependencies.

Answer

Use a single pipeline but add conditional stages to skip unchanged services.

Answer

Create separate pipelines for each service with path triggers, and disable the comprehensive pipeline.

Question 8

A development team is configuring a YAML-based pipeline in Azure Pipelines. The pipeline must meet the following requirements: 
- Build only the main branch.
- Run integration tests after a successful build.
- Deploy to a staging environment only if tests pass.
- Handle failures gracefully by sending a notification to the team.
You need to define the pipeline structure. Which TWO configurations should you include?

Accepted Answer

Define a stage for 'Deploy' with `dependsOn: Test` and `condition: succeeded('Test')`.. Option B is correct because it defines a 'Deploy' stage that depends on the 'Test' stage and uses `condition: succeeded('Test')` to ensure deployment only occurs after tests pass. This satisfies the requirement to deploy to staging only if tests succeed. Option C is correct because `trigger: main` at the pipeline root configures the pipeline to build only the main branch, meeting the first requirement.

Answer

Use a `deployment: Staging` job with `displayName: Deploy to staging`.

Answer

Add `condition: succeeded()` to the build job.

Answer

Define the trigger in the `resources` section using `pipelines`.

Question 9

Refer to the exhibit. The pipeline is configured as shown. A developer pushes a change to the `main` branch that modifies a file under `src/Controllers/HomeController.cs` and also adds a new file under `docs/readme.md`. Which of the following best describes what happens?

Accepted Answer

The pipeline triggers because the change to `src/Controllers/HomeController.cs` is not in an excluded path.. Option B is correct because the pipeline's trigger configuration uses path filters that exclude `docs/*` but include `src/*`. Since the developer's push includes a change to `src/Controllers/HomeController.cs`, which is not in an excluded path, the pipeline triggers. The addition of `docs/readme.md` does not prevent triggering because the trigger evaluates the union of all changed files; as long as at least one changed file matches an included path (or is not excluded), the pipeline runs.

Answer

The pipeline does not trigger because the `docs/` path is excluded and includes a change.

Answer

The pipeline triggers only if the change is on a branch matching `release/*`.

Answer

The pipeline triggers but runs only tests because the build is skipped due to excluded paths.

Question 10

Your organization uses Azure Pipelines for CI/CD. The current pipeline for a .NET Core application builds and runs unit tests, then deploys to a staging environment. The team wants to add a step to run integration tests against the staging environment after deployment, and only if integration tests pass, promote the build to production. The integration tests require a database connection string that is stored as a secret in Azure Key Vault. The pipeline uses a service principal with permissions to read secrets from the Key Vault. You need to modify the pipeline to meet these requirements while ensuring security best practices. Which action should you take?

Accepted Answer

Add an Azure Key Vault task before the integration test step to retrieve the secret and map it to a variable.. Option B is correct because the Azure Key Vault task securely retrieves the secret at pipeline runtime and maps it to a pipeline variable without exposing the secret in logs or YAML. This approach follows security best practices by avoiding hard-coded secrets and leveraging the existing service principal permissions. The integration test step can then reference the variable, ensuring the connection string is available only during execution.

Answer

Set the connection string as a secret variable in the pipeline UI and reference it in the integration test step.

Answer

Add a variable group linked to the Key Vault and reference the secret variable directly in the integration test step.

Answer

Use a PowerShell script to read the secret from Key Vault using the service principal.

Question 11

You have a multi-stage YAML pipeline that deploys to Azure Kubernetes Service (AKS). The pipeline uses a deployment job with a strategy of 'runOnce'. You need to ensure that if the deployment fails, the pipeline automatically redeploys the previous successful version. Which strategy should you use instead?

Accepted Answer

Use the 'rolling' strategy and configure 'on:failure: always'. Option B is correct because the 'rolling' strategy in Azure DevOps deployment jobs supports an 'on:failure' hook that can be configured to run actions like 'always', which can trigger a rollback to the previous successful version. This ensures automatic redeployment of the last stable release upon failure, meeting the requirement without manual intervention.

Answer

Use the 'canary' strategy with manual intervention

Answer

Use the 'blueGreen' strategy and configure automatic swap

Answer

Use the 'runOnce' strategy with a rollback task

Question 12

You are designing a build pipeline that produces a NuGet package. The pipeline must conditionally sign the assembly only when the build is triggered by a tag starting with 'v' (e.g., v1.0.0). The pipeline uses a script task that signs the assembly. Which expression should you use in the condition of the script task?

Accepted Answer

and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/tags/v')). Option A is correct because the condition uses `startsWith(variables['Build.SourceBranch'], 'refs/tags/v')` to check if the build was triggered by a tag whose full Git ref starts with `refs/tags/v`. This ensures the signing script runs only when the source branch is a tag reference matching the 'v' prefix, which is the standard way to identify version tags in Azure Pipelines. The `and(succeeded(), ...)` wrapper guarantees the previous tasks completed successfully before signing.

Answer

and(succeeded(), startsWith(variables['Build.SourceBranchName'], 'v'))

Answer

and(succeeded(), startsWith(variables['Build.SourceVersion'], 'v'))

Answer

and(succeeded(), eq(variables['Build.Reason'], 'IndividualCI'))

Question 13

You have a YAML pipeline that deploys to multiple environments. The pipeline uses environment approvals. You need to ensure that the pipeline waits for manual approval before deploying to the production environment. The production environment is named 'Production'. Which configuration should you add to the deployment job?

Accepted Answer

Add 'environment: Production' to the deployment job and configure approvals on the environment in the Azure DevOps portal. Option A is correct because environment approvals in Azure DevOps are configured on the environment resource itself, not in the pipeline YAML. By adding 'environment: Production' to the deployment job, the pipeline references the environment, and the manual approval gate is enforced by the approvals configured on that environment in the Azure DevOps portal. This ensures the pipeline waits for approval before proceeding to the production deployment job.

Answer

Add 'approvals: Production' to the deployment job

Answer

Add 'checks: Production' to the deployment job

Answer

Add 'dependsOn: ProductionApproval' and use a separate stage for approval

Question 14

You are designing a release pipeline that uses Azure App Service deployment slots. The pipeline must perform a swap after deployment to the staging slot. Which three tasks or actions should you include in the pipeline? (Select all that apply.)

Accepted Answer

Azure App Service deploy: Deploy to staging slot. Option A is correct because the Azure App Service deploy task with the 'Deploy to staging slot' action is the standard method to deploy an application to a staging slot before a swap. This ensures the new release is validated in an isolated environment without affecting the production slot.

Answer

Azure App Service manage: Delete staging slot

Answer

Azure CLI: Run az webapp deployment slot swap

Question 15

You are creating a YAML pipeline that builds a .NET Core application. The pipeline must use a multi-stage build with separate stages for 'Build', 'Test', and 'Deploy'. The 'Deploy' stage should only run if both 'Build' and 'Test' succeed. Which two conditions can you use to achieve this? (Select all that apply.)

Accepted Answer

In the Deploy stage, set 'dependsOn: [Build, Test]'. Option A is correct because setting 'dependsOn: [Build, Test]' in the Deploy stage ensures that the Deploy stage only starts after both the Build and Test stages have completed. By default, a stage runs only if all its dependencies succeed, so this alone meets the requirement without needing an explicit condition. This is the standard way to enforce sequential execution in multi-stage YAML pipelines.

Answer

In the Deploy stage, set 'condition: and(succeeded('Build'), succeeded('Test'))'

Answer

In the Deploy stage, set 'dependsOn: [Build, Test]' and 'condition: stageDependencies.Build.result == 'Succeeded''