Courseiva

ServiceNow Certified Implementation Specialist - IT Service Management (CIS-ITSM) (CIS-ITSM) (CIS-ITSM) — Questions 151–225

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

Take a mock examExam hub
Page 2

Page 3 of 5

Page 4
151
MCQmedium

An administrator created a Catalog UI Policy that makes a variable mandatory when another variable equals 'Other'. However, the policy does not apply when the item is loaded via an Order Guide. How should the administrator resolve this?

A.Add the order guide to the 'Catalog UI Policy Related Lists' tab.
B.Change the execution order of the UI policy to 1.
C.Ensure 'Applies to Order Guides' is checked on the Catalog UI Policy record.
D.Convert the Catalog UI Policy into a Catalog Client Script using g_form.setMandatory().
AnswerC

Catalog UI Policies only run on standalone catalog items unless the 'Applies to Order Guides' flag is enabled. Ticking it makes the policy evaluate variables rendered through an Order Guide, restoring the mandatory condition when the dependent variable equals 'Other'.

Why this answer

Catalog UI Policies have an 'Applies to Order Guides' option that must be checked for the policy to execute when the catalog item is part of an Order Guide. By default, this option is unchecked, so the policy does not apply in the Order Guide context.

Exam trap

CIS-ITSM often tests the subtlety that Catalog UI Policies do not automatically apply to Order Guides unless explicitly configured, and candidates may overlook the 'Applies to Order Guides' checkbox.

How to eliminate wrong answers

Option A is wrong because there is no 'Catalog UI Policy Related Lists' tab on an Order Guide; UI policies are not associated that way. Option B is wrong because changing the execution order does not affect whether the policy applies to Order Guides; it only affects the order of execution relative to other policies. Option D is wrong because converting to a Catalog Client Script is unnecessary and more complex; the simple fix is to check the 'Applies to Order Guides' option.

Full explanation →
152
MCQmedium

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

A.Data Policies
B.Priority Lookup Rules
C.UI Policies
D.Assignment Rules
E.Service Level Agreements (SLAs)
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Full explanation →
153
Multi-Selectmedium

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

Select 2 answers
A.Changing the user's manager.
B.Configuring an SLA breach to trigger an event.
C.Adding the incident to a Change Request.
D.Deleting the incident record.
E.Manually changing the Priority field.
AnswersB, E

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

Why this answer

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

Exam trap

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

Full explanation →
154
Multi-Selectmedium

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

Select 2 answers
A.Assignment rules can only assign incidents to individual users, never groups.
B.Evaluation stops at the first matching rule unless otherwise configured.
C.Assignment rules require client-side JavaScript to function.
D.Assignment rules execute before Inbound Email Actions.
E.Rules are evaluated in ascending order based on their Order field value.
AnswersB, E

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

Why this answer

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

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

Exam trap

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

Full explanation →
155
MCQmedium

A catalog item 'New Employee Laptop' uses a Record Producer to create a task on the 'sc_task' table. The administrator needs to ensure that the 'short_description' of the created task includes the value of the 'laptop_model' variable from the catalog item. Where should the administrator configure this mapping?

A.Create a Business Rule on the 'sc_task' table that sets 'short_description' from the 'laptop_model' variable after insert.
B.In the Catalog Item's 'Variable' record for 'laptop_model', set the 'Map to field' attribute to 'short_description'.
C.In the Record Producer's 'Variable Mapping' related list, create a mapping for the 'short_description' field to the 'laptop_model' variable.
D.In the Record Producer's 'Script' field, use 'current.short_description = producer.laptop_model;' before the insert.
AnswerC

The Variable Mapping related list on a Record Producer allows you to map catalog variables to fields on the target table. This is the intended, no-code method to populate fields like short_description with variable values. The mapping is evaluated when the record is created. This approach is maintainable and does not require custom scripting, making it the best practice for this requirement.

Why this answer

The Variable Mapping related list on a Record Producer is the designed feature to map catalog variables to target table fields. It provides a declarative way to set values like short_description without scripting. Other options involve custom scripts or misusing variable attributes, which are unnecessary and less maintainable.

The mapping is evaluated during record creation, ensuring the field is populated correctly.

Exam trap

The trap here is assuming that variable mapping must be done via scripting or that the 'Map to field' attribute on a variable applies to Record Producers, when in fact Record Producers have a dedicated Variable Mapping related list.

Full explanation →
156
MCQmedium

An organization wants to restrict problem creation so that only users assigned to the 'Problem Management' group can create new problem records. How should this be implemented?

A.A create Access Control List (ACL) on the Problem table checking group membership
B.A Dictionary entry attribute 'no_create'
C.A Client Script hiding the 'New' button for unauthorized users
D.A UI Policy enforcing mandatory user groups
AnswerA

A create ACL on the Problem table evaluates the user's group membership before permitting record insertion, directly enforcing the restriction that only members of the 'Problem Management' group may create problem records. This is the native ServiceNow authorisation mechanism for table-level create operations, satisfying the stem's group-based constraint.

Why this answer

A create ACL on the Problem table that checks group membership is the correct implementation because ACLs are the only server-side security mechanism that can restrict who can create records. By configuring the create ACL with a condition that the user is a member of the 'Problem Management' group, only those users can create problem records. This enforces security at the database level, not just the UI.

Exam trap

CIS-ITSM often tests whether candidates understand that UI-level controls (Client Scripts, UI Policies) are not security — candidates incorrectly pick UI-based solutions for access restriction questions.

How to eliminate wrong answers

Option B is wrong because a Dictionary entry attribute 'no_create' is not a valid ServiceNow attribute — dictionary attributes like 'no_audit' or 'read_only' exist, but 'no_create' does not, and dictionary attributes do not enforce role or group-based creation restrictions. Option C is wrong because a Client Script hiding the 'New' button only affects the UI and can be bypassed via direct URL access, REST API, or list view — it is not a security control. Option D is wrong because a UI Policy enforcing mandatory user groups only makes fields mandatory or read-only on the form; it does not restrict who can create records and is client-side only.

Full explanation →
157
Multi-Selectmedium

Which TWO of the following are valid ways to structure layouts in a Service Catalog item form? (Choose two.)

Select 2 answers
A.UI Macro Table Mappings
B.Variable Sets
C.Dictionary Layout Overrides
D.Container Begin / Container Split / Container End
E.CSS Flexbox Injection via Catalog UI Policy Actions
AnswersB, D

Variable Sets group related variables into a reusable container that can be attached to multiple catalog items, satisfying the requirement for a valid layout structure. They render as a distinct section within the form, letting administrators organise fields logically without rebuilding them per item.

Why this answer

In ServiceNow Service Catalog, form layouts for catalog items are built using variables, and Container Begin, Container Split, and Container End are the standard variable types used to create multi-column and sectioned layouts on a catalog item form, so option D is correct. Variable Sets are also a valid structural mechanism: they group a reusable collection of variables (including their own containers and ordering) that can be attached to one or more catalog items, so option B is correct. Option A is incorrect because UI Macros are used for custom rendering/widgets, not for defining catalog item layout structure, and there is no 'UI Macro Table Mappings' layout construct.

Option C is incorrect because dictionary layout overrides apply to table forms (sys_dictionary/sys_ui), not to catalog item variable layouts. Option E is incorrect because injecting CSS Flexbox through a Catalog UI Policy action is a styling hack, not a supported way to structure catalog item layouts.

Exam trap

CIS-ITSM often tests whether candidates can distinguish supported catalog layout mechanisms (Variable Sets, Containers) from plausible-sounding but invalid options like CSS injection or dictionary overrides.

Full explanation →
158
Multi-Selectmedium

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

Select 2 answers
A.Resolved
B.Under Review
C.Backlog
D.Pending Approval
E.In Progress
AnswersA, E

Resolved is a standard baseline incident state.

Why this answer

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

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

Exam trap

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

Full explanation →
159
MCQhard

During the review of a scheduled Normal Change, the Change Management conflict engine flags an overlap. The conflict is detected against another change record that targets a different CI, but both CIs depend on the same parent business service. How does the conflict engine identify this relationship?

A.By evaluating upstream and downstream relationships in the cmdb_rel_ci table linked to shared dependent CIs or business services.
B.By comparing the assignment groups of the tasks to see if they share the same manager.
C.By checking if both change records reference the same parent service portfolio offering in Service Portfolio Management.
D.Through the Change Schedule map view overlapping boundaries calculated exclusively by the location field.
AnswerA

The conflict engine traverses the CMDB relationship graph, specifically the cmdb_rel_ci table, walking upstream and downstream dependencies from each affected CI. Because both CIs resolve to the same parent business service through those relationship records, the engine detects the shared dependency and flags the overlap, satisfying the stem's cross-CI conflict requirement.

Why this answer

The conflict engine in ServiceNow Change Management identifies overlaps by analyzing the CMDB relationship table (cmdb_rel_ci) to trace dependencies between configuration items (CIs). When two changes target different CIs that both depend on the same parent business service, the engine detects this shared dependency through upstream and downstream relationships, flagging a potential conflict. This ensures that changes affecting interconnected components are coordinated even if they don't directly share a CI.

Exam trap

CIS-ITSM often tests the misconception that conflict detection relies on assignment groups or service portfolio offerings, when it actually depends on CMDB relationship traversal.

How to eliminate wrong answers

Option B is wrong because assignment groups and their managers are not used by the conflict engine to detect CI relationships; the engine focuses on CMDB dependencies, not organizational hierarchy. Option C is wrong because Service Portfolio Management offerings are not the basis for conflict detection; the engine uses the CMDB relationship table, not service portfolio offerings. Option D is wrong because the Change Schedule map view and location field are unrelated to conflict detection; conflicts are based on CI relationships, not geographic or schedule map boundaries.

Full explanation →
160
MCQmedium

An administrator is configuring a Catalog Item for a new laptop. The item has a 'Model' variable (Select Box) and a 'RAM' variable (Select Box). The requirement is that the available RAM options must change based on the selected Model, and the list of RAM choices is maintained in a separate table (u_laptop_ram_options). What should the administrator configure to meet this requirement?

A.Create a Variable Lookup Select Box for the RAM variable, referencing the u_laptop_ram_options table and filtering by the Model variable.
B.Create a new Variable Set containing all possible RAM options and use a Catalog Client Script to hide irrelevant ones.
C.Create a Catalog UI Policy with a Run Script that filters the RAM variable's choices based on the Model variable.
D.Use a Record Producer on the u_laptop_ram_options table to generate the RAM choices dynamically when the Model is selected.
AnswerA

A Variable Lookup Select Box is designed to dynamically populate choices from a table. It supports a reference qualifier that can filter records based on another variable's value, such as the selected Model. This provides a maintainable, out-of-box solution without custom scripting. The administrator can set the reference qualifier to something like 'model=javascript:current.variables.model', ensuring RAM options are relevant to the chosen model.

Why this answer

The requirement is to dynamically filter the RAM variable's choices based on the selected Model, with choices stored in a separate table. A Variable Lookup Select Box is the correct tool because it pulls choices from a table and supports a reference qualifier that can reference other variables. This provides a no-code solution that is maintainable and scalable.

Other options either misuse UI Policies, Variable Sets, or Record Producers, none of which natively support dynamic choice filtering from an external table.

Exam trap

The trap here is assuming that Catalog UI Policies can dynamically repopulate a Select Box's choices from an external table, when in fact they are limited to client-side form behavior.

Full explanation →
161
MCQhard

When configuring Maintenance Schedules in ServiceNow Change Management, what is the effect of defining a Maintenance Schedule versus a Blackout Schedule?

A.Maintenance schedules specify approved windows for changes, while blackout schedules specify prohibited periods
B.Maintenance schedules are only for emergency changes, while blackout schedules apply to normal changes
C.There is no functional difference; they are interchangeable terms in ServiceNow
D.Maintenance schedules automatically close change tasks, while blackout schedules trigger conflict warnings
AnswerA

Maintenance schedules define permitted change windows, whereas blackout schedules block changes during critical periods such as financial close or peak trading. This directly satisfies the stem's requirement to distinguish the two: one authorises approved execution windows, the other prohibits activity, ensuring changes avoid high-risk intervals.

Why this answer

Maintenance Schedules in ServiceNow Change Management define approved windows during which changes can be implemented, while Blackout Schedules specify prohibited periods when changes must not occur. This distinction is critical for planning changes around business-critical periods such as financial close or holiday sales. The system uses these schedules to validate change requests and prevent conflicts.

Exam trap

CIS-ITSM often tests the confusion between Maintenance and Blackout Schedules, where candidates incorrectly assume they are interchangeable or that Maintenance Schedules only apply to emergency changes, when they serve opposite purposes.

How to eliminate wrong answers

Option B is wrong because Maintenance Schedules are not limited to emergency changes — they apply to all types of changes and define when changes are allowed, not the change category. Option C is wrong because there is a clear functional difference: Maintenance Schedules permit changes, while Blackout Schedules prohibit them; they are not interchangeable. Option D is wrong because Maintenance Schedules do not automatically close change tasks — they define time windows; Blackout Schedules do not trigger conflict warnings directly but rather prevent changes from being scheduled during those periods.

Full explanation →
162
MCQmedium

A developer needs to populate a user's department automatically into a catalog variable when the Catalog Item form loads. Which type of script should be used?

A.Business Rule
B.Catalog Client Script (onLoad)
C.Catalog UI Policy Script
D.Script Include
AnswerB

A Catalog Client Script with an onLoad type runs in the browser when the form loads, allowing g_scratchpad or a GlideAjax call to populate the department variable before the user interacts. This satisfies the stem's requirement for automatic population at form load.

Why this answer

A Catalog Client Script with an onLoad script type runs in the browser when the Catalog Item form loads, making it the correct choice to populate a variable such as department based on the logged-in user. Client scripts can call g_form.setValue() to set the variable value before the user interacts with the form. This is the standard mechanism for dynamic, client-side variable population on catalog item forms.

Exam trap

CIS-ITSM often tests the confusion between client-side and server-side scripts, so candidates pick Business Rule or Script Include when the requirement explicitly says the value must populate when the form loads in the browser.

How to eliminate wrong answers

Option A is wrong because a Business Rule runs server-side on database operations and cannot directly populate a catalog variable at form load time in the user's browser. Option C is wrong because a Catalog UI Policy Script runs in response to UI policy conditions (such as making fields mandatory or visible) and is not the primary mechanism for initializing variable values on load. Option D is wrong because a Script Include is a server-side reusable script library and does not execute in the browser to set form variables.

Full explanation →
163
Multi-Selecthard

During Change Conflict Detection, which THREE types of conflicts can the ServiceNow conflict engine automatically identify and report on a change record? (Choose three.)

Select 3 answers
A.Conflicts where another change targets the exact same Configuration Item (CI) during an overlapping time window.
B.Conflicts where a change target CI is related to another CI undergoing a change in a conflicting window.
C.Conflicts where the change request submitter lacks the required approval delegation limits.
D.Conflicts where the estimated cost of the change exceeds the assigned cost center budget threshold.
E.Conflicts where a change is scheduled during a defined Blackout Schedule window.
AnswersA, B, E

The conflict engine compares each change's affected CIs and planned start/end times, flagging records where the same CI appears in two changes whose windows overlap. This directly satisfies the stem's requirement for automatic CI-and-time conflict detection.

Why this answer

The ServiceNow change conflict engine automatically detects three conflict types on a change record. Option A is correct because it identifies direct CI conflicts, where another change targets the exact same Configuration Item during an overlapping time window, which is the classic scheduling collision the engine checks via the change CI relations. Option B is correct because the engine also evaluates related CI conflicts, where a change's target CI is related (through CI relationships) to another CI being changed in a conflicting window, catching downstream or dependency impacts.

Option E is correct because the engine checks blackout schedules, flagging changes scheduled during a defined Blackout Schedule window as conflicts. Options C and D are not conflict types the engine reports: approval delegation limits and cost center budget thresholds are governance/financial controls handled by approval rules and budget workflows, not by change conflict detection.

Exam trap

CIS-ITSM often tests the assumption that conflict detection covers approval, budget, or delegation issues, when the OOB engine only detects CI overlap, related-CI overlap, and blackout window violations.

Full explanation →
164
MCQeasy

When configuring a Service Catalog item, what is the purpose of setting the 'No cart' field to true?

A.It prevents users from ordering more than one quantity of the item.
B.It deletes all existing items currently stored in the user's active shopping cart.
C.It disables the Service Portal shopping experience completely for that user.
D.It hides the 'Add to Cart' button and forces immediate checkout upon submission.
AnswerD

Setting 'No cart' to true bypasses the shopping cart stage entirely, hiding the 'Add to Cart' button so the item is submitted and checked out immediately. This satisfies the requirement for a one-step request flow rather than a multi-item cart interaction.

Why this answer

Setting the 'No cart' field to true on a catalog item bypasses the shopping cart entirely: the 'Add to Cart' button is hidden and the item is submitted for immediate checkout when the user clicks 'Order Now' or equivalent. This is used for items that should not be combined with other purchases or that require immediate fulfillment.

Exam trap

CIS-ITSM often tests the 'No cart' field by offering distractor options about quantity limits or cart deletion, so candidates must remember that 'No cart' specifically hides the Add to Cart button and forces immediate checkout.

How to eliminate wrong answers

Option A is wrong because quantity limits are controlled by the 'Max quantity' or 'Mandatory quantity' fields, not 'No cart'. Option B is wrong because 'No cart' does not delete existing cart contents; it only affects the current item's checkout flow. Option C is wrong because 'No cart' does not disable the Service Portal shopping experience globally — it only changes the behavior for that specific catalog item.

Full explanation →
165
MCQmedium

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

A.The SLA timer pauses indefinitely
B.The SLA timer continues
C.The SLA timer stops
D.The SLA timer resets to zero
AnswerC

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

Why this answer

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

The timer does not continue to run after resolution.

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
166
Multi-Selecteasy

Which TWO roles are typically associated with managing and participating in Change Management processes? (Choose two.)

Select 2 answers
A.itil
B.sn_vul_admin
C.change_manager
D.discovery_admin
E.sn_hr_core
AnswersA, C

The ITIL role encompasses managing the change lifecycle, assessing risk and authorising changes, while participating practitioners raise and implement change records. This satisfies the stem's requirement for roles that both manage and participate in Change Management processes within the CIS-ITSM framework.

Why this answer

Option C, change_manager, is correct because this is the role explicitly designed to oversee the Change Management process, including reviewing, approving, and coordinating change requests. Option A, itil, is correct because the itil role is the baseline role that grants users access to ITIL-based processes such as Change Management, allowing them to create, assess, and participate in change records. The unmarked options do not belong: sn_vul_admin is for Vulnerability Response administration, discovery_admin is for Discovery scheduling and configuration, and sn_hr_core is for HR Service Delivery, none of which are Change Management roles.

Exam trap

CIS-ITSM often tests role-to-process mapping, and the trap is selecting admin roles (like sn_vul_admin or discovery_admin) that sound authoritative but belong to entirely different ServiceNow applications.

Full explanation →
167
MCQhard

A developer needs to populate a List Collector variable with records from a custom table based on criteria evaluated at runtime. How can this dynamic filtering be achieved?

A.By modifying the sc_req_item dictionary directly
B.Using a client-side alert message
C.Using a reference qualifier on the List Collector variable definition
D.Using a Catalog UI Policy action to set filter attributes
AnswerC

A reference qualifier on the List Collector applies an encoded query or scripted condition that filters the referenced table's records dynamically at runtime, so only matching records appear in the collector. This satisfies the requirement for criteria evaluated when the form loads.

Why this answer

A List Collector variable can be dynamically filtered by applying a reference qualifier on the variable definition in item_option_new. The reference qualifier is a query string (or advanced script) that restricts which records from the referenced table appear in the collector's available list, evaluated at runtime based on user or form context. This is the standard, supported mechanism for dynamic filtering of reference and list collector variables.

Exam trap

The trap is confusing UI Policies (which control form field behavior) with reference qualifiers (which control record filtering) — candidates often pick the UI Policy option because both are 'dynamic' catalog configurations.

How to eliminate wrong answers

Option A is wrong because modifying the sc_req_item dictionary directly changes table schema, not variable filtering behavior, and would be a dangerous, unsupported customization. Option B is wrong because a client-side alert message only displays a notification to the user — it has no effect on which records populate a List Collector. Option D is wrong because Catalog UI Policy actions control field visibility, mandatory state, and read-only state on the form; they cannot set the reference qualifier or filter attributes of a List Collector's underlying query.

Full explanation →
168
Multi-Selecteasy

Which TWO types of schedules can be utilized to prevent changes from occurring during critical business hours? (Choose two.)

Select 2 answers
A.Asset Depreciation Schedules
B.Maintenance Schedules
C.Blackout Schedules
D.Employee Shift Schedules
E.Knowledge Article Expiration Schedules
AnswersB, C

Maintenance schedules define windows when changes are allowed to proceed, so work outside them is effectively blocked during critical business hours. This satisfies the stem's requirement to prevent changes by restricting execution to approved maintenance periods.

Why this answer

Maintenance Schedules (B) are correct because they define planned windows during which maintenance or changes are permitted, so by scheduling change activity only within those approved windows, organizations inherently prevent changes from occurring during critical business hours. Blackout Schedules (C) are correct because they explicitly specify periods—such as critical business hours, month-end close, or peak transaction times—during which changes are prohibited, directly preventing change activity at those times. The remaining options do not serve this purpose: Asset Depreciation Schedules (A) track financial depreciation of assets, Employee Shift Schedules (D) manage workforce staffing, and Knowledge Article Expiration Schedules (E) control the lifecycle of knowledge base content—none of which govern when changes may or may not be implemented.

Exam trap

The trap is confusing general scheduling concepts (shift schedules, depreciation schedules) with change-specific schedules. Candidates must remember that only Maintenance and Blackout schedules are used in Change Management to control execution windows.

Full explanation →
169
Multi-Selectmedium

An administrator is configuring a Catalog UI Policy. Which TWO of the following statements are true regarding Catalog UI Policies? (Choose two.)

Select 2 answers
A.They execute on the server side prior to database insertion.
B.They can be applied to both Catalog Items and Record Producers.
C.They can execute client-side logic without requiring JavaScript when using declarative UI policy actions.
D.They only function on legacy UI16 forms and are unsupported in Service Portal.
E.They replace the need for Catalog Client Scripts in all scenarios, including asynchronous database lookups.
AnswersB, C

Catalog UI Policies attach to the catalog item definition itself, so they govern both catalog items and record producers, which share that same underlying structure. This satisfies the stem's requirement by covering record producers, not just items.

Why this answer

Catalog UI Policies are applicable to both Catalog Items and Record Producers, so option B is correct because these policies can control field visibility, mandatory status, and read-only behavior on any catalog-facing form, including record producer forms that create records like incidents or requests. Option C is also correct because Catalog UI Policies support declarative actions such as setting a field to visible, mandatory, or read-only without writing JavaScript, unlike Catalog Client Scripts which require scripting. Option A is incorrect because Catalog UI Policies run on the client side to dynamically alter the form, not on the server side before database insertion; server-side logic would be handled by business rules or other server scripts.

Option D is incorrect because Catalog UI Policies work in Service Portal and other catalog interfaces, not only legacy UI16 forms. Option E is incorrect because Catalog UI Policies cannot replace Catalog Client Scripts in all scenarios; client scripts are still needed for asynchronous database lookups, complex validation, or custom logic that declarative UI policy actions cannot perform.

Exam trap

CIS-ITSM often tests the confusion between Catalog UI Policies and Catalog Client Scripts, leading candidates to incorrectly think UI Policies can handle all client-side logic including asynchronous lookups.

Full explanation →
170
MCQhard

A developer is writing a Catalog Client Script that needs to interact with variables inside a Multi-Row Variable Set (MRVS). Which g_form method is used to retrieve the entire contents of an MRVS as an object/string?

A.g_form.getValue('mrvs_internal_name')
B.g_scratchpad.getVariableSet()
C.g_form.getMRVSValue()
D.g_form.getMatrixValue()
AnswerA

For a Multi-Row Variable Set, g_form.getValue returns the entire set serialised as a JSON string using the MRVS internal name, which the script can then parse. This satisfies the requirement to retrieve all rows at once.

Why this answer

In ServiceNow, g_form.getValue() is the standard method used to retrieve the value of a variable, including Multi-Row Variable Sets, where it returns the MRVS contents as a JSON string that can be parsed into an object. This is the documented approach for accessing the entire MRVS payload from a Catalog Client Script.

Exam trap

The trap is inventing plausible-sounding API method names — candidates who have not memorized the actual g_form API may select getMRVSValue() or getMatrixValue(), which do not exist in ServiceNow.

How to eliminate wrong answers

Option B is wrong because g_scratchpad is a server-to-client data passing mechanism, not a method for reading MRVS values, and getVariableSet() is not a valid g_scratchpad method. Option C is wrong because g_form.getMRVSValue() does not exist in the ServiceNow API — it is a fabricated method name. Option D is wrong because g_form.getMatrixValue() is not a real API method; matrix variables use g_form.getValue() with the variable name, not a dedicated getMatrixValue() call.

Full explanation →
171
Multi-Selectmedium

A Change Manager is preparing a Normal Change for implementation and wants to ensure that the change record captures the plan for backing out if the implementation fails, as required by the organization's change policy. Which TWO actions should the Change Manager perform on the Change Request? (Choose two.)

Select 2 answers
A.Move the Change Request to the Review state before implementation
B.Set the Change Request Type to Standard
C.Attach the rollback procedure document to the Change Request as an attachment
D.Create a Change Task for the rollback and assign it to the implementer
E.Populate the Backout plan field with the documented rollback procedure
AnswersC, E

Attaching the detailed rollback procedure provides the full step-by-step documentation that may be too long for the Backout plan field. Attachments are visible to approvers and implementers and are retained with the change record for audit. This complements the Backout plan field and ensures the rollback guidance is available during implementation.

Why this answer

The organization's policy requires a documented backout plan on the change record. The Backout plan field is the standard location for the rollback procedure, and attaching a detailed document supplements it with full step-by-step instructions. Together they ensure implementers and approvers have the rollback guidance, satisfying the policy without altering the change type or lifecycle.

Exam trap

The trap here is assuming a rollback task or a type change satisfies the backout requirement, when the policy calls for documented rollback content on the change record.

Full explanation →
172
Multi-Selecthard

Which THREE of the following features are characteristic of Order Guides in ServiceNow? (Choose three.)

Select 3 answers
A.They replace the requirement for approval workflows entirely.
B.They allow users to submit multiple related catalog items as a single order.
C.They provide a 'Describe Needs' initial stage to gather high-level user requirements.
D.They use a Rule Base to conditionally include or exclude specific catalog items.
E.They can only be used by ITIL fulfillment agents, not end users.
AnswersB, C, D

Order Guides let users select and submit multiple related catalog items together as a single order, rather than raising separate requests. This bundling is the core purpose of an Order Guide and distinguishes it from individual catalogue items.

Why this answer

Order guides present an initial describe needs phase, evaluate rule bases to determine conditional items, and bundle multiple items into a single cart checkout.

Full explanation →
173
MCQhard

When configuring an Order Guide, how does the system determine which Catalog Items to present to the user in the subsequent steps?

A.Using Catalog Client Scripts attached to the Order Guide container
B.Using variable sets mapped to the target items
C.Using Order Guide Rules
D.Using Flow Designer flow triggers
AnswerC

Order Guide Rules drive conditional logic that filters and presents eligible Catalog Items based on the user's prior selections, satisfying the requirement that subsequent steps adapt dynamically. Unlike static inclusion lists, rules evaluate variables at runtime, ensuring only relevant items appear as the user progresses through the guide.

Why this answer

Order Guide Rules determine which Catalog Items are presented in subsequent steps of an Order Guide. These rules are evaluated based on user selections in previous steps, and they conditionally include or exclude catalog items. This allows for dynamic, guided ordering experiences where the available items depend on earlier choices.

Exam trap

CIS-ITSM often tests the confusion between Order Guide Rules and other mechanisms like Client Scripts or Flow Designer, leading candidates to overlook the specific rule-based determination of catalog items.

How to eliminate wrong answers

Option A is wrong because Catalog Client Scripts attached to the Order Guide container can manipulate the form but do not determine which catalog items are presented in steps; that is the role of Order Guide Rules. Option B is wrong because variable sets mapped to target items are used to share variables across items, not to determine which items appear in steps. Option D is wrong because Flow Designer flow triggers are used for automation and orchestration, not for defining the presentation of catalog items in an Order Guide.

Full explanation →
174
MCQhard

A company integrates Problem Management with an external bug tracker. When a Problem state changes in ServiceNow, an outbound REST message must be sent asynchronously. Which ServiceNow feature should trigger this outbound REST call?

A.An asynchronous Business Rule or Flow Designer action invoking a REST message
B.A UI Policy with an inbound webhook script
C.A Dictionary Override on the REST endpoint field
D.A synchronous Client Script using XMLHttpRequest
AnswerA

An asynchronous Business Rule or Flow Designer action runs after the transaction commits, so the outbound REST message fires without blocking the Problem state change. This satisfies the requirement for a non-blocking, asynchronous call to the external bug tracker.

Why this answer

An asynchronous Business Rule or Flow Designer action invoking a REST message is the correct feature to trigger an outbound REST call asynchronously when a Problem state changes. Business Rules can be configured to run asynchronously, meaning they execute in a separate thread after the transaction commits, preventing user delay. Flow Designer actions can also make REST calls asynchronously as part of a flow.

This ensures the external bug tracker is notified without impacting the user's session.

Exam trap

CIS-ITSM often tests the misconception that client-side scripts can handle outbound REST calls, but the exam expects knowledge that server-side asynchronous mechanisms are required for reliable integrations.

How to eliminate wrong answers

Option B is wrong because a UI Policy with an inbound webhook script is not a valid mechanism for outbound REST calls; UI Policies are client-side and cannot send outbound REST messages. Option C is wrong because a Dictionary Override on the REST endpoint field does not trigger REST calls; Dictionary Overrides are used to change field behavior or labels. Option D is wrong because a synchronous Client Script using XMLHttpRequest runs in the browser, is not asynchronous in the context of server-side state changes, and is not reliable for outbound integrations; it also exposes credentials and is not best practice.

Full explanation →
175
MCQhard

An enterprise uses Agile Development in tandem with Problem Management. When a root cause points to a software defect, the team wants to create a Defect record in ServiceNow Agile Development directly from the Problem form. How is this integration typically achieved?

A.By configuring a UI Action on the Problem form that instantiates an Agile Defect record and establishes a relationship
B.By mapping Data Lookup definitions between rm_defects and problem tables
C.By editing the core cmdb_ci relationship formatter
D.By changing the base table of the problem table to rm_defect
AnswerA

A UI Action on the Problem form runs server-side script that creates an Agile Defect record and links it to the Problem, giving agents one-click defect creation with traceable relationship, which is the standard ServiceNow integration pattern.

Why this answer

Configuring UI Actions or extending Agile Development plugins enables creating Agile artifacts (Stories, Defects, Epics) from task forms like Problem.

Full explanation →
176
Multi-Selecthard

An administrator is troubleshooting a Catalog Client Script that is not executing properly on a Service Portal catalog item. Which THREE factors should be verified? (Choose three.)

Select 3 answers
A.The user has admin rights to the database
B.The 'UI Type' field is set to 'Mobile/Service Portal' or 'All'
C.The correct variable name is referenced in the script and applies to the catalog item
D.The script is written in Java rather than JavaScript
E.The script is marked as 'Active'
AnswersB, C, E

Scripts configured exclusively for Desktop (UI Type = Desktop) will not execute in Service Portal.

Why this answer

Option B is correct because a Catalog Client Script only runs on the Service Portal when its UI Type field is set to 'Mobile/Service Portal' or 'All'; if it is set to 'Desktop' or 'Both' (legacy), it will not fire in the portal. Option C is correct because the script must reference the exact variable name (sys_id/name) defined on that catalog item, and the script must be associated with the correct catalog item or variable set, otherwise the logic never applies. Option E is correct because an inactive Catalog Client Script is not executed at all, so the Active flag must be checked.

Option A is incorrect because admin rights to the database are irrelevant to client-side script execution in the portal. Option D is incorrect because Catalog Client Scripts are written in JavaScript (with the GlideForm/g_form API), not Java.

Exam trap

CIS-ITSM often tests the misconception that Catalog Client Scripts work identically across all interfaces, but the UI Type field is a common cause of scripts not executing in Service Portal.

Full explanation →
177
Multi-Selecthard

An administrator is setting up service commitments and metrics in Service Portfolio Management. Which TWO elements can be defined as part of a Service Commitment? (Choose two.)

Select 2 answers
A.Reliability or uptime metrics
B.Availability target percentage
C.Active directory group membership approval workflows
D.Physical rack elevation layout diagrams
E.Network firewall port opening rules
AnswersA, B

Reliability or uptime metrics are defined directly within a Service Commitment, satisfying the stem's requirement for commitment elements. Service Commitments specify measurable performance targets such as availability percentages, which underpin service level agreements. This makes uptime a valid commitment component rather than a supporting configuration item.

Why this answer

In Service Portfolio Management, a Service Commitment defines the measurable performance and availability promises made to consumers, so option A (reliability or uptime metrics) is correct because metrics such as MTBF, MTTR, or uptime percentages are exactly the quantifiable reliability measures attached to a commitment. Option B (availability target percentage) is also correct because an availability target like 99.9% is a standard, explicitly defined commitment value used to measure whether the service meets its agreed service level. The remaining options do not belong: option C (Active Directory group membership approval workflows) is an identity and access management process, not a service commitment metric; option D (physical rack elevation layout diagrams) is a data center facilities/asset artifact; and option E (network firewall port opening rules) is a network security configuration detail, none of which are defined as service commitments in Service Portfolio Management.

Exam trap

CIS-ITSM often tests whether candidates can distinguish service-level metrics (uptime, availability) from unrelated IT artifacts (AD groups, rack diagrams, firewall rules) that sound technical but have nothing to do with Service Commitments.

Full explanation →
178
MCQmedium

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

A.Workflow
B.Inactivity Monitor
C.Business Rule
D.Client Script
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
179
MCQmedium

An administrator needs to ensure that a catalog item displays a warning message at the top of the form whenever a specific variable is changed. Which script type is best suited for this?

A.Catalog Client Script (OnChange)
B.Catalog UI Policy (Run scripts)
C.Business Rule (Display)
D.Catalog Server Script
AnswerA

A Catalog Client Script with an OnChange event fires immediately in the browser when the specified variable's value changes, letting the script call `g_form.showFieldMsg` or similar to render the warning at the top of the form without a server round-trip. This satisfies the stem's requirement for instant, client-side feedback on variable change.

Why this answer

A Catalog Client Script with the OnChange script type is designed to execute when a specific variable's value changes on the catalog item form. This is the correct place to evaluate the new value and display a warning message (e.g., via g_form.showFieldMsg or alert) at the top of the form. It runs client-side in the browser, giving immediate feedback without a server round-trip.

Exam trap

The trap is confusing UI Policy 'Run scripts' with Catalog Client Script OnChange — both can run JavaScript on variable change, but the exam expects you to know that OnChange is the purpose-built script type for reacting to a specific variable's change.

How to eliminate wrong answers

Option B is wrong because Catalog UI Policies with 'Run scripts' execute on field value changes but are intended for field visibility, mandatory, and read-only logic — they can run scripts, but the canonical mechanism for custom warning messages tied to a variable change is a Catalog Client Script OnChange. Option C is wrong because Business Rules run server-side on database operations and cannot directly display a form warning to the user in real time. Option D is wrong because 'Catalog Server Script' is not a standard ServiceNow script type — server-side catalog logic uses Business Rules, Script Includes, or workflow scripts, none of which render client-side warnings.

Full explanation →
180
Multi-Selecteasy

Which TWO methods can be used to navigate to Problem Management modules in the ServiceNow application navigator? (Choose two.)

Select 2 answers
A.Clicking on System Security > Certificates
B.Navigating via Problem > Open or Problem Administration > Properties
C.Accessing Facilities > Work Orders
D.Opening the Incident menu and selecting 'Payroll Runs'
E.Typing 'Problem' in the Filter navigator box
AnswersB, E

The application navigator exposes Problem Management through its hierarchical menu structure. Expanding Problem > Open or Problem Administration > Properties drills into the specific modules, which is the standard click-through navigation path within the ServiceNow interface.

Why this answer

Option B is correct because the ServiceNow application navigator organizes Problem Management under the Problem menu (e.g., Problem > Open, Problem > Assigned to me) and the Problem Administration module (e.g., Problem Administration > Properties), so navigating those paths reaches Problem Management modules. Option E is correct because the Filter navigator box at the top of the application navigator accepts typed text and performs a live search, so typing 'Problem' filters the menu to display the Problem-related modules for direct navigation. Option A is incorrect because System Security > Certificates belongs to certificate management, not Problem Management.

Option C is incorrect because Facilities > Work Orders is part of Facilities Management, unrelated to Problem records. Option D is incorrect because the Incident menu contains incident-related modules, and 'Payroll Runs' is not a Problem Management module.

Exam trap

CIS-ITSM often tests the distinction between valid navigation paths and unrelated modules, so candidates must recognize that only the Problem menu and Filter navigator search are correct, while options referencing unrelated applications (e.g., Facilities, System Security) are distractors.

Full explanation →
181
MCQmedium

An implementation specialist is asked to configure lifecycle stages for service offerings. What are the baseline lifecycle stages available out-of-the-box in ServiceNow SPM?

A.New, Work in Progress, Pending, Complete
B.Pipeline, Operational, Retired
C.Draft, Active, Suspended, Closed
D.Planning, Developing, Testing, Live, Maintenance, EOL
AnswerB

ServiceNow SPM ships three baseline lifecycle stages: Pipeline, Operational and Retired. Pipeline covers offerings still being planned or built, Operational covers those live and available to consumers, and Retired covers decommissioned offerings, satisfying the stem's requirement for out-of-the-box stages without custom configuration.

Why this answer

The baseline lifecycle stages for service offerings in ServiceNow SPM are Pipeline, Operational, and Retired. These stages represent the offering's journey from being planned (Pipeline) to being actively available (Operational) and finally being phased out (Retired). This out-of-the-box configuration aligns with the product lifecycle management approach in SPM.

Exam trap

CIS-ITSM often tests the distinction between lifecycle stages and other state fields, such as operational status or approval states, causing candidates to confuse them with generic project or task states.

How to eliminate wrong answers

Option A is wrong because 'New, Work in Progress, Pending, Complete' are typical task or project states, not service offering lifecycle stages. Option C is wrong because 'Draft, Active, Suspended, Closed' are common states for records like knowledge articles or contracts, not SPM service offering stages. Option D is wrong because 'Planning, Developing, Testing, Live, Maintenance, EOL' are more granular phases often used in product development or ITIL service lifecycle, but they are not the baseline stages provided out-of-the-box in ServiceNow SPM.

Full explanation →
182
MCQeasy

What is the primary function of the Change Advisory Board (CAB) Workbench?

A.To automatically execute risk assessments
B.To create standard change catalog items
C.To discover configuration items on the network
D.To manage, track, and conduct CAB meetings efficiently
AnswerD

The CAB Workbench provides a dedicated interface for scheduling, running, and recording Change Advisory Board meetings, including agendas, attendees, and decisions. It centralises governance of change requests, directly fulfilling the stem's requirement to manage, track, and conduct CAB meetings efficiently.

Why this answer

The CAB Workbench is a dedicated interface in ServiceNow that lets change managers schedule, run, and document CAB meetings. It aggregates change requests, displays agendas, captures decisions, and records meeting minutes in one place. Its primary purpose is to streamline the governance meeting process rather than automate risk or create catalog items.

Exam trap

CIS-ITSM often tests whether candidates confuse the CAB Workbench with risk automation or catalog creation tools, so pick the answer that emphasizes meeting management, not technical automation.

How to eliminate wrong answers

Option A is wrong because risk assessments are generated by risk assessment questionnaires and the Change Management risk engine, not the CAB Workbench. Option B is wrong because standard change catalog items are created via std_change_proposal and std_change_record_producer, not the CAB Workbench. Option C is wrong because CI discovery is performed by Discovery and Service Mapping, not the CAB Workbench.

Full explanation →
183
MCQeasy

What is the function of the 'No 'Add to Cart'' checkbox on a catalog item form?

A.It completely disables ordering of the item.
B.It removes the 'Add to Cart' button, leaving only the 'Order Now' button.
C.It prevents the item from appearing in search results.
D.It restricts checkout to users with the admin role.
AnswerB

Ticking this checkbox suppresses the cart workflow entirely, so the catalog item form renders only the 'Order Now' button. The item is submitted directly as a request rather than staged in a cart, which suits single-quantity or service-style items.

Why this answer

The 'No Add to Cart' checkbox on a catalog item form, when checked, removes the 'Add to Cart' button from the item's catalog page, leaving only the 'Order Now' button. This forces users to go through the checkout process immediately for that item, rather than adding it to a cart with other items. It does not disable ordering entirely.

Exam trap

CIS-ITSM often tests the difference between 'No Add to Cart' and 'Hide on search' or 'Disable ordering'; candidates may think it disables ordering, but it only removes the cart option.

How to eliminate wrong answers

Option A is wrong because the item can still be ordered via 'Order Now'; it only removes the cart option. Option C is wrong because the checkbox does not affect search visibility; that is controlled by 'Hide on search' or catalog visibility settings. Option D is wrong because it does not restrict checkout to admins; that would require user criteria or role restrictions.

Full explanation →
184
MCQmedium

An organization wants to track problem metrics using Performance Analytics. Which plugin must be active to utilize out-of-the-box Performance Analytics content packs for Problem Management?

A.Incident and Problem Analytics Pack
B.ITSM Performance Analytics Core
C.Problem Management Advanced Analytics
D.Performance Analytics - Content Pack - Problem Management
AnswerD

The Performance Analytics - Content Pack - Problem Management plugin installs the prebuilt indicators, breakdowns, and dashboards that surface problem metrics. Without it, Performance Analytics holds no out-of-the-box Problem Management content, so the required tracking cannot be delivered.

Why this answer

The out-of-the-box Performance Analytics content for Problem Management is delivered through the dedicated plugin 'Performance Analytics - Content Pack - Problem Management.' This plugin installs the pre-built indicators, breakdowns, and dashboards specific to Problem Management KPIs such as open problems, mean time to resolve, and aging. Without this content pack activated, the Problem Management dashboards and indicators will not be populated with baseline data.

Exam trap

CIS-ITSM often tests whether candidates can distinguish between the base Performance Analytics plugin and the process-specific content pack plugin — candidates frequently pick a plausible-sounding but non-existent 'Analytics Pack' name instead of the exact 'Content Pack' plugin.

How to eliminate wrong answers

Option A is wrong because 'Incident and Problem Analytics Pack' is not a real ServiceNow plugin name — it conflates two separate content packs and does not exist in the plugin registry. Option B is wrong because 'ITSM Performance Analytics Core' is not the correct plugin identifier; the core ITSM content is delivered via separate content packs per process (Incident, Problem, Change, etc.), not a single 'Core' plugin. Option C is wrong because 'Problem Management Advanced Analytics' is a fabricated name — no such plugin exists; the actual plugin uses the 'Content Pack' naming convention.

Full explanation →
185
MCQeasy

An administrator is creating a Record Producer. Which table should the resulting records be generated in?

A.sc_req_item
B.sc_request
C.A target table specified in the Record Producer definition (e.g., incident or custom table)
D.sys_user
AnswerC

A Record Producer writes into whatever target table its definition names, so records land in that specified table rather than a fixed one. This satisfies the requirement that the resulting records be generated in a chosen destination.

Why this answer

A Record Producer can generate records in any specified target table, such as incident, problem, change, or a custom table. The target table is defined in the Record Producer's configuration. This allows the producer to create records of that type when the catalog item is ordered.

Exam trap

CIS-ITSM often tests the distinction between Record Producers and standard catalog items; candidates may think Record Producers always create sc_req_item records, but they actually create records in the specified target table.

How to eliminate wrong answers

Option A is wrong because sc_req_item is the default table for catalog items that go through the request process, but a Record Producer can target other tables. Option B is wrong because sc_request is the request table, not the target for Record Producer output. Option D is wrong because sys_user is the user table, which is not a typical target for a Record Producer unless specifically configured, but the question asks for the general answer.

Full explanation →
186
MCQmedium

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

A.The incident table
B.The groups table
C.The sys_user table
D.The cmn_department table
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
187
MCQmedium

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

A.Incident Timeline.
B.Incident History.
C.Task SLA.
D.Dependency View.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
188
MCQmedium

An organization requires that when a user selects 'Hardware' in a dropdown variable, three specific hardware-related variables become mandatory. Which approach represents best practice in ServiceNow?

A.Catalog UI Policy
B.Catalog Client Script (OnChange)
C.Data Policy on the sc_req_item table
D.Order Guide Rule Base
AnswerA

A Catalog UI Policy dynamically makes variables mandatory or visible based on another variable's value, satisfying the requirement that selecting 'Hardware' forces three related fields to become mandatory. Client scripts could also do this, but UI Policies are declarative best practise, requiring no code and remaining maintainable.

Why this answer

A Catalog UI Policy is the best practice in ServiceNow for dynamically making variables mandatory based on the value of another variable. UI Policies run on the client side and can set variables to mandatory, visible, or read-only without writing custom scripts. This declarative approach is easier to maintain and less error-prone than client scripts.

Exam trap

CIS-ITSM often tests the preference for declarative UI Policies over custom client scripts for dynamic form behavior, causing candidates to choose the scripted solution.

How to eliminate wrong answers

Option B is wrong because a Catalog Client Script (OnChange) would require custom JavaScript to set the mandatory flag, which is less maintainable and not best practice when a UI Policy can achieve the same result. Option C is wrong because a Data Policy on the sc_req_item table enforces rules at the database level and is not designed for dynamic form behavior based on variable values. Option D is wrong because an Order Guide Rule Base is used to define multi-step order guides, not to enforce variable mandatory conditions within a single catalog item.

Full explanation →
189
MCQhard

An organization requires that when a Problem goes to 'Resolved', all related active incidents must be updated with the workaround text and moved to 'Awaiting User Info' state. How should this be configured for optimal performance?

A.A Script Include combined with a Problem Business Rule to batch-update related incidents
B.An Access Control List script with update capabilities
C.A Dictionary Client Script on the Incident table
D.A Client Script running on the Problem form with synchronous GlideRecord loops
AnswerA

Encapsulating business logic in a Script Include called by a Business Rule ensures clean, maintainable, and high-performance server processing.

Why this answer

A Script Include combined with a Problem Business Rule is the correct approach because Business Rules execute server-side on the Problem table when the state changes to 'Resolved'. The Script Include encapsulates the batch update logic (using GlideRecord or GlideMultipleUpdate) to efficiently update all related active incidents, setting the workaround field and changing state to 'Awaiting User Info'. This server-side approach ensures data integrity and optimal performance by avoiding client-side loops and leveraging the platform's bulk update capabilities.

Exam trap

CIS-ITSM often tests the misconception that client-side scripts can handle cross-table batch updates, but the exam expects knowledge that server-side Business Rules with Script Includes are required for performance and data integrity.

How to eliminate wrong answers

Option B is wrong because an Access Control List script only controls record-level read/write/delete access and cannot perform business logic updates on related records. Option C is wrong because a Dictionary Client Script runs on the client side and cannot reliably update multiple related incident records, especially in bulk, and is not designed for cross-table operations. Option D is wrong because a Client Script on the Problem form with synchronous GlideRecord loops runs in the browser, causing performance degradation, potential timeouts, and is not suitable for batch updates across many records.

Full explanation →
190
Multi-Selecthard

An enterprise is auditing its ServiceNow instance for ITIL compliance in Problem Management. Which TWO core metrics or practices are typically evaluated to measure Problem Management effectiveness? (Choose two.)

Select 2 answers
A.Reduction in recurring incidents linked to known problems
B.Total number of printer toner cartridges ordered annually
C.Percentage of known errors documented with workarounds in the KEDB
D.Average employee commute distance
E.Frequency of firewall firmware updates
AnswersA, C

Problem Management effectiveness is measured by tracking how many recurring incidents are eliminated once a known error's root cause is fixed. A falling count of incidents tied to known problems demonstrates that permanent resolutions are working, satisfying the stem's audit criterion.

Why this answer

Option A is correct because a primary measure of Problem Management effectiveness is the reduction in recurring incidents tied to known problems, demonstrating that root cause analysis and permanent fixes are working. Option C is correct because documenting known errors with workarounds in the Known Error Database (KEDB) is a core ITIL practice that directly supports faster incident resolution and is measured as a percentage of known errors properly recorded. Options B, D, and E are incorrect because toner cartridge ordering, employee commute distance, and firewall firmware update frequency are unrelated to Problem Management metrics and do not reflect ITIL Problem Management practices.

Exam trap

CIS-ITSM often tests whether candidates can distinguish Problem Management metrics from Incident, Change, or Asset Management metrics — the trap is picking a plausible-sounding operational metric that belongs to another practice.

Full explanation →
191
MCQeasy

What is the primary purpose of the 'Description' field on a Problem record?

A.To hold the XML payload of inbound emails
B.To log the license key of the software
C.To provide a detailed explanation of the symptoms and issue observed
D.To store the administrator's login credentials
AnswerC

The Description field captures the detailed symptoms and observed issue, giving resolvers the technical context needed to investigate the problem's root cause. This satisfies the stem's requirement for the field's primary purpose: documenting what was actually seen, distinct from workaround or resolution notes recorded elsewhere on the Problem record.

Why this answer

The 'Description' field on a Problem record is a free-text field used to capture a detailed explanation of the symptoms and the issue observed. It provides the problem analyst with the context needed to understand what is happening, when it started, and how it impacts users, forming the basis for investigation and root cause analysis.

Exam trap

CIS-ITSM often tests the distinction between Description (symptoms/issue) and other fields like Work notes (internal updates) or Additional comments (user-facing), so candidates who confuse these fields pick the wrong purpose.

How to eliminate wrong answers

Option A is wrong because XML payloads of inbound emails are stored in the email body or attachment fields (e.g., sys_email table), not in the Problem Description field. Option B is wrong because license keys are typically stored in CMDB configuration item records or a dedicated license management table, not in a problem's description. Option D is wrong because storing administrator credentials in any description field is a security violation and has no relation to the purpose of the Description field.

Full explanation →
192
Multi-Selecthard

An administrator is troubleshooting why conflict detection is not evaluating custom CI relationship types. Which THREE components control how CI relationships are traversed during conflict detection? (Choose three.)

Select 3 answers
A.Service Catalog workflow versioning rules
B.CI relationship type definitions (cmdb_rel_type) specifying upstream/downstream semantics
C.Conflict detection system properties enabling relationship traversal
D.Incident management priority lookup tables
E.Script includes (such as ConflictFinderSNC) containing the traversal query logic
AnswersB, C, E

CI relationship type definitions in cmdb_rel_type carry the parent/child and upstream/downstream semantics that conflict detection traverses, so custom types must be defined there before evaluation occurs. Without these directional definitions, the engine cannot resolve how custom relationships connect CIs, leaving them unevaluated during conflict detection.

Why this answer

Option B is correct because CI relationship type definitions in the cmdb_rel_type table specify the parent/child (upstream/downstream) semantics that conflict detection uses to determine how related CIs are traversed; if a custom relationship type is not properly defined there, traversal will not evaluate it. Option C is correct because conflict detection system properties (such as those controlling whether relationship traversal is enabled and which relationship types are considered) govern whether and how the engine walks CI relationships during evaluation. Option E is correct because script includes like ConflictFinderSNC contain the actual traversal query logic that builds and executes the relationship queries, so custom relationship types must be handled by that logic to be evaluated.

Option A is not relevant because Service Catalog workflow versioning rules govern catalog item workflow versions, not CMDB relationship traversal. Option D is not relevant because incident priority lookup tables map impact/urgency to priority and have no role in how CI relationships are traversed during conflict detection.

Exam trap

CIS-ITSM often tests the misconception that conflict detection is driven purely by a single system property or by relationship records alone, when in fact it requires the relationship type definition, the enabling property, and the traversal script include working together.

Full explanation →
193
MCQeasy

Which module allows users to view available pre-approved templates to create a change request quickly?

A.Standard Change Catalog
B.Emergency Change Repository
C.Change Schedule Calendar
D.Normal Change Generator
AnswerA

The Standard Change Catalog presents pre-approved templates for low-risk, repeatable changes, letting users raise a change request without full assessment or CAB review. This directly satisfies the stem's requirement for quick creation from available templates, as standard changes carry pre-authorised approval by definition.

Why this answer

The Standard Change Catalog module allows users to view available pre-approved templates to create a change request quickly. Standard changes are pre-approved, low-risk changes that follow a defined procedure. The catalog provides a list of these templates, enabling users to submit a change request without going through the full approval process.

Exam trap

CIS-ITSM often tests the confusion between standard change templates and other change types, where candidates might incorrectly choose a module for normal or emergency changes when the question asks for pre-approved templates, which are found in the Standard Change Catalog.

How to eliminate wrong answers

Option B is wrong because there is no 'Emergency Change Repository' module; emergency changes are typically created via the Emergency Change process, not a repository. Option C is wrong because the Change Schedule Calendar shows scheduled changes, not templates for creating them. Option D is wrong because 'Normal Change Generator' is not a standard module; normal changes are created via the Change module, but they are not pre-approved templates.

Full explanation →
194
MCQmedium

An analyst wants to search for problems that mention a specific error code in their description or workaround notes. Which ServiceNow search feature indexes and searches across all Problem records efficiently?

A.Global Text Search (Zing / AI Search)
B.Database Views builder
C.Metric Definition report generator
D.Data Archiving search query tool
AnswerA

Global Text Search (Zing / AI Search) indexes all indexed fields across Problem records, including description and workaround notes, so a single query returns matching problems without building explicit filters. This satisfies the requirement to search free-text error codes efficiently across the entire Problem table.

Why this answer

Global Text Search (backed by Zing in older releases and AI Search in newer ones) indexes searchable fields across all records, including Problem short descriptions, descriptions, and workaround notes, so an analyst can find records by keyword or error code without building a filtered list query. It is the platform's cross-table full-text search engine.

Exam trap

CIS-ITSM often tests the misconception that any list filter or report can 'search' free text — candidates pick Database Views or reports, missing that only Global Text Search / AI Search performs indexed full-text lookup across records.

How to eliminate wrong answers

Option B is wrong because Database Views builder creates joined, read-only views of multiple tables for reporting — it does not index or search free-text content. Option C is wrong because Metric Definition reports track numeric KPIs over time, not textual content in descriptions or work notes. Option D is wrong because Data Archiving moves aged records to archive tables; its query tool filters records for archival, it does not provide full-text search across live Problem records.

Full explanation →
195
Multi-Selectmedium

Which TWO features are supported by Multi-Row Variable Sets (MRVS) in ServiceNow Service Catalog? (Choose two.)

Select 2 answers
A.Automatically generating a separate incident record for each row submitted
B.Supporting Catalog UI Policies and Catalog Client Scripts
C.Storing data directly in permanent custom table columns during initial cart checkout
D.Allowing users to enter tabular, multi-row data collections within a single catalog item
E.Replacing standard workflows with spreadsheet imports
AnswersB, D

Multi-Row Variable Sets render as a grid, and ServiceNow supports Catalog UI Policies and Catalog Client Scripts against their child variables, letting you enforce mandatory fields or dynamic behaviour per row. This satisfies the requirement for interactive control within the tabular collection.

Why this answer

Option B is correct because Multi-Row Variable Sets (MRVS) fully support Catalog UI Policies and Catalog Client Scripts, allowing dynamic show/hide, mandatory, and read-only behavior on the grid's fields and rows. Option D is correct because the core purpose of an MRVS is to let a user enter tabular, multi-row data collections (a grid of repeated field sets) within a single catalog item, with the collected rows stored as a JSON array in the variable's value. The unmarked options do not belong: A is wrong because MRVS does not auto-create an incident per row (that would require custom scripting or Flow Designer logic), C is wrong because MRVS data is held as JSON in the variable value rather than written directly to permanent custom table columns at cart checkout, and E is wrong because MRVS neither replaces workflows nor performs spreadsheet imports.

Exam trap

CIS-ITSM often tests the misconception that MRVS create separate records or replace workflows — the correct understanding is that MRVS are a tabular data collection tool stored as JSON, with client script and UI policy support.

Full explanation →
196
Multi-Selectmedium

Which TWO statements are true regarding Record Producers in ServiceNow? (Choose two.)

Select 2 answers
A.They prevent users from accessing the Service Portal
B.Variables can be mapped directly to fields on the target table record
C.They are restricted to creating records only in the sc_req_item table
D.They require an Order Guide to function
E.They generate records in a target table specified in their definition, such as Incident or a custom table
AnswersB, E

Record Producer variables can be mapped to target table fields, so values entered on the producer form populate the created record directly. This satisfies the stem's truth condition by describing the actual data-flow mechanism between the producer's variable set and the target record.

Why this answer

Option B is correct because Record Producers use variable-to-field mapping so that values entered in the producer's variables are written directly into fields on the newly created target record. Option E is correct because a Record Producer is defined with a target table (for example Incident, sc_req_item, or a custom table), and submitting the producer creates a record in that specified table. Options A, C, and D are incorrect: Record Producers do not block Service Portal access, they are not limited to sc_req_item, and they do not require an Order Guide to function.

Exam trap

CIS-ITSM often tests the misconception that Record Producers are tied to sc_req_item or require an Order Guide — candidates confuse them with catalog items and Order Guides, which are separate constructs.

Full explanation →
197
Multi-Selecthard

Which THREE are characteristics of a Standard Change?

Select 3 answers
A.Low risk
B.Requires emergency intervention
C.Repeatable process
D.Requires CAB approval
E.Pre-authorized
AnswersA, C, E

Standard Changes are pre-approved, low-risk, well-understood changes with a documented procedure, so they bypass the full change advisory board review. Low risk is a defining characteristic, distinguishing them from Normal Changes requiring assessment and authorisation.

Why this answer

A Standard Change is a pre-approved, low-risk change that follows a documented, repeatable procedure, so option A ("Low risk") is correct because standard changes are by definition low-risk and well-understood. Option C ("Repeatable process") is correct because standard changes are performed using an established, documented procedure that has been proven through repetition. Option E ("Pre-authorized") is correct because standard changes are authorized in advance by change management, so they do not need individual approval each time they are implemented.

Option B is incorrect because standard changes are routine and do not require emergency intervention, which applies to emergency changes. Option D is incorrect because standard changes are pre-authorized and do not require CAB approval for each occurrence.

Exam trap

CIS-ITSM often tests the confusion between Standard and Normal Changes, tempting candidates to think Standard Changes require CAB approval, but they are pre-approved.

Full explanation →
198
MCQhard

During conflict detection, ServiceNow identifies a 'Blackout Schedule' conflict. What does this indicate?

A.The change implementer lacks the required security role during off-hours
B.The change is scheduled during a predefined period where changes are prohibited for the target CI or service
C.The CI is currently marked as offline in the CMDB
D.Another change is scheduled at the exact same time on the same CI
AnswerB

A Blackout Schedule defines windows in which changes are barred for a given CI or service, so this conflict flags that the planned change falls inside a prohibited period. Conflict detection surfaces it because the schedule constraint is violated, requiring rescheduling or an approved exemption before the change can proceed.

Why this answer

A Blackout Schedule conflict in ServiceNow indicates that the change's planned window overlaps with a defined blackout period — a predefined time range during which changes are prohibited for a specific CI, service, or the entire organization. Blackout schedules are configured on the CI or via the Change Management blackout schedule records to protect critical business periods (e.g., month-end, holidays). Conflict detection flags this so the change cannot proceed without justification or rescheduling.

Exam trap

CIS-ITSM often tests the distinction between conflict types — candidates confuse Blackout Schedule conflicts (prohibited time windows) with Schedule Overlap conflicts (another change at the same time) and pick the wrong option.

How to eliminate wrong answers

Option A is wrong because missing security roles is an ACL/authorization issue, not a conflict detection outcome — conflict detection evaluates scheduling, not user permissions. Option C is wrong because CI operational status (offline) is tracked in the CMDB as install status or operational status, and does not trigger a Blackout Schedule conflict. Option D is wrong because another change at the same time on the same CI produces a Schedule Overlap conflict, not a Blackout Schedule conflict — these are distinct conflict types in the ConflictFinderSNC logic.

Full explanation →
199
Multi-Selecthard

When configuring financial modeling and cost roll-ups for a Service Offering in SPM, which THREE data sources can contribute to the calculated cost of the offering? (Choose three.)

Select 3 answers
A.Direct expense lines associated with the service offering CI
B.Allocated costs from underlying infrastructure CIs linked via CSDM relationships
C.Labor costs tracked via project time cards mapped to the service
D.Syslog error count thresholds
E.Client browser cookies and cache session logs
AnswersA, B, C

Direct expense lines tied to the service offering CI feed the cost roll-up as a primary source, since SPM aggregates actual recorded expenditure against that configuration item rather than deriving it from relationships or allocations.

Why this answer

In ServiceNow SPM (Strategic Portfolio Management), the calculated cost of a Service Offering is built from financial data tied to the offering and its related configuration items. Option A is correct because direct expense lines attached to the service offering CI represent explicit, traceable costs that roll up into the offering's total. Option B is correct because allocated costs from underlying infrastructure CIs linked through CSDM (Common Service Data Model) relationships are distributed to the offering based on allocation rules, reflecting shared infrastructure consumption.

Option C is correct because labor costs captured on project time cards mapped to the service are a legitimate cost input, converting recorded effort into monetary value for the roll-up. Option D does not belong because syslog error count thresholds are operational monitoring metrics, not financial cost data sources. Option E does not belong because client browser cookies and cache session logs are unrelated to cost calculation and are not ingested as financial inputs in SPM.

Exam trap

The trap is treating any data source that touches the service as a valid cost input; the exam expects candidates to distinguish financial data (expenses, allocations, labor) from operational or client-side telemetry that has no bearing on cost roll-ups.

Full explanation →
200
MCQhard

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

A.The Assignment Rule is not active.
B.The 'Assigned to' field is already populated.
C.The incident is in a closed state.
D.The incident was created via an Email Inbound Action.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
201
MCQeasy

A team wants to create a new relationship type to define a custom dependency between hardware and business applications. Which module should be used to define this new relationship type?

A.Dependency View Configurator
B.CI Relationship Rules
C.CMDB Groups
D.Relationship Types
AnswerD

Relationship Types is the module where custom relationship types are defined, letting you specify the parent and child tables (hardware and business applications) and the relationship rules. This directly satisfies the requirement to create a new dependency type between those two tables, rather than merely viewing existing relationships.

Why this answer

The Relationship Types module is where administrators define new relationship types in the CMDB, specifying the parent-child or dependency semantics between CI classes such as hardware and business applications. Creating a new relationship type here makes it available for use in CI relationship records and dependency views. This is the correct module for defining a custom dependency relationship.

Exam trap

CIS-ITSM often tests whether candidates confuse Relationship Types (defining the relationship) with CI Relationship Rules (automating relationship creation) or Dependency View Configurator (displaying relationships), leading them to pick the wrong module.

How to eliminate wrong answers

Option A is wrong because Dependency View Configurator is used to customize how dependency views are displayed (layout, filters, icons), not to define new relationship types. Option B is wrong because CI Relationship Rules are used to automatically create relationships between CIs based on discovery or other conditions; they consume existing relationship types but do not define them. Option C is wrong because CMDB Groups are used to organize CIs into logical groups for reporting and management, not to define relationship types between CIs.

Full explanation →
202
MCQhard

A fulfillment workflow needs to dynamically assign a Catalog Task to the manager of the user specified in a catalog variable named 'target_employee'. How can this be accomplished in a workflow?

A.Write a standalone Business Rule on the sys_user table.
B.Modify the Order Guide rule base to evaluate manager hierarchy.
C.Use the Assignment group field in the Catalog Task activity configuration directly.
D.Configure the Catalog Task activity assignment to use script/dot-walking to reach current.variables.target_employee.manager.
AnswerD

Dot-walking from `current.variables.target_employee` to `.manager` resolves the referenced user's manager record at runtime, satisfying the dynamic assignment constraint without hard-coding a name. Because the variable stores a sys_user reference, the manager field is directly traversable, letting the Catalog Task activity assign to that manager automatically.

Why this answer

The Catalog Task activity in a workflow supports dynamic assignment via scripting. By using dot-walking on the current.variables object, you can directly reference the manager field of the user stored in the 'target_employee' variable. This approach leverages the workflow's access to the current record's variables and the referenced user's manager relationship, eliminating the need for external rules or manual group assignments.

Exam trap

CIS-ITSM often tests the misconception that assignment must be done via groups or business rules, overlooking the scripting capabilities within workflow activities.

How to eliminate wrong answers

Option A is wrong because a standalone Business Rule on sys_user would not have context of the catalog variable and would trigger on all user updates, not just this workflow. Option B is wrong because Order Guide rules are used for guiding catalog item selection, not for dynamic task assignment. Option C is wrong because the Assignment group field expects a group, not a user, and cannot dynamically resolve to a manager without scripting.

Full explanation →
203
Multi-Selectmedium

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

Select 2 answers
A.Define the exact salary range of incident managers.
B.Set the physical server memory allocation for the instance.
C.Configure Active Directory domain controllers.
D.Enable or disable customer updates to reopen closed incidents (e.g., com.snc.incident.reopen_closed).
E.Determine the number of days after which Resolved incidents automatically close.
AnswersD, E

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

Why this answer

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

Exam trap

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

Full explanation →
204
Multi-Selectmedium

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

Select 2 answers
A.Awaiting Assignment
B.Awaiting Approval
C.Awaiting Change
D.Awaiting Caller
E.Awaiting Vendor
AnswersD, E

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

Why this answer

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

Full explanation →
205
MCQhard

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

A.Update the UI Action condition.
B.Use a Data Policy.
C.Create a Client Script.
D.Use an ACL on the 'Major Incident' field.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
206
MCQmedium

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

A.The 'Closed' incident policy.
B.Inbound Email Action.
C.Incident State transition rules.
D.User profile settings.
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
207
Multi-Selecthard

An administrator is configuring UI Policies on the Problem table to streamline user entry. Which TWO properties or configurations can a UI Policy modify on form fields without scripting? (Choose two.)

Select 2 answers
A.Instance IP address binding
B.Java runtime memory allocation
C.Underlying database table schema definition
D.Visible state (showing or hiding fields/sections)
E.Mandatory state (making fields mandatory or optional)
AnswersD, E

UI policies manage field and section visibility.

Why this answer

UI Policies in ServiceNow are declarative, no-script configurations that control form field behavior, and option D (Visible state) is correct because a UI Policy can show or hide fields and sections on the form based on conditions, using the 'Visible' field setting. Option E (Mandatory state) is also correct because a UI Policy can make fields mandatory or optional via the 'Mandatory' field setting, again without any client script. Options A (Instance IP address binding), B (Java runtime memory allocation), and C (Underlying database table schema definition) are incorrect because these are infrastructure, platform, or schema-level concerns handled outside UI Policies — IP binding and JVM memory are system/instance configuration, and table schema is defined in the data dictionary, not on a form UI Policy.

Exam trap

CIS-ITSM often tests the capabilities of UI Policies versus Client Scripts; candidates may think UI Policies can set field values or perform complex logic, but they are limited to visible, mandatory, and read-only states (and sometimes field values via UI Policy Actions, but that is a separate action type).

Full explanation →
208
MCQeasy

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

A.Assignment Rules
B.Dictionary Overrides
C.Inbound Email Actions
D.Data Policies
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
209
MCQmedium

A change manager wants to restrict who can approve Emergency Changes. Where is this restriction configured?

A.Incident Management Properties
B.Global Business Rules only
C.Service Catalog Access Controls
D.Change Authorities and Approval Definitions
AnswerD

Change Authorities define who may approve each change type, and Approval Definitions map those authorities to specific approval records. Configuring both restricts Emergency Change approval to nominated individuals, satisfying the requirement to control who can approve them.

Why this answer

Emergency Change approval restrictions are governed by Change Authorities and Approval Definitions, which map approval rules to change types (including Emergency) and define who is authorized to approve. In ServiceNow Change Management, the 'Change Authority' records specify the approval group or user for a given change type and approval definition, so restricting Emergency Change approvers requires editing these records. This is the only location where approver eligibility per change type is enforced.

Exam trap

CIS-ITSM often tests the misconception that approval restrictions live in business rules or properties, when in fact they are configured through Change Authorities and Approval Definitions.

How to eliminate wrong answers

Option A is wrong because Incident Management Properties control incident-specific behaviors such as major incident thresholds and assignment rules, not change approvals. Option B is wrong because Global Business Rules are server-side scripts that run globally and do not define approval authority mappings for change types. Option C is wrong because Service Catalog Access Controls govern who can view or order catalog items, not who can approve Emergency Changes.

Full explanation →
210
MCQeasy

Which module allows administrators to configure categories and subcategories to organize Service Catalog items for end users?

A.Maintain Items
B.Maintain Categories
C.Order Guides
D.Catalog Definitions
AnswerB

Maintain Categories provides the hierarchical taxonomy that classifies Service Catalog items, letting administrators define parent categories and nested subcategories so end users browse offerings logically. This directly satisfies the stem's requirement to configure categories and subcategories for organising catalog items, unlike modules handling request fulfilment or approval routing.

Why this answer

The Maintain Categories module is the administrative interface in ServiceNow Service Catalog where admins create and organize the category/subcategory hierarchy that end users see when browsing the catalog. Categories defined here drive the catalog's navigation tree and can be assigned to catalog items via the Catalogs/Categories related lists. This is distinct from Maintain Items, which is where the individual catalog items themselves are created and edited.

Exam trap

CIS-ITSM often tests the distinction between Maintain Categories (taxonomy/navigation) and Maintain Items (the actual catalog records), so candidates who conflate 'organizing items' with 'creating items' pick Maintain Items incorrectly.

How to eliminate wrong answers

Option A is wrong because Maintain Items is used to create and edit the catalog items themselves (their variables, pricing, fulfillment process), not the category taxonomy that organizes them. Option C is wrong because Order Guides are multi-item request wizards that bundle several catalog items into a sequenced form — they consume categories but do not define them. Option D is wrong because 'Catalog Definitions' is not a ServiceNow module; the actual related admin modules are Maintain Catalogs, Maintain Categories, and Maintain Items, so this option is a fabricated distractor.

Full explanation →
211
Multi-Selecteasy

Which TWO fields are commonly used to define the execution window of a change request? (Choose two.)

Select 2 answers
A.Planned end date
B.Due date
C.Sys created on
D.Planned start date
E.Closed date
AnswersA, D

Planned end date marks when the change window closes, bounding the execution period alongside its start. Together with planned start date, it defines the interval during which the change may be implemented, satisfying the requirement to specify the change request's execution window.

Why this answer

In change management, the execution window is the period during which the change work is authorized to be performed, and it is bounded by the Planned start date (option D) and the Planned end date (option A). The Planned start date marks when the change implementer may begin the change tasks, while the Planned end date marks the deadline by which the change must be completed, together defining the window. The Due date (option B) is a general task/SLA deadline and does not establish the beginning of the authorized execution period, so it does not define the window.

Sys created on (option C) is an audit timestamp of when the record was created, and Closed date (option E) records when the change was actually closed, neither of which specifies the planned execution window.

Exam trap

The trap is confusing general date fields (Due date, Closed date, Sys created on) with the specific execution-window fields. Candidates must remember that ServiceNow uses 'Planned start date' and 'Planned end date' — not 'Due date' — to define when a change actually executes.

Full explanation →
212
MCQeasy

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

A.sys_user
B.task
C.problem
D.cmdb_ci
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
213
Multi-Selectmedium

Which TWO of the following are true regarding 'Catalog Client Scripts'?

Select 2 answers
A.They are used to update the sc_task state directly
B.They only run on the Service Portal
C.They can be used to make fields mandatory
D.They execute on the server side
E.They can be applied to Variable Sets
AnswersC, E

Catalog Client Scripts run in the browser against the catalog form, so they can set a variable's mandatory flag dynamically based on user input or other variables. This satisfies the requirement that the control enforces field completion before submission.

Why this answer

Option C is correct because Catalog Client Scripts run in the browser on catalog item forms and can enforce field-level validation, such as using g_form.setMandatory() to make a variable mandatory before submission. Option E is correct because Catalog Client Scripts can be associated with Variable Sets, allowing the same client-side logic to be reused across multiple catalog items that include that variable set. Option A is not correct because updating an sc_task state is a server-side record operation typically handled by Business Rules, Workflow, or Flow Designer, not by a catalog client script.

Option B is not correct because Catalog Client Scripts run on the catalog item form in both the standard platform UI and the Service Portal, not exclusively on the Service Portal. Option D is not correct because Catalog Client Scripts execute on the client side (browser), unlike Catalog Script Includes or Business Rules which run server-side.

Exam trap

CIS-ITSM often tests the misconception that Catalog Client Scripts run server-side or only on Service Portal, when they are actually client-side and run on both UIs.

Full explanation →
214
MCQmedium

A change practitioner wants to view all changes scheduled during a specific maintenance window in a calendar format. Which ServiceNow feature should they use?

A.ITOM Health Dashboard
B.Report Designer Bar Chart
C.Change Schedule / Change Calendar
D.CMDB Dependency View
AnswerC

The Change Calendar renders scheduled changes in a calendar view, letting the practitioner see everything falling inside a specific maintenance window. It draws directly on change schedule records, so no manual filtering or reporting workaround is needed to visualise that window.

Why this answer

The Change Schedule (also called Change Calendar) in ServiceNow provides a calendar view of planned changes, including maintenance windows. It allows change practitioners to visualize changes by date and time, filter by CI or group, and identify overlaps. This is the designated feature for viewing changes in a calendar format.

Exam trap

CIS-ITSM often tests the specific ServiceNow feature names and their purposes, and candidates may confuse the Change Calendar with reporting or monitoring tools.

How to eliminate wrong answers

Option A is wrong because ITOM Health Dashboard is for monitoring operational health and alerts, not for viewing change schedules. Option B is wrong because Report Designer Bar Chart is a reporting tool for creating charts, not a calendar view of changes. Option D is wrong because CMDB Dependency View shows relationships between CIs, not a calendar of changes.

Full explanation →
215
MCQmedium

A developer has created a Catalog Client Script that runs onchange of a variable named 'hardware_type'. The script needs to clear and repopulate a 'model' variable based on the selected hardware type using AJAX. Which client-side API method is best suited for making this asynchronous server call?

A.GlideRecordSecure
B.g_scratchpad
C.GlideAjax
D.g_form.getReference()
AnswerC

GlideAjax performs asynchronous client-to-server calls from a Catalog Client Script, invoking a Script Include to query the model records and return them without a page reload. This satisfies the requirement to clear and repopulate the 'model' variable onchange of 'hardware_type'.

Why this answer

GlideAjax is the client-side API method designed for making asynchronous server calls from a client script. It allows the client to call a server-side script include without a full page reload, which is ideal for dynamically repopulating a variable based on user input. This is the standard way to perform AJAX calls in ServiceNow.

Exam trap

CIS-ITSM often tests the difference between client-side and server-side APIs; candidates may choose g_form.getReference() thinking it's asynchronous, but it's synchronous and not suitable for AJAX.

How to eliminate wrong answers

Option A is wrong because GlideRecordSecure is a server-side API for database queries, not for client-side AJAX calls. Option B is wrong because g_scratchpad is used to pass data from the server to the client during form load, not for making asynchronous calls. Option D is wrong because g_form.getReference() is a client-side method that retrieves a reference field's record synchronously, which can cause performance issues and is not asynchronous.

Full explanation →
216
MCQmedium

An administrator is configuring a variable where users can select multiple options from a predefined list. Which variable type should be selected?

A.List Collector
B.Single Line Text
C.Select Box
D.Multiple Choice
AnswerA

A List Collector presents a predefined set of options and stores multiple selected values in a single variable, using slushbucket controls to move items between available and selected lists. A simple Choice variable permits only one selection, so it cannot satisfy the multiple-selection requirement.

Why this answer

A List Collector variable type in ServiceNow allows users to select multiple options from a predefined list, moving items between an available list and a selected list. It is specifically designed for multi-select scenarios and stores the selected values as a comma-separated list or in a related list depending on configuration. This makes it the correct choice for selecting multiple options.

Exam trap

CIS-ITSM often tests the difference between single-select and multi-select variable types, and candidates commonly confuse Multiple Choice with List Collector when multiple selections are required.

How to eliminate wrong answers

Option B is wrong because Single Line Text allows free-form text entry, not selection from a predefined list. Option C is wrong because a Select Box allows only a single selection from a dropdown list, not multiple selections. Option D is wrong because Multiple Choice presents radio buttons or a dropdown for a single selection, not multiple selections.

Full explanation →
217
MCQeasy

Which application menu contains the module for creating and managing Catalog Categories?

A.Service Catalog > Administration > Categories
B.System Definition > Catalog Categories
C.Request Management > Categories
D.Self-Service > Category Setup
AnswerA

Catalog Categories are maintained within the Service Catalog application, not the ITSM or platform menus. Navigating to Service Catalog > Administration > Categories exposes the category hierarchy used to organise catalogue items, which is where creation and management of those categories occurs.

Why this answer

In ServiceNow, Catalog Categories are managed from the Service Catalog application's Administration section. The correct path is Service Catalog > Administration > Categories, which opens the Category table where you can create, edit, and organize categories and subcategories for catalog items. This location is consistent with other catalog administration tasks like catalog management and item design.

Exam trap

CIS-ITSM often tests the exact navigation path for administrative tasks, and candidates may confuse the Service Catalog Administration menu with System Definition or Self-Service options.

How to eliminate wrong answers

Option B is wrong because System Definition contains platform-level configuration tables (like tables, dictionary, and UI properties), not catalog-specific categories. Option C is wrong because Request Management deals with request processes and workflows, not catalog category definitions. Option D is wrong because Self-Service is a user-facing portal for end users, not an administrative area for category setup.

Full explanation →
218
MCQeasy

An auditor wants to verify the physical existence and accuracy of datacenter hardware CIs by having owners attest to their records. Which application provides this attestation capability?

A.Asset Management Audit module
B.CI Class Manager attestation wizard
C.Data Certification
D.CMDB Health Dashboard compliance tab
AnswerC

Data Certification generates attestation tasks that route CI records to their owners for review and sign-off, directly satisfying the auditor's requirement to verify physical existence and accuracy. It is the only application purpose-built for scheduled certification of CMDB records.

Why this answer

The Data Certification application in ServiceNow provides the capability for owners to attest to the accuracy of their Configuration Items (CIs) and other records. It is designed for periodic certification campaigns where users verify that the data is correct. The other options do not provide this attestation functionality.

Exam trap

CIS-ITSM often tests the specific application for data attestation. Candidates might choose the CMDB Health Dashboard because it sounds related to compliance, but it only reports health, not attestation.

How to eliminate wrong answers

Option A is wrong because the Asset Management Audit module is not a standard application for attestation; it may refer to physical audits but not the certification process. Option B is wrong because CI Class Manager is used to manage CI class definitions, not to perform attestations. Option D is wrong because the CMDB Health Dashboard compliance tab shows compliance metrics but does not provide a mechanism for owners to attest to records.

Full explanation →
219
MCQhard

An administrator needs to evaluate the overall health of the CMDB, specifically measuring the percentage of CIs that have not been updated or verified within the last 90 days. Which CMDB Health metric addresses this?

A.Orphans (Correctness metric)
B.Audit (Completeness metric)
C.Staleness (Compliance metric)
D.Duplicate CIs (Correctness metric)
AnswerC

Staleness, a Compliance metric, calculates the percentage of CIs not updated or verified within a defined threshold, here 90 days. It directly satisfies the stem's requirement to measure outdated, unverified CIs, unlike Correctness or Completeness, which assess data accuracy and mandatory field population respectively.

Why this answer

Staleness is the correct CMDB Health metric because it measures the percentage of CIs that have not been updated or verified within a defined threshold (e.g., 90 days). It falls under the Compliance metric category in CMDB Health, which tracks whether CIs meet governance requirements like timely verification. Staleness specifically uses the 'last updated' or 'last verified' timestamp to flag aging CIs.

Exam trap

CIS-ITSM often tests the confusion between Staleness (Compliance) and Audit (Completeness) — candidates pick Audit because it sounds like 'checking' CIs, but staleness is specifically about time since last update/verification.

How to eliminate wrong answers

Option A is wrong because Orphans measures CIs with no relationships (a Correctness metric), not aging or verification status. Option B is wrong because Audit (Completeness) measures whether required attributes are populated, not how recently a CI was updated. Option D is wrong because Duplicate CIs (Correctness) measures CIs that appear to represent the same real-world entity, not stale records.

Full explanation →
220
MCQmedium

An administrator wants to ensure that a catalog item is only visible to users located in the 'United Kingdom' company. Which feature should be configured?

A.Catalog Client Script evaluating g_user.getClientData('company')
B.User Criteria with the Company condition set to United Kingdom
C.Order Guide Rule Base location filter
D.Location Access List on the sc_cat_item table
AnswerB

User Criteria restrict catalog item visibility by conditions such as company, department or location, so setting the Company condition to United Kingdom limits the item to those users. This is the mechanism that enforces the visibility requirement.

Why this answer

User Criteria is the correct feature to control catalog item visibility based on user attributes such as company, location, department, etc. By creating a User Criteria record with the Company condition set to 'United Kingdom' and associating it with the catalog item, only users in that company will see the item.

Exam trap

The trap is confusing client-side hiding (Catalog Client Scripts) with server-side visibility control (User Criteria); the exam expects knowledge that User Criteria is the correct, secure method for restricting item visibility.

How to eliminate wrong answers

Option A is wrong because Catalog Client Scripts run on the client side and can hide fields or sections, but they are not the proper mechanism for controlling item visibility based on user attributes; they can be bypassed and are not secure. Option C is wrong because Order Guide Rule Base location filter is used within order guides to conditionally include items, not to control visibility of a standalone catalog item. Option D is wrong because there is no 'Location Access List' on the sc_cat_item table; access control is managed via User Criteria and ACLs.

Full explanation →
221
MCQmedium

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

A.Use a UI Policy to make the field mandatory when State is Resolved.
B.Modify the Dictionary Entry.
C.Use an Access Control List (ACL).
D.Use an OnSubmit Client Script.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
222
MCQhard

An organization wants to configure Change Risk Assessment such that certain specific answers to questionnaire items instantly escalate the risk to 'High', regardless of other scores. How can this be achieved?

A.Writing a client script on the Change Request form
B.Creating a Data Policy on the Assessment Instance table
C.Editing the Risk Assessment UI Macro
D.Configuring Risk Assessment Conditions with specific Question/Answer thresholds
AnswerD

Risk Assessment Conditions let you define question-and-answer thresholds that force the risk rating to High when matched, overriding the calculated score. This satisfies the stem's requirement for specific answers to escalate risk instantly, regardless of other questionnaire scoring.

Why this answer

Risk Assessment Conditions allow you to define specific question/answer pairs that, when matched, instantly set the risk to 'High' regardless of other scores. This is configured in the Risk Assessment Conditions module, where you can specify thresholds and override rules based on questionnaire responses.

Exam trap

CIS-ITSM often tests the configuration of risk escalation. Candidates might think client scripts or data policies are needed, but the baseline feature is Risk Assessment Conditions with question/answer thresholds.

How to eliminate wrong answers

Option A is wrong because a client script on the Change Request form cannot directly manipulate risk assessment scoring logic; it would be a custom workaround. Option B is wrong because a Data Policy on the Assessment Instance table enforces data consistency, not risk escalation. Option C is wrong because editing the Risk Assessment UI Macro changes the visual interface, not the scoring logic.

Full explanation →
223
MCQhard

A company wants to implement a multi-stage approval for Problem records where the total estimated financial impact exceeds $10,000. Which ServiceNow feature should be used to orchestrate this conditional approval routing?

A.A Client Script validation check
B.An Email Notification template
C.A Dictionary Override on the Approval field
D.Flow Designer with Approval activities and conditional branching based on financial impact
AnswerD

Flow Designer's conditional branching evaluates the financial impact field and routes the record through multi-stage Approval activities only when the $10,000 threshold is exceeded, satisfying the conditional routing constraint that a static approval workflow cannot handle.

Why this answer

Flow Designer supports conditional branching and Approval activities, allowing a flow to evaluate the estimated financial impact and route through multi-stage approvals only when the amount exceeds $10,000. This is the platform's orchestration tool for conditional, multi-step approval routing on Problem records.

Exam trap

CIS-ITSM often tests the misconception that notifications or client scripts can drive approvals — candidates pick Email Notifications, missing that only Flow Designer (or legacy Workflow) creates and manages approval records with conditional branching.

How to eliminate wrong answers

Option A is wrong because a Client Script runs in the browser for form validation and cannot orchestrate server-side approval workflows or multi-stage routing. Option B is wrong because an Email Notification only sends a message; it does not create approval records or manage approval state transitions. Option C is wrong because a Dictionary Override changes field labels, defaults, or reference qualifiers — it has no approval orchestration capability.

Full explanation →
224
MCQmedium

An administrator is tasked with ensuring that Problem records cannot be deleted by anyone except users with the 'admin' role. Where should this security rule be configured?

A.A Before Delete Business Rule on the Task table
B.A delete Access Control List (ACL) on the Problem table
C.Problem Administration Properties
D.Dictionary Overrides for the sys_id field
AnswerB

A delete ACL on the Problem table restricts the delete operation to records matching the condition, so only users holding the admin role can remove them. Table-level ACLs apply before record access, enforcing the requirement centrally.

Why this answer

A delete ACL on the Problem table is the correct place to enforce that only users with the 'admin' role can delete problem records. ACLs in ServiceNow control record-level and field-level access for read, write, create, and delete operations, and a delete ACL specifically governs who can delete records. Configuring the ACL with a role condition of 'admin' ensures only admins can perform the delete operation.

Exam trap

CIS-ITSM often tests whether candidates know that ACLs are the correct mechanism for access control — candidates incorrectly pick Business Rules or UI Policies, which enforce logic or UI behavior but not security.

How to eliminate wrong answers

Option A is wrong because a Before Delete Business Rule on the Task table would affect all task types (incidents, changes, problems, etc.) and is not the proper security mechanism — Business Rules enforce logic, not access control, and should not be used for role-based deletion restrictions. Option C is wrong because Problem Administration Properties do not include a setting for restricting deletion by role — properties control behavior like state transitions or mandatory fields, not ACL-level security. Option D is wrong because Dictionary Overrides for the sys_id field control field-level behavior (like default values or attributes) and have no bearing on delete permissions.

Full explanation →
225
MCQeasy

Which module allows administrators to view and manage all submitted Service Catalog Requests across the organization?

A.Service Catalog > Catalog Items
B.Incident > Open
C.Service Catalog > Requests
D.Request Management > Active Cart
AnswerC

Service Catalog > Requests is the module listing every submitted catalog request organisation-wide, letting administrators track, approve or cancel them. It satisfies the requirement to view and manage all requests across the organisation, unlike category or item configuration views.

Why this answer

The Service Catalog > Requests module in ServiceNow lists all submitted catalog requests (sc_request records) across the organization, allowing administrators to view and manage them. This is the central place to track request states, approvals, and fulfillment. It is distinct from catalog item definitions and incident management.

Exam trap

CIS-ITSM often tests the confusion between catalog item definitions (Catalog Items) and submitted request records (Requests), causing candidates to pick the item management module instead of the request management module.

How to eliminate wrong answers

Option A is wrong because Service Catalog > Catalog Items is where item definitions are created and maintained, not where submitted requests are viewed. Option B is wrong because Incident > Open lists incidents, which are unrelated to catalog requests. Option D is wrong because 'Request Management > Active Cart' is not a standard ServiceNow module for viewing all submitted requests; carts are pre-submission and not a management view.

Full explanation →
Page 2

Page 3 of 5

Page 4

All pages

12345

Practice CIS-ITSM by domain

Target a specific domain to shore up weak areas.

Incident ManagementService Portfolio ManagementProblem ManagementChange ManagementCMDBService Catalog And Request Management
See all domains with question counts →