Panorama Overview

The Panorama™ management server provides centralized monitoring and management of multiple Palo Alto Networks next-generation firewalls and of WildFire appliances and appliance clusters. It provides a single location from which you can oversee all applications, users, and content traversing your network, and then use this knowledge to create application enablement policies that protect and control the network. Using Panorama for centralized policy and firewall management increases operational efficiency in managing and maintaining a distributed network of firewalls. Using Panorama for centralized WildFire appliance and WildFire appliance cluster management increases the number of firewalls a single network supports, provides high availability for fault tolerance, and increases management efficiency.

About Panorama

Panorama enables you to effectively configure, manage, and monitor your Palo Alto Networks firewalls with central oversight. The three main areas in which Panorama adds value are:

Centralized configuration and deployment —To simplify central management and rapid deployment of the firewalls and WildFire appliances on your network, use Panorama to pre-stage the firewalls and WildFire appliances for deployment. You can then assemble the firewalls into groups, and create templates to apply a base network and device configuration and use device groups to administer globally shared and local policy rules. See Centralized Firewall Configuration and Update Management.
Aggregated logging with central oversight for analysis and reporting —Collect information on activity across all the managed firewalls on the network and centrally analyze, investigate and report on the data. This comprehensive view of network traffic, user activity, and the associated risks empowers you to respond to potential threats using the rich set of policies to securely enable applications on your network. See Centralized Logging and Reporting.
Distributed administration —Enables you to delegate or restrict access to global and local firewall configurations and policies. See Role-Based Access Control for delegating appropriate levels of access for distributed administration.

Six Panorama Models are available: the Panorama virtual appliance, M-600 appliance, M-500 appliance, and M-200 appliance are supported in PAN-OS 10.0 and later releases. The M-300 appliance and M-700 appliance are supported in PAN-OS 10.2 and later releases. Panorama Centralized Management illustrates how you can deploy Panorama in a high availability (HA) configuration to manage firewalls.

Panorama Centralized Management Diagram — Figure 1: Panorama Centralized Management

Panorama Models

Panorama is available as one of the following virtual or physical appliances, each of which supports licenses for managing up to 25, 100, or 1,000 firewalls. Additionally, M-600 and M-700 appliances support licenses for managing up to 5,000 firewalls and similarly resourced Panorama virtual appliances support licenses for managing up to 2,500 firewalls:

Panorama virtual appliance —This model provides simple installation and facilitates server consolidation for sites that need a virtual management appliance. You can install Panorama on Alibaba Cloud, Amazon Web Services (AWS), AWS GovCloud, Microsoft Azure, Google Cloud Platform (GCP), KVM, Hyper-V, Oracle Cloud Infrastructure (OCI), a VMware ESXi server, or on VMware vCloud Air. The virtual appliance can collect firewall logs locally at rates of up to 20,000 logs per second and can manage Dedicated Log Collectors for higher logging rates. The virtual appliance can function as a dedicated management server, a Panorama management server with local log collection capabilities, or as a Dedicated Log Collector. For the supported interfaces, log storage capacity, and maximum log collection rates, see the Setup Prerequisites for the Panorama Virtual Appliance. You can deploy the virtual appliance in the following modes:
- Panorama mode —In this mode, the Panorama virtual appliance supports a local Log Collector with 1 to 12 virtual logging disks. Each logging disk has 2TB of storage capacity for a total maximum of 24TB on a single virtual appliance and 48TB on a high availability (HA) pair. Only Panorama mode enables you to add multiple virtual logging disks without losing logs on existing disks. Panorama mode also provides the benefit of faster report generation. In Panorama mode, the virtual appliance does not support NFS storage.
- Legacy mode (ESXi and vCloud Air only)—In this mode, the Panorama virtual appliance receives and stores firewall logs without using a local Log Collector. By default, the virtual appliance in Legacy mode has one disk partition for all data. Approximately 11GB of the partition is allocated to log storage. If you need more local log storage, you can add one virtual disk of up to 8TB on ESXi 5.5 and later versions or on vCloud Air. Earlier ESXi versions support one virtual disk of up to 2TB. If you need more than 8TB, you can mount the virtual appliance in Legacy mode to an NFS datastore but only on the ESXi server, not in vCloud Air. This mode is only available if your Panorama virtual appliance is in Legacy mode on upgrade to PAN-OS 10.0. On upgrade to PAN-OS 9.0 and later releases, Legacy mode is no longer available if you change to any other mode. If you change your Panorama virtual appliance from Legacy mode to one of the available modes, you will no longer be able to change back into Legacy mode.
As a best practice, deploy the Panorama virtual appliance in Panorama mode to optimize log storage and report generation. Legacy mode is not recommended for production environments.
- Management Only mode —In this mode, the Panorama virtual appliance is a dedicated management appliance for your managed devices and Dedicated Log Collectors. An appropriately resourced Panorama virtual appliance can manage up to 2,500 firewalls in this mode. The Panorama virtual appliance has no log collection capabilities except for config and system logs and requires a Dedicated Log Collector to store these logs.
- Log Collector mode —The Panorama virtual appliance functions as a Dedicated Log Collector. If multiple firewalls forward large volumes of log data, a Panorama virtual appliance in Log Collector mode provides increased scale and performance. In this mode, the appliance does not have a web interface for administrative access; it has only a command line interface (CLI).
M-Series appliance —The M-200, M-300, M-500, M-600, and M-700 appliances are dedicated hardware appliances intended for large-scale deployments. In environments with high logging rates (over 10,000 logs per second) and log retention requirements, these appliances enable scaling of your log collection infrastructure. All M-Series models share attributes like RAID drives, SSD for Panorama/Log Collector logs, 1Gbps interfaces (MGT, Eth1-3), redundant power supplies, and front-to-back airflow.

The M-500 and M-600 appliances have additional 10Gbps interfaces (Eth4, Eth5). The M-600 and M-700 appliances in Management Only mode can manage up to 5,000 firewalls.

You can deploy the M-Series appliances in the following modes:
- Panorama mode —The appliance functions as a Panorama management server to manage firewalls and Dedicated Log Collectors, and supports a local Log Collector. This is the default mode.
- Management Only mode —The Panorama appliance is a dedicated management appliance. It has no log collection capabilities (except config/system logs) and requires Dedicated Log Collectors.
- Log Collector mode —The appliance functions as a Dedicated Log Collector, providing increased scale and performance for high log volumes. It has only a CLI for direct access.

     Understanding the different Panorama modes (Panorama, Management Only, Log Collector, Legacy) and their capabilities, especially regarding log collection and device management capacity, is crucial for the PCNSE exam. Note the specific capabilities of M-Series vs. Virtual Appliances.
    

Plan Your Panorama Deployment

Determine the management approach: centralized configuration, policy management, software/content/license updates, and/or centralized logging and reporting.
If transitioning existing firewalls, plan the migration of configurations and policies to Panorama.
Verify Panorama and firewall software versions. Panorama can manage firewalls running PAN-OS versions that match or are earlier than the Panorama version.
(Multi-vsys firewalls) Manage all vsys configurations from Panorama to avoid commit issues and optimize shared object pushes.
(Multi-vsys firewalls) Delete or rename any locally configured firewall Shared object that has an identical name to an object in the Panorama Shared configuration to prevent push failures.
Determine authentication method between Panorama and managed devices/HA peer (default predefined certificates or custom certificates).
Plan for Panorama High Availability (active/passive pair is recommended).
Plan for network segmentation and security in large-scale M-Series deployments (using dedicated interfaces beyond MGT).
Plan a logging solution:
- Estimate log storage capacity (consider Panorama models, topology, number of firewalls, log types, rates, retention).
- Decide on forwarding logs to external services (syslog, etc.) in addition to Panorama.
- Choose between on-premises log storage or leveraging Strata Logging Service.
- Consider a SIEM solution for long-term storage.
- Plan for log redundancy (Collector Groups with multiple Log Collectors or HA peers for Panorama virtual appliance in Legacy mode).
- NFS storage considerations for Panorama virtual appliance in Legacy mode (ESXi only, primary peer only).
Determine role-based access privileges for administrators.
Plan Device Groups (function, policy, location, segmentation; hierarchy considerations).
Plan policy layering strategy (shared, device-group, firewall-specific rules).
Plan firewall organization based on network configuration inheritance from Templates and Template Stacks.

Centralized Firewall Configuration and Update Management

Panorama™ uses device groups and templates to group firewalls into logical sets that require similar configuration. You use device groups and templates to centrally manage all configuration elements, policies, and objects on the managed firewalls. Panorama also enables you to centrally manage licenses, software (PAN-OS® software, SSL-VPN client software, GlobalProtect™ agent/ app software), and content updates (Applications, Threats, WildFire®, and Antivirus). All device group, template, and template stack configuration objects are required to have a unique name.

In the event an unforeseen restart of your managed firewall or Panorama occurs, all uncommitted configuration changes in your device groups and templates are preserved locally until you successfully commit the changes. For firewalls or Panorama in a high availability (HA) configuration, the uncommitted configuration changes do not automatically sync across the HA peers in the event of an unforeseen restart.

Context Switch—Firewall or Panorama

The Panorama™ web interface enables you to toggle between a Panorama-centric view and a firewall-centric view using the Context drop-down. Set the Context to Panorama to manage firewalls centrally or switch context to the web interface of a specific firewall to configure it locally. The similarity of the Panorama and firewall web interfaces enables you to seamlessly move between them.

For firewalls in an HA configuration, icons indicate the HA state (Green: Active, Yellow: Passive/Initiating, Red: Non-functional/Suspended/Tentative).

     A Device Group and Template admin requires a
     
      Device Admin Role
     
     pushed to managed firewalls to enable context switching. Panorama validates vsys access for the admin during context switch.

Total Configuration Size for Panorama

Exceeding the supported total configuration file size of the Panorama management server results in reduced performance. The Panorama management server in Panorama mode supports a total configuration file size of 80MB for all template, device group, and Panorama-specific configurations. The maximum configuration file size supported by Panorama in Management Only mode depends on the Panorama model or resources allocated.

Panorama Model	Virtual Resources Required	Maximum Configuration File Size in Management Only Mode	Maximum Configuration File Size in Panorama Mode
M-200	N/A	120 MB	80 MB
M-300		150 MB
M-500		120 MB
M-600		150 MB
M-700		180 MB
Panorama Virtual Appliance	16 vCPU 128GB memory	120 MB
	56 vCPU 256GB memory	150 MB

Templates and Template Stacks

Templates and template stacks configure settings under the Network and Device tabs on Panorama™. Templates define interface/zone configs, server profiles, VPNs, etc. Template stacks layer multiple templates for a combined configuration, simplifying management by defining a common base and layering specific settings. Templates are evaluated top-to-bottom in a stack, with higher templates having priority.

Template Stacks Diagram — Figure 2: Template Stacks

Both support variables for placeholders (IPs, Group IDs, interfaces). Template variables are inherited by template stacks and can be overridden. Firewalls can also override pushed settings locally.

     Templates or template stacks cannot set firewall modes (VPN, multi-vsys, operational modes like FIPS-CC). However, firewalls with non-matching modes can be assigned to the same template/stack; Panorama pushes mode-specific settings only to supportive firewalls.
    

Device Groups

Device groups logically unitize firewalls based on network segmentation, location, function, etc., for similar policy configurations. They are used to configure policy rules and referenced objects.

Device Group Hierarchy, Policies, and Objects

Device Group Hierarchy

You can create a device group hierarchy up to four levels. Lower-level groups inherit settings (policy rules and objects) from higher-level groups (ancestors). All device groups inherit from the Shared location at the top. This allows organizing firewalls based on common policy requirements without redundant configuration.

In a multiple Panorama plugin deployment, a device group with firewalls in one hypervisor cannot be a child/parent of a device group with firewalls in a different hypervisor.

Device Group Hierarchy with Plugin Constraint Example

Device Group Policies

A firewall evaluates policy rules by layer (shared, device group, local) and type (pre-rules, post-rules, default rules) in a specific order. The first matching rule's action is taken. Panorama-inherited rules are shaded orange on the firewall.

     
      Policy Evaluation Order (CRITICAL for PCNSE):
     
       Shared pre-rules
      
       Device group pre-rules (highest to lowest ancestor)
      
       Local firewall rules
      
       Device group post-rules (lowest to highest ancestor)
      
       Shared post-rules
      
       Default rules (intrazone-default, interzone-default)

Evaluation Order	Rule Scope and Description	Administration Device
Shared pre-rules Device group pre-rules	Shared pre-rules push to all firewalls. Device group-specific pre-rules push to firewalls in that group and descendants. Evaluated highest to lowest level (Shared first). Used for acceptable use policies (e.g., block URL categories, allow DNS).	Visible on firewalls, managed in Panorama.
Local firewall rules	Specific to a single firewall or vsys.	Visible on firewalls, managed in Panorama.
Device group post-rules Shared post-rules	Shared post-rules push to all. Device group-specific post-rules push to that group and descendants. Evaluated lowest to highest level (descendants first, Shared last). Typically include rules to deny based on App-ID™, User-ID™, or service.	Visible on firewalls, managed in Panorama.
intrazone-default interzone-default	Apply to Security rulebase. Intrazone-default allows traffic within a zone. Interzone-default denies traffic between zones. Overridden settings at firewall level take precedence over device group, which takes precedence over Shared.	Default rules can be overridden for tags, action, logging, security profiles at Panorama (Shared/DG) or Firewall level.

Device Group Objects

Objects (IPs, URL categories, security profiles, users, services, applications) are referenced by policy rules. Shared objects are available to all rules in the hierarchy. Device group objects are available to rules in that DG and its descendants. Inherited object values can be overridden.

     
      Object Management:
     
        Pushing unused objects:
       
       By default, Panorama pushes all objects. Can be configured to push only referenced objects.
      
        Precedence of ancestor/descendant objects:
       
       By default, descendant object values take precedence. Can be reversed to push values from Shared or highest ancestor.

Panorama Commit, Validation, and Preview Operations

When ready to activate changes (candidate configuration) on Panorama or push to managed devices, you can Preview, Validate, or Commit Configuration Changes. Changes must be committed to Panorama before they can be pushed to devices. Panorama queues commit requests and prioritizes auto-commits (e.g., FQDN refreshes).

Validation checks for errors or warnings before committing, allowing fixes beforehand. A commit preview shows what changes will be activated.

     
      Automated commit recovery
     
     is enabled by default. Managed firewalls test configurations pushed from Panorama. If a commit breaks connectivity, the firewall reverts to the previous running configuration, and its status in Panorama becomes "out of sync".

     Panorama pushes its
     
      running configuration
     
     to managed firewalls. Therefore, changes must first be committed to Panorama before they can be pushed.

Use the Panorama Task Manager (icon) to view, cancel, or see details of commits.

Panorama Commit and Push Process

Centralized Logging and Reporting

Panorama aggregates logs from managed firewalls, providing visibility across network traffic. It also audits policy modifications and configuration changes. Panorama can forward logs as SNMP traps, email, syslog, or HTTP payloads.

The cloud-based Strata Logging Service is an option for log collection, working with Panorama to augment or scale logging infrastructure.

The Application Command Center (ACC) on Panorama offers unified reporting and allows analysis of traffic and security incidents. Panorama can query logs from Strata Logging Service, its local/managed Log Collectors, or directly from managed firewalls.

Managed Collectors and Collector Groups

Panorama uses Log Collectors to aggregate logs.

Local Log Collector: Runs on the Panorama management server (M-Series or virtual appliance in Panorama mode).
Dedicated Log Collector: An M-Series appliance or Panorama virtual appliance in Log Collector mode. Managed by Panorama, offers higher scale and performance. Accessed via CLI for initial setup/debugging.

A Collector Group is 1 to 16 managed collectors acting as a single logical unit. Panorama distributes logs uniformly across disks and collectors in a group. A Log Collector must be in a Collector Group to receive logs.

Local and Distributed Log Collection

A local Log Collector is easy to deploy. Dedicated Log Collectors allow Panorama to use more resources for management, provide high-volume storage, higher logging rates, scalability, and can help meet regional regulatory requirements.

Distributed Log Collection Diagram — Figure 4: Distributed Log Collection

     Panorama management server can be in an HA configuration, but Dedicated Log Collectors cannot.
    

Caveats for a Collector Group with Multiple Log Collectors

A Collector Group with multiple Log Collectors (up to 16) ensures redundancy, increases retention, and handles high logging rates. All Log Collectors in a group must be the same Panorama model.

Figure 5: Example - Typical Log Collector Group Setup

Log distribution uses a hash algorithm. Even with a preference list, Panorama might choose a different collector in the list to own and write logs.

Log Collector Failure Example — Figure 6: Example - When a Log Collector Fails

     Palo Alto Networks recommends adding at least
     
      three Log Collectors
     
     to a Collector Group to avoid split brain and log ingestion issues if one goes down. Two Log Collectors are supported, but the group becomes non-operational if one fails.

Mitigations for multiple Log Collectors:

Enable log redundancy in Collector Group (requires same number of logging disks per collector, doubles storage needs, halves max logging rate).
Obtain On-Site-Spare (OSS).
Forward logs to an external service as standby.

Log Forwarding Options

Firewalls store logs locally by default. For centralized monitoring, configure log forwarding to Panorama (Log Collector or Strata Logging Service, or both). Logs can also go to external services (syslog, email, SNMP, HTTP) directly from firewalls or from Panorama.

• Forward logs from firewalls to Panorama and from Panorama to external services: Good for insufficient bandwidth between firewalls and external services.

• Forward logs from firewalls to Panorama and to external services in parallel: Good if bandwidth between firewalls and external services is sufficient.

Log Forwarding to Panorama and External in Parallel — Figure 8: Log Forwarding to External Services and Panorama in Parallel

Centralized Reporting

Panorama aggregates logs for a global view. The ACC displays traffic as soon as firewalls are added. Panorama uses its local database (including managed Log Collectors) and remote firewalls for report generation. It summarizes information from firewalls at 15-minute intervals. Over 40 predefined reports are available, customizable, and can be scheduled.

Simplified Log Collection and Reporting Flow

Security, Setup & Exam Focus

Data Redistribution Using Panorama

Data redistribution allows configuring a source once and redistributing multiple data types (e.g., User-ID mappings, authentication timestamps, tags) to many clients (firewalls, Panorama systems). This scales networks and provides granularity. Panorama can redistribute data in layers from firewalls to Panorama, then to other firewalls. Each firewall or Panorama can receive data from up to 100 redistribution points.

Role-Based Access Control (RBAC)

RBAC defines privileges for administrative users. Each admin account has a role and authentication method. Administrative Roles define access to Panorama and firewall contexts. For Device Group and Template admins, roles map to Access Domains (specific device groups, templates, firewalls).

     Best practice: Create separate admin accounts instead of using the default 'admin' account.
    

Administrative Roles

Dynamic Roles: Built-in, auto-updated roles.

Dynamic Role	Privileges
Superuser	Full read-write access to Panorama
Superuser (readonly)	Read-only access to Panorama
Panorama administrator	Full access except managing admins/roles, config operations (export, import, etc.), scheduled config export, generating support/core files.

Admin Role Profiles: Custom roles for granular access (web, CLI, XML API). Require manual updates for new features.

Admin Role Profile	Description
Panorama	Read-write/read-only/no access to Panorama features (except admin/role management - only read-only/no access). Limitations: no reboot, no tech support/core file generation.
Device Group and Template	Read-write/read-only/no access to functional areas within DGs, templates, firewall contexts. Combined with Access Domains. Limitations: no CLI/XML API, no config/system logs, no VM info sources, no reboot/support/core files. Limited access in Panorama tab.

Authentication Profiles and Sequences

An authentication profile defines the service (local, external: SAML, TACACS+, RADIUS, LDAP) for validating admin credentials. Some services manage auth and authorization externally. An authentication sequence ranks profiles for login attempts.

Access Domains

Access domains control admin access to specific Device Groups, templates, and context switching to managed firewalls. Apply only to Device Group and Template roles. Can be assigned locally or via external SAML/TACACS+/RADIUS servers (using VSAs or SAML attributes).

Administrative Authentication

Authentication/Authorization methods include Local, SSH Keys (CLI), Certificates (Web UI), External service with Local authorization, and External service with External authorization (SAML, TACACS+, RADIUS).

     For PCNSE, understand how different admin roles (Superuser, Panorama Admin, DG/Template Admin) restrict access and how Access Domains further refine permissions for DG/Template Admins. Also, know the methods for external authentication and authorization (RADIUS VSAs, TACACS+ VSAs, SAML attributes).
    

Deploy Panorama: Task Overview

STEP	Task
1	(M-Series appliance only) Rack mount the appliance.
2	Perform initial configuration to enable network access to Panorama.
3	Register Panorama and Install Licenses.
4	Install Content and Software Updates for Panorama.
5	(Recommended) Set up Panorama in a high availability configuration.
6	Add a Firewall as a Managed Device.
7	Add a Device Group or Create a Device Group Hierarchy, Add a Template, and (if applicable) Configure a Template Stack.
8	(Optional) Configure log forwarding to Panorama and/or to external services.
9	Monitor Network Activity using the visibility and reporting tools on Panorama.

Set Up Panorama (Summary)

Panorama can be deployed as a virtual appliance or a hardware M-Series appliance. Key setup considerations include:

Log Storage Requirements: Estimate based on firewalls, log rates, retention policies. Consider Panorama model capacities.
Virtual Appliance Setup: Deploy on supported hypervisors/clouds (VMware ESXi, KVM, AWS, Azure, GCP, etc.). Allocate appropriate vCPUs, memory, and disk space based on mode (Panorama, Management Only, Log Collector) and scale.
M-Series Appliance Setup: Physical installation, initial network configuration via console/MGT port.
Registration and Licensing: Register Panorama with Palo Alto Networks support portal. Install necessary licenses (device management, support, subscriptions).
Device Certificates: Panorama and managed devices use SSL for communication. Default certificates are used, but custom certificates can be configured for enhanced security (Panorama device certificate, Dedicated Log Collector certificate).
Administrative Access: Configure admin accounts, roles, and authentication methods (as covered in RBAC).

PCNSE Exam Focus & Key Diagrams:

     
      Panorama Management Compatibility:
     
     Panorama can manage firewalls running PAN-OS versions that are the same as or earlier than the Panorama version. Firewalls running newer PAN-OS versions than Panorama cannot be managed.

     
      Multi-vsys Shared Objects:
     
     If a multi-vsys firewall managed by Panorama has a locally configured 'Shared' object with the same name as an object in Panorama's 'Shared' configuration, configuration pushes from Panorama will fail. Rename or delete the local firewall object.

     
      Automated Commit Recovery:
     
     Enabled by default. If a pushed configuration breaks Panorama-to-firewall connectivity, the firewall reverts to its previous running configuration.

Policy Evaluation Order Flowchart

Firewall Policy Evaluation Order when Managed by Panorama

Panorama Modes (Virtual Appliance)

Panorama Virtual Appliance Deployment Modes

Panorama Knowledge Quiz

1. Which Panorama virtual appliance mode is recommended for optimizing log storage and report generation, supporting multiple virtual logging disks?

Legacy mode Management Only mode Panorama mode Log Collector mode

2. Which M-Series appliances, when in Management Only mode, can manage up to 5,000 firewalls?

M-200 and M-300 All M-Series appliances M-600 and M-700 M-500 only

3. In the policy evaluation order on a Panorama-managed firewall, which rules are evaluated immediately after Shared pre-rules?

Local firewall rules Device group pre-rules Shared post-rules Device group post-rules

4. What is the minimum recommended number of Log Collectors in a Collector Group to avoid split brain and log ingestion issues if one collector fails?

1 2 3 4

5. When Panorama pushes configurations to managed firewalls, which configuration does it push?

Candidate configuration Running configuration Last backup configuration Default factory configuration

6. What is the PAN-OS version compatibility requirement for Panorama managing firewalls?

Panorama must be newer than the firewalls. Firewalls must be newer than Panorama. Panorama can manage firewalls running the same or an older PAN-OS version. Any version combination is supported.

7. What is the maximum number of levels in a Device Group Hierarchy?

2 levels 3 levels 4 levels 5 levels

8. Which type of Panorama administrator role typically uses Access Domains to control access to specific device groups and templates?

Superuser Panorama administrator (dynamic role) Device Group and Template administrator (admin role profile) Superuser (readonly)

9. To enable context switching from Panorama to a managed firewall's web interface for a Device Group and Template admin, what must be configured?

An SNMP profile on the firewall An API key for the admin A Device Admin Role pushed to the managed firewall A shared policy rule allowing management access

10. Can Templates or Template Stacks be used to set firewall modes (e.g., multi-vsys mode, FIPS-CC mode)?

Yes, for all operational and system modes. Yes, but only for operational modes like FIPS-CC. No, templates cannot be used to set firewall modes. Yes, if variables are used within the template.

11. By default, if objects with the same name exist at multiple levels in a Device Group hierarchy, which object's values take precedence for a descendant device group?

Shared object values Highest ancestor device group's object values The descendant device group's own object values Panorama prompts the administrator to choose

12. What happens if a configuration pushed from Panorama via "automated commit recovery" breaks the connection between Panorama and a managed firewall?

The firewall automatically reboots. Panorama automatically retries the push after 5 minutes. The firewall automatically fails the commit and reverts to the previous running configuration. The administrator is notified, but no automatic action is taken on the firewall.

13. For a Panorama virtual appliance in Legacy mode, on which hypervisor platform is NFS storage supported for log collection?

All supported hypervisors AWS only Azure only VMware ESXi server only

14. What is a requirement for Log Collectors within a single Collector Group?

They can be different Panorama models. They must all run on the same Panorama model (e.g., all M-200s or all virtual appliances). A maximum of two different models are allowed. There is no restriction on models within a collector group.

15. How many redistribution points can a single firewall or Panorama management server receive data from for data redistribution?

Up to 10 Up to 25 Up to 50 Up to 100

16. In a Template Stack, how is the priority of settings determined if multiple templates define the same setting?

Alphabetical order of template names. The oldest template created has priority. Templates listed higher in the stack configuration have priority (top-to-bottom evaluation). The template with the smallest configuration size has priority.

17. How are Panorama-inherited rules (shared or device group) typically displayed in a managed firewall's web interface?

Shaded blue Shaded green Shaded orange No special shading, appears like local rules.

18. What is the maximum number of firewalls an appropriately resourced Panorama virtual appliance can manage in Management Only mode?

1,000 firewalls 2,500 firewalls 5,000 firewalls Unlimited, depends only on resources.

19. Which Panorama interface element allows an administrator to view, cancel, or see details of commit operations?

Application Command Center (ACC) Monitor > Logs The Panorama Task Manager (usually an icon) Device > Setup > Operations

20. What is a consequence of enabling log redundancy in a Collector Group?

It doubles the maximum logging rate of the Collector Group. It has no impact on the maximum logging rate. It reduces the maximum logging rate of the Collector Group by half. It requires fewer logging disks per collector.