A company's security team plans a penetration test of its IaaS tenancy and proposes including attacks against the shared storage service and the hypervisor because a weakness there could affect its workloads. What should the team do before testing begins?
Select an answer to reveal the explanation.
Short Explanation
Renting an apartment lets you test your own door lock, not kick in the building's boiler room. Your pen test lives inside the provider's rules of engagement and your own resources. The trap is reasoning that because shared infrastructure affects you, you're allowed to attack it.
Full Explanation
Cloud providers publish penetration testing policies that state which customer resources may be tested, which activities are prohibited, such as denial-of-service attacks or attempts against shared infrastructure, and whether notification or approval is required. A sound test therefore begins with written rules of engagement that define scope limited to customer-owned assets, permitted techniques, time windows, contacts and authorization, aligned with the provider's policy. Attacking the hypervisor or shared storage targets infrastructure the customer does not own and that serves other tenants, so it breaches the terms of service and could harm third parties; assurance for those layers comes from provider attestations instead. An unannounced test of all resources risks triggering the provider's abuse response, account suspension or legal action, and still lacks the authorization that makes testing lawful. Skipping the test on the strength of a SOC 2 report misreads shared responsibility: that report covers the provider's controls, not the customer's configurations, applications and identities. Exam caveat: rules of engagement should also cover data handling, evidence of findings and stop conditions. Operational check: confirm a signed authorization lists every in-scope account and resource, cites the provider policy version reviewed and names the escalation contacts.