Network Security Fundamentals practice questions

Panorama

Why it fails: Panorama is a central management platform, not a processing engine.

Management Plane

Why it fails: The management plane handles configuration and logs.

Control Plane

Why it fails: There is no separate 'Control Plane' in standard PAN-OS terminology; it is management vs data.

The traffic is coming from a zone with no security profile assigned.

Why it fails: Security profiles do not affect policy match decisions.

The firewall is in Layer 2 mode and the MAC address table is full.

Why it fails: MAC table limitations result in flooding, not policy drops.

The App-ID is unidentified, causing a drop by the default cleanup rule.

Why it fails: App-ID unidentified traffic is handled by the interzone policy if configured, not intrazone.

Virtual Wire

Why it fails: Virtual wire is for transparent insertion.

Tap

Why it fails: Tap is for passive monitoring.

Layer 2

Why it fails: Layer 2 is for switching.

SNMP Traps

Why it fails: Used for monitoring.

BGP Peer discovery

Why it fails: Used for routing.

DHCP Server lease logs

Why it fails: Not a direct User-ID mapping method.

Firmware update policy

Why it fails: Not a policy type.

User mapping policy

Why it fails: User-ID configuration, not a policy rule.

Increase the TCP session timeout values in the security policy so that flows remain active longer during failover.

Why it fails: Session timeouts control how long an idle flow is retained before being aged out; they do not influence forwarding decisions or protect a session from a routing change. Extending timeouts only keeps the state table entry alive longer, which can actually sustain a broken path, and it does nothing to preserve the original forwarding decision across a failover.

Configure a Policy-Based Forwarding (PBF) rule that pins matching traffic to a specific egress interface and next hop.

Why it fails: Policy-Based Forwarding overrides the routing table for matching traffic and pins it to a chosen egress interface and next hop, which is useful for traffic steering and link selection. However, PBF itself does not guarantee that a session survives a topology change; the pinned path can still be invalidated or blackholed, and PBF introduces its own failure modes if the designated next hop becomes unreachable.

Enable session ownership and asymmetric routing tolerance so established flows are not re-evaluated against the routing table.

Why it fails: Session ownership and asymmetric routing tolerance allow flows to be handled by the firewall that owns the session and permit out-of-order return paths, but they do not prevent an established session from being disrupted when the preferred route changes. These settings address where a flow is processed, not whether the forwarding path is preserved across a routing change, so they fail to meet the stated requirement.

Tap zone

Why it fails: A tap zone is designed for passive interfaces that receive mirrored traffic for monitoring or analysis, not for active routing of user traffic. Ethernet1/1 here carries live ISP traffic that must be inspected and routed, so a tap zone would not provide the forwarding behavior or the trust-boundary semantics this design requires.

Trust zone

Why it fails: A trust zone is intended for interfaces facing internal networks whose users and systems are considered relatively reliable. Placing the ISP-facing ethernet1/1 in a trust zone would misrepresent the boundary and could allow inbound sessions from the public internet to be treated as originating from a trusted segment, defeating the default protection posture.

Layer 3 zone

Why it fails: A Layer 3 zone is a valid zone type but it only describes the interface's addressing mode, not its trust level. Assigning ethernet1/1 as a Layer 3 zone without marking it as untrusted would not by itself establish the trust boundary the engineer needs, since the security posture depends on zone type, not merely on the interface being routable.

Enable the 'inspect intrazone traffic' checkbox in the zone protection profile for that zone

Why it fails: Zone protection profiles defend against flood, reconnaissance, and packet-based attacks at the ingress zone. They do not control whether intrazone traffic is inspected by security policy. There is no such setting inside a zone protection profile, so enabling it would not satisfy the requirement to force policy inspection between same-zone interfaces.

Configure a policy-based forwarding rule that redirects same-zone traffic through the firewall's inspection engine

Why it fails: Policy-based forwarding changes the next hop for traffic based on policy, but it does not cause intrazone traffic to be evaluated against security policy. The intrazone-default implicit rule still applies first. Policy-based forwarding is used for routing decisions such as sending specific flows to a different gateway, not for forcing inspection of same-zone traffic.

Create a security rule with the source and destination zones both set to the same zone and attach an application filter

Why it fails: A security rule cannot have the same zone as both source and destination in a way that overrides the implicit intrazone-default rule for same-zone interfaces. The implicit rules are evaluated in a fixed order, so this rule would not be matched for intrazone traffic. The engineer must change the zone design instead of attempting to work around it with a rule.

Layer 2 transparent mode with the firewall bridging the two VLANs

Why it fails: Transparent mode bridges two interfaces into a single broadcast domain and does not route between distinct subnets, so it cannot inspect traffic between two VLANs that require Layer 3 separation. It also does not permit the firewall to enforce policy between routed subnets, and it forces the firewall to participate in Layer 2 topology, which contradicts the design goal.

Layer 3 deployment where the firewall is the default gateway for both VLANs

Why it fails: This would satisfy inspection of east-west traffic, but it directly violates the stated requirement that the firewall must not be the default gateway. Making the firewall the gateway also introduces a single point of failure for routing and changes the existing network topology significantly, which is exactly what the architect is trying to avoid.

Virtual wire deployment between a pair of Layer 3 switches

Why it fails: A virtual wire binds two interfaces into a transparent conduit without IP addressing, which inspects traffic inline but does not provide routing between the two VLANs. Because the VLANs need Layer 3 reachability and the firewall must not be the gateway, a virtual wire alone does not solve the routing requirement and would break inter-VLAN communication unless an external router handles it.

File Blocking profile

Why it fails: A File Blocking profile blocks or alerts on specific file types based on their characteristics, but it does not inspect web traffic for malicious content. It operates on file transfers within allowed applications, not as a full web inspection engine. To inspect web traffic for threats, a different security profile is required.

URL Filtering profile

Why it fails: A URL Filtering profile controls access to websites based on URL categories, but it does not inspect web traffic content for malicious files. It is used for policy enforcement and user awareness, not for deep content inspection or file-type blocking.

Antivirus profile

Why it fails: An Antivirus profile scans traffic for viruses and malware, but it is typically applied to specific applications and does not provide comprehensive web traffic inspection on its own. It is one component of a complete security profile group, but not the primary feature for inspecting all outbound web traffic.

Create multiple Layer 2 zones, each containing a different subinterface with VLAN tags.

Why it fails: Layer 2 zones with VLAN-tagged subinterfaces require the connected switch to trunk multiple VLANs to the firewall. The branch has a flat Layer 2 subnet and the engineer cannot alter the switch configuration, so tagged subinterfaces cannot be delivered. This design is technically valid but depends on infrastructure changes the scenario rules out.

Create one Layer 3 zone and place all interfaces in it, then use application-based policy rules.

Why it fails: A single Layer 3 zone gives no zone-level separation, so all traffic is treated as intrazone and the default intrazone rule applies. While application-based rules can still filter traffic, the engineer specifically wants different policies per device type, which requires distinct zone boundaries. This approach collapses the segmentation the scenario demands and weakens least-privilege enforcement.

Create separate Layer 3 zones and assign each device type a different IP subnet.

Why it fails: Layer 3 zones require distinct IP subnets to route between them, but the branch uses one flat subnet and the engineer cannot add VLANs. This design would force re-addressing and switch reconfiguration, which the scenario explicitly excludes. It is a valid segmentation method in other cases, but it does not meet the stated constraint of keeping the existing Layer 2 topology.

Dynamic ARP Inspection on all VLANs

Why it fails: Dynamic ARP Inspection validates ARP packets against the DHCP snooping binding table to prevent ARP spoofing. It does not inspect or block BPDUs, so it cannot stop a rogue switch from participating in Spanning Tree or becoming the root bridge. It addresses a different Layer 2 threat than the one described.

DHCP snooping with trusted uplink ports

Why it fails: DHCP snooping filters DHCP messages to prevent rogue DHCP servers and builds a binding table used by other features. It does not process BPDUs and therefore cannot prevent a rogue switch from joining the Spanning Tree topology. The scenario requires BPDU-level protection, not DHCP message filtering.

Root Guard on the uplink ports toward the distribution layer

Why it fails: Root Guard prevents a port from becoming the root port by blocking superior BPDUs, which is useful on designated ports facing downstream switches. However, the scenario describes rogue switches on access ports, where BPDU Guard is the appropriate control. Root Guard on uplinks does not stop an access-port rogue switch from sending BPDUs and influencing topology.

Enable DNS sinkholing for the malicious IP.

Why it fails: DNS sinkholing is a technique where DNS responses are modified to redirect malicious domain queries to a sinkhole IP, typically for detection and analysis. It does not block traffic to a specific IP address. The analyst wants to block future traffic to the malicious IP, so DNS sinkholing is not the correct tool. It also requires DNS security subscriptions and configuration.

Configure a URL filtering profile to block the IP address.

Why it fails: URL filtering profiles are used to control access to web content based on URL categories, not to block IP addresses. While URL filtering can block access to malicious websites, it does not directly block traffic to a specific IP address. The analyst needs to block all traffic to that IP, including non-web protocols, so a URL filtering profile is not appropriate.

Create a security policy rule that denies traffic from any source to the malicious IP.

Why it fails: Creating a security policy rule can block traffic to the malicious IP, but it requires specifying source and destination zones, and it may be less dynamic than using a block list. Security policies are evaluated in order, and adding a rule at the top could work, but the question asks for a feature that quickly blocks without creating a new policy for each host. A block list is more efficient and purpose-built for this use case.

Create a security policy rule that allows the required applications for the finance group and attach a security profile group to the rule.

Why it fails: Attaching a security profile group enables threat prevention, URL filtering, and file blocking, but it does not ensure logging of all other traffic. Security profiles are for content inspection, not for logging denied traffic. This action is unrelated to the logging requirement and does not help achieve the goal.

Create a security policy rule that allows the required applications for the finance group and enable logging at the start of the session.

Why it fails: Logging at the start of the session logs the session when it begins, but it does not capture the end-of-session details such as bytes transferred. While it provides some logging, it is not the best practice for logging allowed traffic. Moreover, it does not address logging of denied traffic, so it fails the overall requirement.

Create a security policy rule that allows the required applications for the finance group and place it above a rule that denies all other traffic.

Why it fails: Placing an allow rule above a deny-all rule is a common practice, but it does not ensure that all other traffic is logged. The deny-all rule would block other traffic, but logging must be explicitly enabled on that rule. The requirement includes logging all other traffic, so this action alone is insufficient.

Packet Capture (pcap)

Why it fails: A packet capture records raw frames on the wire, showing that traffic is dropped but never which firewall rule matched it. It is tempting because it proves connectivity failure at the packet level, and it would be correct for diagnosing MTU, TCP handshake or application-layer faults rather than policy rule hits.

GlobalProtect logs

Why it fails: GlobalProtect logs record VPN and endpoint connectivity events, not security policy rule evaluations, so they cannot identify which rule matched the traffic. They would be correct when diagnosing remote user tunnel or authentication problems rather than policy enforcement.

Traffic Monitor

Why it fails: Traffic Monitor shows flow-level allow/deny logs but cannot identify the individual rule that matched, so it cannot pinpoint the blocking rule. It is tempting because it visualises traffic flows across the firewall, and it would be the right tool for spotting anomalous or unexpected traffic patterns rather than rule attribution.

Zone Protection Profiles

Why it fails: Zone Protection Profiles defend against flood, reconnaissance and packet-based attacks at the ingress zone; they do not match application identity. It is tempting because they are enforced on traffic entering a zone, which sounds like the port-80 control being sought.

Service Objects

Why it fails: Service objects define protocol and port only, so any application can traverse TCP/80 once the service matches. It is tempting because port 80 is exactly what a service object expresses, and it would suffice if the requirement were port-based rather than application-based filtering.

Log Forwarding

Why it fails: Log Forwarding only exports session logs to external destinations such as syslog or email; it takes no action on traffic. It is tempting because it is configured alongside security policy and appears in the same rulebase, but it is the correct choice when the goal is audit retention, not enforcement.

Application Group

Why it fails: Application Groups bundle applications for policy matching, not IP addresses, so they cannot group hosts for a rule. They are correct when one policy must cover several applications such as web-browsing and ssl, but address grouping requires an Address Group object.

Tag

Why it fails: Tags are metadata labels applied to objects for dynamic grouping and policy filtering; they do not themselves contain IP addresses. Tags are correct for dynamically including registered IP addresses or users matching criteria, but a static list of addresses belongs in an Address Group.

Service Group

Why it fails: Service Group objects bundle port and protocol definitions, not IP addresses, so a security policy referencing one cannot match the required hosts. It is tempting because service groups do simplify rule maintenance, but that role belongs to Service objects; grouping IP addresses requires an Address Group instead.

The source zone is incorrect.

Why it fails: A wrong source zone means the session never matches the rule's zone pair, so the policy is skipped and the default deny applies. It is tempting because zone misconfiguration does cause silent denials, and it would be the answer if the rule matched no traffic at all rather than matching and being denied.

The firewall is in transparent mode.

Why it fails: Transparent mode still evaluates security policy against zone pairs; it changes interface addressing, not rule matching, so a matching web-browsing rule is not denied by it. It is tempting because transparent deployments alter routing, and it would be correct if the stem described traffic bypassing the firewall entirely.

The security profile is missing.

Why it fails: A missing security profile affects threat inspection and content scanning, not policy matching; the rule still matches web-browsing and permits the session. It is tempting because profiles are required for security policy enforcement, and it would be correct if the stem described traffic being allowed without inspection.

Allow all internal traffic, deny external.

Why it fails: Zero Trust requires every interzone flow to be authenticated and authorised, so blanket trust for internal segments contradicts the model outright. It is tempting because perimeter firewalls traditionally trusted the LAN, and that design would suit a legacy castle-and-moat network rather than microsegmented Zero Trust.

Allow traffic based on source IP only.

Why it fails: Source IP alone is spoofable and carries no identity or device posture, so it cannot satisfy Zero Trust's per-session authorisation requirement. It is tempting because IP-based rules are simple to write, and they would be acceptable in a flat network where address ranges map cleanly to trust levels.

Allow all traffic to simplify configuration.

Why it fails: Permitting all traffic removes the inspection and authorisation that Zero Trust demands, leaving no enforcement point between zones. It is tempting because it eliminates rule-tuning effort, and it would suit a lab or trusted test segment where segmentation provides no security value.

Use the 'intrazone-default' policy to automatically allow traffic to all servers.

Why it fails: The intrazone-default policy permits all traffic within a zone, granting far broader access than least privilege allows for specific servers. It is tempting because it removes the need to enumerate hosts, and relying on it would be acceptable where intra-zone traffic is genuinely trusted and no granular control is required.

Set destination zone to 'any' and destination address to 'any' to ensure traffic flow.

Why it fails: Setting both destination zone and address to any permits traffic to every possible destination, directly contradicting least privilege. It is tempting because any/any guarantees connectivity during troubleshooting, and such a permissive rule would be the right temporary choice when diagnosing whether a policy is blocking legitimate traffic.

Configure the security policy to reference the interface IP rather than an Address Object.

Why it fails: Referencing an interface IP ties the rule to the firewall's own address rather than the specific protected host, so it cannot enforce least privilege for that destination. It is tempting because interface IPs are concrete and simple to select, and this approach would suit rules governing traffic addressed to the firewall itself, such as management access.