Knowledge + Practice

CCNA Core Application Development Questions

72 questions · Core Application Development · All types, answers revealed

Practice these questions Domain overview All questions

1

MCQmedium

The ACL above is on the 'incident' table. A user with role 'itil' tries to update an incident record. What will happen?

A.The user will be prompted for credentials.

B.The user will be allowed because the condition is ignored for write operations.

C.The user will be allowed because the script sets answer = true.

D.The user will be denied because the condition fails.

AnswerD

The condition requires incident_manager role, which the user does not have.

Why this answer

The ACL (Access Control Rule) on the 'incident' table has a condition that must evaluate to true for the user to be granted access. In this case, the condition fails for a user with role 'itil' attempting to update the record, so the script does not set answer = true, resulting in a denial of the operation. Option D is correct because the condition failing means the ACL denies the write operation.

Exam trap

The trap here is that candidates often assume that having a role like 'itil' automatically grants update access, but ACLs require both the role and the condition to be satisfied, and a failing condition overrides the role-based permission.

How to eliminate wrong answers

Option A is wrong because ACLs do not prompt for credentials; they either allow or deny access based on conditions and roles, and credential prompts are handled by authentication mechanisms, not ACLs. Option B is wrong because conditions are not ignored for write operations; ACLs evaluate conditions for all operations (read, write, create, delete) unless specifically configured otherwise. Option C is wrong because the script only sets answer = true if the condition passes; since the condition fails, the script does not execute the line that sets answer = true, so the user is denied.

Practice this question →

2

Multi-Selecthard

Which TWO of the following are valid ways to retrieve a single record from a GlideRecord query on the task table?

Select 2 answers

A.gr.next()

B.gr.getRow()

C.gr.getUniqueValue()

D.gr.get()

E.gr.getByID()

AnswersA, D

Correct: Used to iterate through results; when called once, it retrieves the first record.

Why this answer

Option A is correct because `gr.next()` is the standard method to advance the cursor to the next record in a GlideRecord query result set. When called after a `query()`, it retrieves the first record (or subsequent records) and returns true if a record exists, making it a valid way to access a single record. Option D is correct because `gr.get(sys_id)` retrieves a single record by its sys_id directly, without needing a prior query, and returns true if the record is found.

Exam trap

The trap here is that candidates often confuse `getUniqueValue()` with retrieving the record itself, or mistakenly think `getByID()` is a valid method because of its similarity to `get()` or `getByID()` in other platforms, while ServiceNow strictly uses `get(sys_id)`.

Practice this question →

3

MCQmedium

A company has a Business Rule that runs after a record is updated. The rule needs to update a related record on a different table. However, the related record update is not being saved. What is the most likely cause?

A.There is a script error that is being ignored because the Business Rule is set to 'true' for 'Run asynchronously'.

B.The script is missing the .update() method on the GlideRecord object after setting field values.

C.The Business Rule runs in a separate transaction and the update is rolled back.

D.The user running the script does not have write access to the related table.

AnswerB

Without calling update(), the changes are not persisted to the database.

Why this answer

Option B is correct because in ServiceNow, when a Business Rule modifies a GlideRecord object (e.g., setting field values on a related record), the changes are not persisted to the database until the `.update()` method is explicitly called. Without `.update()`, the script runs without error but the modifications are lost, which is the most common cause of an update not being saved.

Exam trap

ServiceNow often tests the misconception that setting field values on a GlideRecord object automatically saves the record, when in fact the `.update()` method is mandatory to persist changes.

How to eliminate wrong answers

Option A is wrong because setting 'Run asynchronously' to true does not cause script errors to be ignored; asynchronous execution still logs errors, and a script error would typically prevent the update from occurring at all, not silently discard it. Option C is wrong because Business Rules run in the same transaction as the triggering record update by default; they are not separate transactions, so there is no rollback unless explicitly coded. Option D is wrong because while insufficient write access can prevent an update, the question states the update is 'not being saved' rather than failing with an error, and the most likely cause in a typical development scenario is a missing `.update()` call, not a permissions issue.

Practice this question →

4

MCQmedium

A developer is configuring an approval flow for a catalog item. When a user submits a request, an approval record is created with a single approver. The approver must be the user's manager. Which is the correct way to set the approver?

A.In the catalog item, set 'Approval type' to 'Single' and select a specific user

B.In the catalog item, write an 'Approval script' that sets the approver to the submitted by user's manager using current.approver = current.caller_id.manager

C.Use an Approval - User rule with condition that the approver is the manager

D.In the catalog item, set 'Approval type' to 'Group' and select the manager's group

AnswerB

Correct; catalog items allow a script in the Approval tab to dynamically set the approver.

Why this answer

Option B is correct because it uses an approval script to dynamically set the approver to the manager of the request's caller. The script `current.approver = current.caller_id.manager` directly assigns the manager field from the user record of the caller, which is the standard way to implement a manager-based approval in ServiceNow. This approach is flexible and avoids hardcoding a specific user or group.

Exam trap

ServiceNow often tests the distinction between static assignment (Option A) and dynamic scripting (Option B), where candidates mistakenly think a simple 'Single' approval type can be configured to use the manager by selecting a field, but ServiceNow requires a script for dynamic resolution.

How to eliminate wrong answers

Option A is wrong because setting 'Approval type' to 'Single' and selecting a specific user would always assign that same user as the approver, regardless of who submits the request, which does not meet the requirement of using the submitter's manager. Option C is wrong because an 'Approval - User' rule defines conditions for when a user can be an approver, but it does not set the approver for a specific catalog item request; it is used for record-level approval rules, not for dynamically assigning the approver based on the caller's manager. Option D is wrong because setting 'Approval type' to 'Group' and selecting the manager's group would send the approval to the entire group, not to the individual manager, and it does not guarantee that the specific manager of the submitter is the one who approves.

Practice this question →

5

MCQeasy

A developer needs to create a UI Policy that hides a field when a checkbox is checked. The UI Policy has a condition: 'State is 2'. The field should be hidden when the checkbox is checked and state is 2. What is the correct approach?

A.Set condition to 'state=2' and add a script action that sets the field's visible attribute based on the checkbox value

B.Add both conditions in the condition builder: checkbox=true AND state=2

C.Set condition to 'state=2' and add a reverse if false action with a condition on the checkbox

D.Use a Client Script instead of UI Policy

AnswerA

Correct; the condition runs on server, and the script runs client-side to react to checkbox changes.

Why this answer

UI Policies have both a condition and actions. The script action can evaluate additional conditions. The best practice is to set the condition to the primary filter (state=2) and add a script action to set the field's visibility based on the checkbox.

Option B describes that correctly.

Practice this question →

6

Multi-Selectmedium

Which TWO of the following are valid ways to create a Business Rule? (Choose two.)

Select 2 answers

A.From the Business Rules list, right-click and select 'New'.

B.Navigate to 'System Definition > Business Rules' and click 'New'.

C.Use the 'New' button on the Business Rules module.

D.Type 'business_rule.do' in the navigator filter.

E.Create a Client Script and convert it to a Business Rule.

AnswersB, C

This is the standard way.

Why this answer

Option B is correct because navigating to 'System Definition > Business Rules' and clicking 'New' is the standard module-based method for creating a Business Rule in ServiceNow. This path directly accesses the Business Rule table (sys_script) and opens a new record form, which is a valid and documented approach.

Exam trap

ServiceNow often tests the distinction between valid navigation paths and invalid shortcuts, such as assuming a right-click menu or a direct URL suffix works, when in fact only the module link or the 'New' button on the list view are correct.

Practice this question →

7

MCQmedium

A developer has created a Business Rule that runs on the 'After' order of the incident table. The Business Rule modifies several fields on the incident record. After testing, the developer notices that the changes are not being saved to the database. What is the most likely cause?

A.The Business Rule is disabled for the current user's role.

B.The Business Rule does not include a call to current.update() after making field changes.

C.The fields being modified are read-only due to a data policy.

D.The Business Rule is set to run on 'Before' instead of 'After'.

AnswerB

Correct: After Business Rules require explicit current.update() to save changes.

Why this answer

In ServiceNow, a Business Rule set to run 'After' the database operation does not automatically save field changes to the database. The developer must explicitly call `current.update()` to persist the modifications. Without this call, the changes exist only in memory during the script execution and are discarded after the rule completes.

Exam trap

The trap here is that candidates often assume any field changes in a Business Rule are automatically saved, failing to distinguish between 'Before' (auto-save) and 'After' (requires explicit `current.update()`) execution order.

How to eliminate wrong answers

Option A is wrong because if the Business Rule were disabled for the current user's role, it would not execute at all, but the developer observed that the rule runs (changes are made but not saved). Option C is wrong because a data policy making fields read-only would prevent the user from modifying them in the UI, but the Business Rule runs server-side and can still set field values regardless of data policies; the issue is specifically about persistence. Option D is wrong because a 'Before' Business Rule automatically saves changes to the database without requiring `current.update()`, so the described symptom (changes not saved) would not occur if the rule were on 'Before'.

Practice this question →

8

MCQmedium

The business rule above does not set the urgency on new incidents created via web service when the caller's department is IT. What is the most likely reason?

A.The condition uses current.urgency == '' but the field may have a default value of 3

B.The table is not 'Incident' but 'Incident Task'

C.The business rule is set to 'before' but web service calls trigger after rules

D.The gs.log statement is preventing the script from completing

AnswerA

Correct; default values are applied before the business rule runs, so urgency is not empty.

Why this answer

Option A is correct because the business rule condition checks if `current.urgency` is an empty string, but the Incident table has a default value of 3 for the urgency field. When a new record is created via web service, the system populates the urgency field with the default value before the business rule runs, so the condition `current.urgency == ''` evaluates to false, and the script never executes to set the urgency.

Exam trap

The trap here is that candidates assume a field will be empty on new record creation, forgetting that dictionary defaults are applied before business rules execute, causing the condition to fail silently.

How to eliminate wrong answers

Option B is wrong because the question explicitly states the rule is for new incidents, and the business rule would be scoped to the Incident table; if the table were 'Incident Task', the rule would not fire at all for incidents, but the issue is about the condition failing, not the table. Option C is wrong because web service calls trigger both 'before' and 'after' business rules; the 'before' rule runs before the record is saved, so timing is not the issue. Option D is wrong because a `gs.log` statement does not prevent script completion; it only writes a log message and does not stop execution.

Practice this question →

9

MCQhard

The ACL is meant to allow users to read an incident only if they are the manager of the assigned user. However, users who are not managers can also read the incident. What is the flaw?

A.The operation should be 'write' not 'read'

B.The table should be 'sys_user'

C.The condition in the ACL condition field should be removed and replaced with the script

D.The script should include an else statement that sets answer = false

AnswerD

Correct; the script currently always sets answer = true, so it grants access unconditionally.

Why this answer

Option D is correct because when an ACL condition script runs, it must explicitly set the answer variable to true or false. If the script lacks an else statement that sets answer = false, the script returns undefined (or the last evaluated expression) for non-matching conditions, which ServiceNow treats as true, inadvertently granting read access to unauthorized users. Adding an else statement that sets answer = false ensures that only users who satisfy the manager condition are granted read access.

Exam trap

The trap here is that candidates assume a script that returns true for the intended condition automatically denies access for others, but ServiceNow requires an explicit else statement to set answer = false; otherwise, the script's return value is undefined, which is often treated as true.

How to eliminate wrong answers

Option A is wrong because the operation 'read' is correct for controlling who can view an incident; changing it to 'write' would control update access, not read access, and would not fix the flaw. Option B is wrong because the table 'incident' is the correct table for incident records; changing the table to 'sys_user' would apply the ACL to user records, not incidents, which is irrelevant to the requirement. Option C is wrong because the condition in the ACL condition field is not inherently flawed; the issue is that the script does not explicitly return false for non-managers, and removing the condition would not address the missing else statement.

Practice this question →

10

Multi-Selecthard

Which TWO statements about update sets are correct? (Choose two.)

Select 2 answers

A.Update sets capture changes to ACLs, but each condition script is captured as a separate record.

B.Update sets must be explicitly exported and then imported into the target instance.

C.Update sets capture all changes made to an instance, including out-of-box records.

D.Update sets can contain changes to system properties.

E.Update sets are used to move data, such as user records, between instances.

AnswersB, D

Retrieved or exported from the source instance and committed in the target.

Why this answer

The correct options are B and D. Update sets track changes to application configurations. Option B is correct: update sets are not automatically exported; manual action is required.

Option D is correct: update sets can include changes from multiple tables, including system properties. Option A is incorrect: update sets are intended for migrating customizations, not all out-of-box records. Option C is incorrect: update sets do not capture individual ACL condition scripts in a transactional way; they capture the full ACL record.

Option E is incorrect: update sets move changes to target instances; they do not move data.

Practice this question →

11

MCQeasy

A service catalog item has a variable set that includes a reference field to the 'cmdb_ci' table. The requirement is to show only 'Server' type CI's in the reference field. Which approach should be used?

A.Create a UI Policy that sets the field as read-only and uses a condition to filter.

B.Set a Reference Qualifier on the variable definition that uses the condition 'sys_class_name=Server'.

C.Write a Client Script on load that sets the reference qualifier using setRefQual().

D.Use a Data Policy to enforce a condition on the field.

AnswerB

Reference Qualifiers directly filter the records shown in the lookup.

Why this answer

Option B is correct because a Reference Qualifier on a variable definition allows you to filter the records displayed in a reference field using a condition string. By setting the condition 'sys_class_name=Server', only CI records with that specific sys_class_name will appear, which directly meets the requirement to show only 'Server' type CIs.

Exam trap

The trap here is that candidates may confuse UI Policies or Data Policies with reference qualifiers, thinking they can filter reference field data, when in fact only a Reference Qualifier (or a derived condition) directly controls which records are available for selection.

How to eliminate wrong answers

Option A is wrong because a UI Policy can set a field as read-only or visible, but it cannot filter the records shown in a reference field; it only controls UI behavior, not the underlying data query. Option C is wrong because while a Client Script can use setRefQual() to dynamically set a reference qualifier, this approach is typically used for client-side filtering and is less efficient and reliable than a server-side Reference Qualifier; the question asks for the approach that should be used, and the standard, best-practice method is a Reference Qualifier on the variable definition. Option D is wrong because a Data Policy enforces data integrity rules (such as mandatory or read-only conditions) on a field, but it does not filter the list of records available in a reference field.

Practice this question →

12

MCQhard

A developer notices that a scheduled job runs but does not execute the script. The job is set to run every hour. The script uses the 'gs.log' function to write messages. The log shows no output. What is the most likely cause?

A.The job's condition script has a syntax error.

B.The 'sys_updated_on' field is not being updated.

C.The job is set to 'Inactive'.

D.The job condition is set to 'false' so it never triggers.

AnswerC

Inactive jobs do not run at all.

Why this answer

Option C is correct because if a scheduled job is set to 'Inactive', it will still appear in the scheduled jobs list and may be considered 'running' in the sense that the system processes it, but the associated script will not execute. The 'gs.log' function would produce no output because the script never runs. This is a common oversight when a developer creates or clones a job but forgets to activate it.

Exam trap

The trap here is that candidates often assume a scheduled job that 'runs' must be active, but ServiceNow distinguishes between the job being processed by the scheduler and the script actually executing, so an inactive job will show as 'run' in the job history but produce no script output.

How to eliminate wrong answers

Option A is wrong because a syntax error in the condition script would typically cause the job to fail with an error message in the system log, not silently produce no output. Option B is wrong because the 'sys_updated_on' field is automatically updated by the platform when a record is modified; it is not related to script execution or log output. Option D is wrong because if the job condition is set to 'false', the job would not trigger at all, but the developer notes the job 'runs' — meaning it is triggered — so the condition being false would prevent triggering, not cause silent failure.

Practice this question →

13

MCQmedium

An application scope includes a Business Rule that runs on the 'before' operation of the Incident table. It attempts to set the 'assignment_group' based on the caller's company. However, the assignment is not being applied. Which is the most likely cause?

A.The Business Rule is set to 'async' which delays execution

B.The script uses 'current.assignment_group = something' without calling setValue

C.The Business Rule is set to run on 'display' instead of 'update'

D.The field 'assignment_group' is not in the current scope's accessible table columns due to cross-scope privilege

AnswerD

Correct; if the Business Rule is in a scoped application and the Incident table belongs to the global scope, the scoped app may not have write access to the field unless an access grant is defined.

Why this answer

Option D is correct because in ServiceNow, cross-scope privilege restrictions prevent a scoped application from accessing or modifying columns in the Incident table that are not explicitly granted via the application's scope. Even though the Business Rule runs on the 'before' operation, if the 'assignment_group' field is not in the application's accessible table columns, the assignment will silently fail. This is a common issue when a scoped application attempts to interact with global table fields without proper cross-scope access.

Exam trap

The trap here is that candidates often assume the issue is a scripting syntax error (like Option B) or a timing problem (like Option A), but ServiceNow's cross-scope security model silently blocks field writes without explicit privilege, making it the most likely cause when a scoped application's Business Rule fails to update a global field.

How to eliminate wrong answers

Option A is wrong because setting a Business Rule to 'async' delays execution to a background queue, but it does not prevent the assignment from being applied; the assignment would still occur asynchronously. Option B is wrong because using 'current.assignment_group = something' is a valid way to set a field value in a 'before' Business Rule, as it directly modifies the current record in memory without needing setValue. Option C is wrong because a Business Rule set to run on 'display' only triggers when the record is viewed, not on update, so it would not affect the assignment during an update operation; however, the question states the rule runs on 'before' operation, so this is not the issue.

Practice this question →

14

Multi-Selectmedium

Which THREE of the following are attributes of a Service Portal widget? (Choose three.)

Select 3 answers

A.Server Script

B.Client Controller

C.CSS Styling

D.Business Rule

E.HTML Template

AnswersA, B, E

Server Script runs server-side to provide data to the widget.

Why this answer

Server Script is a core attribute of a Service Portal widget because it runs on the server side when the widget is loaded or when a client-initiated action triggers a server call via the 'server.get' or 'server.update' options. It allows developers to query the database, perform business logic, and return data to the client controller, making it essential for data retrieval and processing within the widget lifecycle.

Exam trap

ServiceNow often tests the distinction between widget-specific attributes (Server Script, Client Controller, HTML Template) and platform-wide features like Business Rules or CSS Styling, leading candidates to mistakenly include CSS or Business Rules because they are common in other ServiceNow development contexts.

Practice this question →

15

MCQeasy

The exhibit shows a business rule script snippet. The business rule is triggered on 'before update' of incident table. When an incident's state is changed to 2 (Resolved), the short_description is set to 'Resolved'. However, the short_description is also being set to 'Resolved' when the state is already 2 and other fields are updated. Which change to the script would fix this issue?

A.Change the trigger order from 'before' to 'after'.

B.Change 'current.state == 2' to 'current.state.changesTo(2)'.

C.Remove the condition and let the script run always.

D.Change 'current.state == 2' to 'current.state.changes() && current.state == 2'.

AnswerB, D

changesTo() detects a change to a specific value.

Why this answer

Option B is correct because `current.state.changesTo(2)` is a GlideRecord method that returns true only when the `state` field is being changed *to* the value 2 during the current update. This ensures the short_description is set to 'Resolved' only when the state transitions to 2, not when other fields are updated while the state is already 2. The original script used `current.state == 2`, which evaluates to true whenever the state is 2, regardless of whether it just changed.

Exam trap

The trap here is that candidates often confuse `current.state == 2` (a static value check) with `current.state.changesTo(2)` (a transition check), leading them to pick Option D because they think `changes()` combined with `==` is equivalent, but it fails when the field is updated to the same value.

How to eliminate wrong answers

Option A is wrong because changing the trigger order from 'before' to 'after' does not address the condition logic; it would still evaluate `current.state == 2` and set the short_description on every update where state is 2. Option C is wrong because removing the condition would cause the short_description to be set to 'Resolved' on every update of the incident, regardless of state value, which is not the desired behavior. Option D is wrong because `current.state.changes()` returns true if the state field has changed to any value, and combined with `current.state == 2`, it would still set the short_description when state changes from 2 to 2 (if the field is touched), which does not fix the issue; only `changesTo(2)` correctly isolates the transition to value 2.

Practice this question →

16

MCQeasy

A developer needs to display a warning message to the user when a specific field value changes on a form, but the record should still be savable. Which approach should be used?

A.Create a UI Policy with a condition and a UI message.

B.Create a Business Rule that uses gs.addErrorMessage().

C.Create an 'onChange' Client Script using g_form.addErrorMessage() or g_form.showFieldMsg().

D.Create a Data Policy for the field and set a warning message.

AnswerC

Client Script 'onChange' can display a message client-side without preventing save.

Why this answer

Option C is correct because an 'onChange' Client Script runs on the client side when a specific field value changes, allowing the developer to display a warning message using g_form.addErrorMessage() or g_form.showFieldMsg() without preventing the record from being saved. This approach ensures the user sees the warning interactively while still being able to submit the form, which matches the requirement exactly.

Exam trap

The trap here is that candidates confuse client-side warnings with server-side blocking mechanisms, often choosing a Business Rule (Option B) because they think gs.addErrorMessage() can display a warning before save, but it actually runs after the record is committed, making it unsuitable for real-time field change notifications.

How to eliminate wrong answers

Option A is wrong because UI Policies are used to make fields mandatory, read-only, or visible based on conditions, and they do not support displaying warning messages without blocking save; they can show UI messages but those are typically informational and not tied to field value changes in a client-side interactive manner. Option B is wrong because Business Rules run server-side after the record is saved, so gs.addErrorMessage() would display the warning only after submission, not when the field value changes on the form, and it could also prevent saving if used with an abort action. Option D is wrong because Data Policies enforce field-level constraints (e.g., mandatory, read-only) on the server side and cannot display warning messages; they are designed to enforce rules, not to show user notifications.

Practice this question →

17

MCQhard

A developer implements the above Business Rule on the 'incident' table. What is the effect of this script?

A.Deletes the record if the state is closed

B.Prevents the state from ever being set to closed

C.Aborts the update if the record is already in closed state

D.Sets the state to closed for all records

AnswerC

The condition checks if state equals 'closed', and if so, setAbortAction(true) prevents the database operation.

Why this answer

The Business Rule uses 'current.operation() == 'update'' and checks if the state is 'closed' before the update. If the record is already closed, it calls 'gs.addErrorMessage()' and returns false, which aborts the update. This prevents any changes to a closed record, not just preventing the state from being set to closed.

Exam trap

The trap here is that candidates may misinterpret the condition as preventing the state from being set to closed, when in fact it only blocks updates to records that are already closed, not the transition to closed itself.

How to eliminate wrong answers

Option A is wrong because the script does not delete the record; it aborts the update and shows an error message, with no delete operation. Option B is wrong because the script does not prevent the state from being set to closed; it only prevents updates to records that are already in the closed state. Option D is wrong because the script does not set the state to closed; it only checks the current state and aborts the update if it is closed.

Practice this question →

18

MCQhard

A developer is debugging an issue where a Script Action in a Flow Designer flow is not triggering. The flow is configured to run when a record is created or updated in the incident table. The Script Action is supposed to set a field based on a condition, but it never executes. What should the developer check first?

A.Check if the flow is published.

B.Check if the script include used in the Script Action is accessible.

C.Check if the Script Action script has syntax errors.

D.Check the flow's trigger conditions to ensure they match the record update.

AnswerD

The most common issue is that the trigger conditions are not met for the specific record.

Why this answer

Option D is correct because the most common reason a Script Action fails to trigger is that the flow's trigger conditions do not match the record update event. Flow Designer evaluates trigger conditions before any actions execute; if the conditions are misconfigured (e.g., expecting a specific field change that isn't occurring), the entire flow, including the Script Action, will not run. The developer should first verify that the trigger conditions align with the actual record creation or update scenario.

Exam trap

The trap here is that candidates often jump to debugging the Script Action itself (syntax, access) without first verifying the fundamental trigger conditions, which is the first logical step in troubleshooting a flow that never starts.

How to eliminate wrong answers

Option A is wrong because a flow must be published to run, but if it were unpublished, the flow would not trigger at all, not just the Script Action; the question states the flow is configured to run, implying it is published. Option B is wrong because an inaccessible Script Include would cause a runtime error in the Script Action, not prevent the Script Action from triggering; the flow would still execute and fail at the script. Option C is wrong because syntax errors in the Script Action script would also cause a runtime error during execution, not prevent the Script Action from being triggered; the flow would still start and reach the action step.

Practice this question →

19

Multi-Selecteasy

Which TWO are valid ways to create a new application scope in ServiceNow? (Choose two.)

Select 2 answers

A.Install an update set from an application repository that contains an application scope.

B.Use the 'Create Application' module under System Applications.

C.Use the 'Application Creator' UI page to define a new scope via REST API.

D.Import a v1 update set that includes an application definition.

E.Navigate to 'All' > 'Scopes' and click 'New'.

AnswersA, B

Installing an update set with an application scope creates that scope.

Why this answer

Option A is correct because installing an update set from an application repository that contains an application scope is a standard method to bring a scoped application into an instance. The update set carries the application definition and its scope, and upon commit, ServiceNow creates the application scope automatically if it does not already exist. This is a common approach for distributing scoped applications across instances.

Exam trap

The trap here is that candidates often confuse the 'Create Application' module (which is the correct UI path) with the non-existent 'Scopes' menu or the misleading 'Application Creator' UI page, leading them to select options that describe invalid or legacy methods.

Practice this question →

20

MCQhard

A senior developer is troubleshooting a performance issue in a Production instance. The instance has a large number of Business Rules that run on the incident table. One particular Business Rule, 'Update CI Impact', runs on the 'After Update' order and performs a GlideRecord query on the cmdb_ci table based on the incident's configuration item (ci) field. The query uses a filter to find all CIs related to the same location as the incident. Recently, users have reported that saving an incident takes over 30 seconds. The developer suspects this Business Rule is the cause. The developer examines the script and finds it uses a synchronous GlideRecord query with no scoping on the query. The developer wants to minimize impact on performance without removing the functionality. Which approach should the developer take?

A.Change the Business Rule to run asynchronously using the 'Async' checkbox in the Business Rule form.

B.Add an index on the cmdb_ci table for the location field and use an efficient query.

C.Move the logic to a scheduled job that runs every hour instead of on every update.

D.Convert the GlideRecord query to use GlideRecordSecure to limit access.

AnswerA

Correct: Async execution prevents blocking the user transaction.

Why this answer

Option A is correct because enabling the 'Async' checkbox on the Business Rule moves the execution to the background job scheduler, allowing the incident save transaction to complete immediately without waiting for the GlideRecord query to finish. This eliminates the synchronous delay that causes the 30-second save time, while preserving the functionality of updating CI impact.

Exam trap

The trap here is that candidates often assume performance issues are always solved by optimizing the query (indexing) rather than recognizing that moving the execution out of the synchronous transaction path is the correct architectural fix for blocking delays.

How to eliminate wrong answers

Option B is wrong because adding an index on the location field in cmdb_ci table improves query performance but does not address the fundamental issue of a synchronous GlideRecord query blocking the transaction; the query still runs synchronously and can cause delays if the dataset is large or the query is complex. Option C is wrong because moving the logic to a scheduled job that runs every hour removes the real-time functionality of updating CI impact immediately upon incident updates, which may not meet business requirements and is not a minimal-impact change. Option D is wrong because converting to GlideRecordSecure does not affect performance; it only enforces ACL-based security on the query, which does not reduce execution time or remove synchronous blocking.

Practice this question →

21

MCQmedium

A developer is building a Flow in Flow Designer that needs to update an incident record when a certain event occurs. The flow uses a 'Update Record' action. However, the incident record is not being updated even though the flow runs without errors. What could be the issue?

A.The flow trigger is set to 'On Created' but the incident already existed

B.The flow is using a 'Lookup Record' instead of 'Update Record'

C.The flow's application scope does not have write access to the Incident table

D.The 'Update Record' action is referencing the wrong table

AnswerC

Correct; flows in a scoped application require explicit ACL grants to update global tables like Incident.

Why this answer

Option C is correct because the flow's application scope determines the permissions granted to the flow when it executes. Even though the flow runs without errors, if the application scope does not have write access to the Incident table, the 'Update Record' action will silently fail to persist changes. This is a common misconfiguration where the scope's ACLs or table-level permissions are not properly set, causing updates to be discarded without raising an error.

Exam trap

The trap here is that candidates assume a flow running without errors means the update succeeded, but ServiceNow's security model can silently deny write operations when the application scope lacks proper table permissions.

How to eliminate wrong answers

Option A is wrong because the flow trigger being 'On Created' would only prevent the flow from running if the incident already existed before the trigger event; however, the question states the flow runs without errors, meaning the trigger condition is met and the flow executes. Option B is wrong because using a 'Lookup Record' instead of 'Update Record' would not cause a silent failure—it would simply not update the record, and the flow would likely produce a different outcome or error if an update was expected. Option D is wrong because if the 'Update Record' action referenced the wrong table, the flow would either fail with a table-not-found error or update a different table, not silently fail to update the intended incident record.

Practice this question →

22

MCQeasy

The data policy is intended to require short description when category changes during an update. However, the short description is never made mandatory. Which issue exists?

A.The table is Incident but the policy uses current.operation() incorrectly

B.The condition should use AND instead of OR

C.The script uses setMandatory which is not available in Data Policies

D.The policy should be of type 'Constraint'

AnswerC

Correct; Data Policies cannot change field properties via script; they can only enforce validation or abort saves.

Why this answer

Option C is correct because `setMandatory()` is a client-side method used in client scripts or UI policies, not in data policies. Data policies run server-side and use `mandatory=true` on a dictionary element or `gs.addErrorMessage()` to enforce field requirements. Since the script attempts to call `setMandatory()` within a data policy, it will fail to make the short description mandatory, leaving the requirement unmet.

Exam trap

ServiceNow often tests the distinction between server-side and client-side APIs, and the trap here is that candidates assume `setMandatory()` works everywhere because it is commonly used in UI policies, but it is not available in data policies.

How to eliminate wrong answers

Option A is wrong because `current.operation()` is a valid method in data policies to check the current database operation (insert, update, delete), and using it on the Incident table is appropriate; the issue is not about incorrect usage of this method. Option B is wrong because the condition logic (AND vs OR) is not the core problem; even with correct condition syntax, the script would still fail due to the invalid `setMandatory()` call. Option D is wrong because a 'Constraint' type policy is used for enforcing referential integrity or validation rules, not for making fields mandatory; the policy type 'Normal' is correct for this requirement.

Practice this question →

23

MCQeasy

A developer wants to prevent users from closing an incident after it has been resolved for more than 30 days. Which approach should be used?

A.Create an ACL to deny closing after 30 days.

B.Create a UI policy that disables the close button.

C.Create a client script that alerts the user.

D.Create a business rule on 'before' that aborts the operation if the condition is met.

AnswerD

Business rules run server-side and enforce the rule on all updates.

Why this answer

A 'before' business rule with an abort action is the correct server-side approach to prevent an operation from completing. When the condition (resolved_at is more than 30 days ago) is true, the business rule can call current.setAbortAction(true) to stop the incident from being updated or closed, ensuring the restriction is enforced regardless of the client interface.

Exam trap

The trap here is that candidates often choose client-side solutions (UI policy or client script) because they appear to 'disable' the button, but they fail to recognize that server-side enforcement is required to prevent direct API or scripted submissions from bypassing the restriction.

How to eliminate wrong answers

Option A is wrong because ACLs control read/write access to records and fields, not the logic of when an operation should be aborted based on a date condition. Option B is wrong because a UI policy only affects the client-side form behavior (e.g., disabling a button) and can be bypassed by direct API calls or scripts. Option C is wrong because a client script only shows an alert to the user but does not prevent the close operation from being submitted and processed on the server.

Practice this question →

24

MCQmedium

A business rule runs on 'before' and 'update' for the incident table. The rule sets the short_description to 'Test' only when the state changes to 'In Progress'. However, the short_description is being updated even when the state does not change. What is the most likely cause?

A.The business rule is set to run globally.

B.The business rule does not have an 'if (current.state.changes())' condition.

C.The business rule script modifies the field directly without checking.

D.The business rule is using the 'cancel' action.

AnswerB

To update only on state change, you must check if the state changed.

Why this answer

Option B is correct because the business rule lacks an 'if (current.state.changes())' condition. Without this check, the script runs on every update, setting the short_description to 'Test' regardless of whether the state field actually changed. The 'before' and 'update' triggers ensure the rule executes on every update, but the conditional logic must explicitly verify the state transition.

Exam trap

The trap here is that candidates often confuse the 'before' and 'update' triggers with automatic change detection, assuming the rule only fires when the state changes, when in fact the rule fires on every update unless a condition like 'current.state.changes()' is explicitly added.

How to eliminate wrong answers

Option A is wrong because setting a business rule to run globally does not affect its conditional logic; it only determines on which tables the rule applies, not when it fires. Option C is wrong because the script modifying the field directly without checking is exactly the symptom, not the root cause; the root cause is the missing condition that checks for state changes. Option D is wrong because the 'cancel' action is unrelated to this scenario; it is used to cancel a business rule from executing, not to cause unintended field updates.

Practice this question →

25

MCQeasy

A developer needs to create a service catalog variable that allows the user to select multiple values from a predefined list. Which variable type should be used?

A.Single Line Text

B.Radio Button

C.Select Box

D.Multiple Choice (Checkbox)

AnswerD

Multiple Choice allows multiple selections.

Why this answer

Option D is correct because the Multiple Choice (Checkbox) variable type in ServiceNow allows users to select multiple values from a predefined list. This is the only variable type that supports multi-select behavior, which is required when a user needs to choose more than one option from a set of choices.

Exam trap

ServiceNow often tests the distinction between single-select and multi-select variable types, and the trap here is that candidates confuse Select Box with Multiple Choice because both present a predefined list, but only Multiple Choice supports multiple selections.

How to eliminate wrong answers

Option A is wrong because Single Line Text is a free-text input field that does not provide a predefined list of values, so it cannot enforce selection from a set of options. Option B is wrong because Radio Button allows only a single selection from a predefined list, as radio buttons are mutually exclusive by design. Option C is wrong because Select Box (dropdown) also restricts the user to a single selection, even though it presents a predefined list.

Practice this question →

26

Multi-Selecteasy

Which TWO of the following are valid ways to reference a sys_id of a record in a business rule? (Choose two.)

Select 2 answers

A.current.number

B.current.getUniqueValue()

C.current.get('sys_id')

D.current.getRow()

E.current.sys_id

AnswersB, E

This method returns the sys_id.

Why this answer

Option B is correct because `getUniqueValue()` is a GlideRecord method that returns the unique identifier (sys_id) of the current record, even if the record is new and hasn't been saved yet. Option E is correct because `current.sys_id` directly accesses the sys_id field of the GlideRecord object, which is a standard way to reference the record's unique key in a business rule.

Exam trap

ServiceNow often tests the distinction between field values (like `current.number`) and the unique record identifier (sys_id), leading candidates to mistakenly choose `current.number` as a valid sys_id reference.

Practice this question →

27

Matchingmedium

Match each ServiceNow access control rule (ACL) type to its function.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Controls view access to records

Controls create and update access

Controls delete access

Controls record creation

Controls script execution

Why these pairings

ACL types define the operation being restricted.

Practice this question →

28

Multi-Selecteasy

Which TWO of the following are types of UI Policies? (Choose two.)

Select 2 answers

A.On change

B.On load

C.On submit

D.On delete

E.On query

AnswersA, B

UI Policies can run when a field changes.

Why this answer

UI Policies in ServiceNow are client-side scripts that run on the browser to control the behavior of fields on a form. The 'On change' type triggers when a specified field's value changes, allowing dynamic field updates or visibility changes. The 'On load' type triggers when the form is initially loaded, enabling default value setting or field configuration before user interaction.

Exam trap

The trap here is that candidates often confuse UI Policy triggers with Business Rule triggers, mistakenly selecting 'On submit' or 'On query' because they are familiar server-side events, but UI Policies only support 'On load' and 'On change' as client-side events.

Practice this question →

29

MCQhard

The Business Rule above runs on the 'incident' table. It is set to run 'before' update. What is the most likely issue with this script?

A.The script should use 'current' instead of 'gr' to update records.

B.The script has a syntax error: missing semicolon after the while loop.

C.The script will cause a recursive loop because it updates incident records within a Business Rule that runs on the same table.

D.The script does not commit the changes because it uses 'gr.update()' instead of 'current.update()'.

AnswerC

Updating incident records inside a before update Business Rule on incident can trigger the rule again.

Why this answer

Option C is correct because updating the same table (incident) within a 'before update' Business Rule that runs on that table creates a recursive loop. Each time the script calls gr.update() on an incident record, it triggers the same Business Rule again, leading to infinite recursion until the system enforces a governor limit or stack overflow. ServiceNow detects and prevents such loops by throwing an error, but the design is fundamentally flawed.

Exam trap

ServiceNow often tests the concept of recursive loops in Business Rules, and the trap here is that candidates focus on syntax or object usage (like 'current' vs 'gr') instead of recognizing that any update to the same table within a before/after update rule will cause recursion unless explicitly prevented.

How to eliminate wrong answers

Option A is wrong because 'current' is the correct object to use for the record being updated in a 'before' Business Rule, but the issue here is not about which object to use—it's about the recursive update. Option B is wrong because the script does not show a syntax error; the while loop is syntactically valid (assuming proper braces), and missing semicolons in JavaScript do not cause the specific recursive loop problem described. Option D is wrong because 'gr.update()' does commit changes to the database; the problem is not about committing but about triggering the same Business Rule again, which 'current.update()' would also do if it updated the same table.

Practice this question →

30

Drag & Dropmedium

Drag and drop the steps to create a new Catalog Item in ServiceNow into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

The correct order: navigate to Maintain Items, create new, set category and details, add variables, and submit.

Practice this question →

31

MCQmedium

A developer needs to capture the time when a field (assigned_to) was last changed. Which approach should be used?

A.Create a calculated field using a formula.

B.Create a business rule on 'after' update that sets a 'last_assigned' field when assigned_to changes.

C.Create a database trigger to log the change.

D.Use a dictionary override to enable auditing.

AnswerB

An after business rule can set a field on the same record or related record.

Why this answer

Option B is correct because a business rule configured on the 'after' update event can check if the 'assigned_to' field value has changed and then set a 'last_assigned' field to the current date/time. This approach is native to the platform, runs server-side, and ensures the timestamp is captured reliably without external dependencies.

Exam trap

The trap here is that candidates often choose calculated fields (Option A) thinking they can dynamically capture timestamps, but calculated fields are read-only and cannot persist a value when a field changes.

How to eliminate wrong answers

Option A is wrong because calculated fields (formula fields) are computed on the fly and cannot write or update a timestamp value when a field changes; they only display derived data. Option C is wrong because ServiceNow does not support direct database triggers; the platform abstracts database operations and uses business rules or flows instead. Option D is wrong because a dictionary override controls field-level metadata (like label or type) and does not capture change timestamps; auditing would log changes but requires enabling the audit trail and does not automatically populate a custom 'last_assigned' field.

Practice this question →

32

Multi-Selecthard

Which THREE of the following statements are true about ACLs? (Choose three.)

Select 3 answers

A.An ACL with 'require_role' set to true will only be checked after the user has at least one role in the ACL's role list.

B.If no ACL is defined for a table, all users have access to all records.

C.ACLs are evaluated in a deterministic order based on the type (record, field, etc.) and the script condition.

D.ACLs can be enforced on server-side scripts.

E.ACLs can be used to restrict access to specific records using condition scripts.

AnswersA, D, E

Require role means the user must have at least one of the specified roles.

Why this answer

Option A is correct because the 'require_role' attribute on an ACL record means the ACL rule is only evaluated after the system confirms the user has at least one of the roles listed in the ACL's role list. If the user has none of those roles, the ACL is skipped entirely, and the next ACL in the evaluation order is checked. This prevents unnecessary condition script execution for users who lack the prerequisite roles.

Exam trap

The trap here is that candidates often assume no ACL means full access (like a default permit), but ServiceNow's default is implicit deny, and they also confuse the evaluation order of ACLs, thinking it is based on condition script logic rather than the fixed sys_id order.

Practice this question →

33

MCQeasy

A developer wants to restrict access to a specific record in the incident table so that only members of the 'ITIL' group can read it. Which type of ACL should be created?

A.Create a field-level ACL on the sys_id field.

B.Create a record-level ACL with a condition that checks group membership.

C.Create a business rule to delete the record for unauthorized users.

D.Create a UI policy to hide the record.

AnswerB

Record-level ACLs control read, write, delete on the entire record.

Why this answer

A record-level ACL with a condition that checks group membership is the correct approach because it controls read access to the entire record based on the user's group membership. In ServiceNow, record-level ACLs evaluate conditions against the user's session and the record's data, and if the condition (e.g., 'member of ITIL group') is false, the record is hidden from the user entirely. This directly meets the requirement to restrict read access to a specific incident record for only the 'ITIL' group.

Exam trap

The trap here is that candidates often confuse UI policies (client-side) with ACLs (server-side) and think hiding the record in the UI is sufficient, but ServiceNow requires server-side ACLs to truly secure data from all access methods.

How to eliminate wrong answers

Option A is wrong because a field-level ACL on the sys_id field would only restrict access to that specific field, not the entire record; the user could still see other fields of the incident. Option C is wrong because a business rule that deletes the record for unauthorized users would permanently remove the data, which is not the goal (the requirement is to restrict read access, not delete data). Option D is wrong because a UI policy only controls the visibility or behavior of fields on a form in the UI; it does not enforce security at the server level, so a user could still access the record via other channels like web services or reports.

Practice this question →

34

Multi-Selectmedium

Which TWO of the following are true about client-callable script includes? (Choose two.)

Select 2 answers

A.They must have a function that returns a value.

B.They can only be used in scoped applications.

C.They must be accessed using the GlideAjax API.

D.They cannot be used in UI policies.

E.They can be called directly without GlideAjax if marked as synchronous.

AnswersA, C

The client script expects a response from the script include.

Why this answer

Option A is correct because client-callable script includes must have at least one function that returns a value. This is required because the GlideAjax API processes the response asynchronously and expects a return value to be sent back to the client via the callback function. Without a return value, the client-side callback would receive undefined or null, breaking the intended data flow.

Exam trap

ServiceNow often tests the misconception that client-callable script includes can be called synchronously or directly, but the GlideAjax API is mandatory for all client-side calls to server-side script includes, and there is no synchronous alternative.

Practice this question →

35

MCQmedium

A developer needs to create a scheduled job that runs every Monday at 8 AM to update all incidents with a priority of '1' that are still open. Which condition script should be used in the scheduled job?

A.var gr = new GlideAggregate('incident'); gr.addQuery('priority', 1); gr.query();

B.var gr = new GlideRecord('incident'); gr.addEncodedQuery('priority=1^active=true'); gr.query();

C.var gr = new GlideRecord('incident'); gr.get('priority', 1); gr.get('active', true);

D.var gr = new GlideRecord('incident'); gr.addQuery('priority', 1); gr.addQuery('active', true); gr.query();

AnswerB, D

Encoded query also works correctly.

Why this answer

Option B is correct because it uses `addEncodedQuery` with an encoded query string that combines both conditions (`priority=1^active=true`) into a single query, which is the standard approach for filtering records in a scheduled job. The `GlideRecord` object is properly instantiated and the query is executed with `gr.query()`, ensuring only incidents matching both criteria are retrieved for update.

Exam trap

ServiceNow often tests the distinction between `addQuery` and `addEncodedQuery`, and the trap here is that both Option B and Option D appear functionally identical, but the exam expects the encoded query approach as the more robust and standard practice for scheduled jobs, while `addQuery` chaining is also valid but less commonly used in this context.

How to eliminate wrong answers

Option A is wrong because it uses `GlideAggregate` instead of `GlideRecord`, which is designed for aggregation queries (e.g., counting, summing) and does not provide direct record iteration for updates. Option C is wrong because `gr.get('priority', 1)` and `gr.get('active', true)` are used incorrectly; `get()` retrieves a single record by sys_id or a specific field-value pair, not as a query filter, and chaining them does not combine conditions—it overwrites the previous call, resulting in only the last condition being applied.

Practice this question →

36

MCQmedium

A company has a custom table 'u_incident_task' that extends 'task'. The developer wants to add a field 'u_approval' that is a reference to 'sysapproval_approver'. Which method is the correct way to create this field?

A.Create a 'List' field type and set the table to sysapproval_approver.

B.Create a 'Reference' field and set the reference table to 'sysapproval_approver'.

C.Create a 'Reference' field and set the table to 'task' and the reference field to 'sysapproval_approver'.

D.Create a 'Choice' field and populate it with sysapproval_approver values.

AnswerB

This creates a proper reference to the sysapproval_approver table.

Why this answer

Option B is correct because a Reference field is designed to create a link from one table to another, storing the sys_id of the target record. Since 'u_approval' needs to point to a specific record in the 'sysapproval_approver' table, a Reference field with the reference table set to 'sysapproval_approver' is the appropriate method. This ensures referential integrity and allows the platform to resolve display values and enforce relationships.

Exam trap

The trap here is that candidates often confuse 'Reference field' with 'List field' or 'Choice field', mistakenly thinking a List can store a single reference or that a Choice can dynamically pull values from another table, when in fact only a Reference field provides the correct relational link and sys_id storage mechanism.

How to eliminate wrong answers

Option A is wrong because a List field stores multiple values as a delimited string, not a single reference to a record in another table, and cannot enforce referential integrity. Option C is wrong because setting the reference table to 'task' and then specifying a reference field to 'sysapproval_approver' is incorrect; the reference table must be the target table itself, not an intermediate table. Option D is wrong because a Choice field stores a predefined set of static values, not dynamic references to records in another table, and cannot link to sysapproval_approver records.

Practice this question →

37

MCQhard

A developer is troubleshooting a UI policy that sets a field to mandatory when another field equals 'Yes'. The UI policy works on desktop but not on the mobile app. What is the most likely cause?

A.The UI policy is set to 'Run on mobile' but the script is incompatible.

B.The field is not available on the mobile form.

C.The mobile app uses a different table.

D.The UI policy is set to 'Run on desktop' only.

AnswerD

UI policies have separate run options for desktop and mobile.

Why this answer

Option D is correct because UI policies have a 'Run on desktop' and 'Run on mobile' checkbox. By default, a new UI policy is set to run on desktop only. If the developer did not explicitly check the 'Run on mobile' option, the policy will not execute on the mobile app, causing the mandatory behavior to be absent on mobile while working on desktop.

Exam trap

ServiceNow often tests the distinction between 'Run on desktop' and 'Run on mobile' settings, trapping candidates who assume UI policies automatically apply to all platforms or who confuse this with field availability or table differences.

How to eliminate wrong answers

Option A is wrong because if the UI policy were set to 'Run on mobile', it would execute on mobile regardless of script compatibility; script incompatibility would cause errors, not a silent failure to run. Option B is wrong because if the field were not available on the mobile form, the UI policy would still attempt to run but might fail silently or show an error, but the question states the policy works on desktop, implying the field exists on the table; mobile forms typically include the same fields unless explicitly removed. Option C is wrong because the mobile app does not use a different table; it uses the same table as the desktop, and UI policies are table-scoped, so a different table would break the policy on both platforms.

Practice this question →

38

MCQeasy

A developer needs to ensure that a catalog variable of type 'Reference' displays only active users from the sys_user table. Which property configuration should be applied to the variable?

A.Set 'Reference qual' to 'active=true'

B.Set 'Condition' to 'active=true'

C.Set 'Ref qual' to 'active=true'

D.Set 'Default value' to 'active=true'

AnswerC

Ref qual allows a condition to filter the reference list.

Why this answer

Option C is correct because the 'Ref qual' (Reference qualifier) property on a reference variable allows you to specify a condition to filter the records displayed in the lookup. Setting it to 'active=true' restricts the reference field to show only active users from the sys_user table, ensuring the developer meets the requirement.

Exam trap

The trap here is that candidates confuse 'Reference qual' with 'Ref qual' or think 'Condition' is the correct property, when in fact 'Ref qual' is the exact property name used on reference variables in ServiceNow.

How to eliminate wrong answers

Option A is wrong because 'Reference qual' is not a valid property name; the correct property is 'Ref qual' (abbreviated). Option B is wrong because 'Condition' is not a property on a reference variable; it is used on other field types like UI policies or data policies. Option D is wrong because 'Default value' sets a pre-selected record, not a filter on the available choices.

Practice this question →

39

MCQmedium

A company has a custom table 'u_asset' with a reference field 'u_location' pointing to 'cmn_location'. When a user changes the location on an asset record, the system must automatically update the location on all related 'u_asset_software' records. Which approach should the developer use?

A.Create a Client Script that runs on load to update related records.

B.Create an ACL to automatically propagate changes.

C.Create a Business Rule that runs on update of the 'u_asset' table and updates related records.

D.Create a UI Policy that sets the location field on related records.

AnswerC

Business Rules run server-side and can update related records.

Why this answer

Option C is correct because a Business Rule that runs on the 'update' operation of the 'u_asset' table can directly query and update all related 'u_asset_software' records using GlideRecord. This server-side logic ensures the location change is propagated reliably, regardless of how the asset record is updated (UI, web service, import set, etc.), and it executes within the same database transaction for data consistency.

Exam trap

The trap here is that candidates confuse client-side mechanisms (Client Scripts, UI Policies) with server-side automation, or mistakenly think ACLs can perform data updates, when only a Business Rule can reliably propagate changes across tables on the server side.

How to eliminate wrong answers

Option A is wrong because a Client Script that runs on load cannot update related records; it runs in the browser and can only modify the current form's fields, not perform server-side updates on other tables. Option B is wrong because an ACL (Access Control List) controls read/write permissions on records, not data propagation or automated updates. Option D is wrong because a UI Policy is a client-side mechanism that sets field values on the current form based on conditions; it cannot update records on a different table like 'u_asset_software'.

Practice this question →

40

MCQeasy

What happens when a user changes the state from '2' to '1' on an incident record?

A.Nothing happens because the script does not have a return statement.

B.The record is saved without any message because setAbortAction is ignored in 'before' rules.

C.The record is saved and a message 'State change is not allowed' is shown.

D.The record is not saved and an error message 'State change is not allowed' is displayed.

AnswerD

The condition matches, so the action is aborted and error shown.

Why this answer

Option D is correct because in a 'before' business rule, calling `current.setAbortAction(true)` prevents the database operation from completing and displays the error message specified in `gs.addErrorMessage()`. When the state changes from '2' to '1', the script checks for this condition and aborts the save, showing 'State change is not allowed'. This is a standard pattern for enforcing state transition restrictions in ServiceNow.

Exam trap

The trap here is that candidates often confuse 'before' business rules with 'after' rules, mistakenly thinking that `setAbortAction` only works in 'after' rules or that a missing return statement causes the rule to be ignored.

How to eliminate wrong answers

Option A is wrong because a 'before' business rule does not require a return statement; the abort action is controlled by `setAbortAction(true)`, not by a return value. Option B is wrong because `setAbortAction` is fully respected in 'before' rules; it is not ignored, and it prevents the record from being saved. Option C is wrong because the record is not saved when `setAbortAction(true)` is called; the error message is displayed, but the save is aborted.

Practice this question →

41

MCQeasy

A developer is creating a new custom table for tracking software licenses. The table must inherit the core fields (sys_id, sys_created_by, etc.) and support extensibility for future sub-tables. Which base table should be used?

A.Use the Configuration Item (cmdb_ci) table as a base

B.Create a new table that extends directly from sys_db_object

C.Extend from the Task table

D.Clone the Incident table and remove unnecessary fields

AnswerB

Correct; creating a custom table that extends from the base system object provides only core fields and allows future extensibility without unnecessary overhead.

Why this answer

Option B is correct because extending a new table directly from sys_db_object creates a base table that automatically inherits the core system fields (sys_id, sys_created_by, etc.) and supports extensibility for future sub-tables. This is the standard approach in ServiceNow for creating custom tables that are not tied to any specific application or business logic, ensuring maximum flexibility and adherence to platform best practices.

Exam trap

The trap here is that candidates often choose the Task table (Option C) because they mistakenly believe all custom tables must extend from a 'task-like' structure, but ServiceNow explicitly recommends sys_db_object for custom base tables that do not require task management features.

How to eliminate wrong answers

Option A is wrong because the Configuration Item (cmdb_ci) table is designed for CMDB-related data and includes fields and relationships specific to configuration management, which would impose unnecessary constraints and overhead for a software license tracking table. Option C is wrong because extending from the Task table would inherit workflow-related fields (e.g., state, priority, assignment) that are irrelevant for a simple license tracking table and would complicate the data model. Option D is wrong because cloning the Incident table and removing fields is not a supported method for creating a base table; it would carry over incident-specific business rules, ACLs, and references, leading to maintenance issues and violating extensibility principles.

Practice this question →

42

MCQhard

A scoped application includes a script include that is intended to be used by a business rule in the global scope. The script include is marked as 'Client callable: false' and 'Accessible from: This application only'. The business rule cannot call the script include. Which change fixes this?

A.Set the script include name to start with 'global_'

B.Move the script include to the global scope

C.Change 'Accessible from' to 'All application scopes'

D.Set 'Client callable' to true

AnswerC

Correct; this setting allows the script include to be used by scripts in other scopes.

Why this answer

Option C is correct because the business rule in the global scope cannot access a script include restricted to 'This application only'. Changing 'Accessible from' to 'All application scopes' allows the global-scope business rule to invoke the script include, as cross-scope access is controlled by this property. The 'Client callable' setting is irrelevant for server-side business rules.

Exam trap

ServiceNow often tests the misconception that 'Client callable' controls all cross-scope access, but the trap here is that server-side cross-scope access is governed solely by the 'Accessible from' property, not the client-callable flag.

How to eliminate wrong answers

Option A is wrong because prefixing the script include name with 'global_' does not override the 'Accessible from' restriction; naming conventions do not grant cross-scope access. Option B is wrong because moving the script include to the global scope would break the scoped application's encapsulation and is unnecessary when the 'Accessible from' property can be adjusted. Option D is wrong because 'Client callable' controls client-side (browser) access, not server-side invocation by a business rule.

Practice this question →

43

Multi-Selectmedium

Which TWO of the following are valid ways to personalize a Service Portal widget without modifying the original widget code?

Select 2 answers

A.Extend the widget via Widget Library

B.Override the widget's server script via a Business Rule

C.Modify the widget's HTML template directly in the instance

D.Use a Widget Instance option to override properties

E.Create a new widget from scratch

AnswersA, D

Extending a widget via the Widget Library creates a new version that inherits from the original, allowing customization.

Why this answer

Options B and C are correct because they allow personalization without altering the original widget. Option A is wrong because modifying the HTML template directly alters the core widget. Option D is wrong because creating a new widget from scratch is not personalization but creation.

Option E is wrong because there is no standard Business Rule to override server scripts of a widget.

Practice this question →

44

MCQeasy

A junior developer is creating a new catalog item for requesting software licenses. The catalog item includes several variables such as software name, quantity, and cost center. The business requires that when a user submits the request, the cost center variable should automatically populate with the cost center of the user's manager. The developer has written a script in the 'On Load' catalog client script to populate the cost center field. However, during testing, the cost center field remains empty after the form loads. The developer checks the script and finds it uses GlideAjax to call a Scripted REST API to fetch the manager's cost center. What is the most likely cause of the issue?

A.The cost center variable is read-only and cannot be set by client scripts.

B.The Scripted REST API is not accessible from client scripts due to cross-origin restrictions.

C.The GlideAjax call is missing the callback function.

D.The 'On Load' client script runs before the GlideAjax response is received.

AnswerD

Correct: The script sets the field value before the async response returns.

Why this answer

The 'On Load' catalog client script triggers when the form loads, but GlideAjax makes an asynchronous call to the server. The script continues executing without waiting for the response, so the cost center variable remains empty until the callback fires. Since the callback updates the field asynchronously, the field appears empty on load because the response hasn't arrived yet.

Exam trap

ServiceNow often tests the asynchronous nature of GlideAjax in client scripts, tricking candidates into thinking the issue is a missing callback or a permission problem, when the real flaw is the timing of the response relative to the form load.

How to eliminate wrong answers

Option A is wrong because read-only variables can still be set by client scripts using g_form.setValue(), though the user cannot edit them manually. Option B is wrong because GlideAjax uses the same origin as the instance, so cross-origin restrictions do not apply; it calls a Scripted REST API on the same ServiceNow instance. Option C is wrong because while a missing callback would prevent the response from being processed, the question states the developer used GlideAjax to call the API, implying a callback exists; the core issue is the asynchronous timing, not the absence of a callback.

Practice this question →

45

MCQmedium

A company uses a custom application with a table 'incident_task' to track work on incidents. The requirement is to automatically reassign any incident_task that has not been updated in the last 7 days to a specific 'Escalation' group. A developer writes a Business Rule on the 'incident_task' table with the condition 'Current' table and runs on 'before query'. The script checks if (gs.daysAgo(current.sys_updated_on) >= 7) and then performs a current.assignment_group.setValue('escalation_group_sys_id'), followed by current.update(). After testing, the tasks are not being reassigned. What is the most likely cause of this issue?

A.The business rule should be changed to 'after' update.

B.Before query business rules cannot perform updates; they are read-only.

C.The condition should use 'sys_updated_on' instead of 'sys_updated_on' (the same field).

D.The script uses current.update() which causes recursion.

AnswerB

Before query business rules are designed for read operations and any attempt to update will be ignored.

Why this answer

Before query business rules in ServiceNow are executed during the retrieval of records from the database, and they are strictly read-only. They cannot perform updates, inserts, or deletes because the database operation is not yet complete. Attempting to call current.update() within a before query business rule will be ignored or cause an error, which is why the reassignment never occurs.

Exam trap

The trap here is that candidates may think any business rule can update the current record, but ServiceNow explicitly restricts before query rules to read-only operations, and the exam tests this specific constraint.

How to eliminate wrong answers

Option A is wrong because changing the business rule to 'after' update would not help; the issue is that the rule runs on 'before query', which is read-only, and an 'after' update rule would only fire on update operations, not on query. Option C is wrong because the condition already uses 'sys_updated_on' correctly; the field name is not the problem. Option D is wrong because while current.update() can cause recursion in other contexts (e.g., before/after update rules), in a before query rule it is simply not allowed to perform updates at all, so recursion is not the primary issue.

Practice this question →

46

MCQeasy

A developer needs to create a catalog item that requires approval from the user's manager. What is the best practice to configure this?

A.Use a Flow with a 'Get Approvals' action

B.Add an 'Approval' activity in the workflow

C.Use a Client Script to trigger an approval request

D.Use a Business Rule to set the approval state

AnswerB

The 'Approval' activity is specifically designed to manage approval processes in workflows.

Why this answer

Option A is correct because the 'Approval' activity in a workflow is the standard way to add approval steps in ServiceNow. Option B is wrong because Business Rules are not typically used for approval routing. Option C is wrong because 'Get Approvals' is not a standard action in Flow.

Option D is wrong because Client Scripts handle client-side behavior, not approval logic.

Practice this question →

47

MCQeasy

A ServiceNow developer is working on a new application that requires a custom table to store project information. The table needs to have fields for project name, start date, end date, and project manager (reference to sys_user). The developer creates the table using the Application Creator and adds the fields. After creating the table, the developer wants to automatically generate a unique project ID in the format 'PROJ-00001' for each new record. The developer considers using a Business Rule with a script or a Default Value with a scripted function. Which approach would be the most efficient and maintainable for generating the project ID?

A.Create an After Insert Business Rule that updates the project ID after the record is saved.

B.Create a Before Insert Business Rule that uses a script to query the current count of records and generate the next ID.

C.Create a calculated field that uses a scripted formula to generate the ID.

D.Create a Default Value for the project ID field using a script that calls a helper function.

AnswerD

Correct: Sets value before insert without extra update, and reusable.

Why this answer

Option D is correct because a Default Value script runs before the record is saved, allowing the unique ID to be generated without an extra update. Using a helper function promotes reusability and maintainability, and the script can query the current count of records to generate the next sequential ID in the desired format.

Exam trap

The trap here is that candidates often choose a Business Rule (Before or After Insert) because they think it gives more control, but they overlook that a Default Value script is simpler, more efficient, and avoids the extra update overhead or race condition issues.

How to eliminate wrong answers

Option A is wrong because an After Insert Business Rule would require an additional update to the record after it is already saved, causing unnecessary database operations and potential performance issues. Option B is wrong because a Before Insert Business Rule, while it runs before save, typically does not have access to the final record count reliably due to transaction isolation, and querying the count in a script can lead to race conditions under concurrent inserts. Option C is wrong because a calculated field is read-only and computed on the fly, not stored in the database, so it cannot serve as a persistent unique identifier for the record.

Practice this question →

48

MCQhard

A developer reports that an after business rule on the Change Request table is running twice for each update. The business rule is not scheduled or async. Which is the most likely cause?

A.The business rule is set to run 'On Update' and also 'On Insert'

B.The business rule order is too high

C.The business rule script updates the same record, causing a loop

D.The business rule exists in two different scoped applications

AnswerC

Correct; the after business rule triggers an update that re-executes the rule, resulting in double execution.

Why this answer

Option C is correct because an after business rule that updates the same record it triggered on will cause the business rule to fire again on the subsequent update, creating a recursive loop. Since the rule is not scheduled or async, each update triggers the rule synchronously, and if the script performs a `current.update()` or similar operation on the same table, it re-fires the same business rule, leading to duplicate execution.

Exam trap

The trap here is that candidates often confuse a business rule running twice due to a loop with other causes like incorrect event conditions or scope duplication, but the core issue is the recursive update within the same rule's script.

How to eliminate wrong answers

Option A is wrong because a business rule set to run 'On Update' and 'On Insert' would fire once on insert and once on update, not twice on the same update operation. Option B is wrong because the order value only determines the sequence of execution among multiple business rules on the same table and event, not the number of times a single rule runs. Option D is wrong because a business rule existing in two different scoped applications would cause one of them to be ignored (the one in the higher-priority scope or the one that is not active), not duplicate execution on the same record update.

Practice this question →

49

MCQhard

A developer creates a script include with client-callable true. The script include is used in a client script to validate a field. However, when the client script runs, it throws an error that GlideAjax is not defined. What is the most likely issue?

A.The script include is not marked as 'Client-callable'.

B.The client script is running in a UI policy instead of a client script.

C.The script include is a global scope but the client script is in a scoped application.

D.The client script is not using the correct GlideAjax syntax.

AnswerC

In scoped apps, GlideAjax may not be available for global script includes unless explicitly allowed.

Why this answer

Option C is correct because when a script include is marked as client-callable, it must be in the global scope to be accessible from a client script via GlideAjax. If the script include is in a scoped application and the client script is in a different scope (or even the same scope), the GlideAjax call will fail because scoped script includes are not automatically available to client-side code unless explicitly exposed via the 'Accessible from' property. The error 'GlideAjax is not defined' indicates the client-side API cannot find the script include, which is a scope isolation issue.

Exam trap

ServiceNow often tests the misconception that marking a script include as client-callable is sufficient for it to be used from any client script, ignoring the scope isolation requirement that client-callable script includes must be in the global scope.

How to eliminate wrong answers

Option A is wrong because the script include is already marked as client-callable (as stated in the question), so this is not the issue. Option B is wrong because UI Policies also run client-side JavaScript and can use GlideAjax; the error is not specific to the execution context of a UI Policy vs. a client script. Option D is wrong because the error 'GlideAjax is not defined' is a JavaScript reference error indicating the GlideAjax class itself is not available, not a syntax error in how it is used.

Practice this question →

50

MCQhard

A developer implemented an ACL to restrict read access on the 'incident' table. The condition script checks if the user is a member of the 'incident_manager' group. However, users who are not in the group are still able to see incidents. What is the most likely reason?

A.There is another ACL with a lower order that grants read access to all users, and the evaluation never reaches the scripted ACL.

B.The ACL is cached and users need to log out and back in for changes to take effect.

C.The condition script returns 'true' for users in the group but does not return 'false' for others, so the ACL defaults to 'no decision' and access is allowed.

D.The ACL is set to 'Inactive' so it does not apply, leaving access open.

AnswerA

ACLs are evaluated in ascending order; the first matching ACL is applied. A lower-order granting ACL can override a higher-order restrictive one.

Why this answer

Option A is correct because ACLs in ServiceNow are evaluated in order of their 'Order' field (lower numbers first). If a lower-order ACL grants read access to all users, the evaluation stops at that ACL and never reaches the scripted ACL that restricts access to the 'incident_manager' group. This is the most common reason for an ACL appearing to not work — a broader, higher-priority ACL is allowing access before the restrictive one is evaluated.

Exam trap

The trap here is that candidates assume a condition script that only returns 'true' for allowed users will automatically deny others, but in ServiceNow, an ACL must explicitly return 'false' to deny access; otherwise, the system treats it as 'no decision' and continues evaluating subsequent ACLs.

How to eliminate wrong answers

Option B is wrong because ACL changes in ServiceNow take effect immediately; there is no caching mechanism that requires a logout/login. Option C is wrong because if the condition script does not return 'false' for non-members, the ACL returns 'no decision', which means the system continues evaluating the next ACL in order — it does not default to allowing access. Option D is wrong because if the ACL were set to 'Inactive', it would be completely ignored, but the question states the developer implemented the ACL, implying it is active; even if inactive, the symptom would be that no restriction applies, but the most likely reason among the choices is the order issue.

Practice this question →

51

MCQmedium

A Script Include is defined as 'Scoped' and has 'Accessible from' set to 'All applications'. It contains a function that uses 'gs.getUser()'. When the Script Include is called from a Business Rule in a different application scope, what is the result?

A.The function runs successfully and gs.getUser() returns the current user from the caller's session.

B.An error occurs because scoped Script Includes cannot be called from other applications.

C.The function runs but gs.getUser() returns the user from the Script Include's application scope, not the caller.

D.The function runs but returns null because gs is not available in scoped applications.

AnswerA

Scoped Script Includes with 'All applications' access can be called from any scope, and gs APIs work globally.

Why this answer

Option A is correct because a Script Include defined as 'Scoped' with 'Accessible from' set to 'All applications' is explicitly made available to other application scopes. When called from a Business Rule in a different scope, the function executes in the context of the caller's session, so `gs.getUser()` returns the current user from the caller's session, not from the Script Include's own scope. This behavior is governed by the scoping rules that allow cross-application access when the property is set accordingly.

Exam trap

The trap here is that candidates often confuse 'Accessible from' with runtime context, incorrectly assuming that a scoped Script Include runs in its own application scope and thus returns a different user, when in fact the session context is always preserved.

How to eliminate wrong answers

Option B is wrong because scoped Script Includes can be called from other applications if the 'Accessible from' property is set to 'All applications', which is the case here. Option C is wrong because `gs.getUser()` always returns the user from the caller's session, not from the Script Include's application scope; the scope of the Script Include does not affect the session context. Option D is wrong because `gs` is fully available in scoped applications; it is a global object provided by the platform and is not restricted by scope.

Practice this question →

52

MCQmedium

A ServiceNow instance has a custom application for managing IT assets. The application uses a custom table 'u_asset' with fields: u_asset_tag (string), u_model (string), u_assignee (reference to sys_user), u_status (choice: In Use, In Stock, Retired). The application requires that when an asset is retired, the assignee field must be cleared. The developer created a Business Rule on the 'u_asset' table that runs before update. The script checks if the status changes to 'Retired' and sets the assignee to empty. However, the assignee is not being cleared when the status is changed to 'Retired'. The Business Rule is active and runs before update. What is the most likely cause?

A.The script sets the field using 'current.u_assignee = null;' instead of 'current.setValue("u_assignee", "");'.

B.The Business Rule is set to run after the record is saved, so changes are overwritten.

C.The condition 'current.u_status.changesTo("Retired")' is incorrect.

D.The Business Rule runs after update instead of before update.

AnswerA

Setting a reference field to null directly may not work; setValue should be used.

Why this answer

Option A is correct because in ServiceNow Business Rules, setting a field to null using direct assignment (e.g., current.u_assignee = null) does not trigger the platform's update logic; the change is not persisted to the database. The correct method is to use current.setValue('u_assignee', '') which properly marks the field for update and clears the reference.

Exam trap

The trap here is that candidates often assume direct assignment works for all field types, but ServiceNow requires setValue() for proper update tracking, especially when clearing reference fields.

How to eliminate wrong answers

Option B is wrong because the Business Rule is explicitly set to run 'before update', not after, so the timing is correct. Option C is wrong because current.u_status.changesTo('Retired') is a valid and commonly used condition that correctly detects a change to the specified choice value. Option D is wrong because the question states the Business Rule runs before update, and the issue is not about the run order but about how the field value is assigned.

Practice this question →

53

Multi-Selectmedium

Which TWO statements about ServiceNow UI Policies are true?

Select 2 answers

A.UI Policies can enforce data integrity at the database level

B.UI Policies can set fields as mandatory

C.UI Policies cannot be used on catalog items

D.UI Policies can have multiple script actions

E.UI Policies run on the server side only

AnswersB, D

True; UI Policy actions include setting mandatory, visible, etc.

Why this answer

UI Policies are client-side scripts that run on the browser to dynamically control form behavior, such as making fields mandatory, visible, or read-only based on conditions. Option B is correct because UI Policies can set the 'mandatory' attribute on a field, forcing users to provide a value before submitting the record.

Exam trap

The trap here is that candidates often confuse UI Policies with Business Rules, assuming UI Policies run server-side or can enforce database-level integrity, when in fact they are purely client-side and only affect the user interface.

Practice this question →

54

MCQhard

This ACL is configured to control read access on the 'incident' table. Under what condition will a user be allowed to read an incident record?

A.If the user is from the company specified, regardless of the assigned_to field.

B.If the user is from the company specified in the property and the incident is assigned to the user.

C.If the user is from the company specified and the incident is assigned to the user's manager.

D.If the user's manager is from the company specified and the incident is assigned to the user.

AnswerC

Both conditions: user's company matches property, and incident assigned to user's manager.

Why this answer

Option C is correct because the ACL condition checks that the user's company matches the company specified in the property, and the incident record's assigned_to field equals the user's manager. This is a common pattern in ServiceNow where read access is granted based on a relationship (manager) rather than direct assignment, ensuring that managers can view incidents assigned to their direct reports.

Exam trap

The trap here is that candidates often confuse the direction of the manager relationship, assuming the incident must be assigned to the user's manager rather than the user themselves, or they incorrectly apply the company check to the manager instead of the user.

How to eliminate wrong answers

Option A is wrong because it ignores the assigned_to field entirely, which is a required condition in the ACL; the user must also satisfy a relationship to the assigned user. Option B is wrong because it requires the incident to be assigned to the user themselves, but the correct condition uses the user's manager, not the user. Option D is wrong because it incorrectly checks the manager's company instead of the user's company, and the assignment condition is reversed (incident assigned to the user, not the user's manager).

Practice this question →

55

MCQmedium

The exhibit shows an ACL condition script intended to allow read access to an incident only if the user has the 'itil' role and is a member of the incident's assignment group. However, users who are members of the assignment group but do not have the 'itil' role are still able to read the incident. What is the most likely problem?

A.The condition script must return true explicitly for the ACL to deny access.

B.The ACL is set to condition type 'script' but the script is not structured correctly.

C.The isMemberOf method requires a group sys_id, not a user ID.

D.There is another ACL on the incident table that grants read access to users with the 'itil' role without the group membership check.

AnswerD

If another ACL grants access, it overrides the denial from this ACL.

Why this answer

Option D is correct because ServiceNow ACLs are evaluated in a hierarchy: if any ACL on the same table and operation grants access, the user is allowed. Even if the intended ACL correctly denies access when the group membership check fails, another ACL that grants read access to users with the 'itil' role (without the group condition) will override the denial. The condition script in the intended ACL never gets a chance to block the user because the granting ACL is evaluated first and returns true.

Exam trap

The trap here is that candidates assume a single ACL's condition script is evaluated in isolation, when in fact ServiceNow evaluates all ACLs for the same table and operation, and a granting ACL elsewhere can override a denying one.

How to eliminate wrong answers

Option A is wrong because ACLs in ServiceNow do not require an explicit 'return true' to deny access; a condition script that returns false will deny access by default. Option B is wrong because the condition type 'script' is correctly set, and the script structure is not inherently flawed; the issue is the presence of a conflicting ACL, not a syntax or structure error. Option C is wrong because the isMemberOf method in ServiceNow accepts either a group sys_id or a group name, not a user ID; the method checks if the current user is a member of the specified group.

Practice this question →

56

MCQmedium

The UI Policy has a 'Reverse if false' checkbox unchecked. When will the UI Policy's actions (such as setting a field mandatory) be applied?

A.When any user accesses a record interactively.

B.When any user accesses a record via any method.

C.When a user with the 'admin' role accesses a record via web services.

D.When a user with the 'admin' role accesses a record interactively (e.g., via the browser).

AnswerD

Both conditions must be true: admin role and interactive session.

Why this answer

Option D is correct because the 'Reverse if false' checkbox being unchecked means the UI Policy's conditions are evaluated only on interactive form loads (browser access), and the actions apply when the conditions are true. For non-admin users, UI Policies with 'Reverse if false' unchecked apply only when conditions are met during interactive access; however, the question specifies the checkbox is unchecked, and the correct answer highlights that admin users accessing records interactively trigger the policy's actions when conditions are true, as UI Policies do not run for web services or background operations unless explicitly configured.

Exam trap

The trap here is that candidates confuse UI Policies with business rules, assuming they run for all access methods (including web services), or they forget that admin users have special handling where UI Policies still execute but may not enforce mandatory/read-only constraints, leading them to pick 'any user' or 'via any method' options.

How to eliminate wrong answers

Option A is wrong because UI Policies do not apply to 'any user' interactively; they are role-sensitive and can be scoped to specific conditions, and the 'Reverse if false' checkbox being unchecked does not change that the policy only runs for interactive access, but the statement is too broad and ignores that admin users have special behavior (e.g., UI Policies with 'Reverse if false' unchecked still apply to admins interactively). Option B is wrong because UI Policies do not apply 'via any method'—they are specifically designed for interactive (browser) form loads and do not run for web services, background scripts, or REST/SOAP API calls. Option C is wrong because UI Policies are never evaluated during web service access, regardless of the user's role; web services use business rules or scripted REST APIs, not UI Policies.

Practice this question →

57

MCQeasy

An administrator sees that a client script on a catalog item is not firing. The script is defined in the catalog item's 'Variable Editor' as a 'onSubmit' script. Which is the most likely reason?

A.The script is set to run on 'onLoad', but the page is being cached

B.The script is defined on a variable, but the variable is not on the order form

C.The script is written as a 'Catalog Client Script' but is defined in the 'Variable Editor' of the variable

D.The script uses 'g_form' but the form is not loaded yet

AnswerC

Correct; client scripts for catalog items must be defined in the Catalog Client Scripts related list, not inside a variable definition.

Why this answer

Option C is correct because the scenario describes a script defined in the catalog item's 'Variable Editor' as an 'onSubmit' script, which is a variable-level script. However, the question states the script is not firing. The most likely reason is that the script was written as a 'Catalog Client Script' (a global script type) but was incorrectly placed in the 'Variable Editor' of a variable.

Variable-level scripts in the Variable Editor are executed only when that specific variable is present on the form; if the script is actually a Catalog Client Script (which runs on the entire catalog item), it would not execute as expected because it is scoped to the variable, not the item. This mismatch between the intended script type and its location causes the script to fail to fire.

Exam trap

The trap here is that candidates confuse the scope of variable-level scripts (defined in the Variable Editor) with item-level Catalog Client Scripts, assuming any script placed in the Variable Editor will run globally for the catalog item.

How to eliminate wrong answers

Option A is wrong because an 'onSubmit' script fires on form submission, not on page load; caching affects 'onLoad' scripts, not 'onSubmit' scripts. Option B is wrong because if a script is defined on a variable but that variable is not on the order form, the script simply does not execute—it does not cause a 'not firing' issue; the script is correctly scoped but absent. Option D is wrong because 'g_form' is available as soon as the form is loaded, and an 'onSubmit' script runs after the form is fully loaded, so 'g_form' is always accessible at that point.

Practice this question →

58

MCQhard

A company has implemented a custom application for tracking employee training. The application uses a custom table 'u_training' with fields: u_employee (reference to sys_user), u_course (string), u_completion_date (date), and u_status (choice: Not Started, In Progress, Completed). The application has a Business Rule that runs after insert and after update. The rule should send an email notification to the employee when the status changes to 'Completed'. However, the email is not being sent. The developer has verified that the notification record exists and is active. The Business Rule script uses the 'gs.eventQueue' method to trigger a custom event. The event is registered and the notification is configured to be triggered by that event. What is the most likely cause of the issue?

A.The event name is misspelled in the gs.eventQueue call.

B.The Business Rule does not have a condition to check if the status changed to 'Completed'.

C.The notification is set to 'Inactive'.

D.The employee's email address is not set in sys_user.

AnswerB

Without a condition, the event is fired on every insert and update, but the notification may have a condition that checks status. However, the likely issue is that the rule fires on all updates, but the notification condition might not be met. More precisely, the rule should fire only when status changes to Completed.

Why this answer

Option B is correct because the Business Rule lacks a condition to verify that the status field actually changed to 'Completed'. Without a condition like `current.u_status.changesTo('Completed')`, the rule fires on every insert and update, calling `gs.eventQueue` even when the status hasn't changed. This means the event is triggered unnecessarily, but more critically, the notification may not fire because the event is not scoped to the specific state transition.

The developer verified the notification record is active, so the missing condition is the most likely root cause.

Exam trap

The trap here is that candidates assume the Business Rule will always fire the event, overlooking the need for a condition to check the specific field change, which is a common oversight in ServiceNow development.

How to eliminate wrong answers

Option A is wrong because if the event name were misspelled in `gs.eventQueue`, the event would not fire at all, and the developer would likely see an error or no event in the system log; however, the question states the event is registered and the notification is configured, so a misspelling would be a basic mistake that would be caught early. Option C is wrong because the developer explicitly verified that the notification record exists and is active, so it cannot be set to 'Inactive'. Option D is wrong because while a missing email address would prevent delivery, the question focuses on the Business Rule logic; the email not being sent is due to the event not being triggered correctly, not a recipient configuration issue, and the developer would have checked the user record if that were the case.

Practice this question →

59

MCQhard

A company has a requirement that the 'state' field of an incident cannot be changed from 'In Progress' to 'Resolved' if the 'category' field is empty. This validation must be enforced server-side to prevent data integrity issues. Which implementation should be used?

A.Make the 'category' field mandatory using a Data Policy.

B.Configure an ACL on the 'state' field to deny write access when category is empty.

C.Create a Client Script on 'state' change that checks if category is empty and shows an error message.

D.Create a 'before' Business Rule that checks if the state is changing to 'Resolved' and if category is empty, aborts the update with an error message.

AnswerD

Before Business Rules can prevent updates by returning false and setting error messages.

Why this answer

Option C is correct because a Business Rule with 'before' 'update' and a condition checking the change, then using gs.addErrorMessage() and returning false, will prevent the update server-side. Option A (Client Script) runs client-side and can be bypassed. Option B (ACL) controls read/write access, not specific value transitions.

Option D (Data Policy) makes category mandatory, which conflicts with existing records that might have empty category on other states.

Practice this question →

60

MCQmedium

A developer creates a Scheduled Job that runs daily and sends an email notification to a list of users. The job uses a Script Action to query the 'incident' table and sends an email if the count exceeds a threshold. However, the email is not being sent. What is the most likely cause?

A.The email notification is set to 'Inactive'.

B.The Scheduled Job is configured to run on a different schedule than expected.

C.The user who created the job does not have the 'email_send' role.

D.There is a script error in the Script Action that prevents the email from being sent.

AnswerD

A script error would cause the action to fail silently, and no email is sent.

Why this answer

Option D is correct because the most likely cause of the email not being sent is a script error in the Script Action. If the script encounters an error (e.g., a syntax error, a null reference, or a failed query), it will stop execution before reaching the email-sending logic, and the email will not be sent. Scheduled Jobs in ServiceNow execute scripts in a headless environment, and any unhandled exception will silently fail without sending the email.

Exam trap

The trap here is that candidates may assume the email notification's active state (Option A) is the cause, but the question specifies a Script Action directly sending the email, not a notification record, so the notification's state is irrelevant.

How to eliminate wrong answers

Option A is wrong because if the email notification were inactive, the Scheduled Job would still execute, but the notification record would not fire; however, the question states the email is not being sent, and the job uses a Script Action to send the email directly (likely via `gs.email.send()`), not via a notification record, so the notification's active state is irrelevant. Option B is wrong because if the job were running on a different schedule, it would still send the email when it does run; the issue is that the email is never sent, not that it runs at the wrong time. Option C is wrong because the `email_send` role is required to send email via `gs.email.send()` in a background script, but the Scheduled Job runs as the user who created it; if that user lacks the role, the script would throw a security exception, which is a script error, making D the more direct and likely cause.

Practice this question →

61

MCQhard

A company is using ServiceNow for incident management. They have a business rule on the 'before update' of the incident table that automatically assigns the incident to the first available member of the 'Support' group when the state changes to 'New'. The business rule works correctly when an incident is first created with state 'New', but when an existing incident's state is changed to 'New' from another state, the assignment does not happen. The business rule script checks if current.state.changesTo('New') and then queries the group members. The group has multiple members. Other business rules that run on state changes work fine. What is the most likely cause?

A.The condition current.state.changesTo('New') only works on insert, not on update.

B.A subsequent business rule that runs after this one in the same order is clearing the assignment field.

C.The business rule should be set to run on 'after' update instead of 'before' to ensure the state is committed.

D.The script uses current.assignment_group which is not available on update because the group might be different.

AnswerB

If another business rule runs after and sets assignment to empty, it would overwrite the assignment made by this rule.

Why this answer

Option B is correct because the business rule runs on 'before update', and if a subsequent business rule in the same execution order clears the assignment field after this rule sets it, the assignment will be lost. This is a common issue when multiple business rules interact on the same table and order of execution matters. The fact that other state-change business rules work fine indicates the logic itself is sound, but a later rule is overriding the assignment.

Exam trap

The trap here is that candidates often assume changesTo() has a limitation on update, when in reality the issue is the order of execution and interaction between multiple business rules, which is a common pitfall in ServiceNow development.

How to eliminate wrong answers

Option A is wrong because current.state.changesTo('New') works on both insert and update; it returns true when the state field is changing to 'New' during an update, and it also works on insert (though on insert the 'from' value is null). Option C is wrong because running on 'after' update would not fix the issue; the assignment would still be cleared by a subsequent rule, and 'before' is actually the correct timing to set a field before it is saved. Option D is wrong because current.assignment_group is available on update; the group field is not read-only and can be accessed and set in both before and after business rules.

Practice this question →

62

Multi-Selecthard

Which THREE of the following are true about ACLs (Access Control Lists)? (Choose three.)

Select 3 answers

A.ACLs can include conditions that must be met for access.

B.ACLs are evaluated on the client side.

C.ACLs are only applicable to system tables.

D.ACLs can control read and write access to records.

E.ACLs can be scoped to a specific application.

AnswersA, D, E

Conditions can be added to ACLs.

Why this answer

ACLs (Access Control Lists) in ServiceNow are used to enforce security by specifying conditions that must be met for a user to access a record, field, or script. Option A is correct because an ACL defines a condition (typically a script or a set of conditions) that evaluates to true or false, and only when the condition is met is access granted or denied. This is the core mechanism of ServiceNow's role-based and condition-based access control.

Exam trap

ServiceNow often tests the misconception that ACLs are client-side or only apply to system tables, but in ServiceNow, ACLs are server-side and apply to all tables, including custom and scoped application tables.

Practice this question →

63

MCQhard

A developer needs to create a new application scope. Which of the following is a best practice when defining the scope?

A.Set the scope to 'Protected' to prevent other applications from modifying its records.

B.Use the global scope to avoid access restrictions.

C.Use a scope name that is already in use to leverage existing configurations.

D.Create the scope and later change the name if needed.

AnswerA

Protected scope prevents unauthorized modifications.

Why this answer

Setting the scope to 'Protected' is a best practice because it prevents other applications from modifying the application's records while still allowing the application to access records from other scopes. This balances security and interoperability, ensuring that the application's data integrity is maintained without unnecessarily restricting cross-scope access.

Exam trap

The trap here is that candidates often confuse 'Protected' with 'Private' and assume it blocks all access, or they mistakenly think global scope is the safest choice because it avoids access restrictions, when in fact it exposes the application to unauthorized modifications.

How to eliminate wrong answers

Option B is wrong because using the global scope exposes the application's records to modification by any other application, undermining data integrity and security. Option C is wrong because scope names must be unique within an instance; reusing an existing scope name would cause a conflict and is not permitted. Option D is wrong because the scope name is immutable after creation; it cannot be changed later without recreating the application, which would break existing references and configurations.

Practice this question →

64

MCQhard

A developer is designing a solution to allow users to request access to specific applications through a Service Catalog. Each application can be requested by multiple users, and each user can request multiple applications. The request must capture the user's business justification and the date needed. The developer needs to model the data. Which database schema design best adheres to ServiceNow best practices?

A.Add a string field on the Application table that stores a comma-separated list of user sys_ids

B.Add a multi-reference field on the User table that lists all requested applications

C.Create a custom table 'u_application_request' with fields: user (reference to sys_user), application (reference to custom application table), justification (string), date_needed (date)

D.Create one table for all requests with a reference to both user and application, but store justification and date needed separately in a different table

AnswerC

Correct; a dedicated M2M table with additional attributes models the relationship and captures extra data.

Why this answer

Option C is correct because it creates a dedicated 'u_application_request' table with reference fields to both sys_user and the custom application table, plus justification and date_needed fields. This models the many-to-many relationship properly with additional attributes, adhering to ServiceNow best practices of using reference fields for relationships and avoiding unstructured data storage.

Exam trap

The trap here is that candidates often choose Option D thinking it follows 'separation of concerns' by splitting data into multiple tables, but ServiceNow best practices favor a single table for all attributes of a relationship to maintain simplicity and query performance.

How to eliminate wrong answers

Option A is wrong because storing comma-separated user sys_ids in a string field violates normalization principles, makes querying and reporting inefficient, and breaks referential integrity. Option B is wrong because a multi-reference field on the User table can list applications but cannot capture additional attributes like justification and date_needed, and it creates an asymmetric relationship that complicates maintenance. Option D is wrong because storing justification and date_needed in a separate table from the request association introduces unnecessary complexity and fragmentation, violating the principle of keeping related data together in a single table.

Practice this question →

65

Multi-Selecteasy

Which THREE are valid actions that can be performed by a Workflow Activity in Legacy Workflow Editor?

Select 3 answers

A.Run a script

B.Approve a record

C.Wait for condition

D.Create a record

E.Send an event

AnswersA, D, E

True; Run Script activity executes GlideRecord scripts.

Why this answer

Option A is correct because the Legacy Workflow Editor includes a 'Run Script' activity that executes server-side JavaScript (GlideRecord, GlideSystem, etc.) within the workflow context. This allows custom logic such as data manipulation, condition checks, or API calls to be performed as part of the workflow flow.

Exam trap

ServiceNow often tests the exact naming of workflow activities; the trap here is that 'Wait for condition' (lowercase 'c') is not the official activity name—it is 'Wait for Condition'—and candidates may mistakenly select it as a valid action when the question expects only activities that perform an explicit action (like creating, sending, or running a script), not a passive wait state.

Practice this question →

66

MCQmedium

A company is expanding its use of ServiceNow and needs to create a custom application for managing employee onboarding tasks. The application includes several tables: Onboarding Request, Task, and Checklist Items. The business requires that when an onboarding request is submitted, a set of tasks should be automatically created in a specific order. Additionally, when all tasks are completed, the onboarding request status should automatically update to 'Completed'. The developer decides to use Flow Designer to automate this process. The developer creates a flow with a trigger on the Onboarding Request table for 'Record created or updated' and adds actions to create tasks. However, during testing, the flow creates tasks but does not update the request status when tasks are completed. What is the most likely issue?

A.The flow is set to run only on create, not on update.

B.The flow uses a 'Wait for condition' action that is not configured correctly.

C.The user does not have rights to update the Onboarding Request table.

D.The flow is not configured to listen for updates on the Task table.

AnswerD

Correct: The flow needs a trigger on Task table to respond to task completion.

Why this answer

Option D is correct because the flow is triggered only by events on the Onboarding Request table. To update the request status when tasks are completed, the flow must also listen for updates on the Task table (e.g., via a separate flow or a 'Wait for condition' that polls the Task table). Without a trigger or condition monitoring the Task table, the flow has no way to know when tasks finish.

Exam trap

ServiceNow often tests the misconception that a single flow triggered on one table can automatically react to changes in a related table without an explicit trigger or condition on that related table.

How to eliminate wrong answers

Option A is wrong because the trigger is set for 'Record created or updated', so it runs on both create and update events on the Onboarding Request table. Option B is wrong because a 'Wait for condition' action could be used to poll the Task table, but the core issue is that the flow lacks any trigger or mechanism to react to Task table updates; the problem is not misconfiguration of a wait action but the absence of a trigger on the Task table. Option C is wrong because if the user lacked rights to update the Onboarding Request table, the flow would fail entirely or produce an error, not silently skip the status update.

Practice this question →

67

Multi-Selecthard

Which TWO conditions must be met for a Scoped Application to access a table from another scope without using an access grant?

Select 2 answers

A.The application is installed in the same instance as the table

B.The table is extended from a table in the consumer application scope

C.The table name starts with 'sys_'

D.The table belongs to the global scope

E.The table is marked as 'Allow access to all application scopes' in its application file

AnswersD, E

True; global tables are accessible by all scoped applications by default.

Why this answer

Option D is correct because tables in the global scope are accessible by default to all scoped applications without requiring an explicit access grant. This is a fundamental rule in ServiceNow's scoping model: global-scope tables are considered shared resources, so any scoped application can read from or write to them as long as the application is installed in the same instance. Option E is also correct because marking a table as 'Allow access to all application scopes' in its application file explicitly overrides the default scope isolation, granting cross-scope access without a grant.

Exam trap

ServiceNow often tests the misconception that any table in the global scope is automatically accessible, but the trap here is that candidates confuse 'global scope' with 'system tables' (sys_ prefix) or assume that extension implies access, leading them to pick options B or C instead of recognizing the explicit conditions required for grant-free access.

Practice this question →

68

MCQeasy

A developer needs to create a record in the 'task' table when a specific condition is met in a Business Rule. The new record should be linked back to the current record via a reference field. What is the best practice to ensure the new record is created in the same transaction?

A.Use GlideRecord with newRecord() and set values, then call insert().

B.Use Flow Designer to create the record asynchronously.

C.Use the GlideRecord updateMultiple() method.

D.Call a Scripted REST API to insert the record.

AnswerA

This is the standard way to create records in the same transaction within a Business Rule.

Why this answer

Option A is correct because using GlideRecord with newRecord() and insert() within the same Business Rule ensures the new 'task' record is created in the same database transaction as the current record. This guarantees atomicity: if the insert fails, the entire transaction rolls back, preventing orphaned records. The reference field linking back to the current record is set synchronously before the insert, maintaining data integrity.

Exam trap

The trap here is that candidates often think asynchronous methods like Flow Designer are 'best practice' for decoupling, but the question explicitly requires same-transaction creation, which only synchronous GlideRecord insert provides.

How to eliminate wrong answers

Option B is wrong because Flow Designer asynchronously creates the record in a separate transaction, breaking atomicity and potentially causing race conditions or orphaned records if the current transaction fails. Option C is wrong because updateMultiple() is used to update existing records in bulk, not to insert a new record; it cannot create a new record linked to the current one. Option D is wrong because calling a Scripted REST API introduces a separate HTTP request and transaction, defeating the purpose of same-transaction creation and adding unnecessary latency and failure points.

Practice this question →

69

MCQeasy

A developer is creating a catalog item that requires a user to upload a file. Which variable type should be used?

A.Attachment

B.Multi Line Text

C.Single Line Text

D.Checkbox

AnswerA

Attachment variable type allows file uploads.

Why this answer

The Attachment variable type is specifically designed for file uploads in ServiceNow catalog items. It provides a built-in file picker and stores the uploaded file as an attachment on the requested record, enabling users to submit documents directly through the catalog form.

Exam trap

ServiceNow often tests the distinction between variable types that handle data differently; the trap here is that candidates might confuse 'Attachment' with 'Single Line Text' thinking a file path can be entered as text, but ServiceNow requires the dedicated Attachment variable for actual file uploads.

How to eliminate wrong answers

Option B (Multi Line Text) is wrong because it is intended for free-form text input spanning multiple lines, not for file uploads. Option C (Single Line Text) is wrong because it accepts only a single line of text and cannot handle binary file data. Option D (Checkbox) is wrong because it represents a boolean true/false value and has no capability for file attachment.

Practice this question →

70

MCQhard

A developer is optimizing a Business Rule that runs on every update to the 'incident' table. The rule uses GlideAggregate to count related records. The developer notices performance degradation. Which change will most improve performance while maintaining functionality?

A.Replace GlideAggregate with GlideRecord and count results manually.

B.Add a database index on the foreign key field used in the aggregate.

C.Add a condition to the Business Rule such as 'current.changesField('state')' to only run the aggregate when relevant.

D.Use the gs.addInfoMessage() to log the count and disable the script in production.

AnswerC

Limiting execution to only when the 'state' field changes reduces unnecessary processing.

Why this answer

Option C is correct because it prevents the GlideAggregate from executing on every update, instead running only when the 'state' field changes. This reduces unnecessary database operations, directly addressing the performance degradation while preserving the rule's functionality when needed.

Exam trap

ServiceNow often tests the misconception that adding an index (Option B) is the universal performance fix, but the trap here is that reducing unnecessary execution (Option C) is a more impactful optimization than improving query speed for a query that runs too often.

How to eliminate wrong answers

Option A is wrong because replacing GlideAggregate with GlideRecord and manually counting results would be even less efficient, as it retrieves all related records into memory rather than performing a server-side count. Option B is wrong because while adding a database index can improve query performance, it does not address the root cause of running the aggregate on every update; the performance gain is marginal compared to reducing execution frequency. Option D is wrong because using gs.addInfoMessage() to log the count and disabling the script in production would eliminate the functionality entirely, not maintain it.

Practice this question →

71

MCQhard

An application has a custom table 'u_project' with a field 'u_status' (choice list: Not Started, In Progress, Completed). The developer wants to prevent any update to the record if the status is 'Completed'. Which approach should be used?

A.Create a Database View that filters out Completed records.

B.Create a Client Script that sets the field to read-only when status is Completed.

C.Create a Business Rule with condition 'current.u_status.changesTo("Completed")' and set 'current.setAbortAction(true)' in the script.

D.Create a UI Policy to disable the entire form when status is Completed.

AnswerC

Business Rules can abort actions before they occur.

Why this answer

Option C is correct because a Business Rule with the condition `current.u_status.changesTo('Completed')` triggers only when the status field transitions to 'Completed', and `current.setAbortAction(true)` aborts the database update operation at the server level, ensuring that no update can persist regardless of client-side behavior. This approach enforces the restriction server-side, which is essential for data integrity because client-side scripts can be bypassed.

Exam trap

The trap here is that candidates often choose client-side options (B or D) because they see 'prevent update' as a UI problem, but the exam tests the understanding that only server-side logic can enforce data integrity against all update sources.

How to eliminate wrong answers

Option A is wrong because a Database View is a read-only construct that does not prevent updates to the underlying table; it only provides a filtered representation of data for querying. Option B is wrong because a Client Script runs in the browser and can be bypassed by direct API calls or by disabling JavaScript, so it does not provide a server-side enforcement of the update restriction. Option D is wrong because a UI Policy only controls the user interface (e.g., making fields read-only or hiding them) and does not prevent updates submitted via REST, SOAP, or background scripts; it also does not abort the transaction on the server.

Practice this question →

72

MCQeasy

A developer wants to send an email notification when a new incident is created. Which component should be configured to trigger the notification?

A.Use Flow Designer to create a flow that sends an email.

B.Write a Business Rule that calls the email utility.

C.Create a Notification record with the condition 'New' and 'Action: record inserted'.

D.Create an ACL with email action.

AnswerC

Notifications are the standard way to send emails on record events.

Why this answer

Option C is correct because in ServiceNow, the native Notification mechanism is specifically designed to send emails based on conditions like 'New' and 'Action: record inserted'. When a new incident is created, the system evaluates the notification's condition; if it matches, the notification triggers automatically without requiring custom scripting or flow design. This is the standard, out-of-box approach for email alerts on record creation.

Exam trap

The trap here is that candidates often confuse the purpose of Business Rules (which can also send emails via script) with the dedicated Notification engine, leading them to choose Option B, but ServiceNow's best practice and the exam emphasize using the native Notification record for simple email triggers on record creation.

How to eliminate wrong answers

Option A is wrong because Flow Designer is typically used for more complex, multi-step automations; while it can send emails, it is not the simplest or most direct component for a basic trigger-on-insert notification, and using it would introduce unnecessary overhead. Option B is wrong because writing a Business Rule that calls the email utility is a custom scripting approach that bypasses the built-in Notification engine, leading to maintenance challenges and potential performance issues; ServiceNow recommends using Notifications for such standard email triggers. Option D is wrong because ACLs (Access Control Lists) control data access and security, not email notifications; they have no capability to send emails or trigger actions on record insertion.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Core Application Development questions.

Start 20-question session