AZ-400 Hard Questions — 25 Difficult Questions

Question 1

A team uses Git-LFS to store large binary files. They observe that cloning the repository takes a long time because Git-LFS files are downloaded. How can they improve clone performance?

Accepted Answer

Use the --filter=blob:none option when cloning. The `--filter=blob:none` option performs a partial clone, which omits all blob objects (including Git-LFS pointer files and other large blobs) from the initial download. This significantly reduces clone time by only fetching commit and tree metadata, and then lazily downloading blobs on demand when they are actually accessed. For Git-LFS specifically, this avoids downloading the large binary files stored in LFS until they are needed, improving clone performance.

Answer

Use a shallow clone with depth 1

Answer

Use sparse checkout to limit files in working directory

Answer

Configure git lfs prune to run automatically

Question 2

Your company uses Azure Repos with a Git branching strategy that includes a main branch, a develop branch, and feature branches. You need to enforce that only designated release managers can merge changes from develop into main, while developers can create feature branches off develop and merge pull requests into develop. What is the best way to implement this?

Accepted Answer

Configure branch policies on main to require a minimum number of reviewers from the release manager group, and set the 'Allow users to create pull requests' permission to only include release managers.. By configuring branch policies on the main branch to require a minimum number of reviewers from the release manager group, you ensure that any changes to main are reviewed by designated release managers. Additionally, setting the 'Allow users to create pull requests' permission to only include release managers controls who can initiate pull requests into main. Option B is incorrect because branch protection rules are a GitHub feature, not available in Azure Repos. Option C is incorrect because setting the main branch to read-only would prevent all pushes, including those from release managers, unless they are granted write permissions; however, this approach does not enforce pull request reviews and is less granular. Option D is incorrect because requiring a successful build does not restrict who can merge; it only ensures code quality.

Answer

Use GitHub branch protection rules to require pull request reviews from release managers on main.

Answer

Set the main branch to read-only for all users except release managers using the 'Security' tab in repository settings.

Answer

Require a successful build for all branches and set the build pipeline to only run for release manager commits.

Question 3

You are designing a source control strategy for a team that uses GitHub Copilot. The team wants to ensure that code suggestions do not include sensitive data. Which approach should you recommend?

Accepted Answer

Configure content exclusions in GitHub Copilot settings to block sensitive data patterns. GitHub Copilot's content exclusions allow you to define patterns (e.g., regex for API keys, tokens, or PII) that Copilot will block from being used as context for code suggestions. This directly prevents sensitive data from appearing in suggestions without disabling the tool entirely. It is the most targeted and least disruptive approach to meet the team's goal.

Answer

Use pre-commit hooks to scan for secrets

Answer

Disable GitHub Copilot for the organization

Answer

Enable secret scanning for the repository

Question 4

A team uses Azure Boards to manage work items. They want to automatically update the state of a work item when a related pull request is merged in Azure Repos. Which TWO actions should they configure to enable this integration?

Accepted Answer

Add a branch policy that requires a linked work item for pull requests.. A branch policy that requires linked work items for pull requests ensures that every PR is associated with a work item. When the PR is merged, Azure Repos automatically updates the state of the linked work item (e.g., from 'Active' to 'Resolved') based on the default or configured transition rules. This integration is built into Azure DevOps without requiring external services.

Answer

Set up a webhook in Azure Repos to call Azure Logic Apps on pull request merge.

Answer

Configure a Service Hooks subscription in Azure DevOps to send pull request merge events to Azure Boards.

Answer

Create an Azure Function that listens for pull request merge events and updates work items via the REST API.

Question 5

Refer to the exhibit. You have configured a Conditional Access policy in Microsoft Entra ID to require MFA for Azure DevOps. However, users report that they can still access Azure DevOps without MFA when using a PAT for authentication. What is the most likely reason?

Accepted Answer

PATs are not subject to Conditional Access policies because they use legacy authentication.. B is correct because Personal Access Tokens (PATs) in Azure DevOps are considered legacy authentication tokens. Conditional Access policies in Microsoft Entra ID do not evaluate requests made using legacy authentication protocols, including PATs, OAuth device code flow, or IMAP/POP. Therefore, even if a Conditional Access policy requires MFA for Azure DevOps, users authenticating with a PAT bypass the policy entirely.

Answer

The policy should include 'Require device to be marked as compliant'.

Answer

The policy should be scoped to 'All cloud apps' instead of just Azure DevOps.

Answer

The Conditional Access policy is not enabled.

Question 6

A team uses Terraform to manage Azure infrastructure. They want to store the Terraform state file securely and enable collaboration. What is the recommended approach?

Accepted Answer

Store the state file in an Azure Storage account with state locking enabled. Storing the Terraform state file in an Azure Storage account with state locking enabled is the recommended approach because it provides a centralized, durable backend that supports native state locking via Azure Blob Storage leases. This prevents concurrent modifications and state corruption, enabling safe collaboration among team members. Azure Storage also offers encryption at rest and access control via RBAC, aligning with security best practices for infrastructure-as-code.

Answer

Store the state file in a local folder and commit to Git

Answer

Store the state file in Terraform Cloud

Answer

Store the state file in a Git repository with manual locking

Question 7

Your team uses a Git flow branching strategy with develop and release branches. You want to enforce that only release branches can be merged into main, and all merges into main require a successful deployment to a production-like environment. How should you implement this in Azure Pipelines?

Accepted Answer

YAML pipeline with environment approvals and branch filters on trigger. A YAML pipeline with environment approvals can require manual approval for deployment to a production-like environment, ensuring only successful deployments from a production-like environment allow merges. Branch filters on triggers can restrict pipeline execution to only release branches, preventing other branches from triggering the pipeline that leads to main. Option A is wrong because branch policies with required reviewers only enforce PR review requirements, not deployment or branch source restrictions. Option B is wrong because the 'Check for linked work items' status check ensures work items are linked but does not enforce branch restrictions or deployment validation. Option D is wrong because build validation runs on PR creation but does not enforce environment approvals or restrict the source branch to release branches only.

Answer

Branch policy with required reviewers for main

Answer

Required status check for 'Check for linked work items'

Answer

Build validation policy on main

Question 8

Your team uses GitHub Actions to build and deploy a Node.js application to Azure Functions. You need to implement a CI/CD pipeline that automatically deploys to a staging environment on every push to the main branch, and then promotes to production after a manual approval via GitHub Environments. The pipeline must also run unit tests and linting. You want to use the official Azure actions. What should you do?

Accepted Answer

Create a single GitHub Actions workflow with multiple jobs. Use a job for build and test, then a job for deploy to staging, and a job for deploy to production with an environment that requires approval.. Correct answer is C. A single GitHub Actions workflow can have multiple jobs: build and test, deploy to staging, and deploy to production. The production deployment job should use a GitHub Environment configured with required reviewers, enabling manual approval. Option A is incorrect because two separate workflows make it harder to share build artifacts and do not inherently use environment-based approvals for staging vs production. Option B is incorrect because GitHub Issues are not used for manual approvals; approvals are configured via GitHub Environments. Option D is incorrect because it uses Azure Pipelines, not GitHub Actions, which violates the requirement to use official Azure actions in GitHub Actions.

Answer

Create two separate workflows: one for CI (build, test, deploy staging) and one for CD (deploy production) that triggers manually.

Answer

Use a single workflow with a step that deploys to staging and then to production, using a condition to require manual approval via GitHub Issues.

Answer

Use Azure Pipelines with a multi-stage YAML pipeline that includes a stage for staging and a stage for production with pre-deployment approvals.

Question 9

You are designing a release pipeline for a multi-tenant SaaS application that is deployed to Azure App Service. Each tenant has its own App Service instance. The pipeline must deploy a new version of the application to a staging slot for each tenant, run smoke tests, and then swap the staging slot to production. You need to ensure that if the smoke tests fail for any tenant, the swap is not performed for that tenant, while other tenants continue. Which release pipeline configuration should you use?

Accepted Answer

Create a release with multiple jobs (one per tenant) in the same stage, each deploying to a tenant's staging slot, running tests, and conditionally swapping. Set the 'Run this job' condition to 'Only when all previous jobs have succeeded' or use custom conditions to skip swap on failure.. It uses separate jobs per tenant within a single stage, each with its own deployment, smoke test, and conditional swap. By setting the 'Run this job' condition to 'Only when all previous jobs have succeeded' or a custom condition, you ensure that a failed smoke test for one tenant blocks only that tenant's swap, while other tenants' jobs proceed independently. This design aligns with Azure Pipelines' job-level isolation, where each job runs on its own agent and can have independent success/failure conditions.

Answer

Create a single stage with a 'foreach' loop over tenants, and if smoke tests fail, skip the swap using a condition.

Answer

Create a single job with parallel tasks for each tenant, and configure failure conditions to skip the swap.

Answer

Create a single stage with multiple deployment tasks, one per tenant, and use a 'continue on error' option on each task.

Question 10

Which THREE conditions must be met for you to use the 'Approvals' feature in Azure Pipelines to control deployments to a production environment? (Choose three.)

Accepted Answer

The approver must have the 'Approve pipeline permissions' permission for the environment.. The 'Approvals' feature in Azure Pipelines requires an environment to be defined in the pipeline. You must add an approval check to that environment, which can be done in either a classic release pipeline or a YAML pipeline that references the environment as a resource. Additionally, the approver(s) - whether individual users or groups - must have the 'Approve pipeline permissions' permission on that environment. Without an environment resource, the approval check cannot be configured; without the permission, approval requests cannot be validated.

Answer

The approver must be an individual user, not a group.

Answer

The approval must be configured in the release pipeline's pre-deployment conditions.

Question 11

Your organization uses GitHub and wants to implement a monorepo strategy for multiple related projects. Which approach best optimizes CI/CD pipeline performance by only building projects that have changed?

Accepted Answer

Use path filters in GitHub Actions workflows. GitHub Actions path filters (using `on.push.paths` or `on.pull_request.paths`) allow you to trigger workflows only when changes are made to specific directories or files. In a monorepo, this ensures that CI/CD pipelines run exclusively for the projects that have been modified, avoiding unnecessary builds and significantly improving performance.

Answer

Use a single workflow that builds all projects on every push

Answer

Use submodules to separate projects

Answer

Use workflow templates and composite actions

Question 12

Which THREE components are required to set up a self-hosted agent pool in Azure Pipelines?

Accepted Answer

The agent software installed on the target machine. The self-hosted agent requires the Azure Pipelines agent software to be installed on the target machine. This software, which includes the agent listener and worker processes, is what registers the machine with the agent pool and executes pipeline jobs. Without the agent software, the machine cannot communicate with Azure Pipelines or run any tasks.

Answer

A deployment group target

Answer

Azure VM extension for Azure Pipelines Agent

Question 13

Refer to the exhibit. A build pipeline uses this trigger configuration. A developer pushes a commit to the 'main' branch that modifies files in '/src/app/' and '/src/tests/'. How many builds will be triggered?

Accepted Answer

1 build, because batchChanges is true.. The trigger configuration has `batchChanges` set to `true`. When `batchChanges` is enabled, Azure Pipelines groups all commits that arrive while a build is in progress into a single build, rather than triggering a separate build for each commit. In this scenario, the developer pushes a single commit that modifies files in both `/src/app/` and `/src/tests/`. Since `batchChanges` is true, only one build is triggered for that commit, regardless of the number of modified folders.

Answer

0 builds, because the excluded path takes precedence.

Answer

3 builds, because maxConcurrentBuildsPerBranch is 1 but batchChanges overrides.

Answer

2 builds, one for each modified folder.

Question 14

A company uses Azure Pipelines to build a .NET Core application. The build takes 45 minutes due to dependency restoration. They want to reduce build time. What is the most effective strategy?

Accepted Answer

Cache the NuGet packages and enable caching in the pipeline. Caching NuGet packages in Azure Pipelines is the most effective strategy because dependency restoration is the primary bottleneck, often downloading hundreds of packages from nuget.org. By caching the ~/.nuget/packages folder, subsequent builds skip the network download entirely, reducing the 45-minute build time to minutes. This directly addresses the root cause—repetitive package restoration—without requiring additional infrastructure or parallelism.

Answer

Use parallel jobs in the pipeline

Answer

Use a self-hosted agent with more CPU

Answer

Enable incremental builds

Question 15

You are designing a release pipeline for a mission-critical application that must achieve zero-downtime deployments to Azure App Service (Web App for Containers). The application uses Azure SQL Database with schema migrations. The current deployment slot strategy uses staging and production slots. You need to ensure that during a swap, the staging slot is warmed up and the database schema is rolled back if the swap fails. Which combination of deployment slots and pre/post-swap actions should you implement?

Accepted Answer

Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new to staging, warm up staging, then swap staging to production. On failure, swap staging back to production.. It uses three slots to isolate schema changes in a new slot, then swaps to staging for warm-up, and finally swaps to production. If the swap fails, rolling back staging to production reverses the schema changes, ensuring zero-downtime. This approach aligns with Azure App Service slot-swap best practices for mission-critical applications requiring database rollback capability.

Answer

Use two slots (staging and production) with auto-swap enabled. The auto-swap handles warm-up automatically. If the swap fails, Azure automatically rolls back.

Answer

Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new slot to staging, then staging to production. On failure, swap staging back to production.

Answer

Use two slots (staging and production). Apply schema changes in staging before swap. If swap fails, manually redeploy the old version to production.

Question 16

The pipeline fails because the artifact is empty. What is the most likely cause?

Accepted Answer

The build output is not copied to the staging directory. The most common reason for an empty artifact in Azure Pipelines is that the build output files were not copied to the staging directory (typically $(Build.ArtifactStagingDirectory)) before the PublishBuildArtifacts task runs. The PublishBuildArtifacts task publishes whatever is in the staging directory; if no files are copied there, the artifact will be empty. This is a standard pattern where a Copy Files task or similar step must explicitly place the build outputs into the staging directory.

Answer

The projects pattern '**/*.csproj' does not match any files

Answer

The task 'PublishBuildArtifacts@1' is misspelled

Answer

The artifact name 'drop' is invalid

Question 17

You execute the above Azure CLI command. A pipeline YAML references the variable group 'Config' and uses the variable 'env'. However, the pipeline fails because the variable 'env' is not found. What is the most likely reason?

Accepted Answer

The variable group 'Config' is not linked to the pipeline.. In Azure Pipelines, variable names are case-insensitive. A casing mismatch between the variable group and the YAML reference would not cause the variable to be 'not found'. The most likely reason is that the variable group 'Config' is not linked or the pipeline is not authorized to use it, so its variables (including 'env') are not available in the pipeline.

Answer

The variable 'env' is a secret variable and cannot be used in YAML.

Answer

The variable name is case-sensitive; the YAML uses 'Env' instead of 'env'.

Answer

The variable group is scoped to a specific branch, and the pipeline is running on a different branch.

Question 18

You are the DevOps lead for a financial services company. The company uses Azure DevOps Services with a single project containing multiple teams. The compliance team requires that all production deployments be approved by a change advisory board (CAB) member. Additionally, any deployment that changes a configuration value stored in Azure App Configuration must be audited. You have set up a release pipeline with a manual approval gate and a pre-deployment condition that runs a PowerShell script to validate configuration changes. However, the compliance team reports that some deployments bypassed the approval gate. Upon investigation, you find that developers with 'Edit release pipeline' permissions can modify the pipeline and remove the approval gate. You need to ensure that the approval gate cannot be bypassed by developers. You also need to ensure that any change to a configuration key is logged to Azure Monitor. What should you do?

Accepted Answer

Create a protected variable group that stores the approval gate configuration and set the pipeline to use it. Restrict edit permissions on the release pipeline to a security group that does not include developers. For configuration changes, use an Azure Resource Manager template with a deployment script that sends logs to Azure Monitor.. It addresses both requirements: restricting pipeline edit permissions to a security group that excludes developers prevents them from removing the approval gate, and using an ARM template with a deployment script that sends logs to Azure Monitor ensures configuration changes are audited. Protected variable groups secure sensitive configuration, but the key is permission separation and audit logging via ARM deployment scripts.

Answer

Create a new service connection with limited permissions and require that all pipeline runs use it. Use an Azure Policy to audit configuration changes.

Answer

Configure environment-level approvals in the release pipeline and use Azure Policy to enforce that all deployments go through the environment. Use diagnostic settings on App Configuration to stream logs to Azure Monitor.

Answer

Implement a branch policy on the release pipeline's YAML file in the repository to require approval for changes. Use a webhook to send configuration change events to Azure Monitor.

Question 19

Refer to the exhibit. The workflow runs successfully but the deployment fails because the Azure CLI is not authenticated. What should you add to the workflow to authenticate?

Accepted Answer

Add the 'azure/login' action with Azure credentials. The Azure CLI in the workflow requires authentication to interact with Azure resources. Adding the 'azure/login' action with valid Azure credentials (e.g., service principal secrets or OpenID Connect) establishes the necessary authentication context before any Azure CLI commands are executed, resolving the 'not authenticated' error.

Answer

Add the 'actions/setup-node' action

Answer

Add the 'azure/webapps-deploy' action

Answer

Add the 'actions/github-script' action to use the GitHub token

Question 20

Your organization is adopting GitHub Copilot for developers. Which security measure should you implement to ensure that no proprietary code is inadvertently shared with the AI model?

Accepted Answer

Configure content exclusions in the GitHub Copilot settings. GitHub Copilot's content exclusions allow administrators to specify files or repositories that should not be sent to the AI model for code completion suggestions. This prevents proprietary or sensitive code from being transmitted to GitHub's servers, ensuring compliance with security policies. Other options like network segmentation or audit logging do not directly block code from being shared with the AI.

Answer

Use a separate network segment for development

Answer

Disable GitHub Copilot for all users

Answer

Enable audit logging for Copilot usage