Part 3 Full Quiz — Discovery & Service Mapping
18 questions (15 topic questions + 3 cross-topic integration) covering Discovery architecture, MID Server, patterns & probes, Service Mapping, and ACC. Select an answer to reveal the explanation.
Which type of Discovery should be used?
B is correct. CI Group Discovery is designed specifically for refreshing data on CIs already in the CMDB. It targets a defined group (static or dynamic) instead of scanning an IP range for new devices. IP Range Discovery (A) finds NEW unknown CIs — it's less efficient for known servers. Horizontal Discovery (C) is not a schedule type you trigger separately; it's a phase of the Discovery process. Service Mapping (D) discovers application dependencies, not CI attributes.
What should the admin investigate next?
B is correct. Discovery runs in two phases: Horizontal (classifies the CI class) and then Vertical (collects detailed configuration attributes). If Horizontal succeeded but attributes are missing, Vertical either didn't run or failed. Check the Vertical patterns and credential coverage for this CI class. CMDB Health (C) shows the problem but doesn't diagnose the cause. Manual entry (D) is a workaround, not a fix.
[TRAP] Why did no Vertical Discovery data get collected for this device?
B is correct and this is a KEY TRAP. Horizontal Discovery must successfully classify a device (determine its CI class) before Vertical Discovery runs. If no Horizontal Pattern matches — perhaps because the device is a network appliance with no matching pattern — no CI is created and Vertical never executes. The fix is to create a Horizontal Pattern for the device type or add it manually. Vertical Discovery is automatic once Horizontal succeeds — it doesn't need manual triggering (D).
Which of these requires a MID Server?
B is correct. A MID Server is required for on-premises Discovery because the ServiceNow cloud instance cannot directly access devices on a private network behind a firewall. The AWS Service Graph Connector calls AWS public APIs (EC2, RDS, etc.) which are internet-accessible — no MID Server needed. The MID Server acts as an on-premises proxy; public cloud APIs are already internet-facing.
Which MID Server will ServiceNow assign this Discovery job to?
B is correct. ServiceNow uses capability-based routing to select the appropriate MID Server. Each Discovery target has capability requirements (SSH for Linux, WMI for Windows, SNMP for network devices). ServiceNow matches the target's required capability to a MID Server that has declared that capability. MID-2 only has SNMP — it cannot handle SSH targets. MID Servers don't handle jobs simultaneously for the same target (D).
[TRAP] What is the impact on Discovery?
B is correct. A single MID Server is a single point of failure. If it goes down, all Discovery for the private network it covers stops. ServiceNow cloud cannot reach private network devices directly (C is false — that's why MID Server exists). There is no automatic agentless fallback (A). The best practice is to use MID Server clusters for production coverage — multiple MID Servers grouped together provide load balancing and failover.
Which Discovery component executed the SSH command, and which mapped the output to CI fields?
B is correct. In classic Discovery (probe/sensor model): a Probe is the instruction from ServiceNow to the MID Server to collect data from a target (executing SSH commands, WMI queries, SNMP OID walks). A Sensor is the script on ServiceNow that parses the raw probe response and maps the data to CI fields. Probe = collect; Sensor = parse. In modern Pattern Designer, steps combine these concepts, but the directional distinction is the same.
What is the best practice to make credential rotation easier?
B is correct. A Credential Alias is a named reference to a credential record stored in ServiceNow's encrypted credential store. Discovery Patterns and schedules reference the alias by name — not the credential directly. When the password changes, update the credential record once; all patterns using that alias automatically pick up the new credential. This is the ServiceNow-designed solution for credential lifecycle management. Storing credentials in Script Includes (C) is a security anti-pattern.
[TRAP] What is the most likely root cause?
A is correct. Vertical Patterns only execute after a CI has been classified by a Horizontal Pattern. If the switches don't have an existing Horizontal Pattern match, they never get classified as a CI, and Vertical Patterns never trigger. The fix: ensure a Horizontal Pattern exists for the switch type and runs first. Vertical Patterns support all CI types including network devices (B is wrong). Pattern Designer supports network devices (C is wrong). Vertical runs automatically after Horizontal on scheduled Discovery (D is wrong).
What CI class does Service Mapping create to represent the running application topology?
B is correct. Service Mapping creates cmdb_ci_service_auto records — Application Service CIs in the CSDM Operated Landscape. These records contain all discovered CIs (servers, databases, load balancers) and their dependency relationships for one business service. This is different from a Business Application (cmdb_ci_appl, option A) which represents the logical application concept in the Designed Landscape. cmdb_rel_ci (C) stores individual CI-to-CI relationships, not the service as a whole.
Which Service Mapping discovery strategy is best suited for this environment?
B is correct. Tag-based discovery uses lightweight agents on hosts that emit service identity tags. Service Mapping reads these tags to build service maps without requiring manual entry-point configuration per service. This scales naturally to dynamic environments like Kubernetes where pods are ephemeral. Top-down (A) requires manually defining entry points for each service — impractical at microservices scale. IP Range Discovery (C) finds CIs but doesn't map service dependencies. Manual entry (D) cannot keep up with dynamic infrastructure.
[TRAP] What is the most accurate response?
B is correct. Discovery and Service Mapping answer different questions and are complementary. Discovery: "What devices exist and what are their attributes?" Service Mapping: "How do these devices connect to form this specific business service?" Service Mapping outputs Application Service models (cmdb_ci_service_auto) that show application topology — impossible to get from Discovery alone. Both are ITOM Visibility tools that work together. They don't conflict (D) and neither replaces the other (A, C).
Which approach should be used?
B is correct. ACC is designed precisely for this scenario. It is installed ON the target server and pushes CI attribute data TO ServiceNow via outbound HTTPS (port 443) — no inbound connection to the server is required. MID Server (A) still requires the MID Server to send probes TO each target — inbound connection required on each server. Import Sets (C) is manual and doesn't provide automated refresh. Service Mapping (D) maps application dependencies from outside, not CI attributes from locked-down servers.
[TRAP] Can ACC be used for this purpose?
B is correct and this is an important TRAP. ACC is an agent-based tool — it must be installed on each target device in advance. It cannot scan networks, probe unknown IPs, or self-install. To discover unknown devices, use IP Range Discovery (with a MID Server). The recommended workflow: use IP Range Discovery to find and classify new CIs, then deploy ACC on high-security hosts for secure ongoing CI refresh. ACC and MID Server-based Discovery are complementary.
Which architectural statement correctly distinguishes ACC from MID Server?
B is correct. This is the key architectural distinction: MID Server is deployed as a proxy host on the private network — it reaches OUT to targets using SSH/WMI/SNMP (no agent installed on targets). ACC is installed directly on each target host — the agent pushes CI data OUT to ServiceNow via HTTPS (no need for the network to reach the target). MID Server = outbound from ServiceNow through proxy. ACC = outbound from target device. They are NOT interchangeable (D) and they solve different access problems.
Which engine processes this Discovery payload BEFORE any CI record is created or updated in the CMDB?
C is correct. Discovery does NOT write directly to CMDB tables. The payload flows to IRE (Part 4), which runs three phases: Identification (find the existing CI or create a new one), Reconciliation (apply source-authoritative field values), and Deduplication (detect near-duplicate CIs). Only after IRE completes does the CI record reflect the new data. MID Server (A) is a network proxy. Import Sets (B) are a separate ingestion mechanism unrelated to Discovery.
In CSDM 5 (Zurich release and later), what is this top-level CI called and in which table is it stored?
C is correct. Service Mapping always creates its top-level CI in cmdb_ci_service_auto. CSDM 5 (Zurich) renamed 'Application Service' to 'Service Instance' — but the table name is unchanged. High-frequency exam trap: exam scenarios using 'Service Instance' mean the same CI type as 'Application Service.' The base cmdb_ci_service table (B) is not what Service Mapping writes to. Business Service (A) and Technical Service (D) are different CSDM layers.
What is the final state of the CMDB after this Discovery run?
C is correct. Vertical Discovery — which collects the detailed attributes that populate CI fields — only runs AFTER Horizontal Discovery successfully classifies a device. No pattern match = no CI class = no CI creation. The 50 unclassified devices remain invisible in the CMDB. The fix is to create Horizontal Patterns for the unmatched device types. This connects the Discovery lifecycle (Topic 1) directly to the IRE pipeline (Part 4).