B. template stacks
D. variables

Explanation:
To efficiently deploy and manage 15 GlobalProtect gateways using Panorama, the administrator should leverage:

✅ B. Template stacks
Template stacks allow you to combine multiple templates into a layered configuration.
You can define common settings (e.g., interfaces, service routes, DNS, logging) once and apply them across all firewalls.
Each firewall is assigned to a single template stack, which pushes all relevant configuration in one commit.
This dramatically reduces duplication and simplifies management.
📌 Reference:
Palo Alto Networks TechDocs – Template Stacks

✅ D. Variables
Variables allow you to customize specific values (e.g., IP addresses, hostnames, DNS servers) per firewall without creating separate templates.
You define a variable (e.g., $GW_IP) in the template and assign a unique value for each firewall.
This enables scalable, reusable templates while preserving per-device uniqueness.
📌 Reference:
Palo Alto Networks TechDocs – Configure Template Variables

❌ Why Other Options Are Incorrect:
A. Collector groups Used for log collection in distributed log collector deployments. They do not configure firewalls.
C. Virtual systems Allow multiple logical firewalls on a single physical device. Not relevant for deploying multiple physical gateways.

A. Enable NAT Traversal on Site B firewall
D. Match IKE version on both firewalls.

Explanation:
When configuring a VPN tunnel with a dynamic peer, specific settings must be matched on both sides of the connection to ensure successful negotiation.

A. Enable NAT Traversal on Site B firewall: NAT traversal (NAT-T) is essential when one or both endpoints have a dynamic public IP address and might be behind a NAT device. The Site A firewall uses a DHCP-assigned address, which means its address can change. If the Site B firewall is behind a NAT device or if the connection passes through one, enabling NAT-T ensures that the VPN packets can correctly traverse the NAT boundary. Without this, the connection will likely fail.
D. Match IKE version on both firewalls: The IKE Gateway configuration for Site A shows IKEv1 only mode. For a successful tunnel, the remote peer (Site B) must also be configured to use IKEv1. If Site B is set to IKEv2 or a different mode, the IKE negotiation will fail. Matching the IKE version is a fundamental requirement for any IPSec tunnel setup.

Why the Other Options Are Incorrect
B. Configure Local Identification on Site A firewall:
The provided image of the Site A configuration already shows that the Local Identification is configured as FQDN (email address) with the value user@acme.com. No change is needed for this setting.
C. Disable passive mode on Site A firewall:
The "Passive Mode" option on the Site A configuration is currently disabled (unchecked). Passive mode would cause the firewall to only listen for incoming connections and not initiate the connection itself. Since Site A has a dynamic IP address, it must be the initiator of the tunnel, so disabling passive mode is the correct setting. Therefore, this option does not require a change.

B. External

Explanation:
To enable communication between different virtual systems (vsys) on the same Palo Alto Networks firewall, you must configure an External zone. This zone type is specifically designed to facilitate inter-vsys traffic that remains within the firewall, allowing virtual systems to exchange packets without routing them externally.

When setting up inter-vsys communication:
You create an External zone in each virtual system.
In the zone configuration, you specify which other virtual systems it can reach.
Then, you define Security policy rules to allow or restrict traffic between these zones.
This setup is documented in Palo Alto’s official guide on Configuring Inter-Virtual System Communication.

❌ Why the other options are incorrect
A. Tap:
Used for passive monitoring only. It cannot forward traffic or enable communication between virtual systems.
C. Virtual Wire:
Transparent Layer 1 forwarding between interfaces. It’s not designed for inter-vsys traffic.
D. Tunnel:
Used for VPN connectivity, not for internal vsys-to-vsys communication.
Let me know if you want help designing inter-vsys policies or validating zone visibility across templates.

B. Values in efw01lab.chi

Explanation:
In a template stack, configuration values are applied based on hierarchical precedence—the topmost template overrides those below it. In the image, the order from top to bottom is:
efw01lab.chi
Datacenter
Chicago
Global Settings
Since each template defines an SSL/TLS Service profile named "Management", the firewall will use the version from the highest-priority template—which is efw01lab.chi.

This ensures that:
The Management profile from efw01lab.chi is applied
Lower templates (Datacenter, Chicago, Global Settings) are ignored for this setting

Reference:
Palo Alto Networks TechDocs – Template Stack Precedence

A. Route 2

Explanation:

1: List the configured routes
From the screenshot, I can summarize the important parts:
Route 1
Destination: 10.10.0.0/24
Next-hop: 192.168.1.2
Metric: 30
Route 2
Destination: 10.10.0.0/24
Next-hop: 192.168.1.2
Metric: 20
Route 3
Destination: 0.0.0.0/0 (default route)
Next-hop: 10.10.20.1
Metric: 5
Route 4
Destination: 10.10.1.0/25
Next-hop: 192.168.1.2
Metric: 10

2: Match destination 10.10.0.4
IP 10.10.0.4 falls into 10.10.0.0/24.
It does not fall into 10.10.1.0/25.
So only Route 1 and Route 2 are candidates.
Route 3 (default) would only apply if no more specific route existed.
Route 4 is irrelevant (different subnet).

3: Apply route selection rules
Rule: The firewall chooses the longest prefix match (most specific route).
Both Route 1 and Route 2 have the same prefix length (/24).
Next tie-breaker: metric. The lower metric wins.
Route 1 = metric 30, Route 2 = metric 20.
✅ So Route 2 wins.

C. Enable the "Hold Mode" option in Objects > Security Profiles > Antivirus

Explanation:
Enabling real-time WildFire signature lookup allows Palo Alto Networks firewalls to query the WildFire cloud for the latest verdicts on unknown files before allowing them through. However, this lookup happens in parallel with traffic flow—meaning the file may be delivered before the verdict is returned, potentially allowing malware through.
To further reduce the likelihood of newly discovered malware being allowed:

✅ Enable "Hold Mode" in Antivirus Profiles
This feature pauses file delivery until the WildFire cloud returns a verdict.
If the verdict is malicious, the firewall can block the file before it reaches the user.
This prevents patient zero scenarios where malware is delivered before detection.
You can configure this under:
Objects > Security Profiles > Antivirus

And globally under:
Device > Setup > Content-ID > Real-Time Signature Lookup > Enable Hold Mode

❌ Why Other Options Are Incorrect:
A. Increase the frequency of applications and threats dynamic updates This helps with known threats, but not zero-day malware. Real-time lookup is already faster.
B. Increase the frequency of antivirus dynamic updates Antivirus updates are periodic and reactive. They don’t help with real-time detection.
D. Enable "Report Grayware Files" This improves visibility but doesn’t block malware. It’s a reporting feature, not a prevention mechanism.

🔗 Authoritative Reference:
Palo Alto Networks TechDocs: Hold Mode for WildFire Real-Time Signature Lookup

B. Multiple vsys and firewalls can be assigned to a device group, and a multi-vsys firewall can have each vsys in a different device group.

Explanation:

Key Concept: Device Groups in Panorama
Device Groups in Panorama are used to manage policies and objects (security rules, NAT, address objects, etc.) across multiple firewalls.
In multi-vsys (virtual system) firewalls, each vsys is treated like a separate firewall from a Panorama perspective.
That means Panorama can assign different vsys to different device groups.

❌ Eliminating Wrong Answers
A. Only one vsys or one firewall can be assigned to a device group, and a multi-vsys firewall can have each vsys in a different device group.
→ Wrong. A device group can manage multiple firewalls and multiple vsys, not just one.
C. Only one vsys or one firewall can be assigned to a device group, except for a multi-vsys firewall, which must have all its vsys in a single device group.
→ Wrong. Multi-vsys firewalls do not require all vsys to be in the same device group.
D. Multiple vsys and firewalls can be assigned to a device group, and a multi-vsys firewall must have all its vsys in a single device group.
→ Wrong. "Must" is the trap. PAN-OS allows flexibility — each vsys can go to a different device group.

✅ Correct Answer
B. Multiple vsys and firewalls can be assigned to a device group, and a multi-vsys firewall can have each vsys in a different device group.

📖 Reference (Official Docs)
Palo Alto Networks TechDocs – Panorama Admin Guide: Device Groups