Defender for Cloud Inventory cannot show which lock-lab application owns each virtual machine during incident review. Which asset-management control should the security engineer apply first?

Defender for Cloud Inventory is only as useful as the metadata on each asset. Requiring or inheriting tags such as owner, data class, and environment through Azure Policy at the management group is the first asset-management control that makes lock-lab application ownership visible during incident review. Consistent tags flow into Inventory and related posture views so responders can map a VM to an owning application and data sensitivity without tribal knowledge.

Disabling Inventory until a handwritten CMDB spreadsheet is complete removes the live cloud inventory that already exists and replaces it with a slower, error-prone offline process that will drift the moment a new VM appears. Granting every operator Owner so they can rename VMs with the application name in the display name abuses privileged access and treats display names as a fragile naming convention instead of structured, policy-enforced tags. Turning off Secure Score recommendations that mention missing tags cleans the dashboard cosmetically while leaving ownership unknown—the exact gap the incident review needs filled.

Exam caveat: tags help Inventory and reporting, but they are not a substitute for RBAC or resource locks; tagging policy should complement—not replace—identity and deletion protections on the same estate.

Operational check: assign a tag-require or inherit initiative at the management group covering lock-lab subscriptions, remediate non-compliant VMs, then open Defender for Cloud Inventory and confirm owner/data-class/environment columns populate for sampled machines used in the last incident drill.