Introduction to Panorama

Panorama™ enables centralized management of Palo Alto Networks firewalls. It provides a single pane of glass for managing configurations, deploying policies, and monitoring network activity across multiple firewalls.

Panorama simplifies the administration of a large number of firewalls by allowing administrators to group devices, share configurations, and enforce consistent security policies. Key benefits include operational efficiency, consistent security posture, and comprehensive visibility.

Panorama centrally manages multiple firewalls across different locations.

Key Capabilities

• Centralized Configuration: Use Device Groups and Templates to manage policies and network/device settings.
• Policy Management: Create and manage security, NAT, decryption, and other policies across multiple firewalls.
• Log Collection & Reporting: Aggregate logs from managed firewalls for centralized analysis and reporting (often involves dedicated Log Collectors).
• Software & Content Updates: Centrally manage and deploy PAN-OS software updates and content updates (Applications and Threats, Antivirus, WildFire).
• High Availability (HA): Panorama itself can be deployed in an HA pair for redundancy.

Panorama Licensing

To manage firewalls, Panorama requires a Device Management License . This license dictates the maximum number of firewalls Panorama can manage.

• The total count of managed firewalls must not exceed the activated device management license limit on Panorama.
• If adding a firewall exceeds the limit, the operation is blocked, and a warning is displayed.
• You can view the active license and maximum supported firewalls by selecting Panorama > Licenses .

For the PCNSE exam, understand that Panorama's capacity to manage firewalls is tied to its licensing. Each firewall in an HA pair counts as one managed device towards the license limit.

While Panorama can manage licenses for the firewalls themselves (e.g., Threat Prevention, WildFire), Panorama itself needs its own Device Management license to function as a manager.

Device Registration & Initial Connection

To manage a firewall with Panorama, a secure connection must be established. This involves mutual authentication using a Device Registration Authentication Key .

Key Steps:

1. On Panorama: Create Device Registration Authentication Key
   • Navigate to Panorama > Device Registration Auth Key .
   • Specify Name , Lifetime (how long the key is valid), Count (how many times it can be used), and Device Type (Firewall).
   • Optionally, specify device serial numbers for which the key is valid.
   • Copy the generated authentication key.
   • This key ensures mutual authentication for the first connection.
   
2. On Panorama: Add Firewall Serial Number
   • Navigate to Panorama > Managed Devices > Summary and click Add .
   • Enter the firewall's serial number.
   • Enter the device registration authentication key created in the previous step.
   • Optionally, associate with Device Group, Template Stack, Collector Group during initial deployment.
   • Optionally, enable "Auto Push on 1st connect" (for PAN-OS 8.1+ firewalls) to push configuration immediately upon connection.
   
3. On Firewall: Configure Panorama Settings
   • Log in to the firewall's web interface.
   • Navigate to Device > Setup > Management and edit Panorama Settings.
   • Select "Panorama" for "Managed By".
   • Enter the Panorama IP address(es) (primary and optional secondary for HA).
   • Paste the authentication key copied from Panorama.
   • Commit changes on the firewall.
   
4. On Panorama: Commit Changes
   • Commit changes to Panorama ( Commit > Commit to Panorama ).
5. Verify Connection
   • On Panorama, navigate to Panorama > Managed Devices > Summary .
   • Verify the Device State for the new device shows as Connected .
   

Firewall to Panorama Registration and Connection Sequence.

The authentication key is used for the *first connection* for mutual authentication. Subsequent communications use 2,048-bit certificates and AES-256 encrypted SSL connections. For Panorama HA, the auth key is only needed for the primary Panorama; the CA certificate is synchronized for the secondary.

PAN-OS Version Compatibility

Panorama and its managed firewalls must run compatible PAN-OS versions.

• General Rule: Panorama should run the same or a newer PAN-OS version than its managed firewalls.
• Specifics for Panorama on PAN-OS 11.0.0 or later:
  • Can onboard new firewalls running PAN-OS 10.1.3 or later.
  • Cannot onboard new firewalls running PAN-OS 10.1.2 or earlier PAN-OS 10.1 releases.
  • Continues to manage firewalls running PAN-OS 10.0 or earlier PAN-OS releases that were already managed.
• Upgrading Panorama to PAN-OS 10.2 or later does not impact already managed firewalls.

Always check the Palo Alto Networks compatibility matrix for the most current version compatibility information before performing upgrades or adding new devices. Attempting to manage a firewall with an incompatible Panorama version can lead to commit failures or unpredictable behavior.

Adding Firewalls to Panorama

After the initial setup, firewalls are added to Panorama's list of managed devices. This can be done manually or by importing a CSV file.

Manual Addition:

1. Go to Panorama > Managed Devices > Summary and click Add .
2. Enter firewall Serial number(s) (one per line for multiple).
3. Enter the pre-configured Device Registration Authentication Key .
4. (Optional) Select Associate Devices to link the firewall to a Device Group, Template Stack, Log Collector, or Collector Group upon first connection.
   • If associated, you can enable Auto Push on 1st connect (for PAN-OS 8.1+) to automatically push the configuration.
   • (Optional) Specify a target PAN-OS software version ( To SW Version ) for automatic upgrade on first connect. (Requires prior content installation on the firewall).
5. Click OK .
6. Commit changes to Panorama.

Bulk Import via CSV:

1. Go to Panorama > Managed Devices > Summary and click Add .
2. Enter the Device Registration Authentication Key .
3. Click Import .
4. Download Sample CSV , edit it with firewall serial numbers and optional associations (Device Group, Template Stack, Collector Group, Log Collector, Auto Push, Target SW Version).
5. Browse to your edited CSV file and select it.
6. Review and assign any remaining associations if not in CSV.
7. Click OK .
8. Commit changes to Panorama.

Bulk import using CSV is only supported for single-vsys firewalls. You cannot bulk import firewalls with multiple virtual systems (multi-vsys).

Remember to configure the firewall itself to point to Panorama (Device > Setup > Management > Panorama Settings) using the same auth key.

Device Groups: Concepts & Hierarchy

Device Groups in Panorama are used to manage policies and objects for a set of firewalls. Firewalls with similar policy requirements are typically grouped together.

• A firewall (or a virtual system on a multi-vsys firewall) can belong to only one device group.
• Panorama supports up to 1,024 device groups.
• HA peers (active/passive) should be in the same device group to receive the same policies.

Device Group Hierarchy:

Device groups can be arranged in a hierarchy, with a top-level "Shared" location.

• Inheritance: Descendant (child) device groups inherit policies and objects from their ancestor (parent) device groups, including "Shared".
• Order of Precedence (Default):
  1. Device Group-specific objects/policies
  2. Inherited objects/policies from parent Device Group
  3. Inherited objects/policies from "Shared"
• This means a more specific configuration at a lower level overrides a general configuration from a higher level.
• You can change the precedence so that objects defined in ancestors take higher precedence ( Panorama > Setup > Management > Panorama Settings ).

Example of a Device Group Hierarchy with Inheritance.

Creating a Device Group:

1. Go to Panorama > Device Groups and click Add .
2. Enter a Name and Description .
3. Assign Devices (firewalls or virtual systems) to the group.
4. (Optional) Add Reference Template(s) if objects in the device group configuration refer to objects defined in those templates (e.g., zones defined in a template).
5. (Optional) Select Group HA Peers for visual grouping.
6. Select the Parent Device Group (default is "Shared").
7. (Optional) Assign a Master firewall if policy rules will reference users/groups (for User-ID information gathering).
8. Click OK and commit changes.

Device groups are fundamental for policy management. Understanding inheritance and object scope (Shared vs. Device Group-specific) is crucial. Remember that Reference Templates allow a device group to "see" network objects (like zones or interfaces) from a template that its member firewalls might not be directly assigned to, which is useful for policy creation.

Templates & Template Stacks: Concepts

Templates in Panorama are used to manage network and device settings for firewalls. This includes configurations for interfaces, zones, virtual routers, server profiles, services, etc.

Template Stacks are ordered collections of templates. A firewall is assigned to a single template stack, and the stack pushes the combined configuration of its member templates to the firewall.

Key Concepts:

• Templates:
  • Define common base configurations (Network and Device tabs).
  • Can be reused across multiple template stacks.
  • Panorama supports up to 1,024 templates.
  • The Device and Network tabs in Panorama become available only after the first template is added.
• Template Stacks:
  • An ordered list of up to 8 templates.
  • A firewall (or entire multi-vsys firewall) is assigned to only one template stack.
  • Settings from templates higher in the stack override conflicting settings from templates lower in the stack. Be careful with template order to avoid misconfigurations (e.g., interface type conflicts).
  • Panorama supports up to 1,024 template stacks.
  • You can override template settings directly within a template stack or on an individual firewall.

Templates are combined into a Template Stack, which is then assigned to firewalls. Order within the stack determines precedence for overlapping settings.

What Templates Manage:

• Interfaces (Ethernet, Aggregate, VLAN, Tunnel, Loopback)
• Virtual Routers, Virtual Wires
• Zones
• Server Profiles (Syslog, SNMP, Email, LDAP, RADIUS, TACACS+, DNS)
• Services (DNS, NTP, GlobalProtect settings)
• Device-wide settings (Management interface, Log settings, Banners)
• High Availability (HA) configuration (though some aspects like specific HA IP addresses are local to the firewall)

Templates are for network and device settings, while Device Groups are for policies and objects. A firewall must be in a template stack to receive template configurations. HA peers in active/passive mode are typically in the same template stack; active/active peers might be in different template stacks if their network configs differ significantly.

Renaming a VSYS is allowed only on the local firewall, not on Panorama. Doing so on Panorama can lead to a new VSYS being created or incorrect mappings.

Exceptions (Local Firewall Configuration Only):

Some settings can only be configured locally on each managed firewall and not via Panorama templates:

• Device block list.
• Clearing logs.
• Enabling operational modes (normal, multi-vsys, FIPS-CC).
• IP addresses of firewalls in an HA pair (control/data link IPs).
• Master key (though Panorama can *deploy* a new master key, the initial key or change process has local aspects).
• Comparing configuration files (Config Audit on the firewall).

Configuring Templates & Template Stacks

Adding a Template:

1. Go to Panorama > Templates , click Add .
2. Enter a unique Name and optional Description .
3. (Optional) If the template has a VSYS with configurations (e.g., interfaces) to push to firewalls without VSYS, select the template and a Default VSYS from the drop-down.
4. Commit to Panorama.
5. Use the Device and Network tabs, selecting your template from the dropdown, to define settings (e.g., Primary DNS Server under Device > Setup > Services ).

Configuring a Template Stack:

1. Go to Panorama > Templates and click Add Stack . (Cloning stacks is not supported).
2. Enter a unique Name and optional Description .
3. (Optional for VM-Series/CN-Series) Check Automatically push content when software device registers to Panorama .
4. Add up to 8 Templates to the stack. Order them by priority (higher templates override lower ones for duplicate settings). Use Move Up/Down .
5. In the Devices section, select firewalls to assign to this stack. (Entire firewall for multi-vsys).
6. (Optional) Select Group HA Peers for visual grouping.
7. Click OK .
8. Edit Network and Device settings for the stack if needed (stack-level overrides or configurations).
   • Use the Mode drop-down (Multi VSYS, Operational Mode, VPN Mode) to filter settings relevant to specific firewall operational modes to avoid push errors.
9. Commit and Push ( Commit > Commit and Push , select Templates in Push Scope, select firewalls assigned to the stack).

Every managed firewall must belong to a template stack. When you push changes to a template, Panorama pushes the configuration to every firewall assigned to any template stack that includes that template.

A template configuration cannot reference a configuration in another template directly, even if both are in the same stack (e.g., a zone in Template_A can't reference a zone protection profile in Template_B unless that profile is in Template_A or inherited by the stack).

Template & Stack Variables

Variables allow you to create reusable template/stack configurations where certain values (like IP addresses, FQDNs, interface names) can differ per firewall or device group, without needing separate templates for each variation.

Key Features:

• Variables start with a dollar sign ( $ ), e.g., $DNS-primary .
• Supported types: IP Address, IP Netmask, IP Range, FQDN, Group ID, Interface, Hostname, IPv4/IPv6 Subnet, Pre-Shared Key.
• Defined at the Template, Template Stack, or individual Device level (in Panorama > Managed Devices > Summary > Edit Variables).
• Inheritance & Override:
  • A variable defined in a Template can be used by firewalls assigned to a Stack containing that Template.
  • The Stack can override the Template's variable value.
  • An individual Device can override the Stack's (or Template's) variable value.
• Reduces the number of templates/stacks needed.

Creating and Using Variables:

1. Define the Variable:
   • Go to Panorama > Templates .
   • Click Manage (Variables column) for the desired template or template stack. OR
   • Go to Panorama > Managed Devices > Summary , select a device, and click Edit (Variables column) for device-specific variables.
   • Click Add . Enter Name (e.g., $mgmt_ip ), select Type (e.g., IP Netmask), and provide the Value.
   
2. Reference the Variable:
   • In the template/stack configuration (e.g., Device > Setup > Services ), enter the variable name (e.g., $DNS-primary for Primary DNS Server).
   
3. Commit and Push:
   • Commit changes to Panorama.
   • When pushing a device group configuration that references template/stack variables, ensure to Edit Selections in the Push Scope and Include Device and Network Templates .
4. Verify: Check the firewall context to see the resolved variable values.

Importing/Overwriting Variables via CSV:

You can export existing template stack variables to a CSV, modify values, and re-import to overwrite. This cannot be used to create new variables, only update existing ones.

1. Panorama > Templates , select a template stack.
2. Select Variable CSV > Export .
3. Edit the downloaded CSV. Correct serial number formatting if needed (format as Text, add leading '0' if Excel removed it). Update variable values. Values showing as #inherited# are defined in the template stack (not device-specific overrides).
4. Save as CSV UTF-8 .
5. In Panorama, select Variable CSV > Import , browse to your file, and click OK .
6. Commit to Panorama, then Commit and Push.

Variables are powerful for scaling configurations. Understand the hierarchy: Device-specific overrides Template Stack, which overrides Template.

Overriding Template Settings

Overrides allow for exceptions to the base configuration pushed by templates or template stacks. This provides flexibility for firewall-specific settings.

Methods to Override:

1. Override on the Firewall (Local Override):
   • Access the firewall's web interface (directly or via Panorama context switch).
   • Navigate to the setting (e.g., Device > Setup > Services ).
   • Click the template icon ( ) next to the field to enable override.
   • Enter the new firewall-specific value. The icon changes to an override symbol ( ).
   • Commit changes on the firewall.
   • This creates a local setting that takes precedence over the Panorama-pushed value for that specific firewall.
2. Override Template Value using a Template Stack (Stack-level Override):
   • In Panorama, select the Template Stack from the Template drop-down.
   • Navigate to the setting (e.g., Device > Setup > Services ).
   • Configure the desired value. This value in the stack will override the value from any template lower in its hierarchy for all firewalls assigned to this stack.
   • Commit and Push.
3. Override Template Value using a Template Stack Variable:
   • In Panorama, go to Panorama > Templates .
   • Click Manage (Variables column) for the Template Stack.
   • Select the variable inherited from a template and click Override .
   • Enter the new value for the variable at the stack level.
   • Commit and Push.
4. Override Template/Stack Value using Device-Specific Variables (Panorama Managed):
   • In Panorama, go to Panorama > Managed Devices > Summary .
   • Click Edit (Variables column) for the specific firewall.
   • Select an inherited variable (from template or stack) and click Override .
   • Enter the new firewall-specific IP address and click OK .
   • Commit and Push.

Understanding override precedence is key: Device-specific overrides beat Template Stack overrides, which beat Template values. Use overrides judiciously to maintain clarity.

To disable/remove all template settings from a firewall (reverting to local management or preparing for migration):

1. Access the firewall's web interface.
2. Go to Device > Setup > Management , edit Panorama Settings.
3. Click Disable Device and Network Template .
4. (Optional) Check Import Device and Network Template before disabling to save current settings locally. Otherwise, Panorama-pushed settings are deleted.
5. Click OK .

Master Key Management

The master key encrypts sensitive configuration elements (passwords, private keys). It's crucial for security to replace the default master key.

• Default Algorithm: AES-256-CBC (for compatibility with older PAN-OS versions).
• Recommended Algorithm: AES-256-GCM (if all managed devices run PAN-OS 10.0+).
• Uniqueness: Best practice is to configure unique master keys for Panorama and for each managed firewall (or HA pair). Log Collectors and WildFire appliances must share the same master key as Panorama.
• HA Pairs: Both Panorama HA peers and firewall HA peers require the same master key configured manually on each peer; it's not synchronized.
• Expiration: Master keys have a lifetime. If a key expires, you'll need the current key to set a new one. Losing the master key may require a factory reset.

Configuring a Unique Master Key for a Managed Firewall:

1. (Firewall HA only) Disable Config Sync on the firewall HA pair via template.
2. Panorama > Managed Devices > Summary , click Deploy Master Key .
3. Select managed firewall(s) and click Change .
4. Configure the master key: New key, Confirm, Lifetime, Reminder.
5. Click OK (key is pushed automatically). Verify System log.
6. (Optional) Configure auto-renewal via template.

Configuring Master Key on Panorama:

1. (Panorama HA only) Disable Panorama HA.
2. Panorama > Master Key and Diagnostics , configure new key, lifetime, reminder. Click OK.
3. (Optional) Configure auto-renewal for Panorama's master key. Commit to Panorama.
4. (Panorama HA only) Repeat steps on the secondary Panorama peer with the identical key.

Deploying Master Key to Log Collectors / WildFire Appliances:

Similar process via Panorama > Managed Collectors or Panorama > Managed WildFire Appliances . Key must be identical to Panorama's.

Commit any pending configuration changes *before* deploying a new master key to ensure all elements are re-encrypted correctly.

Always store master keys securely. They cannot be recovered if lost.

Scheduled Configuration Push

Panorama allows scheduling configuration pushes to managed firewalls, reducing operational overhead. This can be a one-time or recurring event.

• Supported for firewalls running any PAN-OS release.
• Superusers or custom Panorama admins with appropriate roles can create scheduled pushes.
• In Panorama HA, scheduled pushes are synchronized.
• Minimum Interval: If creating multiple scheduled pushes, ensure at least a 5-minute interval between them to allow Panorama to validate configurations.
• Panorama pushes if Device Group or Template "Last Commit Status" is "out-of-sync".

Creating a Scheduled Push:

1. Go to Panorama > Scheduled Config Push and click Add (or via Commit > Push to Devices ).
2. Configure: Name, Admin Scope, Date & Time, Recurrence.
3. Push Scope Selection: Select Device Groups, Templates, or Template Stacks.
   • Merge with Device Candidate config: (Default: enabled).
   • Include Device and Network Templates: (Default: enabled).
   • Force Template Values is NOT supported for scheduled pushes.
4. Click OK , then Commit to Panorama .

Viewing Execution History:

Go to Panorama > Scheduled Config Push and click the timestamp in the Status column. Click Tasks for full details.

Scheduled pushes are useful for applying changes during maintenance windows without manual intervention.

Data Redistribution

Panorama can redistribute User-ID and other contextual data (IP-User Mappings, IP Tags, User Tags, HIP, Quarantine List) among managed firewalls and User-ID agents. This ensures consistent data for policy enforcement.

Configure Panorama to Redistribute Data:

1. Add Redistribution Agents to Panorama: ( Panorama > Data Redistribution > Add ). Specify Host, Port, Data types.
2. Enable Panorama MGT Interface for Queries: ( Panorama > Setup > Interfaces > Management , select User-ID).
3. Commit to Panorama .

Configure Firewalls to Receive Redistributed Data (via Template):

1. Device > Data Redistribution > Agents (select Template). Add agent (Panorama serial or Host/Port).
2. Commit and Push .

Verification:

• Agent status: Panorama > Data Redistribution > Agents > Status .
• Logs on firewalls: User-ID logs, IP-Tag logs.
• CLI: show user ip-user-mapping all .

Data redistribution ensures all firewalls in a device group have consistent User-ID mappings for policy enforcement.

Device Group Objects (Shared vs. DG)

Objects (Addresses, Services, URL Categories, Security Profiles, etc.) are configuration elements referenced by policies. In Panorama, objects can be created at the Shared level or within specific Device Groups .

• Shared Objects: Visible and usable by all device groups. Changes affect all. Cannot be overridden.
• Device Group Objects: Visible to that DG and its descendants. Can be overridden in descendants (unless "Disable Override" is checked).

Object Scope and Inheritance in Device Groups.

Managing Unused Shared Objects:

Default: Panorama pushes all shared objects. To push only referenced shared objects: Panorama > Setup > Management , edit Panorama Settings, clear Share Unused Address and Service Objects with Devices . This may increase Panorama commit time.

Use Shared objects for global items, DG-specific for granular control.

Object Management (Create, Override, Revert)

Creating Objects:

• Shared Object: Select Shared in DG drop-down during creation.
• Device Group Object: Select target Device Group during creation.

Overriding Inherited Object Values:

Applicable to DG objects inherited from an ancestor (not Shared objects).

1. In Objects , select the DG and the inherited object (green icon). Click Override .
2. Edit values. Icon becomes yellow-overlapping-green ( ). Commit and Push.

Reverting to Inherited Object Values:

1. Select the overridden object. Click Revert . Icon turns green. Commit and Push.

Managing Precedence of Inherited Objects:

Default: Lower-level DG objects take precedence. To reverse: Panorama > Setup > Management , edit Panorama Settings, check Objects defined in ancestors will take higher precedence . Commit to Panorama, then Push to Devices.

Object overrides offer flexibility. The "Find Overridden Objects" link (when changing precedence) is helpful.

Policy Rule Hierarchy & Evaluation

Panorama manages policies in layers. Understanding evaluation order is critical.

Rule Evaluation Order (e.g., Security Rulebase):

1. Panorama Pre-Rules (Shared -> Parent DGs -> Local DG)
2. Local Firewall Rules
3. Panorama Post-Rules (Local DG -> Parent DGs -> Shared)
4. Default Rules

Simplified Policy Rule Evaluation Order.

Use Policies > Preview Rules in Panorama to see the effective rulebase for a specific device.

"Preview Rules" is invaluable. Place specific rules before general ones.

Policy Targeting & Rule Usage

Pushing Policy Rules to a Subset of Firewalls (Targeting):

Within a device group, target specific policy rules to apply only to certain firewalls.

• In policy rule, Target tab: Select firewalls to apply OR select "Install on all but specified devices" to exclude.
• Select EITHER target tags OR target devices, not both.

Monitoring Policy Rule Usage:

Tracks rule usage for managed firewalls (PAN-OS 8.1+ with Policy Rule Hit Count enabled).

• View in Policies > [Rulebase] . Columns: Rule Usage (Used, Partially Used, Unused, —), Modified, Created.

• Click status for per-firewall hits.
• Policy Optimizer (Filter): Filter rules by usage, timeframe, etc. Take actions (Delete, Enable, Tag).

Regularly monitor rule usage. Enforce audit comments ( Panorama > Setup > Management ) for policy changes.

Managing Multi-VSYS Firewalls

Specific considerations for configuration pushes and shared objects on multi-VSYS firewalls.

Device Group Push to Multi-VSYS Firewall:

• Config changes for multiple VSYS on one physical firewall are bundled into a single job (PAN-OS 10.2+).
• If one part fails, the entire push to that multi-VSYS firewall fails.
• A full commit/push required after upgrading to PAN-OS 10.2 for optimized shared object pushes.

Shared Objects Pushed to Multi-VSYS Firewall:

Many shared objects go to a Panorama Shared location on the firewall, accessible by all VSYS.

• Exceptions (replicated per VSYS): Pre/Post Rules, EDLs, Security Profile Groups, HIP objects/profiles, Custom URLs, Decryption Profiles, SD-WAN Profiles.
• Override Precedence: VSYS-specific object in "Panorama" location overrides "Panorama Shared" object of same name.
• Best Practice: When changing shared objects for a multi-VSYS firewall, push to ALL associated DGs/VSYS.

Transitioning Firewalls: Planning

Migrating existing, locally configured firewalls to Panorama management requires careful planning.

Key Planning Steps:

1. Scope & Inventory: Identify firewalls, check PAN-OS versions, verify Panorama licenses.
2. Configuration Audit & Normalization: Plan DGs/Templates, normalize names (zones, objects).
3. Backup & Maintenance Window: Schedule window, backup firewall states and Panorama config.
4. Migration Strategy: Reuse existing config or push new? If from another Panorama, localize first.
5. Post-Migration Test Plan: Define verification tasks.

Thorough planning, especially normalization of names, is crucial.

Migrating Standalone Firewalls

Importing an existing firewall's configuration into Panorama to reuse it.

Process Overview:

1. Plan Migration.
2. Add Firewall as Managed Device in Panorama: Create Auth Key, add serial to Panorama.
3. Connect Firewall to Panorama: Configure Panorama IP and Auth Key on firewall. Verify connection.
4. Import Firewall Configuration into Panorama: ( Panorama > Setup > Operations > Import device configuration... ). Auto-creates Template/DG. Choose rule import location. Commit to Panorama.
5. Push Config Bundle from Panorama to Firewall (CRITICAL): ( Panorama > Setup > Operations > Export or push device config bundle... > Push & Commit ). Removes local policies/objects on firewall. Commit to Panorama again.
6. Push Device Group and Template Configurations: ( Commit > Commit and Push ). Check "Include Device and Network Templates" and "Force Template Values".
7. Verify & Fine-Tune.
8. Perform Post-Migration Test Plan.

The "push device config bundle" step is vital to clear local firewall config. "Force Template Values" makes Panorama's settings authoritative.

Migrating HA Pairs

Similar to standalone, with extra steps for HA state and sync.

Migrating HA Pair and Reusing Existing Configuration:

1. Plan. Disable Config Sync on HA Peers locally.
2. Add both HA firewalls to Panorama Management. Verify connection.
3. Import Configuration for EACH Firewall Separately:
   • For 1st peer: Import config. Then, Push device config bundle. Verify.
   • Repeat for 2nd peer. (Creates separate DGs/Templates).
4. Consolidate into Single DG and Template Stack: Move 2nd firewall into 1st's DG/Stack, delete redundant DG/Stack.
5. Push DG & Template Config to HA Pair (Phased):
   • Suspend passive/active-secondary peer locally.
   • From Panorama, Push to Devices (target suspended peer, Merge, Include Templates, Force Template Values if Panorama manages HA config).
   • Make peer functional. Suspend active/active-primary peer.
   • Repeat push from Panorama to now-suspended active peer. Make functional.
   • Verify sync.
6. (Local HA config only) Re-enable Config Sync .
7. Post-Migration Test Plan.

Migrating HA Pair and Pushing New Configuration:

Overwrites local configs. Plan, Disable Config Sync, Add FWs, Connect FWs. Create target DG/Stack in Panorama for both peers. Push config (phased). Verify. Re-enable local sync if needed. Test.

Disabling config sync and phased pushes (passive first) are key for HA migration.

Loading Partial Configurations

Selectively load specific settings (e.g., application objects) from a firewall into Panorama. Requires superuser, full commit on Panorama, typically uses XML API/CLI.

Process Overview:

1. Plan & Resolve Duplicates.
2. Export Full Firewall Configuration (as XML).
3. Import Snapshot into Panorama ( Panorama > Setup > Operations > Import named Panorama configuration snapshot ).
4. Load Partial Configuration (CLI/XML API):
   • Identify source XPath (from firewall XML) and destination XPath (in Panorama config).
   • Panorama CLI: load config partial mode [append|merge|replace] from-xpath <src> to-xpath <dest> from <file.xml> then commit .
5. Push Configuration from Panorama to Firewall. (Delete local conflicting objects first).
6. Post-Migration Test Plan.

Partial load is advanced. XPath knowledge is essential.

Localizing Panorama Configurations

Makes Panorama-pushed config local to firewall, removing it from Panorama management or preparing for migration to a different Panorama. Requires superuser on firewall GUI.

Steps:

1. Access Firewall Web Interface.
2. (Best Practice) Export Device State.
3. (Active/Passive HA Only) Disable Config Sync locally on each peer.
4. Disable Device and Network Template: ( Device > Setup > Management > Panorama Settings ). Optionally import settings locally.
5. Disable Device Group Configuration (Panorama Policy and Objects): (Same menu). Optionally import settings locally. Do NOT commit yet.
6. Save and Load Snapshot with New UUIDs (CRITICAL):
   • Device > Setup > Operations > Save named configuration snapshot .
   • Load named configuration snapshot (the one just saved).
   • Check: Regenerate Rule UUIDs for selected named configuration .
   • Click OK .
7. Commit on Firewall.
8. (Active/Passive HA Only) Re-enable Config Sync.

Regenerating Rule UUIDs is vital for localizing policies.

Changing Management Modes

Switching between Panorama and cloud services management.

Panorama to Cloud:

1. Panorama: Remove log forwarding preferences for the firewall ( Panorama > Collector Groups > Device Log Forwarding > Delete ). Commit.
2. Firewall: Set "Managed By" to Cloud Services ( Device > Setup > Management > Panorama Settings ). Commit.

Cloud to Panorama:

1. Firewall: Set "Managed By" to Panorama (re-enter IP/Auth Key if needed). Commit.
2. Firewall CLI: debug software restart process management-server .
3. Panorama: Verify connection ( Panorama > Managed Devices > Summary ).

Restarting management-server process on firewall is key when moving from cloud to Panorama.

Device Health Monitoring

Panorama (PAN-OS 8.1+) monitors health of managed firewalls (PAN-OS 8.1+).

Stores last 90 days of stats.

• Baseline Performance: Calculated using 7-day averages.
• Metrics: Sessions, environmentals, interfaces, logging, resources (CPU, memory, DP), HA, throughput.

Accessing Health Data:

1. Panorama > Managed Devices > Health .
2. All Devices View: Overview. Click metric for View Snapshot (Baseline, 24hr, 7-day, 15-day averages).
3. Detailed Device View: Select firewall for time-trended graphs.
4. Deviating Devices Tab: Firewalls with metrics outside baseline.

Helps identify performance or hardware issues. Data preserved for 90 days if firewall removed.

Device health status state diagram.

Device Certificate Installation (for Cloud Services)

Managed firewalls need a device certificate for Palo Alto Networks cloud services. Panorama facilitates this.

Prerequisites:

• Device management license (Panorama), Support license (firewall).
• Firewall outbound internet access (FQDNs/ports allowed).
• CSP account (Super User, etc.), Panorama superuser role.
• Firewall & Panorama in same CSP account. NTP configured (best practice).

PA-400, PA-1400, PA-3400, PA-5400, PA-5450 series install cert automatically on CSP registration.

Process:

1. (Best Practice) Configure NTP on Panorama and Firewalls.
2. Generate OTP Request Token on Panorama: ( Panorama > Managed Devices > Summary , select FW(s) or "Select all devices without a certificate", Copy token).
3. Generate OTP in CSP: ( Products > Device Certificates > Generate OTP , select "Generate OTP for Panorama managed firewalls", paste token, Generate OTP. View History, copy/download OTP. OTP lifetime: 60 mins. )
4. Install Device Certificate via Panorama: ( Panorama > Managed Devices > Summary > Upload OTP , paste OTP, Upload).
5. (WildFire Only) Refresh Firewall CLI: request wildfire registration channel public .
6. Verify: Panorama ( Managed Devices > Summary ) shows "Valid" certificate and expiry.

Device certs: 90-day lifetime, auto-renews 15 days prior.

Device Certificate Installation Workflow.

Ensure the following FQDNs and ports are allowed for successful certificate installation:

PCNSE Panorama Management Quiz

Test your knowledge on managing firewalls with Panorama. Select the best answer for each question.

1. What is the primary purpose of a Device Registration Authentication Key in Panorama?

To encrypt ongoing communication between Panorama and managed firewalls. For mutual authentication during the initial connection between a new firewall and Panorama. To license new firewalls being added to Panorama management. To push software updates from Panorama to the firewalls.

Correct Answer: B
The Device Registration Authentication Key is used for mutual authentication when a new firewall first connects to the Panorama management server. Subsequent communication uses certificates.

2. Which Panorama component is primarily used to manage network and device-specific settings like interfaces, zones, and services?

Device Groups Collector Groups Templates and Template Stacks Shared Objects

Correct Answer: C
Templates and Template Stacks are used to configure network settings (interfaces, zones, virtual routers) and device settings (server profiles, services) on managed firewalls. Device Groups manage policies and objects.

3. When configuring a Device Group hierarchy, how are policies and objects typically inherited?

Descendant (child) device groups inherit from their ancestor (parent) device groups and "Shared". Ancestor (parent) device groups inherit from their descendant (child) device groups. Only the "Shared" device group's policies and objects are inherited by all other device groups. Inheritance only occurs between sibling device groups.

Correct Answer: A
In a Device Group hierarchy, configurations from "Shared" and parent device groups are inherited by child device groups. Lower-level (more specific) configurations typically override higher-level ones by default.

4. A firewall is assigned to a Template Stack containing three Templates (T1, T2, T3) in that order from top to bottom (T1 highest priority). If T1 defines DNS as 1.1.1.1 and T3 defines DNS as 3.3.3.3, what DNS server will the firewall use if T2 does not define DNS?

3.3.3.3 The firewall's locally configured DNS. Panorama will prompt for a choice during push. 1.1.1.1

Correct Answer: D
In a Template Stack, templates higher in the list have higher priority. Settings from T1 will override settings from T2 and T3 if there are conflicts. Since T1 defines DNS as 1.1.1.1, this value will be used.

5. What is a primary benefit of using Template Variables in Panorama?

To enforce identical configurations across all managed firewalls without exceptions. To reuse a common base configuration (template/stack) while allowing specific values (e.g., IP addresses) to differ per firewall. To automatically create new Device Groups based on variable values. To manage policy rule hit counters dynamically.

Correct Answer: B
Template Variables allow administrators to use a single template or template stack for multiple firewalls, even if some settings like IP addresses or hostnames need to be unique for each firewall. The variable acts as a placeholder.

6. When migrating an existing, locally configured firewall to Panorama management and intending to reuse its configuration, what is a critical step after importing the firewall's configuration into Panorama but BEFORE pushing the full Device Group and Template configuration?

Immediately push the Device Group and Template configuration with "Force Template Values" selected. Manually delete all configurations on the local firewall. Perform an "Export or push device config bundle" from Panorama to the firewall to remove its local policies and objects. Localize the configuration on the firewall using the "Disable Device and Network Template" option.

Correct Answer: C
Pushing the device config bundle from Panorama to the newly added firewall is essential to clear its local policy rules and objects. This prevents conflicts and duplication when the full Device Group and Template configurations are subsequently pushed from Panorama.

7. An administrator wants to ensure that certain Panorama-managed firewalls in a Device Group do not receive a specific policy rule, while others in the same group do. What feature should be used?

Policy Rule Targeting Template Variables Creating a Sub-Device Group Overriding the rule on individual firewalls

Correct Answer: A
The Target tab within a policy rule configuration in Panorama allows administrators to specify which firewalls (or virtual systems) within a device group the rule should apply to, or which ones it should be excluded from.

8. What is the recommended best practice for master key management in a Panorama-managed environment with HA firewalls?

All firewalls and Panorama should share one default master key. Panorama synchronizes its unique master key to all managed firewalls, including HA peers. Each firewall in an HA pair should have a different unique master key for increased security. Configure unique master keys for Panorama and each managed firewall (or HA pair), ensuring both peers in an HA configuration have the identical key manually set.

Correct Answer: D
Best practice is to use unique master keys. For HA pairs (both Panorama and firewalls), the same master key must be manually configured on both peers as it's not synchronized. Log Collectors and WildFire appliances typically share Panorama's master key.

9. What is a key difference between Shared Objects and Device Group Objects in Panorama?

Device Group Objects can be overridden in parent Device Groups, but Shared Objects cannot. Shared Objects are accessible by all Device Groups, while Device Group Objects are accessible only by that Device Group and its descendants. Shared objects cannot be overridden. Shared Objects are only for network settings, and Device Group Objects are only for policy settings. Device Group Objects automatically synchronize their values with Shared Objects of the same name.

Correct Answer: B
Shared Objects have global scope and are inherited by all device groups; they cannot be overridden. Device Group Objects have a more limited scope (the DG they are in and its children) and can be overridden in descendant DGs (unless override is disabled on the object).

10. To ensure Panorama pushes only referenced shared objects to managed firewalls, what setting should be configured?

Enable "Force Template Values" in the Commit and Push dialog. Select "Objects defined in ancestors will take higher precedence" in Panorama Settings. Clear the "Share Unused Address and Service Objects with Devices" option in Panorama Setup > Management. Create all shared objects within a specific Device Group marked as "Global".

Correct Answer: C
Clearing the "Share Unused Address and Service Objects with Devices" option in Panorama's management settings will cause Panorama to only push shared objects that are actively referenced by rules in the device groups being pushed to. This can reduce commit times on firewalls but may increase commit times on Panorama.

11. When migrating a firewall HA pair to Panorama management and reusing their existing configuration, what must be done BEFORE importing configurations into Panorama?

Suspend the active firewall. Disable configuration synchronization on both HA peers locally. Assign both firewalls to the same target Device Group in Panorama. Force a failover to the passive firewall.

Correct Answer: B
Before importing configurations from an HA pair, configuration synchronization (Config Sync) must be disabled on each HA firewall locally. This prevents unintended syncs during the migration process.

12. What is the correct order of policy evaluation on a Panorama-managed firewall that includes Pre-Rules, Post-Rules, and Local Firewall Rules?

Local Rules, Panorama Pre-Rules, Panorama Post-Rules Panorama Post-Rules, Local Rules, Panorama Pre-Rules Panorama Pre-Rules, Panorama Post-Rules, Local Rules Panorama Pre-Rules, Local Rules, Panorama Post-Rules

Correct Answer: D
The general evaluation order is: Panorama Pre-Rules (Shared, then Parent DGs, then local DG), followed by Local Firewall Rules, then Panorama Post-Rules (local DG, then Parent DGs, then Shared), and finally default rules.

13. To view the effective, combined rulebase for a specific firewall as managed by Panorama, including all inherited rules, which feature should an administrator use?

Policies > Preview Rules Panorama > Config Audit Monitor > Logs > Configuration Device > Setup > Operations > View Configuration

Correct Answer: A
The "Preview Rules" feature in Panorama (under the Policies tab) allows an administrator to select a rulebase, device group, and a specific device to see the final, evaluated order of rules that will be applied to that firewall.

14. What is the maximum number of templates that can be included in a single Template Stack?

4 16 8 1024

Correct Answer: C
A Template Stack can contain a maximum of 8 templates. Panorama itself can support up to 1,024 template stacks and 1,024 templates.

15. If you want to completely remove a firewall from Panorama management and make its configuration local, what critical action must be taken on the firewall after disabling templates and policy/objects from Panorama?

Delete the Panorama server IP addresses from the firewall's management settings. Save a named configuration snapshot and then load that snapshot, ensuring "Regenerate Rule UUIDs" is checked. Perform a factory reset on the firewall. Restart the management-server process on the firewall CLI.

Correct Answer: B
To successfully localize a Panorama-pushed configuration, after disabling the template and device group settings on the firewall, you must save a named configuration snapshot and then load that same snapshot with the "Regenerate Rule UUIDs for selected named configuration" option checked. This is essential for policy rules to become truly local.

16. Which of the following settings can ONLY be configured locally on a managed firewall and NOT via Panorama templates?

Syslog server profiles Interface IP addresses Zone Protection Profiles Enabling multi-vsys mode

Correct Answer: D
Enabling operational modes such as normal mode, multi-vsys mode, or FIPS-CC mode can only be performed locally on each managed firewall. Other listed items can be managed by Panorama templates.

17. When Panorama is used to manage a multi-VSYS firewall (PAN-OS 10.2+), how are configuration pushes for different VSYS on the same physical device handled?

They are bundled into a single commit job on the managed firewall. Each VSYS configuration is pushed as a separate commit job. Only the primary VSYS configuration is pushed; others require local configuration. Panorama cannot manage multi-VSYS firewalls; they must be managed locally.

Correct Answer: A
For multi-VSYS firewalls (PAN-OS 10.2+), Panorama bundles configuration changes for all VSYS on that device into a single commit job, which helps reduce overall commit completion time on the firewall.

18. If an object named "Server-A" exists in the "Panorama Shared" location on a multi-VSYS firewall with IP 1.1.1.1, and another object also named "Server-A" exists in the "Panorama" location for VSYS1 with IP 2.2.2.2, which IP address will be used by a policy rule within VSYS1 referencing "Server-A"?

1.1.1.1 Panorama will generate a commit error due to duplicate object names. 2.2.2.2 The firewall will load balance between 1.1.1.1 and 2.2.2.2.

Correct Answer: C
If a configuration object with the same name is present in both the VSYS-specific Panorama location and the Panorama Shared location on a multi-VSYS firewall, preference is given to the object in the VSYS-specific Panorama location (2.2.2.2 in this case).

19. What Panorama feature allows an administrator to automatically push Device Group and Template configurations to a newly registered firewall when it first connects?

Scheduled Config Push Auto Push on 1st connect Data Redistribution Force Template Values

Correct Answer: B
The "Auto Push on 1st connect" option, available when associating a new device with a Device Group and Template Stack (for PAN-OS 8.1+ firewalls), allows Panorama to automatically push the configuration when the firewall first successfully connects.

20. When installing a device certificate on a managed firewall via Panorama for cloud services, what is the lifetime of the One Time Password (OTP) generated from the Customer Support Portal (CSP)?

15 minutes 24 hours 90 days 60 minutes

Correct Answer: D
The OTP generated from the CSP for device certificate installation has a lifetime of 60 minutes. If not used within this time, it expires, and a new OTP must be generated.

21. What is the primary role of the "Shared" location in the Panorama Device Group hierarchy?

To store firewall-specific local overrides. To manage network and device settings for all firewalls. To define global policies and objects that are inherited by all device groups. To act as a temporary holding area for newly imported firewall configurations.

Correct Answer: C
The "Shared" location is the highest level in the Device Group hierarchy. Policies and objects defined here are inherited by all device groups, making it suitable for global configurations.

22. If you clear the "Share Unused Address and Service Objects with Devices" option in Panorama settings, what is a potential consequence?

Commit times on Panorama might increase because Panorama has to dynamically check object references. Commit times on managed firewalls will always increase due to larger configuration files. All shared objects will be converted to device group-specific objects. Policy rule targeting will no longer function correctly.

Correct Answer: A
Disabling this option means Panorama pushes only referenced shared objects, which can reduce commit times on firewalls (smaller config). However, Panorama itself might experience longer commit times as it needs to check all policies for object references.

23. When would you typically use the "Force Template Values" option during a Commit and Push operation from Panorama?

When importing a new firewall's configuration for the first time. To ensure that Panorama's template settings overwrite any conflicting locally configured settings on the firewall. When scheduling a configuration push to avoid accidental overrides. When pushing only Device Group policies and not network/device templates.

Correct Answer: B
"Force Template Values" is used to make Panorama's template configuration authoritative, overwriting any local overrides or conflicting settings on the managed firewall for the items defined in the template. It's not supported for scheduled pushes.

24. What is the recommended procedure if a master key on Panorama or a managed firewall expires and you do NOT have the current master key?

Panorama will automatically generate a temporary master key. Contact Palo Alto Networks support to recover the master key. The device will continue to function normally but new encrypted configurations cannot be committed. The device may reboot into maintenance mode, and a factory reset might be required.

Correct Answer: D
If the master key expires and the current key is unknown, the firewall or Panorama may automatically reboot into Maintenance mode. The only way to restore the default master key is to reset the device to factory default settings. Master keys cannot be recovered.

25. In a Panorama-managed multi-VSYS firewall, which of the following object types is typically replicated to the Panorama location of each VSYS rather than being stored in the "Panorama Shared" location?

Address Objects Service Objects External Dynamic Lists (EDL) Application Groups

Correct Answer: C
External Dynamic Lists (EDLs), along with Pre/Post Rules, Security Profile Groups, HIP objects/profiles, Custom URL objects, Decryption Profiles, and SD-WAN Link Management Profiles, are replicated to the Panorama location of each VSYS rather than residing in the common Panorama Shared location.

26. Which PAN-OS version introduced the capability for Panorama to bundle Device Group configuration pushes for multiple VSYS on the same firewall into a single job?

PAN-OS 9.1 PAN-OS 10.2 PAN-OS 8.1 PAN-OS 11.0

Correct Answer: B
The functionality to bundle Device Group configuration changes for multi-VSYS firewalls into a single job on the managed firewall is supported for firewalls managed by Panorama running PAN-OS 10.2 and later releases.

27. If a Panorama administrator wants to change the order of precedence so that objects defined in ancestor device groups take higher precedence than locally defined objects in a child device group, where is this setting configured?

Panorama > Setup > Management > Panorama Settings Panorama > Device Groups > Edit Device Group > Advanced Panorama > Templates > Edit Template Stack > Advanced This precedence order cannot be changed.

Correct Answer: A
The setting "Objects defined in ancestors will take higher precedence" is found under Panorama > Setup > Management, by editing the Panorama Settings.

28. What is a key reason to use Reference Templates when configuring a Device Group in Panorama?

To ensure all firewalls in the Device Group use the same master key. To link multiple Device Groups together for policy inheritance. To automatically update PAN-OS versions on firewalls within the Device Group. To allow policy rules in the Device Group to reference network objects (e.g., zones, interfaces) defined in a template that its member firewalls might not be directly assigned to.

Correct Answer: D
Reference Templates allow a Device Group configuration (like policies) to reference objects (like zones or interfaces) that are defined in a specific template. This is useful if the firewalls in the Device Group get their network settings from different templates, or if the Device Group doesn't initially have firewalls assigned.

29. When changing management of a firewall from Cloud Services back to Panorama, what CLI command is required on the firewall after setting "Managed By" to Panorama in the GUI?

request restart system debug software restart device-server debug software restart process management-server request panorama-connect

Correct Answer: C
After configuring the firewall to be managed by Panorama again (from cloud management), you need to restart the management-server process on the firewall using the CLI command: `debug software restart process management-server`.

30. For Panorama to monitor device health statistics from managed firewalls, what is the minimum PAN-OS version required for both Panorama and the managed firewalls?

PAN-OS 7.1 PAN-OS 8.1 PAN-OS 9.0 PAN-OS 10.0

Correct Answer: B
Both Panorama and the managed firewalls must be running PAN-OS 8.1 or later releases for Panorama to collect and display device health monitoring data.

31. When using Panorama to install device certificates on managed firewalls, which entity generates the One-Time Password (OTP) after receiving an OTP Request Token from Panorama?

The Customer Support Portal (CSP) The Panorama management server itself The managed firewall A dedicated Log Collector

Correct Answer: A
The administrator takes the OTP Request Token generated by Panorama and submits it to the Customer Support Portal (CSP). The CSP then generates the OTP, which the administrator copies and uploads back to Panorama.

32. What is a primary limitation of bulk importing firewalls into Panorama using a CSV file?

It cannot associate firewalls with Template Stacks. It does not support assigning a Device Registration Authentication Key. It can only import a maximum of 10 firewalls at a time. It cannot be used to import firewalls with more than one virtual system (multi-vsys).

Correct Answer: D
You can only bulk import single-vsys firewalls to the Panorama management server using a CSV file. You cannot bulk import firewalls with multiple virtual systems (multi-vsys).

33. If a template configuration in Panorama references a shared object from a Device Group, what must be configured in the Device Group settings for this to work correctly?

The Device Group must be set as "Shared". The object must also be defined within the template. The Device Group must have the appropriate template or template stack added as a "Reference Template". The Device Group's parent must be the "Shared" group.

Correct Answer: C
If a device group configuration references objects configured in a template or template stack (or vice-versa, if a template references objects in a device group), you must assign the appropriate template or template stack as a "Reference Template" to the device group. This allows the device group to "see" objects from that template.

34. What is the "Rule Usage" status if some, but not all, firewalls in a Device Group have traffic matches for a specific policy rule pushed from Panorama?

Partially Used Used Unused Em-dash (—)

Correct Answer: A
"Partially Used" indicates that some of the firewalls in the device group—to which you pushed the policy rule—have traffic matches for the policy rule.

35. For Panorama to onboard a *new* firewall running PAN-OS 10.1.1, what minimum PAN-OS version must Panorama itself be running, according to the provided documentation context?

PAN-OS 10.1.1 Panorama cannot onboard a new firewall running PAN-OS 10.1.1 if Panorama is on 11.0.0 or later. PAN-OS 10.0 PAN-OS 11.0.0 or later, and it will work fine.

Correct Answer: B
The documentation states: "Panorama running PAN-OS 11.0.0 or later release supports onboarding firewalls running PAN-OS 10.1.3 or later release only. You cannot add a firewall running PAN-OS 10.1.2 or earlier PAN-OS 10.1 release to Panorama management if Panorama is running PAN-OS 11.0." Therefore, PAN-OS 10.1.1 cannot be onboarded by Panorama 11.0+.

36. What is the purpose of the "Master" firewall setting within a Device Group configuration?

It is the firewall from which Panorama pulls its own configuration updates. It is the primary firewall in an HA pair within that Device Group. It is the firewall in the Device Group from which Panorama gathers User-ID (username and user group) information for policy rules. It is the firewall that controls licensing for all other firewalls in the Device Group.

Correct Answer: C
If your policy rules will reference users and groups, you assign a Master firewall. This will be the only firewall in the device group from which Panorama gathers username and user group information (User-ID).

37. When migrating a firewall to Panorama and reusing its configuration, if an imported shared object from the firewall has the exact same name and value as an existing shared object in Panorama, what happens?

The import excludes that firewall object; Panorama's existing shared object is retained. The firewall's shared object overwrites Panorama's shared object. Panorama creates a duplicate shared object with a suffix. The import process fails and requires manual resolution.

Correct Answer: A
If a shared firewall object has the same name and value as an existing shared Panorama object, the import excludes that firewall object. Panorama assumes they are identical and no action is needed for that specific object.

38. Which of these actions is NOT typically performed using a Panorama Template or Template Stack?

Configuring interface IP addresses and zones. Defining DNS and NTP server settings for firewalls. Setting up a login banner for managed firewalls. Creating Security policy rules to allow or deny traffic.

Correct Answer: D
Security policy rules (along with NAT, Decryption, etc.) are managed using Device Groups. Templates and Template Stacks are for network and device settings.

39. To import and overwrite existing template stack variable values for multiple firewalls efficiently, what file format should be used?

XML CSV UTF-8 JSON Plain Text (.txt)

Correct Answer: B
Panorama allows exporting existing template stack variables to a CSV file. This CSV can then be edited and re-imported (saved in CSV UTF-8 format) to overwrite the values of multiple existing variables.

40. What is the "Force Template Values" option in Panorama generally NOT supported for?

Pushing configurations to a newly migrated firewall. Overwriting local firewall configuration changes with Panorama's template settings. Scheduled configuration pushes. Pushing template stack configurations to firewalls in an HA pair.

Correct Answer: C
The "Force Template Values" option is not supported for a scheduled configuration push. This is to prevent potential outages during off-hours caused by a configuration push that overwrites local firewall configurations without immediate admin oversight.

41. If an administrator overrides an inherited object value in a descendant Device Group, what icon typically indicates this overridden object in the Panorama GUI?

A green icon A yellow-overlapping-green icon A red icon A blue icon

Correct Answer: B
Inherited objects typically have a green icon. When an inherited object is overridden in a descendant device group, its icon changes to a yellow-overlapping-green symbol. The image provided in the document is .

42. When is it particularly important to ensure that zone names are normalized or consistent across firewalls before migrating them to Panorama management?

To allow Panorama to automatically create template variables for these zones. To ensure the firewalls can establish an initial connection with Panorama. To enable Panorama to manage the master keys for these zones. To successfully import and reuse existing policy rules that reference these zones in Panorama Device Groups.

Correct Answer: D
If policies in Panorama Device Groups are intended to apply to multiple firewalls and reference common zone names (e.g., "trust", "untrust"), those zone names must be consistent on the firewalls being managed. Normalizing zone names before or during migration facilitates the effective reuse of policies.

43. What happens if you attempt to add a firewall to Panorama management, and it exceeds the device management license limit?

The firewall is added, but Panorama operates in a degraded mode. Panorama automatically requests a temporary license extension from Palo Alto Networks. The operation is blocked, and Panorama prompts with a warning that adding the firewall failed. The oldest managed firewall is automatically removed to make space for the new one.

Correct Answer: C
If adding a firewall exceeds the device management license limit activated on Panorama, the operation is blocked, and the user is prompted with a warning indicating that adding the firewall to Panorama management failed.

44. Which of these Panorama features CANNOT be used to directly create or modify Security Policy rules?

Device Groups Templates Shared (as a Device Group location) Pre-Rules and Post-Rules within a Device Group

Correct Answer: B
Templates (and Template Stacks) are used for managing network and device settings. Security Policy rules, along with other policy types and objects, are managed within Device Groups (including Shared, Pre-Rules, and Post-Rules).

45. In a Panorama HA configuration, how is the Device Registration Authentication Key handled for onboarding new firewalls?

The key must be created and applied on both Panorama HA peers simultaneously. The key is only created on the secondary Panorama peer. The key is automatically synchronized from the primary to the secondary Panorama peer. The key is required only to add the firewall to the primary Panorama peer; the CA certificate for ongoing management is synchronized.

Correct Answer: D
If Panorama is in an HA configuration, the device registration authentication key is required only to add the firewall to the primary peer. Panorama in HA configuration synchronizes the Certificate Authority (CA) certificate that allows the secondary peer to manage firewalls in the event of an HA failover.

46. When viewing the "Rule Usage" column in Panorama for a policy, what does an "Em-dash (—)" indicate?

Policy Rule Hit Count is not enabled or available for Panorama to determine the rule usage for firewalls in the device group. The rule is a default rule and hit counts are not tracked. The rule has been recently modified and data is still being collected. The rule is currently disabled.

Correct Answer: A
An em-dash (—) in the Rule Usage column indicates that no firewalls in the device group (to which the policy rule was pushed) have Policy Rule Hit Count enabled or available for Panorama to determine the rule usage.

47. What is the recommended approach for managing the network configurations of firewalls in an active/active HA configuration using Panorama Templates?

Both peers must always be in the same Template Stack and share identical network configurations. Active/active HA configurations cannot be managed by Panorama Templates. Assign each firewall in the active/active HA pair to a separate Template or Template Stack if their network configurations need to be unique. Use only Template Variables to manage all network differences between active/active peers within a single Template Stack.

Correct Answer: C
For active/active HA, if each peer requires unique network configurations (e.g., different routing, unique floating IPs), it's recommended to assign each peer to a separate template or template stack. They are typically in the same Device Group for policy consistency.

48. When an administrator localizes a Panorama pushed configuration on a managed firewall, what specific action related to rule UUIDs is critical for the process to succeed?

Manually deleting all rule UUIDs from the firewall's configuration. Checking "Regenerate Rule UUIDs for selected named configuration" when loading the saved snapshot on the firewall. Exporting rule UUIDs from Panorama and importing them into the firewall. Ensuring all rule UUIDs match between Panorama and the firewall before localizing.

Correct Answer: B
During the localization process, after saving a named configuration snapshot on the firewall, it's critical to check the "Regenerate Rule UUIDs for selected named configuration" option when loading that snapshot. This allows the policies to become truly local.

49. Which Panorama setting determines if objects defined in ancestor device groups take precedence over objects with the same name defined in descendant device groups?

Device Group > Edit > Advanced Settings > Inherit Parent Objects Commit > Push to Devices > Force Object Precedence Objects > [Object Type] > Disable Override checkbox Panorama > Setup > Management > Edit Panorama Settings > "Objects defined in ancestors will take higher precedence"

Correct Answer: D
The order of precedence for inherited objects (whether ancestor or descendant takes priority for same-named objects) is controlled by the "Objects defined in ancestors will take higher precedence" checkbox within Panorama > Setup > Management > Panorama Settings.

50. If a Panorama-managed firewall's Device Health Monitoring shows a metric consistently in the "Deviating Devices" tab, what does this typically indicate?

The metric is outside its calculated normal operating range (baseline). The firewall has lost its connection to Panorama. The firewall's PAN-OS version is incompatible with Panorama. The firewall's device certificate has expired.

Correct Answer: A
When Panorama identifies that a health metric for a managed firewall is outside the normal operating range (its calculated baseline), it marks the metric and populates the Deviating Devices tab with that firewall.

Submit Quiz