← Google Associate Cloud Engineer: operação prática
08 / 9 · 60 MIN

Identidade efetiva, contexto e caminho de acesso

Relaciona ADC, conta de publicação, identidade runtime, tokens e conectividade com o pedido que realmente falha.

Recolher o contexto antes de alterar permissões

Num incidente fictício de reconciliação, o terminal funciona e a aplicação falha. Regista projeto, região, recurso, operação e principal observado, sem expor tokens. Uma operação bem-sucedida numa sessão pessoal não demonstra acesso do processo. O script de mudança deve declarar o projeto pretendido e validá-lo antes de escrever. O nome do serviço ou o aspeto do prompt não são evidência suficiente do destino. Esta preparação reduz mudanças em contas erradas e ajuda a passar um diagnóstico claro entre developers, cloud e APS.

Seguir a pesquisa ADC do processo

Uma biblioteca que usa ADC procura primeiro configuração indicada por GOOGLE_APPLICATION_CREDENTIALS, depois o ficheiro ADC local e, quando aplicável, a identidade anexada através do metadata server. No caso da VM, uma variável herdada pode selecionar outra identidade antes da conta anexada. Não se deve presumir que a variável contém sempre uma chave: pode referenciar configuração de federação aprovada. Confirma a origem e o principal efetivos com informação não secreta. Alterar grants da conta anexada sem essa verificação pode aumentar privilégio sem mudar o erro observado.

Separar CLI, deployer e service identity

A configuração de credenciais do gcloud e a configuração ADC não são a mesma. Além disso, conseguir publicar uma revisão com uma service account não significa que essa conta tem acesso aos dados da aplicação. Desenha três ações separadas: o operador ou pipeline prepara a publicação, a plataforma executa com a identidade escolhida e essa identidade pede acesso ao recurso. Uma recusa ao ler um bucket deve ser relacionada com o principal runtime e o âmbito do bucket. Corrige o grant mínimo necessário e revê concessões de diagnóstico que deixaram de fazer sentido.

Verificar o destinatário e a permissão do token

Uma chamada entre serviços Cloud Run privados precisa do contrato de autenticação e da autorização aplicáveis. No exemplo sem custom audience, A obtém um ID token destinado a B e chama o endpoint de B. O caminho /settle do pedido não é por si a audience. Um token válido também não concede run.invoker automaticamente. Se a audience estiver errada, dar Owner não a corrige. Regista tipo de token, destinatário esperado e principal, sem copiar o token para o ticket. Ensaiar o serviço como administrador não substitui o teste da identidade chamadora.

Preparar APIs e quota para a janela

API ativada num projeto não significa API ativada no projeto de produção. Confirma o destino antes de pedir mais permissões. Para quota, calcula o pico enquanto antigas e novas instâncias coexistem: 56 unidades usadas mais quatro instâncias de oito dá 88, acima do limite explícito de 80. Faltam oito unidades neste modelo. Aprova capacidade adicional ou adapta o rollout antes da janela, mantendo os requisitos de disponibilidade. A conta não demonstra capacidade física garantida nem elimina limites de outro âmbito; esses pressupostos precisam de verificação separada.

Distinguir API Google e destino de parceiro

Private Google Access pode permitir a uma VM sem IP externo chegar a APIs Google suportadas, com a configuração adequada. Isso não representa saída genérica para qualquer parceiro HTTPS. Quando o batch passa a chamar um fornecedor externo, o desenho deve identificar o caminho de egress aprovado, por exemplo NAT ou proxy, além de DNS, rotas e regras. A conectividade à API Google não é prova de acesso ao parceiro. Evita publicar entrada na VM quando o requisito é apenas iniciar saída; confirma também a resposta de retorno e a política do destino.

Construir uma sequência de diagnóstico reproduzível

Começa pelo pedido que falhou e conserva o contexto. Verifica destino e API, origem de credenciais, principal, token quando necessário, caminho de rede e grant no recurso. A ordem pode adaptar-se à evidência: um timeout antes de HTTP sugere começar pela rede, enquanto uma recusa identificada pode apontar para autorização. Muda uma hipótese de cada vez e repete uma operação sintética representativa. No handover, deixa evidência de qual identidade funcionou e quais permissões foram removidas após o diagnóstico. Não declares recuperação apenas porque uma conta mais privilegiada teve sucesso.

NA PRÁTICA

Uma variável ADC aponta à identidade de teste numa VM de produção. Corrigir grants da conta anexada não muda o erro; confirmar o principal efetivo revela a causa.

Armadilhas comuns

Confundir login gcloud e ADC; dar grants à conta errada; usar audience do chamador; confundir API ativada com autorização; aplicar Private Google Access a qualquer parceiro.

Tópicos relacionados: IAM e federação · Redes privadas e contexto de projeto

Leva esta ideia contigo

O diagnóstico deve ligar o pedido a uma identidade e a um destino concretos antes de alterar acesso.

Criar conta

Referência: Application Default Credentials · Standard exam guide linked 2026-09-29; edition date unconfirmed

Google Cloud é uma marca comercial de Google LLC. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por Google. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.