Free Certified Cloud Security Professional (CCSP) practice test: 30 questions with answers

A managed private cloud is run by a provider but dedicated to one organisation, which matches the isolation the workload needs. Community clouds are shared among a group, public clouds share infrastructure across tenants, and hybrid clouds mix models rather than describing one dedicated environment.

In IaaS the customer manages the guest operating system, including patching, configuration and the software that runs on it. The provider covers the physical and hypervisor layers, and the other options misplace or invent responsibilities.

Rapid elasticity is the characteristic that covers scaling capacity up and down with demand. Resource pooling describes sharing, broad access describes reach, and measured service describes metering, so none of the others is about automatic scaling.

Restricting storage and processing to approved regions at design time enforces residency where the data is created and kept. Compression, relying on provider replication or filtering inbound addresses do not control where the data is stored or processed.

Customers keep responsibility for their data in every model, and in SaaS they still manage user access and data handling while the provider runs the application. Under PaaS the provider manages the runtime, and classification and data-centre security remain with the provider.

TLS protects data in transit, the data moving between the client and the service. At-rest, in-use and archive are separate states that TLS does not cover on its own.

Customer-managed keys let the customer control the key lifecycle, including rotation and revocation, inside the provider's key service. Provider-managed keys remove that control, embedded keys are hard to rotate and expose secrets, and shared keys break tenant isolation.

Cryptographic erasure works even when the customer does not control the physical media, because destroying the keys makes the data unreadable. Overwriting depends on storage behaving as expected, deleting names leaves the data intact, and archiving keeps it.

Tokenisation keeps the real card number out of the analytics copy, and only the vault can map a token back. An unsalted hash of a card number is easy to guess, comments are not access control, and a view that keeps the card column still exposes it.

Server-side encryption with managed keys protects stored data, and least-privilege IAM limits who can read or delete it. Public reads, keys stored beside the data and disabling versioning each weaken protection or recovery.

A hypervisor escape lets code in one guest reach the host or other tenants, which is the core multi-tenant isolation risk. Certificate expiry, disk fragmentation and latency jitter are operational issues that do not cross tenant boundaries.

Separate networks with controlled connectivity and explicit firewall rules limit flows to the required ones. Flat networks rely on trust, public addresses weaken isolation, and identical IP ranges cause routing conflicts.

Keeping management ports off the public internet and reaching them through a bastion or identity-aware proxy removes the exposure. Public addresses with passwords, open defaults and alert-only designs leave the port reachable.

RPO defines how much recent data can be lost, expressed as the time since the last recovery point. RTO covers how long recovery may take, while MTBF and uptime percentages describe reliability rather than acceptable data loss.

Network policies limit lateral movement between pods, and namespaces with quotas and RBAC separate tenants' resources and permissions. Root containers, host socket mounts and privileged containers all break isolation.

OAuth 2.0 and OpenID Connect provide delegated access and identity tokens that APIs can validate, including expiry and issuer. Shared passwords, IP allowlists alone and shared basic credentials do not identify individual users or validate tokens.

SAST analyses source code and build artefacts early, which is where injection patterns can be caught before deployment. Load testing, production-only testing and uptime monitoring either come too late or measure different qualities.

Reading secrets at run time from a managed store, with access limited to the function's identity, keeps them out of code and configuration. Plain environment variables, repositories and logs all expose the password to anyone who can read those places.

Parameterised queries separate the SQL statement from the data, so user input cannot change the query's structure. Escaping one field, length limits and moving the concatenation into a procedure all leave the injection path open.

Allowlist validation, output encoding and schema validation each block malformed or malicious input at a different point in the request path. Verbose errors leak internals, and permissive parsing widens the attack surface.

Centralising logs in a restricted security account keeps them tamper-resistant and gives the SIEM one view across accounts. Per-account checks are slow, deleting logs removes evidence, and developer workspaces lack the access separation the SOC needs.

Triaging against real exposure, then fixing through the rebuild pipeline and verifying the result, closes the risk. Ignoring the finding, switching off the scanner and publishing the details do not reduce the risk to the workload.

Disabling the key and revoking its sessions stops further misuse, and the audit logs then show what happened. Deleting logs destroys evidence, emailing keys spreads the secret, and copies of the key widen the exposure.

Continuous monitoring against a defined baseline detects drift as it happens and alerts the team. Annual manual checks, unrestricted changes and an unlinked spreadsheet cannot detect drift in time.

Egress metrics with an alert threshold surface spikes quickly, and logs show the identities behind them. Monthly bills, yearly reviews and uptime checks are too slow or measure different things.

A SOC 2 Type II report gives independent assurance of control operation over a period, which is the evidence auditors need. Brochures, status history and self-assessments are not independent attestation.

A data return and deletion clause sets how and when data is returned or destroyed, with evidence of destruction. Marketing clauses and clauses that allow indefinite retention or sale of data work against the customer's control.

Mapping the data flows and assessing each transfer lets the team choose contract and technical safeguards that meet the adequacy rules. Shared keys, random moves and deleting logs do not satisfy the requirement and remove the evidence of compliance.

Regimes such as GDPR require a lawful basis and documented purposes, along with breach notification to the authority within a set period. Publishing customer lists, paper storage and selling data are not required and conflict with privacy obligations.

Accountability requires the organisation to demonstrate compliance, and auditable access records are the evidence for it. Minimisation, portability and erasure rights address different obligations and do not themselves require access records to be produced.