Public-health IT wants ongoing proof that the health-portal login path stays healthy in production after releases. Which practice fits?
Select an answer to reveal the explanation.
Short Explanation
Post-deploy synthetics are like a robot citizen that keeps trying health-portal login after the release train leaves. Waiting on tickets or laptop-only checks leaves a blind spot in production.
Full Explanation
Post-deployment synthetic monitoring continuously exercises critical user journeys in production with scripted checks, catching breakage that pre-prod testing or silent citizen traffic may miss. Public-health IT wants ongoing proof that the health-portal login path stays healthy after releases; synthetics that exercise that login in production provide scheduled, alerting proof without waiting for a sick citizen to call the help desk.
Disabling monitoring so citizen traffic alone reveals outages turns residents into unpaid detectors and delays response until harm is already visible. Relying only on developer laptop checks before the release train leaves validates a developer environment, not production DNS, certificates, IdP callbacks, or edge configuration. Waiting for help-desk tickets before investigating portal failures accepts outage dwell time and inequitable detection (only those who can reach support).
Exam caveat: synthetics complement—not replace—real-user monitoring and logging; tune thresholds and auth for non-prod identities so synthetic logins do not skew clinical metrics. Operational check: deploy health-portal synthetics that POST/GET the login path on an interval, page on consecutive failures, and verify alerts fire in a controlled failure drill after each major release.