Azure Policy practice questions

The initiative must be copied to every resource group in the new subscription before it takes effect.

Why wrong: Because the assignment is at the corp management group, it is automatically inherited by the new subscription and every resource group inside it; there is no need to copy or recreate the initiative at a lower scope. Azure Policy inheritance means that any resource group or resource in the subscription is already covered by the same assignment. Copying the initiative to each resource group would cause duplicate assignments and is unnecessary, not required.

The initiative changes RBAC so users lose read access to the subscription.

Why wrong: Azure Policy works through effects such as audit, deny, append, or deployIfNotExists to evaluate and enforce resource configurations; it never modifies Azure RBAC role assignments or permissions. Resource access (read, write, delete) is controlled by role assignments, which are unaffected by Policy. The only way a policy can appear to affect access is indirectly by denying creation of a role assignment or resource, but it does not revoke existing read access for users.

Compliance results are only visible in Activity Log, not in Azure Policy.

Why wrong: The Azure Portal has a dedicated Policy blade with a Compliance dashboard that lists per-scope compliance, per-definition results, and per-resource status; returning to the Activity Log is unnecessary and misleading. Activity Log records control-plane events (like creating or deleting resources) and does not persist the ongoing policy compliance state. Therefore, asserting that compliance results are only visible in Activity Log is incorrect because Azure Policy's own reporting surfaces are the primary and authoritative view.

Configure 'Password protection' with a custom banned password list.

Why wrong: A custom banned password list is a Password Protection feature that blocks weak or compromised passphrases during password set and reset operations. It does not create any user-facing password reset workflow or allow users to independently initiate a reset. It is compatible with SSPR, but it is an additive security filter, not the mechanism that permits self-service password reset.

Enable 'Combined registration' for security info to simplify MFA and SSPR registration.

Why wrong: Combined registration is a user-facing onboarding experience that captures security information for both Microsoft Entra MFA and SSPR in a single flow. It improves the likelihood that users register accurate methods, but it does not by itself enable the password reset feature. If SSPR is disabled, users still cannot reset their passwords regardless of how complete their security info is, so this option addresses registration convenience, not the reset capability itself.

Assign the 'Global Administrator' role to all users to allow password reset.

Why wrong: Making every user a Global Administrator is a severe privilege escalation that violates least privilege and expands the attack surface, since the Global Administrator role has tenant-wide control. While Global Administrators can reset passwords manually, that ability is an administrative function, not self-service reset for all users. Users should only need the SSPR permission granted by the SSPR feature, not a directory-wide administrative role, making this option wrong.

Assign each policy only to one resource group.

Why wrong: Scoping the assignments to a single resource group would leave the other nine subscriptions (and all other resource groups) entirely ungoverned, creating severe compliance gaps. It also fragments governance: you would need many separate assignments for each resource group, and any new resource groups in those subscriptions would automatically lack the policy. A broader scope is necessary to meet the department's requirement of uniform governance across all 10 subscriptions.

Use Azure RBAC instead of Policy for both requirements.

Why wrong: Azure RBAC governs who can perform actions by defining roles and permissions, while Azure Policy governs what resource configurations are allowed or expected. Role assignments cannot enforce that resources are created only in a specific region or that every resource has a required tag—those are policy evaluation criteria outside RBAC's authorization model. Even with RBAC, a user with Contributor permissions could create a resource in any location unless a policy denies it.

Create a read-only lock on each subscription.

Why wrong: A read-only lock invokes a deny on all write and delete operations at the resource scope, but it is an operational safeguard, not a compliance control. It does not evaluate tags, cannot inspect resource properties for permitted regions, and does not produce policy compliance data. Locks are also applied uniformly and cannot conditionally allow or deny regions; they simply prevent modifications to locked resources.

Always

Why wrong: Always restarts the container regardless of success or failure. That would cause a completed import job to start again even after successful completion, which is not the requirement.

Never

Why wrong: Never prevents any restart behavior. That means a failed job would not retry automatically, which conflicts with the requirement to restart on failure.

Manual

Why wrong: Manual is not the standard ACI restart policy for an unattended job. It would leave the workload dependent on operator action instead of automatically retrying on failure.

Blob soft delete

Why wrong: Blob soft delete provides a recovery safety net by preserving deleted blobs for a configurable period, but it does not block or prevent deletion in the first place. Even with soft delete enabled, a user with appropriate permissions can still overwrite or delete a blob, and the soft-deleted copy is not immutable—it is simply hidden and recoverable. As a result, it cannot guarantee that legal documents remain unaltered and undeleted for seven years; it only offers post-deletion recovery.

Lifecycle management to move blobs to Archive

Why wrong: Lifecycle management automates the movement of blobs to cooler tiers like Archive based on age or last-modified date, which is purely a cost-optimization mechanism. Moving a blob to the Archive tier does not lock the blob, nor does it prevent deletion or overwrite; an archived blob can be explicitly deleted at any time. This option reduces storage expenses but completely fails to provide any immutability or retention enforcement for legal documents.

Blob versioning

Why wrong: Blob versioning preserves historical versions of a blob whenever it is overwritten or deleted, but it does not prevent those operations from occurring on the current version. Without an immutable policy, an authorized user can still modify or delete the latest version, and while a deleted version is retained, the data remains mutable in practice. Versioning therefore aids recovery and auditing, but it does not satisfy a requirement for write-once, read-many protection over a fixed seven-year period.

Create a custom RBAC role that excludes unsupported VM sizes from the Contributor role.

Why wrong: RBAC role definitions authorize actions such as Microsoft.Compute/virtualMachines/write, but they cannot inspect the request body or evaluate properties like the selected SKU. A custom role cannot "exclude unsupported VM sizes" because size is a deployment parameter evaluated by Azure Policy, not an RBAC permission. Even with full Contributor equivalent write permissions, an RBAC-only approach will still allow an operator to deploy any VM SKU if no policy denies it.

Apply a CanNotDelete lock to the resource group that contains the virtual machines.

Why wrong: A CanNotDelete lock is an Azure management lock that protects resources from deletion, not from creation or update. It functions at the resource/management level and does not validate or constrain configuration values such as VM size during a PUT operation. Applying CanNotDelete to a resource group would block deleting the group and its resources, but it would do nothing to stop an administrator from deploying a VM with a non-approved SKU.

Assign Reader permissions to the operators and rely on Azure portal validation.

Why wrong: Assigning Reader permission would revoke all write capabilities, so users could not deploy any virtual machine at all—far exceeding the intent of blocking only unsupported VM sizes. Relying on Azure portal validation is also not an enforceable control because it exists only in the portal UI; any call through Azure CLI, PowerShell, or the REST API can bypass portal warnings and submit a compliant deployment. The requirement is to actively deny disallowed SKUs, which requires an Azure Policy definition and assignment, not a restrictive RBAC role or a user-facing UI guard.

Always

Why wrong: This would restart the container every time it exits, which is not suitable for a one-time job.

OnFailure

Why wrong: This restarts only after failure, but the question asks for the policy that stops after a successful one-time run.

Manual

Why wrong: Manual is not a valid Azure Container Instances restart policy, so it cannot be selected.

A resource group

Why wrong: A resource group is a container for Azure resources such as virtual machines, storage accounts, and databases within a single subscription. It helps organize and manage resources that share a lifecycle, but it cannot group multiple subscriptions or provide governance inheritance across subscriptions.

A tag

Why wrong: Tags are metadata key-value pairs used to categorize resources, such as by department or cost center. They are useful for reporting and filtering, but they do not create a hierarchy and cannot apply governance settings above the subscription level.

A resource lock

Why wrong: A resource lock prevents accidental deletion or modification of a specific resource or resource group, depending on where it is applied. It is a protection mechanism, not an organizational structure, and it does not group subscriptions or enable inherited governance across them.

Give users Contributor access to the subscription.

Why wrong: Granting Contributor access at subscription scope gives users full management rights for resources, but RBAC permissions are orthogonal to Azure Policy. Contributor allows a user to deploy to any location or with any tags; only a policy assignment can block those actions. This would make governance less restrictive and would not address the requirement to restrict regions or enforce tags.

Create Microsoft Entra ID users for contractors.

Why wrong: Microsoft Entra ID users are identities used for authentication and authorization; creating them does not affect Azure Policy evaluations. Policy assignments operate on Azure resources and their properties, not on identity objects. Contractors who receive Entra ID accounts are still subject to the same policies as employees, but the accounts themselves cannot enforce region or tag rules.

Place a CanNotDelete lock on every resource group.

Why wrong: A CanNotDelete lock is applied to a resource group to prevent deletion of the group or the resources within it. This lock does not influence Azure Resource Manager's deployment-time policy evaluation; a user could still create resources in any region or skip required tags. Locks are an operational protection mechanism, not a compliance enforcement mechanism, so they cannot stop noncompliant deployments.

Apply a CanNotDelete lock to the production resource group.

Why wrong: A CanNotDelete lock protects the resource group from accidental deletion, but it does not affect tag assignment or modification. Because the lock only restricts delete operations, users can still create resources without the required CostCenter tag, and existing resources remain untagged. Therefore it fails to enforce any tagging standard and provides no cost-tracking assurance.

Assign Contributor on the subscription and require teams to enter the tag manually.

Why wrong: Assigning Contributor at the subscription grants broad management rights, but it leaves tagging entirely to manual user discipline. This approach cannot prevent missing or incorrectly spelled tags, and there is no automated way to detect or correct drift, so finance teams will see inconsistent cost data. The role is also overly permissive because the task only needs tag enforcement, not full management access.

Set the tag on the management group and expect all resources to inherit it automatically.

Why wrong: Tags placed directly on a management group are metadata for that management group only; they are not inherited by subscriptions or resources. Azure Policy must be explicitly assigned with an appropriate effect to achieve tag propagation, and without such a policy the CostCenter tag will not appear on any newly created resource. Expecting automatic inheritance from a management group tag is a common misconception and will leave resources untagged.

Create a custom RBAC role that blocks resources deployed outside approved regions.

Why wrong: A custom RBAC role that attempts to block resources outside approved regions cannot work because RBAC permissions are based on actions (such as Microsoft.Resources/deployments/write) and do not inspect resource properties like location during evaluation. Even with deny assignments or custom roles, you cannot express a condition that says 'this deployment is allowed only if the region is X' purely through role-based permissions. Azure Policy is the service that performs property-based evaluation and is the appropriate mechanism for this requirement.

Add a CanNotDelete lock to every resource group.

Why wrong: Adding a CanNotDelete lock to every resource group is wrong here because locks are designed to prevent accidental deletion or modification of critical resources, not to enforce deployment-time compliance rules like allowed regions or required tags. A lock does not evaluate the properties of a newly deployed resource; it operates after the resource exists and cannot inspect the deployment request itself. Contributor users would still be able to create resources in any region, and the lock would not add the Environment tag or reject an unapproved location.

Grant User Access Administrator to the deployment team.

Why wrong: Granting User Access Administrator to the deployment team is incorrect because that role only manages Azure RBAC role assignments and does not enforce any governance or compliance requirements on resource deployments. It would give the team the ability to grant themselves or others additional permissions, making governance worse, but it would not restrict the region or validate tags. Since the team already has Contributor, they can create resources; adding User Access Administrator does nothing to constrain where or how they do it.

A custom RBAC role that removes the create action for virtual machines.

Why wrong: A custom RBAC role that removes the create action for virtual machines (Microsoft.Compute/virtualMachines/write) is an identity-based control: it determines who can perform the action, not whether the resulting resource satisfies a required tag. If assigned, it would block all VM creation by those users, even compliant deployments, and it provides no compliance reporting or auditing of non-compliant resources. Additionally, RBAC cannot evaluate resource properties like tags, so it fails to enforce the specific governance requirement of tagging at deployment time.

A resource lock on the resource group.

Why wrong: A resource lock prevents accidental deletion or modification of a resource group or its resources at the management plane level, typically using CanNotDelete or ReadOnly. It does not inspect the resource payload for tags or evaluate any compliance rules. A lock would simply block all deletion or mutation operations, not specifically those missing a required tag, and it cannot enforce the presence of a tag during initial creation because locks are applied only to existing resources. This is a protective measure, not a governance validation tool.

An Entra ID dynamic group for the VM creators.

Why wrong: Entra ID dynamic groups automatically manage user membership based on properties like department or location, but they are unrelated to resource configuration or tagging. Group membership affects token claims and conditional access, not how the VM is deployed in Azure Resource Manager. A dynamic group could not intercept an ARM deployment request to validate a required cost-center tag, nor could it deny the deployment based on missing metadata. Therefore, it has zero effect on ensuring the tag requirement is met.

Change the backup schedule from daily to hourly.

Why wrong: Changing the backup schedule from daily to hourly only increases the frequency at which recovery points are created; it does not alter how long those recovery points are retained. The retention setting still specifies that each daily (or hourly) recovery point is kept for only 7 days, so all created points, regardless of frequency, will expire after that period. This would increase storage costs and management overhead without satisfying the 30-day retention requirement.

Increase the instant recovery snapshot retention to 30 days.

Why wrong: Instant recovery snapshots are temporary, locally stored snapshots used for fast disk-level restores immediately after a backup. They are retained for a short period (typically up to 7 days) and are not the same as long-term backup recovery points stored in the Recovery Services vault. Increasing their retention to 30 days may extend the quick-restore window but would not change how long the daily recovery points themselves are kept, so the requirement for 30-day retention remains unmet.

Enable a CanNotDelete lock on the Recovery Services vault.

Why wrong: A CanNotDelete lock on the Recovery Services vault prevents the vault itself from being deleted or modified by users or automated processes, but it has no effect on the Azure Backup retention policy. Restore points inside the vault still expire according to the current scheduled retention (7 days), and a lock does not preserve or extend them. This control is designed for resource protection against accidental or malicious deletion, not for compliance-driven data retention.

Always

Why wrong: The Always restart policy in Azure Container Instances relaunches the container group every time it stops, regardless of whether the process exited with code 0 or a non-zero code. For a one-time import job that finishes successfully, this would cause the container to execute repeatedly in an infinite loop, re-running the import logic and potentially creating duplicate or corrupted data. The job is meant to run once and then remain terminated, so Always is inappropriate because it forces continuous re-execution even after a clean exit.

OnFailure

Why wrong: The OnFailure restart policy restarts the container group only when the process exits with a non-zero exit code, which signifies an error. In the context of a one-time import job, this means a transient failure could trigger automatic retries, potentially leading to an unbounded restart loop if the underlying issue isn't resolved. While a successful run would stop cleanly, the job's semantics are 'run exactly once'—not 'retry on failure'—so OnFailure introduces an unwanted retry behavior that doesn't match the requirement of a strictly one-time task.

Manual

Why wrong: Manual is not a valid restart policy for Azure Container Instances. The only restart policies supported by the ACI API and CLI are Always, OnFailure, and Never. Attempting to set Manual as the restartPolicy parameter would cause a validation error and prevent the container group from being created. This option is a distractor that might sound plausible but has no technical basis in the platform.

Blob soft delete

Why wrong: Blob soft delete is a recovery feature that preserves deleted blobs for a configurable retention window, but it does nothing to prevent deletion or modification during the blobs' active lifetime. A user or application with write access can still overwrite or delete a blob, and the soft-deleted copy is only retained after the deletion operation succeeds. Therefore soft delete provides no immutability or compliance-grade WORM assurance.

Lifecycle management to move data to Archive

Why wrong: Lifecycle management policies automatically move blobs between access tiers (e.g., hot to cool to Archive) based on age or other conditions, but they never enforce immutability or block writes and deletes. Archive tier still allows modifications and deletions, and a user with permissions can remove the blob entirely. This is a cost-optimization feature, not a regulatory records-retention control.

A shared access signature

Why wrong: A shared access signature (SAS) is a URI-based delegation token that grants granular permissions (read, write, delete, etc.) to a specific resource for a limited time. It controls access only, and cannot impose retention or immutability on the underlying data; once a SAS is issued, the holder can perform whatever operations the permissions allow. Thus it is a security mechanism, not a data preservation control.

Modify the policy definition so all storage accounts can use public network access.

Why wrong: Modifying the policy definition changes the deny effect for every scope where that definition is assigned, not just the legacy storage account. This would broadly allow public network access for all storage accounts across the environment, undermining the compliance baseline the policy was designed to enforce. Policy definitions should be treated as versioned, centrally managed artifacts; altering them to accommodate a single exception is an anti-pattern and creates audit noise, whereas a policy exemption is a scoped, documented exception that leaves the rest of the footprint governed.

Apply a ReadOnly lock to the storage account.

Why wrong: A ReadOnly lock prevents any management-plane write operation, such as changing network access rules or applying tags, but it does not affect Azure Policy's compliance evaluation. Policy will still see the storage account as non-compliant because the public network access setting remains, and the deny effect will block attempts to update the resource. Locks are meant to prevent accidental deletion or modification, not to grant exceptions; this action would also interfere with legitimate future changes and does not create any explicit exemption from the policy assignment.

Move the storage account to another subscription so the policy no longer applies.

Why wrong: Moving the storage account to another subscription is a heavy, disruptive operation that can change the resource's canonical ID, disrupt access for clients, and may not even avoid the policy if it is assigned at a management group above both subscriptions. Even if the move succeeds, the resource is ungoverned rather than explicitly exempted, which is poor governance practice and will fail an audit that expects a documented exception. Azure Policy exemptions provide a controlled, reversible process for legacy resources, while a migration should be planned for long-term compliance instead of just relocating the problem.

Use the Deny effect.

Why wrong: The Deny effect blocks the creation or update of any resource that violates the policy, which is exactly the opposite of the stated goal of merely identifying non-compliant resources. With Deny, users would be prevented from creating resources without the required tag, causing friction and potentially halting legitimate work. Compliance teams need visibility first; enforcement can come later, but Deny forces enforcement immediately and is therefore inappropriate for a reporting-only request.

Grant Reader on the subscription to the compliance team.

Why wrong: Granting Reader on the subscription gives the compliance team the ability to list and view resource properties, but it does not invoke Azure Policy evaluation or produce compliance results. The tag-missing status is a policy evaluation outcome stored in the policy compliance report, not a visible attribute of the resource itself. Without policy assignments and evaluation, Reader access alone cannot tell which resources are non-compliant—it merely allows viewing the raw resources as they exist.

Apply a ReadOnly lock to all resource groups.

Why wrong: ReadOnly locks are a resource management safeguard that prevents accidental modification or deletion of resources and resource groups, but they do not inspect or analyze tags. They would block legitimate rename, update, and delete operations for everyone, which conflicts with the requirement that users keep creating and changing resources. Locks are not a compliance assessment mechanism; they simply restrict changes at the ARM control plane and offer no reporting on policy adherence.

Azure RBAC, because region selection is part of user permissions.

Why wrong: Azure RBAC grants permissions through role definitions that list management actions, but it has no concept of allowable deployment regions. Even a user with the Contributor role can create resources in any location unless an Azure Policy with a deny effect (such as 'Allowed locations') explicitly rejects the request. RBAC only authorizes an identity to perform an action; it does not evaluate or enforce attributes like the region of a resource during deployment. Thus, RBAC is about access control, not compliance enforcement for geographic restrictions.

A network security group, because it can block unsupported regions.

Why wrong: A network security group (NSG) is a stateful packet-filtering firewall that governs traffic to and from subnets or network interfaces using rules based on source/destination IP, port, and protocol. NSGs operate at the network layer after a resource has been deployed and are completely unaware of Azure Resource Manager provisioning requests or the physical Azure region in which a resource is placed. They cannot intercept deployment-time decisions or block a resource from being created in an unsupported region. Therefore, NSGs are entirely the wrong tool for enforcing location restrictions.

A read-only lock, because it limits changes to approved regions.

Why wrong: Azure resource locks are management-layer safeguards that prevent accidental deletion or modification by denying all change operations within the locked scope. A read-only lock (CanNotDelete) blocks any management action that would alter a resource, but it does not analyze the region of a new deployment request. In fact, applying a read-only lock to a resource group prevents any new resource from being deployed because deployment requires write permissions on the group, which the lock denies. This makes the lock not only ineffective for region compliance but also disruptive to normal operations.

Use one subscription and separate the environments with tags only

Why wrong: Tags are key-value metadata used for cost allocation, inventory, and automation, but they are not an enforcement boundary: Azure RBAC does not evaluate tag values when determining whether a user can manage a resource. With a single subscription, dev and prod share the same billing account, subscription quota, and subscription-level role assignments, so a user with Contributor rights could modify resources regardless of their tag. Even if Azure Policy forces tagging, it does not provide independent budgets, administrators, or fault isolation, so tags alone cannot satisfy the isolation requirement.

Use one management group and two resource groups, one for dev and one for prod

Why wrong: Resource groups are logical containers within a single subscription, so dev and prod would still share the same subscription-level billing account, quota, and any subscription-scoped role assignments such as Owners. Azure Policy inherited from the management group can enforce tagging or location, but it cannot separate budgets, isolate service quotas, or prevent subscription administrators from accessing both resource groups. A resource group is a management boundary, not a billing or security boundary, so this design fails to meet the requirement for independent dev and prod environments.

Put production in a management group and development in a resource group

Why wrong: A management group and a resource group are at different levels of the Azure hierarchy: management groups may contain subscriptions, and subscriptions contain resource groups. Placing production in a management group and development in a resource group means they are not peer environments, so policies, budgets, and RBAC would have to be configured at structurally different scopes, making governance inconsistent and potentially leaving development without a proper management-group context. This violates the hierarchical model and does not create separate billing or administrative boundaries for the two workloads.

Three separate policy assignments at each subscription

Why wrong: Creating three separate policy assignments at each subscription results in duplicated effort and inconsistent configuration if any assignment is altered per subscription. It also fragments governance monitoring, as each subscription has its own set of assignments, making it harder to audit and remediate compliance across the enterprise. While technically functional, this approach does not provide a consolidated, scalable control package.

A custom RBAC role assigned to each subscription

Why wrong: A custom RBAC role controls what principals can do, such as reading, writing, or deleting resources, but it cannot enforce governance rules like allowed locations or required tags. RBAC roles are granted to users, groups, or service principals, and they do not evaluate or report on resource configuration. Therefore, a custom role cannot enforce compliance controls across subscriptions.

A resource lock on each subscription

Why wrong: A resource lock, such as CanNotDelete or ReadOnly, protects resources from accidental deletion or modification, but it does not assess or enforce policy compliance like allowed locations or tag requirements. Locks are meant to prevent unauthorized operations, not to evaluate whether resources meet governance rules. Additionally, locks apply to specific resources or resource groups, not to an entire subscription’s compliance posture.