Azure PipelinesGitHub Actions
#1Both are CI/CD pipeline platforms and Microsoft owns both, so candidates treat them as equivalent.
Deciding signal
Azure Pipelines is the CI/CD service within Azure DevOps — it supports YAML pipelines, classic editor pipelines, deployment to Azure and non-Azure targets, environments, gates, and approvals. It integrates with Azure Boards, Repos, and Artifacts. GitHub Actions is GitHub-native CI/CD — workflows are defined in YAML in the repository and triggered by GitHub events (push, PR, release). Actions has a marketplace of community actions and integrates tightly with the GitHub ecosystem. The exam tests whether candidates recognize that if the source code is in GitHub Repos and the team uses GitHub for project management, GitHub Actions is the native choice. If the team is fully in Azure DevOps, Pipelines is the answer. They can also work together.
Quick check
Is the code repository and team workflow primarily in Azure DevOps (Azure Pipelines), or in GitHub (GitHub Actions)?
Why it looks right
Azure Pipelines is the more prominent enterprise CI/CD answer. GitHub Actions is correct when the scenario explicitly places code in GitHub Repos and describes GitHub-native automation.
Azure ReposGitHubAzure Artifacts
#2Azure Repos and GitHub are both Git hosting platforms under Microsoft, and Artifacts sounds like it could be a source repository.
Deciding signal
Azure Repos is Git (and TFVC) repository hosting within Azure DevOps. GitHub is Microsoft-owned Git hosting with pull requests, code review, Actions, and Packages — it is the world-facing developer platform. Azure Artifacts is a package feed service within Azure DevOps — it hosts Maven, npm, NuGet, Python, and Universal packages for sharing within an organization. It is not a source code repository. When the scenario involves hosting and sharing library packages internally, Azure Artifacts. When it involves source code and version control within Azure DevOps, Azure Repos. When it involves the GitHub platform specifically, GitHub.
Quick check
Is this source code version control within Azure DevOps (Azure Repos), source code hosting on GitHub (GitHub), or storing and sharing software packages internally (Azure Artifacts)?
Why it looks right
Azure Artifacts sounds like it stores build artifacts — which it does, but in the form of versioned packages (npm, NuGet), not generic binary files. S3/Azure Blob is for generic binary artifacts between pipeline stages.
ARM TemplatesBicepTerraformPulumi
#3All four deploy Azure infrastructure as code, so candidates apply Terraform as the default modern answer.
Deciding signal
ARM Templates are Azure-native JSON — verbose, explicit, and directly consumed by the Azure Resource Manager. Bicep is a domain-specific language that compiles to ARM Templates, with significantly cleaner syntax and first-party Microsoft support — it is the recommended Azure-native IaC tool replacing raw ARM JSON. Terraform is HashiCorp HCL-based, multi-cloud, with a large provider ecosystem and state management — the right answer when the team manages infrastructure across multiple clouds or has an existing Terraform workflow. Pulumi uses general-purpose languages (TypeScript, Python, Go) to define infrastructure — suited for teams that prefer programming language expressiveness over DSL. On AZ-400, Bicep is often the correct answer for Azure-native IaC when ARM JSON verbosity is cited as the problem.
Quick check
Is this Azure-native IaC with clean syntax (Bicep), raw Azure JSON templates (ARM), multi-cloud HCL infrastructure management (Terraform), or infrastructure in a general-purpose programming language (Pulumi)?
Why it looks right
Terraform is the modern IaC default and candidates apply it to all infrastructure-as-code scenarios. Bicep is the correct Azure-native answer when the scenario describes improving ARM Template maintainability without adding multi-cloud complexity.
Azure MonitorApplication InsightsLog Analytics
#4All three appear under the Azure Monitor umbrella, so candidates treat them as the same thing.
Deciding signal
Azure Monitor is the collection platform — it ingests metrics and logs from Azure resources and routes them to downstream tools. Log Analytics is a workspace where logs are stored and queried with KQL — it aggregates infrastructure logs, activity logs, and custom logs from agents. Application Insights is an APM tool specifically for application-level telemetry: request rates, response times, dependency calls, exceptions, custom events, and user behavior. On AZ-400, the exam tests whether candidates can identify that Application Insights is the correct tool for instrumenting a .NET or Node.js application to track performance and exceptions — not Log Analytics, which is for infrastructure-level log queries.
Quick check
Is this the platform collecting and routing all Azure logs (Monitor), querying infrastructure and platform logs with KQL (Log Analytics), or instrumenting applications to capture performance traces, exceptions, and user behavior (Application Insights)?
Why it looks right
Log Analytics is the visible query surface and candidates apply it to application performance monitoring. Application Insights is specifically for APM — it has SDK instrumentation, distributed tracing, and user behavior analytics that Log Analytics does not provide.
Azure App ConfigurationAzure Key Vault
#5Both store configuration values, so candidates apply Key Vault to all "store application settings" questions.
Deciding signal
Key Vault is designed for sensitive values — secrets, encryption keys, and TLS certificates. It provides access control, auditing, automatic rotation for secrets, and HSM-backed keys. It is not designed for non-sensitive configuration or feature flags. App Configuration is a managed service for application settings and feature flags — it stores key-value pairs with labeling, environment-based configuration, and a feature management library for controlling feature rollout. App Configuration references Key Vault secrets rather than storing them directly. When the scenario describes managing feature flags for A/B testing or gradual rollout, App Configuration. When it describes storing database passwords or API keys securely, Key Vault.
Quick check
Is this managing application settings, configuration, and feature flags (App Configuration), or storing sensitive secrets, encryption keys, and certificates (Key Vault)?
Why it looks right
Key Vault is the default secrets answer and candidates extend it to feature flag scenarios. App Configuration is specifically correct for feature flag management and non-sensitive configuration — a distinct use case.
Blue/GreenCanaryRollingFeature Flags
#6All four reduce deployment risk, so candidates conflate them when a question describes gradual rollout.
Deciding signal
Blue/Green deploys a full new environment in parallel with the old one, then switches all traffic at once — fast rollback by switching back. Canary routes a small percentage of traffic to the new version (e.g., 5% of users), validates metrics, then gradually increases — traffic-based gradual rollout. Rolling replaces instances of the old version with the new version incrementally — some instances run the new version while others run the old. Feature Flags enable or disable specific features in code without deploying new code — the same binary is deployed to all environments and users see different behavior based on flag state. When the scenario involves risk reduction through incremental traffic shifting, Canary. When it involves toggling features without deployment, Feature Flags.
Quick check
Is this swapping two complete environments (Blue/Green), routing a percentage of traffic to the new version (Canary), replacing instances incrementally (Rolling), or toggling a feature in code without a new deployment (Feature Flags)?
Why it looks right
Blue/Green is the default "zero-downtime deployment" answer. Feature Flags are the correct answer when the scenario specifically involves enabling or disabling a feature for a subset of users without deploying a new version.
Azure Load TestingAzure Chaos Studio
#7Both test application behavior under stress, so candidates treat them as interchangeable resilience testing tools.
Deciding signal
Azure Load Testing generates synthetic traffic to measure application performance — it runs Apache JMeter scripts or URL-based tests and measures response times, throughput, and error rates under defined load. It answers "how does the application perform under N concurrent users?" Azure Chaos Studio injects controlled faults into Azure resources — killing VMs, adding network latency, stopping processes — to validate that the application recovers correctly. It answers "does the application tolerate this failure mode?" Load Testing is for performance capacity; Chaos Studio is for fault tolerance validation.
Quick check
Is the goal to measure application performance and find bottlenecks under user load (Load Testing), or to validate that the application recovers from infrastructure failures (Chaos Studio)?
Why it looks right
Both are described as "stress testing" tools. Chaos Studio is correct when the scenario involves injecting specific failure conditions to verify resilience — not simulating user load.
Azure Container RegistryDocker HubGitHub Packages
#8All three store container images, so candidates default to Docker Hub as the familiar answer.
Deciding signal
Docker Hub is the default public container registry — it is where public base images (nginx, node, python) are hosted. It is the wrong answer when the scenario requires private image storage within Azure. Azure Container Registry (ACR) is a private, Azure-native container registry with RBAC integration, geo-replication, tasks for automated image builds, and private link support. It is the right answer for enterprise container pipelines in Azure. GitHub Packages is a GitHub-native registry for container images (and npm, Maven, NuGet packages) — it is the right answer when the container images are built and consumed within a GitHub Actions pipeline and the team prefers keeping everything in GitHub.
Quick check
Is this a private container image registry within Azure for enterprise pipelines (ACR), the default public registry for community base images (Docker Hub), or a container registry integrated with GitHub Actions (GitHub Packages)?
Why it looks right
Docker Hub is the familiar default. ACR is the correct answer for any scenario describing private image storage in Azure DevOps or Azure Pipelines workflows.
App Service Deployment SlotsAzure Traffic ManagerAzure Front Door
#9All three can route traffic to different versions of an application, so candidates conflate staging with global distribution.
Deciding signal
Deployment Slots are staging environments within an Azure App Service — you deploy to a staging slot, test, and then swap it with the production slot (zero-downtime swap). Slots are in the same region on the same App Service plan. Traffic Manager uses DNS to route users to different regional App Service apps — it does not operate within a single app; it routes between separately deployed apps in different regions. Front Door is a global HTTP proxy with routing, WAF, and CDN — it provides routing between backends with health-based failover globally. When the scenario describes testing a new release before promoting it to production in the same region, Deployment Slots. When it describes routing between regional deployments globally, Traffic Manager or Front Door.
Quick check
Is this testing a new release in a staging environment before swapping to production in the same region (Deployment Slots), DNS-based routing between regional apps (Traffic Manager), or global HTTP proxying with WAF and CDN (Front Door)?
Why it looks right
Traffic Manager is applied to staging scenarios where Deployment Slots are the simpler, more appropriate answer. Deployment Slots are specific to App Service and provide zero-downtime swap without requiring separate DNS routing.
Azure DevTest LabsMicrosoft Dev BoxAzure Sandbox Subscriptions
#10All three provide environments for development and testing without production overhead.
Deciding signal
DevTest Labs is an Azure service for creating cost-controlled VM environments for development and testing — it supports auto-shutdown, reusable formulas, artifact galleries, and spending caps. Best for teams that need configurable VM-based development or testing labs at scale. Microsoft Dev Box provides cloud-based Windows developer workstations — managed, pre-configured development machines that developers access remotely via browser or client. Best for teams that want developers to work from cloud PCs without managing local hardware. Azure Sandbox Subscriptions (or Azure Sandbox environments via Microsoft Learn or internal isolation) provide isolated subscription-level environments for experimentation without affecting production. When the scenario describes giving developers managed cloud PCs, Dev Box. Cost-controlled VM-based test environments, DevTest Labs.
Quick check
Is this cost-controlled VM-based development and test labs (DevTest Labs), managed cloud developer workstations for remote development (Dev Box), or isolated subscription environments for safe experimentation (Sandbox)?
Why it looks right
DevTest Labs is the established dev environment service. Dev Box is the correct answer when the scenario describes cloud-hosted developer workstations — a newer concept that candidates sometimes miss.
10 AZ-400 questions. Pattern-tagged with trap analysis. Free, no signup required.
Start AZ-400 Mini-Trainer →