Reinforce AZ-400 concepts with active-recall study cards covering all 6 blueprint domains. Each card shows the question on the front and the correct answer with a full explanation on the back.
Flashcards work through active recall — the process of retrieving information from memory rather than passively re-reading it. Research consistently shows that active recall produces stronger, longer-lasting memory than re-reading study guides. For AZ-400 preparation, this means flashcards are one of the highest-return study tools available.
Attempt recall first
Read the AZ-400 question on each card, pause, and attempt to formulate the answer in your own words before revealing. This retrieval attempt — even if wrong — dramatically strengthens memory compared to immediately reading the answer.
Review wrong cards again
When you get a card wrong, note it and add it back to your review pile. Spaced repetition — seeing difficult cards more frequently — is the mechanism that makes flashcard study far more efficient than linear reading.
Study by domain
Group your AZ-400 flashcard sessions by domain for the first 3–4 weeks. Master one domain before moving to the next. In the final week, shuffle all cards together to test cross-domain recall — which is what the real AZ-400 exam requires.
Short sessions beat marathon reviews
20–30 flashcard cards per session, done daily, produces better retention than a single 200-card marathon session. Five short daily sessions per week over 4 weeks gives you over 400 total card reviews — enough to reliably pass AZ-400.
Sample cards from the AZ-400 flashcard bank. Read the question, think of the answer, then read the explanation below.
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?
Add a work item rule in the process template to require a code review for the 'Done' transition.
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.
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?
The subscription's 'Deliver to' filter excludes stakeholders.
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.
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?
Use a build validation policy to check commit messages
The 'Require a work item linking policy' in Azure Repos ensures each pull request is linked to a work item, but it does not validate that each commit message contains a reference. To enforce that commit messages themselves reference an Azure Boards work item, a build validation policy can run a script to verify the commit message format. Therefore, option D is the correct choice.
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?
Create an Azure Pipeline decorator that validates the service connection used in each task and fails the pipeline if it is not the approved one.
Azure Pipeline decorators inject custom validation logic at runtime, allowing you to inspect each task's service connection and fail the pipeline if it does not match the approved one. This enforces the security requirement centrally without relying on developer compliance or manual gates.
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?
The build service identity does not have Get and List permissions on the Key Vault secrets.
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.
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?
Enable the Application Insights site extension in the App Service 'Application Insights' blade.
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.
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?
The 'Take App Offline' setting is not enabled in the deployment task.
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.
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?
Create individual build pipelines for each service, and a separate release pipeline that deploys all services to an integration environment for testing.
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.
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?
Use path filters in the trigger section to exclude 'docs/*' and '*.md' files.
Path filters in the trigger section allow you to specify include and exclude patterns. By using exclude patterns for 'docs/*' and '*.md', the pipeline will not trigger when only documentation files are changed. Option B is incorrect because branch policies do not affect the pipeline trigger; they govern pull request requirements. Option C is incorrect because conditions are evaluated at runtime, whereas we want to avoid triggering the pipeline altogether. Option D is incorrect because disabling CI trigger would require manual or scheduled builds, which is less efficient than using path filters.
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?
Use a release pipeline that deploys to a new Azure App Service instance, runs tests, and then removes the instance.
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.
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?
The policy audits the pipeline but does not enforce any mandatory reviewers.
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.
Your company has a large monorepo with multiple microservices. You have a single YAML-based Azure Pipeline that builds the entire solution on every commit to the main branch. The pipeline takes over an hour to complete, causing long feedback loops. Developers often submit changes to only one service, but the whole pipeline runs. You need to reduce build time while maintaining quality. You are considering splitting the pipeline into multiple pipelines, each for a service, and using path triggers. However, some services have dependencies on shared libraries that are updated infrequently. You also need to ensure that integration tests that span multiple services still run when necessary. What should you do?
Create separate pipelines for each service with path triggers, and create an additional comprehensive pipeline that triggers only when shared libraries change.
It uses path triggers to run only the pipeline for the changed service, drastically reducing build time. The additional comprehensive pipeline, triggered only when shared libraries change, ensures that integration tests spanning multiple services still run when dependencies are updated, maintaining quality.
You have a multi-stage YAML pipeline that deploys to Azure Kubernetes Service (AKS). The pipeline uses a deployment job with a strategy of 'runOnce'. You need to ensure that if the deployment fails, the pipeline automatically redeploys the previous successful version. Which strategy should you use instead?
Use the 'runOnce' strategy with a rollback task
The requirement can be met by adding a rollback task to the existing 'runOnce' strategy. When a deployment fails, the rollback task can automatically redeploy the previous successful version. Option A requires manual intervention, which contradicts the 'automatically' requirement. Option B uses invalid syntax ('on:failure: always')—the correct hook is 'on: failure: rollback'—and option C's automatic swap does not revert the deployment on failure.
You are designing a build pipeline that produces a NuGet package. The pipeline must conditionally sign the assembly only when the build is triggered by a tag starting with 'v' (e.g., v1.0.0). The pipeline uses a script task that signs the assembly. Which expression should you use in the condition of the script task?
and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/tags/v'))
The condition uses `startsWith(variables['Build.SourceBranch'], 'refs/tags/v')` to check if the build was triggered by a tag whose full Git ref starts with `refs/tags/v`. This ensures the signing script runs only when the source branch is a tag reference matching the 'v' prefix, which is the standard way to identify version tags in Azure Pipelines. The `and(succeeded(), ...)` wrapper guarantees the previous tasks completed successfully before signing.
You have a YAML pipeline that deploys to multiple environments. The pipeline uses environment approvals. You need to ensure that the pipeline waits for manual approval before deploying to the production environment. The production environment is named 'Production'. Which configuration should you add to the deployment job?
Add 'environment: Production' to the deployment job and configure approvals on the environment in the Azure DevOps portal
Environment approvals in Azure DevOps are configured on the environment resource itself, not in the pipeline YAML. By adding 'environment: Production' to the deployment job, the pipeline references the environment, and the manual approval gate is enforced by the approvals configured on that environment in the Azure DevOps portal. This ensures the pipeline waits for approval before proceeding to the production deployment job.
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?
Use trunk-based development with feature flags to merge small, frequent changes.
Trunk-based development with feature flags is the correct approach because it encourages developers to merge small, frequent changes into the main branch, reducing the surface area for conflicts. Feature flags allow incomplete features to be hidden in production, enabling continuous integration without requiring long-lived feature branches. This strategy directly addresses the problem of frequent merge conflicts by minimizing divergence between branches.
The AZ-400 flashcard bank covers all 6 official blueprint domains published by Microsoft. Cards are distributed proportionally, so domains with higher exam weight have more cards.
Domain Coverage
Configure processes and communications
Design and implement source control
Develop a security and compliance plan
Implement an instrumentation strategy
Design and implement build and release pipelines
Design and implement a source control strategy
Both flashcards and practice questions are evidence-based study tools. The difference is in what they train:
Flashcards — concept retention
Best for memorising definitions, acronyms, protocol behaviours, command syntax, and conceptual distinctions. Use flashcards to build the foundational vocabulary that AZ-400 questions assume you know.
Best in: weeks 1–3
Practice tests — application
Best for applying concepts to realistic scenarios, eliminating distractors, and building exam stamina.AZ-400 questions test scenario reasoning — not just recall — so practice tests are essential.
Best in: weeks 3–6
The most effective AZ-400 study plan combines both: use flashcards for the first 2–3 weeks to build conceptual foundations, then shift to practice tests and mock exams in the final 2–3 weeks to apply and benchmark that knowledge. Most candidates who pass on their first attempt use both tools.
Yes. Courseiva provides free AZ-400 flashcards across all official exam domains. Every card includes the correct answer and a full explanation of why it is right and why the distractors are wrong. The platform also includes topic-based practice, mock exams, and readiness tracking — no account required.
Courseiva has 823+ original AZ-400 flashcards across all 6 exam blueprint domains. New cards are added regularly as the question bank grows. All cards are written by certified engineers against the official Microsoft exam objectives.
Courseiva flashcards are purpose-built for IT certification exams. Unlike generic flashcard platforms where content quality varies, every Courseiva card is mapped to the official AZ-400 exam blueprint, written by engineers who hold the certification, and includes a full explanation of the correct answer and why the distractors are wrong. This explanation quality is what separates genuine learning from rote memorisation.
Courseiva is a web platform — an internet connection is required. For offline study, we recommend creating free Courseiva account, using the platform in your browser, and using your device's offline capabilities if your browser supports offline web apps.
Save your results, see which domains need more work, and get spaced repetition recommendations — all free.
Sign Up FreeFree forever · Every certification included