The Google Cloud estates we get called into arrive in a recognizable state. Projects nobody can account for, a JSON service account key in every pipeline, and a bill that grew faster than the traffic did. Whoever built it usually held the Google badge locally, and that badge was usually earned on Workspace.
If you are shopping for Google Cloud consultants in Kenya, that is the distinction that decides the engagement. CloudSpinx designs and runs Google Cloud estates for organizations here and across East Africa, next to the AWS and private-cloud work we do on hardware. The current one is the production platform behind a school nutrition program: eight Google Cloud projects with their networks, databases, clusters and IAM bindings expressed as 33 OpenTofu modules and 53 Terragrunt stacks, 54 ArgoCD applications reconciling across five GKE clusters, four environments cloned from one template, and not a single static service account key anywhere in it. Roughly 2,700 commits over ten months, starting from a console-built estate nobody could reproduce. The engineering record has the before and the after.
Apply everything below to us as readily as to anyone else on your list.
The Google badge on a Kenyan supplier is often a Workspace badge
Google rebuilt the program in December 2025. Partner Advantage became the Google Cloud Partner Network, two tiers became three (Select, Premier, Diamond), and specializations were replaced by a competency framework that measures capacity, meaning certifications and sales credentials, and capability, meaning validated closed-won customer outcomes. Rollout runs through 2026 with a six-month transition window.
Badges minted under the old scheme are still on supplier websites across this market, and the old scheme held two very different families. Workspace Transformation was about deploying mailboxes, calendars and Drive to an organization, which is real work that real teams are good at. Infrastructure was about Compute Engine, GKE, VPCs and IAM. The graphic looks identical either way, and only one of them is what you are buying.
Ask which competency, then ask what they built in it. The three questions that follow are faster, because each has a right answer that cannot be revised in the meeting.
There is no Google Cloud region in Kenya, and BigQuery makes it worse
Distance is the less interesting number. A cross-border transfer assessment turns on which country's courts can compel the data, and Johannesburg answers South Africa however good the latency is.
Google's africa-south1 region opened in Johannesburg in January 2024, its first on the continent and still its only one. For compute that is workable. For residency it is the entire conversation, because a cross-border transfer assessment asks whose courts can reach the data, and Johannesburg answers South Africa.
BigQuery is where teams get caught. A dataset can sit in africa-south1 and often should. The multi-region tiers, however, are US and EU only, and there is no African multi-region. A team reaching for a multi-region dataset because the durability language sounded better has moved the analytics estate off the continent in one click, and nothing in the console mentions it.
Where the requirement is genuinely that Kenyan data stays in Kenya, the answer is not a Google Cloud region at any tier. It is hardware in a Nairobi facility, or a split where the regulated tables stay here and everything else goes to Johannesburg. Anyone who tells you your data can stay in the country on Google Cloud has not read the region list.
The service account key is the fastest tell in the whole conversation
Google's own IAM documentation says service account keys "are powerful credentials, and can present a security risk if they are not managed correctly". That is the vendor's wording about its own feature, and it is doing a lot of work.
The default policy is the part that catches Kenyan estates. An organization created before 3 May 2024 never received the constraint, so key creation is open unless somebody went looking for a policy they did not know existed.
A JSON key does not expire, and it works from anywhere. By the time an estate is two years old the same key is in a repository secret, on two laptops, in a chat thread, and in the git history of whichever repo it got committed to before somebody noticed. Rotation is a calendar reminder nobody keeps.
The fix is Workload Identity Federation, and Google now applies it by default: organizations created on or after 3 May 2024 get constraints/iam.managed.disableServiceAccountKeyCreation automatically. Older organizations never received it. That is the estate we usually walk into here, created before the cutoff, key creation wide open, nobody aware there was a policy to switch on.
So ask a prospective supplier how their pipelines will authenticate to your projects. A key in the CI secrets is an honest answer and a priced decision. "Federation, bound to your repository by an attribute condition" is the answer from somebody who has done this since the policy landed. Zero static keys is how our DevOps and platform work is built, which is why the number sits on a case study rather than in a sentence about best practice.
What GKE costs before you run a single pod
GKE charges a flat cluster management fee of USD 0.10 per cluster per hour, whatever the mode, whatever the size. The free tier is a USD 74.40 monthly credit per billing account against management fees only, which buys one Autopilot or zonal Standard cluster and does not roll over.
Now price the shape most teams ask for. Separate dev, staging and production clusters is three times 730 hours at ten cents, USD 219 a month, less the credit, so about USD 145 before a node boots, a load balancer exists or a byte is stored.
Not a large number. It is a large number to spend on isolation you could have had from namespaces and separate node pools, and it is the first line we question on a bill review, because three clusters is usually an org chart rather than a blast radius.
The honest answer depends on who can break what. A regulated production workload earns its own cluster and its own project. Three environments for a team of four does not, and that trade is most of a first conversation about designing and running the cluster.
Who holds the billing account
Nobody asks this in advance, and on Google Cloud it has teeth.
Buy through a reseller and the Cloud Billing account is usually theirs, with your projects linked to it. Moving a project onto a different billing account needs Project Billing Manager or Owner on the project plus rights on the target account: Billing Account User and Viewer, or Administrator. The move is possible. It also needs cooperation from the party you are leaving, at the moment you have nothing left to bargain with, and any committed use discount sits on their account rather than yours.
There is a legitimate reason to buy that way, and it is a good one: a reseller invoices you locally and takes the procurement friction out of a USD card, which for some finance teams settles the question on its own. Just price what you traded. We put the organization and the billing account in the client's name from the first project and bill engineering separately, on Google Cloud and AWS alike, which is how our cloud consulting engagements are scoped rather than something promised at handover.
When we tell people to stay off Google Cloud
Three cases come up often enough to name. A Windows estate with Active Directory at the center belongs on Azure, and we say so on the first call. A company whose only reason for considering Google Cloud is that it already pays for Workspace has no reason at all, because the two share a login and almost nothing else.
The third is residency. No cloud region satisfies a contract requiring Kenyan data to stay in Kenya, so the honest design is metal here with a cloud tail, not a migration you unwind in year two. The longer form of that argument is how the three hyperscalers compare for a business here, and what a migration actually costs is a separate question again.
Where Google Cloud wins is narrower and real. Teams that already live in Kubernetes get a better cluster from GKE than from anything they assemble themselves, and teams whose product is data get BigQuery, which has no equal on either competitor at the same effort. Both of those are worth the Johannesburg round trip. Neither of them is worth it because a badge said so.
Send us the project list and how your pipelines authenticate today, and you get back what we would change and one figure for doing it. Free, no obligation, and if the answer is that you should stay exactly where you are, that is the answer you will get. The scoping form or WhatsApp +254 713 403 044.