CCSP Cloud Application Security: 240 practice questions

12 of the 240 Cloud Application Security questions in the Certsqill CCSP bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for CCSP? Take the free 5-min readiness check →

1. Use DAST with authenticated: Which control directly addresses this demonstrated failure?

1. Use DAST with authenticated, cross-tenant authorization tests. ✓

   DAST exercises running software and can verify whether requests improperly cross tenant authorization boundaries.
2. Require a trusted signature on every deployment artifact.

   Artifact signatures establish provenance and integrity, not whether deployed application logic correctly enforces authorization.
3. Generate an SBOM for the API's third-party packages.

   SCA and SBOM activities identify component exposure, but they do not directly test object authorization behavior.
4. Run SAST on the API source before each deployment.

   SAST examines code without execution, so it may miss authorization behavior requiring deployed requests and realistic identities.

DAST tests deployed behavior, making it appropriate for discovering runtime cross-tenant authorization failures.

2. Role-mapped records showing training completion: Which evidence best satisfies the requirement?

1. A general security-newsletter delivery report plus a current repository-access list.

   Distribution and access records do not demonstrate role-specific training or practical comprehension.
2. Commit history containing secure coding changes and review comments.

   Repository activity may show behavior but does not prove completion of assigned role-specific training or assessment.
3. Role-mapped records showing training completion, assessment results, and remediation. ✓

   These records establish applicability, participation, assessed understanding, and follow-up for failures.
4. A manager's email asserting that developers understand secure coding.

   An assertion does not objectively establish assigned training completion or practical understanding.

Role-mapped completion and assessment records verify both participation and understanding.

3. Document the requirement: What is the most appropriate remediation?

1. Document the requirement, update the design, and retest authorization before release. ✓

   This remediation restores traceability, incorporates security before deployment, and verifies the control through a repeat test.
2. Sign the existing artifact and record the failed test as accepted risk.

   Signing protects provenance and integrity, while risk acceptance does not satisfy an unmet authorization requirement before release.
3. Deploy first, then use production monitoring to detect unauthorized access.

   Monitoring may detect consequences, but it does not remediate the missing requirement or prevent an avoidable release defect.
4. Replace the payment service with a network firewall rule restricting its endpoint.

   Network filtering can restrict connectivity, but it cannot enforce authorization for individual payment objects or actions.

The failed test requires a traced requirement, corrected design, and verification before deployment.

4. It supports signer authenticity and artifact integrity: What security conclusion does a successfully validated

1. It guarantees the deployed application cannot be compromised through runtime weaknesses.

   Runtime configuration, credentials, dependencies, and application vulnerabilities can still enable compromise.
2. It proves the artifact has no exploitable vulnerabilities.

   Signature validation does not assess code logic, dependencies, configuration, or vulnerabilities.
3. It proves every dependency received security approval before inclusion.

   Dependency approval requires separate inventory and review evidence.
4. It supports signer authenticity and artifact integrity, but not software safety. ✓

   A trusted signature links the artifact to a signer and detects alteration after signing, but does not prove the artifact is harmless.

A valid signature supports provenance and integrity, not absence of vulnerabilities or malware.

5. The relying service’s application owner: Who owns that decision?

1. The certificate issuer that supports the assertion signature.

   A certificate issuer supports cryptographic trust infrastructure but does not decide whether the firm accepts assertions or grants application permissions.
2. The relying service’s application owner, under documented federation and authorization policy. ✓

   The application owner governs relying-party acceptance and applies the service’s local authorization policy after validating the assertion.
3. The user whose employment account is identified.

   The user is the subject of the assertion, not the authority that configures relying-party trust or authorization policy.
4. The network administrator responsible for the firm’s perimeter firewall rules.

   Firewall rules govern network traffic and do not determine federation trust or application entitlements.

The relying service owner decides assertion acceptance and resulting application permissions.

6. The application must enforce server-side authorization: Which responsibility boundary is correct?

1. The container host should block requests containing modified invoice identifiers.

   Host isolation protects runtime infrastructure, but cannot reliably interpret business ownership or permitted invoice actions.
2. A network firewall should permit only the user's original invoice identifier.

   Network firewalls filter connection attributes and cannot maintain application-specific object authorization decisions.
3. The WAF should decide whether the requested invoice belongs to the caller.

   A WAF can inspect web requests, but business ownership and object-level permission decisions belong inside application authorization.
4. The application must enforce server-side authorization for each object and action. ✓

   The application has the necessary identity, object, and action context to enforce authorization for each request.

Object ownership and action permissions require server-side application authorization, not WAF or network filtering.

7. Model the boundary: Which approach best satisfies the stated requirements?

1. Validate input syntax and rely on a permissive CSP when filtering is unavailable, without changing rendering logic.

   Input validation and CSP do not substitute for maintained sanitization and context-specific output encoding.
2. Reject all user-authored content during every filtering outage.

   This may reduce exposure but violates the stated availability and permitted-content requirements.
3. Model the boundary, sanitize permitted HTML, encode output by context, and define degraded operation. ✓

   This addresses the browser trust-boundary crossing while preserving approved content and planning for filter failure.
4. Use a WAF as the sole control for malicious browser content.

   A WAF is defense in depth and cannot replace context-appropriate encoding and sanitization.

Use trust-boundary analysis, HTML sanitization, contextual encoding, and an explicit degraded mode.

8. Record the flaw: Which evidence qualifies?

1. A scanner screenshot identifying the vulnerability.

   Detection alone does not document tested controls, approval, or expiration.
2. A developer's note that the vulnerable function is rarely used.

   The note does not establish tested compensating controls, accountable approval, or an expiration date.
3. An SBOM listing the affected dependency and version.

   An SBOM supplies inventory but not mitigation testing, risk acceptance, or time limits.
4. Record the flaw, tested mitigation, owner approval, and expiry. ✓

   This evidence addresses all four conditions in the exception policy.

A valid exception record covers the flaw, tested mitigation, accountable approval, and expiry.

9. Training does not itself enforce authorization for each: Which statement is correct?

1. Training proves every API endpoint has been dynamically tested.

   Completion evidence does not demonstrate runtime test coverage, endpoint behavior, or authorization results.
2. Training does not itself enforce authorization for each requested object and action. ✓

   Awareness can guide developers, but server-side application logic must enforce object and action authorization.
3. Training automatically causes the identity provider to issue stronger credentials.

   Training changes knowledge, not identity-provider credential strength or authentication-factor properties.
4. Training eliminates the need for authorization logs and entitlement reviews.

   Training does not replace operational evidence, lifecycle management, monitoring, or periodic entitlement review.

Developer awareness cannot enforce runtime permissions; application logic and verification remain necessary.

10. Add a testable security criterion and require evidence: What should the product owner require?

1. Add a generic security note to the backlog.

   A generic note lacks testable evidence and does not establish that the sensitive flow passed review.
2. Leave the definition unchanged and monitor the first production release.

   Postrelease monitoring cannot satisfy a requirement for security acceptance before release.
3. Add a testable security criterion and require evidence before release. ✓

   This makes the policy requirement part of completion and requires verifiable evidence before release.
4. Require a signed artifact as the release evidence.

   A signature supports integrity and provenance, but does not verify the required security acceptance criterion.

Security acceptance must be testable, evidenced, and required before release.

11. Correlate listed components with vulnerabilities: Which action is most appropriate?

1. Replace the application with a newly signed artifact.

   Signing establishes artifact integrity and provenance, but it does not assess or remediate vulnerable listed components.
2. Correlate listed components with vulnerabilities and prioritize remediation. ✓

   SBOMs inventory components; vulnerability correlation and remediation activities address the resulting security exposure.
3. Require users to complete multifactor authentication before deployment.

   Multifactor authentication protects access, but it does not resolve unidentified or vulnerable software dependencies.
4. Move the application behind a web application firewall.

   A WAF can provide defense in depth, but it cannot replace component assessment and remediation.

An SBOM identifies components; separate assessment and remediation are required to address their vulnerabilities.

12. Require independent MFA for privileged federation: Which gap should the security lead address first?

1. Review authorization roles across every research application.

   Role review may address excessive permissions, but it does not correct password-only authentication.
2. Protect identity-provider key-encryption keys with stronger encryption.

   Key protection may support cryptographic security but cannot add a missing authentication factor.
3. Replace federation with local accounts and passwords.

   Moving accounts does not inherently add an independent authentication factor.
4. Require independent MFA for privileged federation. ✓

   This directly addresses the password-only gap while retaining federation and requiring the policy-mandated second factor.

Federation and SSO do not provide the required independent second factor.

Other CCSP domains

• Cloud Data Security — 300 questions →
• Cloud Concepts, Architecture and Design — 255 questions →
• Cloud Platform and Infrastructure Security — 255 questions →
• Cloud Security Operations — 255 questions →
• Legal, Risk and Compliance — 195 questions →
• All 1500 CCSP questions →
• CCSP certification: requirements, cost and exam format →