AZ-400 Practice Test 31 — 15 Questions

Question 1

Your team uses Azure Pipelines to deploy a Docker container to Azure Kubernetes Service (AKS). The pipeline builds a Docker image, pushes it to Azure Container Registry (ACR), and then runs a deployment to AKS. You want to ensure that the deployment uses the exact image that was built in the same pipeline run. Which approach should you use?

Accepted Answer

Generate a unique tag (e.g., Build.BuildId) and pass it to both the Docker build and Kubernetes manifest via variable substitution.. Option C is correct because using a manifest file with build-specific variables ensures the correct image tag is used. Option A is wrong because 'latest' tag can be overwritten. Option B is wrong because the ACR task can be reused. Option D is wrong because separate pipelines may have different image builds.

Answer

Use two separate pipelines: one for build/push, one for deploy, and share the image tag via a variable group.

Answer

Use a single task for build and push, and rely on ACR's internal pull-through cache.

Answer

Tag the image as 'latest' and reference it in the Kubernetes manifest.

Question 2

Your pipeline uses a multi-stage YAML file. You want to conditionally run a stage only when the build is triggered from the 'main' branch. Which expression should you use in the 'condition' property of the stage?

Accepted Answer

eq(variables['Build.SourceBranch'], 'refs/heads/main'). Option C is correct because eq(variables['Build.SourceBranch'], 'refs/heads/main') compares the source branch to the main branch. Option A is wrong because 'main' is not a valid branch reference; Azure Pipelines uses 'refs/heads/main'. Option B is wrong because 'Build.SourceBranchName' returns 'main' but comparing to 'refs/heads/main' would fail. Option D is wrong because 'startsWith' might match branches like 'maintenance'.

Answer

startsWith(variables['Build.SourceBranch'], 'main')

Answer

eq(variables['Build.SourceBranchName'], 'refs/heads/main')

Answer

eq(variables['Build.SourceBranch'], 'main')

Question 3

Which THREE factors should you consider when designing a strategy for managing secrets in Azure Pipelines? (Choose three.)

Accepted Answer

Use Azure Key Vault to store secrets.. Options A, C, and E are correct. Secrets should be stored in Azure Key Vault, retrieved using library variable groups linked to Key Vault, and referenced as secret variables. Option B is incorrect because variables in YAML are visible in logs. Option D is incorrect because hardcoding secrets is insecure.

Answer

Hardcode secrets in the pipeline YAML for simplicity.

Answer

Store secrets as plain text variables in YAML pipelines.

Question 4

You are designing a build pipeline for a Node.js application. The team wants to ensure that the pipeline runs unit tests and publishes test results to Azure DevOps. Which task should you add to the pipeline?

Accepted Answer

Publish Test Results task. The 'Publish Test Results' task is specifically designed to publish test results in formats like JUnit, NUnit, etc., to Azure DevOps. Option A is wrong because 'npm test' only runs tests but doesn't publish results. Option B is wrong because 'Copy Files' only copies files. Option D is wrong because 'Publish Build Artifacts' publishes build outputs, not test results.

Answer

Copy Files task

Answer

npm test

Answer

Publish Build Artifacts task

Question 5

Which THREE steps should you take to implement a blue-green deployment strategy for an Azure App Service using Azure Pipelines? (Choose three.)

Accepted Answer

Create a deployment slot named 'staging' for the App Service.. Blue-green deployment: deploy to a staging slot (A), swap slots after validation (B), and enable auto-swap for zero-downtime (E). Option C is wrong because deleting the production slot is not part of blue-green; you swap to make it active. Option D is wrong because you typically route a percentage of traffic to the staging slot for testing, not 100%.

Answer

Delete the production slot after swapping.

Answer

Route 100% of traffic to the staging slot.

Question 6

Your release pipeline deploys to multiple Azure regions. You need to ensure that if a deployment to one region fails, the pipeline continues deploying to other regions. Which deployment strategy should you use?

Accepted Answer

Rolling deployment. A rolling deployment updates instances gradually and can continue if one region fails. Option A is wrong because blue-green would switch all traffic at once. Option B is wrong because canary targets a small subset. Option D is wrong because immutable replaces all instances.

Answer

Immutable deployment

Answer

Blue-green deployment

Answer

Canary deployment

Question 7

You are designing a build pipeline for a Python application that uses multiple external packages from PyPI. You want to ensure that builds are reproducible and not affected by package updates. Which strategy should you use?

Accepted Answer

Pin exact versions in requirements.txt.. Option C is correct because using a requirements.txt with pinned versions ensures exact package versions are installed. Option A is wrong because it suggests using latest, which breaks reproducibility. Option B is wrong because it only uses lock file but without version pinning. Option D is wrong because it only updates lock file periodically, still allowing variability.

Answer

Use a Pipfile and Pipfile.lock without version pinning.

Answer

Use a dependency update tool like Dependabot weekly.

Answer

Use 'pip install <package>' without version specifiers.

Question 8

Your team uses Azure Pipelines for CI/CD. You need to enforce that all builds produce a signed artifact. Which approach should you use?

Accepted Answer

Use a Pipeline decorator to inject the signing task into every build pipeline.. Option D is correct because Pipeline decorators allow injecting a task (like signing) into every pipeline without modifying each pipeline definition. Option A is wrong because requiring a manual approval gate does not enforce signing. Option B is wrong because branch policies control PR merges, not build steps. Option C is wrong because YAML templates require explicit inclusion in each pipeline.

Answer

Add a YAML template that includes the signing task and require all pipelines to extend it.

Answer

Set a branch policy requiring a signed build status.

Answer

Configure a manual approval gate on the build pipeline.

Question 9

Refer to the exhibit. You have a YAML pipeline that deploys an ARM template. The pipeline runs successfully on the first commit to main, but subsequent commits fail with 'The resource group myResourceGroup already exists'. How should you modify the pipeline to avoid this error?

Accepted Answer

Add a condition to check if the resource group exists before creating it.. Option C is correct because adding a condition to check if the resource group exists before creating it will prevent the error. Option A is wrong because changing the location does not solve the existence issue. Option B is wrong because using a different pipeline name is irrelevant. Option D is wrong because the error is not about credentials.

Answer

Change the location to a different region.

Answer

Use a different service connection for each deployment.

Answer

Rename the pipeline to trigger a clean build.

Question 10

You are setting up a release pipeline for a web application. The pipeline must deploy to three environments: Dev, Test, and Prod. The deployment to Prod must be triggered only after a successful deployment to Test and after a manual approval. How should you configure the pipeline?

Accepted Answer

Add a pre-deployment approval gate on the Prod environment.. Option A is correct because pre-deployment approvals on the Prod stage ensure manual approval before deployment. Option B is wrong because a separate manual task would not block the pipeline. Option C is wrong because conditions alone don't enforce manual approval. Option D is wrong because schedule ignores approval.

Answer

Add a manual intervention task before the Prod deployment in the pipeline.

Answer

Use a condition on the Prod stage to require success from Test and manual intervention variable.

Answer

Schedule the Prod deployment to run after Test, and require manual trigger.

Question 11

Your release pipeline deploys to multiple environments (Dev, Test, Prod) using approval gates. Recently, the Prod deployment failed because a manual validation task timed out after 30 minutes. You need to ensure that if the manual validation is not approved within 15 minutes, the pipeline automatically rejects the deployment and sends a notification. What should you do?

Accepted Answer

In the Manual Validation task, set 'Timeout' to 15 and 'On timeout' to 'Reject'.. Option D is correct because the Manual Validation task has a 'Timeout' setting; setting it to 15 minutes and configuring the 'On timeout' option to 'Reject' will automatically reject the deployment. Notifications can be set via subscription. Option A is wrong because pre-deployment approvals don't have a timeout that triggers rejection. Option B is wrong because the pipeline-level timeout is not granular enough. Option C is wrong because the 'Cancel' action would cancel the entire pipeline, not just reject the validation.

Answer

Set the 'Timeout in minutes' for the entire stage to 15.

Answer

Configure a pre-deployment approval with a timeout of 15 minutes.

Answer

Add a PowerShell task after the manual validation that checks the status and cancels the pipeline if not approved.

Question 12

Your team uses GitHub Actions to build and deploy a Node.js application to Azure App Service. The deployment succeeds, but the app crashes after startup with an error indicating a missing module. The build artifact includes the node_modules folder. What is the most likely cause?

Accepted Answer

The Node.js version on the runner differs from the App Service runtime, causing native module incompatibility.. Option C is correct because GitHub Actions runners may include a different Node.js version than the target App Service, causing native module incompatibility. Option A is wrong because the node_modules folder is included. Option B is wrong because the YAML syntax is valid. Option D is wrong because build optimization does not cause missing modules.

Answer

The .gitignore file excludes node_modules from the artifact.

Answer

The workflow YAML has an indentation error that causes the deploy step to fail silently.

Answer

The build step does not run npm ci, so the package-lock.json is ignored.

Question 13

Your release pipeline deploys to multiple environments sequentially. The deployment to production fails intermittently due to a database schema migration issue. You need to implement a strategy that automatically rolls back the deployment if the migration fails. What should you do?

Accepted Answer

Add a post-deployment script that runs a rollback script on failure.. Approval gates only pause deployment; they don't roll back. Pre-deployment conditions can check conditions but not automatically roll back. Rollback scripts in the pipeline can reverse changes if a failure is detected. Using multiple stages doesn't automatically roll back; it just defines stages.

Answer

Enable 'Auto-rollback' in the release pipeline settings.

Answer

Use a multi-stage YAML pipeline with manual intervention.

Answer

Configure pre-deployment approval gates.

Question 14

You are creating a release pipeline that deploys to Azure App Service. You want to ensure that the deployment uses the 'Run from package' feature for faster deployments and reduced downtime. Which deployment method should you select in the 'Azure App Service deploy' task?

Accepted Answer

RunFromPackage. The 'Run from package' feature is enabled by selecting 'Web Deploy' with 'Package' or 'RunFromPackage' option. The correct option is to select 'RunFromPackage' as the deployment method. Option A is wrong because 'Zip Deploy' is a different method. Option B is wrong because 'Web Deploy' alone does not enable run from package. Option D is wrong because 'Container' is for containerized apps.

Answer

Web Deploy

Answer

Container

Answer

Zip Deploy

Question 15

You need to automatically run a security scan on every pull request in GitHub. The scan should block the PR if critical vulnerabilities are found. Which GitHub feature should you use?

Accepted Answer

GitHub Code Scanning with a CodeQL workflow. GitHub Code Scanning with a workflow can run security scans and block PRs via check runs. Option B is wrong because Dependabot only updates dependencies. Option C is wrong because secret scanning detects secrets, not vulnerabilities. Option D is wrong because branch protection rules enforce checks, but the scan itself is Code Scanning.

Answer

Dependabot version updates

Answer

Secret scanning

Answer

Branch protection rules with required status checks