Staging tests for a licensing API currently cover only successful authenticated requests. What else must they include?
Select an answer to reveal the explanation.
Short Explanation
Happy paths lie by omission. Staging should also throw bad tokens and garbage bodies to prove the licensing API fails closed. Turning off authorizers to avoid seeing errors just trains false confidence.
Full Explanation
Staging tests for a licensing API must include negative paths such as unauthorized tokens and malformed bodies to verify auth and validation failures on the deployed app—not only successful authenticated requests. Negative testing proves municipal APIs reject bad callers correctly, which is as important as proving happy-path license issuance works for clerks and citizens. Domain 3 environment testing expects both classes of cases against the deployed stage before any production promotion discussion.
Testing only HTTP 200 paths because failures are out of scope for developers fails because auth and validation bugs are developer defects with direct citizen impact. Relying on production monitoring to discover auth bugs after citizens hit them fails conceptually by deferring detection until live harm and support tickets. Disabling authorizers in staging so negative auth cases cannot occur fails by making staging unlike production and hiding the very defects the suite should find.
Exam caveat: negative tests should assert status codes and safe error bodies without leaking stack traces or license holder PII in responses. Operational check: call staging with expired tokens, missing scopes, and malformed JSON; confirm 4xx responses, authorizer denials, and sanitized messages; block promotion until those assertions pass.