feat: Added ARG for Private DNS Zone TTL, Network watcher, Connection Monitor and fixed a bug for storage redundancy

[EshaG-Solanki]

Added KQL for Private DNS Zone TTL - Since its a manual check and will vary based on the RTO needs, the query just lists the TTL for each DNS recordset, the validation will still need to be done with the customer. But it helps when the customer is using Private endpoints heavily as seen in many cases.

Let me know if something is missing/any improvement ideas.

[Copilot]

Pull Request Overview

This PR adds an Azure Resource Graph KQL query to list the Time-To-Live (TTL) for each Private DNS Zone recordset, aiding manual validation against Recovery Time Objective requirements.

• Introduces an ARG query file to project TTL values alongside resource identifiers.
• Tags the output with a static recommendationId for integration in existing workflows.
• Formats TTL in a human-readable string.

Comments suppressed due to low confidence (2)

azure-resources/Network/privateDnsZones/kql/3538aa48-c40b-455b-a93b-269fe6e65be2.kql:4

• The alias param1 is not descriptive. Rename it to something like ttl or timeToLive to clearly indicate the column represents the recordset's TTL.

| project recommendationId = "3538aa48-c40b-455b-a93b-269fe6e65be2", name, id, tags, param1 = strcat("Time-To-Live: ", properties.ttl)

azure-resources/Network/privateDnsZones/kql/3538aa48-c40b-455b-a93b-269fe6e65be2.kql:2

• Clarify the acronym RTO by expanding it to Recovery Time Objective (RTO) so the comment is self-explanatory.

// This query will return Time-To-Live (TTL) for the DNS recordsets. Make sure it is set appropriately to ensure RTOs

[EshaG-Solanki]

Hi, I am Microsoft employee and I confirm this is my original work.
@microsoft-github-policy-service agree company="Microsoft"

[EshaG-Solanki]

Added additional 3 changes today. Please find below the details:

1. Added ARG Query for Connection Monitor not deployed
   

2. Added ARG Query for Network Watcher not deployed
   

3. Bug fix - ARG query for storage redundancy - Removed regions as all regions are either support ZRS or GRS - A customer had LRS storage deployed in AU Southeast (which doesnot have Availability zones) and because of this check, the redundancy gap was not captured. Any region that does not support Availability zones, does have paired region to support geo-redundancy, hence region filter is not required.

[arthurclares]

Also reviewed and approved by Venkat Kannan via Teams chat.