CloudTrail Lake: the query id is not the event

The query id is the job

start-query returns a query id for that statement. Status checks and result pages use that id. It names the job: which statement, which store, and the pages you fetched. It does not name an API call inside the account.

A second run of the same words gets a new query id. The old id still refers to the old job.

eventID is the record

Each result row that includes eventID is one CloudTrail record. That is the id to cite when you say a call happened. The query id can sit in your note as how you retrieved the row. It is not a substitute for eventID.

If the SELECT list omitted eventID, write “eventID not in this result.” Do not use the query id to fill it.

What to file

File the query id with the statement and the status. File eventID on every call you describe. A ticket that only has a query id has a job, not an event.

Worked case: a query id filed as the call

Query id q-440 finished and one row shows DescribeInstances. The row’s eventID was not selected. A draft cites q-440 as the id of the DescribeInstances call.

The note says q-440 is the query job. eventID was not in the result, so the call is not given that id. The event is described as a row from that query, without a record id, until the query is repeated with eventID in the SELECT list.

Snippet

query id: q-440
status: finished
row: eventName DescribeInstances
eventID: not in this result
write: q-440 is the job
not: q-440 is the API event

Diagram

Keep the job id off the event

Query id
The Lake job you started.
Job
```
q-440
```
Status
Whether that job finished.
Job
```
finished
```
Row
One result line from the job.
Row
```
DescribeInstances
```
eventID
The record id, only if the row has it.
Record
```
not in this result
```

Check yourself

1. Query id q-440 finished and returned rows. What is q-440?

2. The SELECT list left out eventID. What can you use as the record id?

3. You run the same statement again. What happens to the id?