AZ-400 Practice Test 38 — 15 Questions

Question 1

Refer to the exhibit. You are reviewing the branch policy configuration for the main branch in Azure DevOps. The policy requires a successful status check for 'continuous-integration/azure-devops' but not for 'security-scanner'. The minimum approver count is 0 and direct push is disallowed. What is the effect of this policy?

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

Accepted Answer

Pull requests must pass the 'continuous-integration/azure-devops' check, but no reviewer approval is needed.. The policy requires a successful status check for 'continuous-integration/azure-devops' but not for 'security-scanner'. With a minimum approver count of 0 and direct push disallowed, pull requests must pass the required CI check, but no reviewer approval is needed. This means the PR can be completed automatically once the CI check passes, without any human reviewer.

Answer

Developers can push directly to main without a pull request.

Answer

Pull requests require at least two reviewers.

Answer

Both status checks are required to pass.

Question 2

You are designing a release pipeline in Azure Pipelines that deploys a web app to multiple environments (dev, test, prod). You want to ensure that the same build artifact is deployed to each environment without rebuilding. Which trigger type should you use?

Accepted Answer

Continuous deployment trigger on the release pipeline. A continuous deployment trigger on the release pipeline automatically starts a new release deployment whenever a new build artifact is available, ensuring the same build artifact is deployed to each environment without rebuilding. This is the correct choice because the requirement is to deploy the same artifact across multiple environments, and the continuous deployment trigger is designed to initiate a release pipeline after a build completes, preserving the artifact for downstream stages.

Answer

Pull request trigger

Answer

Schedule trigger

Answer

Build completion trigger

Question 3

You are a DevOps engineer at a large enterprise that develops a cloud-native application using microservices architecture. The application consists of 15 microservices, each stored in a separate GitHub repository. Your team uses GitHub Actions for CI/CD and Azure Kubernetes Service (AKS) for production. The current deployment process is manual and error-prone. You need to design an automated CI/CD pipeline that supports the following requirements:

1. Each microservice must have its own build and test pipeline triggered on pull requests and merges to the main branch.
2. Upon merging to main, a container image must be built, tagged with the Git commit SHA, and pushed to Azure Container Registry (ACR).
3. A separate release pipeline must deploy the updated images to AKS using a GitOps approach with Flux v2.
4. The release pipeline must support rolling back to a previous version quickly if a deployment fails.
5. The entire solution must be defined as code to ensure reproducibility.

Which approach should you recommend?

Accepted Answer

Use GitHub Actions in each microservice repo for CI to build and push images to ACR. Use a separate GitOps repository that contains Kubernetes manifests. Configure Flux v2 in AKS to sync from the GitOps repo. When a new image is pushed to ACR, update the manifest in the GitOps repo via a GitHub Action, triggering Flux to deploy. For rollback, revert the commit in the GitOps repo.. It aligns with all requirements: each microservice has its own GitHub Actions CI pipeline (requirement 1), images are built and pushed to ACR with commit SHA tags (requirement 2), a separate GitOps repo with Flux v2 handles deployment to AKS (requirement 3), rollback is achieved by reverting the Git commit (requirement 4), and everything is defined as code in repositories (requirement 5). Option A is wrong because it uses a monorepo, violating the separate repository requirement, and uses kubectl in the pipeline instead of GitOps. Option B is wrong because it uses Azure Pipelines, which is not consistent with GitHub Actions, and uses Helm rollback instead of Git-based rollback. Option C is wrong because it deploys directly via kubectl in the same workflow, mixing CI and CD, and uses Argo CD instead of Flux v2 as specified.

Answer

Create a single monorepo with all microservices. Use GitHub Actions with a multi-branch pipeline that builds only changed services. Deploy to AKS using kubectl commands in the pipeline. For rollback, redeploy the previous image tag.

Answer

Use Azure Pipelines with a single build pipeline that triggers on any change in any repo using webhooks. Use Azure DevOps Release Pipelines to deploy to AKS using Helm. Store Helm charts in Azure Container Registry. For rollback, use Helm rollback command.

Answer

Use GitHub Actions for CI and deploy directly to AKS using kubectl in the same workflow. Store Kubernetes manifests in each microservice repo. Use Argo CD to monitor the repos and sync.

Question 4

You are configuring a multi-stage YAML pipeline that builds a .NET Core application and deploys it to Azure Kubernetes Service (AKS). The build stage produces a container image that is pushed to Azure Container Registry (ACR). The deploy stage needs to use the image from ACR. How should you pass the image tag from the build stage to the deploy stage?

Accepted Answer

Use the 'stageDependencies' syntax to retrieve the output variable of a job in the build stage.. Azure DevOps supports cross-stage output variables, allowing a job in the build stage to set a variable (e.g., imageTag) that can be consumed in the deploy stage using the stageDependencies syntax. This avoids the overhead of artifacts or external queries and ensures the exact tag produced during the build is used in deployment.

Answer

Write the image tag to a file and publish it as a build artifact, then read it in the deploy stage.

Answer

Define a pipeline variable at the top level and set it in the build stage.

Answer

Use the 'Azure CLI' task in the deploy stage to query the ACR for the latest image tag.

Question 5

You are designing a security compliance plan for Azure Pipelines. The plan must ensure that no pipeline can use variables containing secrets unless those variables are stored in Azure Key Vault and referenced via a variable group linked to Key Vault. What is the best way to enforce this across all pipelines in an Azure DevOps organization?

Accepted Answer

Create a YAML template that mandates the use of Key Vault references.. You can enforce a YAML template at the organization level using required template policies. This ensures all pipelines include a template that mandates Key Vault references for secrets, providing a scalable enforcement mechanism. Option B is incorrect because Azure Policy applies to Azure resources, not Azure DevOps constructs like variable groups. Option C is incorrect because manual approvals do not enforce Key Vault usage. Option D is incorrect because branch policies control code, not variable usage during execution.

Answer

Implement an Azure Policy that audits variable groups and requires Key Vault integration.

Answer

Require manual approval for all pipeline runs that use variables.

Answer

Use branch policies to prevent merging code that contains secrets.

Question 6

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.. Pipeline decorators allow injecting tasks (like signing) into every pipeline globally without modifying individual pipeline definitions. Option A is wrong because YAML templates require each pipeline to explicitly extend them; they do not enforce automatic inclusion. Option B is wrong because branch policies control pull request merge conditions, not build steps. Option C is wrong because manual approval gates are used in release pipelines to control promotion, not to enforce signing during build.

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 7

Your team uses a multi-stage YAML pipeline to build and deploy a .NET Core application. The build stage runs successfully, but the deployment to a Linux web app fails with an error indicating that the Kudu service cannot start because the startup command is missing. What is the most likely cause?

Accepted Answer

The pipeline is missing the 'AzureWebApp@1' task with a 'StartupCommand' parameter.. The Kudu service on Linux web apps requires a startup command to launch the .NET Core application. The 'AzureWebApp@1' task's 'StartupCommand' parameter specifies this command (e.g., 'dotnet myapp.dll'). Without it, Kudu cannot start the process, causing the deployment failure.

Answer

The service connection lacks permission to access the web app.

Answer

The web app is configured with a Windows runtime stack.

Answer

The build output does not include the web.config file.

Question 8

A development team is configuring a YAML-based pipeline in Azure Pipelines. The pipeline must meet the following requirements: 
- Build only the main branch.
- Run integration tests after a successful build.
- Deploy to a staging environment only if tests pass.
- Handle failures gracefully by sending a notification to the team.
You need to define the pipeline structure. Which TWO configurations should you include?

Accepted Answer

Define a stage for 'Deploy' with `dependsOn: Test` and `condition: succeeded('Test')`.. It defines a 'Deploy' stage that depends on the 'Test' stage and uses `condition: succeeded('Test')` to ensure deployment only occurs after tests pass. This satisfies the requirement to deploy to staging only if tests succeed. Option C is correct because `trigger: main` at the pipeline root configures the pipeline to build only the main branch, meeting the first requirement.

Answer

Use a `deployment: Staging` job with `displayName: Deploy to staging`.

Answer

Add `condition: succeeded()` to the build job.

Answer

Define the trigger in the `resources` section using `pipelines`.

Question 9

Match each Git branching strategy to its description.

Accepted Answer

Git Flow: Uses develop and master branches with release branches.. Git branching strategies vary in complexity. Git Flow uses long-lived branches (develop, release), GitHub Flow is simple with feature branches to main, GitLab Flow adds environment branches, and trunk-based development centers on frequent commits to main. Common confusions involve swapping descriptions between Git Flow and GitHub Flow.

Answer

Git Flow: Uses only main branch and feature branches.

Answer

GitHub Flow: Uses develop and release branches.

Question 10

Match each YAML pipeline trigger to its behavior.

Accepted Answer

CI trigger: Triggers a pipeline when a push occurs on the specified branch. In Azure Pipelines YAML, each trigger type has a distinct purpose: CI for push events, PR for pull requests, Schedules for cron-based runs, and Pipeline for cross-pipeline dependencies. Common confusions mix the behaviors of CI/PR or PR/Pipeline triggers.

Answer

CI trigger: Triggers a pipeline when a pull request is opened

Answer

PR trigger: Triggers a pipeline on completion of another pipeline

Question 11

Refer to the exhibit. You executed the Azure CLI command to list variable groups. A security audit requires that all variable groups containing secrets are configured to be authorized for all pipelines. Which statement is true based on the output?

Accepted Answer

The variable group 'ProdVars' contains a secret variable, but the output does not indicate whether it is authorized for all pipelines. The JSON output shows that 'ProdVars' has an 'ApiKey' variable with a null value, indicating it is a secret variable (values are masked). The output does not include any authorization properties, so we cannot determine if it is authorized for all pipelines. Option B is incorrect because the property 'authorized' may exist but is not shown in the list command; you need to use 'az pipelines variable-group show' or check the settings separately. Option C is incorrect because the secret value is masked (null), not exposed. Option D is incorrect because having secret variables does not automatically authorize the group for all pipelines; authorization must be explicitly configured.

Answer

The variable group 'ProdVars' is not authorized for all pipelines because no such property exists

Answer

The variable group 'ProdVars' has exposed the secret value in the output

Answer

The variable group 'ProdVars' is authorized for all pipelines because it has secret variables

Question 12

Match each Azure Artifacts feed type to its description.

Accepted Answer

Project-scoped feed: A feed scoped to a specific project within an organization, accessible by members of that project.. In Azure Artifacts, project-scoped feeds are limited to a specific project, organization-scoped feeds are available to the entire org, and public feeds allow anonymous access. Common confusions arise from swapping the scope of project and org feeds, or misstating public feed authentication requirements.

Answer

Project-scoped feed: A feed scoped to the entire organization, accessible by all members.

Answer

Organization-scoped feed: A feed scoped to a specific project, accessible by project members.

Answer

Public feed: A feed that requires authentication from external users.

Question 13

A company uses Azure DevOps for CI/CD. The security team requires that all pipeline runs must use a specific service connection (ServiceConnection-Prod) that has been approved for production deployments. However, developers are accidentally using unapproved connections. You need to enforce that only the approved service connection can be used in any pipeline that deploys to the production environment. What should you do?

Accepted Answer

Create an Azure Pipeline decorator that validates the service connection used in each task and fails the pipeline if it is not the approved one.. Azure Pipeline decorators inject custom validation logic at runtime, allowing you to inspect each task's service connection and fail the pipeline if it does not match the approved one. This enforces the security requirement centrally without relying on developer compliance or manual gates.

Answer

Define a required template for all pipelines that includes the service connection, and instruct developers to use it.

Answer

Set up a manual approval gate on the production environment stage in the pipeline.

Answer

Configure a branch policy on the main branch to require a successful build before merging.

Question 14

Which TWO practices help you manage build artifacts efficiently in Azure Pipelines?

Accepted Answer

Set retention policies to automatically delete old artifacts. Setting retention policies (A) helps automate cleanup of old artifacts, reducing storage waste. Using the Publish Build Artifacts task (D) is the standard way to store artifacts from builds efficiently. Option B (copying to each agent) is wasteful because it duplicates artifacts unnecessarily. Option C (manual download) is inefficient because it requires human intervention and does not scale. Option E (large single files) makes downloads and incremental updates difficult.

Answer

Copy artifacts to each agent's local storage

Answer

Download all artifacts manually after each build

Answer

Store artifacts as large single files to reduce number of files

Question 15

Refer to the exhibit. You monitor an Azure App Service web app. At 10:30 AM, you observe a spike in HTTP 5xx errors and response time. Based on the metrics, what is the most likely cause?

Accepted Answer

The web app reached its scaling limit and could not handle the increased load.. The request count increased gradually from 1200 to 2500 before the errors started at 10:30 AM. The sharp rise in errors and response time coinciding with peak load indicates the app reached its capacity limit (e.g., instance count or plan limits).

Answer

A deployment of new code at 10:30 AM introduced a bug.

Answer

A DDoS attack started at 10:30 AM.

Answer

A database outage caused the errors and slow responses.