← Professional Cloud Architect: arquitetura e operação
10 / 14 · 120 MIN

Infraestrutura: rotas, recuperação e pipelines

Configurar ligações híbridas, recuperação, retenção e capacidade com evidência para passagem a RUN.

Provar o caminho usado pelo negócio

Um túnel ativo demonstra apenas parte do caminho. Antes de aceitar uma migração, escreve uma matriz com origem, destino, prefixo, porta, protocolo e resultado esperado. Distingue rotas que o Cloud Router aprende de rotas que anuncia ao peer. Em custom-only, a lista pode excluir sub-redes antes anunciadas; uma sessão com custom mode também pode deixar de herdar a configuração do router. Por isso, guarda os anúncios efetivos por sessão e compara-os com a matriz. Na ligação de uma aplicação de fundos, um prefixo ausente pode afetar o batch mesmo com BGP established. Verifica também o sentido de regresso. O exercício é uma análise documental: escolhe um fluxo, identifica em que equipamento deve existir cada rota e descreve a evidência que pedirias à equipa de rede. Um ping isolado não substitui o teste do protocolo utilizado pela aplicação.

Rever o âmbito regional antes de abrir a firewall

Uma VM numa região nova pode não ter a mesma rota dinâmica das VMs antigas. Em modo regional, o processamento das rotas aprendidas fica limitado à região relevante; global permite considerar caminhos de outras regiões da mesma VPC. Esta escolha não é sinónimo de trânsito automático entre quaisquer redes. No plano de mudança, regista que regiões precisam de alcançar o serviço on-premises, os caminhos previstos e a dependência de cada ligação. Alterar uma firewall sem rota não cria conectividade. Também não basta ver o prefixo no router: confirma a rota aplicável ao recurso e o retorno. Para uma janela de migração, pede evidência anterior e posterior à mudança e define rollback se surgirem caminhos inesperados. A decisão deve explicar o alcance pretendido, a observação que o comprova e quem confirma o impacto em aplicações partilhadas.

Evitar que a recuperação amplifique a falha

Um health check de balanceamento decide para onde enviar tráfego; autohealing pode recriar uma VM. Usa critérios adequados a cada impacto. Se os probes forem bloqueados, uma aplicação saudável pode ser classificada como falhada. Se o check for demasiado sensível a pausas breves, a recuperação pode causar uma interrupção maior. O initial delay ajuda durante o arranque, mas um sucesso pode terminá-lo antecipadamente: não devolvas healthy só porque o processo iniciou se ainda falta uma fase essencial. No cenário da MIG, começa pelos logs de probes e pelo estado da aplicação, conserva evidência e corrige a observação antes de atribuir a falha a capacidade. Define um ensaio que inclua arranque lento, pausa transitória e falha persistente. Para cada um, escreve se esperas retirada de tráfego, espera ou recriação e que resultado faria interromper o rollout.

Inventariar dados antes de prometer poupança

Uma alteração de lifecycle pode demorar até 24 horas e a regra anterior ainda pode atuar nesse intervalo. Não uses a confirmação da atualização como proteção imediata. Além disso, idade, hold, retenção, versões noncurrent e soft delete são dimensões diferentes do inventário. Num bucket versionado, remover a versão live pode conservar bytes recuperáveis e custo. Para FINOPS, prepara uma tabela por conjunto de dados: volume live, histórico, proteção aplicável, regra de transição e evidência de eliminação esperada. O exercício não pede remover retenção para cumprir uma meta financeira; pede explicar por que a previsão mudou. Se uma equipa diz que já apagou tudo porque a listagem normal está vazia, pede o inventário das versões relevantes. Testa a política com dados de ensaio antes de a aplicar ao conjunto pretendido e regista quais os objetos que devem ficar protegidos.

Separar disco recuperado de serviço recuperado

Um disco regional reduz determinadas dependências de zona, mas não executa sozinho todo o plano de recuperação. Se a VM original não pode fazer detach, um procedimento autorizado pode usar force-attach na VM de recuperação; depois dessa operação, Compute Engine impede escritas da VM original nesse disco. Esta garantia não desfaz chamadas externas nem confirma que a aplicação arrancou. O runbook deve identificar o disco, a VM de destino, montagem, verificações da aplicação e reposição do tráfego. Define pontos de decisão antes de voltar a aceitar trabalho. No ensaio, a equipa de infraestrutura entrega evidência de acesso ao volume e a equipa APS confirma um fluxo funcional com referências conhecidas. Mede o tempo até ao serviço utilizável. Guardar apenas a hora do attach omite fases que podem dominar a recuperação e dar uma falsa impressão de cumprimento do objetivo.

Provisionar com dependências explícitas

Um instance template não editável pode conter um script que descarrega latest; por isso, a imutabilidade do objeto não garante repetibilidade dos bytes instalados. Fixa versões e cria um novo template para a mudança. Em GKE Standard, verifica requests e restrições de scheduling quando há Pods Pending, mesmo que a CPU medida esteja baixa. Espaço IP também pode impedir novos nós ou Pods: aumentar o máximo de nós não resolve uma faixa esgotada. Em Cloud Run, private-ranges-only não cumpre um requisito de todos os destinos através da VPC; all-traffic exige ainda validar o caminho de saída. Junta estas dependências numa revisão de capacidade: versão instalada, recursos reservados, endereçamento, quotas e caminho de rede. Para cada item, pede uma medida ou configuração concreta. Uma declaração genérica de que autoscaling está ativo não demonstra que a aplicação consegue crescer dentro da janela exigida.

Tornar pipelines de ML reproduzíveis e autorizados

Na documentação atual, os pipelines surgem sob Gemini Enterprise Agent Platform. Usa a fonte atual sem presumir que um URL antigo define o nome do produto. A cache de um passo depende da interface declarada, incluindo parâmetros, IDs de artefactos e especificação do componente. Se current.csv muda sem mudar essa identidade, a aplicação pode reutilizar um resultado que já não corresponde aos dados pretendidos. Representa a versão ou desativa a cache do passo quando necessário. Se a execução falha a gravar artefactos, identifica a service account runtime: permissões do engenheiro que submeteu o job não são herdadas automaticamente. No exercício, constrói um registo com versão do dataset, componente, decisão de cache, identidade executora e permissões nos recursos. Esse registo deve permitir explicar por que dois resultados diferem sem recorrer apenas ao nome visual do job.

Escolher capacidades de AI e fechar a aceitação

Escolhe uma API pela tarefa e pela saída necessária. Num protótipo Cloud Vision, DOCUMENT_TEXT_DETECTION fornece estrutura de texto denso; isso não valida uma instrução financeira. Pode haver outras soluções adequadas, como Document AI para necessidades documentais específicas. Da mesma forma, a presença de um modelo no Model Garden não substitui a análise do aviso, modo de execução e critérios internos. Um modelo suspeito pode continuar tecnicamente implantável. Como exercício final, prepara uma decisão de go/no-go para o cenário híbrido: lista as duas causas observadas, as mudanças propostas, a evidência exigida e uma alternativa condicionada a rollback aprovado. Depois acrescenta uma dependência de ML que usa os ficheiros do batch e explica que identidade de dados e permissões teriam de constar do handover. Esta análise é documental; não afirma execução em serviços Google.

NA PRÁTICA

Uma migração apresenta túnel ativo, prefixo ausente e probes bloqueados. A aceitação exige corrigir encaminhamento e observação, depois testar o serviço.

Armadilhas comuns

Confundir BGP ativo com serviço acessível, recriação com recuperação, objeto não live com dados eliminados e utilizador do job com identidade runtime.

Tópicos relacionados: Migração híbrida · Capacidade e FINOPS · Passagem a RUN

Leva esta ideia contigo

Relaciona configuração, identidade e observação: cada garantia tem um âmbito e cada decisão de aceitação precisa de evidência nesse âmbito.

Criar conta

Referência: Cloud Router advertised routes · Current linked standard guide; edition date unconfirmed (2026-09-30 inspection)

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.