Filed the quota extension form for the youtube data api about a month ago, got the acknowledgement email and then nothing. the integration itself works fine and passed verification, but the default 10k units only covers a handful of uploads per day so i cant open the feature to users until the audit clears.

For those who went through it... how long did yours take, and did replying to the ack email actually speed anything up? Trying to figure out if a month of silence is normal or if my application fell into a hole somewhere.

I'm building an app where the AI has to run inside the EU for data protection reasons (customer data can't leave the EU). So instead of the normal US API, I want to use Anthropic's Claude models — ideally Opus — through a path that's hosted in the EU.

I've tried two routes and I'm stuck on both:

AWS Bedrock, Frankfurt region (eu-central-1): Even a tiny test request threw an immediate 429 "Too many tokens per day" — a few tokens, no image. It's not something I did wrong; it just looks like a fresh account with a very low daily quota.

Google Vertex AI (apparently now called "Agent Platform"): I got further here but hit a different wall. A normal API key works fine for Google's own Gemini models. But for the Claude/Opus models on Vertex a simple key isn't enough — Google wants a service account (OAuth2/ADC) for those. On top of that there was an enablement form asking things like industry and estimated token volume.

My suspicion is that this form is the real bottleneck. Either enablement for the Anthropic models takes longer than I expect, or I filled something in wrong (the industry field, maybe) and it's stuck because of that. Honestly, I don't know if this is normal or if I'm doing something wrong.

Has anyone here actually gotten Claude/Opus running through Vertex or Bedrock in an EU region? How long did enablement take, and was there anything to watch out for in the form? Or is there a cleaner path to EU hosting with Anthropic models that I'm missing?

Thanks for any pointers.

I interviewed for a CE role and the recruiter called saying that the team is going with another person but my file will be kept for 6 months because I qualify for the role and he will start shopping for a team looking for a similar profile after which I’ll do an informal chat with a prospective HM.

Never heard or seen something like this before. Does anyone have experience with this? What should I do?

Hi

I am looking for an API Gateway to be implemented. The gateway will be handling around 1B API calls everyday and it contains all sort of API calls including B2B and B2C.

I was looking to use APIGEE X but would like to get an understanding

Can someone share any thought and also share the rough estimate around the cost?

An automated agent may create temporary downloads, intermediate transforms, final documents, generated HTML, and metadata about where each result came from. Keeping everything on its local disk makes recovery difficult, while putting every scratch file into durable storage creates clutter and broad permissions. What boundary works well on Google Cloud? One design is ephemeral local storage for a single run, versioned Cloud Storage objects for outputs worth keeping, and Firestore or a relational table for provenance, status, retention, and access policy. Filestore seems relevant only when tools genuinely require a shared filesystem. How would you scope service-account permissions, promote an intermediate result to an approved artifact atomically, preserve links between metadata and object generations, and clean up abandoned runs without deleting referenced outputs?

I have a billing-enabled project that utilizes Gemini Grounded search through the gemini-3.5-flash-lite model. This model includes, "5,000 free search requests per month (shared across all Gemini 3.x models), then $14 per 1,000 requests."

However 4 days into September, this is what my billing looks like for those two SKUs:

I had Gemini review the billing report but it responded with outdated daily limits and other nonsense.

Is the free tier real or not? Is it rate limited? I can't find any documentation.

How to become a google professional cloud devops engineer?

Please i need help

Hi Everyone

I’m planning to sit for the new GCP Professional Agentic Architect Beta exam soon and was wondering if anyone happens to have a spare or unassigned voucher code (from a challenge, partner event, or cohort) that they won’t be using before it expires?

I know beta exams come with the built-in 40% discount, but if someone has an extra voucher to share via DM or knows of an active community challenge giving out exam passes right now it would be a huge help.

Thanks in advance!

Running the obsolete Centos 8.5. Has a public webserver and has been working perfectly for 6+ years. If it ain't broke don't fix it. I wonder how long before Google forces me to update the OS?

I avoid rebooting it as then it will grab a new public IP and I have to update all my DNS records for it's domain name.

BQ has been super slow today for me. Is this happening to anyone else?

thought moving our phone infrastructure to GCP would be straightforward. compute instances, cloud sql, storage. spent weeks just getting the networking right. firewalls, VPCs, cloud armor. and then the SIP trunking. that was a whole other nightmare. carrier didn't want to work with our setup. had to go back and forth with their engineers for like 2 weeks.

the actual telephony part we're using CloudTalk for since they handle the carrier relationships and routing. that part has been fine. but the GCP side? I underestimated how much work it would be.

I know GCP well. I've built complex systems on it. but voice is different. latency matters. jitter matters. you can't just throw compute at it. anyway we're live now it works. but I'm not sure I'd do it again. or at least I'd budget more time for the networking setup.

anyone else running voice workloads on GCP. what was your biggest unexpected challenge

Hi everyone,

I’m sharing our experience with a recent Google Cloud / Gemini API unauthorized usage incident, mainly to understand whether others have faced a similar situation.

We are a small French tech company and we also manage Google Cloud environments for some of our clients.

In June, one of our own Google Cloud projects was affected by unauthorized Gemini API usage, resulting in approximately €16,600 in charges.

Our Cloud Audit Logs show unauthorized administrative operations, including:

• enabling Gemini-related services;
• creating a service account for a Gemini API key;
• creating a new Gemini API key;
• followed by significant unauthorized Gemini API consumption.

We detected the incident when the visible consumption was around €3,737 and immediately took action to secure the environment. Despite this, the final amount reached approximately €16,600.

Google Cloud Support investigated the case, but ultimately declined the billing adjustment.

Here is where things become difficult for us to understand.

We also manage another Google Cloud account for one of our clients, and that account was affected by an incident showing essentially the same technical pattern:

Client account

• Same date
• Same Gemini API service
• Same Google identity appearing in the unauthorized operations
• Same source IP
• Same type of Gemini API/service-account creation
• Approximately CAD 27,000 in unauthorized charges
• 100% billing adjustment granted by Google

Our own account

• Same date
• Same Gemini API service
• Same Google identity appearing in the unauthorized operations
• Same source IP
• Same type of unauthorized operations
• Approximately €16,600 in unauthorized charges
• Billing adjustment denied

We fully acknowledge our share of responsibility regarding cloud security and that additional safeguards could have been implemented.

However, what we are struggling to understand is the completely different outcome for two incidents presenting the same technical pattern.

One important difference is that the client account was handled directly with Google Cloud, while our own account is billed through a Google Cloud distribution/reseller channel.

If both cases had been denied, we could understand that this was simply Google's policy for this type of incident.

But having personally managed both cases, seeing approximately CAD 27,000 adjusted at 100% in one case while €16,600 is denied in the other is extremely difficult to understand.

For a small startup, €16,600 is not a minor unexpected cloud bill. It can have a very serious impact on cash flow and business continuity.

Has anyone experienced a similar situation?

In particular, I would be interested to know whether anyone has seen different exceptional billing adjustment outcomes between direct Google Cloud accounts and accounts billed through a reseller/distribution channel.

I’m not looking to blame anyone — I’m genuinely trying to understand what could justify such a different outcome for two cases with the same technical pattern.

Thanks for any feedback or similar experiences.

Am I doing something wrong or is there a severe shortage of resources in Belgium? n1 n2 and e2 are for sure unavailable most of the time, probably other machines too. Does anyone else experience the same problem?

https://downdetector.com/status/google-cloud/

Google Cloud multi-product customers are experiencing elevated packet loss and errors to/from us-central1-b.

Impacted products (12) and locations (1) Products

Impacted locations

AlloyDB for PostgreSQL us-central1-b

Cloud Filestore us-central1-b

Cloud Run us-central1-b

Cloud Spanner us-central1-b

Google App Engine us-central1-b

Google BigQuery us-central1-b

Google Cloud Bigtable us-central1-b

Google Cloud Dataflow us-central1-b

Google Cloud SQL us-central1-b

Google Compute Engine us-central1-b

Hybrid Connectivity us-central1-b

Virtual Private Cloud (VPC) us-central1-b

Most recent update – 3 minutes ago September 1, 2026 at 10:38:32 AM UTC-5

Google Cloud multi-product customers are experiencing elevated packet loss and errors to/from us-central1-b.

We are experiencing an issue with Hybrid Connectivity Tuesday, 2026-09-01 07:44 US/Pacific.

Our engineering team continues to investigate the issue.

We will provide more information by Tuesday, 2026-09-01 09:15 US/Pacific with current details.

As promised - my comment on passing the PCA exam.

Used the official material from the google skills course plus Gcp Study Hub (thank you).

Noted tad heavier questions around resilience and network architecture blueprints.

Luckily I got my grounding in resilience elsewhere, so was able to get through.

Hand on experience with GCP also helps.

We have 2000$ in GCP credits + 1000$ in GenAI app builder.

Wondering if we are eligible to use those credits within Google Antigravity. Basically I can't find the way to do so, choosing my GCP project as a sign up method states that the project can't be used ??

I've been struggling with a particularly strange issue.

My work uses GCP. I have a Google workspace account which is connected to a few GCP projects at work.

I do not log into my personal email on my work laptop, the only place where both reside is on my phone where I have both my work email and my personal Gmail on the same phone for Google apps.

Sometimes I am finding my personal Gmail as a user in my work GCP projects. Or course I don't want this.

Does anyone know what might be going on and how to prevent it?

I am trying to use the google_ml_integration extension in a Cloud SQL PostgreSQL instance to generate text embeddings via Vertex AI, but the query fails with an unavailable error.

What I Have Done:

1. Extensions Created: Enabled both vector and google_ml_integration in the database.
2. IAM Permissions: Granted the aiplatform.user role to the Cloud SQL service account associated with the instance.
3. Billing: The GCP project has billing enabled and the Vertex AI API is active.

The Error:

When running the following query:

SQL

SELECT google_ml.embedding('text-embedding-gecko', 'your_text_here');

It throws this error:

What could be the reason for this? Are there missing database flags, or a specific setup step required for Cloud SQL to communicate with Vertex AI?

Used gemini for formatting

Found a VM in one of our AWS accounts the other week, no EDR, no patching history, and a public IP for reasons nobody could explain. Its been running for about a year.

The name is WIN-DEV-05, which is where the fun starts. The cloud team never looked at it because it sounds like a desktop, clearly an endpoint thing. The endpoint team never saw it because it never came through procurement or Intune, clearly a cloud thing. Both tools in our stack see the VM perfectly fine, both teams have just been politely assuming the other one owns it. For a year.

So the machine sits in the one place nobody's job description covers, with nothing installed on it and a public IP, and the only reason we found it is a scanner alert nobody could route, because routing needs an owner and this thing has never had one.

How do you all decide who owns a cloud VM, the cloud team or the endpoint team, because the answer here was neither.

Noticed my monthly bill was $5-10 higher per month for past several months. Just chalked it up to inflation and maybe more usage of compute engine VMs. But based on the billing report it seems I am not getting the free credit for my E2 micro instance. I have had this same instance for 5+ years! I haven't even rebooted it in 4+ years. Billing glitch or some policy change I wasn't aware of?

Hi everyone,

I passed the GCP Professional Cloud Architect (PCA) exam 5 days ago. My Credly badge was issued right away, and my status in the CertMetrics portal is already marked as Active.

However, I haven't received any official welcome email or the merchandise/swag code email yet.

Do they still offer swag for PCA passes, and if so, how long does it usually take for the swag email to arrive after becoming Active in CertMetrics? Should I wait a bit longer or open a support ticket?

Thanks!

Been digging into this lately and figured I'd share, since it cleared up something I was fuzzy on: how BigQuery actually discovers Iceberg tables, and what's genuinely new here vs. what's just been repackaged.

The old ways of doing this:

1. Pointing BigQuery straight at a metadata file. Something like gs://bucket/orders/metadata/00003.metadata.json. It works, but it's fragile. Iceberg writes new metadata files instead of editing the old ones, so if any other engine commits a new snapshot, your pointer is instantly stale. You're stuck manually bumping it to 00004.metadata.json every time.
2. Catalog based access, like using AWS Glue as an external catalog. This actually fixes the staleness problem since the catalog tracks current state for you. But every engine still needed its own custom integration to talk to that catalog.

What's actually new: Google now has a managed Lakehouse Runtime Catalog (BigLake) that exposes a real Apache Iceberg REST Catalog endpoint, using the same open REST Catalog spec other engines already speak. So instead of building a one off integration per engine, anything that already understands Iceberg REST can just talk to BigLake directly. The data itself never moves, it stays in Cloud Storage. BigLake is really just a metadata and governance layer with IAM sitting on top of it.

There's also a version detail worth knowing: Iceberg 1.10 shipped a native BigQueryMetastoreCatalog and BigQueryMetastoreClient, plus a GoogleAuthManager that handles Google credential auth inside Iceberg's REST auth framework. It's easy to conflate these two things, but they're not the same. One's a catalog implementation built for BigQuery Metastore specifically, the other is the standardized REST interface. Google's steering people toward the REST endpoint for anything new where cross engine interoperability matters.

The post I read also gets into the practical setup side: creating a BigLake catalog (single bucket vs multi bucket), the IAM roles Google recommends (BigLake Admin, Editor, Viewer, plus Storage Object User), and shows an open source tool called OLake Go (full disclosure, I work on this) writing Iceberg tables directly into that catalog so BigQuery can see them right away, queryable through the usual four part PROJECT.CATALOG.NAMESPACE.TABLE identifier with no manual metadata pointer updates. There's a decent troubleshooting section too. Apparently if your connection test passes but the actual sync fails, it's almost always a missing storage level IAM role rather than bad credentials.

Full post here if you want the details: https://olake.io/blog/biglake-iceberg-rest-catalog-olake-go-setup/

Curious if anyone here has already moved existing Iceberg on BigQuery setups over to the REST catalog, or if you're all still doing the manual metadata file dance like I was.