Admin Credentials Expired After 90-Day Leave?
Short answer
A The user's administrator credentials expired after more than 90 days of leave, which blocks privileged systems while SSO remains functional.
Question
• A device certificate is deployed on all corporate assets.
• Templates for unique user certificates are configured.
• Security updates are installed every 30 days.
• Administrator access is tied to specific hosts.
The ticket contains the following observations:
• The user has been on leave for more than 90 days.
• Internal vulnerability scans indicate no device issues.
• Single sign-on works as expected.
• Privileged systems are not accessible.
Which of the following best describes the root cause?
Key Takeaways
Tests IAM troubleshooting for privileged access; the trap is blaming the 90-day patch gap or certificate configuration when SSO success proves the normal user identity is healthy.
A returning employee cannot access privileged systems even though SSO works normally. The page establishes that expired administrator credentials—not missed patches or certificate template errors—are the root cause.
Common mistake: Many candidates select missed patch cycles (C) because the 90-day leave spans three 30-day update intervals, but internal scans confirm no device issues.
Expert Analysis
Why the Answer Is Correct
The scenario separates normal user authentication from privileged access: SSO succeeds, so the user's regular identity and device certificate are functioning. The only failing path is access to privileged systems, and the user has been away for more than 90 days—a common expiration window for administrator credentials. Because administrator access is tied to specific hosts, the expired admin account cannot authenticate to those hosts even though the user can still SSO to ordinary resources. Internal scans also show no device problems, removing patching and device health as causes. Therefore A is the root cause.
Why the Other Options Are Wrong
B is unsupported: a device certificate is deployed on all corporate assets, and SSO works, so there is no evidence the device lacks user binding. C is contradicted by the vulnerability scan result showing no device issues; missed patches would be a compliance or NAC problem, not an isolated privileged-access denial. D would affect every user issued from the template, not one returning employee, and the question gives no sign of broad certificate failures. None of these explain why SSO succeeds while only privileged systems reject the user.
Community Comment Notes
The only community comment, from BWH9492, focuses on the machine being powered off for "over 3 full patch cycles" and selects C. That observation is factually tied to the 90-day leave, but it does not address the scan finding that no device issues exist. No commenter highlighted the separate administrator-credential expiration path, which is the decisive clue in the ticket. Readers should treat the comment as a useful reminder to check patch history, not as proof of the root cause.
Exam Strategy
When SSO works but privileged systems fail, separate the user account from the administrative account before investigating devices. Check the privileged credential lifecycle—especially expiration windows tied to leave duration—and use scan results to eliminate patching as a red herring.
Frequently Asked Questions
Why is expired administrator credentials the cause when SSO still works?
Why doesn't the 90-day leave mean missed patches are the root cause?
Discussion 1 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 1
-
BWH9492 👍 1 Answered CThe user has been on leave for more than 90 days (meaning the machine has been powered off or disconnected from the corporate network for over 3 full patch cycles).
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.