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

Question 1

Your Azure DevOps pipeline uses a YAML template that defines variables. You want to override a variable value when running the pipeline manually. What is the best approach?

Accepted Answer

Use the 'Variables' tab in the pipeline run UI to set a new value for the variable.. Azure Pipelines allows you to override the value of a YAML-defined variable directly in the pipeline run UI via the 'Variables' tab when manually triggering a run. This approach is the simplest and most flexible way to change a variable's value without modifying the YAML template or pipeline definition, and it supports runtime parameterization for manual runs.

Answer

Create a variable group and link it to the pipeline.

Answer

Edit the template YAML file to hardcode the desired value.

Answer

Define a parameter in the template and pass the value via the 'Override' parameter in the pipeline.

Question 2

You are designing a release pipeline for a critical application that must minimize downtime during deployment. The application runs on Azure Kubernetes Service (AKS) and uses Azure SQL Database. Which deployment strategy should you recommend?

Accepted Answer

Blue-green deployment with traffic manager.. Blue-green deployment with Traffic Manager is recommended because it allows you to maintain two identical environments (blue and green) and instantly switch traffic between them via Azure Traffic Manager. This minimizes downtime to the time it takes to update DNS or routing rules, and provides immediate rollback capability by switching back to the previous environment. For a critical application on AKS with Azure SQL Database, this strategy avoids the complexity of managing state during rolling updates and ensures zero-downtime cutover.

Answer

Rolling update with health probes.

Answer

Canary deployment with progressive exposure.

Answer

Recreate deployment by deleting the old version first.

Question 3

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?

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 4

You are implementing a CI pipeline for a Node.js application. The pipeline must run linting, unit tests, and build the application. Which YAML structure is most appropriate?

Accepted Answer

Define one job with multiple steps: lint, test, build.. A CI pipeline for a Node.js application typically runs linting, unit tests, and build sequentially within a single job using multiple steps. This ensures that each step executes in order, sharing the same workspace and environment, which is efficient for a simple CI workflow. Defining separate stages (Option A) or multiple jobs (Option C) adds unnecessary overhead and complexity for tasks that are inherently sequential and do not require independent environments.

Answer

Define three separate stages: lint, test, build.

Answer

Define one job with parallel steps using 'parallel' keyword.

Answer

Define multiple jobs without dependencies.

Question 5

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.. Enabling Secret scanning and Push protection for the repository helps prevent secrets from being exposed in build logs. Secret scanning can detect secrets when they are pushed or used in workflows, and Push protection blocks pushes containing secrets. Additionally, GitHub Actions automatically masks any string that matches a repository secret or organization secret if it appears in logs, but the developer accidentally printed it. Enabling these features provides proactive detection and prevention. Option B is incorrect because adding the secret to the exclusion list would allow it to be exposed. Option C is incorrect because echoing with `::set-output` still prints the value to logs. Option D is incorrect because the `actions/secrets` action does not exist; secrets are accessed via the `secrets` context.

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 6

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 7

You are setting up a release pipeline that deploys to multiple environments (dev, test, prod) sequentially. Each environment requires approval before deployment. What is the best way to implement this in Azure Pipelines?

Accepted Answer

Define pipeline stages with environment resources and pre-deployment approvals.. Azure Pipelines supports multi-stage YAML pipelines where each stage can reference an environment resource. Pre-deployment approvals are configured on the environment itself, ensuring that before a stage deploys to that environment, the specified approvers must grant approval. This provides a native, auditable, and integrated approval gate without custom scripting or legacy tooling.

Answer

Use environment resources with 'auto' trigger and no approvals.

Answer

Use classic release pipelines with approval gates per environment.

Answer

Use a custom PowerShell script to pause and prompt for approval.

Question 8

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

Accepted Answer

Use variable groups linked to Azure Key Vault for secrets.. Variable groups linked to Azure Key Vault allow you to securely store and manage secrets (e.g., API keys, passwords) outside of pipeline definitions. Azure Pipelines retrieves these secrets at runtime via the Azure Key Vault REST API, ensuring they are never exposed in logs or YAML files. This follows the principle of least privilege and secrets management best practices.

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 9

Which THREE are valid deployment patterns for Kubernetes? (Choose three.)

Accepted Answer

Canary deployment. The correct deployment patterns in Kubernetes are canary, rolling update, and blue-green. A canary deployment releases a new version to a small subset of users first, allowing monitoring and gradual traffic shifting. A rolling update incrementally replaces old pods with new ones, ensuring zero downtime. A blue-green deployment runs two identical environments and switches traffic from the old (blue) to the new (green) environment after validation. Helm is a package manager, not a deployment pattern, and A/B testing is a traffic management technique rather than a core Kubernetes deployment strategy.

Answer

A/B testing deployment

Answer

Helm deployment

Question 10

Which TWO are true about Azure Pipelines YAML templates? (Choose two.)

Accepted Answer

Template expressions are evaluated at compile time.. Template expressions in Azure Pipelines YAML are evaluated at compile time, before the pipeline runs. This allows the template to inject variables, conditions, and other logic into the pipeline definition statically, ensuring that the final pipeline structure is fully resolved before execution begins.

Answer

Templates must be stored in the same repository as the main pipeline.

Answer

Templates require parameters to be defined.

Answer

Templates can only define a single job.

Question 11

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 uniqueString(resourceGroup().id) function generates a deterministic hash based on the resource group ID, resulting in a storage account name that is a hash rather than a human-readable name. Option B is incorrect because the parameter type 'string' can accept a default value that is a string, even if it looks like an object. Option C is incorrect because resourceGroup().location is a valid function that returns the location of the resource group. Option D is incorrect because the apiVersion '2022-09-01' is valid and does not cause naming conflicts; naming conflicts arise from the hash function, not the API version.

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 12

Refer to the exhibit. You have this GitHub Actions workflow YAML. The workflow does not trigger when you push to the main branch. What is the most likely issue?

Accepted Answer

The correct keyword is 'on', not 'triggers'.. GitHub Actions workflows use the `on` keyword to define triggers, not `triggers`. The YAML snippet incorrectly uses `triggers`, which is not a valid key in GitHub Actions syntax; the workflow engine ignores it, so no push event on `main` will start the workflow. This is a common syntax error where the candidate confuses Azure Pipelines (which uses `trigger`) with GitHub Actions (which uses `on`).

Answer

The branch name should be in a list under 'branches' inside 'push'.

Answer

The 'vmImage' should be 'windows-latest' for scripts.

Answer

The 'triggers' keyword is misspelled; it should be 'trigger'.

Question 13

Refer to the exhibit. You have this Azure Pipeline YAML. When you run the pipeline, it fails because the resource group name is not correctly resolved. What is the likely cause?

Accepted Answer

The variable 'resourceGroupName' uses $(environment) which cannot reference a parameter.. In Azure DevOps YAML pipelines, the `$()` syntax is used to reference runtime variables, not parameters. Parameters are defined using `parameters:` and are referenced with `${{ parameters.parameterName }}`. Using `$(environment)` attempts to resolve a variable named 'environment', but since 'environment' is defined as a parameter, it is not available as a variable at runtime, causing the resource group name to remain unresolved and the pipeline to fail.

Answer

The script type 'pscore' is not supported on Ubuntu.

Answer

Parameters cannot be used in YAML pipelines; they must be defined in a template.

Answer

The 'trigger: none' prevents the pipeline from running.

Question 14

Your team uses a multi-stage YAML pipeline. The 'Build' stage compiles the code and runs unit tests. The 'Deploy' stage deploys to a staging environment. You notice that if the 'Build' stage fails, the 'Deploy' stage still starts because it depends on a condition that always evaluates to true. How should you modify the pipeline to prevent the 'Deploy' stage from running if the 'Build' stage fails?

Accepted Answer

Add 'condition: succeeded()' to the Deploy stage.. The `succeeded()` function in Azure Pipelines evaluates whether all previous stages (or jobs, depending on context) have completed successfully. By adding `condition: succeeded()` to the Deploy stage, the stage will only run if the Build stage (its implicit or explicit dependency) succeeded. This directly prevents the Deploy stage from starting when the Build stage fails.

Answer

Add 'condition: eq(variables['Build.Succeeded'], 'true')' to the Deploy stage.

Answer

Add 'condition: and(succeeded(), eq(variables['Build.Succeeded'], 'true'))' to the Deploy stage.

Answer

Add 'dependsOn: Build' to the Deploy stage.

Question 15

Your organization requires that all code changes must be built and tested before merging to the main branch. You plan to use branch policies in Azure Repos. Which policy enforcement will ensure that a pull request cannot be completed unless the build succeeds?

Accepted Answer

Add a build validation policy that triggers a build on each PR update.. Azure Repos branch policies include a 'Build validation' policy that triggers a specified build pipeline on each pull request (PR) update. The policy enforces that the PR cannot be completed unless the build succeeds, directly meeting the requirement that all code changes must be built and tested before merging to the main branch.

Answer

Require a linked work item in the pull request.

Answer

Require a minimum number of reviewers.

Answer

Reset code reviewer votes when new changes are pushed.