Microsoft AZ-204: Azure Functions et Informatique sans serveur — Guide d'étude

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Developer Associate AZ-204 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Azure Functions est un service de calcul serverless optimisé pour les charges de travail éphémères et pilotées par les événements. Il fait abstraction de l’infrastructure pour que vous puissiez vous concentrer sur le code qui répond à des événements provenant de points de terminaison HTTP, de files d’attente, de blobs, de flux de modification de données et de services de streaming. Vous sélectionnez un plan d’hébergement qui régit la mise à l’échelle, la tarification et le comportement de démarrage à froid (cold start) ; vous liez votre code à des déclencheurs et des sources de données avec des liaisons déclaratives ; et vous pouvez éventuellement composer des workflows fiables et de longue durée en utilisant Durable Functions. Une configuration robuste, un déploiement reproductible et une observabilité approfondie avec Application Insights complètent la plateforme pour les systèmes de production.

Plans d’hébergement, mise à l’échelle et démarrages à froid

Le choix d’un plan d’hébergement détermine les caractéristiques d’exécution et le coût.

• Plan Consommation :

  • Mise à l’échelle et tarification : Paiement à l’exécution et à la consommation de ressources. La plateforme effectue un scale-out automatique en fonction des événements. Le nombre d’instances est réduit à zéro en période d’inactivité.
  • Limites d’exécution : Le délai d’expiration (timeout) de la fonction est configurable jusqu’à 10 minutes pour les fonctions non-HTTP ; les fonctions HTTP ont des délais d’expiration pratiques plus courts en raison de la connectivité du client.
  • Démarrage à froid : Les démarrages à froid (cold starts) se produisent après des périodes d’inactivité ou lors d’un scale-out lorsque de nouvelles instances s’initialisent. Le temps de démarrage dépend du langage, des dépendances et de la taille de l’application.
  • Réseau/fonctionnalités : Prend en charge le réseau public par défaut. Ensemble de fonctionnalités limité par rapport au plan Premium (par exemple, pas d’intégration VNET). Les slots de déploiement ne sont pas disponibles.

• Plan Premium :

  • Mise à l’échelle et tarification : Se met à l’échelle en fonction des événements mais maintient des instances « préchauffées » pour éliminer les démarrages à froid. Facturé en fonction des cœurs-secondes et de la mémoire allouée pour les instances actives et préchauffées.
  • Limites d’exécution : Durée d’exécution pratiquement illimitée (soumise aux contraintes du client HTTP). Recommandé pour les charges de travail sensibles à la latence ou plus lourdes.
  • Atténuation du démarrage à froid : Les instances préchauffées maintiennent le runtime actif. Vous contrôlez le nombre d’instances préchauffées par plan, offrant une latence prévisible en cas de pic de charge.
  • Réseau/fonctionnalités : Intégration VNET, points de terminaison privés, tailles d’instance accrues et slots de déploiement pris en charge.

• Plan Dédié (App Service) :

  • Mise à l’échelle et tarification : S’exécute sur des instances App Service provisionnées avec des règles de mise à l’échelle manuelle ou automatique. Vous payez pour le plan App Service sous-jacent, indépendamment de l’utilisation.
  • Limites d’exécution : Pas de délai d’expiration imposé par la plateforme pour l’exécution en arrière-plan. Idéal si vous disposez déjà d’une capacité App Service excédentaire ou si vous avez besoin de performances constantes.
  • Atténuation du démarrage à froid : Activez l’option Always On pour maintenir l’application chargée. Pas de mise à l’échelle à zéro (scale-to-zero) ; les instances restent actives.

Choisissez le plan Consommation pour les charges de travail sporadiques et optimisées en termes de coûts, le plan Premium pour les besoins de faible latence et d’intégration VNET, et le plan Dédié lors de la consolidation avec une capacité App Service existante ou si un contrôle total est requis. Pour une latence ultra-faible, le plan Premium avec des instances préchauffées ou le plan Dédié avec l’option Always On réduit les démarrages à froid. Minimisez davantage l’impact du démarrage à froid en réduisant les dépendances, en utilisant l’exécution à partir d’un package (run-from-package) et en initialisant les clients de manière paresseuse (lazy initialization).

Déclencheurs et liaisons (Triggers and Bindings)

Les fonctions sont activées par des déclencheurs (triggers) et interagissent avec les données via des liaisons (bindings). Les déclencheurs définissent comment et quand une fonction s’exécute. Les liaisons connectent de manière déclarative les services externes pour les entrées/sorties sans nécessiter de code SDK impératif.

Déclencheurs courants :

• Déclencheur HTTP : Expose des points de terminaison pour des API de style REST ou des webhooks. Les niveaux d’autorisation incluent Anonyme (Anonymous), Fonction (Function) et Administrateur (Admin), appliqués via des clés ou l’authentification de la plateforme. Prenez en compte l’idempotence et les délais d’attente (timeouts) pour les tâches de longue durée ; délestez le traitement vers une file d’attente ou des Durable Functions si nécessaire.
• Déclencheur de minuteur (Timer trigger) : Les planifications basées sur CRON s’exécutent sur une seule instance par application (par minuteur). Utilisez des expressions NCRONTAB avec une configuration de fuseau horaire. Idéal pour les tâches de maintenance, d’interrogation (polling) et de nettoyage.
• Déclencheur Azure Storage Queue : Réagit aux messages dans une file d’attente. Prend en charge la gestion des messages incohérents (poison messages) avec une file d’attente -poison après avoir atteint un seuil de tentatives de retrait (dequeue count). Configurez la taille des lots (batch size), le délai de visibilité (visibility timeout) et la concurrence via host.json.
• Déclencheur Azure Blob Storage : Réagit aux événements de création/mise à jour de blobs en utilisant une combinaison d’interrogation (polling) et de notifications Event Grid. Utilisez des modèles de chemin (path patterns) pour cibler des conteneurs et des préfixes spécifiques. Comprenez la cohérence à terme (eventual consistency) et le comportement des nouvelles tentatives pour les téléversements de gros blobs.
• Déclencheur Azure Event Hubs : Consomme des flux d’événements à haut débit avec des points de contrôle (checkpointing). Configurez la concurrence par partition, la taille des lots et la prélecture (prefetch) pour optimiser le débit. Adapté à la télémétrie et au traitement de flux (stream processing) avec un ordre préservé par partition.
• Déclencheur Azure Service Bus : Prend en charge les files d’attente ou les abonnements à des rubriques (topics). Configurez les comportements maxConcurrentCalls, prefetch et auto-complete. Les files d’attente de lettres mortes (dead-letter queues) capturent les messages qui dépassent le nombre de tentatives de livraison pour une inspection ultérieure.
• Déclencheur Azure Cosmos DB : Écoute le flux de modifications (change feed) pour les insertions et les mises à jour. Se met à l’échelle avec le nombre de partitions physiques ; assurez un provisionnement suffisant en RU (Request Units). Utilisez une collection de baux (leases collection) pour coordonner la montée en charge (scale-out) entre les instances.

Liaisons (Bindings) :

• Liaisons d’entrée (Input bindings) : Fournissent des données en entrée à la fonction, par exemple, le contenu d’un blob, une entité de table, des documents Cosmos DB ou les métadonnées d’un message de file d’attente. En .NET, des attributs (par ex.,

undefined

) ou le fichier function.json définissent la liaison ; dans d’autres langages, la configuration est déclarative.

• Liaisons de sortie (Output bindings) : Écrivent des données sans utiliser de SDK, par exemple, mettre un message en file d’attente, créer un blob, envoyer à Event Hub/Service Bus ou écrire dans Cosmos DB. Les fonctions peuvent avoir plusieurs liaisons de sortie ou retourner une seule sortie depuis la signature de la fonction.
• Expressions de liaison (Binding expressions) : Paramètrent les détails de connexion et les chemins à l’aide de variables (placeholders), par exemple, {queueTrigger}, {rand-guid} et les paramètres d’application basés sur l’environnement. Les propriétés de connexion référencent les noms des paramètres d’application, permettant la rotation et la gestion des secrets. Préférez les connexions basées sur l’identité avec une identité managée (managed identity) lorsque cela est pris en charge pour éviter d’intégrer des secrets.
• Concurrence et traitement par lots (Concurrency and batch) : Contrôlez la concurrence et la taille des lots dans host.json par extension (queues, serviceBus, eventHub) pour ajuster le débit et l’utilisation de la mémoire. Validez la gestion des messages incohérents (poison) et des lettres mortes (dead-letter) pour garantir que les échecs sont bien remontés.

Concevez les déclencheurs et les liaisons pour l’idempotence, la contre-pression (backpressure) et l’isolation des défaillances. Pour les sources garantissant une livraison « au moins une fois » (at-least-once) (files d’attente, Event Hubs, Service Bus), écrivez des fonctions idempotentes et résilientes aux nouvelles tentatives.

Durable Functions : Patrons d’orchestration fiables

Durable Functions étend Azure Functions avec une orchestration avec état (stateful) et fiable pour les workflows de longue durée, en utilisant un framework de tâches durables.

Types de fonctions :

• Fonctions d’orchestrateur : Décrivent la logique du workflow dans le code à l’aide de constructions déterministes. Les orchestrateurs rejouent leur état lors de la réception d’événements et doivent éviter les API non déterministes (DateTime.Now, les nombres aléatoires, les appels réseau) sans utiliser les assistants appropriés. Utilisez les API du client d’orchestration Durable pour démarrer, interroger et gérer les instances.
• Fonctions d’activité : Exécutent des unités de travail discrètes comme appeler des API externes, effectuer des opérations gourmandes en CPU ou des tâches d’E/S. Les activités peuvent faire l’objet de nouvelles tentatives et sont mises à l’échelle indépendamment.
• Fonctions d’entité : Fournissent des entités durables et adressables avec un état et des opérations de petite taille et cohérents (par ex., des compteurs, l’état d’un appareil). Les entités traitent les opérations de manière sérialisée avec une cohérence monothread (single-threaded).

Patrons (Patterns) :

• Chaînage de fonctions : Enchaînent des activités dans un ordre défini (A → B → C), en passant les résultats à la suivante. Utile pour les pipelines avec des dépendances.
• Fan-out/fan-in : Démarrent plusieurs activités en parallèle et agrègent leurs résultats. Les orchestrateurs coordonnent avec une sémantique de type Task.WhenAll. Utilisez ce patron pour le traitement parallèle de tâches indépendantes.
• Interaction humaine (événements externes) : Attendent une entrée externe (par ex., une approbation) en utilisant WaitForExternalEvent avec des délais d’attente et une escalade. Combinez avec des minuteurs durables pour implémenter des SLA et une logique de compensation.
• API HTTP asynchrones : Démarrent des orchestrations et retournent une réponse 202 Accepted avec des URL de statut/requête. Les clients interrogent (poll) les points de terminaison de statut exposés par la liaison du client Durable pour obtenir le résultat final ou l’état.
• Moniteur : Points de contrôle récurrents qui s’exécutent selon une planification, par ex., interroger un point de terminaison jusqu’à ce qu’une condition soit remplie, en utilisant des minuteurs durables pour éviter de monopoliser des ressources de calcul.
• Agrégateur/Entité : Stockent un petit état à côté de la logique en utilisant des fonctions d’entité pour une coordination fine sans nécessiter un workflow complet.

Durable Functions garantit une exécution « au moins une fois » (at-least-once) des activités et une progression « exactement une fois » (exactly-once) de l’état de l’orchestrateur. Elles persistent l’état dans un stockage (par défaut, Azure Storage) ; assurez-vous que le compte de stockage répond aux besoins de débit et de fiabilité. Utilisez des stratégies de nouvelle tentative personnalisées pour les défaillances transitoires et levez des événements pour l’interaction externe. Pour les processus très longs, les orchestrations durables peuvent s’exécuter pendant des jours, voire des mois, grâce à leur durabilité intégrée.

Configuration, Déploiement et Observabilité

La configuration d’une Function App est organisée en couches et sensible à l’environnement.

• host.json : Contrôle le comportement du runtime et des extensions. Permet de configurer la journalisation (échantillonnage, niveaux de journal), functionTimeout, les paramètres des extensions (tailles de lot, concurrence, préchargement) et la version du schéma JSON. Conservez host.json dans le contrôle de code source.
• local.settings.json : Paramètres de développement local, y compris les chaînes de connexion et les paramètres d’application. N’est pas déployé sur Azure. Traitez les secrets de manière appropriée ; excluez-le des dépôts publics et utilisez les secrets utilisateur (user-secrets) ou l’injection d’environnement pour le développement local.
• Paramètres de l’application : Stockés dans la configuration de la Function App (App Service). Les paramètres critiques incluent AzureWebJobsStorage (pour le compte de stockage utilisé par les déclencheurs, les journaux et les points de contrôle), les chaînes de connexion spécifiques aux extensions et toute configuration personnalisée. Marquez les secrets comme des paramètres de slot (slot settings) pour éviter leur échange lors d’un swap. Utilisez des références Key Vault avec une identité managée pour éviter de stocker les secrets en texte clair.

Options de déploiement :

• Zip Deploy : Téléversez un fichier ZIP de vos artefacts de build vers l’application. Rapide et simple pour la CI/CD. Utilisez az functionapp deployment source config-zip ou l’API zipdeploy. Cette méthode écrit les fichiers dans le répertoire de contenu.
• Run-From-Package : Définissez WEBSITE_RUN_FROM_PACKAGE sur l’URL d’un package (ou 1 pour le plus récent). Le runtime monte le package en lecture seule, ce qui améliore le démarrage à froid (cold start) et élimine les problèmes de verrouillage de fichiers pendant le déploiement. Stockez le package dans Blob Storage avec une URL SAS pour des restaurations (rollbacks) reproductibles.
• Slots de déploiement : Les slots de préproduction (staging) et de production permettent des échanges (swaps) sans interruption de service (zero-downtime) avec préchauffage (warmup). Les slots sont pris en charge sur les plans Premium et Dedicated. Configurez des paramètres spécifiques au slot (indicateur de paramètre de slot) pour les secrets et les points de terminaison afin d’éviter les fuites entre environnements. Utilisez le préchauffage avant l’échange (preSwap warmup) pour valider les extensions et les liaisons avant que le trafic ne soit basculé.

Surveillance avec Application Insights :

• Journaux d’invocation : Chaque invocation de fonction émet une télémétrie structurée incluant les requêtes (Requests), les traces (Traces), les exceptions (Exceptions) et les dépendances (Dependencies). Utilisez ILogger (ou équivalent) pour des journaux structurés. Les ID d’opération et de corrélation relient l’activité et les dépendances entre les services.
• Live Metrics : Vue en temps réel du débit, des échecs et de la latence, sans échantillonnage. Utile pour observer les déploiements, la mise à l’échelle et les chemins critiques (hot paths). Filtrez par nom de fonction pour isoler les problèmes.
• Échecs et fiabilité : Inspectez les exceptions (Exceptions), les requêtes échouées (failed Requests) et les échecs de dépendances. Configurez des alertes sur le taux d’échec, les anomalies de FunctionExecutionCount ou la croissance de la file d’attente de lettres mortes (DLQ/poison queue). Pour les déclencheurs Storage Queue, surveillez la file d’attente -poison ; pour Service Bus/Event Hubs, surveillez la santé de la file d’attente de lettres mortes (dead-letter) et des points de contrôle (checkpoint). Ajustez les politiques de nouvelle tentative (retry policies) et d’attente exponentielle (backoff) dans host.json pour réduire l’impact des erreurs transitoires.
• Traçage distribué : Activez les en-têtes de traçage W3C pour propager la corrélation via HTTP et la messagerie. Pour les Durable Functions, le framework relie la télémétrie de l’orchestration et des activités, facilitant les diagnostics de bout en bout. Ajustez l’échantillonnage pour équilibrer le coût et la fidélité.

Opérez les fonctions avec l’automatisation du déploiement (GitHub Actions/Azure Pipelines), des sondes de santé (health probes) pour les points de terminaison HTTP et un réglage tenant compte de la mise à l’échelle automatique (autoscale). Gardez les packages légers, mettez en cache les clients (par ex., HttpClient, client Service Bus) en tant que singletons statiques, et validez que les paramètres de connexion des liaisons (bindings) se résolvent au démarrage pour éviter les échecs d’exécution.

Scénario de Problème Pratique

Contoso Retail lance un service de promotion qui applique des réductions en temps réel lorsque les clients ajoutent des articles à leur panier. Le backend doit répondre à un trafic très variable avec une faible latence, appeler une API de tarification tierce et mettre à jour un document de panier dans Cosmos DB. L’équipe des opérations souhaite des déploiements sans interruption de service et une visibilité approfondie des échecs.

1. Choisir le plan d’hébergement et structurer l’application

• Utiliser un plan Azure Functions Premium avec deux instances préchauffées et une intégration VNET. Le plan Premium élimine les démarrages à froid pour les interactions de panier sensibles à la latence et sécurise le trafic sortant vers l’API tierce via un NAT ou un pare-feu dans le VNET.
• Créer une seule Function App avec une fonction déclenchée par HTTP pour le point de terminaison du panier et un orchestrateur Durable Functions pour coordonner la récupération des réductions et la mise à jour du panier.

2. Implémenter l’orchestration Durable pour la fiabilité et le parallélisme

• Fonction d’orchestration : Enchaîner les étapes pour valider l’entrée, distribuer (fan out) pour récupérer les réductions de chaque article du panier en parallèle via des fonctions d’activité, puis regrouper (fan in) pour agréger le meilleur prix. L’orchestration Durable garantit un flux de contrôle déterministe et une résilience aux redémarrages.
• Fonctions d’activité : Une activité appelle l’API tierce avec des politiques de nouvelle tentative ; une autre met à jour le panier dans Cosmos DB via une liaison de sortie (output binding). Les activités encapsulent les E/S externes et peuvent être réessayées indépendamment sans dupliquer la logique de l’orchestrateur.

3. Configurer les déclencheurs et les liaisons pour plus de simplicité

• Déclencheur HTTP avec authentification de type Function pour accepter les requêtes signées du frontend web. Retourner un code 202 avec une URL de statut pour les paniers à traitement long, ou 200 pour les chemins rapides.
• Liaison de sortie (output binding) Cosmos DB sur l’activité pour effectuer un upsert du document de panier. Les expressions de liaison utilisent le cartId de la charge utile HTTP pour cibler la bonne clé de partition.
• Utiliser une identité managée et des connexions basées sur l’identité pour les références Cosmos DB et Key Vault, supprimant ainsi les secrets des paramètres de l’application.

4. Optimiser la configuration et le déploiement

• host.json définit functionTimeout sur illimité (Premium) et configure des délais d’attente HTTP compatibles avec un maillage de services (service mesh). Les niveaux de journalisation sont réglés sur Information pour la production et l’échantillonnage (Samples) est fixé à 20 % pour maîtriser les coûts.
• Utiliser run-from-package avec des packages stockés dans un conteneur Blob versionné. Déployer via la CI avec az functionapp deployment et effectuer un swap d’un slot de préproduction vers la production pour des mises en production sans interruption de service. Marquer les chaînes de connexion et les points de terminaison d’API comme des paramètres de slot pour éviter les fuites entre environnements.

5. Surveiller et opérer

• Activer Application Insights et Live Metrics pour surveiller le débit et la latence pendant les mises en production. Configurer des alertes sur les erreurs HTTP 5xx, le taux d’échec des dépendances vers l’API de tarification, et l’augmentation des orchestrations Durable Function échouées.
• Utiliser le traçage distribué pour corréler la requête HTTP avec l’orchestration Durable et les dépendances des activités, accélérant ainsi l’analyse des causes profondes (root-cause analysis) pour les problèmes intermittents avec les services tiers.

Pourquoi ces choix :

• Le plan Premium avec des instances préchauffées assure une latence faible et constante et prend en charge l’intégration VNET pour un trafic sortant sécurisé.
• Durable Functions fournit un enchaînement fiable et des modèles fan-out/fan-in avec une gestion automatique de l’état et des nouvelles tentatives pour les appels d’API externes.
• Les liaisons (bindings) réduisent le code répétitif (boilerplate) et imposent un accès aux données déclaratif et cohérent à Cosmos DB.
• Run-from-package et les slots permettent des déploiements reproductibles et atomiques sans problèmes de verrouillage de fichiers ni interruption de service.
• Application Insights offre une observabilité en temps réel, une corrélation et des alertes alignées sur les SLA opérationnels.

← Azure App Service et Applications Web · Tous les domaines · Stockage Azure et Stockage Blob →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →