Develop Azure compute solutions →hardMultiple ChoiceObjective-mapped

AZ-204 Develop Azure compute solutions Practice Question

Exhibit

Resources
| where type == 'microsoft.insights/components'
| where name contains 'myapp'

Refer to the exhibit. You run this KQL query in Azure Resource Graph Explorer. The query returns no results. What is the most likely reason?

⚠ Common exam trap

It's easy for candidates to assume Azure resource types are case-insensitive in queries, but Azure Resource Graph enforces exact lowercase matching for the 'type' property, leading to empty results when mixed case is used.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The resource type is incorrect; it should be 'microsoft.insights/components' in lowercase.

The KQL query uses the resource type 'Microsoft.Insights/Components' with mixed case, but Azure Resource Graph Explorer requires resource types to be specified in all lowercase. The correct type is 'microsoft.insights/components'. When the case does not match, the query returns no results because Azure Resource Graph performs a case-sensitive match on the 'type' property.

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 'contains' operator is case-sensitive.
Why it's wrong here
The 'contains' operator in Kusto Query Language (KQL), as utilized by Azure Resource Graph, is inherently case-insensitive by default. This means it will successfully match occurrences of a substring within a target string regardless of the casing used in either. For scenarios requiring case-sensitive string matching, KQL provides specific operators such as 'contains_cs' or 'has_cs'. Therefore, asserting that the standard 'contains' operator is case-sensitive is incorrect.
✗
The query must specify a subscription filter.
Why it's wrong here
Azure Resource Graph (ARG) is specifically designed to facilitate efficient, cross-subscription querying of Azure resources. By default, any ARG query executed will automatically scope to all subscriptions that the user has access to within their current Azure Active Directory tenant. Specifying a subscription filter is an optional refinement to narrow the query's scope to a particular subset of subscriptions, not a mandatory requirement for the query to function.
✗
The 'where' clause must use '== ' instead of '=='.
Why it's wrong here
In Kusto Query Language (KQL), the correct and standard operator for performing an equality comparison within a 'where' clause is '=='. This operator is used to check if two values are identical. Introducing an extra space, as in '== ', would render it an invalid and unrecognized operator, leading to a syntax error rather than a functional comparison. The '==' operator correctly performs a case-sensitive comparison for string values.
✓
The resource type is incorrect; it should be 'microsoft.insights/components' in lowercase.
Why this is correct
Azure Resource Graph queries demand precise casing for resource types to ensure accurate identification and retrieval of resources. The correct and canonical resource type for Application Insights components is 'microsoft.insights/components', which is entirely in lowercase. If the query specifies a resource type with any deviation in casing, such as 'Microsoft.Insights/Components' or 'microsoft.insights/Components', it will fail to match any existing resources, resulting in an empty query output. This strict case-sensitivity is fundamental for correct resource targeting in ARG.

Go deeper

AZ-204 Develop Azure compute solutions Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question