AZ-400 Design and implement build and release pipelines — Timed 30 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''

Question 16

You are designing a build pipeline that uses a combination of tasks. The pipeline must compile code, run unit tests, and then publish code coverage results. Match each task with its appropriate placement in the pipeline order. The tasks are: 'Visual Studio Test', 'Publish Code Coverage Results', 'Visual Studio Build'. The correct order is: 1. Build, 2. Test, 3. Publish coverage.

Answer

Visual Studio Build

Answer

Visual Studio Test

Answer

Publish Code Coverage Results

Question 17

You have a YAML pipeline that builds a .NET application. You need to ensure that the pipeline uses the .NET SDK version 6.0.x. Which task should you add to the pipeline?

Accepted Answer

UseDotNet@2. The UseDotNet@2 task is the correct choice because it explicitly installs a specific .NET SDK version (6.0.x) on the build agent, ensuring the pipeline uses the required SDK for building the .NET application. This task downloads and caches the SDK, making it available for subsequent tasks like DotNetCoreCLI@2.

Answer

NuGetToolInstaller@1

Answer

DotNetCoreCLI@2

Answer

PowerShell@2

Question 18

You have a release pipeline that deploys to multiple stages. You want to ensure that a manual approval is required before deploying to the production stage. Which approach should you use?

Accepted Answer

Add a pre-deployment approval on the production stage.. Pre-deployment approvals in Azure Pipelines allow you to require manual sign-off before a release proceeds to a specific stage. By adding a pre-deployment approval on the production stage, the pipeline will pause and wait for designated approvers to approve the deployment, ensuring that no code reaches production without explicit authorization.

Answer

Add a post-deployment approval on the staging stage.

Answer

Configure a deployment gate with a manual intervention task.

Answer

Use a pipeline decorator to inject approval step.

Question 19

You have a YAML pipeline that uses a multi-stage build. You want to cache the restored NuGet packages across builds to improve performance. Which caching strategy should you use?

Accepted Answer

Use the Cache@2 task with key: 'nuget | "$(Agent.OS)" | packages.lock.json', path: '$(System.DefaultWorkingDirectory)/packages'. Option A is correct because the Cache@2 task is the recommended way to cache NuGet packages in Azure Pipelines. By using a cache key that includes the agent OS and the packages.lock.json file, the cache is invalidated only when the lock file changes, ensuring restored packages are reused across builds. The path points to the NuGet global packages folder, which is typically $(System.DefaultWorkingDirectory)/packages when NUGET_PACKAGES is set.

Answer

Use the NuGetCommand@2 task with the -Cache argument.

Answer

Set the NUGET_PACKAGES environment variable to a custom path and rely on pipeline caching plugin.

Answer

Use the DotNetCoreCLI@2 task with the --no-restore flag and manually copy packages.

Question 20

You need to run a set of tasks only when the build pipeline runs for the main branch. Which condition should you add to the job or step?

Accepted Answer

condition: eq(variables['Build.SourceBranch'], 'refs/heads/main'). Option A is correct because the `Build.SourceBranch` variable in Azure Pipelines contains the full Git ref (e.g., `refs/heads/main`). Using `eq(variables['Build.SourceBranch'], 'refs/heads/main')` ensures the condition evaluates to true only when the pipeline runs on the main branch. This is the standard way to filter by branch in YAML pipeline conditions.

Answer

condition: eq(variables['Build.SourceBranch'], 'main')

Answer

condition: and(succeeded(), eq(variables['System.PullRequest.TargetBranch'], 'main'))

Answer

condition: ne(variables['Build.Reason'], 'PullRequest')