A superuser is tasked with creating administrator accounts for three contractors. For compliance purposes, all three contractors will be working with different device-groups in their hierarchy to depl

Question

Options

• ACreate a Dynamic Admin with the Panorama Administrator role
• BCreate a Custom Panorama Admin
• CCreate a Device Group and Template Admin
• DCreate a Dynamic Read only superuser

• A
  3% (1)
• B
  10% (3)
• C
  73% (22)
• D
  13% (4)

Explanation

Device Group and Template Admin is the right fit because it allows scoped, per-contractor access limited to specific device groups in the hierarchy - exactly what's needed when three contractors each manage different device groups for policy and object deployment, satisfying both the operational and compliance requirements.

Why the distractors are wrong:

• A (Dynamic Admin / Panorama Administrator role): This grants broad Panorama-wide admin rights, which violates the principle of least privilege and gives contractors far more access than their assigned device groups require.
• B (Custom Panorama Admin): A custom admin role can be tailored, but it still operates at the Panorama level rather than being natively scoped to specific device groups - it's more work for less precision.
• D (Dynamic Read-Only Superuser): Read-only access prevents any actual deployment of policies or objects, making it useless for contractors who need to actively deploy.

Memory tip: Think "scope matches role" - when the requirement explicitly mentions different device groups and compliance, the answer will always be the role that maps directly to device group boundaries. If you see "device-group" + "compliance" + "multiple admins," think Device Group and Template Admin.

No community discussion yet for this question.