API 500 responses currently return SQL text and row images of citizen records to make debugging easier for mobile clients. What should the API return instead?
Select an answer to reveal the explanation.
Short Explanation
Clients get a polite "something went wrong," not a SQL autopsy with citizen rows attached. Park the gory details in locked server logs where on-call can read them.
Full Explanation
API 500 responses to mobile clients must minimize sensitive data: return generic client-facing error messages (optionally with a correlation ID) while detailed SQL text, stack traces, and citizen row contents remain in secured server-side logs. Data minimization in error handling protects municipal residents when clients, intermediaries, or crash reporters receive failure payloads. Debugging detail belongs where on-call can read it under IAM, not in the JSON body shipped to phones.
Returning the full DynamoDB item plus KMS plaintext data keys fails because it leaks citizen records and cryptographic material to untrusted clients. Embedding stack traces and SSNs whenever NODE_ENV is not explicitly production fails conceptually—mis-set environment flags commonly ship "non-prod" verbosity into live traffic. HTML dumps of database result sets in error payloads fail by design as large sensitive disclosures for screenshots.
Exam caveat: ensure error middleware applies in all frameworks and edge cases (uncaught exceptions, gateway integration errors), not only happy-path catch blocks. Operational check: force a 500 in a test stage, confirm the client body is generic, and verify detailed diagnostics appear only in locked CloudWatch logs with restricted subscriptions.