Hard Difficulty Questions

Change the discovery pattern logic.

Why it fails: Patterns do not control execution timing.

Update the Discovery Behavior record.

Why it fails: Behaviors define what probes are run, not when.

Modify the MID Server cluster affinity.

Why it fails: This affects load balancing, not timing.

Create an ACL for the CMDB Health table.

Why it fails: ACLs control access, not dashboard data inclusion.

Restart the Discovery services.

Why it fails: Restarting services does not update dashboard configurations.

Run a full Discovery of the entire environment.

Why it fails: Discovery does not control dashboard reporting scope.

Regex

Why it fails: Regex matches patterns within text but returns captures requiring separate parsing logic, not a single-step key-value extraction. It is tempting because regex handles irregular, unstructured strings, and would be correct when the input lacks consistent delimiters or needs conditional pattern matching.

Parse Delimited

Why it fails: Parse Delimited splits on a single character and returns positional fields, so colon-separated key-value pairs lose their names. It is tempting because it handles multi-line text efficiently, and would be correct for CSV-style data where each line has fixed columns rather than named keys.

XPath

Why it fails: XPath queries XML or HTML node trees, so it cannot parse a plain multi-line string of colon-separated pairs. It is tempting because XPath extracts values in one step from structured documents, and would be correct when the source is well-formed XML or HTML.

servers->id

Why it fails: The arrow operator belongs to XML parsing, where it navigates element hierarchies; JSON structures use dot or bracket notation instead. servers->id would be valid only against an XML document containing a servers element with a nested id.

servers.id

Why it fails: servers is an array, so servers.id cannot reach a nested property; you must index the element first, for example servers[0].id, or iterate the array. Dot notation works only when servers is a single object, not a collection.

id(servers)

Why it fails: Parse JSON returns a parsed object or array, so property access uses dot or bracket notation, not function-call syntax like id(servers). Function-style accessors belong to other transformation steps, such as string or date utilities, not JSON navigation.

It searches for available MID servers.

Why it fails: Pattern Designer's Search operates inside the pattern being edited, scanning step content for text or attributes; it does not enumerate MID servers. It is tempting because MID servers execute patterns, but their availability is checked through MID Server selection and capability settings, not this editor tool.

It searches for CIs in the CMDB.

Why it fails: Pattern Designer's Search locates strings, attributes or commands within a pattern's steps during development, not configuration items in the CMDB. It is tempting because CMDB lookup is a discovery outcome, but that querying is performed by discovery schedules and reports, not the pattern editor.

It searches for patterns in the store.

Why it fails: Search within Pattern Designer scans the current pattern's steps for strings or attributes; it does not browse the ServiceNow Store for downloadable patterns. It is tempting because patterns can be imported from the store, but that acquisition happens through the Store interface, not the pattern editor's search.

The MID Server is not validated

Why it fails: Validation confirms the MID Server's credentials and configuration are accepted by the instance; an unvalidated server cannot receive Discovery commands. It is tempting because validation is a genuine prerequisite, but a connected MID Server has already passed it, so validation status cannot explain the failure here.

The MID Server is too old

Why it fails: Discovery failures stem from configuration, credentials or connectivity, not the MID Server build's age; version mismatches surface as unsupported features rather than silent Discovery failure. Upgrading is genuinely required when the instance version exceeds the MID Server's supported range, which is a different symptom.

The proxy is down

Why it fails: A proxy outage would break the MID Server's outbound connection to the instance, yet the stem states it is connected. Proxies are genuinely relevant when the MID Server must reach the instance through a corporate gateway, so the distractor exploits that real dependency rather than the stated connectivity.

The user's password in the instance

Why it fails: Instance credentials govern MID Server authentication and would leave it Down only if login failed, but the running local service already proves the agent started. Credentials are the correct check when the MID Server reports authentication errors or fails to connect after configuration changes.

The MID Server's local disk space

Why it fails: Insufficient disk space can stall the MID Server process, yet the service is confirmed running, so local storage is not preventing startup. Disk capacity is the correct inspection point when the service repeatedly stops or logs write failures.

The number of Discovery Schedules

Why it fails: Discovery Schedules control when discovery runs, not whether the MID Server registers as Up. A running service with a Down status points to connectivity or configuration, not schedule count. Schedule volume matters when tuning discovery throughput or resolving overlapping runs.

The MID Server capabilities.

Why it fails: MID Server capabilities govern which discovery behaviours and credentials a MID Server can run, not the port list probed against targets. Capabilities are correctly configured when restricting or enabling discovery activities per MID Server, not for adding a scanned port.

The Discovery Schedule.

Why it fails: A Discovery Schedule controls when and which IP ranges or CI types are scanned, not the ports probed within each scan. Schedules are the correct record when changing scan timing or target scope, but port definitions live in the port probe records.

The Discovery Classifier.

Why it fails: Classifiers identify device type from probe results; they do not define which TCP or UDP ports Discovery probes. Classifiers are the right record when you need to categorise a newly discovered device by its fingerprint, not when extending port scanning coverage.

Scanning the entire network

Why it fails: The MID Server validates configuration, connects to the instance and registers itself, then begins scheduled jobs; full network scanning is performed later by Discovery probes, not at startup. Scanning is the correct activity once discovery schedules run against target IP ranges.

Creating new user accounts

Why it fails: The MID Server starts under its preconfigured service account and never provisions credentials; user accounts are created by administrators in the instance. Account creation belongs to user administration, which is the correct task when onboarding personnel who need platform access.

Validate

Why it fails: Validate is used to confirm the MID Server's configuration and connectivity during initial setup and marks the record as validated. It is not the mechanism used to trigger an immediate status re-evaluation of an already operational MID Server, so it does not satisfy the requirement to refresh health without waiting for the next heartbeat.

Test MID Server

Why it fails: Test MID Server validates that the MID Server can authenticate and communicate with the instance using its configured user and URL, which is valuable when initially setting up or troubleshooting credentials. It does not force a re-evaluation of the MID Server's current health status; it is a connectivity and authentication test rather than a heartbeat refresh.

Restart MID Server

Why it fails: Restart MID Server sends a command that causes the MID Server process to restart, which is useful for clearing stuck states or applying certain configuration changes. It is not a lightweight reachability check and does not simply refresh the health evaluation; it disrupts running work and is heavier than what the administrator needs in this scenario.

The Credential Alias list.

Why it fails: Credential aliases map discovery credentials to device categories; they govern authentication, not the classification rules that decide a device's type. It is tempting because credentials are essential for successful discovery, and a wrong alias would cause authentication failures, but classification itself is defined elsewhere.

The IP Range definitions.

Why it fails: IP ranges define which addresses discovery scans and their schedules; they control scope, not how a discovered device is classified into a type. It is tempting because an omitted range prevents discovery entirely, but the stem states the device is discovered yet misclassified, so ranges are not the issue.

The MID Server configuration.

Why it fails: MID Server configuration governs the execution host, connectivity and capabilities used to run probes; it does not hold the classification rules that assign device types. It is tempting because a misconfigured MID Server breaks discovery broadly, but here discovery succeeds and only classification fails.

admin

Why it fails: The 'admin' role is far too broad and should never be assigned to a MID Server user. It would grant full access to the instance, creating a severe security risk. The MID Server user only needs specific roles like 'mid_server' and 'discovery' to function. Using 'admin' violates least privilege and is not recommended.

discovery_admin

Why it fails: The 'discovery_admin' role is for human administrators who configure Discovery, not for the MID Server user. Assigning it to the MID Server user would grant excessive privileges, violating the principle of least privilege. The MID Server user only needs the 'mid_server' role and possibly 'discovery' if using Discovery, but not administrative roles.

itil

Why it fails: The 'itil' role is for ITIL users who work with incidents, changes, etc. It has no relevance to MID Server operations or Discovery. Assigning it would not help the MID Server process discovery tasks and could grant unnecessary access to ITIL processes. It is not required for MID Server functionality.

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.

proxy.xml

Why it fails: This is not a valid configuration file in the MID Server agent directory.

mid_server.properties

Why it fails: This is a system property record, not the local configuration file.

wrapper.conf

Why it fails: This file manages Java service parameters, not network proxy connectivity.

It increases the polling speed

Why it fails: Log level governs what the MID Server writes to its log files, not the frequency of discovery polling, which is scheduled separately. It is tempting because verbose logging can slow a MID Server, and increased polling speed would be correct if the property controlled scheduler intervals.

It enables automatic error reporting

Why it fails: The debug level only controls logging verbosity; it does not transmit error reports anywhere. It is tempting because debug output is often used when diagnosing faults, and automatic error reporting would be the correct answer if the setting governed telemetry or diagnostic upload behaviour.

It forces the MID Server to re-validate

Why it fails: Re-validation is triggered by configuration changes or manual action, not by log verbosity. The property only changes the detail recorded in logs. It is tempting because restarting or reconfiguring a MID Server often accompanies troubleshooting, and re-validation would be correct if the setting forced a config refresh.

Create a new CMDB class for all Service Mapping CIs.

Why it fails: Creating a new CMDB class fragments the model: Service Mapping populates existing CI classes such as Application Service and business service, and relationships rely on those established classes. The option is tempting because a fresh class appears to isolate migration risk, but new classes are warranted only for genuinely new CI types, not for mapping existing infrastructure.

Force all CIs to be re-discovered by the same MID server.

Why it fails: Forcing re-discovery by the same MID server discards existing relationship data and ignores the mapping transition's requirement to preserve and reconcile current CMDB relationships. Horizontal discovery already populated those relationships. The option is tempting because re-discovery feels like a clean start, but it is the correct approach only when building a CMDB from scratch, not when migrating.

Delete all existing relationships before starting.

Why it fails: Deleting existing relationships destroys the dependency data that Service Mapping must consume and reconcile, and horizontal discovery would need to rebuild everything. The option is tempting because a blank slate avoids conflicts, but deletion is the correct approach only when the existing CMDB data is confirmed corrupt or obsolete, not during a standard migration.

The MID Server is running on Windows

Why it fails: Encryption is credential-level, not OS-level, so the MID Server's Windows host is irrelevant; the failure stems from the credential record's encryption key or the MID Server's keystore. Windows hosting is tempting because MID Servers commonly run there, but that platform choice never governs encrypted credential decryption.

The MID Server is not in a cluster

Why it fails: Cluster membership governs MID Server load distribution and failover, not credential decryption, so a standalone MID Server can still use encrypted credentials successfully. It is tempting because clustering is a common MID Server topic, but it would be correct when MID Servers must share discovery workload across a pool.

The MID Server needs to be restarted

Why it fails: Restarting the MID Server does not resolve credential decryption failures, which stem from mismatched encryption keys or incorrect credential configuration. It is tempting as a generic first troubleshooting step, but it would be correct for applying configuration changes or clearing a stalled MID Server, not fixing credential errors.

The MID Server is in a cluster

Why it fails: Cluster membership is a supported configuration in which MID Servers still process jobs normally; clustering affects load distribution, not job execution. It is tempting because cluster misconfiguration can cause issues, but a correctly clustered MID Server remains fully functional, so this does not explain the symptom.

The MID Server is not validated

Why it fails: Validation is a prerequisite for a MID Server to start; an unvalidated server would not report 'Up' at all. It is tempting because validation failures do block job processing, but the 'Up' status already confirms validation succeeded, so the cause lies elsewhere.

The MID Server is missing the 'Discovery' capability

Why it fails: Capabilities determine which job types a MID Server can run; a server lacking Discovery would still process other assigned jobs, and Discovery is enabled by default. It is tempting because capability gaps do block specific probes, but the stem states no jobs at all are processed, indicating a broader cause.

Set the discovery to run at night.

Why it fails: Scheduling at night shifts when traffic occurs but does not reduce its volume, so bandwidth contention and device load remain unchanged during the scan window. It is tempting because off-peak scheduling is a valid practice for reducing business-hours disruption, but the requirement here is limiting traffic impact itself.

Disable the Shazzam phase.

Why it fails: Shazzam performs port scanning and classification; disabling it removes discovery's ability to identify running services and open ports, leaving incomplete CIs rather than reducing traffic. It is tempting because Shazzam is the most traffic-intensive phase, so disabling it appears to cut load, but it sacrifices discovery accuracy.

Limit the scan to one IP per hour.

Why it fails: Throttling to one IP per hour is not a supported Discovery control and would stretch a scan across an impractically long window without addressing per-phase traffic behaviour. It is tempting because rate limiting intuitively reduces load, but the correct practice is tuning MID Server concurrency and phase settings.

The CI Class is not in the Discovery Schedule.

Why it fails: If the class were missing, Discovery would fail to classify it entirely.

The 'Sync' flag is disabled in the Discovery Schedule.

Why it fails: There is no 'Sync' flag in a Discovery Schedule.

The Discovery Pattern is set to 'Create' mode.

Why it fails: Patterns do not have a 'Create' mode; they simply output data for the IRE.