Select Two (Multi-Select) Questions

Assigning the tag directly to the interface in the Network tab.

Why it fails: Interface assignment tags the firewall's own interface, not the source or destination IP addresses of sessions, so no address-to-tag mapping is produced for Dynamic Address Groups. It is tempting because interface tagging is a genuine PAN-OS feature used for zone-based policy and routing decisions.

Creating a custom App-ID that identifies the traffic.

Why it fails: App-ID identifies applications by traffic signatures, not by tagging IP addresses, so it cannot register tags into Dynamic Address Groups. It is tempting because App-ID classification feeds security policy, and would be relevant where policy must distinguish applications rather than group addresses.

Use 'show counter global filter delta yes' to look for packet drops.

Why it fails: While this command can show if packets are being dropped, it does not identify the specific security policy rule causing the drop. It indicates that drops are occurring but not why. It is more of a general health check and lacks the granularity to pinpoint policy-related blocks, making it less direct than policy match or log analysis.

Run 'show session all filter source <user-IP> destination <server-IP>' to see if a session exists.

Why it fails: This command shows active sessions between the user and server. If the traffic is being blocked, no session will exist, so the absence of a session does not confirm that a security policy is the cause—it could be a routing issue or the server being down. It is a useful check but not definitive for policy blocking.

Run 'debug dataplane packet-diag set filter match source <user-IP> destination <server-IP>' to capture packets.

Why it fails: Packet capture can show if packets are reaching the firewall and if they are being dropped, but it does not directly indicate which security policy rule is responsible. Analyzing captures is time-consuming and requires expertise. It is not the most efficient first step to determine if a policy rule is blocking traffic.

Routing protocol updates (BGP/OSPF).

Why it fails: BGP and OSPF routing updates are exchanged between routers at runtime and configured under Network > Virtual Routers; they never appear in Device > Dynamic Updates. That menu lists Applications and Threats, Antivirus, and WildFire content. Routing protocols are tempting because they are also called updates, but they are live peer exchanges, not downloadable signature packages.

PAN-OS firmware images.

Why it fails: PAN-OS firmware images are downloaded from the support portal and installed via Device > Software, not managed as dynamic updates. The Dynamic Updates page holds Applications and Threats, Antivirus, and WildFire signatures. Firmware is tempting because both are versioned downloads, but it is a full OS image, not a content signature package.

GlobalProtect configuration

Why it fails: GlobalProtect governs remote user VPN connectivity and tunnel settings, not the forward-proxy decryption policy, certificate or exclusion rules that determine inspection. It would be the correct area to verify when remote users cannot establish VPN tunnels or reach internal resources.

Client-side browser cache

Why it fails: Browser cache stores previously fetched content and holds no decryption policy, certificate trust or cipher configuration, so it cannot affect whether the firewall decrypts a session. It is relevant when troubleshooting stale or corrupted page content on a client, not TLS inspection.

App-ID database version

Why it fails: App-ID signatures identify applications for policy enforcement; they do not govern certificate trust, decryption profiles or exclusion lists, so a stale database cannot block decryption itself. Version verification matters when newly released applications are being misclassified or missed by policy.

QoS profile

Why it fails: A QoS profile governs bandwidth allocation and marking, not the traffic-identification criteria a Security Policy matches against. Policies use sources such as IP address, user identity, or application. A QoS profile would be correct when defining traffic treatment within a QoS policy.

Interface speed

Why it fails: Interface speed is a physical or link-layer attribute, not a traffic-matching source that a Security Policy can reference. Policies match sources such as IP address, user, or application. Interface speed would be relevant when configuring QoS shaping or link-capacity thresholds instead.

NAT policy

Why it fails: NAT policy governs address translation rules, not the source categories from which a Security Policy is derived, such as pre-rules, post-rules, or default rules. It is tempting because NAT policy is itself a policy type configured in the same management interface, and would be the right answer if the question asked about translation rule types rather than policy sources.

Power supply voltage.

Why it fails: Power supply voltage is hardware telemetry absent from traffic log records, so it cannot filter them. It is tempting because voltage genuinely belongs in facilities or hardware-health monitoring, where it would be the correct criterion to track.

CPU temperature.

Why it fails: CPU temperature is host hardware telemetry, not a field within traffic log records, so it cannot filter them. It is tempting because temperature genuinely belongs in infrastructure monitoring dashboards, where it would be the correct criterion to alert on.

A list of all connected switch ports.

Why it fails: Switch port listings describe internal network topology and are not registration data the portal validates. It is tempting because documenting connected ports is genuine switch inventory work, but registration instead requires identifying details such as serial number, model and support entitlement, which the portal uses to associate the device with the correct account.

The public SSH key of the firewall.

Why it fails: The firewall's public SSH key is not collected during portal registration; the portal instead requires identifying details such as serial number, model and support entitlement. It is tempting because SSH keys genuinely authenticate administrative sessions to the device, but that is device management, not the asset-identification data the registration workflow validates.

A tag assignment for the object

Why it fails: Tags are optional metadata used mainly for dynamic address group membership and organization. A static Address Object does not require a tag to be created or to function in a policy, so a missing tag would not prevent the object from committing or matching traffic.

A description field entry

Why it fails: The description field is optional documentation that helps administrators understand an object's purpose. It has no bearing on whether the Address Object can be saved or referenced in policy, so leaving it blank does not affect the object's functionality.

A DNS server association

Why it fails: Associating a DNS server is relevant to FQDN Address Objects, which resolve names to addresses. A static Address Object already contains a fixed IP value and does not perform resolution, so no DNS server association is required for it to be valid.

Random IT forums on the internet.

Why it fails: Random forums carry unverified, potentially outdated or malicious content, so they cannot be trusted for authoritative advisories. They are tempting because they are free and fast, and would be correct only for informal peer troubleshooting, never for official security guidance.

The local system logs.

Why it fails: Local system logs record events on that host only; they contain no vendor advisories or product change notifications. They are tempting because they are readily available, and would be correct when investigating an incident or auditing activity on that specific machine.

Keyboard input logs.

Why it fails: Palo Alto firewalls forward traffic, threat, URL, WildFire, data and system logs, not keystroke capture. It is tempting because endpoint monitoring tools record keyboard input for forensic auditing, which would be the correct source when investigating user activity on managed hosts.

Hardware diagnostic sensor readings.

Why it fails: Hardware diagnostic sensor readings are local telemetry for troubleshooting chassis components and cannot be forwarded as external log streams. The forwardable types are traffic, threat, URL, WildFire and system logs. It is tempting because sensor data genuinely aids hardware fault diagnosis, but that is viewed on-box, not exported to a collector.

BIOS boot sequences.

Why it fails: BIOS boot sequences are firmware-level events never generated as firewall log types. It is tempting because boot-time integrity monitoring exists in endpoint platforms, which would be the correct source when auditing hardware or firmware tampering on individual devices.

Defining an IP range

Why it fails: Tags are colour-coded labels applied to objects for filtering and grouping; an IP range is defined on address objects, not tags. Defining ranges feels plausible since tags organise address objects, but the tag itself holds only name and colour metadata.

Defining a port protocol

Why it fails: Tags carry only a name and colour; port and protocol values belong to service objects. Associating tags with services is tempting because tags group many object types, yet no port or protocol field exists on a tag definition.

Creating a security policy

Why it fails: Tags are metadata applied to existing objects; security policies are separate rule constructs that reference objects. Creating a policy via a tag is tempting because tags filter policy views, but tags cannot themselves define or generate policy rules.

The firewall has a valid Threat Prevention license.

Why it fails: A Threat Prevention license enables threat detection and prevention, but it is not required for log forwarding. Log forwarding can occur regardless of subscription status. While threat logs may be generated only with the license, the forwarding mechanism itself does not depend on it. Thus, this is not a requirement for log forwarding.

The firewall's management interface has a default gateway.

Why it fails: The management interface default gateway is used for management traffic, such as license updates and software downloads. While it may be needed for the firewall to reach external services, it is not directly related to forwarding logs to an external SIEM. Log forwarding uses the data plane or management plane depending on configuration, but the default gateway alone does not ensure log forwarding.

The security policy rules have logging enabled at session end.

Why it fails: Enabling logging at session end ensures that traffic logs are generated, but it does not guarantee forwarding to an external SIEM. The logs could still be stored locally only. For forwarding, a Log Forwarding profile must be applied. Therefore, this action alone is insufficient and not one of the two required verifications.

Tag

Why it fails: Tags are optional labels applied for classification and search, not mandatory attributes of a custom Service Object; creation succeeds without them. They are tempting because tagging is encouraged for governance and reporting, yet the required elements are the object's name, protocol and port, which the tag field does not supply.

Description

Why it fails: Description is optional metadata, not a required field when defining a custom Service Object; the mandatory elements are name, protocol and port. It is tempting because descriptions aid administration and are commonly populated, but they are never enforced at creation, so they cannot satisfy a question asking which elements are required.

User names

Why it fails: User data is from AD.

Security zones

Why it fails: Zones are under Network.

Policy rules

Why it fails: Policies are under Policies tab.

Reduced need for local power supplies.

Why it fails: Strata Cloud Manager is a cloud-delivered management plane; it centralises policy and telemetry and has no bearing on how firewall appliances draw electrical power. Local power provisioning is a site facilities concern, relevant only when planning physical rack installations.

Automatic physical hardware replacement.

Why it fails: Strata Cloud Manager provides centralised policy management and monitoring, not hardware logistics; it cannot dispatch replacement appliances or automate RMA handling. Automatic hardware replacement belongs to vendor support contracts and field services, which operate independently of the management platform.

Increased local firewall interface speed.

Why it fails: Strata Cloud Manager orchestrates configuration and visibility across firewalls; it does not alter the throughput or link speed of local firewall interfaces, which are fixed by hardware and transceiver capabilities. Interface speed is addressed through appliance model selection and physical cabling.

They automatically inherit tags from the policy rule they are applied to.

Why it fails: Service objects hold their own name, protocol and port definitions; they do not inherit tags from the policy rule referencing them, so this fails the stated characteristic. Tag inheritance is tempting because policy rules do carry tags, but that mechanism applies to rule objects themselves, not to the service objects they reference.

They are globally unique across all Device Groups.

Why it fails: Service objects are scoped to a Device Group or shared location rather than being globally unique across all Device Groups, so this fails the stated characteristic. Global uniqueness is tempting because some objects are shared, but service objects follow the same location-scoped model as other configurable objects in Strata Cloud Manager.

They support the definition of both TCP and UDP ports in a single object.

Why it fails: A single service object defines one protocol and port combination; TCP and UDP ports cannot be combined in one object, so this fails the stated characteristic. It is tempting because service groups bundle multiple objects, but that grouping is a separate construct, not a property of an individual service object.

Destination port

Why it fails: Application filters classify traffic by application signature or behaviour, not by transport-layer destination port, which belongs to packet-filter or service-based rules. It is tempting because many application definitions map to well-known ports, but the filter itself inspects payload characteristics rather than the port field.

Source IP address

Why it fails: Application filters identify traffic by application signature, not by source IP address, which is a network-layer attribute handled by address-based rules. It is tempting because source IP is a common match criterion in firewall policies, but application filtering operates on payload and protocol behaviour instead.

Local-only access

Why it fails: Device Groups exist to push shared policy from SCM to many managed firewalls, so access is centralised rather than local-only. It is tempting because local administrators retain device access, but that is the standalone management model Device Groups are designed to replace.

Automatic hardware replacement

Why it fails: Device Groups synchronise configuration and policy across firewalls; they do not detect hardware failure or trigger replacement. It is tempting because groups simplify fleet-wide management, but automatic hardware replacement is a support-contract entitlement, unrelated to SCM policy scoping.

IP address reputation filtering.

Why it fails: IP reputation filtering classifies senders by threat score, not by application signature, so it cannot identify which application generated the traffic. It is tempting because reputation feeds genuinely block known-malicious hosts at the network layer, which is the right control when the requirement is denying traffic from compromised or blacklisted addresses.

MAC address filtering.

Why it fails: MAC address filtering matches layer-2 hardware identifiers, which are irrelevant to identifying the application carried inside the traffic. It is tempting because MAC filtering genuinely restricts which devices may associate with a switch port or wireless network, the correct choice when the requirement is limiting access to known hardware.

URL filtering categories.

Why it fails: URL filtering categories classify web destinations by reputation and content, not by application signature, so they cannot identify arbitrary App-ID traffic. It tempts because URL filtering does inspect HTTP sessions, but App-ID identifies applications via signatures and behavioural heuristics instead.

By reviewing the firewall's physical serial number label.

Why it fails: A serial number label identifies hardware only; it carries no subscription or licensing data. Subscription status is confirmed through the management console's licence or support summary. It is tempting because serial numbers are used for warranty and support entitlement, but they do not reflect whether a security subscription is currently active.

By checking the Traffic Logs.

Why it fails: Traffic Logs record permitted and denied sessions, not licence or subscription state. Subscription status is verified via the management interface's licence or support pages. It is tempting because logs confirm the device is passing traffic, but an expired subscription can still forward traffic, so logging does not evidence entitlement.

By pinging the license server.

Why it fails: Pinging a license server only tests ICMP reachability, revealing nothing about subscription state or expiry. Subscription status is verified through the management interface's licence or support pages. It is tempting because connectivity checks are a familiar troubleshooting step, but reachability and entitlement are separate concerns.