Part 5 Full Quiz

B is correct. The full Update Set lifecycle is: (1) Mark "In Progress" Update Set as Complete on the source instance, (2) Export the completed Update Set to an XML file, (3) Load (import) the XML on the target instance — set moves to "Loaded" state, (4) Preview — ServiceNow checks for collisions, (5) Resolve any collisions, (6) Commit — applies all changes. A skips marking it Complete first. C is wrong — Update Sets are never automatically pushed. D puts commit in the wrong place on the wrong instance.

B is correct. The Default Update Set is a real, functional Update Set — it captures all tracked configuration changes just like a named Update Set. The changes are not lost; they can be marked Complete, exported as XML, and migrated to other instances. The risk is organizational: mixing changes from different projects makes it hard to migrate only one project's changes selectively. A is wrong — changes are not auto-discarded. C is wrong — the Default Update Set can be exported. D is wrong — it accepts changes freely.

B is correct. This is the most tested Update Set trap on the CSA exam. Update Sets capture CONFIGURATION changes only — Business Rules, UI Policies, Tables, Form Layouts, Workflows, Scripts, ACLs. They do NOT capture DATA records — Incidents, User records, Tasks, and Asset rows are never tracked in Update Sets. The developer's Incident test data and User record appear to be "in" the Update Set but will NOT transfer. To move data records, use XML Export/Import instead.

C is correct. The Preview step exists precisely to surface collisions before commit. The admin must review each collision and decide: accept the incoming version (overwrite Test) or keep the existing version (skip that change). After all collisions are resolved, the admin safely commits. A is wrong — collisions are not automatically resolved. B is unnecessary and wasteful. D is wrong — collisions do not prevent loading; the set is already loaded, Preview runs successfully, it just flags conflicts for human review.

B is correct. The sys_update_xml table stores the individual tracked customization records — each configuration change as an XML payload — that belong to a given Update Set. sys_update_set (A) stores the Update Set header record itself (name, state, description), not the individual changes. sys_audit (C) stores field-level change history for data records, unrelated to configuration migration. sys_import_set (D) is the staging table for Import Sets, completely unrelated to Update Sets.

B is correct. XML Export/Import is the correct tool for moving individual data records between ServiceNow instances. The exported XML preserves the record's original sys_id, so when imported on the target, the same sys_id is reused — no duplicate is created and any existing references remain intact. A is inefficient and still requires manual effort. C is wrong — Dependency View is a CMDB visualization tool, not a record migration feature. D introduces unnecessary complexity without benefit.

B is correct. XML export and import intentionally preserve the original sys_id. This is a feature, not a bug — it is essential for referential integrity. If other records reference this Group by sys_id (ACLs, workflows, user memberships), those references continue to resolve correctly after import because the sys_id is unchanged. A is wrong — having the same sys_id for the same logical record across Dev/Test/Prod is expected and desirable. C is wrong — sys_ids are always preserved. D is wrong — no automatic daily sync exists.

B is correct. XML Export/Import is designed exactly for this scenario: migrating data records (users, groups, catalog items) between instances while preserving sys_ids. Since existing Incidents reference users by sys_id, preservation is critical to avoid broken assignments. A is wrong — Update Sets capture configuration changes, not User data records. C works for importing from external non-ServiceNow sources but may not preserve sys_ids from the source instance. D generates new sys_ids for each user, breaking all existing Incident references.

B is correct. This tests when to use each migration tool. Update Sets: move configuration (tables, business rules, forms, scripts). XML Export/Import: move data records (incidents, users, catalog items). Both tools are complementary and needed here. A is wrong — Update Sets do NOT capture data records. C is wrong — Update Sets absolutely can capture and migrate table definitions. D is wrong — who created the incident records is irrelevant to what Update Sets can track.

C is correct. A Spoke is a scoped application within IntegrationHub containing pre-built actions for a specific third-party service. The Microsoft Teams Spoke provides actions like "Send Message," "Create Channel," and "Add Member" without requiring custom REST coding. REST Message (A) is a lower-level configuration requiring manual endpoint, header, and payload definition. Business Rule with GlideHTTPRequest (B) is even more script-heavy. Transform Maps (D) are for data import pipelines, not outbound API calls.

B is correct. IntegrationHub is a subscription-licensed add-on product with three tiers — Standard, Professional, and Enterprise — that unlock different pre-built Spoke libraries and action volumes. It is NOT included in the base ServiceNow platform license. This is a common trap on the CSA exam. A is wrong — IntegrationHub requires a separate purchase. C is wrong — IntegrationHub itself is not free. D is wrong — REST Messages require significant manual scripting and do not provide the codeless Spoke actions that make IntegrationHub valuable.

B is correct. A REST Message stores all the details of an outbound REST API call: endpoint URL, authentication method and credentials, HTTP method (GET, POST, PUT, DELETE), request headers, and variable substitution. It can then be called from Business Rules, Scripts, or Flow Designer actions. Data Source (A) defines inbound data origins for Import Sets — it is for pulling data in via imports, not making programmatic API calls. Transform Map (C) is for field mapping during data imports. Update Set (D) is for configuration migration between instances.

B is correct. IntegrationHub is a higher-level platform providing pre-built Spokes (one per third-party app), codeless drag-and-drop actions in Flow Designer, and managed authentication. REST Messages are lower-level building blocks requiring the developer to manually configure every HTTP call parameter and write scripts to invoke them. Both coexist in ServiceNow. A is wrong — IntegrationHub supports REST, SOAP, and more. C is wrong — REST Messages are not deprecated. D is wrong — they are fundamentally different abstraction levels.

B is correct. In the Update Set lifecycle on the target instance: Loaded → Preview → (resolve collisions) → Commit. "Loaded" means the XML file was successfully imported — the changes are staged but not yet applied, and are ready for Preview. A is wrong — Loaded precedes commit; no changes are applied yet. C is wrong — "In Progress" is the recording state on the source instance. D is wrong — a successful Preview with no collisions prepares the set for commit, but "Loaded" is the state before Preview runs.

B is correct. The primary advantage of IntegrationHub Spoke actions in Flow Designer is the codeless, visual, maintainable approach. Non-developers can understand and modify flows; authentication is managed centrally; error handling is built in; and the integration is visible as a clear step in the flow diagram. Business Rules with REST Messages work technically but require scripting expertise, are hidden in code, harder to debug visually, and authentication must be managed manually in script. A is wrong — Business Rules can make outbound HTTP calls via GlideHTTPRequest. C is wrong — runtime speed is not the distinguishing factor. D is wrong — Spoke actions do not bypass ACLs.