Production AI logs may contain case metadata. Who should be allowed to run KQL against that workspace?
Select an answer to reveal the explanation.
Short Explanation
RBAC on the log workspace is like badge access to the records room—only ops who need case-adjacent telemetry get in.
Full Explanation
Production AI logs that may contain case metadata must be protected: limit Log Analytics workspace query access with RBAC so only authorized ops can run KQL on those production AI logs. Case-adjacent telemetry can include sensitive municipal workflow details even when not intentionally storing full case files; query access is a data-access path and should follow least privilege like any records-room control.
Granting Reader on the workspace to every city employee by default overshares potentially sensitive telemetry far beyond need-to-know. Publishing the workspace query key on an intranet wiki without RBAC treats a powerful credential as documentation and invites uncontrolled exfiltration. Allowing anonymous public query endpoints for transparency dashboards exposes production AI logs beyond the city's authorization boundary.
Exam caveat: Azure RBAC roles on the workspace (and resource-level controls) govern who can run queries; this is separate from ingestion, retention, and customer-managed keys. Also redact PII from custom dimensions at the source so defense-in-depth does not rely on RBAC alone. Break-glass access should be audited and time-bounded.
Operational check: Review workspace IAM for the production AI Log Analytics resource, remove broad Reader grants, assign query rights only to on-call and authorized platform ops groups, enable audit of query activity where available, and verify unauthorized users cannot run KQL. Pair access limits with log redaction standards for case metadata fields.