Why does a management-API audit trail record the creation of an object store but not each read of an object inside it?

## The split follows the platform's own split A cloud platform has two halves. The **control plane** is the management API: the surface through which resources are created, reconfigured, described and destroyed. The **data plane** is the thing you rented actually doing its job: serving objects, answering queries, decrypting, routing packets. The audit record is split along the same seam, and knowing which half an action fell on tells you immediately whether an entry is likely to exist. - **Management events** are calls against the control plane. Creating an object store, changing its access policy, enabling versioning, deleting it. These are recorded by default across the account. - **Data events** are operations against the contents. Reading one object, writing one, listing the contents of a prefix, using a key to decrypt a payload. These are typically *not* recorded unless you ask for them. ## Why the default goes that way It is a volume argument before it is anything else. An account might see thousands of management calls a day; the same account's object store might serve millions of reads an hour. Recording every one of those produces a stream that is larger than the workload's own traffic in event count, and the platform would be charging you to store a near-duplicate of your application's access pattern. So providers converge on the same design, with differences in the details: | dimension | management events | data events | |---|---|---| | on by default | yes | no, in general | | typical volume | thousands per day | millions per hour | | scoping | whole account | per resource, often per path or prefix | | charged | usually bundled | usually charged per event recorded | | destination | the account's audit record | often a separate destination you choose | Providers differ on how far the scoping goes — some let you select a subset of operations as well as a subset of resources, and some record a small set of especially sensitive data operations by default — so the safe statement in an interview is that the *default is off or narrow* and the enabling is a deliberate act, not that any particular operation is or is not covered. ## The consequence you must be able to state This is a decision you can only make **before** the incident. The shape of the trap is always the same: 1. A store is created, and its management events are recorded automatically. 2. Months later somebody changes its access policy to something permissive. That change is a management call, so it *is* in the record, with the caller and the time. 3. Data is suspected to have been taken during the window between that change and its discovery. 4. You go looking for who read what — and there is nothing, because data events were never switched on for that store. You can therefore answer *how the exposure became possible, who caused it and exactly when* with complete precision, and you cannot answer *what was actually taken*. That asymmetry is worth saying out loud in an interview, because it is what drives the decision: you enable data recording selectively, on the stores whose contents would matter in that conversation, and you accept that you cannot afford it everywhere. ## How to choose where to turn it on Since blanket coverage is not affordable, the choice is a classification exercise rather than a technical one: - **Turn it on where the contents are the asset** — the store holding customer records, the key material, the export destination of a reporting pipeline. - **Scope it as tightly as the platform allows** — a path or a prefix rather than the whole store, and read operations rather than every operation, where reads are the risk. - **Leave it off for the bulk** — build artefacts, static assets, scratch space and anything whose disclosure costs nothing. - **Write down the decision** so that the next incident starts by checking the list rather than by hoping. ## The adjacent confusion Two other records look like this one and are not. A service's own access log — the request log the thing you rented emits about traffic it served — is a feature of that service, in its own format, delivered where you point it. And your application's logs describe what your code did with the data after it had it. Both can be valuable, and neither is the platform's audit trail: they are written by something inside the boundary, they can be turned off by whoever operates the workload, and their format and retention are yours to get wrong. Pipelines, parsing and retention design for all of those streams belong to the logging discipline rather than to the platform's own record.