What is the Microsoft Certified: Azure Administrator Associate (AZ-104) certification?

AZ-104 is the role-based associate certification for Azure administrators. It validates that you can implement, manage, and monitor identity, governance, storage, compute, and virtual networks in a cloud environment, and that you can do that work from the Azure portal, PowerShell, the Azure CLI, and ARM templates or Bicep. It is the credential most Azure operations job descriptions ask for. Like every Microsoft role-based certification it is valid for one year and renews free through an online assessment on Microsoft Learn.

How many questions are on the AZ-104 exam and how long is it?

The exam runs for 100 minutes. Microsoft does not publish an exact question count, and candidates typically report somewhere between 40 and 60 items, including single answer multiple choice, multiple response, yes or no statement sets, ordering tasks, and one or two case studies. Every Sailor.sh mock exam gives you 50 questions in the same 100 minute window, so the pacing you practice is the pacing you face.

What is the passing score for the AZ-104 exam?

AZ-104 is scored on a scale of 1 to 1000 and you need 700 or higher to pass. Because the score is scaled, 700 does not mean 70 percent of questions answered correctly. Harder items carry more weight. Every exam in the Sailor.sh bundle totals exactly 1000 marks and reports your result against the same 700 bar, so a passing practice score means what it says.

What topics does the AZ-104 exam cover?

The skills measured as of April 17, 2026 list five domains: manage Azure identities and governance (20 to 25 percent), implement and manage storage (15 to 20 percent), deploy and manage Azure compute resources (20 to 25 percent), implement and manage virtual networking (15 to 20 percent), and monitor and maintain Azure resources (10 to 15 percent). Expect Microsoft Entra ID, Azure RBAC, Azure Policy, storage firewalls and shared access signatures, virtual machines and scale sets, containers, virtual network peering, network security groups, load balancing, Azure Monitor, and Azure Backup.

What experience do I need before taking AZ-104?

Microsoft describes the audience as administrators who are familiar with operating systems, networking, servers, and virtualization, and who can work with PowerShell, the Azure CLI, the Azure portal, ARM templates or Bicep, and Microsoft Entra ID. There is no formal prerequisite and no required exam to sit first. If you can build a virtual network, attach a virtual machine to it, and explain what a role assignment does, you are in the right place to start preparing.

Do these practice questions include the hands-on lab?

No. Microsoft may include a live lab section, and these are written practice questions rather than a simulated Azure environment, so the bundle prepares your knowledge and your pacing rather than your clicking. The honest way to cover that gap is to work through the same tasks in your own subscription. Multiple response items here are scored all or nothing, exactly as they are on the real exam, so a partly correct selection earns nothing.

How much does the AZ-104 exam cost?

The exam fee is USD 165 in most regions. Pricing is set per region and is subject to change, so confirm the amount for your country when you schedule. The exam is delivered through Pearson VUE, either online proctored or at a test center, and Microsoft Learn documentation is available inside the exam interface while your clock keeps running.

How should I prepare for the AZ-104 exam?

Start with the official AZ-104 study guide and the Microsoft Learn path, then build the things it describes in your own subscription: a hub and spoke network, a storage account behind a firewall, a scale set, a Recovery Services vault. Practice the same task twice, once in the portal and once in PowerShell or the Azure CLI, because the exam asks about both. Finish with full length mock exams under the real 100 minute limit, read the explanation for every miss, and repeat your weakest domain until you clear 700 consistently.

Microsoft Azure Administrator (AZ-104): Free Practice Test with AI Feedback

Question #1 Implement and manage virtual networking

A consultant is reviewing a hub and spoke network for a retail client. The virtual network Hub (10.0.0.0/16) hosts a shared file server. Spoke1 (10.1.0.0/16) and Spoke2 (10.2.0.0/16) are each peered with Hub in both directions, and every peering shows a status of Connected. The design contains no network virtual appliance and no VPN gateway. Virtual machines in both spokes reach the file server in Hub without trouble, but a nightly batch job on VM1 in Spoke1 cannot open a TCP connection to VM2 in Spoke2. The network security groups on both subnets allow all traffic from the VirtualNetwork service tag. The client wants VM1 and VM2 to communicate with the least additional configuration. What should the consultant do?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Create a virtual network peering directly between Spoke1 and Spoke2. Peering is a relationship between exactly two virtual networks, and nothing in this design can carry traffic from one spoke through the hub to the other. Virtual network peering is not transitive. When Spoke1 is peered with Hub and Hub is peered with Spoke2, the platform installs system routes in Spoke1 for the Hub address space and in Spoke2 for the Hub address space, but neither spoke learns a route for the other spoke. Packets from VM1 destined for 10.2.0.0/16 match no peering route and are dropped, which is exactly the symptom the batch job reports. Both spokes reaching the file server in Hub confirms that the existing peerings are healthy and Connected in both directions, so the missing piece is a path between the spokes themselves rather than a fault in what already exists. There are two supported ways to build that path. The first is an explicit peering between Spoke1 and Spoke2, created from both sides so the status reaches Connected. The address spaces 10.1.0.0/16 and 10.2.0.0/16 do not overlap, so nothing blocks it. The second is a network virtual appliance in Hub with user defined routes in each spoke that send the other spoke's prefix to the appliance, plus Allow forwarded traffic on the spoke peerings so the hub is permitted to relay packets. The scenario has no appliance and asks for the least configuration, which makes the direct peering the right call. Name resolution across the new peering still needs a private DNS zone linked to both networks, because default Azure name resolution does not span peered networks. Enabling Allow forwarded traffic on both existing peerings only permits a peered network to accept packets that did not originate in the sending network, for example traffic relayed by an appliance. It does not create routes and it does not make peering transitive, so without an appliance and user defined routes the flag changes nothing for VM1. Enabling Allow gateway transit and Use remote gateways shares a VPN or ExpressRoute gateway in Hub with the spokes for on premises connectivity. The design has no gateway to share, and gateway transit never provides spoke to spoke routing on its own. Adding a user defined route with next hop type Virtual network peering cannot be created. Virtual network peering appears only as a system route next hop type. User defined routes accept Virtual appliance, Virtual network gateway, Virtual network, Internet, or None, so the portal and CLI both reject the route as described. Key exam concept: peering connects two networks and stops there. Spoke to spoke traffic needs either a direct peering or an appliance in the hub with user defined routes and forwarded traffic allowed. The exam keeps probing whether you recognize the not transitive rule from the symptom alone.

Question #2 Manage Azure identities and governance

The platform team at example.com inherited three subscriptions from a business unit that was dissolved last quarter. The only person who held the Owner role on Sub3 has left the company, and the account was deleted during offboarding. Admin1 must assign the Contributor role on Sub3 to a new operations group before a scheduled deployment tomorrow morning. The relevant directory and subscription roles are shown below. When Admin1 opens the Subscriptions blade, Sub3 is not listed at all. Admin2 can open Access control (IAM) on Sub3 and view the existing assignments but receives an authorization error when adding one. Company policy forbids creating any additional Global Administrator accounts, and the team wants the repair to leave the least standing privilege behind once the deployment is done. What should Admin1 do first?

Principal  Microsoft Entra role    Azure role   Scope
Admin1     Global Administrator    none         none
Admin2     User Administrator      Reader       Sub3
Admin3     none                    Owner        Sub1, Sub2

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Enable Access management for Azure resources on the Microsoft Entra ID properties page, sign in again, and assign the role on Sub3. This is the elevate access procedure, and it is the only path in the scenario that gives anyone the right to write role assignments on a subscription with no remaining Owner. Microsoft Entra ID and Azure Resource Manager are two separate authorization systems. Microsoft Entra roles such as Global Administrator, User Administrator, and Privileged Role Administrator govern the directory: users, groups, licenses, and directory roles. Azure roles such as Owner, Contributor, Reader, and User Access Administrator govern subscriptions, resource groups, and resources. Holding a directory role grants nothing inside a subscription, which is why Admin1, despite being Global Administrator, cannot even see Sub3. The reverse is equally true. Admin3 owns Sub1 and Sub2 but has no rights on Sub3, because Azure role assignments are scoped and Owner on one subscription does not reach a sibling subscription. The bridge between the two systems is elevate access. A Global Administrator can set the Access management for Azure resources toggle to Yes under the tenant properties. Azure then creates a role assignment of User Access Administrator for that one user at root scope, written as a forward slash, which sits above every management group and subscription in the tenant. After signing out and back in, Admin1 can open Access control (IAM) on Sub3 and add the operations group as Contributor, or appoint a new Owner. The toggle is per user rather than tenant wide, the action is recorded in both the directory audit log and the activity log, and Microsoft's guidance is to switch it back to No as soon as the repair is complete, since a standing root scope assignment is the widest blast radius in the tenant. That matches the least standing privilege requirement in the scenario. Asking Admin3 to add Admin1 as Owner of Sub3 fails because Admin3 holds Owner only on Sub1 and Sub2. Azure role assignments do not extend sideways to other subscriptions, so Admin3 receives the same authorization error Admin2 saw when trying to write an assignment on Sub3. Assigning Privileged Role Administrator and retrying stays inside the directory. That role lets a user manage Microsoft Entra role assignments and has no effect on Azure resource permissions, so Admin1 would still not see Sub3 afterwards. Having Admin2 grant Owner because User Administrator plus Reader is enough confuses the two systems in a different way. User Administrator is a directory role, and Reader on Sub3 allows viewing role assignments but never writing them. Writing assignments needs Owner, User Access Administrator, or Role Based Access Control Administrator at that scope or above. Key exam concept: Microsoft Entra roles manage the directory, Azure roles manage resources, and neither grants the other. When every Owner of a subscription is gone, a Global Administrator elevates access to receive User Access Administrator at root scope, repairs the assignments, then removes the elevation.

Question #3 Implement and manage storage

A storage administrator at sailor.sh shares product images with three logistics partners from a single blob container named catalog in a general purpose v2 storage account. Each partner received a service SAS that was generated against its own stored access policy on that container, named partner-a, partner-b, and partner-c, each granting read permission with a twelve month expiry. Partner B has ended its contract and its SAS must stop working today. The other two partners must keep uninterrupted access, and the internal catalog application, which reads the same container with the account access key in its connection string, must not be affected in any way by the change. Which action should the administrator take?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Delete the partner-b stored access policy on the catalog container. A service SAS that references a stored access policy inherits its permissions, start time, and expiry from that policy, so removing the policy invalidates every token built on it and touches nothing else. A shared access signature is a signed set of query parameters, and Azure Storage keeps no record of the tokens that have been issued. That design is what makes revocation awkward: you cannot look up a token and cancel it. The stored access policy exists to solve this problem for service SAS tokens. Instead of embedding the constraints in the token, the token carries a policy identifier, and the service looks up the constraints on the container, file share, queue, or table each time the token is presented. Edit the policy to shrink its expiry or strip its permissions and every token that references it changes behavior immediately. Delete the policy and those tokens fail with a 403 on the next request. Up to five stored access policies can exist per container, which is why one policy per partner is a common pattern for exactly this situation. The boundaries matter for the exam. Only a service SAS can reference a stored access policy. An account SAS and a user delegation SAS must be ad hoc, meaning their constraints live in the token itself, and the only ways to kill them early are to regenerate the signing key for an account SAS or to revoke the user delegation key for a user delegation SAS. Because each partner here has its own policy, the administrator can cut Partner B off with one deletion while Partner A, Partner C, and the internal application that uses the account key continue without change. Regenerating key1 and sharing the new key with the remaining partners revokes every account and service SAS signed with key1, including the tokens held by Partner A and Partner C, and it breaks the internal application until its connection string is updated. It also hands partners a full access account key, which is far broader than the read only access they were given. Disabling Shared Key authorization and reissuing user delegation SAS tokens would stop Partner B, but it also stops the internal application that authenticates with the account key, and it forces new tokens on the two partners that were supposed to be untouched. The scenario rules out both side effects. Editing the expiry parameter inside Partner B's SAS URI produces a token whose signature no longer matches its parameters, so Azure Storage rejects the edited URI, but the original token Partner B already holds keeps working until its real expiry. Tokens are not tracked server side, so nothing you do to a copy affects the copy the partner has. Key exam concept: a service SAS tied to a stored access policy can be revoked by editing or deleting the policy, while ad hoc tokens can only be revoked by regenerating the key that signed them. The exam tests whether you reach for the policy before the key.

Question #4 Deploy and manage Azure compute resources

An enterprise migration team at example.com maintains the resource group rg-app in East US. The group currently contains a virtual network named vnet-app, a storage account named stapp01, a virtual machine named vm-jump together with its network interface and managed OS disk, and a Log Analytics workspace named law-app. The virtual machine is the team's only jump host into the environment. A new engineer edits the ARM template so that it declares only vnet-app and stapp01, using property values identical to the deployed resources, and then runs the following command from Azure Cloud Shell. No resource locks exist on the group, and the engineer skipped the what-if operation because the change looked harmless. The deployment completes with the provisioning state Succeeded. What is the state of rg-app after the deployment finishes?

az deployment group create \
  --resource-group rg-app \
  --template-file main.json \
  --mode Complete

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: vm-jump, its network interface, its managed disk, and law-app are deleted, while vnet-app and stapp01 remain. Complete mode instructs Resource Manager to make the resource group match the template, and matching means removing what the template does not declare. Every resource group deployment runs in one of two modes. Incremental, the default, creates or updates the resources in the template and leaves everything else in the group untouched. Complete does the same create and update work but then deletes any resource in the target resource group that the template does not mention. The rule operates on resource identity, not on whether the resource is in use or important: the virtual machine, its network interface, its managed disk, and the Log Analytics workspace are each top level resources absent from the template, so each is removed. The virtual network and storage account are declared with unchanged property values, so Resource Manager takes no action on them and they survive. Several details set the boundaries of this behavior. Complete mode works only at resource group scope through a root level template, it is not offered in the portal custom deployment experience, and a lock on the resource group prevents the deletions. Some child resource types are not deleted when omitted unless their parent is also omitted, but the network interface and disk are not child resources of the virtual machine. They are peer resources that the machine references, so they are eligible for deletion. Microsoft now recommends running the what-if operation before any Complete deployment and, for planned deletions, using deployment stacks rather than Complete mode, which the documentation describes as being gradually deprecated. The exam still expects you to predict the outcome shown here. All five resources remain because incremental behavior applies to existing resources confuses the two modes. Incremental would have produced that result, but the command explicitly passed Complete, and Complete evaluates every resource in the group against the template regardless of whether it existed before the deployment. The deployment fails validation because every existing resource must be in the template invents a safeguard that does not exist. Validation checks template syntax and provider level errors, not whether omitted resources are acceptable to delete. The deployment succeeded, which is exactly the danger of this mode. Only vm-jump and law-app are deleted while the interface and disk remain as child resources misclassifies the dependent resources. Network interfaces and managed disks live under Microsoft.Network and Microsoft.Compute as their own top level types, so Complete mode deletes them along with the virtual machine. Key exam concept: incremental adds and updates, Complete adds, updates, and deletes what is missing from the template at resource group scope. Run what-if first, and prefer deployment stacks when deletion is the goal.

Question #5 Monitor and maintain Azure resources

An administrator at a small consultancy is setting up Azure Backup for the first time. The environment includes several Azure virtual machines, a set of Azure managed disks that are not attached to those machines, and two blob containers in a storage account. Which of these workloads must be protected by a Backup vault rather than a Recovery Services vault?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: The Azure managed disks and the blob containers only. Those two workloads are protected by the newer Backup vault, while Azure virtual machines are protected by a Recovery Services vault. Azure Backup uses two vault types, and the exam expects you to route each workload to the right one. A Recovery Services vault is the original vault. It protects Azure virtual machines, SQL Server and SAP HANA databases running inside Azure virtual machines, Azure Files shares, and on premises machines through the Microsoft Azure Recovery Services agent, Azure Backup Server, and System Center Data Protection Manager. It is also the vault that Azure Site Recovery uses for replication and failover. A Backup vault is the newer entity built for workloads that were onboarded later: Azure Blobs, Azure Disks, Azure Database for PostgreSQL, and Azure Kubernetes Service, among others. The two vault types share the same management experience through Azure Business Continuity Center, but they are separate resource types with separate policies and cannot substitute for each other. Mechanically the split shows up at protection time. When you configure backup for a managed disk or for blob containers, the wizard asks for a Backup vault and one of its backup policies, and a Recovery Services vault does not appear in the list. When you enable backup on a virtual machine, only Recovery Services vaults in the same region are offered. Both vault types let you choose storage redundancy, but the choice must be made before the first item is protected, because it is locked once backup data exists. Both support soft delete and immutability settings, and neither can be deleted while it still holds protected items, so cleanup always starts with stopping protection. The Azure virtual machines only reverses the mapping. Virtual machine backup is the classic Recovery Services vault workload, and it has not moved to the Backup vault. The Azure virtual machines and the managed disks only gets disks right but also drags virtual machines into the Backup vault, which is not supported, and leaves out blobs, which do require a Backup vault. All three workloads because Backup vault replaces Recovery Services vault assumes one vault type superseded the other. Both are current products with different workload lists, and Recovery Services vaults remain the only option for virtual machines, files, and Site Recovery. Key exam concept: virtual machines, SQL and SAP HANA in virtual machines, Azure Files, MARS, MABS, and Site Recovery go to a Recovery Services vault. Blobs, disks, PostgreSQL, and AKS go to a Backup vault. When a question mixes workloads, sort them by vault type before picking an answer.

Question #6 Manage Azure identities and governance

A startup that recently moved to Microsoft 365 has 240 employees in its Microsoft Entra tenant, all synchronized from Windows Server Active Directory with the department attribute populated for every user. The tenant holds Microsoft Entra ID P1 licenses for all users and a pool of Microsoft 365 E3 licenses that is large enough for the sales organization. The IT lead wants every user whose department attribute equals Sales to receive a Microsoft 365 E3 license automatically. That includes people who join the Sales department next month, who should be licensed as soon as their attribute is synchronized, and people who transfer out of Sales, who should lose the license without anyone opening an admin center. Nobody on the two person IT team should have to add or remove group members by hand, and the solution must not depend on a script that runs on a schedule. Which two actions should the IT lead perform? Each correct answer presents part of the solution. (Select TWO)

Pick two answers to reveal the explanation.

Why this is correct

Correct answers: create a security group with dynamic user membership using the rule user.department -eq "Sales", and assign the Microsoft 365 E3 license to that group from the Licenses page. The dynamic rule keeps membership current without human intervention, and the group license assignment turns membership into a license automatically. Dynamic membership groups in Microsoft Entra ID evaluate a rule against user attributes. Whenever an attribute changes, the directory evaluates every dynamic rule again, adds users who now match, and removes users who no longer do. The rule user.department -eq "Sales" therefore captures new Sales hires as soon as their synchronized department value lands in the tenant, and drops transfers as soon as the value changes. Members of a dynamic group cannot be added or removed by hand, which is a feature here rather than a limitation. Each unique user who belongs to at least one dynamic group needs a Microsoft Entra ID P1 license, and the scenario confirms the tenant already holds P1 for everyone. A security group is the natural choice because it is the lightest group type and can hold either users or devices, though a Microsoft 365 group with dynamic membership could also receive a license. Group based license assignment completes the chain. When a license is assigned to a group, every current and future member inherits it, and a user who leaves the group loses the inherited license during the next processing pass. Licenses inherited from a group are marked as such on the user, and any service plans toggled off at the group level apply to every member. Errors such as not enough licenses or conflicting service plans surface per user on the group's license page, which is where an administrator looks when a member unexpectedly has no license. Nested groups are not supported, so the licensed group must contain the users directly, which the dynamic rule guarantees. A Microsoft 365 group with assigned membership populated from a CSV file handles today's Sales users but nothing after that. Assigned membership never changes on its own, so joiners and leavers would still require someone to edit the group, which the scenario rules out. An administrative unit that contains the Sales users with the license assigned to it mixes up two features. Administrative units scope the reach of directory role holders, they are not license targets, and the Licenses page does not offer them as an assignee. Assigning the license directly to each Sales user with Set-MgUserLicense works once but is manual by definition. Keeping it current would need a scheduled script to compare department values and add or remove licenses, which the scenario explicitly forbids. Key exam concept: dynamic membership needs Microsoft Entra ID P1 and reacts to attribute changes on its own, and a license assigned to a group follows membership. Direct licensing and assigned groups both require ongoing manual work.

Question #7 Implement and manage virtual networking

An SRE at sailor.sh is investigating why a web tier virtual machine named VM1 in Subnet1 of VNet1 has become unreachable after a security review. VM1 has a Standard SKU public IP address. A network security group named NSG-Subnet is associated with Subnet1, and a second group named NSG-NIC is associated with the network interface of VM1. Both groups still carry their default rules. The custom inbound rules are listed below. A customer on the Internet opens an HTTPS connection to the public IP address of VM1, and an administrator working from 203.0.113.10 starts an RDP session to the same public IP address. The guest operating system firewall is turned off and the web server is listening on port 443. What is the result of the two connection attempts?

NSG-Subnet (inbound)
Priority  Name         Source         Port   Protocol  Action
100       Allow-HTTPS  Internet       443    TCP       Allow
200       Deny-RDP     Any            3389   TCP       Deny

NSG-NIC (inbound)
Priority  Name         Source         Port   Protocol  Action
100       Allow-RDP    203.0.113.10   3389   TCP       Allow

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Both connections fail. The HTTPS request is admitted by the subnet group and then denied by the default rule in the network interface group, and the RDP request is denied by the subnet group before the interface group ever sees it. Inbound traffic to a virtual machine is evaluated by the network security group on the subnet first and then by the network security group on the network interface, and both must allow the flow. Each group is processed in priority order, lowest number first, and the first matching rule decides the outcome for that group. Every group also carries three default inbound rules that cannot be removed: AllowVnetInBound at 65000, which allows sources in the VirtualNetwork service tag, AllowAzureLoadBalancerInBound at 65001, and DenyAllInBound at 65500, which drops everything else. Custom rules take numbers from 100 to 4096, so they always sit ahead of the defaults. Trace the HTTPS flow first. NSG-Subnet matches Allow-HTTPS at priority 100 and passes the packet on. NSG-NIC has no custom rule for port 443. The source is a public Internet address, so it does not match the VirtualNetwork tag at 65000, it does not match the AzureLoadBalancer tag at 65001 either, and DenyAllInBound at 65500 drops it. Now trace RDP from 203.0.113.10. NSG-Subnet has no allow rule for 3389 ahead of Deny-RDP at 200, so the subnet group denies the packet. Evaluation stops there, and the Allow-RDP rule on NSG-NIC is never consulted. The lesson is that an allow in one group cannot compensate for a deny in the other, and a rule in the second group cannot rescue a packet the first group dropped. The fix is an allow for 443 on the interface group and an allow for 3389 from 203.0.113.10 on the subnet group with a number below 200, or better, Azure Bastion instead of an exposed RDP port. Both connections succeed assumes that one matching allow anywhere is enough. Inbound filtering requires both groups to allow, and the interface group has no rule for 443 while the subnet group actively denies 3389. HTTPS succeeds and RDP fails gets the RDP half right but forgets the second group on the HTTPS path. The default DenyAllInBound on NSG-NIC applies because nothing earlier in that group matches Internet traffic on 443. RDP succeeds and HTTPS fails reads the Allow-RDP rule on the interface as decisive. The subnet group runs first for inbound traffic and its Deny-RDP rule ends the evaluation before the interface group gets a turn. Key exam concept: inbound is subnet then NIC and both must allow, outbound is NIC then subnet and both must allow. Lower priority numbers win within a group, and the default DenyAllInBound catches whatever no custom rule admits. Network Watcher IP flow verify names the exact rule that made the decision.

Question #8 Deploy and manage Azure compute resources

A freelance developer is moving a customer facing web application for a small bakery chain to Azure App Service. The customer listed three requirements before go live: the application must answer on the custom domain shop.example.com with a TLS binding, new releases must be validated in a staging deployment slot and then swapped into production without downtime, and the plan must scale out automatically from one to four instances whenever average CPU stays above 70 percent during weekend promotions. Cost matters to the customer, so the developer wants the least expensive pricing tier that satisfies all three requirements without relying on any manual scaling. Which App Service plan tier should the developer choose?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Standard S1. It is the lowest tier that offers deployment slots and autoscale, and it also covers the custom domain with a TLS binding. App Service features are gated by pricing tier, and the exam repeatedly asks for the cheapest tier that unlocks a specific set of them. Free runs on shared compute with no custom domain support. Shared adds custom domains, but it cannot bind a TLS certificate to them and still cannot scale out beyond its single shared instance. Basic moves to dedicated compute, supports custom domains and TLS bindings, and can be scaled out manually to three instances, but it has no deployment slots and no autoscale. Standard is the first tier with deployment slots, five per app, with autoscale rules driven by metrics or schedules, and with scale out to ten instances. Premium v3 raises those limits to twenty slots and thirty instances and adds capabilities such as larger memory sizes and zone redundancy, at a higher price. Isolated v2 runs inside an App Service Environment for network isolation and is the most expensive of all. Map the three requirements to that ladder. The custom domain itself is available from Shared upward, but a TLS binding for it needs Basic or higher, because Free and Shared do not support custom domain SSL. The staging slot with a swap into production needs Standard or higher. Automatic scale out from one to four instances on a CPU rule is autoscale, which also begins at Standard, and four instances sit inside the Standard limit of ten. Standard S1 therefore meets every requirement and nothing cheaper does. Keep the vocabulary straight while you work: scaling up means changing tier or instance size, scaling out means adding instances, and autoscale is the rule engine that performs scale out and scale in on your behalf based on metrics or a schedule. Basic B1 supports the custom domain with a TLS binding and could be scaled out by hand to three instances, but it has no deployment slots and no autoscale, so two of the three requirements fail. Premium v3 P1v3 satisfies everything and adds headroom the customer did not ask for. Because the question asks for the least expensive tier that meets the requirements, choosing Premium ignores the cost constraint. Shared D1 can host the custom domain name, but it runs on shared compute with a CPU quota, cannot scale out at all, and has no slots. It also cannot bind a certificate to shop.example.com, so the TLS requirement fails before scaling is even considered. Key exam concept: custom domains start at Shared, TLS bindings, dedicated compute, and manual scale out start at Basic, deployment slots and autoscale start at Standard, and the larger slot and instance counts belong to Premium. Match the most demanding requirement to the lowest tier that unlocks it.

Question #9 Implement and manage storage

A data engineering team at example.com stores application logs as block blobs in a general purpose v2 storage account whose default access tier is hot. Last access time tracking is not enabled on the account. The team applied the following lifecycle management policy 60 days ago, has not changed it or the account default tier since, and the policy has run normally every day. A blob at logs/2026/03/app.log was uploaded 100 days ago and has not been modified since, although a support engineer downloaded it successfully 40 days ago. A second blob at audit/2026/03/app.log was uploaded on the same day and has also never been modified. Both blobs live in containers named after the first path segment. What is the current state of the two blobs?

{
  "rules": [
    {
      "enabled": true,
      "name": "age-out-logs",
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "logs/2026" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 },
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: the blob in the logs container is in the archive tier and offline, while the blob in the audit container is still in the hot tier. The rule's prefix filter selects only the logs container, and inside it the archive action is the one whose threshold the blob has passed. A lifecycle management policy is a list of rules, and each rule combines filters with actions. The filter here restricts the rule to block blobs whose path starts with logs/2026, and a prefix in a lifecycle policy is written as the container name followed by a slash and the beginning of the blob name. The blob at logs/2026/03/app.log matches, the blob at audit/2026/03/app.log does not, so the second blob is never evaluated and stays in the account default tier of hot. The engine runs on its own schedule roughly once a day, and a policy change can take up to 24 hours to take effect, but sixty days of normal operation is far more than enough for the actions to have fired. For the matching blob, three actions are defined on the base blob keyed to days since last modification. At day 30 the blob became eligible for cool, and at day 90 it became eligible for archive. When a blob satisfies more than one action in the same rule, lifecycle management applies the least expensive outcome, so a blob that passes both the cool and archive thresholds lands in archive, not cool. Delete would take over at day 365. Archive is an offline tier: the data is retained, but any attempt to read or download the blob fails until it is rehydrated to hot, cool, or cold, which can take up to fifteen hours at standard priority. The download 40 days ago happened while the blob sat in cool, an online tier, and with last access time tracking disabled that read had no effect on tiering at all. Both blobs archived and awaiting rehydration ignores the prefix filter. Lifecycle rules act only on blobs that match every filter in the rule, and a blob in a different container has no prefix in common with logs/2026. The logs blob returned to hot by the download and the audit blob in cool assumes reads move blobs. Automatic tiering back to hot on access is a separate action that requires last access time tracking, which is off, and the audit blob was never in scope for any action. The logs blob in cool because only the first exceeded action applies misreads how multiple actions resolve. The engine does not stop at the first threshold, it applies the cheapest tier the blob qualifies for, which at day 100 is archive. Key exam concept: filters decide which blobs a rule sees, thresholds decide which action applies, and the cheapest qualifying action wins. Archive is offline and needs rehydration, and last access rules only work when access tracking is enabled.

Question #10 Deploy and manage Azure compute resources

Azure Container Instances does not automatically add container group instances in response to rising CPU or memory load, so serving more traffic requires deploying additional container groups yourself or moving the workload to a service such as Azure Container Apps.

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: True. Azure Container Instances runs container groups as fixed units, and the service has no built in autoscale, so more capacity means more container groups or a platform that scales for you. A container group in Azure Container Instances is a set of one or more containers scheduled on the same host, sharing a lifecycle, a local network, and storage volumes. You size it by declaring CPU cores and memory for each container, and the group receives exactly those resources for as long as it runs. Nothing in the service watches CPU or memory utilization and launches additional groups when demand rises. Microsoft's own comparison states that concepts like scale, load balancing, and certificates are not provided with Container Instances, and that scaling to five instances means creating five distinct container instances. Container Instances is deliberately a lower level building block: fast to start, billed per second, and well suited to batch jobs, build agents, and bursts of isolated work where a fixed size is acceptable. When a workload needs elastic capacity, the administrator has two realistic paths. The first is to script the creation and deletion of container groups, for example from an automation runbook, or to let Azure Kubernetes Service virtual nodes burst pods onto Container Instances. The second, and the one the exam steers toward, is Azure Container Apps. Container Apps runs replicas of a container between a minimum and maximum count that you set, and it scales those replicas with rules based on HTTP concurrency, TCP connections, CPU, memory, schedules, or event sources such as queues, using KEDA under the hood. It can scale to zero replicas when idle, supports revisions and traffic splitting, and provides ingress with certificates, all of which Container Instances lacks. False would require Container Instances to add container groups on its own when load climbs. That capability does not exist, and candidates who mark the statement false are usually remembering the replica scaling of Container Apps, or the autoscale settings of virtual machine scale sets and App Service, and attributing them to the wrong service. A restart policy on a container group governs what happens when a container exits, not how many groups run. Key exam concept: Container Instances sizes each container and runs a fixed container group, Container Apps scales replicas between a minimum and maximum with rules and can scale to zero. When a scenario says demand varies and mentions containers, Container Apps is the scaling answer.

Question #11 Monitor and maintain Azure resources

An operations engineer at example.com owns forty metric and log search alert rules that target virtual machines across a single subscription. Every Saturday between 22:00 and 02:00 the database team patches the six virtual machines in the resource group rg-db, and the engineer on call receives a burst of CPU and heartbeat alert emails from those machines during the window. The engineer wants to stop the notifications for rg-db during that window only, keep every alert rule unchanged so the other virtual machines remain covered by the same rules, and still be able to see in the portal afterwards that the alerts fired. What should the engineer configure?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: An alert processing rule scoped to rg-db with a recurring weekly schedule that suppresses notifications. The rule strips the action groups from alerts that fire on those six machines during the window, leaves every alert rule intact, and keeps the fired alerts visible in the portal. Azure Monitor separates the decision to fire an alert from the decision to notify someone. Alert rules evaluate a metric, a log query, or the activity log and create a fired alert when the condition is met. Action groups define who is told and how, through email, SMS, voice, push, webhooks, runbooks, or functions. Alert processing rules sit between the two: they apply to alerts that have already fired within a scope and either remove all action groups from them, which is the suppression action, or add action groups to them. The scope can be a subscription, one or more resource groups, or individual resources, and filters narrow it further by severity, alert rule, resource type, or monitor condition. A schedule can make the rule active once, on a recurrence such as every Saturday from 22:00 to 02:00 in a chosen time zone, or all the time. Suppression does not stop the alert from firing. The alert still appears in the Alerts page, in Azure Resource Graph, and through the API, with its state and condition tracked as usual. Only the notifications and automated actions are withheld. That is precisely the outcome the engineer asked for: silence for the six machines in rg-db during patching, full coverage for the other machines the same rules watch, and a visible record of what fired. Because the rule targets the resource group rather than the alert rules, it also catches alerts that are not created by an alert rule at all, such as Azure Backup alerts. A newly created rule can take up to 30 minutes to start processing alerts, so it is worth creating it well before the first window. Swapping a silent action group into the alert rules every Saturday means editing forty rules twice a week and, because most of those rules also cover machines outside rg-db, silencing alerts for resources that are not under maintenance. Action groups define recipients, they do not carry a schedule or a scope. Disabling the alert rules for rg-db with a runbook fails on two counts. Rules that target the whole subscription cannot be disabled for one resource group, so the other machines lose coverage, and a disabled rule does not fire at all, so nothing is visible in the portal afterwards. Adding a schedule condition to each alert rule describes a setting that does not exist. Alert rules have an evaluation frequency and a lookback period, not a maintenance calendar. Schedules live on alert processing rules. Key exam concept: alert rules decide when an alert fires, action groups decide who is notified, and alert processing rules modify fired alerts on a scope and schedule by suppressing or adding action groups. Suppression hides notifications, never the alert itself.

Question #12 Manage Azure identities and governance

A governance lead at sailor.sh must make sure every virtual machine in subscription Sub1 carries a tag named costCenter with the value 2040, both for the 300 virtual machines that already exist and for any created later. The lead wrote a custom policy definition whose rule is shown below and assigned it at the subscription scope with az policy assignment create, supplying only the assignment name, the scope, and the definition. A day later the compliance view lists all 300 existing machines as non compliant, none of them has received the tag, and the Remediation page shows the assignment with no identity attached. The lead must get the tag onto the existing machines without editing each one by hand and without weakening the rule for machines created in the future. Which two actions should the lead take? Each correct answer presents part of the solution. (Select TWO)

"policyRule": {
  "if": {
    "allOf": [
      { "field": "type", "equals": "Microsoft.Compute/virtualMachines" },
      { "field": "tags['costCenter']", "exists": "false" }
    ]
  },
  "then": {
    "effect": "modify",
    "details": {
      "roleDefinitionIds": [
        "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
      ],
      "operations": [
        { "operation": "addOrReplace", "field": "tags['costCenter']", "value": "2040" }
      ]
    }
  }
}

Pick two answers to reveal the explanation.

Why this is correct

Correct answers: assign a managed identity to the policy assignment and grant it the role listed in roleDefinitionIds, and create a remediation task for the assignment. The Modify effect only rewrites requests as they arrive, so existing machines are marked non compliant and stay untouched until a remediation task, running as the assignment's identity, applies the operations to them. Azure Policy evaluates resources in two situations. When a resource is created or updated, the policy engine inspects the request before the resource provider handles it, and effects such as Deny, Append, and Modify act on that request. During a compliance evaluation cycle, which runs on a schedule and after each assignment change, the engine inspects resources that already exist and records their compliance state, but it does not change them. A Modify policy therefore tags new virtual machines at creation and reports the 300 existing machines as non compliant without adding a tag to any of them. That behavior is by design, because changing existing resources requires an identity that Azure can act as, and evaluation runs with no such identity. Remediation supplies both pieces. The policy assignment must carry a managed identity, either system assigned or user assigned, and that identity must hold the roles named in the definition's roleDefinitionIds, in this case Contributor, at a scope that covers the resources. The portal creates the identity and grants the role automatically when you assign a Modify or DeployIfNotExists policy through the wizard, but an assignment created with the CLI, PowerShell, or an SDK needs the identity added and the role granted explicitly. A remediation task then walks the non compliant resources in scope and applies the addOrReplace operation to each one, writing the costCenter tag with the value 2040. The task can be created from the Remediation page, from the compliance view of the assignment, or with az policy remediation create, and its progress and any per resource errors are visible on the Remediation tasks tab. Changing the effect to Deny would block future untagged machines from being created or updated but would do nothing for the 300 that already exist. Deny only ever evaluates requests, and existing resources are simply reported as non compliant. Tagging the resource groups so the machines inherit the tag relies on inheritance that Azure tags do not have. A tag on a resource group applies to the group object only, and the machines inside remain untagged and non compliant. Creating a policy exemption for the existing machines removes them from evaluation so they no longer show as non compliant, but it leaves them without the tag, which defeats the requirement that every machine carries the cost center. Key exam concept: Deny, Audit, and Modify at request time govern new and updated resources, existing resources are only flagged, and Modify or DeployIfNotExists policies fix them through a remediation task that runs as the assignment's managed identity with the roles in roleDefinitionIds.

Question #13 Deploy and manage Azure compute resources

A platform engineer at example.com supports a two node application tier in the resource group rg-erp. VM1 and VM2 are both Standard_D4s_v3 machines in the availability set AS1, created two years ago, each with a Premium SSD OS disk and a static private IP address on its network interface. A performance review shows that VM1 needs more memory, and the application vendor has certified the Standard_E8ds_v5 size. When the engineer opens the Size blade of VM1 while it is running, Standard_E8ds_v5 is not offered, and stopping VM1 and refreshing the list still does not show it, although the size is available in the region and the subscription has quota for the E family. The application tolerates a short maintenance window outside business hours, but the vendor requires both nodes to remain in AS1 and to keep their private IP addresses. What should the engineer do to resize VM1 with the least disruption that still succeeds?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Deallocate both VM1 and VM2, resize VM1, then start both machines. When the target size is not available on the hardware cluster that hosts an availability set, every machine in the set must be deallocated so the whole set can be placed on a cluster that offers the size. Resizing a virtual machine changes its size property and reboots it if it is running. In the simple case the new size is available on the physical cluster where the machine currently lives, and the resize completes with only that restart. When the size is not available on the current cluster, the machine must be deallocated so that the platform can allocate it on a different cluster when it starts again, which is why the portal advises stopping a machine to reveal more sizes. An availability set adds a constraint on top of this: all machines in the set are placed together on one cluster so that their fault and update domains have meaning. A single deallocated member cannot be moved to a new cluster on its own, because it must start on the same cluster as its running partner. The documented procedure is therefore to deallocate every machine in the set, resize the one you need, and start them all, at which point the whole set lands on a cluster that supports the new size. The other members may also need resizing afterwards if their old size is not offered on the new cluster. The rest of the constraints in the scenario are satisfied by this approach. The set membership never changes, the network interfaces and their static private addresses are untouched, and the Premium SSD disks stay attached. Sizes with an s in the name support Premium storage, and Standard_E8ds_v5 qualifies. The d in the name marks a local temp disk, which the current Dsv3 size also has, so the resize never crosses the boundary between a size with a temp disk and a diskless size, a boundary that a Windows machine cannot cross with a plain resize. Quota is checked per family per region, and the scenario confirms the E family has room. Deallocating both nodes does mean a short outage, which the maintenance window covers. Deallocating VM1 only and resizing from the Size blade is what the engineer effectively already tried by stopping VM1, and the size still did not appear. The set pins VM1 to the cluster where VM2 is running, so VM1 alone cannot reach a cluster with the E family. Deleting VM1 and recreating it from its OS disk inside AS1 is the most disruptive path. It means rebuilding the machine configuration, extensions, and identity, and a new member still has to be placed on the cluster where VM2 runs, so the size problem may simply return. The question asks for the least disruption that succeeds. Removing VM1 from AS1 and adding it back later is not possible. Availability set membership is fixed at creation time, so a machine cannot leave or join a set afterwards without being recreated. Key exam concept: a resize restarts the machine, an unavailable size needs deallocation, and an unavailable size for a member of an availability set needs every member deallocated. Availability set and zone placement cannot be changed after creation.

Question #14 Implement and manage storage

A storage administrator at sailor.sh manages a general purpose v2 account named stfinance01 that holds an SMB file share used by the finance team. Public network access on the account is set to Enabled from selected virtual networks and IP addresses, with one virtual network rule for Subnet1 of VNet1, where the Microsoft.Storage service endpoint is enabled, and no IP rules. A site to site VPN connects the head office network 192.168.10.0/24 to VNet1 through a VPN gateway, and the finance team's workstations on that network must mount the share. Their mount attempts fail with an access denied error even though the users hold the Storage File Data SMB Share Contributor role, while the same users succeed from a virtual machine in Subnet1. The administrator tried adding 192.168.10.0/24 as an IP network rule and the portal rejected it. The security team refuses to open the account to any public address range. What should the administrator do?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Create a private endpoint for the file service of stfinance01 in VNet1 and configure on premises DNS to resolve the account name to the private endpoint address. A private endpoint gives the file service an address inside VNet1 that the VPN already routes to, and it is not subject to the public endpoint firewall that is blocking the finance team. The storage firewall controls access to the public endpoint of the account and allows exactly three kinds of sources: subnets with a service endpoint, public IP ranges, and trusted or resource instance exceptions. A service endpoint works by changing the source address of traffic leaving an Azure subnet to a private address that the storage service recognizes, which is why the virtual machine in Subnet1 succeeds. Traffic from head office to the account's public endpoint never passes through Subnet1 at all. The site to site tunnel carries only the VNet1 prefixes, so the SMB request leaves through the head office Internet connection and reaches the public endpoint from a source the firewall does not recognize, and it is denied. An IP network rule for the head office private range cannot help either, because IP rules accept only public Internet ranges and reject private ranges such as 192.168.10.0/24, which is the rejection the administrator saw. A private endpoint takes a different path. It is a network interface in a subnet of VNet1 with a private address from the virtual network's range, connected to one target service of the account, here the file service, through Azure Private Link. Any client that can route to VNet1, including on premises clients over a site to site VPN or ExpressRoute private peering, can reach that address, and the public endpoint firewall does not apply to traffic through it. The prerequisite that trips up real deployments is DNS. The account name must resolve to the private endpoint address, which Azure handles inside the virtual network with the privatelink.file.core.windows.net zone, but head office resolvers need a conditional forwarder to that zone or a matching record so that the SMB mount targets the private address. Port 445 must also be allowed across the VPN, which the successful Subnet1 test does not prove, so the administrator should confirm it with the network team. Enabling the service endpoint on the GatewaySubnet misunderstands what a service endpoint does. It applies to traffic originating from virtual machines in that subnet, and the VPN gateway does not source the finance team's SMB traffic. On premises clients never benefit from a service endpoint. Adding the head office public IP address as an IP rule is the documented way to admit on premises clients that reach the public endpoint through their Internet facing address, and the finance workstations would reach it that way because the VPN carries only the VNet1 prefixes. It fails this scenario on the stated constraint: it opens the account to a public address range, which the security team has ruled out, and SMB on port 445 across the Internet is commonly blocked by ISPs, so it would be neither permitted nor reliable. Turning on the trusted Microsoft services exception admits a fixed list of Azure services such as Backup and Monitor that operate outside your network. It has no effect on user workstations, whether on premises or in Azure. Key exam concept: service endpoints keep the public endpoint and only work for Azure subnets, IP rules accept public addresses only, and private endpoints give the service a private address reachable from peered networks and on premises, with DNS as the mandatory companion.

Question #15 Implement and manage virtual networking

A security team at example.com has decided to remove every public IP address from the twelve Windows and Linux administration servers in VNet1 (10.10.0.0/16) and to require Azure Bastion for all RDP and SSH access. The team wants the Standard SKU so that administrators can keep using their native RDP and SSH clients and so that the number of Bastion instances can be scaled up later as the environment grows. VNet1 currently has two subnets, Servers (10.10.1.0/24) and Management (10.10.2.0/27), plus a network security group on Servers that allows 3389 and 22 only from the Management subnet. The team would prefer to reuse the existing Management subnet for the deployment if the platform allows it, and it has not yet created any other resources for the project. Which two configuration items are required before the Bastion host can be deployed? Each correct answer presents part of the solution. (Select TWO)

Pick two answers to reveal the explanation.

Why this is correct

Correct answers: a subnet named AzureBastionSubnet with a prefix of /26 or larger in VNet1, and a Standard SKU public IP address with static allocation for the Bastion host. Those two resources are the fixed prerequisites for every dedicated Bastion deployment, and the Standard SKU the team wants adds nothing beyond them. Azure Bastion in the Basic, Standard, and Premium SKUs is a managed platform service deployed into your own virtual network. It needs a dedicated subnet whose name is exactly AzureBastionSubnet and whose size is /26 or larger, and that subnet cannot host anything else. The size floor exists because the service scales by adding instances, and host scaling, which the team plans to use, needs address space for those instances. The existing Management subnet fails on both counts: its name is wrong and a /27 is too small, so the team must add a new subnet. The host also needs a public IP address in the same region with the Standard SKU and static allocation. Administrators connect to that public address over TLS on port 443 from the portal or, on the Standard SKU and above, from native RDP and SSH clients, and Bastion opens the RDP or SSH session to the target machine's private address from inside the virtual network. Two things are notably not required. The target servers do not need public IP addresses, which is the entire point of the service, and their network security group does not need to admit RDP or SSH from the Internet. The target subnet only needs to allow 3389 and 22 from the AzureBastionSubnet range, and the existing rule that allows those ports from the Management subnet will need to be extended to the new Bastion subnet. The Developer SKU is the one exception to the subnet and public IP requirements because it runs on shared infrastructure, but it supports one connection at a time and lacks native client support, so it does not fit the scenario. A public IP address on each administration server reverses the design goal. Bastion reaches targets by private address, and the security team is removing public addresses precisely so that RDP and SSH are never exposed. A rule that allows 3389 and 22 from the Internet on the Servers subnet would reopen the exposure Bastion is meant to eliminate. The required rule allows those ports from the AzureBastionSubnet address range, not from the Internet tag. A Basic SKU public IP with dynamic allocation is not accepted by the service, and the Basic public IP SKU itself was retired in September 2025. Bastion requires the Standard SKU and static allocation. Key exam concept: AzureBastionSubnet at /26 or larger plus a Standard static public IP are the prerequisites, targets keep only private addresses, and the target subnet allows RDP and SSH from the Bastion subnet. Native client, host scaling, and shareable links need Standard, session recording needs Premium.

Question #16 Monitor and maintain Azure resources

An SRE at sailor.sh has connected the activity log of every subscription to a single Log Analytics workspace with diagnostic settings, and the AzureActivity table has been receiving records for a month. After a night of failed deployments, the SRE wants a single result table that shows, for the last 24 hours, how many operations ended with a status of Failed in each resource group, with the resource group that had the most failures at the top. The draft query is shown below with one line missing. The result must contain exactly two columns, the resource group name and the number of failed operations, and it must run without errors in the Logs blade of the workspace. Which line should replace MISSING LINE?

AzureActivity
| where TimeGenerated > ago(24h)
| where ActivityStatusValue == "Failed"
| MISSING LINE
| sort by count_ desc

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: summarize count() by ResourceGroup. The summarize operator collapses the filtered records into one row per resource group, its unnamed count() aggregation lands in a column called count_, and that is the exact column the final sort line references. A Kusto query is a pipeline. Each line takes the table produced by the line above and transforms it. The first two where clauses keep records from the last 24 hours whose ActivityStatusValue is Failed, which is the display friendly status column in the AzureActivity table alongside values such as Started, Succeeded, and In Progress. At that point the pipeline still holds one row per activity log record with dozens of columns. Turning rows into a count per group is the job of summarize. Its aggregation function, count(), runs once per distinct value of the columns named after the by keyword, and the output contains only the grouping columns and the aggregation result. When you do not name the aggregation, Kusto derives the column name from the expression, so count() becomes count_, and column names are case sensitive, which is why the last line references count_ rather than Count or count. You can override that default by writing a name in front of the function, for example FailedOps = count(), but then every later operator must use the name you chose, and a downstream line that still says count_ fails with a column resolution error. Every option in this item is valid Kusto, so the elimination has to come from the two constraints in the stem rather than from syntax. Ask three questions of each candidate line: how many rows does it leave, how many columns does it produce, and what are those columns called. The requirement is one row per resource group, exactly two columns, and a column named count_ for the visible sort line to use. Only the unnamed count grouped by ResourceGroup alone satisfies all three. This is how the real exam frames missing line items: the visible lines around the gap constrain the answer as much as the requirement text does. summarize count() by ResourceGroup, OperationNameValue runs cleanly and even sorts correctly, which is what makes it tempting, but it produces three columns and one row per combination of resource group and operation. A resource group whose failures span five different operations appears as five rows, so its total is split and the two column requirement is broken. Adding a second grouping column always changes the shape of the result, it never just adds detail. summarize FailedOps = count() by ResourceGroup produces the right shape, one row per resource group with two columns, but the named aggregation replaces the default count_ with FailedOps. The sort line still says count_, so the query fails to resolve that column and returns an error instead of a result. The line would be correct only if the sort line were changed to match, and the stem fixes the sort line. count is the count operator rather than the count() aggregation function. It returns a single row with a single column named Count holding the total number of failed records across every resource group, with no grouping at all, and the sort line then fails because count_ does not exist. Confusing the operator with the function is one of the most common KQL slips on the exam. Key exam concept: where filters rows, summarize collapses them into groups and names an unnamed aggregation after the function with a trailing underscore, and every later operator must reference the column names summarize actually produced. When a query is shown with a gap, read the visible lines for the column names they expect and pick the line that produces exactly those columns and nothing more.

Question #17 Manage Azure identities and governance

A freelancer maintains a small web application for a nonprofit in the resource group rg-web, which contains an App Service app and a storage account named stnpo01. At startup the app builds its blob connection string by calling the storage resource provider to list the account keys, using a managed identity that holds the Contributor role on rg-web. Yesterday a board member with the Owner role added a lock at the resource group level to prevent accidental changes before an audit. Since the app last restarted, it fails at startup with a 403 error on the key listing call, while blob reads from a second tool that already holds a key continue to work. Nothing else in the environment was changed. What is the most likely cause?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: The lock is a ReadOnly lock, which blocks the List Keys operation because it is a POST request to the control plane. Listing storage account keys is one of the documented side effects of a ReadOnly lock, and a startup path that depends on that call breaks the moment the lock lands on the resource group. Resource locks come in two levels. CanNotDelete lets authorized users read and modify a resource but not delete it. ReadOnly restricts everyone, including Owners, to the equivalent of the Reader role on the locked scope, so no update or delete operations succeed. A lock placed on a resource group is inherited by every resource inside it, including resources added later, and the most restrictive lock in the chain wins. Locks apply to control plane operations that travel through Azure Resource Manager at management.azure.com. They do not govern data plane operations that go directly to the service endpoint, which is why the second tool that already holds a key keeps reading blobs without trouble. The subtlety the exam likes is that some operations that look like reads are implemented as POST requests, and a ReadOnly lock treats POST as a modification. Listing storage account keys is the classic example: the List Keys call is a POST to the storage resource provider, so it fails with a 403 under a ReadOnly lock even though the caller holds Contributor and is asking only to read a secret. The same rule blocks starting or restarting a virtual machine in a locked group, scaling an App Service plan, and starting automation runbooks. The remedy is to remove or downgrade the lock, which needs Owner or User Access Administrator, or to change the app to authenticate to blob data with its managed identity and a data role such as Storage Blob Data Reader, which sidesteps key listing entirely and is the more secure design anyway. The lock removed the Contributor role assignment confuses locks with role based access control. Locks never alter role assignments, they add a restriction on top of whatever roles exist, and a CanNotDelete lock actually protects assignments from deletion. A CanNotDelete lock blocks all write and POST operations overstates that lock level. CanNotDelete only prevents deletion. Updates, key listing, and other POST operations continue to work under it, which is why it is the safer choice before an audit. Resource group locks do not affect the storage account ignores inheritance. Child resources inherit the parent lock, and the scenario states nothing else changed, so an expired key is an invented cause. Key exam concept: CanNotDelete blocks deletes only, ReadOnly blocks updates and every POST including List Keys, virtual machine start, and plan scaling. Locks inherit down the hierarchy, apply to everyone including Owners, and are managed by Owner or User Access Administrator.

Question #18 Deploy and manage Azure compute resources

A security engineer at example.com must enable encryption at host on VM1, a Standard_D8ds_v5 Windows virtual machine in subscription Sub1 that runs a document processing service which writes heavily to the local temp disk. The compliance requirement is that the temp disk and the disk caches are encrypted at rest, not only the managed OS and data disks, and the team is satisfied with platform managed keys. VM1 has never had Azure Disk Encryption enabled, and its size reports the EncryptionAtHostSupported capability as True. An attempt to set the encryption at host property on the running VM1 with Azure PowerShell returns an error, and Sub1 has never had encryption at host enabled on any virtual machine. The engineer holds the Owner role on Sub1 and can schedule downtime for VM1 tonight, but the change record does not permit rebuilding the machine or changing its size. Which two actions should the engineer perform? Each correct answer presents part of the solution. (Select TWO)

Pick two answers to reveal the explanation.

Why this is correct

Correct answers: register the EncryptionAtHost feature of the Microsoft.Compute provider in Sub1 and wait for the Registered state, and deallocate VM1, enable Encryption at host, then start it again. A subscription that has never used the feature has not registered it, and the property only takes effect when a deallocated machine is placed back on a host, so both steps are needed before tonight's window closes. Server side encryption of managed disks is always on and protects the OS and data disks at rest in Azure Storage with platform managed keys, or with customer managed keys through a disk encryption set. It does not cover the temp disk, which lives on the local host, and it does not cover the disk caches or the data as it moves between the host and storage. Encryption at host closes those gaps. When it is enabled, the temp disk and any ephemeral OS disk are encrypted at rest with platform managed keys, the OS and data disk caches are encrypted with whichever key type the disk itself uses, and data flows encrypted from the host to the storage service. The setting is a property of the virtual machine under its security profile, it does not consume guest CPU, and it does not require any agent inside the operating system. The d in Standard_D8ds_v5 marks the local temp disk the service depends on. Its sibling Standard_D8s_v5 has no temp disk at all, which is worth keeping straight because temp disk presence by size is its own exam topic. Three prerequisites govern the change, and the scenario hides two of them behind one generic error. First, the subscription must have the EncryptionAtHost feature registered under the Microsoft.Compute resource provider, done once with Register-AzProviderFeature -FeatureName EncryptionAtHost -ProviderNamespace Microsoft.Compute or az feature register --name EncryptionAtHost --namespace Microsoft.Compute, followed by a wait of a few minutes until Get-AzProviderFeature reports Registered. A subscription that has never enabled the feature on any machine has not been through that step, which is the clue the stem plants. Second, the size must support the feature, which Get-AzComputeResourceSku confirms through the EncryptionAtHostSupported capability, and Standard_D8ds_v5 qualifies. Third, an existing machine must be deallocated and reallocated. Encryption at host is applied when the platform places the machine on a host, so the property cannot be changed on an allocated machine, and the documented PowerShell sequence is Stop-AzVM followed by Update-AzVM -EncryptionAtHost $true and a start. Registering the feature alone leaves the running VM1 unchanged, and deallocating alone still fails on an unregistered subscription. Both steps are required, and the same deallocation is needed later to turn the setting off. Because the team accepts platform managed keys, no Key Vault or disk encryption set enters the picture. Enabling Encryption at host on the running VM1 and restarting it from the guest confuses a reboot with a deallocation. The documentation states that existing machines must be deallocated and reallocated to be encrypted, because the setting takes effect when the machine is placed on a host. A guest restart, and even the portal Restart button, keeps the machine allocated on the same host, so the property update is rejected in the first place and nothing applies at the next boot. Enabling Azure Disk Encryption first is the opposite of what is needed. Encryption at host cannot be enabled on a machine that has Azure Disk Encryption now or ever had it, and Azure Disk Encryption itself is retiring in September 2028, so this step would permanently block the goal. Registering EncryptionAtHost under the Microsoft.Storage resource provider puts the flag in the wrong namespace. Encryption at host is a property of the compute host that runs the machine, and managed disks themselves are Microsoft.Compute resources, so the feature lives under Microsoft.Compute. The Storage provider has no feature by that name, the registration attempt fails, and the Compute flag stays unregistered, so the original error persists. Key exam concept: server side encryption covers managed disks in storage, encryption at host adds the temp disk, caches, and data in flight, needs the Microsoft.Compute feature registered and the machine deallocated rather than restarted, and cannot coexist with Azure Disk Encryption.

Question #19 Implement and manage virtual networking

A consultant is called in by a media company whose public Standard Load Balancer LB1 stopped serving traffic after a security hardening change. The backend pool contains VM1 and VM2 in Subnet1. Each machine serves the site over TLS on port 443 and exposes a plain HTTP health endpoint on port 80 at /healthz that returns 200. The load balancing rule maps frontend port 443 to backend port 443, and its health probe is HTTP on port 80 with the path /healthz. From a virtual machine in Subnet1 the consultant confirms that both health endpoints respond. The network security group on Subnet1 was replaced during the hardening change and now contains the custom inbound rules below, with the default rules still present. Load balancer metrics show a health probe status of 0 percent for both backend instances, and the company insists that port 80 stays closed to the Internet. What should the consultant change to restore service?

Priority  Name           Source     Dest port  Protocol  Action
100       Allow-Web-443  Internet   443        TCP       Allow
110       Deny-Port-80   Any        80         TCP       Deny

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Add an inbound rule ahead of the deny rule that allows port 80 from the AzureLoadBalancer service tag. The hardening rule at priority 110 denies every source on port 80, which includes the platform address that health probes come from, so both backends are marked down and the load balancer sends them no traffic. A Standard Load Balancer only forwards new connections to backend instances that pass their health probe. Every IPv4 probe originates from the address 168.63.129.16, a virtual public address owned by the platform, and the AzureLoadBalancer service tag stands for that address in network security group rules. Each network security group carries a default rule, AllowAzureLoadBalancerInBound at priority 65001, that admits the probe, which is why probes normally work without any explicit rule. Custom rules occupy priorities 100 through 4096 and are always evaluated before the defaults, so a custom deny that matches the probe's destination port with a source of Any silences the probe before the default allow is ever reached. That is exactly what the new rule at 110 does. An HTTP probe also needs an HTTP 200 from the configured path within the timeout, and the consultant verified that the endpoints do respond, so the failure is purely the network path. The fix keeps the intent of the hardening change. A rule at any priority below 110, for example 105, with source AzureLoadBalancer, destination port 80, and the Allow action admits the probe while the deny at 110 continues to block port 80 from every other source, including the Internet. Once the probe returns 200 the backends turn healthy and client traffic on 443, which the rule at 100 already allows, resumes. Network Watcher IP flow verify with source 168.63.129.16 and destination port 80 would have named the deny rule directly. Changing the probe protocol to TCP changes what counts as a healthy response but not where the probe comes from or which port it targets. The TCP handshake to port 80 is dropped by the same deny rule, so the probe still fails. Enabling Floating IP on the load balancing rule changes how the backend sees the destination address for scenarios such as SQL availability group listeners. It has nothing to do with network security group evaluation and leaves the probe blocked. Moving the deny rule to priority 4096 still leaves it inside the custom range, which is evaluated before every default rule. The deny at 4096 continues to beat AllowAzureLoadBalancerInBound at 65001, so nothing changes. Key exam concept: probes come from 168.63.129.16, represented by the AzureLoadBalancer tag, and custom rules always precede the default allow at 65001. When every backend goes unhealthy right after a network security group change, look for a deny that catches the probe port.

Question #20 Manage Azure identities and governance

A Reader role assignment that was created at a management group appears as Inherited on the Access control (IAM) page of a resource group inside that management group, and it cannot be removed from the resource group page. It must be removed at the management group where it was created.

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: True. Role assignments are stored at the scope where they are created, they flow down to every child scope, and the only place they can be deleted is the scope that holds them. Azure role based access control resolves a user's permissions by collecting every role assignment that applies at the requested scope, whether it was created there or at a parent. Scopes form a hierarchy: management group, subscription, resource group, resource. An assignment at a management group applies to every subscription beneath it, to every resource group in those subscriptions, and to every resource in those groups. Effective permissions are the union of all matching assignments, and a lower scope cannot subtract anything. The Access control (IAM) page of a child scope lists inherited assignments with the marker Inherited and shows the scope they came from in the Scope column, which is a signal that the assignment does not belong to the page you are looking at. Attempting to remove an inherited assignment from the child page produces a message that inherited role assignments cannot be removed. The documented remedy is to open Access control (IAM) at the scope where the role was assigned, which the Inherited link takes you to directly, and remove it there. Removing it at the management group removes the access from every subscription and resource group underneath, so if the intent is to exclude only one resource group, the administrator has to restructure the assignments instead, for example by assigning Reader at the individual subscriptions or resource groups that should keep it rather than at the management group. Deny assignments are the only mechanism that blocks access a role assignment would otherwise grant, and they are created by Azure managed applications and deployment tooling such as deployment stacks, not by hand on the portal page. False would mean an inherited assignment could be deleted from a resource group's Access control (IAM) page, or that an inherited permission could be trimmed at a lower scope. Neither is possible. Candidates who choose False usually assume the Remove button on the child page works for every row, or confuse role assignments with locks and policies, which can be created at any scope independently and removed where they were created. Key exam concept: assignments inherit downward, effective permissions are additive, and an assignment is removed only at the scope where it was created. To narrow access, move the assignment lower rather than trying to remove it from a child.

Microsoft Azure Administrator Practice Test

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Frequently asked questions about the AZ-104 exam