Contoso is a large enterprise with a complex Azure environment. They have multiple management groups, subscriptions, and a hub-spoke network topology. The security team wants to implement a consistent security baseline across all subscriptions using Azure Policy. They need to ensure that: 1) All resources must be deployed in approved regions only. 2) Network security groups must have specific rules to block high-risk ports. 3) All storage accounts must enforce HTTPS traffic. 4) The policies must be applied at the management group level to ensure inheritance. 5) Non-compliant resources must be automatically remediated where possible. What should you do?
This is the correct approach because Azure Policy is the native, continuous compliance service for resource-level configurations. By creating custom policy definitions for allowed locations, NSG rules, and storage HTTPS and assigning them at the root management group, the policies inherit to all child subscriptions and resource groups, providing a single, central governance baseline. Enabling the DeployIfNotExists effect makes Azure Policy automatically deploy the required configuration (e.g., a compliant NSG or secure storage setting) whenever a non-compliant resource is created or updated, and remediation tasks then correct pre-existing non-compliant resources, closing the compliance gap without manual intervention.
Why this answer
It uses Azure Policy at the root management group to enforce inheritance across all subscriptions, with custom policy definitions for allowed locations, NSG rules blocking high-risk ports, and storage HTTPS. The 'deployIfNotExists' effect enables automatic remediation of non-compliant resources, and remediation tasks fix existing non-compliant resources, meeting all requirements without manual intervention.
Exam trap
The trap here is confusing Azure Policy's 'deployIfNotExists' effect with manual remediation or third-party automation, leading candidates to choose options that lack native, automatic, and inherited policy enforcement at the management group level.
How to eliminate wrong answers
Option A is wrong because Azure Policy Guest Configuration is designed for in-guest machine settings (e.g., OS configuration), not for enforcing region, NSG rules, or storage HTTPS; assigning policies at each subscription breaks inheritance, and Azure Automation runbooks are not the native remediation mechanism for Azure Policy. Option C is wrong because Azure Blueprints are used for orchestrating resource deployments (including policy assignments) but do not provide automatic remediation; manual remediation violates the requirement for automatic remediation where possible. Option D is wrong because a custom PowerShell script with Logic Apps alerts and manual fixes is not a scalable, automated, or policy-driven solution; it lacks inheritance, automatic remediation, and centralized enforcement at the management group level.