The line that fixed the report turned a 2ms lookup into a scan of 42 million rows.
Context, code, logs and metrics, the same material you would have in production, with nobody pointing at the problem.
No multiple choice and no single right answer: you write what you think is happening, what you would do and what it costs.
The moment you submit, the written solution opens next to your answers, and stays open for you to reread whenever you want.
The audit-api holds the platform's audit log: who changed what, and when. The compliance team opens a panel that asks for one day's events.
GET /api/v1/audit-events?on=2026-08-20select id, actor_id, action, occurred_at
from audit_events
where occurred_at >= $1 and occurred_at <= $2
order by occurred_at desc
limit 500The two parameters are built in the application: '2026-08-20 00:00:00' and '2026-08-20 23:59:59'. The table has 42 million rows and takes about 180 thousand a day. occurred_at is a timestamptz and the database runs in UTC.
A fix shipped on Tuesday. An event was in the table and did not show up in the report: it had happened at 23:59:59.412, and the <= on 23:59:59 sharp left it out. The report is correct again.
> The SQL is PostgreSQL because the query plan is this challenge's evidence. > The same predicate throws the index away in MySQL, SQL Server and Oracle.
Locked
Opening a challenge costs 1 credit. A new account starts with 3, no card.