The Google Cloud console is the visual gateway to the platform: a web dashboard from which you can create, inspect and delete any resource, review spend, read logs and open a terminal. Knowing it well speeds up learning enormously, because it lets you explore services without memorising commands and because every console screen shows you the equivalent gcloud command or REST call, which makes it the best tool for learning the CLI.

In this lesson we go through the console from top to bottom: the top bar and the project selector, the navigation menu and how to pin favourites, the resource search box, the home dashboard and its cards, where to check the project's status and quotas, and the APIs and services section. We will also introduce Cloud Shell and its built-in editor (as a preview only: using it in depth is lesson 01-06) and compare the three ways of working with Google Cloud so as to know when to use each. We will close with a hands-on walkthrough in which Marta leaves the alpinashop-dev project ready for the whole course.

1. Anatomy of the console: top bar and project selector
2. The navigation menu and pinned services
3. The resource search box
4. The home dashboard and its cards
5. Project status, quotas and limits
6. APIs and services
7. Cloud Shell and the editor, at a glance
8. Three ways of working with GCP
9. Hands-on walkthrough: Marta prepares alpinashop-dev

The console lives at console.cloud.google.com. The top bar is always present and contains, from left to right:

It is by some distance the element to be most careful with: everything you see and everything you create happens in the selected project. A considerable proportion of beginner incidents ("I deleted the wrong database", "I can't find the VM I just created") comes down to having had the wrong project selected.

Clicking it opens a dialog with two tabs, Recent and All, the latter showing the organization and folder hierarchy. Each project appears with its name and its ID. You can star projects to keep them at the top.

Practical tips:

• Always look at the projectId, not the name. Names repeat; IDs do not.
• The active projectId also appears in the selector itself, so a quick glance before any destructive action is enough.
• The console URL includes the project: console.cloud.google.com/compute/instances?project=alpinashop-dev. You can bookmark direct links to a service in a specific project, which is very handy when you alternate between alpinashop-dev and alpinashop-prod.
• When the time comes to have production, consider changing the visual theme or using different browser windows for each environment. It is a simple trick that prevents serious mistakes.

The side menu organises services by category: Compute, Storage, Databases, Networking, Operations, Big Data, AI and Machine Learning, Security, and so on. They are the same families we saw in lesson 01-01.

With two hundred services, navigating the whole menu every day is impractical. That is why there is the option of pinning services: hovering over a service reveals a pin icon that moves it to the top section of the menu, always visible and one click away.

Pinned services:

• Are saved per user, not per project: they follow Marta when she switches between alpinashop-dev and alpinashop-prod.
• Can be reordered by dragging.
• Are the best tool for reducing navigation fatigue in the first few weeks.

The menu can also be pinned open using the pin icon in its header, so that the console becomes two columns and the menu stops being a drop-down. On wide screens it is convenient; on small laptops it steals useful space.

The console search bar does not only search the documentation: it searches for real resources in your project. Typing alpinashop-catalogo will take you straight to the bucket; typing Cloud SQL will take you to the service.

What it finds:

• Resources: instances, buckets, databases, service accounts, firewall rules and so on.
• Console services and pages: useful when you cannot remember which menu category something lives in.
• Documentation: official articles.
• Actions: in many cases it offers "Create instance" or similar directly.

Useful details:

• The keyboard shortcut is the slash /, as in GitHub.
• Resource search uses Cloud Asset Inventory underneath. That means two things: it may take a few minutes to index newly created resources, and it only shows what you have read permissions on.
• It is the quickest way to find a resource when you cannot remember which project you created it in, provided the search has the right scope.

The home dashboard is the screen you see when you enter a project. It is made up of cards that you can add, remove and rearrange with the "Customise" button.

The most useful cards in a young project like alpinashop-dev:

The Platform status card deserves a mention: it links to the public Google Cloud status dashboard (status.cloud.google.com), where incidents are published by service and region. It is the first place to look when something stops working without you having touched anything.

Google Cloud imposes quotas on almost every resource: number of CPUs per region, external IP addresses, requests per minute to an API, the size of certain objects. They exist for two reasons: to protect the shared infrastructure from abusive usage and to protect you from a mistake that sends spend through the roof.

They are checked under IAM and admin → Quotas and system limits. There you can filter by service, see the limit, current usage and the percentage consumed, and request an increase when the limit is insufficient.

Things worth knowing before you run into them:

• New accounts have low quotas. It is normal for a freshly created account to allow only a handful of CPUs per region. If when you reach module 2 you cannot create the VM you want, it is probably this and not a mistake of yours.
• Quotas are per project and often per region. Having headroom in europe-west1 does not mean having it in europe-southwest1.
• Increase requests are not instant. They are usually resolved within hours or a day or so. If you are planning a large deployment, ask for them in advance.
• An exhausted quota shows up as a creation error, with a message that explicitly mentions Quota exceeded. Reading the full message saves a lot of time.

The APIs and services section is the control centre for what the project can do. It is divided into:

• Enabled APIs and services: the list of what is active, with graphs of traffic, errors and latency per API. It is a good place to notice that something is calling far more than expected.
• Library: the full catalogue of available APIs, with a search box. This is where they are enabled.
• Credentials: API keys, OAuth client IDs and associated service accounts.
• OAuth consent screen: needed when your application asks for data belonging to Google users.

Remember from the previous lesson that APIs come disabled by default in every new project and that enabling them does not cost money, but using them does. The list of enabled APIs also works as implicit documentation: looking at it tells you what the project really uses.

A very useful practical detail: when the console stops you doing something because an API is missing, it offers an enable button within the flow itself. There is no need to go and find it in the library.

On many resource creation screens, next to the "Create" button, there are two discreet links: "Equivalent command line" and "Equivalent REST". When you click them, the console shows you exactly the gcloud command or the HTTP request it would run with the options you have filled in on the form.

It is, without exaggeration, the platform's best learning tool:

1. You configure the resource visually, with the description of each field in view.
2. You ask for the equivalent command.
3. You copy it, understand it and save it in a script.

That is how you move from the console to automation without memorising anything.

The >_ icon in the top bar opens Cloud Shell: an ephemeral, free Linux virtual machine that opens as a panel at the bottom of the browser. It comes with the Google Cloud CLI, Python, Java, Go, Node.js, Docker, kubectl, git and terraform already installed, and already authenticated as your user, so you can run gcloud commands without configuring anything.

Alongside it, the Open editor button launches Cloud Shell Editor, a code editor based on the same technology as Visual Studio Code, with a file explorer, an integrated terminal and syntax highlighting. It lets you edit files in your Cloud Shell home directory without leaving the browser.

And a third element: the web preview, an eye-shaped icon that lets you open in the browser a service you are running inside Cloud Shell (for example, AlpinaShop's Flask application on port 8080) through a temporary, authenticated URL.

This is enough for now: the detailed workings of Cloud Shell, its limits, the persistence of your $HOME and the anatomy of gcloud commands are the full subject of lesson 01-06, with which we will close the module.

Everything that can be done in Google Cloud can be done in three ways, and all three end up calling the same REST API underneath. Choosing well saves a lot of time.

When to use each, in practice:

• Console: learning a new service, exploring, looking at graphs and billing, diagnosing an incident, doing something just once. And whenever you want the equivalent command to take away into a script.
• gcloud: day-to-day administration, repetitive tasks, deployment scripts, operations across many resources at once. It is the sweet spot for an administrator.
• Client libraries (Python, Java, Go, Node.js and so on): when it is your application that needs to talk to Google Cloud. Dani will use them in AlpinaShop's Flask app to upload images to Cloud Storage or publish messages to the pedidos-nuevos topic. Never invoke gcloud from production code: use the client library.
• The REST API directly: when there is no library for your language or you need very fine-grained control.

And a fourth route worth mentioning even though it comes later: infrastructure as code with Terraform (lesson 06-07). When infrastructure stops being an experiment and becomes an asset, it is not described with loose commands but with files versioned in Git. The natural progression for a team is console → gcloud → Terraform.

The diagram explains something important: there are no console-exclusive features. If something can be done visually, there is an API that does it, and therefore it can be automated.

Marta is going to leave the project ready to work in throughout the course. Follow these steps yourself too:

Step 1. Verify the active project. Open the console and check in the top selector that it says alpinashop-dev. If not, change it. Note down the projectId and the projectNumber shown on the "Project info" card of the home dashboard: we will need them in the next lesson.

Step 2. Pin the course's services. Open the navigation menu and pin these services, which are the ones we will use most:

Step 3. Customise the home dashboard. Click "Customise" and leave at least these visible: Project info, Billing, Resources and Platform status.

Step 4. Check the starting quotas. Go to IAM and admin → Quotas, filter by the Compute Engine API service and find the CPU quota in the europe-west1 region. Note the value: it will tell you how many machines you will be able to create in module 2.

Step 5. Review the enabled APIs. Under APIs and services → Enabled, check that the ones we enabled in the previous lesson are active. Look at the traffic graph: in a freshly created project it should be practically flat.

Step 6. Open Cloud Shell. Click the >_ icon, wait for the machine to be provisioned and run:

The first command reads your local gcloud configuration and shows the authenticated account and the default project. The second queries the Resource Manager API and returns the project's details, formatted as a table with only three columns thanks to --format. If both return what you expect, your environment is properly set up.

Step 7. Save bookmarks. Create browser bookmarks for the pages you will visit most, with the project already included in the URL:

• https://console.cloud.google.com/home/dashboard?project=alpinashop-dev
• https://console.cloud.google.com/billing
• https://console.cloud.google.com/apis/dashboard?project=alpinashop-dev

• Working with the wrong project selected. The most frequent mistake and the one that does most damage. Look at the selector before any destructive action and use different browser windows or profiles for development and production.
• Confusing "I can't see it" with "it doesn't exist". If a resource does not appear, it is almost always because you are in another project, in another region, or because you lack read permissions. The console hides what you cannot see rather than telling you.
• Searching for a just-created resource and not finding it. The search box relies on Cloud Asset Inventory and takes a few minutes to index. Go through the service's menu instead.
• Ignoring the "Equivalent command line" link. It is the fastest way to learn gcloud and to turn a click into something repeatable.
• Not reviewing quotas until they fail. A deployment that fails with Quota exceeded while the increase request is pending can cost you a whole day.
• Being signed in with two Google accounts at once. It is a constant source of confusion: the console may open with the personal account. Use separate browser profiles.
• Tip: when something fails, look at status.cloud.google.com first. Losing an hour debugging a Google incident is an avoidable classic.
• Tip: pin few services. Pinning twenty is like pinning none. Start with the five or six you really use.

For each task, say whether you would tackle it from the console, with gcloud or with a client library, and justify your choice in one sentence:

1. Dani needs AlpinaShop's Flask application to upload a product photo to the alpinashop-catalogo bucket every time an employee adds an item.
2. Marta wants to see how spend has evolved over the last quarter, broken down by service.
3. The same entorno=desarrollo label has to be applied to 40 existing resources.
4. Marta is studying Cloud SQL for the first time and wants to understand what options exist when creating an instance.
5. A nightly process must create a disk snapshot every day at 03:00.

Carry out the walkthrough from section 9 in your own account and answer:

1. What is your project's projectNumber and how does it differ from the projectId?
2. How many CPUs does your current quota allow in the europe-west1 region?
3. Find a resource creation screen in the console that offers the "Equivalent command line" link and note down the command it generates without actually creating the resource.

Marta receives a message from Dani: "I created a virtual machine this morning and now it's nowhere to be seen. Did you delete it?".

List at least four possible causes, ordered from most to least likely, and say how you would check each one from the console.

Solution 1

1. Client library (the Cloud Storage one for Python). It is the application itself that needs to talk to Google Cloud; invoking gcloud from production code would be fragile and insecure.
2. Console, the Billing → Reports section. It is a visualisation and exploration task, exactly where the graphical interface wins.
3. gcloud, combining a listing with --format=value(...) and a bash loop. Doing it by hand in the console forty times is slow and error-prone.
4. Console. When exploring a new service, the form with a description of every field teaches you faster than the CLI documentation. Afterwards, the "Equivalent command line" link gives you the command ready-made.
5. gcloud inside a scheduled task (or, better still, a managed snapshot policy). It is a repetitive, unattended operation: it belongs in a versioned script, not in anyone's memory.

Solution 2

1. The projectNumber is a numeric identifier assigned automatically by Google, whereas the projectId is the readable string you chose when creating the project (alpinashop-dev). Both are immutable and globally unique; some APIs and some internal formats use the number instead of the ID. They are studied in detail in lesson 01-04.
2. It depends on your account. In new accounts it is common to find low limits (in the order of a few dozen CPUs, and sometimes fewer during the trial period). The point of the exercise is to know where it is checked: IAM and admin → Quotas, filtering by Compute Engine API and by region.
3. For example, under Compute Engine → Create instance, once you have filled in the form the "Equivalent command line" link generates a gcloud compute instances create ... with all the flags corresponding to the options you ticked. You can copy it and close the form without creating anything.

Solution 3

Causes ordered by likelihood:

1. Wrong project. Dani may be looking at alpinashop-prod when he created it in alpinashop-dev, or the other way round. Check: review the project selector and search for the VM by name in the global search box.
2. Wrong region or zone. The Compute Engine instance list may have a zone filter active. Check: clear the filters on the instance list, which by default shows every zone.
3. Wrong Google account. Dani may have created the VM with his personal account and now be looking with the corporate one, or vice versa. Check: look at the avatar in the top bar.
4. Insufficient permissions. If someone has adjusted the roles, Dani might not have read permission on Compute Engine and the console would simply not show him the instance. Check: review his roles under IAM and admin.
5. The VM really was deleted or stopped. The definitive check: Cloud Logging, filtered by the project's admin activity, shows who ran which operation and when. It is the source of truth, and we will see it in lesson 06-06.

We now know our way around. In this lesson we have gone through the top bar and identified the project selector as the console's most critical control; we have learned to pin favourite services in the navigation menu to reduce navigation fatigue; we have seen that the search box indexes real resources through Cloud Asset Inventory; we have customised the home dashboard with the project, billing, resources and platform status cards; we have located where quotas are checked and understood that new accounts start with low limits; we have reviewed the APIs and services section and discovered the "Equivalent command line" link, probably the best learning tool on the whole platform. We have also had a passing look at Cloud Shell, its editor and the web preview, and we have compared the three ways of working with GCP so as to know when each is appropriate. Marta has left alpinashop-dev with her services pinned and her dashboard set up.

So far we have treated the project as a box that things fit into. In the next lesson, Projects, Resource Hierarchy and Billing, we will open that box: we will look at the full Organization → Folders → Projects → Resources hierarchy applied to AlpinaShop with produccion and desarrollo folders, the exact difference between projectId, projectNumber and the name, why the project is the boundary for billing, quotas, permissions and networking, how billing accounts and labels work for splitting spend, and how the hierarchy inherits policies. It is the lesson that stops AlpinaShop's cloud being a disorderly heap of projects a year from now.