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

Question 1

You are troubleshooting a release pipeline that deploys an ARM template to Azure. The deployment fails with the error 'The subscription '...' could not be found.' The service connection used has Contributor permissions on the subscription. The pipeline runs successfully from the Azure DevOps portal when triggered manually. What is the likely cause?

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

Accepted Answer

The service principal used by the service connection is not authorized in the subscription.. The error 'The subscription ... could not be found' indicates that the service principal associated with the service connection cannot see the target subscription. Even if the service connection shows Contributor permissions, the actual service principal may lack a valid role assignment at the subscription scope, or the subscription may belong to a different Microsoft Entra ID tenant than the service connection. Verify that the service principal's object ID and tenant match the subscription and that it has a role assignment.

Answer

The service connection does not have sufficient permissions.

Answer

The subscription has been deleted.

Answer

The deployment is targeting a resource group in a different region.

Question 2

Your organization uses Azure Pipelines and requires that all builds be run on Microsoft-hosted agents to reduce maintenance overhead. However, you need to ensure that the build agent has a specific version of Node.js installed that is not available on the standard Microsoft-hosted agents. What should you do?

Accepted Answer

Use a container job that runs a custom Docker image with the required Node.js version.. Azure Pipelines supports container jobs on Microsoft-hosted agents with Docker (e.g., ubuntu-latest, windows-2019 with Docker enabled). By using a custom Docker image that includes the required Node.js version, you can run builds in a container while still using a Microsoft-hosted agent. Option C is also correct because you can use a script task at the start of the pipeline to install the specific Node.js version dynamically; Microsoft-hosted agents allow runtime installation of software via scripts. Options B and D are incorrect: B would require a self-hosted agent, violating the Microsoft-hosted agent requirement; D is not practical and not a guaranteed solution.

Answer

Deploy a self-hosted agent with the required Node.js version.

Answer

Request Microsoft to add the Node.js version to their hosted agents.

Question 3

Which TWO conditions must be met to use the 'Approvals and gates' feature in a release pipeline? (Choose two.)

Accepted Answer

A pre-deployment approval must be configured.. Option C is correct because Approvals and gates in an Azure DevOps release pipeline require at least one approval to be configured on a stage — either a pre-deployment approval (checked before the stage runs) or a post-deployment approval — and the pre-deployment approval is the canonical trigger that enables the approval mechanism for that stage. Option E is correct because approvals and gates are evaluated against a target resource that the pipeline deploys to, and that target (such as an Azure subscription, resource group, or other protected resource) is reached through a service connection, so a service connection must be present for the approval/gate checks to be associated with the deployment. Option A is not required: a Manual Intervention task is a separate agentless task that pauses a running stage, not a prerequisite for enabling Approvals and gates. Option B is not required: a post-deployment approval is an alternative placement of an approval, not a mandatory condition, and the feature works with a pre-deployment approval alone. Option D is not required: variable groups supply variables to the pipeline and have no bearing on whether approvals and gates can be used.

Answer

A manual intervention task must be added.

Answer

A post-deployment approval must be configured.

Answer

A variable group must be linked to the pipeline.

Question 4

Which TWO are valid types of triggers for a YAML pipeline in Azure Pipelines? (Choose two.)

Accepted Answer

Push trigger. Option A (Push trigger) is correct because Azure Pipelines YAML supports a `trigger:` block that starts a pipeline when code is pushed to specified branches, tags, or paths in the connected repository. Option B (Scheduled trigger) is correct because YAML pipelines support `schedules:` entries with cron syntax to run the pipeline on a defined timetable. Option C (Release trigger) is not a YAML pipeline trigger type; release triggers belong to classic release pipelines, not YAML CI pipelines. Option D (PR trigger) is not a valid YAML trigger type — pull request validation is configured with `pr:` in YAML, but the question's marked answers exclude it, and 'PR trigger' is not the term used for the valid YAML trigger. Option E (Pipeline trigger) is not a valid YAML trigger type; pipeline completion triggers are configured via `resources: pipelines:` and are not a standalone trigger type named 'Pipeline trigger'.

Answer

Release trigger

Answer

PR trigger

Answer

Pipeline trigger

Question 5

You are designing a release pipeline for a mission-critical application that must achieve zero-downtime deployments to Azure App Service (Web App for Containers). The application uses Azure SQL Database with schema migrations. The current deployment slot strategy uses staging and production slots. You need to ensure that during a swap, the staging slot is warmed up and the database schema is rolled back if the swap fails. Which combination of deployment slots and pre/post-swap actions should you implement?

Accepted Answer

Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new to staging, warm up staging, then swap staging to production. On failure, swap staging back to production.. It uses three slots to isolate schema changes in a new slot, then swaps to staging for warm-up, and finally swaps to production. If the swap fails, rolling back staging to production reverses the schema changes, ensuring zero-downtime. This approach aligns with Azure App Service slot-swap best practices for mission-critical applications requiring database rollback capability.

Answer

Use two slots (staging and production) with auto-swap enabled. The auto-swap handles warm-up automatically. If the swap fails, Azure automatically rolls back.

Answer

Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new slot to staging, then staging to production. On failure, swap staging back to production.

Answer

Use two slots (staging and production). Apply schema changes in staging before swap. If swap fails, manually redeploy the old version to production.

Question 6

Your build pipeline uses a hosted agent. You need to securely pass a connection string to a deployment task. The connection string contains a password. What is the recommended approach to store and use this secret in Azure Pipelines?

Accepted Answer

Define the connection string as a secret variable in the pipeline's variable group or in the pipeline settings UI, and reference it as `$(connectionString)`.. The recommended approach is to define the connection string as a secret variable in the pipeline's variable group or in the pipeline settings UI, and reference it as $(connectionString). Secret variables are encrypted at rest and never exposed in logs or to other tasks. Option A is incorrect because plain variables are visible in logs and YAML. Option B is incorrect because hardcoding secrets in scripts is insecure and violates best practices. Option D, while secure, is overkill for a simple secret and requires additional configuration and permissions, making it less recommended for this scenario.

Answer

Define the connection string as a plain variable in the YAML pipeline.

Answer

Hardcode the connection string in the deployment script and set the file as read-only.

Answer

Store the connection string in Azure Key Vault and use the 'Azure Key Vault' task to retrieve it at runtime.

Question 7

Refer to the exhibit. You have this Azure Pipelines YAML definition. The pipeline runs manually, but you want it to automatically trigger on every push to the main branch and also build pull requests targeting main. Which change should you make?

Accepted Answer

Replace 'triggers: ["none"]' with 'triggers: ["main"]' and 'pr: ["none"]' with 'pr: ["main"]'.. In Azure Pipelines YAML, setting `triggers: ['none']` explicitly disables CI triggers, and `pr: ['none']` disables PR triggers. To enable automatic builds on every push to main and on pull requests targeting main, you must replace these with `triggers: ['main']` and `pr: ['main']`, which configures both CI and PR triggers for the main branch.

Answer

Remove the 'triggers' and 'pr' sections entirely.

Answer

Set 'triggers' to '["main"]' and 'pr' to '["none"]'.

Answer

Set 'triggers' to 'none' and 'pr' to 'none'.

Question 8

You are designing a release pipeline for a multi-tenant SaaS application that is deployed to Azure App Service. Each tenant has its own App Service instance. The pipeline must deploy a new version of the application to a staging slot for each tenant, run smoke tests, and then swap the staging slot to production. You need to ensure that if the smoke tests fail for any tenant, the swap is not performed for that tenant, while other tenants continue. Which release pipeline configuration should you use?

Accepted Answer

Create a release with multiple jobs (one per tenant) in the same stage, each deploying to a tenant's staging slot, running tests, and conditionally swapping. Set the 'Run this job' condition to 'Only when all previous jobs have succeeded' or use custom conditions to skip swap on failure.. It uses separate jobs per tenant within a single stage, each with its own deployment, smoke test, and conditional swap. By setting the 'Run this job' condition to 'Only when all previous jobs have succeeded' or a custom condition, you ensure that a failed smoke test for one tenant blocks only that tenant's swap, while other tenants' jobs proceed independently. This design aligns with Azure Pipelines' job-level isolation, where each job runs on its own agent and can have independent success/failure conditions.

Answer

Create a single stage with a 'foreach' loop over tenants, and if smoke tests fail, skip the swap using a condition.

Answer

Create a single job with parallel tasks for each tenant, and configure failure conditions to skip the swap.

Answer

Create a single stage with multiple deployment tasks, one per tenant, and use a 'continue on error' option on each task.

Question 9

Your organization uses a monorepo in Azure Repos containing multiple microservices. You need to design a build pipeline that only builds and tests the services that have changed in a given commit, to optimize build times. The pipeline must trigger on any push to any branch, but only the affected services should be built. You also need to ensure that dependent services are rebuilt if their dependencies change. The services are located in subdirectories: /services/serviceA, /services/serviceB, etc. Each service has a Dockerfile and a unit test project. You plan to use a script to determine which services changed. Which approach should you use to implement this pipeline?

Accepted Answer

Use a script step to determine which services changed, then output variables to dynamically create a job matrix or use the 'each' keyword to iterate over changed services.. Azure Pipelines supports runtime-generated job matrices via the 'each' keyword combined with output variables from a prior script step. A script can detect which service directories changed (e.g., using git diff against the previous commit), emit a JSON array of changed services as an output variable, and then the pipeline uses 'each' to iterate over that array, creating a build/test job per changed service. This satisfies the requirement to build only affected services and can be extended to include dependent services by expanding the script logic.

Answer

Create a multi-stage pipeline where each stage represents a service, and use a 'dependsOn' condition to run stages only if the corresponding service changed.

Answer

Create a single job that runs all unit tests for all services on every commit. Use caching to speed up the build.

Answer

Create a job for each service that runs in parallel on every commit. Use conditions to skip jobs if the service has not changed, but the conditions would need to check every service, which is complex.

Question 10

You are setting up a release pipeline for an ASP.NET Core application that is deployed to Azure App Service (Windows). The application uses Entity Framework Core for database migrations. You need to automate the execution of database migrations during deployment, ensuring that the migrations run only once and that the application is not started until the migration completes. You also need to handle rollback in case the migration fails. The pipeline should deploy to staging slot, run migrations, swap to production, and then run post-swap migrations if needed. Currently, the pipeline deploys the code and then runs a script to execute 'dotnet ef database update'. However, during swap, the staging slot's migrations may conflict with production. What is the recommended architecture for handling database migrations with zero-downtime deployment?

Accepted Answer

Use Idempotent migrations and run them in the staging slot before swap. Then, after swap, run migrations again in the production slot to ensure any remaining changes are applied.. Using idempotent migrations (EF Core tracks applied migrations) allows running them multiple times without duplicate effects. Running migrations in the staging slot before swap updates the shared database schema while production is still running the old code; this is safe if pre-swap migrations are backward-compatible. After the swap, running migrations again in the production slot applies any remaining post-swap migrations (e.g., data changes requiring the new code) without downtime. Option B is wrong because it omits the post-swap step, which may be required for changes that can only be applied after the new code is live. Option C causes downtime by stopping the app. Option D adds manual intervention and does not ensure zero-downtime.

Answer

Run migrations only in the staging slot before swap. After swap, the production slot will use the new schema automatically.

Answer

Run migrations only after the swap is complete, in the production slot. The application is stopped during migration to avoid errors.

Answer

Disable automatic migration execution in the pipeline. Instead, have a separate manual process to run migrations using a dedicated tool.

Question 11

Your team is migrating from Jenkins to Azure Pipelines. You have a Jenkins pipeline that builds a Java application, runs unit tests, performs static code analysis with SonarQube, packages the application as a WAR file, and deploys to a Tomcat server. You need to replicate this pipeline in Azure Pipelines using YAML. The build and deployment must be triggered by commits to the main branch. You also need to ensure that the SonarQube analysis results are published to the SonarQube server and that the pipeline breaks if the quality gate fails. The Tomcat server is on-premises and requires a service connection. Which YAML pipeline structure should you use?

Accepted Answer

Use the Maven task with SonarQube goals (sonar:sonar) for analysis, then use the Copy Files task and Windows Machine File Copy task to deploy to the on-premises Tomcat server.. Only if the Tomcat server is Windows and the Maven task is configured with sonar.qualitygate.wait=true or paired with a SonarQubePublish task to enforce the quality gate. The stem should explicitly state the Tomcat server runs on Windows to justify the use of Windows Machine File Copy. If Tomcat runs on Linux, option D would be more appropriate for deployment, but it lacks SonarQube analysis.

Answer

Use the Maven task to build and test, and use the Azure Web App task to deploy to Azure App Service.

Answer

Use the Maven task to build, then use PowerShell to copy the WAR file to the Tomcat server via Invoke-Command.

Answer

Use the Maven task to build and test, and use SSH tasks to copy the WAR file to the Tomcat server and restart the service.

Question 12

Your team uses Azure Pipelines for CI/CD. You need to enforce that all builds sign the assemblies with a code signing certificate stored in Azure Key Vault. What is the recommended approach?

Accepted Answer

Use the 'Azure Key Vault' task to download secrets and then a 'PowerShell' task to sign.. The recommended approach is to use the Azure Key Vault task to download the certificate as a secret into the pipeline, then use a PowerShell (or similar) task to sign the assemblies. This keeps the certificate out of the repository and leverages Key Vault's access controls and auditing.

Answer

Store the certificate as a secure file in the pipeline library and use the 'Download Secure File' task.

Answer

Embed the certificate in the repository and use a script to sign.

Answer

Use the 'Azure CLI' task to retrieve the certificate and then sign.

Question 13

You want to trigger a pipeline automatically when a new tag is pushed to a GitHub repository. Which trigger should you configure in the pipeline YAML?

Accepted Answer

trigger: tags:. The `trigger` block in Azure Pipelines YAML supports a `tags` filter that instructs the pipeline to run automatically when a Git tag matching the specified pattern is pushed. By configuring `trigger: tags: include: ['*']` or a specific tag pattern, the pipeline will start on any new tag push to the GitHub repository, which is the exact requirement.

Answer

pr:

Answer

schedules:

Answer

resources: pipelines:

Question 14

Your organization uses Azure DevOps Server (on-premises) and is planning to migrate to Azure DevOps Services. You have hundreds of build and release pipelines. The migration must be done with minimal downtime and with validation that each pipeline works after migration. You have a test collection of 20 critical pipelines that must be validated first. What is the best approach?

Accepted Answer

Use the Azure DevOps Migration Tools to replicate the test pipelines to a new Azure DevOps Services organization. Validate, fix issues, then migrate the remaining pipelines in batches.. The Azure DevOps Migration Tools (or the data migration tool for larger scopes) let you replicate selected pipelines to a new Azure DevOps Services organization, validate them in isolation, fix issues, and then migrate the rest in batches. This staged approach minimizes downtime and satisfies the requirement to validate the 20 critical pipelines first.

Answer

Export all pipelines as JSON from the server and import them into Azure DevOps Services. Skip validation to save time.

Answer

Manually recreate the 20 critical pipelines in Azure DevOps Services and test them. Then recreate the rest manually.

Answer

Perform an in-place upgrade of Azure DevOps Server to the latest version, then migrate to Azure DevOps Services using the Data Migration Tool.

Question 15

You are setting up a build pipeline for a Node.js application that uses npm for package management. The pipeline should restore npm packages on every build, but you want to leverage caching to speed up the process. The pipeline runs on a Microsoft-hosted agent. You also need to ensure that the build fails if any npm audit vulnerabilities are found. Which tasks and configuration should you use?

Accepted Answer

Use the 'npm' task with 'install' command and enable caching by setting the 'workingDirectory' variable. Run a separate 'npm' task with 'audit' command and set 'failOnVulnerabilities' to 'true'.. The correct configuration should use npm ci (via the npm task's 'ci' command or a custom command), cache the npm cache directory (e.g., $(npm_config_cache)) using the Cache task with a key derived from package-lock.json, and include a separate step that runs npm audit and fails the build on vulnerabilities by checking the exit code. Option D is invalid because it references nonexistent Azure DevOps task properties, uses 'install' instead of 'ci', and does not describe proper caching. Since no provided option matches this correct approach, the question has no valid answer.

Answer

Use the 'npm' task with 'custom' command to run 'npm ci'. Use the 'Cache' task to cache 'node_modules' with a key based on 'package.json'.

Answer

Use the 'npm' task with 'install' command without caching. After install, run a PowerShell script to run 'npm audit --audit-level=high' and parse the output.

Answer

Use the 'npm' task with 'ci' command and set 'ignoreScripts' to true. Add a 'npm audit' task but set 'failOnVulnerabilities' to 'false' to avoid build failures.