A fintech runs an internal package registry at pkg.corp.example that resolves to rotating cloud addresses, and every session to it is HTTPS with no decryption configured. The team wants each session tagged with a named application so it can chart registry usage. Which configuration tags that traffic despite the encryption and the changing addresses?
Select an answer to reveal the explanation.
Short Explanation
A custom application detector lets you name traffic the built-in list does not identify, and the server name in a visible TLS handshake can be read without decrypting the session. It's like recognizing a delivery truck by its name plate instead of peeking inside.
Full Explanation
Custom application detectors let you name traffic that the shipped OpenAppID set does not identify by matching a supported signal. The SSL Host pattern matches the server name the client sends in the TLS handshake; when that name is sent visibly, it can be read without decrypting the session, so the detector can keep tagging the registry whichever cloud address it resolves to. Once the traffic carries that name, an application filter groups it for reports and dashboard widgets. Matching a URI path assumes access to the HTTP request, which an encrypted TLS session does not provide without decryption, so that detector cannot match the path. Depending on built-in identification assumes it identifies this in-house registry as a named application, which the scenario does not establish. Filtering connection events by address object can return counts, but the addresses rotate, so the chart fragments as soon as the registry moves. Caveat: the pattern only matches a name the client actually sends visibly in the handshake; a session opened straight to an address without a visible server name will not be tagged. Practical check: make one request to the registry, then confirm the application name appears in the connection event before you build the report.