CertGrid
Palo Alto Certification

Palo Alto Networks Certified Cloud Security Engineer Practice Exam

Validates deploying and operating the Palo Alto Networks Cortex Cloud CNAPP: planning and installation (architecture, licensing, connectivity, SBAC and RBAC, cost control), integration (cloud account, data and AI source, development system, registry, SAST and SCA tool and Broker VM onboarding), posture security (XQL dashboards, asset groups, cloud and workload rules, vulnerability policies, compliance, Kubernetes connectors, data security), runtime security (XDR agents, endpoint policies, API gateway integration, Cloud Detection and Response), application security (ASPM, code and CI/CD policies, repository scanning, IDE plugins, Cortex CLI) and troubleshooting.

Start with a free Palo Alto Networks Certified Cloud Security Engineer practice test, then work through 347 exam-style questions with full answer explanations, and take timed mock exams to track your readiness against the exam objectives.

Free account: a fixed set of 20 practice questions for this exam, retryable anytime. Paid access unlocks the full bank and timed mock exams. No credit card required to start.

347
Practice pool
Varies
Real exam
90 min
Real exam time
Intermediate
Level
860 / 1000
Passing score

CertGrid runs a fixed 75-question timed mock, separate from the real exam format above.

Objective-mapped practice, aligned to current exam objectives · Reviewed Oct 2026 · Independent practice platform.

What the Palo Alto Networks Certified Cloud Security Engineer exam covers

Free Palo Alto Networks Certified Cloud Security Engineer practice test questions

A sample of 10 questions with answers and explanations. A free account includes a fixed set of 20 practice questions for this exam, retryable anytime. Paid access unlocks the full 347-question bank.

  1. Question 1Planning and Installation

    Norvale Health is planning its first Cortex Cloud onboarding. Each estate below must be covered by one cloud instance, and the security policy forbids deploying any Cortex Cloud role or resource outside the node listed for that estate. ``` | Estate | Node to cover | Contains | |--------|--------------------------------------------|------------------| | AWS | "Payments", a child of the organization root | 40 accounts | | GCP | "Analytics", a child of the organization node | 12 projects | | Azure | "Prod", a child of the tenant root group | 9 subscriptions | ``` Which scope level should the engineer select in the onboarding wizard for each estate?

    • AOrganization for AWS and GCP and Tenant for Azure, excluding every account outside each node
    • BOrganizational unit for AWS, Folder for GCP and Management Group for Azure, one instance per nodeCorrect
    • COrganizational unit for AWS, Project for GCP and Subscription for Azure, one instance per node
    • DAccount for AWS, Folder for GCP and Management Group for Azure, one instance per node
    ✓ Correct answer: B

    The CSP onboarding page lists three scope levels per provider: entire organization (AWS Organization, GCP Organization, Azure Tenant), group of accounts (AWS organizational unit, GCP folder, Azure management group) and single account (AWS account, GCP project, Azure subscription). Each node in the inventory is a group of accounts under the root, so the group-of-accounts level covers exactly that node with one cloud instance. Choosing the broader organization scope with exclusions does not keep resources out of excluded accounts, because the AWS StackSet still deploys IAM roles to every account in the organization scope. The group level therefore meets both the coverage and the policy constraint.

    Why the other options are wrong
    • AExclusions only stop scanning and discovery; for AWS the CloudFormation StackSet still deploys IAM roles to all accounts in the selected organization scope, which breaks the stated policy.
    • CProject and Subscription are the single-account scope levels for GCP and Azure, so each would cover only one project or subscription rather than the whole node.
    • DAccount is the AWS single-account scope level, so it would cover only one of the 40 accounts under the Payments node.
  2. Question 2Planning and Installation

    Fairhaven Water needs two Cortex Cloud API keys and lists the integration requirements below. ``` | Integration | Client | Requirement | |-------------|------------------------------------------------|-------------------------------------| | INT-1 | Bash scripts that call the API with plain cURL | Must work with no extra signing code | | INT-2 | Python service on a CI runner | Must resist replayed requests | ``` Which Security Level should each key use?

    • AStandard for INT-1 and Advanced for INT-2, matching what each client supportsCorrect
    • BAdvanced for both, because it hashes each request with a nonce and a timestamp
    • CStandard for both, with Enable Expiration Date set on INT-2 to block replays
    • DAdvanced for INT-1 and Standard for INT-2, as cURL sends the nonce by itself
    ✓ Correct answer: A

    When creating an API key, the Security Level can be Advanced or Standard. The Advanced key hashes the key using a nonce, a random string and a timestamp to prevent replay attacks, and the page notes that cURL does not support this while scripts can. INT-1 uses plain cURL with no extra signing code, so it needs a Standard key. INT-2 is a Python service that must resist replayed requests, so it should use an Advanced key.

    Why the other options are wrong
    • BcURL does not support Advanced API keys, so the plain cURL scripts in INT-1 cannot use one.
    • CAn expiration date limits how long the key can authenticate; replay protection comes from the Advanced security level.
    • DcURL does not support the Advanced key hashing, and INT-2 is the client that needs replay protection.
  3. Question 3Integration

    At Varley Media, the image payments-api:v1.4 was pushed once on 2 June and never re-pushed. Its Cortex Cloud finding history is below. ``` | Date | Finding change for payments-api:v1.4 | |--------|-----------------------------------------------------| | 02 Jun | Initial scan: 3 vulnerabilities, 1 secret | | 19 Jun | +1 vulnerability (CVE published on 18 Jun) | | 27 Jun | +1 malware finding (file verdict changed) | | 04 Jul | +1 secret, the day after a scanner engine update | ``` Which statement explains the history?

    • AThe 19 and 27 June changes came from re-evaluation; the 4 July secret came from a rescanCorrect
    • BAll three changes came from re-evaluation, which also rechecks secrets against new data
    • CAll three changes came from full rescans that new intelligence triggered each time
    • DThe 19 June change came from re-evaluation; the malware and secret changes needed rescans
    ✓ Correct answer: A

    After the initial scan, scan re-evaluation keeps findings current without re-pulling or rescanning the image, because container images are immutable. New vulnerability intelligence is matched against the stored software inventory, and file verdicts are periodically rechecked so a file later classified as malicious creates a new finding. Re-evaluation applies to vulnerability and malware findings only. Secrets and compliance findings are determined during the image scan and change only when the image is rescanned, for example after a scanner engine update.

    Why the other options are wrong
    • BRe-evaluation applies to vulnerability and malware findings; secrets change only when the image is rescanned.
    • CRe-evaluation updates vulnerability and malware findings without re-pulling or rescanning the image.
    • DUpdated malware verdicts are part of re-evaluation, so the 27 June change did not need a rescan.
  4. Question 4Integration

    Penrith Software added this GitLab CI job to upload SARIF findings to its Generic 3rd Party AppSec Collector in Cortex Cloud. The collector credentials are stored as masked CI variables, and the target repository is onboarded and active. ``` upload-sast-findings: stage: test script: - | curl --fail -X POST "${CORTEX_API_URL}?repo=${CI_PROJECT_PATH}&branch=${CI_COMMIT_REF_NAME}" \ -H "x-crtx-auth-id: ${CORTEX_TOKEN_ID}" \ -H "Authorization: ${CORTEX_API_TOKEN}" \ -H "Content-Type: application/json" \ -d @sarif-results.json ``` What must change in the upload request?

    • AReplace repo= with repository_url= set to the project's full URL, ${CI_PROJECT_URL}Correct
    • BSend the Token ID in Authorization and the API Token in the x-crtx-auth-id header
    • CSet the Content-Type header to application/sarif+json, the media type for SARIF
    • DPass the commit SHA in branch=, since the collector identifies branches by commit
    ✓ Correct answer: A

    The repository mapping reference states that the collector maps findings to repositories at upload time and that each upload requires repository_id or repository_url. repository_url takes the full repository URL, such as https://github.com/org/repo, and the platform resolves the matching asset; repository_id is the asset ID and is preferred for CI/CD automation. The job sends a repo parameter, which is neither documented identifier. The documented examples send the Token ID in x-crtx-auth-id, the API Token in Authorization and Content-Type application/json, as this job already does.

    Why the other options are wrong
    • BThe documented examples send the Token ID in the x-crtx-auth-id header and the API Token in the Authorization header, as the job already does.
    • CThe troubleshooting page says to set the Content-Type header to application/json.
    • Dbranch is optional and takes a branch name such as main, develop or feature/auth, which CI_COMMIT_REF_NAME supplies.
  5. Question 5Posture Security

    Ridgeline Utilities' cloud security engineer receives this ticket and reviews the current vulnerability policy list. ``` Ticket SEC-4471 (network operations) CVE: CVE-2026-10411, present only on vendor-managed load balancer appliances Request: suppress this CVE; the vendor owns the fix | Order | Policy | |-------|-------------------------------------------------| | 0 | Globally Ignored CVEs, Assets, and Asset Groups | | 1 | cvss-9-critical | | 2 | all-findings-low | ``` The engineer adds CVE-2026-10411 to the policy at order 0. What is the result for this CVE?

    • ANo findings are recorded for it, so it leaves the Vulnerable Assets page
    • BFindings are still recorded and listed, and no vulnerability issues are raisedCorrect
    • CFindings are recorded, and cvss-9-critical still raises issues until reordered
    • DFindings are recorded, and issues are raised at Informational severity only
    ✓ Correct answer: B

    Policy 0 in the vulnerability policy list holds the CVEs, asset groups and assets for which Cortex Cloud does not create vulnerability issues. Findings are still created for them and can be reviewed on the Vulnerabilities and Vulnerable Assets pages. Because policies are evaluated from the top and Policy 0 is first, cvss-9-critical never acts on findings for this CVE. Policy 0 can be updated by adding or removing entries, but it cannot be moved down the list.

    Why the other options are wrong
    • AFindings for ignored CVEs are still created and stay reviewable on the Vulnerabilities and Vulnerable Assets pages; only issue creation stops.
    • CPolicy 0 is first in the evaluation order and cannot be moved down, so later policies do not raise issues for a CVE it lists.
    • DPolicy 0 lists CVEs and assets for which no vulnerability issues are created; it does not create issues at a lower severity.
  6. Question 6Runtime Security

    Tamsin Freight's cloud security engineer is tidying the Agent Installations page and wants to delete the package linux-prod-9-3. Forty running EC2 instances were installed from it, and the autoscaling group's launch template still installs the agent from the same downloaded package file on every new instance. What happens if the engineer deletes the package?

    • AThe forty running agents are uninstalled when they next check in with the tenant
    • BRunning agents stay installed, but new instances from it are denied registrationCorrect
    • CNew instances still register, because registration uses each agent's own ID
    • DThe delete is refused while any registered endpoint still uses that package
    ✓ Correct answer: B

    Deleting an installation package does not uninstall the Cortex XDR agent software from any endpoint, so the forty running instances keep their agents. Cortex Cloud relies on the installation package ID to approve agent registration during installation. An agent installed from a package after the package is deleted has its registration request denied and is left unprotected, which is what would happen to every instance the autoscaling group launches. The documentation therefore recommends keeping the packages of active endpoints and hiding them instead if the list is cluttered.

    Why the other options are wrong
    • ADeleting a package does not uninstall the agent software from any endpoint; the running agents keep working.
    • CExisting agents may re-register with the Agent ID generated by the package, but new agents installed from a deleted package cannot register.
    • DThe page allows the delete; the documentation only recommends not deleting packages of active endpoints and offers Hide as an alternative.
  7. Question 7Runtime Security

    Holloway Media has Scope-Based Access Control enabled. The cloud security engineer, an administrator, selects 40 endpoints on All Endpoints, uses Endpoint Control > Assign Endpoint Tags to add the tag Retail EU, and also selects Add selected tags to Users or Groups for the user group retail-ops. What should the engineer anticipate from the last step?

    • AThe step can be completed by any user who is allowed to tag endpoints
    • BThe assignment can change what retail-ops members are permitted to accessCorrect
    • CThe tags affect retail-ops access once the scoping mode is set to Restrictive
    • DThe tags label retail-ops members for reporting and leave their access as is
    ✓ Correct answer: B

    From All Endpoints, selecting endpoints and choosing Endpoint Control, Assign Endpoint Tags adds existing or new tags. A further step, which requires administrator permissions, assigns the tags to users or user groups with Add selected tags to Users or Groups. The documentation warns that when SBAC is enabled, assigning tags may impact user permissions. The Endpoints scoping area can grant access by Endpoint Tags, so retail-ops members may gain access to the tagged endpoints.

    Why the other options are wrong
    • AAssigning tags to users or user groups is the step that requires administrator permissions.
    • CScope tags are evaluated in both Permissive and Restrictive modes; the modes differ only in whether one or all tags must match.
    • DWith SBAC enabled, the documentation warns that assigning tags to users or groups may impact user permissions.
  8. Question 8Application Security

    Linthorpe Bank onboarded the repository billing-svc to Cortex Cloud Application Security. The first scan reported 420 issues. A pull request merged the next day introduced 3 more. A week later a new scanner rule was added, and the next scan reported 12 further issues, all raised by that rule. How are these 435 issues classified?

    • AThe 420 are backlog; the 12 from the new rule and the 3 from the PR are new
    • BAll 435 are new, because backlog starts only after the first full scan ends
    • CThe 420 and the 12 from the new rule are backlog; the 3 from the PR are newCorrect
    • DThe 420 are new; backlog holds only the issues that are older than their SLA
    ✓ Correct answer: C

    The Backlog baseline page separates backlog issues from new issues. Backlog issues are vulnerabilities that existed in a repository or branch before a scanner's initial run, or that were uncovered by new scanner capabilities or rules, and together they define a historical backlog point. New issues are fresh vulnerabilities introduced through recent changes such as pull requests. The 420 from the first scan and the 12 uncovered by the new rule are backlog, and the 3 from the pull request are new.

    Why the other options are wrong
    • AIssues uncovered by new scanner rules are counted as backlog, even though they are reported later.
    • BThe first scan's findings are themselves the backlog; they define the backlog point.
    • DBacklog is defined by the first run or new rules, not by SLA age.
  9. Question 9Application Security

    During an upstream outage, the malicious package intelligence in Corbridge Systems' tenant has not refreshed for about an hour, and the freshness threshold is at its default. A CI pipeline then runs a Cortex CLI code scan whose SCA step includes malicious package detection. What will the CI scan do?

    • AMatch against the cached dataset and print the Malicious Packages table as usual
    • BContinue with all other findings and report the malicious packages sub-check as failedCorrect
    • CHold the CI job until the dataset refresh completes, then run the package check
    • DFail the CI step with a blocking error, since the package check could not complete
    ✓ Correct answer: B

    Malicious package intelligence is refreshed continuously from OSV.dev, and intelligence older than the freshness threshold, 20 minutes by default, is stale, so a scan is never silently evaluated against out-of-date data. An hour without a refresh is beyond the default threshold. The CLI workflow page states that when the check cannot complete during a CLI or CI scan, because the service is unreachable or the data is stale, the scan continues and produces all other findings, emits a CRITICAL-level error log and reports the malicious packages sub-check as failed. The scan is never blocked by a malicious package check failure.

    Why the other options are wrong
    • AStale intelligence beyond the freshness threshold is not silently used; the check cannot complete and is reported as failed.
    • CThe scan continues rather than waiting for a refresh, and the malicious packages sub-check is reported as failed.
    • DThe scan is never blocked by a malicious package check failure; it continues and produces all other findings.
  10. Question 10Troubleshooting

    Orwell Freight's cloud engineer is deploying an Azure outpost in Bring Your Own App (BYOA) mode. A colleague prepared the Azure side by hand in the portal instead of running the helper script, and left these notes. ``` Colleague's notes (Azure portal) 1. App registration created, Supported account types: this organizational directory only 2. Federated credential cortex-outpost-fic added by hand while testing, never removed 3. Five UAMIs created in rg-cortex-outpost, the resource group Cortex manages for the outpost 4. Two of the UAMIs deleted and created again a few seconds before the first run ``` Which of these problems will terraform plan report, before anything is deployed?

    • AItem 1, the app registration's single-tenant sign-in audienceCorrect
    • BItem 2, the federated credential left on the app registration
    • CItem 3, the UAMIs inside the Cortex-managed resource group
    • DItem 4, the UAMIs that have not yet replicated in Entra ID
    ✓ Correct answer: A

    The BYOA troubleshooting table lists each error with the Terraform deployment phase in which it appears. A single-tenant app registration fails the plan with an error that sign_in_audience must be AzureADMultipleOrgs, because the Azure portal defaults to single-tenant (this org only). A stale federated credential and the replication lag of a recently created UAMI surface only in the apply phase. UAMIs inside the outpost's Cortex-managed resource group cause no plan error and are deleted by a later destroy.

    Why the other options are wrong
    • BA stale federated credential from a previous attempt or a manual portal entry is an apply-phase error: another object with the same federatedIdentityCredentials value already exists.
    • CUAMIs placed in the outpost's Cortex-managed resource group are a destroy-phase problem, because Terraform deletes them during a destroy operation.
    • DReplication lag of a recently created UAMI is an apply-phase error: 400 BadRequest, Subject does not exist in directory.

Who this Palo Alto Networks Certified Cloud Security Engineer practice exam is for

This practice set is for anyone preparing for the Palo Alto Networks Certified Cloud Security Engineer exam at the intermediate level - from first-time candidates building a foundation to experienced Palo Alto practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.

How to use this Palo Alto Networks Certified Cloud Security Engineer practice exam

  1. Start with the free sample questions above to gauge your current baseline.
  2. Read the full explanation on every question, including why each wrong option is wrong.
  3. Track your weak domains and focus your study where you are losing the most marks.
  4. Once you are scoring consistently well, take a timed, full-length mock exam.
  5. Use your readiness score to decide when you are ready to book the real Palo Alto Networks Certified Cloud Security Engineer exam.

Related Palo Alto resources

Palo Alto Networks Certified Cloud Security Engineer practice exam FAQ

How many questions are in the Palo Alto Networks Certified Cloud Security Engineer practice exam on CertGrid?

CertGrid has 347 practice questions for Palo Alto Networks Certified Cloud Security Engineer, covering 6 exam domains. The real Palo Alto Networks Certified Cloud Security Engineer exam runs 90 min, with a published question count that varies. CertGrid's timed mock is a fixed 75 questions.

What is the passing score for Palo Alto Networks Certified Cloud Security Engineer?

Palo Alto Networks sets the passing score at 860 on a 300-to-1000 scale for every one of its certification exams. CertGrid grades this mock on its own 0-1000 scale, so read the 860 as the real exam bar and your CertGrid score as readiness, not as the same number. You have about 90 min to complete it. CertGrid tracks your readiness against the exam objectives so you know where to focus.

Are these official Palo Alto Networks Certified Cloud Security Engineer exam questions?

No. CertGrid is an independent practice platform. We do not provide real or leaked exam questions. Our questions are original and designed to help you practice the concepts, scenarios, and difficulty style of the Palo Alto Networks Certified Cloud Security Engineer exam.

Is there a free Palo Alto Networks Certified Cloud Security Engineer practice test?

Yes. You can take a free Palo Alto Networks Certified Cloud Security Engineer practice test straight away: a fixed set of 20 practice questions for this exam, retryable as often as you like, with no credit card required. You get readiness scoring and a weak-domain breakdown on those questions. Paid plans unlock the full 347-question bank, timed mock exams and full-bank domain analytics.

What CertGrid is (and is not)

CertGrid is an independent IT certification practice platform for Azure, AWS, Google, Cisco, Security, Linux, Kubernetes, Terraform, and other certification tracks. It provides objective-mapped practice questions, readiness scoring, weak-domain drills, and explanations to help learners understand what to study next.

Independent & original. CertGrid is an independent practice platform and is not affiliated with or endorsed by Palo Alto Networks. Questions are original practice items designed to mirror certification concepts and exam style. CertGrid does not provide official exam questions or braindumps.