Practice Test #7

No. The policy assignment is scoped only to RG2, so resources in RG1 are outside the assignment scope. VNET1 being a virtual network in RG1 means it is not governed by this deny policy assignment. The statement is therefore false in the context of policy impact, while options implying RG2-scoped enforcement on RG1 resources are incorrect.

No. The policy assigned to RG2 uses the built-in 'Not allowed resource types' definition and includes Microsoft.Network/virtualNetworks. That means virtual networks are not allowed for create or update operations in RG2. Existing resources are not deleted, but for the hotspot's true/false evaluation under policy, the correct choice is No rather than Yes.

No. The assignment at RG2 includes Microsoft.Compute/virtualMachines in the list of not allowed resource types. As a result, virtual machine resources are denied for create and update operations within RG2. Although VM1 already exists and remains running, the intended hotspot answer is No because VMs are not allowed in RG2 under this policy.

Pass. The exhibit provides enough information to answer the scenario: the policy definition is 'Not allowed resource types', the assignment scope is RG2, and the denied types include classic virtual networks, ARM virtual networks, and virtual machines. From that, you can determine that only resources and write operations in RG2 are affected. Existing resources are not removed or powered off, but create, update, and move-into-scope operations for those resource types are denied.

No. Moving VNET1 (a Microsoft.Network/virtualNetworks resource) from RG1 into RG2 would result in the VNet being created/updated in the target scope (RG2). Azure Policy deny assignments are evaluated on write operations at the target scope. Because RG2 has a policy assignment that denies Microsoft.Network/virtualNetworks, the move operation would be blocked. In practice, resource moves are treated as management-plane operations that must pass policy evaluation in the destination resource group. Why “Yes” would be wrong: Policy scope matters. Even though RG1 is not in scope, the destination (RG2) is in scope and denies that resource type, so the move cannot complete.

No. Azure Policy with “Not allowed resource types” (deny) does not change the runtime power state of existing resources. VM1 is currently Running, and assigning a deny policy does not deallocate, stop, or restart the VM. Policy is a governance control over management-plane actions (create/update/delete) and compliance reporting. It is not an automation/remediation mechanism that changes compute state unless you use other tooling (for example, Azure Automation, Logic Apps, or a DeployIfNotExists/Modify policy with remediation tasks—none of which apply here). Why “Yes” would be wrong: There is no policy effect here that triggers deallocation. Deny only blocks future VM create/update operations in RG2.

No. Modifying the address space of VNET2 is an update operation on a resource of type Microsoft.Network/virtualNetworks. The policy assigned to RG2 explicitly denies Microsoft.Network/virtualNetworks. With a deny policy in place, any PUT/PATCH that updates the VNet resource (including address space changes, DNS settings, subnets changes, etc.) will be rejected at the ARM control plane for resources in RG2. Why “Yes” would be wrong: Even though VNET2 already exists, deny policies still block updates to the denied resource type. Existing resources are not removed, but they become effectively “locked” against changes that require an update operation.

Correct answer: C (StorageV2). A StorageV2 (general-purpose v2) storage account is required to support Blob access tiers including hot, cool, and archive. It is the current recommended account type and supports the broadest set of storage features (Blob, File, Queue, Table) along with lifecycle management policies that commonly move data between tiers to optimize cost. Why the others are wrong: - A (FileStorage) is a premium-only account kind intended for Azure Files (SMB/NFS) scenarios. It does not provide the standard blob tiering model (hot/cool/archive) for Blob Storage and is not cost-minimizing. - B (Storage) refers to general-purpose v1 (GPv1). GPv1 is legacy and has feature limitations compared to StorageV2; for exam purposes, when you need modern blob tiering and best-practice capabilities, StorageV2 is the correct choice.

Correct answer: A (Standard_GRS). Standard_GRS (Geo-Redundant Storage) replicates data asynchronously to a secondary region in the paired Azure region, providing resilience if a disaster affects the primary region. This directly satisfies the requirement for fault tolerance at the regional level. Why the others are wrong: - B (Standard_LRS) only replicates within a single region (within a datacenter/zone set depending on implementation) and does not protect against a full regional outage. - C (Standard_RAGRS) includes all GRS capabilities plus read access to the secondary region. That extra read-access feature increases cost and is not required by the prompt, so it does not “minimize costs” compared to GRS. - D (Premium_LRS) is higher cost and still only locally redundant (no cross-region disaster tolerance), failing both cost and regional DR requirements.

Correct sequence (one valid order): 1) Upload a configuration to Azure Automation State Configuration 2) Compile a configuration into a node configuration 3) Check the compliance status of the node Why this is correct: To enforce ongoing consistency, Azure Automation DSC needs a DSC configuration in the Automation account. After upload/import, you must compile it to generate node configurations (MOF artifacts) that nodes can apply. Once nodes apply the configuration, you verify and continuously monitor drift using node compliance status. Why others are wrong: Assigning tags to VMs and creating a management group are governance/organization actions; they don’t create/compile/apply DSC configurations and therefore don’t directly manage configuration consistency. The only actions that represent the DSC operational lifecycle in the provided list are upload, compile, and compliance checking.

VM1 is in VNET1, and the private DNS zone adatum.com is linked to VNET1 with auto-registration enabled. Auto-registration in Azure Private DNS creates A records for the VM’s private IP address on its NIC within that VNet. VM1’s private IP is 10.1.0.4, so an A record (typically vm1.adatum.com) will be created pointing to 10.1.0.4. Why not public IP? Azure Private DNS zones are for private name resolution; auto-registration does not publish public IP addresses into a private zone. Public IPs are generally resolved via public DNS (Azure DNS public zones or external DNS providers), not via Private DNS. Why not none? Because the VM is in the linked VNet and meets the condition for auto-registration. The Windows Server DNS suffix (Adatum.com) is not required for Azure to register the record and does not change the fact that Azure registers based on the VNet link and private IP.

VM2 is also in VNET1, which is linked to the private DNS zone adatum.com with auto-registration enabled. Therefore, Azure will add an A record for VM2 that maps to its private IP address, 10.1.0.5. The configured DNS suffix inside the VM (Contoso.com) is a distractor. That setting influences how the VM’s OS appends domain suffixes during name resolution and how it may register with an on-premises DNS server if configured, but it does not determine Azure Private DNS auto-registration behavior. Azure uses the private DNS zone name (adatum.com) and the VNet link to decide where to register. Why not public IP only or both? Auto-registration does not create records for public IPs in a private DNS zone. Mixing public IPs into private zones would undermine the separation of internal vs. external name resolution and is not how the feature is designed.