ServiceNow CIS-DF - Certified Implementation Specialist Data Foundations

Both critical and best score are correct

'deny class' sounds really aggressive. like it's blocking the class from being in the CMDB at all?

Only from CMDB 360 processing — the CIs still exist and are fully functional. It's denying them from the multisource analytics pipeline, not from the CMDB itself. Important distinction.

We add high-volume low-value classes to deny_class to keep processing costs manageable. Printers and monitors don't need multisource lineage tracking.

that makes a lot of sense. thanks

We hit this exact scenario after onboarding a SCCM connector. 30% of server locations conflicted with Discovery. The governance PDF approach (answer B) was literally what we tried first and it did nothing — Discovery kept winning.

so you fixed it with reconciliation rules?

Yep. Set source precedence so our authoritative source (SCCM in that case) won for location on the server class. Conflicts dropped to near zero within a few scan cycles.

The 'manually edit every conflicting CI' answer is so bad it's almost funny. You'd fix 28% of your estate and the next Discovery run would revert half of them.

Exactly. Treat the root cause, not the symptom.

I'm not totally convinced A and C aren't contradicting each other. One is custom REST, the other is a certified connector — when would you pick one vs the other?

If a Service Graph Connector exists for your source system, use it — it's maintained, certified, and already maps to CMDB classes with IRE. If no connector exists, a custom inbound Scripted REST endpoint is your fallback. The question is asking which patterns match the push model described, and both do.

We've had to build custom REST endpoints for homegrown monitoring systems where no connector existed. The overhead is non-trivial — you own the mapping, IRE wiring, and upgrades yourself.

so the exam just wants you to know both are valid push patterns?

Yes. The wrong answers are about pulling (Query Builder scheduled every minute) or batch patterns (import set coalesce). Push is the scenario.

if discovery can't find the dependency, how does it even know there's something missing?

It doesn't. That's exactly the point. Discovery only finds what it can reach via network probes. A vendor-managed print contract or a SaaS payroll system hosted outside your network is invisible to Discovery. You have to model those manually from contracts or catalogs.

the 'schedule more Discovery passes' distractor is a good trap. like intuitively you think more discovery = more coverage, but it doesn't work for off-network SaaS

Anything vendor-hosted or contractual is essentially a manual or integration job. Discovery is a network tool at its core.

How does IRE actually handle concurrency? Like if two imports hit the same CI at the same time, what prevents a race condition that creates duplicates anyway?

IRE uses locking mechanisms during identification to prevent concurrent inserts for the same CI. The identification rules have to be strong enough that both imports recognize the same existing CI — that's the 'unique identifier entries' part of the answer. Weak identifiers are where concurrency breaks down.

We've seen duplicates under heavy concurrent load when identifier rules had optional conditions that sometimes didn't fire. Tightening the rules fixed it.

'Disable all business rules' as an answer option is hilarious. That would break everything.

lol yes. classic 'option that sounds plausible if you haven't thought it through'

is this property on by default or do you have to explicitly enable it

You have to enable it. It's not on by default because storing per-source attribute contributions adds storage and processing overhead. You turn it on when you're ready to operationalize CMDB 360 multisource analytics.

We enabled it before we were really ready and the data volume was surprising. Worth having a plan for what classes you actually need multisource tracking on before flipping the switch.

so the deny_class table is how you control which classes get tracked even after enabling?

Correct. Enable the property globally, then use cmdb_multisource_deny_class to exclude classes where you don't need or want per-source tracking. Good strategy for large estates.

what's the actual difference between Unified Map and CMDB 360? both seem like 'see your CI from all angles' features

Unified Map is topology — it draws the relationship graph, shows what's connected to what. CMDB 360 is multisource — it shows what each data source contributed and where values conflict. Different dimensions of the same CI.

this question is asking specifically about a 'unified CI workspace experience' — the key word is workspace. CMDB 360 brought the workspace experience together.

Could someone argue CMDB Query Builder is a workspace experience too though? It's in the CMDB Workspace module.

Query Builder is a query tool, not a 'unified CI workspace' in the way the question is framing it. The scenario describes service owners needing consolidated views of relationships, dependencies, and CI history in one place — that's CMDB 360.

is Lineage just a visual thing or does it actually do something

Primarily visualization, but it's analytical visualization. It shows you how data flows through the dependency graph and where sources contribute. You use it to understand flow patterns and trace where conflicts originate. It informs decisions rather than taking action itself.

I use it after Source Cards. Cards tell me what's wrong on a specific CI, Lineage tells me whether it's a systemic issue across multiple CIs in the dependency chain.

ok that workflow makes sense. cards = zoom in, lineage = zoom out to see the pattern

This question's answer feels counterintuitive. Shrinking identifiers = more duplicates? I would have thought fewer attributes to match on = cleaner matching

Think about it from the collision angle. If you only match on serial number and two imports arrive for the same server — one with the serial and one without — you get a duplicate because the second import can't find the first. More strong identifiers = more chances to recognize the same CI from different sources.

We had a consultant remove 'IP address' from identification entries to 'reduce false merges' and our duplicate count went up 40% in the next cycle. Analysis before tuning is critical.

so 'shrinking without analysis' is the key qualifier here. shrinking WITH analysis might be fine?

Exactly. The question is about doing it blindly. Removing bad identifiers that were causing false merges is valid — but you need to understand the impact first.

This question tests whether you understand IRE tuning risk, not just IRE mechanics. Higher-level thinking.

there are SO many cmdb_multisource_ tables. how do you keep them straight

I grouped them by what question they answer. cmdb_multisource_data = 'what did each source report?' cmdb_multisource_deny_class = 'what should be excluded from 360 processing?' sn_cmdb_ws_ms_skip_class = 'what got auto-skipped in charts because there was too much data?' Once you have the questions the table names make more sense.

that's really helpful actually

the distinction between deny_class (admin curated) vs skip_class (auto/volume based) caught me. they sound similar but the trigger is totally different

yep that's the trap. one is intentional exclusion, one is automatic performance protection.

Second question about CMDBTransformUtil. this is clearly something they consider important

Yep. The whole import-set-to-IRE pipeline is a major topic. Know what CMDBTransformUtil does, where it's called (onBefore), and why it matters. Don't confuse it with REST APIs or workflow scripts.

In my experience most shops that have been on ServiceNow for a while have at least some transforms that DON'T use CMDBTransformUtil. Legacy integrations from before IRE was mature. CIS-DF is partly about recognizing and fixing those gaps.

why can't you just put it directly under cmdb_ci? isn't that 'simpler'?

Simpler to set up, painful to maintain. When you skip the intermediate parents you lose inherited identification entries, discovery alignment, and standard CMDB health rules that were designed for device classes. You'd have to reinvent all of that.

Also Discovery patterns are tuned to OOB class branches. If your sensor class is stranded at cmdb_ci root, none of that applies.

The question says extend cmdb_ci_ip_device or cmdb_ci_hardware — but these are IoT sensors, not traditional network devices. Does that actually make sense?

For CMDB purposes, if they have an IP address they behave like IP devices. The hierarchy is about what infrastructure management patterns they inherit, not what the physical device does.

The answer D+E pairing (extend OOB class AND use u_ prefix) is the standard formula for custom CI modeling. See it on multiple questions in this quiz.

I keep getting 1 and 2 mixed up. Like both of them are about matching things... what's the actual difference

Think of it this way: identification answers 'is this the same physical thing?' and reconciliation answers 'when two sources disagree on a value for that same thing, who wins?' Identification prevents duplicate records. Reconciliation prevents attribute chaos.

ohhhh that actually makes so much sense. so identification runs first?

Exactly. Reconciliation can't run until identification has decided you're dealing with one CI, not two.

I'd push back slightly on row 3. Dependent relationship rules — the description says 'service map expects certain relationship patterns between classes.' That feels like it could overlap with identification since IRE can use relationships as hints.

That's worth noting but the exam is drawing a clear line. When relationships are used as identification hints it's still identification doing that work — dependent relationship rules are about validating graph structure, not matching the CI itself.

Fair point. I'll stop overthinking it.

Passed in April. Knowing this distinction cold definitely mattered — it comes up in a few different question formats.

Same. Kept reminding myself: duplicate record = identification problem. Overwritten field = reconciliation problem.

so you can literally chain multiple relationship hops in one Query Builder query? i thought you had to do them separately

Yes — that's the whole point of relationship path nodes. You define each hop (physical host → VM → app → business service) and Query Builder traverses the whole chain declaratively. No custom code needed.

The 'run four reports and merge in Excel' option is a real thing people still do. Took us a while to get teams off that workflow.

i asked our admin about this during study prep and she said the GlideRecord looping approach (answer C) actually works but is completely unnecessary and kills performance on large estates

Correct. GlideRecord loops on cmdb_rel_ci at scale are a performance nightmare. Relationship paths are the governed, efficient alternative.

is this going to be on the exam? MID Server feels like a fundamental concept but the question is pretty specific about firewall direction

Yes, the outbound polling architecture is definitely fair game. It's a security-relevant design decision and comes up in real implementations constantly.

The key architectural fact is that MID Server initiates the connection to the ServiceNow instance — it polls outbound. The instance never opens an inbound connection to the MID. That's what makes it work behind firewalls with no inbound rules.

Answer C says the MID 'depends on inbound firewall holes' — that's explicitly backwards from how it works. Good distractor though.

Deployed MIDs in air-gapped manufacturing networks. Outbound-only is not just an exam fact, it's a real operational requirement in those environments.

Same in healthcare. Can't open inbound holes to clinical networks.

memorizing which table does what is rough. any mnemonics?

I think of cmdb_multisource_data as the 'raw feed snapshots' table. Every source's contribution for every attribute lands there before reconciliation picks a winner. If you want to know what SCCM reported vs what Discovery reported, that's your table.

The wrong answers here are all way off-topic (sys_audit_delete, sys_user_has_role, pa_scores). The exam expects you to recognize the cmdb_ prefix tables for CMDB 360 functionality.

If it starts with cmdb_multisource_ it's part of the 360 analytics stack.

upstream vs downstream in Query Builder always confuses me. which direction am i going when i go 'downstream' from an app to its servers?

Downstream = following 'depends on' in the direction of the dependency. App depends on → server, so downstream from the app takes you toward the infrastructure it needs. Upstream would go the other direction — what depends on this app.

so in this question 'downstream, depth 2' means: app → server (hop 1) → hypervisor (hop 2)?

Exactly right. Downstream chases the dependency chain outward toward infrastructure.

The 'record limit two' option is a really sneaky distractor. Record limit caps how many rows come back, not how many hops deep you go. Totally different concept.

That one got someone in my study group. Know the difference between depth and record limit.

I genuinely disagree with B being the best answer here. F5 load balancers are a distinct enough product that a dedicated child class under Load Balancer seems defensible.

You can make that argument, but the question has three constraints: Discovery auto-population, compliance attributes, AND upgrade safety. A new child class adds pattern targeting complexity and risks breaking on upgrades. The u_ field approach satisfies all three without introducing new hierarchy.

The key phrase is 'future platform upgrades should not force a class redesign.' That's the constraint that pushes you away from a custom class and toward u_ fields on the OOB Load Balancer class.

ok that does make more sense. I focused on the modeling part and skipped the upgradeability requirement.

These best practice questions always trip me up. The 'right' answer isn't always what I'd do, it's what the platform recommends.

why is 'Query Builder -> schedules MID probes' wrong? doesn't Query Builder pull data from MID?

Query Builder is a reporting/analysis tool for data already in the CMDB. It queries relationships and attributes. Discovery schedules and MID Server jobs are a completely separate system. Query Builder doesn't control when probes run.

ohhh i was confusing querying the database with the discovery process. got it

Easy to confuse early on. Different layers of the platform.

Why isn't 'Runs on' correct here? the app has to run somewhere to use the database

Because the application isn't running ON the database. It's running on a server, and it depends on the database. 'Runs on' is about execution placement. 'Depends on' is about functional reliance.

oooh. so 'Runs on' = where something runs. 'Depends on' = what something needs to function

Same mistake I made initially. The scenario even says 'cannot operate without its backing database tier' — that's pure functional dependency language.

In large environments getting relationship types right matters a lot for impact analysis. If you model it as 'Runs on' instead of 'Depends on,' traversal queries go in the wrong direction and blast radius looks wrong during a P1.

Agreed. Learned that lesson in production.

Source Cards show trust scores? like they literally score how much you should trust the data source?

It's more about which source contributed each attribute and reconciliation context than a literal trust score. But yes, you can see which datasource reported a value and assess whether that source is authoritative for that field.

Source Cards were my favorite feature to demo when I worked on a CMDB cleanup project. Made it so easy to explain to stewards why a field had the wrong value — you could literally point at which source won.

Same experience. It's a great visualization tool for conflict conversations.

The answer for row 1 and row 2 being the same letter (B) threw me off. I kept second-guessing myself thinking I miscounted.

Yeah that's intentional. Both Discovery and IRE-enabled transforms fire IRE — that's the whole point. IRE is the engine behind all governed CMDB ingest paths.

does IRE run when you open Unified Map? i guessed yes because you're 'looking at' the CI

No — Unified Map is purely read. It renders what's already stored. IRE only triggers on ingest paths that write authoritative data.

We learned this the hard way. Had a team convinced that running health jobs would 'refresh' IRE processing. Those are completely separate. Health jobs score what's there; they don't re-run identification or reconciliation.

Good real-world example.

I want to understand the mechanism here. How does the Data Foundation Dashboard actually know an integration is bypassing IRE? Is it reading logs?

It's analyzing ingest patterns — specifically whether CI records being created or updated went through the IRE APIs or were written directly to cmdb tables. Direct writes leave a detectable signature in how the records are created versus IRE-processed ones.

We had a legacy integration that was doing direct GlideRecord inserts to cmdb_ci_server. The Data Management Practices tab called it out immediately after we set up the Foundation Dashboard. Took about six months to re-architect.

so this is basically a governance warning that says 'this feed is bypassing the rules'?

Exactly. The dashboard isn't fixing it for you — it's surfacing the problem so you can remediate.

Hardware Status, Operational Status, Install Status... why are there three different status fields on a CI? that seems like too many

They answer different questions. Hardware Status comes from the asset side (is this asset in use, in stock, retired). Operational Status is runtime (is the thing currently running or down). Install Status is the classic CMDB lifecycle flag. They can all be different for the same CI.

We've had servers where Hardware Status = Retired (asset team retired it in the books) but Operational Status = Up (it was still running because nobody turned it off). That's exactly why the fields exist separately.

so when asset-ci sync is enabled, which field does the asset retirement map to?

Hardware Status. Asset State on alm_hardware maps to Hardware Status on the CI in standard sync configuration. That's row 1-B in this question.

This matching question is worth understanding cold. The status fields trip up a lot of people.

This is a 100% real problem. We had stewards setting Environment = Production on servers and Discovery kept blanking it every scan cycle because the probe didn't return that field. Took us a while to realize reconciliation rules were the fix.

so you can configure reconciliation to say 'if the incoming value is blank, don't overwrite what's already there'?

Exactly. 'Do not overwrite with empty' and 'manual source ranks above Discovery for this attribute' are both standard reconciliation patterns. The steward's value becomes the authoritative one for that field.

i almost picked 'disable Discovery globally' which is obviously wrong but honestly felt tempting after reading the scenario lol

The 'mark class non-extensible' distractor is designed to catch people who confuse schema design with ingest behavior. Very different things.

I'd never heard of CMDBTransformUtil before studying for this exam. is it actually used a lot in practice?

Yes, every transform map that targets a CMDB class should be calling it in an onBefore script. It's what makes bulk imports go through IRE instead of landing as raw unidentified records. Without it you might as well be doing direct table inserts.

The exam loves testing whether you know CMDBTransformUtil is the bridge between import sets and IRE. It's a specific technical detail that separates people who've actually built integrations from people who've only read about them.

Worth noting: it goes in onBefore, not onComplete or onAfter. The row needs to go through IRE before the transform logic finalizes.

row 2 says field maps are still required even when IRE is enabled. why? I thought IRE handled everything

IRE handles identity (is this the same CI?) and reconciliation (who wins on attribute conflicts). It does NOT map source_serial_number from your import set to the serial_number field on cmdb_ci_server. Field maps still do that column-to-attribute translation. They're separate pipeline stages.

ohhhhhh. so the data still has to get from the import table to the CMDB table somehow. IRE just governs what happens when it lands

Statement 4 ('reconciliation rules are replaced by coalesce fields') is the most dangerous wrong idea in this whole quiz topic area. People who believe that are running uncontrolled last-writer-wins on sensitive attributes.

Coalesce was the pre-IRE mechanism for deduplication on transforms. IRE identification rules replaced it for CI matching. Reconciliation rules do something coalesce never did — manage source authority after matching. They were never replacements for each other.

this one seems almost too easy compared to the other questions? just use the CMDB 360 view

The easier-looking questions are the ones people rush and get wrong. Make sure you're reading what they're actually asking — here they want per-source attribute visibility in one report, which is specifically what CMDB 360 multisource views provide.

the 'build separate per-source reports and merge manually' option is exactly what I was doing before we had CMDB 360 set up. never again

Wait I thought Source Cards WERE the lineage? like they show where data came from?

Source Cards are per-CI, per-attribute. They answer 'what did Discovery report for this serial number on this CI?' Lineage is broader — it traces the flow across multiple CIs, showing upstream/downstream. Think of cards as the detail view and lineage as the graph view.

ok so Source Cards = zoom in on one CI, Lineage = zoom out to see the whole dependency flow

Exactly. And Coverage cards are different again — they tell you how much of a given class is covered by a given source. All three serve different questions.

The matching answer for row 4 (Coverage) as 'run reusable multisource comparisons on a schedule' confused me. That sounds more like Saved Queries.

You're reading the answer key right. The letter assignments are just A/B/C/D placeholders — coverage cards answer breadth/coverage questions. It's how the matching rows are labeled that matters, not the letter.

Wait, isn't this almost the same question as 35?

Very similar scenario, but 35 is multi-select (D+E) and this one is single answer (D only). The principle is the same — extend OOB, use u_ fields — but how it's asked is slightly different.

Good to know they test the same concept more than once.

ok wait. so if IRE is enabled, the coalesce fields just... do nothing? that seems like a weird design

Not exactly nothing — they still exist in the transform map, they just don't drive the identification anymore. IRE identification rules take over that job. Coalesce is essentially retired for CI matching once IRE is wired up correctly.

so you could have coalesce fields set AND IRE enabled at the same time and they'd conflict?

They won't conflict exactly but you'd have redundant logic. The docs recommend removing or ignoring coalesce once IRE identification rules are in place for that class.

This one tripped me up when I took the exam. The key word in the question is 'no longer needed' — they're asking what becomes redundant, not what breaks.

Good clarification.

if this job isn't running on a schedule do the CMDB 360 dashboards just show stale data?

Yes exactly. We went through a period where the job got disabled accidentally and the dashboard tiles stopped updating. Took us two weeks to notice because the numbers looked plausible.

Make sure this job is both active and scheduled to run frequently enough for your reporting cadence. It's a prerequisite for meaningful CMDB 360 dashboard metrics.

how often should it run?

Depends on how frequently your data changes. Daily is common for most implementations but high-churn estates sometimes run it more often.

is Management view the same as CMDB 360? or is it a separate thing inside the workspace

CMDB 360 is a broader set of capabilities. Management view is a specific workspace landing within it — focused on day-to-day operational hygiene like duplicates and recent mutations. CMDB 360 also includes Source Cards, Lineage, Conflict Resolution, etc.

Good distinction.