Évaluation du module

1.

Un ingénieur cloud doit gérer l’état persistant des réseaux virtuels Azure, des sous-réseaux et des groupes de sécurité réseau (NSG) sur plusieurs environnements. Vous devez vous assurer que les ressources sont créées si elles n’existent pas et mises à jour en cas de dérive de la configuration. Quelle approche d’infrastructure en tant que code convient le mieux à ce scénario ?

IaC déclarative à l’aide de modèles Azure Bicep.

IaC impérative reposant sur des scripts Bash Azure CLI.

Combinaison des deux approches écrites dans un seul fichier.

2.

Un ingénieur cloud génère un modèle de Bicep pour un compte stockage Azure à l’aide de GitHub Copilot. La sortie ne comporte aucune balise, une région codée en dur et un accès public au blob est activé. L'invite d'origine était : « Créer un compte de stockage Bicep ». Quels éléments du prompt ont le plus contribué à ces lacunes ?

Format de sortie et contexte.

Exigences et contraintes.

Exemples few-shot et attribution de rôle.

3.

Une équipe DevOps exécute un script d’approvisionnement Azure CLI selon une planification dans le cadre de la configuration automatisée de l’environnement. Lors de la deuxième exécution, le script échoue, car il tente de créer des ressources qui existent déjà. Qu’est-ce que l’ingénieur doit demander à GitHub Copilot d’ajouter ?

Une directive « set -e » au début du script afin de quitter immédiatement en cas d’échec.

Vérification de l’existence avant chaque commande de création de ressource afin que le script ignore les ressources qui existent déjà.

Commande de suppression de groupe de ressources au début du script pour supprimer toutes les ressources existantes avant de les recréer.

4.

Un ingénieur cloud active le serveur MCP Bicep dans VS Code et régénère un modèle de Bicep pour un Pare-feu Azure. La nouvelle sortie utilise une version d’API différente de la génération précédente. Quelle est la raison la plus probable de ce changement ?

Le serveur MCP a modifié l’invite avant de l’envoyer au modèle de langage.

Le serveur MCP a interrogé le registre des types Bicep en temps réel et a fourni à Copilot la version stable actuelle de l’API pour le type de ressource Pare-feu Azure.

L’extension VS Code de l’ingénieur a été mise à jour et réinitialise les préférences de version d’API par défaut.

5.

Une révision de sécurité détecte qu’une image conteneur de l’application Node.js contient des dépendances de développement, des outils de génération et des mappages sources dans l’image finale, en gonflant sa taille et sa surface d’attaque. Quelle approche gitHub requête Copilot corrige le plus directement cela ?

Demandez à Copilot d’ajouter une instruction HEALTHCHECK au Dockerfile mono-étape existant.

Demander à Copilot de générer un Dockerfile multi-étape qui copie uniquement les artefacts de production depuis l’étape de build vers une image d’exécution propre.

Demandez à Copilot d’ajouter un fichier .Dockerignore qui exclut le répertoire de tests du contexte de génération.

6.

Une équipe plateforme souhaite remplacer les secrets de principal de service Azure stockés dans GitHub Secrets par une méthode d’authentification plus sécurisée pour ses flux de travail de déploiement IaC dans GitHub Actions. Quelle approche devez-vous demander à GitHub Copilot d’implémenter ?

Stockez le mot de passe du principal de service sous la forme d’un secret chiffré GitHub et faites-le pivoter tous les 90 jours.

Utilisez la fédération OIDC avec l’action Azure/login afin que GitHub émette des jetons de courte durée auxquels Azure fait directement confiance, éliminant ainsi la nécessité d’un secret stocké.

Codez en dur les informations d’identification du principal de service dans le workflow YAML et limitez l’accès au référentiel aux membres d’équipe approuvés.

7.

Une équipe met à jour un modèle Bicep pour ajouter Azure Bastion, redimensionner le sous-réseau de pare-feu de /27 à /26 et ajouter une balise CostCenter à toutes les ressources. Un relecteur demande une description de pull request qui explique ce qui a changé et pourquoi. Quel est le moyen le plus efficace d’utiliser GitHub Copilot pour cela ?

Collez le modèle mis à jour dans Copilot et demandez-lui de générer une vue d’ensemble de l’architecture en langage brut.

Collez les anciens modèles et les nouveaux modèles dans Copilot et demandez-lui de générer un résumé des modifications groupé par catégorie, avec la raison probable et l’impact du déploiement pour chaque modification.

Demandez à Copilot d’ajouter des décorateurs @description() aux paramètres du modèle mis à jour.

8.

Un analyste de sécurité doit identifier les adresses IP sources qui génèrent le trafic le plus refusé via Pare-feu Azure au cours des 24 dernières heures et afficher les résultats sous la forme d’un graphique à barres dans Log Analytics. L’analyste n’est pas familiarisé avec KQL. Que devraient-ils demander à GitHub Copilot de produire ?

Exportez les journaux de diagnostic Pare-feu Azure dans un fichier JSON et collez-les dans Copilot Chat pour une analyse directe.

Requête KQL pour la table AzureDiagnostics qui filtre les connexions pare-feu refusées au cours des 24 dernières heures, regroupe par adresse IP source, trie par nombre décroissant et affiche un graphique à barres.

Commande Azure CLI qui répertorie toutes les règles de refus actuellement configurées sur le Pare-feu Azure.

Commentaires