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

Question 1

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 2

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 3

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 4

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.

Question 5

Your team uses Azure Pipelines to deploy a multi-tier application to Azure. The application consists of a web frontend, an API backend, and a database. You need to deploy the database schema changes using a DACPAC file. The deployment should be idempotent and support rollback. You must use the Azure SQL Database deployment task. What should you do?

Accepted Answer

Use the 'Azure SQL Database deployment' task with the 'Deploy' action, specifying the DACPAC file and setting the 'Additional Arguments' to include 'p:BlockOnPossibleDataLoss=False' for safety.. The 'Azure SQL Database deployment' task with the 'Deploy' action is the correct way to deploy a DACPAC file idempotently. To support rollback and avoid data loss, the additional argument should be 'p:BlockOnPossibleDataLoss=True' (or leave the default True). Option A incorrectly sets it to False under the pretense of safety. Option B is incorrect because the Query action is for running queries, not deploying DACPAC. Option C is incorrect because it violates the stated requirement to use the Azure SQL Database deployment task. Option D is incorrect because Run SQL Script is for executing SQL scripts, not DACPAC deployment. Therefore, none of the provided options are fully correct.

Answer

Use the 'Azure SQL Database deployment' task with the 'Query' action to run schema changes.

Answer

Use a 'PowerShell' task to run 'SqlPackage.exe' with the DACPAC file.

Answer

Use the 'Azure SQL Database deployment' task with the 'Run SQL Script' action, and execute the schema changes as SQL scripts.

Question 6

You are configuring a YAML pipeline in Azure Pipelines. The pipeline must trigger only when changes are pushed to the main branch. Which setting should you configure?

Accepted Answer

Set the trigger to include the main branch.. In Azure Pipelines YAML, the `trigger` section controls which branches cause a CI pipeline to run. By setting `trigger.branches.include` to `main`, only pushes to `main` will trigger the pipeline. All other branches are automatically excluded. There is no separate setting required to disable triggers for other branches; the include list is authoritative.

Answer

Set the PR trigger to include main.

Answer

Set the pipeline to run on every push regardless of branch.

Answer

Use a schedule trigger with cron expression.

Answer

Set the trigger to none for other branches.

Question 7

Your release pipeline uses a deployment group to deploy to multiple on-premises servers. You need to ensure that only healthy servers receive the deployment and that deployment history is retained. Which THREE actions should you include?

Accepted Answer

Set a retention policy to keep deployment history for a specified number of days.. A retention policy (A) ensures deployment history is retained. Configuring health checks (C) verifies that each target server is healthy before deployment, so only healthy servers receive the release. Tagging servers by role (B) is used for targeting specific servers based on role, not for verifying health, and is not a stated requirement. Therefore, only A and C directly satisfy the requirements.

Answer

Tag each server with its role (e.g., web, API).

Answer

Use a single deployment group for all servers.

Answer

Disable parallel deployment to avoid conflicts.

Question 8

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 9

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.. 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 10

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.. Path filters in the trigger section allow you to specify include and exclude patterns. By using exclude patterns for 'docs/*' and '*.md', the pipeline will not trigger when only documentation files are changed. Option B is incorrect because branch policies do not affect the pipeline trigger; they govern pull request requirements. Option C is incorrect because conditions are evaluated at runtime, whereas we want to avoid triggering the pipeline altogether. Option D is incorrect because disabling CI trigger would require manual or scheduled builds, which is less efficient than using path filters.

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 11

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.. 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 12

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.. Azure Pipelines allows you to mark variables as secret by using the 'secret' input type in the pipeline settings UI or by setting `secret: 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. Additionally, storing secrets in a variable group linked to Azure Key Vault provides a secure, centralized way to manage secrets, with access control, versioning, and auditability, making it a best practice for protecting sensitive data.

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 13

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 14

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.. 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 15

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')`.. 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`.