Develop a security and compliance plan →easyMultiple ChoiceObjective-mapped

AZ-400 Develop a security and compliance plan Practice Question

Exhibit

Refer to the exhibit.

```json
{
  "alertRule": {
    "displayName": "Key Vault Secret Near Expiry",
    "query": "// Azure Resource Graph query
    resources
    | where type == 'microsoft.keyvault/vaults/secrets'
    | extend DaysToExpiry = datetime_diff('day', now(), properties.attributes.expiresOn)
    | where DaysToExpiry < 30 and DaysToExpiry > 0
    | project name, vaultName = resourceGroup, expiresOn = properties.attributes.expiresOn, DaysToExpiry
    | limit 10"
  }
}
```

The exhibit shows a draft Azure Monitor alert rule for Key Vault secret expiry. However, the query fails to return results for secrets that have already expired. What is the most likely reason?

⚠ Common exam trap

The trap here is that candidates focus on the syntax or limits of the query (like `limit 10`) rather than recognizing that the logical filter `DaysToExpiry > 0` inherently excludes the very data the alert is supposed to detect—expired secrets.

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 condition `DaysToExpiry > 0` excludes secrets that have already expired.

The query filters on `DaysToExpiry > 0`, which only returns secrets with a positive number of days remaining until expiry. Once a secret has expired, its `DaysToExpiry` becomes zero or negative, so it is excluded from the results. This is a logical filter error: the condition should be `DaysToExpiry <= 0` or remove the filter entirely to include expired secrets.

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 query does not include secrets that have no expiry date set.
Why it's wrong here
This is not a flaw for detecting expired secrets because the alert targets secrets with an expiry date; secrets without an expiry date are not relevant to the condition DaysToExpiry and do not affect the identification of already expired ones.
✓
The condition `DaysToExpiry > 0` excludes secrets that have already expired.
Why this is correct
Expired secrets have a DaysToExpiry value that is negative because their expiry date is in the past. Using the condition DaysToExpiry > 0 filters out those negative values, so the alert rule excludes already expired secrets and only reports on those expiring in the future.
✗
The query only checks secrets that are enabled.
Why it's wrong here
The query does not include any filter on the 'enabled' attribute of the secrets, so it evaluates all secrets in the vault regardless of enabled or disabled state. Therefore, the claim that it only checks enabled secrets is incorrect.
✗
The `limit 10` clause restricts to only 10 secrets, which may miss expired ones.
Why it's wrong here
The `limit 10` operator truncates the result set after the `where DaysToExpiry > 0` clause has already been evaluated, and Kusto filters rows before applying the limit. Because expired secrets have a negative DaysToExpiry, they are removed by that filter and never reach the limit stage, so limiting to 10 rows cannot cause them to be missed. The limit only caps how many non-expired secrets are returned, which might hide expiring-soon secrets but not already expired ones. The actual flaw is the filter itself, which deliberately excludes negative values.

Go deeper

AZ-400 Develop a security and compliance plan Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question