Which Sponsor Group Restricts Guest Account Management to Same-Group Sponsors?
A network administrator must restrict sponsor account privileges for managing guest accounts on Cisco ISE for a new account that is being created. Sponsor groups currently exist for each business unit. The new sponsor that is being added must be restricted to only managing guest accounts created by sponsors from the same sponsor group. In which group must the new sponsor account be configured?
Community Votes
100% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
This item tests the three ISE sponsor-account management scopes — OWN_ACCOUNTS, GROUP_ACCOUNTS, and ALL_ACCOUNTS — and the trap is reading "restricted" as OWN_ACCOUNTS instead of the same-sponsor-group scope.
Cisco ISE sponsor accounts inherit their guest-account management scope from the sponsor group applied in the sponsor portal authorization policy. For a new sponsor who must only manage guest accounts created by sponsors in the same sponsor group, the correct scope is GROUP_ACCOUNTS (A).
The most common wrong pick is OWN_ACCOUNTS, because the word "restricted" sounds like "only my own accounts"; OWN_ACCOUNTS would limit the sponsor to the guest accounts that specific sponsor created, which is narrower than what the requirement asks for. ALL_ACCOUNTS is the opposite error, granting management of every guest account in the deployment.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Cisco ISE defines the guest-account management scope through the sponsor group that the sponsor portal authorization policy returns, and the values map to OWN_ACCOUNTS, GROUP_ACCOUNTS, and ALL_ACCOUNTS. GROUP_ACCOUNTS is documented as the group whose sponsors "can manage just the guest accounts created by sponsors from the same sponsor group," which is exactly the requirement stated in the scenario. Because sponsor groups already exist per business unit, placing the new sponsor identity in GROUP_ACCOUNTS ties its visibility to its own business-unit sponsor peers and nothing else. This is also the default sponsor identity group, so no custom authorization profile is needed to satisfy the constraint.Why the Other Options Are Wrong
ALL_ACCOUNTS is far too permissive: a sponsor in that scope can see and manage guest accounts created by any sponsor in the deployment, which breaks the business-unit isolation the administrator wants. OWN_ACCOUNTS is too restrictive in the wrong direction — it limits the sponsor to accounts that particular sponsor personally created, not to accounts created by peers in the same sponsor group. ALL_EMPLOYEES is a default user identity group used to classify employee-type identities in ISE; it is not one of the sponsor-account management scopes and does not control which guest accounts a sponsor can administer. Option C is also written with a stray space in "ALL_ ACCOUNTS," but the underlying intent is the same overly broad ALL_ACCOUNTS scope.Community Comment Notes
All recorded votes land on option A, and the reasoning mirrors the official behavior. As dreamleo puts it, "The sponsor need to manage guest accounts created by sponsors from the same sponsor group, should be in GROUP_ACCOUNTS." Jimmyb007 adds the vendor wording that sponsors in this group "can manage just the guest accounts created by sponsors from the same sponsor group" and notes it is the default sponsor identity group. Gtekzzz confirms the same conclusion and points to Cisco's own guest-account management documentation, which is the authoritative source cited below. There is no dissenting comment to reconcile.Official Reference
Exam Strategy
Memorize the three sponsor scopes as a ladder — OWN_ACCOUNTS (just mine), GROUP_ACCOUNTS (my sponsor group), ALL_ACCOUNTS (everyone) — and match the scenario's wording to the rung it describes. Phrases like "same sponsor group" or "same business unit" always map to GROUP_ACCOUNTS on 300-715.
Frequently Asked Questions
Why is OWN_ACCOUNTS the wrong pick for this new sponsor account?
OWN_ACCOUNTS limits a sponsor to the guest accounts that sponsor personally created, so peers in the same business unit would be invisible — narrower than the stated requirement.
How does GROUP_ACCOUNTS differ from ALL_ACCOUNTS in the ISE sponsor portal?
GROUP_ACCOUNTS lets a sponsor manage only accounts created by sponsors in its own sponsor group, while ALL_ACCOUNTS grants management of every guest account across the deployment.