Developing Solutions for Microsoft Azure

D’après la documentation Microsoft, Strong consistency fournit la linéarisabilité : les lectures retournent toujours l’écriture validée la plus récente. Elle a la latence d’écriture la plus élevée, car les données doivent être répliquées et validées de manière synchrone entre les régions. Les cinq niveaux, du plus fort au plus faible : Strong, Bounded Staleness, Session, Consistent Prefix, Eventual.

Pourquoi les distracteurs sont faux :

• Eventual : cohérence la plus faible, avec la latence la plus basse et aucune garantie d’ordre.
• Session : niveau intermédiaire ; garantit les lectures/écritures monotones uniquement au sein d’une session cliente.
• Bounded staleness : proche de Strong, mais autorise une fenêtre de décalage configurable (temps ou opérations).

Conseil d’examen : connais les cinq niveaux dans l’ordre. Strong = linéarisabilité + latence la plus élevée. La latence d’écriture équivaut à 2x le RTT entre les régions les plus éloignées.

D’après la documentation Microsoft, un trigger provoque l’exécution d’une fonction et définit comment elle est invoquée. Chaque fonction doit avoir exactement un trigger. Les bindings connectent de manière déclarative les fonctions à des ressources externes pour l’entrée/sortie, sans écrire de code boilerplate de connexion. Une fonction peut avoir plusieurs bindings d’entrée et de sortie, mais un seul trigger.

Pourquoi les distracteurs sont faux :

• « Trigger sends data out; binding receives in » : c’est inversé — les triggers invoquent la fonction ; les bindings gèrent les données I/O dans les deux sens.
• « Same thing with different names » : les triggers et les bindings ont des objectifs fondamentalement différents (invocation vs connexion aux données).
• « Triggers work only with HTTP » : les triggers prennent en charge HTTP, timer, queue, blob, Cosmos DB, Event Hub et beaucoup d’autres services.

Conseil d’examen : un trigger par fonction (invocation). Plusieurs bindings autorisés (data I/O). Les bindings sont déclaratifs — aucun code de connexion SDK n’est nécessaire.

Les system-assigned managed identities sont liées au cycle de vie d'une seule ressource Azure : créées en même temps que la ressource, supprimées en même temps qu'elle (relation 1:1). Les user-assigned managed identities sont des ressources Azure autonomes, avec leur propre cycle de vie, qui peuvent être partagées entre plusieurs ressources (relation plusieurs-à-plusieurs). Analyse des distracteurs : Les deux types sont gratuits — aucune différence de coût. Les deux prennent en charge les mêmes mécanismes d'authentification — pas de distinction certificat / secret. Les deux peuvent accéder aux mêmes services Azure via RBAC — la portée d'accès dépend des attributions de rôles, pas du type d'identité. Ref: learn.microsoft.com/entra/identity/managed-identities-azure-resources/overview

L'instrumentation automatique (codeless attach) active la supervision avec Application Insights sans aucune modification de code. Dans App Service, tu l'actives depuis le portail Azure ou la CLI. Elle collecte automatiquement la télémétrie des requêtes, le suivi des dépendances, la journalisation des exceptions et les compteurs de performance pour .NET, Java, Node.js et Python. Analyse des distracteurs : L'instrumentation manuelle avec le SDK impose d'ajouter des packages NuGet/npm et de modifier le code. Les processeurs de télémétrie personnalisés exigent une intégration du SDK et du code pour filtrer ou modifier la télémétrie. Le OpenTelemetry SDK demande lui aussi des modifications de code pour configurer les exportateurs. L'instrumentation automatique échange la profondeur de personnalisation contre la rapidité d'une mise en place sans code. Ref: learn.microsoft.com/azure/azure-monitor/app/codeless-overview