Courseiva
Knowledge + Practice
CertificationsVendorsCareer RoadmapsLabs & ToolsStudy GuidesGlossaryPractice Questions
C
Courseiva

Free IT certification practice questions with explained answers for CCNA, CompTIA, AWS, Azure, Google Cloud, and more.

Certification Practice Questions

CCNA practice questionsSecurity+ SY0-701 practice questionsAWS SAA-C03 practice questionsAZ-104 practice questionsAZ-900 practice questionsCLF-C02 practice questionsA+ Core 1 practice questionsGoogle Cloud ACE practice questionsCySA+ CS0-003 practice questionsNetwork+ N10-009 practice questions
View all certifications →

Product

CertificationsCertification PathsExam TopicsPractice TestsExam Dumps vs Practice TestsStudy HubComparisons

Company

AboutContactEditorial PolicyQuestion Writing PolicyTrust Center

Legal

Privacy PolicyTerms of Service

Courseiva is a free IT certification practice platform offering original exam-style practice questions, detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics for Cisco, CompTIA, Microsoft, AWS, and other technology certifications.

© 2026 Courseiva. Courseiva is operated by JTNetSolutions Ltd. All rights reserved.

Courseiva is an independent certification practice platform and is not affiliated with, endorsed by, or sponsored by Cisco, Microsoft, AWS, CompTIA, Google, ISC2, ISACA, or any other certification vendor. Vendor names and certification marks are used only to identify the exams learners are preparing for.

HomeCertificationsAZ-400Exam Questions

Microsoft · Free Practice Questions · Last reviewed May 2026

AZ-400 Exam Questions and Answers

42real exam-style questions organised by domain, each with the correct answer highlighted and a plain-English explanation of why it's right — and why the others are wrong.

50 exam questions
120 min time limit
Pass: 700/1000 / 1000
7 exam domains
OverviewDomain BlueprintStudy GuideAll QuestionsSample by Domain
1. Configure processes and communications2. Design and implement source control3. Design and implement build and release pipelines4. Develop a security and compliance plan5. Implement an instrumentation strategy6. Design and implement a DevOps infrastructure7. Design and implement a source control strategy
1

Domain 1: Configure processes and communications

All Configure processes and communications questions
Q1
easyFull explanation →

A team uses Azure Boards and wants to ensure that work items moved to the 'Done' state require a completed code review. What should they configure?

A

Add a work item rule in the process template to require a code review for the 'Done' transition.

Work item rules enforce conditions on state transitions.

B

Modify the work item type definition to add a custom field for code review status.

C

Use a tag to mark work items as code-reviewed before moving to 'Done'.

D

Configure branch policies in Azure Repos to require pull request approvals.

Why: Option A is correct because Azure Boards allows you to define work item rules within the process template that enforce specific conditions on state transitions. By adding a rule to the 'Done' transition that requires a completed code review (e.g., via a custom field or check), you ensure work items cannot be moved to 'Done' without meeting that prerequisite. This is done through the inherited process customization in Azure DevOps, where you can add rules to the work item type's state transition.
Q2
mediumFull explanation →

During a sprint review, stakeholders complain that they don't receive notifications about completed work items. The team uses Azure Boards with a custom notification subscription. What is the most likely cause?

A

Email notifications are disabled at the organization level.

B

The subscription is set to deliver only to the team members.

C

The subscription's 'Deliver to' filter excludes stakeholders.

The filter must include stakeholders for them to receive notifications.

D

The subscription was automatically disabled after the first notification.

Why: The most likely cause is that the custom notification subscription's 'Deliver to' filter is configured to exclude stakeholders. In Azure Boards, notification subscriptions can have filters that restrict delivery to specific groups or roles, and if stakeholders are not included in the filter, they will not receive notifications even if the subscription is active. This directly addresses the complaint that stakeholders are not getting notified about completed work items.
Q3
hardFull explanation →

A multinational company uses Azure DevOps with a single project. The project has multiple teams in different time zones. They want to customize the process to reflect different working days for each team. What is the recommended approach?

A

Create a custom process for each time zone and assign teams accordingly.

B

Use the same process but create separate areas for each team, then configure working days per area path.

C

Use the same process and configure working days in the team settings for each team.

Team settings allow per-team working days.

D

Use the same process and configure capacity planning for each team to account for time off.

Why: Option C is correct because Azure DevOps allows each team to have its own working days configured in team settings, independent of the process template. This enables teams in different time zones to define their own non-working days without modifying the shared process, which would affect all teams using that process.
Q4
mediumFull explanation →

A team uses Azure Repos with a Git branching strategy that includes feature branches. They want to ensure that all feature branches are deleted automatically after the pull request is completed. What should they do?

A

Enable 'Automatically delete source branch' in the branch policy.

This deletes the source branch after the PR is completed.

B

Enable 'Create a merge commit' option in the branch policy.

C

Configure branch retention policy in the pipeline to delete branches after build.

D

Create a work item to remind developers to delete branches after merge.

Why: Option A is correct because Azure Repos branch policies include an 'Automatically delete source branch' checkbox. When enabled, the source branch (e.g., a feature branch) is automatically deleted once the pull request is completed (merged or abandoned). This enforces cleanup without manual intervention, directly meeting the requirement.
Q5
hardFull explanation →

An organization uses Azure DevOps and wants to implement a change management process where all changes to the main branch require approval from a change advisory board (CAB). The CAB members are not part of the development team. How should they configure this?

A

Set branch permissions to restrict push to main and only allow CAB to approve via manual process.

B

Create a new branch policy on main that requires a minimum number of reviewers from a separate CAB group.

Branch policies can require specific reviewers or groups.

C

Use a service hook to notify CAB when a PR is created, and rely on manual approval.

D

Add the CAB as members of the development team and require team review.

Why: Option B is correct because Azure DevOps branch policies allow you to enforce a minimum number of reviewers from a specific security group (e.g., a CAB group) on pull requests targeting the main branch. This ensures that every change to main requires explicit approval from CAB members, who are separate from the development team, without relying on manual processes or altering team membership.
Q6
easyFull explanation →

Which TWO actions help improve communication and collaboration in a distributed Azure DevOps team?

A

Maintain a shared wiki with project documentation and decisions.

Centralized documentation aids transparency.

B

Use multiple chat channels for each topic to organize discussions.

C

Use long email threads for decision-making to ensure full documentation.

D

Schedule daily stand-up meetings at a time that works for all time zones.

Daily sync helps alignment.

E

Avoid using pull request comments to reduce noise.

Why: A shared wiki (e.g., Azure DevOps Wiki) provides a single source of truth for project documentation, decisions, and onboarding materials. It is version-controlled, searchable, and accessible asynchronously, which is critical for distributed teams to stay aligned without relying on real-time communication.

Want more Configure processes and communications practice?

Practice this domain
2

Domain 2: Design and implement source control

All Design and implement source control questions
Q1
easyFull explanation →

A team uses a monorepo with multiple projects in one Git repository. They want to enforce that each commit message must reference a work item from Azure Boards. Which branch policy should they configure?

A

Automatically include work items in pull request descriptions

B

Require a work item linking policy in branch policies

This policy enforces that every pull request has at least one linked work item.

C

Configure a minimum number of reviewers policy

D

Use a build validation policy to check commit messages

Why: The 'Require a work item linking policy' in Azure Repos branch policies enforces that every pull request must be associated with at least one Azure Boards work item before it can be completed. This policy directly meets the requirement to ensure each commit message references a work item, as the linking is validated at merge time.
Q2
mediumFull explanation →

An organization has multiple Git repositories. Developers often forget to update the repository README file after making changes. What is the most effective way to ensure the README is always up-to-date?

A

Apply a label to PRs that touch certain files and require review

B

Add a task in the CI pipeline that checks if the README was modified

C

Use a repository template with a mandatory README file structure

Templates provide a starting point and can include a README that developers must fill.

D

Require a pull request comment that confirms README update

Why: Option C is correct because using a repository template with a mandatory README file structure enforces a consistent baseline for all new repositories, ensuring that a README is always present and follows a predefined format. This approach addresses the root cause—developers forgetting to update the README—by making the README an integral part of the repository creation process, rather than relying on post-hoc checks or manual reviews. In Azure Repos, repository templates can include required files and folder structures, which are automatically applied when a new repository is created from the template, thereby preventing the omission of the README from the start.
Q3
hardFull explanation →

A development team uses a forking workflow in Azure Repos. They want to ensure that only specific users can create forks of the main repository. How can they achieve this?

A

Use branch security to restrict who can create forks

Under repository settings, you can set security by group for 'Create Fork' permission.

B

Set branch policies on the main branch to prevent forks

C

Configure the repository to disable forks globally

D

Remove the 'Create Fork' permission from all users except the required group

Why: In Azure Repos, the ability to create forks is controlled by a specific permission called 'Create Fork' at the repository level. By default, all contributors have this permission. To restrict fork creation to only specific users, you must remove the 'Create Fork' permission from all users and groups, then explicitly grant it only to the desired group or individuals. This is a permission-based security model, not a branch policy or global toggle.
Q4
easyFull explanation →

A team uses Git for source control. They want to automatically squash all commits in a feature branch into a single commit when merging to the main branch. Which merge type should they use?

A

Rebase and fast-forward

B

Squash commit

Combines all changes into a single commit on target branch.

C

Merge commit (no fast-forward)

D

Semi-linear merge

Why: B is correct because the squash commit merge type collapses all commits in a feature branch into a single new commit on the target branch. This satisfies the requirement to automatically squash all commits when merging to main, as it creates a clean, linear history with one combined commit that contains all changes from the feature branch.
Q5
mediumFull explanation →

A company has a policy that all code changes must be reviewed by at least two people. However, for urgent bug fixes, they want to allow a single reviewer. How should they configure the branch policy?

A

Set minimum number of reviewers to 1 and require a separate approval from a manager

B

Set minimum number of reviewers to 2 and allow resetting code review votes on new pushes

C

Configure a build validation policy that checks number of approvals

D

Set minimum number of reviewers to 2, but allow policy override for urgent fixes

Policy override can be used with a justification to bypass the two-reviewer requirement.

Why: Option D is correct because Azure Repos branch policies allow you to set a minimum number of reviewers (e.g., 2) and then enable the 'Allow policy override' setting for urgent fixes. This lets authorized users bypass the two-reviewer requirement for critical bug fixes while maintaining the default policy for normal changes.
Q6
hardFull explanation →

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?

A

Use a shallow clone with depth 1

B

Use the --filter=blob:none option when cloning

This partial clone defers downloading LFS blobs until they are accessed.

C

Use sparse checkout to limit files in working directory

D

Configure git lfs prune to run automatically

Why: Option B is correct because 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.

Want more Design and implement source control practice?

Practice this domain
3

Domain 3: Design and implement build and release pipelines

All Design and implement build and release pipelines questions
Q1
easyFull explanation →

A team uses Azure Pipelines to build a .NET Core application. The build pipeline runs successfully, but the release pipeline fails when deploying to Azure App Service with the error: 'ERROR_FILE_IN_USE'. What is the most likely cause?

A

The deployment slot is not configured correctly.

B

The 'Take App Offline' setting is not enabled in the deployment task.

Taking the app offline releases file locks.

C

The Azure App Service plan is not scaled appropriately.

D

The build configuration is set to Release instead of Debug.

Why: The 'ERROR_FILE_IN_USE' error occurs when the deployment process tries to overwrite files that are currently locked by the running application. Enabling the 'Take App Offline' setting in the Azure App Service deploy task places an app_offline.htm file in the wwwroot directory, which gracefully shuts down the application and releases all file locks before the new binaries are copied. Without this setting, the running process holds locks on the DLLs, causing the deployment to fail.
Q2
mediumFull explanation →

A development team is designing a build pipeline for a microservices application. They want to ensure that each service is built and tested independently, but they also need to run integration tests that span multiple services. What is the recommended approach?

A

Use a single release pipeline that triggers manual deployment for each service.

B

Create a single build pipeline that builds all services together to ensure consistency.

C

Create individual build pipelines for each service, and a separate release pipeline that deploys all services to an integration environment for testing.

This allows independent builds and integration tests.

D

Build each service separately, but skip integration tests to avoid complexity.

Why: Option C is correct because it aligns with microservices best practices: each service has its own build pipeline for independent compilation, unit testing, and artifact generation, while a separate release pipeline orchestrates deployment of all services to a shared integration environment for cross-service testing. This decouples build concerns from deployment concerns, enabling parallel development and faster feedback loops.
Q3
hardFull explanation →

A company uses Azure Pipelines with YAML-based pipelines stored in a Git repository. The pipeline triggers on every push to the main branch, but the team wants to reduce unnecessary builds when only documentation files are changed. What is the best way to achieve this?

A

Use path filters in the trigger section to exclude 'docs/*' and '*.md' files.

Path filters allow excluding specific paths from triggering.

B

Configure branch policy to require a pull request for documentation changes.

C

Add a 'condition' to the pipeline that checks if changed files are documentation.

D

Disable CI trigger and rely on scheduled builds.

Why: Option D is correct because using path filters with exclude patterns on the main branch trigger prevents builds for specific file changes. Option A is wrong because branch policies do not filter file changes. Option B is wrong because skipping CI entirely is not desirable. Option C is wrong because conditions evaluate after the pipeline starts, not before.
Q4
mediumFull explanation →

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?

A

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

B

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

C

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

D

Use a release pipeline that deploys to a new Azure App Service instance, runs tests, and then removes the instance.

Ephemeral environments are ideal for temporary testing.

Why: Option D is correct because 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.
Q5
mediumFull explanation →

Which TWO actions should be taken to secure secrets in Azure Pipelines? (Choose two.)

A

Use secret variables with the 'secret' input type to mask them in logs.

Secret variables are masked in logs.

B

Use a variable group without Key Vault integration for easier management.

C

Store secrets directly in the YAML pipeline file.

D

Store secrets in a variable group linked to Azure Key Vault.

Variable groups from Key Vault allow secure secret storage.

E

Disable CI triggers to reduce exposure.

Why: Option A is correct because Azure Pipelines allows you to mark variables as 'secret' by using the 'secret' input type in the pipeline settings UI or by setting `isSecret: true` in YAML. This ensures the variable's value is masked with asterisks in all logs and output, preventing accidental exposure during build or release execution.
Q6
hardFull explanation →

You are reviewing an Azure Policy definition applied to an Azure DevOps project. The project has a build pipeline that deploys to production. What is the effect of this policy on the build pipeline?

A

The policy blocks the pipeline from running if fewer than two reviewers approve.

B

The policy requires two reviewers and blocks the pipeline if not met.

C

The policy audits the pipeline but does not enforce any mandatory reviewers.

The audit effect logs compliance without blocking.

D

The policy does not apply to build pipelines because the field type is teamProjects.

Why: Azure Policy definitions applied to Azure DevOps projects use the 'audit' effect by default for policy types that do not support 'deny' or 'enforce' on build pipelines. Since the policy in question does not specify a mandatory reviewer requirement with enforcement, it only audits the pipeline's compliance without blocking execution. Therefore, the pipeline runs regardless, and the policy logs a compliance state.

Want more Design and implement build and release pipelines practice?

Practice this domain
4

Domain 4: Develop a security and compliance plan

All Develop a security and compliance plan questions
Q1
mediumFull explanation →

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?

A

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

B

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

C

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

D

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.

A decorator can inject validation tasks into every pipeline to enforce the use of a specific service connection.

Why: Option D is correct because 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.
Q2
hardFull explanation →

Your organization uses Azure DevOps and Azure Key Vault to manage secrets. You have a pipeline that deploys a web app to Azure App Service. The pipeline uses a variable group linked to Key Vault to retrieve the database connection string. Recently, the build started failing with the error: 'Access to Key Vault is denied. Please ensure the service connection has Get and List permissions on secrets.' The service connection uses a service principal. You have verified that the service principal has the correct Key Vault access policy with Get and List permissions. What is the most likely cause of the failure?

A

The service connection is configured to use the wrong Azure subscription.

B

The secret name in the variable group does not match the secret name in Key Vault.

C

The service principal used by the service connection does not have Contributor role on the Key Vault.

D

The build service identity does not have Get and List permissions on the Key Vault secrets.

The build service identity (project collection or project level) must be granted access to Key Vault for variable group resolution.

Why: The error message indicates that the identity attempting to access Key Vault lacks the required permissions. Even though the service principal has the correct access policy, the pipeline may be using a different identity—the build service identity—to authenticate with Key Vault. In Azure DevOps, when a variable group is linked to Key Vault, the pipeline's build service identity (not the service connection's service principal) must have Get and List permissions on the Key Vault secrets. This is a common misconfiguration where the service principal is granted permissions but the build service identity is not.
Q3
easyFull explanation →

A company uses Azure DevOps and needs to ensure that all pipelines use approved YAML templates from a central repository. The security team wants to prevent developers from referencing unapproved templates. What is the best way to enforce this?

A

Create a branch policy on the repository that requires all pull requests to be approved by security team members.

B

Configure a variable group with the approved template repository and require it in all pipelines.

C

Use a pipeline decorator to check the template origin and fail the pipeline if unapproved.

D

Set the 'Required template' repository setting in the Azure DevOps project to the approved central repository.

This built-in setting enforces that all YAML templates must come from the specified repository.

Why: Option D is correct because the 'Required template' repository setting in Azure DevOps enforces that all pipelines must use a YAML template from a specified central repository. If a pipeline references a template from any other location, the pipeline will fail at runtime, providing a hard enforcement mechanism that cannot be bypassed by developers. This directly addresses the security team's requirement to prevent unapproved template references.
Q4
mediumFull explanation →

You are designing a compliance strategy for Azure DevOps pipelines that deploy to production. The company policy requires that all production deployments must be reviewed by a security lead. Additionally, the deployment must use a specific release pipeline that has been pre-approved. How should you implement this?

A

Create a branch policy that requires the security lead to approve the pull request before merging.

B

Define a 'production' environment in Azure DevOps and configure an approval check that requires the security lead. Have the pipeline deploy to that environment.

Environment approvals provide the required manual review gate.

C

Use a Classic release pipeline with a pre-deployment approval gate for the production stage.

D

Store the approved pipeline definition in a variable group and reference it in all pipelines.

Why: Option B is correct because Azure DevOps environments allow you to define approval checks that must be satisfied before a deployment proceeds. By creating a 'production' environment and adding a pre-deployment approval check requiring the security lead, you enforce the mandatory review. The pipeline then deploys to that environment, ensuring only the pre-approved release pipeline is used.
Q5
hardFull explanation →

A financial services company uses Azure DevOps and requires that all secrets (e.g., API keys, connection strings) be stored in Azure Key Vault. They have a pipeline that runs automated tests and deploys to staging. The pipeline uses a variable group linked to Key Vault to retrieve secrets. Recently, the pipeline failed with the error: 'Secret 'DbPassword' not found in Key Vault 'kv-prod'. Ensure the secret exists and the service principal has List permission.' The secret exists in the vault. What is the most likely cause?

A

The variable group is linked to the wrong Key Vault instance.

B

The variable name in the variable group does not exactly match the secret name in Key Vault (case-sensitive).

Azure DevOps maps variable names to secret names, and the match is case-sensitive.

C

The service principal does not have Get permission on the secret.

D

The Key Vault is in a different Azure region than the Azure DevOps organization.

Why: Option B is correct because variable groups linked to Azure Key Vault in Azure DevOps require an exact case-sensitive match between the variable name in the variable group and the secret name in Key Vault. Even though the secret 'DbPassword' exists in the vault, if the variable group defines the variable as 'dbpassword' or 'DBPassword', the lookup will fail with the 'not found' error. The error message explicitly states the secret was not found, which is the typical symptom of a case mismatch, not a permissions or connectivity issue.
Q6
mediumFull explanation →

Your organization uses Azure DevOps and Azure Policy to enforce compliance. You need to ensure that all Azure resources deployed by Azure DevOps pipelines have specific tags (e.g., CostCenter and Environment) applied. Which TWO approaches can achieve this? (Choose TWO.)

A

Configure the service connection to only allow deployments with tags.

B

Create an Azure Policy with the 'audit' effect to report non-compliant resources.

C

Create an Azure Policy with the 'deny' effect that requires the tags to be present at resource creation.

Deny policy blocks deployment of non-compliant resources.

D

Add a pipeline task after resource creation that applies the required tags using Azure CLI or PowerShell.

This remediates missing tags post-deployment.

E

Configure a branch policy on the main branch to require tag verification in pull requests.

Why: Option C is correct because an Azure Policy with the 'deny' effect prevents the creation of any resource that does not include the required tags (e.g., CostCenter and Environment). This enforces compliance at the moment of deployment, blocking non-compliant resources from being provisioned by Azure DevOps pipelines. Option D is correct because adding a pipeline task (using Azure CLI or PowerShell) after resource creation programmatically applies the required tags, ensuring resources are tagged even if the initial deployment omitted them.

Want more Develop a security and compliance plan practice?

Practice this domain
5

Domain 5: Implement an instrumentation strategy

All Implement an instrumentation strategy questions
Q1
easyFull explanation →

You are configuring Application Insights for a .NET Core web application deployed to Azure App Service. The application must capture telemetry for all HTTP requests, exceptions, and dependency calls with minimal code changes. What should you do?

A

Enable the Application Insights site extension in the App Service 'Application Insights' blade.

The site extension enables auto-instrumentation with no code changes.

B

Configure diagnostics logging in the App Service and stream logs to Application Insights.

C

Install the Microsoft.ApplicationInsights.AspNetCore NuGet package and add services.AddApplicationInsightsTelemetry() in Startup.cs.

D

Add the Application Insights JavaScript SDK to each page.

Why: Option A is correct because enabling the Application Insights site extension via the App Service 'Application Insights' blade automatically instruments the .NET Core application without requiring any code changes. This extension injects the necessary telemetry modules to capture HTTP requests, exceptions, and dependency calls at the runtime level, leveraging the Azure App Service integration for zero-code instrumentation.
Q2
mediumFull explanation →

Your team uses Azure DevOps for CI/CD. You need to ensure that every build publishes telemetry to Application Insights, including build duration, test pass rate, and deployment frequency. Which approach should you use?

A

Call the Azure DevOps REST API from a custom script in the pipeline to capture telemetry.

B

Run the Azure DevOps CLI command 'az devops telemetry publish' in a build task.

C

Use the built-in 'Pipeline Telemetry' dashboard in Azure DevOps.

D

Use the Azure DevOps Analytics OData endpoint to query pipeline telemetry and send to Application Insights via a release task.

OData provides structured telemetry data that can be streamed.

Why: Option D is correct because the Azure DevOps Analytics OData endpoint provides a standardized, queryable interface to pipeline telemetry data (build duration, test pass rate, deployment frequency). By using a release task to query this endpoint and forward the data to Application Insights, you can instrument your CI/CD pipeline to send custom telemetry without relying on manual scripting or unsupported commands. This approach aligns with the 'Implement an instrumentation strategy' domain by leveraging Azure DevOps Analytics and Application Insights integration.
Q3
hardFull explanation →

You are designing a centralized logging strategy for multiple microservices hosted in Azure Kubernetes Service (AKS). Each microservice writes logs in JSON format to stdout/stderr. The operations team needs to query logs across all services and correlate them with application performance metrics. Which solution provides the best integration?

A

Configure AKS to send logs to Azure Blob Storage and use Azure Storage Analytics for querying.

B

Enable Container Insights in Azure Monitor to collect stdout/stderr logs and metrics into a Log Analytics workspace.

Container Insights provides integrated log and metric collection with querying via KQL.

C

Stream logs to Azure Event Hubs and then to Azure Data Explorer for analysis.

D

Deploy the Application Insights agent as a DaemonSet in AKS and send logs directly to Application Insights.

Why: Container Insights in Azure Monitor is the best solution because it natively collects stdout/stderr logs from AKS containers and correlates them with performance metrics (CPU, memory, disk, network) in a single Log Analytics workspace. This enables the operations team to query logs across all microservices using KQL and join them with metrics for end-to-end troubleshooting, without additional infrastructure or data movement.
Q4
mediumFull explanation →

You have an Azure DevOps pipeline that deploys a web app to Azure App Service. You want to capture deployment frequency and change failure rate as metrics in Application Insights. Which built-in analytics view should you use?

A

Deployment Frequency

It provides the requested metrics.

B

Application Dashboard

C

Time to Restore Service

D

Azure DevOps Pipeline Telemetry

Why: The Deployment Frequency analytics view in Application Insights is specifically designed to track how often deployments occur and the rate at which they fail, directly aligning with the goal of capturing deployment frequency and change failure rate. This view leverages data from Azure DevOps pipelines to provide these metrics without requiring custom queries or additional instrumentation.
Q5
hardFull explanation →

You are troubleshooting an intermittent performance issue in a web application. Application Insights shows a high number of failed dependency calls to Azure SQL Database. The errors are SqlException with error code -2 (timeout). What is the most likely cause and recommended fix?

A

The application is exhausting the connection pool; increase Max Pool Size in the connection string.

Timeouts often indicate pool exhaustion.

B

The SQL Server firewall is blocking the application IP; add a firewall rule.

C

The database is experiencing deadlocks; enable read committed snapshot isolation.

D

The database DTU limit is being exceeded; scale up the service tier.

Why: A is correct because SqlException with error code -2 indicates a connection timeout, which in a high-traffic scenario is most commonly caused by the application exhausting the connection pool. When all connections in the pool are in use and the wait time for a free connection exceeds the Connect Timeout (default 15 seconds), new requests fail with this error. Increasing Max Pool Size in the connection string (e.g., Max Pool Size=200) allows more concurrent connections, reducing contention.
Q6
easyFull explanation →

Which TWO metrics should you monitor to evaluate the reliability of a web application according to the DORA metrics?

A

Lead Time for Changes

B

Change Failure Rate

Measures how often deployments cause failures.

C

Mean Time to Restore (MTTR)

Measures how quickly you recover from failures.

D

CPU Usage

E

Deployment Frequency

Why: The DORA metrics define four key measures for software delivery performance: Deployment Frequency, Lead Time for Changes, Mean Time to Restore (MTTR), and Change Failure Rate. For evaluating the reliability of a web application, the two most directly relevant metrics are Change Failure Rate (B), which measures the percentage of deployments causing a failure in production, and Mean Time to Restore (MTTR) (C), which measures the time it takes to recover from a failure. These two metrics directly quantify stability and resilience, whereas Deployment Frequency and Lead Time for Changes focus on throughput and speed.

Want more Implement an instrumentation strategy practice?

Practice this domain
6

Domain 6: Design and implement a DevOps infrastructure

All Design and implement a DevOps infrastructure questions
Q1
easyFull explanation →

A team wants to enforce that all Azure resource groups in a subscription are tagged with 'CostCenter' and 'Environment'. They need a solution that automatically applies these tags to any new resource group and ensures compliance without manual intervention. What should they use?

A

Azure Policy

Azure Policy can enforce tagging rules via 'deny' or 'append' effects on resource groups.

B

Azure RBAC

C

Azure Blueprints

D

Azure Resource Graph

Why: Azure Policy is the correct choice because it allows you to define and enforce tagging rules at scale. By creating a policy that requires 'CostCenter' and 'Environment' tags on resource groups, and setting the policy effect to 'deny' or 'append' (to automatically add missing tags), any new resource group creation that violates the policy is blocked or automatically remediated, ensuring compliance without manual intervention.
Q2
mediumFull explanation →

A company uses Azure DevOps for CI/CD. They have multiple pipelines that deploy to different environments. They want to ensure that secrets like API keys are not exposed in pipeline logs. What is the best approach?

A

Use Azure App Configuration with Key Vault references

B

Create a Variable Group linked to Azure Key Vault

Variable Groups linked to Key Vault ensure secrets are never stored in the pipeline and are fetched at runtime.

C

Use Azure Kubernetes Service secrets

D

Use pipeline variables marked as 'secret'

Why: Option C is correct because Variable Groups linked to Azure Key Vault securely store secrets and can be referenced in pipelines without exposing values. Option A is wrong because pipeline variables can be set as secret but still need secure storage. Option B is wrong because Azure App Configuration can store secrets but is less integrated for secret management. Option D is wrong because environment secrets are for Kubernetes, not general pipeline secrets.
Q3
hardFull explanation →

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?

A

Cache the NuGet packages and enable caching in the pipeline

Caching packages reduces the need to download them every build, significantly reducing build time.

B

Use parallel jobs in the pipeline

C

Use a self-hosted agent with more CPU

D

Enable incremental builds

Why: 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.
Q4
easyFull explanation →

A team wants to automatically destroy a temporary test environment after a pull request is merged or closed. What Azure DevOps feature should they use?

A

Environment with post-deployment approvals

Post-deployment approvals can trigger a cleanup job when the environment is no longer needed.

B

Branch policy with required reviewers

C

Pipeline trigger on branch deletion

D

Service hook to Azure Functions

Why: Option A is correct because Azure DevOps Environments support post-deployment approvals and can be configured with a deployment job that automatically triggers resource cleanup when a pull request is merged or closed. By defining a 'destroy' job in the YAML pipeline that runs only on the 'post-deployment' trigger of an environment, the team can tear down the temporary test environment without manual intervention.
Q5
mediumFull explanation →

A company uses Azure Pipelines to deploy a web app to Azure App Service. They want to ensure that the deployment is first validated in a staging slot before swapping to production. What should they configure?

A

Create two separate pipelines for staging and production

B

Use Azure Traffic Manager to route traffic

C

Use deployment slots in the App Service and configure auto-swap

Deployment slots with auto-swap allow validation in staging and then swap to production.

D

Use an App Service plan with multiple instances

Why: Option C is correct because Azure App Service deployment slots allow you to deploy a web app to a staging slot, validate it, and then swap it to production with zero downtime. Auto-swap automates this process by swapping the staging slot into production after a successful deployment, ensuring validation occurs before the production slot receives the new code.
Q6
hardFull explanation →

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?

A

Store the state file in an Azure Storage account with state locking enabled

Azure Storage provides remote state with leasing for locking, ensuring consistency.

B

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

C

Store the state file in Terraform Cloud

D

Store the state file in a Git repository with manual locking

Why: 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.

Want more Design and implement a DevOps infrastructure practice?

Practice this domain
7

Domain 7: Design and implement a source control strategy

All Design and implement a source control strategy questions
Q1
mediumFull explanation →

Your team uses a monorepo in Azure Repos with multiple feature branches. You notice that merge conflicts frequently occur because developers are working on the same files. You want to reduce conflicts and improve collaboration. Which branching strategy should you recommend?

A

Use release branches for each deployment and cherry-pick commits from main.

B

Use trunk-based development with feature flags to merge small, frequent changes.

Short-lived branches and feature flags reduce conflicts.

C

Use a single main branch and require all changes to be committed directly.

D

Use GitFlow with separate develop and release branches.

Why: Option C is correct because feature flags allow developers to merge incomplete features into the main branch without affecting users, reducing long-lived branches and conflicts. Option A is wrong because GitFlow has long-lived branches that increase conflict risk. Option B is wrong because trunk-based development with short-lived branches is the recommended approach. Option D is wrong because release branches do not reduce conflicts on the main branch.
Q2
hardFull explanation →

Your company is migrating from TFVC to Git in Azure Repos. The repository contains a large number of binary files (e.g., .dll, .exe) that are frequently updated. You need to minimize repository size and clone time. What should you include in your migration plan?

A

Perform a shallow clone of the last commit only.

B

Use Git LFS to track binary files.

Git LFS replaces large files with pointers, keeping the repo lean.

C

Use sparse checkout to exclude binary files from the working tree.

D

Use TFVC to Git converter with default settings.

Why: Option B is correct because Git LFS (Large File Storage) replaces large binary files in the repository with lightweight text pointers, storing the actual binary content in external storage. This prevents the repository from bloating with frequently updated binaries, reducing clone time and repository size since only the pointers are cloned.
Q3
easyFull explanation →

You have a GitHub repository with a GitHub Actions workflow that builds a .NET application. The workflow should only run when changes are pushed to the main branch, but it currently runs on every push to any branch. How should you fix the workflow trigger?

A

Add 'on: push: branch: [main]' to the workflow.

B

Add 'on: push: paths: [main]' to the workflow.

C

Add 'on: pull_request: branches: [main]' to the workflow.

D

Add 'on: push: branches: [main]' to the workflow.

This restricts the trigger to pushes on main.

Why: Option D is correct because the GitHub Actions workflow syntax to restrict a push trigger to a specific branch uses `on: push: branches: [main]`. This ensures the workflow only executes when commits are pushed to the main branch, not on pushes to any other branch.
Q4
mediumFull explanation →

You are reviewing a webhook payload from Azure Repos. The payload indicates that a new branch named 'feature-123' was created. Which event type triggered this webhook?

A

A new branch creation.

All zeros in 'before' indicates a new branch.

B

A push to an existing branch.

C

A branch deletion.

D

A pull request update.

Why: The webhook payload explicitly indicates that a new branch named 'feature-123' was created. In Azure Repos, the event type that corresponds to this action is 'New branch creation' (also known as 'Push' with a new ref). This event fires when a new branch reference is pushed to the remote repository, which is exactly what happened here.
Q5
hardFull explanation →

You see the above git log output. The team has a policy requiring linear history on the main branch. Which command should be used next time to integrate the feature branch?

A

git merge --squash feature/login

B

git cherry-pick f4e5d6c a7b8c9d

C

git merge --no-ff feature/login

D

git rebase main feature/login then git merge --ff-only

Rebase creates linear history; fast-forward merge preserves it.

Why: Option D is correct because the team requires a linear history on the main branch. By first rebasing the feature branch onto main (`git rebase main feature/login`), you reapply the feature commits on top of the latest main commit, creating a clean, linear sequence. Then `git merge --ff-only` performs a fast-forward merge, which simply moves the main branch pointer forward without creating a merge commit, preserving the linear history policy.
Q6
easyFull explanation →

Your team uses GitHub and wants to enforce that all commits to the main branch are signed with a GPG key. Which branch protection rule should you configure?

A

Require pull request reviews before merging.

B

Require status checks to pass before merging.

C

Require linear history.

D

Require signed commits.

Enforces GPG or S/MIME signing on every commit.

Why: Option D is correct because the 'Require signed commits' branch protection rule enforces that every commit pushed to the protected branch must be signed with a GPG key. This ensures cryptographic verification of the commit author's identity, directly addressing the requirement to enforce signed commits on the main branch.

Want more Design and implement a source control strategy practice?

Practice this domain

Frequently asked questions

How many questions are on the AZ-400 exam?

The AZ-400 exam has 50 questions and must be completed in 120 minutes. The passing score is 700/1000.

What types of questions appear on the AZ-400 exam?

Scenario-based questions covering exam objectives with detailed answer explanations.

How are AZ-400 questions organised by domain?

The exam covers 7 domains: Configure processes and communications, Design and implement source control, Design and implement build and release pipelines, Develop a security and compliance plan, Implement an instrumentation strategy, Design and implement a DevOps infrastructure, Design and implement a source control strategy. Questions are weighted by domain — higher-weight domains appear more on your actual exam.

Are these the actual AZ-400 exam questions?

No. These are original exam-style practice questions written against the official Microsoft AZ-400 exam objectives. They are not copied from the real exam. Courseiva focuses on genuine understanding, not memorisation of braindumps.

Ready to practice all 60 AZ-400 questions?

Courseiva tracks your accuracy per domain and routes you toward weak areas automatically. Free, no account required.

Browse all AZ-400 questionsTake a timed practice test