Azure Governance practice questions

One – assign a policy definition with the Deny effect.

Why wrong: A single Deny effect prevents creation but does not produce a separate compliance state for audit purposes; it only logs a denial event. The requirement explicitly asks for logging attempts for audit, which is more clearly satisfied by an Audit effect.

One – assign a policy definition with the Audit effect.

Why wrong: An Audit effect logs the attempt and shows compliance state, but it does not block the creation of the VM. The requirement also includes preventing the VM from being created.

Two – assign one policy definition with the Deny effect and another with the Append effect.

Why wrong: The Append effect adds tags or settings but does not log attempts for audit. Combining Deny with Append still does not address the logging/audit requirement.

Azure Resource Manager

Why wrong: ARM handles deployments, not resource querying.

Azure Monitor

Why wrong: Monitor collects telemetry, not resource inventory.

Azure Policy

Why wrong: Policy enforces rules, not query resources.

Azure Policy

Why wrong: Azure Policy enforces and audits compliance rules, but it cannot deploy resources like virtual networks or create resource groups. It only handles policy definitions and assignments, not the full package of resources, roles, and policies.

Azure Resource Manager templates

Why wrong: ARM templates deploy Azure resources declaratively, but they do not natively assign Azure Policy or role assignments. While you can use ARM templates for resource deployment, they lack the centralized versioning and auditing of governance artifacts that Blueprints provide.

Management groups

Why wrong: Management groups organize subscriptions into hierarchies for policy and RBAC inheritance. However, they do not deploy resources or define a package of resources, policies, and roles. They are containers, not deployment packages.

Availability sets

Why wrong: Availability sets are for VM high availability, not for logical organization.

Virtual networks

Why wrong: Virtual networks provide network isolation, not a management grouping construct.

Subscriptions

Why wrong: Subscriptions are billing and access boundaries, but resources are further organized into resource groups within a subscription.

Create a resource lock on the subscription to prevent all resource creation.

Why wrong: Resource locks (CanNotDelete or ReadOnly) are designed to protect resources from accidental deletion or modification, not to block the creation of new resources. A resource lock on the subscription would prevent deletion of the subscription itself, but it does not block deployments of virtual machines in disallowed regions.

Assign an Azure RBAC role that denies create permissions for VMs in disallowed regions.

Why wrong: Azure RBAC roles manage permissions based on actions (e.g., Microsoft.Compute/virtualMachines/write) but cannot easily restrict by resource property such as region. Even with a custom role, you would need to specify each disallowed region in NotActions, which is cumbersome and error-prone. Azure Policy is the correct service for rules based on resource properties.

Set up a budget alert in Cost Management to notify when a VM is created in a disallowed region.

Why wrong: Azure Cost Management budget alerts are designed to track spending and send notifications when costs exceed thresholds. They do not prevent resource creation and cannot enforce location restrictions. This solution is reactive, not proactive.

Each subscription individually

Why wrong: Assigning the policy to each subscription individually would require many assignments and would not automatically apply to new subscriptions unless the team also updates the assignments. This is not the most efficient approach for a single, organization-wide policy.

Each child management group (Finance, HR, IT) individually

Why wrong: While assigning to each child management group would cover their respective subscriptions, it requires three separate assignments and will not automatically cover any additional management groups added later. The question specifies assigning the policy once.

A single resource group

Why wrong: Assigning the policy at a resource group scope only affects resources within that specific resource group, not the subscriptions or management groups. This would not meet the requirement to restrict deployments across the entire organization.

Resource groups

Why wrong: Resource groups group resources for an application, but they do not span subscriptions or directly enforce policies across them.

Azure Policies

Why wrong: Azure Policy is a tool to enforce rules, but it is not an organizational feature; it can be applied at management group level.

Azure Policy

Why wrong: Azure Policy enforces compliance rules (like tagging and encryption), but it does not deploy resources such as virtual networks or role assignments. It also does not provide a mechanism to deploy and update a complete set of resources across subscriptions in a coordinated, versioned way.

Azure Resource Manager (ARM) templates

Why wrong: ARM templates can deploy resources, policies, and role assignments, but they are static deployments. If the governance team updates the template, they would need to redeploy it to each subscription manually; there is no built-in 'update and automatically apply' feature like Blueprints provides for existing deployments.

Azure Management Groups

Why wrong: Management Groups organize subscriptions hierarchically and can be used to assign policies and RBAC roles at a scope. However, they do not deploy Azure resources like virtual networks or subnets. They are a governance structure, not a deployment service.

Resource group

Why wrong: Incorrect. Resource groups are containers for resources within a single subscription, not for grouping subscriptions. They cannot apply policies across multiple subscriptions.

Azure Policy initiative

Why wrong: Incorrect. A policy initiative is a group of policy definitions, but it must be assigned to a scope like a management group, subscription, or resource group. It alone does not organize subscriptions.

Azure Blueprint

Why wrong: Incorrect. Blueprints are used to define a repeatable environment (including policies and roles) for a specific subscription, but they are not a construct to group multiple existing subscriptions.

Resource groups

Why wrong: Resource groups contain resources within a subscription; they do not organize subscriptions.

Azure Policy

Why wrong: Azure Policy is used to enforce rules, not to organize subscriptions.

Tagging

Why wrong: Tags provide metadata but do not create a hierarchy for subscriptions.

Azure Policy with the deny effect to block deletion of the storage account

Why wrong: Azure Policy can enforce rules across resources, but configuring a custom policy to block deletion is complex and not the intended purpose. Resource locks are the simpler and more direct mechanism for preventing accidental deletion of specific resources.

An Azure Blueprint that includes the storage account with a policy to prevent deletion

Why wrong: An Azure Blueprint is used to define a repeatable set of governance artifacts (policies, role assignments, etc.) for deploying environments. It is not a feature to apply a protective lock on an existing individual resource.

A Read-only lock on the storage account

Why wrong: A Read-only lock prevents any modification or deletion of the resource. Since the administrator needs to update data within the storage account, a Read-only lock would block those updates, which does not meet the requirement.

To group Azure resources within a single subscription for billing purposes

Why wrong: Grouping resources within a subscription is done by Resource Groups, not Management Groups.

To manage Kubernetes clusters across multiple regions

Why wrong: Kubernetes management is handled by AKS, not Management Groups.

To monitor resource health across different Azure services

Why wrong: Resource health monitoring is done by Azure Monitor and Service Health, not Management Groups.

Azure Resource Manager templates

Why wrong: ARM templates deploy infrastructure but do not bundle RBAC and policy assignments with an auditable link.

Azure Policy

Why wrong: Policy enforces compliance rules but does not bundle multiple governance artifacts for subscription setup.

Azure Management Groups

Why wrong: Management Groups organize subscriptions hierarchically but do not deploy resource packages.

The maximum number of resources you can create in Azure

Why wrong: Resource limits are defined in Azure subscription quotas, not SLAs.

The pricing model for Azure services

Why wrong: Pricing is defined in Azure's pricing documentation, not SLAs.

The geographic locations where services are available

Why wrong: Service availability by region is published separately in Azure regional availability documentation.

Audit

Why wrong: Audit creates a compliance log entry when a condition is evaluated, but it does not take any action to deploy or change resources. It would only report non-compliance, not automatically configure the diagnostic settings.

Deny

Why wrong: Deny prevents the creation of resources that do not meet the policy condition. In this case, it would block the creation of a storage account that lacks diagnostic settings, which contradicts the requirement to allow creation and then automatically configure.

Append

Why wrong: Append is used to add additional fields or properties to an existing resource during creation or update, such as adding a tag. It cannot deploy a separate resource like a diagnostic setting, so it is not suitable for this scenario.

Deny

Why wrong: Deny prevents the creation of the VM entirely if it does not meet the condition. The requirement is to automatically correct the tag, not block creation, so Deny is incorrect.

Audit

Why wrong: Audit only logs non-compliant resources for reporting; it does not take any automatic corrective action. The requirement is to automatically correct the tag, so Audit is incorrect.

DeployIfNotExists

Why wrong: DeployIfNotExists is used to deploy an additional resource (e.g., a network security group) to the resource's location when the resource is created. It is not designed to modify properties like tags on the existing resource, so it is incorrect.

Exclusion scope

Why wrong: This is incorrect because an exclusion completely removes the scope from policy evaluation. If you apply an exclusion to a resource group, the policy is not evaluated at all for resources in that group, and no compliance data is gathered. This does not meet the requirement to record the reason for the exception or to enforce the policy on other resources within the same scope.

Audit effect

Why wrong: This is incorrect because the Audit effect is a property of a policy definition, not a feature applied to a resource or scope. It changes how the policy behaves when non-compliance is detected (audit vs deny). In this scenario, the existing policy uses the Deny effect, and changing it to Audit would alter enforcement for all resources, not just the specific test VM. Also, the Audit effect does not provide a mechanism to record an exception reason or expiration.

Override effect

Why wrong: This is incorrect because there is no 'Override effect' in Azure Policy. Azure Policy supports effects such as Deny, Audit, Append, DeployIfNotExists, etc., but not Override. This is a plausible-sounding but fictitious option.

Azure Policy

Why wrong: Incorrect. Azure Policy enforces rules and effects on resources, but does not deploy resource templates or RBAC assignments.

Azure Resource Manager

Why wrong: Incorrect. Azure Resource Manager is the service for managing resources, but it does not package policies and roles as a single deployable unit.

Azure Management Groups

Why wrong: Incorrect. Management Groups organize subscriptions hierarchically for policy and access management, but they do not define the environment contents.

Create a new Azure Policy assignment at the marketing subscription scope with the 'Allowed Locations' initiative set to 'Audit' instead of 'Deny' and include North Europe in the allowed list.

Why wrong: Creating a new assignment at the subscription scope would not override the deny effect from the parent management group. Policy effects are additive, and a deny effect from a higher scope cannot be overridden by an audit effect at a lower scope. This would not grant the permission to deploy in North Europe.

Create an Azure Blueprint that includes the 'Allowed Locations' policy and assign it to the marketing subscription.

Why wrong: An Azure Blueprint can include policy assignments, but it would still apply the deny effect to the marketing subscription since the root management group assignment is still in effect. This does not provide an exception; it only duplicates the restriction.

Assign a custom RBAC role to the marketing subscription that bypasses the policy.

Why wrong: Azure Role-Based Access Control (RBAC) controls who can perform actions on resources, not whether resources can be created. Azure Policy is independent of RBAC; custom roles cannot bypass policy effects. Only exemptions or modifications to the policy itself can grant exceptions.

Create a second policy assignment at the sandbox subscription with the 'Disabled' effect.

Why wrong: Azure Policy does not support a 'Disabled' effect. You cannot override a parent policy assignment by assigning the same policy with a different effect at a child scope. The only way to exclude a scope from a policy assignment is to use an exemption.

Remove the policy assignment from the management group and assign it individually to all subscriptions except the sandbox.

Why wrong: This approach is extremely inefficient and error-prone for 30 subscriptions. It defeats the purpose of using a management group to apply policy centrally. The correct method is to keep the management group assignment and use an exemption for the sandbox.

Configure an Azure Blueprint for the management group and exclude the sandbox subscription.

Why wrong: Azure Blueprints can include policy assignments, but they do not have a built-in exclusion mechanism. To exclude a subscription from a blueprint's policy assignment, you would still need to create an exemption on that subscription. Additionally, moving from a direct policy assignment to a blueprint is unnecessary complexity.