Part 6 Full Quiz — Governance & Data Quality
18 questions (15 topic questions + 3 cross-topic integration) on Data Policies, Dictionary Overrides, field validation, reference qualifiers, and certification. Select an answer to reveal the explanation.
Which mechanism enforces this server-side requirement?
B is correct. Data Policies (stored in sys_data_policy2) are server-side enforcement rules. Unlike UI Policies (client-side only, bypassed by API/imports), Data Policies fire on every save regardless of access method — including REST API, Import Sets, and scripts. They are the correct tool when enforcement must hold everywhere. UI Policy (A) and Client Script (C) only run in the browser. Reference Qualifier (D) controls lookup filtering, not mandatory validation.
What happens to records that violate a Data Policy during an Import Set run?
C is correct. When "Apply to Import Sets" is enabled, Data Policy evaluates each row individually. Rows that violate the policy fail (error status) and are not written to the target table. Other rows that pass continue normally. This granular behavior means you may get a partial import with some successes and some errors — all logged in the Import Set row status. The import run does not stop entirely (B) on the first failure.
[TRAP] Which approach correctly targets only the child table without modifying the parent?
B is correct. A Dictionary Override (sys_dictionary_override) is designed precisely for this: changing inherited field attributes (mandatory, default value, read-only) specifically on a child table without touching the parent. Setting mandatory on the parent (A) forces it everywhere. Data Policy with a class condition (C) is valid server-side but less precise and not the "dictionary-level" approach. UI Policy (D) is client-side only and not server-enforced.
What is the effect of this Dictionary Override?
B is correct. Dictionary Overrides are scoped to the specific child table. Only new records created in the VIP Incident table will receive "Network" as the Category default. The parent Incident table (and other child tables like Problem or Change) are completely unaffected. Default values only apply to NEW records at creation time — existing records (C) are not retroactively updated. D is wrong — default value IS a supported Dictionary Override attribute.
Which feature enables this dependent filtering behavior?
B is correct. A Dependent choice list links a child choice field to a parent choice field — the available options in Sub-Region are filtered based on the currently selected Region value. This is configured in the Choice List for the Sub-Region field by setting "Dependent on Field" to Region. Reference Qualifier (A) works for Reference-type fields (table lookups), not choice lists. A Client Script (C) can achieve this but is not the built-in configuration mechanism.
[TRAP] Where in ServiceNow is regex-based field validation configured?
C is correct. ServiceNow has a dedicated Field Validator mechanism: a sys_ui_validator record that contains the regex pattern and error message. The validator is then linked to the specific field in the sys_dictionary record via the "Validation" attribute. This provides clean, reusable regex validation. A Business Rule (D) can also validate but is more complex. UI Policy scripts (B) run client-side only. The "Description" attribute (A) is just documentation metadata.
What automatically happens to the Sub-Region field value when the parent changes?
B is correct. When a dependent choice list's parent field changes, ServiceNow automatically clears the dependent field to prevent an invalid (orphaned) value from being saved. The Sub-Region field would show blank/empty and refresh its available options to match the new Region selection. This prevents the "France is in Americas" data integrity problem automatically without requiring a script.
When does this default value apply?
B is correct. A Default Value in sys_dictionary sets the initial field value when a new record is created — both via form (pre-populates the field) and via API/script (if no value is provided in the insert call). It does NOT force the value on every save (A) — once a user changes the field, the default has no further effect. It applies to all users (D is wrong). C is partially correct for forms but misses API/import creation scenarios.
active=true^type=itilWhat type of Reference Qualifier is this?
B is correct. A simple/standard Reference Qualifier uses a static GlideRecord query string (same syntax as a list view filter condition). It is static — the filter conditions do not change based on context or current user. An Advanced/Dynamic qualifier (A/C) uses JavaScript to programmatically generate the filter, enabling context-aware filtering like "show only groups the current user belongs to." The query string format here (active=true^type=itil) is the static form.
[TRAP] What type of qualifier enables this dynamic per-user filtering?
B is correct. An Advanced (Dynamic) Reference Qualifier uses a JavaScript script that runs at the time the lookup is opened, returning a dynamic filter query string. This allows using gs.getUserID(), current record values, or any runtime context to build a per-user filter. A static query (A) cannot call functions in the filter string natively. ACLs (D) control access but don't customize the reference field dropdown filter. Business Rules (C) don't hook into reference lookups.
Which ServiceNow mechanism provides field-level read restriction per user/role?
B is correct. Field-level ACLs can restrict read, write, or create access to individual fields based on role, script, or conditions. Setting a read ACL on the Salary field means users without the required role see the field as blank or hidden. This is a server-side, API-enforced restriction. UI Policy (C) hides the field on the form but the data is still sent to the browser and accessible via API. Record ACL (A) hides the entire record, not just one field.
Which ServiceNow feature provides a structured workflow for this periodic data accuracy review?
B is correct. Data Certification is ServiceNow's purpose-built feature for periodic human review of record accuracy. A campaign is created defining which records need review and who is responsible (certifiers). Tasks are assigned to certifiers who review and mark records as certified or flag for correction. CMDB Health (A) provides automated scoring but not human review. Discovery (C) finds hardware/software, not human-driven certification. Data Policy (D) enforces field rules on save, not periodic review.
What is the role of Certifiers in a Data Certification campaign?
B is correct. Certifiers are the human reviewers in a Data Certification campaign. They receive tasks in their to-do list, open each assigned record, review the data for accuracy, and either certify (confirm it's correct) or flag for correction. Campaign configuration (A) is done by the admin who sets up the certification. Automated scripts (C) are not part of certification — it is human-driven. Report recipients (D) is a different role.
[TRAP] What is the AUTOMATIC effect on the CI record itself?
C is correct. This is a classic exam trap. An overdue Data Certification task does NOT automatically affect the underlying CI record. The CI continues to exist, is editable, and is usable as normal. Only the certification task is flagged as overdue. Any further actions (escalation, notifications, auto-close) would require custom workflows or scheduled jobs built on top of the certification framework. Data Certification is a governance process, not an enforcement mechanism on the data itself.
When does the NEXT certification campaign automatically begin?
B is correct. When a Data Certification is configured with a recurrence (quarterly, monthly, etc.), the next campaign launches automatically based on the configured frequency — approximately 90 days for quarterly. It does not wait for manual triggering (C) or fire immediately on completion (A). The schedule is calendar-based, not completion-triggered. This automation is what makes Data Certification useful for ongoing governance without admin overhead.
Does the Data Policy apply in both scenarios?
B is correct. The critical differentiator of Data Policies over UI Policies is server-side enforcement. Server-side means the rule runs regardless of access path: form save, REST API, Import Set transform, GlideRecord script. UI Policies only run in the browser. Because incident extends task (Part 1 Topic 1 table inheritance), the mandatory priority rule applies to all task child tables including incident.
Which mechanism should be used?
B is correct. Dictionary Overrides let you customize a field's dictionary attributes (label, mandatory, read-only, default value) for a specific child table without modifying the parent definition. Editing sys_dictionary on cmdb_ci (A) changes the label for ALL CI tables — too broad. UI Policies (C) only affect form display, not the dictionary record. Creating a new field (D) duplicates data and creates sync complexity. This uses Part 1's table inheritance to target exactly one child table.
Why can't the admin find 'Absent' in operational_status, and what IS 'Absent' in this context?
B is correct. Absent is a CMDB Data Manager concept — a workflow state identifying a CI that no data source confirmed within the staleness threshold. It is NOT an operational_status field value. OOTB operational_status: 1=Operational, 2=Non-Operational, 3=Repair in Progress, 4=DR Standby, 5=Ready, 6=Retired, 7=Pipeline, 8=Catalog. No Absent slot. When Data Manager flags a CI as Absent, it initiates a review workflow — the admin may then change operational_status manually, but Absent itself is not stored in that field.