Google CloudSeptember 22, 20265 min read

You Just Inherited a Google Cloud Project. What to Do First

There is a one line command that stops anyone deleting the whole thing, and a thirty day window that means the worst case is survivable. Neither is on the dashboard.

Somebody left, or somebody decided you were the technical one, and now the Google Cloud project is yours. No handover, no diagram, just a console and the assumption you already know.

The first few things are about not breaking anything. Understanding it properly comes after, and it comes easier once you are not nervous.

First, see everything at once

The console shows you one service at a time, which is a bad way to meet a project you have never seen.

Use the asset inventory instead. From Cloud Shell, which needs nothing installed:

gcloud asset search-all-resources --scope=projects/PROJECT_ID --format="table(assetType, displayName, location)"

That is the whole project in one list. Read it once without trying to understand it. You are looking for surprises: a database in a region nobody mentioned, a machine named after a person, three things that look like the same app from different years.

Write down the ten that look important. That is your map for everything else.

Second, find out who else has the keys

Go to IAM and admin, then IAM. Look for two things.

People holding Owner or Editor. Editor is close enough to Owner for most purposes, and it gets handed out far more casually than it should be.

Then service accounts, which are the identities that applications and pipelines use. One of them will be the Compute Engine default service account, and it is worth understanding why that one matters. Google says it "might automatically be granted the Editor role on your project" and is "attached by default to all VMs that you created by using the Google Cloud CLI or the Google Cloud console".

So the machines you inherited may be running as something that can edit the whole project. Note it. Do not start unpicking it this week, because you do not yet know what depends on it.

Third, stop anyone deleting the whole thing

This is the one almost nobody does and it takes one command.

Google Cloud has a thing called a lien. Their description: "You can place a lien upon a project to block the project's deletion until you remove the lien."

That is the whole feature and it is exactly what a nervous new owner wants. The project keeps working normally. The only thing that changes is that it cannot be deleted while the lien exists.

gcloud alpha resource-manager liens create --project=PROJECT_ID --restrictions=resourcemanager.projects.delete --reason="Production. Ask before removing."

You need the Project lien modifier role to do it. If you cannot, that is a very easy thing to ask for, and a good first request to make of whoever handed you this.

Put the reason in properly. Six months from now the person blocked by that lien might be you, and a lien that says why is a note to your future self rather than an obstacle.

The good news nobody tells you

If the worst does happen, Google gives you room. A deleted project is soft-deleted first: "These projects are fully deleted after 30 days."

Thirty days. That is not a promise you should ever need, and it is genuinely reassuring to know it is there while you are still learning what everything does. A wrong click on a project is recoverable in a way a wrong click on most individual resources is not.

Worth being precise though: this covers the project, not the things inside it. Delete a storage bucket or a disk directly and no thirty day window saves you. The lien protects the container, and the contents need their own answer.

Fourth, find the billing account

Here is a piece of the shape that catches people coming from other clouds. In Google Cloud, the billing account is a separate object from the project. A project is linked to one, and the person who owns the project is not necessarily the person who owns the billing.

So you can inherit a project and not inherit the ability to see what it costs. Check under Billing whether you actually have access to the linked account. If you do not, ask, because otherwise you are responsible for something you cannot see the price of.

While you are in there, set a budget alert for roughly what it spends now. It is free and it turns a surprise into a notification.

Then learn the shape

Google Cloud stacks like this: organisation, then folders, then projects, then resources. Permissions flow down. Somebody with a role at the organisation level has it on every project underneath without appearing in any project's own list, which is why your IAM page might not be the whole story.

The project is the important boundary. A resource lives in exactly one project, billing attaches to the project, and quotas are per project. When people say Google Cloud is project-centric, that is what they mean, and it is the single most useful thing to internalise early.

What not to do in week one

Do not tidy. Every unexplained thing in an inherited project is either waste or load bearing, and you cannot yet tell which. Waste costs money. Load bearing costs your weekend.

Do not delete service account keys yet, however much they bother you. One of them is probably holding a deployment together.

Do add labels. A label saying who owns a thing and when you last looked at it breaks nothing and is the most useful gift you can leave for yourself in six months.

Where we are with this

Straight with you: Liberra is an AI that connects to your cloud, indexes what is in it, and lets you ask questions in plain English instead of learning six consoles. It runs on AWS and Azure today. Google Cloud is next, and I am not giving a date, because a date promised before something ships is a guess in a nice shirt.

So use the list above. The lien especially. It costs nothing, takes a minute, and it is the difference between a bad afternoon and a bad year.

The one thing I can tell you about how it will work when it does arrive is how it already works on the other two. Liberra cannot delete anything, because the delete commands are blocked in the code rather than in a permission somebody has to get right. Every change that writes stops and explains itself and waits for you to say yes.

When you have just been handed something you are afraid of breaking, that is the only kind of help worth having.

Founder, Liberra AI