Multi-Service Tradeoff — Azure DevOps Engineer (AZ-400)
Managed vs. Orchestrated: What the Scenario Is Really Asking
AZ-400 scenarios frame container workload questions around team capability, scaling granularity, and operational budget—not raw compute power. When the scenario mentions a small team with no Kubernetes expertise, that phrase eliminates AKS regardless of scale requirements. When it says "event-driven" or "short-lived execution," Azure Functions moves ahead of Azure Container Instances. The service capabilities are not in dispute; the constraint that disqualifies the alternatives is what the question is testing.
What This Pattern Tests
Azure offers three messaging services with distinct models. Service Bus handles enterprise messaging with sessions, dead-lettering, and exactly-once delivery at $0.05 per million operations. Event Grid handles reactive event routing with push delivery at $0.60 per million events. Queue Storage handles simple FIFO queueing at $0.004 per 10,000 transactions. The exam gives you a messaging requirement and tests whether you match it: "order processing with dead-letter handling" = Service Bus, "react to blob uploads" = Event Grid, "simple task queue for background workers" = Queue Storage. Cosmos DB vs. SQL Database vs. Table Storage follows the same principle: global multi-model vs. relational with joins vs. simple key-value.
Decision Axis
Message complexity and delivery model determine service. Over-specifying is as wrong as under-specifying.
Associated Traps
Decision Rules
Does the proposed integration maintain an unbroken traceability chain covering all four segments — work item → commit, commit → build, build → artifact, artifact → deployment — or does it satisfy only the work-item-to-commit segment while leaving the build-to-deployment link unrecorded in Azure Boards?
Whether the proposed integration closes the full traceability chain through build-artifact tagging and deployment-event annotation (zero traceability-gap requirement met) or only establishes commit-to-work-item references (partial chain that satisfies fast lookup but leaves the build-to-deployment segment unlinked and fails the audit).
Whether the clone-time bottleneck is driven by large binary blob size (requiring Git LFS to offload blobs to a separate store) or by repository tree depth and history size (requiring Scalar or partial-clone optimizations) — the answer must match the optimization target to the stated root cause.
Select Git LFS (binary blob offload) over Scalar (sparse-checkout and commit-graph acceleration for large trees) when measured clone latency is caused by large binary file sizes rather than deep commit history or wide directory trees — the bottleneck type must be matched to the tool's optimization target before a solution is chosen.
Whether the dominant clone-time bottleneck is large individual binary blobs — solved by enabling Git LFS to replace those files with pointer files in the standard clone path — or working-directory tree depth and file count — solved by Scalar with sparse-checkout — and therefore which feature combination should be configured on the Azure Repos repository.
Whether to use feed views within a single Azure Artifacts feed for environment-scoped promotion, or create separate Azure Artifacts feeds per environment — the dominant constraint is version-immutability combined with minimizing feed management overhead.
Whether to enable upstream sources on the feed containing internal packages (near-right: unified resolution but opens dependency confusion surface) versus enforcing feed-scope-separation with a dedicated internal-only feed and a separate upstream-proxy feed, with Dependabot monitoring the proxy feed.
Whether GitHub Packages or Azure Artifacts is the correct registry when the scenario explicitly requires upstream source proxying — GitHub Packages cannot proxy public registries as upstream sources, making Azure Artifacts the only viable choice despite sitting outside the GitHub-native toolchain.
Distinguish between retention duration (preventing deletion after a time window, analogous to RTO recovery capability) and version immutability (preventing overwrite of a published version, analogous to RPO write-protection); only immutable publishing satisfies the bit-for-bit identical audit constraint because retention policies cannot block a version from being overwritten before any deletion window is evaluated.
Domain Coverage
Difficulty Breakdown