The board adopted CIS Azure Foundations for the lock-lab subscriptions. What should the engineer do in Microsoft Defender for Cloud?
Select an answer to reveal the explanation.
Short Explanation
CIS is already on the shelf as a built-in standard—turn it on for the lock-lab subscriptions. Do not retype CIS into homemade JSON or file a Sentinel ticket hoping someone else flips the switch.
Full Explanation
When the board adopts CIS Azure Foundations for the lock-lab subscriptions, add or enable the CIS standard in Microsoft Defender for Cloud regulatory compliance on those subscriptions. CIS is a built-in standard; enabling it at the right scope is the supported path to CIS assessments and evidence.
Rewriting the entire CIS catalog as a single custom JSON policy definition from scratch duplicates Microsoft's maintained standard, creates drift risk, and wastes engineering time. Disabling MCSB permanently so CIS becomes the only visible number on Secure Score confuses regulatory standards with Secure Score's MCSB-oriented default and throws away useful baseline recommendations. Opening a Microsoft Sentinel incident titled "Enable CIS" and waiting for the SOC to flip the switch misuses the incident queue for a configuration task that security engineering should perform in Defender for Cloud settings.
Exam caveat: enabling CIS does not require disabling MCSB; multiple standards can coexist so the canal can track CIS adoption while keeping MCSB Secure Score guidance.
Operational check: in Defender for Cloud regulatory compliance, enable CIS Azure Foundations on each lock-lab subscription (or supported parent scope), wait for assessments to populate, and sample a few failed CIS controls to confirm resource-level recommendations appear.