AZ-400 Practice Test 25 — 15 Questions

Question 1

You are designing a multi-stage YAML pipeline for an application that requires approval for production deployment. The pipeline must run automatically for non-production stages. Which TWO configurations should you use?

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

Accepted Answer

Set the pipeline trigger to include branches used for non-production stages.. Options A and B are correct. Option A: Setting the pipeline trigger to include branches used for non-production stages enables automatic CI triggers for those branches, so non-production stages run automatically. Option B: Adding an 'approvals' block to the production stage enforces manual approval before deployment to production. Options C, D, and E are incorrect: C suggests using a release pipeline which is unnecessary; D would require manual approval for every stage, not just production; E describes a single-stage pipeline, which doesn't fit the multi-stage requirement.

Answer

Use a release pipeline instead of a YAML pipeline.

Answer

Set the pipeline to require manual approval for every stage.

Answer

Use a single-stage pipeline with conditional approval.

Question 2

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 3

Which TWO of the following are benefits of using Infrastructure as Code (IaC) over manual infrastructure management?

Accepted Answer

Consistent environment provisioning. Options A and B are correct. Option A is correct because IaC enables consistent and repeatable provisioning, reducing manual errors. Option B is correct because IaC helps prevent configuration drift by maintaining desired state configurations. Option C is incorrect because IaC does not remove the need for testing; testing is still required to validate infrastructure code. Option D is incorrect because IaC still requires documentation for design and operations. Option E is incorrect because while IaC can optimize costs, it does not inherently guarantee lower costs; cost depends on resource choices.

Answer

Removes the need for testing

Answer

Eliminates the need for documentation

Answer

Lower infrastructure costs

Question 4

Your team uses GitHub. You need to automatically remove a user's access to all repositories when they leave the company. What is the most efficient approach?

Accepted Answer

Enable SCIM provisioning from Microsoft Entra ID to GitHub. SCIM (System for Cross-domain Identity Management) provisioning from Microsoft Entra ID to GitHub automates user lifecycle management. When a user is disabled or removed from Entra ID, SCIM automatically deprovisions their access across all GitHub resources, including repositories, without manual intervention. This is the most efficient approach because it is event-driven and scales to thousands of users.

Answer

Assign the user to a 'Leaver' team and remove all repository permissions

Answer

Manually remove the user from each repository

Answer

Configure SAML single sign-on (SSO) with Microsoft Entra ID

Question 5

A company uses Azure Pipelines to deploy a web app to Azure App Service. They want to ensure that the deployment is first validated in a staging slot before swapping to production. What should they configure?

Accepted Answer

Use deployment slots in the App Service and configure auto-swap. Azure App Service deployment slots allow you to deploy a web app to a staging slot, validate it, and then swap it to production with zero downtime. Auto-swap automates this process by swapping the staging slot into production after a successful deployment, ensuring validation occurs before the production slot receives the new code.

Answer

Create two separate pipelines for staging and production

Answer

Use Azure Traffic Manager to route traffic

Answer

Use an App Service plan with multiple instances

Question 6

Which TWO actions should you take to protect sensitive information (e.g., API keys, passwords) in Azure Pipelines? (Choose two.)

Accepted Answer

Define secrets as pipeline secret variables and reference them as $(secretName).. Azure Pipelines allows you to define secret variables in the pipeline UI or YAML, which are encrypted at rest and never exposed in logs. Referencing them as $(secretName) ensures they are securely injected at runtime without being stored in plaintext. Option E is correct because Azure Key Vault provides a centralized, audited, and encrypted store for secrets, and variable groups linked to Key Vault allow pipelines to fetch secrets dynamically without embedding them in pipeline definitions.

Answer

Store secrets in environment variables on the agent machine.

Answer

Store secrets in a YAML file and include the file in the repository.

Answer

Use plain text variables in the pipeline and mask them using the 'Logging Command' feature.

Question 7

A team uses Git for source control. They want to automatically squash all commits in a feature branch into a single commit when merging to the main branch. Which merge type should they use?

Accepted Answer

Squash commit. B is correct because the squash commit merge type collapses all commits in a feature branch into a single new commit on the target branch. This satisfies the requirement to automatically squash all commits when merging to main, as it creates a clean, linear history with one combined commit that contains all changes from the feature branch.

Answer

Rebase and fast-forward

Answer

Merge commit (no fast-forward)

Answer

Semi-linear merge

Question 8

Which TWO strategies can you use to manage secrets in Azure Pipelines securely?

Accepted Answer

Use a variable group linked to Azure Key Vault.. Options A and C are correct. Variable groups can be linked to Azure Key Vault to fetch secrets, and you can mark variables as secret in the pipeline UI to prevent them from being displayed in logs. Option B is wrong because storing secrets in YAML files exposes them in source control. Option D is wrong because using environment variables on the build agent is not inherently secure; they can be accessed by other processes and may be logged. Option E is wrong because printing secrets in scripts exposes them in the pipeline logs, which is a security risk.

Answer

Store secrets directly in the YAML pipeline file.

Answer

Use environment variables in the build agent.

Answer

Print the secret in a script to verify it is correct.

Question 9

You need to implement a compliance framework that ensures Azure Pipelines build agents are always patched with the latest security updates. What should you use?

Accepted Answer

Azure Update Management to schedule patching. Azure Update Management is the correct choice because it provides a native, scheduled patching solution for Azure Pipelines build agents. It integrates with Azure Automation and Log Analytics to assess missing updates and deploy them on a recurring schedule, ensuring agents remain compliant with the latest security patches without manual intervention.

Answer

Azure VM Image Builder to create patched images

Answer

Azure Policy to enforce that agents must be patched

Answer

Azure Automation State Configuration to enforce desired state

Question 10

You are reviewing a pipeline YAML file. The variable 'prod-db-password' is stored in a variable group linked to Azure Key Vault. However, the pipeline fails with an error that the secret cannot be accessed. What is the most likely cause?

Accepted Answer

The pipeline's authorized service principal lacks 'Get' permission on the Key Vault.. The most likely cause is that the pipeline's authorized service principal lacks 'Get' permission on the Key Vault. When a variable group is linked to Azure Key Vault, Azure Pipelines uses a service principal (the pipeline's identity) to retrieve secrets. Even if the variable group and secret name are correct, the pipeline will fail if the service principal does not have the 'Get' secret permission in the Key Vault access policy. This is a common misconfiguration because the variable group link only establishes the mapping, not the actual access rights.

Answer

The YAML syntax for referencing the variable is incorrect.

Answer

The variable group 'prod-variables' does not exist.

Answer

The secret name in Key Vault does not match 'prod-db-password'.

Question 11

You are designing a release pipeline for a Node.js application that deploys to Azure App Service. The pipeline must run integration tests against the deployed application. You want to use deployment slots to minimize downtime. What is the recommended approach?

Accepted Answer

Deploy to a staging slot, run tests against the staging slot, then swap to production.. Deploying to a staging slot first allows you to validate the application by running integration tests against the staging slot without impacting production traffic. After successful testing, swapping the staging slot with the production slot ensures zero-downtime deployment, as Azure App Service swaps the underlying virtual directories and configuration settings instantly.

Answer

Deploy to the production slot directly and run tests after deployment.

Answer

Deploy to a staging slot, swap, then run tests.

Answer

Deploy to a staging slot, run tests, then delete the staging slot.

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.. The most likely cause is that the Node.js version on the GitHub Actions runner differs from the version on Azure App Service, leading to native module incompatibility. Native modules (e.g., those using node-gyp) are compiled against the specific Node.js ABI (Application Binary Interface) of the build environment. If the runtime version differs, the compiled .node binaries will fail to load, resulting in a 'missing module' error even though the node_modules folder is present in the artifact.

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 team is using GitHub Actions for CI/CD. The workflow builds a container image and pushes it to Azure Container Registry (ACR). However, the workflow fails with an authentication error when pushing to ACR. What is the most likely cause?

Accepted Answer

The workflow does not include an 'azure/login' step to authenticate with Azure.. GitHub Actions workflows that push container images to Azure Container Registry (ACR) must first authenticate with Azure. Without an 'azure/login' step (using Azure CLI or Azure PowerShell actions), the workflow lacks the necessary OAuth2 tokens or service principal credentials to authorize the 'docker push' command against the ACR endpoint. The authentication error occurs because the Docker client cannot obtain a valid ACR access token without prior Azure authentication.

Answer

The repository name in the workflow is incorrect.

Answer

The Dockerfile is missing a required LABEL instruction.

Answer

The ACR allows anonymous pull access.

Question 14

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 15

You have a multi-stage YAML pipeline that deploys to Azure App Service. The deployment to the production stage should only proceed if a manual approval is granted. How should you configure this?

Accepted Answer

Add an approval check on the production environment. Azure Pipelines supports approval checks on environments, which allow you to require manual approval before a deployment proceeds to a specific stage. By adding an approval check on the production environment, the pipeline will pause at that stage until an authorized user grants approval, meeting the requirement for manual sign-off before production deployment.

Answer

Use deployment gates with Azure Monitor metrics

Answer

Configure branch policies on the main branch

Answer

Add a pipeline decorator to require sign-off