Select Two (Multi-Select) Questions

Removing all user access controls to streamline internal developer productivity.

Why it fails: Removing access controls eliminates least-privilege enforcement, so risk assessment cannot bound exposure or attribute actions to identities. It is tempting because developer friction and slow provisioning are genuine productivity problems, but those are solved through role-based access and just-in-time elevation, not abolition of controls.

Permanently disabling all logging to prevent log storage overflow on SIEM disks.

Why it fails: Disabling logging destroys the telemetry that threat detection and forensic investigation depend on, directly undermining the programme. It is tempting because SIEM storage exhaustion is a real operational concern, but the correct remedy is retention policies, tiering or capacity expansion, not eliminating the evidence source.

Implicitly trust all traffic originating from internal network zones.

Why it fails: Zero Trust requires explicit verification of every request regardless of origin, so blanket trust for internal zones directly contradicts the model. It is tempting because perimeter-based designs historically treated the internal network as trusted, which is exactly the assumption Zero Trust was created to eliminate.

Rely solely on perimeter firewalls while leaving internal lateral traffic uninspected.

Why it fails: Zero Trust inspects all traffic, including east-west flows between internal segments, so trusting the perimeter while leaving lateral traffic uninspected directly contradicts the model. It is tempting because perimeter firewalls remain necessary for north-south control, but Zero Trust additionally requires internal segmentation and inspection of every session regardless of network location.

Create an Amazon Machine Image (AMI) backup of the instance before making changes.

Why it fails: Backing up the instance with an AMI is a good operational practice for recovery, but it does not harden the running system or reduce its attack surface. It protects against mistakes during changes, not against attackers. The question asks for actions that reduce attack surface, so a backup alone does not qualify.

Enable AWS CloudTrail to record all API calls made in the account.

Why it fails: CloudTrail records API activity for auditing and detection, but it does not reduce the attack surface of the EC2 instance. It is a monitoring control, not a preventive one. While valuable, it does not close network ports or remove unnecessary services, so it does not satisfy the goal of hardening the instance itself.

Enable detailed monitoring in Amazon CloudWatch for the instance.

Why it fails: Detailed CloudWatch monitoring provides metrics at one-minute intervals, improving visibility into performance and anomalies. It is a monitoring enhancement, not a hardening measure. It does not remove services, close ports, or patch software, so it does not reduce the attack surface the engineer is trying to shrink.

DHCP Server Scope

Why it fails: A DHCP server scope is configured on a Layer 3 interface only when the firewall itself serves addresses to clients; a routed interface needs a static IP and subnet mask instead. It is tempting because DHCP server configuration does live on Layer 3 interfaces, but only for interfaces acting as a DHCP server for a segment.

MAC Address Override

Why it fails: MAC address override is an optional setting for interfaces using DHCP or PPPoE, not a required parameter for a routed interface; the mandatory values are the zone and IP address. It is tempting because override appears in interface configuration, but it only matters when the interface obtains its address dynamically.

Virtual Wire Pair Identifier

Why it fails: A virtual wire pair identifier belongs to virtual wire interfaces, which forward traffic transparently at Layer 2 without IP addressing; a Layer 3 interface requires a zone and IP address. It is tempting because virtual wire pairs are configured on the same firewall, but they serve tap or inline Layer 2 deployments.

Deploy Prisma Cloud Compute agents on all virtual machines.

Why it fails: Compute agents are used for host and container runtime protection, not for cloud storage configuration assessment. They do not inspect cloud provider storage services. Therefore, deploying them does not contribute to detecting publicly accessible storage buckets.

Configure CloudTrail, Azure Activity Log, and GCP Audit Logs to send logs to Prisma Cloud.

Why it fails: Audit logs are used for activity monitoring and threat detection, not for configuration assessment. While they can reveal changes to bucket policies, they are not the primary mechanism for detecting misconfigurations. Prisma Cloud's Config assessment queries the cloud provider APIs directly for current configurations.

Set up a Prisma Cloud webhook to receive alerts from cloud providers.

Why it fails: Webhooks are used to send alerts out of Prisma Cloud, not to receive configuration data. They do not enable detection of misconfigured storage buckets. The detection relies on Prisma Cloud's own assessment capabilities and permissions, not on external webhooks.

Disable all policies that have not generated an alert in the last 30 days to reduce the number of active policies.

Why it fails: Disabling policies based on recent alert activity removes detection coverage for controls that may simply not have been triggered yet, which creates blind spots. It does not improve routing or prioritization of the alerts that do occur, and it can cause the organization to miss a real misconfiguration later.

Increase the scan frequency of the cloud accounts to every five minutes so that duplicate alerts are generated for each scan cycle.

Why it fails: Increasing scan frequency does not reduce low-value alerts; it can increase alert volume and create duplicate notifications for the same unresolved finding. The requirement is to filter and route alerts intelligently, not to generate more of them, so this approach works against the stated objective.

Enable auto-remediation for every high-severity policy so that all findings are fixed without human review.

Why it fails: Auto-remediation can fix some issues automatically, but enabling it for every high-severity policy in a financial environment risks unintended changes to production resources. It also does not address routing or prioritization of the remaining alerts, so it does not meet the goal of reducing low-value alerts and directing findings to owners.

The full raw packet capture of all traffic from the workstation for the past 24 hours

Why it fails: A full 24-hour packet capture is excessive, often unavailable, and would overwhelm the responder with irrelevant data. Escalation should include targeted evidence such as process trees, hashes, and C2 indicators, not bulk traffic. Volume does not substitute for relevance and can delay triage rather than accelerate it.

A list of every security tool deployed across the entire organization and their version numbers

Why it fails: An organization-wide tool inventory is not relevant to resolving a single-host malware escalation. It does not describe the incident, the affected asset, or observed behavior, so it adds noise. Escalation tickets should focus on incident-specific facts that enable action, not general environment documentation.

The analyst's personal opinion about which team member should handle the case

Why it fails: Assigning the case to a specific individual is a management decision, not technical incident context. Including a personal preference does not help the responder understand the threat or take action. Escalations should contain objective technical and asset details so the receiving team can prioritize and respond effectively.

Process ID

Why it fails: The OSPF process ID is locally significant and need not match between routers; only area ID, hello and dead intervals, authentication, and stub flags must align. It is tempting because it labels the routing instance, so engineers assume peers must share it, yet two routers with different process IDs still form a full adjacency.

Router ID

Why it fails: The router ID uniquely identifies each router within the OSPF domain, so matching values would create a conflict rather than an adjacency. It is tempting because it appears in hello packets, suggesting a shared parameter. Area ID, hello and dead timers, and authentication must match instead.

Physical datacenter environmental temperature readings

Why it fails: Endpoint agents cannot read facility HVAC sensors; Cortex XDR collects host process, file, network and registry events. Environmental monitoring belongs to building management or datacentre infrastructure tooling, so it satisfies neither behavioural analytics nor threat hunting telemetry requirements.

Monitored Wi-Fi router SSID signal strengths

Why it fails: Signal strength is a radio-layer metric gathered by wireless controllers, not endpoint telemetry. Cortex XDR agents capture process, file, network and registry activity on the host. Wi-Fi surveying would be the right tool for coverage or rogue-AP assessments, not behavioural analytics.

A full memory dump of the analyst's own triage laptop

Why it fails: The analyst's laptop is not the compromised system and contains no evidence about the attacker's actions on the affected workstation. Capturing its memory would consume time and storage without advancing the investigation. Evidence must come from the affected host or the mail path, so this artifact is irrelevant to documenting initial access or persistence.

The physical asset tag number of the compromised workstation

Why it fails: An asset tag identifies the device for inventory and chain-of-custody purposes, which is useful for documentation but does not demonstrate how the attacker got in or how the account was created. It is metadata about the asset rather than evidence of the intrusion, so it does not support the technical findings the analyst needs to record.

The workstation's current wallpaper and desktop shortcut layout

Why it fails: Desktop appearance and shortcuts are user-profile artifacts with no reliable forensic value for proving account creation or initial access. They can change for many benign reasons and are not tamper-evident. Collecting them would not substantiate either the phishing vector or the persistence mechanism, so they are not appropriate evidence for this investigation.

BGP Autonomous System Number

Why it fails: A static route entry requires destination, next-hop and interface; BGP is a dynamic routing protocol configured separately under Virtual Router BGP settings. It is tempting because BGP peerings do appear in the same Virtual Router, but an AS number is never a static route parameter.

OSPF Area ID

Why it fails: OSPF Area ID belongs to dynamic OSPF configuration, not static route entries, which need destination, next-hop and interface. Administrators may confuse the two because both live under the same Virtual Router, yet an Area ID only applies when OSPF is enabled.

FTP file transfer session on port 21

Why it fails: FTP on port 21 transfers files and provides no interactive command shell, so it cannot open a firewall CLI session. It is tempting as a familiar remote-access protocol, yet FTP is used for moving configuration or content files, not for issuing CLI commands.

Telnet connection to any data plane interface

Why it fails: Telnet is disabled by default and, where enabled, is supported only on the management interface, not data plane interfaces. It is tempting because Telnet historically provided CLI access on many devices, but on Palo Alto firewalls SSH on port 22 is the supported remote CLI method.

HTTPS web browser session on port 443

Why it fails: Port 443 serves the web management interface, which is a graphical UI, not the CLI; CLI access over the network uses SSH on port 22. HTTPS is tempting because administrators routinely manage the firewall through a browser, but that session never presents a command prompt.

Deploy Prisma Cloud Compute agents on every virtual machine in each cloud account.

Why it fails: Prisma Cloud Compute agents are used for workload protection, such as vulnerability scanning and runtime defense, not for cloud security posture management (CSPM). CSPM relies on API-based discovery of cloud resources. Deploying agents on all VMs is unnecessary for posture assessment and would add overhead without providing the configuration compliance data needed for multi-cloud monitoring.

Set up a VPN connection between each cloud environment and the Prisma Cloud console.

Why it fails: Prisma Cloud communicates with cloud provider APIs over the internet using secure HTTPS. A VPN is not required for API-based onboarding and would introduce unnecessary complexity. While VPNs might be used for other purposes, they are not part of the standard CSPM onboarding process for AWS, Azure, or GCP.

Install the Prisma Cloud app from each cloud provider's marketplace.

Why it fails: While some cloud marketplaces offer Prisma Cloud listings, they are not required for onboarding. The standard method is to create credentials and add the account directly in the Prisma Cloud console. Marketplace apps may simplify billing or deployment for certain features, but they are not a prerequisite for posture management across multiple clouds.

Embedded automotive CAN bus microcontrollers

Why it fails: Automotive CAN bus microcontrollers run bare-metal or RTOS firmware, not the Windows, macOS or Linux platforms the Cortex XDR agent supports. It tempts because connected vehicles are attack surfaces, but agent deployment requires a general-purpose OS, not embedded vehicle control microcontrollers.

Commercial airliner avionics flight control firmware

Why it fails: Cortex XDR agent installs on general-purpose endpoint operating systems such as Windows, macOS and Linux, not avionics flight control firmware, which is safety-certified real-time software. It tempts because aviation systems are computing platforms, but agent deployment targets workstations and servers, not aircraft control firmware.

Consumer smart refrigerator operating systems

Why it fails: Consumer smart refrigerator operating systems are embedded appliance platforms, not supported endpoint OSes for the Cortex XDR agent, which targets Windows, macOS and Linux. It tempts because IoT devices run software and can be attacked, but agent support covers managed endpoints, not appliance firmware.

Disable the Malware, Exploit, and Behavioral Threat Protection modules entirely on the server policy

Why it fails: Turning off all prevention modules removes protection against genuine threats and directly contradicts the goal of reducing false positives without disabling protection. A blanket module shutdown also creates a wide gap that attackers can exploit on a high-value server. The correct approach is targeted exclusions, not disabling the detection engines that protect the rest of the workload.

Set the agent to Report mode for all modules so detections are logged but nothing is blocked

Why it fails: Report mode converts the whole policy to monitoring and stops blocking malicious activity on the server. While it would eliminate false-positive blocking, it also eliminates prevention, which the administrator explicitly wants to keep. Report mode is a troubleshooting step, not a targeted tuning action, and it applies far too broadly for this scenario.

Lower the agent's scan schedule frequency so temporary files are only scanned once per day

Why it fails: Scan scheduling affects when scheduled scans run, not how real-time behavioral or malware engines evaluate activity during batch jobs. The false positives described occur in real time as the application writes files and spawns children, so changing the scan cadence would not stop those detections. Scheduling is also not a supported mechanism for tuning behavioral false positives.

Broadcasting the installation package over commercial FM radio frequencies.

Why it fails: FM radio carries analogue audio, not MSI packages, and offers no addressing, authentication or delivery confirmation to Windows endpoints. Radio broadcast suits one-to-many audio distribution, such as emergency announcements, not software deployment. Enterprise rollout requires management channels like SCCM, Intune or GPO.

Injecting the MSI payload via unauthenticated network printer port scans.

Why it fails: Printer port scans cannot deliver or execute an MSI; they merely probe TCP ports, and unauthenticated injection is not a supported deployment mechanism. Port scanning belongs in vulnerability discovery or exposure assessment. Agent rollout requires authenticated, managed channels such as Intune, SCCM or GPO.

Store application service principal secrets in plaintext in a public repository

Why it fails: Placing service principal secrets in a public repository exposes them to anyone, enabling immediate unauthorized access. This practice dramatically increases the impact of a compromise and violates secret management best practices, so it cannot be part of a hardening strategy.

Assign the Owner role at the subscription scope to all developers

Why it fails: Granting the Owner role at subscription scope gives broad control over resources and access, violating least privilege. If any developer account is compromised, the attacker inherits full control of the subscription, which increases rather than reduces the impact of a compromised account.

Disable Microsoft Entra ID security defaults for the tenant

Why it fails: Security defaults provide baseline protections such as requiring multifactor authentication for administrators and blocking legacy authentication. Turning them off removes those safeguards and weakens the tenant, which conflicts with the goal of limiting the impact of compromised accounts.

Device Control

Why it fails: Device Control manages peripheral devices like USB drives and printers. It does not monitor process creation or memory writes, so it would not generate alerts for these actions. This module is unrelated to the described attack behaviors.

Disk Encryption

Why it fails: Disk Encryption is not a Cortex XDR agent module; Cortex XDR focuses on endpoint detection and response, not full disk encryption. This option is a distractor and does not correspond to a feature that would alert on process behavior or memory writes. It is not a valid module in this context.

Malware Protection

Why it fails: Malware Protection scans files for known malicious signatures and reputation. While it might detect a malicious file if one was involved, the described actions are behavioral and memory-based, not file-based. It is less likely to alert on the process creation and memory write alone without a file indicator.

It enforces network microsegmentation between workloads based on their identity labels.

Why it fails: Network microsegmentation is a workload protection capability, not part of CIEM. CIEM focuses on identity and permission analysis, not on controlling network flows between workloads. Confusing the two would lead the team to expect segmentation features that CIEM does not deliver.

It scans container images for known vulnerabilities and generates fix recommendations.

Why it fails: Container image vulnerability scanning is a workload protection function in Prisma Cloud Compute, not a CIEM capability. CIEM analyzes permissions and entitlements for human and machine identities. Selecting this option mistakes image scanning for entitlement management, which would not help identify excessive permissions.

It automatically rotates all access keys and secrets for every identity in the cloud environment.

Why it fails: Prisma Cloud does not automatically rotate credentials as part of CIEM. Credential rotation is a separate operational task often handled by secrets managers or IAM best practices. Presenting CIEM as an automatic key rotator misstates its function, which is analyzing and right-sizing entitlements.

Configure a Decryption policy to inspect all SSL VPN traffic for threats.

Why it fails: While decryption can be used to inspect traffic for threats, it is not required to enable user authentication or ensure authorized access. GlobalProtect SSL VPN traffic is already encrypted between the client and the firewall, and decryption is typically applied to outbound traffic to the internet, not to VPN tunnels. This configuration is unrelated to the authentication and authorization requirements.

Set up a GlobalProtect portal and gateway with client certificate authentication only.

Why it fails: Configuring client certificate authentication only would not allow for user credential validation via LDAP or other user directories. While certificates can be part of authentication, the scenario specifically requires user authentication, which typically involves username and password or multi-factor authentication. Using only client certificates would not integrate with user directories to enforce group-based policies, failing the authorization requirement.

Enable User-ID on the internal zone to map IP addresses to usernames.

Why it fails: User-ID is used to map IP addresses to users for policy enforcement, but it is not a requirement for GlobalProtect authentication. GlobalProtect itself authenticates users and can pass user information to the firewall for policy matching. Enabling User-ID on the internal zone might be useful for other policies, but it is not necessary to enable authentication and authorized access for remote users via GlobalProtect.