A SOC analyst sees repeated access to a restricted finance share, but file integrity logs show no changes. The team suspects an account may be opening or copying files without modifying them. Which technique best provides high-confidence telemetry for this behavior?
Select an answer to reveal the explanation.
Short Explanation
Think of a canary file like a tripwire on a shelf: you don't care if someone knocks it over, only that it moved. Normal logs often miss a quiet read or copy, so you place a harmless decoy file and alert when it's touched. That's deception telemetry catching what integrity checks would never see.
Full Explanation
A canary file is a deception control placed on a sensitive share so benign-looking reads, copies, or metadata access generate a high-confidence alert. Unlike ordinary file auditing, it is designed to catch quiet reconnaissance or exfiltration staging that leaves no modification trail, making it useful when logs show suspicious access but no changes. A file integrity monitoring rule limited to modifications or deletions would miss the exact behavior here: an adversary opening or copying a file without changing it. A honeypot account or credential lure can expose credential misuse, but it does not directly prove file access on the share and is broader than the stated need. Increasing correlation on failed logon events may help identify brute-force attempts, yet it misses successful access and normal user activity that is actually the concern. Exam caveat: CS0-004 expects you to match the telemetry source to the adversary behavior, not just choose the fanciest tool. Operational check: deploy a uniquely named decoy file with read/copy alerting enabled, then test it with an approved account to confirm the SIEM or SOAR workflow fires without noise.