Ingest
About 19% of the CIS-DF exam — see all 5 domains.
Ingest is about getting data in cleanly, through the IRE, without creating technical debt.
Choosing an ingestion method (a common scenario):
- Discovery: agentless, scheduled discovery through MID Servers; also creates many infrastructure relationships.
- Service Mapping: builds application service maps and their relationships top down.
- Service Graph Connectors (SGCs): the preferred, certified way to bring third-party data (for example Microsoft SCCM, Intune, cloud and security tools) into the CMDB. They are built on IntegrationHub ETL and send data through the IRE. Install and monitor them from SGC Central and the Integration Commons dashboard.
- Agent Client Collector: agent-based collection from endpoints.
- IntegrationHub ETL / Robust Transform Engine: build your own IRE-aligned integration when no connector exists.
- Import sets and manual entry: for non-discoverable CIs and attributes (business applications, manually maintained service instances). Apply the IRE to import sets so they do not create duplicates.
Minimize technical debt: prefer certified connectors and IRE-based integrations over custom scripts that write straight into CMDB tables. Connectors still need normal upgrade work: customizations of legacy integrations (such as the old SCCM plugin's transform maps) do not migrate automatically and must be rebuilt.
Relationships are populated automatically (Discovery, Service Mapping, connectors sending relations in the IRE payload) or manually (relationship editor, Unified Map editor). Dependent relationships (hosting and containment rules) let the IRE identify dependent CIs in context.
Non-discoverable CIs: load them by import or manual entry, assign an owner, and keep them current with Data Manager attestation policies. Remember that Foundation records such as companies, locations, buildings and contracts are referential data, not CIs.
Security and regulatory compliance against CSDM objects: the CSDM Information Object, referenced by the business application, describes the data an application uses (for example PII, PCI or HIPAA data and its sensitivity), which lets audits be scoped by data type.
Asset and CI alignment:
- An asset (alm_asset, financial and contractual view) and a CI (cmdb_ci, operational view) are two separate records kept in sync by two business rules: Update CI fields on change (on alm_asset) and Update Asset fields on change (on cmdb_ci).
- Sync happens only when the asset and the CI reference each other.
- State mapping is not one-to-one. For hardware CIs, the asset State and Substate map to the CI Hardware Status and Substatus. For non-hardware CIs, the asset State maps to Install Status. Install Status and Hardware Status are independent fields.
Sample questions from this domain
Three of the 52 in this domain, with the reasoning. The full set is in the question bank.
After installing several Service Graph Connectors, a CMDB manager wants one central view of the status, processing results, and processing errors of every installed CMDB integration. Which component provides this?
- A. The Discovery Status list for each Discovery schedule
- B. The Correctness scorecard on the CMDB Health Dashboard for each class
- C. The MID Server dashboard for the instance's MID Servers
- D. The CMDB Integrations Dashboard from Integration Commons for CMDB ✓
Why: Integration Commons for CMDB is installed automatically with Store Service Graph Connectors, and it provides the CMDB Integrations Dashboard: a central view of integration status, processing results, and errors. The CMDB Health Correctness scorecard measures data quality (orphan, stale, duplicate CIs), not integration runs. The Discovery Status list tracks Discovery schedules, not connector imports. The MID Server dashboard reports MID Server health and does not summarize connector processing results.
An ITAM team receives hardware assets with serial numbers weeks before the devices are ever discovered. They want a CI created from each asset through the Identification and Reconciliation Engine, so that later Discovery updates that same CI instead of creating a duplicate. Which system property supports this?
- A. glide.create_alm_asset.async
- B. An Asset-CI Install Status Mapping record with direction Asset to CI
- C. glide.asset.create_ci_with_ire ✓
- D. csdm.lifecycle.sync.between.ci.and.asset.activated
Why: glide.asset.create_ci_with_ire enables CIs to be created from assets through the IRE; it applies to hardware CI classes whose identification rule uses serial number, so the asset's serial number is required. Because the CI was created through identification, a later Discovery payload with the same serial number matches it instead of inserting a duplicate. glide.create_alm_asset.async controls whether assets are created from CIs immediately or by a delayed scheduled job, which is the opposite direction. csdm.lifecycle.sync.between.ci.and.asset.activated controls whether Life Cycle Stage and Status sync directly between asset, CI, and install base item; it does not create CIs. An Asset-CI Install Status Mapping record only maps asset states to CI status values for records that are already linked; it does not create CIs.
A finance analyst updates the Cost on a hardware asset. Later, a CMDB administrator edits the Cost value shown on the paired CI. How does out-of-the-box asset and CI synchronization treat the Cost field?
- A. Cost syncs only from the CI to the asset, because the CI is the operational record
- B. Cost syncs in both directions, so the CI edit overwrites the asset's Cost
- C. Cost syncs only from the asset to the CI, and the value on the CI is informational ✓
- D. Cost is not synchronized, so each record keeps its own independent value
Why: In the asset and CI field mapping, Cost synchronizes in only one direction, from asset to CI, and it is informational only on the CI record; the asset (alm_asset) remains the financial record. It is not bidirectional, so a CI edit does not flow back to the asset. Cost is one of the synchronized fields, so it is not independent. CI to asset only is the reverse of the documented direction.