Cloud Security practice questions

Prisma Access Remote Networks Plugin

Why it fails: Incorrect. This is used for connecting branch offices, not as a standalone threat prevention service.

GlobalProtect App Standalone

Why it fails: Incorrect. GlobalProtect is a VPN client for endpoint connectivity.

Panorama Log Collector

Why it fails: Incorrect. Log collectors are used for storing and indexing logs, not threat prevention.

Establish a direct Google Interconnect circuit terminated directly into the Panorama management appliance.

Why it fails: Incorrect. Panorama does not terminate Interconnect circuits or process data plane traffic.

Configure GCP Cloud NAT to forward raw packet captures to the Prisma Access SaaS API endpoint.

Why it fails: Incorrect. Cloud NAT translates IP addresses; it does not forward packet captures to security services.

Install the VM-Series firewall as a native GCP HTTP(S) Load Balancer backend instance group.

Why it fails: Incorrect. VM-Series firewalls operate at Layer 3/4 and cannot function as native GCP HTTP(S) load balancer backends.

The query must include the AWS account ID prefix inside single quotes for every condition.

Why it fails: Incorrect. Account IDs are not required inline in basic resource queries unless filtering explicitly by account.

The query is missing the `event.name` parameter required for cloud storage inspection.

Why it fails: Incorrect. `event.name` is used for audit event queries, not configuration state queries.

RQL queries can only be executed against Azure and GCP resources, not AWS.

Why it fails: Incorrect. Prisma Cloud fully supports AWS resource querying in RQL.

Deploy Panorama as a sidecar container inside every Kubernetes pod namespace.

Why it fails: Incorrect. Panorama is a management server and cannot run as a sidecar container inside pods.

Attach the Prisma Access remote network VPN gateway directly to the Kubernetes cgroup filesystem.

Why it fails: Incorrect. Prisma Access remote network gateways connect branch offices, not internal Kubernetes pods.

Configure AWS Route 53 to proxy all TCP traffic between pods.

Why it fails: Incorrect. Route 53 is a DNS service and cannot proxy raw TCP pod-to-pod traffic.

Configure GCP Secret Manager to inject floating MAC addresses into the management interface.

Why it fails: Secret Manager injects secrets, not floating MAC addresses, and MAC addresses play no part in Panorama licence delivery. It is tempting because Secret Manager is the correct GCP service for storing credentials, and it would suit securely distributing bootstrap credentials to firewall instances.

Connect each VM-Series firewall directly to an on-premises hardware License Key Server (LKS) via a dedicated VPN.

Why it fails: An on-premises LKS serves hardware firewalls and cannot issue consumption or credit-based licences to GCP VM-Series instances. It is tempting because a centralised licence server is the traditional model, and an LKS would be correct for managing licences across on-premises PA-Series appliances.

Manually upload a permanent .lic license file via SSH to every autosscaled GCP instance upon boot.

Why it fails: Manual .lic uploads are per-instance and static, so autoscaled instances cannot obtain licences dynamically from Panorama. It is tempting because permanent licence files are the standard activation method for standalone VM-Series deployments not managed by Panorama.

BGP dynamic routing session establishment with external Azure ExpressRoute circuits.

Why it fails: Incorrect. BGP routing is handled by network firewalls or gateways, not container workload defenders.

Automatic remediation of AWS IAM user policy attachments via automated CLI execution.

Why it fails: Incorrect. IAM policy remediation is a CSPM function, not a container workload Compute Defender function.

Enable transparent proxy mode on the VM-Series trust interface using Generic Routing Encapsulation (GRE).

Why it fails: Incorrect. GRE tunnels are used for remote networks, not explicit client proxies.

Configure AWS Route 53 resolver rules to forward proxy requests to WildFire.

Why it fails: Incorrect. Route 53 resolver handles DNS resolution, not explicit web proxying.

Deploy an Apache Squid proxy server inside an AWS VPC and peer it with Panorama.

Why it fails: Incorrect. Squid proxy is not a Prisma Access component.

Physical USB smartcard hardware serial number validation via local PAN-OS USB ports on user laptops.

Why it fails: Incorrect. Laptops connect via GlobalProtect software; USB smartcards integrate through OS certificate stores, not firewall USB ports.

Plaintext HTTP Basic Authentication embedded in URL parameters.

Why it fails: Incorrect. Plaintext HTTP Basic Authentication is insecure and not supported for GlobalProtect.

Static MAC address whitelisting on enterprise Wi-Fi routers.

Why it fails: Incorrect. Wi-Fi MAC whitelisting is a wireless LAN controller function, not a GlobalProtect authentication method.

AWS Direct Connect dedicated fiber optic circuits connected directly to the Kubernetes kubelet process.

Why it fails: Incorrect. Direct Connect is for hybrid cloud WAN connectivity, not container internal steering.

Dedicated physical rackmount chassis with hardware FPGA accelerator cards installed in the Kubernetes master node.

Why it fails: Incorrect. CN-Series is purely software-based and does not use physical FPGA cards.

A site-to-site VPN between AWS and Google Cloud, with AWS IAM roles mapped to Google Cloud IAM roles via LDAP synchronization.

Why it fails: A VPN secures data in transit but does not address identity management or least-privilege access. Mapping IAM roles via LDAP is not a native cross-cloud federation method; Google Cloud IAM does not integrate with LDAP for role mapping. This adds complexity and does not provide the short-lived credential benefits of Workload Identity Federation, leaving static credentials or broad network access as potential weaknesses.

AWS Cognito user pools with Google Cloud Identity Platform, using OAuth 2.0 tokens for direct access to Cloud Storage.

Why it fails: AWS Cognito and Google Cloud Identity Platform are customer identity solutions, not designed for machine-to-machine workload authentication. OAuth 2.0 tokens from these services are not directly accepted by Google Cloud IAM for service account impersonation. This approach would require custom token exchange and might not enforce least-privilege access to Cloud Storage, as the tokens would need to be mapped to IAM roles manually.

AWS IAM users with programmatic access keys stored in AWS Secrets Manager, and Google Cloud IAM policies granting access to those keys.

Why it fails: This approach relies on long-lived AWS access keys, which are a security risk if leaked or mismanaged. Storing keys in Secrets Manager does not eliminate the need for rotation and does not provide cross-cloud identity federation. Google Cloud IAM cannot directly grant access based on AWS keys; it would require custom token exchange, which is not natively supported. This violates least-privilege and centralized identity management goals.

Amazon GuardDuty EKS Protection

Why it fails: Amazon GuardDuty EKS Protection analyzes Kubernetes audit logs to detect suspicious activity, but it does not provide runtime monitoring of process execution or network connections within containers. It also does not have the capability to automatically block malicious activities; it only generates findings. Therefore, it cannot fulfill the requirement for runtime detection and automated response at the container level.

Falco with a Kubernetes admission controller and eBPF

Why it fails: Falco is a runtime security tool that can detect anomalous activity using system calls, but it does not natively block or prevent malicious actions. While it can be integrated with admission controllers to prevent deployment of risky workloads, it lacks built-in blocking of runtime process execution. Additional components like a response engine would be needed to achieve automatic blocking, making it incomplete for the stated requirement.

AWS Security Hub with Amazon Detective

Why it fails: AWS Security Hub aggregates findings from various AWS services and third-party tools, and Amazon Detective helps investigate security issues. Neither provides runtime monitoring within Kubernetes pods nor the ability to block malicious activities in real time. They are primarily for posture management and investigation, not for active runtime protection and automated response in containerized environments.

Cloud NGFW for AWS in a distributed model with a firewall endpoint in each subnet

Why it fails: A distributed model with per-subnet endpoints would require creating and managing multiple firewall endpoints and could still necessitate route table updates for traffic redirection. This increases complexity and does not meet the requirement to avoid route table modifications. It is better suited for granular control but not for the stated constraint of minimal changes.

Cloud NGFW for AWS in a centralized VPC with Gateway Load Balancer endpoint

Why it fails: This model requires route table changes to redirect traffic through the Gateway Load Balancer endpoint, which the team wants to avoid. It also involves managing a centralized VPC and endpoint configuration, adding operational overhead. The scenario explicitly states that the team does not want to modify existing subnet route tables, so this deployment model is not appropriate.

Cloud NGFW for AWS integrated with AWS Firewall Manager and a VPC ingress routing table

Why it fails: While Firewall Manager can help manage policies, using a VPC ingress routing table still involves modifying route tables to steer traffic to the firewall. This contradicts the team's requirement to avoid such changes. Firewall Manager alone does not provide traffic inspection without routing adjustments, so this option does not satisfy the scenario.

Deploy an AWS Transit Gateway and attach the VPC to it, then route all traffic through the Transit Gateway.

Why it fails: Transit Gateway simplifies connectivity between VPCs and on-premises but does not inherently force traffic through a specific firewall ENI. It can be used with a firewall, but additional routing and attachment configurations are needed. It does not satisfy the single ENI requirement or guarantee return traffic symmetry by itself. This option adds complexity without addressing the core need.

Create a NAT gateway in the public subnet and route all outbound traffic through it.

Why it fails: A NAT gateway provides internet access for private subnets but does not ensure symmetric traffic flow through the VM-Series firewall. It also introduces an additional hop that could bypass inspection. The requirement is to force traffic through the firewall and maintain session symmetry, which NAT gateway alone cannot guarantee. This option does not address the single ENI constraint or return path.

Use an AWS Gateway Load Balancer with a Gateway Load Balancer endpoint in the VPC.

Why it fails: Gateway Load Balancer is designed for transparent inspection using GENEVE encapsulation and requires multiple ENIs for scaling. It does not meet the single ENI requirement. While it provides symmetric flow, the scenario explicitly states a single elastic network interface, making this option invalid. It is a valid architecture but not for this specific constraint.

Prisma Cloud Compute Console

Why it fails: The Prisma Cloud Compute Console provides the web UI and API for managing policies and viewing alerts, but it does not natively listen for syslog traffic from external sources like NSX-T. Syslog ingestion requires a dedicated component that normalizes and forwards logs to the Console, so configuring the Console itself as a syslog receiver will not work.

Prisma Cloud Compute Cloud Controller

Why it fails: The Cloud Controller is a Prisma Cloud Compute component that manages communication between the Console and Defenders in cloud environments, but it does not receive or process syslog messages from external network devices. Its primary role is orchestration and secure tunneling, not log ingestion, so it cannot fulfill the requirement of receiving NSX-T syslog traffic.

Prisma Cloud Compute Defender

Why it fails: Defenders are lightweight agents deployed on hosts, containers, or serverless functions to enforce runtime policies and collect telemetry. They do not accept inbound syslog streams from third-party network devices. While Defenders forward data to the Console, they are not designed to act as syslog receivers for external sources such as NSX-T.

Configure a Cloud Audit Logs sink to export logs to a Pub/Sub topic and grant Prisma Cloud access to the topic

Why it fails: Cloud Audit Logs provide activity logs, not configuration state. While useful for monitoring API activity, this method does not enable Prisma Cloud to assess resource configurations or detect misconfigurations across projects. It also requires per-project setup unless done at the organization level, but it still lacks the configuration assessment capability needed for CSPM.

Add each GCP project individually using a service account with Viewer role

Why it fails: Adding each project individually requires manual effort and will not automatically include future projects. This approach is error-prone and does not scale. The administrator wants to avoid manually adding each project, so this method fails to meet the requirement. It also does not provide organization-wide visibility, as new projects would need to be added separately.

Deploy a Prisma Cloud Compute Defender in each GCP project and use the console to aggregate findings

Why it fails: Prisma Cloud Compute Defenders are used for workload protection, not for configuration posture management of GCP projects. While they can provide runtime visibility, they do not automatically discover projects or assess cloud resource configurations. This approach would require manual deployment per project and does not address the need for organization-wide misconfiguration detection.

Quality of Service (QoS)

Why it fails: QoS is used to prioritize network traffic to ensure critical applications get bandwidth. It does not bypass security inspection; it only manages bandwidth allocation. While QoS can improve performance for SaaS applications by prioritizing their traffic, it does not exempt them from security inspection. Therefore, it does not achieve the goal of bypassing inspection for specific SaaS apps.

SSL Decryption with Exemptions

Why it fails: SSL Decryption with Exemptions allows you to exclude certain traffic from decryption, but it does not necessarily bypass all security inspection. Even if decryption is bypassed, other security profiles might still apply. The goal is to bypass inspection entirely for specific SaaS apps. SSL Decryption exemptions are typically used for privacy or compliance, not for performance optimization of SaaS traffic.

App-ID with Security Policy

Why it fails: App-ID identifies applications and can be used in security policies to allow or deny traffic. However, using App-ID alone would not bypass inspection for specific SaaS applications; it would still subject them to security profiles unless a separate policy is created. The requirement is to bypass inspection, not just identify the application. Therefore, App-ID is not the specific feature that enables bypass.

Custom Policy with RQL

Why it fails: Custom policies using Resource Query Language (RQL) can detect S3 buckets that are not encrypted with KMS CMKs, but they are primarily for detection and alerting. They do not enforce or remediate the configuration. While you could create an alert, the requirement is to prevent encryption from being disabled, which requires an enforcement mechanism beyond detection.

Prisma Cloud Compute Runtime Defense

Why it fails: Prisma Cloud Compute Runtime Defense protects containerized workloads and serverless functions by monitoring runtime behavior, not cloud storage configurations. It cannot enforce S3 bucket encryption settings or KMS key usage. This feature is irrelevant to the scenario, as it focuses on workload protection rather than cloud infrastructure configuration compliance.

Config Compliance Standard

Why it fails: A Config Compliance Standard in Prisma Cloud allows you to group and evaluate policies against regulatory frameworks, but it does not enforce or remediate configurations. It provides a dashboard of compliance status. While useful for auditing S3 encryption, it cannot prevent the disabling of encryption or automatically enforce KMS CMK usage, so it does not meet the continuous enforcement requirement.

Enable Application Override for the SaaS application to skip content inspection

Why it fails: Application Override is used to force traffic to be identified as a specific application, but it does not skip content inspection. Security profiles attached to the rule still apply. While it can help with correct application identification, it does not bypass inspection. The latency issue would persist if security profiles are still active.

Create a decryption bypass policy for the SaaS application's domain

Why it fails: A decryption bypass policy prevents SSL decryption but does not bypass other security inspections like antivirus, anti-spyware, or URL filtering. Those services still process the traffic and can add latency. The requirement is to bypass inspection entirely, not just decryption. Therefore, this policy alone does not meet the need to avoid latency from security processing.

Add the SaaS application to the SSL Decryption Exclusion list

Why it fails: The SSL Decryption Exclusion list prevents decryption for specified domains, but other security inspections that do not require decryption (like URL filtering based on SNI) may still occur. More importantly, if the traffic is not decrypted, some security profiles cannot inspect it, but the firewall still processes the connection. This does not guarantee a complete bypass of all inspection and may not resolve latency.

Prisma Access URL Filtering

Why it fails: URL Filtering categorizes websites and allows or blocks based on URL categories. It can block access to a SaaS application but cannot inspect the traffic for DLP or prevent data exfiltration within the application. It also cannot enforce inspection if the application uses non-HTTP protocols. Therefore, it does not meet the requirement for DLP inspection and bypass prevention.

GlobalProtect App Configuration

Why it fails: GlobalProtect App Configuration allows you to enforce settings on the endpoint, such as always-on VPN or split tunneling. However, it does not directly inspect SaaS traffic for DLP or prevent protocol bypass. While it can ensure traffic is routed through Prisma Access, additional security policies are needed to perform DLP inspection and block non-compliant traffic.

Prisma Access Explicit Proxy

Why it fails: Explicit Proxy requires client configuration to send traffic to a proxy, which can be bypassed if users change settings or use applications that ignore proxy settings. It does not provide the same level of enforcement as SaaS Inline, which operates transparently. While explicit proxy can inspect web traffic, it is not as robust for SaaS applications and can be circumvented.

Inside the customer-managed AWS Transit Gateway associated with the remote network.

Why it fails: A customer-managed AWS Transit Gateway only routes packets between networks; it performs no security inspection, so branch-to-branch traffic would pass uninspected. It is tempting because Transit Gateway is the correct hub for connecting remote networks, and would be the right answer if the question asked where traffic is routed rather than inspected.

On the Panorama management server located in the customer's primary datacenter.

Why it fails: Panorama is a management plane for policy configuration and logging, not a data-plane device, so it cannot inspect transit traffic. It is tempting because Panorama centrally administers Prisma Access security rules, and would be the right answer if the question concerned where policies are authored rather than where packets are examined.

On the local physical firewall at the originating branch office before it leaves the LAN.

Why it fails: Local branch firewalls inspect traffic entering or leaving the LAN, not Prisma Access branch-to-branch flows, which traverse the provider's cloud. It is tempting because on-premises firewalls are the traditional inspection point, and would be correct for traffic destined to the internet rather than between branches.