Zero Trust Architecture And Design practice questions

Configure a single global allow rule for all traffic originating from the switch management subnet

Why it fails: Incorrect. A global allow rule completely violates Zero Trust.

Disable Spanning Tree Protocol on all access layer switches

Why it fails: Incorrect. Disabling STP causes loops, not security segmentation.

Rely on physical VLAN separation exclusively without firewall inspection

Why it fails: Incorrect. VLANs alone do not provide deep layer 7 inspection or prevent lateral movement if compromised.

Permanently disconnecting all directory servers and relying solely on manual CLI IP typing

Why it fails: Disconnecting directory servers and typing IPs manually removes the automated identity mapping User-ID provides, and manual intervention directly violates the no-administrative-intervention requirement. It is tempting as an isolation tactic during outages, but it defeats the purpose of resilient User-ID mapping.

Disabling User-ID failover timeouts and setting retry intervals to infinity

Why it fails: Infinite retry intervals and disabled failover timeouts prevent User-ID from switching to secondary sources, so identity awareness stalls when domain controllers fail. It is tempting to avoid premature failover, but bounded timeouts are what enable automatic failover to alternate sources.

Implementing standard VRRP failover groups across the core routing switches

Why it fails: VRRP is a high-availability redundancy protocol, not a security segmentation strategy.

Configuring static VLAN tagging on the core switch to separate traffic into distinct broadcast domains

Why it fails: VLAN separation alone only operates at Layer 2 and does not provide application-layer visibility or User-ID mapping enforcement.

Relying on standard subnetting with classic IP-based access control lists at the gateway router

Why it fails: IP-based ACLs lack Layer 7 App-ID visibility and violate the principle of least privilege required by Zero Trust.

Configure GlobalProtect with split tunneling to send only SaaS traffic through Prisma Access for inspection.

Why it fails: Split tunneling can direct SaaS traffic to Prisma Access, but it does not guarantee DLP inspection or device posture checks. Split tunneling is a routing decision; it must be combined with security policies and DLP profiles. Without explicit policy configuration, traffic may bypass inspection. Additionally, split tunneling may allow other traffic to go directly, potentially bypassing security controls.

Use GlobalProtect with HIP checks and enforce security policies on the firewall to block non-compliant devices.

Why it fails: HIP checks and firewall policies enforce device posture and access control, but they do not provide DLP inspection for SaaS traffic. DLP requires deep content inspection, which is not performed by standard firewall policies. Without SSL decryption and DLP profiles, data loss prevention cannot be achieved. This option addresses access control but not data protection.

Implement Cloud Access Security Broker (CASB) inline with Prisma Access to inspect SaaS traffic and enforce DLP.

Why it fails: While CASB can provide DLP for SaaS, it is not a native component of Prisma Access and would require additional integration. Prisma Access already includes CASB capabilities, but the question specifies using Palo Alto Networks components. Inline CASB may not enforce device posture or integrate seamlessly with GlobalProtect. The most integrated approach is to use Prisma Access's built-in DLP and SSL decryption.

AWS Security Groups for pods with VPC CNI, combined with IAM roles for service accounts and VPC endpoint policies.

Why it fails: Security groups for pods enforce Layer 3 and Layer 4 rules at the elastic network interface level, and IAM roles for service accounts govern AWS API access. Neither provides Layer 7 authorization for service-to-service traffic inside the cluster, and VPC endpoint policies apply only to AWS service endpoints. They do not inspect or authorize HTTP methods or paths between microservices.

Kubernetes NetworkPolicy resources with pod selectors and namespace selectors, applied to all namespaces.

Why it fails: Kubernetes NetworkPolicy operates at Layers 3 and 4, allowing or denying traffic based on pod and namespace selectors, IP blocks, and ports. It cannot enforce Layer 7 authorization such as permitting only GET requests to a specific path or requiring a particular service identity. It also does not provide mutual TLS or application-layer identity verification.

AWS App Mesh with Envoy sidecar proxies, mTLS enabled, and virtual service routes that enforce HTTP header-based authorization.

Why it fails: AWS App Mesh provides service mesh capabilities with Envoy sidecars and mTLS, but its routing and authorization features are limited to traffic shifting and basic HTTP matching. It does not natively support identity-based Layer 7 authorization policies as expressive as those needed for Zero Trust, and it lacks a built-in policy engine for fine-grained authorization decisions based on service identity.

Set up a VPN with split tunneling and require contractors to use MFA to access the application.

Why it fails: A VPN with split tunneling grants network-level access, which violates least privilege because contractors could potentially reach other internal resources. MFA alone does not verify device posture, and split tunneling can expose the corporate network to risks from the contractor's personal device. This approach does not provide the granular, application-level control required for Zero Trust.

Use a next-generation firewall with App-ID to control access to the application based on user credentials and application signatures.

Why it fails: A next-generation firewall with App-ID can identify the application and enforce user-based policies, but it does not verify device posture or provide per-application access for unmanaged devices. It operates at the network level and may not support clientless access for contractors. This approach lacks the continuous verification and least privilege enforcement needed for Zero Trust.

Deploy a reverse proxy that provides clientless access to the application after authenticating contractors and checking device posture via a lightweight agent.

Why it fails: A reverse proxy with clientless access is suitable for web applications, but the requirement states that contractors use personal devices that cannot be managed. A lightweight agent may not be installable on personal devices, and clientless access may not support the custom application's full functionality. This approach may not enforce device posture adequately without an agent.

Explicit Proxy configuration to redirect all web traffic to Prisma Access.

Why it fails: Explicit Proxy is useful for web traffic inspection but is not required for ZTNA. GlobalProtect tunnel mode provides connectivity for all applications, not just web. Explicit Proxy may be used for specific use cases but is not a core component of ZTNA. Its absence does not prevent ZTNA implementation.

Cloud Identity Engine to synchronize user identities from multiple directories.

Why it fails: Cloud Identity Engine helps aggregate user identities, but it is not mandatory for ZTNA. User-ID can be obtained directly from directories or via GlobalProtect. While it simplifies identity management, it is an optional enhancement, not a required component for enforcing least privilege in ZTNA.

Prisma Access service connections to integrate with on-premises resources.

Why it fails: Service connections are used to connect Prisma Access to on-premises networks, but they are not strictly required for ZTNA to SaaS or internet-based applications. ZTNA can be implemented for cloud applications without service connections. While they are important for hybrid environments, they are not a fundamental component for all ZTNA deployments.

Configure port-mapping on NAT devices to correlate user IP addresses manually via a custom script

Why it fails: Incorrect. Manual correlation scripts are insecure, non-scalable, and prone to administrative errors.

Configure Panorama to pull user mappings exclusively via Windows client-based WMI polling across WAN links for every endpoint

Why it fails: Incorrect. WMI polling across WAN links does not scale, is prone to failure over high-latency networks, and is not recommended for cloud-centric identity.

Rely solely on local User-ID agent installations on every single workstation without central management

Why it fails: Incorrect. Managing local agents on every endpoint individually is not scalable for enterprise environments.

External Dynamic Lists (EDLs) pointing to static local text files on an internal FTP server

Why it fails: Static local text files on an FTP server cannot reflect workloads that spin up or down automatically, so policies would still need manual edits. EDLs are genuinely useful for ingesting external threat feeds, such as published malicious IP lists, where the source updates on a predictable schedule rather than per-workload.

GlobalProtect clientless VPN portals configured with static user accounts

Why it fails: Clientless VPN portals with static user accounts govern remote user access, not workload IP addresses, so they cannot drive dynamic policy as instances spin up or down. It is tempting because GlobalProtect delivers Zero Trust user access control, and would be correct for securing remote workforce connections rather than cloud workload identity.

Static IP address objects maintained via a weekly scheduled ticket queue

Why it fails: Static IP objects updated through a weekly ticket queue are manual, so policies cannot adapt as AWS and NSX workloads scale; the stem explicitly requires no manual IP updates. It is tempting because static objects are simple and auditable, and would suffice for stable, unchanging on-premises hosts.

Disable User-ID and App-ID mapping for internal traffic to reduce CPU overhead on the firewall while maintaining layer 3/4 filtering

Why it fails: Disabling User-ID and App-ID strips the identity and application context that ZTNA policy decisions depend on, leaving only addresses and ports. It is tempting because it cuts firewall CPU load, and that trade-off suits throughput-constrained environments where coarse layer 3/4 segmentation is the accepted security posture.

Create a wide-open intra-zone rule to allow all east-west traffic for performance optimization and apply inspection only on the perimeter

Why it fails: A blanket intra-zone permit removes the per-application policy enforcement ZTNA requires, so lateral movement within the zone is uninspected. It is tempting because perimeter-only inspection preserves firewall throughput, and that design fits legacy flat networks where the zone boundary is the sole trust boundary.

Route all east-west traffic directly through core enterprise switches without firewall inspection to minimize latency

Why it fails: Zero Trust requires inspection of all traffic, including east-west flows between applications, so bypassing firewalls contradicts the model. Direct core switching suits trusted flat networks optimised for latency, not microsegmentation enforcing least-privilege policy between workloads.

Delete all rules older than one year and create a single wildcard 'any-any' allow rule with WildFire enabled

Why it fails: Deleting rules by age and inserting any-any with WildFire removes all segmentation, granting unrestricted access and violating Zero Trust. A broad allow rule is appropriate only as a temporary troubleshooting measure, never as a replacement for granular App-ID policy in production.

Enable strict pre-rules on Panorama that automatically drop any traffic matching application-default without human intervention

Why it fails: Strict pre-rules drop traffic automatically without human review, so legitimate application-default sessions would be blocked, disrupting production. Pre-rules are intended for known-bad enforcement, whereas Policy Optimizer's App-ID conversion workflow lets the architect review suggested rules before committing them.

Run theACC (Application Command Center) to manually export all traffic logs into CSV format and rewrite rules via CLI scripts

Why it fails: ACC provides traffic visibility and log export, but CSV exports and CLI scripts give no shadowed-rule detection, no App-ID dependency mapping and no safe conversion path. ACC is the right tool for monitoring and investigating traffic patterns, not for automating legacy port-based rule migration.

Create a single rule allowing 'any' application over port 443 with WildFire enabled

Why it fails: Allowing any application over port 443 grants far more than least privilege, since App-ID cannot distinguish permitted applications from others tunnelling on that port. It tempts because WildFire inspection adds threat detection, and would be correct for a broad internet-edge rule where application identification is genuinely unavailable.

Disable App-ID entirely and rely exclusively on IP subnet filtering to maximize packet throughput

Why it fails: IP subnet filtering cannot identify applications, so it cannot enforce least privilege per App-ID; it also abandons the Layer 7 visibility the scenario requires. It tempts because subnet filtering is a legitimate coarse segmentation control, and would be correct where only network-level zoning, not application-level policy, is needed.

Set all application actions to 'reset-both' and require manual administrator approval for every new TCP connection

Why it fails: Reset-both on every application plus per-connection manual approval blocks legitimate traffic and is operationally impossible, not least privilege. It tempts because reset-both is a genuine App-ID action for blocking unwanted sessions, and would be correct for specific risky applications rather than all traffic.

Directly on every end-user laptop as a software-only client package without any network gateway

Why it fails: ISGs are network appliances positioned at internal chokepoints to enforce zone-to-zone policy. A software client on each laptop provides host-based enforcement without a network segmentation gateway, so east-west traffic between segments is not inspected. Endpoint agents would be correct for device-level posture and host firewall control.

Only inside public cloud VPCs as software gateways dedicated exclusively to VPN tunnels

Why it fails: ISGs are placed at internal network aggregation points to segment east-west traffic between internal zones. Restricting them to cloud VPCs as VPN-only software gateways leaves on-premises lateral movement uninspected. Cloud-hosted segmentation gateways would be correct for isolating workloads within a public cloud environment.

Exclusively at the internet edge to inspect inbound and outbound traffic

Why it fails: ISGs segment internal east-west traffic between internal zones; placing them solely at the internet edge inspects north-south traffic instead. Internal lateral movement therefore remains uncontrolled. Internet-edge placement would be correct for perimeter ingress and egress inspection, not internal segmentation.

Rely exclusively on browser-based captive portal prompts for every single TCP session initiated by any user

Why it fails: Captive portal prompts authenticate users only when they first browse, so mappings lapse and every TCP session cannot be intercepted this way at scale. It is tempting for guest or BYOD networks lacking domain integration, where portal authentication genuinely is the intended mechanism.

Configure the firewalls to perform continuous brute-force SNMP polling against all domain controller management interfaces

Why it fails: SNMP polling of domain controller management interfaces retrieves device health and interface data, not user-to-IP mappings, and brute-force attempts trigger lockouts and monitoring alerts. It is tempting because SNMP is a lightweight, firewall-initiated protocol, but it is correct for monitoring network devices, not identity collection.

Disable authentication checks and allow unauthenticated guest access for all internal users

Why it fails: Disabling authentication and permitting unauthenticated guest access removes the identity verification User-ID depends on, violating hardening requirements and mapping no real users. It is tempting as a way to avoid RPC dependencies, but it would only suit a deliberately open public network with no accountability.

To log user browsing habits for human resources compliance reporting

Why it fails: Decryption supports security inspection and policy enforcement, not HR monitoring of browsing habits. Logging user activity is tempting because URL filtering and User-ID produce browsing logs, but those come from existing firewall logging, not from decrypting TLS; the purpose is threat detection and access control.

To store plaintext copies of all banking and medical passwords in the firewall local database

Why it fails: Decryption exists to inspect traffic for threats and enforce policy, not to archive credentials; storing plaintext passwords would itself violate PCI DSS and privacy requirements. Retaining plaintext is tempting where audit or DLP logging is mandated, but that scenario uses tokenisation or hashed credential vaults, not firewall databases.

To accelerate TCP handshake performance and reduce firewall CPU utilization

Why it fails: Decryption adds processing overhead rather than reducing it, and TCP handshakes are unaffected by SSL inspection. Performance optimisation is tempting because hardware acceleration and TLS session reuse exist, but those are separate features; the primary purpose here is visibility into encrypted traffic for Zero Trust policy enforcement.

Static IPsec pre-shared keys configured on standard native OS VPN clients

Why it fails: Static IPsec pre-shared keys authenticate the tunnel but cannot evaluate endpoint posture, so certificate, disk-encryption and endpoint-protection checks never occur before access. It is tempting because site-to-site IPsec suits fixed gateways with pre-shared keys, yet it provides no per-device compliance signal for 20,000 roaming endpoints.

Standard HTTP basic authentication prompts combined with local administrator username/password files

Why it fails: HTTP basic authentication transmits credentials unencrypted and cannot interrogate endpoint state, so no certificate, disk-encryption or endpoint-protection posture data reaches the gateway before access. It is tempting because basic auth suits simple internal portals or lab devices where identity alone suffices and no device trust is required.

RADIUS authentication to an external OTP token server without any endpoint compliance agent

Why it fails: RADIUS with an external OTP server verifies only user credentials, so no mechanism reports certificate, disk-encryption or endpoint-protection state to the gateway; posture cannot be evaluated before access. It suits environments needing a second authentication factor for legacy VPN clients, where device health is out of scope.

Enforcing static local user accounts on every firewall CLI

Why it fails: Static local accounts exist only on the firewall itself and carry no directory identity, so they cannot map Active Directory users to IP addresses across forests. They are tempting for small, isolated deployments with no directory integration, where local authentication alone is sufficient.

Writing custom Python scripts on every firewall to scrape NetBIOS cache every 5 seconds

Why it fails: Scraping NetBIOS cache via custom scripts is unsupported, unreliable and does not aggregate directory identities from multiple forests into policy. It is tempting because it avoids deploying agents, and could work in a single small network where scripting overhead is tolerable.

A single static User-ID agent pointing only to the primary domain controller of the root domain

Why it fails: A single User-ID agent bound to one root domain controller cannot read user-to-IP mappings from disjointed forests, since each forest holds separate directory data. Multiple agents, one per forest, are required. It is tempting as the simplest deployment, and suffices for a single-domain environment.

Full-tunnel IPsec VPN granting access to the entire internal RFC1918 subnet space

Why it fails: A full-tunnel IPsec VPN places contractors inside the RFC1918 address space, contradicting least privilege by granting network-layer reach far beyond the named applications. It is tempting because IPsec VPNs are the traditional remote-access mechanism, but they are correct for broad internal access, not application-scoped contractor sessions.

Disabling authentication and placing contractors on the guest Wi-Fi VLAN

Why it fails: Disabling authentication removes any identity basis for authorisation, and the guest VLAN still permits lateral reachability, so least privilege cannot be enforced. It is tempting because guest isolation appears restrictive, but it is correct only for anonymous internet-only visitors, not contractors needing specific legacy applications.

Open public-facing NAT rules on the perimeter firewall mapped to internal legacy application servers

Why it fails: Public NAT rules expose legacy servers to arbitrary internet sources and authenticate nobody, granting broad reachability rather than least privilege. It is tempting because NAT is a familiar way to publish internal services, but it is correct only for deliberately public, unauthenticated endpoints, not contractor-scoped access.

Deploying a single physical PA-7050 firewall at the top-of-rack switch layer outside the hypervisor

Why it fails: Top-of-rack inspection only sees traffic leaving the host, so same-host VM-to-VM frames never reach the PA-7050. It is tempting because a high-throughput physical chassis is the standard choice for north-south perimeter filtering, where traffic does traverse the rack uplink.

Configuring standard syslog forwarding from the hypervisor management daemon directly to external storage

Why it fails: Syslog forwarding only exports hypervisor log events; it neither intercepts nor inspects VM-to-VM packets. It is tempting because centralised logging is a genuine Zero Trust telemetry component, and would be the right answer if the requirement were audit visibility rather than inline inspection.

Disabling all virtual firewalls and trusting inter-VM communication by default

Why it fails: Trusting inter-VM traffic by default removes the enforcement point entirely, so no inspection occurs. It is tempting because it restores east-west throughput and avoids firewall-induced latency, which is the correct trade-off only where the segment is already isolated by other controls.

WildFire malicious sample submission logs

Why it fails: WildFire logs record malware verdicts and sample submissions, not rule hit counters, so they cannot identify unused rules. Rule usage analysis requires the Policy Optimizer's rule-hit data. WildFire logging is the right tool when investigating which files triggered sandbox verdicts.

Traffic log export to Excel with manual VLOOKUP formulas

Why it fails: Exporting traffic logs and applying manual VLOOKUP formulas cannot reliably correlate rule names against hit counts across the full rulebase, and it lacks scheduled, repeatable analysis. It is tempting because the logs do contain the necessary hit data, and spreadsheet analysis would be correct for a one-off audit of a small, static ruleset.

GlobalProtect client posture assessment reports

Why it fails: GlobalProtect posture assessment reports describe endpoint compliance state, such as patch level and disk encryption, and contain no security rule hit counters. It is tempting because posture data supports policy decisions, and these reports would be correct when the requirement is verifying endpoint compliance before granting access.