0.5 Ethics, cloud provider policy, and not setting money on fire

Everything from G1 Ch 0.6 still applies: attack only what you own, what is a purpose-built target, or what you have written authorisation for. Three additions specific to this guide:

   1. CLOUD PROVIDER PENETRATION-TESTING POLICY.
      AWS, GCP, and Azure permit customer-initiated testing of YOUR OWN
      resources without prior approval, EXCEPT for a named list of
      prohibited activities (DoS/DDoS simulation, testing other tenants,
      testing the provider's own infrastructure, certain managed services).
      Read the current policy for each provider before you start. Never
      point cloud attack tools (pacu, ScoutSuite, CloudFox) at an account
      you don't control.

   2. NO CRYPTOMINING, NO "JUST SEEING IF IT WORKS" ON SHARED INFRA.
      The single most common real cloud incident is a leaked key used to
      spin up mining instances (denial-of-wallet). Don't create that
      pattern even in your own lab -- you'll train bad reflexes and risk a
      real bill. Budget alerts are a control, not a safety net.

   3. RESPONSIBLE DISCLOSURE STILL MEANS STOP.
      If a lab exercise or a legitimate engagement surfaces a real issue in
      a third party's cloud config (an open bucket, an exposed dashboard):
      stop, don't enumerate, don't download, report via security.txt or a
      bug-bounty channel. "I was just confirming the finding" is how people
      get prosecuted.

   Dangerous: many techniques in Parts 4 and 6 (container escapes, request
   smuggling against a shared front-end, SAML forgery) can damage or
   compromise multi-tenant systems. Every one is written for a lab you own
   or a target built for the purpose. There is no exception for "our
   staging" without written sign-off and a defined window.