Select Two (Multi-Select) Questions

DNS server addresses for the proxy.

Why it fails: DNS server addresses are used for name resolution, not for proxy configuration. While DNS is important for resolving the proxy's hostname, it is not a proxy-specific setting that must be specified in the agent configuration for proxy communication. The agent uses the system's DNS settings by default.

Broker VM address and port.

Why it fails: The broker VM is used for communication when direct internet access is unavailable, but it is not a proxy setting. The scenario specifically asks for proxy configuration to enable communication through a forward proxy. Broker VM settings are separate and not required for proxy communication.

SSL/TLS certificate for the proxy.

Why it fails: An SSL/TLS certificate is not required for the agent to connect through a forward proxy. The agent uses TLS to communicate with the management server, but proxy authentication typically relies on credentials or IP-based rules. Specifying a certificate for the proxy is not a standard configuration setting.

Mitigation

Why it fails: Mitigation is a defensive response action, not a phase of the attack kill chain.

Continuous Patching

Why it fails: Continuous patching is a preventative operational process, not part of the offensive kill chain.

Quarantine (isolates the client workstation into an isolated VLAN)

Why it fails: Quarantine is a response action in security profiles such as antivirus or vulnerability protection, isolating an infected host, not a URL Filtering category action. URL Filtering categories support allow, block, alert, continue, override and user credential submission. Quarantine would be correct when containing a compromised endpoint after malware detection.

Encrypt (automatically forces SSL forward proxy decryption for the URL)

Why it fails: Encrypt is not an assignable URL filtering action; decryption is handled by SSL forward proxy settings, not category actions. It is tempting because URL filtering profiles do interact with decryption policy. The assignable actions are allow, block, alert, continue, and override, depending on the platform.

Assign all administrative users the 'superuser' role to simplify troubleshooting.

Why it fails: Granting every administrator superuser removes role-based separation of duties, so any compromised account gains full device control. It is tempting to simplify troubleshooting, but least privilege requires assigning role-based admin accounts scoped to actual duties, reserving superuser for a minimal set.

Enable SSHv1 and SSLv2 to ensure legacy administrative tool compatibility.

Why it fails: SSHv1 and SSLv2 are deprecated, cryptographically broken protocols that expose the management plane to interception and downgrade attacks. It is tempting when legacy tools demand old ciphers, but the correct approach is disabling weak protocols and permitting only SSHv2 and TLS 1.2 or later.

Personal user email message bodies and browser photo uploads.

Why it fails: Cortex XDR ingests endpoint telemetry such as process, file, network and registry events; personal email bodies and photo uploads are user content outside its collection scope. It tempts because email and cloud storage are common breach vectors, but those are covered by separate email and CASB products.

Internal corporate cafeteria menu preferences.

Why it fails: Cafeteria menu preferences are business data unrelated to endpoint security telemetry; Cortex XDR collects process, file, network, registry and authentication events. It tempts because Dynamics 365 and HR systems do hold such data, but that is a business application scenario, not endpoint detection and response.

Granting permanent administrative access once a device passes initial corporate compliance checks

Why it fails: Zero Trust requires just-in-time, least-privilege access with continuous verification, so standing admin rights granted after a one-off compliance check violate that model. It tempts because compliance gating is genuinely part of Zero Trust, and it would fit a scenario permitting persistent privileged sessions after device attestation.

Trusting internal network traffic implicitly once the user connects via corporate VPN

Why it fails: Zero Trust treats the network as hostile and never trusts traffic implicitly, so a VPN tunnel cannot confer trust on internal flows. It is tempting because VPNs do encrypt and authenticate the transport, and implicit trust would be acceptable in a perimeter-based design where the corporate network is the trust boundary.

Allowing users to bypass authentication prompts when accessing internal web applications from managed assets

Why it fails: Zero Trust mandates explicit verification for every access request, so skipping authentication for internal apps on managed assets breaches that principle. It tempts because device compliance genuinely strengthens assurance, and such bypass would suit a legacy perimeter model trusting managed endpoints inside the network.

Exclusive reliance on publicly available penetration testing scripts

Why it fails: APTs develop custom tooling and zero-day exploits, so dependence on public penetration-testing scripts contradicts their defining resourcefulness. It is tempting because commodity attackers and script kiddies do reuse such scripts, and that behaviour would fit a low-sophistication threat rather than a persistent, well-funded campaign.

Short dwell times with aggressive, noisy data encryption

Why it fails: APTs prioritise long-term stealthy persistence, so short dwell times and noisy encryption describe ransomware, not APT tradecraft. It is tempting because aggressive encryption causes obvious impact, and that pattern would be the correct indicator when investigating a fast, disruptive ransomware incident instead.

Disable logging on all security rules to conserve management plane CPU resources.

Why it fails: Logging must remain enabled on security rules; logs feed traffic analysis, threat detection and forensic investigation. Disabling logging conserves management-plane CPU, which is why it tempts administrators facing resource pressure, but that saving sacrifices the visibility the firewall exists to provide.

Always use the 'any' source zone to ensure all internal subnets are covered simultaneously.

Why it fails: Using 'any' source zone collapses inter-zone and intra-zone distinctions, granting unintended lateral access and defeating zone-based segmentation. It tempts administrators wanting one rule to cover every internal subnet, but zones should be scoped explicitly so policy reflects the intended trust boundaries.

Place broad, permissive rules at the top of the security policy base to speed up rule evaluation.

Why it fails: Broad permissive rules at the top shadow the specific deny and allow rules beneath them, so later rules never match. Placing them first does reduce evaluation depth, which is the tempting rationale, but rule order should run specific-to-general with implicit deny at the base.

Reflash the physical BIOS firmware remotely to remove persistent bootkits.

Why it fails: BIOS reflashing is firmware-level work performed locally or via vendor management tools, not through an endpoint detection agent. Cortex XDR's console offers response actions like host isolation, file quarantine and process termination. Persistent bootkit removal would need physical or out-of-band access, outside the agent's scope.

Upgrade the physical RAM hardware configuration.

Why it fails: Cortex XDR is a software agent; it cannot alter physical hardware, and RAM upgrades require hands-on chassis work regardless. Console actions are limited to endpoint response functions such as isolating the host, terminating processes, quarantining files or initiating scans. Hardware changes belong to a maintenance window, not incident response.

Reinstall the host operating system from a golden cloud image.

Why it fails: Cortex XDR cannot reimage an endpoint from a golden image; it only runs response actions through its installed agent, such as isolation, quarantine and script execution. OS reinstallation is a provisioning task handled by imaging or configuration-management tooling, not by the XDR management console during an active incident.

Disable HTTPS redirection on the management interface

Why it fails: Disabling HTTPS redirection leaves administrators able to reach the management interface over plain HTTP, exposing credentials and session cookies to interception. HTTPS redirection exists precisely to force encrypted management sessions, so it should remain enabled on Panorama.

Share a single superuser account among all shift analysts to streamline shift handovers

Why it fails: A shared superuser account removes individual accountability, so audit logs cannot attribute administrative actions to a person, and one compromised credential exposes full control. Named accounts with role-based access suit shift handovers while preserving traceability.

Allow unauthenticated HTTP management access from any internal IP address

Why it fails: Unauthenticated HTTP access from any internal address permits credential-free, cleartext administrative sessions reachable by any host on the network, including compromised endpoints. Restricting management access to specific trusted addresses over HTTPS with authentication is the hardening baseline.

External Dynamic List (EDL) pointing to the RADIUS authentication database.

Why it fails: An External Dynamic List supplies IP addresses or URLs for policy matching; it holds no user credentials and cannot query RADIUS. It is tempting because EDLs are configured on the firewall and referenced in policy, but authentication requires a RADIUS server profile plus an authentication profile bound to the management interface.

WildFire Analysis Profile set to authenticate users.

Why it fails: WildFire Analysis Profile submits files for sandbox verdicts; it performs no user authentication and cannot contact a RADIUS server. It is tempting because WildFire profiles are firewall objects frequently attached to security policy, but administrative RADIUS login needs a server profile and an authentication profile.

SSL Decryption Profile attached to the management interface.

Why it fails: An SSL Decryption Profile governs certificate handling and cipher enforcement for inspected traffic; it neither authenticates administrators nor communicates with RADIUS. It is tempting because decryption profiles sit on the management plane's configuration tree, yet RADIUS admin login requires a server profile and an authentication profile.

Set the agent to report-only mode for device control

Why it fails: Report-only mode logs device usage without enforcing any block or allow decisions, so unauthorized USB storage would still function. This mode is useful for auditing but fails to enforce the restriction requirement, making it an incorrect choice for this configuration task.

Enable the exploit protection module for USB drivers

Why it fails: Exploit protection targets vulnerabilities in running processes and does not manage device access. Enabling it for USB drivers would not block or allow USB mass storage devices, so it does not contribute to enforcing the restriction on USB usage described in the scenario.

Add the USB mass storage class to the malware profile blocklist

Why it fails: Malware profile blocklists apply to files identified by hash or name, not to device classes. Adding a device class there has no effect on USB storage enforcement, so this option does not help implement the device control restriction required by the scenario.

Trust the internal network perimeter implicitly once a user successfully authenticates via VPN

Why it fails: Zero Trust grants no implicit trust based on network location or a single VPN authentication event; access is continuously verified per session. It is tempting because perimeter VPNs once implied internal trust, but that model is precisely what Zero Trust replaces.

Bypass security inspection for internal-to-internal data center traffic to maximize network performance

Why it fails: Zero Trust requires inspection of all traffic, including east-west flows between internal workloads; blanket bypass reintroduces implicit trust. It is tempting because bypassing inspection reduces latency, but that performance gain directly contradicts the inspect-everything principle.

Full disk encryption

Why it fails: Full disk encryption protects data at rest if the device is lost or stolen, but it does not prevent malware from executing when the system is running. It addresses confidentiality, not execution. Therefore, it is not directly effective for mitigating malware execution.

Host-based firewall

Why it fails: A host-based firewall controls network traffic to and from the endpoint, which can block malicious connections but does not prevent malware from executing locally. It is more about network containment than execution prevention. It is not the most direct control for stopping malware execution.

Security awareness training

Why it fails: Security awareness training educates users to recognize phishing and avoid risky behavior, reducing the likelihood of malware introduction, but it does not directly prevent execution once malware is present. It is an administrative control that complements technical controls.

Quality of Service (QoS) Profile

Why it fails: QoS profiles classify and shape bandwidth by application or DSCP, affecting throughput and latency rather than inspecting payloads for malicious URLs or exploits. They are tempting because they are attached to Security policy rules, but URL Filtering and Threat Prevention provide the content inspection this scenario requires.

Zone Protection Profile

Why it fails: Zone Protection Profiles defend the ingress zone against flood, reconnaissance and packet-based attacks before a session exists; they do not inspect HTTP/HTTPS content for URLs or exploits. They are tempting because they harden the firewall itself, but URL Filtering and Threat Prevention profiles attach to the Security policy rule for this.

Network Access Profile

Why it fails: No such profile type exists in PAN-OS; Security policy rules accept URL Filtering, Threat Prevention, WildFire, File Blocking, Data Filtering and similar profiles. It is tempting because the name suggests controlling which users or hosts may browse, but access decisions belong in the Security policy rule's source and destination fields, not a profile.

An improperly sized Layer 3 forwarding table causing next-hop packet re-synthesis on the data plane.

Why it fails: Layer 3 forwarding and next-hop re-synthesis occur on the data plane's forwarding ASICs and CPU, leaving management plane utilisation untouched. It is tempting because an undersized forwarding table genuinely causes packet drops and re-synthesis, so it would be the correct investigation if the symptom were data plane throughput loss rather than 99% management CPU.

GlobalProtect Gateway SSL VPN data tunnel encryption processing.

Why it fails: SSL VPN data tunnel encryption is processed by the data plane's session and decryption hardware, not the management plane, so it cannot drive management CPU to 99%. It is tempting because GlobalProtect is a headline firewall feature, and heavy tunnel encryption would be the right suspect if data plane throughput, not management responsiveness, were degraded.

Runtime Defense

Why it fails: Runtime Defense monitors and protects running containers from threats such as malware or suspicious processes. While it can alert on unauthorized activity, it does not prevent the deployment of unapproved images. It operates after the container is running, so it cannot enforce image admission control. Therefore, it does not meet the requirement of ensuring only approved images are deployed.

Image Scanning

Why it fails: Image Scanning analyzes container images for vulnerabilities and compliance issues. It can identify problematic images, but it does not block their deployment. Scanning is typically performed in CI/CD pipelines or registries, and the results can inform admission decisions, but by itself it does not enforce that only approved images are deployed. It is a detection mechanism, not a prevention control.

Cloud Discovery

Why it fails: Cloud Discovery identifies cloud resources and workloads across your environment. It provides visibility into what is running but does not enforce deployment policies. It cannot prevent unapproved images from being deployed; it only reports on existing resources. Therefore, it does not help in ensuring that only approved images are deployed in Kubernetes.

Cloud Infrastructure Entitlement Management (CIEM) for analyzing identity permissions.

Why it fails: CIEM specializes in managing and analyzing identity and access permissions to detect excessive privileges and entitlement risks. Although it contributes to overall cloud security, it does not perform broad configuration assessment of resources like storage or network settings. The scenario requires continuous configuration evaluation, which is beyond CIEM's identity-focused scope.

Cloud Network Security (CNS) for microsegmentation and firewall policy management.

Why it fails: Cloud Network Security provides network-level controls such as microsegmentation and firewall rule management. It does not continuously assess resource configurations against security best practices across multiple clouds. This capability is about enforcing network policies, not about posture assessment of cloud resources, so it does not satisfy the requirement.

Cloud Workload Protection Platform (CWPP) for runtime defense of virtual machines.

Why it fails: CWPP focuses on protecting running workloads, such as VMs and containers, from threats at runtime through behavioral monitoring and vulnerability management. While valuable, it does not primarily assess static cloud resource configurations against best practices. The question asks for configuration assessment, which is the domain of CSPM, not runtime workload protection.

Automated remediation of identity and access management (IAM) policies across cloud accounts.

Why it fails: While Prisma Cloud can detect overly permissive IAM policies, automated remediation is not a core function of CSPM. CSPM provides alerts and recommendations, but actual remediation often requires integration with other tools or manual action. Some platforms offer remediation, but for Prisma Cloud CSPM, it is primarily detection and reporting. This option overstates the automation capability of the CSPM module.

Runtime protection for serverless functions, including blocking malicious invocations.

Why it fails: Runtime protection for serverless functions is provided by Prisma Cloud Compute, not CSPM. CSPM focuses on configuration and posture, not runtime enforcement. While Prisma Cloud as a platform offers serverless runtime protection, it is a separate module. This option misattributes the capability to CSPM, which does not handle runtime blocking of function invocations.

Network traffic inspection and intrusion prevention for east-west traffic in Kubernetes clusters.

Why it fails: Network traffic inspection and intrusion prevention are capabilities of Prisma Cloud Compute's runtime defense, often using a Defender. CSPM does not inspect network traffic; it analyzes configurations via APIs. This option confuses the CSPM module with the Compute module, which handles runtime security. CSPM is not designed for inline traffic analysis or IPS.

A Prisma Access remote network connection for each cloud region

Why it fails: Prisma Access remote network connections are used to connect branch or data center networks to the Prisma Access security platform for traffic inspection. They are unrelated to onboarding cloud accounts for CSPM posture scanning. CSPM requires API-level access and account registration, not a remote network tunnel, so this option does not fulfill any onboarding requirement for cloud configuration assessment.

A Prisma Cloud Compute Defender deployed on every virtual machine in each cloud account

Why it fails: Defenders are used for workload and host protection with Prisma Cloud Compute, not for CSPM posture scanning of cloud resources. CSPM ingests cloud provider APIs directly and does not require an agent on each virtual machine. Deploying Defenders everywhere would add operational overhead without enabling the configuration checks that posture management performs against cloud service APIs.

An inline forward proxy in each virtual network to capture east-west traffic

Why it fails: CSPM evaluates cloud resource configurations through provider APIs and does not depend on capturing network traffic between workloads. An inline forward proxy is relevant to traffic inspection use cases, not to posture assessment of storage, identity, or network configuration. Adding proxies in every virtual network would not contribute to the required CSPM onboarding and would complicate the environment unnecessarily.