CCNA Incident Management Questions — Page 1 of 2

MCQhard

An administrator is configuring SLA Definitions for Incident Management. They need the SLA timer to pause whenever an incident is placed in the 'Awaiting Vendor' state. How should this be configured?

A.Set the Pause condition to State is Awaiting Vendor.

B.Modify the Incident workflow to suspend timers.

C.Set the Stop condition to State is Awaiting Vendor.

D.Create a Business Rule to pause task_sla records.

AnswerA

Setting the Pause condition to State is Awaiting Vendor stops the SLA timer whenever the incident enters that state, so vendor wait time is excluded from the resolution target. The timer resumes automatically once the state changes, satisfying the requirement.

Why this answer

In ServiceNow SLA Definitions, the Pause condition is the field that determines when an SLA timer stops counting. Setting the Pause condition to 'State is Awaiting Vendor' makes the timer pause as soon as the incident enters that state and resume when it leaves. This is the native, supported configuration and does not require custom scripting.

Exam trap

CIS-ITSM often tests the confusion between Pause and Stop conditions — candidates incorrectly select Stop when the requirement is to temporarily halt the timer, which would instead terminate the SLA.

How to eliminate wrong answers

Option B is wrong because modifying the Incident workflow to suspend timers is a custom workaround that bypasses the SLA engine and is not the recommended configuration; it also risks breaking other SLAs. Option C is wrong because the Stop condition ends the SLA entirely (marking it as met or breached), not pauses it — using Stop would incorrectly close the SLA when the incident is merely waiting on a vendor. Option D is wrong because a Business Rule that pauses task_sla records is a custom scripted approach; the platform already provides a declarative Pause condition field, so scripting is unnecessary and harder to maintain.

Practice this question →

MCQmedium

When using 'Incident Communication Plans', what happens when a major incident is updated?

A.The incident priority is automatically increased.

B.Notifications are sent to defined stakeholders.

C.All child incidents are immediately resolved.

D.The incident is automatically assigned to the Major Incident Manager.

AnswerB

Incident Communication Plans define stakeholder groups and notification templates, so updating a major incident automatically triggers notifications to those defined recipients. This satisfies the stem's requirement that communication occurs on update, ensuring affected users and resolver groups receive timely status information without manual intervention.

Why this answer

Incident Communication Plans in ServiceNow are designed to automate stakeholder notifications based on incident state changes or updates. When a major incident is updated, the plan triggers and sends notifications to the predefined stakeholders (e.g., affected users, management, support teams) according to the configured communication channels and templates. This ensures timely and consistent information dissemination during critical events.

Exam trap

CIS-ITSM often tests the misconception that communication plans perform actions beyond notifications, such as changing priority or assignment, when in fact they are strictly for stakeholder communication.

How to eliminate wrong answers

Option A is wrong because Incident Communication Plans do not modify incident priority; priority is typically set manually or via business rules, not by communication plans. Option C is wrong because resolving child incidents is not an automatic function of communication plans; child incidents must be resolved individually based on their own lifecycle. Option D is wrong because assignment to a Major Incident Manager is handled by assignment rules or workflows, not by communication plans, which focus solely on notifications.

Practice this question →

Multi-Selectmedium

Which THREE fields are auto-populated when an incident is created via email?

Select 3 answers

A.Priority

B.Description

C.Short Description

D.SLA

E.Caller

AnswersB, C, E

Inbound email parsing maps the message body directly into the Description field, satisfying the auto-population requirement for incidents created via email. The subject line populates Short description, while the sender's address resolves to the Caller, so Description correctly captures the remaining content without manual entry.

Why this answer

When an incident is created via email, the email body is auto-populated into the Description field (B), since the message content becomes the detailed incident text. The email subject line is auto-populated into the Short Description field (C), providing the incident's summary/title. The sender's email address is matched against user records to auto-populate the Caller field (E), identifying who reported the incident.

Priority (A) is not auto-populated from email because it is typically assigned by the system based on impact/urgency rules or set manually, and SLA (D) is not a field populated at creation but rather a derived/attached record calculated from the assignment and priority, so neither belongs among the auto-populated fields.

Exam trap

CIS-ITSM often tests the assumption that Priority or SLA are auto-populated from email, when in fact only content-derived fields (Description, Short Description) and identity-derived fields (Caller) are populated automatically.

Practice this question →

MCQeasy

An ITIL user complains they cannot see the 'Major Incident' tab on an incident record. What is the most likely cause?

A.The user does not have the 'itil' role.

B.The incident is not in the 'In Progress' state.

C.The 'Major Incident Management' plugin is not active.

D.The user needs to be a member of the 'Major Incident Management' group.

AnswerC

The Major Incident tab is rendered by the Major Incident Management plugin, which extends the Incident form. Without it active, the tab and its related UI actions are absent, so the user cannot see or manage major incidents.

Why this answer

The 'Major Incident' tab on an incident record is added by the Major Incident Management (MIM) plugin. If the plugin is not active, the tab and its related UI actions, fields, and workflows are not present on the form. Without the plugin, even users with the correct roles and group memberships will not see the tab.

Therefore, the most likely cause is that the plugin is not active.

Exam trap

CIS-ITSM often tests the misconception that user roles or group memberships control the visibility of plugin-specific UI elements, when in fact the plugin must be active first.

How to eliminate wrong answers

Option A is wrong because the 'itil' role is a standard role that grants access to incident management, but it does not control the visibility of the 'Major Incident' tab; that tab is plugin-dependent. Option B is wrong because the incident state does not determine the presence of the tab; the tab is available regardless of state if the plugin is active and the user has the necessary roles. Option D is wrong because group membership may affect access to certain features, but the tab itself is added by the plugin and is not hidden solely based on group membership; the plugin must be active first.

Practice this question →

MCQmedium

A support agent needs to create a Problem record directly from an existing Incident while preserving the correlation between the two. Which related link or UI action should the agent use on the Incident form?

A.Create Knowledge

B.Create Problem

C.Create Change Request

D.Create Major Incident

AnswerB

The Create Problem UI action on an Incident form generates a new Problem record and automatically links it back to the originating Incident. This preserves the correlation between the two records, which is exactly what the support agent requires.

Why this answer

The 'Create Problem' UI action on the Incident form creates a new Problem record and automatically establishes the Problem-to-Incident relationship, preserving correlation for root cause analysis. This is the standard ServiceNow flow for elevating recurring or high-impact incidents into problem management.

Exam trap

CIS-ITSM often tests whether candidates confuse 'Create Problem' (root cause record with incident correlation) with 'Create Major Incident' (escalation of the same incident) or 'Create Change Request' (fix implementation), so any option that creates a different record type is a distractor.

How to eliminate wrong answers

Option A is wrong because 'Create Knowledge' generates a knowledge article from the incident — it does not create a Problem record or preserve problem-incident correlation. Option C is wrong because 'Create Change Request' spawns a change record for implementing a fix, not a Problem record for root cause investigation. Option D is wrong because 'Create Major Incident' promotes the incident itself to major incident status; it does not create a Problem record or link one.

Practice this question →

MCQmedium

An incident is currently in the 'Resolved' state. A user calls the service desk to report that the issue is still occurring. The agent needs to reopen the incident. Which action should the agent take?

A.Click the 'Reopen Incident' UI action button.

B.Create a new incident and reference the original incident number in the description.

C.Change the State to 'In Progress' and update the incident.

D.Change the State to 'Closed' and then back to 'In Progress'.

AnswerA

The 'Reopen Incident' UI action is designed to transition an incident from Resolved to In Progress or New, while clearing resolution fields. It ensures proper state transition and data consistency. This is the recommended method for reopening a resolved incident.

Why this answer

The correct way to reopen a resolved incident is to use the 'Reopen Incident' UI action. It properly transitions the state and clears resolution details, maintaining data integrity. Manually changing states or creating new incidents is not recommended.

Exam trap

The trap here is assuming that simply changing the State field to 'In Progress' is sufficient, but the dedicated UI action ensures proper handling of related fields.

Practice this question →

MCQmedium

A company requires that when an incident is assigned to a specific group, the 'Assigned to' field must be mandatory. Which configuration change accomplishes this using the most efficient ServiceNow best practice?

A.Modify the dictionary entry for the 'Assigned to' field to be mandatory.

B.Write an OnChange Client Script on the assignment group field to set the field mandatory.

C.Create a Data Policy with the condition set to the assignment group.

D.Create a UI Policy with the condition 'Assignment group is [Group Name]' and 'Mandatory' set to true for the 'Assigned to' field.

AnswerD

A UI Policy dynamically sets the 'Assigned to' field to mandatory only when the assignment group matches the specified group, meeting the conditional requirement without scripting. This is the most efficient ServiceNow best practice, since client-side policies avoid server-side business rule overhead.

Why this answer

A UI Policy with the condition 'Assignment group is [Group Name]' and 'Mandatory' set to true for the 'Assigned to' field is the most efficient best practice because UI Policies are declarative, client-side, and require no scripting. They dynamically enforce mandatory behavior only when the condition is met, and they are easy to maintain and audit.

Exam trap

CIS-ITSM often tests whether candidates know that UI Policies are the best practice for conditional form behavior, while Data Policies are for server-side data integrity — the trap is picking a Data Policy or Client Script when the requirement is purely UI-driven.

How to eliminate wrong answers

Option A is wrong because making the dictionary entry mandatory would require 'Assigned to' on every incident regardless of assignment group, which is too broad and breaks the conditional requirement. Option B is wrong because an OnChange Client Script requires custom JavaScript, is harder to maintain, and is not the recommended best practice when a declarative UI Policy can achieve the same result. Option C is wrong because a Data Policy is server-side and enforces data integrity on the database, but it is not the most efficient for a UI-driven conditional mandatory requirement, and it would also block API/import updates that may legitimately omit the field.

Practice this question →

Multi-Selectmedium

Which TWO fields are commonly used to categorize an incident?

Select 2 answers

A.SLA Definition

B.Resolution Code

C.Category

D.Subcategory

E.Assignment Group

AnswersC, D

Category records the high-level service type an incident relates to, such as hardware, software or network, driving routing and reporting. It satisfies the stem's categorisation requirement by classifying the incident at the top tier of the taxonomy, beneath which subcategory provides finer granularity.

Why this answer

Category (C) is correct because it is the primary classification field used to group incidents into broad types such as hardware, software, or network, enabling reporting and routing. Subcategory (D) is correct because it refines the Category into a more specific classification (for example, under Hardware: Printer or Laptop), which is the standard two-level categorization model in ITSM tools like ServiceNow. Together, Category and Subcategory are the fields commonly used to categorize an incident.

SLA Definition (A) defines the service-level target applied to the ticket, not its classification. Resolution Code (B) records how the incident was resolved and is used for closure analysis, not categorization. Assignment Group (E) identifies the team responsible for working the incident, which is routing/ownership rather than categorization.

Exam trap

CIS-ITSM often tests the distinction between categorization fields (Category/Subcategory) and process fields (SLA, Resolution Code, Assignment Group), and candidates pick fields that sound related but serve a different function.

Practice this question →

MCQmedium

What happens when an incident 'Priority' is changed from 3 to 1?

A.SLA target dates are recalculated

B.The incident is deleted

C.The caller is notified via email

D.The incident is automatically closed

AnswerA

Priority drives the SLA definition attached to the incident, so changing it from 3 to 1 rebinds the record to the more stringent priority-1 SLA and recalculates the target dates from the incident's start time. The original breach or resolution deadlines no longer apply.

Why this answer

When an incident's Priority is changed from 3 to 1, the SLA target dates are recalculated based on the new priority's SLA definitions. This is because SLAs are attached based on priority, and a change in priority triggers the SLA engine to re-evaluate and adjust the target times for response and resolution.

Exam trap

CIS-ITSM often tests the automatic recalculation of SLA targets when priority changes; candidates may think the caller is notified or that the incident is escalated, but the primary effect is SLA recalculation.

How to eliminate wrong answers

Option B is wrong because changing priority does not delete the incident; deletion is a separate action. Option C is wrong because the caller is not automatically notified via email just by changing priority; notifications are triggered by specific events or business rules. Option D is wrong because the incident is not automatically closed; closure requires resolution and user action.

Practice this question →

MCQmedium

Which feature allows an agent to create a knowledge article directly from an Incident?

A.Create Knowledge UI Action

B.Incident Template

C.Import Set

D.Knowledge Management Plugin

AnswerA

The Create Knowledge UI Action on the Incident form launches article creation with fields pre-populated from the incident record, letting agents capture resolution details without leaving the record. This directly satisfies the requirement to generate a knowledge article from an incident.

Why this answer

The 'Create Knowledge' UI Action on the Incident form allows an agent to generate a knowledge article pre-populated with incident details such as short description, description, and resolution notes. This native UI Action streamlines the knowledge creation process directly from the incident context.

Exam trap

CIS-ITSM often tests whether candidates confuse enabling features (like the Knowledge Management Plugin) with the actual UI Action that performs the creation — the trap is picking the plugin instead of the UI Action.

How to eliminate wrong answers

Option B is wrong because Incident Templates pre-fill incident fields for new incidents — they do not create knowledge articles. Option C is wrong because Import Sets are used to bring external data into ServiceNow tables via transform maps, not to author knowledge articles. Option D is wrong because the Knowledge Management Plugin enables the knowledge base functionality itself; it is a prerequisite, not the feature that lets an agent create an article from an incident.

Practice this question →

MCQeasy

When viewing an Incident record, where can an agent see a chronological audit trail of all field updates, comments, and work notes added by users and system processes?

A.Dictionary Entries

B.System Log

C.Activity Stream (Form Stream)

D.Related Links

AnswerC

The Activity Stream (Form Stream) renders the record's sys_journal_field entries chronologically, combining field-level audit records with comments and work notes in one timeline. This satisfies the requirement to see all user and system updates without querying the audit table separately.

Why this answer

The Activity Stream (also known as Form Stream) on an Incident record displays a chronological audit trail of all field updates, comments, and work notes added by users and system processes. It provides a consolidated view of the record's history. The other options do not provide this functionality.

Exam trap

CIS-ITSM often tests where to find specific information on a form. Candidates might confuse the Activity Stream with System Logs or Dictionary Entries, especially if they are not familiar with the ServiceNow interface.

How to eliminate wrong answers

Option A is wrong because Dictionary Entries define the schema and properties of tables and fields, not the audit trail of a specific record. Option B is wrong because System Log contains system-level logs for debugging and monitoring, not per-record activity. Option D is wrong because Related Links are links to other records or resources, not a chronological history of changes.

Practice this question →

MCQmedium

Which field on the Incident form is calculated automatically based on the 'Impact' and 'Urgency' fields using the Priority Lookup Rules?

A.Impact

B.SLA

C.Severity

D.Priority

AnswerD

Priority is derived automatically by the Priority Lookup Rules, which map the combination of Impact and Urgency values to a priority level. Administrators therefore never set it manually on the Incident form, keeping prioritisation consistent across all records.

Why this answer

On the Incident form in ServiceNow, the Priority field is automatically calculated based on the Impact and Urgency fields using Priority Lookup Rules. These rules map combinations of Impact and Urgency to a specific Priority value (e.g., Impact=1 and Urgency=1 yields Priority=1).

Exam trap

CIS-ITSM often tests the relationship between Impact, Urgency, and Priority; candidates may incorrectly think that Priority is manually set or that Severity is the calculated field, but Priority is the one derived from the lookup rules.

How to eliminate wrong answers

Option A is wrong because Impact is a manually entered or derived field, not calculated from Urgency. Option B is wrong because SLA is not a field on the Incident form; it is a separate table and process that tracks service level agreements. Option C is wrong because Severity is not a standard field on the Incident form in ServiceNow; it is sometimes used in other modules but not calculated from Impact and Urgency.

Practice this question →

MCQhard

When configuring Assignment Rules for incidents, what occurs if multiple assignment rules match the criteria of an incoming or updated incident record?

A.The rule with the highest Order value takes precedence.

B.All matching assignment rules execute sequentially, overwriting the assignment group.

C.An error is logged indicating conflicting assignment parameters.

D.The rule with the lowest Order value executes first, and evaluation stops.

AnswerD

Assignment rules use the Order field to establish precedence, so the lowest Order value executes first and evaluation halts, preventing later rules from overriding it. This satisfies the stem's requirement for deterministic behaviour when multiple rules match, ensuring a single predictable assignment outcome rather than conflicting execution.

Why this answer

ServiceNow evaluates assignment rules in ascending Order value; the first matching rule (lowest Order) executes and evaluation stops, so only one assignment rule applies per incident. This deterministic behavior prevents conflicting assignments and ensures a predictable ownership outcome. Higher Order values act as fallbacks only when lower-Order rules do not match.

Exam trap

The trap here is confusing 'Order' semantics — candidates often assume higher Order means higher priority, when in ServiceNow lower Order executes first and stops evaluation.

How to eliminate wrong answers

Option A is wrong because a higher Order value does not take precedence — ServiceNow processes rules from lowest to highest Order, and the first match wins. Option B is wrong because matching rules do not all execute sequentially; evaluation halts at the first match, so no overwriting occurs. Option C is wrong because multiple matches are not treated as an error — the Order field is specifically designed to resolve them deterministically.

Practice this question →

MCQmedium

What is the purpose of the 'Incident Task' table?

A.To replace the Incident table

B.To store SLA definitions

C.To act as a parent for multiple incidents

D.To break down a complex incident into smaller tasks

AnswerD

The Incident Task table decomposes a complex incident into discrete, assignable child tasks, each with its own state, assignment group and owner. This satisfies the stem's requirement to manage multi-step resolution work that a single incident record cannot track, enabling parallel effort and clearer accountability across resolving teams.

Why this answer

The Incident Task table in ServiceNow is used to break down a complex incident into smaller, assignable tasks. It allows multiple people or groups to work on different parts of a large incident, providing granular tracking and assignment.

Exam trap

CIS-ITSM often tests the confusion between Incident Task and other task types (Problem Task, Change Task), or the misconception that Incident Task is a parent rather than a child of Incident.

How to eliminate wrong answers

Option A is wrong because Incident Task does not replace the Incident table; it is a child table that extends Task and is related to Incident. Option B is wrong because SLA definitions are stored in the SLA table and related contract tables, not Incident Task. Option C is wrong because Incident Task is not a parent for multiple incidents; it is a child of a single incident, used to decompose work.

Practice this question →

MCQmedium

An organization requires that when an Incident priority is set to '1 - Critical', a 'Major Incident' candidate record is created. What is the best practice approach?

A.Create a Business Rule on the Incident table

B.Use a Client Script to trigger a workflow

C.Update the Incident Priority Lookup table

D.Enable the Major Incident Management plugin and configure 'Major Incident Trigger Rules'

AnswerD

The Major Incident Management plugin provides purpose-built trigger rules that automatically create a Major Incident candidate when priority reaches '1 - Critical'. This is native, supported functionality, avoiding brittle custom business rules or workflows that are harder to maintain and upgrade.

Why this answer

The best practice is to enable the Major Incident Management plugin and configure 'Major Incident Trigger Rules'. This approach leverages out-of-the-box functionality designed specifically for creating major incident candidate records based on conditions like priority. It ensures consistency and integrates with the major incident management process, including communication and escalation.

Exam trap

CIS-ITSM often tests whether candidates know to use the built-in Major Incident Management plugin rather than custom scripting, as custom solutions may miss integration points and best practices.

How to eliminate wrong answers

Option A is wrong because creating a custom Business Rule on the Incident table would require custom development and may not integrate with the full major incident management lifecycle. Option B is wrong because Client Scripts run on the client side and are not suitable for triggering server-side record creation. Option C is wrong because the Incident Priority Lookup table defines priority values, not major incident triggers.

Practice this question →

MCQeasy

What is the primary function of the 'Knowledge' icon on an incident form?

A.To search for knowledge articles related to the incident.

B.To email the knowledge base team.

C.To archive the incident.

D.To create a new knowledge article from the incident.

AnswerA

The Knowledge icon opens a search pane that queries the knowledge base for articles matching the incident's short description, category, or CI, surfacing relevant resolutions without leaving the form. This satisfies the requirement to find related articles directly from the incident record.

Why this answer

The 'Knowledge' icon on an incident form opens a knowledge search interface that automatically queries the knowledge base using the incident's short description and other fields. This allows agents to quickly find relevant articles to resolve the incident without leaving the form. It does not create or email anything by default.

Exam trap

CIS-ITSM often tests the difference between searching and creating knowledge; candidates may assume the icon creates an article because it's on the incident form, but creation is a separate action.

How to eliminate wrong answers

Option B is wrong because the icon does not email the knowledge base team; that would require a notification or workflow, not a search icon. Option C is wrong because archiving an incident is unrelated to knowledge search and is typically done via a state change or archive rule. Option D is wrong because creating a new knowledge article is a separate action, often available via a different link or button, not the search icon.

Practice this question →

MCQmedium

A user reports that they cannot see the 'Create Problem' UI Action on the Incident form. What is the most likely cause?

A.The user lacks the 'problem_admin' role.

B.The Incident is already linked to a Problem.

C.The UI Action is disabled in the UI Action Properties.

D.The UI Action Condition field evaluates to false.

AnswerD

UI Actions appear only when their Condition field evaluates true against the current record. If that condition returns false, ServiceNow hides the action, which directly explains why the user cannot see 'Create Problem' on the Incident form.

Why this answer

UI Actions in ServiceNow have a 'Condition' field that determines when the action is visible. If the condition evaluates to false, the UI Action will not appear. The most likely cause is that the condition is not met for the current user or incident state.

Exam trap

CIS-ITSM often tests the misconception that missing UI Actions are due to disabled actions or roles, but the condition field is the most common cause of visibility issues.

How to eliminate wrong answers

Option A is wrong because lacking 'problem_admin' role might affect access, but the UI Action condition is more specific; if the condition requires a role, it would be part of the condition. Option B is wrong because linking to a Problem might hide the action via condition, but the condition is the direct cause. Option C is wrong because if the UI Action were disabled, it would not appear for anyone, but the question implies it's missing for a specific user, so condition is more likely.

Practice this question →

MCQhard

An organization wants to capture 'Resolution Code' values that are specific to the 'Network' category. How is this achieved?

A.Dependent Values on the Choice field

B.ACLs

C.System Properties

D.Client Script

AnswerA

Dependent Values let a parent choice, here the 'Network' category, drive which Resolution Code options appear, so codes stay specific to that category rather than being globally available. This directly satisfies the requirement for category-specific Resolution Code values without custom tables or scripting.

Why this answer

Dependent Values on a Choice field is the standard ServiceNow mechanism for cascading choice lists, where the options in one field are filtered based on the value selected in another. To capture Resolution Codes specific to the 'Network' category, you configure the Resolution Code choice field with a dependent relationship to the Category field, so only Network-related codes appear when Category = Network.

Exam trap

The trap is confusing access control (ACLs) or scripting (Client Scripts) with declarative choice filtering — candidates may pick ACL because it sounds like it 'restricts' values, but ACLs restrict access, not the displayed option set.

How to eliminate wrong answers

Option B is wrong because ACLs control record- and field-level read/write/delete permissions, not the set of values displayed in a choice list. Option C is wrong because System Properties are global configuration key-value pairs (e.g., glide.* settings) and do not drive per-record choice filtering. Option D is wrong because a Client Script could technically manipulate choices via JavaScript, but it is not the standard, declarative configuration for dependent choice values — Dependent Values is the built-in feature designed for this exact purpose.

Practice this question →

Multi-Selecthard

Which THREE items are included in the Major Incident Workbench?

Select 3 answers

A.System Logs.

B.Incident Task list.

C.Communication history.

D.SLA Definition editor.

E.Timeline.

AnswersB, C, E

The Incident Task list tracks the individual action items assigned to responders during a major incident, showing ownership and completion status. It is a core component of the Major Incident Workbench for coordinating resolution work.

Why this answer

The Major Incident Workbench in ServiceNow is designed to give responders a single pane of glass for managing a major incident, and it includes the Incident Task list (B), which shows the child tasks created to resolve the incident and their states. It also includes the Communication history (C), which records all outbound notifications, emails, and updates sent to stakeholders during the incident. The Timeline (E) is likewise part of the workbench, providing a chronological view of key incident events, actions, and updates.

System Logs (A) are accessed through system diagnostics/log modules rather than the workbench, and the SLA Definition editor (D) is a separate configuration tool for creating and modifying SLA records, not a component of the Major Incident Workbench.

Exam trap

CIS-ITSM often tests the specific components of the Major Incident Workbench, and candidates may mistakenly include System Logs or SLA Definition editor, which are not part of it.

Practice this question →

MCQmedium

What is the purpose of the 'Parent Incident' field?

A.To link an incident to a problem

B.To link an incident to a user

C.To define the SLA group

D.To link child incidents to a master incident

AnswerD

The Parent Incident field establishes a hierarchical relationship, letting multiple child incidents be grouped under one master incident. This supports consolidated tracking and resolution when several related incidents stem from a single underlying cause or major outage.

Why this answer

The 'Parent Incident' field is used to link child incidents to a master incident, typically a major incident. When a major incident is created, related child incidents are associated with it via the Parent Incident field, creating a hierarchical relationship. This allows the major incident to serve as a coordination point, and child incidents inherit updates and share context with the parent.

Exam trap

CIS-ITSM often tests the purpose of the Parent Incident field — candidates confuse it with problem linking or user linking, but the correct answer is that it links child incidents to a master (major) incident.

How to eliminate wrong answers

Option A is wrong because linking an incident to a problem uses the 'Problem' field or the 'Problem ID' reference, not the Parent Incident field. Option B is wrong because linking an incident to a user is done via the 'Caller', 'Opened by', or 'Assigned to' fields, not Parent Incident. Option C is wrong because SLA groups are defined by SLA definitions and assignment rules, not by the Parent Incident field.

Practice this question →

Multi-Selecthard

Which THREE settings can be modified in an SLA Definition to control the SLA timer?

Select 3 answers

A.Duration type

B.Priority

C.Pause conditions

D.Incident State

E.Schedule

AnswersA, C, E

Duration type determines whether the SLA timer counts down to an end time or counts up from a start time. This directly governs how the timer is calculated against the SLA Definition, satisfying the requirement for a setting that controls the SLA timer.

Why this answer

In an SLA Definition, the Duration type (A) determines how the SLA timer's target is calculated — for example, whether it uses a relative duration from the task's creation/start or a percentage of a defined span — so it directly controls how the timer runs. Pause conditions (C) define the circumstances under which the SLA timer is paused (e.g., while the task is in an inactive state or awaiting a customer), which directly governs when the timer stops and resumes. The Schedule (E) specifies the business hours/calendar the SLA uses, so the timer only counts time within the defined schedule, directly controlling elapsed time.

The other options do not belong: Priority (B) is a task attribute used for routing/assignment rather than an SLA timer control, and Incident State (D) is a field on the incident record, not a timer setting in the SLA Definition (state-based behavior is handled through pause conditions or start/stop conditions, not by selecting a state as a timer setting).

Exam trap

CIS-ITSM often tests the distinction between fields on the incident record (Priority, State) and settings inside the SLA Definition (Duration type, Pause conditions, Schedule), catching candidates who conflate the two.

Practice this question →

MCQeasy

When migrating incidents from a legacy system, you need to ensure that the SLA duration is calculated based on the Business Calendar. Where is this configured?

A.SLA Definition record.

B.Incident Properties.

C.Workflow Activity.

D.Incident Business Rule.

AnswerA

The SLA Definition record holds the Business Calendar reference that drives duration calculation, so attaching the correct calendar there makes migrated incidents inherit business-hours timing. Without it, SLA durations would count continuous time rather than the defined schedule.

Why this answer

In ServiceNow, SLA duration calculations (including business calendar, schedule, and time zone) are configured on the SLA Definition record. The SLA Definition specifies the schedule (e.g., 8x5 business calendar) that determines when the SLA clock runs, so this is where business calendar-based duration is set.

Exam trap

CIS-ITSM often tests the misconception that SLA business calendars are configured in Incident Properties or Business Rules, when they are actually defined on the SLA Definition record via the Schedule field.

How to eliminate wrong answers

Option B is wrong because Incident Properties control system-wide incident behavior (e.g., auto-close, assignment) but not SLA duration or business calendar settings. Option C is wrong because Workflow Activities are steps in a workflow and do not configure SLA calendars. Option D is wrong because Incident Business Rules enforce record logic (e.g., state changes, field defaults) and do not define SLA business calendars.

Practice this question →

MCQmedium

What is the purpose of the 'Configuration Item' (CI) field on the Incident form?

A.To list the incident reporter

B.To define the SLA group

C.To store the resolution notes

D.To identify the affected asset

AnswerD

The CI field records the specific asset or service affected by the incident, linking the record to its entry in the CMDB. This satisfies the stem's requirement to identify what is broken, enabling impact assessment, correct assignment, and historical reporting against that configuration item.

Why this answer

The Configuration Item (CI) field on the Incident form identifies the specific asset, service, or infrastructure element affected by the incident, linking the incident to the CMDB. This linkage enables impact analysis, SLA targeting based on the CI's criticality, and root-cause correlation across incidents affecting the same CI. It is not used for reporter identity, SLA grouping, or resolution notes.

Exam trap

The trap is conflating the CI field with caller or SLA fields — candidates must remember CI is strictly the affected asset reference to the CMDB.

How to eliminate wrong answers

Option A is wrong because the incident reporter is captured in the 'Caller' or 'Opened by' field, not the CI field. Option B is wrong because SLA grouping is determined by SLA definitions and the task's SLA records, not by the CI field itself. Option C is wrong because resolution notes are stored in 'Close notes' or 'Resolution' fields, not the CI reference.

Practice this question →

MCQmedium

What is the 'Service Desk' group's primary role in Incident Management?

A.Managing service level agreements

B.Developing new applications

C.Fixing all hardware issues

D.Single Point of Contact for end users

AnswerD

Acting as the single point of contact satisfies the Service Desk's core Incident Management constraint: end users report every issue through one channel rather than contacting resolver groups directly. This centralised intake enables consistent logging, categorisation, initial diagnosis and ownership of incidents until resolution or escalation.

Why this answer

The Service Desk is defined in ITIL as the Single Point of Contact (SPOC) between the IT organization and users, handling all incident reports, service requests, and communications. Its primary role in Incident Management is to log, categorize, prioritize, and route incidents, and to keep users informed — not to own SLAs or fix every issue itself.

Exam trap

CIS-ITSM often tests the confusion between the Service Desk's SPOC/communication role and functional ownership of SLAs or technical fixes — candidates over-attribute responsibilities to the Service Desk that actually belong to other ITIL practices.

How to eliminate wrong answers

Option A is wrong because managing SLAs is the responsibility of Service Level Management, not the Service Desk — the Service Desk consumes SLA targets but does not define or manage them. Option B is wrong because developing new applications is an application development/DevOps function, entirely outside the Service Desk's scope. Option C is wrong because the Service Desk is not required to fix all hardware issues; it performs first-line diagnosis and escalates to second-line support groups when needed.

Practice this question →

Multi-Selecthard

Which THREE aspects must be considered when creating an SLA Definition for Incidents?

Select 3 answers

A.Assignment Group.

B.User locale.

C.Start Condition.

D.Stop Condition.

E.Duration (Schedule).

AnswersC, D, E

The start condition defines the trigger that begins SLA timing, such as when an incident is created or assigned. Without it, the SLA cannot determine when its clock starts, so this aspect is essential to any Incident SLA Definition.

Why this answer

When building an SLA Definition for Incidents, the Start Condition (C) is required because it defines the trigger event that begins the SLA timer, such as when an Incident is created or when its priority changes. The Stop Condition (D) is equally essential because it specifies the event that halts the SLA clock, for example when the Incident is resolved or closed. The Duration (E) is also mandatory since it establishes the target time, calculated against a Schedule, within which the task must be completed to meet the SLA.

Assignment Group (A) is not a required SLA Definition component—it is a field on the Incident record that may be referenced in conditions but is not itself an SLA aspect. User locale (B) is irrelevant to SLA timing and does not affect how an SLA Definition is configured.

Exam trap

The trap is selecting plausible-sounding but non-structural fields like Assignment Group or User locale — candidates must recognize that Start Condition, Stop Condition, and Duration/Schedule are the three mandatory pillars of any SLA Definition.

Practice this question →

MCQmedium

While working on a high-priority incident, an agent navigates away from the incident record without saving. The agent had changed the State to 'In Progress' and entered work notes. What happens to those unsaved changes?

A.The changes are saved to a temporary draft that can be recovered later from the 'My Drafts' module.

B.The changes are lost and the incident record remains unchanged.

C.The system automatically saves the changes to the incident record when the agent navigates away.

D.The system prompts the agent to save changes before navigating away.

AnswerB

In ServiceNow, unsaved form changes are not persisted when the user navigates away from the record. The incident remains in its previous state, and any entered work notes or state changes are discarded. This is standard behavior to avoid accidental updates. Agents must click Save or Update to commit changes.

Why this answer

ServiceNow does not auto-save or prompt to save when leaving an incident form. Any unsaved modifications are discarded, and the record remains as it was last saved. Agents must explicitly save their work.

This design prevents unintended updates but requires diligence.

Exam trap

The trap here is assuming that ServiceNow auto-saves or prompts to save when navigating away from a form.

Practice this question →

MCQeasy

Which role is specifically required to create or modify 'SLA Definitions'?

A.itil

B.admin

C.sla_admin

D.incident_manager

AnswerC

The sla_admin role holds the elevated privileges needed to define and edit SLA Definitions, satisfying the stem's requirement for a role specifically authorised to create or modify them. Standard users and other admin roles cannot alter these records, so sla_admin is the only role granting that exact capability.

Why this answer

The 'sla_admin' role is specifically designed to create and modify SLA Definitions in ServiceNow. This role grants the necessary permissions to manage SLA records and their associated configurations. Other roles like 'admin' have broad privileges but are not specifically tailored for SLA management, and 'itil' or 'incident_manager' do not have the required rights to modify SLA definitions.

Exam trap

CIS-ITSM often tests the confusion between the broad 'admin' role and the specific 'sla_admin' role, leading candidates to choose 'admin' when a more precise role is required.

How to eliminate wrong answers

Option A is wrong because the 'itil' role is for ITIL process users and does not include permissions to create or modify SLA definitions. Option B is wrong because while 'admin' can do everything, the question asks for the role specifically required, and 'sla_admin' is the precise role for this task. Option D is wrong because 'incident_manager' manages incidents, not SLAs.

Practice this question →

MCQmedium

When a Major Incident is created, a 'Major Incident Workbench' is available. What is its primary function?

A.Providing a central dashboard for communication and status.

B.Automating incident resolution.

C.Configuring SLA definitions.

D.Managing assignment rules.

AnswerA

The Major Incident Workbench supplies a single consolidated dashboard where responders view incident status, track assigned tasks and coordinate communications across teams. This directly satisfies the stem's requirement for a centralised coordination point during major incidents, eliminating scattered updates and giving stakeholders real-time visibility of resolution progress.

Why this answer

The Major Incident Workbench is a centralized dashboard in ServiceNow that aggregates all major incidents, their status, affected services, communication logs, and task assignments in one view. Its primary function is to give major incident managers a single pane of glass for communication and status tracking across the incident lifecycle.

Exam trap

CIS-ITSM often tests the distinction between the Workbench's monitoring/communication purpose and configuration functions like SLA or assignment rules — candidates pick options that sound operational but are actually configuration tasks.

How to eliminate wrong answers

Option B is wrong because automating incident resolution is not the Workbench's role — resolution is handled by workflows, business rules, and assignment logic, not the Workbench UI. Option C is wrong because SLA definitions are configured in the SLA module (Contract/SLA), not in the Major Incident Workbench. Option D is wrong because assignment rules are configured in assignment rule tables and workflows, not in the Workbench, which is a monitoring and communication interface.

Practice this question →

Multi-Selecthard

Which THREE types of metrics can be tracked using the baseline Incident Management SLA and Metric definitions? (Choose three.)

Select 3 answers

A.The exact GPS coordinates of the technician resolving the ticket.

B.Duration an incident spent in a specific assignment group.

C.The physical CPU utilization of the server hosting the database.

D.Time elapsed before an incident reaches the 'Resolved' state (SLA target).

E.Whether an SLA achieved its target or breached.

AnswersB, D, E

The baseline metric definitions capture time spent within assignment groups, so the duration an incident remained in a specific group is measurable. This satisfies the stem's request for trackable metric types by reporting group-level dwell time rather than resolution or attainment.

Why this answer

Option B is correct because baseline Incident Management SLA and Metric definitions in ServiceNow can measure the time an incident spends in a particular assignment group, using a metric definition with the Assignment group field as the condition. Option D is correct because SLA definitions track the elapsed time against a target, such as the time before an incident reaches the 'Resolved' state, which is a standard SLA target type. Option E is correct because SLA processing records whether the SLA achieved its target or breached, which is the core outcome reported by SLA metrics.

Option A is not correct because GPS coordinates of a technician are not part of baseline Incident Management SLA or metric definitions. Option C is not correct because physical CPU utilization of a database server is infrastructure monitoring data, not an incident SLA or metric definition.

Exam trap

CIS-ITSM often tests the distinction between SLA metrics (time-based, target-driven) and unrelated operational data (like GPS or CPU), so candidates may incorrectly assume any measurable data is part of the baseline SLA.

Practice this question →

MCQhard

If an organization wants to prevent an Incident from being closed unless certain fields are populated, which feature should be used?

A.Client Script

B.Data Policy

C.Assignment Rule

D.System Property

AnswerB

Data Policies enforce mandatory field completion before an Incident can be closed, directly satisfying the stem's constraint that closure must be blocked until specified fields are populated. Unlike UI Policies, which only control field visibility or read-only state on the form, Data Policies apply server-side validation regardless of how the record is saved.

Why this answer

Data Policies in ServiceNow enforce mandatory field requirements at the database level regardless of how a record is saved (UI, import, script, or API). They are the correct feature to prevent an Incident from being closed unless specified fields are populated, because they apply consistently across all entry points.

Exam trap

CIS-ITSM often tests the distinction between client-side enforcement (Client Scripts, UI Policies) and server-side enforcement (Data Policies), luring candidates toward UI-only features that can be bypassed.

How to eliminate wrong answers

Option A is wrong because Client Scripts run only in the browser UI and can be bypassed by imports, web services, or background scripts. Option C is wrong because Assignment Rules determine who a record is assigned to, not field validation. Option D is wrong because System Properties control global platform behavior, not per-record field enforcement on close.

Practice this question →

MCQmedium

When creating an Incident from a Service Portal, which component defines the fields displayed to the user?

A.Incident Form

B.Catalog Item

C.Record Producer

D.Business Rule

AnswerC

A Record Producer defines which fields appear on a Service Portal form and maps submitted values onto the target Incident record. It satisfies the stem's constraint by controlling the portal-facing field set independently of the Incident table's dictionary, unlike catalogue items or UI policies, which govern catalogue ordering or client-side behaviour rather than portal field display.

Why this answer

A Record Producer is used to create records (like Incidents) from the Service Portal. It defines the fields that are displayed to the user by allowing you to select which variables to include and how they map to the target record. The Record Producer essentially acts as a form builder for record creation.

Exam trap

CIS-ITSM often tests the distinction between Record Producers and Catalog Items, and candidates may confuse the two when asked about incident creation from the portal.

How to eliminate wrong answers

Option A is wrong because the Incident Form is the backend form used by fulfillers, not the portal interface for end users. Option B is wrong because a Catalog Item is used for requesting items or services, not for creating incidents directly. Option D is wrong because a Business Rule is server-side logic that runs on database operations, not a UI component for field display.

Practice this question →

Multi-Selecthard

Which THREE actions can be performed when utilizing the incident-to-problem workflow in ITSM? (Choose three.)

Select 3 answers

A.Associate multiple active incidents to a single Problem record.

B.Convert the incident table class directly into a problem table class via schema map manipulation.

C.Propagate workarounds from the Problem record to all associated Incidents.

D.Automatically generate a hardware purchase order from the problem investigation.

E.Create a new Problem record directly from an Incident form.

AnswersA, C, E

Associating multiple active incidents to one Problem record satisfies the workflow's core purpose: consolidating recurring or related incidents so root cause analysis occurs once. The incident-to-problem relationship is many-to-one, letting agents link each affected incident while tracking resolution progress centrally against the single Problem.

Why this answer

Option A is correct because the incident-to-problem workflow is designed to link many active incidents that share a common root cause to one Problem record, enabling consolidated root cause analysis. Option C is correct because once a workaround is documented on the Problem record, it can be propagated to all associated Incidents so affected users receive the interim fix. Option E is correct because the workflow allows an agent to create a new Problem record directly from an Incident form, establishing the parent-child relationship without leaving the incident context.

Option B is not part of the workflow; converting an incident table class into a problem table class via schema map manipulation is a database schema change, not an ITSM process action. Option D is not part of the workflow; automatically generating a hardware purchase order from a problem investigation is a procurement activity outside the incident-to-problem process.

Exam trap

The trap is including schema-level or procurement actions that sound plausible but are outside the supported incident-to-problem workflow — candidates must stick to the three documented actions.

Practice this question →

Multi-Selecthard

Which THREE components are configured when setting up a Service Level Agreement (SLA) Definition for Incident Management? (Choose three.)

Select 3 answers

A.Start condition

B.Workflow / Schedule

C.Stop condition

D.Assignment rule mapping

E.Data policy rule

AnswersA, B, C

The start condition defines the trigger criteria determining when the SLA timer begins, such as incident creation or a specific state change. It satisfies the stem by being one of the three required components configured in an SLA Definition.

Why this answer

In an SLA Definition for Incident Management, the three core components that must be configured are the Start condition (A), the Workflow/Schedule (B), and the Stop condition (C). The Start condition (A) defines the trigger criteria—such as when an incident is created or when a specific field changes—that begins the SLA timer. The Workflow/Schedule (B) specifies the SLA's timing behavior, including the schedule (e.g., 8x5 or 24x7), duration, and the workflow that drives the SLA stages and breach actions.

The Stop condition (C) defines the criteria that pause or end the SLA timer, such as when the incident is resolved or closed. Assignment rule mapping (D) and Data policy rule (E) are separate configuration elements used for routing and data validation, not for defining an SLA.

Exam trap

CIS-ITSM often tests the exact components of an SLA Definition — the trap is selecting adjacent configuration items like assignment rules or data policies that are configured elsewhere and are not part of the SLA Definition itself.

Practice this question →

MCQmedium

A service desk manager needs to ensure that Incidents assigned to the 'Hardware' group are automatically routed to a specific sub-group based on the 'Category' field. Which configuration should be used?

A.Flow Designer

B.Assignment Rules

C.Data Lookups

D.Business Rules

AnswerB

Assignment Rules evaluate conditions such as the Category field on an Incident record and automatically set the assignment group, satisfying the requirement to route Hardware Incidents to a specific sub-group. They run on record creation or update, so routing happens without agent intervention, unlike business rules or UI policies.

Why this answer

Assignment Rules in ServiceNow are designed to automatically assign records (like Incidents) to the appropriate assignment group or individual based on conditions such as Category. They are evaluated when a record is created or updated, and can route based on fields like Category. This is the standard configuration for such routing.

Exam trap

CIS-ITSM often tests the confusion between Assignment Rules and Business Rules, tempting candidates to choose Business Rules for simple routing, but Assignment Rules are the correct out-of-box feature.

How to eliminate wrong answers

Option A is wrong because Flow Designer is a broader automation tool; while it can perform assignments, it is not the specific configuration for simple routing based on Category. Option C is wrong because Data Lookups are used to populate field values from external tables, not for assignment routing. Option D is wrong because Business Rules are server-side scripts that can set assignments, but they are more complex and not the out-of-box configuration for this purpose; Assignment Rules are the intended feature.

Practice this question →

MCQhard

You are troubleshooting a scenario where an Incident SLA is not attaching to a ticket. What is the first place you should investigate?

A.SLA Definition Conditions

B.Incident State

C.System Dictionary

D.User Preferences

AnswerA

SLA definitions carry start, stop, pause and reset conditions that determine whether a record qualifies for attachment. If these conditions reference fields the ticket does not populate, or exclude its values, no SLA binds. Verifying them first satisfies the stem's requirement to find why attachment fails before checking workflows or schedules.

Why this answer

The first place to investigate when an Incident SLA is not attaching is the SLA Definition Conditions. SLA definitions in ServiceNow use start conditions, stop conditions, and pause conditions to determine when an SLA attaches to a task. If the conditions do not match the incident's field values (e.g., priority, category, assignment group), the SLA will not attach.

Checking the SLA Definition Conditions first confirms whether the incident meets the criteria for the SLA to be applied.

Exam trap

CIS-ITSM often tests SLA troubleshooting — candidates jump to incident state or user preferences, but the first and most logical place to check is the SLA definition's start conditions, which determine whether the SLA should attach at all.

How to eliminate wrong answers

Option B is wrong because the Incident State is a field value that may be part of the SLA conditions, but it is not the first place to investigate — the SLA definition itself defines which states trigger attachment. Option C is wrong because the System Dictionary defines table schema and field properties, not SLA attachment logic. Option D is wrong because User Preferences affect personal UI settings, not SLA attachment behavior.

Practice this question →

MCQmedium

A customer wants to make the 'Short Description' field mandatory only when the Incident state changes to 'Resolved'. Which approach is best?

A.Create a Business Rule with 'abortAction()'.

B.Use a UI Policy with the 'Mandatory' field set to 'True'.

C.Use a Data Policy on the field.

D.Create an OnChange Client Script.

AnswerB

A UI Policy with Mandatory set to True enforces the field only when its condition—state equals Resolved—is met, satisfying the stem's conditional requirement. A dictionary-level mandatory setting would apply unconditionally, making Short Description required at every state instead.

Why this answer

A UI Policy is the correct tool to make a field mandatory based on another field's value or state, because it operates on the client side and can dynamically set the 'Mandatory' attribute when the condition (state = Resolved) is met. UI Policies are designed exactly for this kind of conditional field behavior without writing code.

Exam trap

CIS-ITSM often tests the confusion between UI Policies (client-side, form behavior) and Data Policies (server-side, import/API enforcement), leading candidates to pick Data Policy for form-level mandatory logic.

How to eliminate wrong answers

Option A is wrong because a Business Rule with abortAction() runs server-side and would block the save entirely rather than conditionally making the field mandatory; it also does not provide the dynamic UI behavior expected. Option C is wrong because Data Policies are server-side and enforce mandatory/read-only rules on import and API, not dynamically on the form when a user changes state. Option D is wrong because an OnChange Client Script could set the mandatory flag, but it is more complex and less maintainable than a UI Policy, which is the standard declarative approach.

Practice this question →

MCQmedium

A service desk manager reports that priority is not updating automatically when Impact and Urgency are changed on an incident form. Where is the mapping between Impact, Urgency, and Priority configured?

A.Data Policies

B.Priority Lookup Rules

C.UI Policies

D.Assignment Rules

E.Service Level Agreements (SLAs)

AnswerB

Priority Lookup Rules hold the mapping table that derives Priority from the Impact and Urgency matrix. Without an active rule matching the selected combination, the incident form cannot calculate Priority automatically, which explains the manager's reported symptom.

Why this answer

The mapping between Impact, Urgency, and Priority on incident records is defined in Priority Lookup Rules (sys_priority_lookup table). These rules specify which priority value is assigned for each combination of Impact and Urgency, and they are evaluated by a business rule that runs when either field changes. Without a matching Priority Lookup Rule, the priority field will not auto-update.

Exam trap

CIS-ITSM often tests whether candidates confuse UI Policies (client-side field behavior) with Priority Lookup Rules (server-side value mapping), so the trap is picking UI Policies because it sounds like it controls field behavior.

How to eliminate wrong answers

Option A is wrong because Data Policies enforce mandatory/read-only field behavior on the server side, not value derivation logic. Option C is wrong because UI Policies control field visibility, mandatory, and read-only states on the client form, not the Impact/Urgency/Priority mapping. Option D is wrong because Assignment Rules determine who gets assigned the incident, not the priority value.

Option E is wrong because SLAs define response and resolution targets based on priority, but they do not set the priority itself.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid ways to escalate an incident?

Select 2 answers

A.Changing the user's manager.

B.Configuring an SLA breach to trigger an event.

C.Adding the incident to a Change Request.

D.Deleting the incident record.

E.Manually changing the Priority field.

AnswersB, E

An SLA breach triggering an event is a valid automated escalation route: the SLA engine fires a workflow event when the target time is exceeded, which can then reassign or notify. This satisfies the stem's requirement for a legitimate escalation mechanism without manual intervention.

Why this answer

Option B is correct because configuring an SLA breach to trigger an event is a standard automated escalation mechanism: when a response or resolution target in the SLA is breached (or about to be breached), the system fires an event that can notify a manager, reassign the incident, or raise its urgency. Option E is correct because manually changing the Priority field is a valid functional escalation path — raising priority (for example, from P3 to P1) increases visibility and drives the incident up the support hierarchy per the priority matrix. Options A, C, and D are not escalation methods: changing the user's manager alters ownership/contact data rather than escalating the incident, adding the incident to a Change Request links it to change management but does not escalate it, and deleting the incident record destroys the ticket instead of escalating it.

Exam trap

CIS-ITSM often tests the misconception that escalation requires creating a new record (like a Change or Problem) or reassigning ownership, when in fact it is driven by SLA events or Priority changes on the incident itself.

Practice this question →

Multi-Selectmedium

Which TWO considerations are important when designing Assignment Rules for Incident Management? (Choose two.)

Select 2 answers

A.Assignment rules can only assign incidents to individual users, never groups.

B.Evaluation stops at the first matching rule unless otherwise configured.

C.Assignment rules require client-side JavaScript to function.

D.Assignment rules execute before Inbound Email Actions.

E.Rules are evaluated in ascending order based on their Order field value.

AnswersB, E

Assignment rules execute sequentially, and by default the first rule whose conditions match wins, halting further evaluation. This ordering behaviour is a core design consideration, since overlapping conditions in later rules never fire unless earlier matches are excluded or the stop-on-match setting is disabled.

Why this answer

Option B is correct because in ServiceNow assignment rules are processed sequentially and, by default, the first rule whose conditions match is applied and evaluation stops, so rule ordering and specificity matter to avoid an unintended match. Option E is correct because assignment rules are evaluated in ascending order of their Order field value, meaning lower numbers run first and determine which rule wins when multiple rules could match. Option A is wrong because assignment rules can assign to groups as well as individual users, so they are not limited to individual users.

Option C is wrong because assignment rules are server-side logic and do not require client-side JavaScript. Option D is wrong because assignment rules run after inbound email actions create or update the incident, not before them.

Exam trap

CIS-ITSM often tests the misconception that assignment rules can only target users (not groups) or that they run before inbound email actions — the actual behavior is group-or-user assignment, ascending Order evaluation, and first-match stop.

Practice this question →

Multi-Selectmedium

Which TWO states are typically included in the baseline Incident lifecycle state model? (Choose two.)

Select 2 answers

A.Resolved

B.Under Review

C.Backlog

D.Pending Approval

E.In Progress

AnswersA, E

Resolved is a standard baseline incident state.

Why this answer

Option A (Resolved) is correct because the baseline Incident lifecycle state model in ITIL/ITSM includes Resolved as the state reached once a fix has been applied and the user confirms restoration of service, prior to formal closure. Option E (In Progress) is correct because In Progress is a core lifecycle state indicating the incident is actively being worked on by support staff after being logged and categorized. Option B (Under Review) is not part of the standard baseline incident states; it is more typical of problem or change management workflows.

Option C (Backlog) is a work-queue concept used in development or agile contexts, not a defined incident lifecycle state. Option D (Pending Approval) belongs to change management or request fulfillment workflows, not the baseline incident lifecycle.

Exam trap

CIS-ITSM often tests the distinction between baseline incident states and states from other ITIL processes, causing candidates to mistakenly select 'Pending Approval' or 'Under Review' as incident states.

Practice this question →

MCQmedium

When an incident is moved to 'Resolved', what happens to the SLA timer?

A.The SLA timer pauses indefinitely

B.The SLA timer continues

C.The SLA timer stops

D.The SLA timer resets to zero

AnswerC

The SLA timer halts at the moment the incident transitions to 'Resolved', satisfying the requirement that resolution ends active SLA measurement. ServiceNow stops the task SLA clock on this state change, so elapsed time reflects only the active working period up to resolution, excluding any subsequent closure or review stages.

Why this answer

The [CORRECT] answer is C. In ServiceNow, when an incident is moved to the 'Resolved' state, the SLA timer stops because the resolution effectively ends the active work period. The SLA engine records the time spent up to resolution and marks the SLA as completed or met/missed based on the elapsed duration.

The timer does not continue to run after resolution.

Exam trap

The trap is thinking the SLA timer continues or resets after resolution; candidates must remember that resolution is typically a stop condition, and the timer halts at that point.

How to eliminate wrong answers

Option A is wrong because the SLA timer does not pause indefinitely; pausing occurs only under specific conditions defined in the SLA (e.g., awaiting customer response), not simply upon resolution. Option B is wrong because the timer does not continue after resolution—continuing would incorrectly count post-resolution time against the SLA. Option D is wrong because the timer does not reset to zero; resetting would erase the recorded response/resolution time and is not how SLA processing works.

Practice this question →

MCQmedium

Which mechanism ensures that if an Incident is not updated for 24 hours, an email is sent to the manager?

A.Workflow

B.Inactivity Monitor

C.Business Rule

D.Client Script

AnswerB

Inactivity Monitor tracks elapsed time since the last update on an Incident record, then triggers the notification workflow once the 24-hour threshold lapses. This directly satisfies the stem's constraint: an email to the manager fired by inactivity, not by state change, priority, or assignment, which other mechanisms would require.

Why this answer

The Inactivity Monitor is a ServiceNow feature that sends notifications when a record has not been updated for a specified period. It is configured to monitor the Incident table and trigger an email to the manager after 24 hours of inactivity.

Exam trap

The trap is confusing the Inactivity Monitor with other automation mechanisms like Business Rules or Workflows, which are not time-based by default.

How to eliminate wrong answers

Option A is wrong because Workflow is a broader automation tool that can include inactivity monitoring, but it is not the specific mechanism. Option C is wrong because Business Rules execute on database operations, not on time-based inactivity. Option D is wrong because Client Scripts run in the browser and cannot monitor server-side inactivity.

Practice this question →

MCQmedium

What does the 'Caller' field on the Incident form reference?

A.The incident table

B.The groups table

C.The sys_user table

D.The cmn_department table

AnswerC

The Caller field references the sys_user table, storing a reference to the user record of the person reporting the incident. This links the incident to an existing user account, enabling contact details, location and affected-user reporting to be pulled automatically.

Why this answer

The 'Caller' field on the Incident form is a reference field that points to the sys_user table, identifying the user who reported the incident. It stores the sys_id of the user record and displays the user's name.

Exam trap

CIS-ITSM often tests whether candidates know which table each reference field points to — the trap is confusing Caller (sys_user) with Assignment Group (sys_user_group) or Department (cmn_department).

How to eliminate wrong answers

Option A is wrong because the incident table is the table the form itself is based on — the Caller field references a user, not the incident table. Option B is wrong because the groups table (sys_user_group) is referenced by fields like Assignment Group, not Caller. Option D is wrong because cmn_department is the department table, referenced by fields like Department on the user record, not the Caller field on the incident.

Practice this question →

MCQmedium

Which tool is best for visualizing the relationship between an Incident and the affected Configuration Item?

A.Incident Timeline.

B.Incident History.

C.Task SLA.

D.Dependency View.

AnswerD

The Dependency View maps a Configuration Item to its related records, so it directly exposes the Incident's link to the affected CI. This satisfies the stem's requirement for visualising that relationship, unlike a list or form view, which shows the Incident's fields but not its CI associations.

Why this answer

The Dependency View is the best tool for visualizing the relationship between an Incident and the affected Configuration Item (CI) because it provides a graphical representation of the CI and its dependencies, including the incident's impact on related CIs. This view helps ITIL practitioners understand the upstream and downstream relationships, which is critical for impact analysis and root cause investigation. It is specifically designed to show dependencies and relationships in the CMDB.

Exam trap

CIS-ITSM often tests the specific purpose of CMDB visualization tools, tricking candidates into selecting timeline or history views when the question asks for relationship visualization.

How to eliminate wrong answers

Option A is wrong because the Incident Timeline shows the chronological history of activities and updates on an incident, not the relationship to CIs. Option B is wrong because Incident History displays past changes and audit records for the incident, not the CI dependency graph. Option C is wrong because Task SLA shows the service level agreement status for tasks associated with the incident, not the CI relationships.

Practice this question →

MCQhard

You are investigating why an incident was not auto-assigned. You check the Assignment Rules but notice the 'Match Conditions' are met. What is another common reason?

A.The Assignment Rule is not active.

B.The 'Assigned to' field is already populated.

C.The incident is in a closed state.

D.The incident was created via an Email Inbound Action.

AnswerA

Assignment rules only execute when active; an inactive rule is skipped entirely regardless of whether its match conditions are satisfied. Since the stem confirms conditions are met, the rule's inactive state is the remaining common cause preventing auto-assignment.

Why this answer

A common reason an incident is not auto-assigned despite matching Assignment Rule conditions is that the Assignment Rule itself is inactive. ServiceNow only evaluates active assignment rules; an inactive rule is skipped entirely during incident creation, regardless of whether its match conditions are satisfied. Checking the 'Active' checkbox on the rule is a standard troubleshooting step.

Exam trap

CIS-ITSM often tests the assumption that matching conditions are sufficient for an assignment rule to fire, catching candidates who overlook that the rule must also be active and evaluated in the correct order.

How to eliminate wrong answers

Option B is wrong because if the 'Assigned to' field is already populated, the assignment rule would typically not fire — but the question states the incident was not auto-assigned, so this is not the cause; also, an already-populated field would be a reason the rule is skipped, but the scenario implies the field is empty. Option C is wrong because a closed-state incident would not be subject to assignment rules at all, but the question is about an incident that should have been auto-assigned, implying it is in a new/open state. Option D is wrong because incidents created via Email Inbound Actions can still trigger assignment rules — the creation source does not inherently block assignment rules unless a specific business rule or condition excludes them.

Practice this question →

Multi-Selectmedium

When configuring Incident Management properties (Incident > Administration > Properties), which TWO behaviors can an administrator control globally? (Choose two.)

Select 2 answers

A.Define the exact salary range of incident managers.

B.Set the physical server memory allocation for the instance.

C.Configure Active Directory domain controllers.

D.Enable or disable customer updates to reopen closed incidents (e.g., com.snc.incident.reopen_closed).

E.Determine the number of days after which Resolved incidents automatically close.

AnswersD, E

The com.snc.incident.reopen_closed property governs whether customer replies can reopen a closed incident. Setting it globally in Incident Management properties satisfies the stem's requirement for an administrator-controlled behaviour, overriding per-record reopening and enforcing consistent closure handling across the instance.

Why this answer

Option D is correct because the Incident Properties page exposes the system property com.snc.incident.reopen_closed, which globally controls whether customers can add comments or updates that reopen an already closed incident. Option E is correct because the same Incident > Administration > Properties page includes the 'Close incident after' (auto-close) setting, which defines the number of days a Resolved incident remains open before it is automatically moved to Closed. Options A, B, and C are incorrect because salary ranges, physical server memory allocation, and Active Directory domain controller configuration are not Incident Management properties; they belong to HR/finance data, infrastructure/hosting configuration, and LDAP/AD integration settings respectively, not to the incident property registry.

Exam trap

CIS-ITSM often tests whether candidates can distinguish global Incident Management properties from unrelated configuration areas — the trap is picking answers that sound like administrative settings but belong to HR, infrastructure, or directory services.

Practice this question →

Multi-Selectmedium

Which TWO are common 'On Hold' reasons in the standard Incident process?

Select 2 answers

A.Awaiting Assignment

B.Awaiting Approval

C.Awaiting Change

D.Awaiting Caller

E.Awaiting Vendor

AnswersD, E

Awaiting Caller suspends the incident because the service desk requires information or action from the user before proceeding. Responsibility shifts temporarily to the requester, so the ticket is parked rather than closed, with follow-up scheduled if no response arrives.

Why this answer

Standard on-hold reasons include 'Awaiting Caller' and 'Awaiting Vendor'.

Practice this question →

MCQhard

You need to ensure that only members of the 'Major Incident Management' group can promote an incident to a Major Incident. How do you restrict this?

A.Update the UI Action condition.

B.Use a Data Policy.

C.Create a Client Script.

D.Use an ACL on the 'Major Incident' field.

AnswerA

The UI Action that promotes an incident to Major Incident can carry a condition restricting visibility and execution to members of the specified group. This satisfies the stem's requirement that only Major Incident Management members can perform the promotion.

Why this answer

The 'Promote to Major Incident' action is typically implemented as a UI Action on the Incident form. Restricting who can see or execute it is done by editing the UI Action's condition or by adding a role/group check in the condition field, so only members of the Major Incident Management group can trigger it.

Exam trap

CIS-ITSM often tests the misconception that an ACL on a field can restrict a UI Action, when in fact UI Action conditions or roles are the correct mechanism for controlling action visibility.

How to eliminate wrong answers

Option B is wrong because Data Policies enforce field-level mandatory/read-only rules on import and API, not UI Action visibility or execution. Option C is wrong because a Client Script can hide buttons but is not a secure enforcement mechanism; users could still invoke the action via URL or API. Option D is wrong because an ACL on the 'Major Incident' field controls read/write access to that field, not the ability to execute the promote action.

Practice this question →

MCQmedium

A user's incident was closed, but they respond via email. The system creates a new incident instead of reopening the old one. What setting should be checked?

A.The 'Closed' incident policy.

B.Inbound Email Action.

C.Incident State transition rules.

D.User profile settings.

AnswerB

Inbound Email Actions define how received emails are processed, including whether a reply reopens the matching incident or creates a new record. The setting controlling this reopen-versus-create behaviour must be inspected to stop duplicate incidents being generated for the same user issue.

Why this answer

Inbound Email Actions in ServiceNow determine how incoming emails are processed — including whether a reply to a closed incident reopens it or spawns a new record. The default 'Reply' action checks the watermark (target record) and, if the incident is closed, may create a new incident unless the action is configured to reopen. Checking the Inbound Email Action (specifically the action tied to the reply email) is the correct place to verify this behavior.

Exam trap

CIS-ITSM often tests the misconception that a global 'Closed incident policy' or state transition rule controls email-driven reopening, when in fact the Inbound Email Action's script and watermark logic are what determine whether a reply reopens or creates a new incident.

How to eliminate wrong answers

Option A is wrong because the 'Closed' incident policy is not a ServiceNow configuration artifact — closure behavior is governed by state models, business rules, and email actions, not a single 'Closed policy' setting. Option C is wrong because state transition rules govern how an incident moves between states (e.g., Resolved to Closed), not how inbound email is routed to existing versus new records. Option D is wrong because user profile settings control preferences and notification subscriptions, not record creation logic from inbound email.

Practice this question →

MCQeasy

An administrator needs to configure the system so that when an incident is created from an inbound email, a specific Assignment Group is automatically populated based on the email subject. Which feature should be used to achieve this?

A.Assignment Rules

B.Dictionary Overrides

C.Inbound Email Actions

D.Data Policies

AnswerC

Inbound email actions define scripted rules that run when email creates an incident, allowing conditions on the subject line to set fields such as Assignment Group automatically. This satisfies the requirement to populate the group based on email subject.

Why this answer

Inbound Email Actions in ServiceNow are scripts that run when an email is received and can set field values (including Assignment Group) on the record being created, based on conditions like the email subject. They are the correct mechanism for parsing inbound email content and populating fields during record creation.

Exam trap

The trap is assuming Assignment Rules can read email content — they cannot; only Inbound Email Actions have access to the email object, so candidates who pick Assignment Rules misunderstand the scope of that feature.

How to eliminate wrong answers

Option A is wrong because Assignment Rules are used to set the assignment group on task records based on conditions evaluated at creation/update, but they do not parse inbound email subject lines — they operate on record fields, not email content. Option B is wrong because Dictionary Overrides change field attributes (e.g., mandatory, read-only) for a table or extended table, not assignment logic. Option D is wrong because Data Policies enforce field-level validation and can set default values, but they cannot read the email subject to drive conditional assignment.

Practice this question →

MCQeasy

Which table is the base table for the 'Incident' table?

A.sys_user

B.task

C.problem

D.cmdb_ci

AnswerB

The Incident table extends task, inheriting its core fields and behaviour. This satisfies the stem's requirement for the base table, since ServiceNow's task hierarchy places incident beneath task, not the reverse. Configuration item, problem and change relationships are references, not parent-child extensions.

Why this answer

The 'task' table is the base table for the Incident table in ServiceNow. Incident extends task, inheriting fields like number, state, priority, and assignment group. This inheritance allows Incidents to share common task-related functionality with other task types like Problems and Changes.

Exam trap

CIS-ITSM often tests the table inheritance hierarchy, and candidates may confuse the base table of Incident with other common tables like sys_user or cmdb_ci.

How to eliminate wrong answers

Option A is wrong because sys_user is the base table for User records, not Incidents. Option C is wrong because problem is a separate task type that extends task, not the base for Incident. Option D is wrong because cmdb_ci is the base table for Configuration Items, not Incidents.

Practice this question →

MCQmedium

An organization wants to require a 'Resolution Code' when closing an incident. What is the standard configuration?

A.Use a UI Policy to make the field mandatory when State is Resolved.

B.Modify the Dictionary Entry.

C.Use an Access Control List (ACL).

D.Use an OnSubmit Client Script.

AnswerA

A UI Policy enforces field-level behaviour client-side, so making Resolution Code mandatory when State becomes Resolved satisfies the requirement at the moment of closure. This is the standard ServiceNow configuration, since UI Policies control mandatory, visible and read-only states without server-side scripting.

Why this answer

The standard, declarative way to make a field mandatory based on another field's value in ServiceNow is a UI Policy. A UI Policy with the condition 'State is Resolved' and the action 'Set Resolution Code to Mandatory' enforces the requirement at the form level without custom code. This is the recommended configuration because it is maintainable and visible in the platform's configuration records.

Exam trap

The trap is choosing a Dictionary change or ACL because they sound authoritative — but Dictionary makes the field mandatory everywhere, and ACLs control access, not requiredness; only UI Policy provides conditional, form-level mandatory enforcement.

How to eliminate wrong answers

Option B is wrong because modifying the Dictionary Entry would make Resolution Code mandatory globally on the table, regardless of state — it cannot be conditional on State = Resolved. Option C is wrong because an ACL controls read/write access to the field, not whether it is required on the form; an ACL could block writes but would not present the field as mandatory. Option D is wrong because an OnSubmit Client Script is a custom-code workaround that runs after submission and is not the standard configuration; UI Policy is the built-in, no-code solution designed for exactly this requirement.

Practice this question →

Multi-Selectmedium

Which TWO components can be used to notify a user about an incident update?

Select 2 answers

A.Customer Comments

B.Assignment Rule

C.Work Notes

D.UI Policy

E.Email Notification

AnswersA, E

Comments trigger notification events for the end user.

Why this answer

Customer Comments (A) are correct because they are visible to the caller/end user on the incident record and, when added, can trigger outbound communication such as an email notification to the user, thereby notifying them of an update. Email Notification (E) is correct because it is the mechanism that actually sends an email to the user (for example, via a notification configured on the incident table when a comment is added or the record is updated). Assignment Rule (B) is not correct because it only automatically sets fields such as assignment group or assigned user during insert/update and does not notify users.

Work Notes (C) are not correct because they are internal-only and are not visible to the end user. UI Policy (D) is not correct because it only dynamically changes form field behavior (visible, mandatory, read-only) on the client side and does not send notifications.

Exam trap

CIS-ITSM often tests the visibility distinction between Customer Comments and Work Notes — the trap is assuming Work Notes notify the user, when they are internal-only.

Practice this question →

MCQeasy

What is the difference between 'Work Notes' and 'Comments' in an incident?

A.Work notes are mandatory; Comments are optional

B.Work notes are visible to the caller; Comments are internal

C.Work notes are internal; Comments are visible to the caller

D.None

E.Both are visible to everyone

AnswerC

Work notes are restricted to internal IT staff and never surface in the customer portal, while additional comments are customer-visible and notify the caller. This visibility split satisfies the stem's distinction, letting technicians document diagnostics privately while communicating updates externally.

Why this answer

In ServiceNow Incident records, 'Work Notes' are internal and visible only to users with appropriate roles (such as ITIL), while 'Comments' (also called Additional Comments) are visible to the caller and external parties. This distinction is fundamental to incident communication.

Exam trap

CIS-ITSM often tests the visibility distinction between Work Notes and Comments, and candidates sometimes confuse which is internal and which is external.

How to eliminate wrong answers

Option A is wrong because neither Work Notes nor Comments are mandatory by default; mandatory status is controlled by UI Policies or Data Policies. Option B is wrong because it reverses the visibility: Work Notes are internal, Comments are visible to the caller. Option D is wrong because there is a clear difference.

Option E is wrong because Work Notes are not visible to everyone; they are restricted to internal users with roles.

Practice this question →

Multi-Selectmedium

Which TWO fields are used in the default Incident Priority calculation?

Select 2 answers

A.Impact

B.Priority

C.Configuration Item

D.Assignment Group

E.Urgency

AnswersA, E

Impact is the second axis in ServiceNow's default priority lookup, quantifying how broadly the incident affects users or services. Combined with urgency in the priority matrix, it produces the priority value the stem's calculation requires, making it one of the two fields used.

Why this answer

In the default Incident Priority calculation, the two fields used are Impact (option A) and Urgency (option E). Priority is derived from a lookup matrix that maps the combination of Impact and Urgency values to a Priority value, so both fields must be populated for the calculation to work. Impact reflects how broadly the incident affects the business, while Urgency reflects how quickly the incident needs resolution, and together they determine the resulting Priority.

Options B, C, and D are not inputs to the calculation: Priority is the output, and Configuration Item and Assignment Group are unrelated to the default Priority matrix.

Exam trap

CIS-ITSM often tests the confusion between inputs and outputs of the priority calculation — candidates may select Priority itself or unrelated fields like Configuration Item, forgetting that only Impact and Urgency are used.

Practice this question →

MCQeasy

Which tab on the Incident form is typically used to track communication with the caller?

A.Notes

B.Activity

C.SLA

D.Related Records

AnswerB

The Activity tab records the full interaction history, including outbound notifications, work notes and emails exchanged with the caller. It provides the chronological audit trail needed to track communication, which the question specifically asks for.

Why this answer

The Activity tab on the Incident form is the standard location for tracking all communication with the caller, including outbound emails, inbound replies, comments, and work notes. It provides a chronological feed of all interactions, making it the primary tab for reviewing the communication history with the user.

Exam trap

CIS-ITSM often tests whether candidates confuse the Activity tab (full communication history) with the Notes field (internal work notes) or Related Records, so they pick the wrong tab for caller communication tracking.

How to eliminate wrong answers

Option A is wrong because the Notes tab (or field) is used for internal work notes and additional comments but does not aggregate the full communication thread; it is a field, not the tab that tracks caller communication. Option C is wrong because the SLA tab displays service level agreement milestones and breach times, not communication. Option D is wrong because Related Records shows linked records such as problems, changes, or tasks, not the communication history.

Practice this question →

MCQmedium

An organization wants to require 'Work Notes' whenever an incident is set to 'Pending'. How do you configure this?

A.Use a Client Script on the state field.

B.Modify the Form Layout.

C.Use a UI Policy with a condition.

D.Use a Business Rule to check for null notes.

AnswerC

A UI Policy applies client-side logic that can make the Work Notes field mandatory when the State changes to Pending, enforcing completion before submission. This satisfies the requirement to require Work Notes specifically on that state transition.

Why this answer

A UI Policy with a condition is the correct approach because UI Policies are designed to dynamically enforce field-level behavior (mandatory, visible, read-only) on the client side based on form conditions. By setting a condition on the State field (State = Pending), the UI Policy can make the Work Notes field mandatory exactly when the incident enters the Pending state, without writing custom code. This is the declarative, maintainable way ServiceNow intends for this requirement.

Exam trap

CIS-ITSM often tests the confusion between client-side declarative controls (UI Policies) and server-side enforcement (Business Rules/Data Policies), tricking candidates into choosing a Business Rule when the question emphasizes the user-facing form behavior.

How to eliminate wrong answers

Option A is wrong because a Client Script requires custom JavaScript (onChange or onSubmit) and is more error-prone and harder to maintain than a declarative UI Policy for a simple mandatory-field rule. Option B is wrong because modifying the Form Layout only controls which fields appear on the form; it cannot conditionally enforce that a field is mandatory based on another field's value. Option D is wrong because a Business Rule runs server-side and can only validate after submission (or on update), which produces a poor user experience and does not prevent the user from submitting the form with empty Work Notes in the first place.

Practice this question →

MCQhard

An incident manager wants to ensure that when an incident is escalated to a major incident, the 'Major Incident' field is set to true and a notification is sent to the major incident management team. The escalation can happen via a UI Action or automatically via a business rule. Which configuration should be used to meet this requirement?

A.Create a Business Rule that runs after update on the Incident table, checks if the 'Major Incident' field changed to true, and if so, triggers an event that sends a notification to the major incident management team.

B.Create a UI Action that sets the 'Major Incident' field to true and sends a notification directly using the 'gs.eventQueue' method.

C.Create a Notification with a condition that the 'Major Incident' field is true, and set it to send when the record is updated.

D.Create a Business Rule that runs before update on the Incident table, checks if the 'Major Incident' field changes to true, and if so, sends a notification using the 'event' mechanism.

AnswerA

An after update business rule runs after the record is saved, ensuring the change is committed. Triggering an event at this point is the standard way to send notifications asynchronously. The event can be tied to a notification that targets the major incident management team. This approach works regardless of whether the escalation was manual or automatic, as it reacts to the field change.

Why this answer

The requirement is to set the Major Incident field and send a notification when escalation occurs, whether manual or automatic. An after update business rule can detect the change to true and trigger an event, which the notification engine uses to send the email. This ensures the notification is sent only when the field actually changes, and it works regardless of how the escalation was initiated.

A before rule is too early, a UI Action only handles manual, and a simple notification condition lacks change detection.

Exam trap

The trap here is using a before update rule or a UI Action, which either sends notifications prematurely or only works for manual escalations, missing the need for a robust, event-driven approach.

Practice this question →

MCQmedium

An analyst opens an incident and needs to populate several fields quickly with predefined standard text for a VPN connectivity issue. Which ServiceNow feature should the analyst use?

A.Quick Messages

B.Data Policies

C.Incident Templates

D.Catalog Client Scripts

AnswerC

Incident Templates store predefined field values, letting the analyst populate multiple fields with standard VPN text in one action. This directly satisfies the requirement to fill several fields quickly with predefined standard text, avoiding manual re-entry and ensuring consistency across similar incidents.

Why this answer

Incident Templates in ServiceNow allow analysts to quickly populate multiple fields with predefined standard text for common issues like VPN connectivity. Templates can pre-fill short description, description, category, assignment group, and other fields, saving time and ensuring consistency.

Exam trap

The trap is confusing Templates with Quick Messages — candidates may pick Quick Messages because they think of predefined text, but the question specifies populating several fields, which requires Templates.

How to eliminate wrong answers

Option A is wrong because Quick Messages are used for inserting predefined text into a single field (like additional comments or work notes), not for populating multiple fields on a form. Option B is wrong because Data Policies enforce field requirements and read-only behavior, not pre-populate standard text. Option D is wrong because Catalog Client Scripts are used in Service Catalog items to dynamically change form behavior, not for incident field population.

Practice this question →

MCQeasy

An incident record has been closed, and a user calls in reporting the exact same issue is still occurring. What is the recommended ITIL and ServiceNow best practice?

A.Use the Reopen UI action if permitted by system properties and workflow.

B.Delete the closed incident and create a new one.

C.Convert the closed incident into a change request.

D.Modify the closed record state directly via database XML export.

AnswerA

Reopening preserves the original incident's timeline, assignment and audit trail, which ITIL and ServiceNow treat as preferable to raising a duplicate. The Reopen UI action restores the record to an active state, subject to system properties and workflow rules governing whether reopening is permitted.

Why this answer

ITIL and ServiceNow best practice is to reopen the closed incident using the Reopen UI action, which is governed by system properties (such as glide.incident.reopen or the incident state model) and workflow conditions. Reopening preserves the incident's history, SLA data, and relationships, which is essential for accurate reporting and problem management.

Exam trap

CIS-ITSM often tests the misconception that a closed incident should be deleted or recreated, when the correct ITIL-aligned action is to reopen it (subject to system properties and workflow).

How to eliminate wrong answers

Option B is wrong because deleting a closed incident destroys audit history, SLA records, and any linked problem, change, or knowledge articles — and ServiceNow generally restricts deletion of task records for compliance reasons. Option C is wrong because converting an incident to a change request is a different process used when the resolution requires a controlled change, not when a user reports the same unresolved issue. Option D is wrong because modifying a closed record directly via XML export/import bypasses audit trails, business rules, and state model validation, and is explicitly discouraged in ServiceNow administration.

Practice this question →

MCQeasy

An organization wants to ensure that when an incident is resolved, the Caller receives an email notification with a survey link. Which baseline module manages the triggering of this survey?

A.Incident Properties

B.Event Registry

C.SLA Definitions

D.Assessment and Surveys (Assessment Metric Types)

AnswerD

The Assessment and Surveys module holds survey definitions and the assessment metric types that drive them. Configuring a survey there and attaching it to incident resolution triggers the notification email containing the survey link to the Caller.

Why this answer

The Assessment and Surveys module (specifically Assessment Metric Types) manages survey definitions, triggers, and metric types used to generate surveys. When an incident is resolved, a survey can be triggered based on a metric type, and the notification with the survey link is part of that configuration.

Exam trap

The trap is confusing survey triggering with notifications or events — candidates may pick Event Registry because it triggers emails, but the survey definition itself lives in the Assessment and Surveys module.

How to eliminate wrong answers

Option A is wrong because Incident Properties control default field values and behaviors on the incident table, not survey triggering. Option B is wrong because Event Registry defines events that can trigger notifications or scripts, but it does not manage survey definitions or metric types. Option C is wrong because SLA Definitions define service level agreements and their workflows, not surveys.

Practice this question →

Multi-Selectmedium

Which TWO of the following are true about 'Incident Tasks'?

Select 2 answers

A.Closing an incident task automatically closes the parent.

B.They allow for granular work tracking.

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

D.They can only be created by admins.

E.They are child tasks of the incident.

AnswersB, E

Incident Tasks decompose an incident into discrete, assignable units of work, each with its own state, assignment and short description. This granularity lets teams track individual activities separately from the parent incident, satisfying the requirement for detailed, item-level progress visibility across the resolution effort.

Why this answer

Option B is correct because Incident Tasks exist specifically to break an incident down into smaller, individually trackable units of work, giving teams granular visibility into progress on each piece of the resolution effort. Option E is correct because an Incident Task is by definition a child record of the parent incident, inheriting its context and rolling up under it rather than standing alone. Closing a task does not close the parent incident (A), since the parent's state is managed independently and typically requires all work plus resolution to be complete.

Tasks are not automatically assigned to the parent's assignee (C); assignment is set explicitly or by assignment rules. And they are not admin-only (D), as fulfillers and other roles with the appropriate role permissions can create them.

Exam trap

CIS-ITSM often tests the assumption that child task state changes cascade to the parent record — candidates incorrectly pick 'closing a task closes the incident' because that pattern exists in some other ITSM tools.

Practice this question →

MCQmedium

What is the primary function of the 'Incident State' field choices?

A.To determine SLA priority

B.To define user visibility

C.To track the lifecycle stage of an incident

D.To trigger the assignment rule

AnswerC

Incident State records where an incident sits in its lifecycle — New, In Progress, On Hold, Resolved, Closed — driving workflow transitions and reporting. It is distinct from Priority or Assignment Group, which classify urgency and ownership rather than progression.

Why this answer

The Incident State field tracks the lifecycle stage of an incident — values like New, In Progress, On Hold, Resolved, and Closed represent where the incident is in its workflow. It is the primary indicator of progress and drives reporting, SLA pause logic, and closure requirements. It does not itself set priority or assignment.

Exam trap

CIS-ITSM often tests whether candidates confuse State (lifecycle stage) with Priority (SLA urgency) or Assignment (routing), causing them to pick a field that drives a different process.

How to eliminate wrong answers

Option A is wrong because SLA priority is determined by the Priority field (impact × urgency) and SLA definitions, not by State. Option B is wrong because user visibility is controlled by ACLs and the 'opened by'/'caller' relationships, not by the State value. Option D is wrong because assignment rules run based on fields like Category, Subcategory, and Assignment Group, not on State — State changes after assignment typically.

Practice this question →

MCQeasy

Which field on an incident is used to indicate the severity of the business impact?

A.Impact

B.Priority

C.Urgency

D.Severity

AnswerA

Impact records how extensively the incident affects business operations or users, which is the severity of business impact. Urgency measures how quickly resolution is needed; priority is derived from combining impact and urgency, so it is not the impact field itself.

Why this answer

On a ServiceNow incident, the Impact field indicates the severity of the business impact — how broadly the issue affects users or business operations (e.g., 1 - High, 2 - Medium, 3 - Low). Impact is one of the two inputs (along with Urgency) that the system uses to calculate Priority via the priority lookup matrix.

Exam trap

CIS-ITSM often tests the confusion between Impact, Urgency, and Priority — candidates pick Priority thinking it indicates business impact, when Priority is actually the derived output of Impact and Urgency.

How to eliminate wrong answers

Option B is wrong because Priority is a derived value calculated from Impact and Urgency, not the field that indicates business impact severity itself; it represents the overall urgency ranking for resolution. Option C is wrong because Urgency describes how quickly the issue needs resolution from the user's or business's perspective (time sensitivity), not the breadth or severity of business impact. Option D is wrong because 'Severity' is not a standard field on the ServiceNow incident table — it is a distractor term borrowed from other ITSM tools; ServiceNow uses Impact and Urgency to derive Priority.

Practice this question →

MCQmedium

A service desk analyst wants to assign an unassigned incident to themselves with a single click. Which UI Action provides this functionality out of the box?

A.Claim Incident

B.Assign to me

C.Self-Assign

D.Take Ownership

AnswerB

The Assign to me UI Action is shipped out of the box on incident records; it sets the Assigned to field to the current user and saves the record in one click, satisfying the analyst's single-click self-assignment requirement without customisation.

Why this answer

ServiceNow ships an out-of-the-box UI Action named 'Assign to me' on the Incident table that sets the Assigned to field to the current user in a single click. It is a form button visible when the incident is unassigned (or reassignable) and is the standard mechanism analysts use to claim work.

Exam trap

CIS-ITSM often tests whether candidates know the exact out-of-the-box UI Action name — 'Assign to me' — versus plausible but non-existent labels like 'Claim Incident' or 'Self-Assign'.

How to eliminate wrong answers

Option A is wrong because 'Claim Incident' is not a standard out-of-the-box UI Action name on the Incident table — claiming is accomplished via 'Assign to me' or assignment group logic. Option C is wrong because 'Self-Assign' is not a shipped UI Action; it is a plausible-sounding but fabricated label. Option D is wrong because 'Take Ownership' is not a base-system UI Action on Incident; ownership concepts exist in other modules but not as this button.

Practice this question →

MCQhard

What is the correct order of operations when an incident meets criteria for both a standard SLA and an SLA pause condition?

A.The latest SLA created always takes priority

B.Conditions are evaluated based on defined order

C.Only one SLA can be active at a time

D.Pause conditions take precedence over start conditions

AnswerB

When an incident satisfies both a standard SLA and a pause condition, the platform applies the configured evaluation order to determine precedence, so the defined sequence governs which SLA applies and when pausing takes effect rather than either rule overriding arbitrarily.

Why this answer

When an incident qualifies for multiple SLAs, ServiceNow evaluates SLA definitions in a defined order (typically the order field on the SLA definition, or the order in which they are processed). Pause conditions are evaluated as part of the SLA lifecycle, but the overall processing follows the configured order rather than a fixed rule like 'pause always wins'.

Exam trap

CIS-ITSM often tests the misconception that pause conditions always override start conditions or that only one SLA can be active — candidates miss that multiple SLAs can run concurrently and are evaluated in a defined order.

How to eliminate wrong answers

Option A is wrong because the latest-created SLA does not automatically take priority; priority is determined by the SLA definition's order or the processing sequence, not creation timestamp. Option C is wrong because multiple SLAs can be active on a single incident simultaneously (e.g., response and resolution SLAs, or SLAs from different SLA definitions). Option D is wrong because pause conditions do not inherently take precedence over start conditions — both are evaluated according to the SLA engine's processing order and the SLA's own configuration.

Practice this question →

MCQeasy

Which user role is required by default to create, manage, and close incident records within the standard ServiceNow IT Service Management application?

A.snc_read

B.sn_incident_write

C.admin

D.itil

AnswerD

The itil role grants the baseline permissions needed to create, update, and close incident records in ServiceNow ITSM. It satisfies the stem's requirement for default incident management capability, since this role is assigned to fulfil ITIL process tasks without requiring elevated admin rights.

Why this answer

The 'itil' role is the standard user role required to create, manage, and close incident records in ServiceNow ITSM. It grants the necessary permissions to perform these actions without granting full administrative privileges. The other roles either provide read-only access or are too broad.

Exam trap

CIS-ITSM often tests the default roles required for specific actions. Candidates might choose 'sn_incident_write' because it sounds specific to incidents, but the 'itil' role is the standard role that encompasses incident management capabilities.

How to eliminate wrong answers

Option A is wrong because 'snc_read' is a read-only role that allows viewing records but not creating or modifying them. Option B is wrong because 'sn_incident_write' is a role that grants write access to incident records, but it is not the standard role assigned to ITIL users; it is often included as part of the 'itil' role. Option C is wrong because 'admin' has full access but is not the default role for typical incident management; using admin for routine tasks violates the principle of least privilege.

Practice this question →

MCQmedium

Which field must be populated to allow the 'Resolution' tab to be visible or actionable?

A.Incident State

B.Caller

C.Assignment Group

D.Category

AnswerA

The Resolution tab only becomes visible and editable once the incident's State field is populated with a value such as Resolved, since resolution information is captured as part of closing the record. Populating State satisfies the stem's requirement for the tab to be actionable.

Why this answer

In ServiceNow Incident Management, the Resolution tab (or Resolution Information section) becomes visible and actionable only when the Incident State is set to 'Resolved' (or 'Closed'). The State field drives the form's UI behavior, so it must be populated correctly to expose resolution fields like Resolution code and Resolution notes.

Exam trap

CIS-ITSM often tests which field gates the Resolution tab — candidates assume Assignment Group or Category drives form behavior, but it is the Incident State field that controls resolution visibility.

How to eliminate wrong answers

Option B is wrong because Caller identifies who reported the incident but has no bearing on whether the Resolution tab appears. Option C is wrong because Assignment Group determines who works the incident, not the form's resolution visibility. Option D is wrong because Category classifies the incident type but does not control the Resolution tab's visibility or actionability.

Practice this question →

MCQhard

You are designing an integration where incidents are created via an API. How do you ensure that 'Assignment Rules' are triggered?

A.Ensure the API user has the 'itil' role.

B.Set the 'auto_assignment' flag to true.

C.Enable the 'Run Assignment Rules' checkbox in the API call.

D.Leave the assignment fields empty in the API payload.

AnswerD

Assignment rules execute only when the assignment fields arrive empty, letting the engine evaluate and populate them. Supplying values in the API payload bypasses rule evaluation entirely, so leaving those fields blank ensures the configured assignment logic fires.

Why this answer

Assignment Rules in ServiceNow run automatically on incident insert/update only when the assignment fields (assignment_group, assigned_to) are empty. If the API payload leaves these fields blank, the rules execute and assign the incident. If the payload sets them, the rules are skipped.

Exam trap

The trap is inventing API flags like 'auto_assignment' or checkboxes — ServiceNow assignment rules are triggered by the absence of assignment values, not by an explicit toggle.

How to eliminate wrong answers

Option A is wrong because the 'itil' role grants access to the incident table but does not trigger assignment rules — rules run based on field values, not user roles. Option B is wrong because there is no 'auto_assignment' flag in the incident API; assignment rules are controlled by the emptiness of assignment fields. Option C is wrong because there is no 'Run Assignment Rules' checkbox in the API — this is a fabricated option.

Practice this question →

MCQeasy

Where do you configure the email notification that is sent to the 'Caller' when an incident is resolved?

A.Business Rule > Email

B.System Notification > Email > Notifications

C.Incident Form Layout

D.Service Portal Configuration

AnswerB

Caller resolution notifications are defined under System Notification > Email > Notifications, where the notification record for the incident resolved event is configured. Editing that record controls the email dispatched to the caller when the incident reaches the resolved state.

Why this answer

Email notifications in ServiceNow are configured in System Notification > Email > Notifications, where you define the notification trigger (e.g., incident resolved), recipients (e.g., Caller), and email template. This is the baseline module for all outbound notification rules.

Exam trap

The trap is thinking a Business Rule is needed to send email — candidates often pick Business Rule because it's scriptable, but the exam expects the standard notification module for out-of-the-box email configuration.

How to eliminate wrong answers

Option A is wrong because Business Rules are server-side scripts that run on database operations; while a business rule can send an email via gs.eventQueue or GlideEmailOutbound, it is not the configuration module for notifications. Option C is wrong because the Incident Form Layout controls which fields appear on the form, not email behavior. Option D is wrong because Service Portal Configuration manages the portal UI and widgets, not email notifications.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →