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

Question 1

You are designing a release pipeline for a microservices application. Each service must be deployed independently with zero downtime. Which deployment strategy should you recommend?

Accepted Answer

Blue-green deployment. Blue-green deployment maintains two identical production environments (blue and green). Traffic is switched from the old version to the new version only after the new environment is fully validated, enabling instant rollback and zero downtime. This makes it the strongest fit when each microservice must be released independently with no service interruption.

Answer

Rolling update

Answer

Feature flags

Answer

Canary release

Question 2

Refer to the exhibit. Your team uses a classic build pipeline. You notice that test assemblies are not being found during the Test phase. Which change resolves the issue?

Accepted Answer

Use fully qualified paths in testAssemblyVer2. The VSTest task's searchFolder defaults to the source folder, so setting it to $(Build.BinariesDirectory) correctly finds test DLLs in the build output. However, specifying fully qualified paths in testAssemblyVer2 (e.g., $(Build.BinariesDirectory)\**\*.Test.dll) also works because the task accepts full paths. Therefore, B and D both resolve the issue. The original explanation incorrectly dismisses B by saying it is 'unnecessary'—unnecessary does not mean incorrect. The question needs revision to have a single unambiguous correct answer.

Answer

Change testSelector to 'testMethod'

Answer

Add buildConfiguration: 'Release' to the DotNetCoreCLI task

Question 3

Your organization uses Azure DevOps and GitHub. You need to ensure that secrets such as API keys are not exposed in pipeline logs. What should you do?

Accepted Answer

Store the API key in Azure Key Vault and use a variable group linked to the vault. The correct answers are B and C. Storing the API key in Azure Key Vault and using a variable group linked to the vault (B) ensures secrets are securely stored and not exposed in logs. Storing the API key in a secret variable (C) also masks the value in logs. Both approaches prevent secrets from being exposed.

Answer

Store the API key in a plain text variable and reference it as $(apiKey)

Answer

Use the Logging Command to suppress output

Question 4

You manage a release pipeline that deploys to multiple environments. The pipeline uses variables that differ per environment. You want to avoid duplicating variable definitions. Which strategy should you use?

Accepted Answer

Use variable groups linked to environments. Variable groups in Azure DevOps can be linked to specific stages or environments, allowing a single group definition to be reused across a pipeline while supplying environment-specific values. This avoids duplicating variable definitions in each stage while keeping values scoped correctly. Linking a variable group to an environment also enables approval and check gates on the group's use.

Answer

Use the 'variables' section in the pipeline YAML with conditions

Answer

Define variables in each stage of the YAML pipeline

Answer

Store all variables in Azure Key Vault and reference them in the pipeline

Question 5

You are responsible for a release pipeline that deploys a containerized application to Azure Kubernetes Service (AKS). The pipeline currently builds and pushes a Docker image to Azure Container Registry (ACR) and then updates the Kubernetes manifest. You need to implement a rollback strategy in case the deployment fails. The rollback should revert to the previous known good version of the application. Which approach should you use?

Accepted Answer

Use the Kubernetes task with the 'rollback' option, which runs 'kubectl rollout undo' on the deployment.. The Kubernetes task in Azure Pipelines includes a 'rollback' command that invokes 'kubectl rollout undo' against the specified deployment, reverting to the previous ReplicaSet revision tracked by Kubernetes. This is the native, automated mechanism designed for exactly this scenario and integrates directly into the pipeline. It preserves the deployment history and requires no manual image-tag manipulation.

Answer

Keep the previous Docker image tag in ACR and update the manifest to point to it manually.

Answer

Rerun the previous successful pipeline run.

Answer

Use Helm to manage releases and rollback using 'helm rollback' command.

Question 6

Your team uses Azure DevOps for CI/CD. You want to ensure that only code from the main branch is deployed to production. The release pipeline has a pre-deployment condition that requires approval. However, you notice that a release created from a feature branch was approved and deployed. What is the most likely cause?

Accepted Answer

The pre-deployment condition did not include a branch filter on the artifact.. The pre-deployment condition in Azure DevOps release pipelines can include a branch filter on the artifact to restrict which branches trigger a release. If this filter is not configured, any release—regardless of the source branch—can proceed through the approval gate. Since the feature branch release was approved and deployed, the most likely cause is that the pre-deployment condition lacked a branch filter to enforce that only artifacts from the main branch are eligible.

Answer

The deployment queue settings were set to 'Deploy all in parallel'.

Answer

The artifact was published from a build pipeline that allowed any branch.

Answer

The pre-deployment condition was set to 'After release' instead of 'Before deployment'.

Question 7

Your build pipeline uses a Microsoft-hosted agent. The pipeline fails intermittently with 'Error: No space left on device'. What is the most effective solution?

Accepted Answer

Add a step to clean up temporary files before the build completes.. The intermittent 'No space left on device' error on a Microsoft-hosted agent is typically caused by temporary build artifacts accumulating during the pipeline run. Adding a step to clean up temporary files (e.g., using shell commands like `rm -rf` or the `DeleteFiles` task) before the build runs out of space frees disk space proactively, preventing the error without requiring infrastructure changes.

Answer

Increase the agent's temporary storage by setting the TMP variable.

Answer

Switch to a self-hosted agent with more disk space.

Answer

Configure the pipeline to use more parallel jobs.

Question 8

Your release pipeline uses deployment groups to deploy to on-premises servers. You want to ensure that only one deployment runs at a time on each server. Which option should you configure?

Accepted Answer

Set the deployment queue to 'Deploy one at a time' with 'Exclusive lock'.. Setting the deployment queue to 'Deploy one at a time' with 'Exclusive lock' ensures that only one deployment runs at a time on each server in the deployment group. This lock prevents concurrent deployments to the same target, which is essential for on-premises servers that cannot handle parallel updates without conflicts.

Answer

Configure a pre-deployment condition that checks the current deployment status.

Answer

Add a manual approval step before each deployment.

Answer

Set the deployment queue to 'Deploy all in parallel' with 'Number of parallel deployments' set to 1.

Question 9

Which TWO triggers can be used to start a release pipeline in Azure DevOps?

Accepted Answer

Scheduled release trigger. Option B (Scheduled release trigger) is correct because Azure DevOps release pipelines support a schedule trigger that automatically creates a new release at defined times (e.g., daily or weekly at a specified hour), independent of any code commit. Option C (Continuous deployment trigger) is correct because a release pipeline can be configured with a continuous deployment trigger on its artifact source, so a new release is created automatically whenever a new build artifact is produced. Option A (Continuous integration trigger) is not a release pipeline trigger; CI triggers are configured on build (YAML/pipeline) definitions to start builds on commits. Option D (Pull request trigger) and Option E (Branch policy trigger) apply to build validation and branch policies, not to starting release pipelines.

Answer

Continuous integration trigger

Answer

Pull request trigger

Answer

Branch policy trigger

Question 10

Your team uses GitHub Actions for CI/CD. You have a workflow that builds and deploys a Node.js application to Azure App Service. The workflow uses the 'azure/webapps-deploy@v2' action. You notice that the deployment often fails with a 403 error during the 'Deploy to Azure' step. The error message indicates that the publish profile credentials are invalid. You have stored the publish profile as a secret in the repository. The secret name is AZURE_WEBAPP_PUBLISH_PROFILE. The workflow step uses the secret correctly. However, the secret value might have been rotated. You need to ensure that the deployment works reliably. What should you do?

Accepted Answer

Use OpenID Connect with a service principal instead of publish profile.. Using OpenID Connect (OIDC) with a service principal eliminates dependency on publish profile credentials, which can expire or be rotated. OIDC provides short-lived tokens and is more secure and reliable. Option B, while it could resolve the immediate issue by updating the secret with the current publish profile, is not the most reliable long-term solution because it requires manual intervention each time the publish profile rotates. Option C is wrong because using the Azure CLI action still requires valid credentials; if the publish profile is invalid, it will still fail. Option D is wrong because recreating the secret with the same value does not fix the problem if the credentials have been rotated on the Azure side.

Answer

Check the workflow run log for the exact error and update the secret accordingly.

Answer

Replace the 'azure/webapps-deploy' action with 'Azure/cli' action and run az webapp deployment source config-zip.

Answer

Recreate the secret in GitHub by deleting and adding it again with the same value.

Question 11

Your company uses Azure DevOps for CI/CD. You have a build pipeline that compiles a C++ application and runs unit tests. The pipeline uses a Microsoft-hosted agent. The build takes approximately 45 minutes to complete. You want to reduce the build time. You notice that the pipeline downloads dependencies from a NuGet feed every time. You have a private NuGet feed in Azure Artifacts. The pipeline restores packages using 'nuget restore'. You want to cache the NuGet packages on the agent to avoid downloading them on every build. What should you do?

Accepted Answer

Add a CacheBeta task before the restore step to cache the packages folder.. Adding a CacheBeta task before the restore step allows the pipeline to cache the NuGet packages folder on the agent. On subsequent builds, if the cache is hit, the packages are restored from the local cache instead of downloading from the NuGet feed, significantly reducing build time. This is the recommended approach for caching dependencies in Azure Pipelines.

Answer

Use a self-hosted agent with persistent storage.

Answer

Use a hosted Azure Artifacts feed with upstream sources.

Answer

Increase the agent's compute resources by selecting a higher SKU.

Question 12

Your team uses Azure Pipelines to build a .NET application. You need to implement a secure build pipeline that meets the following requirements:
- Secrets must be injected at build time without being exposed in logs or YAML files.
- The build must use Microsoft-hosted agents.
- All builds must be auditable.
Which TWO actions should you take? (Choose two.)

Accepted Answer

Use a variable group linked to Azure Key Vault to store secrets, and reference the variable group in the pipeline.. Option B is correct because linking a variable group to Azure Key Vault lets the pipeline retrieve secrets at runtime from Key Vault, so the secret values are never stored in the YAML or exposed in logs; Azure Pipelines masks secret variables in log output, and the variable group reference keeps the pipeline definition free of secret material. Option D is correct because the Replace Tokens task substitutes pipeline variables (including secret variables sourced from Key Vault) into configuration files at build time, which is the standard pattern for injecting secrets into appsettings.json or similar files without committing them to source control. Option A is not appropriate because the OAuth token is the pipeline's access token for the build service, not an application secret, and enabling scripts to access it broadens the credential exposure surface rather than securely injecting application secrets. Option C is wrong because plain-text secrets in YAML are visible to anyone with repo access and are not masked as secret variables. Option E is wrong because the requirement explicitly states Microsoft-hosted agents must be used, so a self-hosted on-premises agent violates the scenario.

Answer

Enable 'Allow scripts to access the OAuth token' on the agent job and use the token in scripts.

Answer

Store secrets as plain-text environment variables in the pipeline YAML file.

Answer

Deploy a self-hosted agent on-premises to keep secrets within the corporate network.

Question 13

You are designing a build pipeline for a Python application that uses multiple third-party packages from the public PyPI repository. Your organization has security policies that require all build dependencies to be scanned for known vulnerabilities before being used. The build pipeline runs on Microsoft-hosted agents. You need to integrate vulnerability scanning into the build pipeline with minimal overhead and without storing credentials in the pipeline. What should you do?

Accepted Answer

Add a dependency scanning task from the Azure DevOps marketplace to the build pipeline.. The most efficient and secure way to integrate vulnerability scanning into an Azure DevOps build pipeline is to add a dependency scanning task from the Azure DevOps marketplace. This task can scan third-party packages for known vulnerabilities without requiring custom scripts or stored credentials, and it integrates directly into the pipeline. It leverages existing extensions that are designed for this purpose, minimizing overhead.

Answer

Configure a service connection to a private vulnerability database and use a script to scan.

Answer

Write a custom script that uses pip audit to scan the requirements.txt file.

Answer

Use a pre-build validation step in the pipeline to manually review dependencies.

Question 14

Your company uses GitHub Actions for CI/CD. The development team wants to automatically create a new GitHub release with release notes whenever a pull request is merged to the main branch. The release notes should include a list of all merged pull requests since the last release. You need to implement this automation. What should you do?

Accepted Answer

Add a workflow triggered on push to main that uses the 'softprops/action-gh-release' action to create a release with auto-generated release notes.. The 'softprops/action-gh-release' action can create a release and, when configured with `generate_release_notes: true`, generates release notes from merged PRs. Option B is incorrect because requiring a release note file via branch protection does not create a GitHub release. Option C is incorrect because GitHub does not automatically create releases from tags; a release must be created explicitly. Option D is incorrect because `gh release create` alone does not automatically generate release notes from merged PRs; it requires a manually constructed changelog.

Answer

Configure a branch protection rule to require a release note file in each pull request.

Answer

Use a workflow that runs on pull request merge and creates a Git tag, then rely on GitHub to create a release from the tag.

Answer

Add a step to the existing CI workflow that runs 'gh release create' with a changelog.

Question 15

You are responsible for managing build pipelines in Azure DevOps for a large .NET solution that consists of multiple projects. The build takes approximately 45 minutes, which is too long. The solution has unit tests and integration tests. The integration tests require a database that is provisioned during the build. You need to reduce the build time while maintaining code quality. What should you do?

Accepted Answer

Enable incremental build by using the 'Build' task's 'Clean' option set to false, and separate unit and integration tests into different stages.. A is correct: Setting Clean to false enables incremental builds by preserving previous outputs and only rebuilding changed projects, which reduces build time. Separating unit and integration tests into different stages allows unit tests to run first, providing faster feedback and allowing integration tests to be skipped if unit tests fail, thus saving time while still maintaining overall code quality. B is not the best choice because moving integration tests to the release pipeline delays detection of integration issues, but it does not reduce code quality; however, it is less effective for early feedback. C can help if projects are independent, but it does not address the likely compile-time overhead of unchanged projects and may not solve the database-dependent test bottleneck. D is not ideal because moving tests out of the build pipeline means the build no longer validates test results, creating a gap in quality gating (even if another pipeline exists).

Answer

Remove integration tests from the build pipeline and run them only in the release pipeline.

Answer

Increase the number of parallel jobs and use a multi-agent job to build projects in parallel.

Answer

Disable the 'Test' step in the build pipeline and rely on a separate test pipeline.