Part 1 Full Quiz — ServiceNow Data Model
18 questions (15 topic questions + 3 cross-topic integration) on table hierarchy, field types, relationships, schema design, and CMDB connections. Select an answer to reveal the explanation.
Where is the data physically stored in ServiceNow's database?
C is correct. ServiceNow uses object-oriented inheritance. When a table extends another, data is physically split: fields inherited from the parent table are stored in the parent's database table, while fields added in the child table are stored in the child table. A JOIN is performed transparently when querying. sys_db_object (D) is the metadata catalog, not where records live.
What is a sys_id in ServiceNow?
B is correct. Every ServiceNow record has a sys_id — a 32-character hex GUID that is globally unique across the entire instance, all tables included. It is how records are referenced by Reference fields, REST API calls, and imports. The human-readable number (C) is the number field (e.g., INC0001234), which is table-scoped and not globally unique.
[TRAP] What is the correct approach?
B is correct. The proper OO approach is to create a child table that extends incident — the "VIP Level" field exists only in that child. A Dictionary Override (C) changes attributes (mandatory, default, read-only) of an existing field on a child table; it cannot add entirely new fields. Adding the field to the base incident table (A) bloats the schema for all incidents. Data Policy (D) enforces values but cannot add fields.
Which table stores all field/column metadata for ServiceNow tables?
B is correct. sys_dictionary is the central dictionary — it holds one row per field per table, storing field type, max length, mandatory flag, default value, etc. sys_db_object (A) is the table registry (one row per table, not per field). sys_metadata is the parent of all configuration records. sys_table_schema is not a standard ServiceNow table.
Which field type is the correct choice?
B is correct. A Reference field stores the sys_id of exactly one record from a specified related table and renders a lookup field on the form. List Collector (A) is for multi-select references (glide_list). Document ID (C) is a special field that can reference any table (the table is stored separately in a "Table Name" field) — used for polymorphic references. Choice (D) uses a static dropdown list, not a table lookup.
What does this setting control?
B is correct. Max Length on a string (or similar text) field in the dictionary controls the maximum number of characters that ServiceNow will store for that field. Values exceeding this limit are truncated or rejected. It is enforced at the database column level. It does not control display width (D), query limits (A), or choice counts (C).
[TRAP] What is the correct mechanism?
B is correct. A Dictionary Override (sys_dictionary_override) lets you override specific field attributes (mandatory, default value, read-only, choices) for an inherited field on a specific child table — without touching the parent table definition. Setting mandatory on the parent (A) would force it everywhere. UI Policy (C) is client-side only; Data Policy (D) enforces on save but lacks field-level child specificity without conditions. Dictionary Override is the right tool for child-specific attribute changes.
What is the key enforcement difference?
B is correct. This is a frequently tested distinction. Dictionary mandatory is enforced server-side on every save — form, API, import, whatever. UI Policy mandatory is enforced only in the browser form — it has no effect when records are created via REST API, Import Sets, or scripts. Always use Dictionary (or Data Policy) for requirements that must hold regardless of access method.
What does a Database View (sys_db_view) support?
B is correct. Database Views (sys_db_view) are read-only virtual joins. They exist solely to enable reporting across tables that are not in a direct parent-child relationship. You cannot write data through a view, create records, run Business Rules on the view, or synchronise data. They are purely a reporting construct — a named SQL-like JOIN definition.
Which relationship type handles this correctly in ServiceNow?
B is correct. When both sides can have multiple associations (CI belongs to many groups; group supports many CIs), a Many-to-Many relationship is required. In ServiceNow, this is implemented via an intermediary "relationship table" with two Reference fields pointing to each side. A Reference field (A) only stores one value — that's one-to-many. Extension (D) means inheritance, not association. Parent_id (C) is a self-referential hierarchy within one table.
[TRAP] What happens to Incidents with no matching SLA record in a report built on this view?
B is correct. A Left Outer Join includes ALL rows from the primary (left) table, regardless of whether a matching row exists in the secondary table. When there is no match, the secondary table's fields are null/empty in the result. If it were an Inner Join, then only records with matches in both tables would appear (answer A would apply). This join-type distinction is frequently tested in CIS-DF.
What is the recommended approach?
B is correct. Extending an OOB table creates a child table that inherits all parent fields while adding only the custom fields needed. This preserves the inheritance hierarchy (allowing CMDB/task queries to work), avoids modifying the OOB table directly (A/D — both touch the parent), and is the recommended upgrade-safe approach. A separate unrelated table (C) breaks the hierarchy and requires manual joins for reports.
Which field type stores multiple reference values (comma-separated sys_ids) in a single field?
B is correct. A Glide List (field type: List) stores multiple sys_ids from the same table as a comma-delimited string in a single database field. It renders as a multi-select list on the form. Reference fields (A) store exactly one sys_id. Document ID (C) stores one polymorphic reference. Journal Input (D) is for append-only text like Work Notes. Glide Lists are quick but less performant than M2M tables for large-scale associations.
[TRAP] Which mechanism GUARANTEES server-side enforcement on every save regardless of access method?
C is correct. Only a Business Rule (before insert/update) runs server-side on every save path — form, API, import, script. UI Policy (A) and Client Script (B) are browser-only and bypassed by any non-form access. Data Policy (D) enforces server-side too but only when "Apply to Import Sets" is enabled and still has edge cases. A Business Rule with current.setAbortAction(true) is the absolute guarantee across all paths.
What does table extension mean in ServiceNow's data architecture?
B is correct. Table extension in ServiceNow implements OO inheritance. The child table inherits ALL columns from the parent (they are not copied — still stored in the parent's database table) and adds its own unique columns. Business Rules, ACLs, and scripts on the parent may also apply. Existing records stay in the parent (D is wrong). No copy is made (C). No fields are added to the parent (A). The key insight: the child IS-A parent — an Incident IS-A Task.
cmdb_ci with no conditions and returns 85,000 records spanning servers, laptops, applications, and network devices. A junior admin expected far fewer because they only see a few fields in the cmdb_ci form.Why does a query on cmdb_ci return records from child tables like cmdb_ci_server and cmdb_ci_appl?
C is correct. Single-table inheritance (Part 1 Topic 1) means all CI records exist in a unified physical table. Querying cmdb_ci returns all CIs regardless of class because they share that base. The sys_class_name field identifies each record's real class (e.g., cmdb_ci_server). This is the foundation for CMDB architecture in Part 5 — the entire CI class hierarchy is built on this inheritance model.
name and operational_status of each affected CI. The Incident table only has a Reference field to cmdb_ci, not flat CI columns.Which Part 1 feature creates a virtual read-only joined table that lets the Report Builder access both Incident and cmdb_ci columns as flat fields?
C is correct. Database Views (Part 1 Topic 3) are exactly this: virtual read-only tables defined in ServiceNow that join related tables. Once created, the Report Builder treats the view as a flat table. This is the direct prerequisite for Part 7's advanced reporting scenarios. Import Sets (A) are for data ingestion. Coalesce (B) is a Transform Map deduplication technique. GlideRecord (D) is a scripting API, not a reporting configuration.
sys_user_role to find all users assigned the itil role. The query returns only 4 rows — the exact number of role definitions in the system, not the hundreds of users expected.What is wrong with the approach, and which table contains the actual user-to-role assignments?
B is correct. This is a classic exam trap also corrected in Part 1 Topic 3. sys_user_role stores ROLE DEFINITIONS (name, description, elevated_privilege) — there are only a few rows because there are few distinct roles. The M2M junction sys_user_has_role has one row per user-role assignment. This "definition table vs assignment junction" pattern repeats throughout ServiceNow (e.g., sys_group defines groups, sys_user_grmember assigns users to groups).