Transit dispatch phones that fail passcode complexity should receive an email and then an enterprise wipe after a grace period. Which compliance design matches that response?
Select an answer to reveal the explanation.
Short Explanation
Compliance actions are a warning ticket then a tow, not a wrecking ball on the first miss. Email first, grace period, then enterprise wipe. Instant unenroll on one fail is a valid action, but it is not the escalating pattern transit asked for.
Full Explanation
Transit dispatch phones that fail passcode complexity should receive an email and then an enterprise wipe after a grace period. Configure a UEM compliance policy with escalating actions that notify by email, then enterprise wipe after the grace period—warning ticket then tow, not a wrecking ball on the first miss. Unenrolling every device the first time passcode complexity fails fails by concept relative to the asked design because instant unenroll skips the escalating notify-then-wipe pattern transit requested. Using an NSX-T gateway firewall time-based rule to wipe the phone after 24 hours fails because gateway firewall cannot perform MDM enterprise wipe. Setting Carbon Black Cloud to isolate the device on the first weak-passcode event fails because CBC isolation is network containment on a sensor, not UEM passcode compliance escalation. Exam caveat: escalating compliance actions (email, grace, enterprise wipe) are a UEM compliance policy design—not NSX timers, not CBC isolate-as-wipe, not immediate unenroll when escalation was specified. Operational check: apply the escalating compliance policy to a lab dispatch phone, fail passcode complexity, confirm email notification, wait through grace in a test setting if feasible, and confirm wipe is the configured next action—not instant unenroll. Align grace period length with transit operations so overnight shifts still see the email before wipe.