ServiceNow CIS-DF Certified Implementation Specialist - Data Foundations (CMDB and CSDM) Exam Practice Test

In CMDB governance, different CMDB Data Manager policy types serve different validation and enforcement purposes. When the objective is to allow an assigned individual to review and update specific fields on a CI record, the correct policy type is Certification.

A Certification policy creates actionable tasks that require the assignee to validate and, if necessary, correct specific CI attributes, such as lifecycle status, support group, environment, or ownership. During certification, the user can directly update CI fields to bring the record into compliance with defined standards.

Attestation (Option C) only asks the user to confirm that a CI still exists or is still valid; it does not require or enable attribute-level updates. Audit (Option A) is used for reporting and evidence collection, not remediation. Compliance (Option D) measures adherence to rules but does not itself generate editable remediation tasks.

Certification is therefore the primary mechanism used when human validation and correction of CI data is required—making it a cornerstone of CMDB data quality management.

Hence, the correct answer is B – Certification.

Creating a custom CI class in the CMDB is a dictionary-level configuration activity and must be performed with the correct minimum privileges to ensure governance and upgrade safety in ServiceNow.

The sn_cmdb_admin role is required because it grants administrative access to CMDB structures, including CI class hierarchy management. This role ensures that changes align with CMDB governance controls and Data Foundations practices.

The personalize_dictionary role is also required because adding a new CI class involves creating or extending dictionary entries (tables, attributes, inheritance). Without dictionary-level access, a user cannot define new classes or attributes in the CMDB schema.

Option A is incorrect because sn_cmdb_admin alone is insufficient without dictionary privileges. Option B and D focus on form personalization, which affects UI layout only and does not allow creation of new CI classes. Additionally, itil_admin is not the correct role for schema-level CMDB changes.

Therefore, the minimal and correct role combination is sn_cmdb_admin and personalize_dictionary, making Option C the verified answer.

CI Class Manager provides a centralized interface for reviewing and configuring the characteristics of each CMDB class. It includes class hierarchy information, attributes, identification rules, reconciliation settings, suggested relationships, principal-class configuration, and related governance information.

Identification rules define the attributes that IRE uses to determine whether incoming data matches an existing CI or should create a new record. Reconciliation settings identify which sources are authorized or prioritized for updating particular attributes. These capabilities allow an administrator to document the authoritative sources and identification criteria for principal CI classes in one management interface.

The CMDB Data Foundations Dashboard identifies foundational quality risks, while CMDB Data Manager controls lifecycle policies. CMDB Workspace is the broader operational interface, but CI Class Manager is the specific tool for class-level configuration and identification governance.

=========

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.

In Data Foundations, “Ingest” is not limited to Discovery. It includes establishing reliable sources and mechanisms to populate and maintain CMDB attributes—especially those that Discovery cannot provide. Warranty expiration dates are a classic example of non-discoverable data: they typically come from procurement systems, asset repositories, vendors, or contract tools rather than from device interrogation.

The correct approach is to maintain these attributes via a scheduled data import from an authoritative external source. This ensures ongoing accuracy and consistency at scale. A scheduled import allows you to define a repeatable integration pattern, apply data quality checks, and keep warranty data current as vendors and procurement records change—without relying on manual updates that inevitably drift over time.

Option A is incorrect because the CMDB Reconciliation Engine resolves conflicts between multiple data sources and applies precedence rules; it does not create the warranty values out of thin air. Reconciliation helps decide which source wins when updates occur, but you still need a source feed providing the warranty attribute values. Option B is also not recommended because creating a new CI class just to hold non-discoverable attributes fragments the model and complicates reporting and processes. Best practice is to keep the attributes on the appropriate hardware CI classes (or related normalized structures, when applicable) and manage them through governed ingestion from authoritative systems. Therefore, C is the best method.

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.

In ServiceNow, duplicate CI management spans detection, insight, and remediation:

The CMDB Health Dashboard – Correctness surfaces where duplicates exist and their impact, providing visibility and prioritization.

Certification Tasks support governed resolution, allowing assignment to individuals or groups to validate and correct data.

De-duplication Templates enable bulk remediation, ideal when standardized merge rules can be applied across many duplicates.

The Duplicate CI Remediator offers a guided, record-by-record wizard, preserving relationships and history for safer individual resolutions.

De-duplication Tasks are the work items generated by these processes, but they do not themselves represent an outcome—hence not applicable .

This mapping aligns with CMDB Data Foundations best practices, ensuring duplicates are identified, prioritized, and remediated efficiently and safely.

Creating new CI classes is a high-impact configuration activity and must follow strict Data Foundations and CSDM-aligned best practices to avoid long-term technical debt and upgrade risk.

Option B is a recommended first step. Before creating any new CI class, administrators should install or update the CMDB CI Class Models Store application and verify whether an appropriate class already exists. ServiceNow frequently delivers new CI classes through updates and class model packages, and duplicating an existing or planned class can lead to fragmentation and governance issues.

Option C is also correct. When a new class is truly required, it should be added under an appropriate parent class to inherit attributes, behaviors, and discovery patterns. For an IoT Sensor, this might be under a hardware or device-related parent class, ensuring consistency and minimizing customization.

Option A is incorrect and dangerous—deleting unused classes can break dependencies and historical data. Option D is also discouraged; modifying existing classes to repurpose them violates upgrade-safe design principles and can negatively impact discovery, integrations, and reporting.

By verifying existing models first and extending the class hierarchy correctly, organizations maintain a clean, scalable, and upgrade-safe CMDB.

Therefore, the correct answers are B and C.

The correct answer is C. Service Graph Connectors are ServiceNow-supported integrations when used as delivered or configured within supported boundaries. When an administrator customizes the mappings, the implementation moves away from the supported out-of-box connector behavior. This creates upgrade and support implications because ServiceNow cannot guarantee that customized mappings will remain compatible with future connector updates. The customer becomes responsible for validating, maintaining, and troubleshooting those customizations. Option A is not the primary consequence because customized fields are not simply protected by a special CMDB tag. Option B is incorrect because custom mapping does not automatically block connector execution pending approval. The key risk is supportability and technical debt, making C the correct answer.

=========

CI Analyst → Manages assigned CI tables, keeps records updated, and resolves tasks related to CMDB records

Service or Product Owner → Accountable for managing all elements that make up a portfolio throughout their entire lifecycle

Configuration Manager / CMDB Admin → Obtains the highest-level role for CMDB privileges

CMDB Process Owner → Has read-only access to CMDB data and to basic user interfaces such as CMDB reports and dashboards

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.

Agent Client Collector (ACC) → Collects inventory and telemetry from devices using an installed agent, especially where agentless discovery is not practical.

ServiceNow Discovery → Automatically identifies devices and applications on the network and populates the CMDB with accurate, up-to-date information.

Service Graph Connectors → Facilitates integration between ServiceNow and external systems to import and synchronize CMDB data.

Service Mapping → Builds the complete topology of services and shows how they are supported by underlying infrastructure and applications.

Each ingestion product has a specific role in CMDB Data Foundations. ServiceNow Discovery is primarily agentless and discovers infrastructure, applications, and relationships across the network. Agent Client Collector is agent-based and is useful for devices that are intermittently connected, remote, restricted, or difficult to scan through traditional Discovery. Service Graph Connectors are prebuilt, governed integrations used to bring third-party data into the CMDB while aligning with IRE and ServiceNow class models. Service Mapping focuses on service topology by identifying how application services depend on infrastructure and application components. The key distinction is that Discovery and ACC collect technical inventory, Service Graph Connectors integrate external sources, and Service Mapping builds service dependency models.

=========

CMDB Data Manager supports multiple governance policy types because CMDB lifecycle management is broader than simply deleting or certifying records. The complete set represented here is Retire, Archive, Attestation, Certification, and Delete. Retire policies support lifecycle transition of CIs that should no longer be active. Archive policies remove records from active operational use while preserving them according to retention requirements. Delete policies permanently remove records when they no longer need to be retained. Attestation policies validate that a CI still exists or is still relevant. Certification policies require users to validate and potentially correct specific CI attribute values. Options B, C, and D are incomplete because each omits at least one major CMDB Data Manager policy type. Option A is therefore the best answer because it includes both lifecycle/removal policy types and validation-focused policy types.

In ServiceNow, CMDB 360 / Multisource CMDB extends the Identification and Reconciliation Engine (IRE) to support multi-source visibility, reconciliation, and confidence scoring. Configuration is controlled through system properties, each enabling a specific capability.

glide.identification_engine.multisource_enabled is the master switch that activates CMDB 360 functionality.

glide.identification_engine.multisource_cmdb_ci_enabled allows CMDB 360 to collect and evaluate data specifically from CMDB CI classes.

glide.cmdb.logger.source.cmdb_multisource enables detailed logging for troubleshooting multisource ingestion and reconciliation.

glide.identification_engine.multisource_recompute.max_ci_limit protects performance by limiting how many CIs can be processed during a recompute operation.

Capturing CMDB 360 data from non-CMDB classes is not supported, which is why no property applies to that option.

This mapping aligns with Data Foundations and CMDB governance best practices, ensuring CMDB 360 is enabled safely, transparently, and at scale.

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 approach is controlled consolidation rather than preserving unnecessary custom classes or deleting records indiscriminately. CI Class Manager should be used to review the class hierarchy, identify suitable out-of-box ServiceNow classes, and govern the target data model. The existing CIs should then be moved or reclassified into those standard classes, with custom attributes mapped carefully to corresponding standard or approved extended attributes.

Retaining fragmented classes preserves the exact reporting and integration problems described in the scenario. Deleting the custom classes and manually recreating every CI is unnecessarily destructive and risks losing relationships, historical references, source information, and task associations.

Data Foundations recommends using existing supported classes wherever possible and extending an appropriate class only when the required model does not exist. Standardized classes improve inheritance, reporting, identification, reconciliation, Discovery integration, and upgrade compatibility.

=========

The organization should use a CMDB Query to identify application services and their related infrastructure because those records are CMDB classes and relationships. CMDB Query Builder is designed to traverse CMDB relationships, such as application services to databases, servers, and supporting infrastructure. Since the requirement also includes incidents, the query must include a non-CMDB table because Incident is a task/process table, not a CMDB CI class. That is why adding a non-CMDB table to the query is required. A Service Mapping Query is not the correct approach for adding Incident data; Service Mapping is used to discover and visualize service topology, not to build mixed CMDB and task-table analytical queries. Therefore, the correct steps are using a CMDB Query for application services and infrastructure, then adding the non-CMDB Incident table.

=========

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 Design and Planning domain of CSDM focuses on planning-level constructs such as Business Applications, Business Capabilities, Information Objects, and architecture context. The two roles most directly involved are the Application Owner and the Enterprise Architect . Application Owners provide authoritative ownership, lifecycle, criticality, and portfolio information for Business Applications. Enterprise Architects define and govern enterprise capabilities, application rationalization, architecture alignment, and strategic planning relationships. Application Service Owners are more closely aligned with operational service delivery and application service health, especially in the technical/manage domain. Business Relationship Managers are more closely tied to consumption, offerings, and business-facing service value. Because Design and Planning is about application portfolio and enterprise architecture structure, the correct roles are Application Owner and Enterprise Architect.

=========

A CMDB delivers business value when it enables better outcomes across IT and enterprise service delivery—especially when aligned with CSDM so services, offerings, and supporting technology are connected in a consumable model. Two major business values are improved operational execution and improved business continuity.

Option C is a direct business value: a trusted CMDB improves incident and change management by providing accurate CI details, relationships, and service context. This supports faster triage and assignment, better prioritization, and higher-quality impact analysis for changes. When incidents and changes are informed by dependable configuration data, organizations reduce downtime, avoid unnecessary escalations, and make safer change decisions—benefits that the business experiences as higher service quality and fewer disruptions.

Option D is also a core business value: CMDB strengthens operational resiliency by enabling clearer dependency understanding and faster response to failures. Resiliency improves when teams can quickly identify what’s impacted, understand upstream/downstream relationships, and plan mitigation steps using known service-to-technology mappings. In regulated or mission-critical environments, this translates into better continuity, reduced risk exposure, and improved compliance reporting.

Option A can be beneficial, but it is more of a technical/operational mechanism than a primary “business value” statement in Data Foundations framing. Option B is primarily the domain of IT Asset Management and financial systems; while CMDB can relate to assets, it is not the system of record for financial management. Hence, the best two business values are streamlining incident and change management and strengthening operational resiliency.

The CMDB Data Manager is the ServiceNow capability responsible for generating actionable governance tasks and assigning them to CI class owners and data stewards. These tasks appear directly in the “My Work” tab within the CMDB Workspace, enabling proactive and role-based CMDB governance.

CMDB Data Manager focuses on data lifecycle management, including archival, retirement, and cleanup of CIs based on defined policies. When lifecycle rules or retention thresholds are met—or when human validation is required—the Data Manager creates tasks to prompt responsible owners to take action. This ensures that CMDB data remains accurate, compliant, and lean over time.

The CMDB Health Dashboard (Option C) provides visibility into health metrics such as completeness, correctness, and compliance, but it does not generate tasks. Similarly, De-duplication templates (Option A) support duplicate identification and remediation workflows, but they do not create ongoing governance tasks in the CMDB Workspace.

By surfacing tasks in “My Work,” CMDB Data Manager operationalizes governance and embeds accountability into daily workflows, which is a key principle of CMDB Data Foundations.

Therefore, the correct answer is Option B – CMDB Data Manager.

Service Graph Connectors are predefined, vendor-specific integrations that import and synchronize external data with the ServiceNow CMDB. They are generally delivered through the ServiceNow Store and use standardized mappings, supported class models, source tracking, and Identification and Reconciliation Engine processing. This reduces the amount of custom scripting and transformation logic required to integrate third-party platforms.

Agent Client Collector is an agent-based inventory and telemetry collection mechanism. IRE identifies incoming CIs and controls how authorized sources update CMDB attributes, but it is an underlying data-processing engine rather than a packaged external-system integration. Service Mapping discovers and models Application Service dependencies; it is not a library of predefined third-party connectors.

The Data Foundations material describes Service Graph Connectors as prebuilt Store integration solutions requiring minimal customization. It also identifies them as the preferred method for third-party CI ingestion when minimizing technical debt and maintaining upgrade compatibility are priorities.

=========

Discovery and Service Mapping are the correct answers because both capabilities can automatically create CMDB relationships that support Application Services. ServiceNow Discovery identifies infrastructure, applications, running processes, and dependencies in the environment. During discovery, it can create technical relationships between discovered CIs, such as servers, applications, databases, and other supporting components. Service Mapping extends this further by building application service topology, identifying how application components interact, and creating the relationship model that connects CIs into an Application Service. These relationships are essential for impact analysis, change risk assessment, incident correlation, and service-aware operations. Event Management does not create application-service CI relationships; it correlates operational events and alerts. Data Manager governs lifecycle, attestation, certification, archival, retirement, and deletion policies, but it does not discover application topology. IntegrationHub ETL can ingest and transform external CMDB data, but it does not automatically discover service relationships in the same way Discovery and Service Mapping do. Therefore, Discovery and Service Mapping are the ServiceNow solutions that automatically create these relationships.

The CMDB Health Dashboard is available as part of the ServiceNow CMDB capability and does not need to be separately downloaded from the ServiceNow Store or enabled through a special dashboard system property. The dashboard framework is available by default for authorized users. However, this question is specifically asking what must be done to start using the dashboard, not what is required to refresh calculated scores. Health calculations and score updates depend on scheduled jobs, but the dashboard itself is not something the administrator downloads or separately installs. Option A is a common trap: scheduled jobs are needed to generate current health scores, but they are not the action required to activate or obtain the dashboard. Therefore, the best answer is that nothing additional is required because the dashboard is activated by default.

=========

The Assignment Group attribute on the CI provides the operational routing information needed to direct work to the responsible technical team. When the affected CI is associated with the change, governed group information from the CMDB can be used to populate or determine the appropriate assignment group, reducing manual routing and preventing the change from being assigned incorrectly.

The Approval Group serves a different purpose: it identifies a group responsible for approval decisions rather than the team that performs the work. A Service Offering can provide service, environment, entitlement, or consumption context, but it does not by itself identify the resolver group for this question. Service Subscriptions identify service consumers and are not task-assignment mechanisms.

A trusted CMDB therefore improves Change Management by supplying accurate ownership and group information, enabling dynamic routing and clearer accountability.

=========

The correct answer is Use the CMDBTransformUtil API in the transform script . Import Sets and Transform Maps can create duplicate CIs if they write directly into CMDB tables without routing the data through the Identification and Reconciliation Engine. The CMDBTransformUtil API is used in transform scripting to process incoming CI data through the CMDB identification and reconciliation logic. This allows ServiceNow to evaluate existing CIs using configured identification rules and then update the correct CI rather than creating a duplicate record. Coalesce rules are not sufficient for CMDB ingestion because they rely on simple field matching and do not apply the full IRE logic. “Comparison rules” is not the correct mechanism. A system property alone is also not the recommended implementation pattern for vendor shipment import data. Therefore, CMDBTransformUtil is the correct method to prevent duplicate CI creation through import sets.

In Data Foundations, “insight” focuses on turning trusted configuration data into clear visual understanding—so teams can assess relationships, troubleshoot impact, and validate service context. Unified Map supports this by providing a graphical view of CIs and their relationships, combining strengths of traditional dependency views and service-mapping-style visualization into a single, consistent map experience.

Unified Map is accessed from CMDB Workspace, typically via a Quick Links entry (and in some experiences, also from relevant CI/service contexts). This location makes sense in the Data Foundations model because CMDB Workspace is the central place where configuration and service data is explored, validated, and used for operational decision-making—exactly what mapping relationships is meant to enable.

The other options do not fit the purpose or access pattern. CI Class Manager is focused on defining and maintaining CI class structures and related class settings; it is not the user entry point for relationship visualization. CMDB Data Manager is focused on governance through lifecycle policies (attestation, archival, deletion) and bulk lifecycle operations—again, not the primary interface for interactive mapping and dependency exploration.

Therefore, for a Configuration Manager seeking to use Unified Map for relationship and dependency insight, the correct access point is CMDB Workspace.

The correct answer is 75 because the Windows Server class has its own dynamic reconciliation rule configured as most reported for the Disk Space field. Even though the parent Server class uses the lowest value rule, the more specific class rule on Windows Server takes precedence for Windows Server records. In CMDB 360 / Multisource CMDB, dynamic reconciliation evaluates values from multiple contributing sources and selects the value according to the configured reconciliation strategy. Here, 75 GB is reported by two sources: Thycotic and ServiceNow. The other values, 50 GB and 80 GB, are each reported only once. Because the rule is “most reported,” the value appearing most frequently across sources is selected. Therefore, 75 GB is added to the CMDB.

=========

CI Class Manager is used to configure class-level health requirements, including attributes designated as required or recommended for a selected CI class. The administrator can identify Support Group and Managed By Group as recommended attributes for the Linux Server class. Recommended fields provide operational and diagnostic value even when they are not technically mandatory for inserting a CI.

Health Preferences control how CMDB Health findings are processed, including task-generation behaviour for CIs that fail applicable health conditions. Once the health calculations identify operational Linux servers with missing recommended values, remediation tasks can be generated and assigned for corrective action. The guide confirms that task behaviour for unhealthy CIs is governed through the relevant health metric configuration rather than through the dashboard itself.

Technical Service Offerings and Dynamic CI Groups can populate and synchronize group values, but they are not the modules used to define recommended-field health checks and generate health tasks. Therefore, B is correct.

=========

CMDB Data Manager is the governance capability designed to control the lifecycle of CI records through policy-driven actions. Its policy types include Retire, Archive, Delete, Attestation, and Certification. These policies enable obsolete or no-longer-relevant records to be identified and processed consistently rather than removed through uncontrolled scripts or manual cleanup.

Archive policies remove eligible records from active operational use while retaining them for a defined recovery or compliance period. Delete policies permanently remove records after applicable lifecycle and retention requirements are satisfied. Retire policies transition CIs out of active operational status. The guide identifies automated archival and deletion according to retention policies as a primary purpose of CMDB Data Manager.

The CMDB Health and Data Foundations dashboards identify problems but do not perform lifecycle removal themselves. CI Class Manager governs classes, while de-duplication templates address duplicates specifically. Therefore, B is correct.

=========

In Data Foundations for CMDB and CSDM, a dashboard indicator (like “Services Have Owners Identified”) highlights a data quality condition—in this case, Services missing required ownership information. The playbook-driven remediation model typically follows a practical sequence: first you identify and validate the scope of the issue, then you correct the underlying records so the metric improves and remains sustainable.

The Analyze Data play is used to break down what the dashboard is reporting into actionable detail. It helps determine which Service records are failing the ownership requirement, what ownership fields are missing (for example, service owner / business owner / technical owner depending on configuration), and where the gaps are concentrated (by business unit, environment, lifecycle stage, or service portfolio segment). This ensures the remediation effort targets the correct records and avoids inaccurate assignments.

The Fix Data play is used to perform the actual remediation—populating or correcting the owner attributes on the Service records so accountability is clear and operational processes can route approvals, escalations, and service decisions correctly. In CSDM terms, clearly assigned owners enable proper stewardship of Service Portfolio and Service Offerings and improve downstream outcomes such as incident assignment accuracy, change impact analysis, and reporting reliability.

While Govern Data supports preventing recurrence (policies, controls, ownership model, and stewardship routines) and Report Data communicates progress, the two plays directly used to remediate the dashboard issue are Analyze Data and Fix Data.

Information Objects in CSDM are used to represent logical data associated with Business Applications. They are especially important for governance, compliance, privacy, and audit use cases because they describe the type of data a Business Application processes, stores, or transmits. For example, if an application handles personal data, payment card data, or regulated healthcare information, that logical data context should be modeled as an Information Object and related to the Business Application. Option A is too broad and incorrectly frames the object as general data for a group of CIs. CIs represent technical components, while Information Objects describe logical business data. Option B is too narrow because API exchange data is only one possible technical integration scenario and does not define the purpose of the CSDM artifact. Therefore, the correct purpose is to describe logical data related to Business Applications.

The Dynamic CI Group must be populated in the Configuration Item field on the Change Request form. A Dynamic CI Group represents a rule-based group of CIs, such as all Windows servers or all CIs matching a specific operational condition. When a Change needs to apply across multiple CIs, referencing the Dynamic CI Group in the Configuration Item field allows the platform to associate the Change with the relevant CI population. Service Offering and Business Service describe service context, but they do not represent the target CI group for the technical change. The Configuration Item field is the correct field because Change Management operates against affected configuration items and their dependencies. Therefore, C is correct.

=========

Data Refresh Rules allow a lower-priority source to update an attribute when the higher-priority authoritative source has not refreshed that attribute within a configured period. This prevents CI data from remaining indefinitely outdated merely because the preferred source has stopped reporting.

Reconciliation rules establish the normal source priority and determine which authorized source wins when multiple sources report values for the same attributes. The guide confirms that source precedence is assigned through reconciliation rules. Data Refresh Rules supplement that precedence by defining a freshness exception: after the higher-priority source becomes inactive for the configured interval, a lower-priority source may supply a more current value.

Identification Rules determine whether an incoming payload matches an existing CI. Health Inclusion Rules control which CIs participate in CMDB Health calculations. Neither addresses temporary source inactivity or freshness-based update authorization.

=========

Custom CMDB class tables should begin with u_cmdb_ci . The u_ portion identifies a customer-created table, while cmdb_ci preserves the standard CMDB naming convention and clearly indicates that the table extends the Configuration Item hierarchy.

For example, appropriate custom class names may resemble u_cmdb_ci_custom_router or u_cmdb_ci_special_switch. The uploaded guide uses these exact naming patterns when discussing custom-class consolidation and the technical debt created by unnecessary custom classes.

Using only cmdb_ci would incorrectly suggest an out-of-box ServiceNow table. Prefixes such as u_ci_cmdb and ci_cmdb do not follow the standard hierarchy convention. Before creating any custom class, the administrator should still verify that a suitable supported class is not already available through the CMDB CI Class Models application.

=========

A Business Application represents a logical application from a portfolio, ownership, investment, risk, and lifecycle perspective. Following an acquisition, Business Application records allow the combined organization to compare overlapping applications, identify redundant functionality, establish authoritative application ownership, and decide which applications should be retained, consolidated, migrated, replaced, or retired.

An Application Service represents a deployed and operational instance of an application, such as a production or development service. The Application class represents executable software components running on infrastructure, while Incident is a process record and not part of application portfolio modelling.

Business Applications belong to the CSDM Design and Planning domain and support application portfolio management and rationalization. Therefore, they are the appropriate records for unifying and evaluating the applications inherited through the acquisition.

=========

The correct answer is C . In CSDM and Application Portfolio Management, a platform should be modeled as a Business Application with the architecture type Platform Host . Applications that run on or are provided by that platform should be modeled as Platform Applications and should reference the platform host. In this scenario, the ServiceNow Platform is the platform host, while Incident and Change are platform applications because they are capabilities delivered on the ServiceNow Platform. The relationship is not best represented by making all three applications generic web-based applications. That would lose the platform/application distinction. The preferred model is also not simply a Depends On relationship, because CSDM provides a more specific platform host reference model for this use case. Therefore, ServiceNow Platform should be Platform Host, and Incident and Change should be Platform Applications referencing ServiceNow Platform.

=========

The CMDB is a foundational capability that enables organizations to operate IT services with confidence, resilience, and efficiency. Its value lies not in automation for its own sake or financial data management, but in how it supports service-aware operations and decision-making.

Strengthening operational resiliency (Option A) is a core value of the CMDB. By maintaining accurate configuration data and relationships, organizations can better understand dependencies, assess risk, and recover more quickly from incidents or outages. A trusted CMDB enables proactive problem management and informed change planning, directly contributing to resiliency.

Streamlining Incident and Change Management (Option B) is another primary value. Accurate CI data allows incidents to be routed automatically to the correct support groups, enables faster root-cause analysis, and supports risk-based change assessments. This reduces manual effort, improves response times, and lowers operational risk.

Option C is incorrect because automating CI relationship maintenance is a capability enabled by tools like Discovery and Service Mapping—not a value in itself. Option D is also incorrect because financial data management is the domain of IT Asset Management (ITAM) and Financial Management, not the CMDB’s core value proposition.

In summary, the CMDB delivers value by improving operational resilience and optimizing ITSM processes, making Options A and B the correct answers.

The correct answer is Certification because the team is validating a specific CI attribute or relationship: whether each server is correctly associated with its location. Data Certification is used when assigned users must review and validate specific field values on CI records, such as location, support group, lifecycle status, environment, or ownership. If incorrect, the certifier can update or correct the data. Attestation would be correct only if the question asked users to confirm that the CI still exists or is still valid in general. This question is more precise: the location association must be confirmed, which is an attribute-level validation requirement. Delete, Archive, and Retire are lifecycle policy types used to remove, archive, or transition records, not validate field accuracy. Therefore, Certification is the correct CMDB Data Manager policy type.

=========

The Correctness scorecard evaluates whether CI data accurately represents the real environment. It includes the Duplicate , Orphan , and Staleness metrics.

Duplicate identifies cases where the same real-world configuration item is represented by multiple CMDB records. Orphan identifies CIs that lack expected relationships or supporting context. Staleness identifies records that have not been updated within the configured period and may no longer represent active infrastructure.

The other choices belong to different CMDB Health KPIs. Audit belongs to Compliance because it evaluates whether CI values satisfy defined standards or desired-state conditions. Required and Recommended belong to Completeness because they measure whether mandatory and useful attributes are populated.

Therefore, Duplicate, Orphan, and Staleness are the metrics shown under Correctness.

=========

In Data Foundations, “Govern” is about putting repeatable, controlled mechanisms in place to keep CMDB data healthy over time. Duplicate CI cleanup is a governance activity because duplicates degrade trust, break reporting, create incorrect service impacts, and cause operational confusion (for example, incidents linked to the wrong CI). The preferred approach is to use the guided and purpose-built de-duplication experience designed for CMDB administrators rather than relying on generic task lists or ad-hoc work.

The de-duplication dashboard in CMDB Workspace is the preferred place because it centralizes duplicate identification, prioritization, and remediation in a single operational experience. It typically provides visibility into suspected duplicates, helps users review records side-by-side, and supports controlled actions (such as merge/retire workflows, depending on configuration) while maintaining auditability. This aligns with Data Foundations’ emphasis on standard processes and consistent remediation patterns rather than one-off manual fixes.

“My Tasks” is a generic work queue and does not provide the purpose-built context or tooling required to confidently resolve duplicates in a safe, repeatable way. A standalone “de-duplication task module” may exist as a navigation entry, but the recommended operational method is to use the workspace dashboard where duplicate remediation is organized and guided as part of CMDB health and governance. Therefore, the correct answer is the de-duplication dashboard on CMDB Workspace.

In the CMDB Health Dashboard, the format Healthy CIs / Evaluated separates two different meanings. The Evaluated value represents the total number of CIs included in the metric calculation scope. The Healthy CIs value represents how many of those evaluated CIs passed the metric. In this question, 60,000 server records were evaluated for the Duplicate metric, so 60,000 server records are in scope. Of those, 59,000 are healthy, meaning they are not considered duplicate according to the duplicate evaluation logic. The remaining 1,000 are not healthy for that metric and require investigation or remediation. Option B incorrectly treats the healthy count as the scope. Option C identifies the unhealthy difference, not the evaluated scope. Option A invents a Linux/Windows breakdown that is not provided by the scorecard. Therefore, the evaluated scope is 60,000 server records.

The correct answer is Data Quality Scheduled Job because CMDB data quality checks are not simply visual or manual activities. Scheduled jobs are used to execute recurring evaluations that calculate and refresh quality indicators for CI records. These jobs support CMDB health and data quality by periodically checking records against configured rules, such as stale records, missing required attributes, compliance conditions, or correctness-related metrics. CMDB Workspace is the interface where users can review and act on CMDB information, but it is not itself the mechanism that performs scheduled quality evaluation. Business rules can enforce logic during insert or update actions, but they are not the normal mechanism for recurring CMDB data quality calculation. Therefore, the Data Quality Scheduled Job is the best answer.

=========

The Crawl stage establishes the initial CSDM foundation and design information required to create a usable CMDB. This includes identifying applications, their ownership, associated Application Services, foundational reference data, and essential relationships.

The Application Owner provides authoritative information concerning the Business Application, including ownership, lifecycle, criticality, purpose, and portfolio context. The Application Service Owner provides operational knowledge about the deployed Application Services, their environments, support arrangements, and relationships to underlying CIs.

The guide explains that Crawl addresses the Foundation and Design domains. Foundation establishes organizations, locations, users, groups, products, and core CI information, while Design introduces Business Applications, capabilities, processes, Information Objects, ownership, and architecture context.

Business Service Managers and Technology Service Owners become more central as business-facing and technical services mature during later stages. Customer Service Managers are primarily associated with service consumption. Therefore, B is correct.

=========

This scenario hinges on how the Identification and Reconciliation Engine (IRE) in ServiceNow evaluates identification rules.

The identification rule for the Apache Web Server class includes Version as part of the identifier criteria, along with Class and Configuration file. Identification rules must match all criterion attributes exactly for an incoming record to be identified as an existing CI and reconciled.

Yesterday’s discovery created an Apache Web Server CI with a specific version value. When Apache is upgraded and discovery is rerun, the Version attribute changes. Because Version is part of the identifier, the incoming record no longer matches the existing CI’s identifier entry. As a result, the IRE cannot identify the existing CI as the same configuration item.

When identification fails and no matching identifier entry is found, the IRE proceeds to insert a new CI record rather than updating the existing one. This behavior is intentional and protects the CMDB from incorrectly reconciling records that no longer meet identification criteria.

Option A is incorrect because reconciliation only occurs after successful identification.

Option C is incorrect because reclassification is unrelated to identification criteria.

Option D is incorrect because this is not an error condition; it is expected IRE behavior.

This example highlights a best practice caution: volatile attributes (such as Version) should generally not be used as identifier attributes, as they can cause unintended CI duplication during upgrades.

The fastest and most supportable time-to-value option is the SCCM Service Graph Connector . Service Graph Connectors are purpose-built integrations for bringing third-party source data into the CMDB using ServiceNow-supported mappings, Identification and Reconciliation Engine processing, source tracking, and standardized class alignment. For SCCM specifically, the SCCM Service Graph Connector avoids the technical debt of building custom JDBC imports, transform maps, and scripts. Import sets and transform maps can work, but they require more implementation effort and create higher risk if IRE is not correctly invoked. IntegrationHub ETL with RTE is a stronger pattern than raw imports, but for SCCM the dedicated Service Graph Connector is still the fastest and most governed solution. SCCM Usage Metering Spoke is not the CMDB ingestion tool for Windows computer CI data. Therefore, D is correct.

Agent Client Collector

Automated agent-based solution running patterns

Import Sets

Organization-built solution using transform maps

Service Graph Connector

Pre-built store integration solutions that require minimal customization

ServiceNow Discovery

Automated agentless solution running patterns

Agent Client Collector: This is ServiceNow ' s agent-based approach. It requires a software agent to be installed on the target host to run discovery patterns locally.

Import Sets: This is the traditional, manual way to bring in data. You define the source, and the organization builds the logic (Transform Maps) to move that data into the CMDB.

Service Graph Connector: These are found in the ServiceNow Store. They are " certified " integrations built to work with specific third-party vendors (like SCCM or Jamf) with minimal setup.

ServiceNow Discovery: The classic agentless method. It probes the network and uses patterns to identify and map CIs without needing software installed on every machine.

The CMDB Data Foundations Dashboard identifies foundational CMDB data-quality deficiencies, including hardware CIs that lack important identification attributes such as serial numbers. A missing serial number is particularly serious because serial number is commonly included in Hardware identification rules. Without it, Discovery and external integrations may fail to match an incoming device to its existing record, resulting in duplicate CIs.

The dashboard exposes the affected population and provides remediation playbooks that help administrators analyse the responsible data sources, correct existing records, and establish controls to ensure that serial numbers continue to be populated.

CI Class Manager is used to configure class structures and identification rules, but it is not the dashboard used to locate the full population of affected CIs. CMDB Data Manager governs lifecycle policies, while the CSDM dashboard focuses on service-model alignment.

=========

The Identification and Reconciliation Engine (IRE) is a core platform capability in ServiceNow and does not require CMDB 360 / Multisource CMDB to function. Even without the ITOM Discovery license, organizations can still define and use IRE reconciliation rules across multiple data sources.

IRE rules are source-aware and can evaluate attributes based on source precedence, regardless of whether CMDB 360 is enabled. CMDB 360 enhances visibility, governance, and monitoring of multiple sources, but it is not a prerequisite for reconciliation logic itself.

Option A is incorrect because purchasing ITOM Discovery is not mandatory to use multisource reconciliation. Option C is also incorrect because CMDB 360 / Multisource CMDB is a licensed add-on, not a universally available platform feature.

Therefore, the Data Owner can proceed by configuring IRE reconciliation rules directly, making Option B the correct answer.

The default staleness threshold is 60 days . A CI is considered stale when it has not been updated within the applicable staleness interval. The update may normally come from Discovery, Agent Client Collector, Service Graph Connectors, IntegrationHub ETL, or another governed source.

Staleness is important because an old CI record may no longer represent the actual environment. Stale data can distort service-impact analysis, misdirect incidents, undermine change-risk calculations, and generate inaccurate operational reports. The guide identifies stale CIs as a core CMDB data-quality condition monitored through CMDB Health.

The 60-day value is the default, not an immutable platform rule. Administrators can configure appropriate thresholds by CI class and organizational requirements. Frequently changing cloud resources may require a shorter period, while stable infrastructure may justify a different governed interval.

CMDB Data Foundations Dashboard playbooks explain why a deficient metric matters and provide recommended actions for improving it. This includes insight into downstream consequences such as duplicate creation, inaccurate assignment, unreliable impact analysis, weak service context, incorrect reporting, or ineffective Incident, Change, and Security Operations processes.

The playbooks also provide remediation options. These guide administrators through analysing affected records, identifying responsible data sources, correcting existing data, and introducing governance controls to prevent the condition from returning. The guide describes remediation playbooks as structured guidance for analysing issues and implementing targeted corrective actions.

They are not automatically executed scripts. Human analysis, source correction, ownership decisions, and governance changes are generally required. They are also more than generic remediation templates because their value includes contextual impact information and metric-specific recommendations.

Therefore, the two stated benefits are downstream-impact insight and remediation options, making B and D correct.

=========

In Data Foundations, “govern” is not only about defining standards—it also includes implementing repeatable controls that keep CMDB data clean over time. CMDB Data Manager is the ServiceNow capability built specifically for policy-driven CI lifecycle operations such as deletion, archival, and attestation. Rather than relying on one-off scripts or manual cleanup, Data Manager applies consistent lifecycle rules at scale, which is a core expectation of CMDB Data Foundations governance.

The place to administer these lifecycle policies is within CMDB Workspace, under the Management area, where the Data Manager tools expose a dedicated Policies experience. From there, a Data Manager can create new policies, publish them, and manage existing policies used to automate lifecycle processing. This aligns with the intent of “keeping the CMDB healthy and efficient” because it operationalizes governance through automated, standardized actions and controlled approvals where needed.

By contrast, CI Class Manager is primarily for managing CI class definitions and class-level settings (for example, class configuration related to identification, reconciliation, and health rules), not for publishing CI lifecycle automation policies. “CMDB 360” is oriented toward exploring CI/service context, and “Service Operations Workspace” is designed for operational workflows rather than CMDB lifecycle policy administration.

The correct option is Allow fallback to parent’s rules . In CI identification, ServiceNow evaluates the configured identification rule for the target class first. If the Tomcat rule cannot find a match using its class-specific criterion attributes, fallback behavior allows the Identification and Reconciliation Engine to attempt matching against the parent class identification rule. Since Tomcat is a more specific application class, falling back to the parent Application identification rule helps prevent unnecessary duplicate records when a match cannot be made at the subclass level. “Applies to” defines the class or scope for the identifier entry. “Independent” controls whether a rule is evaluated independently rather than through parent inheritance. “Criterion attributes” are the fields used for matching, not the fallback setting. Therefore, the correct configuration is Allow fallback to parent’s rules .

=========

In Data Foundations (CMDB and CSDM), relationship modeling must reflect real operational dependency so that incident triage, change impact analysis, and service visibility remain accurate. When an Application is hosted on a Server, the standard hosting-style relationship used in CMDB relationship governance is expressed as “Runs on::Runs”. This pairing represents the two directional descriptors of the same relationship type: from the application perspective it runs on the server, and from the server perspective it runs the application.

This matters because CMDB relationships are used by downstream capabilities (for example, dependency views, impact calculations, and governance rules). Using the correct out-of-box relationship descriptor pair ensures consistent reporting and prevents confusion when teams traverse relationships “upstream” and “downstream.” In addition, relationship governance rules and inheritance are commonly built around standard relationship types; using the correct “Runs on::Runs” semantics supports validation across subclasses (for example, specific application and server subclasses) without requiring custom relationship definitions.

The other options are either reversed (“Runs::Runs On”), represent different semantics (“Uses::Used by”), or do not align with the typical hosting relationship naming used for application-to-server hosting dependencies. Therefore, the correct relationship expression between an Application and a Server is Application > Runs on::Runs > Server.

Service Mapping (Top-down) → Recommended for mission-critical application services that require a precise approach using patterns

Tag-Based → Best fit to map cloud-native, container-based, or virtual machine environments

Service Mapping (Connection Suggestions) → Ideal for custom-built applications and leverages application fingerprinting to generate service maps in a timely manner

Dynamic CI Group → Ideal for small application services that can be easily grouped using filters and CMDB queries

In Data Foundations (CMDB + CSDM), an Application Service should be created using an approach that balances accuracy, speed, and maintainability, because the service map becomes the foundation for impact analysis, service visibility, and operational workflows.

Service Mapping (Top-down) is best for mission-critical services because it uses structured entry points and patterns to precisely discover infrastructure, dependencies, and communication paths. This produces high-fidelity maps suitable for strict governance, controlled change, and reliable outage impact analysis.

Tag-Based mapping is best for cloud-native and dynamic environments (containers, elastic virtual machines, and cloud resources) because tags/labels are the most stable identifiers in rapidly changing estates. It aligns well with modern cloud governance where ownership, environment, and service affiliation are expressed through standardized tagging strategies.

Service Mapping (Connection Suggestions) fits custom-built applications because it leverages observed connection data and application fingerprinting to propose likely dependencies. This accelerates service map creation when traditional pattern-first modeling would take longer, helping teams reach usable service visibility faster while still allowing validation and refinement.

Dynamic CI Group is ideal for smaller services where a full discovered map may be unnecessary. It groups CIs using filters and CMDB queries, providing a lightweight way to define “what’s in the service” for reporting, ownership, and basic impact without heavy mapping overhead.

The CMDB Data Manager capability in ServiceNow is designed to support CMDB governance, specifically around data lifecycle management. Its primary purpose is to ensure that CI records are retained, archived, and deleted in accordance with defined retention policies, regulatory requirements, and organizational data governance standards.

As CMDBs mature, they naturally accumulate obsolete, retired, or decommissioned CIs. If these records are not properly managed, they negatively impact CMDB health, reporting accuracy, discovery reconciliation, and performance. CMDB Data Manager addresses this by automating the archival and deletion of records once lifecycle conditions and retention thresholds are met.

Option A is incorrect because encryption of archived records is handled by platform-level security and data protection features, not CMDB Data Manager. Option B is also incorrect because relationship rule enforcement is managed through CSDM guidance, CMDB relationship rules, and identification/reconciliation logic—not by CMDB Data Manager.

By automating retention-based archival and cleanup, CMDB Data Manager helps organizations maintain a lean, compliant, and high-quality CMDB, which directly supports CMDB Health metrics such as correctness and compliance.

Therefore, the correct and verified answer is Option C.

The CMDB aligns to business processes by giving the organization a trusted operational data foundation. First, it enhances decision-making and operational efficiency because Incident, Problem, Change, Risk, Security, and Service Management teams can assess impact, ownership, dependency, and priority using reliable CI and relationship data. Second, it provides a centralized view of configuration items and relationships , which is the core function of the CMDB. That centralized relationship model is what makes service impact analysis, change risk assessment, outage analysis, and operational routing possible. Tracking software licenses is primarily an IT Asset Management and Software Asset Management concern, not the main CMDB business-process alignment value. Extending service delivery management to all enterprise departments is too broad and belongs more to enterprise service management strategy than core CMDB alignment. Therefore, A and C are correct.

=========

IntegrationHub ETL is a ServiceNow data-ingestion application used to extract data from external sources, transform it through defined mappings, and load it into the CMDB. Its Robust Transform Engine provides a guided, low-code mechanism for mapping source data to appropriate CMDB classes, attributes, and relationships.

A major Data Foundations advantage of IntegrationHub ETL is its integration with the Identification and Reconciliation Engine. Incoming records can be processed through identification and reconciliation rules so that existing CIs are updated correctly, duplicate creation is reduced, and source-authority controls are respected.

Agent Client Collector is used to gather inventory and telemetry from devices through an installed endpoint agent. Service Mapping builds Application Service topology and dependency relationships; it is not the general ETL application for importing data from multiple external sources.

The guide identifies IntegrationHub ETL as the recommended method for importing external data through the Identification and Reconciliation API when a dedicated Service Graph Connector is not the applicable solution.

CMDB Query Builder provides purpose-built Export Query and Import Query functions for transferring saved query definitions between ServiceNow instances. The administrator selects the saved query, exports its definition as an XML file, and the receiving team imports that file using the Import Query function. The imported definition then appears in the destination instance’s Saved Queries tab.

Exporting the query as a report would transfer report configuration rather than the complete Query Builder canvas and relationship definition. A generic record-level XML export is not the prescribed Query Builder workflow.

ServiceNow also documents transfer through an update set, but identifies that process as an alternative maintained for backward compatibility. Because the question asks for the direct and recommended Query Builder approach, Option A is the best answer.

Task behaviour for CIs that fail a CMDB Health condition is configured through Health Metrics . The Orphan metric evaluates whether CIs have the required relationships or contextual connections defined for their class. Its metric configuration determines how the condition is evaluated and supports the generation of remediation work for unhealthy records.

The CMDB Health Dashboard displays calculated results and scorecards, but it is primarily a reporting and investigation interface rather than the underlying metric-configuration location. CI Class Manager is used to manage CI classes, attributes, identification rules, and related class-level settings. System Properties control broader platform behaviour and are not the specific location for configuring task handling for the Orphan metric.

Because task creation is tied to the applicable health condition and its remediation behaviour, the administrator configures it through Health Metrics .

=========

Top of Form