Opening a Google Cloud account takes ten minutes, but doing it well is the difference between an environment that grows in an orderly way and one that is impossible to audit six months later. In this lesson Marta signs AlpinaShop up to Google Cloud: we will look at what you need before you start, what the free tier really includes (and what it does not), why a company should not build its cloud on a personal Gmail account, how to create the billing account and the first project alpinashop-dev, how to enable the service APIs and —most importantly— how to set budgets and billing alerts before switching on the first resource.

That last part is not optional. The classic cloud horror story is the unexpected four-figure bill for something left running. It is avoided with fifteen minutes of configuration on day one.

1. Prerequisites
2. The free tier: free trial credit and "Always Free"
3. Personal account versus Cloud Identity or Workspace
4. Creating the billing account and the alpinashop-dev project
5. Enabling the service APIs
6. Budgets and billing alerts from day 1
7. Security hygiene for the initial account

To create a Google Cloud account you need three things:

Points that usually raise doubts:

• Will I be charged without warning during the free trial? No. While you are in the trial period with credit, Google does not charge automatically when it runs out: resources are stopped and you have to activate the paid account manually. That is deliberate behaviour to avoid nasty surprises. Even so, once the paid account is activated, billing is real and has no ceiling: hence the budgets in section 6.
• Does a prepaid or virtual card work? It depends on the issuer. Google requires it to accept recurring charges; many prepaid cards are rejected. Virtual cards from Spanish banks usually work as long as they are not single-use.
• Can I use a company account from the start? Yes, and it is the recommended approach for an organization. We look at it in section 3.

Google Cloud combines two distinct free mechanisms that are frequently confused:

When you first sign up you receive a credit (historically around 300 USD) valid for about 90 days. It is more than enough to follow this entire course if you are disciplined about switching resources off. It is spent on any paid service, including VMs and BigQuery.

Independently of the credit, some services have a permanent free quota. These are representative examples, whose exact limits you must check on the official free tier page because they change:

Two important nuances:

• The geographical restriction on the Always Free tier for Compute Engine and Cloud Storage is real. The free e2-micro only exists in certain US regions. Since AlpinaShop will work in europe-west1 for reasons of latency and data residency, its VMs will not be free. It is a conscious decision: for a Spanish company, saving a few euros at the cost of serving from Iowa is not worth it.
• The free tier does not cover outbound traffic or reserved external IP addresses that go unused. Both are common sources of small but constant charges.

Always check. The figures above are orders of magnitude as at the time of writing. Free tier limits, prices and the regions included all change. Consult the official pricing and free tier documentation before assuming that something is free.

Here lies the most structural decision in this lesson, and the one that is most expensive to correct later.

When you sign up with an @gmail.com account, Google Cloud creates your projects without an organization: loose projects, owned by an individual, with no hierarchy and no central policies.

Cloud Identity is the key and little-known piece: it is an identity management service that gives you corporate users and groups tied to your domain without needing to buy Google Workspace (that is, without paying for corporate Gmail or Drive). Its free version covers a limited number of users, more than enough for a 40-person small business like AlpinaShop, and it is what enables the Organization node.

Marta registers the domain alpinashop.example in Cloud Identity, verifies ownership of the domain by means of a TXT DNS record, and creates corporate users:

• [email protected] (infrastructure)
• [email protected] (development)
• [email protected] (data)

In doing so, the alpinashop.example Organization node appears automatically, and every project created from that moment on will hang from it. The full hierarchy (Organization → Folders → Projects) is the subject of lesson 01-04.

If you are following the course in a personal capacity with a Gmail account, you can still do everything: you simply will not have an Organization node or folders. Whenever a lesson uses folders, the alternative will be indicated.

A billing account is the object that defines who pays and by what method. It is not the same as a project: projects consume resources, the billing account pays for them. A project with no billing account linked can only use free services, and most APIs will refuse to be enabled.

The path in the console is straightforward:

1. Go to console.cloud.google.com with the corporate account.
2. Navigation menu → Billing → Create account. Give the country (Spain), the account type (business), the tax details (company tax number) and the payment method.
3. Top menu → project selector → New project. Name: alpinashop-dev.
4. Check the project ID the console proposes. The name can be edited later; the ID cannot.

That last point deserves emphasis because it is irreversible: the project ID (projectId) is unique across the whole of Google Cloud, not just within your organization, and can never be changed. If alpinashop-dev were taken by another Google customer somewhere in the world, the console would propose something like alpinashop-dev-482913. Choose the ID carefully. The difference between projectId, projectNumber and the name is explained in depth in lesson 01-04.

The same steps with gcloud (the tool is explained in detail in lesson 01-06; here we use it only as a reference for what happens underneath):

A breakdown of what each command does:

• gcloud billing accounts list queries the billing accounts your user has permissions on. It returns the ACCOUNT_ID you need in step 3. If the list comes back empty, either you have not created the billing account or your user does not have the role to see it.
• gcloud projects create creates the project. The positional argument alpinashop-dev is the definitive projectId; --name is only the visible label.
• gcloud billing projects link associates the project with the billing account. It requires the billing.resourceAssociations.create permission on the billing account and ownership of the project: in other words, being a project administrator is not enough, you also need permission over billing. It is a deliberate separation of duties.
• gcloud config set project saves the active project in your local configuration.

In Google Cloud, every service is exposed as an API, and APIs come disabled by default in every new project. It is a security and clarity measure: it reduces the exposed surface and makes explicit what each project actually uses.

If you try to create a VM without having enabled compute.googleapis.com, the console will offer to enable it and the CLI will return an error along the lines of "API has not been used in project ... before or it is disabled".

Practical notes:

• Enabling can take a few seconds to propagate. If a command fails immediately after enabling an API, wait half a minute and retry before assuming there is a real problem.
• Enabling an API does not cost money; using it does. Even so, do not routinely enable the whole catalogue: every enabled API is attack surface and noise in the audit trail.
• The cloudresourcemanager.googleapis.com and cloudbilling.googleapis.com APIs are usually needed to manage projects and budgets through scripts.

This is the section you must not skip. A budget in Google Cloud is an object that watches spend and warns you when thresholds are crossed. It is worth being clear about what it does and does not do:

• It does: send email notifications to the billing administrators when the thresholds you define are reached, and it can publish a message to a Pub/Sub topic so that reactions can be automated.
• It does not: switch resources off or block spend by itself. A €50 budget does not prevent you spending €500. It is a smoke detector, not a fire extinguisher.

To actually switch resources off automatically you have to combine the budget with Pub/Sub and a Cloud Function that unlinks billing, something covered in lesson 07-05.

An explanation of each option, because each one has a consequence:

• --billing-account: budgets hang from the billing account, not from the project. That is why you need the billing administrator role to create them.
• --budget-amount=50EUR: the reference amount. There is also the option of basing the budget on the previous month's spend, useful when consumption is stable.
• --threshold-rule=percent=...: each rule generates a warning. Setting three is good practice: 50 % informs you, 90 % alerts you and 100 % forces you to act. You can add basis=forecasted-spend to be warned when the end-of-month forecast exceeds the threshold, which gives you room to react.
• --filter-projects: restricts the budget to a specific project. Without this filter, the budget watches spend across the whole billing account.

Depending on the SDK version you have installed, this command group may live under gcloud billing budgets or require the gcloud alpha billing budgets route. If the command does not exist, try the alpha prefix or check gcloud billing budgets --help.

For AlpinaShop, Marta puts the following in place from day one:

And a habit just as valuable as any configuration: reviewing the billing reports once a week during the first few months. They are found under Billing → Reports, broken down by project, service and SKU. An in-depth analysis of those reports is the subject of lesson 01-04.

The first account the organization creates accumulates enormous power: it can create projects, link billing and grant permissions to anyone. Treating it as a normal working account is an unnecessary risk.

Good practices from minute one:

1. Mandatory two-step verification. Enable it for every account in the organization, and preferably use a physical security key or the authenticator app rather than SMS. Google lets you impose it as a policy for the whole domain from the admin console.
2. Do not work day to day with the super administrator account. Marta should have two identities: her normal account [email protected], with the permissions she needs for her job, and a super administrator account used only for exceptional tasks (creating the organization, recovering access).
3. At least two super administrators. If there is only one and they lose access or leave the company, recovery is slow and painful. Two is the reasonable minimum; three if the team allows it.
4. An up-to-date recovery account and contact details, with an alternative email address that does not depend on the domain itself.
5. The least privilege principle from the start. Dani does not need to be a project owner in order to deploy; Lucía does not need network permissions in order to query data. Granting "Owner" to everyone "so it doesn't cause trouble" is convenient today and very expensive a year from now. The detail of IAM roles and policies is studied in lesson 03-04.
6. Permissions by group, not by person. Create groups such as [email protected] or [email protected] and grant the permissions to the group. When someone joins or leaves, you change the group membership and there is no policy to touch.
7. Never share credentials. If two people need the same thing, it is granted to two identities; a single one is not shared.

• Building the company's cloud on a personal Gmail account. Migrating to an organization later is possible but tedious: you have to move projects, redo permissions and transfer billing. If the cloud is for a company, start with Cloud Identity.
• Confusing the free trial credit with Always Free. When the credit runs out, whatever is still running is billed unless it falls within the Always Free quotas, which are small and often limited to US regions.
• Believing that a budget stops spend. It does not. It only warns.
• Creating the budget "once there is something deployed". Surprise spend appears precisely during the first experiments, which is when you still do not know what each thing costs.
• Choosing an ill-considered projectId. It is immutable and global. Adopt a convention (company-environment, company-workload-environment) and stick to it.
• Forgetting "invisible" resources. Persistent disks from deleted VMs, reserved external IPs with nothing attached, old snapshots and orphaned load balancers all generate charges even when nothing is "switched on".
• Tip: create alpinashop-dev first and only then alpinashop-prod. Learning in the project where there are no customers is cheaper in every sense.
• Tip: enable APIs as you need them, not all at once. The list of enabled APIs is good implicit documentation of what the project really uses.

Marta is torn between three options for signing AlpinaShop up to Google Cloud:

• A) Use her personal Gmail [email protected] to create the projects.
• B) Buy full Google Workspace for the company's 40 people.
• C) Register the domain alpinashop.example in Cloud Identity Free and create the technical team's identities there.

Argue which one you would choose, what concrete consequence each option has when Marta moves to another company two years from now, and in what case option B would be the right one.

Write the commands needed to:

1. Find the ID of AlpinaShop's billing account.
2. Create a budget named Presupuesto AlpinaShop Desarrollo of 30 euros a month applied only to the alpinashop-dev project, with warnings at 60 %, 90 % and 100 %.
3. Verify that it has been created.

Then answer this: if the project ends up spending €200, what will the budget have done?

An external consultant reviews another company's initial setup and finds this situation:

• There is a single super administrator, who also uses that account for daily email.
• Two-step verification is disabled.
• All five developers have the Owner role on every project "to speed things up".
• No budget is configured.
• The recovery email for the administrator account is the corporate account itself.

List the concrete risks of each point and the fix you would propose, ordered from most to least urgent.

Solution 1

The right option for AlpinaShop is C.

• With option A, the projects belong to an individual. When Marta leaves, the company is left with resources whose ownership has to be transferred manually one by one, with no Organization node, no folders, no central policies and no corporate audit logs. That is a business continuity risk, not merely an inconvenience.
• With option C, the alpinashop.example organization owns everything. When Marta leaves, her user is suspended and the resources remain intact and accessible to everyone else. Cloud Identity Free covers the users the technical team needs at no cost.
• Option B would be the right one if AlpinaShop also wanted Google's corporate email, calendar and storage (that is, if the decision were about the workplace, not just the cloud). Buying Workspace solely to be able to use Google Cloud is overpaying: Cloud Identity already provides the Organization node.

Solution 2

If the project ends up spending €200, the budget will have sent three warning emails (on passing €18, €27 and €30) and nothing more: spend will have carried on unimpeded up to €200. A budget warns, it does not block. To stop spend automatically you have to connect the budget to a Pub/Sub topic and to a function that reacts, something covered in lesson 07-05.

Solution 3

In order of urgency:

1. Two-step verification disabled. This is the most serious risk: one leaked password gives total control over the company's entire cloud. Immediate fix: enable 2FA on every account and impose it as a domain policy, preferably with a physical key for administrators.
2. Five owners and no privilege control. The Owner role allows entire projects to be deleted and permissions to be modified. Any mistake or compromised account is catastrophic. Fix: apply least privilege with specific roles, granted to groups rather than to individuals.
3. A single super administrator who also uses the account daily. A double risk: a single point of failure if they lose access, and constant exposure of the most powerful account to everyday email and browsing. Fix: create a second super administrator and a daily working account with normal permissions.
4. A recovery email inside the domain itself. If access to the domain is lost, the recovery route is lost too. Fix: configure an external alternative email address and a recovery phone number.
5. No budgets. This is an economic risk rather than a security one, which is why it comes last, but it is the easiest to fix: fifteen minutes to create budgets with alerts going to more than one recipient.

We now have an account. In this lesson we have looked at the prerequisites for signing up, the real difference between the free trial credit and the Always Free quotas (with the warning that many of them only exist in US regions and not in europe-west1), and why a company like AlpinaShop should rely on Cloud Identity over the alpinashop.example domain rather than on personal accounts. We have created the billing account and the alpinashop-dev project, understanding that the projectId is immutable and global; we have enabled the APIs of the services we will use; we have set up budgets with alerts at 50, 90 and 100 %, knowing that they warn but do not block; and we have established the minimum hygiene for the account: two-factor authentication, two super administrators, separate accounts for daily work and permissions by group.

Marta now has an empty project and an economic safety net. The next thing is learning to find your way around the environment: in the next lesson, A Tour of the GCP Console, we will go through the web interface piece by piece —project selector, navigation menu, search box, quotas, the APIs and services dashboard—, get acquainted with Cloud Shell and its editor, and compare the three ways of working with GCP (console, CLI and client libraries) so as to know when each is appropriate. Marta will leave the alpinashop-dev project set up with her favourite services close at hand.