Cloud Digital Leader — Questões de prática e simulado

O Cloud Trace é o serviço de rastreamento distribuído do Google Cloud, que acompanha as requisições entre microsserviços e registra a latência em cada etapa (docs.cloud.google.com/trace/docs/overview). Ele gera visualizações em cascata que mostram quanto tempo cada serviço leva para processar uma requisição, o que facilita apontar os gargalos. O Cloud Trace se integra ao GKE, ao Cloud Run e ao App Engine, e oferece suporte à instrumentação com OpenTelemetry. Por que não o Cloud Monitoring? Ele acompanha métricas como uso de CPU e memória, mas não rastreia o caminho de cada requisição entre os serviços. Por que não o Error Reporting? Ele identifica erros e exceções do aplicativo, não gargalos de latência. Por que não o Cloud Logging? Ele captura entradas de log, mas não oferece rastreamento de latência no nível da requisição entre as fronteiras dos serviços. Dica de prova: identificar qual serviço específico causa a latência em uma cadeia de requisições distribuída = Cloud Trace.

O AutoML na Agent Platform automatiza a seleção de algoritmos, o ajuste de hiperparâmetros e o treinamento do modelo, sem exigir experiência em ML nem programação (docs.cloud.google.com/vertex-ai/docs/start/training-methods). Para times com pouca experiência em ML e conjuntos de dados menores, o AutoML produz modelos de alta qualidade mais rápido, já que elimina a necessidade de escrever código de treinamento e de desenvolver pipelines de dados. A comparação oficial dos métodos de treinamento confirma: o AutoML não precisa de experiência em ciência de dados e dispensa código. Por que não treinamento personalizado? Ele exige bastante experiência em ML para desenvolver aplicações de treinamento—não produz sempre modelos melhores, independentemente da experiência. Por que não apenas APIs pré-treinadas? As APIs pré-treinadas resolvem tarefas comuns, mas não conseguem treinar com o seu conjunto de dados personalizado. Por que não 'o AutoML é só para grandes empresas'? O AutoML está disponível para todos os usuários, independentemente do tamanho da organização. Dica de prova: pouca experiência em ML + necessidade de resultados rápidos + conjunto de dados pequeno = AutoML.

O Google Cloud criptografa os dados em trânsito tanto na internet pública quanto dentro da própria rede interna (docs.cloud.google.com/docs/security/encryption-in-transit). O tráfego externo usa criptografia TLS/QUIC pelos Google Front Ends (GFEs), enquanto o tráfego interno entre serviços usa ALTS (Application Layer Transport Security) para autenticação mútua e criptografia. O Google também usa o protocolo de segurança PSP para criptografia na camada de rede, com offload em SmartNIC. Isso é automático e não exige nenhuma configuração do cliente para o tráfego padrão. Por que não só no Premium Tier? A criptografia em trânsito se aplica independentemente do tier de rede. Por que não só na internet pública? A documentação afirma explicitamente que o Google criptografa os dados dentro da própria rede interna usando ALTS. Por que não configuração manual de TLS? O Google cuida automaticamente da criptografia dos seus serviços—não são necessários certificados gerenciados pelo cliente. Dica de prova: TLS = externo; ALTS = interno. Ambos automáticos.

Escalonar para zero é a característica que mais claramente diferencia uma plataforma de aplicativos serverless de um cluster que você mantém em execução. O Cloud Run adiciona instâncias conforme as solicitações recebidas e as remove à medida que a demanda cai e, por padrão, uma revisão que não recebe tráfego é escalonada para zero instâncias. Isso não acontece no momento em que a última solicitação termina: para reduzir as inicializações a frio, o Cloud Run pode manter uma instância ociosa por até 15 minutos depois que ela termina de processar solicitações, e uma instância ociosa pode manter recursos como conexões abertas com o banco de dados. Para cargas de trabalho com longos períodos de ociosidade, como ferramentas internas ou endpoints sazonais, isso significa que nenhuma instância fica em execução durante a noite. A contrapartida é a inicialização a frio: a primeira solicitação depois que a revisão foi escalonada para zero precisa esperar enquanto uma nova instância é criada, o que pode adicionar uma latência perceptível. Equipes que não podem aceitar essa latência configuram um número mínimo de instâncias para manter uma delas aquecida, trocando deliberadamente algum custo de ociosidade por um tempo de resposta previsível.