Aller au contenu

Devenir AWS Authorized Instructor : un parcours enrichissant

Quelques conseils pour bien préparer le passage de l'ICA en vue de devenir AWS Authorized Instructor.

Tips pour devenir AWS Authorized Instructor

Je souhaite à travers cet article partager mon retour d'expérience sur l'ICA, l'examen nécessaire pour devenir AWS Authorized Instructor, en espérant que cela puisse aider d'autres personnes à passer cette étape et maximiser leur taux de réussite !

Le déroulé de l'ICA

L'ICA (Instructor Candidate Authorization) est un examen qu'il faut réussir pour obtenir le statut d'Authorized Instructor et pouvoir dispenser des formations agréées par AWS. Cet examen se concentre sur la formation Architecting on AWS, qui correspond à la certification AWS Architect Associate. L'ICA se déroule en deux parties sur une journée :

  • Présentation d'un module complet parmi les 13 possibles, choisi par l'examinateur.
  • Débogage d'un Lab : l'examinateur introduit des erreurs dans un lab, et le candidat doit aider l'élève (simulé par l'examinateur) à corriger le problème.

Les critères de notation

Il y a 20 critères de notation, chacun noté de 1 à 4. Pour réussir l'examen, il faut obtenir au moins 60/80. Il est important de noter que la majorité des critères concernent la forme plutôt que le fond. Pour réussir l'examen, il ne suffit pas d'être compétent sur les technologies AWS ; il faut surtout travailler sa pédagogie.

La connaissance de cette grille de notation est primordiale car elle est très précise et aide à comprendre toutes les exigences de l'examen. La grille de notation est disponible dans les cours SkillBuilder qu'AWS fournit pour la préparation à l'examen.

Le matériel d'AWS pour se préparer

Pour se préparer au mieux à l'examen, AWS demande de valider plusieurs cours Skill Builder obligatoires. Principalement, il y a :

  • Un cours de montée en compétence sur la formation, avec des liens vers du contenu pour approfondir les sujets.
  • Un cours qui donne des conseils pour dispenser une formation virtuelle.
  • Un cours sur les Labs.
  • Un cours sur Webex (le produit qu'AWS utilise pour ses formations à distance).
  • Un cours sur les bons messages à délivrer aux clients.

Il est également nécessaire d'obtenir la certification Architect Associate. Il y a beaucoup de vidéos à regarder, ce qui peut sembler intimidant au début, mais ce n'est pas si long. Un cours chapeau englobe les autres, indiquant 174 heures, ce qui correspond plutôt au temps estimé pour être prêt que le temps nécessaire pour regarder les vidéos, qui est beaucoup plus court.

En plus de ces obligations, AWS propose trois activités facultatives pour mieux se préparer à l'examen :

  • Participer à une session "What to expect at an ICA?" : une réunion d'une heure donnée par des instructeurs expliquant les points essentiels.
  • Participer à des sessions de shadowing : assister à des cours donnés par des instructeurs AWS. Cela permet d'approfondir certains points techniques mais peut ne pas répondre complètement aux attentes car l'instructeur peut enseigner comme dans un vrai cours plutôt que comme lors de l'examen.
  • Avoir un mentor : un mentor peut vous donner des conseils pour mieux préparer votre présentation et assister à une présentation d'essai pour vous faire des retours. Personnellement, je n'ai pas demandé de mentor par manque de temps, mais cela peut être intéressant.

Ma préparation et mes conseils

Ce qui m'a pris le plus de temps dans ma préparation, c'est de bien comprendre chacun des critères de notation et de m'assurer de pouvoir obtenir au moins 3/4 sur chacun d'eux, ce qui est le minimum pour réussir l'examen. En réalité, j'ai visé les 4/4 à chaque fois pour me donner une marge de sécurité.

Il faut que tous les modules soient au même niveau car on ne sait pas à l'avance lequel sera choisi. Personnellement, je suis tombé sur le module 5 : Storage.

Présentation du module

Voici les points qu'il faut préparer pour chaque module et qui permettent de gagner des points lors de la présentation :

  • Des démos.
    • Ne pas hésiter à builder des objets avant la démo pour gagner du temps dans son exécution. Bien entendu, l'infraAsCode est plus qu'un must have pour cela. Par exemple, si vous voulez créer une Lambda en démo, ne vous attardez pas à créer le rôle IAM associé, faites-le à l'avance, restez focus sur ce que vous essayez de démontrer.
    • Il faut dans la mesure du nécessaire accompagner la démo d'un whiteboard qui permet d'expliquer ce que l'on va faire et l'objectif de la démo. Ce dernier point peut être facultatif et dépend aussi de la complexité du sujet.
  • Montrer sur la console où se situent les objets et features, sans forcément faire une démo.
    • Cela permet de prouver que l'on n'est pas PPT dépendant et que l'on est capable de délivrer le cours autrement.
    • Ne perdez pas de temps à expliquer toutes les features possibles que l'on voit sur la console. Montrez l'essentiel, ne vous noyez pas dans les détails.
  • Des analogies : j'ai dû, pour chacun des cours, trouver au moins une analogie pertinente. C'est un exercice qui peut être à double tranchant, car une mauvaise analogie qui crée de la confusion peut faire perdre des points.
  • Des customer success stories : il s'agit d'aller chercher dans la banque de story d'AWS des histoires pertinentes qui permettent de mettre en avant un service ou une de ses fonctionnalités. Cela permet de rendre plus concrets les services et leurs features à l'audience.
  • Des poll questions : il s'agit de mini-quiz qui permettent de valider que les gens ont compris le sujet et/ou de favoriser l'interaction. Il ne faut pas se contenter du quiz en fin de module. J'ai personnellement utilisé mentimeter pour cela, mais tout autre outil du même genre peut faire l'affaire. AWS préconise d'utiliser la feature de poll questions de Webex, mais malheureusement, je n'ai pas la bonne licence pour les utiliser.
  • Des whiteboards, par exemple sur draw.io, en complément du PPT, qui permettent d'approfondir des points qui ne sont pas assez explicites dans le PPT. Cela permet de fluidifier son discours et ils peuvent aussi servir à mettre des réponses à des questions que l'on pourrait anticiper de la part des élèves.
  • Soigner ses introductions et conclusions. En particulier, les introductions ne doivent pas être trop longues mais doivent donner envie à l'auditoire d'en savoir plus. J'ai rédigé à l'avance une petite introduction pour chacun des modules pour ne rien laisser au hasard.
  • Il faut essayer d'impliquer les élèves dans le cours. Par exemple :
    • demander s'ils ont des questions ou pas régulièrement
    • demander s'ils se rappellent des notions que l'on a déjà vu au moment où on les recroise
    • demander si quelqu'un peut expliquer des notions génériques, par exemple la notion de container, de microservices, ce qu'est le pattern API Gateway...
    • demander à certaines personnes de parler de leurs expériences sur le sujet.

Pour cela, les présentations des élèves au tout début de l'examen sont importantes pour mesurer la maturité de l'audience sur le sujet du module.

  • Il est extrêmement important de ne pas se contenter d'expliquer les features en mode liste à la Prévert, mais d'expliquer surtout à quoi elles servent et pourquoi l'élève devrait s'en soucier. Par exemple, ne pas se contenter de dire qu'il y a des resource-based policies et des identity-based policies. Il faut essayer de donner des cas concrets qui expliquent dans quel cas on peut utiliser l'un ou l'autre. C'est un point qui sera challengé par l'examinateur si vous n'êtes pas assez explicite d'après mon expérience.
  • Il faut essayer d'avoir un discours fluide qui donne l'impression de raconter une histoire avec un cheminement logique à travers les modules. L'ordre des slides dans le PPT aide à cela bien entendu, mais il faut travailler la fluidité de son discours, et donc il faut parfaitement maîtriser le déroulé des slides pour cela. Évitez de parler de features avancées lorsque vous n'avez pas encore fini de parler des features plus basiques. N'hésitez pas à dire aux élèves qu'on parlera de ces sujets un peu plus tard. Restez maître du déroulé de votre présentation.
  • Je recommande vivement de filmer une formation à blanc pour se rendre compte du ton que l'on emprunte, des gestes que l'on fait. C'est important pour donner de la vivacité à son discours. C'est à mon avis d'autant plus important dans le cadre d'une formation virtuelle (ce qui sera probablement le contexte de l'ICA). Personnellement, je me suis rendu compte en me filmant que je manquais de dynamisme. J'ai donc pu travailler mes intonations de voix, mettre plus d'énergie et de conviction dans mon discours. Et j'ai aussi décidé de passer l'examen debout et non assis, car le fait d'être debout m'incite naturellement à faire plus de gestes avec les mains, et apporte du dynamisme à ma présentation
  • La plus grosse difficulté que j'ai eu est d'arriver à montrer tout cela tout en restant dans le timing imparti. En effet, prendre trop de temps peut vous faire perdre des points. D'ailleurs, pendant l'examen, je n'ai pas réussi à finir dans les temps, mais l'examinateur a été tolérant là-dessus car je suis tombé sur un module très dense. Deux conseils à ce sujet :
    • Lorsque l'on fait une démo, par exemple, il faut la substituer aux slides. Il ne faut pas montrer les deux à la suite l'un de l'autre car cela prend trop de temps.
    • Il est très important de se contenter du contenu des slides en termes de fond. Le but n'est pas de montrer l'étendue de votre savoir sur AWS. Bien entendu, si un élève demande un approfondissement, il faut répondre à la question, mais spontanément, ne donnez que le strict nécessaire en termes d'information. Le timing est très court déjà pour donner le strict contenu des slides.

Mon examen s'est plutôt bien déroulé car j'étais bien préparé. Ma performance a été moins bonne que lors de mes sessions d'entraînement, probablement due au stress. Il faut vraiment bien répéter pour avoir le discours le plus fluide possible lors du passage.

L'examinateur ne m'a pas posé de questions pièges ou trop difficiles qui sortent du scope de la formation, plutôt des questions basiques.

Les labs

Sur les labs, mon conseil est de les avoir faits plusieurs fois. En réalité, ils sont plutôt faciles, mais il faut bien noter tout ce qui peut engendrer des erreurs et les effets que provoquent ces erreurs, afin d'avoir immédiatement une idée de ce qui peut poser problème lorsque l'on commence à déboguer. Voici deux exemples concrets :

  • Dans le lab sur les VPC, il y a des configurations à changer sur le VPC et le subnet public pour qu'AWS assigne automatiquement un nom de domaine public et une adresse IP publique. Ce n'est pas nécessairement compliqué, mais l'examinateur peut faire exprès d'omettre ces étapes pour générer un problème. Avoir conscience de toutes ces étapes et de leurs effets peut grandement accélérer la résolution.
  • Ce n'est plus d'actualité dans les dernières versions de l'examen, mais parfois il fallait sélectionner une AMI qui n'était pas celle par défaut. Il faut le savoir, car cela peut générer une erreur. J'ai moi-même mis beaucoup de temps à trouver cette erreur lorsque j'ai fait le lab. J'avais zappé la ligne en allant trop vite...

Bien entendu, l'examinateur ne fera jamais d'erreur hors-lab. Il essaiera simplement de simuler des erreurs d'élèves, comme le fait d'avoir mal cliqué ou d'avoir sauté une étape. Si le lab ne parle pas de network ACL, par exemple, il ne devrait normalement pas changer ces configurations pour simuler une erreur.

Lors de l'examen, il est important que l'élève comprenne son erreur. L'idéal est d'aider l'élève à comprendre lui-même la nature de son erreur. Ce moment de débogage doit être un moment d'interaction et d'apprentissage pour l'élève également.

Mon lab s'est très bien passé. J'ai été interrogé sur le Lab 2 sur le VPC. L'examinateur avait vraiment mis le bazar dans le lab, et lorsque je lui disais de refaire certains objets en direct, il faisait exprès d'oublier des configurations importantes pour voir si je réagissais bien pour rattraper l'élève. J'ai pu tout déboguer, mais sans une maîtrise parfaite du lab, il m'aurait été impossible de résoudre tous les problèmes qu'il avait introduits dans le temps imparti (20 min).

Conclusion

L'ICA demande beaucoup de préparation, même pour ceux qui ont déjà plusieurs certifications AWS. Ce qui m'a pris le plus de temps, c'est d'améliorer la pédagogie de ma présentation. L'examen est très scolaire et objectivé, reflétant la mentalité data-driven d'AWS.

Bien que cette méthode puisse être débattue, elle m'a aidé à améliorer la qualité de ma présentation et à prendre conscience des points importants pour une pédagogie efficace. L'examen est exigeant et demande un investissement conséquent, mais il en vaut la peine car il vous aide à devenir un meilleur formateur.

J'espère que ces conseils seront utiles aux prochains candidats et permettront de maximiser leur taux de réussite !

Dernier