At subscription Sub-Dev you open Access control (IAM) > Check access for user Tom. The pane lists only the Reader role. Tom says he deleted a VM in resource group RG-Test in Sub-Dev yesterday. What is the most likely explanation?
ACheck access lists only built-in role assignments, so a custom role that permits Microsoft.Compute/virtualMachines/delete wouldn't appear.
BReader grants read on everything plus Microsoft.Compute/virtualMachines/delete at the subscription.
CTom holds Contributor at RG-Test, and Check access at the subscription doesn't list assignments at child scopes.
DA deny assignment at Sub-Dev listed Tom under excluded principals, which granted him the delete.
CCorrect. Check access shows assignments at the current scope and inherited to it. Assignments at child scopes aren't listed.
AIncorrect. The pane lists the role assignments added with Azure RBAC at that scope, custom roles included, along with deny assignments.
BIncorrect. Reader lets you view resources but not change them. Its permission set is read-only and includes no delete action.
DIncorrect. Excluded principals are the ones a deny assignment doesn't apply to. Deny assignments only block actions; they never grant any.
Tests
1.2 Manage access to Azure resources > Interpret access assignments
Not a preview. This is question 2.09 with its full explanation, so you can judge the depth before paying.
Q 2.09 · Implement and manage storagedifficulty 3 / 5
All applications that use the storage account stcore01 authenticate with key1. You must rotate both access keys without any application losing access. Which sequence should you follow?
AUpdate applications to use key2; regenerate key1; update applications to use key1; regenerate key2.
BUpdate applications to use key2; regenerate key2; update applications to use key1; regenerate key1.
CRegenerate key2; regenerate key1; update applications to use key1.
DRegenerate key1; update applications to use key1; regenerate key2.
ACorrect. Moving applications to the secondary key first means nothing depends on key1 when you regenerate it. You then move back and regenerate key2.
BIncorrect. Regenerating key2 while the applications are pointed at it takes them offline at once, because regeneration takes effect immediately.
CIncorrect. Applications use key1, so they fail as soon as it is regenerated and stay broken until updated.
DIncorrect. Applications fail as soon as key1 is regenerated, before you update them.
VM1 runs in East US and belongs to resource group RG1, whose location is East US. You move VM1 and its disk and NIC to resource group RG2, whose location is West Europe. Both groups are in the same subscription. What is the result after the move completes?
AThe move fails because the resource groups are in different regions.
BVM1 runs in West Europe, and its resource ID is unchanged.
CVM1 still runs in East US, and its resource ID now contains RG2.
DVM1 is redeployed to West Europe with a new public IP address.
CCorrect. Moving only changes the resource group and resource ID. It doesn't alter the physical region. Update scripts and dashboards that use the old ID.
AIncorrect. A resource group's location only stores metadata. Resources in a group can be in other regions.
BIncorrect. A move doesn't change the region, and it does change the resource ID because the resource group name is part of the ID.
DIncorrect. Changing region needs a region move, for example with Azure Resource Mover; a resource group move never relocates the VM.
You create a Standard SKU public IP address and associate it with the NIC of a new web server VM. Neither the NIC nor its subnet has a network security group. Users can't reach the site on TCP 443, although IIS is running and listening. What should you do?
AChange the public IP address allocation method from Dynamic to Static, then associate the address with the NIC again.
BAssociate a network security group with the NIC or subnet and add an inbound rule that allows TCP 443.
CReplace the IP with a Basic SKU public IP, which is open by default and needs no network security group.
DSet the public IP address routing preference to Internet so that traffic reaches the VM over the ISP network.
BCorrect. Standard public IPs are secure by default and closed to inbound traffic until an NSG allows it.
AIncorrect. Standard SKU public IP addresses are always static, so there is no Dynamic setting to change. Reassociating the address does not open inbound access.
CIncorrect. Basic SKU public IPs were retired on September 30, 2025, so they cannot be created. Standard is the only SKU for new deployments.
DIncorrect. Routing preference chooses whether traffic travels over the Microsoft global network or an ISP network, which changes the path and the egress price. It does not allow inbound traffic.
Tests
4.1 Configure public IP addresses: Standard SKU secure-by-default behavior
Five months ago you created a subscription diagnostic setting that sends the activity log to workspace WS1. WS1 table retention is 180 days. A manager asks who created VM7, which was created four months ago. Where do you find this?
AA query against the AzureActivity table in WS1.
BThe resource logs of VM7 collected by a diagnostic setting.
CThe Change history tab on VM7's current activity log entries.
DThe Activity log page of the subscription in the Azure portal, filtered to VM7.
ACorrect. The activity log is the only place that records a resource's creator. The exported copy in AzureActivity is kept for the table's retention, here 180 days.
BIncorrect. Resource logs cover data-plane operations inside a resource. Creation is a control-plane event recorded in the activity log.
CIncorrect. Change history is opened from an activity log event and covers about 30 minutes around it. The creation event is older than the 90-day portal window.
DIncorrect. The portal activity log keeps events for 90 days. An event from four months ago is gone from there.