Prérequis et périmètre
Le programme officiel demande les certifications valides F5-CA BIG-IP, F5-CTS LTM et F5-CTS DNS.
Le blueprint définit les compétences d’architecture. Les APIs, templates, versions et modèles de licence doivent être vérifiés dans la documentation actuelle de chaque composant. Consulter la fiche officielle F5.
Les étapes et exercices ci-dessous sont une proposition pédagogique Samhan. Les objectifs sont reformulés en repères courts ; leur périmètre détaillé reste celui des blueprints. Les exemples sont à adapter à un laboratoire autorisé et à la documentation de vos versions.
Examens associés
Séparer infrastructure, initialisation et publication avant de valider le service et ses changements de capacité.
Télécharger le schéma en SVG · version claireRelier cloud, identité et application
Commencez par les responsabilités partagées, les identités d’administration et les dépendances applicatives. Une capacité de calcul supplémentaire ne rend pas automatiquement l’application mobile.
Pour déplacer ou étendre un service, relevez sessions, données, noms, certificats et chemins réseau. Le changement doit préserver un parcours métier observable ; un test réseau seul ne valide pas la cohérence des données.
| Examen | Objectif | Repère de révision |
|---|---|---|
| 402 | 1.01 | Modèles cloud |
| 402 | 1.02 | IAM |
| 402 | 1.03 | Mobilité : notions |
| 402 | 1.04 | Mobilité : application |
Exercice de compréhension
Décrivez une application qui doit absorber une hausse de charge. Listez ce qui peut être répliqué, ce qui reste partagé et ce qui détermine le site de réponse.
Lectures pour cette étape
Choisir l’infrastructure et ses dépendances
Comparez instances, plateformes et capacités avec les fonctions réellement activées. Intégrez la reprise, les quotas cloud, les routes et les limites du SDN au dimensionnement.
Les chemins de bascule cloud ne reproduisent pas nécessairement les mécanismes d’un réseau physique. Documentez les ressources modifiées par la reprise et les permissions nécessaires. Distinguez initialisation du système, publication applicative et orchestration du fournisseur.
| Examen | Objectif | Repère de révision |
|---|---|---|
| 402 | 2.01 | Licences et support |
| 402 | 2.02 | Contraintes |
| 402 | 2.03 | Virtualisation |
| 402 | 2.04 | Limites SDN |
| 402 | 2.05 | Choix de plateforme |
| 402 | 2.06 | Architecture multi-tier |
| 402 | 2.07 | Services opérateur |
| 402 | 2.08 | Provisionnement : conception |
| 402 | 2.09 | Provisionnement : arbitrage |
Exercice de compréhension
Dessinez une architecture sur deux zones. Expliquez comment le trafic atteint l’instance saine, qui modifie les ressources réseau et quelles permissions minimales sont nécessaires.
Lectures pour cette étape
Préparer une migration vérifiable
Construisez une séquence de migration avec inventaire, dépendances, critères de passage et retour arrière. Les certificats, accès, données et noms doivent être cohérents au moment du changement de trafic.
Comparez une recette directe et une recette passant par le chemin final. Les différences de source, MTU, route ou politique peuvent expliquer un comportement qui n’apparaît pas dans le test isolé du backend.
| Examen | Objectif | Repère de révision |
|---|---|---|
| 402 | 3.01 | Plan de migration |
| 402 | 3.02 | Migration : réalisation |
| 402 | 3.03 | Migration : arbitrage |
| 402 | 3.04 | SDN : intégration |
| 402 | 3.05 | SDN : arbitrage |
Exercice de compréhension
Rédigez un plan de migration de recette avec arrêt de décision, validation de données, modification du trafic et condition de rollback. Ajoutez un cas de dépendance SDN indisponible.
Lectures pour cette étape
Déployer et observer une instance
Reliez la taille et la région aux contraintes de trafic, de disponibilité et de proximité des dépendances. Une instance démarrée n’est pas encore une application publiée ni un service prêt à reprendre.
Préparez des vérifications séparées pour infrastructure, système et service. Identifiez les ressources que l’équipe cloud et l’équipe BIG-IP doivent observer ensemble pendant la recette et les changements.
| Examen | Objectif | Repère de révision |
|---|---|---|
| 402 | 4.01 | Taille et région |
| 402 | 4.02 | Déploiement |
Exercice de compréhension
Préparez une liste de recette d’une instance neuve : accès, licence, réseau, publication, observabilité et reprise. Associez une preuve à chaque point.
Lectures pour cette étape
Construire un workflow déclaratif
Découpez le workflow en responsabilités : créer l’infrastructure, initialiser BIG-IP, publier l’application puis valider le service. DO et AS3 traitent des objets différents ; le contrôle d’accès et les erreurs doivent rester visibles à chaque étape.
Un workflow robuste peut être rejoué et rendre compte d’un échec partiel. Versionnez les déclarations, protégez les secrets, vérifiez la compatibilité des schémas et définissez ce qui doit être supprimé ou conservé lors d’un retour arrière.
| Examen | Objectif | Repère de révision |
|---|---|---|
| 402 | 5.01 | Modèle API |
| 402 | 5.02 | API : réalisation |
| 402 | 5.03 | API : arbitrage |
| 402 | 5.04 | Bursting : conception |
| 402 | 5.05 | Bursting : arbitrage |
| 402 | 5.06 | Templates : application |
| 402 | 5.07 | Templates : évaluation |
| 402 | 5.08 | Provisionnement : réalisation |
| 402 | 5.09 | Provisionnement : évaluation |
Exercice de compréhension
Décrivez une hausse puis une baisse de capacité : signal déclencheur, provisionnement, publication, contrôle de santé, modification du trafic et drainage. Indiquez le résultat attendu si une étape échoue.
Lectures pour cette étape
Relier les étapes
Présentez une architecture, son plan de migration et un workflow de capacité dynamique. Justifiez le comportement en panne et la manière de constater le retour au service.
Blueprints et références officielles
Références consultées le . Les versions et conditions d’accès évoluent : vérifiez votre fiche d’examen avant l’inscription.