Critical applications should become IRM entities from application CIs where business criticality is high. Which configuration pattern matches that need?
Select an answer to reveal the explanation.
Short Explanation
Want critical apps as entities? Teach an entity type to read the application CI table and keep only high-criticality rows. That is CMDB-aware scoping with a purpose filter—not a one-off spreadsheet that goes stale by Monday.
Full Explanation
Critical applications should become IRM entities through an entity type on cmdb_ci_appl (or equivalent application CI table) with a condition selecting high business criticality. That CMDB-aware pattern with a purpose filter keeps scope tied to living inventory instead of a spreadsheet that goes stale by Monday. Generation then creates or refreshes entities for matching CIs so risk and compliance content can attach with referential integrity. A manual spreadsheet import with no link back to cmdb_ci_appl loses automated refresh and reconciliation. An entity class rename that ignores CMDB attributes entirely does not select critical apps. A UI policy that hides non-critical apps without creating entities changes presentation, not GRC scope. Exam caveat: entity types on application CI classes filtered by criticality are the standard pattern. Operational check for the team: configure the application entity type with a high-criticality condition, run generation, sample that entities match critical CIs, and confirm a non-critical app is excluded until its criticality changes and refresh runs. Keep civic stakeholders aligned on the operating model, and verify platform records after each change before reporting posture to leadership. Revisit the design when CMDB classes, org structures, or program charters change.