AZ-400 Develop a security and compliance plan Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Conduct a manual audit of all service connections and variable groups every quarter, and revoke any permissions that are not needed. Disable service connections associated with the former employee.

  Why it's wrong here

  A quarterly manual audit is a point-in-time check that leaves a window of up to three months during which an orphaned service principal or over-permissioned connection could be exploited. In a financial services environment, where continuous compliance is expected, a manual review cannot detect misconfigurations introduced minutes after the audit, nor can it scale across a growing number of pipelines and service connections. It also relies entirely on human diligence to identify every unnecessary permission, which is error-prone and easily misses subtle over-grants or variable group access issues. Disabling the former employee's connections is necessary but insufficient; it does not address the need for automated, continuous controls like Azure Policy or access reviews.

• ✗

  Immediately delete all service connections associated with the former employee and recreate them using service principals with the least privilege. Then, update all pipelines to use the new connections.

  Why it's wrong here

  Immediately deleting and recreating the service connections is a high-risk, reactive response that does not address the root cause. Deleting connections in use will break running pipelines and force urgent, error-prone updates to every pipeline definition and release stage that references them; any in-flight deployment could fail mid-run. Moreover, this only cleans up the former employee's specific connections but does nothing to prevent the next administrator from accidentally creating a new service principal with excessive subscription-level rights. Without Azure Policy or similar automated guardrails, the same over-permissioned configuration can be recreated at any time.

• ✗

  Restrict all service connections to use resource-group level scoped permissions instead of subscription-level. For variable groups, set them to be accessible only to specific pipelines.

  Why it's wrong here

  Restricting service connections to resource-group scoped permissions and locking variable groups to specific pipelines is a partial least-privilege hardening, but it is a manual, point-in-time configuration change that does not remediate existing over-permissioned service principals or the former employee's stale credentials. It also lacks any automated enforcement or ongoing governance, so future service connections could still be created with subscription-level Contributor access. Further, restricting variable groups to specific pipelines does not enforce branch policies or approval checks on secret updates, leaving a key governance gap.

• ✓

  Implement Azure Policy to enforce that service connections cannot have subscription-level Contributor role; instead, require specific resource group roles. Use Azure AD access reviews to automatically remove stale service principals. Use pipeline decorators to enforce branch policy and approval checks on variable groups that contain secrets.

  Why this is correct

  This answer combines three complementary Azure native controls that together provide preventive, detective, and corrective governance. Azure Policy continuously audits and denies role assignments that grant subscription-level Contributor to service connections, enforcing least privilege automatically across all resources. Azure AD access reviews periodically evaluate service principal usage and automatically remove or disable stale principals, eliminating orphaned credentials like the former employee's. Pipeline decorators inject pre-execution steps into every pipeline run, enforcing branch policies and mandatory approval checks whenever a variable group containing secrets is referenced, even if the pipeline YAML does not explicitly include those checks.

Go deeper

Related to this question