Before open enrollment, a school-district registration API candidate must prove it can handle a surge in a pre-production environment. What test belongs there?
Select an answer to reveal the explanation.
Short Explanation
Dress rehearsal with a packed gym—before opening night. Pre-prod load tests on the candidate build show whether enrollment surge will buckle the API. First-hour-in-prod experiments are cruel to parents.
Full Explanation
Before open enrollment, a school-district registration API candidate must run a scaled load test against the candidate build in pre-prod to evaluate performance before enrollment traffic. Higher non-prod environments should include performance testing of deployed municipal candidates ahead of peak civic events such as enrollment day. Discovering saturation, throttling, or database contention on opening morning is too late for families and district operators.
Skipping load testing because unit tests already assert CPU equals zero fails because unit tests do not model concurrency, connection pools, or I/O wait under enrollment surge. Load-testing only the production environment during the first hour of open enrollment fails conceptually by experimenting on live citizens. Replacing performance testing with a single manual browser click in staging fails as a non-representative sample of one session.
Exam caveat: load tests need production-like data volumes and downstream dependencies (or faithful mocks) or results mislead capacity planning for the registration API. Operational check: execute the scaled pre-prod load test against the candidate build, compare latency and error budgets to SLOs, remediate bottlenecks, and re-test before enabling enrollment traffic.