Before approving a change to a shared cloud load balancer, the change board cannot tell which applications, certificates and network rules depend on it. Which practice fills this gap?
Select an answer to reveal the explanation.
Short Explanation
A CMDB is the wiring diagram for your environment: it shows what plugs into what. Without it, you're approving changes to a load balancer without knowing whose lights go out. The trap is a practice that's useful but answers a different question.
Full Explanation
Configuration management identifies the configuration items that make up services, such as load balancers, certificates, network rules, virtual machines and applications, records their attributes and approved baselines, and, crucially, maps the relationships and dependencies between them in a configuration management database. When a change is proposed to one item, the change board queries those relationships to assess impact: which applications route through the load balancer, which certificates it presents, which rules depend on it. This is the information the board is missing. Capacity management forecasts and plans resource needs so performance meets demand; it says how much load the device must handle, not what depends on it. Problem management investigates the root causes of recurring incidents and records known errors; it may use CMDB data but does not maintain dependency records. Service-level management defines and reviews service targets with customers and providers; it reports performance against agreements, not configuration relationships. Exam caveat: cloud resources change constantly, so configuration data should be populated automatically from provider APIs; an outdated CMDB gives false confidence. Operational check: select the load balancer in the CMDB and confirm that it lists every upstream and downstream dependency, that the data is reconciled automatically with the cloud inventory, and that change records reference the affected configuration items.