AZ-400 Practice Exam 60 — 20 Questions

Question 1

Your company is a startup developing a mobile application with a small team of 5 developers. You use GitHub Free and want to implement a simple but effective branching strategy that supports continuous delivery. The team wants to release new features every week and be able to hotfix critical bugs quickly. They currently have a main branch and feature branches, but sometimes features are merged to main before they are fully tested, causing issues. You need to recommend a strategy that minimizes risk while keeping the process lightweight. The team does not want to use long-lived branches. What should you recommend?

Accepted Answer

Use GitHub Flow: developers create feature branches from main, open pull requests with required CI and at least one review, then merge to main. Hotfixes follow the same process.. GitHub Flow is the simplest and most effective strategy for a small team using GitHub Free that wants continuous delivery without long-lived branches. By requiring feature branches, pull requests with CI checks, and at least one review before merging to main, it ensures that all code is tested and reviewed before integration, preventing untested features from breaking main. Hotfixes follow the same lightweight process, allowing quick, safe patches without additional branch overhead.

Answer

Use a single main branch and create release branches for each weekly release; features are merged to release branches, then release branches are merged to main after testing.

Answer

Allow developers to commit directly to main but require all commits to pass CI and be reviewed by at least one other developer after the fact.

Answer

Adopt GitFlow with develop and release branches.

Question 2

Your team is migrating from TFVC to Git in Azure Repos. You need to preserve the full history of the TFVC repository, including all branches and changesets. The TFVC repository is large (over 10 GB). Which tool should you use to perform the migration?

Accepted Answer

Use git-tfs to clone the TFVC repository and then push to Azure Repos.. B is correct because git-tfs is specifically designed to bridge TFVC and Git, allowing you to clone a TFVC repository (including all branches, changesets, and history) into a local Git repository, which can then be pushed to Azure Repos. It handles large repositories (over 10 GB) by performing an incremental clone, preserving the full history without manual recreation.

Answer

Manually recreate the commits in a new Git repository.

Answer

Use git-svn to convert TFVC to Git.

Answer

Use the Azure DevOps Migration Tools to export TFVC to Git.

Question 3

Your team uses GitHub with a monorepo containing frontend and backend code. You need to implement a strategy where changes to the frontend folder trigger a frontend CI pipeline, changes to the backend folder trigger a backend CI pipeline, and changes to both trigger both. You also want to ensure that pull requests include changes only to one area to reduce complexity. What should you do?

Accepted Answer

Configure separate CI pipelines with path filters so that each pipeline triggers only on changes to its respective folder.. Option B is correct because GitHub Actions and Azure Pipelines support path filters (e.g., `paths` in YAML triggers) that allow you to define separate CI pipelines for frontend and backend folders. When a pull request includes changes to both folders, both pipelines automatically trigger, satisfying the requirement. This approach ensures that each pipeline runs only when its relevant code changes, reducing unnecessary builds and complexity.

Answer

Use CODEOWNERS to assign different reviewers for frontend and backend, and rely on manual pipeline triggers.

Answer

Create branch policies that require specific builds based on the branch name.

Answer

Use a single pipeline that runs all tests on every change.

Question 4

Your team uses Azure Repos and has a repository with a large number of binary files (e.g., images, compiled libraries) that bloat the repository size. You want to reduce clone times and storage usage while still maintaining version history for those files. Which approach should you recommend?

Accepted Answer

Use Git Large File Storage (LFS) to track large files with pointers.. Git LFS (Large File Storage) replaces large binary files in the repository with text pointers, while storing the actual file content in a separate remote store. This keeps the repository lightweight for cloning and fetching, but still preserves the full version history of the binary files because each pointer references a specific version in the LFS store. It integrates natively with Azure Repos and requires minimal workflow changes.

Answer

Split the repository into two: one for code and one for binaries.

Answer

Use git annex to manage large files with a separate store.

Answer

Use git submodules to reference the large files from another repository.

Question 5

Your organization uses a monorepo in Azure Repos containing multiple microservices. You need to design a build pipeline that only builds and tests the services that have changed in a given commit, to optimize build times. The pipeline must trigger on any push to any branch, but only the affected services should be built. You also need to ensure that dependent services are rebuilt if their dependencies change. The services are located in subdirectories: /services/serviceA, /services/serviceB, etc. Each service has a Dockerfile and a unit test project. You plan to use a script to determine which services changed. Which approach should you use to implement this pipeline?

Accepted Answer

Use a script step to determine which services changed, then output variables to dynamically create a job matrix or use the 'each' keyword to iterate over changed services.. Option D is correct because the pipeline can use a script to detect changed files in the commit, map them to services, and then dynamically create jobs or stages for each affected service. This is efficient and flexible. Option A is wrong because using a single job that runs all tests ignores the requirement to only build changed services. Option B is wrong because using multiple jobs for all services would build everything every time, not optimizing. Option C is wrong because using a multi-stage pipeline with stages for each service would also build all services every time.

Answer

Create a multi-stage pipeline where each stage represents a service, and use a 'dependsOn' condition to run stages only if the corresponding service changed.

Answer

Create a single job that runs all unit tests for all services on every commit. Use caching to speed up the build.

Answer

Create a job for each service that runs in parallel on every commit. Use conditions to skip jobs if the service has not changed, but the conditions would need to check every service, which is complex.

Question 6

You are the DevOps lead for a large enterprise that uses GitHub for source control and Azure Pipelines for CI/CD. The organization has hundreds of repositories, each with its own pipeline. Recently, the security team mandated that all pipelines must use a centralized set of tasks for secret scanning and compliance checks before any deployment. You need to design a solution that enforces these mandatory tasks across all pipelines without modifying each pipeline individually. The solution should allow pipeline authors to add their own custom steps after the mandatory steps. The mandatory steps must be versioned and updated centrally. You also need to ensure that the mandatory steps are not bypassed by pipeline authors. What should you do?

Accepted Answer

Store the mandatory tasks as a YAML template in a central repository. In each pipeline, use the 'template' reference to include the mandatory steps. Use branch protection rules on the central repository to require approval for changes to the template.. Option C is correct because using a template repository with required templates and branch protection rules enforces the use of the mandatory steps. Option A is wrong because extensions can be disabled. Option B is wrong because a single pipeline cannot serve all repositories. Option D is wrong because the YAML template repository approach with enforcement through branch policies is the recommended way.

Answer

Use a global list of tasks in the Azure DevOps organization settings that automatically get injected into every pipeline.

Answer

Create a single pipeline that runs across all repositories and include the mandatory tasks in that pipeline.

Answer

Create a custom Azure DevOps extension that adds the mandatory tasks to all pipelines using a pre-job hook.

Question 7

You are setting up a release pipeline for an ASP.NET Core application that is deployed to Azure App Service (Windows). The application uses Entity Framework Core for database migrations. You need to automate the execution of database migrations during deployment, ensuring that the migrations run only once and that the application is not started until the migration completes. You also need to handle rollback in case the migration fails. The pipeline should deploy to staging slot, run migrations, swap to production, and then run post-swap migrations if needed. Currently, the pipeline deploys the code and then runs a script to execute 'dotnet ef database update'. However, during swap, the staging slot's migrations may conflict with production. What is the recommended architecture for handling database migrations with zero-downtime deployment?

Accepted Answer

Use Idempotent migrations and run them in the staging slot before swap. Then, after swap, run migrations again in the production slot to ensure any remaining changes are applied.. Option C is correct because using Idempotent migrations allows you to run them before swap without affecting production, and running them again after swap ensures any additional changes are applied. Running migrations before swap ensures the staging slot has the updated schema, and after swap, the production slot also gets the updates. Idempotent migrations ensure that running them multiple times is safe. Option A is wrong because running migrations only in staging before swap does not update production's database unless you run migrations after swap. Option B is wrong because running migrations only after swap causes downtime during migration. Option D is wrong because disabling automatic migration and using manual scripts adds risk and does not ensure zero-downtime.

Answer

Run migrations only in the staging slot before swap. After swap, the production slot will use the new schema automatically.

Answer

Run migrations only after the swap is complete, in the production slot. The application is stopped during migration to avoid errors.

Answer

Disable automatic migration execution in the pipeline. Instead, have a separate manual process to run migrations using a dedicated tool.

Question 8

Your organization uses Azure DevOps Server (on-premises) and is planning to migrate to Azure DevOps Services. You have hundreds of build and release pipelines. The migration must be done with minimal downtime and with validation that each pipeline works after migration. You have a test collection of 20 critical pipelines that must be validated first. What is the best approach?

Accepted Answer

Use the Azure DevOps Migration Tools to replicate the test pipelines to a new Azure DevOps Services organization. Validate, fix issues, then migrate the remaining pipelines in batches.. Using the Azure DevOps Migration Tools to perform a trial migration to a test organization allows you to validate and fix issues before migrating the full collection. Direct upgrade is not supported. Manual recreation is error-prone and not minimal downtime. Skipping validation risks breaking pipelines.

Answer

Export all pipelines as JSON from the server and import them into Azure DevOps Services. Skip validation to save time.

Answer

Manually recreate the 20 critical pipelines in Azure DevOps Services and test them. Then recreate the rest manually.

Answer

Perform an in-place upgrade of Azure DevOps Server to the latest version, then migrate to Azure DevOps Services using the Data Migration Tool.

Question 9

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.. Option A is correct because it uses GitHub Actions for CI per microservice, pushes to ACR, and uses Flux v2 for GitOps-based deployment with rollback by reverting Git. Option B is wrong because Azure Pipelines is not preferred if the team already uses GitHub Actions and GitOps. Option C is wrong because multi-branch pipelines in a single repo would mix concerns and violate requirement 1 (separate repos). Option D is wrong because Argo CD is not a native GitHub or Azure solution and introduces complexity.

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 10

Your team deploys a web application to Azure App Service using Azure Pipelines. The application requires a configuration file that contains connection strings and app settings. You need to ensure that the configuration is environment-specific and that sensitive values are not exposed in the pipeline logs. The configuration file is stored in a Git repository with different branches for each environment. You also need to support local development with the same configuration approach. Which strategy should you use?

Accepted Answer

Store environment-specific settings in Azure App Service configuration, and use variable groups in Azure Pipelines for secrets. Use token replacement in the config file during deployment.. Using environment-specific variable groups and token replacement is secure and supports local development with config transforms. Option B exposes secrets in logs. Option C relies on branch names, which is inflexible. Option D uses a single config, which is not environment-specific.

Answer

Store all settings, including secrets, in the config file in each branch. Use a script to replace tokens.

Answer

Use Azure App Service slots with sticky settings and store all settings in a single config file committed to the repository.

Answer

Use the same config file for all environments and override settings using pipeline variables based on branch name.

Question 11

You are setting up a build pipeline for a Node.js application that uses npm for package management. The pipeline should restore npm packages on every build, but you want to leverage caching to speed up the process. The pipeline runs on a Microsoft-hosted agent. You also need to ensure that the build fails if any npm audit vulnerabilities are found. Which tasks and configuration should you use?

Accepted Answer

Use the 'npm' task with 'install' command and enable caching by setting the 'workingDirectory' variable. Run a separate 'npm' task with 'audit' command and set 'failOnVulnerabilities' to 'true'.. The npm task with 'install' restores packages, and the 'npm audit' command checks for vulnerabilities. Caching is done with the Cache task using a key based on package-lock.json.

Answer

Use the 'npm' task with 'custom' command to run 'npm ci'. Use the 'Cache' task to cache 'node_modules' with a key based on 'package.json'.

Answer

Use the 'npm' task with 'install' command without caching. After install, run a PowerShell script to run 'npm audit --audit-level=high' and parse the output.

Answer

Use the 'npm' task with 'ci' command and set 'ignoreScripts' to true. Add a 'npm audit' task but set 'failOnVulnerabilities' to 'false' to avoid build failures.

Question 12

Your organization uses Azure DevOps Server (on-premises) and plans to migrate to Azure DevOps Services. You have hundreds of classic build and release pipelines. You need to design a migration strategy that minimizes downtime and allows for a gradual transition. The team wants to use the new YAML-based pipelines after migration. What should you do?

Accepted Answer

Export the classic pipeline definitions as JSON, and manually recreate them as YAML pipelines in Azure DevOps Services.. Option B is correct: Exporting pipeline definitions and converting them to YAML manually allows gradual migration. Option A is incorrect because the migration tool does not convert classic pipelines to YAML. Option C is incorrect because using classic pipelines after migration is not leveraging YAML. Option D is incorrect because recreating from scratch is inefficient and error-prone.

Answer

Recreate all pipelines from scratch using YAML in the new organization.

Answer

Use the Azure DevOps Migration Tools to automatically convert classic pipelines to YAML.

Answer

Migrate all pipelines as-is (classic) and then plan a separate project to convert them to YAML.

Question 13

You are a DevOps engineer for a large e-commerce company. The development team uses GitHub for source control and GitHub Actions for CI/CD. The application is a microservices architecture with 15 services, each in its own repository. You need to implement a continuous delivery pipeline that builds and deploys each service to a Kubernetes cluster in Azure (AKS). The pipeline must meet the following requirements: 
- Each service must have its own pipeline that triggers on pushes to the main branch.
- Deployment to AKS must use Helm charts.
- The pipeline must automatically increment the Helm chart version and update the deployment manifest in the repository.
- Security scanning must be performed on container images before deployment.
- The pipeline must support manual approval for production deployment.
- All secrets (e.g., AKS credentials, registry credentials) must be stored securely and not exposed in logs.
You need to design the workflow. What is the best course of action?

Accepted Answer

Create a reusable workflow with OIDC authentication to Azure. Use Helm to deploy, increment chart version, and commit back. Use GitHub environments for approval gates. Integrate container scanning with Docker Scout or Trivy.. Using GitHub Actions with OIDC to authenticate to Azure avoids storing long-lived secrets. Helm chart version bumping can be done with a script. The workflow uses environments for approval gates. Container scanning using tools like Trivy can be added as a step.

Answer

Use Azure Pipelines instead of GitHub Actions because it has better integration with AKS. Store secrets in Azure Key Vault and use variable groups.

Answer

Create a workflow per service with direct deployment. Use kubectl commands to deploy. Store all secrets in a single GitHub secret. Skip security scanning to save time.

Answer

Create a single reusable workflow that each service calls. Use Azure CLI to deploy Helm charts. Store AKS credentials as GitHub secrets. Use a manual approval step via environment protection rules.

Question 14

Your company uses Azure DevOps for CI/CD. You have a build pipeline that compiles a C++ application and runs unit tests. The pipeline uses a Microsoft-hosted agent. The build takes approximately 45 minutes to complete. You want to reduce the build time. You notice that the pipeline downloads dependencies from a NuGet feed every time. You have a private NuGet feed in Azure Artifacts. The pipeline restores packages using 'nuget restore'. You want to cache the NuGet packages on the agent to avoid downloading them on every build. What should you do?

Accepted Answer

Add a CacheBeta task before the restore step to cache the packages folder.. Option B is correct because the CacheBeta task allows caching folders between builds, reducing download time. Option A is wrong because self-hosted agents might not be available or cost-effective. Option C is wrong because upgrading to a higher SKU of Microsoft-hosted agents does not affect package caching. Option D is wrong because a hosted NuGet feed does not inherently cache packages locally.

Answer

Use a self-hosted agent with persistent storage.

Answer

Use a hosted Azure Artifacts feed with upstream sources.

Answer

Increase the agent's compute resources by selecting a higher SKU.

Question 15

Your company uses GitHub Actions for CI/CD. The development team wants to automatically create a new GitHub release with release notes whenever a pull request is merged to the main branch. The release notes should include a list of all merged pull requests since the last release. You need to implement this automation. What should you do?

Accepted Answer

Add a workflow triggered on push to main that uses the 'softprops/action-gh-release' action to create a release with auto-generated release notes.. Option A is correct: The 'softprops/action-gh-release' action creates releases and can generate release notes from merged PRs. Option B is incorrect because tagging manually is not automated. Option C is incorrect because releases are not created by default on tag push. Option D is incorrect because the 'Create a release' step alone does not generate release notes from merged PRs.

Answer

Configure a branch protection rule to require a release note file in each pull request.

Answer

Use a workflow that runs on pull request merge and creates a Git tag, then rely on GitHub to create a release from the tag.

Answer

Add a step to the existing CI workflow that runs 'gh release create' with a changelog.

Question 16

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a pipeline that automatically builds and tests a Python application on every pull request to the main branch, but only if the pull request is from a fork. The pipeline must also publish test results as a build artifact. What should you do?

Accepted Answer

Configure a branch protection rule on main that requires status checks from Azure Pipelines. Set the pipeline trigger to 'Pull request validation' and include a condition to run only if the pull request is from a fork.. Option A is correct because GitHub branch protection can require status checks from Azure Pipelines, and the pipeline can be triggered on pull request events. Option B is incorrect because pipeline completion trigger is not for PR from forks. Option C is incorrect because manual trigger doesn't automate. Option D is incorrect because GitHub Actions is not Azure Pipelines.

Answer

Use GitHub Actions to build and test the application on PRs, and then trigger Azure Pipelines for deployment.

Answer

Use a scheduled trigger to run the pipeline every hour and check for new PRs from forks.

Answer

Set up a pipeline completion trigger on the main branch that runs the pipeline after every merge.

Question 17

Your company develops a microservices-based application deployed on Azure Kubernetes Service (AKS). The CI/CD pipeline uses Azure Pipelines. The development team has recently adopted a trunk-based development strategy where all feature work is done on short-lived branches that merge to main at least daily. The release pipeline must automatically deploy to a development environment on each commit to main, and to a staging environment after a manual approval. The staging environment is used for integration tests and must remain stable. You need to design the release pipeline strategy to support this workflow. What should you do?

Accepted Answer

Create a single release pipeline with two stages: 'Dev' triggered automatically on successful build, and 'Staging' with a pre-deployment approval gate.. Option A is correct: A single release pipeline with multiple stages (dev and staging) and an approval gate on staging meets the requirements. Option B is incorrect because separate pipelines would cause duplication and maintenance overhead. Option C is incorrect because multiple environments in a single stage would not allow different triggers. Option D is incorrect because disabling CD for staging would require manual promotion, which is not desired.

Answer

Create a single release pipeline with one stage that deploys to both dev and staging simultaneously, and add a manual intervention task before staging deployment.

Answer

Create two separate release pipelines: one for dev with continuous deployment trigger, and one for staging with a manual trigger.

Answer

Create a single release pipeline with two stages: 'Dev' triggered automatically, and 'Staging' with a post-deployment approval gate and disable continuous deployment trigger.

Question 18

Your team uses Azure Pipelines to deploy a multi-tier application to Azure. The application consists of a web frontend, an API backend, and a database. You need to deploy the database schema changes using a DACPAC file. The deployment should be idempotent and support rollback. You must use the Azure SQL Database deployment task. What should you do?

Accepted Answer

Use the 'Azure SQL Database deployment' task with the 'Deploy' action, specifying the DACPAC file and setting the 'Additional Arguments' to include 'p:BlockOnPossibleDataLoss=False' for safety.. Option A is correct: The 'Azure SQL Database deployment' task supports incremental deployment from a DACPAC and allows rollback via additional steps. Option B is incorrect because SQL scripts do not provide the same level of idempotency as DACPAC. Option C is incorrect because executing the DACPAC manually is not automated. Option D is incorrect because the task does support DACPAC deployment.

Answer

Use the 'Azure SQL Database deployment' task with the 'Query' action to run schema changes.

Answer

Use a 'PowerShell' task to run 'SqlPackage.exe' with the DACPAC file.

Answer

Use the 'Azure SQL Database deployment' task with the 'Run SQL Script' action, and execute the schema changes as SQL scripts.

Question 19

You are implementing a release pipeline for a web application deployed to multiple Azure App Service instances across different regions (West US, East US, and North Europe). The deployment must follow a phased rollout: first West US, then East US, then North Europe, with a manual approval gate between each region. Each region should have its own slot for staging and production. You need to design the pipeline to minimize duplication of stages and tasks. What should you do?

Accepted Answer

Use a single stage with a deployment group job that targets agents tagged with region names, and use deployment group tags to control phased rollout.. Option A is correct because a deployment group job with deployment group tags allows targeting regions and reusing tasks. Option B is incorrect because each region would need separate stages. Option C is incorrect because environment-based strategy requires separate environments. Option D is incorrect because parallel deployment does not support phased rollout with approvals.

Answer

Use a multi-stage YAML pipeline with environment per region and a manual approval on each environment.

Answer

Create three separate stages (one per region) and duplicate the deployment tasks in each.

Answer

Use a single stage with parallel deployment to all regions and add manual approvals before each region's deployment.

Question 20

Your team uses GitHub Actions to deploy a microservices application to a Kubernetes cluster. The workflow builds Docker images and pushes them to a container registry, then updates the Kubernetes deployment. The deployment often fails due to image pull errors, specifically 'ErrImagePull' and 'ImagePullBackOff'. You investigate and find that the image tag in the Kubernetes manifest is the commit SHA. The workflow uses the 'azure/k8s-deploy@v1' action. You suspect that the image is not being pulled because the registry credentials are not properly configured. You have stored the registry credentials as secrets. What is the most likely cause and solution?

Accepted Answer

The action does not automatically create imagePullSecrets; you need to add a step to create the secret in the cluster and reference it in the deployment.. Option A is correct because the k8s-deploy action by default uses the kubeconfig file for cluster access but does not automatically set up image pull secrets for the registry. The credentials need to be explicitly configured as imagePullSecrets in the deployment manifest. Option B is wrong because the image tag is correct; the issue is authentication. Option C is wrong because the image name is likely correct; the issue is pulling. Option D is wrong because the action is capable of deploying; the issue is configuration.

Answer

The commit SHA tag is not valid; use 'latest' tag instead.

Answer

The image name is incorrect; verify the registry URL.

Answer

The 'azure/k8s-deploy' action does not support private registries; use a different action.