Panorama Push Failure and Help-Desk Least Privilege
Panorama manages 14 firewalls in three device groups: DC, Branch, and Guest. Template stacks map interfaces and zones. After a network team changes a branch switch VLAN, a Panorama commit succeeds, but the push to two branch firewalls fails with 'interface ethernet1/3 is not assigned to a zone' and those firewalls keep the previous configuration. Meanwhile, the help desk has been given the built-in superuser role because read-only log access 'didn't work' - they could not see logs from branch firewalls. The security team also wants 90 days of traffic logs, but Panorama retains only 30 days, and the branch firewalls have 16 GB local storage.
1. The Panorama commit succeeds but the push to two branch firewalls fails with 'interface ethernet1/3 is not assigned to a zone.' What is happening, and what is the safest fix?
Read the worked answer
Commit to Panorama only validates the Panorama configuration; push validation runs per managed firewall. A template stack change likely removed ethernet1/3 from a zone, or the interface was renamed while a zone or policy still references it, or template stack order means the wrong template wins. Check the device group versus template, template stack order, local overrides on the two firewalls, and the exact validation error in the push job. Fix in Panorama templates, not with local CLI edits, because local changes are overwritten on the next push and create configuration drift. Add the interface to the correct zone in the template, commit to Panorama, then push to a canary firewall first. If the interface no longer exists, remove stale zone references and update policy.
2. Help desk needs read-only access to branch logs but currently has superuser. Design the least-privilege role and explain why read-only log access may have failed.
Read the worked answer
Create a Panorama admin role profile with Monitoring read-only for traffic, threat, URL, and WildFire logs, and no configuration or commit rights. Assign it through a role assignment to the help-desk group. Built-in superuser is excessive and bypasses least privilege. Read-only log access may fail because logs reside on managed firewalls and are not forwarded to Panorama, or because the role lacks visibility to the relevant device groups. Fix by configuring log forwarding from branch firewalls to Panorama or Cortex Data Lake, setting retention, and granting the role visibility to all device groups but no configuration rights. Test with a help-desk account: they should see logs but be unable to commit, push, or edit objects.
3. Panorama retains 30 days, but the requirement is 90 days. Branch firewalls have 16 GB local storage. What are the options?
Read the worked answer
Do not rely on 16 GB local storage; it will not hold 90 days at branch volume. Options: expand Panorama storage or deploy a Panorama appliance/VM with more disk; forward logs to Cortex Data Lake if licensed; forward to an external syslog or SIEM for long-term retention; and reduce log volume by tuning high-volume benign logs and using log forwarding profiles. Retention must be designed before decryption increases log volume. Verify per-log-type retention, because traffic, threat, URL, and decryption logs can have different quotas. If the requirement is regulatory, document the chosen repository and test search and restore.