Safety Norms: Google Cloud Platform Basics

1Purpose, scope, and safety principles

These norms guide safe, compliant use of Google Cloud Platform for learners and early-career practitioners. They explain how to create and manage resources, control who can reach them, protect the data they hold, test changes without harming others, and respond when something goes wrong. The goal is to prevent avoidable exposure, outages, cost overruns, and privacy failures before they reach real users.

The scope covers the organization, folders, and projects in the Google Cloud console, the gcloud command-line tool, client libraries, infrastructure-as-code files, and sandbox or shared projects used for training. It applies to any system that stores company, customer, or personal information. Cloud infrastructure is operated by Google, but customers remain responsible for how they configure identity, networking, data, and workloads under the shared responsibility model described in provider documentation.

• Mandatory: never use production data, customer records, or real personal information in training projects unless an approved authorization covers it.
• Mandatory: perform only the actions your written authorization allows, in projects you are assigned to.
• Recommended: apply least privilege, defense in depth, deny by default, separation of environments, and traceable change as default design principles.

2Roles, competence, and accountability

Every project should have a named owner, a billing contact, and a security contact recorded in the resource inventory. Owners approve access, accept risk, and make sure resources are removed when no longer needed. Learners and operators act only within the duties their role describes and escalate anything outside it.

Competence comes before privilege. Complete formal training on identity, networking, and data protection before receiving any role that can change IAM policy, networks, or stored data. Sandbox work is the place to practice. Access to shared or production projects requires documented approval from the project owner and, where applicable, the security team. Verify your organization's current requirements; professional certifications and internal authorization rules vary by employer and jurisdiction, and this document does not confer any credential.

• Organization administrator: manages the resource hierarchy, organization policies, and billing structure.
• Project owner: approves members, roles, and resource lifecycle for the project.
• Security reviewer: reviews firewall, IAM, encryption, and logging changes before production.
• Workload owner: maintains application configuration, data classification, and recovery targets.
• Learner: follows norms, uses sandbox projects, and reports issues without attempting risky fixes alone.

3Course-specific hazards and risk assessment

Most harm in cloud work is caused by configuration and access, not by physical equipment. The hazards below are realistic for people learning the platform. Each is rated by likelihood and impact in a typical training or small-business setting. Ratings are educational starting points and should be adjusted by a qualified risk assessor.

• High: broad basic roles such as Owner or Editor granted to individuals or large groups, which allow far more change than most tasks need.
• High: service account keys downloaded to laptops, repositories, or chat threads, where they can be copied and used without the person's knowledge.
• High: Cloud Storage buckets or objects made public by an IAM binding to allUsers or allAuthenticatedUsers when they should be private.
• High: firewall rules that expose administrative ports such as SSH or RDP to all internet addresses.
• Medium: forgotten virtual machines, disks, or static IP addresses that continue to incur charges without an owner.
• Medium: personal or regulated data copied into test environments with weaker controls.
• Medium: logs that record secrets, tokens, or personal data and are then read by too many people.
• Medium: changes made directly in the console with no review, record, or rollback plan.
• Low to medium: accidental deletion of a resource that lacks deletion protection or verified backups.
• Lower but still important: testing against a system, domain, or address range that you do not own or have written permission to test.

4Preventive controls and safe work practices

Require multi-factor authentication for every human account, use Google groups or Cloud Identity groups to grant roles, and assign the narrowest predefined or custom role that completes the task. Avoid basic roles in production. Review bindings before saving them and record the reason in the change ticket. Where an organization policy is available, use it to block risky patterns such as service account key creation or public access to storage, but only after the administrator confirms the effect on existing workloads.

Prefer short-lived credentials, such as attached service accounts for workloads or workload identity federation, over long-lived downloaded keys. If a key is unavoidable, record its owner, purpose, and expiry in the inventory, store it in Secret Manager rather than in code, and rotate it on a schedule set by policy. Never commit keys, passwords, or tokens to source control, screenshots, or tickets.

Separate development, test, and production into different projects with different owners and access lists. Before any command that changes state, confirm the active project and account with gcloud config list, use plan or preview steps where the tool provides them, and avoid running destructive commands in a shell whose context you have not checked. Use labels and consistent naming so every resource has an owner and a purpose.

Enable budgets and billing alerts for every project, and check that alerts reach a monitored address. Turn on deletion protection for critical resources and keep tested backups or snapshots before major changes. Make infrastructure changes through version-controlled code with peer review rather than manual console edits, except in documented emergencies.

Open network paths only when required. Default to private addresses, restrict ingress to named sources, and use managed access methods such as identity-aware access for administration where available. Treat any rule with 0.0.0.0/0 as requiring security reviewer approval and a documented expiry.

• Mandatory: enforce multi-factor authentication for all human accounts with administrative access.
• Mandatory: no downloaded service account keys in shared locations, source repositories, tickets, or chat.
• Mandatory: all IAM changes to shared or production projects require peer review and a recorded reason.
• Recommended: use infrastructure as code with pull request review for network, IAM, and storage configuration.
• Recommended: run periodic checks for publicly exposed storage and unused resources.

5Equipment, environment, information, and protective safeguards

Your workstation is part of the cloud trust boundary. Use an organization-managed device with current operating system updates, full-disk encryption, screen locking, and endpoint protection. Do not use shared or generic accounts for console or CLI access. Avoid administrative sessions over unmanaged networks, and close sessions when leaving a device unattended. Physical data centers are operated by the provider, but your own devices, removable media, and printouts are your responsibility.

Information controls start with classification. Label data as public, internal, confidential, or regulated according to your organization's scheme, then match storage location, encryption, and access to that label. Minimize personal data and use synthetic or masked data for learning. Choose regions that meet residency and contractual requirements, and confirm them with the privacy team, since legal obligations are jurisdiction-dependent. Use Cloud KMS for managed encryption keys and customer-managed keys where policy requires them. Enable Cloud Audit Logs and make sure logs exclude secrets and unnecessary personal data.

• Mandatory: store secrets only in Secret Manager or an approved vault, never in code or environment files committed to repositories.
• Mandatory: use managed or approved encryption for data classified as confidential or regulated.
• Recommended: use Cloud Logging retention and access controls matched to the sensitivity of the logged data.
• Recommended: apply data loss prevention scanning where data volumes or policy justify it.

6Incident reporting, emergency response, and escalation

An incident is any event that exposes data, changes access without approval, causes unplanned outage or cost, or breaks a safety control. A near miss is an event that could have caused one, such as a public bucket found by a scanner before anyone accessed it. Report both within the reporting window set by your security policy, and never wait to confirm the full picture before alerting the security contact.

When an incident is suspected, stop further changes to the affected resources, do not delete logs or instances that may hold evidence, and notify the security contact and project owner immediately. Revoke or disable suspect credentials following the approved runbook, and use Cloud Audit Logs and Cloud Logging to establish who did what and when. Do not attempt to hunt attackers or retaliate. Cloud outages and billing spikes follow the same escalation path. If a person is injured or in immediate danger from a physical site or a safety-critical system, contact local emergency services first and then the incident lead. Breach notification duties are jurisdiction-dependent and must be decided with legal and privacy professionals.

• Step 1: contain by disabling the affected key, pausing the affected change, or restricting the affected binding, if the runbook permits.
• Step 2: preserve logs, configuration snapshots, and relevant ticket history.
• Step 3: notify the security contact, project owner, and incident lead with what is known, what is not, and the time of discovery.
• Step 4: conduct a blameless review within the period set by policy, recording root cause, control gaps, and corrective actions.

7Records, training, inspection, and review

Maintain a current inventory of projects, owners, purposes, data classifications, billing accounts, service accounts, and key holders. Keep approvals, access grants, and change records together so an auditor or incident lead can reconstruct decisions. Records should be retained according to organizational retention rules and legal duties, which vary by jurisdiction.

Training should be role based. Every learner completes foundational instruction on identity, data handling, and reporting before sandbox access. Operators complete additional training before production access and refresh it on a periodic schedule. Inspections combine automated checks, such as security posture findings from Security Command Center where enabled, with manual access reviews. Review findings in a meeting, assign owners and due times, and feed lessons into updated norms.

• Record every project with an owner, purpose, and data classification.
• Review IAM bindings on production projects at a periodic interval set by policy, removing unused or excessive grants.
• Track metrics such as open high-risk findings, overdue access reviews, and resources without owners.

8Responsible use and continuous improvement

Responsible use means respecting the people whose data and systems you touch, using cloud resources only for authorized purposes, and not building tools that scan, probe, or access systems you do not own. Do not use the platform to bypass controls, run unapproved workloads, mine resources without approval, or store material you are not permitted to hold.

Treat these norms as a starting point. Adapt them through your organization's approved safety and security process, verify all laws, standards, and provider terms with competent authorities or qualified professionals, and update them after incidents, platform changes, or significant new services. This guidance is educational and does not replace formal training, supervision, or approved procedures.

Implementation checklist

• Confirm you have written authorization for each project and action.
• Enable multi-factor authentication on your account.
• Check the active project and account before running any change.
• Assign the narrowest role that completes your task.
• Keep keys out of code, tickets, and chat; use Secret Manager.
• Set budgets and alerts on every project.
• Confirm storage and firewall rules are not public unless approved.
• Label data and confirm its region and encryption requirements.
• Report suspected incidents and near misses immediately.
• Delete or record every sandbox resource when the exercise ends.