Free Practice Questions for ServiceNow CIS-DF Exam

In ServiceNow CMDB governance, the CI Class Manager allows administrators to assign ownership and accountability at the class level. This ownership is used by governance tools—especially CMDB Data Manager—to automatically determine who receives tasks and actions related to data lifecycle management.

The group reference field that aligns with class ownership and is consumed by CMDB Data Manager policies is the Managed By Group. This field represents the team responsible for the technical stewardship and lifecycle management of CIs within that class.

When CMDB Data Manager executes policies such as retention, archival, or cleanup, it uses the Managed By Group to assign tasks to the appropriate data owners. This ensures governance actions are routed to the correct accountable team without manual intervention.

Approval Group, Support Group, and Change Group serve different purposes. Approval Group is used for workflow approvals, Support Group is used for operational ticket routing, and Change Group supports Change Management governance. None of these reflect data ownership at the class level.

Therefore, to leverage CI class ownership defined in the CI Class Manager within CMDB Data Manager policies, the correct field is Managed By Group, making Option B the verified answer.

This question hinges on understanding class-specific Dynamic Reconciliation Rules in CMDB 360 / Multisource CMDB within ServiceNow.

Although two different dynamic rules are configured, the rule applied depends on the CI class being evaluated:

For the Server class, the configured rule is Largest value for the RAM attribute.

For the Windows Server class, the rule Most reported would apply—but only if the CI were evaluated as a Windows Server.

The question explicitly asks for the resulting RAM value for a Server CI, not a Windows Server CI. Therefore, the Largest value rule governs the outcome.

Looking at the multisource values:

2,048 MB (LANDesk)

4,096 MB (Tivoli)

4,096 MB (ServiceNow)

8,192 MB (Altiris)

Under the Largest value dynamic reconciliation rule, the IRE selects the maximum numeric value, regardless of how frequently it is reported or which source provided it.

The Most reported logic (which would result in 4,096 MB) does not apply here because that rule is configured for a different class (Windows Server).

This scenario illustrates an important CMDB 360 principle: Dynamic reconciliation is evaluated per class, and child-class rules do not override parent-class rules unless the CI is actually classified under that child class.

Within the Common Service Data Model (CSDM), regulatory, security, and compliance-related information—especially for PII and PCI—must be modeled at the business and information level, not at the infrastructure or service offering level. The correct location for this data is Business Applications combined with Information Objects.

Business Applications represent the logical applications that support business capabilities and processes. Since compliance obligations (such as GDPR, PCI-DSS, or HIPAA) are assessed based on how the business uses data—not how many servers host the application—this is the correct anchor point for audit-relevant context.

Information Objects are explicitly designed to capture what data is processed, stored, or transmitted by an application, including data classifications such as PII, PCI, PHI, or confidential business data. They allow organizations to document regulatory scope, retention rules, encryption requirements, and audit controls without overloading CI records or polluting infrastructure classes.

Option A is incorrect because Technical Service Offerings and Groups focus on operational support and service delivery, not regulatory data context. Option C is also incorrect because Customer Service Offerings describe how services are consumed, while databases are technical components; neither is the authoritative place for compliance definitions.

Therefore, Business Applications and Information Objects are the correct CSDM constructs to support audits and regulatory compliance, making Option B the correct answer.

The CMDB Data Foundations Dashboard is paired with Get Well Playbooks that guide administrators through structured remediation. The “Services Have Owners Identified” playbook focuses on closing ownership gaps for services, which is a governance and data correction activity.

Fix Data (Option A) is used to correct missing or incorrect values, such as populating owner fields, assigning responsible groups, or updating relationships. In this playbook, Fix Data actions are required to actually remediate the issue by assigning owners to services.

Govern Data (Option D) is also required because ownership is not a one-time correction—it must be enforced and sustained. Govern Data establishes policies, ownership accountability, and controls (such as certifications or attestations) to ensure services continue to have owners over time and do not regress.

Analyze Data (Option B) is used to understand patterns and root causes, but it does not remediate the issue. Report Data (Option C) provides visibility and communication, not corrective action.

Therefore, the remediation plays that apply to the Services Have Owners Identified playbook are Fix Data and Govern Data, making Options A and D correct.

Comprehensive and Detailed Explanation (200–300 words)

Within ServiceNow Data Foundations, CMDB Data Manager provides multiple policy types to support governance, data quality, and lifecycle management of configuration items (CIs). The scenario described—confirming that servers recorded in the CMDB physically exist in the data center—is a classic example of existence validation and ownership confirmation, which is exactly the purpose of an Attestation policy.

An Attestation policy is designed to request a human validation from a responsible individual or group (such as a data center manager, platform owner, or infrastructure team). The policy generates attestation tasks that require reviewers to explicitly confirm whether a CI is valid, accurate, and still exists. This aligns directly with CMDB governance best practices and ITIL 4 Service Configuration Management, where periodic verification ensures trust in the CMDB as a system of record.

The other policy types do not meet this requirement:

Certification is typically used to validate compliance with defined data standards (e.g., mandatory fields populated), not physical existence.

Delete, Archive, and Retire are lifecycle actions, used after a CI has already been identified as obsolete or no longer required.

None of these options involve human confirmation of real-world existence.

From a CSDM and Data Foundations perspective, attestation supports:

CMDB accuracy and credibility

Audit and regulatory compliance (especially critical in financial services)

Clear accountability for CI ownership and validation

Therefore, when the goal is to confirm that servers actually exist, the correct and fully aligned CMDB Data Manager policy type is Attestation (E).

Within the CMDB class dictionary in ServiceNow, attributes can be inherited from parent classes or defined directly on a specific class. To identify attributes created specifically for the Windows Server class, administrators must use the Added tab.

The Added tab displays attributes that are unique to the selected class and not inherited from parent classes (such as Server or Computer). This is essential for understanding class-specific extensions—like Windows-only configuration details—that were introduced to support platform requirements, discovery enhancements, or organizational needs.

The All tab shows every attribute available to the class, including inherited and added attributes, which makes it difficult to isolate class-specific additions. The Child tab focuses on attributes inherited by subclasses, not attributes introduced at the current class level. The Derived tab shows attributes calculated or derived from other data, not necessarily those created specifically for the class.

Using the Added tab supports best practices for configuration transparency, impact analysis during upgrades, and governance—especially important in Data Foundations to minimize unnecessary customization and maintain upgrade-safe designs.

Therefore, the correct answer is B – Added.

In ServiceNow, each CMDB Health metric can independently define which CIs are in scope for evaluation. This scoping is controlled primarily through Health Inclusion Rules, not CMDB Groups.

In this scenario, the Duplicate metric evaluates all 60,000 Server CIs, indicating no inclusion rule is restricting its scope. In contrast, the Orphan metric evaluates only 50,000 Server CIs, which means 10,000 servers are intentionally excluded from that metric’s evaluation.

This difference is explained by a Health Inclusion rule configured specifically for the Orphan metric on the Server class. Health Inclusion rules allow administrators to define conditions—such as lifecycle state, environment, discovery source, or operational status—that determine whether a CI should be included in a specific health calculation. For example, retired servers or servers in build states may be excluded from orphan checks.

CMDB Groups are not used by the CMDB Health Engine to determine metric scope; they are used for reporting, assignment, and operational grouping. Therefore, Options A and D are incorrect. Option C is also incorrect because the Duplicate metric clearly evaluates the full population of 60,000 servers.

Thus, the scope difference is correctly explained by the Orphan metric having a Health Inclusion rule configured, making Option B the verified answer.

In ServiceNow, Dynamic CI Groups are a core Data Foundations capability used to automatically manage CI membership based on rules rather than manual maintenance. When Technology Management Service Offerings (Technical Service Offerings) are related to Dynamic CI Groups, ServiceNow uses those relationships to synchronize operational support attributes to the member CIs.

The two CI attributes that are intentionally designed to sync in this model are the Managed by Group and the Support Group. These groups directly influence operational ownership and support routing, which is why they are automatically aligned when Dynamic CI Groups are used. This ensures that incidents, changes, problems, and operational tasks are routed consistently as CI membership changes over time.

The Support Group defines who provides day-to-day operational support and is critical for Incident and Request Management workflows. The Managed by Group represents the team responsible for the technical lifecycle and operational health of the CI. Synchronizing these attributes eliminates manual updates and reduces misrouted tickets, which is a key goal of Configuration Management maturity.

The Approval Group (Option A) is not synced because approvals are process-driven and often context-specific rather than CI-driven. Similarly, the Owned by Group (Option C) represents accountability or financial ownership, which is intentionally decoupled from dynamic operational grouping to avoid unintended governance changes.

Therefore, the correct answers are B (Managed by Group) and D (Support Group).

This question tests understanding of reconciliation source priority in the Identification and Reconciliation Engine (IRE) in ServiceNow.

In reconciliation rules, lower numeric values represent higher priority. Therefore, the priority order is:

ServiceNow (100) – highest authority

Altiris (200)

SCCM (300) – lowest authority

Why A is correct

Because Altiris (200) has higher priority than SCCM (300), data from Altiris can update records originally inserted by SCCM. This is exactly how reconciliation precedence works—higher-priority sources can overwrite lower-priority ones.

Why C is correct

SCCM, even though it has the lowest priority, is still an authorized discovery source. It can insert new records into the Windows Server table when no existing CI is identified. Priority only affects updates, not the ability to create records.

Why B is incorrect

ServiceNow (priority 100) can update records from Altiris and SCCM because it has the highest priority. The statement incorrectly claims it cannot.

Why D is incorrect

SCCM does not have the highest authority. A higher numeric value means lower priority, so SCCM cannot update records created by higher-priority sources.