Courseiva

CCNA Platform Features and Integration Questions

41 questions · Platform Features and Integration · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

A company uses IntegrationHub to connect to an external CRM. The OAuth provider record and REST message are configured. When testing, authentication fails. What is the most likely cause?

A.The client secret is not base64 encoded.
B.The OAuth provider profile is not linked to the REST message.
C.The token URL is missing the grant_type parameter.
D.The REST message is set to POST instead of GET.
AnswerB

The OAuth profile must be associated with the REST message for authentication to work.

Why this answer

The OAuth provider profile must be linked to the REST message; otherwise, the authentication configuration is not applied. Option A is not required for client credentials. Option B: grant_type is in the body, not URL.

Option C: POST is correct for token endpoint.

Practice this question →
2
MCQeasy

A company wants to allow their customers to submit requests via email. The email should create a new record in the 'Request' table. Which component should be used to define the mapping of email fields to the ServiceNow table fields?

A.Inbound Email Action
B.Email Account
C.Inbound Email Script
D.Email Notification
AnswerA

Inbound email actions define conditions and scripts to map email fields to table fields.

Why this answer

An Inbound Email Action is the correct component because it defines the mapping of email fields (e.g., subject, body, sender) to ServiceNow table fields (e.g., 'Short description', 'Description', 'Caller'). It uses a script or condition to parse the incoming email and create or update records in a specified table, such as the 'Request' table. This is the standard mechanism for turning an email into a ServiceNow record.

Exam trap

The trap here is that candidates confuse 'Inbound Email Action' with 'Inbound Email Script' because both involve scripting, but the Action is the correct component for declarative field mapping and record creation, while the Script is a more manual, lower-level option that is not the standard approach for this use case.

How to eliminate wrong answers

Option B (Email Account) is wrong because an Email Account only configures the connection to an email server (e.g., POP3, IMAP, SMTP) and defines the mailbox to monitor; it does not define field mappings or record creation logic. Option C (Inbound Email Script) is wrong because while it can process incoming emails, it is a lower-level scripting tool that requires manual parsing and record creation, whereas an Inbound Email Action provides a structured, declarative way to map email fields to table fields without custom scripting. Option D (Email Notification) is wrong because it is used to send outbound emails (e.g., alerts, updates) and has no role in processing incoming email or creating records.

Practice this question →
3
Multi-Selectmedium

Which THREE of the following are valid components of the ServiceNow IntegrationHub?

Select 3 answers
A.Action steps
B.Spoke actions
C.REST Message
D.Data Source
E.Flow triggers
AnswersA, B, E

Action steps are individual steps within a spoke action.

Why this answer

Action steps are a core component of IntegrationHub, representing individual, reusable actions that can be composed into a flow to perform specific tasks, such as making API calls or transforming data. They are the building blocks that define the logic and operations within an IntegrationHub flow, enabling complex integrations without custom scripting.

Exam trap

The trap here is that candidates often confuse REST Message (a legacy tool for manual REST calls) with the modern IntegrationHub components, or mistake Data Source (a reporting element) as part of the integration framework, when in fact only Action steps, Spoke actions, and Flow triggers are valid IntegrationHub components.

Practice this question →
4
MCQhard

A global company is using ServiceNow for IT Service Management. They have an external asset management system that needs to update asset records in ServiceNow in real-time. The integration is implemented using REST API calls from the external system to ServiceNow. Recently, the integration started failing intermittently with HTTP 429 (Too Many Requests) errors. The external system is sending a high volume of update requests (up to 1000 per minute) to the /api/now/table/alm_asset endpoint. The administrator noticed that the instance performance is degraded during peak times. The company wants to resolve the 429 errors while ensuring data is updated as quickly as possible, but without overloading the instance. Which course of action should the administrator take?

A.Increase the API rate limit in the instance's system properties.
B.Reduce the number of requests from the external system to 500 per minute.
C.Implement a queue-based integration using Flow Designer to process updates asynchronously with a controlled rate.
D.Switch the authentication method from basic to OAuth to reduce overhead.
AnswerC

Queuing allows decoupling and rate control, preventing 429 errors.

Why this answer

Option C is correct because it addresses the root cause of the 429 errors—overwhelming the REST API endpoint with synchronous requests—by decoupling the external system from direct writes. Using Flow Designer with a queue (e.g., via the ServiceNow Queue or a custom table) allows the external system to submit requests asynchronously, and then a scheduled flow or script processes them at a controlled rate (e.g., using a rate limiter or batch size). This ensures data is updated as quickly as possible without exceeding the instance's API rate limits or degrading performance, as the processing is throttled server-side.

Exam trap

The trap here is that candidates often assume increasing rate limits (Option A) or reducing external request volume (Option B) are sufficient fixes, but they overlook the need for a controlled, asynchronous processing pattern to prevent instance degradation while maintaining near-real-time updates.

How to eliminate wrong answers

Option A is wrong because increasing the API rate limit in system properties does not solve the underlying performance degradation; it only raises the threshold for 429 errors, potentially allowing even more requests to hit the instance and worsen the overload. Option B is wrong because simply reducing the external system's request rate to 500 per minute is a manual, inflexible workaround that does not guarantee the instance can handle that volume without degradation, and it may still cause 429 errors if the instance's capacity is lower; it also fails to address the need for real-time updates. Option D is wrong because switching from basic to OAuth authentication reduces authentication overhead per request (e.g., no password hashing), but it does not reduce the number of requests or the load on the /api/now/table/alm_asset endpoint; the 429 errors are due to request volume, not authentication method.

Practice this question →
5
Multi-Selecthard

A ServiceNow instance needs to expose a REST API endpoint for external applications to query incident data. The developer creates a Scripted REST API and needs to ensure that only authorized applications can access it. Which THREE methods can be used to secure the Scripted REST API?

Select 3 answers
A.Require the request to include a valid ServiceNow username and password (Basic Authentication)
B.Require a valid SAML 2.0 assertion in the request body
C.Require a valid OAuth 2.0 access token in the Authorization header
D.Require a specific API key in the request header that is validated against an API Keys application
E.Require that the request originates from an IP address within a specified LDAP directory
AnswersA, C, D

Basic Auth is a built-in option for REST API security.

Why this answer

Option A is correct because ServiceNow supports HTTP Basic Authentication, which requires the request to include a valid ServiceNow username and password in the Authorization header. This is a standard method for securing Scripted REST APIs, as the platform validates credentials against its user table before processing the request.

Exam trap

The trap here is that candidates may confuse SAML 2.0 assertions (used for SSO) with API authentication mechanisms, or assume IP-based restrictions are a valid API security method in ServiceNow, when in fact only Basic Auth, OAuth 2.0, and API keys are supported for Scripted REST APIs.

Practice this question →
6
MCQmedium

An organization has a ServiceNow instance that integrates with a third-party monitoring tool using a webhook. The monitoring tool sends HTTP POST requests to a Scripted REST API in ServiceNow to create incidents automatically. Recently, the monitoring tool started sending duplicate requests due to a retry mechanism. The developer wants to ensure that duplicate incidents are not created. The Scripted REST API currently creates a new incident record for every request without checking for duplicates. The request payload includes a unique 'alert_id' field. The developer decides to implement idempotency logic. Which approach should the developer use to prevent duplicate incident creation?

A.In the Scripted REST API, use a GlideRecord to query the incident table with a condition on the 'alert_id' field before inserting a new record; if a record exists, skip creation and return the existing record's sys_id
B.Create a GlideAggregate script that counts incidents with the same 'alert_id'; proceed only if count is zero
C.Add a before-insert business rule on the incident table that checks for duplicates using the 'alert_id' field
D.Use a flow in Flow Designer triggered by the REST API that creates an incident only if the 'alert_id' is not already present in a custom table
AnswerA

This is the simplest and most effective idempotency check within the same API script.

Why this answer

Option A is correct because it implements idempotency directly within the Scripted REST API by querying the incident table using GlideRecord with a condition on the unique 'alert_id' field before inserting. If a record with that 'alert_id' already exists, the API skips creation and returns the existing sys_id, ensuring no duplicate incidents are created despite duplicate webhook requests.

Exam trap

The trap here is that candidates may choose Option C (business rule) thinking it centralizes duplicate logic, but they overlook that the business rule runs after the insert attempt, not before the API call, so it cannot prevent the duplicate request from being processed or the API from returning a success response for the duplicate.

How to eliminate wrong answers

Option B is wrong because GlideAggregate is designed for aggregation (e.g., SUM, COUNT) and is unnecessarily heavy for a simple existence check; a standard GlideRecord query with getRowCount() is more efficient and idiomatic. Option C is wrong because a before-insert business rule runs after the REST API has already initiated the insert operation, meaning the duplicate record may still be partially processed or cause a rollback, and it does not prevent the initial API call from consuming resources or returning an error. Option D is wrong because using a Flow Designer flow triggered by the REST API adds unnecessary complexity and latency; the idempotency check should be performed synchronously within the Scripted REST API script itself to maintain atomicity and avoid race conditions.

Practice this question →
7
MCQmedium

Refer to the exhibit. A developer is making a REST API call to create an incident. The call returns a 201 Created response, but the incident record is not visible in the instance. What is the most likely cause?

A.The 'caller_id' sys_id is invalid or points to a non-existent user.
B.The request method should be PUT instead of POST.
C.The field 'short_description' is misspelled.
D.The instance has an ACL that prevents creating incidents via REST.
AnswerA

An invalid sys_id can cause the record to be created without proper assignment, possibly hidden.

Why this answer

A 201 Created response indicates the REST API call was syntactically correct and the server accepted the payload, but the incident record is not visible. The most likely cause is an invalid caller_id sys_id, because ServiceNow validates the caller_id field against the sys_user table during record creation. If the sys_id does not exist or is malformed, the record is created but the caller_id reference fails silently, often causing the record to be hidden from standard views or filtered out by default queries.

Exam trap

The trap here is that candidates assume a 201 Created response guarantees the record is fully functional and visible, but ServiceNow's reference validation can silently fail, leaving the record orphaned and hidden from standard views.

How to eliminate wrong answers

Option B is wrong because PUT is used for updates or upserts, not for creating new records; POST is the correct HTTP method for creating a new incident via REST API. Option C is wrong because a misspelled field name like 'short_description' would cause a 400 Bad Request or a field validation error, not a 201 Created response. Option D is wrong because if an ACL prevented creating incidents via REST, the API call would return a 403 Forbidden or 401 Unauthorized error, not a 201 Created.

Practice this question →
8
MCQhard

A developer is implementing a custom integration using the ServiceNow REST API Explorer. The endpoint requires an API key in the header. Which approach should be used to secure the API key?

A.Create an authentication profile of type 'API Key' and reference it in the REST message.
B.Hardcode the API key in the script.
C.Store the API key in a system property encrypted.
D.Use a REST message variable and set the header directly.
AnswerA

Auth profiles securely store credentials and can be referenced without exposing the key.

Why this answer

Option A is correct because the ServiceNow REST API Explorer and REST messages support authentication profiles, which securely store and manage API keys. By creating an 'API Key' authentication profile and referencing it in the REST message, the API key is automatically injected into the request header without exposing it in scripts or system properties. This approach follows ServiceNow best practices for credential management and ensures the key is encrypted and centrally managed.

Exam trap

The trap here is that candidates may think storing the API key in an encrypted system property (Option C) is sufficient, but they overlook that the key still needs to be retrieved and injected into the header via script, which is less secure and not the recommended ServiceNow pattern for REST message integrations.

How to eliminate wrong answers

Option B is wrong because hardcoding the API key in a script exposes it in plain text within the application code, violating security best practices and making it difficult to rotate or audit. Option C is wrong because storing the API key in an encrypted system property still requires the script to retrieve and inject it into the header manually, which is less secure and more error-prone than using a dedicated authentication profile. Option D is wrong because using a REST message variable and setting the header directly in the script bypasses the built-in authentication profile framework, leading to potential exposure of the key in script logs or code reviews.

Practice this question →
9
MCQmedium

Refer to the exhibit. An IntegrationHub flow using this REST step is failing with a 401 error. What is the most likely cause?

A.The MID Server is not configured with the username and password variables.
B.The endpoint URL is incorrect.
C.The authentication type should be OAuth 2.0.
D.The Content-Type header should be text/plain.
AnswerA

The variables must be defined in the MID Server's configuration file; otherwise, they resolve to empty.

Why this answer

The 401 error indicates an authentication failure. In IntegrationHub, when a REST step uses a MID Server, the MID Server must have the necessary credentials (username and password) stored as variables in its configuration to authenticate with the target endpoint. If these variables are missing or misconfigured, the MID Server cannot supply valid credentials, resulting in a 401 error.

Exam trap

The trap here is that candidates often assume a 401 error always points to an incorrect endpoint or authentication type, rather than recognizing that MID Server credential variables must be explicitly configured for MID Server-based integrations.

How to eliminate wrong answers

Option B is wrong because an incorrect endpoint URL would typically result in a 404 (Not Found) or connection timeout, not a 401 (Unauthorized) error, which specifically indicates an authentication issue. Option C is wrong because the question does not specify that the endpoint requires OAuth 2.0; the existing authentication type (e.g., Basic Auth) could be correct if the credentials are properly configured. Option D is wrong because the Content-Type header being text/plain would cause a data format mismatch or 415 Unsupported Media Type error, not a 401 authentication error.

Practice this question →
10
MCQeasy

A ServiceNow administrator is configuring Single Sign-On (SSO) using SAML 2.0 with a corporate identity provider. Users report that after authenticating, they are redirected back to ServiceNow but see an error: 'Unable to process SAML response. Invalid user.' The administrator checks the SSO log and sees the message: 'No user found with username: [user@company.com]'. The username format in the SAML assertion is userPrincipalName (e.g., user@company.com). ServiceNow user records use the 'User ID' field (e.g., 'user'). What configuration change should the administrator make to resolve this issue?

A.Change the 'NameID format' from 'Unspecified' to 'EmailAddress' in the SAML2 configuration
B.Create an LDAP integration to automatically create ServiceNow users from the identity provider
C.Update all ServiceNow user records to have the 'User ID' field populated as full email addresses
D.Set the 'User Field' property to 'User ID' in the SAML2 configuration to match users based on their User ID
AnswerD

This determines which ServiceNow field is used for lookup; currently it likely defaults to 'User ID' but if set incorrectly, it may fail.

Why this answer

Option D is correct because the SAML assertion contains the userPrincipalName (user@company.com), but ServiceNow's default user matching field is the 'User ID' field, which stores only the username (e.g., 'user'). By setting the 'User Field' property to 'User ID' in the SAML2 configuration, ServiceNow will extract the username portion from the NameID (or a custom attribute) and match it against the 'User ID' field, resolving the mismatch. This avoids the need to change user records or the NameID format.

Exam trap

The trap here is that candidates often assume the NameID format (e.g., EmailAddress) must match the user record field, when in fact the 'User Field' property controls the mapping, and the NameID format only affects how the IdP sends the identifier.

How to eliminate wrong answers

Option A is wrong because changing the NameID format from 'Unspecified' to 'EmailAddress' only tells the IdP how to format the NameID in the SAML assertion; it does not change how ServiceNow maps the incoming identifier to a user record. The error is about field mapping, not NameID format. Option B is wrong because creating an LDAP integration would automate user provisioning, but it does not fix the immediate mapping issue; the administrator needs to configure the SAML2 mapping to match existing users, not create new ones.

Option C is wrong because updating all User ID fields to full email addresses would be a workaround that changes the user database schema unnecessarily; the proper fix is to configure the SAML2 mapping to extract the correct portion of the identifier.

Practice this question →
11
MCQhard

A ServiceNow instance is configured to use LDAP for user authentication and role membership. After a recent LDAP schema change, users can authenticate but some users are missing their assigned roles. The LDAP server is returning all attributes correctly. What is the most likely cause of this issue?

A.The 'LDAP Group DN' format in the LDAP server configuration does not match the new schema
B.The LDAP server's base DN for user search has changed
C.The 'Use secure connection' checkbox is unchecked in the LDAP configuration
D.The LDAP server is not returning the 'memberOf' attribute for users
AnswerA

Role mapping uses LDAP groups; if the DN format changed, groups won't be found, so roles are not applied.

Why this answer

The correct answer is A because the LDAP Group DN format defines how ServiceNow maps LDAP groups to roles. After a schema change, if the DN structure for groups has been altered (e.g., OU names changed), the stored format in the LDAP server configuration will no longer match, causing role membership to fail even though user authentication (which uses a separate base DN and filter) still works. The LDAP server returning all attributes correctly confirms the issue is in the mapping configuration, not in data retrieval.

Exam trap

The trap here is that candidates confuse a missing 'memberOf' attribute with a Group DN format mismatch, but the question explicitly states all attributes are returned correctly, so the issue must be in how ServiceNow constructs the group search filter, not in the data itself.

How to eliminate wrong answers

Option B is wrong because if the base DN for user search had changed, users would not be able to authenticate at all, but the question states users can authenticate. Option C is wrong because the 'Use secure connection' checkbox affects the encryption of the LDAP connection, not the mapping of group DNs to roles; authentication is working, so connectivity is fine. Option D is wrong because the question explicitly states the LDAP server is returning all attributes correctly, which includes the 'memberOf' attribute if it exists; the issue is that the Group DN format in ServiceNow does not match the new schema, not that the attribute is missing.

Practice this question →
12
MCQhard

A ServiceNow instance integrates with an external inventory system via a scheduled REST import job. Recently, the import started failing intermittently with HTTP 429 (Too Many Requests) errors. The external system enforces a rate limit of 100 requests per minute. The existing job pulls 1500 records at a time using a single REST message. Which design change would best resolve this issue while ensuring the import completes successfully?

A.Reduce the batch size to 50 records and add a 1-second delay between consecutive REST calls
B.Increase the number of threads in the import set table loader to process records faster
C.Increase the batch size to 5000 records per request to reduce the number of calls
D.Switch the REST message to use Basic Authentication instead of OAuth to reduce overhead
AnswerA

This stays within the 100 requests/min limit (50 requests with 1s delay = 50 requests/min) and ensures all data is imported.

Why this answer

Option A is correct because reducing the batch size to 50 records ensures that each REST call stays within the external system's rate limit of 100 requests per minute. Adding a 1-second delay between consecutive calls further prevents bursts that could trigger HTTP 429 errors, while still allowing the import to complete by making multiple smaller requests over time.

Exam trap

The trap here is that candidates often assume increasing batch size or thread count will improve throughput, but in rate-limited scenarios, reducing concurrency and pacing requests is the correct approach to avoid HTTP 429 errors.

How to eliminate wrong answers

Option B is wrong because increasing the number of threads in the import set table loader would increase concurrency, potentially sending more requests simultaneously and worsening the rate-limit issue. Option C is wrong because increasing the batch size to 5000 records per request would likely exceed the external system's payload limits or timeout thresholds, and does not address the rate limit of 100 requests per minute. Option D is wrong because switching from OAuth to Basic Authentication does not reduce the number of requests or the rate at which they are sent; authentication method has no impact on HTTP 429 errors caused by rate limiting.

Practice this question →
13
MCQeasy

An administrator wants to enable inbound email integration to automatically create incidents from emails sent to support@company.com. What is the first step in configuring this?

A.Enable the Email Integration plugin.
B.Configure an email account (mailbox) to receive emails.
C.Create an inbound email action.
D.Create an ACL to allow email processing.
AnswerB

The first step is to set up an email account (mailbox) to receive emails, then create inbound actions.

Why this answer

The first step in configuring inbound email integration is to set up an email account (mailbox) that the instance can connect to and retrieve emails from. Without a configured mailbox, the instance has no source from which to pull incoming messages, making subsequent steps like creating inbound email actions or enabling plugins meaningless. This mailbox configuration defines the IMAP or POP3 server, credentials, and folder settings that the platform uses to poll for new emails.

Exam trap

ServiceNow often tests the order of operations in configuration workflows, and the trap here is that candidates think enabling a plugin or creating an action is the first step, when in reality the mailbox must be configured first to provide the source of emails.

How to eliminate wrong answers

Option A is wrong because the Email Integration plugin is not a separate plugin that needs enabling; inbound email functionality is built into the base platform and is available by default. Option C is wrong because an inbound email action defines how to process an email after it has been retrieved, but it cannot be created or used until a mailbox is configured to receive the emails. Option D is wrong because ACLs control access to records and tables, not the ability to process incoming emails; email processing is governed by system properties and the mailbox configuration, not by ACLs.

Practice this question →
14
MCQhard

A ServiceNow instance is being integrated with an external HR system using a SOAP message. The SOAP call is failing intermittently. The developer notices that the XML payload contains special characters like '&' and '<'. What is the best practice to handle these characters in SOAP messages?

A.Wrap the payload in a CDATA section.
B.Encode the entire payload in Base64.
C.Use URL encoding for the payload.
D.Escape the characters using XML entities (e.g., &amp; for &).
AnswerD

Escaping special characters ensures well-formed XML and is the standard practice.

Why this answer

SOAP messages are XML-based, and special characters like '&' and '<' must be escaped using XML entities (e.g., &amp; for &, &lt; for <) to maintain valid XML syntax. This ensures the XML parser correctly interprets the payload without breaking the message structure, which is the standard practice per the XML specification and SOAP protocol.

Exam trap

The trap here is that candidates often confuse XML escaping with other encoding methods (like CDATA or URL encoding) and assume CDATA is a catch-all solution, but the exam tests the precise XML standard for handling special characters within SOAP message bodies.

How to eliminate wrong answers

Option A is wrong because CDATA sections are used to mark blocks of text that should not be parsed as XML, but they are not the best practice for escaping individual special characters within SOAP payloads; they can cause issues with XML validation and are not universally supported in all SOAP implementations. Option B is wrong because Base64 encoding would convert the entire payload to a binary-safe string, but it would require the receiver to decode it, adding unnecessary complexity and violating the SOAP standard for human-readable XML messages. Option C is wrong because URL encoding (percent-encoding) is designed for query strings in URLs, not for XML content; it would not produce valid XML and would likely cause parsing errors in the SOAP handler.

Practice this question →
15
MCQmedium

A company is using a MID Server to run a discovery probe. The probe fails with a timeout error. The developer checks the MID Server logs and sees 'Connection refused'. What is the most likely issue?

A.The MID Server credentials are incorrect.
B.The MID Server's SSL certificate is expired.
C.The target host's firewall is blocking the port used by the probe.
D.The target host is unreachable from the MID Server network.
AnswerC

Connection refused indicates the TCP connection was rejected, often due to firewall or service not running.

Why this answer

The 'Connection refused' error in the MID Server logs indicates that the target host actively rejected the connection attempt on the specified port. This is most commonly caused by a firewall on the target host blocking the port used by the discovery probe, as the firewall sends a TCP RST packet to refuse the connection. Incorrect credentials would result in an authentication failure, not a connection refusal, and an unreachable host would produce a 'No route to host' or timeout error.

Exam trap

The trap here is that candidates often confuse 'Connection refused' with 'Host unreachable' or 'Timeout', but Cisco tests the distinction that a firewall actively blocking a port sends a TCP RST (refused), while a network-level block or host down results in a timeout or ICMP unreachable.

How to eliminate wrong answers

Option A is wrong because incorrect MID Server credentials would cause an authentication failure (e.g., 'Invalid credentials' or 'Access denied'), not a TCP-level 'Connection refused' error. Option B is wrong because an expired SSL certificate would cause a TLS handshake failure (e.g., 'certificate expired' or 'SSL error'), not a raw socket connection refusal. Option D is wrong because if the target host were unreachable from the MID Server network, the error would be 'No route to host' or 'Host unreachable' (ICMP unreachable), not a TCP RST-based 'Connection refused'.

Practice this question →
16
Multi-Selectmedium

Which TWO actions are valid for handling errors in a Flow Designer integration action? (Choose two.)

Select 2 answers
A.Configure the action to log error details to a local log table.
B.Use an 'if' condition to check the HTTP status and branch accordingly.
C.Return a specific error code as a flow variable.
D.Send an email notification to the system administrator using a notification action.
E.Set the action to automatically retry on failure without configuration.
AnswersA, B

Logging errors to a table is a common pattern.

Why this answer

Correct: B and C. Flow Designer allows writing to a log table and sending an email. Option A does not exist as standard output.

Option D is for conditions, not error handling. Option E is manual.

Practice this question →
17
Drag & Dropmedium

Drag and drop the steps to create a new Scheduled Job 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 Scheduled Jobs, create new, set name and type, define schedule, write script/select report, and submit.

Practice this question →
18
MCQhard

A company has developed a custom Scripted REST API endpoint that processes incoming orders and then makes synchronous outbound REST calls to an external shipping system for validation. During testing with low concurrency, the endpoint works correctly. However, in production with high concurrency, the endpoint frequently times out and returns 504 errors to the caller. The performance team has confirmed that the external shipping system is responsive and the network latency is acceptable. Which course of action should the development team take to resolve the timeout issue?

A.Deploy additional MID Servers to distribute the outbound call load.
B.Implement a caching layer to store shipping validation results and avoid repeated calls to the external system.
C.Increase the timeout value in the outbound REST Message record to accommodate peak loads.
D.Refactor the script to make asynchronous HTTP requests and process the shipping validation response using a separate queue or business rule.
AnswerD

Asynchronous requests free the script while waiting for the external response, allowing the instance to handle more concurrent requests without blocking.

Why this answer

The synchronous HTTP request blocks the script until the response is received. With high concurrency, this leads to thread starvation and timeouts. The best solution is to use asynchronous HTTP requests and handle the response via a queue or event mechanism, freeing the script to process other requests.

Practice this question →
19
MCQeasy

A ServiceNow developer is integrating with an external system using a REST message. The external system requires a custom header 'X-API-Key' to be included in every request. Where should the developer configure this header to ensure it is automatically included in all REST messages that call this endpoint?

A.In the 'Query Parameters' tab of the REST message definition
B.In the 'HTTP Headers' tab of the REST message definition
C.In the 'Authentication Profile' associated with the REST message
D.In the Scripted REST API used to create the endpoint
AnswerB

Correct: Custom headers are defined here and automatically included in every request.

Why this answer

Option B is correct because the 'HTTP Headers' tab in a REST message definition allows you to define custom headers that are automatically included in every request sent to that endpoint. This is the standard location for headers like 'X-API-Key' that must accompany all calls, as they are part of the HTTP request metadata, not query parameters or authentication credentials.

Exam trap

The trap here is that candidates confuse HTTP headers with query parameters or authentication profiles, assuming that custom API keys can be passed as query strings or handled by authentication mechanisms, when in fact they must be explicitly defined in the HTTP Headers tab of the REST message.

How to eliminate wrong answers

Option A is wrong because the 'Query Parameters' tab is for URL query string parameters (e.g., ?key=value), not HTTP headers; placing a header there would result in it being appended to the URL rather than sent as a header, causing the external system to reject the request. Option C is wrong because an 'Authentication Profile' is used for standard authentication methods (e.g., Basic Auth, OAuth) and is not designed to inject arbitrary custom headers; it would not include the 'X-API-Key' header unless the profile specifically supports custom header injection, which is not its intended purpose. Option D is wrong because a Scripted REST API defines the server-side endpoint that receives requests, not the client-side configuration for outbound REST messages; the developer is configuring the outbound call, not the endpoint itself.

Practice this question →
20
MCQeasy

A developer is creating a REST API endpoint in ServiceNow that must accept JSON payloads and return a response. Which method should be used to parse the incoming request body?

A.JSON.parse(request.body)

Why this answer

Option D is correct because request.body returns a string representation of the request body, which must be parsed using JSON.parse if it is JSON. Option A is incorrect because request.body.data is not a standard property. Option B is incorrect because dataString is not a property.

Option C is incorrect because bodyJSON is not a method.

Practice this question →
21
MCQmedium

A developer needs to create a flow in Flow Designer that sends an email to a manager when a high-priority incident is created. The flow should retrieve the manager's email from the caller's user record. Which data pill should be used to access the caller's manager's email in the 'Send Email' action?

A.{{trigger.caller.manager_record.email}}
B.{{trigger.caller.manager.email}}
C.{{trigger.caller.email}}
D.{{trigger.incident.caller.email}}
AnswerB

Correct dot-walking over the 'manager' reference field to the user record's email.

Why this answer

Option B is correct because in Flow Designer, the dot-walking syntax `trigger.caller.manager.email` navigates from the incident record's caller field to the user record, then to the manager reference field (which is a sys_user record), and finally retrieves the email attribute of that manager's user record. This directly accesses the caller's manager's email address without needing an intermediate lookup.

Exam trap

The trap here is that candidates often confuse the field name `manager` with a non-existent `manager_record` or mistakenly use `trigger.incident` instead of `trigger` directly, leading them to pick options that either reference an invalid field or retrieve the wrong user's email.

How to eliminate wrong answers

Option A is wrong because `manager_record` is not a valid field name on the sys_user table; the manager field is a reference field named `manager`, not `manager_record`. Option C is wrong because `trigger.caller.email` retrieves the caller's own email, not the manager's email. Option D is wrong because `trigger.incident.caller.email` uses an incorrect path (`incident` is not a direct child of `trigger` in this context; the correct starting point is `trigger.caller`), and it also retrieves the caller's email rather than the manager's.

Practice this question →
22
Multi-Selectmedium

A ServiceNow developer is building an integration using IntegrationHub to connect to a third-party system via REST. The system requires OAuth 2.0 with client credentials grant flow. Which TWO configurations are mandatory for setting up this integration in IntegrationHub?

Select 2 answers
A.OAuth server discovery URL (well-known endpoint)
B.Token request endpoint URL (e.g., https://example.com/oauth/token)
C.Base64 encoding of the client secret
D.Username and password for user impersonation
E.OAuth client ID and client secret from the third-party system
AnswersB, E

Required to obtain an access token.

Why this answer

Option B is correct because the client credentials grant flow requires a direct token request endpoint URL where the client sends its credentials (client ID and secret) to obtain an access token. IntegrationHub must be configured with this specific endpoint to complete the OAuth 2.0 handshake, as the grant type does not involve user interaction or discovery endpoints.

Exam trap

ServiceNow often tests the distinction between mandatory and optional OAuth 2.0 configurations, and the trap here is that candidates mistakenly think the well-known discovery URL or Base64 encoding is required, when in fact the client credentials flow only needs the token endpoint and the client credentials themselves.

Practice this question →
23
Multi-Selecteasy

Which TWO of the following are valid authentication options for a Scripted REST API in ServiceNow?

Select 2 answers
A.JWT
B.Basic Auth
C.API Key
D.SAML 2.0
E.OAuth 2.0
AnswersB, E

Basic Auth is a supported authentication option for Scripted REST APIs.

Why this answer

Basic Auth is a valid authentication option for Scripted REST APIs in ServiceNow because it allows the API to authenticate requests using a username and password pair encoded in the Authorization header. ServiceNow natively supports Basic Auth for inbound REST calls, making it a straightforward choice for legacy or simple integrations.

Exam trap

ServiceNow often tests the misconception that JWT or API Key are native authentication options for Scripted REST APIs, when in fact ServiceNow only supports Basic Auth and OAuth 2.0 as built-in choices for this specific API type.

Practice this question →
24
MCQhard

Refer to the exhibit. A developer created this Script Include to be used as a REST API endpoint. However, when calling the API, the response is empty. What is the most likely reason?

A.The Script Include is not marked as 'Client callable'.
B.The function name 'getOpenIncidents' is not exposed.
C.The GlideRecord query returns no results.
D.The Script Include is not marked as 'REST API endpoint' or does not extend the appropriate class.
AnswerD

For REST API, the Script Include must extend 'AbstractAjaxProcessor' and be marked as 'script' for REST, but the exhibit shows it extends AbstractAjaxProcessor, which is correct for GlideAjax, not for REST. Actually, for REST, you need to use 'Scripted REST API' or 'RESTMessage'? Wait, the exhibit shows it extends AbstractAjaxProcessor, which is used for GlideAjax, not for REST API. So the correct answer is that it should be a Scripted REST API instead. But Option B says 'not marked as REST API endpoint' which is the key: it should be a Scripted REST API, not a Script Include. So B is correct.

Why this answer

Option D is correct because a Script Include used as a REST API endpoint must either extend the appropriate class (such as 'RESTAPI' or 'RESTAPIV2') or be explicitly marked as a REST API endpoint in its definition. Without this, the platform does not recognize it as a valid endpoint, resulting in an empty response when the API is called.

Exam trap

ServiceNow often tests the misconception that any Script Include can serve as a REST API endpoint if it contains a function, when in reality it must extend the appropriate class or be explicitly marked as a REST API endpoint to be recognized by the platform.

How to eliminate wrong answers

Option A is wrong because 'Client callable' is a property that allows a Script Include to be invoked from client-side scripts (e.g., client scripts or UI policies), but it is not required for REST API endpoints; REST API Script Includes are server-side and do not need this flag. Option B is wrong because the function name 'getOpenIncidents' does not need to be explicitly exposed; REST API Script Includes use a specific method signature (e.g., get() or post()) that the platform automatically routes to based on the HTTP method, not arbitrary function names. Option C is wrong because an empty GlideRecord query would return an empty array or object, not an empty response; the response being empty (no JSON body at all) indicates the endpoint itself is not being reached, not that the query returned no results.

Practice this question →
25
MCQmedium

A developer is building a REST API endpoint in ServiceNow to return data from the 'incident' table. The API should only return incidents assigned to the caller. Which method should be used to filter the records based on the caller's user ID?

A.Use the 'sysparm_display_value' parameter.
B.Use the 'sysparm_query' parameter with an encoded query.
C.Use the 'sysparm_limit' parameter to limit results.
D.Use the 'sysparm_fields' parameter to specify fields.
AnswerB

sysparm_query allows filtering using encoded queries.

Why this answer

Option B is correct because the 'sysparm_query' parameter allows you to pass an encoded query string to filter records in a REST API endpoint. By specifying a query like 'assigned_to=javascript:gs.getUserID()' or using the caller's sys_id directly, you can restrict the incident records returned to only those assigned to the caller. This is the standard method for applying dynamic filters in ServiceNow REST API calls.

Exam trap

ServiceNow often tests the distinction between parameters that filter records (sysparm_query) versus those that control output format or field selection, leading candidates to confuse display or field parameters with filtering capabilities.

How to eliminate wrong answers

Option A is wrong because 'sysparm_display_value' controls whether field values are returned as display values or database values, not how records are filtered. Option C is wrong because 'sysparm_limit' restricts the number of records returned but does not filter which records are included based on caller identity. Option D is wrong because 'sysparm_fields' specifies which fields to include in the response, not a condition to filter records.

Practice this question →
26
MCQeasy

A developer needs to import CSV data into a custom table using Import Sets. The data contains a reference field to a user record. Which configuration ensures that the user record is correctly matched?

A.Set the target field 'email' as coalesce on the transform map.
B.Set the source field as coalesce on the transform map.
C.Configure the import set row to be ignored if the user is not found.
D.Use a script in the 'on before' transform script to find the user.
AnswerA

Using a unique identifier like email as coalesce ensures proper matching.

Why this answer

Option A is correct because setting the 'email' field as a coalesce field on the transform map tells the Import Set engine to use that field to match incoming records against existing target table records. When the reference field points to a user record, the coalesce field (e.g., email) is used to look up the sys_user table and automatically populate the correct sys_id, ensuring the reference is properly resolved without manual scripting.

Exam trap

The trap here is that candidates often confuse 'coalesce' with a field that must be set on the source field (Option B) or think that a script is always required for reference resolution (Option D), when in fact the coalesce field is a declarative, target-side configuration that handles matching automatically.

How to eliminate wrong answers

Option B is wrong because setting the source field as coalesce would attempt to match on the raw source value (e.g., a CSV column name) rather than the target field value, which does not help resolve the reference to the user record. Option C is wrong because ignoring the row if the user is not found would skip the record entirely, preventing any import or error handling, rather than matching or creating the user. Option D is wrong because while an 'on before' script could find the user, it is not the standard or recommended configuration; coalesce fields provide a declarative, no-code solution that is more efficient and maintainable.

Practice this question →
27
Matchingmedium

Match each ServiceNow REST API method to its CRUD equivalent.

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

Concepts
Matches

Read

Create

Update (full replacement)

Update (partial)

Delete

Why these pairings

Standard REST methods map to CRUD operations.

Practice this question →
28
MCQmedium

An organization uses ServiceNow with an external identity provider (IdP) for single sign-on (SSO). Users report that they cannot log in via SSO, but direct username/password login still works. The ServiceNow administrator checks the SAML2 configuration and sees that the 'Validate AuthnResponse Signature' checkbox is enabled and the 'X.509 Certificate' field is filled. What is the most likely cause of the SSO failure?

A.The 'Account lockout after invalid attempts' property is set too low
B.The 'Single Sign-On (SSO)' module is disabled in the ServiceNow application menu
C.The IdP's signing certificate has been rotated, but the new certificate is not uploaded to ServiceNow
D.The 'AuthnRequest Signed' checkbox is not enabled in the SAML2 configuration
AnswerC

If the IdP signs the response with a new certificate, ServiceNow will fail to validate the signature.

Why this answer

The most likely cause is that the IdP's signing certificate has been rotated, but the new certificate is not uploaded to ServiceNow. When 'Validate AuthnResponse Signature' is enabled, ServiceNow uses the uploaded X.509 certificate to verify the SAML assertion signature. If the IdP signs responses with a new certificate that ServiceNow does not have, signature validation fails, blocking SSO login while direct username/password login remains unaffected.

Exam trap

ServiceNow often tests the distinction between request signing and response signing, leading candidates to incorrectly select 'AuthnRequest Signed' (Option D) when the real issue is the IdP's response certificate mismatch.

How to eliminate wrong answers

Option A is wrong because account lockout after invalid attempts would affect both SSO and direct login equally, not just SSO, and the symptom is that direct login still works. Option B is wrong because disabling the 'Single Sign-On (SSO)' module in the application menu would prevent SSO configuration from being accessible, but the SAML2 configuration is already present and the issue is signature validation, not module visibility. Option D is wrong because 'AuthnRequest Signed' controls whether ServiceNow signs the authentication request sent to the IdP; this is not required for validating the IdP's response signature, and the reported symptom points to response validation failure, not request signing.

Practice this question →
29
MCQhard

A company uses ServiceNow to manage IT assets. An integration sends asset data from an external CMDB to ServiceNow via REST API. The external system sends a payload that includes the asset's serial number, location, and status. The developer has created a Scripted REST API to receive this data. However, when testing, the external system receives an HTTP 500 error. The developer inspects the script log and sees the error: 'java.lang.NullPointerException' at line 10 of the script. The script uses the GlideRecord API to query for an existing asset by serial number. The relevant code is: var gr = new GlideRecord('alm_asset'); gr.get('serial_number', request.body.serial); What is the most likely cause of the NullPointerException?

A.The 'serial_number' field in the 'alm_asset' table does not exist or is misspelled
B.The GlideRecord.get() method is incorrectly used; it should be gr.get('serial_number') without the value
C.The request body is not being parsed; 'request.body' is null because the content type is not set to JSON or the API is not expecting a body
D.The external system is sending the serial number as part of the URL instead of the request body
AnswerC

If the API does not parse the body, request.body remains null, causing a NullPointerException when accessing .serial.

Why this answer

Option C is correct because the NullPointerException occurs when trying to access a property of a null object. In this case, `request.body` is null, meaning the request body was not parsed into a JavaScript object. This typically happens when the Content-Type header is not set to `application/json` or the Scripted REST API endpoint is not configured to expect a request body, so `request.body.serial` evaluates to `null.serial`, causing the exception.

Exam trap

The trap here is that candidates often assume the NullPointerException is due to a field name typo or incorrect GlideRecord usage, but the real issue is that `request.body` is null because the request body was not parsed, which is a subtle but critical detail about REST API request handling in ServiceNow.

How to eliminate wrong answers

Option A is wrong because a misspelled or non-existent field name would throw a ScriptException or return an empty GlideRecord, not a NullPointerException at line 10. Option B is wrong because `gr.get('serial_number', value)` is the correct syntax for querying by field and value; using `gr.get('serial_number')` without a value would query by sys_id, not by serial number. Option D is wrong because even if the serial number were sent in the URL, the error is specifically about `request.body` being null, not about missing URL parameters.

Practice this question →
30
MCQhard

A company is integrating ServiceNow with an external system using a custom SOAP web service. The external system requires WS-Security with a username token and a timestamp. How should the developer configure this?

A.Use a RESTMessageV2 with Basic Authentication.
B.Add the username and password to the SOAP message's HTTP headers.
C.Configure the WS-Security tab under the SOAP Message record with UsernameToken and timestamp.
D.Set the SOAP action header to include the token.
AnswerC

The SOAP Message record has dedicated WS-Security settings.

Why this answer

Option C is correct because ServiceNow's SOAP Message record includes a dedicated WS-Security tab where you can configure UsernameToken and timestamp elements to meet WS-Security requirements. This allows the platform to generate the proper SOAP envelope headers with the security token and timestamp, which the external system expects for authentication and message freshness validation.

Exam trap

The trap here is that candidates confuse HTTP-level authentication (like Basic Auth in headers) with WS-Security, which requires security tokens to be embedded inside the SOAP envelope itself, not in transport-level headers.

How to eliminate wrong answers

Option A is wrong because RESTMessageV2 is used for RESTful services, not SOAP, and Basic Authentication does not implement WS-Security standards. Option B is wrong because adding credentials to HTTP headers is not part of the WS-Security specification; WS-Security requires the token to be embedded within the SOAP envelope's <wsse:Security> header, not in HTTP headers. Option D is wrong because the SOAP action header is used to specify the operation being invoked (e.g., via SOAPAction), not to carry security tokens; tokens must be placed in the WS-Security header of the SOAP message.

Practice this question →
31
MCQmedium

A developer needs to invoke a third-party SOAP web service from a business rule. The WSDL is imported and the SOAP message is created. What is the correct way to send the request?

A.Create a SOAPMessage object and use the send() method.
B.Use the XMLDocument object to parse the response only.
C.Use a GlideRecord insert to write the SOAP envelope to a table.
D.Use the RESTMessageV2 object to send the request as a POST.
AnswerA

SOAPMessage's send() method properly sends the SOAP request and returns a SOAPResponse.

Why this answer

Option A is correct because the SOAPMessage object, part of the javax.xml.soap API, provides a send() method that handles the entire SOAP request-response cycle over HTTP. This method automatically marshals the SOAP message, sends it to the endpoint defined in the WSDL, and returns the response as a SOAPMessage object, making it the appropriate choice for invoking a SOAP web service from a business rule.

Exam trap

ServiceNow often tests the distinction between SOAP and REST integration methods, and the trap here is that candidates mistakenly choose RESTMessageV2 (Option D) because they assume any HTTP POST can handle SOAP, ignoring that SOAP requires a dedicated API to manage the SOAP envelope, headers, and fault handling properly.

How to eliminate wrong answers

Option B is wrong because XMLDocument is used for parsing XML responses, not for sending SOAP requests; it lacks the capability to transmit the SOAP envelope over HTTP. Option C is wrong because GlideRecord is a database manipulation class for ServiceNow tables and cannot send HTTP requests or handle SOAP message transmission. Option D is wrong because RESTMessageV2 is designed for RESTful web services using JSON/XML over HTTP, not for SOAP web services which require SOAP-specific headers and envelope handling; using it would require manually constructing the SOAP envelope and managing SOAP-specific faults.

Practice this question →
32
MCQmedium

A company is integrating ServiceNow with an external system using REST API. The integration is failing with a 401 Unauthorized error. The integration user's credentials are correct and the user has the 'rest_service' role. What is the most likely cause of the failure?

A.The password for the integration user does not meet complexity requirements.
B.The integration user does not have the 'rest_api' role.
C.The OAuth token used for authentication has expired or is invalid.
D.The integration is hitting a table ACL that denies read access.
AnswerC

401 Unauthorized indicates authentication failure; expired/invalid OAuth token is a common cause.

Why this answer

A 401 Unauthorized error indicates that the request lacks valid authentication credentials. Since the integration user's credentials are correct and the user has the 'rest_service' role, the most likely cause is that the OAuth token used for authentication has expired or is invalid. ServiceNow REST API integrations commonly use OAuth 2.0 tokens, which have a finite lifetime and must be refreshed or reissued upon expiration.

Exam trap

The trap here is confusing 401 Unauthorized with 403 Forbidden; candidates often attribute authentication failures to role or ACL issues, but 401 specifically points to missing or invalid credentials, not insufficient permissions.

How to eliminate wrong answers

Option A is wrong because password complexity requirements do not cause a 401 error; they affect password creation or reset, not authentication with an already-valid credential. Option B is wrong because the 'rest_api' role does not exist in ServiceNow; the correct role for REST API access is 'rest_service', which the user already has. Option D is wrong because table ACLs denying read access would result in a 403 Forbidden error, not a 401 Unauthorized error, as ACLs control authorization after authentication succeeds.

Practice this question →
33
MCQeasy

A ServiceNow instance needs to synchronize data with an external SQL database nightly. Which integration method is most appropriate?

A.Use a REST API exposed by the external database.
B.Use a MID Server with a JDBC data source.
C.Use a SOAP web service with a MID Server.
D.Use an email-based integration to send CSV files.
AnswerB

JDBC provides direct database connectivity through the MID Server.

Why this answer

A MID Server with a JDBC data source is the most appropriate method for nightly batch synchronization with an external SQL database because JDBC provides a direct, efficient, and secure database-level connection without requiring the external database to expose a web service or API. The MID Server acts as a secure proxy, allowing the ServiceNow instance to execute SQL queries against the external database over a persistent, encrypted connection, which is ideal for scheduled bulk data transfers.

Exam trap

The trap here is that candidates often assume REST APIs are the universal integration method, but for direct SQL database synchronization, JDBC via a MID Server is the native and most efficient approach, while REST would require an additional middleware layer that the external database likely does not provide.

How to eliminate wrong answers

Option A is wrong because using a REST API exposed by the external database would require the database to have a custom REST layer, which is not a standard feature of most SQL databases and adds unnecessary complexity and overhead for a simple nightly batch sync; REST APIs are better suited for real-time, granular operations. Option C is wrong because a SOAP web service with a MID Server is over-engineered for this scenario—SOAP is heavyweight, requires WSDL definitions, and is typically used for complex transactional integrations, not for straightforward nightly SQL data pulls. Option D is wrong because an email-based integration sending CSV files is unreliable for scheduled data synchronization due to lack of guaranteed delivery, file size limits, and no built-in error handling or retry mechanisms, making it unsuitable for production data syncs.

Practice this question →
34
Drag & Dropmedium

Drag and drop the steps to create a new table 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 order is: navigate to tables, click new, define table properties, set attributes, then submit.

Practice this question →
35
Multi-Selecthard

Which TWO of the following are valid methods to authenticate a REST API call to ServiceNow?

Select 2 answers
A.SAML assertion authentication.
B.LDAP authentication.
C.Basic Authentication with username and password.
D.API Key authentication.
E.OAuth 2.0 authentication.
AnswersC, E

Basic Authentication is supported.

Why this answer

Option C is correct because ServiceNow supports Basic Authentication, where the REST API call includes an HTTP Authorization header with a Base64-encoded string of 'username:password'. This is a straightforward method for authenticating API requests, though it requires HTTPS to avoid exposing credentials in plaintext.

Exam trap

The trap here is that candidates may confuse authentication methods supported for the UI (like SAML or LDAP) with those valid for REST API calls, or mistakenly think ServiceNow supports API keys when it does not.

Practice this question →
36
MCQhard

A ServiceNow instance has a custom table 'u_integration_log' that stores integration transactions. A flow in Flow Designer logs errors by creating records in this table. The flow is running with high volume, and the table is growing quickly causing performance issues. What is the best design to mitigate this?

A.Configure a scheduled job to archive and delete records older than 30 days.
B.Disable error logging in the flow.
C.Use a 'Log to file' action in the flow instead of a table.
D.Store logs in a separate instance via MID Server.
AnswerA

Regular cleanup balances data retention with performance.

Why this answer

Option A is correct because it directly addresses the root cause of performance degradation—uncontrolled table growth—by implementing a scheduled job to archive and delete records older than 30 days. This reduces table size, improves query performance, and maintains the ability to retain recent logs for debugging. In ServiceNow, scheduled jobs can use GlideRecord to delete records based on a date condition, and archiving can be done via export to CSV or a separate archive table.

Exam trap

The trap here is that candidates may choose Option B (disable logging) thinking it's a quick fix, but the exam tests understanding that logging is essential for operations and that proper data lifecycle management (archiving/deletion) is the correct design pattern for high-volume tables.

How to eliminate wrong answers

Option B is wrong because disabling error logging entirely removes visibility into integration failures, which is critical for troubleshooting and monitoring; it does not solve the performance issue but instead eliminates the data needed for diagnostics. Option C is wrong because 'Log to file' action in Flow Designer writes to the instance's local file system, which is not a scalable or supported method for high-volume logging and does not provide the structured querying and retention capabilities of a table; it also does not address the underlying performance issue of table growth. Option D is wrong because storing logs in a separate instance via MID Server introduces unnecessary complexity, latency, and dependency on MID Server availability, and does not solve the immediate performance problem on the current instance; it is an over-engineered solution for simple log retention.

Practice this question →
37
MCQmedium

A developer is creating a REST API in ServiceNow to expose incident data. The API must return only incidents with 'state' = 2 (in progress) and limit results to 50. Which implementation is correct?

A.Use the ServiceNow table API with endpoint '/api/now/table/incident?state=2&sysparm_limit=50'.
B.In the script, use 'gr.addQuery('state', 2); gr.setLimit(50);' and return the records.
C.Use a REST API endpoint with path /api/incidents and set the query parameter 'sysparm_query=state=2' and 'sysparm_limit=50'.
D.In the script, use 'gr.get('state', 2)' and then limit via 'gr.setLimit(50)'.
AnswerB

This is the standard approach in a scripted REST API handler.

Why this answer

Option B is correct because it uses the standard GlideRecord pattern to query the incident table with an 'addQuery' filter for state=2 and 'setLimit' to restrict results to 50, which is the proper server-side approach when building a custom REST API endpoint in a Scripted REST API or similar. The other options misuse table API syntax or GlideRecord methods in ways that would not work as intended.

Exam trap

The trap here is confusing the built-in table API's parameter syntax (which requires 'sysparm_query' for filters) with the GlideRecord method syntax, and assuming that 'gr.get()' can be used to filter multiple records when it is designed for single-record retrieval by key.

How to eliminate wrong answers

Option A is wrong because the ServiceNow table API endpoint '/api/now/table/incident' does not accept a raw query parameter like 'state=2'; it requires the 'sysparm_query' parameter with an encoded query string (e.g., 'sysparm_query=state=2'). Option C is wrong because the path '/api/incidents' is not a valid ServiceNow REST API endpoint; the correct base path for table APIs is '/api/now/table/', and query parameters must be 'sysparm_query' and 'sysparm_limit', not 'sysparm_query=state=2' without proper encoding. Option D is wrong because 'gr.get('state', 2)' is used to retrieve a single record by sys_id or a unique key, not to filter a set of records; it would return only one record (if any) and ignore the limit.

Practice this question →
38
Matchingmedium

Match each ServiceNow feature to its primary service.

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

Concepts
Matches

Automation

Self-service portal

Conversational AI chatbot

Reporting and dashboards

CMDB population and maintenance

Why these pairings

Each feature belongs to a specific ServiceNow service or capability.

Practice this question →
39
MCQmedium

An organization has a ServiceNow instance that integrates with an external HR system using a scheduled job that runs every hour. The job uses a REST message to fetch new hire records and creates user accounts in ServiceNow via a transform map. Recently, the number of new hires has increased significantly, and the job now takes over an hour to complete, causing the next job to start before the previous one finishes. The administrator notices that the transform map is using 'Coalesce' set to 'false' because the external system does not provide a unique identifier. The job also creates a large number of intermediate records that are later updated. The administrator wants to optimize the process to prevent overlapping job runs. Which course of action should the administrator take?

A.Increase the scheduled job's interval to run every 2 hours to avoid overlap
B.Set the 'Maximum rows to load' property on the transform map to a value that ensures the job finishes within 60 minutes
C.Change the transform map to run asynchronously using a flow triggered by the import set row
D.Configure the import set table loader to run in multiple parallel threads to process records faster
AnswerB

Limiting the rows per run controls the job duration, preventing overlap.

Why this answer

Option B is correct because setting the 'Maximum rows to load' property on the transform map limits the number of rows processed per run, ensuring the job completes within the 60-minute window. This prevents overlapping runs by capping the workload, allowing the scheduled job to finish before the next trigger, without requiring changes to the integration logic or external system.

Exam trap

The trap here is that candidates often assume increasing the interval or adding parallelism (Options A or D) will solve the overlap, but they overlook that without a unique identifier, parallel processing can cause duplicates, and simply delaying the job does not fix the underlying processing speed issue.

How to eliminate wrong answers

Option A is wrong because simply increasing the interval to 2 hours does not address the root cause of slow processing; the job would still take over an hour and could still overlap if the workload remains unconstrained, and it reduces data freshness. Option C is wrong because running the transform map asynchronously via a flow triggered by the import set row does not prevent overlapping job runs; it only decouples processing from the scheduled job, but the underlying bottleneck of processing large volumes without a unique identifier remains, and flows can still queue up and cause delays. Option D is wrong because configuring the import set table loader to run in multiple parallel threads can cause data integrity issues when 'Coalesce' is set to 'false' (no unique identifier), leading to duplicate records or race conditions, and it does not guarantee the job finishes within the hour.

Practice this question →
40
Multi-Selecthard

Which THREE considerations are important when designing a ServiceNow REST API for external consumption? (Choose three.)

Select 3 answers
A.Implement rate limiting to protect the instance from overload.
B.Use versioning in the API path (e.g., /api/now/v1/table).
C.Use GlideAggregate for performance in the API script.
D.Always use OAuth 2.0 for authentication.
E.Provide meaningful error messages in the response body.
AnswersA, B, E

Rate limiting prevents abuse and maintains performance.

Why this answer

Option A is correct because implementing rate limiting is crucial for protecting a ServiceNow instance from being overwhelmed by excessive API requests from external consumers. Without rate limiting, a single client could degrade performance for all users or even cause an outage. ServiceNow provides built-in mechanisms like the REST API rate limit property (glide.rest.rate_limit) to control request frequency per client.

Exam trap

The trap here is that candidates may confuse internal implementation techniques (like GlideAggregate) with high-level design considerations for external REST APIs, or assume that OAuth 2.0 is strictly required when ServiceNow actually supports multiple authentication methods.

Practice this question →
41
Multi-Selectmedium

Which TWO approaches are valid for importing data from an external database into ServiceNow on a recurring basis? (Choose two.)

Select 2 answers
A.Set up a MID Server to run a scheduled transform map from an external SQL query.
B.Use a REST API with a periodic flow that calls an external endpoint.
C.Write a business rule that triggers on an external event via web service.
D.Use an email inbound action to parse CSV attachments from the external system.
E.Configure a JDBC data source and scheduled import set.
AnswersA, E

MID Server can execute SQL queries and transform data into ServiceNow.

Why this answer

Option A is correct because a MID Server can execute a scheduled SQL query against an external database and then run a transform map to map the retrieved data into ServiceNow tables. This approach is a standard pattern for recurring data imports using the MID Server's JDBC capabilities combined with scheduled import sets.

Exam trap

The trap here is that candidates often confuse 'importing from an external database' with any external data integration, but the question specifically requires direct database import, which mandates JDBC and a MID Server, not REST APIs or email-based methods.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Platform Features and Integration questions.

Start 20-question session