hardmultiple choiceObjective-mapped

Exhibit

Application log excerpt:
10:20 HR updated jsmith from finance_approver to finance_viewer
10:35 invoice-approve allowed for jsmith by token claim role=finance_approver
11:05 jsmith still able to submit approval actions
JWT sample:
{
  "sub": "jsmith",
  "roles": ["finance_approver"],
  "exp": "2026-05-01T18:00:00Z"
}
Identity team note: tokens remain valid for 8 hours after sign-in.

Based on the exhibit, what is the best fix so role changes take effect promptly without waiting for token expiration?

Question 1hardmultiple choice
Full question →

Based on the exhibit, what is the best fix so role changes take effect promptly without waiting for token expiration?

Answer choices

Why each option matters

Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.

A

Distractor review

Increase the token lifetime so users reauthenticate less often during the workday.

Longer-lived tokens would make stale access last even longer, which worsens the authorization delay shown in the exhibit rather than fixing it.

B

Best answer

Perform authorization checks against current directory data on each privileged request.

This is the best fix because the problem is stale authorization, not failed authentication. The app is trusting a role claim that was correct at sign-in but became outdated after the HR change. Checking current directory data, or re-evaluating authorization on each sensitive action, ensures access follows the user's current status instead of an old token snapshot.

C

Distractor review

Store the JWT in a browser cookie so it refreshes automatically when roles change.

Moving the token into a cookie does not solve stale authorization. The application would still rely on the same outdated role information unless it revalidates the user's permissions against an authoritative source.

D

Distractor review

Disable MFA and rely only on the role claim inside the token.

Removing MFA weakens authentication and does nothing to correct the stale authorization decision. The issue is that the app trusts an old claim for too long, not that the user needs fewer login steps.

Common exam trap

Common exam trap: authentication is not authorization

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

How to think about this question

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.

KKey Concepts to Remember

  • Authentication checks who the user is.
  • Authorization controls what the user is allowed to do after login.
  • Privilege levels affect access to EXEC and configuration commands.
  • AAA, TACACS+ and RADIUS can separate login success from command access.

TExam Day Tips

  • Do not assume successful login means full administrative access.
  • Look for words such as cannot enter configuration mode, privilege level, authorization or command access.
  • Separate login problems from permission problems before choosing the answer.

Related practice questions

Related SY0-701 practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

More questions from this exam

Keep practising from the same exam bank, or move into a focused topic page if this question exposed a weak area.

FAQ

Questions learners often ask

What does this SY0-701 question test?

Authentication checks who the user is.

What is the correct answer to this question?

The correct answer is: Perform authorization checks against current directory data on each privileged request. — The log shows that authentication succeeded, but authorization remained based on an old role claim after the HR update. That is a classic stale-authorization problem. The best fix is to evaluate permissions against current directory or authorization data when a privileged action occurs, or to reissue/refresh claims frequently enough to reflect changes. This ensures access changes take effect quickly instead of waiting for the token to expire. Why others are wrong: Increasing token lifetime makes the security gap last longer. Storing the token in a cookie changes transport/storage, not the authorization logic. Disabling MFA weakens login security but does not address the core issue: the application is using outdated role information for access decisions.

What should I do if I get this SY0-701 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.

Discussion

Loading comments…

Sign in to join the discussion.