Part 8 Full Quiz — Integration & Advanced

C is correct. RESTful HTTP methods in Table API: GET = read/retrieve records (single or list); POST = create a new record; PUT = update/replace an entire record; PATCH = partial update (update specific fields only); DELETE = delete a record. For retrieving Incident records, GET is always used. These map directly to CRUD: Create=POST, Read=GET, Update=PUT/PATCH, Delete=DELETE.

B is correct. The sysparm_display_value parameter has three options: false (default) = raw values only (sys_ids, internal codes); true = display values only (human-readable labels); all = BOTH raw value and display value for each field as a JSON object: {"value": "a1b2c3...", "display_value": "John Smith"}. Use all when your integration needs both the sys_id (for programmatic use) and the label (for display). ACLs (D) are still enforced regardless of this parameter.

B is correct. Standard HTTP status codes for REST APIs: 200 OK = successful GET/PUT/PATCH; 201 Created = successful POST (record created); 204 No Content = successful DELETE; 400 Bad Request = client error (bad params); 401 Unauthorized = auth failed; 403 Forbidden = ACL blocked; 404 Not Found = record doesn't exist; 500 Internal Server Error = server-side error. 201 specifically confirms the new record was created successfully.

B is correct. Key Table API sysparm parameters: sysparm_fields = comma-separated field names to include (e.g., number,short_description,state); sysparm_query = GlideRecord-style filter (e.g., state=1^priority=1); sysparm_limit = max records to return (pagination); sysparm_offset = pagination offset; sysparm_display_value = raw vs display values; sysparm_view = use a named view's field set. Specifying sysparm_fields reduces payload size and improves performance.

B is correct. An IntegrationHub Spoke is a packaged set of pre-built Actions for a specific third-party platform. The Jira Spoke includes actions like "Create Issue," "Update Issue," "Add Comment." Each Spoke requires a separate license (except core HTTP). Spokes abstract away the raw API details — you use high-level actions instead of building raw REST calls. A Mid Server (D) handles on-premise network connectivity but is not a Spoke. A Spoke is a higher-level abstraction built on top of network connectivity.

B is correct. The IntegrationHub core HTTP step (generic outbound REST call) is included with the base IntegrationHub entitlement — no specific Spoke license is needed for it. Spoke licenses (Jira, Slack, ServiceNow-to-ServiceNow, etc.) are required to use those specific pre-built platform Spokes. If you need to call a custom REST API, use the core HTTP step — it's available without additional cost. This distinction is commonly tested to check if candidates understand the IHub licensing model.

B is correct. A Data Stream Action in IntegrationHub is specifically designed to handle paginated bulk data from external REST APIs — it iterates through pages automatically, handling pagination tokens or page offsets, until all data is retrieved. Regular Actions execute once per invocation (A would only get the first page). Scripted REST API (C) handles INBOUND calls to ServiceNow. Import Sets with JDBC (D) work for database-to-database pulls, not REST API pagination. Data Stream Actions bridge the gap between REST APIs and bulk data needs.

B is correct. An Outbound REST Message (sys_rest_message) is the template for calling external REST APIs FROM ServiceNow. It stores the base URL, authentication method (Basic, OAuth, API Key), HTTP methods (GET/POST/etc.), and headers. Individual HTTP Methods within the REST Message define specific endpoints and request bodies. This is then called from scripts or workflows. A Scripted REST API (C) is the INBOUND counterpart — it defines REST endpoints that external systems call on ServiceNow. D is completely incorrect.

B is correct. This is one of the most important and tested distinctions in Part 6: Archive — moves records from the active table (e.g., incident) to the archive table (e.g., incident_archive). Data is preserved but no longer in the active table, so standard queries won't find it. Purge — permanently destroys the records from the database. This is irreversible. Archive preserves data for compliance/audit; purge is for permanent disposal. A (soft delete/flag) is NOT how ServiceNow archive works — records are physically moved.

B is correct. After archiving, the record is physically moved to the incident_archive table. Queries against the active incident table will find nothing — the record is gone from that table. To find archived records, you must explicitly query the incident_archive table. This is a common trap because users expect to still find records after "archiving" — but archiving in ServiceNow is a table move, not a status flag. There is no automatic redirect (D) or visual flag in the active table (C).

B is correct. ServiceNow follows a consistent naming convention for archive tables: the original table name followed by _archive. So incident → incident_archive, sc_request → sc_request_archive, etc. The archive table has the same column structure as the original (it is created automatically when archiving is first configured). Querying incident_archive directly via GlideRecord or via the list view allows compliance audits of archived data.

B is correct. Archive Rules are stored in the sys_archive table (accessible via System Archiving → Archive Rules). Each rule defines: which table to archive, the filter conditions (State = Closed AND Closed more than 2 years ago), the archive table to move records to, and optional fields to exclude from archiving. A scheduler runs the archive rule periodically. This is distinct from Data Retention Policy (D), which is a newer feature for broader data lifecycle management, and from manual scripts (C) which are not the standard mechanism.

B is correct. This is a critical post-clone risk. When Production is cloned, the Development instance contains real production user data — including actual email addresses. If a scheduled job that sends emails runs in Dev, it uses those real email addresses and sends emails to real users from the Dev instance. This is embarrassing, potentially a compliance issue, and confusing for recipients. After every clone, always review and disable scheduled jobs in the Development instance — especially any that communicate with external systems (email, SMS, webhooks). ServiceNow does NOT automatically disable jobs post-clone (D).

A is correct. Clone Excluders let you specify tables, records, or fields that should NOT be overwritten when a clone runs. Sensitive API credentials, Dev-specific configuration, or integration URLs stored in System Properties can be protected this way. The clone proceeds but skips the excluded data, keeping Dev-specific values intact. Clone Profiles (B) define the clone source/target and settings — they control the clone configuration. Post-Clone Scripts (D) run after the clone to restore specific values — also useful, but Excluders prevent the overwrite in the first place.

B is correct. glide.max_query_result_limit is a system-wide safety cap on query result sizes. If a GlideRecord query or Report would return more than 10,000 records, ServiceNow limits the result set to this maximum — preventing uncontrolled full-table scans from degrading instance performance. This is a database performance protection property. When reports or queries "stop at exactly 10,000 records," this property is usually why. Admins should be aware of this limit when designing reports and integrations that process large record sets.

B is correct. The Table API writes to exactly the table specified and sets sys_class_name accordingly (Part 1 Topic 1). A CI in cmdb_ci has sys_class_name = cmdb_ci — it won't appear in server-specific views, Discovery CI Groups filtered by server class, or CMDB Health rules for cmdb_ci_server. Always target the correct subclass when creating CIs via the Table API. The Table API supports any table (C is false). IRE is not automatically invoked by Table API calls (D is false).

B is correct. IRE is NOT a transparent interceptor for all CMDB writes. It is only invoked when Discovery sends payloads, SGC processes data, or you explicitly call the IRE API. A direct PATCH to the Table API goes straight to the database — bypassing Identification, Reconciliation, and Deduplication. This means the Integration Hub flow will overwrite Discovery's cpu_count value ignoring source authority rules. The correct architecture is to route external data through the IRE API. This is a critical architecture trap connecting Part 8 with Part 4.

C is correct. ServiceNow archiving (Part 8 Topic 3) moves records to a dedicated archive table. Records are removed from the active table (so standard queries don't find them) but remain in the database in the archive table, accessible via the Archive API or direct table queries. Archiving is NOT deletion (A). Records are not exported to CSV (B). Active-table filtering (D) describes something different — archive records are physically relocated to the archive table.