Accueil › Certifications › PVE9-L3 › Questions gratuites

Questions gratuites PVE9-L3 — Proxmox VE 9 Certified Architect (Level 3)

Téléchargez gratuitement 99 questions d'entraînement pour la certification PVE9-L3 proposée par Proxmox. Toutes les questions sont accompagnées de corrections détaillées avec explications techniques.

Caractéristiques de l'examen blanc

Code de certificationPVE9-L3
ÉditeurProxmox
Nombre de questions99
TypeQCM avec 4 réponses possibles
Niveauprofessional
CatégorieIT
Prix100% gratuit

Aperçu de 8 questions représentatives

Voici un échantillon aléatoire de 8 questions tirées de notre base d'entraînement PVE9-L3. Pour accéder aux 99 questions complètes, lancez l'examen blanc gratuitement.

Question 1
Une entreprise déploie un cluster Proxmox VE 9 de 5 nœuds avec Ceph pour héberger 200 VMs. Chaque nœud dispose de 6 disques HDD de 4 TB et 2 NVMe de 1.6 TB. L'architecte doit dimensionner les OSD Ceph. Quelle configuration est la plus adaptée pour optimiser performances et capacité ?
  1. 6 OSD HDD par nœud pour le stockage (1 OSD par disque de 4 TB) avec les 2 NVMe dédiés comme DB/WAL pour les OSD HDD, soit un ratio de 3 OSD HDD par NVMe DB/WAL
  2. Regrouper 2 HDD par OSD (3 OSD par nœud) pour réduire la charge de recovery, et utiliser 1 NVMe comme journal partagé et l'autre comme hot-spare Ceph automatique
  3. Créer 6 OSD HDD et 2 OSD NVMe par nœud dans le même pool Ceph, puis configurer des CRUSH rules pour distribuer les écritures aléatoirement entre HDD et NVMe
  4. Configurer 3 OSD par nœud en RAID-Z sur paires de HDD via ZFS, puis utiliser les NVMe comme cache L2ARC/ZIL pour accélérer les lectures et écritures séquentielles
Question 2
Un ingénieur performance constate que des VMs exécutant des applications temps-réel sensibles à la latence (trading algorithmique) subissent des pics de latence sporadiques de 2-5ms sur un hôte Proxmox. L'analyse avec 'perf stat' montre un nombre élevé de context switches et des migrations CPU fréquentes. Le timer TSC est stable (constant_tsc confirmé). Quelle configuration optimale doit-il appliquer ?
  1. Configurer cpu: host avec les flags +invtsc,+tsc-deadline, désactiver le timer HPET dans la VM via args: -no-hpet, et isoler des cœurs CPU avec taskset pour le processus QEMU de la VM via hookscript
  2. Passer le type CPU en host-passthrough, activer le hugepages 1G statique sur l'hôte avec 'echo 16 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages', et configurer la VM avec memory hotplug désactivé
  3. Activer le CPU pinning via cgroup v2 en éditant /etc/pve/qemu-server/<vmid>.conf avec affinity: 0-7, désactiver le ballooning, et ajouter args: -overcommit cpu-pm=on pour réduire les C-states transitions
  4. Utiliser le scheduler FIFO temps-réel pour le thread QEMU principal avec 'chrt -f 90 <pid>', désactiver irqbalance sur l'hôte, et configurer numa: 1 avec des nœuds NUMA correctement mappés dans la VM
Question 3
Un administrateur Proxmox VE 9 utilise le passthrough GPU (VFIO) pour une VM de calcul scientifique. La VM démarre mais le périphérique GPU n'est pas visible dans la VM. La commande dmesg sur l'hôte montre 'vfio-pci: Unable to change power state from D3cold to D0, device inaccessible' et 'BAR 0: can't reserve mem region'. Quelle analyse et correction sont les plus pertinentes ?
  1. Vérifier que le GPU n'est pas initialisé par le driver hôte en confirmant dans dmesg que vfio-pci a bien capturé le device au boot via les options ids dans /etc/modprobe.d/vfio.conf, puis ajouter le paramètre kernel 'pcie_acs_override=downstream,multifunction' et 'video=efifb:off' pour libérer les ressources BAR
  2. Activer le paramètre 'x-vga=on' dans la configuration de la VM avec qm set <vmid> -hostpci0 0000:01:00.0,x-vga=on puis configurer le BIOS de la VM en OVMF (UEFI) car le mode SeaBIOS ne supporte pas le passthrough GPU avec les BAR 64-bit
  3. Exécuter lspci -vvv pour identifier l'adresse BAR du GPU, puis redimensionner manuellement la région mémoire avec setpci pour forcer l'allocation, et désactiver le power management PCIe avec le paramètre kernel 'pcie_aspm=off'
  4. Ajouter 'machine: q35' dans le fichier de configuration de la VM pour activer le contrôleur PCIe natif, puis configurer le paramètre 'rombar=1' et fournir le ROM du GPU extrait via gpu-rom-tool pour contourner l'initialisation UEFI du périphérique
Question 4
Un cluster Proxmox VE 9 utilise des certificats émis par une CA interne d'entreprise. L'administrateur remplace les certificats auto-signés par des certificats signés par cette CA sur tous les nœuds. Après le remplacement via l'interface GUI (Certificates > Upload Custom Certificate), la GUI se recharge correctement avec le nouveau certificat, mais les communications inter-nœuds du cluster (migration live, réplication) échouent avec des erreurs TLS 'certificate verify failed'. Les nœuds utilisent le FQDN correct correspondant au CN des certificats. Quelle est la cause et la correction appropriée?
  1. Les communications inter-nœuds utilisent le certificat cluster corosync, pas le certificat pveproxy. Il faut également remplacer les certificats corosync via 'pvecm updatecerts' après avoir placé les certificats CA dans /etc/corosync/authkey et redémarrer corosync sur tous les nœuds
  2. Le certificat de la CA interne n'est pas dans le trust store des nœuds. Il faut copier le certificat racine (et intermédiaires) de la CA dans /usr/local/share/ca-certificates/ avec l'extension .crt sur chaque nœud, exécuter update-ca-certificates, puis redémarrer pvedaemon et pveproxy pour que les connexions inter-nœuds valident la chaîne de confiance
  3. Les certificats custom uploadés via la GUI ne s'appliquent qu'à pveproxy (port 8006). Les connexions inter-nœuds de migration utilisent un canal SSH distinct qui ne vérifie pas les certificats TLS. L'erreur vient d'une incompatibilité de version TLS — il faut forcer TLS 1.3 dans /etc/pve/datacenter.cfg avec 'min_tls_version: 1.3'
  4. Lors de l'upload du certificat custom, il faut inclure la chaîne complète (certificat serveur + intermédiaires + racine) dans le champ certificat de la GUI. L'erreur vient du fait que seul le certificat serveur a été uploadé sans la chaîne. Recréer le fichier PEM avec cat server.crt intermediate.crt root.crt > fullchain.pem
Question 5
Sur un cluster Proxmox VE 4 nœuds avec HA activé, un nœud (pve3) est déclaré 'dead' par le fencing watchdog après un kernel panic. Cependant, les VMs HA ne sont pas relocalisées automatiquement. La commande 'journalctl -u pve-ha-lrm' sur les nœuds survivants montre 'ha-manager status: wait_for_agent_lock' et 'pvecm status' affiche 'Quorum: 1, Activity blocked: Yes'. Quelle est la cause la plus probable et la résolution correcte?
  1. Le cluster a perdu le quorum car le nœud mort détenait un vote critique et le cluster est configuré avec 4 nœuds sans QDevice. Avec 3 nœuds sur 4 survivants, le quorum (3) est atteint, mais si un second nœud a aussi un problème réseau partiel, l'activité est bloquée. Vérifier 'pvecm status' en détail et potentiellement déployer un corosync QDevice
  2. Le HA Manager (pve-ha-crm) ne peut pas acquérir le lock sur le storage partagé car le fencing n'est pas confirmé comme terminé. Vérifier que le watchdog hardware (IPMI ou softdog) a correctement power-cyclé pve3 avec 'ha-manager status', puis forcer le fencing avec 'pvecm fencenode pve3' si nécessaire
  3. L'affichage 'Activity blocked: Yes' indique que le quorum est insuffisant malgré 3 nœuds survivants. Avec 4 nœuds et 4 votes, le quorum requis est 3 (majorité = N/2+1). Si 'Quorum: 1' signifie que seulement 1 nœud voit le cluster, les deux autres nœuds ont probablement aussi des problèmes de connectivité corosync. Diagnostiquer avec 'corosync-cfgtool -s' sur chaque nœud
  4. Le pve-ha-lrm attend le lock agent car le fichier de lock dans /etc/pve/ha/ est corrompu suite au crash de pmxcfs pendant le kernel panic de pve3. Supprimer manuellement les fichiers de lock avec 'rm /etc/pve/ha/*.lock' et redémarrer pve-ha-lrm sur tous les nœuds
Question 6
Un architecte infrastructure met en place un pipeline CI/CD GitLab pour provisionner automatiquement des VM Proxmox via Terraform (provider bpg/proxmox). Il souhaite que le state Terraform soit protégé et que les credentials Proxmox ne soient jamais exposées dans les logs CI. Lors des premiers tests, il constate que le 'terraform plan' échoue avec une erreur 401 Unauthorized, bien que le token API fonctionne via curl depuis le runner GitLab. Quelle est la cause la plus probable et la solution appropriée ?
  1. Le provider bpg/proxmox nécessite que le token API soit passé au format 'USER@REALM!TOKENID=SECRET' dans la variable pm_api_token_secret, et non séparé en deux champs distincts comme certains autres providers. Il faut vérifier le format exact attendu par la version du provider utilisée.
  2. Le token API utilisé possède les privilèges nécessaires mais le provider bpg/proxmox requiert que l'attribut 'privilege separation' soit désactivé sur le token (coché 'Privilege Separation: No' lors de la création) pour hériter des permissions complètes de l'utilisateur associé.
  3. L'erreur 401 provient du fait que le runner GitLab utilise un proxy HTTP qui modifie les headers Authorization. Il faut configurer la variable NO_PROXY avec l'adresse du cluster Proxmox ou utiliser un tunnel SSH direct vers l'API Proxmox sur le port 8006.
  4. Le provider Terraform tente d'abord une authentification par cookie ticket PVE avant de basculer sur le token API. Il faut explicitement définir pm_auth_method='token' dans le bloc provider pour forcer l'utilisation directe du token API sans tentative de négociation cookie.
Question 7
Un cluster Proxmox VE 3 nœuds perd subitement le quorum. La commande 'pvecm status' affiche 'Quorum: 0' et 'Expected votes: 3, Total votes: 1'. Les logs 'journalctl -u corosync' montrent des messages 'Token has not been received in 11000 ms' sur le nœud survivant. La commande 'corosync-cfgtool -s' affiche 'status = Blocked (UDP/IP)' sur les deux interfaces ring. Quelle est l'analyse correcte et l'action de remédiation appropriée?
  1. Les deux liens réseau corosync sont bloqués, indiquant un problème réseau complet vers les deux autres nœuds. Vérifier les switchs, VLAN tagging et pare-feu, puis utiliser 'pvecm expected 1' temporairement pour restaurer le quorum sur le nœud isolé si nécessaire
  2. Le token timeout de 11000 ms est trop bas pour un cluster en production. Augmenter tokvs_timeout à 30000 ms dans corosync.conf et redémarrer corosync sur tous les nœuds pour éviter les fausses détections de panne
  3. Le problème vient d'un split-brain réseau. Redémarrer le service pve-cluster avec 'systemctl restart pve-cluster' sur les trois nœuds simultanément pour forcer la resynchronisation de pmxcfs via SQLite
  4. Les votes attendus sont incorrects. Modifier manuellement /etc/pve/corosync.conf pour réduire expected_votes à 1 de manière permanente et relancer corosync pour rétablir le quorum immédiatement
Question 8
Un administrateur exploite un cluster Proxmox VE 9 avec SDN EVPN/VXLAN en production. Il doit implémenter une solution de disaster recovery où, en cas de panne du datacenter principal (DC1), le datacenter secondaire (DC2) doit reprendre les services en moins de 5 minutes. Les VMs critiques sont répliquées via `pvesr` (Proxmox storage replication). Dans le contexte EVPN multi-site, quel mécanisme garantit la continuité réseau transparente lors du basculement DC1 → DC2 sans reconfiguration manuelle des VMs ?
  1. Les routes Type-2 EVPN (MAC/IP Mobility) permettent au VTEP de DC2 d'annoncer les mêmes adresses MAC/IP des VMs après leur démarrage sur DC2 avec un numéro de séquence MAC Mobility incrémenté : les autres VTEPs retirent automatiquement l'ancienne entrée et programment le nouveau next-hop VTEP DC2, assurant la continuité sans reconfiguration VM.
  2. La configuration d'un `anycast VTEP` avec une adresse IP VTEP partagée entre DC1 et DC2 (configurée sur une interface loopback avec même adresse sur les deux sites) garantit que lors du basculement, le trafic VXLAN est automatiquement redirigé vers DC2 par le routage underlay sans nécessiter de mise à jour des tables EVPN.
  3. Le mécanisme `BFD (Bidirectional Forwarding Detection)` intégré à FRRouting permet une détection de panne en moins de 500ms et déclenche automatiquement le failover EVPN : lors de la panne de DC1, BFD notifie FRR qui invalide toutes les routes Type-2 et Type-3 de DC1 et annonce les routes de DC2 comme actives dans les 5 secondes.
  4. La commande `pvesh create /cluster/sdn/vnets/<vnet>/failover --target dc2` dans Proxmox VE 9 déclenche une procédure de failover SDN orchestrée : Proxmox contacte automatiquement les nœuds de DC2, transfère les configurations VNI/VRF actives, et met à jour les annonces BGP EVPN pour pointer vers les nouveaux VTEPs DC2 via l'API SDN.

Accédez aux 99 questions complètes gratuitement

Aucune carte bancaire requise. Examen chronométré, corrections détaillées, score final.

Lancer l'examen blanc PVE9-L3 →

Pourquoi s'entraîner avec Certifexpress ?