How Do You Filter Classic Availability Tests in Application Insights?
You manage an Azure subscription that contains 100 Azure App Service web apps. Each web app is associated with an individual Application Insights instance. You plan to remove Classic availability tests from all Application Insights instances that have this functionality configured. You have the following PowerShell statement: Get-AzApplicationInsightsWebTest | Where-Object { $condition } You need to set the value of the $condition variable. Which value should you use?
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
It tests whether you know that classic URL ping tests are identified by the WebTestKind property (value "ping"), not by a Type property — the trap is picking $_Type or the "standard" value used by the newer standard tests.
Application Insights classic availability tests are URL ping tests, and the Get-AzApplicationInsightsWebTest cmdlet exposes that distinction through the WebTestKind property. This page confirms that the correct $condition value is $_.WebTestKind -eq "ping" (option B).
The most common wrong pick is $_.Type -eq "ping" (A), because candidates assume the object exposes a simple Type field; the returned web test objects actually expose WebTestKind, and Type either does not exist or does not carry the ping/standard distinction.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The cmdlet Get-AzApplicationInsightsWebTest returns Application Insights web test objects whose test style is exposed as the WebTestKind property. Classic availability tests are the legacy URL ping tests, and Microsoft's migration guidance explicitly identifies them with the value "ping", while the newer standard tests use "standard". Therefore Where-Object { $_.WebTestKind -eq "ping" } returns exactly the classic tests you intend to remove, so option B is correct.Filtering on WebTestKind also lets you chain a second action safely, for example piping the result into Remove-AzApplicationInsightsWebTest, which is precisely the cleanup scenario described for the 100 web apps. Because each App Insights instance exposes its own web tests, the filter runs per resource and only removes the classic entries. The cmdlet's property set is documented in both the Azure Monitor availability documentation and the Az.ApplicationInsights PowerShell reference.
Why the Other Options Are Wrong
Option C ($_.WebTestKind -eq "standard") is syntactically valid PowerShell but targets the wrong generation of tests: standard tests are the modern replacement, not the classic tests being retired. It would leave every legacy ping test untouched and could decommission modern tests instead.Options A and D both filter on a Type property ($_.Type -eq "ping" and $_.Type -eq "standard"). The returned web test objects do not use Type to express ping versus standard; that information lives in WebTestKind, so those predicates match nothing (or match on an unrelated field) and the removal script silently does nothing. The "ping"/"standard" pairing is a distractor that makes A look plausible even though the property name is wrong.
Community Comment Notes
All of the collected learner comments converge on B, and shantanunp supplied the Microsoft Learn availability page covering how to "migrate classic URL ping tests to standard tests", which is the authoritative source for the WebTestKind values. Mattt shared a working pipeline — Get-AzApplicationInsightsWebTest piped through Where-Object on WebTestKind, then Format-Table with ResourceGroupName, Name, WebTestKind and Enabled — showing WebTestKind is a real, inspectable property. Vichu_1607 simply restated the correct filter, so the community consensus and the official documentation agree with the answer key.Official Reference
Exam Strategy
When an AZ-204 question shows a PowerShell (or CLI) cmdlet followed by a Where-Object condition, recall the exact property names returned by that cmdlet rather than guessing from the display names used in the portal. Here the portal says "classic" but the API property value is "ping" on WebTestKind, so map portal terminology to API terminology before choosing.
Frequently Asked Questions
Why not filter on $_.Type -eq "ping" to find classic availability tests?
The web test objects returned by Get-AzApplicationInsightsWebTest express the test generation through WebTestKind, not Type, so a Type filter matches nothing and the classic tests are never removed.
What is the difference between WebTestKind "ping" and "standard"?
"ping" identifies legacy classic URL ping tests, while "standard" identifies the newer standard availability tests that support more validation features and are the migration target.
Where-Object { $_.WebTestKind -eq "ping" } |Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;