Accueil › Certifications › PVE9-L2 › Questions gratuites

Questions gratuites PVE9-L2 — Proxmox VE 9 Certified Administrator (Level 2)

Téléchargez gratuitement 96 questions d'entraînement pour la certification PVE9-L2 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-L2
ÉditeurProxmox
Nombre de questions96
TypeQCM avec 4 réponses possibles
Niveauassociate
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-L2. Pour accéder aux 96 questions complètes, lancez l'examen blanc gratuitement.

Question 1
Un administrateur Proxmox VE configure un VLAN-aware bridge 'vmbr0' et souhaite que le trafic de management du noeud (accès WebUI sur le port 8006) transite sur le VLAN 10, tout en permettant aux VMs d'utiliser les VLANs 100 à 110. Quelle est la configuration correcte dans /etc/network/interfaces pour le bridge?
  1. Configurer 'bridge-vlan-aware yes' sur vmbr0, créer une interface vmbr0.10 avec l'adresse IP de management, et déclarer 'bridge-vids 10 100-110' pour autoriser tous les VLANs nécessaires sur le bridge
  2. Créer un bond avec les interfaces physiques, puis configurer deux bridges séparés : vmbr0 sans VLAN pour le management et vmbr1 avec 'bridge-vlan-aware yes' et 'bridge-vids 100-110' pour les VMs
  3. Configurer 'bridge-vlan-aware yes' sur vmbr0 avec 'bridge-pvid 10' pour forcer tout le trafic non taggé vers le VLAN 10 et ajouter l'adresse IP directement sur vmbr0 sans sous-interface
  4. Créer d'abord une interface VLAN 'eno1.10' sur l'interface physique, puis construire vmbr0 avec bridge-ports eno1.10 et 'bridge-vlan-aware yes' pour combiner management et VMs
Question 2
Un administrateur effectue une live migration d'une VM de 64 Go de RAM sur un lien réseau 1 Gbps dédié à la migration. La VM héberge une base de données très active avec un taux élevé d'écritures mémoire (dirty pages). Après 30 minutes, la migration ne converge pas et finit par échouer en timeout. Quelle combinaison d'actions est la plus adaptée pour résoudre ce problème?
  1. Réduire la charge d'écriture mémoire de la VM temporairement (mode maintenance applicatif), configurer '--bwlimit' à une valeur élevée ou illimitée sur le lien dédié, et éventuellement augmenter le paramètre 'migrate_downtime' pour accepter une micro-coupure plus longue lors du basculement final
  2. Augmenter la RAM allouée à la VM à 128 Go pour que le ratio dirty pages/RAM totale diminue, ce qui permettra à QEMU de copier la mémoire plus vite que les pages ne sont salies pendant la phase de convergence
  3. Activer la compression mémoire avec 'qm set 100 --migrate_compress on' et forcer le protocole de migration RDMA avec '--migration_type rdma' pour accélérer le transfert des pages mémoire entre les nœuds
  4. Passer la VM en mode pause (qm suspend 100) pendant 10 secondes pour vider le dirty bitmap, puis reprendre la migration avec 'qm resume 100 --continue-migration' afin de transférer uniquement le delta résiduel
Question 3
Suite à une panne réseau, un administrateur découvre que le bonding en mode active-backup sur un serveur Proxmox n'a pas basculé automatiquement sur l'interface secondaire. La commande 'cat /proc/net/bonding/bond0' montre que les deux interfaces sont 'up' mais le MII Status de l'esclave secondaire indique 'down'. Quel paramètre est le plus probablement en cause?
  1. Le paramètre bond_miimon est défini à 0, désactivant la surveillance MII des liens : il faut le configurer à 100ms minimum pour permettre la détection de panne et le basculement automatique
  2. Le paramètre bond_primary n'est pas défini : sans interface primaire explicite, le bonding active-backup ne sait pas vers quelle interface basculer en cas de panne
  3. Le paramètre bond_downdelay est trop élevé (30000ms) : le bonding attend trop longtemps avant de déclarer une interface comme défaillante, retardant le failover au-delà du seuil acceptable
  4. Le paramètre bond_arp_ip_target n'est pas configuré : sans cible ARP, le bonding ne peut pas vérifier la connectivité réelle et maintient les deux interfaces en état 'up' indéfiniment
Question 4
Dans le cadre d'un hardening avancé de Proxmox VE 9, quelle approche est recommandée pour restreindre l'accès à l'interface web de gestion (pveproxy) aux seuls réseaux d'administration autorisés ?
  1. A. Configurer une règle iptables DROP sur le port 8006 puis ajouter des exceptions ACCEPT pour les sous-réseaux autorisés via le fichier /etc/network/interfaces
  2. B. Modifier la directive 'LISTEN_IP' dans /etc/default/pveproxy pour lier le service à l'adresse IP du VLAN d'administration et compléter par des règles dans le pare-feu intégré de Proxmox (pve-firewall)
  3. C. Désactiver pveproxy et utiliser exclusivement un tunnel SSH avec redirection de port vers localhost:8006 pour chaque session d'administration
  4. D. Configurer un reverse proxy Apache sur le port 443 avec authentification client par certificat X.509 et désactiver complètement pveproxy
Question 5
Un administrateur doit migrer un conteneur LXC (CT 300) depuis le nœud pve1 vers pve3 dans le même cluster Proxmox VE 9. Le conteneur utilise un point de montage bind vers /srv/data sur le système hôte et un volume rootfs sur le stockage partagé Ceph. Quelle commande et quelle précaution sont appropriées ?
  1. Exécuter 'pct migrate 300 pve3' après avoir vérifié que le chemin /srv/data existe et contient les données nécessaires sur pve3, car les bind mounts ne sont pas transférés automatiquement lors de la migration
  2. Exécuter 'pct migrate 300 pve3 --online --with-local-disks' pour migrer à chaud le conteneur avec ses bind mounts, Proxmox synchronisant automatiquement les répertoires liés via rsync
  3. Exécuter 'qm migrate 300 pve3 --online' car depuis Proxmox VE 9, la commande qm gère de manière unifiée les VMs et les conteneurs pour simplifier l'administration
  4. Exécuter 'pct move-volume 300 --target-node pve3' pour migrer d'abord les volumes du conteneur, puis utiliser 'pct relocate 300 pve3' pour déplacer la configuration du conteneur
Question 6
Un administrateur Proxmox VE 9 souhaite migrer à chaud une VM KVM depuis le nœud pve1 vers pve2. La VM utilise un disque stocké sur un volume group LVM local (local-lvm). Lors de l'exécution de 'qm migrate 105 pve2 --online', la migration échoue avec une erreur indiquant que le stockage n'est pas disponible sur le nœud cible. Quelle est la solution appropriée pour réussir cette migration en ligne ?
  1. Utiliser l'option --with-local-disks pour que Proxmox transfère automatiquement les disques locaux vers un stockage local équivalent sur le nœud cible via un flux réseau dédié
  2. Convertir le stockage local-lvm en stockage Ceph RBD sur les deux nœuds avant la migration, car la live migration est strictement impossible avec des disques locaux sous Proxmox VE 9
  3. Ajouter l'option --force à la commande qm migrate pour ignorer la vérification de disponibilité du stockage et laisser Proxmox recréer automatiquement le disque sur le nœud cible
  4. Effectuer d'abord une réplication avec 'pvesr create-local-job' vers pve2, puis exécuter la migration sans option supplémentaire puisque les données seront déjà synchronisées
Question 7
Un administrateur Proxmox VE configure un bonding LACP (802.3ad) entre deux interfaces réseau physiques connectées à un switch Cisco. Le bond est créé mais aucun trafic ne passe. La commande 'cat /proc/net/bonding/bond0' montre 'Partner Mac Address: 00:00:00:00:00:00'. Quelle est la cause la plus probable et la solution appropriée?
  1. Le switch n'a pas LACP activé sur les ports correspondants : il faut configurer un channel-group en mode active sur les ports du switch pour établir la négociation LACP avec le serveur Proxmox
  2. Le bond est configuré en mode balance-rr au lieu de 802.3ad : il faut modifier /etc/network/interfaces pour passer le bond_mode à 802.3ad et redémarrer le service networking
  3. Les interfaces esclaves du bond ont des vitesses différentes (1G et 10G) : LACP exige des interfaces identiques, il faut remplacer une carte pour homogénéiser les débits
  4. Le paramètre bond_xmit_hash_policy est absent : sans politique de hachage layer3+4, LACP refuse d'établir l'agrégation et le Partner Mac reste à zéro
Question 8
Un administrateur Proxmox VE 9 gère un cluster Ceph de 12 OSD sur 4 nœuds. Il remarque via 'ceph osd df' que certains OSD ont une utilisation de 85% tandis que d autres sont à 40%. La commande 'ceph osd tree' montre des poids CRUSH hétérogènes correspondant à des disques de tailles différentes (certains 2 To, d autres 4 To). Quelle approche est la plus adaptée pour rééquilibrer la distribution des données ?
  1. Vérifier que les poids CRUSH reflètent bien la capacité réelle avec ceph osd crush reweight-by-utilization, puis si nécessaire ajuster individuellement avec ceph osd crush reweight osd.X <nouveau_poids> en fonction du ratio de capacité
  2. Exécuter ceph osd reweight-by-utilization 110 pour automatiquement réduire le poids des OSD surchargés au-delà de 110% de la moyenne, rééquilibrant ainsi la distribution de manière dynamique
  3. Modifier la CRUSH map manuellement avec crushtool --decompile et --compile pour créer une hiérarchie séparant les disques 2 To et 4 To dans des buckets host distincts
  4. Augmenter le nombre de PG de chaque pool avec ceph osd pool set <pool> pg_num <valeur_plus_élevée> car le déséquilibre est causé par un nombre insuffisant de Placement Groups

Accédez aux 96 questions complètes gratuitement

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

Lancer l'examen blanc PVE9-L2 →

Pourquoi s'entraîner avec Certifexpress ?