AI-103 Practice Question 62: Diagnostic Logging Log Analytics
Microsoft Azure AI Apps and Agents Developer Associate (AI-103) · Test 7 · question 2 of 10
A platform team runs a shared Foundry resource that several application teams call. After an incident where nobody could say which application caused a spike in 429 errors, the platform team is asked to make every request and error auditable and to be able to write alert queries over the history, not just look at live counters.
What should they configure on the Foundry resource?
Show answer and explanation
Answer:
Diagnostic logs are generated automatically but are not retained or queryable until a diagnostic setting routes them somewhere. Microsoft's how-to has the team add a diagnostic setting on the Foundry resource, select the Audit, RequestResponse, and AllMetrics categories, and send them to a Log Analytics workspace, after which the data can be queried with Kusto (for example, grouping by Resource or OperationName) and used as the source for alert rules. That is exactly the audit-and-alert requirement here.
- B is wrong because quotas and rate limits change how much traffic is *allowed*, not whether the resulting requests and errors are recorded anywhere queryable. It doesn't produce an audit trail. - C is wrong because the Metrics blade shows near-real-time aggregated charts. It isn't a durable log store, doesn't retain per-request detail, and can't back a Kusto alert query the way a Log Analytics workspace can. - D is wrong because Entra sign-in logs record authentication events for identities, not the resource's own API request/response traffic and errors; it doesn't tell the team which application generated a given 429.
Reference: Enable diagnostic logging