5V0-62.22 · Question #44
Refer to the exhibit. A company has created a compliance policy with the following rules: Recently, the Android device was marked as non-compliant. The VMware Workspace ONE UGM administrator found…
VMware Workspace ONE UEM - Compliance Not Updating After Remediation Correct Answers: A and C A is correct because if the Android device has not checked in with the UEM tenant after the user removed Facebook and set a passcode, the server has no way of knowing the device's…
Question
Refer to the exhibit. A company has created a compliance policy with the following rules:
Recently, the Android device was marked as non-compliant. The VMware Workspace ONE UGM administrator found that the Facebook application was installed on the device and that a passcode was not present. However, after the user removed the Facebook app and created a device passcode, the Android device still shows as non-compliant in the VMware Workspace ONE UEM console. Other devices within this organization all show as compliant. Which two root causes could possibly cause this problem? (Choose two.)
Exhibit
Options
- AThe device has not checked in with the Workspace ONE UEM tenant.
- BThe Policy Engine Service is not running
- CThe Interrogator Queue Service is not running.
- DThe Android device operating system version is lower than 8.0.0
- EThe device is not enrolled into Workspace ONE UEM.
Explanation
VMware Workspace ONE UEM - Compliance Not Updating After Remediation
Correct Answers: A and C
A is correct because if the Android device has not checked in with the UEM tenant after the user removed Facebook and set a passcode, the server has no way of knowing the device's current state has changed - it retains the last known non-compliant snapshot. A manual check-in or scheduled sync is required to push the updated device status to the console.
C is correct because even if the device does check in and transmits its updated sample data, that data is queued for processing by the Interrogator Queue Service. If that service is not running, the incoming device data never gets processed, so the compliance engine never receives the signal that the device has remediated - leaving it stuck as non-compliant.
Why the others are wrong: B (Policy Engine not running) is unlikely because other devices still show as compliant, meaning policy evaluation is working for the rest of the org - a stopped Policy Engine would affect everyone. D (OS < 8.0.0) would only apply if the exhibit's compliance policy included an OS version rule as a third condition; the question attributes non-compliance only to Facebook and passcode. E is impossible - an unenrolled device wouldn't appear in the UEM console at all.
Memory tip: Think of it as a two-step pipeline - the device must report (check-in, A) and the server must process (Interrogator Queue, C). Either step failing leaves stale compliance data.
Topics
Community Discussion
No community discussion yet for this question.