AZ-305 Design infrastructure solutions Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The storage account type is incorrectly specified; it should be 'Premium_ZRS'

  Why it's wrong here

  The storage account type specification is a red herring because Azure Resource Graph queries operate on resource properties, not the underlying storage tier of managed disks. Premium_LRS is the correct SKU for premium SSD managed disks, and even if it were wrong, the query's WHERE clause is checking for virtualMachines, not storage accounts. A mismatch in storage account type would not cause an empty result set for VM resources; it would simply have no bearing on the query's filtering logic. Therefore, this option incorrectly attributes the query failure to an irrelevant detail.

• ✓

  The resource type string is case-sensitive; it should be 'Microsoft.Compute/virtualMachines'

  Why this is correct

  Azure Resource Graph queries enforce strict case-sensitivity for the `resourceType` property. To accurately retrieve virtual machine resources, the precise string `Microsoft.Compute/virtualMachines` must be utilised. If the query shown in the exhibit employs an incorrect casing, such as `microsoft.compute/virtualmachines` or `Microsoft.Compute/VirtualMachines`, it will fail to match any existing virtual machines within the subscription. This adherence to exact casing is the most likely reason for the empty result set, despite the presence of VMs.

• ✗

  The 'limit 10' clause restricts too many results; remove the limit

  Why it's wrong here

  The 'limit 10' operator in Kusto Query Language (KQL) is applied after the query filters and retrieves results; it only caps the number of rows returned, not the scope of the search. If any virtual machines matched the resourceType filter, the query would return up to 10 rows, so removing the limit would not produce results when the initial filter matches nothing. Azure Resource Graph applies limits at the server side to bound response size, but a limit of 10 does not suppress valid matches. This option misunderstands how 'limit' interacts with the result pipeline.

• ✗

  The 'name' property does not exist; use 'properties.name' instead

  Why it's wrong here

  The 'name' property is a top-level property on every Azure Resource Graph resource, including virtual machines, and is directly queryable without needing to reference 'properties.name'. The Azure Resource Graph schema flattens certain common properties like 'name', 'type', 'location', and 'resourceGroup' to the top level for efficient filtering and projection. Using 'properties.name' would actually be incorrect for the 'name' field because Resource Graph's schema stores the resource name at the root. Therefore, this option is incorrect because the query's use of 'name' is valid and would not cause an empty result set.

Go deeper

Related to this question