A hotel chain stored a guest-portal password inside a network-loss test and expected that test to prove the guest login. What is wrong with that setup?
Select an answer to reveal the explanation.
Short Explanation
You can see the mismatch: a network-loss test measures the path; it does not log in, so the stored password cannot prove the guest login. Authentication has to be exercised by a test that actually signs in. Switching to an auth method the booking application does not use, running the portal check without credentials, or scoring only low loss still won’t prove that login.
Full Explanation
A network-loss test probes reachability characteristics such as loss, latency, and jitter. It does not submit the guest portal login, so a password stored on that test is never exercised as an application credential and does not belong there. The login has to be proved by a web test that actually signs in the way guests do. Switching the guest portal to an authentication method the booking application does not use would make the synthetic check unlike the real stay; it does not fix the misplaced password. Running the portal check with no credentials stored on the test would skip login rather than prove it. Keeping the password on the loss test and scoring only whether loss stays low continues to treat a path measurement as a sign-in result. Exam caveat: storing a secret on a test does not mean that test performs authentication; the test type has to be one that logs in. Operational check: open the test definition, confirm it is a network test rather than a web transaction, and move the portal credential onto a web test that completes the same login the booking application uses.