Free Practice Questions for ServiceNow CIS-DF Exam

The Agent Client Collector (ACC) in ServiceNow is designed to collect inventory data from endpoints that are not consistently reachable by traditional Discovery methods. ACC is especially valuable where credential-based, network-based discovery is impractical or impossible.

Devices in secure environments (Option C), such as isolated networks, restricted zones, or highly regulated environments, often block inbound discovery traffic. ACC runs locally on the device and securely sends inventory data outward, making it ideal for these scenarios.

Devices that intermittently connect to the network (Option D), such as laptops, remote endpoints, or roaming devices, are another core use case. Traditional Discovery requires the device to be reachable during scheduled scans, which is unreliable for mobile or off-network assets. ACC ensures inventory data is collected whenever the device is online.

Option A (data center servers) is better served by agentless Discovery, which provides deeper infrastructure and relationship data. Option B (network devices in the DMZ) are typically discovered using SNMP and network discovery, not ACC.

ACC complements Discovery as part of a layered ingestion strategy, ensuring accurate inventory coverage across diverse environments.

Therefore, the correct answers are C – Devices in secure environments and D – Devices that intermittently connect to the network.

Completeness → Required

Compliance → Audit

Correctness → Orphan

The CMDB Health Dashboard helps administrators measure whether the CMDB is trustworthy, usable, and aligned with governance expectations. The three main CMDB Health KPIs are Completeness , Compliance , and Correctness , and each KPI evaluates a different aspect of CMDB data quality.

Completeness focuses on whether required or expected fields are populated on CI records. A CI may exist in the CMDB, but if important fields such as owner, support group, location, serial number, or environment are missing, the record is not complete enough to support operational processes. Therefore, Required belongs under Completeness .

Compliance focuses on whether CIs follow defined rules, policies, and governance requirements. The Audit sub-metric is associated with Compliance because audits check whether records meet expected standards and whether governance controls are being followed.

Correctness focuses on whether the CI data is accurate and logically valid. Orphan belongs under Correctness because an orphan CI lacks expected relationships or context. For example, a server without expected dependencies or service relationships may reduce the accuracy of impact analysis and operational reporting.

The other visible options, such as Stability , Suggested , and Certify , are not the best fit for the three answer slots shown in this question.

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.

A CMDB Data Foundations Dashboard playbook provides a Problem Overview and information about likely Root Causes . The Problem Overview explains the deficient metric, why the condition matters, and the operational or governance risks created by poor performance. The Root Cause material helps administrators identify why the condition exists, such as incomplete source data, incorrect transformations, missing ownership, inappropriate class usage, or weak governance controls.

The guide describes these playbooks as structured, prescriptive guidance for identifying root causes, assessing ingestion and governance gaps, and applying appropriate corrective actions.

Playbooks may recommend analysis, correction, reporting, and governance activities, but they do not normally provide fully automated remediation scripts that should be executed without review. “Problem Analysis” is not the named documentation component tested here; analysis is instead performed through the recommended remediation plays.

=========

Within ServiceNow CMDB governance, Attestation and Data Certification serve distinct but complementary purposes. The key difference lies in what is being validated.

Attestation is focused on existence and ownership confirmation. When a CI is attested, the assigned user or group is asked to confirm that the CI still exists, is still relevant, and is still owned or managed by the appropriate team. No detailed attribute-level validation is required. This lightweight process is commonly used to prevent “ghost CIs” from lingering in the CMDB.

Data Certification, on the other hand, is more rigorous. It requires the certifier to validate specific attributes of the CI, such as lifecycle status, support group, environment, or service relationships. Certification ensures data correctness and completeness, which directly impacts CMDB Health scores and downstream processes like Change and Incident Management.

Options A, B, and C incorrectly describe these mechanisms or their assignment and scheduling capabilities. Both attestation and certification can be scheduled and assigned flexibly, but their validation depth is what truly differentiates them.

Therefore, Option D correctly describes the distinction: attestation confirms existence, while data certification validates CI attributes.

The correct answer is Business Service Offering and Business Service. In CSDM, the Sell/Consume domain represents how services are presented to and consumed by business users, customers, or consumers. Business Services describe the business-facing services delivered by the organization, while Business Service Offerings represent the specific consumable versions of those services, often differentiated by audience, location, service level, availability, or entitlement. Option A belongs more closely to technical service delivery and management, not Sell/Consume. Option B belongs to Design and Planning, where Business Applications, Business Capabilities, and Information Objects are modeled. Since the question specifically asks for the Sell/Consume domain, the correct tables are Business Service and Business Service Offering.

=========

Service Mapping creates and maintains an Application Service by discovering the application’s entry point and tracing its dependencies across the supporting infrastructure. The resulting service map can include application components, servers, databases, middleware, load balancers, and communication relationships. This produces the service-aware topology required for impact analysis, incident investigation, and change-risk assessment.

ServiceNow Discovery identifies infrastructure CIs and can create technical relationships between discovered components, but Discovery alone does not normally build the complete, application-centric service topology requested in the question. Agent Client Collector gathers inventory and telemetry from devices through an installed agent, while Event Management processes and correlates operational events and alerts.

The study material identifies Service Mapping as the capability that builds Application Service topology and shows how services are supported by underlying applications and infrastructure. It also describes top-down Service Mapping as the recommended high-fidelity approach for mission-critical Application Services.

=========

The CMDB plays a critical role in security operations by providing trusted, structured insight into the organization’s IT landscape. When built according to Data Foundations principles—accurate discovery, governed relationships, and alignment to CSDM—the CMDB becomes an essential enabler for security incident response and vulnerability management.

Option D is correct because the CMDB allows security teams to identify exactly which IT infrastructure components are affected by a vulnerability. By correlating vulnerability scan results with configuration items (CIs), security teams can determine whether an issue exists on a server, application, cloud resource, or network device—and understand where that CI sits within the broader service context. This eliminates blind spots and reduces time spent investigating unknown or unmanaged assets.

Option A is also correct because the CMDB supports assessment and remediation activities during security incidents. Once affected CIs are identified, the CMDB provides ownership, support group, environment, and service relationships. This enables security teams to quickly route remediation tasks to the correct resolver groups, assess business impact, and prioritize response based on service criticality. While the CMDB does not perform remediation itself, it enables informed and coordinated action.

Option B is incorrect because vulnerabilities are not auto-resolved by the CMDB; remediation requires human decision-making and execution through security, patching, or change processes. Option C, while related to governance and compliance use cases, is more aligned with GRC and audit functions rather than day-to-day security operations, making it less appropriate for this question.

In summary, the CMDB’s primary value in security operations is visibility and actionable insight, enabling faster identification, assessment, and response to security threats.

Asset Management → Tracks the lifecycle of a CI

Asset Management uses CMDB and asset data to track an item throughout its lifecycle, including procurement, deployment, operation, maintenance, retirement, and disposal. This helps the organization understand both the operational status of the CI and its financial or contractual information.

Event Management → Automates incident creation based on threshold configuration

Event Management collects events from monitoring tools and evaluates them against configured rules and thresholds. When a threshold is exceeded or a significant alert is generated, ServiceNow can automatically create an incident and associate it with the affected CI in the CMDB.

Incident Management → Uses the CMDB to identify and resolve issues faster

Incident Management uses CI records and relationships to determine which component is affected, who supports it, and which services depend on it. This provides technicians with accurate context, enabling faster assignment, troubleshooting, impact assessment, and resolution.

Change Management → Identifies the impact on downstream CIs when planning for an upgrade

Change Management uses CMDB relationships to evaluate the potential impact of a planned change. Before upgrading a server, application, or other CI, the change team can identify dependent and downstream CIs or services that could be affected, reducing the risk of outages or unexpected disruption.

Enhancing Incident Management in ServiceNow often involves integrating complementary products that enrich context, prioritization, and decision-making.

Discovery strengthens incident resolution by automatically populating accurate CI data and relationships, allowing responders to quickly understand affected infrastructure and applications.

Hardware Asset Management (HAM) adds visibility into asset lifecycle, ownership, and maintenance actions, which is especially valuable when incidents involve physical devices or failures.

Risk Management (part of IRM) provides insight into business and financial risk exposure, helping teams prioritize incidents based on potential regulatory, safety, or financial impact.

Service Portfolio Management (SPM) connects incidents to the service lifecycle, enabling better understanding of whether an incident affects a live, retiring, or planned service—and improving communication with stakeholders.

Together, these integrations transform Incident Management from a reactive process into a context-rich, business-aligned capability.