Scenario practice questions

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

Trap 1: Incident State

Incident state governs whether the SLA condition matches, but it is one condition among several and not the first checkpoint; the SLA definition's start, stop and pause conditions must be validated first. State matters when a correctly defined SLA fails to trigger at a specific transition.

Trap 2: System Dictionary

The System Dictionary stores field labels, choices and dependent relationships, not SLA definitions or start conditions, so it cannot explain why an SLA fails to attach. It is tempting because dictionary entries do underpin form behaviour, and editing them is the right fix when a field's choice list or dependency misbehaves.

Trap 3: User Preferences

User preferences affect notification and display settings, not SLA attachment logic, so they cannot prevent a matching SLA from attaching. Preferences would be relevant when a user reports missing alerts or a personalised view rather than a missing SLA record.

A
SLA Definition Conditions
SLA definitions carry start, stop, pause and reset conditions that determine whether a record qualifies for attachment. If these conditions reference fields the ticket does not populate, or exclude its values, no SLA binds. Verifying them first satisfies the stem's requirement to find why attachment fails before checking workflows or schedules.
B
Incident State
Why it fails: Incident state governs whether the SLA condition matches, but it is one condition among several and not the first checkpoint; the SLA definition's start, stop and pause conditions must be validated first. State matters when a correctly defined SLA fails to trigger at a specific transition.
C
System Dictionary
Why it fails: The System Dictionary stores field labels, choices and dependent relationships, not SLA definitions or start conditions, so it cannot explain why an SLA fails to attach. It is tempting because dictionary entries do underpin form behaviour, and editing them is the right fix when a field's choice list or dependency misbehaves.
D
User Preferences
Why it fails: User preferences affect notification and display settings, not SLA attachment logic, so they cannot prevent a matching SLA from attaching. Preferences would be relevant when a user reports missing alerts or a personalised view rather than a missing SLA record.

Question 2hardmultiple choice

An administrator is troubleshooting an Order Guide where Rule Base conditions evaluate to true, but the expected child catalog item is not being added to the cart. What is a valid troubleshooting step in this scenario?

Trap 1: Check the 'No cart' attribute on the order guide record itself.

The 'No cart' attribute controls whether an order guide bypasses the cart and submits directly; it does not prevent Rule Base child items from being inserted. It would be the right setting to inspect when an order guide should skip cart review entirely.

Trap 2: Rewrite the rule base conditions using legacy javascript eval()…

Legacy eval() statements are not required for Rule Base conditions, which already evaluate server-side; rewriting them introduces deprecated scripting without addressing why the child item is skipped. Legacy eval() would matter only when migrating very old custom condition scripts that still depend on it.

Trap 3: Disable cascading variables on all child catalog items.

Cascading variables control how variable values propagate between catalog items; they do not govern whether a Rule Base adds a child item to the cart, so disabling them changes nothing here. Cascading variables would be relevant when child item variables must inherit or filter values from parent items.

A
Check the 'No cart' attribute on the order guide record itself.
Why it fails: The 'No cart' attribute controls whether an order guide bypasses the cart and submits directly; it does not prevent Rule Base child items from being inserted. It would be the right setting to inspect when an order guide should skip cart review entirely.
B
Verify that the child catalog item is active and that the submitting user satisfies the child item's User Criteria.
Rule Base conditions can evaluate true while the child item is still excluded, because inactive items or unmet User Criteria prevent addition. Confirming the child catalog item's active status and the submitting user's User Criteria eligibility isolates that cause.
C
Rewrite the rule base conditions using legacy javascript eval() statements.
Why it fails: Legacy eval() statements are not required for Rule Base conditions, which already evaluate server-side; rewriting them introduces deprecated scripting without addressing why the child item is skipped. Legacy eval() would matter only when migrating very old custom condition scripts that still depend on it.
D
Disable cascading variables on all child catalog items.
Why it fails: Cascading variables control how variable values propagate between catalog items; they do not govern whether a Rule Base adds a child item to the cart, so disabling them changes nothing here. Cascading variables would be relevant when child item variables must inherit or filter values from parent items.

Question 3mediummultiple choice

A catalog item has a variable named 'software_version' that needs to be populated dynamically using a script. Which type of variable allows options to be populated dynamically via a lookup or script?

Trap 1: Checkbox

Checkbox captures a boolean yes/no state, so it cannot hold a script-populated list of software versions. It is tempting as a simple selection control, and it would be correct for a flag such as 'include beta builds', not for choosing one value from a dynamic lookup.

Trap 2: Multi-Line Text

Multi-Line Text stores free-form prose, so it cannot present a script-populated list of selectable values; the platform offers no lookup binding for it. It is tempting because it accommodates long descriptions, and it would suit capturing verbose release notes or change justifications, not a controlled software_version choice.

Trap 3: Single Line Text

Single Line Text accepts typed free text, so no lookup or script can populate selectable options, and users could enter invalid versions. It is tempting because it is the default field, and it would suit a free-form reference like a ticket number, not a controlled version list.

A
Lookup Select Box
Lookup Select Box variables pull their option list from a referenced table via a lookup configuration, or from a script, rather than storing static choices. This satisfies the stem's requirement that software_version be populated dynamically at runtime.
B
Checkbox
Why it fails: Checkbox captures a boolean yes/no state, so it cannot hold a script-populated list of software versions. It is tempting as a simple selection control, and it would be correct for a flag such as 'include beta builds', not for choosing one value from a dynamic lookup.
C
Multi-Line Text
Why it fails: Multi-Line Text stores free-form prose, so it cannot present a script-populated list of selectable values; the platform offers no lookup binding for it. It is tempting because it accommodates long descriptions, and it would suit capturing verbose release notes or change justifications, not a controlled software_version choice.
D
Single Line Text
Why it fails: Single Line Text accepts typed free text, so no lookup or script can populate selectable options, and users could enter invalid versions. It is tempting because it is the default field, and it would suit a free-form reference like a ticket number, not a controlled version list.

Question 4mediummulti select

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

Trap 1: They execute on the server side prior to database insertion.

Catalog UI Policies run client-side in the browser to control form field behaviour; server-side execution before database insertion is handled by business rules or data policies. It is tempting because server-side enforcement genuinely exists in ServiceNow, so it would be correct for validating records before insert.

Trap 2: They only function on legacy UI16 forms and are unsupported in…

Catalog UI Policies function on both UI16 forms and Service Portal, so restricting them to legacy UI16 is false. It is tempting because some legacy client-side scripting behaves differently across portals, so the claim would be correct only for technologies genuinely tied to the classic interface.

Trap 3: They replace the need for Catalog Client Scripts in all scenarios,…

Catalog UI Policies only manipulate form field visibility, mandatory and read-only states client-side; they cannot perform asynchronous database lookups, which require Catalog Client Scripts or GlideAjax. It is tempting because UI Policies do handle many field-behaviour requirements, so they would be correct where no server query is needed.

A
They execute on the server side prior to database insertion.
Why it fails: Catalog UI Policies run client-side in the browser to control form field behaviour; server-side execution before database insertion is handled by business rules or data policies. It is tempting because server-side enforcement genuinely exists in ServiceNow, so it would be correct for validating records before insert.
B
They can be applied to both Catalog Items and Record Producers.
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.
C
They can execute client-side logic without requiring JavaScript when using declarative UI policy actions.
Declarative UI policy actions let administrators define field visibility, mandatory, or read-only behaviour through configuration rather than writing client scripts. This satisfies the stem's statement about executing client-side logic without JavaScript, applying immediately in the browser.
D
They only function on legacy UI16 forms and are unsupported in Service Portal.
Why it fails: Catalog UI Policies function on both UI16 forms and Service Portal, so restricting them to legacy UI16 is false. It is tempting because some legacy client-side scripting behaves differently across portals, so the claim would be correct only for technologies genuinely tied to the classic interface.
E
They replace the need for Catalog Client Scripts in all scenarios, including asynchronous database lookups.
Why it fails: Catalog UI Policies only manipulate form field visibility, mandatory and read-only states client-side; they cannot perform asynchronous database lookups, which require Catalog Client Scripts or GlideAjax. It is tempting because UI Policies do handle many field-behaviour requirements, so they would be correct where no server query is needed.

Question 5mediummultiple choice

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

Trap 1: Single Line Text

Single Line Text stores one free-form string, so it cannot constrain input to a predefined list nor capture multiple selections. It is tempting because it suits open-ended data such as a short description or justification, where users type any value and no fixed option set applies.

Trap 2: Select Box

A Select Box renders a dropdown permitting only one selection, so it cannot capture multiple answers from a predefined list. It is tempting because it suits single-select lists, where a compact dropdown is the correct variable type.

Trap 3: Multiple Choice

Multiple Choice permits only one selection from a predefined list, so it cannot capture the several values the scenario requires. It is tempting because it does present a predefined list of options, which suits single-answer questions such as choosing a priority or a single affected department.

A
List Collector
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.
B
Single Line Text
Why it fails: Single Line Text stores one free-form string, so it cannot constrain input to a predefined list nor capture multiple selections. It is tempting because it suits open-ended data such as a short description or justification, where users type any value and no fixed option set applies.
C
Select Box
Why it fails: A Select Box renders a dropdown permitting only one selection, so it cannot capture multiple answers from a predefined list. It is tempting because it suits single-select lists, where a compact dropdown is the correct variable type.
D
Multiple Choice
Why it fails: Multiple Choice permits only one selection from a predefined list, so it cannot capture the several values the scenario requires. It is tempting because it does present a predefined list of options, which suits single-answer questions such as choosing a priority or a single affected department.