Accueil › Certifications › PVE9-ADMIN-50H › Questions gratuites

Questions gratuites PVE9-ADMIN-50H — Proxmox VE 9 Administration — Niveau Difficile

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

Question 1
Sur un cluster Proxmox VE 9 de 5 nodes, apres une panne reseau majeure, seuls 2 nodes restent operationnels. Le fichier /etc/pve devient read-only et la commande 'pvecm status' affiche 'Quorate: No' avec 'Total votes: 2, Quorum: 3'. Vous devez restaurer temporairement l'acces en ecriture a pmxcfs sur ces 2 nodes pour migrer les VMs critiques avant la reparation reseau. Quelle commande appliquer ?
  1. A. pvecm expected 2 sur un seul des 2 nodes survivants
  2. B. systemctl restart pve-cluster corosync sur les 2 nodes simultanement
  3. C. pmxcfs -l puis editer manuellement /etc/pve/corosync.conf pour reduire nodelist
  4. D. corosync-quorumtool -s --override-quorum sur chaque node
Question 2
Apres une corruption totale du SQLite backing store de pmxcfs (fichier /var/lib/pve-cluster/config.db non recuperable) sur un node membre d'un cluster PVE 9 a 3 nodes, vous devez reintegrer ce node sans perdre les VMs locales deja presentes sur son stockage ZFS. Quelle est la sequence correcte ?
  1. A. Copier config.db depuis un autre node via scp, redemarrer pve-cluster et pveproxy
  2. B. systemctl stop pve-cluster corosync, supprimer /etc/corosync/* et /var/lib/pve-cluster/*, pvecm delnode depuis un node sain, puis pvecm add depuis le node restaure avec --force
  3. C. pmxcfs -l, restaurer config.db depuis /var/lib/pve-cluster/config.db.backup et redemarrer
  4. D. qm rescan suivi de pvecm updatecerts --force et systemctl reload-or-restart pve-cluster
Question 3
Sur un cluster Proxmox VE 9 hyperconverge de 5 noeuds avec Ceph, vous devez deployer Ceph RGW pour fournir un acces S3. Apres 'pveceph rgw create' et creation du user via 'radosgw-admin user create --uid=app --display-name=app', les uploads multipart de fichiers > 5GB echouent avec 'EntityTooLarge' alors que les fichiers < 5GB fonctionnent. La configuration via 'radosgw-admin zonegroup get' semble correcte. Quelle est la cause ?
  1. A. Le parametre 'rgw_max_chunk_size' est limite a 4MB par defaut, il faut l'augmenter a 16MB minimum
  2. B. La limite 'rgw_max_put_size' par defaut est de 5GB et bloque les uploads single-part, mais les multipart parts depassent 'rgw_multipart_part_upload_limit' (10000 parts max avec une taille de part par defaut inadequate)
  3. C. Le pool '.rgw.buckets.data' a atteint son 'target_size_ratio' et refuse les nouvelles ecritures
  4. D. Le quota utilisateur n'a pas ete configure et le defaut est 5GB par bucket
Question 4
Sur un noeud PVE 9 avec 64 vCPU (2x Xeon Gold 6338), une VM critique de 16 vCPU configuree avec 'cpu: host,flags=+pdpe1gb' et 'numa: 1' montre des performances erratiques. 'numastat -c qemu' revele 'numa_miss' croissant et 'other_node' a 40% du total. La config inclut sockets=2, cores=8. Quelle action resout durablement l'asymetrie NUMA ?
  1. A. Ajouter 'hugepages: 1024' et 'numa0: cpus=0-7,memory=32768,hostnodes=0,policy=bind' + 'numa1: cpus=8-15,memory=32768,hostnodes=1,policy=bind'
  2. B. Activer 'balloon: 0' et fixer 'affinity: 0-15' dans la config VM pour epingler les vCPUs aux 16 premiers coeurs physiques
  3. C. Definir 'cpu: host,flags=+pdpe1gb;+pcid' avec 'machine: q35,kernel-irqchip=split' pour ameliorer le routage interruption NUMA
  4. D. Desactiver le SMT hote via 'echo off > /sys/devices/system/cpu/smt/control' et reduire la VM a 8 vCPU mono-socket
Question 5
Vous deployez pve_exporter (version 3.x) sur tous les noeuds d'un cluster PVE 9 a 8 noeuds pour scraper les metriques vers Prometheus. Apres deploiement, vous observez des metriques 'pve_up{id="node/pve-03"}' a 0 intermittentes alors que le noeud est sain. Le scrape interval est de 15s. Le log montre 'ReadTimeout' sur certains endpoints. Quelle action resout le probleme de maniere optimale ?
  1. A. Augmenter scrape_timeout a 30s dans prometheus.yml et configurer pve_exporter avec un token API dedie ayant uniquement PVEAuditor sur /
  2. B. Passer pve_exporter en mode 'cluster=false' et scraper chaque noeud individuellement avec un endpoint par noeud
  3. C. Desactiver les modules 'storage' et 'replication' dans pve.yml car ils causent toujours des timeouts en cluster
  4. D. Migrer vers le module InfluxDB natif de Proxmox via /etc/pve/status.cfg, pve_exporter etant deprecie en PVE 9
Question 6
Sur un cluster Proxmox VE 9 a 5 noeuds avec une zone Simple utilisant le subnet 10.10.0.0/24, vous activez 'dhcp dnsmasq' sur le VNet. Les VMs obtiennent une IP mais 'pvesh get /cluster/sdn/vnets/vnet1/ips' retourne une liste vide, et apres reboot d'un noeud, des conflits d'IP apparaissent. Quelle est la cause racine ?
  1. A. Le service pve-cluster doit etre redemarre apres activation du DHCP pour synchroniser la base IPAM /etc/pve/priv/ipam.db
  2. B. Le plugin IPAM 'pve' n'est pas selectionne sur la zone ; dnsmasq attribue des IPs sans persistance dans /etc/pve/sdn/ipam.db
  3. C. dnsmasq necessite que /var/lib/dnsmasq soit monte en tmpfs partage entre noeuds via NFS
  4. D. Le parametre 'dhcp-range' doit etre defini manuellement dans /etc/dnsmasq.d/sdn-vnet1.conf car le subnet SDN ne le propage pas
Question 7
Apres une mise a jour vers PVE 9.0, vos hookscripts existants fonctionnent mais vous voulez implementer un hook 'pre-start' qui verifie l'etat d'un service externe (Vault) via curl avant de demarrer 50 VMs en parallele lors d'un boot de cluster. Vous constatez que le timeout global du hookscript est de 60s, ce qui est insuffisant pour 50 verifications sequentielles. Comment contourner cette limite sans modifier qemu-server ?
  1. A. Definir 'hookscript-timeout: 300' dans /etc/pve/datacenter.cfg, parametre cluster-wide introduit en PVE 9.0
  2. B. Faire forker le script (double-fork avec setsid) pour rendre la verification asynchrone et retourner immediatement 0, en deplacant la logique bloquante dans la phase 'post-start'
  3. C. Decouper en utilisant un cache externe (Redis) interroge par le hook avec un TTL court, alimente par un daemon systemd separe qui pre-verifie Vault
  4. D. Augmenter 'qm_timeout' dans /etc/pve/qemu-server/<vmid>.conf via 'qm set <vmid> --timeout 300'
Question 8
Sur un Proxmox VE 9 hebergeant une VM PostgreSQL critique avec un disque virtio-scsi de 2TB sur stockage NVMe local, vous observez via 'iostat -x 1' une saturation de la queue (avgqu-sz > 32) et une latence elevee. La configuration actuelle est : scsi0: local-nvme:vm-100-disk-0,cache=writeback,aio=threads,iothread=0. Quelle modification optimisera le mieux les IOPS et la latence ?
  1. A. Activer iothread=1, passer aio=io_uring et basculer le controleur en virtio-scsi-single
  2. B. Conserver iothread=0 mais passer cache=none et aio=native pour bypass du pagecache hote
  3. C. Activer iothread=1 avec aio=native et cache=writeback en gardant virtio-scsi standard
  4. D. Passer cache=unsafe avec aio=io_uring pour eliminer les barrieres de synchronisation

Accédez aux 50 questions complètes gratuitement

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

Lancer l'examen blanc PVE9-ADMIN-50H →

Pourquoi s'entraîner avec Certifexpress ?