09:10 Token issued for user jdoe
groups=[Finance_Approver, Expense_Reviewer]
auth_time=09:10
exp=17:10
09:15 HR updated directory: jdoe moved to Sales
11:00 The application still accepts the original token and allows expense approval
11:01 Identity provider logs show no token revocation eventBased on the exhibit, what is the best fix so role changes are reflected promptly in the application?
Token and directory data:
09:10 Token issued for user jdoe groups=[Finance_Approver, Expense_Reviewer] auth_time=09:10 exp=17:10 09:15 HR updated directory: jdoe moved to Sales 11:00 The application still accepts the original token and allows expense approval 11:01 Identity provider logs show no token revocation event
Answer choices
Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.
Increase the token lifetime so users reauthenticate less often.
Longer token lifetimes make stale authorization claims valid for even more time after role changes.
Shorten token and session lifetime and revoke active tokens when the directory role changes.
Shorter lifetimes reduce stale access, and revocation ensures authorization changes take effect quickly after role updates.
Move the application to a different subnet to isolate it from HR systems.
Network placement does not correct stale claims already issued to the user by the identity system.
Disable group-based authorization and let any authenticated user approve expenses.
Removing authorization checks would create a much larger access problem instead of fixing stale role data.
Common exam trap
Logging in proves the user can authenticate. It does not automatically mean the user is allowed to enter privileged or configuration mode. Watch for AAA authorization, privilege level and command authorization details.
Technical deep dive
This kind of question is testing the difference between identity and permission. A user may successfully log in to a router because authentication is working, but still fail to enter configuration mode because authorization is missing, misconfigured or mapped to a lower privilege level.
Related practice questions
Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.
Practise SY0-701 questions linked to Security+ social engineering questions.
Practise SY0-701 questions linked to Security+ cryptography.
Practise SY0-701 questions linked to Security+ IAM questions.
Practise SY0-701 questions linked to Security+ risk management questions.
Practise SY0-701 questions linked to Security+ incident response questions.
Practise SY0-701 questions linked to Security+ malware questions.
Practise SY0-701 questions linked to Security+ vulnerability management questions.
Practise SY0-701 questions linked to Security+ security operations questions.
Practise SY0-701 questions linked to Security+ zero trust questions.
Practise SY0-701 questions linked to Security+ authentication factors questions.
Keep practising from the same exam bank, or move into a focused topic page if this question exposed a weak area.
Question 1
Question 2
Question 3
Question 4
Question 5
Question 6
FAQ
Authentication checks who the user is.
The correct answer is: Shorten token and session lifetime and revoke active tokens when the directory role changes. — The issue is stale authorization data. The user changed roles in the directory, but the application still honors the original token until it expires. Shortening token and session lifetime limits how long old claims remain valid, and revoking active tokens on role changes forces the application to re-evaluate access. This is the most direct fix for role drift in an SSO or claims-based environment. It addresses the timing gap rather than the network or user interface. Why others are wrong: Increasing token lifetime makes the stale-access window worse. Moving the application to another subnet does not affect token validity or authorization decisions already in place. Disabling group-based authorization would eliminate the control entirely and let any authenticated user approve expenses, which is far less secure than the current design. The best solution must make authorization reflect current identity state quickly, not weaken the model.
Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.
Sign in to join the discussion.