Architecture and Discovery
About 13% of the CIS-EM exam — see all 5 domains.
This domain is about the moving parts that make Event Management work and how it depends on a well-discovered CMDB.
MID Server
The MID Server (Management, Instrumentation, and Discovery) is a Java application that runs inside the customer network and brokers communication between the ServiceNow instance and on-premise resources. It is the workhorse for both Discovery and Event Management collection. The instance never connects directly into the customer's data center; the MID Server does, and it initiates outbound communication to the instance.
For Event Management, a MID Server runs connectors that collect events. MID Servers have capabilities and applications that scope what work they can do; for Operational Intelligence/metrics you assign the Metrics capability and run the Operational Intelligence (Metric Intelligence) extension. MID Servers can be clustered for load balancing and high availability.
Discovery and the CMDB dependency
Event Management is only as service-aware as the CMDB beneath it. Discovery populates the CMDB with CIs and their attributes; Service Mapping builds the service topology (which CIs support which business services). Without accurate CI records and relationships, CI binding fails, topology-based correlation cannot work, and service impact cannot be computed. This is why CMDB health, CSDM structure, and Discovery quality are explicitly part of Event Management architecture.
How events reach the instance
- Push — an external monitor (or script) sends events to the instance or to a MID Server via the web service / REST API. The sender initiates.
- Pull — a MID Server connector periodically queries the external monitoring system and brings events back. The MID Server initiates on a schedule.
Both paths land events in em_event for the same processing pipeline.
Components installed
Activating Event Management installs the event/alert tables, processing jobs, base event rules and subflows, dashboards, and the operator workspace artifacts. Operational Intelligence and Health Log Analytics are separately installed/licensed capabilities layered on top.
Sample questions from this domain
Three of the 39 in this domain, with the reasoning. The full set is in the question bank.
What is the primary role of a MID Server in an Event Management deployment?
- A. To replace the CMDB identification engine
- B. To securely collect events from on-premises monitoring tools and relay them to the ServiceNow instance ✓
- C. To store alerts in the em_alert table
- D. To render the Operator Workspace dashboards
Why: The MID Server acts as a secure bridge that collects events from on-premises sources and relays them to the ServiceNow instance, especially for pull connectors. It does not store alerts, replace the identification engine, or render dashboards.
In a pull-based monitoring connector, which component initiates the collection of events?
- A. The em_event table polls external systems
- B. The MID Server periodically queries the monitoring tool for new events ✓
- C. The monitoring tool pushes events directly to the instance
- D. The end user manually exports a CSV each interval
Why: With a pull connector, the MID Server periodically queries (pulls) the monitoring tool to collect new events. A push model has the tool send events to the instance, em_event does not poll external systems, and manual CSV export is not how pull connectors operate.
Which method do push-based event sources typically use to deliver events to ServiceNow?
- A. They send events to the Event Management REST/web service endpoint (inbound API) ✓
- B. They rely on the MID Server pulling on a timer
- C. They require a Discovery schedule to import events
- D. They write directly to the cmdb_ci table
Why: Push sources deliver events by sending them to the Event Management inbound REST/web service endpoint. They do not write to cmdb_ci, do not rely on Discovery schedules, and do not depend on a MID Server polling timer (that is the pull model).