Learning a cloud platform is difficult partly because the documentation is so good.
That sounds backwards, but Azure is a useful example. Microsoft has documentation for almost every service, feature, edge case, and architectural decision an admin could encounter. The problem is not a lack of information, it’s that the information is contained in a vast reference library, organized more for retrieval than for actually learning.
When I need to understand something in Azure, particularly identity and access management, I have started using NotebookLM as a study tool. I feed it selected Microsoft documentation and use it to ask questions, generate outlines, and create audio discussions that make the material easier to revisit. The important part is not treating it as an authority. Microsoft’s documentation is the authority. NotebookLM is useful because it gives me another way to work through the otherwise overwhelming source material.
IAM roles are a good case study. At first, Azure role-based access control seems straightforward: identities receive permissions through role assignments, usually at a management-group, subscription, resource-group, or resource scope. Spend a little more time with it, though, and a simple diagram becomes a set of consequential distinctions. What is the difference between a built-in role and a custom role? When should access be assigned to a group rather than an individual? How do Azure RBAC roles relate to Microsoft Entra directory roles? What does least privilege actually mean when someone needs to operate a production service?
Those are not questions that are best answered by memorizing a list of roles. They require repeated contact with the concepts, envisioning different scenarios and how they would evolve over time.
My current approach is to gather a focused set of Microsoft Learn pages: introductory RBAC material, documentation on role assignments and scopes, pages describing built-in roles, and the relevant material on managed identities or Microsoft Entra ID. Rather than adding the entire Azure documentation universe to a notebook, I try to assemble a small, coherent reading list around a question I actually have. A notebook about RBAC should have enough material to explain RBAC well, not every document about every Azure service.
Once the sources are in place, I ask NotebookLM to help me identify the conceptual structure. I might ask it to distinguish the terms that beginners often collapse together: identity, principal, role definition, role assignment, scope, directory role, and resource role. I can then return to the original documentation with better questions in mind.
The audio-overview feature has been unexpectedly useful here. It is not a replacement for reading technical documentation, and I would not use it as a source for a production change. But a conversation between two hosts can make a dense body of documentation feel more navigable. I can listen while walking, doing routine work, or preparing to read more closely. Hearing a discussion of why scope matters, for example, makes it easier to remember that assigning a role at the subscription level is a very different decision from assigning it to a single resource group.
I have been using this approach to create a small series of Azure “podcasts,” each built around a tightly bounded topic. One episode might introduce RBAC and scope. Another might examine managed identities and the difference between system-assigned and user-assigned identities. A later episode could focus on practical access design: group-based assignments, privileged access, auditing, and the uncomfortable fact that convenience often expands permissions faster than anyone intends.
The format works because it encourages a useful kind of engaged repetition. First I read the documentation. Then I use the notebook to ask for a map of the territory. Then I listen to an audio discussion. Finally, I return to the documentation and test whether I can explain the idea in my own terms. The goal is not merely to recognize Azure vocabulary. It is to be able to reason about a real request, such as whether an application needs a managed identity, which scope is appropriate for an operator, or whether a broad role assignment can be replaced with something narrower.
Here is the kind of prompt I use for a long-form audio overview:
Create the first episode of a long-form technical podcast series based only on the Microsoft documentation in this notebook. The series is for a technically literate listener who is learning Azure carefully and wants to understand concepts rather than memorize product names.
This episode should be a 30- to 40-minute deep dive on Azure role-based access control (Azure RBAC). Structure it as a conversation between two experts: one is a cloud identity architect who explains the formal model precisely; the other is a senior systems administrator who keeps the discussion grounded in operational decisions and realistic scenarios.
Explain identities, security principals, role definitions, role assignments, and scopes. Carefully distinguish Azure RBAC from Microsoft Entra directory roles. Use a realistic example involving an application, a developer team, and a production resource group to show how least privilege, group-based access, and scope interact. Discuss common misunderstandings and tradeoffs, but do not invent details that are not supported by the provided sources.
End with a concise recap of the concepts a listener should be able to explain after the episode, followed by three questions that would prepare them for the next episode on managed identities.
The value of a prompt like this is not that it produces a perfect lecture. It is that it creates a structured encounter with the material. The two-expert format pushes the discussion toward both theory and practice: what Azure means by a role assignment, but also what a sensible administrator should hesitate before doing.
There is a temptation to use AI tools as shortcuts around difficult material. I find them more interesting when they make sustained attention easier. Azure remains complicated after an audio overview. IAM roles still require care, documentation, and judgment. But NotebookLM can turn a pile of reference pages into a conversation worth returning to, and that is often enough to get the learning process moving.