DP-700

Activer Git integration ne suffit pas à industrialiser Fabric. Cinq piliers comptent : accès, secrets, infrastructure as code, CI/CD, monitoring. Le point essentiel de chacun, et où aller plus loin.

Créer un Key Vault en mode RBAC au portail Azure, puis y ranger un secret : la création échoue en Forbidden alors qu’on vient de créer le coffre. Pourquoi, et les deux rôles à connaître.

Lire un secret Key Vault, obtenir un jeton, appeler l’API Fabric depuis un notebook : ce que fait vraiment notebookutils.credentials. getSecret veut une URL, putSecret existe mais échoue, et un service principal ne voit pas les mêmes workspaces que vous.

Un Viewer sans aucun rôle OneLake ne voit rien dans l’explorateur du lakehouse, mais lit pourtant la table via le point de terminaison SQL. La cause : le mode delegated identity, actif par défaut. Test en lab, avant et après le passage en user’s identity.

Dans OneLake security, un utilisateur cumule les accès de tous ses rôles : un rôle restrictif ne retire rien à ce qu’un autre accorde. Test avec un compte Viewer, puis Contributor, et le rôle DefaultReader alimenté par ReadAll.

Aide-mémoire interactif : cherchez le motif SQL que vous écrivez d’habitude, voyez son équivalent en KQL. Filtres par catégorie, recherche plein texte, copie en un clic.

Les trois DMV de cycle de vie de Fabric Warehouse ressemblent à celles de SQL Server, jusqu’au moment où on les utilise exactement pareil. Ce qui manque, ce qui trompe, et le modèle de concurrence qui change tout, vérifié en lab.

queryinsights regroupe six vues pour analyser l’historique des requêtes d’un Fabric Warehouse. Grain, rétention, agrégation par forme de requête, et des noms de colonnes qui glissent d’une couche à l’autre, vérifié en lab.

Cinq actions du panneau Source Control de Fabric se ressemblent sur le papier mais font des choses radicalement différentes. Retour d’expérience pratique, avec les pièges rencontrés en testant chacune.

Retour d’expérience pas à pas : authentifier Azure DevOps auprès de l’API Fabric via un Service Principal, et déclencher un déploiement Dev → Test, avec les pièges rencontrés en conditions réelles.