AZ-400 Practice Test 17 — 15 Questions

Question 1

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets are not exposed in build logs. What should you use?

Accepted Answer

GitHub Secrets. GitHub Secrets (Option C) is the correct choice because GitHub Actions provides a built-in encrypted secrets store that automatically masks secret values in build logs. When you reference a secret using `${{ secrets.MY_SECRET }}`, GitHub ensures the value is never printed or exposed in workflow output, unlike plaintext or environment variables that can be inadvertently logged.

Answer

Hardcoded values in the workflow YAML

Answer

Environment variables in the workflow

Answer

Artifact storage

Question 2

Your team wants to automatically assign a code reviewer from a specific security group when a pull request modifies files in a 'security' folder. Which Azure DevOps feature should you use?

Accepted Answer

Add a required reviewer policy for the branch.. Azure DevOps branch policies include a 'Required reviewers' policy that can be configured with a path filter. By specifying the path 'security' and adding the security group as required reviewers, the system will automatically add those reviewers to any pull request that modifies files in that folder. This is the built-in feature designed for this scenario. A CODEOWNERS file can also suggest reviewers based on file paths, but it is not a branch policy and does not enforce that the review must occur.

Answer

Enable 'Automatically approve' for security group.

Answer

Code ownership policy with automatic reviewer assignment.

Answer

Branch policy with minimum number of reviewers.

Question 3

You are designing a security compliance plan for a GitHub Enterprise environment. Which THREE practices should you implement? (Select THREE.)

Accepted Answer

Configure branch protection rules to require pull request reviews. Branch protection rules with required pull request reviews enforce mandatory code review before merging, Dependabot alerts automatically monitor dependency vulnerabilities, and secret scanning detects accidental credential commits. Together these practices strengthen security compliance in GitHub Enterprise.

Answer

Disable two-factor authentication for automation accounts

Answer

Allow repository admins to bypass branch protection rules

Question 4

Your release pipeline deploys to multiple environments sequentially: Dev, QA, Staging, Production. You need to implement manual approval gates before Staging and Production deployments. Which TWO configurations should you use? (Choose two.)

Accepted Answer

Use the 'Approvals and gates' settings in the release pipeline stage.. The 'Approvals and gates' settings in a release pipeline stage allow you to configure pre-deployment approvals, which require designated users to approve the deployment before it proceeds. This is the standard mechanism in Azure DevOps for implementing manual approval gates. Option E is correct because adding a pre-deployment approval gate specifically to the Staging and Production stages ensures that deployments to these environments are blocked until the required approvals are granted, meeting the requirement for manual approval before Staging and Production.

Answer

Add a post-deployment approval gate to the Dev and QA stages.

Answer

Configure branch policy on the release branch to require approvals.

Answer

Add a 'Manual Validation' task in the YAML pipeline.

Question 5

Your organization uses GitHub for source control. You need to implement a secure source control strategy that prevents secrets from being exposed and ensures code quality. Which THREE practices should you implement?

Accepted Answer

Configure branch protection rules requiring status checks to pass. Branch protection rules enforce required status checks (e.g., CI builds, code reviews) before merging, ensuring only validated changes enter protected branches—this supports code quality. GitHub secret scanning automatically detects known types of secrets in repositories and alerts on exposure, directly preventing secret leaks. Pre-commit hooks scan code for secrets before a commit is created, blocking accidental commits of credentials or tokens. Together, A, D, and E address both secret prevention and code quality. Commit signing (C) verifies authorship but does not prevent secret exposure or enforce code quality checks.

Answer

Store secrets in a .env file committed to the repository

Answer

Require commit signing using GPG keys

Question 6

The pipeline above fails with: 'The deployment job 'DeployToProd' references environment 'Production' which does not exist.' What should you do to resolve this error?

Accepted Answer

Create an environment named 'Production' in Azure DevOps project settings.. The error indicates that the Azure DevOps pipeline references an environment named 'Production' that does not exist in the project. Environments must be explicitly created in Azure DevOps project settings before they can be used in deployment jobs. Option D resolves this by creating the required environment, allowing the deployment job to target it correctly.

Answer

Remove the 'environment' property from the deployment job.

Answer

Change the deployment strategy from 'runOnce' to 'rolling'.

Answer

Add a script step before the deployment job to create the environment.

Question 7

Which TWO are valid strategies for managing secrets in a GitHub Actions workflow?

Accepted Answer

Use OpenID Connect to authenticate to Azure without storing any credentials.. OpenID Connect (OIDC) allows GitHub Actions to exchange a short-lived token directly with Azure without storing any long-lived credentials as secrets. This eliminates the need to manage and rotate client secrets or service principal passwords, reducing the risk of credential leakage. The workflow uses the `azure/login` action with `client-id`, `tenant-id`, and `subscription-id` parameters, and Azure trusts the OIDC token issued by GitHub. Alternatively, storing the secret as an encrypted GitHub secret is also a valid strategy: GitHub encrypts secrets at rest and injects them into the workflow runtime only when referenced via `${{ secrets.SECRET_NAME }}`. This prevents hardcoding secrets in the YAML and keeps them out of logs, though it still requires managing the secret value and rotation.

Answer

Hardcode the secret in the YAML file.

Answer

Set the secret as an environment variable in the runner's shell profile.

Answer

Base64-encode the secret and include it directly in the workflow file.

Question 8

A team is implementing a release pipeline for a Node.js application. They want to run integration tests against a temporary environment that is destroyed after the tests complete. Which strategy should they use?

Accepted Answer

Use a release pipeline that deploys to a new Azure App Service instance, runs tests, and then removes the instance.. It provisions a dedicated, isolated Azure App Service instance for integration testing, runs the tests against the real environment, and then destroys the instance to avoid ongoing costs. This aligns with the ephemeral environment pattern, ensuring tests validate actual deployment behavior without contaminating shared resources.

Answer

Use a separate release pipeline that deploys to a production environment for testing.

Answer

Use a single release pipeline that deploys to a staging slot and runs tests on the slot.

Answer

Run integration tests in the build pipeline using a mock environment.

Question 9

You need to integrate security scanning into your build pipeline to detect vulnerable open-source dependencies. Which Azure DevOps extension should you use?

Accepted Answer

WhiteSource Bolt. WhiteSource Bolt is a free Azure DevOps extension that integrates directly into build pipelines to automatically scan open-source dependencies for known vulnerabilities. It identifies vulnerable components, provides remediation guidance, and enforces security policies without requiring additional configuration or external tools, making it the correct choice for this scenario.

Answer

Azure Policy

Answer

GitHub Advanced Security

Answer

SonarQube

Question 10

Which TWO actions are required to securely use Azure Key Vault secrets in an Azure Pipelines build? (Choose 2)

Accepted Answer

Use the 'Azure Key Vault' task to download secrets as pipeline variables.. The Azure Key Vault task in Azure Pipelines is the recommended way to securely download secrets from a Key Vault and expose them as pipeline variables. This task automatically handles authentication and ensures that secret values are masked in logs, preventing accidental exposure. It eliminates the need to manually manage secret retrieval and mapping in YAML. For the task to succeed, the Azure DevOps service principal (from the Azure Resource Manager service connection) must have 'Get' and 'List' permissions on the Key Vault. Without these permissions, the task cannot retrieve the secrets. Therefore, both using the Azure Key Vault task and granting the appropriate permissions are required actions.

Answer

Set the 'secrets' output variable to 'true' in the pipeline.

Answer

Use the 'Environment Variables' section in the pipeline to map secrets.

Answer

Reference the secret identifier directly in the pipeline YAML.

Question 11

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 Azure DevOps YAML pipelines, variables set at the pipeline level (not in a variable group or at queue time) are evaluated at compile time, not at runtime. When 'publishEnabled' is defined as a simple variable in the YAML file, changing it at queue time does not affect the compiled pipeline stages; the condition is evaluated against the compile-time value (false), so the Publish stage never runs. To make it settable at queue time, the variable must be defined as a runtime parameter, or explicitly defined in the pipeline UI with the 'Let users override this value when running this pipeline' checkbox enabled.

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 12

You need to configure a build pipeline that triggers only when changes are pushed to the 'release/*' branch. Which trigger configuration should you use?

Accepted Answer

Set 'trigger: branches: include: - release/*'. The YAML trigger configuration 'trigger: branches: include: - release/*' explicitly specifies that the pipeline should run only when changes are pushed to any branch matching the 'release/*' wildcard pattern. This is the standard way to define branch-based triggers in Azure Pipelines YAML, ensuring that only pushes to release branches initiate the build.

Answer

Set 'trigger: none' in YAML

Answer

Set 'trigger: branches: include: - main'

Answer

Set 'trigger: tags: include: - v*'

Question 13

Which THREE of the following are valid deployment strategies that can be implemented using Azure DevOps release pipelines? (Select THREE.)

Accepted Answer

Rolling deployment.. Rolling deployment is a valid strategy in Azure DevOps release pipelines, where instances of the previous version are gradually replaced with the new version, typically by updating a subset of instances (e.g., in a virtual machine scale set or Kubernetes cluster) while the rest continue serving traffic. Blue-green deployment is also valid, maintaining two identical environments and switching all traffic from the blue (old) to the green (new) environment after validation, often implemented using deployment slots or Kubernetes namespaces. Canary deployment is a third valid strategy, where a small percentage of traffic is routed to the new version initially, gradually increasing it while monitoring health, commonly implemented with deployment slots or progressive exposure in Kubernetes. Red-black, while sometimes used as a synonym for blue-green, is not a distinct deployment strategy recognized in Azure DevOps documentation, and linear deployment is not a recognized industry-standard pattern.

Answer

Red-black deployment.

Answer

Linear deployment.

Question 14

You need to monitor the health of your Azure Pipeline agents. Which Azure DevOps Analytics view should you use to identify agents that have not reported in the last hour?

Accepted Answer

Agent Health dashboard. The Agent Health dashboard in Azure DevOps provides real-time status of pipeline agents, including their last communication timestamp. By filtering for agents that have not reported in the last hour, you can identify unhealthy or disconnected agents. This dashboard directly surfaces agent connectivity and health metrics. Note that this is a dashboard, not an Analytics view like Release Analytics, Test Analytics, or Pipeline Run Analytics.

Answer

Release Analytics

Answer

Test Analytics

Answer

Pipeline Run Analytics

Question 15

Drag and drop the steps to set up a self-hosted Azure DevOps agent on a Windows VM into the correct order.

Accepted Answer

First create a PAT, then download the agent, then run config.cmd to configure and register, then start the agent as a service.. The correct order to set up a self-hosted Azure DevOps agent on a Windows VM is: create a Personal Access Token (PAT) first, then download the agent package, then run config.cmd to configure and register the agent with Azure DevOps, and finally start the agent as a service. Option A reflects this sequence correctly. Other options either place download before PAT creation or start the agent before configuration, which would fail.

Answer

First download the agent, then create a PAT, then run config.cmd, then start the agent as a service.

Answer

First create a PAT, then run config.cmd, then download the agent, then start the agent as a service.

Answer

First create a PAT, then download the agent, then start the agent as a service, then run config.cmd.