Which provider-side record shows who called which management API to change a service overnight, and what does one entry contain?
answer
- not the application's log
- the platform writes it, not you
- one entry per management API call
- who, when, from where, on what
- outcome field includes denials
basics
~20 sThe platform's audit trail of management API calls, a provider-side stream your application never writes to. Each entry names the calling principal, the time, the source address, the operation, the target resource and whether the call was performed, denied or failed.
solid answer
~50 sEvery resource on a cloud platform is created and changed through the provider's management API, and the platform writes its own record of each of those calls: the **audit trail** of management events. It is written on the provider's side, from the credentials it authenticated, so nothing inside your account has to cooperate for the entry to exist. One entry answers a fixed set of questions — `when`, `which principal`, `what kind of principal`, `from which address`, `which operation`, `on which resource`, `with which arguments`, `with what outcome`, and a correlation id that joins the calls of one multi-step request. Two fields get overlooked: the outcome field records **denied and failed calls**, not only successful ones, and the source address plus timestamp are usually what first separates an interactive human session from a scheduled automation. It is often the only account of a change nobody had to opt into keeping.
code
json · 14 lines{
"at": "2026-03-02T02:41:07Z",
"principal": "automation/reporting-deployer",
"principalKind": "workload-identity",
"calledFrom": "198.51.100.24",
"operation": "UpdateServiceConfiguration",
"target": "reporting-service/prod",
"arguments": {
"retentionDays": 7,
"previousRetentionDays": 90
},
"result": "performed",
"correlationId": "req-4f19c2"
}go deeper
Recall that the platform keeps its own record of calls made to its management API, separate from anything your application writes, and that it names the caller, the time and the operation.
Explain why the reconfigured service has nothing to log — it did not make the call — and walk through the fields of one entry, including that the outcome field records denied and failed calls, not only successes.
Show that you reach for this record first for an unexplained change, and that you state its limits out loud: it carries no intent, no judgment about whether the grant should have allowed the call, and no entry for a change that bypassed the management API.
The question you own is whether the record is worth anything when it matters: how long it survives, who could alter it, and whether anyone is watching that it is still being written.
## Two records, written by two different parties Everything you own on a large cloud platform is created, changed and deleted through the provider's **management API** — the control plane. When the platform accepts one of those calls it writes its own record of it: an **audit trail** of management events. Every large provider keeps one, under a different name, and the property that matters is not the name but the authorship. The platform writes the entry, on its side of the boundary, from the credentials it authenticated and the request it actually received. Nothing inside your account — not the workload, not an agent, not a log shipper — has to be working for the entry to exist. Your application's logs are the other record, and they are written by your code about what your code did. A reporting service whose configuration was changed through the management API never executed that change: the platform did, and then handed the service a new configuration. The service has nothing to log. That is why an unexplained overnight change is a control-plane question rather than an application question, and why searching the application's logs returns nothing however good that logging is. ## What one entry carries A management event is an answer to a fixed set of questions about exactly one call: | field | what it answers | |---|---| | `at` | when the control plane accepted the call | | `principal` | which identity presented credentials | | `principalKind` | a human session, a workload identity, or an automation | | `calledFrom` | the network address the request arrived from | | `operation` | which management API action was requested | | `target` | which resource the call acted on | | `arguments` | the values sent with the request | | `result` | performed, denied, or failed | | `correlationId` | which request, so the calls of one multi-step operation join up | Two of those are routinely forgotten: - **The outcome field records refusals.** A call that was denied is still a call that was made. A run of denied operations from one identity, minutes apart, is frequently the most interesting thing in the whole record — and a candidate who assumes only successes are kept will never look for it. - **Address plus timestamp carry a lot before you know anything else.** A call at 02:41 from a fixed address, repeating on a weekly cadence, looks like an automation; the same operation from a changing address in office hours looks like a person. That inference costs nothing and usually orients the investigation first. ## Why this record exists at all Providers keep it because the management API is the one surface through which the estate can be changed, and because a platform that cannot say who changed something cannot be used by anyone with an auditor. For you, three properties follow: 1. **You do not have to have predicted the question.** The record is kept whether or not anyone thought this resource was sensitive. 2. **It spans services.** A single stream covers the whole account's management activity, so a change to storage, to a network rule and to an identity grant are all in one place, in one time order. 3. **It is evidence rather than telemetry.** It is not sampled to save money, and it is not aggregated into a rate; it is a list of calls. ## Where the record deliberately stops The audit trail answers *which identity called which management API, from where, on what, and what happened*. It does not answer several neighbouring questions, and treating it as though it did is the usual mistake: - **Was the caller allowed to do that, and should it have been?** The entry names the principal and the outcome; reasoning about which grant permitted the call, and whether that grant was too broad, is the platform access model's subject, not the record's. - **Does the live resource now differ from what was declared?** A change read back as a difference from declared state is the business of the tooling that declares it. - **What did the workload do with the data?** Management events are about the shape of the estate, not about the rows a query returned. - **Why did the person do it?** No record carries intent. The trail gives you a call and a time; the conversation gives you the reason. It also has a practical limit worth stating plainly: a setting changed through a path that is not the management API — inside the service's own interface, or by an operator of a system layered above it — leaves no management event. When the record shows nothing at all, the honest first hypothesis is not that nothing happened but that the change did not travel through the surface this record watches.
- The audit record shows the change was made by an automation's identity. What have you learned, and what have you not?You have learned the change travelled through that automation's credentials, which narrows the path: a pipeline run, a scheduled job, or someone using those credentials directly. You have not learned which human triggered it — mapping a workload identity back to a person needs the system that invoked the automation, because the platform only ever saw the credential.
- Why is a denied call in the audit record often worth more attention than a successful one?A successful call is usually routine work by an identity that was meant to have the permission. A denial records an attempt that the access model stopped, so it is either a legitimate caller with a missing grant — a broken deployment about to be reported — or a caller reaching for something it should not. Both are worth knowing early.
- The audit record shows no entry at all for the resource that changed. What are the plausible explanations?Three, in order of likelihood: the change was made through a path the management API does not front, such as a setting inside the service's own interface; the record exists but your query window or filter missed it, since delivery is not instantaneous; or the recording was not covering that activity. Absence of an entry is a lead, not a verdict.
A badge reader records which badge opened which door at what time, whether or not anyone inside the room wrote anything down. It tells you nothing about what was said in the meeting.
saying these in an interview costs you the question
- Expects the application's own logs to show who changed platform configuration
- Assumes only successful calls are recorded, so never looks for denials
- Thinks the reconfigured service writes the audit entry itself
- Reads the record as proof of why a change was made
- Believes the entry tells you whether the caller was permitted to make the call
- Treats an empty result as proof that no change happened