CIS-SM Sample Questions & Answers

The Identification and Reconciliation Engine (IRE) is the core CMDB feature for preventing duplicate CIs. By defining robust Identification Rules, you tell the IRE which attributes to use to uniquely identify a CI, regardless of the discovery source. Reconciliation Rules and Datasource Precedence Rules then govern which data source is authoritative for which attributes when updates occur. Properly configuring the IRE rules for the web server class will ensure that both Service Mapping and horizontal discovery identify and update the same CI record.

ServiceNow discovers Kubernetes environments by querying the Kubernetes API, not by logging into individual nodes. This API provides all the necessary information about namespaces, services, pods, and their relationships.

ServiceNow provides specialized patterns for discovering modern technologies like Kubernetes. These patterns contain the necessary logic to query the API and build the correct CI model in the CMDB.

For a containerized application exposed to users, the Ingress controller or Load Balancer is the logical starting point for top-down discovery. Mapping starts from this entry point and traces the traffic flow through Kubernetes services to the backend pods.

The 'Log' operation in the Pattern Designer has a 'Level' parameter (e.g., Debug, Info, Warn, Error). The pattern execution itself also has a log level, which is controlled by system properties (e.g., glide.discovery.debug). If the message in the 'Log' step is set to 'Debug', but the overall pattern discovery log level is set to 'Info', the debug message will not be written to the log. This is a common issue when debugging patterns.

A 'Generic Application' CI is created when Service Mapping detects a listening process on a port but no pattern's Identification Section successfully matches that process. The first step in troubleshooting is to examine the Discovery Log for the source CI (the Apache server). The log will contain details about which patterns were attempted on the destination IP/port, why they failed (e.g., credential failure, no matching process found), and the information that was gathered. This information is crucial for determining whether to fix credentials, adjust the Tomcat pattern, or create a new pattern.

The Extension Section is a critical feature for maintaining customizations across platform upgrades. It allows an implementer to add custom steps (e.g., to gather additional attributes or create extra relationships) to a baseline, out-of-the-box pattern. These extensions are stored separately from the base pattern. During an upgrade, the base pattern can be updated by ServiceNow without overwriting the custom logic in the Extension Section. This prevents customizations from being lost and reduces the maintenance burden.

ServiceNow provides a specific mechanism to filter out noise from traffic-based mapping. Under Service Mapping > Administration > Traffic Connection Management, administrators can create rules to exclude connections based on criteria such as the process name (e.g., 'backup.exe'), the TCP port (e.g., port for a monitoring tool), or IP address ranges. This allows the system to ignore common infrastructure traffic and focus on suggesting connections that are relevant to the business service.

By providing a clear view of all CIs that constitute a business service and their dependencies, Service Mapping allows change managers to accurately assess the potential impact of a change, reducing the risk of unplanned outages.

When an incident occurs, a service map immediately shows the incident response team all the infrastructure and application components that support the affected service. This context is critical for quickly narrowing down the potential root cause, which significantly reduces MTTR.

The MID Server selection process is highly structured. ServiceNow discovery probes and patterns can be configured to require a specific capability. When a discovery schedule runs (e.g., a VMware discovery), the system looks for a validated, active MID Server that has the required 'VMware' capability. This ensures that only MID Servers that are properly configured and located to perform a specific type of discovery are used for that task. If no MID Server has the required capability, the job will fail.

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.