OpenTelemetry Certified Associate

Como é a prova

A prova oficial tem 60 questões de múltipla escolha, com até 90 minutos de prova. Custa US$ 250 com 1 retake grátis incluído, vale por 2 anos e é feita somente online, com supervisão remota (PSI). A CNCF publica a nota de corte: 75% de acertos. Os pesos por domínio também são publicados. Materiais oficiais gratuitos: exam guide e learning path.

O simulado do PassMind tem 60 questões de múltipla escolha em 90 minutos. Consideramos aprovado a partir de 75% de acertos: a mesma nota de corte publicada para a prova oficial. As questões são sorteadas de um banco de 835 questões originais, todas com explicação.

Duração

90 min

Meta do simulado

75%

Questões por simulado

60

Questões no banco

835

Domínios e pesos

Os domínios seguem o guia oficial da prova. Os percentuais são os pesos oficiais publicados pela CNCF no guia da prova.

• Fundamentals of Observability18%
• The OpenTelemetry API and SDK46%
• The OpenTelemetry Collector26%
• Maintaining and Debugging Observability Pipelines10%

Questões de amostra

5 questões do banco do PassMind, com gabarito e explicação.

1. Questão 1Fácil

   Qual é a função principal da OpenTelemetry API na telemetria de aplicações?

   • AEla cria dashboards visuais para análise de telemetria
   • BEla armazena permanentemente as informações de telemetria coletadas
   • CEla define interfaces para o código da aplicação gerar dados de telemetria
   • DEla serve como o sistema backend para monitoramento de dados
   Ver gabarito e explicação

   Resposta correta: C. Ela define interfaces para o código da aplicação gerar dados de telemetria

   A OpenTelemetry API fornece interfaces padronizadas que os desenvolvedores de aplicações usam para instrumentar seu código e produzir dados de telemetria, como traces e métricas. Ela não gerencia armazenamento de dados, monitoramento backend ou visualização, que são responsabilidades de outros componentes no ecossistema de observabilidade.

2. Questão 2Fácil

   Como o monitoring difere do observability em sistemas de TI?

   • AMonitoring coleta apenas métricas, enquanto observability foca exclusivamente em logs
   • BMonitoring rastreia problemas predefinidos, enquanto observability ajuda a identificar problemas desconhecidos
   • CMonitoring requer análise manual de dados, enquanto observability é totalmente automatizado
   • DMonitoring e observability são termos intercambiáveis para verificações de saúde do sistema
   Ver gabarito e explicação

   Resposta correta: B. Monitoring rastreia problemas predefinidos, enquanto observability ajuda a identificar problemas desconhecidos

   Monitoring envolve o acompanhamento de condições conhecidas e esperadas usando métricas específicas ou alertas, enquanto observability fornece uma compreensão abrangente que permite a descoberta e diagnóstico de comportamentos inesperados ou desconhecidos do sistema. Observability utiliza diversas fontes de dados e técnicas analíticas para explorar problemas além dos parâmetros predefinidos.

3. Questão 3Média

   Em que momento um span deve ser finalizado em um sistema de tracing?

   • ALogo após o span ser criado
   • BUma vez que toda a trace tenha sido exportada
   • CApenas se ocorrer um erro durante a operação
   • DQuando a operação que ele representa for concluída
   Ver gabarito e explicação

   Resposta correta: D. Quando a operação que ele representa for concluída

   Um span deve ser finalizado quando a operação específica que ele rastreia for concluída, marcando o término desse segmento temporizado. Finalizar um span muito cedo ou muito tarde representaria incorretamente a duração real da operação. A exportação da trace ou a ocorrência de erros estão relacionadas, mas não determinam quando um span termina.

4. Questão 4Média

   O que normalmente acontece se a auto-instrumentation estiver habilitada, mas nenhum exporter estiver configurado?

   • AA aplicação automaticamente se torna totalmente observável em every backend
   • BO Collector é instalado dentro da aplicação
   • CO SDK para de criar spans e metrics
   • DA telemetry pode ser criada, mas não enviada para nenhum lugar útil
   Ver gabarito e explicação

   Resposta correta: D. A telemetry pode ser criada, mas não enviada para nenhum lugar útil

   A telemetry pode ser criada, mas não enviada para nenhum lugar útil está correto porque instrumentation e export são etapas separadas. A auto-instrumentation pode gerar dados, mas ainda é necessário um exporter ou um Collector pipeline para entregá-los a um backend.

5. Questão 5Difícil

   Em uma pipeline OpenTelemetry Collector usando exporterhelper com sending_queue e retry_on_failure ativos, o que acontece com dados de telemetria se as tentativas de envio superam o max_elapsed_time configurado?

   • ADados de telemetria são descartados após o max_elapsed_time, mesmo se ainda houver possibilidade de retries
   • BDados ficam enfileirados indefinidamente até que o envio seja bem-sucedido
   • CO timer de retry reinicia continuamente, impedindo que dados sejam descartados
   • DO Collector bloqueia toda entrada de novos dados até que a fila de envio seja esvaziada
   Ver gabarito e explicação

   Resposta correta: A. Dados de telemetria são descartados após o max_elapsed_time, mesmo se ainda houver possibilidade de retries

   O retry_on_failure no exporterhelper utiliza max_elapsed_time para limitar duração de retries. Se os dados não forem enviados com sucesso nesse período, são descartados para evitar retenção indefinida e esgotamento de recursos. Dados não são mantidos indefinidamente, timers não reiniciam infinitamente e o Collector continua aceitando novos dados sem bloqueios.