Question 123 of 1,013
SY0-701 General Security Concepts Practice Question
Exhibit
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
⚠ Common exam trap
Watch out — candidates often think increasing token lifetime improves user experience, but the question specifically asks for the best fix to reflect role changes promptly, which requires shorter lifetimes and revocation, not longer ones.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Shorten token and session lifetime and revoke active tokens when the directory role changes.
The token's long lifetime (issued at 09:10, expires at 17:10) allows the application to continue accepting the original token even after the user's directory role changes at 09:15. Shortening the token lifetime forces more frequent reauthentication, and revoking active tokens when the directory role changes ensures that the application immediately reflects the updated authorization. This aligns with the principle of dynamic access control and token lifecycle management.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the token lifetime so users reauthenticate less often.
Why it's wrong here
Increasing the token lifetime directly worsens the stale-claims problem: the identity provider issues tokens containing the user's current role, and a longer lifetime means those tokens (with pre-change roles) remain valid for a much longer window after the directory role changes. This extends the period in which the user can still perform actions based on outdated authorization, such as approving expenses they should no longer approve. It also amplifies the impact of token theft, since a stolen token stays usable longer.
- ✓
Shorten token and session lifetime and revoke active tokens when the directory role changes.
Why this is correct
This is the correct fix because it combines two complementary controls: shortening token and session lifetimes limits the maximum time any token can carry stale role claims, while revoking active tokens at the moment the directory role changes actively invalidates already-issued tokens so the authorization change is enforced immediately. Together these ensure that after a role change, the user cannot continue using old tokens with outdated permissions — they must obtain a new token with the updated role. This directly addresses the root cause of stale claims persisting in the system.
- ✗
Move the application to a different subnet to isolate it from HR systems.
Why it's wrong here
Moving the application to a different subnet is purely a network architecture change and has no effect on the contents of the user's authentication token or the authorization claims embedded in it. The token still carries the old role information no matter where the application is hosted, and the application will continue to honor those stale claims when making access decisions. Subnet isolation might improve network security or segmentation, but it does nothing to ensure that role changes are reflected in the tokens used by the application.
- ✗
Disable group-based authorization and let any authenticated user approve expenses.
Why it's wrong here
Disabling group-based authorization and allowing any authenticated user to approve expenses completely removes the access control check rather than fixing the stale role data. This creates a far more serious security vulnerability: every authenticated user, regardless of their actual job function or approved role, would have permission to approve expenses, leading to unauthorized financial actions or privilege escalation. It abandons the principle of least privilege and turns a temporary stale-claims issue into a permanent, systemic authorization failure.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Last reviewed: Jun 11, 2026
This SY0-701 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SY0-701 exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.