Deallocated lock-lab VMs and a Databricks workspace flood Secure Score with recommendations that do not apply. What should the engineer do instead of treating Secure Score as broken?
Select an answer to reveal the explanation.
Short Explanation
Score is not broken—those idle VMs and Databricks boxes just do not fit the rule. Exempt the recommendation with a written why, or filter the scope, and stop pretending the meter is lying.
Full Explanation
When deallocated lock-lab VMs and a Databricks workspace generate Secure Score recommendations that do not apply, the correct response is a recommendation exemption or supported scope filter with a documented justification—not treating Secure Score as broken. Exemptions keep the score honest for in-scope resources while formally recording why a control is waived for idle or non-applicable workloads.
Disabling Microsoft Defender for Cloud on the entire subscription silences useful posture and threat signals estate-wide just to quiet a few noisy resource types. Marking every recommendation as a Microsoft Sentinel incident dumps posture homework into the SOC queue and misuses incidents, which are meant for threat detections rather than unfinished recommendations. Deleting the Databricks workspace and all deallocated VMs without change control clears the list by destroying assets, which is operationally reckless and fails change-management expectations on a municipal estate.
Exam caveat: exemptions are auditable exceptions—overusing them without expiry or owner review recreates the "dashboard looks green but risk remains" problem assessors look for.
Operational check: create exemptions (or scope filters) only for the deallocated VMs and Databricks resources with ticketed justification and review dates, then re-check Secure Score to confirm unrelated high-impact recommendations on active lock-lab assets still surface.