60 questions d'embauche IT et cybersécurité avec réponses modèles courtes — mode entraînement : masquez les réponses, répondez à voix haute, puis vérifiez
60 questions affichées
Généralisten°1
Présentez-vous en deux minutes pour un poste IT.
Structurez en trois temps : parcours (formation, certifications en cours), compétences clés liées au poste visé avec un exemple concret, puis motivation pour ce poste précis. Terminez par ce que vous apportez à l'équipe. Restez factuel, chiffré quand c'est possible, et sous les deux minutes.
Piège à éviter : réciter son CV de façon exhaustive ou raconter sa vie personnelle ; le recruteur veut une synthèse orientée poste.
Expliquez la triade CIA en sécurité de l'information.
Confidentialité : seuls les autorisés accèdent aux données (chiffrement, contrôle d'accès). Intégrité : les données ne sont ni altérées ni corrompues (hachage, signatures). Disponibilité : les systèmes restent accessibles aux utilisateurs légitimes (redondance, sauvegardes). Tout contrôle de sécurité vise au moins un de ces trois piliers.
Piège à éviter : confondre CIA avec l'agence américaine ou citer les trois termes sans donner un exemple de contrôle pour chacun.
Décrivez le modèle OSI et son utilité en dépannage.
Sept couches : physique, liaison, réseau, transport, session, présentation, application. En dépannage, on isole la panne par couches : câble et connectivité (1-2), adressage et routage (3), ports et sessions (4), puis applicatif (5-7). Cette méthode descendante ou ascendante évite de chercher au hasard.
Piège à éviter : énumérer les couches sans expliquer comment on s'en sert concrètement face à une panne réseau.
TCP ou UDP : quelles différences et quand choisir ?
TCP est orienté connexion : fiable, ordonné, avec accusés de réception (web, e-mail, transferts de fichiers). UDP est sans connexion : rapide, sans garantie de livraison (streaming, VoIP, DNS). On choisit TCP quand la fiabilité prime, UDP quand la latence prime et que la perte de quelques paquets est acceptable.
Piège à éviter : dire que l'un est « meilleur » que l'autre dans l'absolu ; tout dépend du besoin applicatif.
Comment fonctionne une résolution DNS de bout en bout ?
Le client interroge son résolveur, qui contacte les serveurs racine, puis le serveur TLD (.fr, .com), puis le serveur faisant autorité pour le domaine, et renvoie l'adresse IP. Le cache à chaque niveau accélère les requêtes suivantes. Un échec à une étape précise (timeout, NXDOMAIN) oriente le diagnostic.
Piège à éviter : répondre « ça traduit un nom en IP » sans décrire la hiérarchie ; c'est la hiérarchie que le recruteur attend.
Qu'est-ce qu'un VPN et quels en sont les usages en entreprise ?
Un VPN crée un tunnel chiffré sur un réseau non fiable pour relier un poste distant ou un site au réseau d'entreprise. Usages : télétravail sécurisé, interconnexion de sites, accès d'administrateurs. Protocoles courants : IPsec, SSL/TLS, WireGuard. Il protège la confidentialité du transit mais ne dispense pas d'authentifier les utilisateurs.
Piège à éviter : assimiler VPN grand public et VPN d'entreprise, ou croire qu'un VPN protège contre les malwares.
Pourquoi le MFA est-il indispensable, même avec un bon mot de passe ?
Parce que les mots de passe fuient (phishing, bases divulguées, réutilisation) et que le MFA exige un second facteur indépendant : ce que l'on possède (application, clé FIDO2) ou ce que l'on est (biométrie). Il bloque l'essentiel des prises de contrôle de comptes. Privilégiez les facteurs résistants au phishing plutôt que le SMS.
Piège à éviter : dire que le MFA rend un compte inviolable ; il réduit fortement le risque mais le phishing de session reste possible.
Chiffrement symétrique ou asymétrique : différences et usages ?
Symétrique (AES) : une seule clé, rapide, idéal pour chiffrer des volumes de données. Asymétrique (RSA, ECC) : paire clé publique/privée, plus lent, utilisé pour échanger des clés et signer. En pratique on combine les deux : l'asymétrique négocie une clé de session, le symétrique chiffre le flux (c'est le principe de TLS).
Piège à éviter : opposer les deux comme concurrents alors qu'ils sont complémentaires dans les protocoles réels.
Qu'est-ce que le phishing et comment s'en protéger en entreprise ?
Le phishing usurpe une identité de confiance (e-mail, SMS, appel) pour voler identifiants ou déclencher une action. Défenses : filtrage des e-mails, MFA résistant, sensibilisation et simulations régulières, procédure de signalement simple, et vérification des demandes sensibles par un second canal. La vitesse de signalement conditionne l'efficacité de la réponse.
Piège à éviter : réduire la protection à un outil technique ; le facteur humain et la procédure de signalement comptent autant.
Quelle est la différence entre un virus, un ver et un rançongiciel ?
Le virus s'attache à un programme hôte et nécessite une action pour se propager. Le ver se réplique seul sur le réseau sans hôte ni action. Le rançongiciel chiffre les données puis exige une rançon ; c'est une finalité, pas un mode de propagation. Face à un rançongiciel : isoler, ne pas payer sans avis, restaurer depuis des sauvegardes saines.
Piège à éviter : appeler « virus » tout malware ; utilisez le vocabulaire précis attendu en cybersécurité.
Chaque utilisateur, service ou processus ne reçoit que les droits strictement nécessaires à sa mission, pour une durée limitée. Cela réduit la surface d'attaque et l'impact d'un compte compromis. Mise en œuvre : rôles (RBAC), comptes séparés pour l'administration, revues d'accès régulières, suppression des droits dormants.
Piège à éviter : rester théorique ; citez une mesure concrète comme la suppression des droits administrateurs locaux.
HTTP ou HTTPS : que change le « S » concrètement ?
HTTPS encapsule HTTP dans TLS : chiffrement du contenu, authentification du serveur via certificat, garantie d'intégrité. Il ne garantit ni l'honnêteté du site ni l'absence de malware : un site frauduleux peut avoir un certificat valide. Vérifiez toujours le domaine exact et les signaux de confiance au-delà du cadenas.
Piège à éviter : affirmer qu'un site en HTTPS est forcément sûr ; le chiffrement n'est pas une preuve de légitimité.
Qu'est-ce qu'un pare-feu et que filtre-t-il exactement ?
Un pare-feu contrôle les flux réseau selon des règles : adresses, ports, protocoles, et pour les pare-feux nouvelle génération, applications, utilisateurs et contenu (IPS, filtrage web, antivirus). Il s'applique en périmètre, entre segments internes et sur les postes. Sans règles revues et journalisées, ce n'est qu'une boîte coûteuse.
Piège à éviter : croire qu'un pare-feu suffit seul ; il fait partie d'une défense en profondeur.
Comment sécurisez-vous un mot de passe en base de données ?
On ne stocke jamais le mot de passe en clair : on stocke une empreinte produite par une fonction lente et salée (bcrypt, Argon2), avec un sel unique par utilisateur. On ajoute une politique de longueur, la détection des mots de passe compromis et le MFA. En cas de fuite, les empreintes lentes rendent le cassage coûteux.
Piège à éviter : proposer MD5 ou SHA-1, cassés et trop rapides pour cet usage, ou « chiffrer » les mots de passe de façon réversible.
Qu'est-ce que la sauvegarde 3-2-1 et pourquoi l'appliquer ?
Trois copies des données, sur deux supports différents, dont une hors site ou hors ligne. Cette règle protège contre la panne matérielle, l'erreur humaine et le rançongiciel. L'essentiel est de tester régulièrement la restauration : une sauvegarde non testée n'est qu'une hypothèse de reprise.
Piège à éviter : parler de sauvegardes sans mentionner le test de restauration, que tout recruteur attend.
Quelle est la différence entre authentification, autorisation et traçabilité ?
Authentification : prouver qui l'on est (identifiants, MFA). Autorisation : déterminer ce que l'on a le droit de faire (rôles, ACL). Traçabilité : enregistrer qui a fait quoi pour auditer et enquêter (journaux). Un système sûr exige les trois : identifier, limiter, puis prouver a posteriori.
Piège à éviter : mélanger authentification et autorisation, deux étapes distinctes et complémentaires.
Qu'est-ce que le Zero Trust en une explication simple ?
Ne jamais faire confiance par défaut, même à l'intérieur du réseau : chaque accès est vérifié (identité, poste, contexte) et limité au strict nécessaire, en continu. Concrètement : MFA partout, micro-segmentation, contrôle d'accès conditionnel, supervision. C'est une stratégie, pas un produit unique.
Piège à éviter : présenter le Zero Trust comme un outil à acheter plutôt qu'une architecture et des politiques.
Comment gérez-vous les mises à jour et les correctifs en entreprise ?
Inventaire des actifs, priorisation selon la criticité et l'exploitabilité (CVE, correctifs de sécurité d'abord), tests sur un périmètre pilote, déploiement planifié avec fenêtre de maintenance, puis vérification de conformité. Les correctifs de sécurité critiques ne doivent pas attendre le cycle mensuel.
Piège à éviter : dire « on met tout à jour dès que ça sort » sans parler de tests ni de priorisation.
Qu'est-ce qu'une CVE et comment l'exploitez-vous au quotidien ?
Une CVE est un identifiant unique de vulnérabilité connue, avec description et score de gravité (CVSS). Au quotidien : veille sur les CVE touchant nos actifs, croisement avec l'inventaire, priorisation des correctifs, et vérification d'exploitation active. C'est le langage commun entre équipes, éditeurs et RSSI.
Piège à éviter : confondre CVE (la faille), CWE (le type de faiblesse) et CVSS (le score de gravité).
Pourquoi voulez-vous travailler dans la cybersécurité / l'IT chez nous ?
Reliez trois éléments : ce que l'entreprise fait concrètement (secteur, défis cités dans l'offre), ce que vous savez déjà faire (compétences, certifications, labs), et ce que vous voulez y apprendre. Montrez que vous avez préparé l'entretien : un fait précis sur l'entreprise vaut mieux qu'un compliment général.
Piège à éviter : la réponse générique (« la cyber me passionne ») sans aucun lien avec l'entreprise ou le poste.
Décrivez votre méthode de triage face à une alerte SIEM.
Je qualifie d'abord : criticité de l'actif, fiabilité de la règle, contexte (utilisateur, horaire, historique). Je corrobore avec d'autres sources (EDR, pare-feu, logs), je détermine vrai ou faux positif, puis je classe : clôture documentée, surveillance renforcée ou escalade avec un résumé et des preuves. Chaque décision est tracée dans le ticket.
Piège à éviter : foncer sur l'escalade sans vérifier le contexte ; un bon analyste filtre avant d'alerter.
Comment distinguez-vous un vrai positif d'un faux positif ?
Je croise l'alerte avec le comportement attendu : l'action est-elle légitime dans ce contexte (admin, script connu, plage de maintenance) ? Je cherche des corroborations indépendantes (processus, connexions, intégrité des fichiers) et l'historique de l'entité. Sans preuve d'activité malveillante après investigation, je conclus en faux positif documenté et je propose d'affiner la règle.
Piège à éviter : clôturer en faux positif par lassitude sans preuve ; la fatigue des alertes est un risque connu à nommer.
Que signifient MTTD et MTTR, et comment les améliorer ?
MTTD : délai moyen de détection d'un incident ; MTTR : délai moyen de réponse et de rétablissement. On les améliore par des règles de détection pertinentes, l'enrichissement automatique des alertes, des runbooks clairs, l'automatisation (SOAR) et des exercices réguliers. Ce sont les indicateurs de performance suivis par le management du SOC.
Piège à éviter : confondre les deux métriques ou promettre un MTTR nul, irréaliste.
Un runbook est la procédure pas à pas pour traiter un type d'alerte : conditions de déclenchement, vérifications à effectuer, commandes et requêtes utiles, critères d'escalade, actions de confinement autorisées, modèle de compte rendu. Il garantit une réponse homogène quel que soit l'analyste de garde et sert de base à l'automatisation.
Piège à éviter : décrire un runbook comme un simple document ; insistez sur sa mise à jour après chaque retour d'expérience.
J'escalade quand l'impact potentiel dépasse mon périmètre : criticité élevée, actif sensible, propagation suspectée, ou besoin d'actions que je ne peux autoriser (coupure, restauration). J'escalade vers le niveau 2 ou le responsable d'astreinte avec un dossier : faits, preuves, actions déjà menées, impact estimé. Escalader tôt un cas grave vaut mieux qu'escalader tard.
Piège à éviter : escalader sans dossier ni synthèse ; le niveau 2 attend des faits exploitables, pas une alerte brute.
Donnez un exemple de requête KQL utile en chasse aux menaces.
Par exemple lister les processus rares sur le parc : rechercher les créations de processus, regrouper par nom de fichier, compter les hôtes distincts, et filtrer les occurrences uniques pour repérer l'anormal. En KQL Sentinel cela combine where sur le temps, summarize avec dcount, et un tri. L'idée à montrer : partir d'une hypothèse et réduire le bruit par agrégation.
Piège à éviter : réciter une requête apprise par cœur sans expliquer l'hypothèse de chasse qui la motive.
Quelles sont les grandes phases de la réponse aux incidents ?
Préparation (runbooks, contacts, outils), détection et analyse (triage, qualification), confinement (isoler sans détruire les preuves), éradication (supprimer la cause), reprise (restaurer et surveiller), puis retour d'expérience (rapport, actions correctives). La traçabilité et la communication jalonnent toutes les phases.
Piège à éviter : oublier la préparation et le retour d'expérience, qui distinguent une équipe mature.
Un indicateur de compromission (hash, IP, domaine, URL, nom de fichier) signale une activité malveillante connue. Je l'utilise pour balayer les logs (chasse rétrospective), enrichir les alertes, bloquer en préventif et partager avec la communauté. Un IOC seul ne suffit pas : il faut le contexte (campagne, TTP associées) et vérifier sa fraîcheur.
Piège à éviter : traiter un IOC comme une preuve définitive ; c'est un indice à corroborer.
À quoi sert le cadre MITRE ATT&CK pour un analyste ?
C'est une cartographie des tactiques et techniques adverses (reconnaissance, exécution, persistance, exfiltration) avec identifiants et détections associées. L'analyste s'en sert pour qualifier une alerte, anticiper l'étape suivante de l'attaquant, structurer la chasse et mesurer la couverture de détection du SOC.
Piège à éviter : citer MITRE comme un produit ou un outil ; c'est une base de connaissances ouverte.
SIEM ou SOAR : quelles différences et complémentarités ?
Le SIEM collecte, corrèle et alerte à partir des journaux : c'est l'œil du SOC. Le SOAR orchestre et automatise la réponse via des playbooks : c'est le bras armé. Ensemble, ils réduisent le MTTR : le SIEM détecte, le SOAR enrichit, confine et documente automatiquement, l'analyste garde la décision sur les cas sensibles.
Piège à éviter : présenter le SOAR comme un remplaçant du SIEM ou de l'analyste.
Un poste est suspecté compromis : quelles sont vos premières actions ?
Je fais qualifier l'alerte, j'isole le poste du réseau tout en le laissant allumé (préserver la mémoire et les preuves), je bloque les IOC connus, je collecte les artefacts (processus, connexions, journaux EDR) et j'ouvre un ticket d'incident. Aucune réinstallation avant l'analyse : on confine d'abord, on comprend ensuite.
Piège à éviter : éteindre ou réinstaller immédiatement la machine, ce qui détruit des preuves volatiles.
Comment analysez-vous un e-mail de phishing signalé ?
J'examine les en-têtes (expéditeur réel, SPF/DKIM/DMARC, serveurs traversés), les liens et pièces jointes (URL réécrites, sandbox), puis je recherche d'autres destinataires dans l'entreprise. Si malveillant : purge des boîtes, blocage des IOC, réinitialisation des identifiants saisis, sensibilisation ciblée. Je remercie toujours le déclarant.
Piège à éviter : cliquer sur les liens « pour vérifier » depuis son poste de travail.
Qu'est-ce que la threat intelligence et ses niveaux ?
C'est le renseignement sur les menaces : stratégique (tendances pour la direction), opérationnelle (campagnes visant notre secteur), tactique (TTP et IOC pour le SOC). Elle alimente les règles de détection, la chasse et la priorisation. Une bonne threat intel est contextualisée à nos actifs, pas un simple flux d'IOC génériques.
Piège à éviter : réduire la threat intelligence à une liste d'adresses IP bloquées.
Comment priorisez-vous 50 alertes en début de garde ?
Par criticité et impact potentiel : sévérité de la règle, sensibilité des actifs, indices de compromission active, puis ancienneté. Je traite d'abord les alertes corrélées entre elles (signe d'une attaque en cours), je regroupe les doublons, et je planifie le reste. L'objectif : aucun incident critique en attente à la fin du tri initial.
Piège à éviter : traiter dans l'ordre chronologique sans priorisation par risque.
Résumé exécutif, chronologie des faits, périmètre et impact, cause racine, actions menées avec horodatage, preuves conservées, et recommandations (correctives et préventives). Il doit être lisible par un non-technique pour la synthèse et assez précis pour la technique en annexe.
Piège à éviter : un rapport purement technique sans synthèse ni recommandations actionnables.
L'antivirus classique bloque les malwares connus par signatures. L'EDR surveille en continu le comportement des postes (processus, réseau, registre), détecte l'anormal, permet l'investigation à distance et la réponse (isolation, neutralisation). En SOC, l'EDR est une source d'enquête ; l'antivirus seul ne suffit plus.
Piège à éviter : dire que l'EDR remplace toute analyse ; il reste un outil au service de l'analyste.
Comment détecter un mouvement latéral dans le réseau ?
Signes : connexions SMB/RDP inhabituelles entre postes, authentifications avec des comptes à privilèges hors horaires, création de tâches planifiées, outils d'administration détournés (PsExec, WMI). En pratique : corréler les logs d'authentification, repérer les comptes se déplaçant de machine en machine, et cartographier avec MITRE ATT&CK (tactique Lateral Movement).
Piège à éviter : ne surveiller que le périmètre ; le mouvement latéral se joue à l'intérieur.
Que faites-vous si une règle de détection génère trop de faux positifs ?
J'analyse un échantillon pour identifier le motif bénin déclencheur, je propose un affinage (exclusions ciblées, seuils, listes blanches documentées), je teste en mode surveillance avant mise en production, et je mesure la baisse des faux positifs sans perte de vrais positifs. Toute exclusion est tracée et réévaluée périodiquement.
Piège à éviter : désactiver la règle purement et simplement pour retrouver le calme.
Expliquez la chaîne de traitement d'un log, du capteur au ticket.
Collecte (agents, syslog, API), normalisation et parsing (format commun, horodatage), enrichissement (contexte utilisateurs, actifs, threat intel), corrélation (règles, modèles), génération d'alerte, triage analyste, puis ticket avec preuves. Une rupture à une étape (horloge désynchronisée, parser cassé) fausse toute la chaîne.
Piège à éviter : croire que le SIEM « voit tout » ; sans sources bien configurées, il est aveugle.
Racontez un incident (réel ou en lab) que vous avez traité.
Utilisez la méthode STAR : Situation (contexte et alerte), Tâche (votre rôle), Actions (investigation pas à pas, outils, décisions), Résultat (verdict, mesures, leçon apprise). Un exercice de lab bien raconté vaut mieux qu'un incident réel flou : montrez votre raisonnement, pas seulement l'outil.
Piège à éviter : inventer un incident spectaculaire invérifiable ou divulguer des données confidentielles d'un ancien employeur.
Un VLAN segmente logiquement un commutateur en plusieurs domaines de diffusion, séparant les populations (utilisateurs, serveurs, invités) sans matériel supplémentaire. Avantages : sécurité (isolation), performance (broadcasts limités), souplesse. Les VLAN communiquent via un routeur ou un commutateur de niveau 3, avec marquage 802.1Q sur les liens trunk.
Piège à éviter : présenter le VLAN comme une sécurité suffisante à lui seul ; sans ACL et sans durcissement, le saut de VLAN reste possible.
Le NAT traduit des adresses privées en adresse publique à la sortie vers Internet, palliant la pénurie d'IPv4. Variantes : statique (1 pour 1), dynamique (pool d'adresses), PAT/surcharge (plusieurs privés vers une seule publique via les ports, le cas courant des box et pare-feux). Il complique la traçabilité et le trafic entrant, d'où l'importance des journaux.
Piège à éviter : dire que le NAT est un mécanisme de sécurité ; c'est une fonction d'adressage, pas un pare-feu.
Qu'est-ce qu'Active Directory et quels sont ses composants clés ?
Annuaire central gérant identités et ressources du domaine Windows : contrôleurs de domaine, forêt et domaines, unités d'organisation, objets utilisateurs et groupes, stratégies de groupe (GPO), DNS intégré, Kerberos pour l'authentification. Compromettre l'AD, c'est compromettre l'entreprise : d'où la surveillance des comptes à privilèges.
Piège à éviter : réduire l'AD à « la gestion des mots de passe » ; montrez la vision annuaire, GPO et Kerberos.
À quoi servent les GPO et donnez un exemple concret.
Les stratégies de groupe appliquent des configurations aux utilisateurs et ordinateurs d'une OU : sécurité (complexité des mots de passe, verrouillage), déploiement logiciel, restrictions (désactiver les supports USB), page d'accueil imposée. Exemple : forcer le verrouillage de session après 5 minutes sur tous les postes du service comptabilité via une GPO liée à son OU.
Piège à éviter : oublier l'ordre d'application (local, site, domaine, OU) et le filtrage qui expliquent les conflits.
Expliquez la différence entre un cloud public, privé et hybride.
Public : ressources mutualisées chez un fournisseur (Azure, AWS), souplesse et paiement à l'usage. Privé : infrastructure dédiée à une organisation, contrôle maximal. Hybride : combinaison des deux, avec des charges réparties selon sensibilité et besoin (données critiques en local, pics absorbés dans le public). Le choix dépend des contraintes réglementaires et de coûts.
Piège à éviter : affirmer qu'un modèle est toujours supérieur ; chaque contexte a ses contraintes.
Azure Arc projette la gestion Azure (stratégies, inventaire, Defender for Cloud, Update Manager) sur des serveurs hors Azure : locaux ou autres clouds. Intérêt : administration unifiée, conformité homogène et supervision centralisée d'un parc hybride depuis le portail Azure, sans migrer les machines.
Piège à éviter : confondre Arc avec une migration ; les serveurs restent où ils sont, seule la gestion est centralisée.
Comment fonctionne le protocole DHCP, en quatre messages ?
Discover (le client cherche un serveur), Offer (le serveur propose une adresse), Request (le client accepte), ACK (le serveur confirme avec bail, masque, passerelle, DNS). En dépannage : vérifier la portée, les baux épuisés, les relais DHCP entre VLAN, et les serveurs pirates qui distribuent de fausses configurations.
Piège à éviter : oublier le rôle du relais (helper) quand client et serveur sont sur des sous-réseaux différents.
OSPF ou routage statique : quand utiliser chacun ?
Routage statique : simple et prévisible pour les petits sites et les routes par défaut, mais sans adaptation aux pannes. OSPF : protocole dynamique à état de liens, convergence rapide, adapté aux réseaux d'entreprise avec plusieurs chemins. On combine souvent les deux : OSPF au cœur, routes statiques redistribuées en bordure.
Piège à éviter : opposer les deux sans nuance ; les architectures réelles les mélangent.
Qu'est-ce qu'une ACL réseau et où l'appliquez-vous ?
Une liste de contrôle d'accès filtre le trafic selon adresses, ports et protocoles, dans l'ordre des règles jusqu'à la première correspondance. Placement : au plus près de la source pour les ACL étendues, en entrée ou sortie d'interface selon le sens à contrôler. Principe : autoriser l'explicite nécessaire, tout le reste est refusé, avec journalisation des refus.
Piège à éviter : oublier le refus implicite final ni l'ordre séquentiel des règles.
IPv4 ou IPv6 : pourquoi migrer et qu'est-ce qui change ?
IPv4 est épuisé (NAT en palliatif) ; IPv6 offre un espace immense, l'autoconfiguration (SLAAC), IPsec intégré et des en-têtes simplifiés. Changements pratiques : adresses hexadécimales 128 bits, plus de NAT nécessaire, Neighbor Discovery remplaçant ARP, et double pile pendant la transition. La migration se prépare : inventaire, formation, plan d'adressage.
Piège à éviter : croire qu'IPv6 est « sécurisé par nature » ; il faut le filtrer et le superviser comme IPv4.
Expliquez le handshake TLS 1.2/1.3 en termes simples.
Le client et le serveur négocient la version et les suites cryptographiques, le serveur présente son certificat, ils établissent une clé de session (échange de clés), puis le trafic applicatif est chiffré. TLS 1.3 réduit les allers-retours et supprime les algorithmes faibles. Vérifiez certificats, dates et chaînes de confiance en dépannage.
Piège à éviter : confondre le certificat (identité) avec le chiffrement (confidentialité du flux).
Qu'est-ce qu'un VNet Azure et comment le sécuriser ?
Un réseau virtuel isole les ressources Azure avec sous-réseaux, routage et peering. Sécurisation : groupes de sécurité réseau (NSG) par sous-réseau, pare-feu Azure en sortie, points de terminaison privés pour les PaaS, journalisation des flux (NSG flow logs), et segmentation par environnement. Même logique que le réseau local, adaptée au cloud.
Piège à éviter : exposer des ressources par IP publique par facilité au lieu d'un accès privé.
PowerShell ou interface graphique : que privilégiez-vous pour administrer ?
PowerShell pour tout ce qui se répète : scripts versionnés, reproductibles et auditables (création d'utilisateurs en masse, conformité, rapports). L'interface graphique pour explorer et pour les actions ponctuelles. Un bon administrateur automatise les tâches récurrentes et documente ses scripts : c'est du temps gagné et des erreurs en moins.
Piège à éviter : mépriser l'un ou l'autre ; montrez que vous choisissez l'outil selon la tâche.
Comment diagnostiquez-vous une panne réseau entre deux sites ?
Méthode par couches : vérifier la connectivité locale (passerelle, DNS), tester par étapes (ping, traceroute, ports avec Test-NetConnection), examiner les équipements intermédiaires (VPN, pare-feu, routes), puis les journaux. Je documente chaque résultat pour prouver où s'arrête le flux. L'isolement du segment fautif précède toute correction.
Piège à éviter : redémarrer les équipements au hasard avant d'avoir localisé la panne.
Qu'est-ce que le DNS menteur (split-brain) et à quoi sert-il ?
Servir des réponses différentes selon l'origine de la requête : les clients internes reçoivent les adresses privées, les externes les adresses publiques d'un même nom. Cela permet d'utiliser un seul nom de domaine en interne et externe tout en gardant les flux internes en local. À documenter soigneusement pour éviter les divergences.
Piège à éviter : laisser diverger les deux vues sans processus de synchronisation.
Expliquez le principe du modèle de responsabilité partagée dans le cloud.
Le fournisseur sécurise le cloud lui-même (infrastructure physique, hyperviseur) ; le client sécurise ce qu'il y met (données, identités, configurations, correctifs des VM). En IaaS le client garde beaucoup, en SaaS presque tout repose sur le fournisseur sauf les accès et les données. L'erreur classique : croire que « c'est dans le cloud donc c'est sécurisé ».
Piège à éviter : déléguer implicitement toute la sécurité au fournisseur, surtout en IaaS.
Qu'est-ce que Kerberos et pourquoi est-il central dans Windows ?
Protocole d'authentification par tickets : le client obtient un ticket du KDC puis prouve son identité aux services sans renvoyer son mot de passe. Central car il sécurise les ouvertures de session et l'accès aux ressources du domaine. Attaques connues (pass-the-ticket, Golden Ticket) : d'où la protection des contrôleurs et la surveillance des anomalies.
Piège à éviter : confondre Kerberos (authentification) avec les autorisations gérées par ailleurs.
Comment sécurisez-vous un accès administrateur à distance ?
Comptes nominatifs séparés pour l'administration, MFA obligatoire, accès via bastion ou VPN avec journalisation, principe du moindre privilège et accès juste-à-temps quand c'est possible. Les sessions sont enregistrées et revues. Jamais de compte générique partagé ni d'ouverture RDP/SSH directe sur Internet.
Piège à éviter : proposer un simple mot de passe fort sur un port exposé ; c'est exactement ce que les attaquants scannent.
Que vérifiez-vous avant de mettre un serveur en production ?
Durcissement (services inutiles désactivés, comptes par défaut supprimés), correctifs à jour, pare-feu local configuré, antivirus/EDR installé, sauvegarde et supervision en place, documentation (rôle, contacts, procédure de reprise), et tests de restauration. Un serveur non supervisé et non sauvegardé n'est pas prêt pour la production.
Piège à éviter : mettre en production puis « penser à la sauvegarde plus tard ».
Comment expliquez-vous un problème technique à un non-technicien ?
Je traduis l'impact métier d'abord (ce qui ne marche plus, pour qui, délai estimé), avec une analogie simple, sans jargon. Puis les options et ma recommandation, et ce que j'attends d'eux. Je confirme la compréhension et je m'engage sur le prochain point d'information. La clarté rassure plus que la technicité.
Piège à éviter : noyer l'interlocuteur sous les détails techniques au lieu de parler impact et délai.