Prisma Cloud Architecture And Components practice questions

Google Cloud Identity and Access Management (IAM) Admin API

Why it fails: While IAM is used for permissions, resource inventory discovery primarily depends on the Cloud Asset and Resource Manager APIs.

Google Cloud Kubernetes Engine API only

Why it fails: Enabling only GKE API would limit asset discovery exclusively to container clusters, ignoring IAM, storage, and compute instances.

Google Cloud Billing Budgets API

Why it fails: Billing APIs are used for cost management, not cloud security posture inventory discovery.

Enable AWS Direct Connect bypass rules to route Defender management traffic over private virtual interfaces.

Why it fails: Direct Connect links on-premises or cloud VPCs to AWS, but does not inherently solve outbound reachability to a SaaS console without proxy configuration.

Switch the Defender architecture to agentless scanning mode which does not require any network connectivity.

Why it fails: Agentless scanning relies on snapshot analysis performed by cloud-native infrastructure APIs, but Compute Defenders specifically require network connectivity to enforce runtime protection.

Configure the Defender container with local storage caching to store scan results indefinitely until manually exported.

Why it fails: Defenders require continuous connectivity to stream telemetry and vulnerability data to the console.

Raw container binary memory dumps captured during kernel panics

Why it fails: Memory dumps are not ingested by CSPM for posture management.

Local enterprise Active Directory domain controller database files (NTDS.dit)

Why it fails: On-premises Active Directory database files are not ingested by cloud-native CSPM.

Execute ad-hoc Resource Query Language (RQL) queries across asset inventories

Why it fails: RQL queries are executed in the Investigate module, not the Settings menu.

Define container runtime defense policies and process allowlists

Why it fails: Container runtime policies are configured in the Compute module (Compute > Defend), not general Settings.

Physical network cable link speed and duplex settings on the hypervisor switch

Why it fails: Physical switch link speeds do not affect logical WebSocket tunnel establishment.

Local database schema version of the Microsoft SQL Server backing the local VM

Why it fails: Compute Defenders do not interact directly with external SQL databases.

Manually create the PrismaCloudApp role in every member account using the AWS Console.

Why it fails: Incorrect. Manual creation defeats the purpose of StackSets and does not scale for large AWS organizations.

Modify the Prisma Cloud onboarding wizard to use the CFT-Local deployment method instead.

Why it fails: Incorrect. CFT-Local is for single-account onboarding and does not utilize StackSets.

Regenerate the Prisma Cloud API access keys and update the CloudFormation template parameters.

Why it fails: Incorrect. API keys are not used by the CloudFormation stack template during initial AWS IAM role provisioning.

event where cloud.type = 'aws' and operation = 'PutBucketAcl' and public = true

Why it fails: Incorrect. The 'event' collection queries audit logs rather than current resource configurations.

network where source.public = true and destination.service = 'S3'

Why it fails: Incorrect. Network traffic queries do not inspect S3 bucket configuration parameters.

vulnerability where resource.type = 'AWS S3 Bucket' and severity = 'high'

Why it fails: Incorrect. Vulnerability queries are used for software packages and CVEs, not configuration settings.

Local MongoDB database cluster (required for customer-managed tenant storage)

Why it fails: Prisma Cloud Enterprise Edition is a SaaS platform; its three components are the tenant console, the compute/defender agents, and the cloud-native data store managed by Palo Alto Networks. Requiring customers to run a local MongoDB cluster contradicts the SaaS delivery model. It would suit a self-hosted deployment where data residency mandates customer-controlled storage.

Prisma Cloud Hardware Appliance (on-premises physical proxy)

Why it fails: Prisma Cloud Enterprise Edition is delivered as a cloud-hosted SaaS platform with no on-premises hardware component; its three parts are the web console, defender agents, and the vendor-managed backend. A physical proxy appliance belongs to inline on-premises inspection architectures, not agentless cloud API-based security posture management.

Microsoft Exchange SMTP mail relay

Why it fails: Prisma Cloud's native email channel sends through its own mail service, not a customer-configured Exchange relay, so an SMTP relay is not an out-of-the-box integration. It is tempting because email alerting is natively supported, and relaying through Exchange would be correct where outbound mail must traverse an internal server.

Local Syslog server via proprietary TCP framing

Why it fails: Prisma Cloud's syslog integration emits standard RFC-formatted messages to a listener; it does not use proprietary TCP framing, so such a server is not natively supported. It is tempting because syslog forwarding is a genuine native channel, and a proprietary-framed collector would be correct for a bespoke SIEM ingestion pipeline.

Prisma Cloud Compute Defender DaemonSet

Why it fails: The Defender DaemonSet is designed specifically for Kubernetes clusters, where it deploys one Defender pod per node to protect containers and the node itself. It is not intended for standalone EC2 instances outside a Kubernetes environment. Using it on non-Kubernetes EC2 instances is unsupported and would not provide the required host-based protection.

Prisma Cloud Compute Console

Why it fails: The Console is the central management interface for Prisma Cloud Compute, providing policy configuration, visibility, and reporting. It does not run on individual hosts to enforce runtime protection. Deploying only the Console would leave the EC2 instances without a local enforcement agent, so host-based vulnerability and runtime defense would not be available.

Prisma Cloud Compute Cloud Discovery

Why it fails: Cloud Discovery is a Prisma Cloud Compute feature that scans cloud accounts to identify unmanaged hosts and containers, providing visibility but not enforcement. It does not install an agent or enforce runtime policies. Relying on Cloud Discovery alone would leave the EC2 instances unprotected; it is a discovery tool, not a protection component.

Manually install the Defender on each EC2 instance using a user-data script that pulls the image from ECR and configures a cron job for updates.

Why it fails: Manual installation via user-data and cron jobs is error-prone and does not leverage Prisma Cloud's native management capabilities. It would require custom scripting for updates and lacks centralized control. This approach does not satisfy the requirement for automatic updates managed by Prisma Cloud and is not the recommended method.

Deploy the Defender using the Prisma Cloud Compute Console's 'Deploy Defenders' wizard with the 'Docker' option, specifying the private ECR image URL and enabling auto-update.

Why it fails: The Docker deployment option in the Defender wizard is designed for standalone Docker hosts, not for orchestrating across an EC2 fleet. It does not provide a mechanism for automated updates across many instances, and you would still need to manually run the container on each host. This fails the requirement for fleet-wide automated management.

Use the Prisma Cloud Compute 'Defender as a DaemonSet' deployment for Kubernetes, referencing the private ECR image and setting the auto-update flag.

Why it fails: DaemonSet deployment is specific to Kubernetes clusters, not standalone EC2 instances. While it supports private registries and auto-update, it cannot be applied to non-Kubernetes EC2 hosts. The scenario does not mention Kubernetes, so this method is inapplicable and would not cover the fleet.

TCP 443

Why it fails: TCP 443 is typically used for HTTPS web access to the Console UI, not for Defender-Console communication. While some components may use 443 for secure API calls, the Defenders use a dedicated port for their connection. Thus, 443 is not the required port for Defender-to-Console traffic.

TCP 8081

Why it fails: TCP 8081 is used by the Console for its internal communication and is not the port that Defenders use to connect. Defenders connect to the Console on a different port. Therefore, opening 8081 is not necessary for Defender-Console communication.

TCP 8083

Why it fails: TCP 8083 is used by the Defender to communicate with the Console for management and intelligence updates, but it is not the primary port for Defender-to-Console communication. The primary communication uses a different port. Therefore, this is not one of the required ports.

Custom Compliance Standards with built-in RBAC overrides

Why it fails: Custom Compliance Standards define which checks run; RBAC overrides control who may view or edit them, not which accounts a report covers. They are tempting because both features shape reporting, but restricting report scope to Finance accounts requires an account group or resource list.

Alert Rules tied exclusively to user email domains

Why it fails: Alert Rules trigger notifications on audit events; they neither scope report data nor filter accounts by business unit. They are tempting because alerting is genuinely used for per-team notification routing, but report scoping requires account groups, which is what the Finance business unit needs here.

Saved Views within the Inventory module

Why it fails: Saved Views filter what appears in the Inventory module for a user; they do not scope the account set that compliance reports evaluate. They are tempting because they provide per-user filtering, but report scoping requires a resource list or account group bound to the Finance accounts.

Separate Prisma Cloud Consoles with different root passwords.

Why it fails: Separate consoles with distinct root passwords create parallel deployments, not scoped visibility within one tenant; users still lack role-based resource boundaries and administration fragments. It is tempting because separate instances genuinely suit wholly independent business units with no shared inventory, which is not this requirement.

IP Whitelisting rules applied to the Identity Provider (IdP) integration.

Why it fails: IP whitelisting restricts which source networks can authenticate to Prisma Cloud; it does not partition data visibility, so APAC users on permitted addresses still see EMEA posture. It is genuinely used to harden IdP access by trusted corporate ranges, which is an authentication control, not an authorisation boundary.

Resource tagging policies enforced via AWS Organizations SCPs.

Why it fails: SCPs govern which AWS API actions accounts may perform; they cannot filter Prisma Cloud's own console views, so EMEA posture remains visible to APAC users. Tagging policies are genuinely for enforcing resource metadata and guardrails across AWS accounts, not for scoping a security platform's UI.

Generate an API Access Key in the logging account and hardcode it into the AWS CloudFormation template parameters.

Why it fails: Prisma Cloud onboarding uses cross-account IAM roles, not long-lived access keys; hardcoding credentials in a template exposes them and breaks the assumed-role model. API keys suit programmatic access to the Prisma Cloud API itself, not AWS account onboarding.

Install a Compute Defender on the EC2 instance hosting the S3 bucket.

Why it fails: S3 is a managed object storage service and cannot host compute defenders.

Enable VPC Flow Logs to replicate directly to the Prisma Cloud Console public IP address.

Why it fails: VPC Flow Logs capture network traffic metadata and cannot be delivered to an external console IP; CloudTrail monitoring needs S3 bucket access instead. Flow Logs would be relevant when analysing network-level traffic within a VPC.

Manual throttling intervals configured per subscription in the Prisma Cloud System settings.

Why it fails: Prisma Cloud does not rely on manually configured per-subscription throttling intervals; it manages Azure API rate limits automatically through adaptive mechanisms. It is tempting because manual throttling settings exist in some platforms, and would be correct where an administrator must cap request rates for a specific tenant or integration.

Delegating all asset discovery requests to an external Azure Event Grid subscription.

Why it fails: Azure Event Grid is an event-routing service, not an asset-discovery delegation mechanism, and Prisma Cloud does not outsource discovery to an external Event Grid subscription. It is tempting because Event Grid genuinely suits reactive, event-driven architectures, and would be correct for triggering workflows on Azure resource-change events.

Deploying a local proxy instance inside an Azure Virtual Network to cache API responses.

Why it fails: A local proxy caching API responses is not how Prisma Cloud manages Azure throttling; it adds infrastructure without addressing request-rate governance. It is tempting because caching reduces repeated calls, and would be correct where read-heavy workloads repeatedly fetch identical data and latency reduction, not rate-limit compliance, is the goal.

Attach the Prisma Cloud Serverless Defender layer to the Kubernetes API server deployment.

Why it fails: The Serverless Defender layer instruments AWS Lambda functions, not Kubernetes nodes, so it cannot place a Defender on every EKS node. It is tempting because it is a genuine Prisma Cloud Defender deployment method, and would be correct when protecting serverless functions running outside a cluster.

Deploy the Defender as a Kubernetes Deployment object with replica count set to 3.

Why it fails: A Deployment with three replicas schedules pods on three arbitrary nodes, leaving remaining nodes unmonitored; it also lacks the node-level tolerations and host access a DaemonSet provides. DaemonSets exist precisely to guarantee one Defender pod per node, which is what cluster-wide host monitoring on EKS demands.

Install the Prisma Cloud Enterprise Edition agent via AWS Systems Manager directly onto the worker node OS.

Why it fails: Systems Manager installs the agent on individual node operating systems, giving no DaemonSet controller to schedule and maintain a Defender pod on every node automatically. It is tempting because it targets hosts directly, and would be correct for standalone EC2 instances outside Kubernetes orchestration.

Administration > Cloud Accounts > Credentials

Why it fails: Cloud Accounts > Credentials stores cloud provider access keys and secrets for onboarding accounts, not Prisma Cloud API access keys for CI/CD. It is tempting because the word credentials suggests key management, and this is the correct location when adding an AWS or Azure cloud account rather than generating a console API key.

Risks > Policies > Integrations

Why it fails: Risks > Policies > Integrations configures outbound integrations such as webhooks and ticketing, not Prisma Cloud API access keys. It is tempting because integrations imply programmatic connectivity, and this is the correct area when wiring policy alerts into an external system rather than authenticating to the Prisma Cloud API.

Compute > Defend > Access Control

Why it fails: Compute > Defend > Access Control manages container and host runtime access rules, not API credentials. It is tempting because access control sounds like key management, and this is the correct location when defining runtime protection policies for workloads rather than issuing an API access key for pipeline authentication.

Add the Slack API token directly into the AWS CloudFormation onboarding template.

Why it fails: Embedding a Slack API token in a CloudFormation onboarding template exposes the credential in plaintext infrastructure code and creates no notification rule. It is tempting because onboarding templates already carry configuration, but Slack integration belongs in Prisma Cloud's alert rules and integrations settings. Templates would be correct for provisioning cloud accounts, not routing alerts.

Go to Compute > Defend > Runtime and select Slack Webhook as the enforcement action.

Why it fails: Runtime enforcement actions block or alert on running workloads; they do not deliver notifications to Slack. Slack delivery requires an alert rule with a Slack integration configured under Settings > Integrations, then a notification template. Runtime Defend is tempting because it handles policy violations, but its actions are prevent/alert within Compute, not external messaging.

Configure a Syslog forwarder in the Prisma Cloud Console system settings to pipe alerts to Slack.

Why it fails: Syslog forwarding transmits alerts to a syslog receiver, not Slack's API, so no Slack message is produced without an intermediary. It is tempting because syslog is a genuine Prisma Cloud alert-forwarding mechanism, and would be correct for sending alerts to a SIEM or log collector rather than a Slack channel.

To stream raw AWS CloudTrail logs directly to S3 storage buckets.

Why it fails: Intelligence Stream curates and correlates threat intelligence and configuration findings into Prisma Cloud; it does not perform raw CloudTrail ingestion, which is CloudTrail's own delivery to S3. It tempts because CloudTrail log pipelines are a real logging pattern, but that is data collection, not intelligence curation.

To accelerate UI page loading speeds using edge caching mechanisms.

Why it fails: Intelligence Stream delivers curated threat and vulnerability intelligence to inform policy and detection; edge caching for UI performance is a content-delivery concern unrelated to it. It tempts because Prisma Cloud is a web console, but page-load acceleration is handled by CDN or front-end caching, not the intelligence feed.

To provide real-time packet capture (PCAP) analysis for network firewalls.

Why it fails: Intelligence Stream supplies curated threat intelligence and vulnerability data; it performs no packet capture, which belongs to network detection tooling inspecting traffic flows. It tempts because Prisma Cloud covers cloud network visibility, but PCAP analysis is a separate network-layer function, not intelligence curation.