Hard Difficulty Questions

Requiring the user to manually email the data governance team

Why it fails: Manual emailing leaves remediation tasks open, since closure requires the task to detect that the underlying CI data now satisfies the policy. It is tempting as a low-effort notification route, and would be correct only for alerting the governance team, not for automatically closing tasks.

Deleting the remediation task manually from the task list

Why it fails: Manual deletion cannot be automated, so tasks persist after the user corrects the support group, defeating the policy's closure requirement. It is tempting because the task list is where remediation tasks are visible and actionable, and manual closure suits one-off cleanups where no recurring policy validation exists.

Writing a custom business rule on the incident table

Why it fails: Business rules on the incident table never fire for CMDB remediation tasks, which are stored in their own task table, so corrections cannot trigger closure. It is tempting because business rules are the standard automation mechanism, and would be correct for automating incident record behaviour.

CI Class Manager relationship rule definitions

Why it fails: Relationship rules manage parent-child connectivity, not aging thresholds.

Discovery Schedule properties

Why it fails: Discovery schedules govern scan frequency, not CMDB health aging rules.

Data Archiving rule definitions

Why it fails: Data archiving moves old records to archive tables, which is distinct from CMDB Health correctness metrics.

Automatic MID Server selection rule

Why it fails: MID servers are used for Discovery, not Data Certification campaigns.

CI Class Manager relationship definition tab

Why it fails: CI Class Manager defines class hierarchy, attributes and identification, not which relationship types Dependency Views renders by default. The default relationship filter set lives in the Dependency Views properties. Class Manager would be right for editing a class's relationship definitions, not for scoping the map's rendered edges.

Service Mapping Properties table

Why it fails: Service Mapping Properties govern mapping discovery behaviour and credentials, not the Dependency Views relationship filter defaults. Those defaults are held in the Dependency Views property for included relationship types. Service Mapping properties would be correct when tuning discovery schedules or mapping rules for service instances.

CMDB Query Builder global settings

Why it fails: CMDB Query Builder global settings control query execution options and saved query behaviour, not which relationship types Dependency Views draws. The rendered relationship defaults sit in the Dependency Views properties. Query Builder settings would be correct when adjusting how queries aggregate or export CI data.

CMDB Query Builder execution logs

Why it fails: Query Builder execution logs capture who ran which CMDB query and when, not the relationship records those queries returned or any modification made to them. It is tempting because it is an audit-style log, and would be correct when tracing who accessed CMDB data.

Service Mapping traffic log table

Why it fails: Service Mapping traffic logs record observed connection data used to infer application dependencies; they do not capture manual relationship edits or their authors. It would be the right source when validating discovered application service topology against actual network traffic.

Reconciliation Definition audit table

Why it fails: Reconciliation Definition audit records capture reconciliation outcomes, not manual relationship edits, so it cannot evidence who altered production relationships. It is tempting because reconciliation governs CI data integrity, and it would be the right place to trace why an attribute was overwritten during a scheduled reconciliation run.

Merge the on-premises database and AWS RDS instance into a single physical CI record.

Why it fails: Merging distinct CIs destroys the individual identity and relationship data CSDM requires; each database must remain a separate CI linked to the Application Service. It tempts because consolidation reduces record count, but CSDM models hybrid dependencies as discrete CIs connected through relationships, not as one combined physical record.

Link only the primary database to the Application Service and nest the secondary database inside the Business Application.

Why it fails: Nesting the secondary database under the Business Application breaks the dependency chain the Application Service needs for impact analysis. It tempts because prioritising a primary database seems tidy, but CSDM requires every supporting database CI to relate directly to the Application Service so hybrid dependencies remain visible.

Create a separate Business Application for each database and link them together.

Why it fails: Databases are infrastructure CIs, not Business Applications, so creating Business Applications for them misclassifies the layer and severs the Application Service dependency mapping. It tempts because grouping related items feels organised, but CSDM links each database CI to the Application Service through relationships, not via peer Business Applications.

Manual approval workflows for every inbound payload

Why it fails: Manual approval workflows gate each inbound payload on human review, which cannot serialise concurrent writes from multiple discovery tools and stalls ingestion at scale. It is tempting because approvals provide governance over changes, and would suit low-volume, high-risk updates needing sign-off rather than race-condition prevention.

Asynchronous business rules triggered on insert to pause payloads

Why it fails: Asynchronous business rules run after the insert commits, so they cannot pause or serialise the competing writes that cause the race condition. It is tempting because asynchronous rules offload processing from the transaction, and would suit non-blocking notifications or downstream updates rather than locking CIs during ingestion.

Database locks enforced via Table Administration settings

Why it fails: Table Administration settings govern table-level attributes such as auditing, extensibility and display values, not row-level locking during concurrent CI writes. It is tempting because it sounds like database-level control, and would be relevant when configuring table behaviour or schema options rather than preventing simultaneous updates.

RTE automatically translates foreign languages in source data payloads.

Why it fails: RTE performs no language translation; it handles large-volume, multi-source CMDB payloads through parallelised, pre-target processing. Translation is not a transform capability at all. The option tempts because RTE does manipulate source field values, but only for coalescing and mapping, not linguistic conversion.

RTE eliminates the need for staging tables during data imports.

Why it fails: RTE still relies on staging tables to hold source data before transformation; it changes how that data is processed, not whether staging occurs. The option tempts because RTE reduces staging bottlenecks through parallel jobs, which can be misread as eliminating staging entirely. The real benefit is throughput at scale.

RTE bypasses all access control lists to accelerate import times.

Why it fails: RTE runs under the importing user's permissions and does not bypass ACLs; it accelerates processing through parallel execution and pre-target staging. The option tempts because RTE does reduce per-record overhead, which can be mistaken for privilege escalation. Access control remains enforced throughout the import.

Data Policy Enforcement Engine

Why it fails: Data Policy Enforcement applies mandatory, read-only and default rules to records, but it does not detect or block duplicate CI insertion. Duplicate prevention is handled by the IRE's duplicate detection via identification and reconciliation rules, which Data Policies do not perform.

CMDB Health Duplicate Engine

Why it fails: CMDB Health Duplicate Engine only detects and reports duplicates for health dashboards; it does not block inserts from API integrations or imports. It is tempting because it targets duplicates, but it is a monitoring and scoring tool, not an enforcement mechanism at the point of record creation.

Transform Map Unique Key matching

Why it fails: Transform Map Unique Key matching only applies to imports running through that specific transform map, so API inserts and manual entries bypass it entirely. It is tempting because it prevents duplicates during import, but it cannot enforce governance across all insertion paths into cmdb_ci.

CMDB Data Manager policy conditions

Why it fails: CMDB Data Manager policies govern certification, attestation and lifecycle tasks on configuration items, not visual overlays. Custom indicators and map decorators belong to Dependency Views widget configuration, which is tempting because both features reference the CMDB and CI conditions.

Service Mapping pattern extension script

Why it fails: Service Mapping pattern extension scripts populate the CMDB by discovering CIs and their relationships; they do not render Dependency Views badges. The warning badge depends on widget indicators and map decorators, configured in the Dependency Views configuration. Pattern extensions would be the right choice when you need to discover new CI types or attributes that existing patterns miss.

CI Class Manager identifier rules

Why it fails: CI Class Manager identifier rules define uniqueness criteria for CI records during identification and reconciliation, so they cannot render badges or decorators on Dependency Views maps. They are tempting because they govern CI class attributes, and would be correct when configuring which fields uniquely identify a CI, not for visual indicators driven by metric thresholds.

Deploy

Why it fails: CSDM's recognised lifecycle phases are Crawl, Walk, Run and Fly; Deploy is not one of them. Deploy is tempting because it is a common ITSM or DevOps stage name, but CSDM maturity describes data-model adoption progression, not release or deployment activity.

Sprint

Why it fails: Sprint is an agile delivery cadence, not a CSDM maturity phase; the recognised phases are Crawl, Walk, Run and Fly. It is tempting because maturity work is often delivered iteratively in sprints, but the framework names data-model adoption stages, not project ceremonies.

Check the 'No-Delete' flag on the Discovery Schedule record.

Why it fails: The No-Delete flag only prevents record deletion, not attribute overwrites, so it cannot stop the nightly run replacing the Asset tag. It is tempting because it sounds like a protective control, and it would be correct when Discovery must be blocked from removing CIs entirely.

Disable the 'Asset tag' field mapping in the IRE payload processor script.

Why it fails: The IRE payload processor handles reconciliation and merging of incoming payloads, not the field-level precedence that decides whether a manually edited attribute survives. Disabling a mapping there would be right when a specific source attribute should never populate a field at all.

Set the cmdb_ci table to read-only for the Discovery integration user via ACLs.

Why it fails: Read-only ACLs block all writes from the integration user, including legitimate CI updates, rather than resolving the attribute precedence conflict. This would be correct when a service account must be prevented from modifying any records, such as a strictly read-only audit integration.

Discovery Schedules > CMDB Health

Why it fails: Discovery Schedules govern discovery runs, not CMDB Health metric calculation jobs. CMDB Health schedules are configured in the CMDB Health properties, where the scheduled job records can be adjusted. It tempts because both involve scheduled jobs, but discovery scheduling is unrelated to health metric execution.

CMDB Health Dashboard > Schedule Settings

Why it fails: The CMDB Health Dashboard displays results; it holds no schedule settings. Calculation schedules are defined in the CMDB Health properties and their associated scheduled jobs. It tempts because dashboards surface health data, but scheduling is controlled through the underlying job records, not the dashboard interface.

Data Governance > Job Execution

Why it fails: Data Governance > Job Execution monitors job runs and logs; it does not define schedules. CMDB Health calculation schedules are set in the CMDB Health properties and their scheduled job records. It tempts because job execution shows timing data, but editing the schedule requires the job record itself.

Convert the record into a Technical Service Offering.

Why it fails: Converting to a Technical Service Offering misclassifies the record along the wrong CMDB class hierarchy: a Technical Service Offering describes technical capability, not the application service consumed by business services. It is tempting because both sit under service-related tables, but the corrective action is recreating the record on the Application Service table.

Leave the record as-is, because Business Application and Application Service tables are interchangeable in newer ServiceNow releases.

Why it fails: Business Application and Application Service remain distinct CMDB classes with separate tables and relationships; they are not interchangeable, so leaving the record breaks the intended service model and reporting. It is tempting when the two names appear similar, but the correct fix is recreating the record on the Application Service table.

Change the table attribute in Dictionary Overrides so that Business Applications act as Application Services.

Why it fails: Dictionary Overrides cannot reassign a record's table or class; they only alter field attributes such as labels, defaults and mandatory flags for a table. It is tempting because overrides do change table behaviour, but the record still resides on Business Application, so it must be recreated on the Application Service table.

Hardware assets will automatically be marked as deprecated

Why it fails: Deprecating hardware assets is triggered by lifecycle and asset state, not by a missing application-service-to-technical-service relationship, so this gap cannot cause it. It is tempting because deprecation is a governance action, and it would be correct when asset lifecycle policy marks end-of-life hardware.

Database replication lag will increase across MID servers

Why it fails: Replication lag is a MID server and database transport concern, unaffected by how application services map to technical services in CSDM. It is tempting because MID server health is a genuine governance concern, and it would be the right focus when diagnosing discovery or integration throughput problems.

Discovery will fail to run network scans on IP subnets

Why it fails: Discovery scans IP subnets independently of service-model relationships, so a missing application-to-technical-service mapping cannot halt network scanning. The tempting pull is that discovery populates the CMDB and CI relationships, making it feel foundational to CSDM. Discovery would be the right focus if the gap were unpopulated CIs, not an unlinked service structure.

Discovery Log analyzer widget

Why it fails: The Discovery Log analyzer widget aggregates discovery run status, errors and timing; it does not expose the raw payload or intermediate pattern variables. It is tempting because it is the standard first stop for failed discoveries, and would be correct for identifying which discovery run failed and at which phase.

CMDB Query Builder execution trace

Why it fails: CMDB Query Builder builds and runs reports against CMDB tables; it does not capture pattern execution state, so it cannot expose the raw payload or intermediate variables. It is tempting because it queries CMDB data, and would be the right choice for validating which CIs and relationships a completed pattern actually wrote.

Dependency Views inspector console

Why it fails: Dependency Views inspector console visualises CI relationships on a service map, not pattern execution internals, so it cannot expose raw payloads or intermediate variables. It is tempting because it is the natural tool for validating discovered dependencies and troubleshooting map topology after discovery, which is a different diagnostic task from debugging pattern logic.

The Discovery schedule is currently paused by an administrator.

Why it fails: A paused Discovery schedule affects discovery, not Service Mapping's map status. 'Partial' specifically means the entry point was mapped but some connections or CI attributes could not be fully resolved, so it is tempting because both conditions leave a service incompletely represented.

The underlying infrastructure has not been updated within the last 90 days.

Why it fails: Stale infrastructure age is surfaced through CMDB Health dashboards, not the Service Mapping map status. 'Partial' indicates the entry point was discovered but some downstream connections or attributes remain unresolved, so it is tempting because both signal incomplete service data.

The business service record lacks mandatory CSDM technical service offerings.

Why it fails: A 'Partial' map status reflects discovered CIs whose connections to the entry point remain unresolved, not CSDM record completeness. It is tempting because missing mandatory technical service offerings genuinely blocks service mapping certification, but that surfaces as CSDM compliance errors on the service record, not as a Partial insight indicator.

Business Rules on the cmdb_ci table

Why it fails: Using custom Business Rules is an anti-pattern; native CI relationship rules should be used.

Data Dictionary [sys_dictionary] attribute settings

Why it fails: sys_dictionary handles database level cascades for reference fields, not CMDB relationship rules.

IRE payload processor scripts

Why it fails: IRE processes incoming payloads for insert and update actions, it does not manage structural relationship cascade deletion rules.

The cmdb_rel_ci table is missing indexes.

Why it fails: Table indexing impacts query performance, not record matching logic.

The CMDB Health Dashboard needs to be restarted.

Why it fails: The Health Dashboard is a read-only reporting and scoring interface; restarting it merely reloads its calculations and cannot alter how the Identification and Reconciliation Engine matches attributes at insert. It is tempting when dashboard scores look stale, and a restart would be correct to refresh displayed health metrics.

Inside the CI Class Manager under Governance settings

Why it fails: CI Class Manager defines class hierarchy, identification and reconciliation rules, not certification filter criteria. The filter determining which CIs enter a certification schedule is set on the Data Certification schedule record itself. Class Manager tempts because it governs CI classes broadly, but it holds no certification scheduling fields.

On the CMDB Health Dashboard compliance settings tab

Why it fails: The CMDB Health Dashboard displays compliance, completeness and correctness KPIs; its settings tab configures health score thresholds and weights, not certification scope. Certification filters live on the Data Certification schedule. The dashboard tempts because both concern CI data quality, yet health scoring and certification scheduling are separate mechanisms.

In the CMDB Data Manager policy definition

Why it fails: CMDB Data Manager policies automate CI lifecycle tasks such as retirement, archival and deletion, driven by policy conditions on CI records. Certification filter criteria are defined on the Data Certification schedule instead. Data Manager tempts because it also targets CI subsets, but it executes lifecycle actions rather than review assignments.