← Home
🔥0 DAY
⚡0 XP
Interview Prep · Discovery & CMDB

DISCOVERY
INTERVIEW.

Four scenario lessons covering horizontal vs top-down discovery, MID Server sizing, classification vs identification rules, and the IRE — each with a runnable simulator trace you can step through.

Pair with the scenario scripting guide for full interview coverage.

  1. 1. Horizontal vs Top-Down Discovery — when to use each

    “Your CMDB has servers populated but no business-service dependencies. Which Discovery flavor do you reach for?”

    How to answer

    • Horizontal Discovery scans IP ranges, probes ports, and populates infrastructure CIs (servers, network gear, apps).
    • Service Mapping (top-down) starts from an entry point (URL or load balancer) and traces traffic to map a business service.
    • Horizontal answers 'what exists', top-down answers 'what depends on what'.
    • Run horizontal first to seed CIs; layer Service Mapping on top for impact analysis and outage scoping.

    Reference config

    // Discovery schedule (horizontal)
schedule.name      = 'Prod DC1 sweep';
schedule.ip_range  = '10.42.0.0/16';
schedule.mid_group = 'mid_dc1';

// Service Mapping (top-down)
serviceMap.entry_point = 'https://shop.example.com';
serviceMap.discover_from = 'Load Balancer VIP';

    Pitfall

    Service Mapping needs accurate horizontal CIs first — running it against a sparse CMDB produces orphan 'unknown' nodes that look like outages on the dashboard.

  2. 2. MID Server architecture — placement, credentials, and load

    “How do you size and place MID Servers for a multi-region datacenter discovery?”

    How to answer

    • MID Server runs inside the customer network and brokers traffic between the instance and discovery targets.
    • Place one MID Server cluster per network zone (DC, DMZ, cloud VPC) so probes don't cross firewalls.
    • Each MID Server needs Java + credentials from the credential table; secrets are pulled at runtime, never stored locally in plain text.
    • Rule of thumb: 1 MID Server per ~5,000 CIs scanned per cycle; add a cluster member before maxing out a single host.

    Reference config

    // MID Server config (config.xml)
<parameter name="name"     value="mid_dc1_a"/>
<parameter name="url"      value="https://acme.service-now.com"/>
<parameter name="mid.instance.username" value="midserver_svc"/>

// Credential affinity (sys_user_group)
group.name = 'mid_dc1';
group.applies_to = ['mid_dc1_a','mid_dc1_b'];

    Pitfall

    A single MID Server straddling two firewall zones works in dev and silently drops probes in prod. Always split MID clusters along network boundaries.

  3. 3. Classification vs Identification rules — what runs when

    “Two servers with the same hostname show up as duplicate CIs after every Discovery run. Which rule type is misconfigured?”

    How to answer

    • Classification rules look at probe output to decide WHAT a CI is (Linux, Windows, Cisco router…).
    • Identification rules decide WHO a CI is (which existing record matches) using priority-ordered criteria sets.
    • Order matters: classification runs first, then identification matches via serial_number → MAC → name+IP → name.
    • Duplicate CIs almost always trace back to identification — usually name-only matching with no FQDN or serial.

    Reference config

    // Identification rule on cmdb_ci_server
rule.name = 'Server identification';
rule.criteria = [
  { attribute: 'serial_number', priority: 1 },
  { attribute: 'mac_address',   priority: 2 },
  { attribute: 'name+ip_address', priority: 3 },
];
rule.allow_independent_search = false;

    Pitfall

    Setting allow_independent_search=true lets the engine fall through to weaker criteria and creates duplicates. Keep it false unless you really know why.

  4. 4. CI reconciliation & IRE — who writes wins

    “Discovery overwrote the CI 'environment' field that the SACM team manually set. How do you stop it next time?”

    How to answer

    • The Identification and Reconciliation Engine (IRE) is the single entry point for every CI write — Discovery, Service Mapping, integrations, all of it.
    • Reconciliation rules declare which DATA SOURCE owns which attribute on which class.
    • If 'SACM' owns environment on cmdb_ci_server, Discovery payloads that include environment are silently dropped for that field.
    • Always file reconciliation rules in source control — they're the contract between teams writing to the same CIs.

    Reference config

    // Reconciliation rule
rule.applies_to = 'cmdb_ci_server';
rule.attribute  = 'environment';
rule.data_source = 'SACM';     // wins
rule.precedence  = 1;

// Discovery payload arriving second is ignored for this field
payload.data_source = 'ServiceNow';
payload.environment = 'production';

    Pitfall

    Without reconciliation rules, the most recent write wins — meaning Discovery and your CMDB integration ping-pong values every hour. Define ownership before turning on a second source.

Keep going

Glossary topicsScenario scripting