Select Two (Multi-Select) Questions

Public access to logs

Why it fails: Public access exposes log data to unauthorised parties and violates audit integrity and confidentiality requirements; logs belong in restricted, access-controlled storage. It is tempting when teams want quick troubleshooting visibility, but public exposure breaks the chain-of-custody that audit strategies depend on.

Manual log deletion

Why it fails: Manual log deletion destroys the audit trail that a Cloud Audit log strategy exists to preserve, breaking integrity and retention requirements. It is tempting because deleting logs is a legitimate housekeeping task for managing storage costs or removing obsolete data, but that belongs in a separate retention-policy discussion, not an audit strategy.

Packet capture via physical span port

Why it fails: Prisma Cloud consumes cloud audit, flow and service logs via APIs and agents; a physical SPAN port captures raw packets, which the platform does not ingest. It tempts because span ports are standard for network monitoring, and would be correct for feeding an on-premises IDS or packet-analysis tool.

Manual file upload via browser

Why it fails: Prisma Cloud's ingestion relies on continuous API-based or agent-based collection; a browser file upload is one-off and cannot sustain ongoing log flow. It tempts because manual uploads work for ad-hoc forensic imports, and would be the right choice when onboarding a small historical log export for a one-time investigation.

SQL database direct connect

Why it fails: Prisma Cloud ingests logs through API integrations and agent-based collectors, not by querying a SQL database directly; no such connector exists. It tempts because security teams already centralise event data in relational stores, so pulling from SQL feels natural, and it would suit custom SIEM pipelines built on database polling.

Ignore the alert

Why it fails: Ignoring the alert leaves the violation unaddressed, allowing the compliance breach and any underlying exposure to persist. It is tempting when alerts are noisy or believed to be false positives, and would be right only after documented triage confirms a benign, non-reportable event.

Delete all audit logs

Why it fails: Deleting audit logs destroys the evidence needed to investigate and report the violation, and may itself breach retention requirements. It is tempting as apparent clean-up, and would be defensible only when securely disposing of data past its mandated retention period under an approved policy.

Encrypting the data stored within the application

Why it fails: In SaaS the customer remains responsible for classifying and encrypting its own data, including choosing encryption keys where customer-managed keys are offered. It is tempting because the provider encrypts data at rest on its infrastructure, which is a provider task, but application-level data encryption stays with the tenant.

Configuration of user access roles

Why it fails: User access role configuration stays with the SaaS customer, who decides which of its staff may use which features. It is tempting because the provider manages the identity platform and role definitions, but assigning roles to the tenant's own users is a customer administrative task, not a provider one.

User biography

Why it fails: RQL requires a resource or data type, filtering criteria and selected fields; a user biography is descriptive HR content, not a query component. It is tempting because user attributes such as department or manager appear in identity queries, but biography text is never an essential structural element.

System uptime

Why it fails: RQL queries are built from a data type, filter conditions and fields to return; uptime is a monitored metric, not a query element. It is tempting because availability data is frequently queried in cloud security reporting, so it feels relevant, but it belongs in the results, not the query structure.

Delete Account

Why it fails: Delete Account is an identity lifecycle operation performed in a directory or IAM console, not an action an alert rule can invoke on a monitored resource. It is tempting because alert rules can trigger automated responses, yet those act on the monitored workload, not on user accounts in Microsoft Entra ID.

Reboot VM

Why it fails: Reboot VM is a compute management operation issued through the cloud provider's instance controls, not an action available inside an alert rule's action list. It is tempting because alert rules do automate remediation, but they target monitoring, notification and workload-level responses rather than virtual machine power state.

Format Disk

Why it fails: Format Disk is not an alert-rule action; it is a destructive disk operation performed through OS or storage tooling, and no alerting platform exposes it as a response. It is tempting because alert rules do offer remediation actions, but those are scoped to notification, tagging or workload control rather than low-level disk formatting.

Cloud provider's profit margin

Why it fails: Alert details expose the affected resource, policy violated, and severity; a provider's profit margin is commercial data never surfaced there. It is tempting because cloud economics influence risk decisions, and margin figures belong in vendor pricing or cost-optimisation reporting instead.

User's home address

Why it fails: Prisma Cloud alerts surface identity, resource, policy and timeline data, not personal home addresses, which no cloud security posture tool collects. It is tempting because user identity attributes do appear in alerts, but the relevant field is the account or principal name, never a residential address.

Container image vulnerability scan results for outdated packages.

Why it fails: Vulnerability scanning identifies known CVEs in images but does not detect active crypto-mining behavior at runtime. Mining attacks can be deployed via previously clean images or through runtime exploits. While important, it is not a runtime detection method for active mining processes.

File integrity monitoring of system binaries under `/usr/bin`.

Why it fails: While file integrity monitoring is useful for detecting unauthorized changes to system binaries, it is not the primary runtime capability for detecting crypto-mining attacks. Mining attacks often involve new binaries or scripts, not necessarily modifying existing ones. It may provide indirect indicators but is not as direct as process or network monitoring.

Kubernetes API server audit logs for suspicious `create pod` events.

Why it fails: Audit logs can reveal suspicious deployment activity, but crypto-mining attacks typically occur within existing containers. Monitoring API server logs is more about control plane security and does not directly detect runtime mining behavior. It is not a runtime capability of Prisma Cloud Compute for workload protection.

Container start time

Why it fails: Prisma Cloud computes Risk Score from vulnerability findings, compliance benchmarks, and runtime activity; start time is scheduling metadata with no security relevance. It is tempting because container age can correlate with patch drift, but the score uses current findings rather than launch timestamps.

User operating system preference

Why it fails: Risk Score derives from image vulnerabilities, compliance misconfigurations, and runtime threat indicators; an operator's OS preference has no bearing on container posture. It is tempting because user environment choices influence tooling, but Prisma Cloud scores the container artefact and its behaviour, not the analyst's desktop.

Network latency

Why it fails: Prisma Cloud risk scoring aggregates vulnerability severity, compliance violations, and runtime behaviour such as processes and network connections; latency is a performance metric, not a security signal. It is tempting because latency affects application health, but that belongs to observability tooling rather than container risk posture.

Over-abundance of cloud providers

Why it fails: Multi-cloud estates typically involve two or three providers, so provider count is not a data protection challenge; the real difficulties are fragmented identity, inconsistent encryption controls and scattered key management. It tempts because sprawl genuinely complicates governance, but the stem asks about protecting data, not managing vendor relationships.

Too much cloud bandwidth

Why it fails: Bandwidth is a network capacity and cost concern, not a data protection challenge; cloud-native protection issues centre on shared responsibility, key management, misconfiguration and data residency. It is tempting because cloud egress charges and throughput limits are real operational pains, but they do not threaten confidentiality, integrity or availability of data.

Excessive cloud uptime

Why it fails: High availability is a design goal, not a protection challenge; uptime does not create exposure, misconfiguration, over-permissive access or unmanaged keys do. It tempts because resilience and security are often discussed together, yet excessive uptime would be the correct concern only when availability itself is the requirement being assessed.

Rotate the user's password

Why it fails: Password rotation addresses identity credentials, not container image or runtime configuration weaknesses. It is tempting because Prisma Cloud does surface credential findings, but that remediation applies to identity hygiene, not to hardening a container deployment.

Update the host operating system kernel

Why it fails: Kernel patching addresses the host node, not the container image or its runtime settings, so the deployment's own misconfiguration persists. It tempts because host hardening matters generally, but container remediation targets image and deployment configuration instead.

Manually delete all containers

Why it fails: Deleting containers removes running workloads without fixing the underlying image or manifest defect, and the deployment recreates them. It tempts as an immediate stopgap, yet the correct remediation corrects the vulnerable image or configuration so redeployed containers are secure.

Patching the underlying hypervisor that supports the EC2 instances

Why it fails: The hypervisor is part of AWS's managed infrastructure. AWS is responsible for patching and securing the hypervisor to ensure isolation between tenants. Customers do not have access to the hypervisor and cannot patch it. This is a provider responsibility in all cloud models. Selecting this option confuses a provider task with a customer task.

Maintaining the physical security of the AWS datacenter where the EC2 instances run

Why it fails: Physical security of AWS datacenters is always AWS's responsibility. Customers have no access to these facilities and cannot implement physical controls. AWS manages access controls, surveillance, and environmental safeguards. Assigning this to the customer is incorrect and would be impossible to fulfill. This option describes a provider task.

Managing the physical network cabling within the AWS region

Why it fails: Physical network cabling is part of AWS's infrastructure and is managed entirely by AWS. Customers have no visibility or control over the physical network. This includes cabling, switches, and routers within AWS regions. Assigning this to the customer is incorrect and reflects a misunderstanding of the shared responsibility model. This is a provider responsibility.

Cloud Infrastructure Provisioning

Why it fails: Cloud infrastructure provisioning belongs to IaC tooling such as Terraform or CloudFormation, not to a web application and API security module. It is tempting because Prisma Cloud's wider platform does scan IaC templates, but WAAS itself inspects HTTP traffic for OWASP threats, bot mitigation and API protection.

Identity Federation

Why it fails: Identity federation is handled by identity providers and Microsoft Entra ID, sitting outside WAAS's layer 7 inspection scope. It is tempting because Prisma Cloud's CSPM correlates identity findings, but WAAS specifically delivers web application firewalling, API security and DDoS/bot defence for exposed workloads.

Automatic creation of cloud resources

Why it fails: Prisma Cloud assesses and remediates misconfigured permissions; it does not provision cloud resources, which is the function of infrastructure-as-code or native APIs. It is tempting because automated remediation can modify policies, but creating resources such as VMs or buckets lies outside IAM governance.

Replacement for all user authentication methods

Why it fails: Prisma Cloud performs IAM governance by analysing permissions, detecting excessive access and enforcing least privilege; it does not authenticate users, which remains the role of identity providers. It is tempting because Prisma Cloud integrates with identity systems for visibility, but replacing authentication methods falls outside its governance scope.

Elimination of the need for cloud-native IAM tools

Why it fails: Prisma Cloud complements cloud-native IAM by providing cross-account visibility, policy checks and remediation; it consumes those tools' data rather than replacing them. It is tempting because Prisma Cloud centralises IAM posture across providers, yet native IAM remains the enforcement plane for identities and permissions.

Cloud account billing details

Why it fails: Billing details sit under Prisma Cloud's account or licence management, not Access Control, which governs users, roles and SSO. It is tempting because cloud account onboarding does capture billing identifiers, but that belongs to account configuration rather than the access-control settings this menu exposes.

Defender deployment scripts

Why it fails: Defender deployment scripts belong to the Defenders or Compute menu, which manages host and container protection, not identity permissions. Access Control governs roles, users and permission assignments; deployment scripts are the right setting when provisioning Defenders to hosts.

Vulnerability scan frequency

Why it fails: Scan frequency is configured in the vulnerability or compliance scan policy, not Access Control, which manages users, roles, SSO and permissions. It tempts because both appear as security settings, yet scheduling belongs to scan configuration; Access Control never governs when scans run.

User password length

Why it fails: Password length describes credential strength and is not an alert attribute, so it cannot narrow the Alerts view. It is tempting because password policy is a genuine security concern, and it would be the correct choice if the question asked which criteria are used to assess account security posture rather than to filter alerts.

Browser type

Why it fails: Browser type is client telemetry unrelated to alert severity, source or category, so it cannot reduce alert fatigue. It is tempting because browser data appears in endpoint and web telemetry, and it would be the correct choice if the question asked which attribute helps investigate a web-based attack rather than filter the Alerts view.

Voice Message

Why it fails: Prisma Cloud exports findings through APIs, webhooks, syslog and CSV downloads; voice messages carry no structured data channel. It tempts because voice notes suit informal alerting, yet they would only fit a scenario needing human-readable audio notifications, not machine-parseable export.

Fax

Why it fails: Prisma Cloud exports findings through APIs, webhooks, syslog and CSV downloads; fax transmits scanned images, not structured telemetry. It tempts because fax still appears in regulated industries for signed documents, yet it would only fit a scenario requiring hard-copy delivery of a signed report.

Physical Mail

Why it fails: Prisma Cloud exports findings through APIs, webhooks, syslog and CSV downloads; physical mail moves paper, not queryable data. It tempts because some compliance regimes demand mailed notifications, yet it would only fit a scenario requiring legally served hard-copy correspondence rather than data export.

Access Transparency logs

Why it fails: Access Transparency logs record when Google personnel access customer data, which is a specialized compliance feature. They do not capture customer administrative or data access events, so they are not the correct log types for this scenario.

System Event audit logs

Why it fails: System Event audit logs record Google Cloud administrative actions that modify resources, but they are generated by Google systems, not customer activity. They are not the primary source for monitoring customer administrative or data access events, so they do not fulfill the requirement.

VPC Flow Logs

Why it fails: VPC Flow Logs capture network traffic metadata for VPC subnets, not audit activity. While useful for network monitoring, they do not provide the API-level audit events needed to track administrative changes or data access in GCP.

Enable S3 server access logging on the central bucket and store the access logs in the same bucket.

Why it fails: S3 server access logging records requests to the bucket but does not detect attempts to disable CloudTrail logging or centralize trail delivery. Storing access logs in the same bucket creates a circular dependency and does not provide the required tamper detection. This option does not satisfy the scenario.

Deploy a service control policy that allows only the security team to call cloudtrail:StopLogging and cloudtrail:DeleteTrail.

Why it fails: A service control policy restricting StopLogging and DeleteTrail reduces the risk of tampering but does not centralize log delivery or detect when logging is disabled. It is a preventive control, not a detection mechanism. The scenario requires both centralized delivery and detection of disable attempts.

Enable AWS CloudTrail Insights in each member account and configure Amazon SNS notifications for anomalous activity.

Why it fails: CloudTrail Insights detects unusual API call volumes but does not centralize log delivery or prevent log deletion. SNS notifications alert on anomalies but do not detect attempts to disable logging. This option does not meet the centralized architecture or tamper-detection requirements.

AWS Config configuration history for the S3 bucket, which records changes to bucket properties over time.

Why it fails: AWS Config records resource configuration changes and compliance state, not object access events. It can show when bucket settings changed but does not provide the requester identity or the specific objects read, making it irrelevant for tracing data exfiltration activity.

AWS CloudTrail management events, which record bucket-level configuration changes such as policy updates.

Why it fails: CloudTrail management events record control plane operations like PutBucketPolicy or DeleteBucket, not object-level reads. They are useful for detecting configuration changes but do not show which objects were accessed or by which identity during data exfiltration.

Amazon VPC Flow Logs for the subnet containing the S3 endpoint, which record IP-level traffic metadata.

Why it fails: VPC Flow Logs capture IP traffic metadata such as source and destination addresses and ports, but not the S3 object key or the authenticated identity. They can indicate that traffic occurred but cannot identify which objects were accessed, so they are insufficient for this correlation.