Retirée
HashiCorp · HC-CA · Associate
HashiCorp Certified: Consul Associate (003)
Prépare l’examen HashiCorp Certified: Consul Associate (003) (HC-CA) avec des questions d’entraînement réalistes et illimitées tirées des domaines officiels de l’examen, et des explications IA pour chaque réponse. Commence gratuitement.
Cette certification a été retirée.
Aperçu
À propos de l’examen
La certification HashiCorp Certified : Consul Associate (003) valide les connaissances fondamentales de Consul pour la mise en réseau des services, notamment la découverte de services, la vérification de l'état de santé, le service mesh avec mTLS, la configuration clé-valeur et les bases du multi-datacenter. Elle confirme que tu comprends l'architecture de Consul, que tu sais faire fonctionner un petit cluster, enregistrer des services, définir des intentions et te servir de Consul pour connecter des workloads sur des machines virtuelles et Kubernetes. L'examen couvre dix domaines qui englobent à la fois les opérations du control plane et le comportement du data plane.
Cette certification s'adresse aux platform engineers, aux praticiens DevOps et aux ingénieurs réseau ou sécurité chargés de la connectivité entre services. Elle convient aussi très bien aux développeurs qui intègrent leurs services à Consul pour la découverte ou le mesh, ainsi qu'aux opérateurs cumulant environ six mois de pratique concrète qui veulent formaliser leurs acquis avant de se lancer dans des déploiements Consul plus ambitieux.
Domaines
Contenu de l’examen
L'examen Consul Associate est une épreuve d'une heure, surveillée en ligne, à choix multiples. Tu vas rencontrer des questions à choix unique, à choix multiples, des vrai/faux et des questions à saisie de texte, ainsi que des scénarios qui présentent une sortie CLI, une configuration HCL ou des définitions d'intentions et te demandent de prédire le comportement. Il n'y a pas de lab en direct au niveau associate.
- Understand the Pillars of Service Networking
Découverte, suivi et surveillance de l'état de santé des services. Sécurisation de la communication entre services. Contrôle d'accès au point d'entrée. Automatisation des tâches réseau.
- Describe Consul Architecture
Composants du datacenter, agents, protocoles de communication. Haute disponibilité et scalabilité des serveurs. Server agents vs composants du data plane (client agents, Consul Dataplane). Support multi-plateforme.
- Deploy a Single Datacenter
Configurer, bootstrapper et démarrer des server agents. Client agents. Consul sur Kubernetes. Méthodes de join des agents et leur comportement.
- Register Services and Use Service Discovery
Interprétation de l'enregistrement des services, méthodes d'enregistrement, configuration des health checks, interrogation du catalog de services via CLI/API/UI/DNS, prepared queries.
- Use Consul Service Mesh
Architecture de haut niveau et bénéfices. Intentions du service mesh et leur utilisation. Options de configuration des proxies.
- Secure Agent Communication
Modèle de sécurité et de menaces. Types de certificats TLS. Paramètres de chiffrement TLS. Configuration du chiffrement gossip.
- Secure Services with Basic ACLs
Composants du système ACL et leur utilisation. Création et configuration des policies et tokens ACL. Utilisation des tokens ACL pour une communication sécurisée.
- Secure and Connect Service Mesh Applications
Consul gateways pour la connectivité du service mesh. Activation de la communication multi-datacenter.
- Monitor Consul
Observabilité du service mesh. Observabilité du datacenter.
- Operate and Maintain Consul
Gestion des serveurs. Maintien de la sécurité des communications. Sauvegarde et restauration. Options de dépannage.
Format
À quoi t’attendre
Vise environ une minute par question et marque les items plus difficiles pour y revenir plutôt que de bloquer dessus. Les questions de scénario sur les intentions, les gateways et les tokens ACL récompensent une lecture attentive, car un simple changement de source ou de destination peut inverser la réponse. Si une question fait référence à une fonctionnalité que tu n'as jamais utilisée, appuie-toi sur les fondamentaux de Consul (agents, catalog et gossip) pour raisonner vers la réponse la plus cohérente.
Attention
Où les candidats coincent
Une erreur fréquente consiste à confondre la découverte de services et le service mesh. Les candidats perdent des points en supposant que mTLS et les intentions s'appliquent à de simples requêtes DNS ou aux consultations HTTP du catalog, ou en mélangeant les rôles des sidecar proxies, des ingress gateways, des terminating gateways et des mesh gateways. Le bootstrapping des ACL, le cadrage des tokens et la différence entre agent tokens, default tokens et anonymous tokens sont eux aussi souvent mal compris.
Conseil de révision : fais tourner en local un cluster Consul multi-agents, enregistre quelques services, écris des health checks et active le service mesh de bout en bout avec au moins deux services connectés. Entraîne-toi à écrire et tester des intentions en mode allow comme en mode deny. Déroule un déploiement Kubernetes avec le Helm chart officiel pour que la synchronisation, le mesh et la configuration pilotée par annotations te deviennent familiers, puisque ces sujets reviennent régulièrement dans les objectifs de la 003.
- 01Intentions default — L'autorisation par défaut (default allow) versus le refus par défaut (default deny) est un paramètre à l'échelle du cluster ; passer en mode deny sans intentions bloque instantanément tout le trafic mesh.
- 02ACL bootstrap — Le jeton de bootstrap est à usage unique ; le perdre nécessite une procédure de réinitialisation via le fichier d'index Raft. Les candidats oublient qu'il n'est pas récupérable via l'API.
- 03Gossip vs RPC — Le protocole gossip utilise les pools serf LAN/WAN avec une clé symétrique ; le RPC utilise des certificats TLS. Chiffrer l'un ne chiffre pas l'autre.
- 04WAN federation — La fédération WAN classique utilise serf entre les datacenters ; les passerelles mesh (mesh gateways) la remplacent pour le trafic de services inter-DC mais pas pour le gossip entre serveurs.
- 05Service vs node check — Les vérifications d'état au niveau du nœud font échouer tous les services sur ce nœud ; les vérifications au niveau du service ne marquent que ce service comme critique dans le catalogue.
Détails
Logistique de l’examen
L'inscription se fait via le portail de certification de HashiCorp, avec une surveillance en ligne assurée par PSI. Les frais s'élèvent à 70,50 dollars US, plus les taxes applicables, et il te faudra une webcam, un micro, un espace de test privé et calme, ainsi qu'une pièce d'identité officielle avec photo. Un créneau est généralement disponible sous quelques jours, et il est possible de reprogrammer dans la fenêtre autorisée.
Si tu échoues, un délai d'attente s'applique avant de repasser l'examen, et chaque tentative nécessite un nouvel achat. La certification est valable deux ans, après quoi tu dois te recertifier sur la version d'examen en vigueur. La version 003 a mis à jour les objectifs pour refléter les schémas actuels de service mesh, de gateways et d'intégration Kubernetes : vérifie donc que tu révises des supports alignés sur cette version plutôt que d'anciennes ressources de l'époque 002.