Introdução: O projeto é seu ponto de partida no Google Cloud
Desde o momento em que você provisiona seu primeiro recurso até o dia em que exclui o último, tudo no Google Cloud acontece dentro de um projeto. As permissões do Cloud IAM são aplicadas no nível do projeto, os encargos de faturamento são consolidados por projeto, e a habilitação de APIs é gerenciada de forma independente em cada projeto. Entender esse modelo não é opcional — é a base sobre a qual todos os outros conceitos do GCP são construídos. Este guia percorre a hierarquia de recursos, os tipos de contas de faturamento, as ferramentas de visibilidade de custos e as ferramentas de linha de comando que impulsionam as operações diárias na nuvem.
---
A hierarquia Organização → Pasta → Projeto
O Google Cloud organiza os recursos em uma hierarquia de três níveis: Organização, Pasta e Projeto. Isso não é apenas uma convenção de nomenclatura — é a espinha dorsal estrutural para herança de políticas e limites de controle de acesso.
O nó Organização corresponde a toda a sua empresa. Ele está vinculado a um domínio do Google Workspace ou Cloud Identity, e qualquer Organization Policy ou função do Cloud IAM aplicada nesse nível é herdada automaticamente por todas as pastas e projetos abaixo. Por exemplo, se você configurar a restrição para permitir apenas , nenhuma equipe na organização poderá provisionar recursos em qualquer outra região. Um engenheiro que tente criar uma VM do Compute Engine em receberá uma negação imediata no nível da API — a restrição é aplicada antes que qualquer recurso seja criado.
As pastas representam agrupamentos lógicos como unidades de negócio, equipes ou ambientes como dev, staging e prod. Você pode aninhar pastas até dez níveis de profundidade. Conceder uma função do Cloud IAM em uma pasta faz com que todos os projetos dentro dessa pasta herdem automaticamente a mesma permissão.
Os projetos são o limite de isolamento primário para recursos, Cloud IAM e faturamento no GCP. Quando uma questão do exame de certificação pergunta sobre isolamento de equipes e rastreamento independente de custos, a resposta correta é a separação de projetos — não rótulos.
| Nível | Corresponde a | Propósito principal | |-------|--------------|--------------------| | Organização | Empresa inteira | Raiz de políticas, base do Cloud IAM para toda a empresa | | Pasta | Unidade de negócio / equipe / ambiente | Herança intermediária de políticas, agrupamento de projetos | | Projeto | Unidade de serviço individual | Limite de isolamento de recursos, Cloud IAM e faturamento | | Recurso | VM, bucket do Cloud Storage, etc. | Objeto de infraestrutura real |
---
Entendendo as contas de faturamento e o modelo de cobranças
Um projeto deve estar vinculado a exatamente uma conta do Cloud Billing antes de poder consumir serviços pagos do GCP. Uma única conta de faturamento pode ser vinculada a vários projetos, o que facilita a consolidação dos encargos de diversas equipes em uma única fatura.
As contas do Cloud Billing existem em dois tipos. Uma conta de autoatendimento cobra automaticamente um cartão de crédito ou conta bancária e é a escolha típica para desenvolvedores individuais e startups. Uma conta faturada emite uma fatura mensal que deve ser paga em trinta dias e é preferida por empresas e organizações do setor público que exigem fluxos de trabalho com ordens de compra.
Um ponto de design crítico: o Cloud IAM da conta do Cloud Billing e o Cloud IAM no nível do projeto são completamente independentes. Conceder à equipe financeira no nível da conta de faturamento dá a eles acesso de leitura a faturas e relatórios de custos — nada mais. Eles não obtêm nenhum acesso a qualquer recurso dentro dos projetos vinculados. Este é o princípio do mínimo privilégio aplicado em um cenário concreto e real.
| Função de faturamento | Permissão principal | Palavra-chave do exame | |----------------------|--------------------|-----------------------| | billing.viewer | Acesso somente leitura a faturas e relatórios de custos | Somente leitura para equipe financeira | | billing.user | Vincular um projeto a uma conta de faturamento | Vinculação de projeto pelo desenvolvedor | | billing.admin | Gerenciamento completo de uma conta de faturamento | Adicionar ou remover métodos de pagamento | | billing.costsManager | Gerenciar orçamentos e controles de custos | Gerenciamento dedicado de orçamentos |
---
Visibilidade de custos: orçamentos, alertas e exportação de faturamento
O gerenciamento eficaz de custos significa projetar alertas na sua arquitetura antes de gastar dinheiro — não descobrir excessos depois do fato. O Google Cloud fornece Cloud Billing Budget, Cloud Billing Export e Looker Studio para essa finalidade.
O Cloud Billing Budget permite definir uma meta de gasto mensal e envia notificações por e-mail ou mensagens do Pub/Sub quando o gasto real atinge 50%, 80%, 90% e 100% do limite. Um ponto que confunde muitos engenheiros e candidatos ao exame: um Cloud Billing Budget não para nem limita automaticamente nenhum serviço. Se você quiser desligar automaticamente VMs do Compute Engine quando um orçamento for excedido, você mesmo precisa construir essa automação usando um tópico do Pub/Sub combinado com uma função do Cloud Functions.
O Cloud Billing Export envia dados de faturamento para um conjunto de dados do BigQuery automaticamente. A exportação Standard Usage Cost fornece dados no nível de projeto e SKU, enquanto a exportação Detailed Usage Cost vai mais fundo até o nível de recurso individual. Os dados exportados incluem ID do projeto, nome do serviço, SKU e quaisquer rótulos que você tenha aplicado — fornecendo o material bruto para escrever consultas SQL que agregam custos por departamento, equipe ou ambiente. Tenha em mente que há um atraso de até vinte e quatro horas, o que torna esse pipeline inadequado para monitoramento em tempo real.
| Ferramenta | Caso de uso | Limitação | |-----------|-------------|----------| | Console do Cloud Billing | Revisão visual, consultas rápidas | Sem análise SQL ou retenção de longo prazo | | Cloud Billing Budget | Alertas de limite, rastreamento de orçamento | Não pode parar recursos automaticamente | | BigQuery Billing Export | Análise SQL, retenção de longo prazo | Atraso de até 24 horas nos dados | | Looker Studio | Visualização em dashboards | Requer dados do BigQuery como pré-requisito |
O Looker Studio se conecta nativamente ao BigQuery sem necessidade de nenhum pipeline ETL, portanto você pode construir um dashboard de custos ao vivo diretamente sobre os dados de faturamento exportados. Para cenários que exigem análise SQL baseada em rótulos e relatórios visuais, a arquitetura padrão é: exportação de faturamento para o BigQuery, depois o BigQuery como fonte de dados para o Looker Studio.
---
gcloud, gsutil, bq e kubectl: divisão de responsabilidades entre ferramentas CLI
O Google Cloud SDK vem com quatro ferramentas de linha de comando, cada uma com um escopo claramente definido. Manter essa distinção clara reduz a confusão tanto nas operações do dia a dia quanto no exame de certificação.
gcloud é a principal ferramenta para controlar a grande maioria dos serviços do GCP. Criar instâncias do Compute Engine, gerenciar clusters do GKE, atribuir funções do Cloud IAM, configurar redes VPC — quase todo o gerenciamento de infraestrutura passa pelo gcloud. gsutil é a CLI dedicada para o Cloud Storage: criar buckets, fazer upload e download de objetos e gerenciar listas de controle de acesso. bq é a CLI específica do BigQuery para criar conjuntos de dados, executar consultas SQL e carregar dados em tabelas. kubectl controla as cargas de trabalho do Kubernetes em clusters do GKE. Antes de poder usar o kubectl em um cluster do GKE, você precisa preencher seu arquivo kubeconfig executando .
| Ferramenta CLI | Alvo principal | Comandos representativos | |---------------|---------------|-------------------------| | gcloud | A maioria dos serviços GCP (Compute Engine, Cloud IAM, GKE, etc.) | gcloud compute instances create | | gsutil | Buckets e objetos do Cloud Storage | gsutil cp, gsutil mb | | bq | Conjuntos de dados, tabelas e consultas do BigQuery | bq query, bq load | | kubectl | Clusters e cargas de trabalho do Kubernetes (GKE) | kubectl apply, kubectl get pods |
---
Configurações do gcloud e troca de contexto
O gcloud usa um conceito chamado Configurações para armazenar e alternar rapidamente entre diferentes combinações de conta, projeto e configurações de região. Pense nisso como perfis de navegador — você salva uma Configuração de dev e uma Configuração de prod separadamente, e alterna entre elas com um único comando em vez de respecificar flags em cada invocação.
Os principais padrões de comando do gcloud se enquadram em quatro categorias:
| Categoria | Comando | Descrição | |-----------|---------|----------| | Autenticação | gcloud auth login | Fazer login com uma conta do Google | | Autenticação | gcloud auth list | Listar contas atualmente autenticadas | | Configuração | gcloud config set project PROJECT_ID | Alterar o projeto ativo | | Configuração | gcloud config configurations create NAME | Criar uma nova Configuração | | Configuração | gcloud config configurations activate NAME | Mudar para uma Configuração diferente | | Projeto | gcloud projects list | Listar projetos aos quais você tem acesso |
Adicionar diretamente a qualquer comando do gcloud permite que você aponte para um projeto específico nessa única invocação sem alterar sua Configuração ativa. A estrutura de comandos do gcloud segue o padrão , portanto, uma vez que você internalize esse padrão, muitas vezes pode inferir o comando correto sem memorizá-lo.
Para permitir que um aplicativo chame as APIs do GCP sem um arquivo de chave de conta de serviço, configure o Application Default Credentials (ADC). Executar configura o ADC no seu ambiente de desenvolvimento local, após o qual qualquer