Free ServiceNow CIS-DF Practice Exam with Questions & Answers | Set: 6

In ServiceNow, validating whether Configuration Items (CIs) still exist is a core CMDB governance activity. Over time, environments change rapidly—servers are decommissioned, cloud resources are torn down, and applications are replaced. If existence validation is not enforced, the CMDB quickly fills with obsolete or “ghost” CIs.

Attestation policies are specifically designed to address this need. An attestation policy automatically generates and assigns tasks to responsible users or groups, asking them to confirm that a CI still exists and is still relevant. This process focuses on acknowledgment rather than deep data validation, making it lightweight and scalable across large CMDBs.

Certification policies (Option A) are used when specific attributes must be validated, such as lifecycle status, support group, or environment. While important for data correctness, certification is not intended solely to confirm CI existence. Delete (Option B) and Retire (Option C) policies are lifecycle actions that remove or transition records, but they do not validate existence before taking action.

Attestation integrates cleanly with CMDB Workspace, assigns tasks automatically, and supports auditability—ensuring accountability for CI ownership. This makes it the correct and Data Foundations–aligned policy type for validating CI existence.

Therefore, Option D – Attestation is the correct answer.

The two applicable roles are cmdb_dm_admin and cmdb_dm_user . The administrative role provides permission to configure, publish, and manage CMDB Data Manager policies. These policies govern activities such as attestation, certification, retirement, archival, and deletion of CI records.

The user role provides access to the operational work generated by those policies. Assigned users can review and complete applicable Data Manager tasks through the My Work tab in CMDB Workspace.

The alternative role names data_manager_user and data_manager_admin do not represent the CMDB Data Manager roles tested in this question. The distinction is important: policy administrators configure governance controls in the Management area, while task users act on the resulting assignments. CMDB Data Manager therefore separates policy administration from task execution through these two roles.

=========

A Technology Management Service Offering associated with the applicable Dynamic CI Group synchronizes operational group information to its member CIs. The fields designed for this synchronization include Managed by Group and Support Group .

Therefore, Linux Server CIs included in the offering’s CI population receive Enterprise IT Services as their Managed by Group. The CI Class Manager value can provide class-level ownership or governance context, but the service-offering alignment actively maintains the operational group value on the related member CIs.

The conflicting values do not cause Discovery or ingestion to fail. ServiceNow applies the configured group-synchronization mechanism rather than leaving the field empty. Change Management Team is assigned to the Change Group field, not the Managed by Group field, so Option D does not answer the question.

Consequently, the Managed by Group assigned to the discovered Linux Server instances is Enterprise IT Services.

To specifically improve data quality related to CSDM, the most effective and prescribed action is to use the CSDM Data Foundations Dashboard. In ServiceNow, this dashboard is purpose-built to assess and improve CSDM alignment, not just general CMDB hygiene.

The CSDM Data Foundations Dashboard focuses on service modeling readiness, highlighting gaps such as missing service ownership, incomplete relationships between Business Applications and Application Services, unmanaged services, and misaligned lifecycle states. It provides Get Well Playbooks that guide administrators through structured remediation using Analyze Data, Fix Data, and Govern Data plays—directly tied to CSDM outcomes.

Option C (default CMDB Health Dashboard) is valuable, but it measures generic CMDB data quality dimensions (completeness, correctness, compliance) and does not specifically evaluate CSDM constructs or service modeling maturity. Option B (ServiceNow Health Scan) provides platform-wide configuration and performance recommendations, but it is not focused on CMDB or CSDM data quality.

Therefore, to improve CSDM-specific data quality, the administrator should use the CSDM Data Foundations Dashboard, making Option A the correct answer.

When building advanced CMDB queries using CMDB Query Builder in ServiceNow, the correct approach is to model CI scope, relationships, and task context explicitly on the canvas.

To limit results to databases in a specific location, the administrator must filter the Database CI node by the Location attribute. Therefore, Option C is required to scope the query to Database CIs where Location = Seattle.

To include Incidents related to those databases, the Incident table must be added from the Non-CMDB Tables list and linked through the task_ci relationship. This is exactly what Option A provides. CMDB Query Builder separates CMDB tables (CIs) from task and transactional tables, so incidents must be explicitly added from the Non-CMDB section.

Option B is incorrect because property columns on Application Services do not scope databases or incidents. Option D is unnecessary because relationship depth alone does not include non-CMDB task data and does not filter by location.

Thus, the correct actions are A (add Incident table) and C (filter Database by location).

When duplicate CIs are evaluated, one record is treated as the main or original CI and the remaining records are marked as duplicates of that record. In this scenario, the oldest record—created on January 20—is retained as the primary CI. The records created on January 21 and January 22 therefore have their Duplicate Of field populated with a reference to the January 20 CI.

This approach preserves the record with the longest history and reduces the risk of breaking references from incidents, changes, relationships, and other dependent records. The Duplicate CI Remediator similarly presents Oldest Created and Most Related Items as significant criteria when determining the Main CI.

The January 20 record itself is not marked as a duplicate of one of the newer records. Consequently, the two later records receive the Duplicate Of reference, making Option A correct.

=========

Foundation → Use the base system tables when implementing CSDM to get the highest value from ServiceNow products and the Now Platform.

Design and Planning → Understand CIs related to Business Applications and related capabilities; identify redundancies, monitor costs, and make better investment decisions around the roadmap.

Service Consumption → Understand Business Services, ownership, cost, scope of work offered to business consumers, and request access to business services.

Service Delivery → Understand Technical Services, Technical Service Offerings, service support, and all relationships to underlying technology CIs.

CSDM separates data into domains so organizations can model business planning, consumption, and technical delivery without mixing concerns. The Foundation domain provides base reference data such as users, groups, companies, locations, and foundational tables used across the platform. Design and Planning supports architecture and portfolio planning through Business Applications, Business Capabilities, and Information Objects. Service Consumption focuses on how services are exposed to and consumed by business users through Business Services and Business Service Offerings. Service Delivery focuses on how services are technically operated using Technical Services, Technical Service Offerings, Application Services, and supporting infrastructure CIs. This separation is what makes CSDM valuable: each domain answers a different management question while still connecting to a unified service model.

=========

In ServiceNow, the Duplicate CI Remediator is designed to resolve duplicate records while preserving the most authoritative data from each source. Data Foundations guidance clearly states that automated discovery is the system of record for technical attributes, such as IP address, hostname, and operational status, while manually maintained records often contain valuable business context, such as relationships to business applications or services.

In this scenario, the discovered CI contains the most accurate and up-to-date technical data, making it the correct CI to retain as the primary record. However, the manually imported CI has a critical relationship to a business application, which is essential for impact analysis, incident prioritization, and CSDM alignment. Deleting this CI without preserving the relationship would result in loss of business context and reduced CMDB value.

The Duplicate CI Remediator supports selective merging, allowing administrators to retain one CI while merging specific attributes or relationships from the duplicate. Option C reflects this best practice by retaining the discovered CI and merging the relationship from the manually imported CI, ensuring both technical accuracy and business relevance are preserved.

Options A and D would result in the loss of important relationship data, while Option B would discard the discovered CI, violating the principle that discovery should be the authoritative source for technical attributes.

Therefore, Option C is the correct and Data Foundations–aligned answer.

Life cycle mappings are used to review how legacy CMDB status values correspond to the newer CSDM life cycle stage and life cycle stage status model. This is a key governance activity during transition from older status fields to CSDM-aligned lifecycle management. The mapping layer allows administrators to understand and control how legacy operational values translate into standardized lifecycle stages and stage statuses. This prevents inconsistent reporting, incorrect CI retirement behavior, and confusion between old and new status models. A choice list only stores selectable values and does not provide the mapping relationship between legacy status and CSDM lifecycle fields. Life cycle properties may control behavior but do not serve as the review location for legacy-to-CSDM value alignment. Therefore, when reviewing equivalent legacy status and CSDM lifecycle values, the correct location is Life cycle mappings.

Business Criticality in the Service Offering is the correct CSDM attribute because the requirement is prioritization based on business impact. Customer-facing services that affect revenue should be modeled and prioritized according to their business importance, not only by technical ownership or affected infrastructure. In CSDM, Service Offerings represent consumable versions of services and can carry important business context such as audience, availability expectations, and criticality. Business Criticality helps Incident, Change, and operational teams understand which services require faster response because disruption would create greater business or customer impact. Assignment Group is used for routing work, not determining service priority. Service classification in a Technical Service describes the nature of a technical service, not customer-facing business impact. Affected CIs identify technical scope, but they do not directly express revenue or business criticality. Therefore, Business Criticality in the Service Offering is the correct prioritization attribute.