Scope Overreach — Azure DevOps Engineer (AZ-400)
You solved a broader problem than what was asked. The scenario had specific constraints — you addressed requirements that weren't there.
When the Simpler Answer Is the Correct Answer
Requirement: automate infrastructure deployment for a single-team project with a six-week deadline. Competing choices: a full Azure Landing Zone with management group hierarchy, or Bicep modules deployed from an Azure DevOps pipeline. The deciding constraint is scope—Landing Zones govern multi-subscription estates, not single-team workloads. Choosing the more powerful tool fails not because it is wrong in general, but because the scenario does not justify its footprint.
The Scenario
A team needs to restrict access to a Storage Account so only resources in their virtual network can reach it. You design Azure Private Link for private IP connectivity, Azure Firewall for traffic inspection, and Network Security Groups for subnet-level filtering. The correct answer is enabling a Service Endpoint on the VNet subnet and adding a network rule on the Storage Account to allow only that VNet. The scenario said "restrict to VNet" — not "implement zero-trust network architecture." Service Endpoints are free, require no DNS changes, and take 30 seconds to configure.
How to Spot It
- •Azure Service Endpoints vs. Private Endpoints is the most common scope overreach test. Service Endpoints (free, VNet-scoped access restriction) are correct when you just need to limit network access. Private Endpoints ($0.01/hour, private IP in your VNet) are correct when you need private IP addressing, on-premises access via VPN/ExpressRoute, or cross-region private connectivity.
- •Azure Firewall costs ~$912/month base. If the scenario does not mention traffic inspection, threat intelligence, or centralized network security policy, adding Azure Firewall is scope overreach.
- •The exam tests whether you solve exactly the stated problem. If your answer addresses security threats, compliance requirements, or scaling concerns the scenario never mentioned, you have expanded scope beyond what was asked.
Decision Rules
Whether to satisfy both approval requirements through a single shared pre-deployment gate backed by one service connection with broad Key Vault access, or to implement two environment-scoped gates each backed by a distinct least-privilege service connection — one scoped to QA quality validation with no Key Vault role and one scoped to Security with Key Vault Reader.
Whether to implement performance and quality release gates as two independently scoped, separately auditable pre-deployment gates in Azure Pipelines — each with its own least-privilege service connection — versus consolidating both evaluations into a single composite gate backed by one broadly-permissioned service principal.
Enforce each release gate at the narrowest possible scope — one gate per organizational trust boundary, each with a dedicated least-privilege service connection — rather than consolidating both security and performance checks into a single subscription-scoped Defender for Cloud posture gate.
Whether to route security-metric queries through a dedicated Log Analytics workspace with RBAC-restricted reader access, or to surface them via the shared Azure DevOps project Analytics view — where the correct choice is determined by the data-classification boundary and least-privilege-metric-access constraint.
GitHub Advanced Security's native secret scanning feature must own the detection and enforcement function (blocking commits containing credentials), while Microsoft Defender for Cloud DevOps Security is configured only as the aggregation and unified-visibility layer — not as a scanner — and CodeQL is reserved for custom code-pattern analysis, not credential detection.
Whether to use workload identity federation (OIDC-based federated credential on a Service Principal — no stored secret, token issued per job) versus a Service Principal with client secret externalized to Azure Key Vault (which still constitutes a long-lived credential regardless of storage location), given that Microsoft-hosted agents cannot hold a VM-assigned Managed Identity.
Domain Coverage
Difficulty Breakdown
Related Patterns