Cloud penetration testing adds contractual and architectural boundaries to the normal rules of engagement. A customer may control an application, virtual machine, cloud account, or identity configuration without controlling the underlying provider infrastructure. For CompTIA PenTest+ PT0-003 candidates and practitioners, shared responsibility should therefore be treated as a map of control ownership, not as blanket permission to test anything reachable from a cloud account.
The current CompTIA Cloud+ CV0-004 perspective is also useful because the tester needs to understand which controls belong to the customer at the IaaS, PaaS, and SaaS layers. Provider testing policies change, so every engagement should verify the current rules before activity begins. Recheck them if the engagement is delayed, extended, or expanded to a new service. A provider can add or remove permitted services, change notification expectations, or introduce separate requirements for activities such as command-and-control simulation, load testing, or managed-security products. Authorization from the customer and permission under the provider’s terms are separate requirements.
Shared responsibility defines control ownership, not testing permission
In IaaS, the customer usually controls more of the guest operating system, applications, identities, and network configuration. In managed PaaS, the provider controls more of the platform while the customer still controls data, identities, application logic, and selected configuration. In SaaS, the customer may control users, tenant policy, and data while having little or no right to test the service implementation itself.
The penetration-test scope should identify which layer is being assessed. Testing a customer-owned virtual machine is different from testing the provider’s hypervisor. Reviewing tenant authorization in a SaaS application is different from attempting to probe the shared backend. A shared-responsibility diagram helps only if it is translated into explicit in-scope assets and permitted actions.
Provider policies must be checked immediately before the engagement
Cloud providers publish security-testing terms that can differ by service and activity. AWS permits customer security assessments without prior approval only for the services enumerated in its penetration-testing policy; AWS infrastructure and managed services themselves remain outside customer testing authorization. Testing involving command-and-control infrastructure requires prior AWS approval, and denial-of-service testing has separate strict requirements. Treat the permitted-service list and any special approvals as dated evidence rather than a blanket cloud-account permission. Microsoft directs customers to its cloud penetration-testing rules of engagement. Other providers and SaaS vendors use their own requirements.
Treat provider policy as versioned engagement evidence. Keep a copy or reference in the engagement file so reviewers can understand which terms governed the test. Large organizations may also have internal cloud guardrails that are stricter than the provider policy; both layers should be satisfied before activity begins. Record the policy location and date checked, note any notification or approval requirement, and identify prohibited activities. If the planned technique is not clearly covered, pause and seek clarification rather than assuming a generic customer authorization overrides platform terms.
IaaS testing should separate workload security from provider infrastructure
Customer-controlled IaaS workloads can include operating systems, applications, security groups, identities, storage, and virtual-network configuration. Define how snapshots, images, autoscaling groups, and infrastructure-as-code resources are handled because a test change can be recreated automatically or copied into new instances. Rollback plans should account for those automation paths. A test can evaluate whether those controls expose customer data or allow unauthorized access while staying away from provider management planes and neighboring tenants that are outside scope.
Cloud metadata, instance identities, attached roles, network paths, and storage permissions can create high-impact customer-side risk. The assessment should focus on whether the customer’s configuration and applications enforce intended boundaries. Demonstrating customer misconfiguration does not require probing the hypervisor, control-plane internals, or infrastructure owned solely by the provider.
PaaS and managed services require service-specific boundaries
Managed databases, serverless platforms, API gateways, container services, queues, and analytics platforms expose configuration and application surfaces without giving the customer control over the underlying host. Determine whether the assessment is validating customer configuration, application logic, or service permissions, and avoid techniques that attempt to inspect or influence provider-managed internals. The test plan should identify which interfaces the customer is authorized to assess and which behaviors are managed by the provider.
Rate limits, service quotas, automated scaling, and shared infrastructure make availability risk especially important. A small validation can often prove a control weakness without generating high volume. If an assessment requires stress, resilience, or load testing, treat that as a separate activity with explicit provider and customer approval.
SaaS assessments focus on the tenant controls the customer owns
In SaaS, useful testing often centers on identity, role design, tenant isolation exposed through supported functionality, data-sharing configuration, integrations, session controls, and administrative policy. The customer may have no authorization to scan or fuzz the provider’s service endpoints beyond normal tenant use.
Third-party SaaS integrations also create trust paths. If a potential issue appears to be in the provider’s shared service rather than the customer’s tenant configuration, stop testing that path and use the provider’s security or vulnerability-reporting channel. The client’s authorization cannot convert a provider-owned vulnerability into an in-scope target. OAuth grants, API tokens, webhooks, synchronization accounts, and marketplace applications can expand what a compromised tenant identity can reach. The engagement should determine whether those connected services are in scope and whether the customer has authority to test them.
Cloud identity and authorization should receive first-class attention
Cloud environments are heavily controlled by identity policy. Human users, service accounts, workload identities, federated principals, API keys, temporary credentials, and automation roles can all carry permissions. The assessment should compare granted privileges with the business purpose of the identity and verify that high-impact actions require appropriate authentication and authorization.
Use designated accounts and least-impact validation. Review federation and workload-identity trust as well as static keys. Temporary cloud credentials, role assumption, service principals, and CI/CD identities can create powerful cross-account paths even when no long-lived password exists. The finding should explain which trust relationship granted the access. Cloud remediation should name the policy object or configuration owner, not merely recommend “reduce permissions.” Useful findings identify the role, scope, trust condition, and business workflow that need redesign so the client can correct the access without breaking necessary automation. If an identity appears overprivileged, prove only the access needed to support the finding. Avoid modifying production resources or accessing unrelated data when a read-only or synthetic test can demonstrate the control problem. Cloud testing should reduce uncertainty without creating a new incident.
Data boundaries and multi-tenant risk require conservative evidence handling
Cloud systems can expose large data sets quickly. The rules of engagement should define which storage locations, databases, logs, and backups may be inspected and how much data may be collected. Use synthetic records or minimal samples when possible. Finding a path to sensitive data is different from needing to copy the data.
If the tester encounters another customer’s information, provider-managed secrets, or resources whose ownership is unclear, stop and escalate. Data residency and privacy rules may also limit where test evidence can be stored. Agree in advance whether cloud logs, screenshots, or exported configuration can leave the region or tenant where they were generated. Multi-tenant boundaries are a hard authorization line. The objective is to assess the client’s security posture, not to use accidental cross-tenant access as permission for further exploration.
Logging and evidence should capture cloud context
Cloud findings need enough context to reproduce the issue: account or project, region, resource identifier, identity, policy state, relevant audit event, and the expected versus observed behavior. Cloud resources are ephemeral, so screenshots alone can become misleading after an autoscaling event or redeployment.
Preserve provider audit logs and configuration evidence when the rules allow it. Coordinate alert expectations with cloud SOC teams, managed security providers, and platform owners so automated containment does not create unexpected outages. If the exercise is intended to test detection, define what the control group will do if safety thresholds are crossed. Correlate test activity with timestamps so defenders can distinguish authorized testing from unrelated malicious activity. If the engagement intentionally triggers alerts, coordinate with the SOC so the exercise measures detection without creating confusion during a real incident.
Cleanup and reporting should restore the cloud environment to a known state
Closeout should remove temporary identities, tokens, rules, test files, snapshots, and other artifacts created during the assessment. Verify that infrastructure-as-code repositories and automation pipelines do not re-create the artifacts after cleanup. A cloud environment can look clean immediately after the test and then restore an insecure rule during the next deployment. Include a post-cleanup validation after the next normal deployment or configuration sync when feasible. This catches drift between the live environment and the declarative configuration that actually governs future state. An operational cloud engagement must leave the client with a verified cleanup record and reproducible findings.
Report responsibility boundaries clearly: which control was customer-managed, which provider policy constrained testing, and what remediation the customer can actually perform. Assign findings to the team that owns the control—application, identity, networking, cloud platform, or vendor management—so shared responsibility becomes actionable ownership instead of a vague explanation. A good cloud penetration test demonstrates risk without confusing shared responsibility with shared authorization. The engagement should finish with a responsibility matrix that names who owns each remediation, which provider constraint influenced the assessment, and what evidence will be used to verify the fix after the cloud environment changes.
Provider terms and tenant boundaries should be checked before the first intrusive test. A technique that is acceptable on an owned virtual machine may be prohibited against a managed control plane or may create risk for shared infrastructure. Record the permitted services and test identities explicitly, then use cloud audit logs to prove which actions came from the assessment and which came from normal platform activity.