Google Cloud Platform Basics

01Purpose and scope

• This manual supports the course Google Cloud Platform Basics. It describes how practitioners who create, configure, and run resources in Google Cloud actually do that work, from the first project and billing link through routine operation of virtual machines, storage buckets, and managed databases.
• The scope covers the resource hierarchy, projects, identity and access management, billing accounts and budgets, core networking concepts, and the basic compute, storage, and data services that most new users touch first. It also covers the habits that keep those resources manageable, such as naming, labeling, logging, and cleanup. It does not cover advanced architecture design, certification preparation, or industry-specific regulatory requirements, which need their own references.
• The practice looks different depending on context. A single developer running a sandbox project can work mostly in the Cloud Console with minimal process. A team operating customer data in a regulated organization usually needs a formal landing zone, organization policies, approved service lists, and change records. The same tools apply in both settings, but the amount of gating, documentation, and review grows with the cost of a mistake. Most of the trade-offs in this manual come from that tension between speed and control.

02Core principles

• Resources in Google Cloud sit inside a hierarchy. An organization node sits at the top when a Google Workspace or Cloud Identity domain is in place. Folders group projects by team, environment, or business unit. Projects are the main boundary for resources, quotas, APIs, and billing. Most day-to-day decisions are about which project a resource belongs in and which identities can act on it.
• Access should follow least privilege. Grant predefined IAM roles at the smallest scope that lets someone do the job, and prefer groups over individual user grants so that access can be reviewed and removed in one place. Basic roles such as Owner, Editor, and Viewer are broad and often more permissive than people expect. Treat them with suspicion in any project that holds real data.
• Billing is attached to projects through a billing account. Charges accrue for resources that run or store data, and some charges continue after an application appears idle, such as disks, static IP addresses, snapshots, and logs. Cost is therefore a design concern, not only a finance concern.
• Managed services reduce operational work because Google runs the underlying infrastructure, but they also create dependencies on specific APIs, quotas, and service behaviors. Virtual machines give more control over the operating system and are easier to move conceptually from other data centers, but they require patching, backups, and monitoring that a managed service may handle for you. Choose on purpose, not by habit.
• Location matters. Resources are created in regions and, for some services, zones. Latency, availability design, and data residency obligations all depend on location. Where a regulation or contract restricts where data may be stored or processed, the choice of region is a compliance decision and should be recorded as one.

03Planning and preparation

• Before creating anything, confirm who owns the Google Cloud organization or the billing account. In many companies the person who first signs up becomes the only billing administrator, which later causes problems when that person changes roles. Establish at least two people with billing administration rights, stored as a group where possible, and document where the billing account is linked.
• Decide on a naming and labeling convention. A common pattern is to include the environment, application, and owner in project names and to apply labels such as cost-center, environment, and data-classification to resources. Project IDs are globally unique and cannot be changed after creation, so choose them carefully. Display names can be changed later.
• Choose a region for each workload based on user location, service availability for the required resource types, and any data residency rule that applies. Record the reason for the choice. If you are not sure whether a dataset may leave a given country or region, stop and ask the data owner and the relevant compliance function. Do not infer the answer from a technical default.
• Set up a budget with alerts at the billing account or project level before deploying anything expensive. Budgets send notifications when thresholds are crossed, but they do not stop spending by themselves. Decide in advance who receives alerts and what the response is.
• Prepare tooling. The Cloud Console is adequate for learning and for one-off tasks. The gcloud command-line tool and Cloud Shell are better for repeatable steps, and infrastructure-as-code tools such as Terraform are common once a team grows. Pick one primary method for changes so that the environment does not drift between what the console shows and what the code describes.

04Recommended workflow

1. 1
   : Create or confirm the organization structure. Place a new project under the right folder so that inherited policies and IAM bindings apply as intended. If no organization exists, note that projects will be personal and not subject to central policy, which affects later governance.
2. 2
   : Create the project and link it to the billing account. Set the project ID, display name, and labels at creation time. Confirm in the billing section that the project appears under the intended billing account before enabling any paid API.
3. 3
   : Grant access through groups. Add the team group to the project with the narrowest predefined role that covers the tasks. Review any service accounts and grant them roles only for the APIs and resources they call. Avoid downloading service account keys. Where keys are unavoidable, record who holds them and set a rotation plan.
4. 4
   : Enable only the APIs you need. Each enabled API is an additional surface for configuration and cost. Enabling Compute Engine, Cloud Storage, or BigQuery is a deliberate choice that should match the planned workload.
5. 5
   : Create the network and first resources. The default network exists in many projects and includes firewall rules that may be broader than intended. For anything beyond a test, create a dedicated VPC with subnets in the chosen region and write firewall rules that allow only required ports from known sources. Launch virtual machines or other compute with explicit machine types and disk sizes, and attach labels as you create them.
6. 6
   : Configure logging, monitoring, and backups. Confirm that Cloud Logging captures the logs your team needs and set retention periods to match policy. Create uptime or resource alerts in Cloud Monitoring for services that users depend on. Turn on backups or snapshots for data stores and test a restore at least once, because an untested backup is only a guess.
7. 7
   : Review cost and access after the first week and then on a regular schedule. Compare actual spend with the budget, look for idle or oversized resources, and check the IAM policy for new broad grants. Record what you changed and why in the project documentation. Remove test resources that are no longer needed, including disks and load balancers that continue to bill after the workload stops.

05Quality checks, risk controls and compliance

• Good practice relies on a small set of recurring checks. Review IAM bindings for primary principals, basic roles, and external identities. Confirm that Cloud Storage buckets are not publicly accessible unless the data is meant to be public. Check firewall rules for ranges such as all internet addresses on administrative ports. Verify that audit logs are enabled for the services in use and that someone is reading the relevant alerts.
• Organization policies let administrators restrict behaviors across the hierarchy, such as limiting which regions resources may be created in or disabling service account key creation. They are one of the strongest controls available, but they can break existing automation if applied without testing. Introduce them in a sandbox folder first and confirm that deployment pipelines still succeed.
• Security Command Center and the recommender features in the Console can surface misconfigurations and rightsizing suggestions. Treat these as inputs for review rather than automatic fixes. A recommendation to downsize a virtual machine should be checked against the workload's peak demand and any scheduled jobs before it is applied.
• Compliance depends on jurisdiction, industry, and contract. Privacy laws, sector rules, and customer agreements may restrict data location, access logging, encryption requirements, or vendor reviews. Google publishes compliance documentation and data processing terms, and the current text of those documents, along with the applicable regulator's guidance, is the authoritative source. This manual does not summarize legal requirements, and it does not replace qualified legal, security, or privacy professional judgment, approved internal procedures, or required authorization before processing regulated or high-risk data.
• Keep a record of exceptions. When a team needs a broader role, an unusual region, or a public endpoint, document the business reason, the approver, the review date, and the planned end point. Exceptions that never expire become standing risks.

06Collaboration and documentation

• Each project should have a named owner, a technical contact, and a billing contact, recorded in labels or in a shared inventory. When people change roles, these fields must be updated during the handoff rather than discovered during an incident.
• Keep a short runbook per project covering the architecture at a high level, the deployment method, the location of logs and dashboards, the backup and restore procedure, and the escalation path. Write it so that someone who did not build the system can follow it at two in the morning. Store it where the team already works, and link it from the project labels or description field.
• Changes should go through the same channel every time. Use a ticket or pull request that states the purpose, the affected projects, the expected cost change, and the rollback method. For console changes made in an emergency, record them within the same working day and reconcile them into code later so the next deployment does not reverse them.
• Design decisions deserve brief written records. A decision note can state the options considered, such as managed database versus self-managed database on virtual machines, the reason for the choice, and the conditions under which it should be revisited. These notes save time when a new team member asks why something is built the way it is.

07Measures and continuous improvement

• Useful indicators are operational and financial rather than abstract. Track the share of projects that have an owner label and a billing contact. Count the number of identities with basic roles at the project or organization level and aim for a downward trend. Compare monthly spend with budget for each project and note the largest variances with explanations. Track the amount of spend that has no cost-center label, since unlabeled spend is hard to allocate and hard to challenge.
• Track reliability and recovery measures for production-facing services. Record how often alerts fire, how many were actionable, how long recovery took, and whether restore tests succeeded. Do not set numerical targets without a baseline from your own environment, because a target copied from another organization may be unrealistic or irrelevant to your risk profile.
• Review the measures at a regular team meeting. Pick one or two changes each cycle, such as tightening a firewall rule set, removing an unused service account, or adding a label requirement to the creation template. Measure whether the change worked and keep it only if it did.
• Trade-offs appear here as well. Stricter organization policies reduce risk but slow down experimentation. Aggressive cost controls can cause outages if they shut down resources automatically without warning. Tune controls to the cost of failure in each environment and be explicit about who accepts the residual risk.

08Common mistakes and how to prevent them

• Granting the Owner or Editor role to a whole team for convenience is the most frequent problem. It is hard to review and easy to misuse. Prevent it by creating a custom or predefined role map at the start, using groups, and scheduling periodic access reviews.
• Leaving test resources running after a demonstration is the most common cost surprise. Prevent it by labeling every experimental resource with an expiration date and running a weekly cleanup query or review, and by setting budget alerts with a low threshold for sandbox projects.
• Relying on the default network without checking its firewall rules exposes services unintentionally. Prevent it by creating a dedicated network for each workload and removing or restricting default rules that are broader than needed.
• Creating a public Cloud Storage bucket because a link needed to work quickly is another frequent error. Prevent it by using signed URLs or granting access to specific identities, and by enabling organization policies that block public access where appropriate.
• Assuming that a free trial or free usage tier covers everything is risky. Free allowances apply to specific services and quantities and change over time, so check the current pricing documentation for each service before relying on it.
• Downloading service account keys and storing them in source code or shared drives creates long-lived credentials that are often forgotten. Prevent it by using workload identity features where available, attaching service accounts to resources directly, and auditing any key that exists.
• Skipping restore tests gives a false sense of security. Prevent it by scheduling a restore into a separate project at least periodically and recording the time it took and what was missing.

09Practical checklist

• Confirm the organization, folder, and project placement before creating resources.
• Link each project to an approved billing account and confirm two billing administrators exist.
• Set a budget with alert thresholds and name the recipients for each alert.
• Apply owner, environment, cost-center, and data-classification labels at creation.
• Grant access through groups using the narrowest predefined role that fits the task.
• Confirm no service account keys exist unless an approved exception is recorded.
• Enable only the APIs required by the planned workload.
• Create a dedicated VPC and review firewall rules for broad source ranges.
• Confirm storage buckets and other data stores are not publicly accessible unless intended.
• Verify that audit logs are enabled and that alerts route to a monitored destination.
• Test a backup restore and record the result and duration.
• Document the region choice and the data residency basis for it, with input from the data owner.
• Review cost, idle resources, and IAM grants on a fixed schedule and record changes.
• Update the runbook and handoff contacts whenever ownership changes.

★Learning sources

• Micro Degree: Google Cloud Platform Basics
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Generative AI Applications