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.

Os contêineres virtualizam no nível do sistema operacional, compartilhando o kernel do host, enquanto as VMs virtualizam no nível do hardware, cada uma executando um sistema operacional convidado completo (docs.cloud.google.com/migrate/containers/docs/anthos-migrate-benefits). A documentação do Google confirma que os contêineres são muito mais leves que as VMs, porque não contêm o sistema operacional e, por isso, exigem consideravelmente menos recursos de computação e memória. Isso resulta em inicialização em segundos (não em minutos) e maior densidade no mesmo hardware. Por que não 'eliminam a necessidade de qualquer sistema operacional'? Os contêineres continuam dependendo do kernel do sistema operacional do host—eles o compartilham em vez de trazer o próprio. Por que não 'só podem rodar no Google Cloud'? Os contêineres são portáveis para qualquer plataforma que ofereça suporte a runtimes de contêiner. Por que não 'isolamento de segurança mais forte'? As VMs oferecem isolamento mais forte por meio de kernels separados; os contêineres abrem mão de parte do isolamento em troca de eficiência. Dica de prova: contêineres compartilham o kernel do sistema operacional; cada VM tem o seu próprio.

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.