RHCSA : compétences essentielles

Cette page recense les compétences officielles de l'examen RHCSA (EX200), telles que publiées par Red Hat dans les study points de la certification. Pour chaque bloc, elle traduit ces compétences en savoir-faire concrets à démontrer sur RHEL 10.

Il ne s'agit pas d'une liste fermée de commandes à mémoriser. Red Hat publie des objectifs de compétence, pas une checklist d'outils. L'objectif est de vous aider à identifier ce que vous devez être capable de faire le jour de l'examen, un examen performance-based où chaque tâche doit produire un résultat fonctionnel sur un système RHEL réel.

L'examen se déroule sur un poste isolé, et cette contrainte oriente toute votre préparation : vous devrez retrouver seul une option de commande, sans moteur de recherche ni assistant. Entraînez-vous donc avec les mêmes ressources que celles autorisées le jour J.

Les grands blocs de compétences EX200

Red Hat ne publie pas de pondération chiffrée par bloc. Les blocs ci-dessous correspondent aux catégories d'objectifs publiées sur la page officielle EX200.

Bloc	Ce que ça couvre
Understand and use essential tools	Shell, redirections, grep, regex, SSH, fichiers, liens, permissions, documentation
Create simple shell scripts	Variables, conditions, boucles, codes retour
Operate running systems	Boot targets, interruption boot, processus, journaux, planification, services, VMs
Configure local storage	Partitions, LVM, swap, montages persistants
Create and configure file systems	Filesystems, attributs, permissions, ACL, chiffrement, NFS
Deploy, configure, and maintain systems	Installation logicielle, dépôts, services de base, maintenance
Manage users and groups	Comptes, groupes, droits, changements d'utilisateur
Manage security	Firewall, SELinux, SSH par clé
Perform basic container management	Opérations conteneur de base

La page officielle EX200 pour RHEL 10 découpe ses objectifs en dix sections, dont deux n'apparaissent pas telles quelles dans le tableau ci-dessus : Manage software (dépôts RPM, paquets, Flatpak) et Manage basic networking (adressage IPv4/IPv6, résolution de noms, services réseau au démarrage, restriction d'accès via firewalld). Cette page les traite dans les blocs Deploy, configure, and maintain systems et Manage security. À l'inverse, la gestion de conteneurs ne figure plus dans les objectifs publiés pour RHEL 10, voir la section correspondante plus bas.

Understand and use essential tools

Ce bloc couvre la maîtrise du shell, la manipulation de fichiers, les permissions Unix standard et l'utilisation de la documentation intégrée.

Compétences officielles

Voici les objectifs publiés par Red Hat pour ce bloc, traduits sans reformulation. Ils décrivent des gestes, pas des commandes : « archiver, compresser, décompresser » n'impose ni tar ni gzip, c'est le résultat qui est évalué. Lisez-les comme la liste des situations que le correcteur automatique peut vous mettre entre les mains.

Accéder à un shell et exécuter des commandes avec la syntaxe correcte
Utiliser les redirections d'entrée-sortie (>, >>, |, 2>, etc.)
Utiliser grep et les expressions régulières pour analyser du texte
Accéder à des systèmes distants via SSH
Se connecter et changer d'utilisateur dans des cibles multi-utilisateurs
Archiver, compresser, décompresser des fichiers avec tar, gzip, bzip2
Créer et éditer des fichiers texte
Créer, supprimer, copier et déplacer des fichiers et répertoires
Créer des liens physiques et symboliques
Lister, définir et modifier les permissions standard ugo/rwx
Localiser, lire et utiliser la documentation système, man, info, /usr/share/doc

Ce que cela implique concrètement

Ce bloc est celui qu'on croit acquis et qui coûte pourtant du temps le jour J. La différence entre un candidat rapide et un candidat lent ne se joue pas sur la connaissance des commandes mais sur l'absence d'hésitation : chaque aller-retour dans une page man pour retrouver une option se paie sur un examen chronométré. Les six familles ci-dessous sont à travailler jusqu'au réflexe.

Shell et redirections :

Enchaîner des commandes avec des pipes sans hésitation
Rediriger stdout, stderr ou les deux vers un fichier, savoir la différence entre écraser et ajouter
Utiliser tee pour afficher et enregistrer simultanément
Travailler proprement sans erreur de syntaxe, en examen, une erreur de redirection peut produire un résultat incomplet

Grep et expressions régulières :

Rechercher un motif dans un fichier ou récursivement dans une arborescence
Utiliser les regex de base et étendues : ancres (^, $), classes de caractères, alternation
Exclure des lignes (commentaires, lignes vides)
Combiner grep avec d'autres outils (awk, cut, sort, uniq) pour extraire et formater des données

SSH :

Se connecter à un système distant avec un utilisateur spécifique
Utiliser scp et rsync pour transférer des fichiers de façon sécurisée
Travailler sur un système distant comme si c'était le système local

Fichiers, liens, archives :

Créer, copier, déplacer et supprimer des fichiers et répertoires rapidement
Comprendre la différence entre lien physique et lien symbolique, savoir quand utiliser l'un ou l'autre
Créer une archive tar compressée (gzip ou bzip2) et l'extraire dans un répertoire cible
Lister le contenu d'une archive sans l'extraire

Permissions :

Lire et interpréter les permissions affichées par ls -l
Modifier les permissions en notation symbolique et octale
Comprendre les bits spéciaux : SUID, SGID, sticky bit
Appliquer un umask adapté
Modifier le propriétaire et le groupe d'un fichier ou d'une arborescence

Documentation :

Trouver rapidement une option dans une page man (navigation, recherche par /)
Identifier la bonne section man quand plusieurs existent
Consulter /usr/share/doc pour trouver des exemples de configuration

Pièges fréquents

Ces quatre erreurs ont en commun d'être silencieuses : rien ne signale l'échec, et vous découvrez le problème en relisant le résultat, ou jamais. La première est la plus destructrice, parce qu'elle détruit le fichier de configuration que la tâche suivante attendait.

Confondre > (écrase) et >> (ajoute), un candidat peut écraser un fichier de configuration par erreur
Oublier les guillemets autour des regex dans grep, le shell interprète les caractères spéciaux
Ne pas connaître man -k pour rechercher une commande par mot-clé
Appliquer chmod -R de façon trop large sans réfléchir aux conséquences sur les fichiers et répertoires

Create simple shell scripts

Ce bloc est dédié aux scripts shell simples. Il ne s'agit pas de développement avancé, mais de la capacité à automatiser une tâche d'administration avec un script Bash fonctionnel.

Compétences officielles

Red Hat détaille ce bloc en quatre objectifs, tous centrés sur la structure d'un script, jamais sur une bibliothèque ou un style d'écriture. Retenez la formulation du dernier : traiter la sortie d'une commande à l'intérieur d'un script, ce qui suppose de savoir capturer une sortie et boucler dessus.

Exécuter du code conditionnellement (if, test, [ ], etc.)
Utiliser des boucles (for, etc.) pour traiter un fichier ou une entrée en ligne de commande
Traiter les entrées du script ($1, $2, etc.)
Traiter la sortie de commandes shell à l'intérieur du script

Ce que cela implique concrètement

Un script d'examen n'a pas besoin d'être élégant, il doit produire le bon résultat sans intervention. Le correcteur exécute votre script, éventuellement avec des arguments, et regarde ce qui en sort. Travaillez donc les sept points ci-dessous en vous imposant de lancer le script depuis un autre répertoire que celui où vous l'avez écrit : c'est la condition la plus proche de l'examen.

Écrire un script Bash avec un shebang (#!/bin/bash) et les bonnes permissions d'exécution
Utiliser des variables (affectation, expansion, variables spéciales $?, $1, $#)
Écrire des conditions : if/elif/else, tests sur des fichiers (-f, -d, -e), sur des chaînes, sur des valeurs numériques
Écrire des boucles : for, while, itération sur une liste ou sur la sortie d'une commande
Gérer un code de retour : tester le succès ou l'échec d'une commande et réagir en conséquence
Lire et modifier un petit script existant sans se perdre
Rendre le script exécutable et le lancer correctement

Pièges fréquents

Trois de ces quatre pièges empêchent le script de démarrer ou le font échouer sans message clair. Le second est le plus sournois : [[ "$a" = "$b" ]] compare des chaînes, [ "$a" -eq "$b" ] compare des nombres, et confondre les deux donne un test qui « marche » sur certaines valeurs et pas sur d'autres.

Oublier le shebang ou les permissions d'exécution, le script ne s'exécute pas
Confondre = (comparaison de chaînes dans [[ ]]) et -eq (comparaison numérique)
Ne pas tester le code retour de la commande précédente alors que le script doit réagir à un échec
Écrire des scripts sans gestion d'erreur minimale, en examen, un script qui crashe silencieusement ne marque pas de point

Operate running systems

Ce bloc couvre la gestion opérationnelle d'un système en fonctionnement : boot, processus, journaux, planification, services et machines virtuelles.

Compétences officielles

Ce bloc est le plus large de l'examen et c'est celui qui contient la récupération de boot, l'exercice le plus mécanique et le plus rentable à automatiser mentalement. Deux objectifs sont souvent oubliés dans les préparations : ajuster l'ordonnancement d'un processus, et préserver les journaux système entre deux redémarrages.

Démarrer, redémarrer et arrêter un système normalement
Démarrer en différents targets manuellement
Interrompre la séquence de boot pour accéder à un système
Identifier les processus gourmands en CPU ou mémoire et les tuer
Ajuster l'ordonnancement des processus (nice, renice)
Gérer les profils de tuning (tuned-adm)
Localiser et interpréter les fichiers journaux et les journaux système
Préserver les journaux système entre les redémarrages
Démarrer, arrêter et vérifier l'état des services réseau
Transférer des fichiers entre systèmes de façon sécurisée

Ce que cela implique concrètement

Le fil conducteur de ce bloc est le passage de l'observation à l'action : constater qu'un service est en échec ne rapporte rien, il faut lire le journal, comprendre la cause et corriger. Les cinq familles ci-dessous se travaillent sur une machine réelle qu'on redémarre volontairement, pas en lisant.

Boot et targets :

Connaître les targets systemd principales : multi-user.target, graphical.target, rescue.target, emergency.target
Changer la target par défaut de façon persistante
Basculer vers une target à chaud pour diagnostiquer un problème
Interrompre le boot via GRUB2 : éditer l'entrée de démarrage pour ajouter un paramètre noyau
Exécuter la procédure rd.break pour réinitialiser le mot de passe root, incluant le remount en écriture, le chroot, le changement de mot de passe et le touch /.autorelabel obligatoire pour SELinux

Processus :

Lister les processus et identifier celui qui consomme le plus de CPU ou de mémoire
Envoyer un signal à un processus : arrêt gracieux (SIGTERM), arrêt forcé (SIGKILL)
Modifier la priorité d'un processus en cours d'exécution (nice/renice)
Gérer les tâches en arrière-plan du shell (bg, fg, jobs, nohup)

Journaux :

Consulter les journaux d'un service spécifique avec journalctl
Rechercher dans les journaux par date, par priorité ou par unité
Configurer la persistance des journaux (/etc/systemd/journald.conf) pour conserver les logs entre les redémarrages
Consulter les logs du boot précédent (possible uniquement si la persistance est configurée)

Planification :

Créer une tâche récurrente avec cron, maîtriser la syntaxe des 5 champs
Créer une tâche unique différée avec at
Vérifier qu'une tâche planifiée est bien en place
Connaître les répertoires /etc/cron.d/, /etc/cron.daily/…

Services :

Démarrer, arrêter, redémarrer un service avec systemctl
Activer un service au démarrage avec systemctl enable
Vérifier qu'un service est actif et activé, comprendre la différence
Diagnostiquer un service en état failed en lisant les journaux

Transfert de fichiers :

Copier un fichier vers un système distant avec scp ou rsync sur SSH
Conserver les permissions et l'horodatage lors du transfert
Vérifier l'intégrité du fichier reçu côté distant

Pièges fréquents

Ces quatre erreurs partagent le même symptôme : tout paraît fonctionner pendant la session, et le point disparaît après le redémarrage d'évaluation. La première est la plus brutale, car elle peut rendre le système inutilisable au prochain démarrage.

Oublier touch /.autorelabel après la procédure rd.break, SELinux bloque le système au prochain boot
Confondre systemctl enable (persistant) et systemctl start (immédiat), les deux sont nécessaires, ou utiliser systemctl enable --now
Ne pas configurer la persistance de journald, sans elle, les logs sont perdus au reboot et le diagnostic post-reboot est impossible
Négliger tuned : savoir activer un profil de performance fait partie des objectifs operate running systems

Configure local storage

Ce bloc couvre le partitionnement, les volumes logiques, le swap et les montages persistants.

Compétences officielles

Red Hat décompose ce bloc jusqu'au niveau de chaque objet LVM, ce qui est un indice fort : l'examen attend la chaîne complète, du disque brut au point de montage persistant. Le dernier objectif contient le mot le plus important, « non destructif » : ajouter de l'espace ne doit jamais faire perdre de données existantes.

Lister, créer et supprimer des partitions sur des disques GPT
Créer et supprimer des volumes physiques (PV)
Affecter des volumes physiques à des groupes de volumes (VG)
Créer et supprimer des volumes logiques (LV)
Monter les systèmes de fichiers au démarrage par UUID ou par label
Ajouter partitions, volumes logiques et swap de façon non destructive

Ce que cela implique concrètement

Le stockage est le bloc où une erreur se voit immédiatement au redémarrage, et c'est aussi celui qui peut empêcher la machine de démarrer. Travaillez toujours dans cet ordre : créer, formater, tester le montage, puis seulement écrire dans /etc/fstab. Les quatre familles ci-dessous suivent cette progression.

Partitions :

Créer des partitions GPT avec gdisk ou parted
Informer le noyau qu'une table de partitions a changé (partprobe)
Identifier les disques et partitions disponibles (lsblk, blkid)

LVM :

Créer un Physical Volume, un Volume Group et un Logical Volume
Étendre un VG en ajoutant un disque, puis étendre un LV
Redimensionner le filesystem après l'extension du LV, resize2fs pour ext4, xfs_growfs pour XFS (monté uniquement)
Créer un snapshot LVM si demandé
Supprimer proprement un LV

Swap :

Créer une partition swap ou un fichier swap
Activer le swap de façon éphémère et de façon persistante via /etc/fstab
Vérifier l'état du swap actif

Persistance (fstab) :

Monter un filesystem via /etc/fstab en utilisant l'UUID, jamais /dev/sdX
Tester la cohérence de /etc/fstab avant le reboot (mount -a, findmnt --verify)
Comprendre qu'une erreur dans fstab peut empêcher le système de démarrer

Pièges fréquents

Les deux premiers pièges de cette liste sont les plus fréquents de tout l'examen. Le troisième est le plus grave : une erreur de syntaxe dans /etc/fstab fait basculer le système en mode maintenance au redémarrage, et vous perdez alors bien plus qu'un point sur une tâche.

Utiliser /dev/sdb1 au lieu de l'UUID dans /etc/fstab, les noms de devices peuvent changer entre les reboots
Étendre un LV sans redimensionner le filesystem, l'espace supplémentaire reste invisible
Ne pas tester mount -a après modification de /etc/fstab, une erreur de syntaxe peut rendre le système non bootable
Oublier de créer le point de montage (mkdir -p) avant d'ajouter l'entrée fstab

Create and configure file systems

Ce bloc couvre la création de systèmes de fichiers, les attributs, les permissions avancées (ACL), le chiffrement éventuel et les systèmes de fichiers réseau.

Compétences officielles

Ce bloc nomme explicitement les trois systèmes de fichiers attendus, et il place autofs au même niveau que le montage NFS classique : c'est le sujet le plus souvent négligé de tout l'examen. Le dernier objectif est formulé comme un diagnostic, pas comme une configuration, et c'est bien ainsi qu'il tombe.

Créer, monter, démonter et utiliser des systèmes de fichiers VFAT, ext4 et XFS
Monter et démonter des systèmes de fichiers réseau via NFS
Configurer autofs
Étendre un volume logique existant
Diagnostiquer et corriger des problèmes de permissions sur les fichiers

Ce que cela implique concrètement

Le mot à retenir ici est monté. Beaucoup d'opérations n'ont pas le même comportement selon que le système de fichiers est monté ou non : xfs_growfs exige qu'il le soit, xfs_repair exige l'inverse. Vérifiez systématiquement l'état avec findmnt avant d'agir, les cinq familles ci-dessous en dépendent.

Création et gestion de filesystems :

Formater une partition ou un LV en ext4, XFS ou VFAT
Attribuer un label à un filesystem
Vérifier et réparer un filesystem non monté (e2fsck, xfs_repair)
Monter un filesystem avec les options appropriées

Attributs et labels :

Modifier le label d'un filesystem existant
Trouver l'UUID d'un block device avec blkid

ACL :

Ajouter une permission à un utilisateur ou un groupe spécifique sur un fichier ou répertoire
Définir des ACL par défaut pour que les nouveaux fichiers héritent des permissions
Supprimer des ACL ciblées ou réinitialiser toutes les ACL
Vérifier la présence d'ACL avec getfacl et reconnaître le + dans la sortie de ls -l

NFS :

Monter un partage NFS de façon persistante via /etc/fstab, avec l'option _netdev obligatoire
Découvrir les exports disponibles sur un serveur NFS (showmount -e)
Activer le service client NFS si nécessaire

Autofs :

Configurer autofs pour monter un partage à la demande
Comprendre la relation entre /etc/auto.master et les fichiers de map
Activer et vérifier le fonctionnement d'autofs

Pièges fréquents

Le premier piège est spécifique aux montages réseau et ne se manifeste qu'au redémarrage : sans _netdev, systemd tente le montage avant que le réseau ne soit disponible. Les deux derniers concernent les ACL, dont le comportement d'héritage n'a rien d'intuitif et ne s'acquiert qu'en manipulant.

Oublier _netdev pour les montages NFS dans /etc/fstab, le montage échoue au boot car le réseau n'est pas encore disponible
Ne pas pratiquer autofs, le montage dynamique est un sujet qui se maîtrise uniquement par la pratique en lab
Confondre permissions classiques ugo/rwx et ACL, les ACL ne remplacent pas les permissions de base, elles les complètent
Oublier setfacl -d pour les ACL par défaut, les nouveaux fichiers n'héritent pas automatiquement des ACL du répertoire parent

Deploy, configure, and maintain systems

Ce bloc couvre l'installation de logiciels, la gestion de dépôts, la maintenance système et la configuration des services de base.

Compétences officielles

Ce bloc rassemble les objectifs de deux sections officielles : Deploy, configure, and maintain systems et Manage software. Deux objectifs y sont régulièrement sous-estimés : la configuration du client de temps (chronyd), et la modification du chargeur de démarrage, qui n'est pas la même chose que l'interruption du boot vue plus haut.

Planifier des tâches avec at, cron et les unités timer de systemd
Démarrer et arrêter des services, et les configurer pour démarrer au boot
Configurer le démarrage automatique sur une cible donnée
Configurer les clients de service de temps
Installer et mettre à jour des paquets depuis le CDN Red Hat, un dépôt distant ou le système de fichiers local
Modifier le chargeur de démarrage du système
Configurer l'accès aux dépôts RPM, installer et supprimer des paquets RPM
Configurer l'accès aux dépôts Flatpak, installer et supprimer des applications Flatpak

Ce que cela implique concrètement

Ce bloc est celui où la persistance est la plus facile à oublier, parce que tout fonctionne pendant la session : un service démarré sans enable, une interface configurée avec ip addr au lieu de nmcli, une tâche at au lieu d'une entrée cron. Les six familles ci-dessous couvrent chacune un cas où la commande immédiate et la commande persistante diffèrent.

Gestion de paquets (dnf/rpm) :

Installer, supprimer, mettre à jour un paquet
Rechercher un paquet ou identifier quel paquet fournit un fichier donné
Consulter l'historique des transactions et effectuer un rollback si nécessaire
Vérifier l'intégrité d'un paquet installé

Modules AppStream :

Lister les modules disponibles et leurs streams
Activer un stream spécifique et installer un profil de module
Comprendre que le changement de stream peut nécessiter un reset préalable

Dépôts (yum/dnf repos) :

Ajouter un dépôt externe ou local
Activer ou désactiver un dépôt existant
Créer un fichier .repo dans /etc/yum.repos.d/ avec la bonne syntaxe
Vider et reconstruire le cache

Flatpak :

Ajouter un dépôt Flatpak (Flathub)
Installer, lister, mettre à jour et supprimer une application Flatpak
Flatpak fait partie des objectifs EX200, ne pas le négliger

Tuned :

Lister les profils de tuning disponibles
Activer un profil de performance adapté à l'usage du système
Vérifier le profil actif et savoir quel profil est recommandé

Configuration réseau de base :

Configurer une interface réseau avec une adresse IPv4 et IPv6 statique via nmcli
Modifier le hostname de façon persistante
Configurer la résolution DNS
Ajouter des routes statiques persistantes
Appliquer les modifications sans reboot

Pièges fréquents

Le premier et le dernier piège de cette liste décrivent la même confusion vue de deux angles : sur RHEL, modifier une configuration réseau et appliquer cette modification sont deux gestes distincts. Le troisième rappelle que Flatpak est bien un objectif publié, malgré son apparence anecdotique.

Oublier nmcli con up après nmcli con mod, les modifications ne sont pas appliquées tant que la connexion n'est pas réactivée
Ne pas savoir créer un fichier .repo manuellement, en examen, le dépôt peut ne pas être pré-configuré
Ignorer Flatpak dans la préparation, c'est un objectif officiel récent
Confondre la configuration réseau immédiate et la configuration persistante, sans nmcli, les modifications ip addr sont éphémères

Manage users and groups

Ce bloc couvre la gestion des comptes utilisateurs, des groupes et des droits d'accès.

Compétences officielles

Quatre objectifs seulement, mais le dernier, « configurer l'accès privilégié », recouvre à lui seul toute la délégation sudo. Notez également que le vieillissement des mots de passe est cité explicitement : ce n'est pas un détail, c'est un objectif à part entière.

Créer, supprimer et modifier des comptes utilisateurs locaux
Changer les mots de passe et ajuster leur vieillissement pour les comptes locaux
Créer, supprimer et modifier des groupes locaux et leurs appartenances
Configurer l'accès privilégié (sudo)

Ce que cela implique concrètement

Ce bloc se corrige presque entièrement à la commande id et au fichier /etc/shadow. Prenez donc l'habitude de terminer chaque tâche par une vérification affichant l'état réel du compte, plutôt que de vous fier à l'absence de message d'erreur. Les quatre familles ci-dessous en dépendent.

Comptes utilisateurs :

Créer un utilisateur avec des paramètres précis : home, shell, UID, groupe principal, groupes secondaires
Ajouter un utilisateur à un groupe secondaire sans perdre ses groupes existants (usermod -aG)
Verrouiller et déverrouiller un compte
Supprimer un compte et son répertoire personnel
Définir un mot de passe interactivement et en mode non interactif

Politique de mots de passe :

Configurer l'expiration du mot de passe (durée max, durée min, avertissement)
Configurer l'expiration du compte (date limite)
Forcer un changement de mot de passe à la prochaine connexion
Vérifier la politique appliquée à un utilisateur

Groupes :

Créer un groupe avec un GID spécifique
Ajouter et retirer des membres d'un groupe
Vérifier l'appartenance aux groupes d'un utilisateur

Délégation sudo :

Configurer des règles sudo ciblées dans /etc/sudoers.d/
Appliquer le moindre privilège : ne pas donner ALL=(ALL) ALL quand une commande spécifique suffit
Vérifier les droits sudo effectifs d'un utilisateur
Comprendre le rôle du groupe wheel sur RHEL

Pièges fréquents

Le premier piège est le plus classique de toute l'administration Linux, et il ne provoque aucun message d'erreur : l'utilisateur perd simplement ses autres groupes, ce qui casse des accès ailleurs sur le système. Le dernier crée un compte qui existe mais reste inutilisable, donc non validé par le correcteur.

Utiliser usermod -G au lieu de usermod -aG, sans -a, les groupes secondaires existants sont écrasés
Ne pas vérifier le résultat avec id après modification, l'examen évalue le résultat, pas la commande
Créer des règles sudo trop permissives, en environnement Red Hat, le moindre privilège est attendu
Oublier de définir un mot de passe après useradd, le compte existe mais est inaccessible

Manage security

Ce bloc couvre la sécurité du système : firewall, SELinux et authentification SSH par clé.

Compétences officielles

C'est le bloc dont Red Hat détaille le plus les objectifs, et cinq d'entre eux portent sur SELinux seul. Le message est clair : l'examen ne demande pas de « connaître » SELinux, il demande de savoir le diagnostiquer et le corriger en mode Enforcing. L'objectif sur les permissions par défaut renvoie à umask, souvent oublié.

Configurer le pare-feu avec firewall-cmd / firewalld
Gérer les permissions par défaut des fichiers (umask)
Configurer l'authentification SSH par clé
Basculer SELinux entre les modes Enforcing et Permissive
Lister et identifier les contextes SELinux de fichiers et de processus
Restaurer les contextes par défaut des fichiers
Gérer les labels de ports SELinux
Utiliser les booléens pour modifier le comportement de SELinux

Ce que cela implique concrètement

Retenez que le pare-feu et SELinux sont deux couches indépendantes qui bloquent des choses différentes : ouvrir un port dans firewalld ne dit rien à SELinux, et labelliser un port SELinux ne l'ouvre pas dans le pare-feu. Pour un service sur un port non standard, il faut presque toujours faire les deux, et c'est exactement ce que l'examen cherche à vérifier.

Firewall (firewalld) :

Autoriser un service ou un port dans le firewall de façon permanente
Appliquer les règles permanentes avec --reload, sans reload, la règle permanente n'est pas active
Changer la zone par défaut
Vérifier la configuration complète du firewall
Comprendre que --permanent seul ne rend pas la règle immédiatement active, et qu'une règle sans --permanent est perdue au reboot

SELinux :

Vérifier le mode courant (Enforcing, Permissive, Disabled) et la politique active
Passer du mode Enforcing au mode Permissive de façon éphémère et de façon persistante (/etc/selinux/config)
Afficher et comprendre le contexte SELinux d'un fichier (ls -Z) et d'un processus (ps -Z)
Corriger un contexte fichier : définir une règle persistante avec semanage fcontext puis appliquer avec restorecon
Ne pas utiliser chcon seul, le contexte sera écrasé au prochain relabel
Activer un boolean SELinux de façon persistante (setsebool -P)
Autoriser un port non standard pour un service (semanage port -a)
Diagnostiquer un refus SELinux : lire les logs d'audit (ausearch -m avc), utiliser sealert pour obtenir des suggestions, puis appliquer la correction (contexte, boolean ou port)
Comprendre que SELinux et le firewall sont deux couches indépendantes, un service peut être bloqué par l'un, l'autre, ou les deux

SSH par clé :

Générer une paire de clés (préférer ed25519)
Déployer la clé publique sur un serveur distant
Configurer le serveur SSH : désactiver l'authentification par mot de passe, interdire la connexion root directe
Vérifier les permissions obligatoires sur ~/.ssh/ (700) et ~/.ssh/authorized_keys (600)
Appliquer les modifications du serveur SSH sans couper les sessions actives

Pièges fréquents

Deux de ces cinq pièges produisent une configuration qui fonctionne pendant la session et disparaît ensuite : la règle --permanent sans --reload, et le contexte posé avec chcon. Le deuxième piège est d'une autre nature, c'est une faute d'attitude : désactiver SELinux pour faire passer une tâche invalide le travail au lieu de le valider.

Ajouter une règle firewall avec --permanent mais oublier --reload, la règle existe dans la config mais n'est pas active
Désactiver SELinux au lieu de le gérer, la RHCSA exige de travailler en mode Enforcing
Utiliser chcon au lieu de semanage fcontext + restorecon, la correction ne survit pas à un relabel
Oublier que semanage port et firewall-cmd sont deux choses différentes : l'un gère le label SELinux du port, l'autre l'autorise dans le pare-feu, les deux sont souvent nécessaires pour un service non standard
Mauvaises permissions sur ~/.ssh/, SSH refuse silencieusement l'authentification par clé

Gestion de conteneurs, hors objectifs RHEL 10

Sur RHEL, l'outil de référence pour les conteneurs est Podman en mode rootless. Ce bloc figurait dans les objectifs EX200 basés sur RHEL 9 ; il n'apparaît plus dans la liste publiée pour RHEL 10.

Ce que Podman rootless suppose de connaître

Ces gestes ne sont pas évalués par l'EX200 sur RHEL 10, mais ils constituent le socle attendu d'un administrateur RHEL et se retrouvent dans les certifications de niveau supérieur.

Rechercher et télécharger une image depuis un registry
Lancer un conteneur en arrière-plan avec un port exposé
Inspecter un conteneur et exécuter une commande à l'intérieur
Arrêter et supprimer un conteneur
Lister les images locales
Rendre un conteneur persistant avec un unit systemd
Activer le service conteneur en mode rootless (systemctl --user enable)
Configurer loginctl enable-linger pour qu'un conteneur rootless démarre sans session interactive

Pièges fréquents

Le premier piège est celui qui surprend le plus : un service utilisateur ne survit pas à la fermeture de la session tant que le lingering n'est pas activé. Le second est un piège de génération, car la méthode enseignée par la plupart des supports est désormais obsolète.

Oublier loginctl enable-linger, le conteneur rootless ne démarre pas automatiquement au boot
S'appuyer sur podman generate systemd : la commande affiche [DEPRECATED] Generate systemd units et sa propre aide renvoie vers Quadlet (podman-systemd.unit(5)), la méthode déclarative désormais recommandée
Surpondérer les conteneurs dans la préparation au détriment des fondamentaux système, ce bloc reste secondaire par rapport au stockage, aux services ou à SELinux

La persistance, fil rouge de la RHCSA

La RHCSA ne se résume pas à exécuter des commandes. L'examen évalue votre capacité à produire un état stable qui survit au redémarrage. Le système est redémarré avant l'évaluation finale.

Cela concerne tous les blocs :

Domaine	Ce qui doit persister
Stockage	Montages dans `/etc/fstab` avec UUID, swap activé
Réseau	Configuration via `nmcli` (pas `ip addr`), hostname, routes, DNS
Firewall	Règles avec `--permanent` + `--reload`
SELinux	Contextes via `semanage fcontext` + `restorecon`, booleans avec `-P`, ports avec `semanage port`
Services	`systemctl enable` (pas seulement `start`)
Journaux	`Storage=persistent` dans `/etc/systemd/journald.conf`
Conteneurs	Unit systemd + `loginctl enable-linger`
Planification	Entrées crontab, fichiers dans `/etc/cron.d/`
Boot target	`systemctl set-default`
Tuned	`tuned-adm profile` (persistant par défaut si le service est activé)

Règle d'or : si vous configurez quelque chose pendant l'examen et que ce n'est plus là après reboot, le point n'est pas marqué.

Compétences les plus discriminantes

Ces sujets font souvent la différence entre un candidat qui rate de peu et un candidat qui réussit. Ils ont un point commun : ce sont des compétences qu'on contourne au quotidien en production, faute de temps ou parce qu'un collègue s'en charge, et qui deviennent bloquantes le jour où il faut les exécuter seul et sous chronomètre.

Deux précisions sur la lecture de ce tableau. Les ACL et autofs ne sont pas nommés tels quels dans les objectifs RHEL 10 : les premières relèvent de l'objectif « diagnostiquer et corriger des problèmes de permissions », le second est en revanche cité explicitement sous Create and configure file systems. Et si vous ne deviez travailler qu'une seule ligne, prenez LVM et le redimensionnement du système de fichiers : l'oubli du resize2fs ou du xfs_growfs après extension du volume logique est l'erreur la plus fréquemment rapportée.

Compétence	Pourquoi c'est discriminant
SELinux	Beaucoup le contournent au quotidien, la RHCSA exige de le gérer en Enforcing
LVM + redimensionnement FS	L'extension d'un LV sans le resize du FS est l'erreur la plus courante
Interrompre le boot (rd.break)	Procédure mécanique qui doit être fluide, le moindre oubli bloque
Firewall persistant	Le duo `--permanent` + `--reload` doit être un automatisme
Services et journaux	Diagnostiquer un service `failed` avec `journalctl` est attendu, pas seulement démarrer des services
fstab avec UUID	Une erreur dans fstab peut rendre le système non bootable, tester avant le reboot est vital
ACL	Les permissions avancées sont souvent négligées, mais explicitement dans le blueprint
Autofs	Le montage à la demande ne s'invente pas, il faut l'avoir pratiqué
Scripts shell	Un script non fonctionnel ne marque aucun point, la syntaxe doit être sûre

Réflexes de préparation

Ces principes sont transversaux à tous les blocs de compétences.

Toujours distinguer configuration immédiate et configuration persistante :

Sur RHEL, beaucoup de modifications sont éphémères par défaut. Si vous ne savez pas comment rendre un changement permanent, vous ne maîtrisez pas encore la compétence.

Toujours vérifier le résultat après modification :

L'examen évalue l'état du système, pas les commandes tapées. Après chaque action : systemctl status, findmnt, firewall-cmd --list-all, getenforce, ip addr, ss -tulpn…

Savoir diagnostiquer, pas seulement exécuter :

Le blueprint demande explicitement de dépanner et de localiser des problèmes. Lire des journaux, interpréter un message d'erreur, identifier une cause : ce sont des compétences à part entière.

Réviser sur un environnement RHEL 10 :

L'examen est basé sur RHEL 10. Les outils RHEL (dnf, nmcli, firewalld, systemd, SELinux, Podman) sont spécifiques, les maîtriser sur une autre distribution ne suffit pas.

Travailler les fondamentaux avant les sujets périphériques :

Le stockage (LVM, fstab), les services (systemd, journalctl), la sécurité (firewalld, SELinux) et le boot recovery représentent le cœur de l'examen. Maîtrisez-les parfaitement avant de consacrer du temps aux conteneurs ou à Flatpak.

Utiliser les ressources autorisées :

Pendant l'examen, man, --help, info et /usr/share/doc sont disponibles. Savoir naviguer rapidement dans une page man pour trouver la bonne option fait gagner un temps précieux.

À retenir

La RHCSA est un examen performance-based sur RHEL 10, chaque tâche doit produire un résultat fonctionnel et persistant.
Red Hat publie des objectifs de compétence, pas une liste de commandes, la page EX200 décrit ce que vous devez savoir faire.
Le système est redémarré avant évaluation, tout ce qui n'est pas persistant est perdu et ne marque pas de point.
Les blocs les plus lourds sont : stockage et LVM, services et journaux, firewall et SELinux, récupération de boot.
SELinux ne se contourne pas : l'examen exige de travailler en mode Enforcing et de savoir diagnostiquer les refus.
Le duo semanage + firewall-cmd est souvent nécessaire ensemble pour un service non standard.
La RHCSA est la base obligatoire vers la RHCE, les compétences acquises ici sont cumulatives.
L'entraînement en lab sur RHEL 10 est irremplaçable, relire une page de compétences ne suffit pas.