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

Question 1

You are designing a release pipeline for a microservices application where each service is built as a Docker container and deployed to Azure Kubernetes Service (AKS). You want to ensure that each service is deployed independently to the same cluster. The services have dependencies on each other. Which deployment strategy should you use?

Accepted Answer

Blue-green deployment to AKS using Kubernetes namespaces for isolation.. Blue-green deployment is ideal for microservices with dependencies because it allows you to deploy a new version of a service alongside the old version and then switch traffic after testing. Rolling updates can cause issues if dependencies are not compatible. Canary releases are gradual but more complex. Option A is correct because blue-green provides isolation and easy rollback. Option B is not suitable for dependencies. Option C is more for testing. Option D is simpler but riskier.

Answer

Canary deployment with traffic splitting via Istio.

Answer

Immutable infrastructure with new cluster per deployment.

Answer

Rolling update using Kubernetes Deployment strategies.

Question 2

Your organization uses GitHub Actions with self-hosted runners on Azure virtual machines. You notice that some workflows are taking longer than expected because runners are busy. You need to improve the performance without adding more permanent runners. Which solution should you implement?

Accepted Answer

Implement auto-scaling for self-hosted runners using a scale set or Kubernetes-based runner controller.. GitHub Actions supports auto-scaling for self-hosted runners using scaling applications like 'actions-runner-controller' for Kubernetes or custom scripts. Option A is correct because it dynamically adds/removes runners based on demand. Option B increases cost and maintenance. Option C is for GitHub-hosted runners. Option D reduces wait but doesn't address root cause.

Answer

Migrate all workflows to GitHub-hosted runners.

Answer

Reduce the number of concurrent jobs in each workflow.

Answer

Increase the size of the existing self-hosted runner VMs to handle more jobs.

Question 3

You have a YAML pipeline that builds a Java project using Maven. The pipeline uses a private artifact feed in Azure Artifacts. You need to authenticate to the feed from the pipeline. Which authentication method should you use?

Accepted Answer

Use the 'MavenAuthenticate' task with a settings.xml file.. Azure Pipelines can use the project-level 'Azure Artifacts' service connection to authenticate to feeds. Option B is correct because it uses the pipeline identity. Option A is for npm. Option C is for Python. Option D is for NuGet.

Answer

Use the 'PipAuthenticate' task with a pip.conf file.

Answer

Use the 'npmAuthenticate' task with a .npmrc file.

Answer

Use the 'NuGetAuthenticate' task with a nuget.config file.

Question 4

Your team uses Azure Pipelines to deploy a web app to Azure App Service. The deployment uses the 'AzureWebApp@1' task with a deployment slot. You need to ensure that after a successful deployment to the staging slot, the slot swap happens automatically and the staging slot is warmed up before the swap. Which configuration should you use?

Accepted Answer

Set the 'Slot' parameter to 'staging' and enable 'Swap with production' in the task.. Option B is correct because the 'AzureWebApp@1' task includes a 'Swap with production' checkbox that, when enabled, automatically performs a slot swap after the deployment to the specified slot (e.g., staging) completes. This ensures the staging slot is warmed up by the deployment process before the swap, as the swap operation respects the warm-up phase of the target slot, preventing downtime and ensuring the production slot receives a fully initialized application.

Answer

Use the 'Azure App Service manage' task to swap slots after deployment.

Answer

Use the 'Azure CLI' task to run 'az webapp deployment slot swap' after deployment.

Answer

Configure the deployment task to deploy to staging and then use a separate task to swap.

Question 5

Which TWO of the following are valid strategies to securely store and use secrets in Azure Pipelines?

Accepted Answer

Link a variable group to Azure Key Vault and reference variables in the pipeline.. Variable groups can be linked to Azure Key Vault to store secrets securely. The 'AzureKeyVault@1' task can retrieve secrets from Key Vault at runtime. Option A is correct because variable groups support Key Vault integration. Option D is correct because the task can download secrets. Option B is not secure; Option C is not secure; Option E is not a pipeline feature.

Answer

Use the 'secret' variable type in YAML and hardcode the value.

Answer

Store secrets in a text file in the repository and use a script to read them.

Answer

Use encrypted environment variables in GitHub Actions.

Question 6

Which THREE of the following are valid considerations when designing a release pipeline to deploy to multiple environments (dev, test, prod) using Azure Pipelines YAML?

Accepted Answer

Use variable groups scoped to environments to override variables per stage.. Approval gates are configured on environments, not stages. Stage filters with conditions can control deployment to specific branches. Variables can be overridden per stage using variable groups scoped to environments. Option A is correct because approvals are set on environments. Option C is correct because stage filters can restrict branches. Option D is correct because variable groups can be scoped to environments. Option B is incorrect because stages don't have approvals. Option E is incorrect because YAML templates are not required.

Answer

Use stage-level approvals to gate each stage.

Answer

Use YAML templates to define each environment's deployment steps.

Question 7

Which TWO of the following are true about multi-stage pipelines in Azure Pipelines?

Accepted Answer

Stages can run in parallel if dependencies allow.. Multi-stage pipelines are defined in YAML and can include multiple sequential or parallel stages. Option A is correct because YAML is the primary definition. Option C is correct because stages can be parallelized using dependsOn. Option B is incorrect because stages can run across multiple agents. Option D is incorrect because stages are not limited to one job. Option E is incorrect because stages can have conditions.

Answer

Each stage can contain only one job.

Answer

Each stage must run on the same agent.

Answer

Stages cannot have conditions.

Question 8

Refer to the exhibit. This YAML pipeline snippet is configured in an Azure Pipelines YAML file. The team reports that the pipeline does not trigger when changes are pushed to the main branch that modify files outside the /src folder. What is the most likely reason?

Accepted Answer

The path filter restricts the trigger to only changes in /src/.. The trigger includes a path filter that only includes /src/*. This means the pipeline will only trigger if changes are in /src. Option C is correct. Option A is incorrect because the trigger is valid. Option B is incorrect because vmImage is not the issue. Option D is incorrect because script is valid.

Answer

The trigger syntax is incorrect; 'branch' should be 'branches'.

Answer

The script step is missing a display name.

Answer

The pool vmImage is not specified correctly.

Question 9

Refer to the exhibit. This multi-stage YAML pipeline has a variable 'publishEnabled' set to false. The team wants the Publish stage to run only when 'publishEnabled' is true. However, the Publish stage never runs, even when the variable is changed to true at queue time. What is the most likely cause?

Accepted Answer

The variable 'publishEnabled' is not settable at queue time; it is a compile-time variable.. In YAML pipelines, variables defined in the 'variables' section are compile-time and cannot be overridden at queue time unless they are marked as 'queue-time' settable. The condition 'eq(variables['publishEnabled'], true)' evaluates at runtime, but the variable value is fixed at compile time. Option C is correct. Option A is incorrect because 'dependsOn' is correct. Option B is incorrect because the condition syntax is valid. Option D is incorrect because the variable is not runtime-settable.

Answer

The condition syntax is wrong; it should use 'eq(variables.publishEnabled, true)'.

Answer

The Publish stage is missing 'dependsOn: Build'.

Answer

The 'dependsOn' syntax is incorrect; it should be 'dependsOn: Build'.

Question 10

Refer to the exhibit. This YAML pipeline snippet uses parameters to deploy to different environments. The team wants to run the pipeline for a specific environment by providing the parameter at queue time. However, the pipeline fails with 'Invalid stage name'. What is the most likely cause?

Accepted Answer

Stage names cannot contain template expressions; they must be static.. Stage names cannot contain template expressions like '${{ parameters.environment }}' directly; they must be resolved to a static string. In YAML, stage names are used for dependencies and must be known at compile time. Using a parameter in the stage name is not allowed because the parameter value is not known when the YAML is parsed. Option A is correct. Option B is incorrect because the task inputs are fine. Option C is incorrect. Option D is incorrect.

Answer

The parameter values must be defined in a separate file.

Answer

The 'AzureWebApp@1' task inputs are incorrectly formatted.

Answer

The 'stage' keyword should be 'stageName'.

Question 11

Your team uses Azure DevOps to build a .NET application. The build pipeline takes 45 minutes to complete. You want to reduce build times by caching dependencies. What should you configure in the pipeline?

Accepted Answer

Add a Cache task with a key based on the package-lock.json file hash.. Using the Cache task with a key based on the package-lock.json file restores cached dependencies when the file hasn't changed, reducing build time. Option A is wrong because Build Retention Policy controls artifact retention, not caching. Option B is wrong because Incremental builds are not natively supported in YAML pipelines. Option D is wrong because Pipeline Artifacts are for sharing files between stages, not caching.

Answer

Configure a Build Retention Policy to keep only the latest build.

Answer

Use Pipeline Artifacts to store dependencies between builds.

Answer

Enable Incremental builds in the pipeline settings.

Question 12

You are designing a release pipeline for a critical production application. The pipeline must ensure that changes are deployed to a staging environment first, and if integration tests pass, they are automatically deployed to production. However, if the tests fail, the deployment to production must be blocked. What is the best approach?

Accepted Answer

Create a multi-stage YAML pipeline with a gate on the production stage that evaluates test results from the staging stage.. A multi-stage YAML pipeline with a gate on the production stage that evaluates test results is the best approach because it allows for automated promotion with conditional logic. Option A is wrong because a single stage with conditional tasks doesn't separate environments properly. Option B is wrong because separate pipelines are harder to manage and coordinate. Option D is wrong because manual approval defeats the requirement for automatic deployment.

Answer

Create a single stage in the pipeline with conditional tasks to deploy to staging and then to production based on test results.

Answer

Create two separate pipelines: one for staging and one for production. Use a pipeline trigger to run the production pipeline after staging completes.

Answer

Use a classic release pipeline with pre-deployment approvals on the production stage.

Question 13

Which TWO features in Azure Pipelines allow you to enforce separation of duties between development and operations teams? (Choose two.)

Accepted Answer

Approvals and checks on environments. Approvals and checks enforce separation by requiring ops approval before deployment. Environment security ensures only specific users can deploy to production. Option C is wrong because branch policies are for source control, not deployment. Option D is wrong because service connections are for authentication, not separation of duties. Option E is wrong because pipeline decorators inject steps but do not enforce separation.

Answer

Pipeline decorators

Answer

Service connections with different scopes

Answer

Branch policies on the main branch

Question 14

Your build pipeline includes a task that runs unit tests. You want to ensure that if any test fails, the pipeline stops immediately and does not proceed to the next tasks. What should you configure in the pipeline?

Accepted Answer

Ensure the task control option 'Run this task' is set to 'Only when all previous tasks have succeeded'.. Setting the task control option 'Run this task' to 'Only when all previous tasks have succeeded' ensures that the pipeline stops on failure. Option A is wrong because 'Continue on error' allows the pipeline to continue even if the task fails. Option C is wrong because 'Always run' runs the task regardless of previous failures. Option D is wrong because 'Custom conditions' can be used but are not the simplest way to stop on failure.

Answer

Set the 'Continue on error' option to false for the test task.

Answer

Add a custom condition to the test task to only run if previous tasks succeeded.

Answer

Set the 'Always run' option for the test task.

Question 15

Refer to the exhibit. The YAML pipeline triggers on commits to main and develop branches, and pull requests targeting develop. A developer pushes a commit directly to main. What will happen?

Accepted Answer

The pipeline runs once for the CI trigger.. The trigger includes main, so a push to main triggers a build. The PR trigger includes develop, but since it's a push to main, not a PR, only the CI trigger applies. Option A is wrong because PR trigger only applies to PRs. Option C is wrong because the pipeline will run once for the CI trigger. Option D is wrong because the PR trigger does not cover pushes to main.

Answer

The pipeline does not run because the PR trigger requires a pull request.

Answer

The pipeline runs twice: once for the CI trigger and once for the PR trigger.

Answer

The pipeline runs once for the PR trigger only.