11.1 Panorama Architecture, Device Groups & Template Stacks

11.1 Panorama Architecture, Device Groups & Template Stacks

Panorama Is Still on the Blueprint

It is tempting to assume that Strata Cloud Manager has retired Panorama and that chapter 7 therefore covers everything the exam asks about management. It does not. Blueprint task 2.4 requires you to "explain the functionality of Panorama and Strata Cloud Manager (SCM) for managing Strata and SASE solutions," and task 5.4 asks about "supported products, new device addition, reporting, and configuration management in SCM and Panorama." Both platforms are examinable, and several Prisma Access and PAN-OS features documented in this guide are explicitly scoped as "Prisma Access (Managed by Panorama)."

---

Deployment Modes

A Panorama appliance is deployed in one of four modes, and the mode determines whether it manages configuration, stores logs, or both.

Panorama runs as the M-Series hardware appliance or as a virtual appliance on supported hypervisors and public clouds. Management Only mode plus separate Log Collectors is the standard scaling pattern: configuration management and log ingestion have very different resource profiles, and separating them lets each scale independently.

Panorama High Availability

Panorama HA is active/passive only — there is no active/active Panorama. The peers synchronise configuration, and the passive peer takes over management if the active fails. Managed firewalls continue enforcing policy normally while Panorama is down; losing Panorama costs you central management and logging, not enforcement. On the Panorama HA configuration you specify how many milliseconds the system waits before acting on a control link failure: the range is 1,000 to 60,000 ms with a default of 3,000 ms.

---

The Two Hierarchies — the Most Examined Panorama Concept

Panorama pushes configuration through two completely separate containers, and confusing them is the single most common Panorama mistake.

   +-------------------------------+     +-------------------------------+
   |        DEVICE GROUPS          |     |   TEMPLATES / TEMPLATE STACKS |
   +-------------------------------+     +-------------------------------+
   | Security, NAT, QoS, PBF,      |     | Interfaces, zones, virtual/   |
   | Decryption, Authentication,   |     | logical routers, IKE/IPSec,   |
   | Application Override,         |     | DNS, NTP, SNMP, log settings, |
   | DoS Protection, SD-WAN rules  |     | HA, admin accounts, certs,    |
   | + all Objects (addresses,     |     | GlobalProtect portal/gateway  |
   |   services, profiles, tags)   |     | network configuration         |
   +-------------------------------+     +-------------------------------+
        = Policies + Objects tabs             = Device + Network tabs

If it appears on the Policies or Objects tab of a firewall, it comes from a device group. If it appears on the Device or Network tab, it comes from a template. A firewall is assigned to exactly one device group and one template stack.

Device Group Hierarchy and Rule Evaluation Order

Device groups can be nested into a hierarchy up to four levels deep beneath Shared, so a global ruleset can be inherited and progressively specialised by region, then country, then site type.

The resulting rule evaluation order on the firewall is fixed and heavily examined:

1. Shared pre-rules
2. Device group pre-rules — evaluated from the highest to lowest level of the hierarchy
3. Local firewall rules (configured on the firewall itself, per vsys)
4. Device group post-rules — evaluated from the lowest to highest level of the hierarchy
5. Shared post-rules
6. Default rules (intrazone-default, interzone-default)

The firewall implements the action of the first matching rule and disregards the rest.

Exam Trap Alert: Note the inversion. Pre-rules run top-down through the hierarchy (Shared first, most specific last), while post-rules run bottom-up (most specific first, Shared last). This is what makes the pattern "global allow-list as a pre-rule, global deny as a post-rule" work: the global deny sits at the very bottom of every firewall's evaluation, after every local and child-group exception has had its chance to match.

Template Stacks

A template stack combines multiple templates and is pushed to firewalls as a single unit. Panorama supports up to 1,024 template stacks, and each stack can contain up to 8 templates.

Conflict resolution is by position in the list, not by specificity: if two templates define the same setting, Panorama pushes only the setting from the template that is higher in the list. If Template_A sits above Template_B and both define ethernet1/1, the definition from Template_A wins. Templates are re-ordered with Move Up and Move Down, and Panorama does not validate template combinations in stacks, so an invalid combination is your problem to plan around.

Best practice from the Panorama guidance is to build modular templates — model-specific ones for interface layouts, use-case-specific ones for admin roles and logging — accepting that an individual template may be incomplete. The configuration must be complete and all references resolved at the template stack level, not in every template.

Firewalls with non-matching modes (VPN mode, multi-vsys mode, operational mode) can share a stack; Panorama pushes mode-specific settings only to the firewalls that support them.

Overrides

When an administrator overrides a pushed setting locally on a firewall, the firewall saves that value to its local configuration and Panorama no longer manages the setting. To restore central control you force the template or template stack configuration onto the firewall from Panorama. Similarly, deleting a template stack or removing a firewall from it does not delete values Panorama previously pushed — Panorama simply stops sending updates.

---

Adding a New Device

Blueprint task 5.4 names "new device addition" explicitly. The workflow is:

1. Add the serial number under Panorama > Managed Devices > Add.
2. Point the firewall at Panorama in Device > Setup > Management > Panorama Settings, or use Zero Touch Provisioning (ZTP) so a factory-fresh firewall registers itself when it first reaches the internet.
3. Exchange device certificates so the connection is mutually authenticated.
4. Assign the firewall to a device group and a template stack.
5. Commit to Panorama, then Push to Devices. These are two distinct operations: committing saves the candidate configuration on Panorama, and pushing delivers it to firewalls. A "Commit and Push" action performs both.

Panorama also supports migrating an existing firewall into management while reusing its existing configuration, importing the device configuration into a new device group and template so that a working firewall does not have to be rebuilt from scratch.

---

Configuration Management and Change Control

---

Reporting and Visibility

Panorama aggregates logs from managed firewalls, either into its own Log Collectors or through the Strata Logging Service, and provides:

• Application Command Center (ACC) across the whole managed estate rather than one firewall at a time.
• Predefined and custom reports, report groups, and PDF summary reports.
• An email scheduler that delivers report groups to stakeholders on a recurring schedule.
• Log Collector Groups with log forwarding preference lists, so each firewall knows its primary and secondary collectors.

---

Panorama Versus Strata Cloud Manager

Both are current products. Panorama remains the answer for estates with regulatory or connectivity constraints that preclude a cloud control plane, and Prisma Access tenants deployed as "Managed by Panorama" continue to be documented and supported. Section 7.3 covers the migration pathway when an organisation does move to Strata Cloud Manager.