QCM : Révision d’architecture Azure AZ-305 (39 questions)

Explication

Un tenant est une instance dédiée de l’annuaire qui regroupe notamment les utilisateurs, les groupes et les applications d’une organisation. Un conteneur de ressources et de facturation correspond plutôt à une subscription Azure.

Explication

Une subscription Azure est un conteneur de facturation et de ressources qui fait confiance à un seul tenant, alors qu’un tenant peut être associé à plusieurs subscriptions. L’idée qu’un tenant ne puisse avoir qu’une subscription inverse cette relation.

Explication

Azure RBAC sert à administrer les ressources Azure, tandis que les rôles Entra servent à administrer l’annuaire. Les rôles Entra ne remplacent donc pas Azure RBAC pour la gestion des ressources.

Explication

External ID B2B sert à inviter des partenaires dans un tenant, tandis que le tenant clients External ID gère l’inscription et la connexion des clients d’une application. Les affecter dans l’ordre inverse confond collaboration avec partenaires et identité des clients.

Explication

L’inscription définit l’application dans son tenant d’origine, tandis que l’application d’entreprise en est la représentation dans un tenant et correspond au principal de service. L’inversion de ces rôles attribue à tort la représentation locale à l’inscription.

Explication

Les permissions d’application permettent à un service d’agir sans utilisateur, alors que les permissions déléguées agissent au nom d’un utilisateur connecté. Une permission déléguée ne convient donc pas à un appel effectué en l’absence d’utilisateur.

Explication

Avec une identité managée, Azure gère les informations d’identification, ce qui évite à l’équipe de gérer et de faire tourner un secret. Un principal de service fondé sur un secret ou un certificat requiert au contraire la gestion de ces éléments.

Explication

Une identité attribuée par l’utilisateur est indépendante du cycle de vie d’une ressource et peut être partagée entre plusieurs ressources. Une identité attribuée par le système est liée à une ressource particulière et suit son cycle de vie.

Explication

L’autorisation détermine ce que l’utilisateur peut faire, tandis que l’authentification établit qui il est. La méthode utilisée pour vérifier son identité relève donc de l’authentification, et non de l’autorisation.

Explication

FIDO2 fait partie des méthodes résistantes au phishing, avec Windows Hello for Business et l’authentification par certificat. Les codes SMS, les appels vocaux et OATH TOTP ne sont pas classés comme résistants au phishing.

Explication

Les security defaults fournissent gratuitement des protections de base adaptées aux petits tenants sans licence P1. Conditional Access, contrairement à cette option, nécessite au minimum Entra ID P1.

Explication

Une politique Conditional Access combine des affectations d’utilisateurs et d’applications, des conditions et des contrôles d’octroi ou de session ; les comptes break-glass doivent être exclus. Les inclure dans les affectations risquerait de leur appliquer les exigences de la politique.

Explication

Identity Protection cible les risques liés aux identités, alors que Defender for Identity surveille l’Active Directory local. Sentinel corrèle des données de sécurité plutôt que de se consacrer à la détection des risques d’identité.

Explication

Pour un risque de connexion moyen, la mesure recommandée est l’authentification multifacteur, et ces politiques basées sur le risque nécessitent Entra ID P2. Le changement de mot de passe ou le blocage correspond plutôt à un risque utilisateur élevé.

Explication

Un rôle éligible est disponible pour une activation à la demande, tandis qu’un rôle actif est actuellement utilisable, de façon permanente ou temporaire. Un rôle éligible n’est donc pas utilisable sans activation.

Explication

Après la demande d’activation et les contrôles requis, PIM active le rôle pour une durée limitée, à l’issue de laquelle il expire automatiquement. Le flux ne transforme pas l’activation en attribution permanente.

Explication

Une affectation Azure RBAC associe un principal de sécurité, une définition de rôle et un scope. Une stratégie Azure ou un package d’accès relève d’autres mécanismes de gouvernance.

Explication

Les scopes suivent la hiérarchie du groupe de gestion à l’abonnement, au groupe de ressources, puis à la ressource, et les affectations sont héritées vers le bas. Une affectation au groupe de ressources ne remonte donc pas vers l’abonnement.

Explication

Les DataActions régissent l’accès au contenu des ressources, notamment aux blobs ou aux secrets. Les Actions concernent la gestion des ressources plutôt que la lecture de leur contenu.

Explication

Contributor peut créer et modifier des ressources, mais ne peut pas attribuer de rôles. Owner peut également attribuer des rôles, ce qui dépasse le besoin décrit.

Explication

Les rôles RBAC appliqués à un management group sont hérités par les éléments situés en dessous, dont les abonnements. L’affectation ne remonte pas vers les éléments parents.

Explication

Azure Policy définit des règles de conformité sur les ressources, tandis que RBAC détermine qui peut effectuer des actions. Inverser ces fonctions confond le contrôle des ressources avec le contrôle des identités et des permissions.

Explication

L’effet Deny bloque la création ou la modification non conforme, tandis qu’Audit signale la non-conformité sans bloquer l’opération. Audit ne suffit donc pas à empêcher la création.

Explication

Les tags servent notamment à organiser les ressources, répartir les coûts et filtrer l’inventaire, mais ils ne se transmettent pas automatiquement du groupe de ressources à ses ressources. La configuration d’un groupe ne suffit donc pas à appliquer le tag à ses membres.

Explication

CanNotDelete protège la ressource contre la suppression sans empêcher sa lecture ni sa modification. ReadOnly bloque aussi les modifications et s’applique aux Owners tant que le verrou n’est pas retiré.

Explication

Azure Cost Management propose des budgets et des alertes pour suivre les dépenses, mais un budget n’arrête pas les ressources par défaut. Une alerte informe l’équipe; elle ne réalise pas automatiquement le redimensionnement décrit par un distracteur.

Explication

Metrics fournit des données numériques légères et quasi temps réel, tandis que Logs contient des événements détaillés que l’on peut interroger dans Log Analytics avec KQL. Le distracteur qui inverse Metrics et Logs confond les mesures avec les événements détaillés.

Explication

Les resource logs décrivent l’activité interne d’une ressource et nécessitent des diagnostic settings pour être collectés. L’Activity Log porte plutôt sur les opérations du plan de contrôle de la subscription.

Explication

Azure Monitor Agent collecte les données des machines virtuelles selon des Data Collection Rules qui précisent quoi collecter, comment transformer les données et où les envoyer. Ces règles pilotent la collecte; elles ne servent pas à gérer le cycle de vie des machines virtuelles.

Explication

L’alerte définit la condition à détecter, tandis que l’Action Group définit les actions de notification ou de réponse et peut être partagé entre plusieurs alertes. Une condition d’alerte ne remplace donc pas la configuration réutilisable des actions.

Explication

Application Insights surveille les performances et la disponibilité d’une application en collectant notamment ses requêtes, dépendances, exceptions et temps de réponse. Service Health porte plutôt sur les incidents Azure susceptibles d’affecter les services d’un client.

Explication

Azure Advisor examine la configuration et l’usage pour proposer des optimisations, Defender for Cloud évalue la posture et protège les charges de travail, et Sentinel sert à détecter, investiguer et répondre aux incidents. Confier les recommandations d’optimisation à Defender for Cloud confond son rôle de sécurité avec celui d’Advisor.

Explication

CSPM concerne la gestion de la posture de sécurité dans le cloud, alors que CWPP porte sur la protection des charges de travail. L’association inverse est une confusion fréquente entre ces deux fonctions.

Explication

Dans Sentinel, les règles analytiques détectent les événements et génèrent des incidents, qui sont ensuite investigués avant une réponse automatisée par règles et playbooks Logic Apps. Les connecteurs assurent l’ingestion des données, pas la création des incidents.

Explication

Azure Backup restaure les données depuis un point de récupération, alors qu’Azure Site Recovery réplique des charges de travail et permet leur basculement vers un site ou une région secondaire. Attribuer la réplication de charge à Azure Backup confond sauvegarde et reprise après sinistre.

Explication

Le RTO correspond à la durée maximale d’indisponibilité acceptable, tandis que le RPO mesure la perte maximale de données acceptable en temps. Inverser ces deux mesures attribue à chacune le seuil défini par l’autre.

Explication

Les machines virtuelles relèvent notamment du Recovery Services vault, tandis que les disques managés figurent parmi les ressources protégées par le Backup vault. Le choix du Recovery Services vault pour les disques managés confond les ressources associées aux deux coffres.

Explication

Les Availability Sets contribuent à la disponibilité face aux pannes de rack et aux opérations de maintenance, alors que les Availability Zones protègent contre la panne d’un datacenter dans une région. Inverser ces mécanismes attribue à chacun le niveau de défaillance de l’autre.

Explication

La réplication vers une région secondaire, notamment par ASR, GRS/GZRS ou des solutions de bases multirégion, protège contre une panne régionale. Les zones améliorent la résilience face à la panne d’un datacenter, mais ne couvrent pas à elles seules la perte de la région.