AZ-400 Practice Test 39 — 15 Questions

Question 1

Your organization is migrating from Azure Repos to GitHub. You have 200 repositories with complex branching strategies and build policies. You need to preserve the commit history and branch policies. What is the best migration approach?

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

Accepted Answer

Use git push --force to push all branches to GitHub and recreate policies manually. The GitHub Importer tool does not preserve branch policies; it only migrates repository history and code. To keep commit history and then recreate branch policies, the best approach is to use `git push --force` to push all branches from Azure Repos to GitHub, then recreate branch policies manually or via the GitHub API. This ensures complete history is preserved while policies are re-established separately.

Answer

Manually recreate each repository in GitHub and copy the code from Azure Repos

Answer

Use a third-party tool to perform a mirror clone and then push to GitHub

Answer

Use the GitHub Importer tool with a custom mapping script to migrate repositories and policies

Question 2

A company uses Azure Monitor and Application Insights to monitor a microservices application deployed on Azure Kubernetes Service (AKS). The development team wants to implement distributed tracing to correlate requests across services. They currently have Application Insights SDKs instrumented in each service. Which TWO configurations are required to enable end-to-end distributed tracing?

Accepted Answer

Ensure all services use the same Application Insights instrumentation key or connection string.. All services must share the same Application Insights instrumentation key or connection string to ensure that telemetry from different microservices is correlated into a single application map and trace. Without a common instrumentation key, the distributed trace data would be siloed across separate Application Insights resources, preventing end-to-end correlation.

Answer

Enable the Live Metrics Stream feature in Application Insights.

Answer

Configure adaptive sampling in the Application Insights SDK.

Answer

Enable Application Map in the Azure portal for each service.

Question 3

Drag and drop the steps to configure a service hook for build completion notifications to Microsoft Teams into the correct order.

Accepted Answer

First, navigate to Project Settings and select Service Hooks. Then, create a new subscription choosing the Build completed event and Microsoft Teams as the service. Finally, configure the webhook URL and test the subscription.. To configure a service hook for build completion notifications to Microsoft Teams, you must first access the Service Hooks page in Project Settings. Then, you create a new subscription and select the Build completed event and Microsoft Teams as the service. Finally, you provide the webhook URL and test the subscription to ensure it works.

Answer

First, create a new subscription choosing the Build completed event and Microsoft Teams. Then, navigate to Project Settings and select Service Hooks. Finally, configure the webhook URL and test the subscription.

Answer

First, configure the webhook URL and test the subscription. Then, navigate to Project Settings and select Service Hooks. Finally, create a new subscription for the Build completed event.

Answer

First, choose Microsoft Teams as the service and paste the webhook URL. Then, navigate to Project Settings and select Service Hooks. Finally, create a new subscription for the Build completed event.

Question 4

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 5

Which THREE are valid ways to trigger a pipeline in Azure Pipelines using GitHub integration? (Choose three.)

Accepted Answer

GitHub App webhooks. GitHub App webhooks are the primary integration mechanism for Azure Pipelines with GitHub. When you configure a GitHub App connection in Azure Pipelines, it registers webhooks that listen for specific GitHub events (like push and pull request) and automatically triggers pipeline runs in real-time without polling.

Answer

Polling GitHub on a schedule

Answer

Azure Pipelines schedule trigger

Question 6

Your Azure DevOps pipeline deploys to multiple environments. You want to require manual approval before production deployment, but only if the deployment originated from a branch other than 'main'. How can you implement this?

Accepted Answer

Add a manual validation task with a condition: ne(variables['Build.SourceBranch'], 'refs/heads/main'). To require manual approval only for non-main branches, add a manual validation task to the production deployment job with a condition checking that the source branch is not main: `ne(variables['Build.SourceBranch'], 'refs/heads/main')`. This pauses the pipeline and waits for approval. Pre-deployment approvals (A) cannot be conditional on branch, and deployment groups (B) are not for manual approval. Branch policies (C) do not apply to pipeline stages.

Answer

Set a pre-deployment approval on the production environment

Answer

Configure a deployment group with approval gates

Answer

Use a branch policy that requires approval for non-main branches

Question 7

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 8

Which THREE are valid approaches to securely store secrets used in Azure Pipelines? (Choose three.)

Accepted Answer

Secret variables defined in the pipeline UI. Secret variables defined in the pipeline UI (B) are encrypted at rest and masked in logs, preventing exposure in source control. The Azure Key Vault task (C) retrieves secrets from Azure Key Vault at runtime, avoiding storage in Azure DevOps. Variable groups linked to Azure Key Vault (D) allow you to reference Key Vault secrets directly as pipeline variables, keeping them out of YAML and providing centralized access control. All three approaches ensure secrets are not stored in plaintext in repositories or pipeline definitions.

Answer

Inline secret variables defined in the YAML file

Answer

Environment variables set on the build agent

Question 9

Your team uses Azure DevOps with a Git repository. You want to enforce that all pull requests to main must have at least one reviewer from the 'security' group. Which two configurations are required? (Choose two.)

Accepted Answer

Add the security group as a required reviewer for the main branch policy.. You can add the security group as a required reviewer in the branch policy. Option D is correct because setting the minimum number of reviewers to 1 ensures at least one reviewer is required. Option A is incorrect because automatic reviewers are not the same as required reviewers; they only suggest reviewers but do not enforce mandatory review. Option C is incorrect because a repository policy applies to all branches, not just main, and does not enforce required reviewers for pull requests; a branch policy is needed. Option E is incorrect because a branch protection rule is a GitHub feature, not available in Azure Repos.

Answer

Configure automatic reviewers for the security group.

Answer

Create a repository policy for the main branch.

Answer

Configure a branch protection rule in GitHub.

Question 10

Which THREE practices are recommended for managing secrets in a Git repository? (Select THREE.)

Accepted Answer

Use tools like GitLeaks to scan for accidentally committed secrets. The recommended practices for managing secrets in a Git repository include using tools like GitLeaks to scan for accidentally committed secrets (Option A), using GitHub Secrets or Azure Pipelines secret variables (Option C), and using Azure Key Vault to store and retrieve secrets at build/release time (Option D). These approaches help avoid storing secrets directly in the repository. Option B is incorrect because storing secrets in an encrypted file committed to the repository still exposes them to anyone who can access the repo and the decryption key. Option E is incorrect because committing a .env file with default values risks including sensitive data and is not a secure practice.

Answer

Store secrets in a separate encrypted file committed to the repository

Answer

Commit a .env file with default values to the repository

Question 11

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets are securely passed to workflows without being exposed in logs. What should you use?

Accepted Answer

GitHub Secrets. GitHub Secrets (Option A) is the correct choice because GitHub Actions provides a built-in secrets management system that encrypts sensitive values at rest and masks them in all workflow logs. When you reference a secret using ${{ secrets.MY_SECRET }}, GitHub automatically redacts the value from any log output, ensuring it is never exposed during execution.

Answer

Environment variables in the workflow YAML

Answer

Hardcode the secrets in the workflow file

Answer

Azure Key Vault with Azure DevOps encrypted variables

Question 12

Your organization uses GitHub for source control and GitHub Actions for CI/CD. You need to implement a branching strategy where every commit to the main branch triggers a build and deployment to a staging environment, but only after a successful pull request review. Which GitHub Actions trigger should you use?

Accepted Answer

push with branches: [main]. The `push` trigger with `branches: [main]` runs on every commit pushed to main. When branch protection requires pull request reviews, commits only reach main through a reviewed and merged PR, so this satisfies the 'only after successful pull request review' condition. In contrast, `pull_request_target` with `types: [closed]` triggers for any closed PR, including those not merged, and does not map one-to-one to commits on main. To use a PR event, you would need an additional condition like `if: github.event.pull_request.merged == true`, which is not mentioned.

Answer

pull_request_target with branches: [main] and types: [closed]

Answer

pull_request with branches: [main]

Answer

workflow_dispatch

Question 13

Your organization uses Azure Pipelines and requires that all builds be run on Microsoft-hosted agents to reduce maintenance overhead. However, you need to ensure that the build agent has a specific version of Node.js installed that is not available on the standard Microsoft-hosted agents. What should you do?

Accepted Answer

Use a container job that runs a custom Docker image with the required Node.js version.. Azure Pipelines supports container jobs on Microsoft-hosted agents with Docker (e.g., ubuntu-latest, windows-2019 with Docker enabled). By using a custom Docker image that includes the required Node.js version, you can run builds in a container while still using a Microsoft-hosted agent. Option C is also correct because you can use a script task at the start of the pipeline to install the specific Node.js version dynamically; Microsoft-hosted agents allow runtime installation of software via scripts. Options B and D are incorrect: B would require a self-hosted agent, violating the Microsoft-hosted agent requirement; D is not practical and not a guaranteed solution.

Answer

Deploy a self-hosted agent with the required Node.js version.

Answer

Request Microsoft to add the Node.js version to their hosted agents.

Question 14

You are designing a release strategy for a critical application that must maintain high availability. You decide to use Azure Traffic Manager to route traffic between deployments in two Azure regions. Your release pipeline deploys the application to the secondary region first, then switches Traffic Manager priority to route traffic to the secondary region while the primary region is updated. This strategy is known as:

Accepted Answer

Blue-green deployment. This strategy is a blue-green deployment because it uses two complete environments (primary and secondary regions). The new version is deployed to the secondary (green) environment first, then Traffic Manager priority routing switches all traffic from the primary (blue) to the secondary (green). The primary is then updated while idle. This is the classic blue-green pattern applied across regions, not a rolling deployment.

Answer

Canary deployment

Answer

Red/Black deployment

Answer

Rolling deployment across regions

Question 15

A development team uses Git for source control. They want to enforce a branching strategy where all feature work is done in short-lived branches that are merged to main via pull requests. The team also requires that every commit on main builds successfully. Which TWO practices should the team implement?

Accepted Answer

Configure a branch policy on main that requires a successful build before merging.. Option A configures a branch policy on main that requires a successful build before merging, directly ensuring every commit on main has passed a build. Option C requires at least one approver on all pull requests targeting main, which enforces the code review process as part of the pull request workflow, a key practice for maintaining a healthy branching strategy with short-lived feature branches. Together, these two practices enforce both the build-success requirement and the pull-request-based workflow.

Answer

Use squash merge when completing pull requests to main.

Answer

Create feature branches from main and keep them long-lived for stability.

Answer

Allow developers to commit directly to main for urgent fixes.