ServiceNow Certified Implementation Specialist - IT Service Management (CIS-ITSM) (CIS-ITSM) CIS-ITSM Questions 301–372 | Page 5/5

301

MCQmedium

What must be defined in the CAB Definition to ensure the right people are invited to the CAB meeting?

A.Approval Rules

B.Assignment Groups

C.CAB Members

D.User Criteria

E.Change Groups

AnswerC

Defining CAB Members populates the roster from which attendees are drawn, so only the appropriate stakeholders receive meeting invitations. Without this list, the CAB Definition cannot determine who should attend, directly satisfying the stem's requirement to invite the right people.

Why this answer

In the CAB Definition, the CAB Members field specifies the users or groups who are invited to the CAB meeting. This ensures that the right stakeholders are included in the change advisory board discussions. Without defining CAB Members, the meeting invitations would not be sent to the appropriate individuals.

Exam trap

CIS-ITSM often tests the distinction between CAB Members and Approval Rules, where candidates might confuse who attends the CAB with who approves changes.

How to eliminate wrong answers

Option A is wrong because Approval Rules define who must approve changes, not who attends CAB meetings. Option B is wrong because Assignment Groups are used for assigning tasks, not for CAB invitations. Option D is wrong because User Criteria are used for filtering in other contexts, not for CAB membership.

Option E is wrong because Change Groups are used to group changes for reporting, not for CAB invitations.

Full explanation →

302

MCQeasy

Which form component is used to quickly search the Knowledge Base based on incident short description?

A.Incident History

B.Catalog

C.Service Portal

D.Knowledge Sidebar

AnswerD

The Knowledge Sidebar searches the Knowledge Base using the incident's short description as the query, surfacing relevant articles directly on the incident form. This satisfies the stem's requirement of quickly finding knowledge based on the short description without leaving the record.

Why this answer

The Knowledge Sidebar is a contextual component embedded in incident records that automatically searches the Knowledge Base using the incident's short description. It surfaces relevant articles in real time, allowing agents to resolve issues faster without manually navigating to the Knowledge Base. This is a core feature of ServiceNow ITSM designed to integrate knowledge directly into the incident management workflow.

Exam trap

CIS-ITSM often tests the distinction between agent-facing form components (like Knowledge Sidebar) and user-facing portals (like Service Portal), causing candidates to confuse where knowledge search is integrated.

How to eliminate wrong answers

Option A is wrong because Incident History displays past activity and audit trails for the current incident, not knowledge articles. Option B is wrong because Catalog refers to the Service Catalog, which lists available services and items for request fulfillment, not knowledge search. Option C is wrong because Service Portal is an end-user self-service interface, not a form component within the incident form for agents.

Full explanation →

303

MCQeasy

An incident has been inactive in the 'Resolved' state for a specific number of days defined by system properties. Which out-of-the-box scheduled job automatically moves it to 'Closed'?

A.Incident Escalation Job

B.Data Archival Job

C.Autoclosed Incidents

D.SLA Generation Job

AnswerC

The Autoclosed Incidents scheduled job scans incidents left inactive in Resolved beyond the configured inactivity duration and transitions them to Closed. The stem's constraint is a system-property-defined number of days, which this job reads directly.

Why this answer

The 'Autoclosed Incidents' scheduled job in ServiceNow automatically transitions incidents that have been in the Resolved state beyond the configured number of days (defined by system properties like glide.incident.autoclose.delay) to the Closed state. It is the out-of-the-box job responsible for this lifecycle transition.

Exam trap

CIS-ITSM often tests whether candidates confuse the Autoclosed Incidents job (Resolved to Closed) with escalation, SLA, or archival jobs — the key is recognizing that only the autoclose job performs the state transition after the configured delay.

How to eliminate wrong answers

Option A is wrong because the Incident Escalation Job handles SLA-based escalations and priority changes, not resolution-to-closure transitions. Option B is wrong because the Data Archival Job archives old records for storage management; it does not change incident states. Option D is wrong because the SLA Generation Job creates and updates SLA task records, not incident state transitions.

Full explanation →

304

MCQmedium

When configuring CAB meeting definitions, how can an administrator ensure that only High-risk changes are automatically pulled into the meeting agenda?

A.By modifying the Risk Assessment questionnaire

B.By setting a system property for global CAB filters

C.By writing an inbound email action

D.By defining filter conditions on the CAB definition record

AnswerD

Filter conditions on the CAB definition record drive the agenda query, so only changes matching the High-risk criterion are pulled in automatically. This satisfies the stem's requirement for automatic inclusion without manual triage, since the filter is evaluated each time the meeting agenda is generated.

Why this answer

CAB definitions in ServiceNow contain a filter condition field that determines which change records are automatically added to that CAB's meeting agenda. By defining filter conditions (e.g., Risk = High) on the CAB definition record, only changes matching those criteria are pulled into the agenda. This is the native, supported mechanism for scoping CAB meetings to specific change populations.

Exam trap

CIS-ITSM often tests the misconception that risk assessment configuration controls CAB membership, when in fact CAB agenda population is driven by filter conditions on the CAB definition record.

How to eliminate wrong answers

Option A is wrong because the Risk Assessment questionnaire only determines how risk is calculated for a change — it does not control which changes appear on a CAB agenda. Option B is wrong because there is no global system property that filters CAB agenda contents; CAB scoping is per-definition, not global. Option C is wrong because an inbound email action processes incoming email to create/update records and has no role in populating CAB meeting agendas.

Full explanation →

305

MCQeasy

Which field on a Change Request indicates whether the change was successful, successful with issues, or unsuccessful during the Post Implementation Review?

A.Category

B.Risk value

C.Close code

D.Conflict status

AnswerC

The close code records the Post Implementation Review outcome, distinguishing successful, successful with issues, and unsuccessful. It is the field that captures the review verdict, satisfying the stem's requirement for indicating change success after implementation.

Why this answer

The Close code field on a Change Request indicates the outcome of the change during Post Implementation Review, with values such as 'successful', 'successful with issues', or 'unsuccessful'. This field is specifically designed to capture the final result of the change after implementation.

Exam trap

CIS-ITSM often tests whether candidates confuse fields that describe the change (Category, Risk) with fields that record the outcome (Close code), leading them to pick a pre-implementation field for a post-implementation result.

How to eliminate wrong answers

Option A is wrong because Category classifies the type of change (e.g., hardware, software, network) and does not indicate success or failure. Option B is wrong because Risk value assesses the potential risk before implementation, not the outcome. Option D is wrong because Conflict status indicates whether the change conflicts with other changes or maintenance windows, not whether it was successful.

Full explanation →

306

MCQhard

When designing a Record Producer that maps user input to the Incident table, an administrator notices that the 'Caller' field on Incident is not populating correctly even though the variable is mapped to 'caller_id'. What is the most likely reason?

A.The variable name must exactly match 'sys_id' to populate reference fields.

B.The variable type is set to Single Line Text instead of Reference pointing to the sys_user table.

C.Record producers cannot map fields to the Incident table due to security restrictions.

D.The Incident table requires an active Business Rule to accept record producer inputs.

AnswerB

A Single Line Text variable stores a string, so the mapped caller_id value cannot resolve to a sys_user reference, leaving Caller empty. Setting the variable type to Reference against sys_user satisfies the stem's requirement for correct caller population.

Why this answer

For a Record Producer to correctly populate a reference field like Caller on the Incident table, the variable mapped to that field must be of type Reference and point to the sys_user table. A Single Line Text variable, even if named 'caller_id', will store a string value that cannot be resolved to a valid user sys_id, resulting in an empty or incorrect Caller field. The mapping process relies on the variable's type to determine how to transfer data to the target field.

Exam trap

CIS-ITSM often tests the misconception that variable names alone determine mapping success, when in fact the variable type must match the target field type, especially for reference fields.

How to eliminate wrong answers

Option A is wrong because the variable name does not need to match 'sys_id'; the mapping is defined by the variable's name matching the field name (e.g., 'caller_id') and the variable type must be Reference. Option C is wrong because Record Producers are fully capable of mapping to the Incident table; security restrictions are managed via ACLs, not an inherent limitation. Option D is wrong because no active Business Rule is required for Record Producer inputs; the mapping is handled by the platform's built-in record creation process.

Full explanation →

307

MCQeasy

Which application menu in ServiceNow provides access to the CAB Workbench?

A.Incident > CAB Workbench

B.System Definition > CAB Workbench

C.Problem > CAB Workbench

D.Change > CAB Workbench

AnswerD

The CAB Workbench is accessed through the Change application menu, which groups change management tooling including the CAB Workbench module. This satisfies the stem's requirement for the application menu providing access, as the Workbench sits under Change rather than Incident, Problem or Service Catalog.

Why this answer

The CAB Workbench is a feature within the Change Management application in ServiceNow. It provides a centralized interface for managing Change Advisory Board (CAB) meetings, including agendas, approvals, and meeting minutes. To access it, users navigate to the Change application menu, where the CAB Workbench module is listed.

Therefore, 'Change > CAB Workbench' is the correct path.

Exam trap

CIS-ITSM often tests the exact navigation path for ServiceNow features, and candidates may confuse the CAB Workbench with other change-related modules or assume it resides under a different application like Incident or Problem.

How to eliminate wrong answers

Option A is wrong because the Incident application menu does not contain the CAB Workbench; it focuses on incident resolution and does not include change advisory board tools. Option B is wrong because System Definition is used for configuring tables, fields, and other system components, not for accessing operational applications like CAB Workbench. Option C is wrong because the Problem application menu deals with root cause analysis and known errors, not with CAB meeting management.

Full explanation →

308

MCQmedium

An administrator wants to add a custom field called 'Root Cause Category' to the Problem table. What is the recommended best practice for naming the column name in ServiceNow?

A.It must match an existing incident table column exactly

B.It must contain uppercase spaces for readability

C.It must start with 'sys_' to ensure system privileges

D.The system automatically prefixes custom fields with 'u_' (e.g., u_root_cause_category)

AnswerD

ServiceNow automatically applies the 'u_' prefix to any custom field created on a table, ensuring it never collides with reserved out-of-box column names during upgrades. This satisfies the stem's best-practice requirement: administrators should not manually add prefixes, as the platform enforces this convention automatically.

Why this answer

ServiceNow automatically prefixes custom fields created on any table with 'u_' to distinguish them from out-of-box (OOB) system fields. This convention prevents naming collisions with future platform upgrades and makes it easy to identify customizations during cloning or upgrade reviews. So a custom field named 'Root Cause Category' becomes 'u_root_cause_category' on the Problem table.

Exam trap

CIS-ITSM often tests the 'u_' prefix convention — candidates mistakenly think they must manually add the prefix, or they confuse the column name with the field label and pick an option about spaces or uppercase.

How to eliminate wrong answers

Option A is wrong because custom fields do not need to match any existing Incident column; field names are scoped per table and matching an Incident column would create confusion, not a best practice. Option B is wrong because ServiceNow column names must be lowercase with underscores — uppercase letters and spaces are not valid in the database column name (the label can have spaces, but the column name cannot). Option C is wrong because the 'sys_' prefix is reserved for ServiceNow's own system tables and fields; using it for custom fields would conflict with platform internals and is explicitly discouraged.

Full explanation →

309

MCQmedium

When creating a Catalog Client Script, what is the purpose of selecting 'Mobile / Service Portal' as the UI type?

A.It ensures the script executes correctly in Service Portal and mobile interfaces where DOM manipulation is restricted.

B.It restricts the script to run exclusively on native iOS and Android mobile apps.

C.It bypasses client-side caching for catalog item variables.

D.It automatically converts jQuery syntax into AngularJS directives.

AnswerA

Service Portal and mobile render outside the classic Jelly DOM, so scripts relying on direct DOM manipulation fail. Selecting this UI type targets the script at those interfaces and enforces the restricted API model they require.

Why this answer

Selecting 'Mobile / Service Portal' as the UI type in a Catalog Client Script ensures the script is compatible with the Service Portal and mobile interfaces, which use AngularJS instead of the classic Jelly/Prototype-based UI. In these environments, direct DOM manipulation (e.g., using $j or document.getElementById) is restricted or behaves differently, so the script must use the client-side API (g_form, g_user, etc.) that abstracts the UI. This option correctly identifies that the script executes properly in those interfaces by adhering to their constraints.

Exam trap

CIS-ITSM often tests the misconception that 'Mobile / Service Portal' restricts scripts to native mobile apps or that it enables automatic jQuery-to-AngularJS conversion, when in fact it simply ensures compatibility with the AngularJS-based interfaces by enforcing the use of the client-side API.

How to eliminate wrong answers

Option B is wrong because 'Mobile / Service Portal' does not restrict the script to native mobile apps; it applies to any Service Portal or mobile interface, including web-based portals. Option C is wrong because UI type selection has no impact on client-side caching; caching is controlled by browser settings or cache-busting mechanisms, not by the script's UI type. Option D is wrong because the platform does not automatically convert jQuery to AngularJS; developers must write scripts using the provided client-side API, and jQuery is not supported in Service Portal.

Full explanation →

310

MCQeasy

A catalog administrator needs to create a collection of variables that can be reused across multiple catalog items. Which feature should they use?

A.Variable Templates

B.Variable Sets

C.Variable Collections

D.Catalog Item Groups

AnswerB

Variable Sets group reusable variables that can be attached to many catalog items, so the administrator defines values once and references them everywhere. This satisfies the requirement to share variables across multiple catalog items without duplication.

Why this answer

Variable Sets are reusable collections of variables that can be attached to multiple catalog items, allowing administrators to define a set of variables once and include it wherever needed. This promotes consistency and reduces duplication across catalog items.

Exam trap

CIS-ITSM often tests the confusion between Variable Sets and non-existent features like Variable Templates or Variable Collections, when Variable Sets are the correct reusable variable mechanism.

How to eliminate wrong answers

Option A is wrong because Variable Templates are not a standard ServiceNow feature for reusable variable collections; the correct feature is Variable Sets. Option C is wrong because Variable Collections is not a ServiceNow catalog feature; it is a distractor term. Option D is wrong because Catalog Item Groups are used to organize catalog items into categories or groups, not to reuse variables across items.

Full explanation →

311

MCQhard

You want to hide the 'Impact' field from all users except those with the 'admin' role. What is the most secure way to do this?

A.Use an ACL.

B.Update the Dictionary entry.

C.Use a Data Policy.

D.Use a UI Policy.

AnswerA

An ACL evaluates field-level read restrictions against the user's roles, so the Impact field is hidden from everyone lacking the admin role regardless of UI configuration. Client-side or form-layout hiding is bypassable via list views, reports and APIs.

Why this answer

An ACL (Access Control List) is the most secure way to restrict field-level visibility to a specific role because ACLs are enforced server-side and apply to all access paths, including UI, API, and background scripts. By creating a field-level read ACL on the Impact field that requires the 'admin' role, you ensure that only admins can see the field's value regardless of how the data is accessed. This is the recommended security mechanism in ServiceNow for role-based field restrictions.

Exam trap

CIS-ITSM often tests the difference between client-side hiding (UI Policy) and server-side enforcement (ACL), tricking candidates into choosing UI Policy when the question emphasizes security and role-based restriction.

How to eliminate wrong answers

Option B is wrong because updating the Dictionary entry controls field attributes like data type, default value, and dependencies, but it does not enforce role-based visibility; dictionary-level changes affect all users equally. Option C is wrong because Data Policies are used for server-side validation and enforcement of field values (e.g., mandatory, read-only) but are not designed for role-based visibility restrictions. Option D is wrong because a UI Policy only hides the field on the client-side form; a savvy user could still access the field via list views, reports, or API calls, making it insecure.

Full explanation →

312

MCQeasy

When managing known errors, what is the primary purpose of a Known Error Article in ServiceNow Problem Management?

A.To permanently close all related Incidents without user confirmation

B.To communicate workarounds and symptoms to support staff for faster incident resolution

C.To automatically deploy software patches to affected configuration items

D.To replace the need for creating a Root Cause Analysis document

AnswerB

A Known Error Article records the root cause, symptoms and available workaround, letting service desk staff resolve incidents quickly without rediscovering the fault. It satisfies the scenario's need to communicate workarounds and symptoms to support staff, reducing mean time to restore while permanent remediation continues.

Why this answer

A Known Error Article is a knowledge base record created from a Problem that documents the confirmed root cause (or known cause) and any available workaround. Its primary purpose is to surface that information to support agents so they can apply the workaround to related incidents, reducing resolution time while the permanent fix is being developed. It does not close incidents, deploy patches, or replace the RCA — it is a knowledge-sharing artifact tied to the Problem record.

Exam trap

CIS-ITSM often tests the distinction between the Known Error Article (knowledge/workaround communication) and the Change Request (fix deployment), so candidates who conflate 'documenting the fix' with 'applying the fix' pick the patch-deployment distractor.

How to eliminate wrong answers

Option A is wrong because Known Error Articles are informational knowledge records; they have no mechanism to close incidents, and incident closure always requires user confirmation or a defined resolution workflow. Option C is wrong because deploying patches is the job of Change Management (via change tasks and orchestration), not a knowledge article — a Known Error Article only documents the fix, it does not execute it. Option D is wrong because the Root Cause Analysis document captures the investigation findings and is a separate deliverable; the Known Error Article complements the RCA by publishing workarounds and symptoms, it does not replace it.

Full explanation →

313

MCQmedium

A change manager is configuring approval rules for a new Change model called “Database Patching.” The organization requires that all changes using this model be approved by the Database CAB group, but only when the change affects production. Which configuration should the change manager use to meet this requirement without affecting non-production changes?

A.Modify the CAB workbench to include only production changes and assign the Database CAB group as the default approver.

B.Set the “Approval” field on the Change model to “Required” and assign the Database CAB group as the owner.

C.Add a conditional approval to the Change model that triggers only when the “Production” field is true.

D.Create a Change Approval Policy with the condition “Assignment group is Database CAB” and apply it to all Database Patching changes.

AnswerC

Approvals on a Change model can be made conditional by using a condition builder that evaluates fields like Production. This ensures the Database CAB approval is generated only when the change affects production, satisfying the requirement without impacting non-production changes.

Why this answer

Conditional approvals on a Change model allow an organization to require specific approvers only when defined criteria are met. By adding an approval that evaluates the Production field, the Database CAB is engaged exclusively for production changes, leaving non-production changes unaffected. This is the correct way to scope approval requirements to a subset of changes within a model.

Exam trap

The trap here is assuming that assigning an approver group to a model or policy automatically scopes the approval to production changes, when in fact a condition must be explicitly defined.

Full explanation →

314

MCQmedium

An administrator wants to configure SLA definitions specifically for Problem Management. Where should the SLA definition be targeted so it only applies to Problem records?

A.By writing a Client Script on the Incident table

B.In the Problem Properties module

C.By selecting 'Problem [problem]' in the Table field of the SLA Definition record

D.Via Dictionary Overrides on the Task SLA table

AnswerC

Targeting the SLA Definition at the Problem [problem] table scopes the SLA to Problem records only, so the engine evaluates conditions solely against that table rather than Incident or Task. This satisfies the stem's requirement that the definition apply exclusively to Problem Management.

Why this answer

SLA Definitions in ServiceNow are stored in the 'contract_sla' table and include a 'Table' field that determines which task type the SLA applies to. Selecting 'Problem [problem]' in that field scopes the SLA definition exclusively to Problem records, so it will not fire on Incidents, Changes, or other task types. This is the standard, out-of-the-box way to target SLAs at a specific table.

Exam trap

CIS-ITSM often tests the misconception that SLAs are scoped via properties, client scripts, or dictionary overrides, when the actual scoping field is the 'Table' field on the SLA Definition record itself.

How to eliminate wrong answers

Option A is wrong because client scripts run in the browser and cannot create or scope SLA definitions — SLAs are server-side records evaluated by the SLA engine. Option B is wrong because there is no 'Problem Properties' module that controls SLA targeting; Problem properties govern behaviors like state transitions and notifications, not SLA scope. Option D is wrong because Dictionary Overrides change field labels, defaults, or mandatory status on a table — they do not control which table an SLA definition applies to.

Option C is correct because the Table field on the SLA Definition record is the native scoping mechanism.

Full explanation →

315

MCQeasy

What is the definition of a 'Known Error' in ITIL and ServiceNow Problem Management?

A.A software bug that has been successfully patched and deployed to production

B.An expired knowledge base article

C.An incident that has been rejected by the service desk three times

D.A problem that has a documented root cause and a temporary workaround, but no permanent fix yet

AnswerD

A Known Error requires both a documented root cause and a workaround, distinguishing it from an unresolved Problem. The stem asks for the ITIL definition, and this option supplies exactly those two elements while correctly noting the permanent fix is still outstanding.

Why this answer

A Known Error in ITIL and ServiceNow Problem Management is a problem whose root cause has been identified and documented, and for which a workaround exists, but a permanent fix has not yet been implemented. This state is reached after the problem investigation phase confirms the underlying cause. It is distinct from a resolved problem, which has a permanent fix applied.

Exam trap

CIS-ITSM often tests the distinction between a Known Error (root cause known, workaround available, no permanent fix) and a Resolved problem (permanent fix deployed), so candidates who conflate 'documented' with 'fixed' pick the patched-software option.

How to eliminate wrong answers

Option A is wrong because a patched and deployed bug describes a resolved/closed problem, not a Known Error — Known Errors specifically lack a permanent fix. Option B is wrong because an expired knowledge base article is a documentation lifecycle issue unrelated to the ITIL Known Error definition. Option C is wrong because incident rejection counts have no bearing on the Known Error classification; Known Error status depends on root cause identification and workaround availability, not service desk triage history.

Full explanation →

316

MCQeasy

Which field on the Incident form indicates the urgency of the issue from the user's perspective?

A.Priority

B.Severity

C.Urgency

D.Impact

AnswerC

Urgency captures the user's own perception of how quickly the issue needs resolution, which is exactly what the stem asks for. Impact, by contrast, reflects the breadth of disruption across the organisation. ServiceNow combines these two fields to calculate priority, so urgency is the correct answer here.

Why this answer

The Urgency field on the Incident form captures how quickly the user believes the issue needs to be resolved from their perspective. In ServiceNow, Urgency is a user-supplied value (typically High, Medium, Low) that reflects the business or personal need for speed, independent of technical severity. It is a core input to the Priority calculation, which combines Urgency and Impact to determine the overall priority of the incident.

Exam trap

CIS-ITSM often tests the distinction between Urgency and Impact, and candidates frequently confuse Urgency with Priority or Impact, leading them to select the derived or broader field instead of the user-centric one.

How to eliminate wrong answers

Option A is wrong because Priority is a derived field calculated from Impact and Urgency, not a direct indicator of the user's perspective. Option B is wrong because Severity typically measures the technical or business impact of the incident on systems or services, not the user's sense of urgency. Option D is wrong because Impact represents the breadth and depth of the effect on business operations or users, not the user's urgency perception.

Full explanation →

317

MCQmedium

A change manager needs to review the history of a change request, including all state transitions and approval decisions. Which related list on the Change Request form provides this audit trail?

A.Approval History / Activity Stream

B.Outages

C.Configuration Items

D.Catalog Tasks

AnswerA

The Approval History related list records each approval decision with timestamps and approver identity, while the Activity Stream captures state transitions and field changes. Together they provide the complete audit trail the change manager needs.

Why this answer

The Approval History related list (and the Activity Stream) on the Change Request form records all approval decisions, state transitions, and comments, providing the audit trail the change manager needs. Approval History shows who approved or rejected and when, while the Activity Stream captures field changes and work notes. Together they satisfy the requirement to review the full history of the change.

Exam trap

CIS-ITSM often tests whether candidates can distinguish between related lists that show impact (CIs, Outages) and those that show process history (Approval History, Activity Stream), causing them to pick a CI-related list for an audit question.

How to eliminate wrong answers

Option B is wrong because the Outages related list tracks outage records associated with the change, not state transitions or approval decisions. Option C is wrong because Configuration Items lists the CIs affected by the change, which is impact data, not an audit trail. Option D is wrong because Catalog Tasks are the fulfillment tasks generated from a catalog item, not the approval or state history of the change request itself.

Full explanation →

318

MCQhard

A customized Problem workflow utilizes legacy workflow engine. During testing, a workflow timer activity fails to resume after a server restart. What is the most likely cause related to workflow engine execution?

A.The browser cache needs clearing

B.The system scheduler (sys_trigger) or workflow event queue processing encountered an issue

C.The user session expired

D.The Problem form layout was modified

AnswerB

Timer activities depend on scheduled jobs recorded in sys_trigger; after a restart, the scheduler must resume those pending triggers. If sys_trigger processing or the workflow event queue stalls, the timer never fires, so the workflow cannot resume.

Why this answer

Legacy workflow timers in ServiceNow are driven by the system scheduler (sys_trigger) and the workflow event queue. If a timer activity fails to resume after a server restart, the most likely cause is that the scheduler or event queue processing was interrupted or not properly restored. This prevents the timer from firing and resuming the workflow.

Exam trap

CIS-ITSM often tests the misconception that workflow timers are client-side or session-dependent — candidates forget that timers rely on the server-side scheduler and event queue, which can be disrupted by restarts.

How to eliminate wrong answers

Option A is wrong because browser cache is a client-side issue and has no effect on server-side workflow timer execution. Option C is wrong because user session expiration does not stop a workflow timer; workflows run as system processes independent of user sessions. Option D is wrong because form layout changes are cosmetic and do not affect workflow engine execution or timer scheduling.

Full explanation →

319

MCQeasy

What is the purpose of the 'Outages' related list on a Problem record?

A.To record periods of service unavailability associated with the problem's impact

B.To schedule future maintenance windows

C.To log network printer connection drops

D.To track employee vacation schedules

AnswerA

The Outages related list stores distinct outage records, each capturing a period when a service was unavailable, and links them to the problem. This satisfies the stem's requirement to document service unavailability tied to the problem's impact, rather than incident or change data.

Why this answer

The 'Outages' related list on a Problem record in ServiceNow is specifically designed to capture and display periods of service unavailability that are linked to the problem. This allows IT teams to document when a service was down, correlate it with the problem's impact, and analyze the duration and frequency of outages. It is a key part of problem management, helping to assess the business impact and prioritize fixes.

Exam trap

CIS-ITSM often tests the distinction between related lists on Problem records, and candidates may confuse 'Outages' with 'Change Requests' or 'Incidents', assuming it's for scheduling maintenance or logging individual device issues rather than recording service unavailability periods.

How to eliminate wrong answers

Option B is wrong because scheduling future maintenance windows is typically handled through Change Management (e.g., change schedules or maintenance plans), not through the Outages related list on a Problem. Option C is wrong because logging network printer connection drops would be an incident or a specific monitoring alert, not a high-level outage record; the Outages list is for service-level unavailability, not individual device issues. Option D is wrong because tracking employee vacation schedules is an HR function, completely unrelated to IT service management or problem records.

Full explanation →

320

Multi-Selectmedium

Which THREE entities can be associated as 'Affected CIs' or related configuration items in ServiceNow ITSM problem handling? (Choose three.)

Select 3 answers

A.Hardware server

B.Personal grocery shopping list

C.Software application

D.Business service

E.Fictional movie character profile

AnswersA, C, D

Hardware servers exist as configuration items in the CMDB, so they can be linked to a problem record as affected CIs, identifying the physical infrastructure underlying the fault. This satisfies the stem's requirement that the entity be associable as an affected or related CI.

Why this answer

Option A (Hardware server) is correct because physical CIs such as servers are stored in the CMDB as Configuration Items and can be linked to a problem record as Affected CIs to show which infrastructure is impacted. Option C (Software application) is correct because applications are also CMDB configuration items and are commonly associated with problems to identify the affected software. Option D (Business service) is correct because business services are CMDB CIs that can be attached as Affected CIs, allowing problem managers to see the service-level impact of an issue.

Options B (Personal grocery shopping list) and E (Fictional movie character profile) are not valid configuration items in ServiceNow ITSM, since they are not CMDB records representing managed IT assets or services.

Exam trap

CIS-ITSM often tests the distinction between valid CMDB configuration items and arbitrary records, so candidates might mistakenly think any 'item' can be an affected CI, but only those defined in the CMDB as CI classes qualify.

Full explanation →

321

MCQhard

An organization wishes to customize the Risk Assessment questionnaire to include custom branching logic based on the user's previous answer. Which module is used to design and manage these assessments?

A.Assessment Designer (survey_designer)

B.Service Catalog Item Builder

C.Form Designer

D.Workflow Studio

AnswerA

Assessment Designer (survey_designer) is the module for building assessments with conditional branching, letting administrators define question-level logic that routes based on prior answers. It satisfies the requirement for custom branching logic in the Risk Assessment questionnaire.

Why this answer

The Assessment Designer (survey_designer) is the module used to design and manage assessments, including Risk Assessment questionnaires. It provides a graphical interface to create questions, define branching logic, and configure scoring. This is the correct tool for customizing assessments with conditional branching based on previous answers.

Exam trap

CIS-ITSM often tests the distinction between tools for assessments versus forms or workflows. Candidates might choose Form Designer or Workflow Studio, but only Assessment Designer handles questionnaire branching.

How to eliminate wrong answers

Option B is wrong because Service Catalog Item Builder is for creating catalog items, not assessments. Option C is wrong because Form Designer is used to customize form layouts, not questionnaire logic. Option D is wrong because Workflow Studio designs workflows, not assessment branching.

Full explanation →

322

MCQmedium

When configuring a CAB meeting definition, what does the 'Duration' field specify?

A.The maximum allowable time a change request can stay in the Authorize state

B.The window of time for conflict detection lookahead

C.The lead time required before submitting a normal change

D.The planned length of time for the CAB meeting session

AnswerD

Duration defines how long the CAB meeting is scheduled to run, setting the session's planned length in the meeting definition. It does not control attendee lists, agenda items or approval thresholds, so it directly satisfies the stem's requirement to specify the meeting's scheduled time span.

Why this answer

In ServiceNow Change Management, the 'Duration' field on a CAB meeting definition specifies the planned length of the meeting session itself. This value is used to schedule the meeting on the CAB's calendar and to determine the meeting's start and end times. It does not control change state timings, conflict detection, or lead times.

Exam trap

CIS-ITSM often tests the confusion between the CAB meeting Duration field and other time-related settings such as conflict detection windows or state durations, causing candidates to overlook that Duration simply defines the meeting's planned length.

How to eliminate wrong answers

Option A is wrong because the maximum allowable time a change request can stay in the Authorize state is governed by the change model's state transition rules or SLAs, not by the CAB meeting Duration field. Option B is wrong because conflict detection lookahead is configured separately, often via the 'Conflict detection window' or related properties, not through the CAB meeting definition. Option C is wrong because lead time for normal changes is typically defined in the change model or workflow, not in the CAB meeting Duration field.

Full explanation →

323

MCQhard

During an order guide configuration, an administrator needs to ensure that specific catalog items are automatically added to the cart based on the user's answers in the initial 'Describe Needs' prompt. Where should the administrator define this logic?

A.Order Guide Rule Base

B.Workflow Properties

C.Cart Layout

D.Catalog Client Script

AnswerA

The Order Guide Rule Base is the only place where conditional logic can be defined to add catalog items automatically, based on responses to the 'Describe Needs' prompt. It evaluates user answers and triggers the appropriate inclusion of items, satisfying the requirement for dynamic cart population during order guide configuration.

Why this answer

Order Guide Rule Base is the configuration area where administrators define rules that determine which catalog items are included in the cart based on the user's answers to the initial 'Describe Needs' questions. Each rule specifies a condition (based on the order guide's variables) and the catalog items to add when the condition is true. This is the native mechanism for conditional item inclusion in an order guide.

Exam trap

CIS-ITSM often tests the confusion between order guide rule logic (Rule Base) and client-side form logic (Catalog Client Script), causing candidates to pick the client script option for server-side cart composition.

How to eliminate wrong answers

Option B is wrong because Workflow Properties control workflow behavior (e.g., stages, activities), not the conditional inclusion of catalog items in an order guide cart. Option C is wrong because Cart Layout defines the visual arrangement of the cart, not the logic for adding items. Option D is wrong because a Catalog Client Script runs on the catalog item form and cannot govern order guide rule evaluation, which is a server-side order guide feature.

Full explanation →

324

Multi-Selecthard

Which THREE factors can be used by the Change Conflict Detection engine to identify a conflict?

Select 3 answers

A.The change requester's location

B.Planned start and end dates

C.Blackout or maintenance windows

D.The change priority level

E.Configuration Item (CI)

AnswersB, C, E

Planned start and end dates define when each change executes, so overlapping schedules are detected as conflicts. This satisfies the detection criterion by comparing time ranges, catching changes that would run concurrently on shared resources.

Why this answer

The Change Conflict Detection engine identifies conflicts by comparing the planned start and end dates (B) of changes, since overlapping schedules on the same resource create a scheduling conflict. Blackout or maintenance windows (C) are also used, because a change scheduled inside a restricted window conflicts with the policy-defined freeze period. The Configuration Item (CI) (E) is a key factor, as conflicts are detected when multiple changes target the same CI or related CIs.

The change requester's location (A) is not a conflict criterion, since geography alone does not create a scheduling or resource conflict. The change priority level (D) is not used to detect conflicts; priority affects approval and sequencing, not whether a conflict exists.

Exam trap

CIS-ITSM often tests the distinction between factors that feed conflict detection (dates, blackout windows, CIs) versus factors that are merely attributes of a change (requester location, priority), so candidates must recognize that priority and location are red herrings.

Full explanation →

325

Multi-Selecteasy

Which TWO options represent valid ways an end user (caller) can check the status of their submitted incident? (Choose two.)

Select 2 answers

A.Accessing the core UI Incident list view

B.System Administrator impersonation

C.Direct database query via ODBC client

D.Automated email notifications triggered by lifecycle state changes

E.Service Portal ('My Requests' or 'My Tickets' widget)

AnswersD, E

Automated email notifications fire on lifecycle state transitions, so the caller receives status updates without logging in or contacting the service desk. This satisfies the stem's requirement for a valid caller-facing status check, since the incident record's state change itself triggers the notification, keeping the user informed passively.

Why this answer

Option D is correct because automated email notifications are triggered by lifecycle state changes on the incident record, so the caller receives status updates (e.g., when the incident moves to In Progress, On Hold, or Resolved) without needing direct system access. Option E is correct because the Service Portal provides end users with 'My Requests' or 'My Tickets' widgets that query incident records where the caller is the opened_by or requested_for user, giving them a self-service view of current state and work notes visible to the caller. Option A is not valid for an end user because the core UI Incident list view is a platform/agent-facing interface that requires an internal role (e.g., itil) and is not exposed to callers.

Option B is not valid because System Administrator impersonation is a privileged admin capability, not a caller self-service method, and would be an inappropriate/unauthorized way for an end user to check status. Option C is not valid because direct database queries via an ODBC client bypass the application's ACLs and business logic, are not a supported end-user mechanism, and would typically be blocked or require elevated DBA credentials.

Exam trap

The trap is assuming that any interface showing incident data is available to end users; the exam tests whether candidates know that core UI list views and database queries are privileged, while portal widgets and notifications are the caller-facing channels.

Full explanation →

326

MCQmedium

An organization uses custom pricing for specific catalog items based on user attributes or quantities. Where is item pricing primarily configured for a standard catalog item?

A.Workflow transition conditions

B.Service Level Agreement (SLA) definition

C.Order Guide Rule Base

D.Catalog Item form (Price and Recurring Price fields)

AnswerD

Custom pricing for catalog items is stored directly on the Catalog Item record, where the Price and Recurring Price fields hold the values used when the item is ordered. Configuring these fields satisfies the requirement for attribute- or quantity-based custom pricing without relying on separate price lists.

Why this answer

For a standard catalog item, the Price and Recurring Price fields on the Catalog Item form are the primary place where item pricing is configured. These fields define the one-time and recurring costs that appear on the catalog item and flow into the resulting request and price records. Custom pricing based on user attributes or quantities is then layered on via pricing rules or scripts, but the base price lives on the Catalog Item form.

Exam trap

CIS-ITSM often tests whether candidates know that base pricing lives on the Catalog Item form, while dynamic pricing rules are separate — candidates mistakenly pick workflow or SLA options that sound related to 'configuration.'

How to eliminate wrong answers

Option A is wrong because workflow transition conditions control the flow of approvals and task execution, not pricing — they determine when a record moves between states. Option B is wrong because an SLA definition governs response and resolution time targets, not item cost. Option C is wrong because an Order Guide Rule Base controls which catalog items are included or excluded in an order guide based on user answers, not the price of an individual item.

Full explanation →

327

MCQeasy

Which role is the minimum required to read and update incident records?

A.user

B.itil

C.admin

D.itil_admin

AnswerB

The itil role grants the read and update permissions required for incident records, making it the minimum role that satisfies both operations. Roles such as admin or sn_incident_write exceed this requirement, while read-only roles cannot update records.

Why this answer

The itil role in ServiceNow is the minimum role that grants read and write access to incident, problem, and change records. It is designed for ITIL process users such as service desk agents who need to work on incidents daily. The user role alone cannot update incidents, and admin/itil_admin are higher-privileged than required.

Exam trap

CIS-ITSM often tests the difference between 'user' (self-service only) and 'itil' (process user), and candidates incorrectly assume the base user role can update incidents.

How to eliminate wrong answers

Option A is wrong because the base 'user' role only grants access to self-service and basic record viewing — it cannot read or update incident records belonging to other users. Option C is wrong because 'admin' is a full system administrator role with far more privileges than needed, so it is not the minimum. Option D is wrong because 'itil_admin' is a role that combines ITIL process access with administrative capabilities over ITIL tables, which exceeds the minimum required to simply read and update incidents.

Full explanation →

328

MCQhard

A catalog item 'Software Request' includes a variable 'Justification' that should only be visible when the 'Request Type' variable is set to 'New Software'. The 'Justification' variable is part of a Variable Set that is used in multiple catalog items. The administrator needs to ensure the visibility rule applies consistently across all items where the set is used, without modifying each item individually. What should the administrator do?

A.Create a Catalog Client Script on each catalog item that uses the Variable Set to hide the 'Justification' variable based on 'Request Type'.

B.Modify the Variable Set to include a condition that hides the 'Justification' variable unless 'Request Type' is 'New Software'.

C.Create a Catalog UI Policy on the Variable Set record that hides the 'Justification' variable when 'Request Type' is not 'New Software'.

D.Create a UI Policy on the 'Request Type' variable that sets the 'Justification' variable to not visible when the condition is met.

AnswerC

Catalog UI Policies can be defined on Variable Sets, and they apply to all catalog items that include that set. This ensures consistent behavior without editing each item. The policy can target the specific variable within the set and use a condition on the 'Request Type' variable. This is the most efficient and maintainable approach, as changes to the policy automatically propagate to all items using the set.

Why this answer

Catalog UI Policies can be defined on Variable Sets, and they apply wherever the set is used. This centralizes the visibility rule for the 'Justification' variable, ensuring it only appears when 'Request Type' is 'New Software' across all catalog items. This avoids per-item customization and maintains consistency.

Other options either require individual item changes, incorrectly assume UI Policies on variables propagate, or misunderstand Variable Set capabilities.

Exam trap

The trap here is thinking that UI Policies on individual variables automatically apply to all instances of a Variable Set, when in fact the policy must be defined on the Variable Set itself to propagate.

Full explanation →

329

MCQeasy

An administrator needs to create a variable that is shared across multiple catalog items in ServiceNow. Which feature should the administrator use to achieve this efficiently without recreating the variables each time?

A.Order Guide

B.Catalog UI Policy

C.Record Producer

D.Variable Set

AnswerD

A Variable Set groups variables into a reusable container that can be attached to many catalog items, so the administrator defines the variables once and references the set everywhere. This avoids recreating identical variables per item, meeting the efficiency requirement.

Why this answer

A Variable Set is a reusable container of variables that can be attached to multiple catalog items, record producers, or other variable sets. This allows the administrator to define variables once and share them across items without recreating them, which is exactly the requirement.

Exam trap

CIS-ITSM often tests the misconception that Order Guides or UI Policies can share variables across items, when the correct feature for reusable variable definitions is the Variable Set.

How to eliminate wrong answers

Option A is wrong because an Order Guide groups multiple catalog items into a single ordering flow — it does not share variables across items. Option B is wrong because a Catalog UI Policy controls variable behavior (visibility, mandatory, read-only) on a single item; it does not share variable definitions. Option C is wrong because a Record Producer creates records from a catalog-like form but does not provide a mechanism for sharing variables across multiple catalog items.

Full explanation →

330

MCQmedium

When configuring User Criteria to restrict a catalog item so that only members of the 'HR' department can view it, where should this user criteria be attached?

A.In the 'User Criteria' related list on the Catalog Category form.

B.In the 'Available For' related list on the Catalog Item form.

C.In the 'Audience' field of the Service Portal Page record.

D.In the 'Access Control' rules mapped to the sc_cat_item table.

AnswerB

User Criteria restricting visibility must be attached via the 'Available For' related list on the Catalog Item form, which controls which users or groups can see and request the item. This satisfies the requirement that only HR department members can view it.

Why this answer

User Criteria that restrict a catalog item to a specific department are attached in the 'Available For' related list on the Catalog Item form. This related list is the supported mechanism for granting visibility to specific users, groups, or departments, and it is evaluated by the catalog visibility engine when users browse or search the catalog.

Exam trap

CIS-ITSM often tests the difference between User Criteria on the Catalog Item form versus ACLs on sc_cat_item — the trap is picking the ACL option because it sounds more secure, but User Criteria is the correct and supported mechanism for catalog visibility.

How to eliminate wrong answers

Option A is wrong because User Criteria on a Catalog Category form controls visibility of the category, not an individual catalog item — and the question specifically asks about restricting a catalog item. Option C is wrong because the 'Audience' field on a Service Portal Page record controls which portal page a user sees, not catalog item visibility. Option D is wrong because ACLs on sc_cat_item control record-level read/write access and are not the recommended way to manage catalog item visibility; they can break portal rendering and search.

Full explanation →

331

Multi-Selecthard

Which THREE of the following components are part of the Service Catalog data model? (Choose three.)

Select 3 answers

A.Configuration Item [cmdb_ci]

B.Problem [problem]

C.Catalog Task [sc_task]

D.Request [sc_request]

E.Requested Item [sc_req_item]

AnswersC, D, E

Catalog Task [sc_task] records the fulfilment work generated when a catalog item is ordered, linking the request to its underlying tasks. It forms part of the Service Catalog data model alongside Catalog Item and Category, satisfying the stem's requirement for three valid components rather than unrelated task tables.

Why this answer

In the ServiceNow Service Catalog data model, the three core tables that make up a catalog request are Request [sc_request], Requested Item [sc_req_item], and Catalog Task [sc_task]. Option D, Request [sc_request], is correct because it is the top-level record that groups one or more requested items submitted together in a single catalog order. Option E, Requested Item [sc_req_item], is correct because it represents the individual line item for each catalog item ordered and is the record that drives approval and fulfillment workflows.

Option C, Catalog Task [sc_task], is correct because it is the task record generated against a requested item to carry out the actual fulfillment work. Options A and B are not part of the Service Catalog data model: Configuration Item [cmdb_ci] belongs to the CMDB, and Problem [problem] belongs to ITIL problem management, neither of which is a catalog request component.

Exam trap

CIS-ITSM often tests the distinction between Service Catalog tables and other ITSM tables like CMDB and Problem — candidates incorrectly include cmdb_ci or problem in the Service Catalog data model.

Full explanation →

332

MCQeasy

What is the primary function of the 'Known Error Database' (KEDB) module in ServiceNow ITSM?

A.To store known problems and their documented workarounds for searching and incident deflection

B.To log hardware failures directly from network monitoring tools

C.To store employee training documentation for the service desk

D.To automatically approve change requests linked to problems

AnswerA

The KEDB stores known errors with their root causes and documented workarounds, letting service desk agents search existing entries and apply fixes without re-investigating. This directly satisfies the incident deflection requirement in the stem, reducing resolution time by surfacing proven workarounds for problems already diagnosed.

Why this answer

The Known Error Database (KEDB) in ServiceNow ITSM stores known problems and their documented workarounds, allowing service desk agents to quickly search for and apply workarounds to resolve incidents or deflect them. It is a repository of problem records that have been analyzed and have a root cause and workaround identified, often linked to incidents to provide immediate resolution guidance.

Exam trap

CIS-ITSM often tests the difference between the KEDB and the Knowledge Base; candidates may think the KEDB is a separate database, but it is essentially a subset of problem records with workarounds.

How to eliminate wrong answers

Option B is wrong because hardware failures from network monitoring tools are typically logged as incidents or alerts via event management, not stored in the KEDB. Option C is wrong because employee training documentation is stored in Knowledge Base articles or document repositories, not the KEDB. Option D is wrong because change request approvals are handled by change management workflows, not the KEDB; the KEDB does not automatically approve changes.

Full explanation →

333

MCQhard

When a Major Incident is created, what happens to the linked child incidents?

A.They are ignored by the system

B.They are deleted

C.They are closed immediately

D.They are automatically updated with major incident information

AnswerD

When a major incident is raised, linked child incidents are automatically updated with the major incident information, keeping them aligned without manual edits. This propagation ensures consistent status and reference data across all related records throughout the major incident lifecycle.

Why this answer

When a Major Incident is created in ServiceNow, linked child incidents are automatically updated with major incident information. This ensures that all related incidents share the major incident context, including the major incident number, state, and communication updates. The system propagates key fields from the parent major incident to the child incidents so that support teams and users have consistent information across all linked records.

Exam trap

CIS-ITSM often tests the Major Incident Management process — candidates assume child incidents are closed or deleted when a major incident is created, but the correct behavior is that they are updated with major incident information and remain linked for tracking.

How to eliminate wrong answers

Option A is wrong because child incidents are not ignored — they are actively updated with major incident details. Option B is wrong because child incidents are not deleted; they remain as separate records linked to the major incident for tracking and reporting. Option C is wrong because child incidents are not closed immediately — they are updated with major incident information and remain open until resolved through the normal incident lifecycle.

Full explanation →

334

MCQhard

To prevent overlapping outages, you are configuring Conflict Detection. Which table contains the criteria used to identify conflicts?

A.Change Conflict Definition [change_conflict_definition]

B.Change Request [change_request]

C.CAB Definition [cab_definition]

D.Change Schedule [cmn_schedule]

E.Change Conflict [change_conflict]

AnswerA

The Change Conflict Definition [change_conflict_definition] table stores the criteria records that Conflict Detection evaluates to determine whether changes overlap. Configuring entries there defines which change fields and conditions trigger a conflict warning, preventing overlapping outages.

Why this answer

The Change Conflict Definition [change_conflict_definition] table contains the criteria used to identify conflicts between changes. It defines the conditions under which changes are considered conflicting, such as overlapping schedules or shared configuration items.

Exam trap

CIS-ITSM often tests the distinction between the definition table and the conflict table; candidates may choose Change Conflict [change_conflict] because it sounds like it contains conflict criteria, but it actually stores the detected conflicts.

How to eliminate wrong answers

Option B is wrong because the Change Request [change_request] table stores the actual change records, not the conflict criteria. Option C is wrong because the CAB Definition [cab_definition] table defines CAB members and schedules, not conflict detection rules. Option D is wrong because the Change Schedule [cmn_schedule] table stores schedule records, not conflict criteria.

Option E is wrong because the Change Conflict [change_conflict] table stores detected conflicts, not the criteria used to identify them.

Full explanation →

335

MCQhard

A CMDB administrator is configuring the Identification and Reconciliation Engine (IRE) to handle data from multiple discovery sources. The administrator wants to ensure that if two sources provide conflicting values for the same attribute, the source with the highest priority wins. Which IRE feature should be configured to achieve this?

A.CI class manager

B.Identification rules

C.Reconciliation rules

D.Data source precedence

AnswerD

Data source precedence allows administrators to define the order of priority for discovery sources. When IRE processes data from multiple sources, it uses this precedence to determine which source's values take precedence during reconciliation. This directly addresses the requirement to have the highest priority source win in case of conflicts.

Why this answer

Data source precedence is a specific IRE configuration that ranks discovery sources. When IRE reconciles data, it compares values from different sources and applies the source with the highest precedence. This ensures that authoritative sources override less reliable ones.

Configuring data source precedence is the correct method to achieve the desired conflict resolution.

Exam trap

The trap here is confusing reconciliation rules with data source precedence; while both are part of IRE, only data source precedence determines which source's values win.

Full explanation →

336

MCQhard

When utilizing Flow Designer to fulfill a Service Catalog request, how should the flow access the variables submitted by the user on the catalog item?

A.By calling a client-side script from the flow action

B.Using a legacy GlideRecord query on sc_item_option_mtom

C.Through the 'Requested Item' record data pill, accessing the 'Variables' section

D.Using system properties configured in the flow inputs

AnswerC

Catalog item variables are stored on the Requested Item (sc_req_item) record, so the flow retrieves them via that record's data pill and its Variables section. This gives the flow the submitted user values it needs to fulfil the request.

Why this answer

In Flow Designer, catalog item variables submitted by the user are accessible through the 'Requested Item' record data pill, which exposes a 'Variables' section containing all the variable values. This is the standard, supported way to reference catalog variables within a flow.

Exam trap

The trap is choosing legacy GlideRecord queries or client-side scripting out of habit — candidates familiar with older ServiceNow patterns may miss that Flow Designer natively exposes catalog variables through the Requested Item data pill.

How to eliminate wrong answers

Option A is wrong because calling a client-side script from a flow action is not how Flow Designer accesses catalog variables — flows run server-side and should use data pills, not client scripts. Option B is wrong because querying sc_item_option_mtom directly with GlideRecord is a legacy, unsupported pattern that bypasses the modern Flow Designer data model and is unnecessary when the Requested Item data pill already exposes variables. Option D is wrong because system properties are global configuration values, not the mechanism for passing catalog item variable data into a flow.

Full explanation →

337

Multi-Selecthard

When an administrator troubleshoots why conflict detection did not flag an overlap between two change requests, which THREE factors should be investigated? (Choose three.)

Select 3 answers

A.Whether conflict detection properties and business rules are active and enabled

B.Whether both change requests share the same Configuration Item or have a defined CI relationship

C.Whether the user submitting the change has the security_admin role

D.Whether the change requests have overlapping Planned Start and Planned End date-time values

E.Whether the target CI classes are excluded from incident management

AnswersA, B, D

Conflict detection relies on active properties and business rules to compare change schedules; if these are disabled, overlaps pass unflagged. Verifying they are enabled directly satisfies the stem's requirement to investigate why detection failed, since inactive configuration is a primary cause of missed conflicts in the change management workflow.

Why this answer

Option A is correct because conflict detection depends on the relevant properties and business rules being active and enabled; if those configuration records are disabled or misconfigured, overlaps will not be flagged. Option B is correct because conflict detection evaluates changes against the same Configuration Item or CIs connected through a defined CI relationship, so without a shared or related CI no conflict is identified. Option C is incorrect because the security_admin role governs elevated access to security-related records and does not determine whether change conflict detection runs.

Option D is correct because conflict detection compares the Planned Start and Planned End date-time values, and only overlapping windows trigger a conflict. Option E is incorrect because exclusion of CI classes from incident management is unrelated to change conflict detection logic.

Exam trap

CIS-ITSM often tests the misconception that conflict detection depends on user roles or incident settings, when it actually hinges on CI relationships, schedule overlap, and active conflict rules.

Full explanation →

338

Multi-Selectmedium

Which TWO criteria are typically evaluated when selecting whether a change should be classified as a Standard Change rather than a Normal Change? (Choose two.)

Select 2 answers

A.The change has a proven history of success and is repeatable

B.The change requires a full CAB review and multi-level executive sign-off

C.The change affects the entire enterprise core data center simultaneously with unknown impact

D.The change is low risk and has been pre-authorized

E.The change requires urgent, immediate implementation due to an active outage

AnswersA, D

Standard changes are routine and repeatable with a known track record.

Why this answer

Option A is correct because a Standard Change is by definition a pre-approved, repeatable change with a documented and proven history of successful execution, which is exactly the criterion used to decide it does not need individual review. Option D is correct because Standard Changes are characterized as low-risk, routine changes that have been pre-authorized (typically via a change model in the ITIL/ITSM framework), so they can be implemented without a CAB review each time. Option B is not correct because requiring a full CAB review and multi-level executive sign-off describes a Normal Change (often a major/high-impact one), which is the opposite of a Standard Change.

Option C is not correct because affecting the entire enterprise core data center simultaneously with unknown impact is a high-risk, high-impact change that would be classified as a Normal (or Emergency) Change requiring assessment. Option E is not correct because urgent, immediate implementation due to an active outage describes an Emergency Change, which follows an expedited approval path rather than the pre-authorized Standard Change route.

Exam trap

The trap is confusing Standard Changes with Emergency Changes or Normal Changes. Candidates might think that any low-risk change is Standard, but it must also be pre-authorized and repeatable. Conversely, they might think that high-risk changes can be Standard if they are urgent, which is not the case.

Full explanation →

339

MCQmedium

A CMDB administrator is configuring the Identification and Reconciliation Engine (IRE) for a new data source that discovers network switches. The administrator needs to ensure that when a switch is discovered, IRE uses the switch's serial number as the primary identifier and falls back to the MAC address if the serial number is missing. Which configuration should the administrator perform?

A.Modify the CI Class Manager to set the serial_number as the unique key for the Network Switch class, and configure mac_address as an alternate key.

B.Create an Identification Rule for the Network Switch [cmdb_ci_netgear] class with two entries: serial_number with a higher priority, and mac_address with a lower priority.

C.Create a Reconciliation Rule for the Network Switch [cmdb_ci_netgear] class that specifies serial_number as the primary attribute and mac_address as the secondary attribute.

D.Create a Data Source Precedence rule that prioritizes serial_number over mac_address for the Network Switch class.

AnswerB

This is correct because IRE identification rules allow multiple entries with priority order to determine the primary and fallback identifiers. By placing serial_number at a higher priority and mac_address at a lower priority, IRE will attempt to match using serial_number first, and if absent, will use mac_address. This aligns with the requirement for a fallback identifier.

Why this answer

The Identification and Reconciliation Engine uses identification rules to match incoming CI data to existing records. Identification rules contain entries that specify attributes and their priority. By creating a rule with serial_number at a higher priority and mac_address at a lower priority, IRE will use serial_number as the primary identifier and mac_address as a fallback when serial_number is missing.

This is the standard way to configure fallback identification.

Exam trap

The trap here is confusing identification rules with reconciliation rules or data source precedence, which govern different stages of the CI data processing pipeline.

Full explanation →

340

Multi-Selecthard

Which THREE of the following statements are correct regarding Catalog Client Scripts? (Choose three.)

Select 3 answers

A.They execute on the server side during database insert operations.

B.They support script types including onLoad, onChange, and onSubmit.

C.They can use the g_form API to control field visibility and values.

D.They can be written to execute asynchronously using GlideAjax to query server data.

E.They automatically replace workflow activities in defining task assignments.

AnswersB, C, D

Catalog Client Scripts run client-side in the browser, and ServiceNow defines distinct script types for them: onLoad fires when the form loads, onChange when a specified field value changes, and onSubmit before submission. This directly satisfies the stem's requirement for supported script types, confirming the statement as accurate.

Why this answer

Option B is correct because Catalog Client Scripts support the standard client-side script types onLoad (runs when the catalog form loads), onChange (runs when a specified variable changes), and onSubmit (runs when the form is submitted). Option C is correct because Catalog Client Scripts run in the browser and can use the g_form API to manipulate the form, such as hiding/showing variables with g_form.setDisplay() or setting values with g_form.setValue(). Option D is correct because client scripts can call GlideAjax to asynchronously query server-side data without a full page reload, which is a common pattern for retrieving reference or database values in catalog items.

Option A is incorrect because Catalog Client Scripts execute on the client (browser) side, not on the server during database inserts; server-side logic would require a Catalog Script Include, Business Rule, or similar. Option E is incorrect because Catalog Client Scripts do not replace workflow activities; workflows and Flow Designer are separate orchestration mechanisms for task assignments and approvals.

Exam trap

CIS-ITSM often tests the misconception that Catalog Client Scripts run on the server side or can directly manipulate database records, when they are actually client-side and require GlideAjax for server data.

Full explanation →

341

Multi-Selectmedium

Which TWO of the following settings are required for the CAB Workbench to function correctly?

Select 2 answers

A.A dedicated CI for the CAB

B.An assigned ITIL manager

C.Scheduled CAB meetings

D.An active workflow for every change

E.A defined CAB Definition

AnswersC, E

Scheduled CAB meetings supply the change calendar entries the Workbench aggregates and displays, satisfying the requirement that upcoming change windows be visible to approvers. Without defined meeting records, the Workbench cannot render the agenda or associate changes with a review slot, so this setting is mandatory for correct operation.

Why this answer

Option C is correct because the CAB Workbench is driven by scheduled CAB meetings; the workbench aggregates the change records that are linked to a CAB meeting's agenda, so without scheduled meetings there is nothing for the workbench to display or manage. Option E is correct because a CAB Definition record is the configuration that tells the CAB Workbench which table, fields, and meeting-related settings to use, so the workbench cannot render or function without a defined CAB Definition. Option A is not required, since the CAB Workbench does not depend on a dedicated CI for the CAB; it works from CAB definitions and meetings rather than a specific configuration item.

Option B is not required, as the workbench does not mandate an assigned ITIL manager role to operate. Option D is not required, because an active workflow for every change is a change-management process concern and is not a prerequisite for the CAB Workbench to function.

Exam trap

CIS-ITSM often tests the prerequisites for the CAB Workbench, so the trap is selecting plausible-sounding but unnecessary items like a dedicated CI or an ITIL manager, when the actual requirements are the CAB Definition and scheduled meetings.

Full explanation →

342

MCQhard

An administrator needs to write an onSubmit Catalog Client Script that validates whether at least one checkbox in a group of ten checkboxes is checked before the item can be added to the cart. Which approach should be used?

A.Write a Client Script on the sc_cart table to intercept the checkout action.

B.Configure a Dictionary Override on the sc_req_item table to enforce mandatory checkboxes.

C.Iterate through the checkbox variable names using g_form.getValue() and return false if none are true, preventing submission.

D.Use document.getElementsByClassName() to count checked elements directly from the DOM.

AnswerC

Iterating with g_form.getValue() across all ten checkbox variables directly satisfies the "at least one checked" constraint, since onSubmit returning false halts submission and displays the mandatory message. This client-side validation runs before the item reaches the cart, catching the empty selection without server round-trips.

Why this answer

An onSubmit Catalog Client Script runs before the item is added to the cart, allowing validation logic to execute. Using g_form.getValue() to iterate through each checkbox variable and checking if at least one is true, then returning false if none are checked, prevents submission and displays an error message. This is the standard client-side validation approach for catalog items.

Exam trap

CIS-ITSM often tests the confusion between client-side validation using g_form API and unsupported DOM manipulation or incorrect table-level scripts, leading candidates to choose DOM-based or sc_cart-based approaches.

How to eliminate wrong answers

Option A is wrong because a Client Script on the sc_cart table intercepts checkout, not the 'Add to Cart' action, and does not validate individual catalog item variables at submission time. Option B is wrong because Dictionary Overrides apply to table fields, not catalog variables, and cannot enforce mandatory checkboxes in a variable group. Option D is wrong because using document.getElementsByClassName() directly manipulates the DOM, which is unsupported in ServiceNow client scripts and breaks with UI changes or platform upgrades.

Full explanation →

343

MCQhard

You want to hide the 'Impact' field for users who do not have the 'itil' role. Where is the most appropriate place to configure this?

A.ACL

B.UI Policy

C.Data Policy

D.Client Script

AnswerB

A UI Policy dynamically hides or makes fields read-only based on role or other conditions, so the Impact field can be suppressed for users lacking the itil role. ACLs and dictionary changes cannot achieve this role-based form behaviour.

Why this answer

A UI Policy is the correct place to hide the 'Impact' field for users without the 'itil' role, because UI Policies control field visibility, mandatory, and read-only behavior on the client side based on conditions like role or field values. They are the standard ServiceNow mechanism for role-based form field display.

Exam trap

CIS-ITSM often tests the confusion between UI Policies (form field visibility) and ACLs (data access security) — candidates pick ACLs thinking 'hide' means 'secure,' but the question asks about form field visibility.

How to eliminate wrong answers

Option A is wrong because ACLs control record- and field-level read/write access at the database layer — they restrict data access, not form field visibility, and hiding via ACL would still leave the field rendered but inaccessible. Option C is wrong because Data Policies enforce mandatory/read-only rules on the server side during save, not visibility on the form. Option D is wrong because a Client Script can manipulate fields via JavaScript, but it is not the declarative, maintainable mechanism for role-based field hiding that UI Policies provide.

Full explanation →

344

MCQeasy

An incident has been resolved and the caller confirms the fix. The incident is now in the 'Resolved' state. After a predefined period, the incident should automatically move to 'Closed'. Which feature controls this automatic closure?

A.The 'Close unresolved incidents' scheduled job.

B.A business rule that runs on the incident table when the state changes to Resolved.

C.The 'Incident resolution' workflow.

D.The 'Auto close incidents' scheduled job.

AnswerD

The 'Auto close incidents' scheduled job automatically closes incidents that have been in the Resolved state for a specified number of days. This is the standard mechanism for moving resolved incidents to closed after a grace period. It ensures that incidents are not left open indefinitely.

Why this answer

The 'Auto close incidents' scheduled job is the standard feature that automatically closes incidents after they have been in the Resolved state for a configured number of days. This ensures that resolved incidents are eventually closed without manual intervention.

Exam trap

The trap here is confusing the job that closes unresolved incidents with the one that closes resolved incidents.

Full explanation →

345

MCQeasy

Which record type represents the actual fulfillment process of a single catalog item included in a request?

A.Order Guide (sc_cat_item_guide)

B.Catalog Task (sc_task)

C.Service Request (sc_request)

D.Request Item (sc_req_item)

AnswerD

A Request Item (sc_req_item) tracks the fulfilment of one individual catalog item within a parent Request, recording its own state, tasks and approvals. This granularity satisfies the stem's requirement for the actual fulfilment process of a single catalog item, rather than the whole request.

Why this answer

The Request Item (sc_req_item) record represents the fulfillment of a single catalog item within a request. When a user orders a catalog item (or an Order Guide containing multiple items), ServiceNow creates one sc_request record and one sc_req_item per catalog item, and each Request Item drives its own fulfillment workflow and catalog tasks.

Exam trap

CIS-ITSM often tests the confusion between sc_request, sc_req_item, and sc_task — candidates pick the top-level Service Request when the question asks about a single catalog item's fulfillment.

How to eliminate wrong answers

Option A is wrong because an Order Guide (sc_cat_item_guide) is a container that bundles multiple catalog items into a single ordering experience — it is not the fulfillment record for a single item. Option B is wrong because a Catalog Task (sc_task) represents a unit of work assigned to a fulfiller within a Request Item's workflow, not the item-level fulfillment record itself. Option C is wrong because a Service Request (sc_request) is the top-level container that groups one or more Request Items; it represents the overall request, not a single item's fulfillment.

Full explanation →

346

MCQhard

An administrator needs to modify the window of time considered by the Conflict Detection engine when checking for overlapping changes on the same Configuration Item (CI). Where is this conflict time window configured?

A.The ConflictFinderSNC script include hardcoded constants

B.CI Relationship types table

C.Change Properties module under 'Conflict' tab

D.System Properties (prefix com.snc.change_management.conflict)

AnswerD

The conflict detection window is governed by system properties under the com.snc.change_management.conflict prefix, which define the look-back and look-ahead periods for overlapping changes on a CI. Editing these properties directly modifies the time window the engine considers.

Why this answer

The conflict detection time window is configured in System Properties with the prefix com.snc.change_management.conflict. These properties define the window before and after a change during which overlapping changes on the same CI are flagged. Administrators adjust these values to control how far apart changes must be to avoid conflicts.

Exam trap

The trap is assuming the conflict window is hardcoded in a script include or configured in a module, when it is actually controlled via system properties with the com.snc.change_management.conflict prefix.

How to eliminate wrong answers

Option A is wrong because the ConflictFinderSNC script include does not contain hardcoded constants for the time window; it reads from system properties. Option B is wrong because CI Relationship types define how CIs relate, not conflict timing. Option C is wrong because there is no 'Conflict' tab under Change Properties; the settings are in System Properties.

Full explanation →

347

Multi-Selectmedium

A change manager is configuring the Change Management process to meet audit requirements. The auditor requests evidence that changes are properly authorized and that the risk of changes is assessed before implementation. Which TWO configurations should the change manager verify are in place? (Choose two.)

Select 2 answers

A.The Change model includes a mandatory approval step before the change can move to Implement.

B.The Change request is automatically assigned to the change manager's assignment group.

C.The Change request has a post-implementation review task created automatically.

D.The Change request form includes a mandatory field for the implementation plan.

E.The Risk Assessment is completed and the Risk field is populated before the change is approved.

AnswersA, E

A mandatory approval step ensures that changes cannot proceed to implementation without explicit authorization. This provides auditable evidence that changes are reviewed and approved by the appropriate authority, directly satisfying the auditor's requirement for proper authorization.

Why this answer

To satisfy the auditor, the change process must enforce authorization and risk assessment before implementation. A mandatory approval step ensures changes are authorized, and a completed risk assessment with a populated Risk field shows that risk was evaluated. Together, these provide the necessary audit evidence.

Exam trap

The trap here is confusing general good practices like implementation plans or post-implementation reviews with the specific evidence needed for authorization and risk assessment.

Full explanation →

348

Multi-Selectmedium

Which TWO actions can a change coordinator perform within the CAB Workbench during an active meeting? (Choose two.)

Select 2 answers

A.Add ad-hoc change requests to the meeting agenda

B.Automatically deploy software packages to production servers

C.Record votes and decisions for change requests on the agenda

D.Modify global system properties for risk calculation

E.Initiate ITOM Discovery scans across the entire network

AnswersA, C

Adding ad-hoc change requests to the agenda is a core CAB Workbench capability, letting the coordinator inject unplanned changes mid-meeting without ending the session. This satisfies the stem's "during an active meeting" constraint, since the workbench supports live agenda modification rather than requiring changes to be scheduled beforehand.

Why this answer

Option A is correct because the CAB Workbench allows a change coordinator to add ad-hoc change requests to the meeting agenda during an active meeting, enabling last-minute items to be discussed and reviewed. Option C is correct because the change coordinator can record votes and decisions for change requests on the agenda, capturing CAB approvals or rejections directly in the workbench. Option B is incorrect because deploying software packages to production servers is a fulfillment/release activity, not a CAB Workbench meeting action.

Option D is incorrect because modifying global system properties for risk calculation is an administrative configuration task outside the CAB Workbench meeting workflow. Option E is incorrect because initiating ITOM Discovery scans is a discovery/operations function, not a change coordination meeting action.

Exam trap

CIS-ITSM often tests the distinction between meeting facilitation actions (adding agenda items, recording votes) and broader administrative or operational tasks (system property changes, discovery scans, deployments), so candidates must recognize that the CAB Workbench is strictly for meeting management.

Full explanation →

349

MCQhard

An IT organization defines a Service Level Agreement (SLA) for Incident Resolution that must pause its timer whenever an incident moves to the 'Awaiting User Info' state. Where must this pause condition be configured within the SLA definition record?

A.In the SLA Workflow properties under 'Timer Pause Actions'

B.In the SLA Definition form under the 'Pause condition' field

C.In the Dictionary entry for the Incident 'State' field

D.Within the Data Lookup Rules table for SLAs

AnswerB

The SLA Definition record exposes a dedicated Pause condition field, evaluated against the task's state, so setting it to 'Awaiting User Info' halts the resolution timer while the incident waits on the user and resumes when the state changes.

Why this answer

The pause condition for an SLA is configured on the SLA Definition record in the 'Pause condition' field, where you define the condition (e.g., State is 'Awaiting User Info') that halts the SLA timer. This field is evaluated by the SLA engine whenever the task is updated, and the timer resumes when the condition becomes false. It is not configured in workflow properties, dictionary entries, or data lookup rules.

Exam trap

The trap is placing the pause condition in workflow or dictionary configuration — candidates must remember it is a dedicated field on the SLA Definition record.

How to eliminate wrong answers

Option A is wrong because SLA Workflow properties control workflow activities and stages, not the pause condition logic — the pause condition is a field on the SLA Definition itself. Option C is wrong because the Dictionary entry for the Incident 'State' field defines field attributes (type, choices, default), not SLA pause behavior. Option D is wrong because Data Lookup Rules are used for data population and mapping, not for SLA timer pause conditions.

Full explanation →

350

Multi-Selectmedium

Which TWO factors are typically evaluated by the ServiceNow Conflict Detection engine when checking a change request? (Choose two.)

Select 2 answers

A.User password complexity and security compliance

B.Schedule overlaps with other change requests on the same CI

C.Service Catalog item fulfillment costs

D.Blackout schedules prohibiting changes during specific critical periods

E.CMDB hardware depreciation schedules

AnswersB, D

Conflict Detection compares the change's planned start and end times against other change requests targeting the same configuration item, flagging overlapping windows. This satisfies the stem by identifying schedule overlaps on shared CIs before approval.

Why this answer

The ServiceNow Conflict Detection engine evaluates whether a change request's planned window collides with other scheduled changes affecting the same configuration item, so option B (schedule overlaps with other change requests on the same CI) is correct because overlapping maintenance windows on a shared CI create operational risk. Option D (blackout schedules prohibiting changes during specific critical periods) is also correct because the engine checks the change against defined blackout/maintenance windows to prevent changes during frozen or critical business periods. Options A, C, and E are not part of conflict detection: password complexity and security compliance are handled by security/audit controls, Service Catalog fulfillment costs relate to financial/request management, and CMDB hardware depreciation is an asset-financial concept, none of which the Conflict Detection engine evaluates.

Exam trap

CIS-ITSM often tests whether candidates conflate change conflict detection with unrelated CMDB or catalog attributes — the trap is picking plausible-sounding but functionally unrelated options like depreciation or fulfillment cost.

Full explanation →

351

MCQeasy

A service desk manager wants to identify which problems are currently being investigated by the network team. Which field on the Problem record should be used to filter the list view to show only those problems?

A.Assignment group

B.Problem state

C.Configuration item

D.Assigned to

AnswerA

The Assignment group field on a Problem record indicates the team responsible for working on the problem. Filtering by 'Assignment group = Network' will show all problems currently assigned to the network team for investigation. This is the standard way to segment problems by responsible group and is used in list views, reports, and dashboards to track team workloads.

Why this answer

To filter problems by the team investigating them, the Assignment group field is the correct choice. It specifies the group responsible for the problem, allowing managers to see all problems assigned to the network team. Other fields like Assigned to, Configuration item, or Problem state do not directly indicate the responsible team and would not provide the desired list.

Exam trap

The trap here is confusing the individual assignee with the team assignment; the 'Assigned to' field is for a person, while 'Assignment group' is for the team.

Full explanation →

352

Multi-Selectmedium

Which TWO actions happen when a conflict is detected during the change scheduling process? (Choose two.)

Select 2 answers

A.Conflict status indicators provide visibility into soft or hard conflicts

B.An automated email is broadcast to all company employees

C.The configuration item is automatically retired from service

D.The change request is automatically deleted from the database

E.Conflict records are generated and displayed in the Conflicts related list

AnswersA, E

Conflict status indicators distinguish soft from hard conflicts directly on the change schedule, satisfying the requirement to surface detected clashes during scheduling. Soft conflicts flag overlaps needing review, while hard conflicts block conflicting changes outright, giving schedulers immediate visibility of the conflict type before approval proceeds.

Why this answer

Option A is correct because conflict status indicators are the mechanism that surfaces whether a detected scheduling clash is a soft conflict (a warning that can often be resolved by rescheduling) or a hard conflict (a genuine overlap that must be addressed before the change can proceed), giving change managers the visibility needed to act. Option E is correct because when the scheduling process detects a conflict, it creates conflict records that are stored and shown in the Conflicts related list on the change request, providing an auditable, actionable record of the clash. The remaining options do not belong: B is wrong because conflict detection does not trigger a company-wide email broadcast, C is wrong because a scheduling conflict never automatically retires the affected configuration item from service, and D is wrong because the change request is not deleted from the database — it is retained and flagged so the conflict can be resolved.

Exam trap

CIS-ITSM often tests whether candidates know that conflict detection produces visibility artifacts (indicators and related-list records) rather than destructive or organization-wide actions, so options implying deletion or mass notification are distractors.

Full explanation →

353

MCQmedium

A Change Manager wants to ensure that all changes hitting a specific production database CI require a Risk Assessment. Where is this association between CI classes or specific CIs and Risk Assessment criteria defined?

A.Business Service Portfolio settings

B.CI Relationship Rules

C.Risk Conditions (risk_conditions table)

D.Change Model state transition maps

AnswerC

Risk Conditions in the risk_conditions table define the criteria that trigger a Risk Assessment, and these conditions can be scoped to specific CI classes or individual CIs. Associating the production database CI with a Risk Condition ensures every change affecting it automatically requires assessment, satisfying the Change Manager's constraint.

Why this answer

Risk Conditions (the risk_conditions table) in ServiceNow Change Management define the criteria that determine when a risk assessment is required for a change. Administrators configure conditions based on CI class or specific CI, and if the change matches, a risk assessment is triggered.

Exam trap

The trap is confusing risk conditions with change models or CI relationships — candidates may pick CI Relationship Rules because it mentions CIs, but risk assessment criteria are specifically in the risk_conditions table.

How to eliminate wrong answers

Option A is wrong because Business Service Portfolio settings define business services and their relationships, not risk assessment criteria. Option B is wrong because CI Relationship Rules define how CIs relate to each other, not risk conditions. Option D is wrong because Change Model state transition maps define the states and transitions for change models, not risk assessment triggers.

Full explanation →

354

MCQhard

An enterprise requires that whenever a change request's risk is calculated as 'High', the change model automatically enforces an additional approval from the Security Operations team. How can this requirement be met?

A.Adding Security Operations as the primary assignment group

B.Writing a client script on the Risk Assessment form

C.Configuring Change Approval Policies or Approval Definitions tied to the Change Model based on risk criteria

D.Modifying the system date/time format

AnswerC

Change Approval Policies and Approval Definitions attach approval logic to a change model and can evaluate risk criteria. Binding a Security Operations approval to the High-risk condition makes the extra sign-off automatic, satisfying the requirement without manual intervention.

Why this answer

Change Approval Policies or Approval Definitions in ServiceNow allow you to define conditional approvals based on risk. By tying a policy to the Change Model and setting conditions such as risk = High, the system automatically enforces an additional approval from the Security Operations group. This is the standard, declarative way to meet the requirement without custom code.

Exam trap

The trap is thinking that any approval-related configuration (like assignment group) will automatically enforce approvals. Candidates often confuse assignment groups with approval groups, or they resort to client scripts when declarative policies are the correct tool.

How to eliminate wrong answers

Option A is wrong because adding Security Operations as the primary assignment group does not automatically enforce an additional approval; it only changes who is assigned to work on the change. Option B is wrong because a client script on the Risk Assessment form runs on the client side and is not the appropriate mechanism to enforce approval workflows; client scripts are for UI behavior, not for orchestrating approvals. Option D is wrong because modifying the system date/time format has no relevance to approval logic.

Full explanation →

355

MCQhard

A developer needs to retrieve variable values from a requested item (sc_req_item) inside a Server-side Script Include called by a catalog workflow. Which method is the most reliable way to obtain variable values on the sc_req_item record?

A.current.variable_pool[variable_name]

B.current.variables.variable_name

C.GlideSystem.getProperty('variable_name')

D.gr.getValue('variables')

AnswerB

On a requested item record, the variables object exposes catalogue item variable values directly, so current.variables.variable_name reliably returns them within a Script Include invoked by the workflow, without extra GlideRecord queries against the item option tables.

Why this answer

On an sc_req_item record, the 'variables' field is a GlideElement that exposes the variable pool as an object, so current.variables.variable_name returns the value of the named variable. This is the documented, supported API for reading catalog variables server-side and works consistently in Script Includes, Business Rules, and workflow scripts. It resolves the variable by its internal name and returns the value with the correct type.

Exam trap

The trap here is confusing the raw serialized 'variables' field (getValue) with the parsed variable object (current.variables.x), or assuming a system property or variable_pool exists — candidates who haven't worked with catalog scripting often pick the wrong accessor.

How to eliminate wrong answers

Option A is wrong because 'variable_pool' is not a valid field or property on sc_req_item — the correct container is 'variables'. Option C is wrong because GlideSystem.getProperty reads a system property (sys_properties), not a catalog variable, so it would return unrelated configuration data. Option D is wrong because gr.getValue('variables') returns the raw serialized string of the variable pool, not the parsed value of a specific variable, and is not the reliable way to obtain a single variable's value.

Full explanation →

356

MCQhard

An order guide includes three cascading catalog items. When a user submits the order guide, the values populated in the base order guide prompt variables do not pass to one of the child items. What is the most likely cause of this behavior?

A.The variable names or types between the order guide and the child catalog item do not match exactly.

B.The child catalog item has 'No cart' checked in its Web Service settings.

C.Cascade variables is disabled globally in Service Catalog properties (glide.sc.cascade).

D.The child catalog item uses a multi-row variable set which prevents cascading.

AnswerA

Order guide values propagate to child items only when variable names and types align exactly. A mismatch in either prevents the mapping, so the child receives no inherited value — the specific cause of the described failure.

Why this answer

The most likely cause is that the variable names or types between the order guide and the child catalog item do not match exactly. Order guide cascading relies on matching variable names and types to pass values from the order guide's prompt variables to the child item's variables. If they differ, the values will not populate.

Exam trap

Candidates might blame global settings or MRVS, but the most common issue is mismatched variable names/types; the exam tests attention to configuration details.

How to eliminate wrong answers

Option B is wrong because 'No cart' setting affects whether the item uses a shopping cart, not variable cascading. Option C is wrong because there is no global property 'glide.sc.cascade' that disables cascading; cascading is configured per order guide. Option D is wrong because multi-row variable sets do not inherently prevent cascading; they can be used with cascading if variables match.

Full explanation →

357

MCQeasy

An ITIL practitioner needs to view the standard baseline workflow for Problem Management in ServiceNow. Which state comes immediately after the 'Assess' state in the baseline Problem lifecycle?

A.Resolved

B.Root Cause Analysis

C.Fix In Progress

D.Review

AnswerB

ServiceNow's baseline Problem Management lifecycle flows from Assess into Root Cause Analysis, where the problem is investigated to identify underlying causes. This precedes the Fix and Review states that follow once a cause is confirmed.

Why this answer

In the ServiceNow baseline Problem Management workflow, the state sequence is New → Assess → Root Cause Analysis → Fix in Progress → Resolved → Closed. Therefore, the state immediately after 'Assess' is 'Root Cause Analysis'. This reflects the ITIL problem lifecycle where assessment is followed by investigation to determine the root cause.

Exam trap

CIS-ITSM often tests the exact order of baseline Problem states, so candidates who assume 'Fix in Progress' follows 'Assess' (skipping RCA) or who confuse the Problem lifecycle with the Incident lifecycle pick the wrong state.

How to eliminate wrong answers

Option A is wrong because 'Resolved' comes much later in the lifecycle, after the fix has been implemented and verified — it cannot immediately follow 'Assess' because no root cause has been identified yet. Option C is wrong because 'Fix in Progress' comes after 'Root Cause Analysis', not immediately after 'Assess' — you must first identify the root cause before you can implement a fix. Option D is wrong because 'Review' is not a standard baseline state in the Problem lifecycle; the baseline states are New, Assess, Root Cause Analysis, Fix in Progress, Resolved, and Closed.

Full explanation →

358

MCQeasy

Which role is required to create a new Standard Change proposal?

A.discovery_admin

B.catalogue_builder

C.itil

D.security_admin

AnswerC

The itil role grants the permissions needed to draft and submit a Standard Change proposal, satisfying the stem's requirement to create one. Standard Change proposals are authored by users holding itil, since that role carries the change-management write access, whereas non-itil roles such as sn_change_read or approver roles cannot initiate proposals.

Why this answer

The itil role is required to create a new Standard Change proposal in ServiceNow ITSM. Standard Changes are pre-approved, low-risk changes, and the itil role grants the necessary access to the Change Management application to propose them. Users without itil cannot access the change creation workflow.

Exam trap

The trap is confusing application-specific admin roles (discovery_admin, catalogue_builder, security_admin) with the process role (itil) that actually grants Change Management access — candidates pick a role that sounds administrative but is unrelated to changes.

How to eliminate wrong answers

Option A is wrong because discovery_admin is for Discovery and Service Mapping administration, unrelated to Change Management. Option B is wrong because catalogue_builder is for building service catalog items, not for creating change proposals. Option D is wrong because security_admin is for managing security ACLs and related security configuration, not for Change Management tasks.

Full explanation →

359

MCQmedium

You are tasked with configuring the Incident Priority Matrix. If an Incident has an Urgency of 2 and an Impact of 2, what is the default Priority?

A.Priority 4 - Low

B.Priority 2 - High

C.Priority 3 - Moderate

D.Priority 1 - Critical

AnswerC

With Urgency 2 and Impact 2, the matrix maps both mid-scale values to Priority 3 – Moderate, matching ServiceNow's default priority calculation. This satisfies the stem's constraint of a two-by-two mid-range intersection, where neither axis escalates severity, so no higher priority band applies.

Why this answer

In the ServiceNow Incident Priority Matrix, Priority is derived from the combination of Impact and Urgency using a default lookup table. For the intersection of Urgency = 2 and Impact = 2, the default Priority is 3 (Moderate). This follows the standard ITIL-based matrix where only combinations of high urgency and high impact yield Priority 1 or 2, while mid-range combinations produce Priority 3.

Exam trap

CIS-ITSM often tests the default Priority Matrix values, and candidates frequently confuse the combinations that yield Priority 2 versus Priority 3, especially when both Impact and Urgency are 2.

How to eliminate wrong answers

Option A is wrong because Priority 4 (Low) is typically assigned when both Impact and Urgency are 3 (or lower), not 2. Option B is wrong because Priority 2 (High) results from combinations like Impact=1 and Urgency=2, or Impact=2 and Urgency=1, not when both are 2. Option D is wrong because Priority 1 (Critical) is reserved for the highest combination: Impact=1 and Urgency=1.

Full explanation →

360

MCQmedium

When using the 'On-Hold' state, which sub-field is typically used to explain why the incident is waiting?

A.Assignment Group

B.Work Notes

C.On-Hold Reason

D.Resolution Code

AnswerC

The On-Hold Reason sub-field records the specific cause of the pause, such as awaiting a vendor or a change window, distinguishing it from the generic On-Hold state. This satisfies the stem's requirement to explain why the incident is waiting.

Why this answer

The 'On-Hold' state in ServiceNow incident management requires a mandatory sub-field called 'On-Hold Reason' to specify why the incident is paused. This field provides a structured, reportable reason (e.g., 'Awaiting Caller', 'Awaiting Change', 'Awaiting Problem') that distinguishes it from free-form notes. It ensures consistency and enables metrics like hold duration by reason.

Therefore, C is correct.

Exam trap

CIS-ITSM often tests the distinction between structured fields (like On-Hold Reason) and free-text fields (like Work Notes), so candidates may incorrectly choose Work Notes because it seems like a place to explain anything.

How to eliminate wrong answers

Option A is wrong because Assignment Group is a field that determines which team owns the incident, not why it is on hold. Option B is wrong because Work Notes are free-text updates for collaboration, not a structured sub-field for hold reasons. Option D is wrong because Resolution Code is used when resolving or closing an incident, not for explaining a hold state.

Full explanation →

361

MCQhard

A service desk manager wants to ensure that when an incident is reassigned to a different assignment group, the previous assignee is automatically cleared. Which feature should be configured to achieve this?

A.A business rule that runs before update and clears the Assigned to field if the Assignment group changes.

B.A data policy that sets the Assigned to field to mandatory when the Assignment group changes.

C.A UI policy that makes the Assigned to field read-only when the Assignment group changes.

D.A client script that clears the Assigned to field on change of the Assignment group.

AnswerA

A before update business rule can detect a change in the Assignment group field and clear the Assigned to field. This ensures that when the group changes, the previous assignee is removed, preventing misassignment. Business rules are the appropriate tool for enforcing such data integrity logic on the server side.

Why this answer

To automatically clear the Assigned to field when the Assignment group changes, a before update business rule is the correct solution. It runs on the server, ensuring consistency regardless of how the update is made. UI policies and client scripts only affect the client side and do not guarantee data integrity.

Exam trap

The trap here is thinking that a UI policy or client script can enforce automatic field clearing, but they are client-side and not reliable for all update paths.

Full explanation →

362

MCQhard

A custom Service Catalog workflow encounters an error where a 'Run Script' activity fails to complete because it attempts to query the sc_cart table instead of the requested item. What is the proper table object to query for submitted request items within a workflow?

A.sc_cart

B.sys_user_has_role

C.sc_req_item

D.sc_request

AnswerC

The sc_req_item table stores individual requested items generated from a submitted request, so a workflow querying it retrieves the correct catalogue item records. The sc_cart table holds pre-submission shopping cart contents, which is why that query fails to return the submitted items.

Why this answer

The sc_req_item table (Requested Item) is the correct table to query for individual submitted request items within a workflow. Each requested item represents a line item in a request and contains the catalog item details and variables.

Exam trap

The trap is confusing the shopping cart table (sc_cart) with the submitted requested item table (sc_req_item), so candidates must remember that sc_cart is transient and not used in workflows.

How to eliminate wrong answers

Option A is wrong because sc_cart is a temporary table used for the shopping cart before submission; it is not used for submitted request items. Option B is wrong because sys_user_has_role is a table storing user role assignments, unrelated to request items. Option D is wrong because sc_request is the parent request record that can contain multiple requested items; querying it would not give individual item details.

Full explanation →

363

MCQhard

A Problem Coordinator wants to create a Problem record from an existing Incident. By default, which UI Action on the Incident form initiates this relationship and populates related fields?

A.Associate to Problem

B.Create Major Incident

C.Create Problem

D.Promote to Problem

AnswerC

The Create Problem UI Action on the Incident form spawns a new Problem record and copies the Incident's details into related fields, establishing the default association. This is the out-of-box mechanism linking an Incident to Problem Management without manual re-entry.

Why this answer

The 'Create Problem' UI Action on the Incident form is the default action that creates a new Problem record and populates related fields such as the short description and links the originating incident. This establishes the Problem-Incident relationship out of the box. It is the standard mechanism a Problem Coordinator uses to initiate problem management from an incident.

Exam trap

CIS-ITSM often tests the exact UI Action name, catching candidates who confuse 'Create Problem' with 'Promote to Problem' or 'Associate to Problem'.

How to eliminate wrong answers

Option A is wrong because 'Associate to Problem' is not a default UI Action on the Incident form; association is typically done from the Problem side or via related lists, not as a creation action. Option B is wrong because 'Create Major Incident' promotes the incident to a major incident, which is an incident management escalation, not a problem creation action. Option D is wrong because 'Promote to Problem' is not the default UI Action name in ServiceNow; the base system uses 'Create Problem'.

Full explanation →

364

MCQeasy

What is the primary function of the 'Review' state in the change lifecycle?

A.Conducting Post Implementation Review (PIR) and assessing success

B.Approving standard change proposals

C.Running automated risk assessments

D.Performing initial conflict detection checks

AnswerA

The Review state exists to conduct the Post Implementation Review, confirming the change achieved its objective and assessing success before closure. It sits after implementation, so the change record is evaluated for effectiveness rather than being actively deployed or authorised.

Why this answer

The 'Review' state in the change lifecycle is used to conduct the Post Implementation Review (PIR) after a change has been implemented. During this state, the change manager and stakeholders assess whether the change was successful, if it met its objectives, and if any follow-up actions are needed. This is a distinct phase that occurs after implementation and before closure.

Exam trap

CIS-ITSM often tests the sequence of change states, and candidates may confuse 'Review' with 'Authorize' or 'Assess', incorrectly associating it with approval or risk assessment rather than post-implementation evaluation.

How to eliminate wrong answers

Option B is wrong because approving standard change proposals occurs during the 'Authorize' or 'Approve' state, not 'Review'. Option C is wrong because automated risk assessments are typically run during the 'Assess' state or when the change is created. Option D is wrong because initial conflict detection checks are performed during the 'Assess' or 'Authorize' states, not during 'Review'.

Full explanation →

365

Multi-Selecteasy

Which TWO of the following are primary benefits of utilizing Standard Changes in ServiceNow? (Choose two.)

Select 2 answers

A.They require mandatory manual risk assessment questionnaires for every execution

B.They automatically trigger emergency incident swarming

C.They bypass traditional CAB approval because they are pre-approved

D.They are designed for major, high-risk infrastructure overhauls

E.They provide a repeatable, consistent method for implementing frequent, low-risk changes

AnswersC, E

Standard Changes carry pre-authorised approval, so they skip the traditional CAB review that normal and emergency changes require. This satisfies the stem by removing the approval bottleneck for frequent, low-risk work already vetted through the change model.

Why this answer

Option C is correct because Standard Changes are pre-approved by the Change Management process, so they do not require individual CAB review or approval each time they are executed, which speeds up delivery. Option E is correct because Standard Changes follow a documented, repeatable procedure for frequent, low-risk changes, ensuring consistency and reducing administrative overhead. Option A is incorrect because Standard Changes are low-risk and pre-authorized, so mandatory manual risk assessment questionnaires for every execution are not a primary benefit and would defeat their purpose.

Option B is incorrect because emergency incident swarming is associated with major incidents or emergency changes, not routine Standard Changes. Option D is incorrect because Standard Changes are intended for low-risk, routine changes, whereas major, high-risk infrastructure overhauls would typically follow Normal or Emergency Change processes.

Exam trap

The trap is assuming Standard Changes still require per-execution risk assessment or CAB approval, when their defining feature is pre-approval and repeatability for low-risk work.

Full explanation →

366

MCQhard

An enterprise organization requires that when a Major Incident Candidate is promoted to a Major Incident, a dedicated Major Incident workspace opens automatically, and specific child incidents are automatically associated. Which plugin must be activated to utilize the formal Major Incident Management workbench and associated workflows in ITSM?

A.com.snc.incident.mim

B.com.snc.problem.mim

C.com.snc.itsm.major_incident

D.com.snc.incident_management.advanced

AnswerA

The com.snc.incident.mim plugin activates the Major Incident Management workbench, which delivers the dedicated workspace and automated child-incident association workflows. Without it, promoting a Major Incident Candidate cannot trigger the formal MIM process the organisation requires.

Why this answer

The plugin com.snc.incident.mim is the official ServiceNow plugin that activates the Major Incident Management (MIM) workbench. It provides the dedicated Major Incident workspace, the promotion of Major Incident Candidates to Major Incidents, and the automatic association of child incidents. This plugin is specifically designed for the formal MIM workflows within ITSM.

Exam trap

CIS-ITSM often tests the exact plugin name for Major Incident Management, and candidates may confuse it with non-existent or similarly named plugins like com.snc.itsm.major_incident or com.snc.incident_management.advanced.

How to eliminate wrong answers

Option B is wrong because com.snc.problem.mim does not exist; the correct plugin for problem management is com.snc.problem, and there is no MIM-specific problem plugin. Option C is wrong because com.snc.itsm.major_incident is not a valid ServiceNow plugin; the correct plugin name follows the pattern com.snc.incident.mim. Option D is wrong because com.snc.incident_management.advanced is not a real plugin; advanced incident management features are part of other plugins like com.snc.incident or com.snc.incident.mim.

Full explanation →

367

Multi-Selecteasy

Which TWO actions can a Catalog UI Policy perform on catalog item variables without writing code? (Choose two.)

Select 2 answers

A.Make variables mandatory or optional

B.Automatically compile Java source code

C.Delete user profile records

D.Create new database tables

E.Make variables visible or hidden

AnswersA, E

Catalog UI Policies can dynamically set variables to mandatory or optional.

Why this answer

Catalog UI Policies are no-code configuration records in ServiceNow that dynamically control the behavior of catalog item variables on the form. Option A is correct because a Catalog UI Policy can set a variable's Mandatory field to true or false, forcing or removing the requirement that the user supply a value before submission. Option E is correct because the same policy can toggle a variable's Visible field, showing or hiding it based on conditions such as the value of another variable.

The remaining options are incorrect: compiling Java source code (B) is a development activity unrelated to UI policies, deleting user profile records (C) is a data operation performed by users or scripts, and creating new database tables (D) is a schema change done through table administration, none of which a Catalog UI Policy can do.

Exam trap

CIS-ITSM often tests the boundary between no-code UI Policies and code-required Client Scripts, so candidates who think any dynamic behavior needs JavaScript pick wrong options.

Full explanation →

368

MCQmedium

An administrator is configuring a Record Producer that allows end users to submit a Facilities request. Which table should be selected as the target table for this record producer?

A.Cart [sc_cart]

B.Catalog Item [sc_cat_item]

C.Requested Item [sc_req_item]

D.Target functional table (e.g., Facilities [x_facilities_task])

AnswerD

A Record Producer must target a functional table that stores the resulting records, such as a custom Facilities task table. Selecting the functional table ensures submitted requests create properly structured task records rather than landing on an unrelated or non-task table.

Why this answer

A Record Producer's purpose is to create records directly on a target functional table (like Facilities [x_facilities_task]) rather than going through the standard catalog request/requested-item flow. The target table field on the Record Producer determines which table the submitted record is inserted into, so for a Facilities request the correct target is the Facilities task table.

Exam trap

The trap here is confusing the Record Producer's target table with the catalog infrastructure tables (sc_cart, sc_cat_item, sc_req_item) that standard catalog items use — candidates must remember Record Producers write directly to a functional table.

How to eliminate wrong answers

Option A is wrong because Cart [sc_cart] is a transient staging table for catalog checkout, not a destination for record producer output. Option B is wrong because Catalog Item [sc_cat_item] defines the catalog entry itself, not the record produced when a user submits the producer. Option C is wrong because Requested Item [sc_req_item] is used by standard catalog items to track fulfillment, but Record Producers bypass this and write directly to a functional table.

Full explanation →

369

MCQhard

A company has a requirement that when a Problem is created from an incident, all attachments on the incident must be automatically copied over to the new Problem record. Which ServiceNow feature facilitates attachment copying between related tasks?

A.Knowledge Base attachment synchronization rules

B.UI Policy attachment actions

C.Sys_attachment glide utility methods triggered via Business Rule or script

D.Data Lookup definitions for binary streams

AnswerC

The sys_attachment GlideRecord API lets a script copy attachment records by re-pointing their table_sys_id to the new Problem, satisfying the requirement that all incident attachments transfer automatically. A Business Rule on Problem insert can invoke this, since ServiceNow stores attachments as records rather than embedded files.

Why this answer

ServiceNow does not provide a native declarative 'copy attachments' feature for related records; attachment copying must be scripted. The GlideSysAttachment API (e.g., copy() or write()) invoked from a Business Rule on the Incident-to-Problem creation event is the correct approach. This allows the script to read all attachments on the source incident and write them to the newly created problem record.

Exam trap

The trap here is assuming ServiceNow has a built-in declarative attachment-copy feature like it does for field values; candidates who haven't scripted attachments often pick UI Policy or Data Lookup options that sound plausible but cannot handle binary data.

How to eliminate wrong answers

Option A is wrong because Knowledge Base attachment synchronization rules govern KB article attachments, not task-to-task copying. Option B is wrong because UI Policies only manipulate form field behavior client-side and cannot move binary attachment data between records. Option D is wrong because Data Lookup definitions map reference field values, not binary attachment streams — there is no 'binary stream' lookup type in ServiceNow.

Full explanation →

370

MCQeasy

Which ServiceNow table stores CAB meeting records?

A.sys_user_group

B.wm_meeting

C.std_change_proposal

D.change_request

AnswerB

CAB meeting records are stored in the wm_meeting table, which underpins the CAB Workbench. This satisfies the stem's requirement for the specific table holding meeting data, distinct from change_request or task tables that hold the changes themselves.

Why this answer

The ServiceNow table that stores CAB meeting records is wm_meeting. This table is part of the Change Management application and is specifically designed to hold meeting details such as agenda, attendees, and minutes for Change Advisory Board (CAB) meetings. It is distinct from tables that store user groups, change proposals, or change requests.

Exam trap

CIS-ITSM often tests the distinction between tables that store configuration items versus those that store process records, and candidates may confuse CAB meeting records with change request records or user groups.

How to eliminate wrong answers

Option A is wrong because sys_user_group stores user group definitions (e.g., CAB groups) but not meeting records. Option C is wrong because std_change_proposal stores standard change proposal templates, not meeting records. Option D is wrong because change_request stores individual change requests, not CAB meeting records.

Full explanation →

371

MCQmedium

An administrator wants to hide a variable set on a catalog item form when a checkbox variable is unchecked. Where should this behavior be configured?

A.Catalog UI Policy

B.Catalog Client Script (onLoad)

C.Workflow properties

D.Order Guide Rule Base

AnswerA

Catalog UI Policies control field visibility, mandatory and read-only behaviour on catalog item forms, driven by conditions on other variables. A policy with the condition that the checkbox is false, and an action setting the variable set to not visible, hides it dynamically without scripting.

Why this answer

A Catalog UI Policy is the correct mechanism to hide a variable set when a checkbox variable is unchecked. UI Policies provide declarative, no-code control over field visibility, mandatory, and read-only states on catalog forms, and they support conditions based on other variables. The policy's action would target the variable set (or its contained variables) and set 'Visible = false' when the checkbox is false.

Exam trap

The trap is choosing a client script because it feels more flexible — candidates often overlook that UI Policies are the declarative, supported way to hide fields based on other field values, and client scripts are reserved for logic UI Policies cannot express.

How to eliminate wrong answers

Option B is wrong because a Catalog Client Script (onLoad) runs only once when the form loads and does not automatically re-evaluate when the checkbox changes — you would need an OnChange script instead, and even then UI Policy is the declarative best practice. Option C is wrong because workflow properties control fulfillment behavior after submission, not form field visibility during ordering. Option D is wrong because 'Order Guide Rule Base' is not a standard ServiceNow configuration for hiding variables on a catalog item form — order guides have their own inclusion rules, but they govern which items appear in the guide, not variable visibility within an item.

Full explanation →

372

MCQhard

A Problem record is linked to multiple incidents. When the Problem is resolved, a custom requirement dictates that an email notification must be sent to the callers of all associated active incidents. Which ServiceNow component is best suited to trigger this efficiently?

A.A Business Rule on the Problem table that fires an event for each related active incident

B.A Client Script utilizing GlideAjax to send emails synchronously

C.A Record Producer attached to the Incident table

D.An Email Client Template configured on the Problem form

AnswerA

A Business Rule on the Problem table can query related active incidents and fire a dedicated event per incident, letting the notification engine handle delivery. This satisfies the custom requirement to email every affected caller efficiently without manual intervention or per-incident scripting.

Why this answer

A Business Rule on the Problem table can execute server-side logic when the Problem is resolved. It can query all related active incidents and fire an event for each, which the notification engine then processes to send emails. This is efficient because it leverages ServiceNow's event queue and notification framework, avoiding synchronous email sending and ensuring scalability.

Exam trap

CIS-ITSM often tests the misconception that client-side scripts or email templates can directly trigger notifications, when in fact server-side Business Rules and events are the correct approach for efficient, scalable notifications.

How to eliminate wrong answers

Option B is wrong because Client Scripts run in the browser and GlideAjax is used for asynchronous server calls, but sending emails synchronously from a client script is not efficient, can cause performance issues, and is not the intended use of client scripts. Option C is wrong because a Record Producer is used to create records via a catalog interface, not to trigger notifications on existing records. Option D is wrong because an Email Client Template is a template for composing emails, not a mechanism to trigger notifications; it must be used within a notification or mail script.

Full explanation →

ServiceNow Certified Implementation Specialist - IT Service Management (CIS-ITSM) (CIS-ITSM) (CIS-ITSM) — Questions 301–372