Developing Solutions for Microsoft Azure

De acordo com a documentação da Microsoft, Strong consistency oferece linearizability — as leituras sempre retornam a gravação confirmada mais recente. Ela tem a maior latência de gravação porque os dados precisam ser replicados e confirmados de forma síncrona entre regiões. Os cinco níveis, do mais forte para o mais fraco: Strong, Bounded Staleness, Session, Consistent Prefix, Eventual.

Por que os distratores estão errados:

• Eventual: consistência mais fraca, com menor latência e sem garantias de ordenação.
• Session: nível intermediário; garante leituras/gravações monotônicas apenas dentro de uma sessão de cliente.
• Bounded staleness: quase forte, mas permite uma janela de atraso configurável (tempo ou operações).

Dica de prova: conheça todos os cinco níveis em ordem. Strong = linearizability + maior latência. A latência de gravação equivale a 2x RTT entre as regiões mais distantes.

De acordo com a documentação da Microsoft, um trigger faz uma function executar e define como ela é invocada. Cada function deve ter exatamente um trigger. Bindings conectam functions declarativamente a recursos externos para entrada/saída sem escrever boilerplate de conexão. Uma function pode ter vários bindings de entrada e saída, mas apenas um trigger.

Por que os distratores estão errados:

• 'Trigger envia dados para fora; binding recebe entrada': está invertido — triggers invocam a function; bindings lidam com I/O de dados nas duas direções.
• 'Mesma coisa com nomes diferentes': triggers e bindings têm finalidades fundamentalmente diferentes (invocação vs. conexão de dados).
• 'Triggers funcionam apenas com HTTP': triggers oferecem suporte a HTTP, timer, queue, blob, Cosmos DB, Event Hub e muitos outros serviços.

Dica de prova: um trigger por function (invocação). Vários bindings permitidos (I/O de dados). Bindings são declarativos — não é necessário código de conexão com SDK.

As system-assigned managed identities estão atreladas ao ciclo de vida de um único recurso do Azure: são criadas quando o recurso é criado e excluídas quando o recurso é excluído (relação 1:1). As user-assigned managed identities são recursos autônomos do Azure, com ciclo de vida independente, que podem ser compartilhadas entre vários recursos (muitos para muitos). Análise dos distratores: Os dois tipos são gratuitos — não há diferença de custo. Os dois oferecem suporte aos mesmos mecanismos de autenticação — não existe distinção entre certificado e segredo. Os dois conseguem acessar os mesmos serviços do Azure via RBAC — o escopo de acesso depende das atribuições de função, não do tipo de identidade. Ref: learn.microsoft.com/entra/identity/managed-identities-azure-resources/overview

A instrumentação automática (codeless attach) habilita o monitoramento com Application Insights sem nenhuma alteração de código. No App Service, você a habilita pelo portal do Azure ou pela CLI. Ela coleta automaticamente telemetria de requisições, rastreamento de dependências, registro de exceções e contadores de desempenho para .NET, Java, Node.js e Python. Análise dos distratores: A instrumentação manual com o SDK exige adicionar pacotes NuGet/npm e alterar o código. Os processadores de telemetria personalizados exigem integração com o SDK e código para filtrar ou modificar a telemetria. O OpenTelemetry SDK também exige alterações de código para configurar os exportadores. A instrumentação automática troca profundidade de personalização pela rapidez de uma configuração sem código. Ref: learn.microsoft.com/azure/azure-monitor/app/codeless-overview