Knowledge + Practice

ServiceNow Certified Implementation Specialist - IT Service Management (CIS-ITSM) (CIS-ITSM) (CIS-ITSM) — Questions 1–75

372 questions total · 5 pages · All types, answers revealed

Take a mock exam Exam hub

Page 1 of 5

1

MCQmedium

A change coordinator notices that conflict detection generated a 'Soft Conflict'. How does a soft conflict differ from a hard conflict in ServiceNow?

A.Soft conflicts are generated by manual user input, whereas hard conflicts are automated

B.Soft conflicts provide a warning without automatically blocking progress, whereas hard conflicts can block the change workflow

C.Soft conflicts only apply to standard changes

D.Soft conflicts require CAB approval, while hard conflicts do not

AnswerB

Soft conflicts flag overlapping changes as advisory warnings, letting the coordinator proceed, while hard conflicts enforce a stop by blocking the change workflow. This distinction matches the stem's scenario where the coordinator observes a soft conflict and needs to understand its non-blocking behaviour.

Why this answer

In ServiceNow change management, a soft conflict is a warning that does not block the change workflow, whereas a hard conflict can prevent the change from proceeding or require explicit override. Soft conflicts alert the change coordinator to potential scheduling or CI overlaps but allow the change to continue. This distinction is defined in conflict detection rules.

Exam trap

CIS-ITSM often tests the difference between soft and hard conflicts, and candidates may incorrectly assume soft conflicts block the workflow or require CAB approval.

How to eliminate wrong answers

Option A is wrong because both soft and hard conflicts are generated by automated conflict detection rules, not by manual input. Option C is wrong because soft conflicts apply to all change types, not only standard changes. Option D is wrong because CAB approval requirements are independent of conflict type; hard conflicts may require CAB review, but soft conflicts do not inherently require CAB approval.

Full explanation →

2

MCQmedium

A company wants to automatically retire hardware CIs that have been in an 'In Maintenance' state for more than 180 days without an active update. Which CMDB feature is designed to automate this lifecycle management workflow?

A.Data Certification schedules

B.Lifecycle Management Business Rules

C.CMDB Data Manager

D.Scheduled Jobs with baseline scripts

AnswerC

CMDB Data Manager provides automated lifecycle policies that can retire or archive CIs matching conditions such as prolonged 'In Maintenance' status without updates, removing manual intervention. This directly satisfies the requirement to automate hardware CI retirement after 180 days.

Why this answer

CMDB Data Manager is specifically designed to automate lifecycle management tasks, including the retirement of CIs based on conditions like state and inactivity. It provides policies and schedules to manage CI lifecycles without manual intervention.

Exam trap

CIS-ITSM often tests the confusion between CMDB Data Manager and other CMDB features like Data Certification, leading candidates to select certification for lifecycle automation.

How to eliminate wrong answers

Option A is wrong because Data Certification schedules are used to verify CI data accuracy, not to automate retirement. Option B is wrong because Lifecycle Management Business Rules are custom scripts, not a built-in feature for automated retirement. Option D is wrong because Scheduled Jobs with baseline scripts require custom development and are not a dedicated CMDB feature for lifecycle automation.

Full explanation →

3

Multi-Selectmedium

Which THREE methods can be used to assign incoming Problem records to the correct assignment group automatically? (Choose three.)

Select 3 answers

A.Flow Designer or Workflow assignment logic

B.Assignment Rules

C.Random guessing by junior service desk agents

D.Manually rolling dice in the server room

E.Data Lookup and Matching rules

AnswersA, B, E

Flow Designer and Workflow assignment logic evaluate record conditions at creation, then set the assignment group field automatically via server-side rules — satisfying the stem's requirement for automatic routing of incoming Problem records without manual intervention. This is native platform automation, distinct from client-side UI policies or default value configuration.

Why this answer

Option A (Flow Designer or Workflow assignment logic) is correct because ServiceNow lets you build server-side automation in Flow Designer or Workflow that sets the assignment_group field on a Problem record based on conditions, so the record is routed without human intervention. Option B (Assignment Rules) is correct because Assignment Rules are a native platform mechanism that evaluates conditions on the Problem record and automatically populates the assignment group (and optionally the assigned user) when the record is created or updated. Option E (Data Lookup and Matching rules) is correct because Data Lookup and Matching rules can derive and set field values such as assignment group by matching record attributes against a lookup table, enabling automatic routing of incoming Problems.

Option C (Random guessing by junior service desk agents) is not a valid automated assignment method because it relies on arbitrary human choice and provides no deterministic, rule-based routing. Option D (Manually rolling dice in the server room) is not a supported ServiceNow capability and is purely a joke distractor with no technical mechanism for setting assignment groups.

Exam trap

The trap is including non-automated or nonsensical options — candidates must recognize that only native ServiceNow assignment features (Flow Designer, Assignment Rules, Data Lookup) are valid, while manual or random methods are distractors.

Full explanation →

4

MCQmedium

A problem manager wants to ensure that when a problem is moved to the 'Fix in Progress' state, a specific approval from the change manager is automatically requested before any fix tasks can be created. Which configuration should be used to enforce this requirement?

A.Configure a workflow that, upon entering 'Fix in Progress', creates an approval record and waits for it before proceeding.

B.Use a UI policy to make the 'Fix in Progress' state read-only until an approval is manually attached.

C.Set up a scheduled job that checks for problems in 'Fix in Progress' and sends an email to the change manager for approval.

D.Create a business rule on the Problem table that blocks state changes to 'Fix in Progress' unless an approval record exists.

AnswerA

Workflows are the standard mechanism to automate approvals. By adding an approval activity in the Problem workflow that triggers on the 'Fix in Progress' state, the system automatically generates an approval request and pauses until it is approved. This ensures the change manager's approval is obtained before fix tasks are created, meeting the requirement without custom scripting.

Why this answer

The requirement is to automatically request approval when a problem enters 'Fix in Progress' and ensure no fix tasks are created until approval is granted. ServiceNow workflows natively support approval activities that create approval records and pause execution, providing a controlled and auditable process. This is the standard and most reliable method to enforce such a gate.

Exam trap

The trap here is assuming that business rules or UI policies can handle approval automation, when in fact workflows are the designated tool for orchestrating approvals and state transitions.

Full explanation →

5

MCQhard

An enterprise wants to track availability metrics across different geographies for a global email service offering. Each region has a different uptime target and maintenance window. How should the implementation specialist configure this in ServiceNow SPM?

A.Attach multiple SLA definitions to a single Business Service record

B.Create multiple Service Portfolios with domain separation enabled

C.Create separate Service Offerings under the parent email service for each region

D.Modify the base system SLA workflow using dynamic script includes

AnswerC

Service Offerings sit beneath a parent Service in SPM and each carries its own availability target, maintenance window and support hours. Creating one per region lets the specialist apply distinct uptime commitments and maintenance windows while still reporting against the single global email service.

Why this answer

In ServiceNow SPM, a Service Offering represents a specific variant of a service delivered to a particular audience, region, or with distinct commitments. Creating separate Service Offerings under the parent email service for each region allows each offering to carry its own SLA definitions, uptime targets, and maintenance windows while still rolling up to the same Business Service. This is the CSDM-aligned way to model regional variations of a global service.

Exam trap

CIS-ITSM often tests the confusion between Business Service and Service Offering, tempting candidates to attach SLAs to the Business Service when regional variations require Service Offerings.

How to eliminate wrong answers

Option A is wrong because attaching multiple SLA definitions with different targets to a single Business Service record creates ambiguity — SLA processing would not know which target applies to which region, and the Business Service is meant to be the aggregate, not the per-region commitment holder. Option B is wrong because domain separation is a data segregation mechanism for multi-tenant instances, not a modeling technique for regional service variants; creating multiple portfolios would fragment reporting and misrepresent the service hierarchy. Option D is wrong because modifying base system SLA workflows with dynamic script includes is a customization that breaks upgradeability and is not the intended configuration approach for regional commitments.

Full explanation →

6

MCQmedium

A problem coordinator wants to analyze the effectiveness of the problem management process. They need to see how many problems were reopened after being closed in the last quarter. Which metric or report should they use?

A.Problem reopen rate

B.Problem aging report

C.Mean time to resolve (MTTR) for problems

D.Problem backlog trend

AnswerA

The problem reopen rate metric specifically measures the percentage or count of problems that were reopened after closure. It is a key performance indicator for process quality, as a high reopen rate indicates ineffective root cause analysis or premature closure. This metric directly answers how many problems were reopened in a given period, such as the last quarter.

Why this answer

The problem reopen rate is the metric that counts or calculates the percentage of problems that were closed and subsequently reopened. It is a direct measure of process effectiveness, as reopening indicates that the original resolution did not fully address the root cause. Other metrics like aging, backlog, or MTTR do not specifically track reopen events.

Exam trap

The trap here is confusing metrics that measure volume or duration with those that measure quality, such as reopen rate, which specifically tracks problems that failed closure.

Full explanation →

7

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.

Full explanation →

8

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.

Full explanation →

9

Multi-Selecteasy

Which TWO types of records can be directly linked to a Problem record in standard ServiceNow ITSM? (Choose two.)

Select 2 answers

A.Bank Account

B.Incident

C.Airplane Flight Plan

D.Change Request

E.Real Estate Deed

AnswersB, D

Incidents are linked directly to Problem records so that recurring or related outages roll up into a single root-cause investigation. This satisfies the stem's requirement by naming a record type that standard ServiceNow ITSM permits as a direct Problem association.

Why this answer

Option B (Incident) is correct because in standard ServiceNow ITSM a Problem record can be directly linked to one or more Incidents via the related Incidents related list, allowing multiple incidents with a common root cause to be grouped under a single problem. Option D (Change Request) is correct because a Problem can be directly associated with a Change Request through the related Change Requests related list, typically to implement the fix or workaround identified during problem investigation. Options A (Bank Account), C (Airplane Flight Plan), and E (Real Estate Deed) are not standard ServiceNow ITSM record types and have no native relationship to Problem records, so they cannot be directly linked in the base platform.

Exam trap

CIS-ITSM often tests whether candidates know the standard ITSM record relationships, and the distractor options (Bank Account, Airplane Flight Plan, Real Estate Deed) are absurd non-ITSM records designed to see if you'll pick anything that sounds like a 'record'.

Full explanation →

10

Multi-Selecthard

Which THREE configurations or components are involved when setting up and managing CAB meetings using the CAB Workbench? (Choose three.)

Select 3 answers

A.CAB Definitions (wm_definition)

B.CAB Agenda items (wm_agenda)

C.Incident Major Problem Log

D.CAB Attendees and Meeting instances

E.Risk Assessment Metric Categories

AnswersA, B, D

CAB Definitions (wm_definition) store the meeting configuration records that the CAB Workbench uses to generate and manage meetings. Defining them is a prerequisite component, satisfying the stem's requirement for configurations involved in setting up CAB meetings.

Why this answer

Option A, CAB Definitions (wm_definition), is correct because the CAB Workbench relies on CAB definition records to establish the meeting structure, schedule, and the change criteria that determine which changes populate the agenda. Option B, CAB Agenda items (wm_agenda), is correct because agenda items are the actual change records assembled and reviewed during a CAB meeting, and the Workbench uses the wm_agenda table to organize and present them. Option D, CAB Attendees and Meeting instances, is correct because the CAB Workbench manages meeting instances and their associated attendees (members, guests, and their roles) so that the right participants can review and vote on agenda items.

Option C, Incident Major Problem Log, is not involved because it relates to incident and problem management records, not to the configuration of CAB meetings. Option E, Risk Assessment Metric Categories, is not involved because risk assessment metrics are used for scoring change risk, not for defining or managing CAB meeting setup and structure.

Full explanation →

11

MCQeasy

Which module allows service desk agents to view problems that have been published as known errors?

A.Known Errors

B.Problem Properties

C.Incident Overview

D.Change Schedule

AnswerA

The Known Errors module stores problems whose root cause is identified and for which a workaround exists, publishing them for service desk reference. Agents open this module to view those records, satisfying the requirement to see published known errors.

Why this answer

The 'Known Errors' module in ServiceNow allows service desk agents to view problems that have been published as known errors. Known errors are problems that have a root cause and a workaround, and they are made available to agents to help resolve incidents.

Exam trap

The trap is confusing the Known Errors module with other problem-related modules or incident modules; candidates might think known errors are viewed within incidents or problems, but there is a dedicated module.

How to eliminate wrong answers

Option B is wrong because Problem Properties is a configuration form, not a module for viewing known errors. Option C is wrong because Incident Overview is for viewing incidents, not known errors. Option D is wrong because Change Schedule is for viewing changes, not known errors.

Full explanation →

12

Multi-Selecteasy

Which TWO fields on a Change Request form help determine whether a schedule conflict exists? (Choose two.)

Select 2 answers

A.Planned end date

B.Assignment group

C.Category

D.Planned start date

E.Short description

AnswersA, D

The planned end date marks when a change releases its affected configuration items, so overlapping end times with another change reveal a scheduling conflict. It satisfies the stem's requirement for a field used to detect conflicts.

Why this answer

The Planned start date (D) and Planned end date (A) are the two fields that define the time window during which a change will be implemented, so comparing these dates against other changes' windows is exactly how a schedule conflict (overlapping maintenance windows) is detected. If another approved change's planned start/end overlaps with these dates, a conflict exists; without both boundaries you cannot determine overlap. Assignment group (B) only identifies who will perform the work and does not convey timing.

Category (C) classifies the type of change (e.g., hardware, software) and has no temporal information. Short description (E) is a free-text summary of the change and does not provide structured scheduling data.

Exam trap

CIS-ITSM often tests which fields drive conflict detection — candidates select unrelated fields like Assignment group or Category, not realizing only Planned start date and Planned end date are evaluated.

Full explanation →

13

MCQeasy

Which tab on a Catalog Item form is used to define which categories the item appears under?

A.Categories related list

B.Item Relationships related list

C.Catalogs related list

D.Portal Sections tab

AnswerA

The Categories related list on the Catalog Item form maps the item to one or more category records, controlling where it appears in the service catalogue. Adding entries there satisfies the requirement to define the categories the item is listed under.

Why this answer

The Categories related list on a Catalog Item form is used to associate the item with one or more categories, which determine where the item appears in the catalog browsing structure. This related list allows administrators to define the item's categorization.

Exam trap

CIS-ITSM often tests the distinction between Categories (browsing taxonomy) and Catalogs (container of items), so candidates must not confuse the two related lists.

How to eliminate wrong answers

Option B is wrong because the Item Relationships related list defines relationships between catalog items (e.g., 'requires' or 'bundled with'), not categories. Option C is wrong because the Catalogs related list determines which catalogs the item belongs to, not the categories within a catalog. Option D is wrong because Portal Sections tab is used to configure which portal sections the item appears in, which is a different level of organization than categories.

Full explanation →

14

MCQmedium

You are configuring a Catalog UI Policy to hide a specific variable on a catalog item form. Which setting ensures the policy also applies when the variable is viewed in the Request Item (RITM) form?

A.Reverse if false

B.Catalog conditions

C.Applies on Requested Items

D.Global scope enforcement

AnswerC

Enabling Applies on Requested Items extends the Catalog UI Policy beyond the catalog item form to the RITM form, hiding the variable there too. Applies on Catalog Tasks and Applies on Target Record affect other record types, so they would not satisfy the RITM visibility requirement.

Why this answer

The 'Applies on Requested Items' setting on a Catalog UI Policy ensures the policy's actions (like hiding a variable) also apply when the variable is displayed on the Request Item (RITM) form, not just the initial catalog item form. Without this, the UI policy only affects the catalog item view, and the variable may still appear on the RITM. This is the specific checkbox that extends the policy's scope to requested items.

Exam trap

CIS-ITSM often tests the distinction between catalog item form behavior and RITM form behavior, tricking candidates into choosing 'Reverse if false' or 'Catalog conditions' when the question is about extending a UI policy to requested items.

How to eliminate wrong answers

Option A is wrong because 'Reverse if false' controls whether the policy's actions are inverted when the condition is false — it does not extend the policy to the RITM form. Option B is wrong because 'Catalog conditions' define when the policy runs on the catalog item form, not whether it applies to requested items. Option D is wrong because 'Global scope enforcement' is not a real Catalog UI Policy setting — scope is a development concept (application scope), not a UI policy option.

Full explanation →

15

MCQmedium

A developer needs to ensure that a variable named 'request_justification' becomes mandatory only when another variable 'urgency' has a value of 'High'. Which configuration tool should be used to accomplish this without writing code?

A.Catalog UI Policy

B.Business Rule

C.Data Policy

D.Catalog Client Script

AnswerA

Catalog UI Policies enforce client-side field behaviour on catalog forms, making a variable mandatory based on another variable's value. A UI Policy with a condition of urgency equals High, and a mandatory action on request_justification, satisfies the no-code requirement directly, unlike client scripts or data policies.

Why this answer

Catalog UI Policies are the no-code tool in ServiceNow for dynamically changing the behavior of catalog item variables based on other variable values or user actions. They can make a variable mandatory, read-only, or hidden when a condition is met—exactly the requirement here: set 'request_justification' to mandatory when 'urgency' equals 'High'. Because UI Policies are configuration records, no scripting is needed, satisfying the 'without writing code' constraint.

Exam trap

CIS-ITSM often tests the distinction between client-side UI Policies and server-side Data Policies/Business Rules, and candidates frequently confuse Data Policies (for table fields) with Catalog UI Policies (for catalog variables).

How to eliminate wrong answers

Option B is wrong because Business Rules run on the server side against database records and cannot directly control the client-side mandatory state of catalog variables; they would require scripting and would not achieve the dynamic form behavior. Option C is wrong because Data Policies enforce data integrity at the database level (e.g., mandatory, read-only) but do not apply to catalog item variables on the form; they are used for table fields, not variable sets. Option D is wrong because Catalog Client Scripts require writing JavaScript (e.g., onChange or onLoad) to achieve the same result, violating the no-code requirement.

Full explanation →

16

MCQeasy

Where can a change manager view a graphical representation of planned changes, maintenance windows, and blackouts to identify potential scheduling conflicts?

A.Change Schedule calendar workspace

B.CMDB Health Dashboard

C.Service Portfolio Management dashboard

D.CAB Workbench

AnswerA

The Change Schedule calendar workspace renders planned changes, maintenance windows and blackouts on a shared timeline, so a change manager can visually spot overlapping entries. This directly satisfies the stem's requirement for a graphical representation to identify potential scheduling conflicts, rather than relying on lists or reports.

Why this answer

The Change Schedule calendar workspace in ServiceNow provides a visual timeline view of planned changes, maintenance windows, and blackout periods, enabling change managers to spot scheduling conflicts at a glance. It aggregates change requests and their associated schedules into a single graphical interface, highlighting overlaps and potential collisions. This is the designated tool for proactive conflict identification in the change management process.

Exam trap

CIS-ITSM often tests the distinction between tools for scheduling versus tools for health monitoring or governance, so candidates may confuse the CMDB Health Dashboard or CAB Workbench with the Change Schedule calendar workspace.

How to eliminate wrong answers

Option B is wrong because the CMDB Health Dashboard focuses on the health and completeness of configuration items (CIs) and their relationships, not on change scheduling or conflict detection. Option C is wrong because the Service Portfolio Management dashboard is used for managing the service lifecycle, investment decisions, and service performance, not for visualizing change schedules. Option D is wrong because the CAB Workbench is designed for managing Change Advisory Board meetings, agendas, and approvals, not for providing a graphical representation of change schedules and conflicts.

Full explanation →

17

MCQmedium

An administrator needs to create a variable that allows a user to select a single record from the 'User' (sys_user) table. Which variable type should be selected?

A.List Collector

B.Lookup Select Box

C.Single Line Text

D.Reference

AnswerD

A Reference variable stores a sys_refrence to a single record on a specified table, presenting a lookup that resolves to one sys_user record. This matches the requirement for selecting exactly one record rather than a list.

Why this answer

A Reference variable type allows a user to select a single record from a specified table, such as sys_user. It provides a lookup field with a reference to the target table, ensuring data integrity and enabling dot-walking. This is the standard variable type for selecting one record from another table.

Exam trap

CIS-ITSM often tests the difference between Reference (single record from a table) and List Collector (multiple records), tricking candidates who confuse 'select a single record' with 'select from a list.'

How to eliminate wrong answers

Option A is wrong because a List Collector allows selection of multiple records from a table, not a single record. Option B is wrong because a Lookup Select Box is used to select from a predefined set of choices (a choice list), not from a table of records. Option C is wrong because a Single Line Text variable accepts free-form text input and does not enforce a reference to a table record.

Full explanation →

18

MCQhard

A change request is currently in the 'New' state. You want to automate the transition to 'Assess'. Where do you define this logic in a Change Model?

A.Change Model Flow

B.UI Action on change_request

C.State transition table

D.Business Rule on change_request

E.Workflow properties

AnswerA

The Change Model Flow defines the states and the transitions between them, including any conditions or automation governing movement from 'New' to 'Assess'. Configuring the transition logic there ensures the state change triggers automatically rather than requiring manual intervention.

Why this answer

In ServiceNow Change Management, the Change Model Flow (also called Change Model workflow) defines the states and transitions for a change request, including automated transitions like moving from 'New' to 'Assess'. This is where you configure the logic that drives the state model.

Exam trap

The trap is confusing the Change Model Flow with other configuration elements like Business Rules or UI Actions; candidates may think any automation is done via Business Rules, but state transitions are specifically defined in the Change Model.

How to eliminate wrong answers

Option B is wrong because a UI Action is a button or link on a form, not the underlying state transition logic. Option C is wrong because there is no standard 'State transition table' in Change Management; state transitions are defined in the Change Model. Option D is wrong because a Business Rule is server-side script logic that can trigger on database operations, but it is not the designated place to define the change model's state flow.

Option E is wrong because Workflow properties are used in legacy Workflow editor, but the Change Model Flow is the correct place for state transitions in the current Change Management model.

Full explanation →

19

Multi-Selectmedium

Which TWO of the following options correctly describe Record Producers? (Choose two.)

Select 2 answers

A.They always create a parent Request [sc_request] and Requested Item [sc_req_item] instead of a target table record.

B.They generate a record on a target table, such as Incident or Task.

C.They cannot contain variable sets.

D.They are restricted to administrators only and cannot be accessed by end users.

E.They use variables to capture user input that can be mapped to fields on the target record.

AnswersB, E

Record Producers create records on a specified target table, such as Incident or Task, satisfying the stem's requirement that they generate records. This is their defining function: a catalogue item or producer configuration maps submitted variables directly onto fields of the target table, producing a new record without the user accessing that table directly.

Why this answer

Option B is correct because a Record Producer's defining behavior is to insert a new record into a specified target table, such as Incident, Task, or a custom table, rather than being limited to request/requested-item creation. Option E is correct because Record Producers present catalog variables (including variable sets) that capture user input, and these variables can be mapped via the producer's script or field mapping to populate fields on the generated target record. Option A is incorrect because Record Producers do not always create sc_request and sc_req_item records; that is the behavior of standard catalog items, whereas producers create the target table record directly.

Option C is incorrect because Record Producers can contain variable sets just like other catalog items. Option D is incorrect because Record Producers are catalog items that can be published to the service catalog and accessed by end users, not restricted to administrators.

Exam trap

CIS-ITSM often tests the misconception that Record Producers always create Request and Requested Item records, when they can create records directly on any target table.

Full explanation →

20

Multi-Selectmedium

Which TWO steps are required to publish a new Standard Change template from a proposal? (Choose two.)

Select 2 answers

A.Publish the proposal to make it available in the Standard Change Catalog

B.Execute an automated network vulnerability scan

C.Convert the proposal into an Emergency Change record

D.Review and authorize the standard change proposal

E.Manually write a custom Business Rule for every proposal

AnswersA, D

Publishing the proposal promotes the approved change proposal into the Standard Change Catalog, satisfying the requirement that the template becomes selectable for future standard changes. Without this publication step, the proposal remains a draft and never appears in the catalog, so the template cannot be used.

Why this answer

Option A is correct because publishing the proposal is the step that actually makes the new Standard Change template available in the Standard Change Catalog, moving it from a draft/proposal state into the catalog where it can be selected for future changes. Option D is correct because a standard change proposal must first be reviewed and authorized by the appropriate approval body before it can be published; this governance step validates that the change is low-risk, repeatable, and suitable for pre-approved treatment. Options B, C, and E are incorrect: an automated network vulnerability scan is not a prerequisite for publishing a standard change template, converting the proposal into an Emergency Change record contradicts the purpose of a pre-approved standard change, and manually writing a custom Business Rule for every proposal is neither required nor scalable for standard change publication.

Exam trap

The trap is thinking that publishing a Standard Change template requires technical steps like writing business rules or performing scans, when it's actually a governance process of review, authorization, and publication.

Full explanation →

21

MCQeasy

A technician wants to view the graphical relationship hierarchy of a Business Service and its underlying servers. Which feature should they open from a CI record?

A.Relationship Builder

B.CMDB Dashboard

C.CI Class Manager

D.Dependency View

AnswerD

Dependency View renders the graphical relationship hierarchy directly from a CI record, mapping the Business Service to its underlying servers and downstream dependencies. This satisfies the requirement to visualise the service's composition without running reports or queries, showing parent-child relationships across configuration items in Microsoft Entra ID-integrated environments.

Why this answer

Dependency View is the correct feature because it provides a graphical, hierarchical visualization of a CI and its relationships — showing a Business Service at the top and its underlying servers, applications, and infrastructure beneath it. It is accessible directly from a CI record via the 'Dependency Views' related link or the Dependency View UI action. This is the standard way to see service-to-infrastructure mapping in ServiceNow ITSM.

Exam trap

CIS-ITSM often tests the confusion between Relationship Builder (create/edit relationships) and Dependency View (visualize them) — candidates pick the builder because it sounds more powerful, but the question asks for graphical hierarchy viewing.

How to eliminate wrong answers

Option A is wrong because Relationship Builder is a tool for creating and editing CI relationships, not for visualizing the hierarchy graphically. Option B is wrong because CMDB Dashboard shows aggregate health metrics and KPIs, not a per-CI graphical hierarchy. Option C is wrong because CI Class Manager is used to manage CI class definitions, attributes, and identification rules — it has nothing to do with viewing relationships.

Full explanation →

22

Multi-Selectmedium

Which TWO components are part of the CAB Workbench meeting structure? (Choose two.)

Select 2 answers

A.Agenda management listing change requests to be reviewed

B.Attendee tracking and voting interfaces

C.Service Portfolio management dashboards

D.CMDB Discovery schedule configuration screens

E.Automated software patch deployment pipelines

AnswersA, B

Agenda management lists the change requests queued for review during a CAB Workbench meeting, giving the meeting its structured order of business. This is a core component of the meeting structure the stem asks about.

Why this answer

Option A is correct because the CAB Workbench meeting structure centers on agenda management, which lists the change requests (typically in 'ready for review' state) that the Change Advisory Board will review during the meeting. Option B is correct because the CAB Workbench provides attendee tracking and voting interfaces, allowing members to record attendance and cast votes (such as approve or reject) on each change request directly within the meeting. Options C, D, and E are incorrect because Service Portfolio management dashboards, CMDB Discovery schedule configuration, and automated software patch deployment pipelines are separate ServiceNow capabilities unrelated to the CAB Workbench meeting structure.

Exam trap

CIS-ITSM often tests the distinction between CAB Workbench meeting components and general change management or CMDB features, causing candidates to select unrelated administrative dashboards.

Full explanation →

23

Multi-Selectmedium

A service catalog administrator needs to make a catalog item available only during a specific two-week window each quarter and also prevent it from appearing to users who are not in the 'Finance' department. Which TWO configurations should the administrator use? (Choose two.)

Select 2 answers

A.Configure a Catalog UI Policy that hides the item from users outside Finance.

B.Set the catalog item's Start date and End date fields to define the availability window.

C.Use a scheduled job to activate and deactivate the item each quarter.

D.Add an access control list entry on the sc_cat_item table that denies read to non-Finance users.

E.Create a user criteria record that includes the 'Finance' department and attach it to the catalog item's Available for list.

AnswersB, E

Catalog items include Start date and End date fields on the item record that control when the item is orderable. Setting these dates restricts availability to the desired two-week quarterly window without scripting, directly satisfying the time-bound requirement.

Why this answer

Catalog items support Start date and End date fields for time-bound availability and user criteria for audience targeting. Setting the dates limits ordering to the quarterly window, and attaching Finance department criteria to the Available for list ensures only that department sees the item. Together these two native configurations meet both requirements without custom code.

Exam trap

The trap here is reaching for ACLs or Catalog UI Policies to control who sees a catalog item, when user criteria and the item's date fields are the intended visibility controls.

Full explanation →

24

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.

Full explanation →

25

Multi-Selectmedium

Which TWO of the following entities can be restricted using User Criteria in the Service Catalog? (Choose two.)

Select 2 answers

A.Workflow Activity Types

B.Catalog Categories

C.Catalog Items

D.Individual Catalog Variables

E.Service Portal Widgets

AnswersB, C

User Criteria can be applied to catalog categories, restricting which users see an entire grouping of items in the Service Catalog. This satisfies the stem's constraint because category-level restriction governs visibility of all contained items, complementing item-level criteria.

Why this answer

User Criteria in the Service Catalog is used to control visibility and access to catalog content based on conditions such as user role, department, or group. Option B, Catalog Categories, is correct because User Criteria can be applied to categories to restrict which users can see or access those categories in the catalog. Option C, Catalog Items, is also correct because User Criteria can be assigned to individual catalog items to determine which users are eligible to view or order them.

Option A, Workflow Activity Types, is not restricted via User Criteria; workflow activities are controlled through workflow configuration and conditions, not catalog user criteria. Option D, Individual Catalog Variables, is not restricted via User Criteria; variable visibility is managed through variable attributes and UI policies, not user criteria. Option E, Service Portal Widgets, is not restricted via User Criteria; widget visibility is controlled through portal configuration, roles, and widget instances, not catalog user criteria.

Exam trap

CIS-ITSM often tests the misconception that User Criteria can be applied to any catalog-related record (variables, widgets, workflows), when in fact only Categories and Catalog Items expose the User Criteria related lists.

Full explanation →

26

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.

Full explanation →

27

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.

Full explanation →

28

MCQhard

When using the CAB Workbench, meeting attendees can vote on change requests. Where are these votes stored in the database?

A.asmt_assessment_instance

B.wm_decision and related CAB meeting tables

C.approval_history

D.sys_audit

AnswerB

Votes cast in the CAB Workbench are persisted in the wm_decision table, which records each attendee's decision against the change request, with related CAB meeting tables holding the agenda and attendee context. This satisfies the stem's requirement for the exact database location where CAB Workbench votes are stored.

Why this answer

The CAB Workbench stores meeting decisions and attendee votes in the wm_decision table along with related CAB meeting tables (such as wm_meeting, wm_decision_question, and wm_decision_answer). These tables are part of the Change Management CAB Workbench plugin and are purpose-built to capture voting outcomes, decision types (approve/reject/abstain), and meeting context. This is distinct from the generic assessment or approval tables used elsewhere in the platform.

Exam trap

CIS-ITSM often tests the confusion between CAB Workbench voting tables (wm_*) and the more familiar approval tables (sysapproval_approver, approval_history), causing candidates to pick approval_history by default.

How to eliminate wrong answers

Option A is wrong because asmt_assessment_instance stores assessment questionnaire instances (used for risk assessments and surveys), not CAB meeting votes. Option C is wrong because approval_history tracks approval record state changes for approval records (sysapproval_approver), not CAB workbench voting decisions. Option D is wrong because sys_audit is the generic field-level audit trail that logs changes to any record, not a dedicated store for CAB votes.

Full explanation →

29

MCQeasy

What is the primary function of an Order Guide in the ServiceNow Service Catalog?

A.To guide users through a questionnaire and help them submit multiple related catalog items in a single request.

B.To automate the generation of Knowledge Base articles from resolved requests.

C.To enforce approval chains across multiple departments before submission.

D.To restrict catalog items based on user roles and company location.

AnswerA

An Order Guide presents a questionnaire that branches based on answers, then bundles the resulting related catalog items into one cart and request. This satisfies the need to submit multiple linked items together rather than as separate orders.

Why this answer

An Order Guide in the ServiceNow Service Catalog is a wizard-style interface that presents a series of questions (via a catalog UI policy or variable set) and, based on the answers, generates a single request containing multiple related catalog items (a 'bundle'). It is designed to simplify multi-item ordering by guiding the user through a decision tree and automatically adding the appropriate items to the cart. This reduces the need for users to search for and add each item individually.

Exam trap

CIS-ITSM often tests the distinction between Order Guides and other catalog features like Record Producers or Catalog UI Policies; candidates may confuse the multi-item bundling capability with approval or visibility controls.

How to eliminate wrong answers

Option B is wrong because Knowledge Base article generation is handled by Knowledge Management workflows or the 'Article' creation process, not by Order Guides. Option C is wrong because approval chains are enforced by workflow/approval engines or catalog item approval configurations, not by Order Guides themselves. Option D is wrong because restricting catalog items based on user roles or location is done through User Criteria, Access Control Lists (ACLs), or catalog item visibility settings, not Order Guides.

Full explanation →

30

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.

Full explanation →

31

MCQeasy

What is the primary function of the Catalog Task [sc_task] table in Request Fulfillment?

A.To store the catalog item definition and pricing details.

B.To act as the top-level shopping cart container.

C.To represent individual work assignments generated during request fulfillment.

D.To track approvals required from department managers.

AnswerC

The sc_task table stores the individual fulfilment tasks spawned from a requested item, each assigned to a group or user. It captures the discrete work assignments that drive a request through fulfilment, distinct from the request itself.

Why this answer

The Catalog Task [sc_task] table is the workhorse of Request Fulfillment in ServiceNow. When a catalog item is ordered and the request [sc_request] and requested item [sc_req_item] records are created, the fulfillment workflow or flow generates one or more sc_task records, each representing a discrete unit of work assigned to a fulfillment group or individual. This is why sc_task is described as representing individual work assignments generated during request fulfillment.

Exam trap

CIS-ITSM often tests the distinction between the request lifecycle tables — sc_request (container), sc_req_item (what was ordered), and sc_task (the work) — so candidates who confuse the cart, request, or approval tables with the task table pick the wrong answer.

How to eliminate wrong answers

Option A is wrong because catalog item definitions and pricing are stored in the Catalog Item [sc_cat_item] table (with pricing on the item or via price fields), not in sc_task. Option B is wrong because the top-level shopping cart container is the Cart [sc_cart] table (with cart items in sc_cart_item), which exists before checkout and is unrelated to task fulfillment. Option D is wrong because approvals are tracked in the Approval [sysapproval_approver] table, which references the requested item or request, not in sc_task.

Full explanation →

32

MCQhard

A custom catalog item requires variable validation that depends on complex calculations spanning multiple fields, which cannot be achieved using standard UI Policy conditions. What is the best method to implement this client-side validation before the user submits the form?

A.Dictionary Client Script

B.UI Action with client-side script

C.Catalog Client Script (onSubmit) returning false upon failure

D.Business Rule (Before Insert)

AnswerC

A Catalog Client Script with an onSubmit script runs complex JavaScript across multiple fields and can return false to block submission. This handles calculations beyond UI Policy conditions, enforcing validation client-side before the form is submitted.

Why this answer

A Catalog Client Script with an onSubmit script is the correct choice because it runs client-side when the user submits the catalog item form and can return false to block submission. This allows complex, multi-field calculations and validation logic in JavaScript before the record is created. UI Policies cannot handle complex calculations, so a client script is required.

Exam trap

CIS-ITSM often tests the confusion between client-side onSubmit validation (which blocks submission) and server-side Business Rules (which run after submission), causing candidates to pick the Business Rule for pre-submit validation.

How to eliminate wrong answers

Option A is wrong because a Dictionary Client Script runs on the server against a table dictionary and is not designed for catalog form validation or multi-field client-side calculations. Option B is wrong because a UI Action with client-side script is typically used for buttons/links on forms, not for intercepting catalog item submission validation. Option D is wrong because a Business Rule (Before Insert) runs server-side after submission, so it cannot prevent the user from submitting the form in the first place — it can only abort the insert after the fact.

Full explanation →

33

MCQhard

During a CAB review, a Change Manager notices that a Normal Change has an assigned Change Task for a database migration, but the task was never completed and the change was still moved to Review. The Change Manager wants to ensure that a Change Request cannot transition to Review until all of its Change Tasks are closed complete. What should the Change Manager configure to enforce this requirement?

A.A business rule on the Change Request table that aborts the transition when open Change Tasks exist

B.A UI policy on the Change Task table that makes the State field mandatory

C.A client script on the Change Request form that displays an alert when Change Tasks are open

D.A workflow activity on the Change Request workflow that waits for Change Tasks to close

AnswerA

A before business rule on the Change Request table can query related Change Tasks and abort the state transition to Review if any remain open. This enforces the gate at the data layer regardless of how the transition is triggered, including list edits and workflow. It is the correct server-side control for preventing the transition until all tasks are closed complete.

Why this answer

Enforcing a lifecycle gate requires server-side validation on the Change Request record itself. A before business rule can query related Change Tasks and abort the transition to Review whenever any task is not closed complete, covering form edits, list edits, and API updates alike. Client-side or workflow-only controls are bypassable and therefore insufficient for this compliance requirement.

Exam trap

The trap here is assuming a workflow wait or client-side alert reliably blocks a state transition, when only a server-side rule prevents all paths to Review.

Full explanation →

34

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.

Full explanation →

35

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.

Full explanation →

36

MCQmedium

When using the CAB Workbench, how is a meeting agenda created?

A.Defined in the Change Request form.

B.Manually add each change.

C.Set by the CAB manager in the meeting.

D.Generated automatically by the CAB Definition.

E.Imported via Excel.

AnswerD

The CAB Definition drives agenda creation: the workbench reads its configuration and automatically generates the meeting agenda from the changes and items it specifies. No manual agenda assembly is required, satisfying the stem's question about how the agenda is produced.

Why this answer

The CAB Workbench agenda is driven by the CAB Definition record, which specifies the meeting schedule, related change filters, and agenda item sources. When a CAB meeting is opened in the Workbench, the system automatically populates the agenda with changes that match the CAB Definition's criteria (such as changes in the 'Assess' or 'Authorize' state assigned to that CAB). This means the agenda is generated automatically rather than assembled by hand.

Exam trap

CIS-ITSM often tests the misconception that the CAB agenda is manually curated by the CAB manager, when in fact the CAB Definition record auto-generates it based on filters.

How to eliminate wrong answers

Option A is wrong because the Change Request form captures change details and approvals, not the CAB meeting agenda structure. Option B is wrong because manually adding each change defeats the purpose of the Workbench, which is designed to auto-aggregate agenda items from the CAB Definition. Option C is wrong because the CAB manager does not hand-build the agenda in the meeting; the CAB Definition drives it.

Option E is wrong because there is no Excel import mechanism for CAB agendas in the base platform.

Full explanation →

37

Multi-Selectmedium

Which THREE actions can be performed directly from a Problem record form using baseline UI Actions or related lists? (Choose three.)

Select 3 answers

A.Create a Known Error Article

B.Create a Problem Task

C.Automatically reboot all linked server CIs

D.Create a Change Request

E.Convert the problem directly into an HR Case

AnswersA, B, D

The Problem form provides a UI Action to create a Known Error article, publishing the root cause and workaround to the knowledge base. This satisfies the requirement because the action is invoked directly from the Problem record, not through a separate knowledge workflow.

Why this answer

Option A (Create a Known Error Article) is correct because the Problem form includes a baseline UI Action that lets an agent create a Known Error article, typically by generating it from the problem's information and linking it back to the Problem record. Option B (Create a Problem Task) is correct because the Problem form provides a baseline UI Action and a Problem Tasks related list that allow agents to add child Problem Task records to break the investigation into work items. Option D (Create a Change Request) is correct because the baseline Problem form offers a UI Action to create a Change Request when a fix requires a change, linking the change to the problem for traceability.

Option C is not correct because rebooting linked server CIs is not a baseline Problem UI Action or related-list function; that would require orchestration, workflow, or a custom action. Option E is not correct because converting a Problem directly into an HR Case is not a baseline capability of the Problem form and would require custom configuration.

Exam trap

CIS-ITSM often tests the boundary between baseline problem actions and cross-application actions — candidates pick HR Case or CI reboot because they sound plausible, but they are not baseline UI actions on the Problem form.

Full explanation →

38

MCQhard

If you perform a 'Mass Update' on multiple Change Requests, which feature ensures that risk assessments are recalculated for every record?

A.Scheduled Job

B.Business Rule

C.Flow Designer

D.UI Policy

E.Client Script

AnswerB

A Business Rule runs server-side on every record write, including those triggered by a Mass Update, so it can recalculate the risk assessment fields for each affected Change Request. This satisfies the stem's requirement that every record's assessment is refreshed, not just the first.

Why this answer

When performing a Mass Update on multiple Change Requests, a Business Rule ensures that risk assessments are recalculated for every record. Business Rules run on the server for each record during the mass update, allowing the system to recalculate risk based on the updated data. This is the standard mechanism for enforcing logic across multiple records.

Exam trap

The trap is assuming that client-side scripts or UI policies will run during a mass update, but they do not because mass updates bypass the UI. Candidates must remember that server-side business rules are the correct tool for enforcing logic on bulk operations.

How to eliminate wrong answers

Option A is wrong because a Scheduled Job runs at defined times and is not triggered by a mass update; it would not recalculate risk in real-time for each record. Option C is wrong because Flow Designer is used for automation and orchestration, but it does not automatically trigger on mass updates unless explicitly configured, and it is not the typical mechanism for recalculating risk on each record. Option D is wrong because a UI Policy only affects the user interface and does not run on the server during mass updates.

Option E is wrong because a Client Script runs in the browser and is not executed during a mass update, which is a server-side operation.

Full explanation →

39

MCQmedium

When a Standard Change proposal is submitted, what is its initial state before approval?

A.Draft / Submitted

B.Approved

C.Published

D.Closed

AnswerA

A Standard Change proposal begins in Draft or Submitted state, before any approval workflow runs. It only advances to Assessed or Approved once the change authority reviews it, so this initial state precedes authorisation and scheduling.

Why this answer

The [CORRECT] answer is A. When a Standard Change proposal is first submitted, it enters a 'Draft' or 'Submitted' state, awaiting review and approval by the change management process. It is not yet approved, published, or closed.

The initial state reflects that the proposal has been created but not yet vetted.

Exam trap

The trap is confusing the initial state with later states like Approved or Published; candidates must remember that a proposal starts as Draft/Submitted before any approval occurs.

How to eliminate wrong answers

Option B is wrong because 'Approved' is a later state that occurs after the proposal has been reviewed and accepted; it is not the initial state. Option C is wrong because 'Published' is a state for a standard change template that has been approved and made available for use; it comes after approval. Option D is wrong because 'Closed' is a final state after the change has been implemented and verified, not an initial state.

Full explanation →

40

MCQeasy

Which tab or related list on a Problem record displays the individual tasks assigned to various groups to investigate specific components of the root cause?

A.Problem Tasks

B.Child Incidents

C.Outages

D.Affected CIs

AnswerA

Problem Tasks is the related list holding the individual task records assigned to groups investigating specific components of the root cause. It captures the decomposition of the investigation, distinguishing it from the broader Problem record fields and unrelated lists.

Why this answer

The Problem Tasks tab or related list on a Problem record is specifically designed to hold individual tasks that are assigned to different groups to investigate specific components of the root cause. These tasks allow for parallel investigation and are a core part of the Problem Management process in ServiceNow. Child Incidents, Outages, and Affected CIs serve different purposes and do not represent the breakdown of root cause investigation work.

Exam trap

CIS-ITSM often tests the distinction between related lists on Problem records, and candidates may confuse Child Incidents (which are linked incidents) with Problem Tasks (which are the actual investigation tasks).

How to eliminate wrong answers

Option B is wrong because Child Incidents are incidents that are linked to the problem, typically to indicate they may share a common root cause, but they are not tasks assigned for investigation. Option C is wrong because Outages record unplanned downtime events or service outages, not the individual investigation tasks. Option D is wrong because Affected CIs list the configuration items that are impacted by the problem, not the tasks to investigate the root cause.

Full explanation →

41

MCQeasy

What is the primary benefit of utilizing Change Models in modern ServiceNow implementations?

A.They generate automatic invoices for IT services

B.They allow tailoring workflows, states, and rules for different change types

C.They replace the need for the CMDB entirely

D.They automatically discover software vulnerabilities on network assets

AnswerB

Change Models decouple change types from a single rigid workflow, letting each type define its own states, approvals, and rules. This satisfies the need to tailor process behaviour per change type rather than forcing one flow across all changes.

Why this answer

Change Models in ServiceNow allow organizations to tailor workflows, states, rules, and approval processes for different types of changes (e.g., standard, normal, emergency). This enables differentiated governance — a low-risk standard change can follow a streamlined flow, while a high-risk normal change requires full CAB review. The primary benefit is this flexibility and alignment of process rigor with change risk.

Exam trap

CIS-ITSM often tests the purpose of Change Models — candidates confuse them with CMDB or security functions, or assume they are purely cosmetic, missing that they drive workflow, states, and approval differentiation.

How to eliminate wrong answers

Option A is wrong because Change Models have nothing to do with invoicing — they are workflow and governance configurations, not financial tools. Option C is wrong because Change Models do not replace the CMDB; the CMDB remains the authoritative source of CI data, and Change Models reference CIs but do not substitute for them. Option D is wrong because vulnerability discovery is handled by Security Operations (e.g., Vulnerability Response, Qualys integrations), not Change Models — Change Models govern change process flow, not asset scanning.

Full explanation →

42

MCQhard

An organization requires that emergency changes bypass standard CAB approval but still require approval from a specific Incident Commander group. Which feature should be configured to achieve this without writing custom business rules?

A.Change Models and associated Approval Definitions

B.Change Management - State Model properties

C.Out-of-the-box Emergency CAB definition

D.Change Risk Calculator script

AnswerA

Change Models let you attach approval definitions that override the standard CAB flow for a specific change type, so emergency changes route to the Incident Commander group instead. This satisfies the bypass-without-custom-code constraint, since the model's approval definition is declarative configuration rather than a business rule.

Why this answer

Change Models in ServiceNow allow you to define the end-to-end lifecycle of a change type, including which approval definitions apply at each state. By creating a dedicated Change Model for emergency changes and attaching an Approval Definition that targets the Incident Commander group, you can enforce the required approval without writing custom business rules. This is the declarative, supported way to customize approval routing per change type.

Exam trap

The trap here is assuming that emergency changes must be handled by modifying the out-of-the-box Emergency CAB or by writing business rules, when Change Models with Approval Definitions are the intended no-code solution.

How to eliminate wrong answers

Option B is wrong because State Model properties control state transitions and mandatory fields, not approval routing to specific groups. Option C is wrong because the out-of-the-box Emergency CAB definition still routes to a CAB, not to an Incident Commander group, and modifying it would require customization. Option D is wrong because the Change Risk Calculator script computes risk scores; it has nothing to do with approval group assignment.

Full explanation →

43

Multi-Selecthard

An implementation specialist is designing an Order Guide that triggers three different child items based on user selections. Which THREE of the following components are essential parts of configuring this Order Guide? (Choose three.)

Select 3 answers

A.Child Catalog Items that are active and accessible to the submitting user.

B.Order Guide Rule Base rules to determine when child items are included.

C.Catalog UI Policies mapped specifically to the order guide container.

D.A scheduled job on sc_cart to purge abandoned order guides.

E.Prompt variables to collect initial user information shared across items.

AnswersA, B, E

Child catalog items must be active and accessible to the submitting user, otherwise the Order Guide cannot add them to the request or the user cannot order them. This satisfies the requirement that three different child items are triggered, since inactive or restricted items would break the branching outcome.

Why this answer

Option A is correct because an Order Guide can only include child catalog items that are active and available to the user submitting the request; inactive or access-restricted items cannot be added to the guide. Option B is correct because Order Guide rules (defined in the Order Guide Rule Base) evaluate conditions and determine which child items are automatically included or excluded based on the user's selections. Option E is correct because prompt variables (also called Order Guide variables) collect initial user input that is shared across the child items, driving the rule logic and pre-populating item variables.

Option C is incorrect because Catalog UI Policies apply to individual catalog items or variable sets, not to an Order Guide container as a distinct configuration component. Option D is incorrect because a scheduled job to purge abandoned sc_cart records is unrelated to Order Guide configuration and is not required for triggering child items.

Exam trap

CIS-ITSM often tests the misconception that UI Policies or scheduled jobs are part of Order Guide configuration, when the essential trio is child items, Rule Base rules, and prompt variables.

Full explanation →

44

MCQhard

An organization wants to ensure that change tasks of type 'Implementation' cannot be closed unless the parent change request is in the 'Implement' state. How is this relationship typically enforced?

A.Business rules and state validation on the change_task table

B.Client scripts running on the portal view

C.Dictionary overrides on the state field

D.CMDB class relationship definitions

AnswerA

Business rules and state validation on the change_task table enforce conditional logic, blocking closure of Implementation tasks unless the parent change request sits in the Implement state. This server-side validation guarantees the dependency regardless of client-side UI behaviour.

Why this answer

The relationship between change tasks and the parent change request's state is enforced through business rules and state validation on the change_task table. Business rules can run before insert/update/delete to check the parent's state and prevent closing the task if the parent is not in the 'Implement' state. This is a server-side validation that ensures data integrity.

Exam trap

The trap is assuming that client-side scripts or UI policies can enforce data integrity, but they can be bypassed. Candidates must remember that server-side business rules are required for robust validation.

How to eliminate wrong answers

Option B is wrong because client scripts run in the browser and can be bypassed; they are not suitable for enforcing critical data validation. Option C is wrong because dictionary overrides are used to change field properties (like making a field mandatory) but do not enforce cross-record state dependencies. Option D is wrong because CMDB class relationships define how CIs relate, not how task states are validated.

Full explanation →

45

MCQmedium

An IT manager wants to ensure that whenever a Problem is resolved, a survey is automatically sent to the caller of each associated active incident. Which ServiceNow feature manages survey triggers upon task resolution?

A.Email Client Template rules

B.Assessments / Trigger Conditions

C.Data Lookup definitions for surveys

D.UI Action Survey buttons

AnswerB

Assessments with trigger conditions fire a survey automatically when the associated task resolves, sending it to each active incident caller. This is the native ServiceNow mechanism for conditional, resolution-triggered surveys rather than manual or notification-based approaches.

Why this answer

ServiceNow's Assessments (Survey) module uses Trigger Conditions to define when a survey is dispatched. An administrator configures a trigger condition on the survey (e.g., Problem state changes to Resolved) and a recipient source, which can include callers of associated incidents, so surveys fire automatically on resolution.

Exam trap

CIS-ITSM often tests confusion between notification mechanics and survey mechanics — candidates pick Email Client Templates or UI Actions, not realizing surveys are governed by Assessment Trigger Conditions, not email or form logic.

How to eliminate wrong answers

Option A is wrong because Email Client Templates format outbound email content; they do not evaluate task state or determine survey recipients. Option C is wrong because Data Lookup definitions resolve field values from reference tables — they have no role in triggering surveys. Option D is wrong because UI Actions are buttons rendered on forms; they require manual user interaction and cannot automatically send surveys on state change.

Full explanation →

46

MCQeasy

An implementation specialist is setting up the Service Portfolio in ServiceNow and needs to define the top-level container that groups services based on business units and strategic objectives. Which record type should the specialist create first?

A.Service Classification

B.Business Service

C.Service Offering

D.Service Portfolio

AnswerD

The Service Portfolio is the top-level container that groups services by business unit and strategic objective, so it must exist before services are catalogued. Creating it first satisfies the stem's requirement to define the highest-level grouping record.

Why this answer

The Service Portfolio is the top-level container that groups services based on business units and strategic objectives. It is the highest-level record in the Service Portfolio hierarchy and must be created first before defining Business Services, Service Offerings, or Service Classifications.

Exam trap

CIS-ITSM often tests the hierarchy of the Service Portfolio — candidates confuse the top-level container (Service Portfolio) with the services themselves (Business Service) or their offerings, leading them to select a lower-level record type.

How to eliminate wrong answers

Option A is wrong because Service Classification is a categorization mechanism used within the portfolio, not the top-level container. Option B is wrong because Business Service is a lower-level record that resides within the Service Portfolio, not the top-level container itself. Option C is wrong because Service Offering is a specific offering within a Business Service, and it cannot exist without a parent Business Service and Portfolio.

Full explanation →

47

Multi-Selecteasy

Which TWO tasks are typically performed during the 'Review' state of a normal change? (Choose two.)

Select 2 answers

A.Performing risk assessment questionnaires

B.Running initial conflict detection and scheduling

C.Submitting standard change proposals to the catalog

D.Verifying whether the change was successful and documenting lessons learned

E.Conducting a Post Implementation Review (PIR)

AnswersD, E

The Review state confirms the change achieved its intended outcome and captures lessons learned for future improvements. Verifying success and documenting findings closes the change record, distinguishing Review from the authorisation and implementation stages of the normal change lifecycle.

Why this answer

Option D is correct because the Review state of a normal change includes verifying that the change achieved its intended outcome and documenting lessons learned for future improvements. Option E is correct because conducting a Post Implementation Review (PIR) is a core activity in the Review state, where stakeholders assess the change's success, identify any issues, and confirm closure. Options A and B are incorrect because risk assessment questionnaires and initial conflict detection/scheduling occur during the Assess and Authorize or planning states, before implementation.

Option C is incorrect because submitting standard change proposals to the catalog relates to the standard change lifecycle, not the Review state of a normal change.

Exam trap

The trap is mixing up activities from the Assess state (risk assessment, conflict detection) with the Review state (verification, PIR), causing candidates to select early-lifecycle tasks.

Full explanation →

48

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.

Full explanation →

49

MCQmedium

An order guide is configured with three catalog items. The administrator wants to ensure that a specific item in the order guide is only displayed in the rule base when the user selects 'International' in a location variable. Where is this condition specified?

A.Workflow switch activity

B.Order Guide Rule Base condition builder

C.Variable Set mapping table

D.Catalog UI Policy on the parent order guide

AnswerB

The rule base's condition builder evaluates variables at runtime, so a condition testing the location variable against 'International' controls whether that catalog item appears. This keeps the item hidden until the user's selection satisfies the rule.

Why this answer

The Order Guide Rule Base condition builder is where you define the logic that determines which catalog items are included or excluded from the order guide based on user selections. When a user selects 'International' in a location variable, the rule base evaluates that condition and conditionally displays the specific item. This is the native mechanism for conditional item inclusion in order guides, not a UI policy or workflow activity.

Exam trap

CIS-ITSM often tests the confusion between UI Policies (which control field behavior) and Order Guide Rule Base (which controls item inclusion), so candidates mistakenly pick a UI Policy for conditional item display.

How to eliminate wrong answers

Option A is wrong because a Workflow switch activity controls process branching after submission, not the display of items in the order guide UI. Option C is wrong because a Variable Set mapping table is used to map variable sets to catalog items, not to define conditional display logic. Option D is wrong because a Catalog UI Policy on the parent order guide affects field behavior on the form (visible, mandatory, read-only) but does not control which catalog items appear in the order guide's rule base.

Full explanation →

50

MCQeasy

When defining a Business Service in ServiceNow, which field is mandatory to uniquely identify the service record?

A.Name

B.Serial Number

C.MAC Address

D.IP Address

AnswerA

The Name field is the mandatory unique identifier for a Business Service record in ServiceNow, distinguishing each service from all others. Without it the record cannot be saved, so it satisfies the requirement to uniquely identify the service.

Why this answer

The Name field is mandatory and serves as the unique identifier for a Business Service record in ServiceNow. When creating a Business Service via the CMDB or SPM module, the Name field is required by the dictionary to save the record, and it is the primary human-readable identifier used across references and reports. Other fields like Serial Number, MAC, and IP are not applicable to a logical Business Service CI.

Exam trap

The trap here is overthinking the 'unique identifier' wording — candidates may look for a system field like sys_id or a serial number, but the exam expects the mandatory human-readable Name field on the Business Service form.

How to eliminate wrong answers

Option B is wrong because Serial Number is a hardware asset attribute, not a field on the Business Service [cmdb_ci_service] table — Business Services are logical, not physical assets. Option C is wrong because MAC Address is a network interface attribute for hardware CIs, not a logical service identifier. Option D is wrong because IP Address is a network configuration item attribute; a Business Service may have no IP at all since it represents a logical grouping of capabilities.

Full explanation →

51

Multi-Selecthard

Which THREE of the following actions can be performed using CMDB Data Manager? (Choose three.)

Select 3 answers

A.Generate real-time network topology maps for IT service mapping.

B.Archive old and unused CI records based on age and lifecycle state criteria.

C.Automatically discover cloud infrastructure using AWS CloudFormation templates.

D.Delete archived CIs after a specified retention period.

E.Retire CIs that have reached the end of their operational lifecycle.

AnswersB, D, E

CMDB Data Manager applies configurable policies that archive CI records once they match age thresholds and lifecycle states, removing stale entries from active views while preserving them for reference. This directly satisfies the requirement to clear old, unused CIs without permanent loss.

Why this answer

CMDB Data Manager is a ServiceNow application used to govern the CMDB lifecycle by creating policies that archive, retire, and delete CI records. Option B is correct because Data Manager policies can archive old and unused CIs by evaluating criteria such as age (for example, 'last discovered more than 90 days ago') and lifecycle state, moving them out of the active CMDB. Option D is correct because Data Manager supports retention-based deletion policies that permanently remove previously archived CIs after a defined retention period elapses.

Option E is correct because Data Manager can automatically retire CIs that have reached end of life by setting their install status to Retired (or Absent) according to policy conditions. Option A is not correct because real-time network topology and service mapping views are produced by Service Mapping and Discovery, not by CMDB Data Manager. Option C is not correct because cloud discovery via AWS CloudFormation templates is performed by Discovery and Service Mapping patterns/Cloud Discovery, not by CMDB Data Manager, which only governs existing CI records.

Exam trap

CIS-ITSM often tests whether candidates confuse CMDB Data Manager (lifecycle governance: archive, delete, retire) with Discovery/Service Mapping (populate and visualize CIs), so any option mentioning topology maps or cloud discovery is a distractor.

Full explanation →

52

MCQmedium

An IT organization wants to ensure that Emergency Changes bypass standard multi-tier CAB reviews while still capturing post-implementation reviews. Which configuration component natively supports this requirement in ServiceNow ITSM?

A.Assignment Rules

B.Change Schedule conflict rules

C.Change Risk Calculator properties

D.Change Models

AnswerD

Change Models define the workflow, approval steps and required tasks for a change type, so an emergency model can omit multi-tier CAB approval while mandating a post-implementation review task. This natively satisfies the bypass-and-review requirement without custom scripting.

Why this answer

Change Models in ServiceNow natively support defining different process flows for different change types, including Emergency changes that bypass standard multi-tier CAB reviews while still enforcing post-implementation review. A Change Model can specify the workflow/flow, approval policy, and state transitions appropriate for emergency changes, making it the correct configuration component.

Exam trap

CIS-ITSM often tests whether candidates understand that Change Models (not assignment rules, schedules, or risk calculators) are the native mechanism for defining differentiated approval and process flows per change type.

How to eliminate wrong answers

Option A is wrong because Assignment Rules determine who a record is assigned to based on conditions; they do not control approval routing or CAB review bypass. Option B is wrong because Change Schedule conflict rules detect and manage scheduling conflicts between changes, not approval workflows. Option C is wrong because Change Risk Calculator properties configure how risk scores are computed, not how approvals or CAB reviews are structured.

Full explanation →

53

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.

Full explanation →

54

MCQmedium

An organization wants to reuse a set of standard hardware specification questions across twenty different laptop and desktop catalog items. Which feature should the administrator implement?

A.Record Producer Template

B.Catalog UI Policy Collection

C.Variable Set

D.Order Guide Rule Base

AnswerC

Variable Sets bundle a group of variables that can be attached to multiple catalog items, so the twenty hardware specification questions are maintained once and reused everywhere. This directly satisfies the stem's requirement to reuse standard questions across many catalog items without duplicating them.

Why this answer

Variable Sets in ServiceNow are containers that hold a group of variables (questions) which can be attached to multiple catalog items. By creating a Variable Set containing the standard hardware specification questions, the administrator can reuse it across all twenty catalog items without redefining the questions each time. This ensures consistency and simplifies maintenance: updating the Variable Set updates all catalog items that use it.

Thus, Variable Set is the correct feature for reusing a set of questions across multiple catalog items.

Exam trap

CIS-ITSM often tests the distinction between features that sound similar but serve different purposes, such as confusing Variable Sets with Record Producer Templates or Order Guides, leading candidates to choose an option that does not support reuse of variables across multiple catalog items.

How to eliminate wrong answers

Option A is wrong because Record Producer Templates are used to pre-populate record producers with default values, not to group and reuse variables across catalog items. Option B is wrong because Catalog UI Policy Collection is not a standard ServiceNow feature; UI Policies are used to dynamically change form behavior, but there is no 'Collection' feature for reuse across catalog items. Option D is wrong because Order Guide Rule Base is not a feature; Order Guides are used to bundle catalog items into a single order, but they do not provide a mechanism to reuse a set of variables across multiple catalog items.

Full explanation →

55

MCQhard

A company implements Service Portfolio Management and wants to use business service mapping to evaluate financial risk. Which ServiceNow product works alongside SPM to capture total cost of ownership (TCO) by allocating IT costs to business services and offerings?

A.ITOM Discovery

B.Demand Management

C.Vendor Performance Management

D.Financial Management (Cost Management / FSM)

AnswerD

Financial Management's cost allocation engine maps IT component costs onto business services and offerings, producing the TCO figures Service Portfolio Management needs for financial risk evaluation. Cost Management supplies the actual allocated amounts; SPM consumes them, satisfying the stem's requirement that TCO be captured alongside portfolio decisions.

Why this answer

Financial Management (Cost Management / Financial Services Management) in ServiceNow works alongside Service Portfolio Management to capture total cost of ownership by allocating IT costs to business services and offerings. It provides cost models, allocation rules, and financial reporting that tie IT spend to business services.

Exam trap

CIS-ITSM often tests the confusion between Financial Management and other ServiceNow products like Demand Management or Vendor Performance Management, when Financial Management is the one that allocates IT costs to business services.

How to eliminate wrong answers

Option A is wrong because ITOM Discovery is used to discover and map IT infrastructure, not to allocate costs to business services. Option B is wrong because Demand Management captures and prioritizes demand for services, not financial cost allocation. Option C is wrong because Vendor Performance Management tracks vendor performance and contracts, not TCO allocation to business services.

Full explanation →

56

Multi-Selectmedium

Which TWO factors should be considered when defining relationship rules between CI classes? (Choose two.)

Select 2 answers

A.The IP subnet mask of the connected network gear.

B.The financial depreciation schedule of the connected assets.

C.Whether the relationship is mandatory or optional for compliance checking.

D.Allowed parent classes and child classes for the relationship type.

E.The operating system version of the parent server.

AnswersC, D

Compliance checking depends on whether a relationship must exist, so defining each rule as mandatory or optional determines which missing links are flagged. This satisfies the stem's requirement by letting the CMDB distinguish genuine gaps from legitimately absent associations.

Why this answer

Option C is correct because when defining relationship rules between CI classes, you must specify whether a relationship is mandatory or optional, since this determines how compliance checking and CI validation behave — for example, a server must have a mandatory 'Runs on' relationship to a host, while other relationships may be optional. Option D is correct because relationship rules must define the allowed parent and child classes for each relationship type, ensuring that only valid class combinations (such as 'Server' as parent and 'Database' as child for a 'Hosts' relationship) can be created, which enforces data integrity in the CMDB. The unmarked options do not belong: A (IP subnet mask) is a network configuration detail, not a relationship rule factor; B (depreciation schedule) is a financial asset attribute unrelated to CI class relationships; and E (OS version) is a CI attribute, not a factor governing relationship rules between classes.

Exam trap

CIS-ITSM often tests the confusion between CI attributes (like OS version or IP) and relationship rule definitions, catching candidates who pick operational details instead of structural factors.

Full explanation →

57

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.

Full explanation →

58

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.

Full explanation →

59

MCQhard

An administrator has configured a Catalog UI Policy with a Catalog UI Policy Action. However, the action is not taking effect when the dependent variable changes value. What is a common troubleshooting step for Catalog UI Policies?

A.Clear the browser cache and restart the instance JVM

B.Convert the UI Policy into a Business Rule

C.Change the UI Policy execution order to zero

D.Verify that 'Applies on Target' (such as Service Portal or Catalog Item) is correctly checked on the UI Policy definition

AnswerD

Catalog UI Policies only run against the interface or target specified in 'Applies on Target'. If that checkbox omits the relevant Service Portal or Catalog Item, the policy and its actions never execute when the dependent variable changes, so verifying it is the first troubleshooting step.

Why this answer

Catalog UI Policies only execute when the form is rendered in a context where the policy is marked as applicable. The 'Applies on Target' setting (also called 'Applies to' in some versions) determines whether the policy runs on the Catalog Item, the Service Portal, or both. If this is unchecked or set to the wrong target, the policy and its actions silently do nothing even though the configuration looks correct.

Exam trap

CIS-ITSM often tests the 'Applies on Target' / 'Applies to' setting because candidates assume a UI Policy runs everywhere by default, when in fact it must be explicitly scoped to the Catalog Item and/or Service Portal target.

How to eliminate wrong answers

Option A is wrong because clearing browser cache or restarting the JVM is a generic troubleshooting step that does not address UI Policy execution context; UI Policies are evaluated server-side and delivered to the client, so cache is rarely the cause. Option B is wrong because converting a UI Policy to a Business Rule is a redesign, not a troubleshooting step, and Business Rules run server-side without the same client-side form behavior. Option C is wrong because execution order only matters when multiple UI Policies conflict; setting order to zero does not make an inapplicable policy run.

Full explanation →

60

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.

Full explanation →

61

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.

Full explanation →

62

MCQmedium

An IT director wants to view an aggregated dashboard showing all services within the 'Infrastructure Services' portfolio, categorized by their current lifecycle stage (e.g., Pipeline, Operational, Retired). Which built-in module in ServiceNow should the administrator direct the director to use?

A.Service Level Management Dashboard

B.ITSM Performance Analytics Home

C.Service Portfolio Workspace

D.Configuration Status Workspace

AnswerC

Service Portfolio Workspace aggregates every service in a portfolio and groups them by lifecycle stage, directly satisfying the director's need for a single categorised dashboard. It is the built-in module for portfolio-level lifecycle visibility, unlike Service Catalog or demand views.

Why this answer

The Service Portfolio Workspace is the built-in ServiceNow module that provides an aggregated view of services within a portfolio, including lifecycle stage categorization (Pipeline, Operational, Retired). It is designed for portfolio managers and directors to visualize service health and lifecycle. This directly matches the director's requirement.

Exam trap

CIS-ITSM often tests the distinction between portfolio-level views (Service Portfolio Workspace) and operational/SLA dashboards, confusing candidates who pick Performance Analytics for strategic views.

How to eliminate wrong answers

Option A is wrong because the Service Level Management Dashboard focuses on SLA performance and compliance, not portfolio lifecycle stages. Option B is wrong because ITSM Performance Analytics Home provides operational metrics and KPIs, not a portfolio-level lifecycle view. Option D is wrong because the Configuration Status Workspace is for CMDB configuration item health and compliance, not service portfolio lifecycle aggregation.

Full explanation →

63

MCQmedium

A change request is currently in the 'Authorize' state. Which group or entity is typically responsible for giving final approval during this state for a Normal change?

A.Configuration Management Team

B.Service Desk Agents

C.Change Advisory Board (CAB) / Change Authority

D.Discovery Admin

AnswerC

During the Authorize state, the Change Advisory Board or delegated Change Authority reviews risk and schedule impact, then grants final approval for Normal changes. This body holds the authorisation mandate that the Change Manager alone does not, satisfying the stem's requirement for the entity giving final approval.

Why this answer

In the ServiceNow change management lifecycle, the 'Authorize' state is where the change request awaits approval, and for a Normal change the Change Advisory Board (CAB) or designated Change Authority performs that approval. The CAB assesses risk, impact, and scheduling before authorizing the change to proceed. This is the standard governance body for Normal changes.

Exam trap

The trap is confusing operational teams (Service Desk, Discovery, Config Management) with the governance body (CAB/Change Authority) that actually authorizes Normal changes.

How to eliminate wrong answers

Option A is wrong because the Configuration Management Team owns CI data and the CMDB, not change authorization. Option B is wrong because Service Desk Agents handle incident intake and user communication, not CAB-level approval of Normal changes. Option D is wrong because the Discovery Admin manages Discovery schedules and CI population, which is unrelated to change approval authority.

Full explanation →

64

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.

Full explanation →

65

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.

Full explanation →

66

MCQhard

When designing a complex fulfillment workflow, an administrator uses a 'Create Task' activity to generate a catalog task. How are variable values collected from the requested item passed or accessed within the task description?

A.By referencing variables using syntax like ${current.variables.variable_name} directly in the task description or workflow script.

B.By configuring a Catalog UI Policy to sync task descriptions on submission.

C.By mapping variable sets in the workflow properties related list.

D.Variables must be manually copied using a Business Rule because workflows cannot read variable data.

AnswerA

The ${current.variables.variable_name} syntax reads the requested item's variable values through the current record, so the catalog task description inherits the collected answers without extra scripting. This satisfies the requirement to pass variable values into the generated task.

Why this answer

In ServiceNow workflows, the Create Task activity and workflow scripts can access catalog variable values through the current.variables object, using the syntax ${current.variables.variable_name} in the task description or short description fields. This substitution is evaluated at runtime when the task is created, pulling the value from the parent sc_req_item. The same syntax works in workflow script activities via current.variables.variable_name.

Exam trap

The trap is assuming workflows need a Business Rule or UI Policy to read variables — candidates who haven't built workflows often pick the Business Rule option, not realizing current.variables is natively available in workflow context.

How to eliminate wrong answers

Option B is wrong because Catalog UI Policies operate on the catalog item form at submission time and cannot sync data into downstream task descriptions — they control field visibility and mandatory state, not workflow data propagation. Option C is wrong because variable sets are containers for variable definitions, not a mapping mechanism for passing values into workflow tasks; there is no 'workflow properties related list' that maps variable sets to task fields. Option D is wrong because workflows absolutely can read variable data via current.variables — no Business Rule is required, and this misconception leads to unnecessary custom scripting.

Full explanation →

67

MCQeasy

What does the 'Root cause summary' field on a Problem record typically capture?

A.The SLA breach percentage for the problem task

B.The detailed explanation of the underlying cause determined during investigation

C.A list of all engineers who logged into the server

D.The purchase order number of the replacement hardware

AnswerB

The 'Root cause summary' field documents the verified underlying cause identified through problem investigation, satisfying the requirement to record why an incident occurred. Unlike workaround or resolution fields, it captures the diagnostic conclusion itself, enabling trend analysis and preventing recurrence. This aligns with ITIL problem management practise, where root cause determination is the core investigative output.

Why this answer

The 'Root cause summary' field on a Problem record captures the detailed explanation of the underlying cause identified during investigation. It documents why the problem occurred, such as a misconfiguration, code defect, or process gap, so that permanent fixes can be applied and knowledge shared. This field is populated after root cause analysis (RCA) is complete.

Exam trap

The trap is selecting a field that sounds related to problem resolution but actually belongs to a different record type (SLA, audit, or procurement) — candidates must know which fields live on the Problem table itself.

How to eliminate wrong answers

Option A is wrong because SLA breach percentage is a metric tracked on task SLA records, not a narrative field on the Problem record. Option C is wrong because a list of engineers who logged into a server is audit/access data, not root cause information. Option D is wrong because a purchase order number for replacement hardware is procurement data that might appear in work notes or related records, but it does not describe the underlying cause of the problem.

Full explanation →

68

MCQeasy

During the implementation of Service Portfolio Management, which persona is primarily responsible for maintaining the lifecycle, roadmap, and financial performance of a specific service?

A.CSDM Architect

B.Service Owner

C.Service Desk Manager

D.Catalog Administrator

AnswerB

The Service Owner owns a specific service end-to-end, so they maintain its lifecycle stages, roadmap and financial performance. This persona accountability directly satisfies the stem's requirement for lifecycle, roadmap and financial responsibility for a single service.

Why this answer

The Service Owner is the persona primarily responsible for maintaining the lifecycle, roadmap, and financial performance of a specific service. In ServiceNow SPM and ITIL, the Service Owner is accountable for the end-to-end service across its lifecycle, including strategy, design, transition, and continual improvement, as well as the service's P&L. This role is distinct from the process owner or service desk manager.

Exam trap

CIS-ITSM often tests role confusion between Service Owner (strategic/financial accountability) and Service Desk Manager (operational incident management) — candidates pick the desk manager because they think 'maintaining the service' means handling tickets.

How to eliminate wrong answers

Option A is wrong because the CSDM Architect designs and governs the Common Service Data Model structure (CI classes, relationships, domains), not the lifecycle or financial performance of individual services. Option C is wrong because the Service Desk Manager oversees incident and request handling operations, not the strategic roadmap or financials of a service. Option D is wrong because the Catalog Administrator manages catalog items, categories, and ordering workflows, not service lifecycle or P&L.

Full explanation →

69

MCQeasy

In ServiceNow Service Catalog terminology, what does the Request [sc_request] table represent?

A.The parent container representing the overall shopping cart order submission.

B.The fulfillment task assigned to a specific assignment group.

C.The individual catalog item being requested by the end user.

D.The workflow definition triggered upon catalog checkout.

AnswerA

The sc_request table acts as the parent record for a submitted catalog order, grouping one or more sc_req_item rows beneath it. It represents the overall cart submission, satisfying the stem's definition of the parent container.

Why this answer

The Request [sc_request] table is the parent container that represents the overall shopping cart submission — it groups one or more Requested Items (sc_req_item) that were checked out together. It holds header-level information like the requester, submission date, and approval state for the entire order.

Exam trap

CIS-ITSM often tests whether candidates confuse the three-tier catalog hierarchy — Request (parent order), Requested Item (individual item), and Catalog Task (fulfillment work) — since all three sound similar but represent distinct levels.

How to eliminate wrong answers

Option B is wrong because fulfillment tasks assigned to assignment groups are represented by Task [sc_task] records, which are children of Requested Items, not the Request itself. Option C is wrong because the individual catalog item being requested is the Requested Item [sc_req_item], which is a child of the Request. Option D is wrong because the workflow definition triggered at checkout is a Workflow [wf_workflow] record, not the Request table.

Full explanation →

70

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.

Full explanation →

71

Multi-Selecteasy

Which TWO actions should be taken when an Emergency Change is required in production? (Choose two.)

Select 2 answers

A.Create an Emergency change request detailing the urgent issue and remediation plan

B.Convert the change into a standard change template

C.Route the change through rapid emergency approval channels defined for emergency models

D.Disable all auditing and logging on the instance

E.Wait for the next monthly CAB meeting scheduled three weeks away

AnswersA, C

An Emergency change request documents the urgent issue and remediation plan, satisfying the stem's requirement by creating the formal record before implementation. This enables retrospective review and provides the audit trail that emergency changes still demand despite compressed approval timelines.

Why this answer

Option A is correct because an Emergency Change must still be documented via a change request that captures the urgent issue, the remediation plan, and the associated risk/impact so the change is traceable and auditable. Option C is correct because emergency changes are handled through a pre-defined expedited approval path (an Emergency CAB or delegated approver model) rather than the normal change calendar, allowing rapid authorization while preserving governance. Options B, D, and E are incorrect: converting the change to a standard change template (B) is inappropriate since standard changes are pre-approved, low-risk, and repetitive, not urgent unplanned fixes; disabling auditing and logging (D) violates compliance and destroys the audit trail needed for post-implementation review; and waiting for the next monthly CAB (E) defeats the purpose of an emergency change, which by definition cannot wait for the normal change cycle.

Exam trap

The trap is thinking emergency changes bypass all process — candidates may pick 'disable auditing' or 'wait for CAB' when the correct approach is to use the predefined emergency approval path while still documenting the change.

Full explanation →

72

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.

Full explanation →

73

MCQeasy

What is the primary objective of reactive Problem Management?

A.To build the initial Configuration Management Database (CMDB)

B.To review change request risk before deployment

C.To handle password reset requests from end users

D.To identify and eliminate the underlying causes of incidents that have already occurred

AnswerD

Reactive Problem Management responds after incidents occur, performing root cause analysis to find and remove the underlying cause, preventing recurrence. This contrasts with proactive Problem Management, which seeks causes before incidents arise, matching the stem's emphasis on incidents that have already happened.

Why this answer

Reactive Problem Management focuses on investigating incidents that have already occurred to determine and eliminate their root cause, preventing recurrence. Its primary objective is to reduce the number and impact of future incidents by addressing the underlying cause rather than just restoring service. This is distinct from proactive Problem Management, which seeks to identify problems before incidents occur.

Exam trap

CIS-ITSM often tests the distinction between reactive and proactive Problem Management — candidates confuse reactive (responding to incidents already occurred) with proactive (identifying problems before incidents happen) and pick answers describing proactive or unrelated activities.

How to eliminate wrong answers

Option A is wrong because building the initial CMDB is a Configuration Management objective, not a Problem Management objective — CMDB population is driven by discovery and configuration management processes. Option B is wrong because reviewing change request risk before deployment is a Change Management responsibility handled through change advisory board (CAB) reviews and risk assessment, not Problem Management. Option C is wrong because handling password reset requests is a Service Desk / Incident Management function (often automated via password reset tools), not a Problem Management activity.

Full explanation →

74

MCQhard

A developer needs to retrieve the value of a catalog variable named 'urgency_level' within a Service Catalog Workflow using a Run Script activity. Which syntax is correct?

A.producer.urgency_level

B.current.variables.urgency_level

C.workflow.scratchpad.urgency_level

D.g_form.getValue('urgency_level')

AnswerB

Within a Service Catalog Workflow Run Script activity, the current object exposes the requested catalog item's variables, so current.variables.urgency_level retrieves the submitted value directly. This satisfies the developer's need to read the named variable during workflow execution.

Why this answer

In a Service Catalog Workflow Run Script activity, the `current` object represents the current record (the catalog task or requested item), and catalog variable values are accessed through the `variables` property. The correct syntax is `current.variables.urgency_level`, which retrieves the value of the 'urgency_level' variable. This is the standard method for reading catalog variables in server-side scripts within workflows.

Exam trap

CIS-ITSM often tests the distinction between client-side and server-side variable access, confusing candidates with methods like g_form.getValue() that only work in client scripts, or misusing workflow scratchpad for variable retrieval.

How to eliminate wrong answers

Option A is wrong because `producer` is not a valid object in this context; it might be confused with a workflow producer, but it does not hold catalog variable values. Option C is wrong because `workflow.scratchpad` is used to store and retrieve temporary data within a workflow, not to directly access catalog variables. Option D is wrong because `g_form.getValue('urgency_level')` is a client-side method used in catalog client scripts or UI policies, not available in server-side Run Script activities.

Full explanation →

75

MCQhard

A CMDB administrator notices that a large number of Windows servers are being created as duplicate CIs in the CMDB. The servers are discovered by both SCCM and ServiceNow Discovery. After investigation, the administrator finds that SCCM populates the serial_number field with the service tag, while ServiceNow Discovery populates the serial_number field with the BIOS UUID. Both data sources are configured to use the same identification rule that includes serial_number. What is the most likely cause of the duplicates?

A.The CMDB is not configured with a Data Source Precedence rule, so both data sources are creating separate CIs.

B.The reconciliation rule is not configured to merge CIs from different data sources, causing duplicates to be created.

C.The identification rule is using serial_number as the only identifier, and the values from the two sources differ, so IRE cannot match them.

D.The CI Class Manager is not configured to allow multiple data sources to update the same CI, resulting in duplicates.

AnswerC

This is correct because IRE matches CIs based on the values of the attributes in the identification rule. If SCCM and ServiceNow Discovery provide different values for serial_number, IRE will not consider them the same CI and will create separate records. The rule must include additional attributes or a different attribute that is consistent across sources to ensure proper matching.

Why this answer

The Identification and Reconciliation Engine uses identification rules to match incoming CI data to existing CIs. If the identification rule relies solely on serial_number and the two discovery sources provide different values for that attribute, IRE will not find a match and will create duplicate CIs. To resolve this, the administrator should include additional attributes in the identification rule that are consistent across sources, such as name and MAC address, or use a different attribute like BIOS UUID if both sources can populate it consistently.

Exam trap

The trap here is assuming that reconciliation or data source precedence can prevent duplicates, when the root cause is mismatched identification attributes.

Full explanation →

Page 1 of 5

All pages

Practice CIS-ITSM by domain

Target a specific domain to shore up weak areas.

Incident Management Service Portfolio Management Problem Management Change Management CMDB Service Catalog And Request Management

See all domains with question counts →