Select Two (Multi-Select) Questions

Closing an incident task automatically closes the parent.

Why it fails: Closing a task updates only that task's state; the parent incident closes independently once all its tasks and resolution requirements are met. The reverse dependency is tempting because parent closure often requires completed tasks, but that is a gating condition on the parent, not an automatic cascade from child to parent.

They are automatically assigned to the same user as the parent.

Why it fails: Incident tasks are assigned manually or via assignment rules to the resolver group handling the work; they inherit nothing automatically from the parent incident's assigned user. Automatic inheritance is tempting because parent-child records often cascade fields, but that cascade applies to configuration items and relationships, not assignment.

They can only be created by admins.

Why it fails: Any user with the incident_task role, including fulfilers and delegated creators, can create incident tasks; admin rights are not required. Admin-only creation is tempting because admins configure task templates and assignment rules, but those govern structure, not who may raise a task against an incident.

Schedules are automatically generated by ITOM Discovery based on server reboots

Why it fails: cmn_schedule records are created manually by administrators or change managers; ITOM Discovery populates the CMDB with configuration items and relationships, not schedules. It is tempting because Discovery does gather server data, but it never generates maintenance or blackout schedules from reboots.

Schedules are strictly limited to single-day events and cannot span multiple days

Why it fails: cmn_schedule records support recurring patterns and can span multiple days, for example a weekend change window starting Friday and ending Monday. Single-day-only is tempting because many maintenance windows are short, but the schema imposes no such limit.

Accessing the core UI Incident list view

Why it fails: The core UI Incident list view is a fulfiller-facing interface showing all incidents, not the caller's own submissions, and typically requires roles the end user lacks. It is tempting because it displays incident status, and it would be correct for an agent or fulfiller managing the queue.

System Administrator impersonation

Why it fails: Impersonation requires elevated administrative privileges and is an auditing or troubleshooting technique, not a method available to a caller checking their own incident. It is tempting because it reveals another user's records, and it would be correct for an administrator reproducing a reported issue.

Direct database query via ODBC client

Why it fails: Direct ODBC database queries bypass the application's access controls and are not an end-user-facing status mechanism. It is tempting because it retrieves the underlying record directly, and it would be correct for a database administrator performing backend troubleshooting rather than a caller checking their incident.

Automatic execution of incident management triage workflows for failed discoveries.

Why it fails: CI Class Manager governs class definitions, hierarchies and attributes; it does not execute incident triage workflows, which belong to Flow Designer or Incident Management. It is tempting because failed discoveries do generate alerts, but remediation is handled elsewhere, not by class configuration.

Direct editing of system-level Java source code for Discovery patterns.

Why it fails: CI Class Manager is a configuration interface for class hierarchies and attributes, not a code editor; pattern logic is changed in Discovery pattern scripts. It is tempting because class changes affect pattern output, but direct Java editing happens in the pattern designer, not here.

Automatically generating a separate incident record for each row submitted

Why it fails: Multi-Row Variable Sets store multiple rows of variable data within a single catalog item submission; they do not spawn separate incident records per row. It is tempting because each row resembles an individual request, and generating records per row is correct when using a workflow that explicitly creates them, not an MRVS capability.

Storing data directly in permanent custom table columns during initial cart checkout

Why it fails: MRVS rows are stored as JSON within the catalog item's variable data, not written to custom table columns at cart checkout; that mapping occurs later via a record producer or flow. It tempts because MRVS looks like a table, but permanent column storage requires explicit post-submission processing.

Replacing standard workflows with spreadsheet imports

Why it fails: MRVS collects structured rows within a single catalog item's variables; it cannot replace workflow orchestration or ingest external spreadsheets. It is tempting because MRVS output resembles tabular data, but spreadsheet import is a separate integration task, and workflows remain defined in Flow Designer or Workflow Editor.

They prevent users from accessing the Service Portal

Why it fails: Record Producers are catalogue items that render on the Service Portal to create records, so they enable access rather than prevent it. It is tempting because producers can be gated by user criteria or roles, but that restricts who may submit, not whether users can reach the portal itself.

They are restricted to creating records only in the sc_req_item table

Why it fails: Record Producers can target any table, including custom tables and task-extended tables such as incident or sc_task, so restricting them to sc_req_item is false. It is tempting because the catalogue-item pattern commonly writes to sc_req_item, but that is one configuration, not a platform restriction.

They require an Order Guide to function

Why it fails: Record Producers create records directly from a table form and need no Order Guide; that dependency applies only when a catalogue item must bundle several products through sequenced questions. Requiring one would block the simple single-record submission the Producer is designed for.

The change requester's location

Why it fails: Requester location carries no bearing on whether two changes touch the same configuration items or overlap in time. It is tempting because location can drive approval routing in some workflows, which is a valid concern for assignment rules, not conflict detection.

The change priority level

Why it fails: Priority ranks urgency for approval routing; the conflict engine compares overlapping configuration items and scheduled maintenance windows, not severity. It is tempting because priority feels central to change management, and it would matter for CAB sequencing decisions rather than detecting collisions.

Due date

Why it fails: Due date marks when the change must be finished, giving a single deadline rather than a start and end pair, so it cannot define an execution window. It is tempting because it is a date field on the change record, but it would be correct for tracking completion deadlines, not scheduling the window itself.

Sys created on

Why it fails: Sys created on records when the change record was inserted, not when work is scheduled to run, so it cannot bound the execution window. It is tempting because it is a date field on the change form, but it would be the right choice only for auditing or reporting on record creation timing.

Closed date

Why it fails: Closed date records when a change was completed, not when it may execute, so it cannot define an execution window. It tempts as a change-record date field, but the planned start and end dates bound the permitted execution period; closure occurs after the work finishes.

A dedicated CI for the CAB

Why it fails: CAB Workbench needs the CAB record and membership setup, not a dedicated configuration item representing the board. It is tempting because CIs model infrastructure and services in the CMDB, and creating a CI would be the correct choice when you need to track an asset's relationships and lifecycle.

An assigned ITIL manager

Why it fails: CAB Workbench requires the change management enablement and CAB membership configuration, not an assigned ITIL manager. It is tempting because ITIL roles underpin change governance, and assigning a manager would be the correct step when establishing ownership and accountability for change processes.

An active workflow for every change

Why it fails: CAB Workbench functions through CAB membership and change schedule configuration, not an active workflow per change. It is tempting because workflows automate approvals and states, and an active workflow would be the correct choice when you need to enforce a defined approval path for a specific change type.

User password complexity and security compliance

Why it fails: Conflict Detection compares change schedules and configuration item relationships — overlapping maintenance windows and shared CIs — not credential or compliance attributes. Password complexity belongs to authentication and security policy controls, which are evaluated elsewhere, not by the change conflict engine.

Service Catalog item fulfillment costs

Why it fails: Conflict Detection examines scheduling overlaps and CI relationships between change requests, not financial data. Fulfilment costs belong to Service Catalog pricing and demand management reporting, which are evaluated when costing catalogue items, not when detecting change conflicts.

CMDB hardware depreciation schedules

Why it fails: Depreciation schedules track asset value over time and play no part in conflict detection, which compares change windows and CI relationships. It is tempting because CMDB data feeds the engine, but only schedule and CI overlap fields matter; depreciation belongs to financial asset reporting instead.

An automated email is broadcast to all company employees

Why it fails: Conflict detection triggers notifications to the affected change stakeholders and reschedules or reassigns the change, not a company-wide broadcast. Mass emailing is tempting because conflict alerts are notifications, and would be correct only if the stem described a general announcement rather than a targeted change-management conflict workflow.

The configuration item is automatically retired from service

Why it fails: A scheduling conflict blocks or reschedules the change; it never retires the affected configuration item, which is a separate lifecycle action. Retirement is tempting because conflicts can prompt review of affected CIs, and would be correct if the stem asked about decommissioning assets rather than resolving overlapping change windows.

The change request is automatically deleted from the database

Why it fails: Conflict detection flags the change for review or rescheduling; it does not delete the change request record, which must remain auditable. Deletion is tempting because conflicts can cause a change to be cancelled, and would be correct only if the stem described rejecting a request outright rather than detecting a scheduling clash.

Convert the change into a standard change template

Why it fails: Converting an emergency change into a standard change template misclassifies it; emergency changes follow the emergency path with retrospective CAB review, not pre-approved standard templates. It tempts because standard templates speed up recurring low-risk changes, which is the right choice only for pre-authorised routine work.

Disable all auditing and logging on the instance

Why it fails: Disabling auditing and logging removes the evidence trail that emergency change records must retain for post-implementation review and compliance. It tempts as a way to reduce overhead during urgent production fixes, but emergency changes still require documentation, so audit data must remain enabled throughout.

Wait for the next monthly CAB meeting scheduled three weeks away

Why it fails: Waiting three weeks for the monthly CAB contradicts the emergency change process, which authorises urgent production fixes immediately with retrospective review. It tempts because CAB approval is the normal governance route, and deferring is correct for routine changes where no urgent production impact exists.

They require mandatory manual risk assessment questionnaires for every execution

Why it fails: Standard Changes are pre-approved precisely so they bypass per-execution risk assessment; requiring a manual questionnaire each time defeats that purpose. It is tempting because risk assessment is central to change management generally, but it applies to normal changes, whereas standard changes rely on the template's prior authorisation.

They automatically trigger emergency incident swarming

Why it fails: Standard Changes execute through their pre-approved template without invoking incident swarming, which is an incident-management response for major outages. It is tempting because automation and swarming both reduce resolution time, but swarming is triggered by incidents, not by routine pre-authorised change execution.

They are designed for major, high-risk infrastructure overhauls

Why it fails: Standard Changes are pre-approved, low-risk, repeatable tasks with a defined template; major high-risk overhauls follow the normal or emergency change model instead. It is tempting because standardisation implies governance, but the defining criterion is low risk and pre-authorisation, not scale or infrastructure impact.

Automatically compile Java source code

Why it fails: Catalog UI policies do not compile code.

Delete user profile records

Why it fails: UI policies do not delete user records.

Create new database tables

Why it fails: UI policies do not create tables.

System Logs.

Why it fails: System Logs are diagnostic records viewed through platform logging tools, not a component surfaced within the Major Incident Workbench itself. It is tempting because logs are central to incident investigation, and would be the right answer if the question asked where engineers diagnose major incident root cause.

SLA Definition editor.

Why it fails: The SLA Definition editor configures service level agreements in the SLA module, not content displayed inside the Major Incident Workbench. It is tempting because SLAs govern major incident response targets, and would be correct if the question asked where SLA terms are created or maintained.

Conflicts where the change request submitter lacks the required approval delegation limits.

Why it fails: Approval delegation limits are governed by user and group approval configuration, not by the conflict engine, which compares schedule, CI and blackout data. It is tempting because approval shortfalls do block changes, but that is enforced at approval time, whereas conflict detection reports overlapping windows and related CI or blackout clashes.

Conflicts where the estimated cost of the change exceeds the assigned cost center budget threshold.

Why it fails: Budget thresholds belong to cost management and financial tracking, not to the conflict engine, which evaluates scheduling and configuration item relationships. It is tempting because cost overruns do stall changes, but that check happens through budget workflows, while conflict detection reports schedule overlaps, blackout violations and CI conflicts.

Service Catalog workflow versioning rules

Why it fails: Service Catalog workflow versioning governs request fulfilment approval, not CI relationship traversal, so it cannot influence conflict detection. It is tempting because both are ServiceNow configuration areas, and would be correct when controlling which catalogue item versions remain orderable.

Incident management priority lookup tables

Why it fails: Conflict detection traverses CI relationships using the CI class relationship rules, the CI relationship type definitions, and the identification/reconciliation engine's traversal configuration — not incident priority lookups. Priority lookup tables map impact and urgency values to incident priority, which is useful for incident SLA routing but has no bearing on how relationship records are walked during conflict detection.

Random guessing by junior service desk agents

Why it fails: Random guessing by agents is a manual, human decision that bypasses assignment rules entirely, so records are not routed automatically. It is tempting because it superficially resembles load spreading, but automated assignment requires configurable rules matching record attributes such as category or CI to a group. Guessing would only fit a question about manual triage.

Manually rolling dice in the server room

Why it fails: Dice cannot read record attributes or invoke assignment rules, so no automated routing occurs. It is tempting because random allocation superficially resembles round-robin distribution, but round-robin is a configured assignment rule evaluated against group capacity. Dice would only be relevant to a question about manual, non-system workload allocation.

Whether the user submitting the change has the security_admin role

Why it fails: Conflict detection evaluates schedule overlap and CI relationships regardless of the submitter's roles; security_admin governs access to restricted tables and UI actions, not change conflict logic. Investigators should instead check change windows, CI relationships, and whether conflict checking is enabled.

Whether the target CI classes are excluded from incident management

Why it fails: Conflict detection compares change schedules against CI relationships and maintenance windows, not incident management exclusions. CI class exclusions can suppress conflict checks, but the incident module plays no part, making this a plausible-sounding but irrelevant area to investigate.

Service Catalog variable sets

Why it fails: Variable sets group catalogue questions and UI policies; they hold no change approval logic or authorisation conditions. It is tempting because they are reusable configuration records, and would be correct when standardising request form fields rather than determining which approvals a change requires.

Hardware asset reconciliation rules

Why it fails: Hardware asset reconciliation rules match discovered CIs against asset records; they do not evaluate change criteria or approvers. It is tempting because reconciliation underpins CMDB accuracy, and would be correct when governing asset data integrity rather than defining who must authorise a change.