Free CCCS practice test: 30 questions with answers

CSPM continuously evaluates cloud account and service configuration against policies and benchmarks, which is how it surfaces publicly readable storage. CWP protects running workloads, while ASPM and DSPM focus on application code and sensitive data, so neither matches the request.

A Kubernetes admission controller intercepts deployment requests and enforces image assessment results and policy before the cluster admits a workload. The other options describe runtime scanning, account registration and Fusion notifications, which happen at different points in the lifecycle.

One-click sensor deployment is the feature meant to cut the manual, per-host effort of installing the Falcon sensor on cloud virtual machines. Image assessment policy, scan exclusions and Fusion notifications all have other purposes and do not install sensors.

CSPM assesses configuration of cloud accounts and services against policies and benchmarks, and CWP protects workloads such as containers and VMs while they run. CSPM does not block runtime malware, and CWP is not limited to IAM review, so the other two statements are wrong.

IaC security evaluates infrastructure templates such as Terraform before resources are created, which is where insecure settings are cheapest to fix. CWP protects running hosts, DSPM focuses on sensitive data stores, and IOA tuning concerns live behaviour, so none of them check templates before deployment.

CSPM evaluates configuration through account registration, which gives Falcon permission to read the account's settings, so no sensor is needed on each instance. Sensors, image exclusions and spreadsheet exports are not prerequisites for CSPM findings to appear.

Least privilege means the registration grants only the read access the assessment requires, which limits the damage if the integration is compromised. Full admin rights, shared root credentials and broad write access all create unnecessary risk and are not sound practice.

A registration that reports a permissions error usually lacks the read permissions it needs in the subscription, so verifying those grants is the correct first step. Installing sensors, creating image policies or disabling CSPM policies do not fix a registration problem.

Good exclusions are documented with a reason, reviewed on a schedule, and scoped as narrowly as possible so other resources keep being assessed. Excluding a whole account, or treating exclusions as permanent and unreviewed, hides risk and is poor practice.

A cross-account role that Falcon assumes lets the platform read configuration without holding long-lived keys. Emailing access keys, sharing one secret across accounts and storing root passwords in the console all expose credentials and are poor practice.

Assigning a CSPM policy to a cloud group that contains only production accounts scopes evaluation without duplicating policies or turning off coverage. Applying the policy to all accounts with a note, copying policies, or disabling CSPM does not enforce the intended scope.

A CSPM rule compares the current configuration of a cloud resource with an expected setting, such as encryption or access restrictions. Malware signatures, runtime process trees and user keystrokes are outside the scope of configuration assessment.

A narrowly scoped, documented exclusion lets the one approved image run while the policy keeps protecting everything else. Disabling the policy broadly, marking findings resolved without review, or ignoring them on a ticket approval removes the control without proper governance.

Runtime sensor policies control prevention versus detection-only response, and admission controller policies can block non-compliant workloads before admission. CSPM does not need sensors and does not analyze process memory, so those two statements are false.

Leaked secrets detection during image assessment finds credentials or tokens stored in image content before the image is deployed. Runtime IOA detection acts on live behaviour, CSPM checks account configuration, and Fusion workflows act after events, so none of them catch the token in the image.

A Dockerfile misconfiguration finding flags build instructions that weaken the image, such as running as root when no user is set. The other options describe runtime resource use, identity sign-ins and load balancer certificates, which are not Dockerfile issues.

A known CVE in a base layer is fixed by rebuilding on a patched base image and rescanning before deployment. Deploying anyway, removing the sensor, or excluding the image without review leaves the vulnerability in place.

Pre-runtime image assessment checks image content for malware and for known CVEs in installed packages before deployment. Excess CPU use, outbound connections and unapproved processes only appear once a container is running, so they are runtime signals.

A Falcon sensor built for container and Kubernetes environments provides runtime visibility into container workloads on the cluster. A browser extension, a DNS setting or a USB policy does not provide runtime protection for container processes.

An indicator of attack is a behaviour-based pattern that suggests an attack is under way, so it can detect threats without a known signature. Hash lists, drift reports and account labels do not describe attack behaviour.

Drift describes a running container that has changed from its source image, such as a process the image never contained. Image assessment, admission control and cloud grouping describe other stages or organizational features, not a mismatch with the image.

A container started outside the orchestrator bypasses the admission checks and approval path that the cluster normally enforces, which is why it is treated as a potential rogue container. Resource use, image tags and label names do not establish whether a container is authorized.

A publicly readable storage bucket is a configuration problem, so it is reported as an indicator of misconfiguration. The other findings relate to live workload behaviour, image content and workflow health, which are different categories.

A CIS-style benchmark provides a standard set of configuration checks that can be measured and tracked over time. It does not replace account registration, run malware scans, or control runtime sensor modes.

Reviewing which IAM users hold administrative rights and whether they are still used belongs to the user activity and permissions audit. Scan exclusions, sensor deployment and image assessment do not evaluate identities or permissions.

A public-facing asset that lacks a Falcon sensor, or that no owning team has recorded, is an unmanaged exposure needing follow-up. An internal-only database and an on-time report delivery do not represent exposed unmanaged assets.

A scheduled report is the feature that sends recurring summaries of findings to a list of recipients on a set cadence. Scan exclusions, image assessment thresholds and sensor modes control what is evaluated or blocked, not how results are delivered.

Following the remediation guidance closes the exposure at its source, and re-evaluation confirms that the finding has cleared. Exclusions, accepting risk while leaving the bucket public, or removing the registration only hide the problem.

Fusion SOAR workflows automate notifications and response steps when a detection or finding meets conditions the team has defined. The other options describe sensor installation, detection logic replacement and identity provisioning, none of which is the workflow's role.

The chat notification is configured as an action inside the Fusion workflow that runs when the detection fires. The image policy, exclusion list and sensor update policy each control other areas and cannot send a notification to a chat channel.