Parks IT creates a honeytoken service account that should never log in; any use triggers a high-fidelity alert. What is the primary purpose of that account?

Deception technologies such as honeytokens and honeyfiles exist to detect unauthorized interaction with artifacts that legitimate users should never need. A parks IT honeytoken service account that should never log in provides a high-fidelity detective signal when anyone authenticates with it: interaction implies misuse, reconnaissance, or credential theft rather than normal volunteer work. The primary purpose is deception for detection, not production identity support.

Providing a production login for seasonal volunteers who forgot MFA contradicts the design—real users should never use the honeytoken, and MFA problems need proper identity recovery processes. Claiming the token replaces the need for any detective monitoring elsewhere oversells deception; honeytokens complement SIEM, EDR, and logs rather than substituting for a monitoring program. Storing the only copy of parks payroll encryption keys in that account turns bait into a catastrophic single point of failure and misunderstands deception—critical secrets must not live in decoy identities.

Exam caveat: distinguish decoys from real assets. SY0-701 covers honeypots, honeynets, and honeytokens as detection-oriented deception, not as operational accounts or key vaults.

Operational check: create municipal honeytokens with realistic names, alert on any authentication or ACL use, keep them out of password vaults staff use daily, document ownership in the SOC, and never place production keys or real HR data behind decoy credentials. Tune alerts for immediate investigation when parks or other department honeytokens fire.