DEV Community: Olivier Miossec

Using Claude Code in a PowerShell Project: An Introduction

Olivier Miossec — Sat, 14 Mar 2026 18:47:01 +0000

Generative and agentic AI have reshaped software development in a few short months. This is more than asking a chatbot for help; it’s a mindset shift and a cultural transformation in how we design, generate and maintain code.

Claude Code is one of the most advanced agentic tools for code generation, but like any generative system it can produce incorrect or low quality output. See the sloop content on Instagram, AI used carelessly, it can create the same "surface level" results you see on social platforms, attractive but unreliable.

In this post I’ll show how to use Claude Code in a PowerShell project: we’ll build a module to automate GitHub issue management.
First, a quick intro: Claude Code is part of Anthropic’s ecosystem (alongside Claude.ai, the Claude API and Claude CoWork). Claude Code is designed as an agentic coding assistant rather than a simple chatbot.
You can download it here

Claude Code is not a Chatbot, it is an AI Agent; it follow a workflow, gets the context, analyzes, plan the work and creates the code. In Claude Code, you don’t ask a question, you specify the result you want and the agent executes.

There is one important notion in Claude Code (and other AI tools), the Context. Context is the agent’s working memory, measured in tokens. It’s critical to manage. Claude Code sessions typically support large contexts (hundreds of thousands of tokens, depending on your plan). Monitor usage with the /context command; if you approach ~60% capacity, run /compact to reduce context size and avoid degraded behaviours.

The first best practice with Claude Code, is to keep a CLAUDE.md at the project root: treat it like a brief for the agent. Describe the project goals, constraints, runtime targets and coding conventions. That file becomes the agent’s persistent context, so you manage an agentic collaborator rather than a stateless LLM chat.

You can generate CLAUDE.md with the /init command: when run against an existing codebase, the agent analyses the repository and drafts the brief based on discovered files and patterns.

In this tutorial we start from an empty folder; you can author CLAUDE.md manually or ask Claude Code to create it for you.

"Create a new CLAUDE.md file in this folder with these instructions, PowerShell module for GitHub Issue Automation, named psGTIssue, the module will use classes, private function and public function, it run with PwSh 7 on Linux, MacOS and Windows. The project structure include, src, tests and build folder, the code should respect the camel case notation for variable and authorized verb for function (get-something), Pester will be used for unit testing"

You should have something like this:

# CLAUDE.md — psGTIssue Project Instructions

## Project Overview

**Module name:** `psGTIssue`
**Purpose:** PowerShell module for GitHub Issue Automation
**Runtime:** PowerShell 7 (pwsh) — cross-platform: Linux, macOS, Windows

---

## Project Structure

psGTIssue/
├── src/
│ ├── Classes/ # PowerShell classes
│ ├── Private/ # Private (internal) functions
│ ├── Public/ # Public (exported) functions
│ └── psGTIssue.psm1 # Module root — dot-sources all classes, private, public
├── tests/
│ ├── Unit/ # Pester unit tests mirroring src/ structure
│ └── Integration/ # Integration tests (optional)
├── build/ # Build output and scripts
│ └── psGTIssue.psd1 # Module manifest (generated or maintained here)
└── CLAUDE.md


---

## Coding Conventions

### Naming

- **Variables:** camelCase — `$issueTitle`, `$repoOwner`, `$pageNumber`
- **Parameters:** camelCase — `param([string]$issueTitle)`
- **Classes:** PascalCase — `class GitHubIssue`, `class IssueFilter`
- **Functions:** Approved PowerShell verb + PascalCase noun — `Get-GtIssue`, `New-GtIssue`, `Set-GtIssue`, `Remove-GtIssue`, `Invoke-GtIssueAction`
- **Private functions:** same verb-noun convention, not exported — `Get-GtApiHeader`, `ConvertTo-GtIssueObject`
- **Constants / enum values:** camelCase

### Approved Verbs

Always use verbs from `Get-Verb`. Common ones for this module:
---

Now, we can create the project structure. First, create the project skeleton. Use a prompt such as Create the project structure and Claude will scaffold folders, a .psd1 manifest, a .psm1 module file, a build.ps1 script and Pester test stubs.

"Create a public function that list all issue for a given repository, param are repository, organization name and a switch all, open, close"

Now we can create a function that list all issue for a repository

The agent will create several files, a function to call the GitHub API, a function to retrieve all issues in the repository and test files.

You see that the prompt used are optimised to create a function, the prompt should be optimised to get the result. If you want a modification, you should be precise on the result you want.

For example, using a switch for the parameter $State is not a great idead
We can ask Claude to replace the switch parameter in the Get-GtIssueList to a simple validateSet parameter with All, Open, Closed.

"replace the switch parameter in the Get-GtIssueList to a simple validateSet parameter with All, Open, Closed in the
@psGTIssue\src\Public\Get-GtIssueList.ps1"

You can work directly on a file work by using @ here @psGTIssue\src\Public\Get-GtIssueList.ps1 it will cost less in token as Claude will not have to search for the file.

Now it is time to check the status of the session with /context. The command will show the percentage used by the session. If the number is higher than 60% you should run the command /compact
It is a good practice to name the session (and its context) so you can retrieve it later.

/rename buildGitHubIssuePwSh

To restart the session

claude --resume "buildGitHubIssuePwSh"

Review generated code carefully. Common issues: the agent may prefer Write-Verbose over Write-Debug, and it might scaffold a .psm1 that dynamically dot sources files at runtime. For best practice a static .psm1 that explicitly imports and exports functions and classes is better; this improves readability, testability and module loading behaviours.

You can encode these conventions in CLAUDE.md, but they’re generic PowerShell best practices you’ll want in every project.

Claude Code supports skills; reusable instruction sets that tell the agent how to behave in specific contexts. Create a PowerShell module skill to enforce coding conventions, file layout and test patterns across projects.
All you need to do is to create a folder in .claude/skills/ and create the file SKILL.md.

You can ask Claude for that

"Create the folder ./claude/skills/powershell-module at the root and add the file SKILL.md"

Claude will create the file for you with some elements

  - Trigger conditions for when the skill applies
  - Naming conventions summary
  - Function templates (public & private)
  - Class template
  - Module dot-source order
  - API call rules
  - Pester test patterns
  - File placement checklist

You can add an header

--- 
name: powershell-module 
description: conventions and guidelines for building PowerShell modules
argument-hint: "[check|fix]" 
---

And information about write-verbose and write-debug and psm1 generation.

### write-verbose?/write-debug?
- Use `Write-Verbose` for informational messages that may be helpful for debugging but are not critical to the user, only visible when the `-Verbose` switch is used. 
- Use `Write-Debug` for detailed debugging information that is typically only relevant when troubleshooting specific issues. This can be enabled with the `-Debug` switch when running the function.
- Avoid using `Write-Host` for regular output; reserve it for special cases where you want to display colored or formatted output directly to the console. For standard output, return objects or use `Write-Output`.

### psm1 file 
- The `.psm1` file should contain all individual functions and class files, and the `Export-ModuleMember` call to specify which public functions are exported. The build script will handle the creation of the `.psm1` manifest file, so you do not need to create that manually.
- All actual code (functions, classes) should live in separate `.ps1` files under the `src/` directory, organized into `Public`, `Private`, and `Classes` subdirectories.

Once conventions live in a skill, you can simplify CLAUDE.md and rely on the skill for enforcement. Skills are shareable, store them in a repo so your teams can reuse the same conventions and templates.

Another way to extend Claude Code is to use sub-agent. Sub-agent is a separate agent that use its own context (it doesn’t impact your session) specialised in one task. The task must be specific and should not be related to any other task in your current session.

Agents are located inside ./claude/agents folder.

We can ask Claude code to create the agent

Create the folder ./claude/agents/ at the root and add the file security-check.md

Claude will create the markdown file with some security check; you can review them and add your own check.

You can run the check

Start security check with the sub agent security-check

Claude will produce a report in the terminal you can review and then act on it.

Claude Code is a powerful agentic coding tool; it lets you manage a team of coding agents as if you had human collaborators. That power demands discipline: be precise in your briefs, test outputs, and maintain human oversight. Agents can produce useful code quickly, but they also make mistakes; you must validate, adapt, and own the result.

In short

Core commands and session hygiene

/init — generate CLAUDE.md from an existing repo.
/context — show token usage (monitor session memory).
/compact — reduce context when usage is high.
/rename — name the session for later resume.
claude --resume "" — resume a named session.
1st rule of Claude: compact when usage approaches 60–80% of context capacity.

Project files

CLAUDE.md — project brief (goals, constraints, runtime, conventions).
.claude/skills/powershell-module/SKILL.md — reusable PowerShell conventions and templates.
.claude/agents/ — sub‑agents for isolated tasks (security, linting).

Will AI Replace Your Job? A Practical Guide for Devs and Cloud Engineers

Olivier Miossec — Fri, 06 Mar 2026 18:28:55 +0000

The hot question today is: Will AI take my job? Headlines about mass layoffs and viral posts claiming an entire team can be replaced with a single prompt make the fear feel immediate. Scrolling LinkedIn or Twitter, you see dramatic claims and quick takes.

Many of those claims are exaggerated, for now. Companies cut headcount for many reasons: cost, restructuring, strategic shifts, and sometimes, "AI" is just a convenient narrative. Dismissing AI as a simple chatbot hype is also a mistake. The reality is that AI, mostly agentic AI, will change our relationship with work and how enterprises create value.

Agentic AI is real, and some roles will be replaced, just as roles shifted during the Internet, SaaS, and cloud revolutions. In this post, I’ll try to identify which roles are most at risk, suggest ways to protect and reskill yourself, and show how AI can create new opportunities. Like past technological revolutions, Agentic AI will destroy some roles, like steam trains removed the need for diligence, but it will create others.

Generative AI is a powerful tool that can process texts based on general knowledge. It excels at producing and transforming text-based artifacts: contracts, job descriptions, support tickets, documentation, and code. Agentic AI goes further by orchestrating workflows and subtasks autonomously. If your role is primarily about following a strict, repeatable process to produce standardized outputs, an agent can often do it faster and cheaper.

Examples include analysts, consultants, HR processes, and other roles where a defined input yields a standardized output. Developers face partial automation too: AI can generate boilerplate code, tests, and scaffolding quickly. Accounting and routine financial reporting are vulnerable. Many managerial tasks, such as synthesizing and distributing information from up and down, can be automated or augmented.

We already see concrete examples of agentic systems accelerating decision cycles. In high-stakes contexts, automated analysis of multiple data sources can reduce days of work to minutes. Similar acceleration is appearing in HR workflows and financial analysis, where agents aggregate, filter, and summarize large datasets. In the current war in the Middle East, the Pentagon is using agentic AI to analyze multiple data sources to make decisions.

If your role is primarily execution, producing outputs from well-defined and static processes without having to make any design or judgment, it’s at high risk of automation. Execution can be delegated to agents cheaply. It scales much more than humans can do. Does that mean you’ll lose your job? Not necessarily.

Generative AI is powerful but limited: it doesn’t make value judgments, exercise domain judgment, or possess taste. Those human skills, judgment, critical thinking, navigating ambiguity, domain expertise, and taste, become stronger differentiators in an AI-augmented workplace.

Be proactive: learn how AI works beyond the surface of simple prompts. You don’t need to be an expert or LLM engineer, but you should understand core concepts, how models generate text or images, what tokens and context windows are, and how parameters like temperature affect output. It will help you to have a better vision of what generative AI can do, cannot do, and why hallucinations happen.

Get hands-on with agentic AI platforms and tooling. Explore multiple ecosystems (Anthropic, OpenAI, GitHub Copilot, and others) and experiment with APIs, MCP, agent orchestration, and observability. Use vendor resources and community tutorials to build practical experience.

To learn more about the Anthropic ecosystem, you can use these courses published here

You can also learn GitHub Copilot CLI, it is for developers, but you can try to learn it with this beginner course (if you want to learn more, this page will be useful).

You may also try on local AI tool, where you can use a model on your local device. A good start is to set up Foundry local (https://learn.microsoft.com/en-us/azure/foundry-local/get-started?view=foundry-classic).

You can also try any other alternative AI tools, for example, Mistral AI (https://mistral.ai/products/studio).

Don’t wait for corporate training. Start learning on your own and build demonstrable projects. Early adopters will have an advantage over peers who delay.

Don’t be desperate, AI will also create new roles. Here are practical examples of emerging job categories where human expertise will remain essential:

Agent governance and compliance, to add policies, audit data access, and permissions for agents.
AI debt management, to identify, track, and remediate risks from unsupervised agent usage.
Agent developer/integrator, for designing, building, and maintaining task-specific agents and orchestrations.
Data discoverability and indexing, to ensure agents can reliably find and use the right data (the “AI SEO” problem).
AI-assisted code reviewer/verifier, for validating code produced by agents and ensuring security, correctness, and maintainability.
Token and cost optimization engineer for minimizing inference costs and optimizing model usage patterns.
AI infrastructure engineer, to deploy and operate compute resources, networking, and observability stacks for agentic workloads.

These are predictions,s and I may be wrong. But like past revolutions, agentic AI will eliminate some roles and create new ones, often in places we don’t yet fully anticipate. Things about the Steam train, it revolutionized the world of transportation and the economy.

AI will reshape work, but it won’t simply “replace” people overnight. Tasks that are repeatable and execution focused are most at risk; judgment, design, domain expertise, and governance remain human strengths. The practical strategy for engineers is clear: learn how agents work, build hands-on experience, and pivot toward roles that require oversight, orchestration, and measurable impact. Those who combine technical fluency with judgment and governance skills will be best positioned in this new tech revolution.

When AI Agents Meet Wall Street: Why Markets Overreact and what Engineers Should Prepare For

Olivier Miossec — Sat, 28 Feb 2026 12:28:00 +0000

An economic bubble occurs when asset prices detach from long term fundamentals and are driven instead by irrational exuberance and social contagion.

Since 2025 we’ve seen that pattern again: mass layoffs, elevated valuations, and extreme market volatility, all of this are tied to the AI narrative.

Let’s try to analyse what happens and see if we can define a strategy for us, engineer.

Last year major tech firms, Meta, Amazon, Microsoft and others, announced mass layoffs totalling roughly 200,000 roles. Publicly, the rationale was the rise of AI: many positions will be automated or restructured around AI capabilities.

There is some truth in this reason, but this is not the main reason. To get the main reason, take a lot on what these companies are doing with their investments.

There’s truth in that claim, but it misses the main driver. Look at where these companies are investing infrastructure, chips, datacentres and energy capacity. It is not just about chatbots.

They’re not just chasing chatbots; they’re preparing for an agentic AI world. Training large models consumes massive energy, while inference, asking something, is far cheaper. The real shift is the infrastructure needed to run persistent, autonomous AI agents at scale.

Agentic AI is not like Chatbot: agents such as Claude CoWork operate autonomously, executing tasks without continuous human input; managing email, CRM workflows, scheduling, and more. Once created, an agent can remain active and consume resources while completing its tasks.

The capacity required is colossal: servers, accelerators, datacentre space, networking and power provisioning at scale.

To build that capacity companies must invest heavily; buying accelerators (e.g., NVIDIA GPUs), networking devices and datacenter capacity, and securing power contracts. That capital commitment helps explain why some firms reallocate headcount toward these investments.

It is capital reallocation, laying off people to build AI capacity, I can’t say it is fair or normal. But this is very rational.

What’s less rational is the market’s reaction to agentic AI in 2026. Agents differ from chatbots: the value proposition is task execution, not prompt finesse. An agent combines an LLM, tool access and autonomy, but that doesn’t mean it instantly replaces entire software categories.

In January Anthropic launched Claude CoWork, an agent that handles non technical tasks locally (initially macOS only): files, email, calendar, and deliver artifacts like spreadsheets and text summaries.

Claude CoWork wasn’t the first agentic solution, but it was the first to capture broad public attention. Anthropic developed it after customers used Claude Code for non coding tasks; managing email, expense reports and file organization, demonstrating real demand for delegated AI automation.

Soon after CoWork’s general availability, several SaaS and enterprise software stocks, like Salesforce, SAP or Adobe, saw a large market declines, contributing to a broader sell off in software. The MSCI Software & Services index fell significantly in early 2026.

The market appears to be pricing a future where AI agents displace some SaaS functionality. That view is optimistic and only partially rational, because agents may complement rather than fully replace many enterprise apps in the near future.

What’s coming next is surprising. Markets moved into irrational territory. On 20 February Anthropic published a blog post suggesting Claude Code could assist with static code analysis. It is just a concept, not a shipped product or roadmap. Yet cybersecurity stocks, from niche vendors to large firms like Palo Alto and CrowdStrike, tumbled in response.

On 23 February another Anthropic post suggested agents could assist with modernizing COBOL code, again a concept. Consulting firms and legacy technology vendors saw market pressure as investors extrapolated far beyond the announcement.

This is the irrational zone: a static analysis capability cannot replace entire cybersecurity teams, runtime scanners, or the complex processes that govern legacy banking systems. The market is reacting to buzzwords without understanding the engineering and operational realities behind the headlines.

Sound familiar? It echoes the dot com bubble, when a single buzzword in a press release could inflate a stock. The mechanism is the same: narrative driven speculation divorced from technical substance.

It’s easy to laugh, but boards will react. A sudden market signal can pressure executives to “do AI”, sometimes by reallocating resources toward visible AI projects at the expense of core capabilities like cybersecurity.

We may be in a feedback loop where irrational market moves trigger irrational corporate responses. As engineers, remember that AI is a tool, a powerful tool, but only a probabilistic predictor that generates text, code or images. It does not make value judgments or replace human decision making.

Strategy for engineers: learn agentic AI, not just prompt engineering, but how agents are built, orchestrated and monitored. Master relevant tools and workflows (e.g., agent orchestration, observability and safety patterns). AI will also create new roles; those who understand agentic systems will be better positioned.

And of course, there will be soon some AI tools that could complete the cybersecurity landscape, but it will be a real product, with verifiable, measurable and concrete results.

What is wrong with LinkedIn in the age of AI

Olivier Miossec — Wed, 11 Feb 2026 11:02:06 +0000

Like everyone in tech, I utilize LinkedIn to manage my professional network, showcase my work, and maintain visibility to recruiters. LinkedIn is central to professional life and has no real competitor.

Not long ago, I had a strange experience: a stream of posts about an Azure networking change. Nothing unusual, this kind of post floods my LinkedIn every week, but here, there was a tiny but consequential error. The update stated that the change would occur on 30 September 2025, yet the posts were dated December 2025. Everyone was warning readers to act on a change that, in reality, was scheduled for 31 March

This is where we are now: a lot of noise on a professional network. That noise is amplified by conformity. People avoid friction and rarely post dissenting views. The result is a chorus of similar takes that can feel caricatural; sometimes the most viral LinkedIn posts end up as jokes on Twitter or Reddit, and some have become famous memes.

This Mediocrity is only part of the problem on the platform. Much of LinkedIn is declarative and unverified: anyone can claim to be a Rust or Go expert simply by writing it. You can be a brain surgeon if you want; you only need to edit your profile. The platform is full of inflated titles and grandiose claims that often bear little relation to reality.

That’s bad news for job seekers. Recruiters must wade through noise and exaggerated titles before they even reach your profile. By the time they find you, they still don’t know whether your résumé is accurate or just inflated.

There is a lot of friction before reaching your profile. A potential recruiter will need to navigate through all the noise, do some research, and maybe find you. But at this point, the recruiter will have no idea if your profile is valid or if it is just an inflated one.

The recruiter needs to navigate to LinkedIn, like you do when trying to find a job. It’s often frustrating. The probability that a recruit will find you is limited.

LinkedIn’s interface, like any computer interface, is designed for humans to navigate into the complexity of data, to control their behaviours, and authorize access.

The interface is going to be disrupted by Artificial Intelligence. Agentic AI are systems that can autonomously plan, make decisions, and take actions to achieve goals without human direction, and can now replace some work tasks, including finding profile.

AI Agents do not have time to lose scrolling a feed on the interface; they work on raw data. When a recruiter instructs an agent to find an Azure architect skilled in Bicep and Terraform, the agent won’t scroll through posts and buzzwords. It will search raw, verifiable artifacts; GitHub and GitLab repositories, blog posts, published articles, … These are concrete and verifiable artifacts to spot the perfect profile.

In this agentic recruitment world, LinkedIn becomes secondary. It will be useful for correlation, but the primary sources will be your public artifacts: documented side projects, repositories, PRs and issues, and technical blog posts. Those are the things agents can verify and score.

To facilitate the AI, you should group them on a single page visible from GitHub, Twitter and LinkedIn. A personal brand API that automatically lists your original blog posts, your public repos, your PR, and your contributions. This will be your new AI era visit card.

LinkedIn still matters for human networking and visibility, but the rise of agentic hiring shifts the signal to verifiable, AI-readable artifacts. Start publishing concrete work and make it easy for agents to find and verify.

Azure Machine Configuration, Linux, and DSC Configuration

Olivier Miossec — Tue, 13 Jan 2026 22:03:23 +0000

I recently made a post about Azure Machine Configuration and PowerShell DSC, and how to deploy VM configurations as infrastructure as Code, just like the rest of your infrastructure.

But in this post, I focused mainly on Windows configuration and wrote almost nothing about Linux.

However, Azure Machine Configuration is also available for Linux VMs, where you can use DSC or Chef InSpec.

To run DSC configurations, VMs need to have the AzurePolicyForLinux extension and a managed identity.

But unlike Windows, most Linux VMs don’t come with PowerShell installed. To solve this problem, the AzurePolicyForLinux extension installs PowerShell in a Folder but doesn’t modify the Path of the VM. PowerShell can only be used by the policy.

The next step is to write a DSC configuration. There are many DSC resources for managing Windows, but to manage a Linux server, you will need a compatible DSC resource. The most advanced is the NxTools module. It is the recommended version to use with the Azure Machine configuration.

The NxTools module is a POSIX wrapper for several Linux commands and includes several DSC resources.

nxFiles, to manage files and folders
nxGroup, to manage groups and group membership
nxUser, to manage users
nxPackages, to manage packages (support only apt)
nxService, to manage service (only system)
nxScript, to execute scripts in DSC configurations

To demonstrate DSC on Linux with Azure Machine Configuration, let's ensure the user devTo is created and added to the group publisher, and a file with specified content is created using a script resource.

configuration demoDSCLinux
{

    Import-DscResource -ModuleName 'nxtools'


        nxUser ensureDevToUser {

            Ensure =  'Present'
            UserName =  'DevTo'
            FullName = 'Dev To Demo user'
            HomeDirectory = '/home/DevTo'
            Description = 'Ensure that DevTo user is present on the system'
        }

        nxGroup ensurePublishersGroup {
            # the group must be present and have root as only member
            Ensure =  'Present'
            GroupName =  'publishers'
            Members = @('DevTo')
        }

        nxScript ensurePublisherfilePresent {
        GetScript = {
            $Reason = [Reason]::new()
            $Reason.Code = "Script:Script:FileMissing"
            $Reason.Phrase = "File does not exist"

            if (Test-Path -Path "/home/DevTo/publisher.txt")
            {
                    $Reason.Code = "Script:Script:Success"
                    $Reason.Phrase = "File exists"
            }

            return @{
                Reasons = @($Reason)
            }
        }
        TestScript = {
            if (Test-Path -Path "/home/DevTo/publisher.txt")
            {
                return $true
            }
            else
            {
                return $false
            }
        }
        SetScript = {
            $null = New-Item -Path "/home/DevTo/publisher.txt" -ItemType "File" -Force
        }
        }

}

The first two resources create the DevTo user and create the Publishers group, and add the DevTo user.

The last one ensures that the file "/home/DevTo/publisher.txt" is present on the system using a nxScript resource. The GetScript block of the resource needs to return a Hashtable with a Reason object to work. The reason.phrase will be shown in the Azure Portal in case of noncompliance.

If you try to compile this configuration on your Windows or macOS machine, you will get an error; you need a Linux VM with PowerShell.

You can set up a dev VM for that, but you can also use a CI/CD pipeline to compile and package the configuration for Linux. You can also compile and package the DSC configuration in GitHub Actions.

First, you will need a script for compiling the configuration and creating the Azure Machine Configuration package.

# Check if the host is a Linux system

if ($IsLinux -eq $false) {
    Write-Error "This script must be run on a Linux system."
    exit 1
}

# install modules 
Install-Module -Name nxtools -Force
install-module -name PSDesiredStateConfiguration -RequiredVersion 3.0.0-beta1 -Force -AllowPrerelease
install-module -name GuestConfiguration -Force -RequiredVersion 4.1.0 

# compile the demo configuration

. ./DSC-Linux/demolinux.dsc.ps1

demoDSCLinux

# rename the MOF file 

Rename-Item -Path .\demoDSCLinux\localhost.mof -NewName demoDSCLinux.mof -Force 

# create the package for Azure Machine Configuration

New-GuestConfigurationPackage -name "demoDSCLinux" -Type AuditAndSet -Configuration .\demoDSCLinux\demoDSCLinux.mof -Force $true

The first line of the script tests if the host is a Linux machine. The configuration can only be created on Linux.

Then the script imports all the necessary modules, nxtools for the DSC resources, PSDesiredStateConfiguration for DSC, and GuestConfiguration to package the configuration.

It then compiles the configuration and packages it. The package can then be deployed to a Linux VM with Azure Machine configuration.

Overview of Azure Service Groups (public preview)

Olivier Miossec — Tue, 02 Dec 2025 20:38:03 +0000

In an Azure tenant, you use management groups to organize subscriptions. In that hierarchy, you can define access controls and apply policies.

When resources for a single workload are deployed across multiple subscriptions, management becomes more complex. Azure Service Groups help by allowing you to group resources without moving them.

A Service Group is a logical container that groups resources across subscriptions and resource groups while leaving each resource in its original subscription. You can manage that collection from within the management group hierarchy.

An Azure Service Group is a logical container, similar to a resource group, a subscription, or a management group, but completely separate from the last ones. Service Groups organize resources across subscriptions, resource groups, and management groups without moving these resources. It stores metadata used to identify workloads, track state, and manage processes.

Suppose your networking team manages gateways, load balancers, and other network services that are deployed across several subscriptions. With Azure Service Group, you can create a service group for these networking resources, add the network resources you need, and apply permissions to people who will manage these resources.

With Azure Service Groups, you can create a service group for those networking resources, add the relevant resources, and assign permissions to the people who manage them. Users assigned the Service Group Reader role can view the service group and its child resources.

You also get an inventory of resources in the service group, a list of issues affecting those resources, application maps, and availability tests (if Application Insights is linked), and monitoring recommendations and coverage for VMs and AKS.

Each Service Group requires a unique global name (similar to a storage account; up to 250 characters). Service Groups form a hierarchy: you can create a Service Group at the top level (under the Tenant Root Service Group) or as a child of another Service Group.

You can create a Service Group and associate resources using the Azure Portal or the Azure REST API. There is no dedicated PowerShell cmdlet or Azure CLI tool for the moment.

Below is an example that creates a Service Group and associates a resource using Bicep. (Note: you can also use ARM templates or the REST API.)

Creating a Service Group and associating a resource in Azure Bicep.

param serviceGroupId string
param parentServiceGroupId string
param serviceGroupName string 
param storageAccountName string

resource serviceGroup 'Microsoft.Management/serviceGroups@2024-02-01-preview' = {
  scope: tenant()
  name: serviceGroupId
  properties: {
    displayName: serviceGroupName
    parent: {
      resourceId: '/providers/Microsoft.Management/serviceGroups/${parentServiceGroupId}'
    }
  }
}

resource storageAccount 'Microsoft.Storage/storageAccounts@2025-06-01' existing = {
  name: storageAccountName
}

resource rel1 'Microsoft.Relationships/serviceGroupMember@2023-09-01-preview' = {
  scope: storageAccount
  name: 'childResource1'
  properties: {
    targetId: serviceGroup.id
  }
}

In this example, the service group is created using the Microsoft.Management/serviceGroups at the tenant level. The resource has a name (the ID of the service group) and a display name. It has a parent, either the root service group or another service group.

For associating a resource, a storage account, to the new service group, the Microsoft.Relationships/serviceGroupMember is used. You need a reference of the resource in the scope property.

To get this reference, I use the Existing keyword in bicep to access the resource property without deploying it again.

The scope property in the Microsoft.Relationships/serviceGroupMember don’t take a resourceID in Azure Bicep for the scope property. But ARM template allows it on the same scope property.

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "storageAccountName":  {                 
            "type": "string"
        }, 
        "storageAccountRG":  {                 
            "type": "string"
        }, 
        "storageAccountSubID":  {                 
            "type": "string"
        }, 
        "targetServiceGroupResourceID":  {                 
            "type": "string"
        }
    },
    "variables": {},
    "resources": [
                 {
                    "type": "Microsoft.Relationships/serviceGroupMember",
                    "apiVersion": "2023-09-01-preview",
                    "name": "[concat('rel-', parameters('storageAccountName'))]",
                    "scope": "[resourceId(parameters('storageAccountSubID'), parameters('storageAccountRG'), 'Microsoft.Storage/storageAccounts/', parameters('storageAccountName'))]",
                    "properties": {
                      "targetId": "[parameters('targetServiceGroupResourceID')]"
                    }
                  }
    ],
    "outputs": {}
}

Service Groups are in public preview, so APIs and tooling may change before general availability. Still, it’s worth evaluating the feature now if you manage medium or large Azure tenants.

Install and use the Microsoft Learn MCP server in VS Code

Olivier Miossec — Mon, 10 Nov 2025 20:07:46 +0000

This short guide shows how to install and use the Microsoft Learn MCP server inside Visual Studio Code so you can query official Microsoft documentation and code samples directly from your editor.
You will need a VS Code installation with the latest updates, Internet and permission to install extensions.

VS Code allows you to use MCP servers. An MCP server (Model Context Protocol server) is a small service that exposes tools and data to AI agents. Instead of returning only text, it can call real functions such as reading web pages or querying documentation and return structured results that the editor can use.

As a cloud platform engineer or operator, you often switch between an editor and a browser to look up docs, examples, or snippets. The Microsoft Learn MCP server brings official docs and code samples into VS Code, so answers and examples appear where you work.

To activate the MS Learn MCP server in VS Code, go to “Extensions” (or CTRL + Shift + x) and then type @mcp
You will have to enable the “MCP server marketplace” if it is the first time you do that.

Then search for the Microsoft Learn MCP server.

And then click on install. You now have access to the service.

To start using the MS Learn MCP server, open the AI shell with [Ctrl + Shift + I] in VSCode.

Make sure you are in “Agent” mode in the chat windows.

For more context, I open a PowerShell file, then I can type the prompt:

Give me an example of PowerShell code to create a VNET use microsoft_code_sample_search

The chat provides a sample code based on the MCP server.
We can do the same with Azure Bicep.

How can I add the private subnet option to a subnet resource in Bicep? Use the microsoft_code_sample_search feature, which will provide a sample in Bicep.

If you need to know more about the private subnet feature, you can use the MCP tool, microsoft_docs_search, to query Microsoft Doc.

using microsoft_docs_search, explain the features of private subnets in an Azure VNet

There is another useful tool in the MCP server, microsoft_docs_fetch, which can take a Microsoft Doc page and put it in a Markdown format.

microsoft_docs_fetch https://learn.microsoft.com/en-us/azure/expressroute/resiliency-insights

It is very useful when you are working on a documentation or on a script, you can have the Microsoft Documentation inside your editor.

The MS Learn MCP server is an excellent introduction to the world of AI-assisted programming. It can help you solve a problem, reduce the number of tabs open in your browser, and be more efficient while working with VSCode.

Azure Bicep: Extension and local deploy

Olivier Miossec — Sun, 19 Oct 2025 06:28:28 +0000

Bicep was created with a single goal: to simplify Azure resource deployment. Instead of writing verbose JSON, Bicep gives us a cleaner, more concise way to define infrastructure.

But here’s the catch: like most Infrastructure as Code (IaC) tools, Bicep traditionally only deploys Azure resources. Modern deployments often require more than that; they need configuration tasks, data plane actions, or external integrations. The result? You end up gluing together multiple scripts in your pipeline, breaking the IaC promise of having a single source of truth.

This is the purpose of Extension in Bicep. Extension is about doing things beyond the Azure Resource Manager.

How does it work? When a Bicep template is published, the Azure Resource Manager API determines if a resource coded in the template should be deployed (like a storage account) or if another API should be used (like the Graph API for Entra resource).

I already talked about the Azure Graph API for Bicep extension. This extension is generally available.

For an extension to work, the Azure Resource Manager API needs to be able to contact an external API. This is a huge limitation. Extensions must live inside the Azure ecosystem. This is the case for the Microsoft Graph and the Kubernetes extensions. Anything else was impossible.

But with the Bicep Local deploy, experimental feature deployment occurs on the local devices without interacting with the Azure Resource Manager API.
Local Deploy is a new experimental feature; you need to update your Bicep CLI (at least v0.30) to use it.

There are already several extensions available; you can use them to make HTTP calls, manage GitHub or Azure DevOps, create passwords, execute scripts locally, and other things.

You can get more information on these GitHub pages bicep-extensions and Bicep GitHub Doc.

You can also create your own extension (but it is beyond the subject of this post), check this and this post

For this post, I will use two extensions, [bicep-ext-local}(https://github.com/anthony-c-martin/bicep-ext-local) to run scripts and bicep-ext-PassWordGenerator (https://github.com/anthony-c-martin/bicep-ext-local) to generate random passwords.

Keep in mind that local extensions run on the device where the Bicep code is executed. You need to check if the extension is compatible with your OS (Windows and Linux ARM may not be available).

To use these extensions and the local deploy feature, the Bicep configuration must be updated. A bicepconfig.json file needs to be created in the same folder (or a parent folder) of the bicep files. You can check the documentation on this page.

We need to indicate Bicep to use the experimental local deploy feature and which extension to use. But also, as we need to manipulate passwords and want to print them for the demonstration, Bicep will return a warning (outputs-should-not-contain-secrets). The linter should be modified to avoid this warning.

the bicepconfig.json file

{
  "experimentalFeaturesEnabled": {
    "localDeploy": true
  },
  "extensions": {
    "PassWordGenerator": "br:bicepextsys4opsacr.azurecr.io/extensions/passwordgenerator:0.1.0",
    "local": "br:bicepextdemo.azurecr.io/extensions/local:0.1.3"
  },
  "analyzers": {
    "core": {
      "rules": {
        "outputs-should-not-contain-secrets": {
          "level": "off"
        }
      }
    }
  }
}

The BicepConfig file allows to use of the experimental feature, use the two extensions (passwordgenerator and local), and change the linter to not show a warning when a password is used in the output.

The Bicep code used (main.bicep)

targetScope = 'local'

extension PassWordGenerator
extension local

resource password 'GeneratedPassword'  = {
  name: 'pass'
  properties: {
    includeLower: true
    includeUpper: false
    includeDigits: true
    includeSpecial: false
    passwordLength: 20
  }
}

resource sayHelloWithPowerShell 'Script' = {
  type: 'powershell'
  script: replace(loadTextContent('./pwshscript.ps1'), '$input', 'dev.to')
}

output sayHelloWithPowerShell string = sayHelloWithPowerShell.stdout
output password string = password.output

The first thing to notice is the TargetScope statement. The value, local, indicates that local deploy will be used. Without enabling it in the bicepconfig file, it will generate an error.

As you can only have one TargetScope statement in a deployment, including linked modules, you can only deploy locally.

The two extension statements import the extension defined in the bicepconfig file.

Then we have the two resources, the password and the script.
The first one generates a random 20-character string in lowercase, the second one executes a script, pwshscript.ps1, in the same folder.

Write-Host "Hello from Bicep $($input)"

If you try to deploy the template, like any other template using Azure CLI or Azure PowerShell, you will get an “InvalidTemplateDeployment “error.

"details": [ 
{ 
"code": "UnknownExtension", 
"message": "Unknown extension 'PassWordGenerator'.", 
"target": "/resources/password" 
}, 
{ 
"code": "UnknownExtension", 
"message": "Unknown extension 'Local'.", 
"target": "/resources/sayHelloWithPowerShell" 
} 
]

To use local deploy, the latest version of Bicep CLI is needed. The command to use is:

bicep local-deploy <PathToBicepParamFile>

You need to provide a bicep parameter file and not the path to the bicep template.
In the same directory as the Bicep template, main.bicep, and the PowerShell script pwshscript.ps1, we need a main.bicepparam file.

A bicepparam file defines values of parameters, but the template doesn’t have any parameters; it only needs to have a using close referencing the main.bicep.

using 'main.bicep'

Running bicep local-deploy produces this output

password │ 5gmj6e7qrxktvxsuzakr
sayHelloWithPowerShell │ Hello from Bicep

Local Deploy is still experimental and limited, but it’s a big step forward. Combined with extensions like Microsoft Graph, it reduces the need for configuring resources or managing data plane and makes Bicep a true central point for both infrastructure and configuration.

Azure Networking: Expanding Subnets with Multiple Prefixes without Downtime.

Olivier Miossec — Tue, 23 Sep 2025 21:04:21 +0000

In Azure, a subnet has a single address prefix, a part of your Virtual Network (VNet) address space. This works fine until your workloads outgrow the available IPs. Traditionally, the fix meant creating a new subnet and moving resources, often causing downtime. Now, Azure has introduced a multiple-prefix subnet feature that lets you expand capacity without redeploying.

Sometimes, your subnet prefix is too small and doesn’t fit your needs anymore. In many situations, it is not a problem.

Think of a subnet as a logical grouping of virtual network interfaces (vNICs) that share the same network policies, like Network Security Groups (NSGs), NAT Gateways, and route tables. Within the same VNet, vNICs can communicate directly, regardless of which subnet they’re in. Adding a new prefix to the VNET and creating a new subnet will be enough to overcome the shortage of IP addresses in the first Subnet.

But with stateful or large-scale deployments, like Virtual Machine Scale Sets (VMSS), IP exhaustion can be painful. Redeploying VMSS into a new subnet means downtime, scaling delays, and potential customer impact.

Fortunately, a new feature in Azure Virtual Network allows you to add a new prefix to a subnet. This feature is only available in PowerShell, Azure CLI, ARM Template, and Bicep.

Let’s take an example: an application needs an Azure SQL Database, a load balancer, and 10 to 15 VMs with the application. To ease the deployment, VMSS with the flexible orchestration mode.

You create a VNET for the application, with the 192.168.0.0/24 prefix. Within this VNET, two subnets are created, one for the private endpoint of the Database, 192.168.0.0/29, and one for the VMSS and the LB (192.168.0.128/27). The last prefix has enough IP addresses to support scaling operation (27 free IPs).

Everything works perfectly until the marketing team announces that the application will be presented on social media and TV, so you need to increase the capacity at least sixfold, which means at least 90 VMSS instances or a /25 prefix.

There are two solutions:

Create a new subnet and move the VMSS. This is the default solution until now, but a downtime is needed.
Add a prefix to the existing subnet. This is the new feature.

A /25 prefix is needed, but to avoid any disturbance while scaling, a /24 is better. A new prefix will be added to the VNET and then to the subnet.

The multiple-prefix feature is currently supported via PowerShell, Azure CLI, ARM templates, and Bicep. The Azure portal is not supported. Below is a PowerShell example to expand a subnet without downtime.

The first step is to update the Azure PowerShell module.

Update-Module-NameAz-Force

After that, a new /24 prefix needs to be added to the current VNET.

$vnet= Get-AzVirtualNetwork -Name <VnetName> -ResourceGroupName <ResourceGroupName>
$vnet.AddressSpace.AddressPrefixes.Add("192.168.1.0/24")
Set-AzVirtualNetwork-VirtualNetwork $vnet

After that, we can add the new prefix to the subnet.

$vnet=Get-AzVirtualNetwork -Name <VnetName> ResourceGroupName <ResourceGroupName>
Set-AzVirtualNetworkSubnetConfig -Name'APP' -VirtualNetwork$vnet-AddressPrefix '192.168.0.128/27','192.168.1.0/24'
$vnet|Set-AzVirtualNetwork

The subnet has been updated. If you take a look at the Azure Portal, you will get:

You can see that Azure reserves the first three available IP addresses of each prefix for internal use.

However, you will have no option to manage this from the portal.

But you can also manage multiple prefixes in a subnet using Bicep and ARM templates. You will need to use at least the 2018-08-01 API version to use the property called addressPrefixes. This property uses an array of strings as a value.

In ARM/Bicep, the addressPrefixes property accepts an array of CIDR blocks. This is what enables multiple prefixes. You can still use addressPrefix for single values, but mixing the two in the same resource definition isn’t allowed.

param location string = resourceGroup().location


@description('VNet name')
param vnetName string = 'vnet2'

@description('Vnet Address space')
param vnetAddressPrefix string = '10.0.0.0/8'

@description('First Subnet Prefix')
param subnetPrefix1 string  = '10.0.0.0/24'

@description('First Subnet Prefix')
param subnetPrefix2 string  = '10.0.1.0/24'

@description('Subnet1 Name')
param subnet1Name string  = 'sub1'

resource vnet 'Microsoft.Network/virtualNetworks@2024-07-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        vnetAddressPrefix
      ]
    }

  }
}

resource subnet1 'Microsoft.Network/virtualNetworks/subnets@2024-07-01' =  {
  parent: vnet
  name: subnet1Name
  properties: {
    addressPrefixes: [
        subnetPrefix1
        subnetPrefix2
    ]
  }
}

Restrictions for Multiple-Prefix Subnets

No subnet delegation (except VPN/ExpressRoute gateways)
No VNet injection for container services
Primarily supports IaaS workloads (VM, VMSS)

Best Practice: Plan for growth by using addressPrefixes from the start in Bicep/ARM Template. Even if you only need one prefix today, defining it as an array future-proofs your network configuration.

Breaking change in Azure Network

Olivier Miossec — Tue, 15 Jul 2025 04:45:12 +0000

Olivier Miossec

Jun 19 '25

About the implicit outbound connectivity retirement in Azure on 31/03/2026

#azure #networking

Comments

3 min read

[Boost]

Olivier Miossec — Tue, 15 Jul 2025 04:40:07 +0000

Olivier Miossec

May 20 '25

Azure Machine Configuration, deploy DSC config to Azure VMs.

#azure #iac

Comments 2

5 min read

Azure RBAC roles, an advanced introduction

Olivier Miossec — Thu, 10 Jul 2025 18:55:10 +0000

Azure role-based access control (RBAC) roles are essential in any organization to create granular access to resources across subscriptions.

Azure RBAC lets you define your roles, allowing you to create fine-grained permissions that you can’t find in built-in roles.
A custom role is defined by an ID, a name, an assignable scope (such as subscriptions or management groups), a description, and specific permissions. There are several kinds of permission; the most important is “Actions” (it is mandatory when creating a costume role), there are also “noActions”, “DataActions”, and “noDataActions” properties.

“Actions” list what you can do on the control plane of resources. Thinks about all actions on a resource like a virtual machine or a storage action that do not include accessing data. DataActions list what you can do on the data plate of resources, think about what is inside an Azure Key Vault, or data in a storage account.
The purpose of noActions and noDataActions is to remove a permission that is listed in the “Actions” or “DataActions” properties. Because permissions are a hierarchy of actions, starting with a resource type and subtype.
For example, this is the list of all actions for virtual machines

"Microsoft.Compute/virtualMachines/read",
"Microsoft.Compute/virtualMachines/write",
"Microsoft.Compute/virtualMachines/delete",
"Microsoft.Compute/virtualMachines/start/action",                  "Microsoft.Compute/virtualMachines/powerOff/action",
"Microsoft.Compute/virtualMachines/reapply/action",
"Microsoft.Compute/virtualMachines/redeploy/action",
"Microsoft.Compute/virtualMachines/restart/action",
"Microsoft.Compute/virtualMachines/retrieveBootDiagnosticsData/action",
"Microsoft.Compute/virtualMachines/deallocate/action",
"Microsoft.Compute/virtualMachines/generalize/action",
"Microsoft.Compute/virtualMachines/capture/action",
"Microsoft.Compute/virtualMachines/runCommand/action",
"Microsoft.Compute/virtualMachines/convertToManagedDisks/action",
"Microsoft.Compute/virtualMachines/performMaintenance/action",
"Microsoft.Compute/virtualMachines/reimage/action",
"Microsoft.Compute/virtualMachines/installPatches/action",
"Microsoft.Compute/virtualMachines/assessPatches/action",
"Microsoft.Compute/virtualMachines/cancelPatchInstallation/action",
"Microsoft.Compute/virtualMachines/simulateEviction/action",
"Microsoft.Compute/virtualMachines/osUpgradeInternal/action",
"Microsoft.Compute/virtualMachines/rollbackOSDisk/action",
"Microsoft.Compute/virtualMachines/deletePreservedOSDisk/action",
"Microsoft.Compute/virtualMachines/upgradeVMAgent/action",
"Microsoft.Compute/virtualMachines/attachDetachDataDisks/action",
"Microsoft.Compute/virtualMachines/patchAssessmentResults/latest/read",
"Microsoft.Compute/virtualMachines/patchAssessmentResults/latest/softwarePatches/read",
"Microsoft.Compute/virtualMachines/patchInstallationResults/read",
"Microsoft.Compute/virtualMachines/patchInstallationResults/softwarePatches/read",
"Microsoft.Compute/virtualMachines/providers/Microsoft.Insights/logDefinitions/read",
"Microsoft.Compute/virtualMachines/providers/Microsoft.Insights/diagnosticSettings/read",
"Microsoft.Compute/virtualMachines/providers/Microsoft.Insights/diagnosticSettings/write",
"Microsoft.Compute/virtualMachines/extensions/read",
"Microsoft.Compute/virtualMachines/extensions/write",
"Microsoft.Compute/virtualMachines/extensions/delete",
"Microsoft.Compute/virtualMachines/instanceView/read",
"Microsoft.Compute/virtualMachines/providers/Microsoft.Insights/metricDefinitions/read",
"Microsoft.Compute/virtualMachines/runCommands/read",
"Microsoft.Compute/virtualMachines/runCommands/write",
"Microsoft.Compute/virtualMachines/runCommands/delete",
"Microsoft.Compute/virtualMachines/vmSizes/read"

You see that you see the hierarchy (Microsoft.Compute, then virtual machine, then a child resource, and an action or an action).
Because it can be error-prone and boring to write every single permission for virtual machines (about 40 possible actions), you can use a wildcard.
"Microsoft.Compute/virtualMachines/"
You can see here the utility of no action. If you want to give all permissions except one, you can use noAction to remove a permission. For example, if you want to give all actions except "Microsoft.Compute/virtualMachines/runCommands/delete", and "Microsoft.Compute/virtualMachines/extensions/delete", you can add it the the noAction property.
To get all the possible permissions from a resource, you can use PowerShell:
`Get-AzProviderOperation "Microsoft.Compute/virtualMachines//*" | select-object OperationName, Operation, Description`
PowerShell can create a custom role by using a JSON file defining the role.

{
  "Name": "Demo Role 01",
  "Id": null,
  "IsCustom": true,
  "Description": "Allows all actions on VM",
  "Actions": [
    "Microsoft.Compute/virtualMachines/*"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/providers/Microsoft.Management/managementGroups/test-mg"
  ]
}

To create the role
New-AzRoleDefinition -InputFile "./role1.json"

Now, if we want to restrict the role to perform delete operations on VM extensions and runCommands we can add these two actions to the noActions parameter.

 {
  "Name": "Demo Role 02",
  "Id": null,
  "IsCustom": true,
  "Description": "Allows all actions on VM",
  "Actions": [
    "Microsoft.Compute/virtualMachines/*"
  ],
  "NotActions": [
    "Microsoft.Compute/virtualMachines/runCommands/delete", 
    "Microsoft.Compute/virtualMachines/extensions/delete"
  ],
  "AssignableScopes": [
    "/providers/Microsoft.Management/managementGroups/group01"
  ]
}

Now, if a role needs to allow all actions on VMs (Microsoft.Compute/virtualMachines) and VMSSs (Microsoft.Compute/virtualMachineScaleSets), we can add both resources to the "Actions" parameter.

{
  "Name": "Demo Role 03",
  "Id": null,
  "IsCustom": true,
  "Description": "Allows all actions on VM and VMSS",
  "Actions": [
    "Microsoft.Compute/virtualMachines/*",
    "Microsoft.Compute/virtualMachineScaleSets/*"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/providers/Microsoft.Management/managementGroups/group01"
  ]
}

Or use a wildcard on Microsoft.compute

{
  "Name": "Demo Role 04",
  "Id": null,
  "IsCustom": true,
  "Description": "Allows all actions on MS Compute with wildcard",
  "Actions": [
    "Microsoft.Compute/*"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/providers/Microsoft.Management/managementGroups/group01"
  ]
}

This will allow 279 different actions, and that could be a problem. The role created by this JSON file will have every permission possible from the Microsoft.compute service, including actions that may be added in the future. This is the opposite of a fine-grained security policy. It is just like using a medieval axe to perform microsurgery.
By using Microsoft.compute/* alone, I get 279 possible actions. What about using “*/read”? The number is 9840 possible actions! This leaves a place for malicious actions.
But this is the case with some built-in roles, the reader role.

{
    "id": "/providers/Microsoft.Authorization/roleDefinitions/acdd72a7-3385-48ef-bd42-f606fba81ae7",
    "properties": {
        "roleName": "Reader",
        "description": "View all resources, but does not allow you to make any changes.",
        "assignableScopes": [
            "/"
        ],
        "permissions": [
            {
                "actions": [
                    "*/read"
                ],
                "notActions": [],
                "dataActions": [],
                "notDataActions": []
            }
        ]
    }
}

Or User Access Administrator

{
    "id": "/providers/Microsoft.Authorization/roleDefinitions/18d7d88d-d35e-4fb5-a5c3-7773c20a72d9",
    "properties": {
        "roleName": "User Access Administrator",
        "description": "Lets you manage user access to Azure resources.",
        "assignableScopes": [
            "/"
        ],
        "permissions": [
            {
                "actions": [
                    "*/read",
                    "Microsoft.Authorization/*",
                    "Microsoft.Support/*"
                ],
                "notActions": [],
                "dataActions": [],
                "notDataActions": []
            }
        ]
    }
}

Several built-in roles are too permissive. Custom roles, with fewer actions, should be used instead. It can be long and boring, but it will limit your attack surface.