CMDB — core concepts, tables, governance
How the Configuration Management Database is structured, extended, and governed.
5 questions loaded · 4 definitive · 1 scenario
Definitive questions
Scenario drills
Extending a CI class without breaking upgrades
“You need to add a 'lease_expiry' field on Windows servers. Do you extend cmdb_ci_win_server or create a custom table?”
Approach
- Add columns to the existing OOB class via CI Class Manager; this preserves identification rules and inheritance.
- Never create a parallel u_windows_server table — you'd lose OOB identification, reconciliation, and Discovery mapping.
- Prefix custom columns with u_ so upgrades don't clash.
// Add column via sys_dictionary (or CI Class Manager UI) column.name = 'u_lease_expiry'; column.table = 'cmdb_ci_win_server'; column.type = 'glide_date';Alternate approach
Alternate: create a scoped application table that references the OOB CI (cmdb_ci_win_server) via a reference field — good when the data is app-specific rather than a CI property.
Pitfall
Extending too deep in the tree forces every subclass to inherit the column. Extend at the lowest class that needs it.
Grow this section
Generate more unique questions on demand — the AI sees the titles already on the page and avoids repeats. Repeat until you reach the depth you need.