CIS-Discovery study guide: pass the ServiceNow Discovery implementation specialist exam
A field guide to the CIS-Discovery exam: MID Servers, credentials, the four discovery phases, patterns, and the IRE knowledge that actually decides who passes.
The CIS-Discovery is for people who populate CMDBs for a living, or are about to: ITOM engineers, CMDB owners, infrastructure folks who got handed the Discovery module, and consultants implementing it at customers. Where the CSA asks whether you understand the platform and the CAD asks whether you can build on it, this one asks whether you can walk into an environment with ten thousand unknown IP addresses and turn them into a CMDB that people trust.
Here is my honest read on its value, having implemented Discovery at several organizations. This certification signals something rarer than scripting skill: it says you understand the machinery that keeps configuration data true. Bad Discovery implementations are everywhere, half-scanned networks, duplicate CIs breeding in the dark, a CMDB nobody believes, and the people who can fix them are scarce. If ITOM is your line of work, this cert pays for itself. If you are a generalist collecting certificates, skip it; without infrastructure context the material will not stick, and the exam is written to catch exactly that.
One thing up front, because it shapes the whole guide: the topic that decides who passes is not the MID Server or credentials. It is identification and reconciliation, the IRE. People who treat the IRE as a footnote fail this exam, and worse, they fail their implementations. We will spend our time accordingly.
The exam at a glance
Booked through Now Learning, proctored online or at a test center, multiple choice, around 60 questions in 90 minutes. The blueprint covers roughly this ground:
| Domain | What it covers | Approximate weight |
|---|---|---|
| Discovery overview and architecture | What Discovery does, components, how the pieces talk | ~10% |
| MID Server | Installation, validation, capabilities, clusters, sizing | ~20% |
| Credentials and classification | Credential types, order, affinity, classifiers | ~15% |
| The discovery process | Phases, probes and sensors, patterns, scheduling, ranges | ~25% |
| CMDB and the IRE | CI classes, identification rules, reconciliation, dedup, health | ~20% |
| Troubleshooting | Discovery log, ECC queue, common failure signatures | ~10% |
As with every ServiceNow exam, the question count, duration, and exact weights move between blueprint revisions. Take the table as the shape of the exam and check the current blueprint on Now Learning before you book.
Before you start
The CSA is the prerequisite for CIS tracks, so that comes first, and ServiceNow's Discovery fundamentals training is part of the expected path, often bundled with the voucher; check the current requirements on Now Learning.
Beyond the formal gates, you want two kinds of background. First, basic infrastructure literacy: what SSH and WMI are, what SNMP does, roughly how subnets and CIDR ranges work. Discovery is a conversation with infrastructure, and you need to speak enough of the language to follow it. Second, a lab. A PDI plus one virtual machine on your own hardware is enough: the MID Server installs on any modest Windows or Linux box, and discovering even a two-machine home lab teaches you more than any amount of reading. The labs below assume exactly that setup.
The concepts that actually matter
What Discovery is, and what it is not
Discovery finds things on your network and records them in the CMDB: servers, network devices, storage, the software running on them, and the relationships between them. It is agentless; instead of installing software on every target, it reaches out over standard protocols (SSH, WMI and WinRM, SNMP, HTTP APIs) from a MID Server sitting inside your network, using credentials you provide. Horizontal discovery, the kind this exam is about, sweeps IP ranges and maps what exists.
Now the distinction the exam draws early and often: Discovery is not Service Mapping. Horizontal discovery answers "what is out there and what is it running?" It finds hosts and applications and the basic relationships between them (this Tomcat runs on this Linux server). Service Mapping performs top-down discovery: starting from a service entry point, it walks the actual traffic path to answer "which specific components deliver this business service?" Same MID Servers, same credentials, overlapping patterns, completely different question. When a scenario talks about application service maps and entry points, you are in Service Mapping territory.
Also not Discovery: asset management (assets and CIs are related but distinct records with different lifecycles), and agent-based inventory tools.
The MID Server: your agent on the inside
The instance lives in ServiceNow's cloud; your servers live behind your firewall. The MID Server bridges them, a Java application installed on a Windows or Linux host inside your network. Communication direction is the architectural fact to internalize: the MID Server always initiates, polling the instance over HTTPS for work and posting results back. No inbound firewall hole, which is why security teams tolerate it.
The work queue between them is the ECC queue, a table (ecc_queue) on the instance. Output records are instructions for the MID Server; input records are the results coming back. Burn that vocabulary in now, because every Discovery troubleshooting session of your life starts at the ECC queue, and the exam knows it.
Installation and validation: download the installer from the instance, install on the host, point it at the instance URL with a MID user's credentials, then validate it from the instance before it will do real work. The MID user needs the mid_server role, not admin, an exam favorite and a security review favorite. After validation you assign coverage: which IP ranges it serves, which applications (Discovery, Orchestration, Service Mapping) may use it, which capabilities it advertises. Selection logic matters: when a discovery needs a MID Server, the platform matches on application, then IP range, then capabilities.
For scale and resilience, MID Servers form clusters: load-balancing clusters spread work across members, failover clusters keep discovery running when a member dies. Know both and when you would choose each. Operational basics: MID Servers auto-upgrade from the instance, they are often dedicated per network segment or DMZ, and one MID Server cannot serve networks it cannot route to, which sounds obvious until an exam scenario hides the answer behind exactly that.
Credentials and credential order
Discovery logs into things, so it needs credentials: SSH keys or passwords for Unix and Linux, Windows credentials for WMI/WinRM (with the domain account requirements that come with it), SNMP community strings for network gear, and API keys for cloud and appliance types. They are stored encrypted on the instance in the credentials table, or externally in a credential vault via a broker, an architecture the exam expects you to know exists.
The subtleties that separate the prepared: credential order determines the sequence in which Discovery tries credentials of a matching type against a target. Lower order runs first. Get the commonly correct credential at the top and discovery gets faster and target account-lockout logs get quieter; I have seen a badly ordered credential list lock out a service account across an entire Windows estate in one afternoon, which is a memorable way to meet the security team. Credential affinity is the platform remembering which credential worked for which target and trying it first next time, which is why the second discovery run is faster than the first. Credentials can also be scoped to IP ranges, and MID Servers can hold certain credentials locally in specific setups.
The four phases, in order, forever
Everything Discovery does to a single IP address happens in a fixed sequence of phases. This is the centerpiece of the exam: questions name a symptom and expect you to place it in the correct phase, so the phases need to be reflexive.
Operationally: scanning (the Shazzam phase, after the probe that performs it) needs no credentials, it is pure port behavior. Classification is the first credentialed step, and its output is a class decision: this is a cmdb_ci_win_server, go run the Windows exploration. Identification is where the CMDB is protected from duplicates; it gets its own section below because it deserves one. Exploration is the deep dive, and it is where patterns do most of their work.
The phase model is also your triage map. Device unclassified? Credentials or classification, not exploration. Duplicate CIs? Identification, always. Device missing entirely? Scanning: the port scan never saw it, check ranges and firewalls. Once you think in phases, half the troubleshooting domain becomes free marks.
Probes and sensors, and the pattern era
Discovery's original engine works in pairs: a probe goes out (via the ECC queue, through the MID Server) and runs a command or query against the target; a sensor is the script on the instance that processes what came back and writes CMDB data. Many probes and sensors are still in service, especially for scanning and classification, so you must know the model: probe out, payload back, sensor processes.
The modern engine is patterns: sequences of operations (run a command, parse a file, query a registry key, call an API) defined in Pattern Designer, executed on the MID Server, with parsed results shipped home in bulk. Patterns are what you customize in real implementations: extending one to grab a custom attribute is the everyday job, and the exam expects you to know pattern structure (identification section, exploration section, steps, variables). Pattern debugging happens in Pattern Designer against a live target, a far kinder experience than probe XML archaeology, and the exam prefers pattern answers for new customization for exactly that reason.
Where do the results go in either model? Not straight into cmdb_ci tables. They go through identification. Which brings us to the part of this guide I most want you to remember.
The IRE: the machinery that decides pass or fail
The Identification and Reconciliation Engine stands between incoming discovery payloads and your CMDB tables. Every insert or update flows through it. It answers two questions: is this an existing CI or a new one? (identification) and which data source is allowed to write which fields? (reconciliation). Understand this section deeply and you are in the group that passes; the exam probes it from more angles than any other topic.
Identification works through identification rules defined per CI class. A rule contains identifier entries, prioritized sets of attributes that can uniquely identify a CI of that class: serial number for hardware, name plus parent for applications that only make sense in context. Rules distinguish independent CIs (a server, identifiable on its own) from dependent CIs (a database instance, identifiable only relative to its host, via dependent rules). The engine evaluates identifier entries in priority order: a match means update that CI, no match anywhere means insert a new one. Weak or missing rules for a class are how you get four copies of the same server, one per data source that ever touched it.
Reconciliation handles the second problem: multiple sources (Discovery, an integration, manual entry) disagreeing about the same CI. Reconciliation rules declare which data source may update which attributes of which class, and data source precedence settles conflicts, so your hand-entered serial number does not get stomped by a lower-trust import. Also worth knowing: de-duplication tasks, generated when the engine detects probable duplicates it cannot safely merge on its own.
The most expensive Discovery failure mode is silent: an integration writing directly to cmdb_ci tables with GlideRecord, bypassing the IRE entirely. No identification, no reconciliation, duplicates forever. The correct pattern, in implementations and on the exam, is always through the IRE (the identification engine APIs) so the rules actually run.
The IRE writes into a class hierarchy, and you should be able to sketch the discovery-relevant spine of it. Every CI class extends cmdb_ci, and classification decisions land targets in the right branch:
cmdb_ci
├── cmdb_ci_hardware
│ └── cmdb_ci_computer
│ ├── cmdb_ci_server
│ │ ├── cmdb_ci_win_server
│ │ ├── cmdb_ci_linux_server
│ │ └── cmdb_ci_esx_server
│ └── cmdb_ci_pc_hardware
├── cmdb_ci_netgear
│ ├── cmdb_ci_ip_switch
│ └── cmdb_ci_ip_router
├── cmdb_ci_appl
│ ├── cmdb_ci_apache_web_server
│ └── cmdb_ci_db_instance
│ └── cmdb_ci_db_mysql_instance
└── cmdb_ci_vm_instance
Why the tree matters: identification rules are defined at class level and inherit down, classification chooses the class, and reporting or ACLs applied high in the tree cover everything beneath. When an exam question asks where a discovered Windows machine lands or which rule identifies a MySQL instance running on it (a dependent CI, hosted on the server), this tree plus the dependent-rule concept is the answer.
Finally, CMDB health: the dashboards that score your CMDB on completeness (required fields populated), compliance (audit rules), and correctness (duplicates, staleness, orphans). Know the three categories and that duplicate detection here is the downstream safety net for identification problems upstream.
Running it for real: schedules, ranges, cloud, and troubleshooting
Discovery runs from discovery schedules: what to discover (IP ranges or specific targets), which MID Server or cluster, when, and how (full discovery versus network-only, max run time). Ranges can be entered manually, imported, or built from network discovery itself. Schedule design is a real skill: stagger by subnet, respect change windows, and never point an aggressive schedule at a fragile segment without warning its owners. Quick Discovery of a single IP is your test harness.
Cloud discovery, at the altitude this exam flies: AWS, Azure, and GCP resources are discovered through API calls against the provider (service accounts and API keys, not SSH), driven by cloud discovery schedules. The resulting CIs flow through the same IRE. Know the shape, credentials plus API plus IRE, and leave the per-provider details to the docs.
Troubleshooting lives in two places. The discovery log (per discovery status record) narrates each phase per IP: classification failures, credential failures, sensor errors, all timestamped and phase-tagged. The ECC queue shows the raw conversation. A stuck output record means MID Server trouble (down, wrong capabilities, wrong range); an error input means the probe or pattern ran and failed on the target.
A practitioner's helper for the first symptom, output records nobody claimed, run from scripts background on a non-production instance:
// find output records stuck unclaimed for 15+ minutes (MID Server not picking up work)
var gr = new GlideRecord('ecc_queue');
gr.addQuery('queue', 'output');
gr.addQuery('state', 'ready');
gr.addQuery('sys_created_on', '<', gs.minutesAgoStart(15));
gr.orderByDesc('sys_created_on');
gr.setLimit(20); // sample, not sweep
gr.query();
while (gr.next()) {
gs.info('Stuck: ' + gr.getValue('topic') + ' for agent ' + gr.getValue('agent'));
}
When you troubleshoot in the lab, keep the discovery log and the ecc_queue list open side by side, filtered to the same discovery status. Watching one run flow through both views teaches the architecture better than any diagram, including mine.
A six week study plan
Assumes CSA-level platform knowledge, about eight to ten hours a week, and the PDI-plus-one-VM lab.
Week one: architecture and the MID Server. Read the architecture, then build it: install a MID Server on a local VM or spare machine, validate it, assign capabilities and an IP range covering your lab. By Friday you should be able to draw instance, MID, ECC queue, and target from memory.
Week two: credentials and first blood. Set up SSH and, if you have a Windows box, Windows credentials. Run Quick Discovery against your VM. Read the entire discovery log for that run, every line, and map each entry to its phase.
Week three: the phases and classifiers. Study scanning, classification, identification, exploration until the flow diagram above is reflex. Explore port probes and classifiers in the instance. Break classification deliberately (wrong credential) and observe exactly where the log complains.
Week four: patterns and the IRE. Walk through an out-of-box pattern's identification and exploration sections in Pattern Designer and debug it against your VM. Then the deep IRE week: read the identification rules for cmdb_ci_server and one dependent class, and run payloads through identification simulation to watch match-versus-insert decisions happen.
Week five: operations. Build a real discovery schedule with a range set. Explore CMDB health dashboards. Read cloud discovery architecture and MID Server clusters (the concepts carry the questions). Practice the troubleshooting drill: break something, find it from symptoms alone.
Week six: consolidate and drill. Redo the weakest lab. Practice questions diagnostically. Recite the four phases, credential order and affinity, and the IRE decision flow to someone patient. Book the exam.
Hands-on labs on your PDI
- MID Server from bare metal. Install, validate, set capabilities and ranges, then stop the service and watch what the instance reports. Restart it. You now understand MID status from both ends.
- One IP, full autopsy. Quick Discovery against your lab VM. Label every discovery log line with its phase. This single exercise covers a quarter of the blueprint.
- Credential order experiment. Create two SSH credentials, one wrong, ordered first. Discover, watch the failure then the success, then check affinity: the next run should try the working credential first.
- Break classification on purpose. Remove credentials and discover: unclassified device. Restore and rerun. The symptom-to-phase mapping you build here answers a half-dozen exam questions.
- Duplicate CI, created and cured. Insert a CI by hand matching your VM (same serial number), discover, and watch identification update your record instead of inserting. Then damage the identifying field and rerun to see a duplicate appear. Clean it up with the de-duplication tooling. This is the IRE lab; do not skip it.
- Pattern surgery. Debug an OS pattern against your VM in Pattern Designer and add one step capturing a value the pattern currently ignores. Verify it lands on the CI.
- ECC queue stakeout. Run a discovery with the ecc_queue list open, filtered and refreshing. Watch output become input. Then stop the MID Server mid-run and study what a stuck queue looks like.
- Schedule and range design. Build a schedule for a /28 range including your VM, run it off-hours, and review the discovery status rollup: what succeeded, what was skipped, what timed out.
How the questions try to trick you
Phase misdirection. A symptom from one phase with answer options drawn from another: duplicate CIs paired with credential fixes, unclassified devices paired with pattern edits. Name the phase first, then look at the options. Duplicates are identification. Unclassified is classification or credentials. Missing entirely is scanning.
Service Mapping bait. Options mentioning entry points and top-down maps for plain horizontal discovery scenarios. Different capability, wrong answer, unless the question explicitly asks about business service maps.
The almighty MID account. Answers granting the MID user admin or domain admin. The MID user needs mid_server; target credentials need what the protocol needs. Least privilege wins every security-flavored question.
Direct-write temptations. Fix data problems by scripting straight into cmdb_ci? Never the right answer. Through the IRE, with identification rules, every time.
Push versus pull. Statements implying the instance connects inbound to the MID Server. It never does; the MID Server always initiates over HTTPS. Any answer requiring an inbound firewall hole is wrong.
Credential shotgun. Answers suggesting more or mightier credentials fix slow discovery. The fix is usually order, affinity, or range scoping: fewer, better-aimed attempts, not more ammunition.
Exam week checklist
- Self-score the current Now Learning blueprint line by line; drill only the reds.
- Redo lab 5 (the IRE lab) from scratch. If any part of identification rules or reconciliation feels fuzzy, that is your remaining study time, all of it.
- Recite the four phases with a one-line symptom for each. Do the same for the ECC queue round trip.
- Review MID Server selection logic (application, then range, then capabilities) and cluster types; both are dense with easy marks.
- Verify your proctoring setup the day before if testing online.
- In the exam, tag each scenario with its phase before reading the options. It converts trick questions into sorting exercises.
After you pass
Delta exams through Now Learning keep the certification current per release; do them on time.
Then put it to work, because the specialty compounds. The natural adjacent moves: Service Mapping (you already have the MID Servers, credentials, and patterns; top-down is the missing piece), Event Management (a clean CMDB is exactly what alert correlation needs), and the broader CSDM story of how discovered infrastructure supports application services. And keep one habit from your study: before extending any discovery, read the identification rules for the classes involved. The people who check the rules first are the people whose CMDBs get trusted, and now you are one of them.