Practice Test #9

Subscription1 is in ManagementGroup21, which is under ManagementGroup11, which is under Tenant Root Group. Therefore, Subscription1 inherits policies assigned at Tenant Root Group. The policy “Not allowed resource types” with parameter virtualNetworks is assigned at Tenant Root Group. That means creating Microsoft.Network/virtualNetworks is denied everywhere in the tenant unless an exemption is configured (none is mentioned). The “Allowed resource types” policy is scoped to ManagementGroup12 only, so it does not apply to Subscription1 (which is under ManagementGroup11). Even if it did apply, multiple policies are evaluated together and any deny would still block the deployment. Therefore, you cannot create a virtual network in Subscription1 because the Tenant Root Group policy explicitly denies virtualNetworks.

Subscription2 is in ManagementGroup12, so it inherits policies from both Tenant Root Group and ManagementGroup12. The Tenant Root Group policy blocks only Microsoft.Network/virtualNetworks, but the ManagementGroup12 'Allowed resource types' policy allows only virtualNetworks and denies all other resource types. Because a virtual machine is Microsoft.Compute/virtualMachines, it is not in the allowed list and the deployment is denied. Therefore, the statement is false, so the correct answer is No.

A subscription can belong to only one management group at a time, but it can be moved (re-parented) from one management group to another, assuming you have sufficient permissions (typically Management Group Contributor/Owner at the destination scope and appropriate permissions at the current scope). Subscription1 is currently in ManagementGroup21. ManagementGroup21 is a child of ManagementGroup11. Adding (moving) Subscription1 to ManagementGroup11 is allowed: it would simply change the subscription’s parent management group from ManagementGroup21 to ManagementGroup11. This is a governance operation and does not violate any structural rule of management groups. After the move, Subscription1 would still inherit Tenant Root Group policies and would inherit any policies assigned to ManagementGroup11 (and no longer inherit those assigned specifically to ManagementGroup21). Therefore, you can add Subscription1 to ManagementGroup11 (i.e., move it there).

Yes. An Azure Storage account (ARM-based) generally supports moving across subscriptions, provided the destination subscription is in the same Azure AD tenant and the move operation doesn’t violate constraints (for example, resource locks must be removed, and policies may block the move). Storage accounts are not inherently “pinned” to a subscription the way some governance/security resources are. Why not No: The common blockers for storage moves are usually external dependencies (apps using access keys/connection strings, private endpoints, or network rules) rather than an Azure platform limitation on moving the storage account itself. From an exam standpoint, storage accounts are considered movable resources across subscriptions using Azure Resource Manager move.

Yes. An Azure virtual network (VNet) can be moved to another subscription (same tenant) using a resource move. This is a supported ARM scenario. Important dependency note (exam-relevant): if the VNet has dependent resources (subnets with NICs, private endpoints, gateways, peerings, etc.), you may need to move dependent resources together or remove/recreate certain configurations (for example, VNet peerings often need to be re-established after moves). But the question asks which resources can be moved, and VNets are in the “supported to move” category. Why not No: VNets are not like Recovery Services vaults; they are standard ARM networking resources and are commonly moved during subscription reorganizations.

Yes. An Azure virtual machine (VM) can be moved to another subscription, but you must move the VM together with its dependent resources (at minimum: NIC(s) and managed disks; often also public IPs, NSGs, and load balancer associations depending on the design). The move is an ARM metadata operation; it doesn’t “recreate” the VM, but dependencies must remain consistent. Why not No: VMs are a standard supported resource type for cross-subscription moves. The typical exam trap is forgetting that you can’t move only the VM object while leaving its disks behind; however, the VM resource itself is movable when handled correctly with its dependencies.

Yes. Managed disks support moving across subscriptions. In fact, when moving a VM, its managed disks are commonly moved as part of the same move operation to keep the VM’s storage dependencies intact. Why not No: Managed disks are ARM resources and are not restricted like vaults or certain identity/governance resources. The main considerations are dependency integrity (the disk is attached to a VM) and ensuring you move related resources together. If you attempted to move the disk alone while leaving the VM behind, you would break the VM configuration; but the disk resource type itself is supported for moves, and in practice it should be moved with VM1.

No. A Recovery Services vault used for Site Recovery (ASR) is typically not movable across subscriptions, especially when it contains Site Recovery configuration/protected items (replication metadata, fabrics, protection containers, replicated items). Microsoft’s move restrictions for Recovery Services vaults are a frequent AZ-104 exam point: vaults with backup items or ASR replication are not supported for resource moves. Why not Yes: Moving the vault would risk breaking the reliability chain and the recovery metadata required for failover/failback operations. The supported approach is usually to disable replication/stop protection for the VM, clean up vault contents, and then reconfigure in the target subscription (or create a new vault in AZPT2 and re-protect workloads).

Vault1 is a Recovery Services vault located in Central US. Azure VM backup requires the vault to be in the same region as the VM. VM1 is in Central US, so VM1 can be backed up to Vault1. share1 (Azure Files) is in storage1, which is in West US, so it cannot be protected by a Central US vault. blob1 (Blob container) isn’t backed up using a Recovery Services vault. SQL1 is an Azure SQL Database (PaaS) in East US and is not protected by Recovery Services vault; it uses built-in backups/LTR instead. Therefore, only VM1 qualifies for Vault1, making option A correct and all options including share1/blob1/SQL1 incorrect.

Vault2 is a Recovery Services vault located in West US. Azure Files share backup (share-level, not storage-account-level) is supported by Recovery Services vault and must be in the same region as the storage account. storage1 is in West US, so share1 (in storage1) can be backed up to Vault2. VM1 is in Central US, so it cannot be backed up to a West US vault. blob1 (blob container) is not protected by Recovery Services vault. “storage1 only” is incorrect because Azure Backup protects Azure Files shares, not the entire storage account as a single protected item. SQL1 (East US) also cannot be backed up to Recovery Services vault. Hence, only share1 is valid: option B.

Pass. The correct configuration is: 1) assignableScopes: "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e" - This ensures the custom role can only be assigned within Subscription1 (at resource groups or below). Choosing "/" would allow assignment anywhere (too broad). Choosing "/subscriptions/.../resourceGroups" is not the correct scope format for RBAC; you must specify a valid scope such as a subscription or a specific resource group ID. 2) permissions: - actions: ["*"] to allow viewing/creating/modifying/deleting resources. - notActions: ["Microsoft.Authorization/*"] to prevent managing access permissions (role assignments/definitions) at the resource group scope. Other notActions options like Microsoft.Resources/* would block resource management itself, and Microsoft.Security/* is unrelated to RBAC access management.