Security And Governance Boundary — Azure DevOps Engineer (AZ-400)
Detecting Threats and Preventing Them Are Different Controls
The candidate reads "unauthorized access" and selects Microsoft Defender for Cloud, which provides threat detection and security posture scoring. The scenario, however, requires enforcing least-privilege access before a threat materializes—a job for Azure RBAC and Entra ID Conditional Access. Defender observes and alerts; RBAC and Conditional Access constrain. Conflating detection with prevention produces an answer that is directionally correct but operationally wrong for the stated requirement.
What This Pattern Tests
Azure security questions test four distinct control planes. RBAC controls who can manage resources (Contributor, Reader, custom roles) scoped to management group, subscription, resource group, or resource. Azure Policy controls what resource configurations are allowed (enforce tags, restrict VM sizes, require encryption). NSGs control network traffic at the subnet or NIC level. Conditional Access controls authentication requirements (MFA, compliant device, location). The exam tests whether you apply the right control at the right layer — using Azure Policy to enforce encryption at rest, not RBAC.
Decision Axis
Security layer (identity vs. configuration vs. network vs. authentication) determines which Azure control applies.
Associated Traps
More Top Traps on This Exam
Decision Rules
Whether to scope the security auditor's query surface to a dedicated Log Analytics workspace (enforcing data classification via workspace-level RBAC) or to grant project-level access in Azure DevOps and restrict visibility through an Analytics view filter (near-right but fails separation of duties because project membership exposes Boards and Sprint navigation).
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.
Whether to authenticate the pipeline workload via a system-assigned Managed Identity on the agent VM (secretless, scope-bounded, no credential rotation) or via a Service Principal whose client secret is retrieved from Azure Key Vault at runtime (vault-backed but still a long-lived secret that violates the no-long-lived-credentials 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