Only the payments management group must show PCI assessments. How should the engineer scope the standard?
Select an answer to reveal the explanation.
Short Explanation
PCI belongs on the payments pier, not on every toy boat in the sandbox marina. Scope the standard like you would scope Azure Policy—right subscriptions, not the whole harbor.
Full Explanation
PCI assessments should be enabled on the payments subscriptions (or supported Defender for Cloud scope) and left off unrelated sandboxes. Scoping the standard like Policy—right subscriptions, not the entire marina—keeps the PCI dashboard meaningful for the cardholder environment.
Enabling PCI on every sandbox and lab subscription so the dashboard stays consistent everywhere floods non-cardholder estates with inapplicable controls and false urgency. Enabling PCI only inside Microsoft Sentinel workspaces and never on Defender for Cloud scopes puts the standard in the wrong product surface; regulatory compliance standards are managed in Defender for Cloud. Converting PCI into an Entra Conditional Access policy applied at the tenant root conflates identity access policies with cloud regulatory compliance assessments.
Exam caveat: management-group or subscription scoping must still align to actual cardholder data environments; enabling PCI on "payments" labels without validating CHD/CDE scope can still fail a real assessor review.
Operational check: enable PCI only on payments management-group subscriptions, verify sandboxes lack that standard, and spot-check that PCI failed resources listed are truly in the payments estate.