Select Two (Multi-Select) Questions

Knowledge Base

Why it fails: Discovery configuration depends on credentials, MID Servers, schedules and IP ranges; the Knowledge Base stores articles rather than discovery definitions. A Knowledge Base is the right choice for documenting procedures or sharing troubleshooting guidance, but it supplies no credentials, probes or ranges that Discovery needs to run.

Incident Management

Why it fails: Discovery configuration requires credentials, MID Servers, schedules and IP service ranges; Incident Management records and resolves service disruptions. Incident Management is the right module for restoring failed services, but it contributes no discovery credentials, probes or schedules, so it cannot be a configuration component.

It requires a dedicated database

Why it fails: The MID Server is a lightweight Java application that connects to the instance over HTTPS and needs no dedicated database of its own. It is tempting because it stores and forwards discovery data, but that data is held in memory and transmitted to the ServiceNow instance, not persisted locally.

It replaces the ServiceNow instance

Why it fails: The MID Server is a Java process running inside the customer network that executes probes and orchestration on behalf of the instance; it never replaces it. It is tempting because it performs discovery and integration work, so it can appear central, but it is an agent, not the platform itself.

It is the only place to define IP ranges

Why it fails: IP ranges are defined in Discovery schedules and the IP address range records, not in the Discovery Status module, which reports progress and outcomes of discovery runs. It is tempting because Discovery Status shows discovered devices, but range configuration lives in the schedules themselves.

It automatically fixes CMDB errors

Why it fails: Discovery Status is a read-only reporting view of discovery runs, showing progress, devices found and errors; it does not remediate or correct CMDB records. It is tempting because it surfaces data problems, but correction requires manual edits or separate remediation workflows.

It is used to manage credentials

Why it fails: Credentials are created and stored in the Credentials module and Discovery credential records, then attached to schedules; Discovery Status only displays run results and errors. It is tempting because both relate to discovery, but credential management sits in its own dedicated module.

Service Mapping

Why it fails: Service Mapping builds application topology from discovered configuration items; it consumes Discovery data rather than forming part of the Discovery flow itself. It is tempting because both features share the same MID Server and credentials, and Service Mapping would be the right answer if the question asked how business services are modelled.

CI Class Manager

Why it fails: CI Class Manager administers the class hierarchy and identification rules for configuration items; it is not a stage in the Discovery flow, which runs from scheduling and discovery through identification and reconciliation. It is tempting because it governs CI classes that discovery populates, but it is configuration tooling rather than a discovery component.

Restart the instance

Why it fails: Restarting the instance clears transient state but provides no pattern-level diagnostics: no step-through, no variable inspection, no probe output. It is tempting as a generic remedy for stuck MID Server jobs, and would be reasonable when a discovery run hangs due to a wedged service rather than faulty pattern logic.

Modify the MID Server source code

Why it fails: MID Server source code is vendor-supplied and unsupported for modification; editing it breaks upgrade paths and support agreements without exposing pattern logic. It is tempting because the MID Server executes patterns, and would be correct only for debugging custom JavaScript steps within a pattern, not the platform itself.

Run the pattern from the command line

Why it fails: Patterns execute inside the MID Server's Java engine against a target; there is no supported command-line invocation that loads and runs a pattern standalone. It appeals because command-line execution is a genuine debugging route for other ServiceNow scripts, such as background scripts and scheduled jobs.

Hardware replacement probes

Why it fails: MID Server probes are executable scripts or commands that gather configuration data; hardware replacement is a physical maintenance task, not a probe type. It tempts as an asset-management activity, but Discovery probes only collect and report CI attributes.

User creation probes

Why it fails: User creation is an administrative action performed in directories, not a Discovery probe function; probes only read and report configuration data. It tempts because user accounts are discovered CIs, but the MID Server never creates users during discovery.

SQL injection probes

Why it fails: SQL injection is an attack technique, not a Discovery probe category; MID Server probes gather configuration items rather than test application security. It tempts because probes execute commands, but no SQL-injection probe type exists in ServiceNow Discovery.

Admin password for the host

Why it fails: The MID Server authenticates to the instance using its own service account credentials, not the host's admin password, which grants nothing on the ServiceNow side. Host admin rights are needed only for installing or troubleshooting the MID Server service on the operating system.

Database credentials

Why it fails: The MID Server never connects to a database; it communicates with the instance over REST and ECC queue messages, so database credentials are irrelevant to that connection. Database credentials matter only for separate JDBC-based discovery of database instances, not for MID-to-instance communication.

Reducing the number of attributes collected.

Why it fails: Reducing collected attributes makes CIs less complete but does not refresh their last-discovered timestamps, so staleness persists. It is tempting because fewer attributes reduce discovery load and processing time, and that approach would be correct when the requirement is improving discovery performance rather than keeping CI data current.

Hardcoding CI attributes manually.

Why it fails: Manual hardcoding fixes attribute values at a point in time, so they drift as discovery sources update and staleness persists rather than being reduced. It is tempting because manual overrides are useful for CIs that discovery cannot reach, but that is a targeted exception, not a staleness-reduction action.

Adding more classes to the dashboard.

Why it fails: Dashboard classes only affect which CIs are displayed and reported on; they do not refresh CI records or update their last-discovered timestamps. It is tempting because dashboards surface stale CIs for review, and adding classes would be correct when the goal is broadening reporting coverage rather than reducing staleness.

Upgrade the database

Why it fails: Database upgrades are performed through the instance upgrade process, not from a MID Server record's related links. It tempts because related links do expose maintenance-style actions on the MID Server itself, yet upgrading the underlying database is a platform-level task unrelated to MID Server controls.

View the CMDB records

Why it fails: Viewing CMDB records is done through CMDB modules and the MID Server's own record, not a dedicated related link on the MID Server form. It tempts because MID Servers populate the CMDB, but the related links offer MID Server actions such as restart and log retrieval instead.

Delete the instance

Why it fails: Deleting the instance is an administrative platform operation, not a MID Server related link. It tempts because related links expose MID Server lifecycle actions such as restart and test, but instance-wide deletion sits in the ServiceNow instance administration area, outside the MID Server record's own controls.

They are not required for Discovery

Why it fails: Discovery requires credentials to authenticate to target devices; without them, probes cannot log in and only limited fingerprint or port data is returned. It is tempting because agentless discovery still needs some access, and credentials would be unnecessary only for credentialless probes such as ping or port scans.

They are stored in the MID Server locally

Why it fails: Credentials are stored encrypted in the ServiceNow instance credential store, not on the MID Server; the MID Server retrieves them at execution. It is tempting because the MID Server performs the probes, but it holds no persistent credential copy, so local storage is incorrect.

They are passed as plain text in the ECC queue

Why it fails: Credentials are encrypted before being placed on the ECC queue and decrypted by the MID Server, so they never travel as plain text. It is tempting because the ECC queue does carry credential references between instance and MID Server, but the payload itself is encrypted.

Managing user access

Why it fails: Capabilities determine which discovery and integration functions a MID Server can execute, not user authentication or authorisation. User access is governed by ServiceNow roles and ACLs, not MID Server capability records. Capabilities are correct when scoping which probes, patterns, or integrations a specific MID Server may run.

Configuring proxy connections

Why it fails: Capabilities select which discovery and integration functions a MID Server performs, not outbound network routing. Proxy connections are configured in the MID Server's config.xml or via MID Server properties, not capability records. Capabilities are the right mechanism when restricting a MID Server to specific probes, patterns, or integrations.

Setting the memory limit

Why it fails: Capabilities govern which discovery, orchestration, or integration functions a MID Server performs, not JVM heap sizing. Memory limits are set through the MID Server's wrapper configuration or JVM parameters on the host. Capabilities are the right control when enabling or restricting specific probe and pattern execution on a MID Server.

Schedule Behaviors

Why it fails: Schedule Behaviors control when discovery runs, not which IP ranges, subnets or CI types are scanned. It is tempting because scheduling feels like configuration of a scan, and it would be the correct answer if the question asked how to control discovery timing rather than scope.

MID Server Capability

Why it fails: MID Server Capability determines which MID Server can execute a discovery, not the address space or targets included. It is tempting because capabilities do constrain which probes run where, and it would be correct if the question asked how to route discovery to specific MID Servers.

Credential profiles

Why it fails: Credential profiles supply authentication for accessing targets; they do not define which devices or ranges are scanned. It is tempting because credentials are mandatory for successful discovery, and a credential profile would be the right answer if the question asked how to authenticate to discovered hosts.

An active Incident Management module

Why it fails: Incident Management is unrelated to Discovery; discovery needs credentials, MID Server access and network connectivity. It tempts because Incident is a core ITSM module, but no incident record is required for a horizontal discovery run against a Windows server.

A manual CI creation

Why it fails: Discovery creates CIs automatically from scan results, so manual creation is unnecessary and can cause duplicates. It tempts because CIs are the discovery output, but the requirement is credentials, MID Server reachability and WMI access, not pre-existing records.

SQL Query

Why it fails: SQL Query is a data-retrieval method, not a parsing strategy; Pattern Designer parses already-retrieved device output using strategies such as JSON, XML, regex or delimited text. It tempts because Discovery does query databases, but the SQL runs in a database step, not as a parsing strategy.

SOAP Envelope

Why it fails: SOAP Envelope is a message format, not a Pattern Designer parsing strategy; the designer parses retrieved payloads using strategies such as JSON, XML, regex or delimited text. It tempts because SOAP responses do contain XML envelopes, but you would select the XML parsing strategy to process that content.

Binary Stream

Why it fails: Binary Stream is not one of the Pattern Designer parsing strategies; those cover delimited, JSON, XML, key-value and similar text formats. It is tempting because discovery collects raw device output that may include binary content, but binary handling belongs to file or payload processing, not to the text-oriented parsing strategies offered in the Pattern Designer.

Database version

Why it fails: The MID Server is a Java application connecting to the instance; it never hosts or queries a database, so database version is irrelevant. It is tempting because database compatibility matters for many on-premises integrations, and would be valid when sizing a database server that the MID Server itself connects to.

User browser settings

Why it fails: MID Server requirements concern OS, Java/JVM version, network connectivity, and service account permissions; end-user browser settings affect only client access to the instance. It is tempting because browser compatibility is a genuine consideration for platform upgrades, but it would apply when validating UI support, not server installation.

Credentials

Why it fails: Credentials are configured in the MID Server and credential records, not the Pattern Designer, so inspecting them there yields nothing; the identification phase runs pattern steps against a target. Credential faults surface as authentication errors, which is when credential troubleshooting becomes the right focus.

Schedule

Why it fails: The Schedule tab controls when a pattern runs, not how it identifies devices, so it cannot explain an identification-phase failure. It is tempting because scheduling is configured in the same Pattern Designer interface, and it would be the right area to inspect if the pattern never launched at all.

Discovery log

Why it fails: The Discovery log records overall run outcomes and errors, but not the step-level pattern logic that determines how identification classifies a device. It is the right place to confirm a discovery failed, yet the Pattern Designer's steps and debug output reveal why identification misfired.

Regex does not support capture groups

Why it fails: Regex engines in ServiceNow patterns fully support capture groups, so this claim is factually false and cannot be a genuine challenge. It tempts candidates who confuse capture groups with named groups or lookbehind, which some flavours restrict; capture groups themselves are standard and widely used in pattern extraction.

Regex is automatically converted to JSON

Why it fails: Regex returns matched text or capture groups, never JSON; conversion to JSON is performed by the pattern's parsing or post-processing step, not the regex engine. It tempts because extracted values are often stored as JSON objects, so the output format appears tied to the matching mechanism.

The instance database is full

Why it fails: A full instance database halts platform-wide writes, so scans would fail everywhere rather than being a Discovery-specific failure cause; capacity issues are an infrastructure concern. It is tempting because database exhaustion does break many operations, and it would be the answer in a question about instance performance or MID Server problems, not scan failures.

The browser is out of date

Why it fails: Discovery runs from a MID Server using credentials and probes, not a browser, so client browser version cannot affect scan execution. It is tempting because browser compatibility genuinely breaks web-based interfaces, and it would be correct for a question about ServiceNow UI access problems rather than Discovery scan failures.

Execute an external shell script

Why it fails: An external shell script runs on the MID Server rather than parsing within the discovery pattern, so the key-value pairs are never mapped to attributes. It is tempting because shell scripts are the right choice when output needs custom processing that built-in pattern steps cannot perform.

Convert the output to XML

Why it fails: Converting output to XML adds a transformation step without extracting the 'key = value' pairs, so no attributes are populated. It is tempting because XML conversion is correct when the target system consumes XML or when the source already returns XML needing namespace handling.

Apply a JSON Path

Why it fails: JSON Path queries hierarchical JSON documents, so it cannot extract 'key = value' text pairs from raw command output. It is tempting because JSON Path is the correct tool when the command returns structured JSON, where keys are already delimited by braces and quotes.

The MID Server has 100% CPU free

Why it fails: Up status requires a recent heartbeat, successful validation, and supported OS; CPU availability is a performance metric, not a status condition. It is tempting because CPU exhaustion does impair discovery, but a busy MID Server still reports Up while its heartbeat remains current.

The MID Server is running on Linux

Why it fails: MID Server status depends on the agent's heartbeat, its validation state, and its supported OS, not on which Linux distribution or platform it runs. Linux is tempting because MID Servers commonly run there, yet Windows hosts reach Up status identically when the same conditions are satisfied.