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

Question 1

Your Azure DevOps pipeline uses the 'DotNetCoreCLI@2' task to run unit tests. Some tests are failing intermittently. You suspect test flakiness due to race conditions. What should you do to automatically retry failed tests without rewriting the tests?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Use the 'VSTest@2' task with 'retryFailedTests: true' option.. The 'VSTest@2' task in Azure DevOps includes a built-in 'retryFailedTests' property that automatically re-runs failed tests a specified number of times. This directly addresses intermittent test flakiness caused by race conditions without requiring any code changes to the tests themselves. The 'DotNetCoreCLI@2' task does not support this retry mechanism, so switching to 'VSTest@2' is the appropriate solution.

Answer

Create a custom script that runs each test individually and retries on failure.

Answer

Enable 'test retry' in the pipeline settings under 'General'.

Answer

Wrap the test task in a 'Retry' loop using a 'each' expression.

Question 2

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub are not exposed in build logs. A developer accidentally printed a secret to the console in a workflow step. How can you prevent this from happening in the future?

Accepted Answer

Enable 'Secret scanning' and 'Push protection' for the repository.. GitHub Advanced Security's secret scanning automatically detects exposed secrets in a repository, and push protection blocks commits containing detected secrets before they reach the remote. Enabling both features prevents secrets from being committed or pushed in the first place, which is the root cause of accidental exposure in logs. While GitHub Actions does mask registered secrets in logs by default, secret scanning and push protection add a preventive layer that catches secrets before they enter the codebase or workflow files.

Answer

Add the secret to the 'Secret scanning' exclusion list.

Answer

Instruct developers to avoid using 'echo' and use '::set-output' instead.

Answer

Use the 'actions/secrets' action to mask secrets automatically.

Question 3

Your Azure DevOps pipeline deploys an ARM template to create a storage account. The deployment fails with 'AuthorizationFailed' error. The service principal used by the service connection has 'Contributor' role on the resource group. What is the most likely issue?

Accepted Answer

The 'Microsoft.Storage' resource provider is not registered for the subscription, and the service principal lacks permission to register it at subscription scope.. The AuthorizationFailed error is likely due to the Microsoft.Storage resource provider not being registered for the subscription. The service principal has Contributor on the resource group, but registering a resource provider requires Microsoft.Register/action at the subscription scope, which the principal does not have. The service principal itself is not registered for the resource provider; resource providers are registered at the subscription level.

Answer

The storage account name is already taken.

Answer

The ARM template is using an unsupported API version.

Answer

The service principal does not have 'Contributor' role at the subscription scope.

Question 4

Which TWO are best practices for securing Azure Pipelines? (Choose two.)

Accepted Answer

Use variable groups linked to Azure Key Vault for secrets.. Option A is correct because linking variable groups to Azure Key Vault keeps secrets out of the pipeline YAML and lets you centralize secret management, rotate credentials, and control access via Key Vault access policies or RBAC, so secrets are never stored in plain text in the repository. Option B is correct because scoping a service connection to a specific resource group with the least-privilege 'Contributor' role limits the blast radius if the connection is compromised, following the principle of least privilege rather than granting broad subscription-level access. Option C is incorrect because granting 'Administrator' to all service connections violates least privilege and dramatically increases the impact of a compromised pipeline. Option D is incorrect because storing variables as plain text in YAML exposes secrets in source control and build logs. Option E is incorrect because disabling pipeline logging removes auditability and hinders detection and troubleshooting of security incidents.

Answer

Grant 'Administrator' role to all service connections for ease of management.

Answer

Store all pipeline variables in the YAML file as plain text.

Answer

Disable pipeline logging for all jobs.

Question 5

Refer to the exhibit. You deploy this ARM template using Azure Pipelines. The deployment succeeds, but the storage account is created with a name that is not what you expected. What is the most likely reason?

Accepted Answer

The uniqueString function returns a hash based on the resource group ID, resulting in a non-meaningful name.. The most likely reason is that the uniqueString function returns a hash based on the resource group ID, resulting in a non-meaningful name. This is a common ARM template behavior when using uniqueString to generate a globally unique storage account name, which often produces a random-looking string rather than a descriptive name.

Answer

The storage account name parameter is of type 'string' but the default value is an object.

Answer

The location parameter uses resourceGroup().location which is not a valid function.

Answer

The apiVersion '2022-09-01' is too new and causes a naming conflict.

Question 6

You need to implement a strategy to manage secrets for your multi-stage YAML pipeline. The pipeline runs on Microsoft-hosted agents. Which approach should you use to securely pass secrets to pipeline tasks?

Accepted Answer

Use pipeline variables with 'secret: true' and reference them as $(variableName).. Azure Pipelines supports secret pipeline variables that are encrypted at rest and never exposed in logs or output. By defining a variable with `secret: true` in the YAML or via the UI, you can reference it securely as `$(variableName)` in tasks, ensuring the secret value is masked during execution.

Answer

Define the secrets as environment variables in the pipeline YAML directly.

Answer

Use the Azure Key Vault task to download secrets and then pass them as parameters.

Answer

Store secrets in a file in the repository and read it during the build.

Question 7

You want to trigger a pipeline automatically when a new commit is pushed to the 'develop' branch of your repository. Which trigger configuration should you use in the YAML pipeline?

Accepted Answer

resources:
  repositories:
  - repository: self
    trigger:
      branches:
        include:
          - develop. Both C and D are valid ways to define a CI trigger on a push to the 'develop' branch. The top-level `trigger` (D) is the conventional and recommended syntax. A repository resource with `repository: self` and a `trigger` (C) is also an officially supported alternative. Options A and B are incorrect: A defines a schedule, and B defines a pull request trigger, not a direct push CI trigger.

Answer

schedules:
- cron: "0 0 * * *"
  branches:
    include:
      - develop

Answer

pr:
  branches:
    include:
      - develop

Question 8

You are implementing a release pipeline with multiple stages. You want to automatically trigger the next stage only if the previous stage succeeds and the build is from the 'main' branch. Which TWO conditions should you configure?

Accepted Answer

Add a condition that checks if the source branch is 'main'.. Option A is correct because gating the stage on the source branch being 'main' ensures the pipeline only proceeds for builds originating from the main branch, which is exactly the branch restriction the scenario requires. Option B is correct because configuring the stage trigger as 'After stage' and selecting the previous stage establishes the dependency that makes the next stage run only after the prior stage completes successfully. Option C is incorrect because the expression uses single quotes around 'main' inside the eq() function, which is invalid Azure Pipelines syntax and would fail to evaluate properly. Option D is incorrect because succeeded() alone only verifies that previous dependencies succeeded but does not enforce the 'main' branch requirement. Option E is incorrect because, while it mentions correct syntax, it is a distractor that duplicates the branch condition without providing the stage dependency trigger needed to run only after the previous stage succeeds.

Answer

Add a condition: 'eq(variables['Build.SourceBranch'], 'main')' to the stage.

Answer

Add a condition: 'succeeded()' to the stage.

Answer

Add a condition: 'eq(variables['Build.SourceBranch'], 'main')' with correct syntax.

Question 9

Your release pipeline deploys to multiple environments sequentially. The deployment to production fails intermittently due to a database schema migration issue. You need to implement a strategy that automatically rolls back the deployment if the migration fails. What should you do?

Accepted Answer

Add a post-deployment script that runs a rollback script on failure.. It directly addresses the requirement to automatically roll back the deployment when a database schema migration fails. By adding a post-deployment script that runs a rollback script on failure, you can execute custom logic (e.g., reverting schema changes using SQL scripts or tools like Entity Framework migrations) immediately after the deployment step detects an error. This approach provides fine-grained control over the rollback process, which is essential for database migrations that cannot be handled by Azure Pipelines' built-in auto-rollback feature, which only reverts the application deployment (e.g., swapping slots or restoring files) and does not execute custom rollback scripts.

Answer

Enable 'Auto-rollback' in the release pipeline settings.

Answer

Use a multi-stage YAML pipeline with manual intervention.

Answer

Configure pre-deployment approval gates.

Question 10

You are designing a build pipeline that uses Microsoft-hosted agents. The pipeline must build a .NET Framework 4.8 application and run on a Windows agent. Due to compliance, the build must use a specific version of Visual Studio that is not pre-installed on the Microsoft-hosted agents. What should you do?

Accepted Answer

Use a self-hosted agent that has the required version of Visual Studio installed.. To use a specific version of Visual Studio not pre-installed on Microsoft-hosted agents, you can either use a self-hosted agent with that version installed, or run the build in a Docker container that includes the required Visual Studio/Build Tools version. Microsoft-hosted agents have Docker installed and can run Windows containers, so option B is viable. Options C and D do not install a full Visual Studio version.

Answer

Specify the 'vsVersion' parameter in the MSBuild task to target the required version.

Answer

Use the 'Visual Studio Test Platform Installer' task to install the required version at build time.

Question 11

Which THREE options are valid strategies to reduce build times in Azure Pipelines? (Choose three.)

Accepted Answer

Enable incremental builds by using the 'Clean: false' option.. Option A is correct because setting the build task's 'Clean' option to false preserves previous build outputs on the agent, enabling incremental builds so only changed files are recompiled instead of rebuilding everything from scratch. Option B is correct because a self-hosted agent can retain a local cache of dependencies (e.g., NuGet, npm, Maven artifacts) between runs, avoiding repeated downloads and reducing restore time. Option E is correct because the built-in 'Cache' task (Cache@2) persists folders such as node_modules or .m2 across pipeline runs using a cache key, so dependencies are restored from the cache rather than re-downloaded. Option C is not a valid strategy because splitting a pipeline into sequential stages adds overhead and does not inherently reduce total build time. Option D is also not valid because increasing parallel jobs improves throughput across multiple builds, not the duration of a single build.

Answer

Break the pipeline into multiple stages running sequentially.

Answer

Increase the number of parallel jobs in the pipeline.

Question 12

Which TWO conditions should you configure in a release pipeline to ensure that a deployment to production only happens when both the staging deployment succeeded and a manual approval is granted? (Choose two.)

Accepted Answer

Add a pre-deployment approval on the production stage.. Option B is correct because a pre-deployment approval on the production stage pauses the pipeline immediately before the production deployment begins, requiring a designated approver to manually authorize it, which satisfies the manual approval condition. Option E is correct because a gate on the production stage can invoke a check (for example, an Azure DevOps REST API or Azure Monitor query) that verifies the staging stage's deployment status succeeded before allowing production to proceed, satisfying the staging-success condition. Option A is wrong because a post-deployment approval on staging only controls what happens after staging finishes and does not gate entry into production. Option C is wrong because the 'After release' trigger with an artifact filter controls when a release is created from a build artifact, not whether production waits for staging success plus approval. Option D is wrong because 'After previous deployment' only sequences the production stage to run after the prior stage completes; it does not verify the staging result nor enforce a manual approval.

Answer

Add a post-deployment approval on the staging stage.

Answer

Set the trigger to 'After release' and filter by artifact.

Answer

Set the deployment queue setting to 'After previous deployment' for the production stage.

Question 13

Which THREE steps should you take to implement a blue-green deployment strategy for an Azure App Service using Azure Pipelines? (Choose three.)

Accepted Answer

Create a deployment slot named 'staging' for the App Service.. Option A is correct because a blue-green deployment requires a separate, parallel environment to host the new (green) version, and creating a deployment slot named 'staging' on the App Service provides exactly that isolated slot with its own hostname and configuration. Option B is correct because enabling 'Auto swap' on the staging slot automatically swaps the staging slot into production once a deployment completes successfully, which is the mechanism that promotes the green version to blue with minimal downtime. Option C is correct because the new application version must first be deployed to the staging slot (the green environment) so it can be warmed up and validated before being swapped into production. Option D is not correct because the production slot is the live target of the swap and must be retained, not deleted. Option E is not correct because routing 100% of traffic to the staging slot would expose the unvalidated new version directly to users and bypasses the controlled swap that defines blue-green deployment.

Answer

Delete the production slot after swapping.

Answer

Route 100% of traffic to the staging slot.

Question 14

Your team uses Azure Pipelines to build a .NET application. Recently, builds have been failing intermittently with NuGet restore errors. The pipeline uses a hosted agent. You need to ensure consistent package restoration. What should you do?

Accepted Answer

Use a self-hosted agent with persistent NuGet package caches.. Intermittent NuGet restore errors on hosted agents often occur because hosted agents are ephemeral and do not persist the NuGet package cache between builds. Using a self-hosted agent with a persistent NuGet package cache ensures that packages are cached locally, reducing network-related failures and providing consistent restoration.

Answer

Clear the NuGet cache in the pipeline using 'dotnet nuget locals all --clear' before restore.

Answer

Enable multi-stage Docker builds for the application.

Answer

Configure the pipeline to use the Dapr sidecar for package management.

Question 15

Which TWO are valid ways to pass build artifacts from one stage to another in a multi-stage YAML pipeline in Azure Pipelines?

Accepted Answer

Use the Publish Pipeline Artifact task in the first stage and Download Pipeline Artifact task in the second stage.. Option B is correct because the PublishPipelineArtifact task (Publish Pipeline Artifact) stores artifacts in the pipeline's artifact storage, and the DownloadPipelineArtifact task (Download Pipeline Artifact) in a later stage retrieves them, which is the recommended native mechanism for passing build outputs across stages in a multi-stage YAML pipeline. Option D is correct because the CopyFiles task can copy build outputs to a shared network drive or UNC path accessible from the agent, and a later stage can read those files from that shared location, making it a valid (if less integrated) way to pass artifacts between stages. Option A is incorrect because publishing a pipeline artifact does not automatically make it available to subsequent stages — a Download Pipeline Artifact task (or equivalent) must be used to fetch it. Option C is incorrect because PublishBuildArtifacts and DownloadBuildArtifacts are the legacy build artifact tasks tied to the older build system and are not the valid cross-stage mechanism in multi-stage YAML pipelines. Option E is incorrect because variables only carry scalar values (strings) between stages and cannot transfer build artifact files.

Answer

Use the Pipeline Artifact task to publish artifacts, which are automatically available to subsequent stages without download.

Answer

Use the Publish Build Artifacts task and then the Download Build Artifacts task.

Answer

Define variables in the first stage and reference them in the second stage.