CIS-SM Service Mapping Practice Questions

The discovery process often works in stages. A device might first be classified into a general parent class (like Server). As more specific probes run and gather more information (like OS name and version), the system can move the CI to a more specific child class (like Linux Server). This process of moving a CI down the class hierarchy to a more specific class is officially termed a 'class upgrade'.

In a standard Apache-Tomcat integration, the connection is often made using the AJP (Apache JServ Protocol) connector, not standard HTTP. The out-of-the-box Apache pattern's connection section needs to find the configuration file that defines this link (e.g., mod_jk.conf or httpd.conf). If the connection information is stored in a non-standard file path or uses a custom configuration format, the pattern will not find the connection details. The most likely issue is that the pattern's 'Parse File' or 'Find File' operations are not looking in the right place or for the right syntax to discover the AJP connection to the Tomcat servers.

When glide.discovery.log_ci_data is set to true, the system will log the entire XML or JSON payload received from the MID Server in the discovery log for each input message in the ECC Queue. This is extremely useful for debugging patterns because it allows the implementer to see the raw data that the pattern is attempting to parse, without having to repeatedly run the pattern in debug mode. However, it should be used sparingly in production as it can generate very large logs.

Service Mapping respects the boundaries defined by IP ranges. If a pattern discovers a connection to an IP address that is not included in any IP range configured for discovery, it will not attempt to discover that endpoint. Instead, it will represent the connection on the map with a special icon (often a circle with a dot) indicating that this is an unscoped or boundary connection. This prevents Service Mapping from unintentionally scanning devices outside its authorized scope, such as the public internet or a partner network.

Traffic-based mapping relies on collecting data about active network connections on servers. The primary mechanism for this is by running commands like netstat (or equivalent tools) on the target hosts via the MID Server. This command provides a snapshot of all TCP connections, including source IP/port and destination IP/port. This data is sent back to the ServiceNow instance, where machine learning algorithms analyze it to identify recurring communication patterns and suggest them as CI relationships.

This statement is true. The pattern execution flow is hierarchical. First, the classification phase of horizontal discovery must identify a running process and classify it to a specific CI type (e.g., 'Apache Web Server'). The system then looks for active patterns that are designed to operate on that specific CI type. Only then will the 'Identification Section' of the matching pattern be executed to confirm the identification and create/update the CI.

The service map interface provides powerful, user-friendly 'View' and 'Filter' capabilities. Users can switch between different views, such as an 'Application' view that hides infrastructure, or a 'Physical' view that shows it. Additionally, they can apply filters to show or hide specific CI classes (e.g., hide all CIs of class 'Network Switch'). This allows different stakeholders, from engineers to business owners, to see the level of detail that is most relevant to them without altering the underlying discovered data.

For proprietary TCP protocols where configuration files are not available or readable, the most reliable method to discover active connections is to inspect the network state of the host machine. Running a command like netstat (for Windows) or lsof -i (for Linux/Unix) will list active network connections. The output of this command can then be parsed within the pattern to identify the remote IP addresses and ports the application is communicating with, allowing Service Mapping to create the correct dependency links.

A 'Connection timed out' error indicates that the MID Server sent a request to the target port, but received no response, which is a classic symptom of a firewall blocking the traffic. Since horizontal discovery of the nodes works (likely via SSH/WMI), but the specific application port is unreachable, it points to a network access control list (ACL) or firewall rule that is not configured to allow the MID Server to communicate with the Oracle Listener port. Incorrect credentials would typically result in an authentication error, not a timeout.

ServiceNow provides a specific feature for this purpose. Within the configuration of a discovered application service, there is a checkbox labeled 'Update on change'. When this option is enabled, Service Mapping will automatically trigger a re-discovery of that specific service whenever a CI that is part of the service map is updated through a change request. This is the most efficient and targeted method, as it avoids unnecessary full-schedule rescans.