A cloud security service can push its events as JSON over HTTPS to a URL, but nothing can be installed in the vendor's environment and the Splunk team does not want to add a forwarder. How should the Splunk administrator accept these events directly?
Select an answer to reveal the explanation.
Short Explanation
HEC is like a mail slot in Splunk's front door: anybody holding the right key can push a letter straight through. You create an HTTP Event Collector token, the service posts JSON over HTTPS with that token, and no forwarder is needed. The trap is a polling or file-based input — the stem says the service pushes, and you didn't want to install anything.
Full Explanation
The Splunk HTTP Event Collector lets applications and cloud services send data directly to Splunk over HTTP or HTTPS without a forwarder. The administrator enables HEC, creates a token tied to a default index and sourcetype, and gives the sender the endpoint URL and token; each request carries the token in its Authorization header, and Splunk uses it to authenticate the sender and route the events. Because the service already pushes JSON over HTTPS, HEC matches the integration exactly and avoids installing software anywhere. A universal forwarder monitoring a staging folder requires both an installed forwarder and a mechanism to write files there, which the stem rules out. A scripted input on the search head pulls data on a schedule, reverses the direction of the integration, and runs collection on a component that should be serving searches. A syslog input expects syslog-formatted messages, typically over UDP or TCP, and the service sends JSON over HTTPS, not syslog. Exam caveat: HEC tokens are credentials; scope each token to the minimum indexes required and enable indexer acknowledgment when the sender supports it and delivery must be confirmed. Operational check: send a test event with the token, confirm a success response, and search the target index and sourcetype to verify the event arrived parsed.