Google Cloud Developer Professional

1. 1.Uma equipe empacota uma API HTTP sem estado como um contêiner. O tráfego é irregular, cai a zero à noite, e a equipe não quer gerenciar nós, clusters nem políticas de escalonamento. Qual plataforma atende melhor a esses requisitos?

   • ACloud RunResposta correta
   • BGoogle Kubernetes Engine Standard
   • CGrupos de instâncias gerenciadas do Compute Engine
   • DAmbiente flexível do App Engine

   Por quê

   O Cloud Run executa contêineres sem estado, escala automaticamente conforme o volume de requisições, reduz a zero quando ocioso e não exige gerenciamento de cluster ou de nós. O GKE Standard exige gerenciar cluster e pools de nós. O Compute Engine exige gerenciar máquinas virtuais e grupos de instâncias. O ambiente flexível do App Engine mantém pelo menos uma instância ativa e não escala a zero.

2. 2.Um aplicativo precisa de contêineres sidecar, daemons por nó para coleta de logs, agendamento personalizado de pods com base em afinidade de nós e StatefulSets com volumes persistentes. Qual plataforma a equipe deve escolher?

   • AGoogle Kubernetes EngineResposta correta
   • BServiços do Cloud Run
   • CJobs do Cloud Run
   • DCloud Functions

   Por quê

   O Google Kubernetes Engine expõe toda a API do Kubernetes, incluindo DaemonSets, StatefulSets, regras de afinidade e sidecars. Os serviços do Cloud Run executam um único grupo de contêineres com um modelo muito mais restrito, sem DaemonSets nem controle de agendamento por nó. O Cloud Functions executa funções individuais. Os jobs do Cloud Run executam tarefas finitas, e não cargas de trabalho persistentes com estado.

3. 3.Um aplicativo web atende usuários na Europa, na América do Norte e na Ásia a partir de um único endereço IP anycast e precisa rotear cada usuário para o backend íntegro mais próximo, encerrando o TLS na borda. Qual balanceador de carga deve ser usado?

   • AApplication Load Balancer externo globalResposta correta
   • BApplication Load Balancer externo regional
   • CApplication Load Balancer interno
   • DNetwork Load Balancer externo de passagem

   Por quê

   O Application Load Balancer externo global oferece um único IP anycast, encerra o TLS na borda do Google e roteia cada requisição para o backend íntegro mais próximo. Um Application Load Balancer externo regional atende apenas uma região. Um balanceador interno não é acessível pela internet. Um Network Load Balancer de passagem opera na camada 4 e não encerra TLS nem toma decisões de roteamento HTTP.

4. 4.Um aplicativo de compras legado mantém o carrinho na memória da instância que atendeu o usuário pela primeira vez, e os usuários perdem os carrinhos quando as requisições caem em backends diferentes. Sem reescrever o aplicativo de imediato, o que o desenvolvedor deve configurar no balanceador de carga?

   • AAfinidade de sessão no serviço de backendResposta correta
   • BUm número maior de instâncias de backend
   • CUm intervalo menor de verificação de integridade
   • DCloud CDN na frente do serviço de backend

   Por quê

   A afinidade de sessão no serviço de backend direciona as requisições de um mesmo cliente para a mesma instância de backend, o que mantém o carrinho em memória acessível. Aumentar o número de instâncias torna o problema mais provável, não menos. Um intervalo menor de verificação de integridade afeta a detecção de falhas. O Cloud CDN armazena respostas em cache e serviria dados desatualizados do carrinho, em vez de resolver a afinidade.

5. 5.Um serviço de catálogo de produtos lê as mesmas linhas do Cloud SQL milhares de vezes por segundo, e a latência de leitura domina o tempo de resposta. Os dados mudam algumas vezes por hora. Qual é a mudança mais eficaz?

   • AAdicionar um cache do Memorystore para Redis na frente do banco de dadosResposta correta
   • BAdicionar réplicas de leitura do Cloud SQL na mesma região
   • CAumentar o tamanho de máquina da instância do Cloud SQL
   • DMigrar o catálogo para o Bigtable

   Por quê

   Colocar um cache do Memorystore para Redis na frente do banco atende as leituras repetidas a partir da memória em menos de um milissegundo e remove a maior parte da carga do Cloud SQL, o que combina com dados que mudam raramente. Adicionar réplicas de leitura ajuda na vazão, mas ainda paga a latência do banco em cada leitura. Uma instância maior custa mais e não elimina a ida e volta. Migrar para o Bigtable é uma reescrita desproporcional para um catálogo pequeno.

Praticar todas as 65 questões

Perguntas frequentes