1.18Question 1

Prompt: You run an API test that creates a new user and the response is HTTP 201 with a valid JSON body. A week later, a customer reports their account does not exist. Walk me through how you would investigate this at the database level, and how you would prevent it in the future.

What a strong answer should cover:

• Querying the database directly to check if the row exists, was soft-deleted, or was never persisted
• Checking for caching layers that might return a stale 201 while the write actually failed
• Verifying default values (active flag, email_verified) and timestamps (created_at not null)
• Adding a database-level verification step to the automated test suite

Example answer:

• First, I would run SELECT * FROM users WHERE email = '<customer_email>' to determine if the row exists at all. If it does not, I would check if there is a deleted_at timestamp or if the record was never written.
• I would then investigate whether the API has a caching layer that might have returned a cached 201 response without actually persisting. I would look at the request logs and error logs tables for that time window.
• To prevent recurrence, I would add a database verification step to every user creation test: after the API returns 201, query the database to confirm the row exists, the default role is applied, and created_at is within an acceptable time window. This becomes a standard pattern across all creation endpoints.