The SOC wants Catalyst Center to post network events to a new internal relay at https://events.corp.example:8443/ingest. The relay still needs to be registered, company policy requires TLS, and only device reachability and configuration-change alerts should leave the platform. Which destination and subscription setup delivers exactly that?
Select an answer to reveal the explanation.
Short Explanation
You can send events only to a destination you’ve registered, and the subscription connects that destination to the events you select. Create the destination first, then map only device-reachability and configuration-change events to it. This meets your TLS requirement and keeps the alert scope exact.
Full Explanation
The correct setup is to create the HTTPS destination for the relay first, then create a subscription that maps only device-reachability and configuration-change events to it. Registering the destination gives the subscription a defined endpoint to target; using HTTPS meets the company’s TLS requirement, and limiting the mapping to those two event types prevents unrelated alerts from leaving the platform. Registering the HTTPS hostname on port 443 would target a different endpoint than the specified URL, which uses port 8443, and could fail to reach the relay. Including interface-state events would send an event category the SOC did not authorize, violating the “only” requirement. Subscribing only to device-reachability alerts would omit the required configuration-change alerts, making the event coverage incomplete. Exam caveat: event labels and grouping can vary by Catalyst Center release, so verify which event types correspond to the requested alert categories rather than relying on similar names. Practical check: confirm the registered destination uses the exact HTTPS scheme, hostname, port 8443, and /ingest path, then inspect the subscription’s event selections and validate delivery with a test or representative event for each required category.