Revision Guide · Certified Next-Generation Firewall (NGFW) Engineer

Management & Ops

← Back to full guide index

~10 min read
Prerequisites: Resilience & Scale — Panorama/logging typically manages fleets of the HA pairs and clusters covered there.

Panorama (Centralized Management) 50

Learning objectives

  • Explain why centralized management is necessary once a fleet grows beyond a handful of firewalls
  • Distinguish shared/device-group/template configuration from local overrides
  • Identify which advanced features require Panorama as the provisioning point

Palo Alto's centralized management platform for configuring, monitoring, and updating fleets of NGFWs (and, per HA docs, the only way to get a consolidated cross-pair log/ACC view).

Why

Managing dozens or thousands of individual firewall web UIs doesn't scale; policy consistency, software/content updates, and fleet-wide visibility all need a single control point.

How

Panorama pushes shared and device-group-specific configuration and dynamic content/software updates to managed firewalls, aggregates logs centrally, and is the recommended (and sometimes required, e.g. HA-cluster provisioning, NGFW Clustering, SD-WAN) provisioning point for advanced multi-firewall features. Firewalls can be onboarded to Panorama or to Strata Cloud Manager for cloud-based management instead.
Panorama centrally pushes policy and updates while aggregating logs from managed NGFWs.
Panorama centrally pushes policy and updates while aggregating logs from managed NGFWs.

Pros

  • Single point for policy, licensing, and content/software update rollout across the whole fleet
  • Required (or strongly recommended) for advanced features: HA-cluster provisioning, NGFW Clustering, SD-WAN, consolidated HA logging/ACC
  • Device groups and templates let you reuse shared policy while allowing local overrides

Cons

  • Becomes a second thing to size, patch, and keep highly available — itself a potential single point of failure
  • Adds a layer of indirection (templates/device-groups/overrides) that has its own learning curve
  • Version compatibility between Panorama and managed firewalls/plugins must be tracked for every feature (e.g. specific Panorama + Clustering Plugin versions for NGFW Clustering)

Exam trap

Panorama being "recommended" for basic multi-firewall policy management is an understatement for several features — HA-cluster provisioning, NGFW Clustering, and SD-WAN specifically require it. Don't assume any centralized feature is optional just because Panorama itself is a separate product.
Self-check

Q1. You're deploying NGFW Clustering across a site. Do you need Panorama, and why?

A: Yes — NGFW Clustering is one of the advanced multi-firewall features that requires Panorama as the provisioning point, alongside a matching Clustering Plugin version.

Q2. A device group has a shared rule from Panorama and a local override on one firewall. Which one wins on that firewall?

A: The local override — device groups/templates let you reuse shared policy while still allowing per-firewall overrides where configured.

Cross-referenced from: ngfw/administration/high-availability, ngfw/administration/ngfw-clustering, pan-os/11-1/pan-os-admin/subscriptions (Strata Cloud Manager entry)

Monitoring & Logging 51

Support license required

Learning objectives

  • Name the five main monitoring tools and what each is best used for
  • Explain how ACC and ACE differ from raw log review
  • Identify platform-specific monitoring caveats (e.g. PA-410)

Visibility tooling built on top of the firewall's logs: Dashboard, Application Command Center (ACC), Reports, the Automated Correlation Engine (ACE), and packet captures.

Why

Prevention isn't perfect — teams need fast visibility into traffic, threats, and system health to detect what got through and respond quickly.

How

The Dashboard gives at-a-glance status (version, interfaces, resource use). ACC provides interactive, filterable graphical summaries of log data, including a "Compromised Hosts" widget that correlates events to surface likely-infected systems. Reports (App Scope, Botnet, SaaS usage, User Activity, custom) track longer-term trends and can be scheduled for email delivery. ACE analyzes logs for suspicious patterns automatically. Packet captures support deep troubleshooting. Traffic, Threat, and URL Filtering logs (among others) can be filtered, exported, or forwarded externally.
Traffic, threat, and URL logs feed dashboards, ACC, reports, and ACE for incident response.
Traffic, threat, and URL logs feed dashboards, ACC, reports, and ACE for incident response.

Pros

  • ACC correlates disparate log types into one investigative view instead of grepping raw logs
  • ACE automates pattern detection across logs rather than relying purely on manual review
  • Scheduled reports keep stakeholders informed without manual effort

Cons

  • Meaningful long-term analysis needs adequate log storage sizing or external forwarding — easy to under-provision
  • PA-410 specifically requires Panorama management just to get monitoring functionality
  • Deep-dive investigation still requires an analyst who knows how to use ACC filters/pcaps effectively

Exam trap

ACC and Reports summarize logged traffic — if a rule doesn't log (like the default intrazone/interzone-default rules), that traffic won't appear in either, even though it happened. "Not showing in ACC" is not proof traffic didn't occur.
Self-check

Q1. Which tool would you use to see whether a specific host has an active session right now, independent of what's been logged?

A: The live Session Browser — it reflects the session table directly rather than depending on logging configuration.

Q2. A PA-410 admin says monitoring seems unavailable locally. What's the likely explanation?

A: The PA-410 specifically requires Panorama management to get monitoring functionality — it's a documented platform-specific constraint, not a misconfiguration.

Source: ngfw/administration/monitoring

Log Forwarding 52

PAN-OS course · Log Forwarding

Learning objectives

  • Explain why logs are forwarded off-box rather than viewed only locally
  • Trace the Log Forwarding profile → match-list → server-profile chain
  • Identify the 4,096-byte truncation and unsupported-field crash risk

Any single firewall can only show logs for the traffic it saw — forwarding centralizes that visibility to Panorama or external tools instead of requiring an admin to log into every box individually.

Why

Multi-firewall environments make per-box log review impractical, and different teams often only care about a subset of logs (a SOC analyst wants WildFire-flagged Threat logs, not every Traffic log). Centralizing and filtering solves both problems at once.

How

A Log Forwarding profile (Objects > Log Forwarding) contains one or more match-list profiles — each scoped to one log type (Traffic, Threat, WildFire Submission, URL Filtering, Data Filtering, Tunnel, Authentication), with an optional filter and one or more destinations: Panorama/Log Collectors, or external server profiles (SNMP trap, Email, Syslog, HTTP/S — each configured separately with its own certificate/authentication needs). The profile is then attached to Security, Authentication, or DoS Protection rules (and to zones, for System/Correlation/GlobalProtect/HIP Match/User-ID logs via Device > Log Settings) so matching traffic actually triggers forwarding — Threat and WildFire Submission logs require the rule to also carry the relevant security profile. By default logs forward over the management interface unless a dedicated log interface or service route is configured (required on some high-throughput platforms like the PA-7000/PA-7500/PA-5450 series). A Log Forwarding profile can also carry a built-in Quarantine action, tying log forwarding directly into GlobalProtect device quarantine.
A Log Forwarding profile fans out matched logs from an NGFW to Panorama, Strata Logging Service, and external server profiles.
A Log Forwarding profile fans out matched logs from an NGFW to Panorama, Strata Logging Service, and external server profiles.

Pros

  • Per-log-type filtering means teams only receive the logs relevant to their job
  • Multiple destination types (Panorama, SNMP, Email, Syslog, HTTP/S) fit almost any existing SIEM/monitoring stack
  • Built-in Quarantine action wires log forwarding directly into automated response

Cons

  • Forwarded log records are truncated at 4,096 bytes — large log entries silently lose data past that limit
  • Forwarding logs with unsupported fields/pseudo-fields can crash the firewall — a sharp, non-obvious failure mode
  • HTTP/S forwarding is explicitly not recommended for high-volume deployments — log loss is a real risk at scale
  • High-throughput hardware (PA-7000/7500/5450) needs dedicated log interfaces/cards — this isn't just a software toggle on those platforms

Exam trap

Attaching a Log Forwarding profile to a Security rule is not enough on its own for Threat or WildFire Submission logs — the rule must also carry the relevant security profile (e.g. a Vulnerability Protection or WildFire Analysis profile), or there's nothing for that match-list to forward.
Self-check

Q1. A large log entry appears truncated in your SIEM after forwarding. What's the most likely cause?

A: The 4,096-byte truncation limit on forwarded log records — entries larger than that silently lose data past the limit.

Q2. Why might HTTP/S be a poor choice as the sole forwarding destination for a high-volume PA-7500 deployment?

A: HTTP/S forwarding is explicitly not recommended at high volume — log loss risk increases, and high-throughput platforms like the PA-7000/7500/5450 series need dedicated log interfaces/cards rather than relying on a software-only path.

Source: ngfw/administration/monitoring/configure-log-forwarding

Strata Logging Service 53

PAN-OS course · Strata Logging Service FeaturesCloud-delivered

Learning objectives

  • Explain what Strata Logging Service replaces and why
  • Identify which other services depend on it

Strata Logging Service is Palo Alto's cloud-based, multi-tenant log storage and analytics back end — the destination that lets you retire on-box/on-prem log storage capacity planning entirely and get essentially unlimited, centrally-searchable retention instead.

Why

On-box log storage is finite and platform-dependent (smaller appliances fill up fast under heavy logging), and building out on-prem Log Collector infrastructure to scale storage is its own project. A cloud-native, elastically-scaled log store removes that capacity-planning burden and gives every managed firewall the same retention/search experience regardless of its own hardware.

How

Firewalls (and CN-Series, per CN-Series Architecture) forward logs to Strata Logging Service the same way they'd forward to Panorama or any other log-forwarding destination, once licensed. It underpins several other cloud-delivered features covered elsewhere in this guide: Device Telemetry uploads feed it, Panorama and Strata Cloud Manager query it for centralized reporting instead of aggregating from individual Log Collectors, and it's the log store behind Cloud NGFW deployments. Buying a Strata Logging Service license automatically extends it to every firewall registered under that support account.
NGFWs and Panorama upload logs to the cloud-based Strata Logging Service, which powers Panorama reporting, ADEM, and downstream detection apps.
NGFWs and Panorama upload logs to the cloud-based Strata Logging Service, which powers Panorama reporting, ADEM, and downstream detection apps.

Pros

  • Removes on-box/on-prem log storage capacity planning entirely
  • One license covers every firewall on the support account, including CN-Series
  • Underpins several other cloud-delivered management/telemetry features rather than being a standalone silo

Cons

  • Introduces a cloud dependency for something as core as log retention/search
  • Separate licensing line item on top of core NGFW/Panorama costs
  • Same 4,096-byte-record and unsupported-field constraints as any other forwarding destination still apply

Exam trap

Strata Logging Service doesn't remove the log-forwarding constraints you already learned — the same 4,096-byte record truncation and unsupported-field crash risk still apply, because it's reached via the same forwarding mechanism as any other destination.
Self-check

Q1. Why does buying one Strata Logging Service license cover every firewall on the support account, including CN-Series?

A: It's a cloud-delivered, multi-tenant service tied to the support account rather than to individual hardware — licensing extends automatically to every firewall registered under that account.

Q2. Which two other features/services covered in this guide depend on Strata Logging Service as their back end?

A: Device Telemetry (uploads feed it) and Panorama/Strata Cloud Manager (query it for centralized reporting) — it's also the log store behind Cloud NGFW.

Curriculum: PAN-OS course, "Strata Logging Service Features" lesson; cross-referenced against ngfw/administration/monitoring/configure-log-forwarding and the CN-Series "What's New" changelog (Strata Logging Service support for CN-Series).

Reading Traffic Logs — Deep Dive 54

Reading Traffic Logs course (standalone, 5-lesson)

Learning objectives

  • Identify the scope of information available within a single Traffic log entry
  • Match column display on Monitor > Logs > Traffic to your troubleshooting needs
  • Use filters to find and display the logs you need
  • Distinguish potentially misleading information from legitimate diagnostic indicators

Traffic logs are really session logs — most troubleshooting questions ("did this get allowed," "why did this connection end," "is this even reaching the firewall") can be answered by knowing how to read them correctly, before ever reaching for a packet capture.

Why

A "level-appropriate methods" approach — start with the highest-level tool that answers the question — saves enormous troubleshooting time. If a Traffic log entry already contains the answer, running a packet capture or standing up a custom diagnostic rule is wasted effort and a wasted change-window.

How

Each entry is a data dump from the session-setup process (a calculated allow/deny outcome per Security Policy) plus later session-table updates from application shifts or policy rematches. Log type ("drop", "start", "end") indicates only when the log was generated, not content-inspection results — a "drop" log means the session-setup process denied the session before a session table entry was even created (always Session ID 0), while an "end" log is generated once per session regardless of whether it was clean, blocked mid-session by a security profile, or denied by policy. Similarly, the Action column (allow/deny/drop/reset-client/ reset-server/reset-both) reflects the Security Policy verdict only — "allow" traffic can still be blocked afterward by a Threat/URL Filtering profile, so "allow" alone doesn't mean "clean." Session End Reason shows only the single highest-priority cause when termination had multiple causes, and must be read alongside other fields — e.g. "aged-out" is simply expected/normal for UDP and ICMP, not necessarily a problem. Logs are generated per Security Policy rule's own logging configuration — the built-in intrazone-default and interzone-default rules don't log by default, so "no logs" does not mean "no traffic"; the live, filterable Session Browser shows active sessions regardless of logging configuration and is the better tool for "is this actually happening right now." With 100+ available columns on PAN-OS 10.1+, the default column set is intentionally generic — customize the displayed columns to your actual troubleshooting need rather than assuming the defaults show everything relevant, and build filters from clicking individual field values (e.g. a timestamp) rather than hand-typing filter syntax.
Key fields of a single Traffic log entry and the three most commonly misread signals: allow action, aged-out reason, and missing logs.
Key fields of a single Traffic log entry and the three most commonly misread signals: allow action, aged-out reason, and missing logs.

Pros

  • Traffic logs alone resolve most connectivity/rule-matching questions without a packet capture
  • Session Browser gives live visibility independent of whatever logging is configured on the matched rule
  • Column customization and click-to-filter make large log volumes practically searchable

Cons

  • "Allow" action and "no logs" are two of the most commonly misread signals — both require the analyst to know what they don't mean
  • Default intrazone/interzone-default rules not logging by default is a common blind spot until explicitly overridden
  • 100+ possible columns means the useful ones have to be deliberately configured — the out-of-the-box view isn't tuned for any specific investigation

Exam trap

"Allow" in the Action column and "no logs at all" are the two most commonly misread signals — "allow" only reflects the Security Policy verdict (a Threat/URL Filtering profile can still block after that), and "no logs" can simply mean the matching rule (often intrazone/interzone-default) isn't configured to log, not that no traffic occurred.
Self-check

Q1. A Traffic log entry shows Session ID 0 and Log Type "drop." What does that tell you about when the session table was involved?

A: It wasn't — a "drop" log means Security Policy denied the session during setup, before any session table entry was created, which is why it's always Session ID 0.

Q2. Session End Reason shows "aged-out" for a UDP session. Is that a red flag?

A: No — "aged-out" is expected/normal behavior for UDP and ICMP sessions and shouldn't be treated as an anomaly on its own.

Source: G:\NGFW\001-Reading Traffic Logs.md (standalone course export, 5 lessons: Traffic Logs Key Concepts, Troubleshooting Methodology, Searching and Displaying Logs, Detailed Log View, Correction to Common False Assumptions).

Device Telemetry 55

Learning objectives

  • Identify the broad categories of data Device Telemetry collects
  • Explain how telemetry uploads feed Palo Alto's threat-intelligence and ML detection models
  • Know what administrator controls exist over collection and inspection of telemetry data

Collects operational data about the firewall/Panorama and uploads it to Strata Logging Service to power telemetry-driven apps and Palo Alto's threat-intelligence sharing.

Why

Both the customer (proactive monitoring/AIOps) and Palo Alto (aggregate threat intelligence) benefit from continuous device health and usage data rather than point-in-time snapshots. Detection models — including WildFire and Advanced Threat Prevention's cloud-based ML classifiers — are only as good as the population of data they're trained and tuned against, so telemetry from the installed base is part of what keeps those services effective against new threats rather than static after release.

How

Data is collected on defined intervals and transmitted to Strata Logging Service, grouped into categories such as product usage (feature adoption, resource utilization), device health (system/hardware status, crash and error data), and threat/application data (App-ID and Threat Prevention statistics) — not full packet or session-content capture. Administrators can manage what's collected at a per-category level, monitor the telemetry pipeline itself for delivery status, and inspect samples of the actual data being sent before/while it's transmitted, which is the main lever for reconciling telemetry participation against internal data-governance requirements.
Interval-based telemetry flows from NGFW or Panorama to Strata Logging Service and downstream apps.
Interval-based telemetry flows from NGFW or Panorama to Strata Logging Service and downstream apps.

Pros

  • Feeds AIOps-style proactive health/anomaly monitoring apps
  • Contributes to community-wide threat intelligence
  • Collection/transmission intervals and content are administrator-configurable and inspectable

Cons

  • Requires a Strata Cloud Manager license tier (Essentials or Pro) to fully use
  • Data-sharing-to-vendor nature may require review against internal data-governance/compliance policy

Exam trap

Device Telemetry uploads operational/health/usage data to Strata Logging Service — it is not full packet or session-content capture, and it's a distinct data flow from the Log Forwarding profiles covered earlier in this module.
Self-check

Q1. Your org's data-governance policy requires reviewing exactly what's sent to a vendor before enabling a feature. What lets you do that for Device Telemetry?

A: Administrators can inspect samples of the actual telemetry data being sent, and manage collection at a per-category level, before/while deciding to enable it.

Q2. Why does Palo Alto benefit from telemetry beyond just the customer's own AIOps monitoring?

A: Aggregate telemetry from the installed base feeds Palo Alto's threat-intelligence sharing and helps keep cloud-based ML detection (WildFire, Advanced Threat Prevention) tuned against current threats.

Source: pan-os/11-1/pan-os-admin/device-telemetry

Platform Security — Integrity Measurement Architecture 56

PAN-OS 12.1+

Learning objectives

  • Explain what IMA protects against that network-layer inspection cannot
  • Describe the two configurable violation responses and when each is appropriate

Built-in protections that harden PAN-OS itself against tampering — not traffic inspection, but defense of the firewall's own runtime integrity.

Why

A firewall is a high-value target; if the platform's own binaries can be modified or malware executed on the appliance itself, every downstream security control is compromised.

How

IMA (Integrity Measurement Architecture) runs in enforcement mode by default, allowing execution only of binaries cryptographically signed by Palo Alto Networks — extending secure boot into the running system. Violations log as critical system events; PAN-OS can either keep running and log (default) or reboot to maintenance mode to disrupt an active attacker. Software integrity checks run at boot and daily, on an admin-configurable schedule.
Secure boot and IMA enforce signed binaries and define violation responses.
Secure boot and IMA enforce signed binaries and define violation responses.

Pros

  • Blocks execution of unsigned/tampered code at the platform level, not just network level
  • Enforcement is on by default — no extra configuration needed to get baseline protection
  • Configurable response (log-only vs. reboot-to-maintenance) fits different operational risk tolerances

Cons

  • Only available on PAN-OS 12.1 and later — not a benefit on older deployed code
  • Reboot-to-maintenance response, if misapplied, could itself be leveraged for a disruption/DoS scenario against the firewall

Exam trap

IMA's default enforcement response is log-only, not reboot — don't assume a violation automatically disrupts the firewall; the reboot-to-maintenance response has to be deliberately configured for environments that prioritize stopping an active attacker over uptime.
Self-check

Q1. An unsigned binary attempts to execute on a PAN-OS 12.1 firewall with IMA enforcement on. What happens?

A: Execution is blocked — IMA only allows binaries cryptographically signed by Palo Alto Networks to run, and the violation is logged as a critical system event.

Q2. Is IMA a network-traffic control?

A: No — it hardens the PAN-OS platform's own runtime integrity (what code can execute on the box), which is a different layer from traffic inspection.

Source: ngfw/administration/security-settings

Module Quiz

1. A team is planning a large firewall fleet and wants to know which capability specifically requires Panorama as the provisioning point, rather than merely benefiting from it. Which one is it?

HA-cluster provisioning, NGFW Clustering, and SD-WAN specifically require Panorama; most other monitoring features don't.

2. A SOC lead wants a tool that surfaces suspicious patterns across logs automatically, instead of requiring an analyst to build and run manual filters. Which tool fits?

ACE analyzes logs for suspicious patterns automatically and surfaces correlation objects; ACC is interactive/filterable but analyst-driven.

3. An engineer attaches a Log Forwarding profile to a Security rule but still doesn't see WildFire Submission logs arriving at the SIEM. What is the most likely cause?

Threat and WildFire Submission logs are only generated when the matching rule also carries the relevant security profile — attaching a Log Forwarding profile alone doesn't generate them.

4. A single forwarded log record exceeds 4,096 bytes. What happens to the excess data?

Forwarded log records are truncated at 4,096 bytes with no automatic splitting or retry — a common reason a SIEM shows incomplete log fields.

5. A high-throughput data-center deployment needs dedicated hardware log interfaces rather than sending logs out the management interface. Which platform family specifically requires this?

These high-throughput chassis platforms require dedicated log interfaces/cards — it isn't just a software toggle the way it is on smaller platforms.

6. A customer is trying to avoid sizing and forecasting on-prem Log Collector storage as their fleet grows. Which capability removes that specific capacity-planning problem?

Strata Logging Service is a cloud-native, elastically-scaled log store, removing the need to plan on-box or on-prem Log Collector storage capacity.

7. A Kubernetes-heavy environment wants a single, unified log destination that both its CN-Series firewalls and its PA-Series hardware can forward to once licensed. Which two firewall types can forward logs to Strata Logging Service? (Choose two.)

CN-Series and PA-Series firewalls both forward logs to Strata Logging Service the same way as any other managed firewall, once licensed and onboarded.

8. While troubleshooting, an engineer finds a Traffic log entry with Log Type "drop" and Session ID 0. What does this combination indicate?

A "drop" log with Session ID 0 always means denial happened during session setup, before any session table entry was created — distinct from a "deny" after a session is established.

9. A user reports a file download was blocked, but when the admin checks the Traffic log, the Action column for that session shows "allow." How is this possible?

The Traffic log Action column reflects only the Security Policy verdict; content-inspection profiles (Threat, WildFire, URL Filtering) can still act on "allowed" traffic afterward — check the Threat/WildFire logs for that session ID.

10. A compliance reviewer asks exactly what categories of data Device Telemetry uploads to Palo Alto Networks. Which answer is accurate?

Telemetry covers operational categories — usage, health, and threat/app statistics — feeding Palo Alto's ML/threat-intel pipeline, not full packet or session content.

11. Integrity Measurement Architecture (IMA) detects a platform integrity violation on a production firewall. What happens by default?

The default response is to log the violation as a critical system event while continuing to run; reboot-to-maintenance is a configurable, more disruptive alternative.

12. Which of these is a documented, platform-specific monitoring caveat an engineer should account for when planning a small-branch deployment?

The PA-410 is called out specifically as requiring Panorama management just for full monitoring functionality — a planning gotcha for small-branch, standalone deployments.