DEV Community: Massimo Bonanni

Book Review: Azure or Developers (third edition)

Massimo Bonanni — Mon, 02 Mar 2026 09:30:00 +0000

Azure for Developers – Third Edition by Kamil Mrzygłód is a mature, well-structured guide that targets a very real need in the Azure ecosystem: helping developers build, integrate, and operate modern cloud applications without turning them into full-time infrastructure specialists .

Unlike many Azure books that either remain too high-level or dive deeply into isolated services, this book succeeds in maintaining a developer-centric perspective across a wide range of Azure application services.

Overall Assessment

This third edition reflects both the evolution of Azure and the author’s practical experience. The content feels current, intentional, and aligned with how Azure is actually used in real-world projects today—especially in environments where developers are expected to care about deployment, security, and operational concerns alongside application code.

The book is not trying to be an encyclopedic reference. Instead, it acts as a guided learning path, which is a conscious and effective design choice.

Strengths

1. Clear developer-oriented scope

The book consistently focuses on application-oriented Azure services: App Service, Azure Functions, Logic Apps, Container Apps, Storage, messaging services, and monitoring. This clarity makes it especially valuable for developers who want to stay productive without being overwhelmed by infrastructure-heavy topics.

2. Strong CLI and automation mindset

A notable strength is the emphasis on Azure CLI, Azure PowerShell, and GitHub Actions. This reinforces modern Azure practices:

Repeatability over portal-driven workflows
Automation-first thinking
Easy transition from local development to CI/CD pipelines

This approach makes the book particularly suitable for teams adopting DevOps practices incrementally.

3. Practical progression and learning flow

Chapters are logically ordered, starting from environment setup and identity fundamentals, moving through hosting models, serverless and containers, and finally addressing AI, ML, and DevOps automation. Each section builds on previous knowledge without unnecessary repetition.

The frequent inclusion of use cases and design considerations helps readers understand why a service should be chosen—not just how to configure it.

4. Modern Azure coverage

The inclusion of Azure OpenAI Service, Azure Machine Learning, and GitHub Actions is handled pragmatically. These chapters avoid hype and instead focus on realistic integration scenarios, which is refreshing in a rapidly evolving AI landscape.

Areas for Improvement (Constructive Feedback)

1. Architecture-level context could be expanded

While individual services are well explained, readers with a solutions-architecture mindset may occasionally wish for more cross-service architectural diagrams or decision matrices, especially when comparing overlapping services (e.g., Logic Apps vs Durable Functions, Container Apps vs App Service).

2. Cost and governance considerations are implicit rather than explicit

Cost management, naming conventions, and governance practices are present indirectly, but a dedicated section or recurring callouts could further strengthen the enterprise-readiness of the material.

3. Advanced enterprise scenarios

The book intentionally avoids deep dives into topics such as large-scale multi-tenant architectures, complex networking, or advanced security patterns. This is not a flaw, but readers should be aware that it is not aimed at senior cloud architects designing global platforms.

Audience Fit

This book is particularly well suited for:

Developers building or modernizing applications on Azure
Teams transitioning from local or on-premises development to the cloud
Trainers and educators looking for structured, hands-on material
Developers who want to understand how Azure services fit together, not just how to deploy them

Readers expecting deep coverage of low-level infrastructure or exhaustive service catalogs should consider complementary resources.

Final Verdict

Azure for Developers (Third Edition) is a strong, reliable, and modern guide for developers working with Azure. It balances theory and practice well, promotes healthy cloud habits, and reflects real-world usage rather than idealized scenarios.

Its greatest strength lies in its pragmatic clarity: it teaches readers how to be effective Azure developers today, without unnecessary complexity or outdated patterns.

Definitive outcome:
This is a good book—and a trustworthy one. It deserves a place on the shelf of any developer serious about building applications on Azure in 2025 and beyond.

Book Review: Microsoft Copilot in Azure: AI-powered cloud automation and optimization

Massimo Bonanni — Wed, 24 Sep 2025 09:00:01 +0000

Microsoft Copilot in Azure by David Rendón and Steve Miles is a comprehensive and hands-on guide to one of the most exciting evolutions in cloud computing: bringing generative AI directly into the heart of Azure operations.

The book begins by laying a clear foundation of how large language models (LLMs) and Microsoft’s Copilot architecture fit into modern cloud environments. From there, it quickly moves into practical, real-world use cases. Readers learn how to set up and configure Copilot in the Azure portal, manage access securely with RBAC, and deploy infrastructure ranging from virtual machines to Azure Kubernetes Service (AKS) clusters and App Services—all through Copilot’s natural language interface.

What makes this book stand out is its breadth of coverage. It doesn’t stop at deployments. The authors dive into:

Integrating Copilot with Azure Functions, Blob Storage, and SQL databases
Real-time monitoring, diagnostics, and troubleshooting with AI-powered insights
Cost optimization strategies that use Copilot’s recommendations
Security posture management with Microsoft Defender for Cloud and compliance policies
Advanced prompt engineering techniques to maximize accuracy and results

The style is approachable yet precise, with step-by-step examples and scenarios that cloud architects, DevOps engineers, and administrators can immediately apply to their environments. By aligning Copilot’s capabilities with the Azure Well-Architected Framework, the book ensures readers not only understand the “how,” but also the “why” behind AI-driven cloud practices.

Why you’ll want this book: If you’re responsible for deploying, securing, or optimizing workloads in Azure, this guide shows how Copilot can save time, improve reliability, and reduce costs—without sacrificing governance or security.

In short, Microsoft Copilot in Azure is more than just a manual. It’s a roadmap for embracing AI as a true collaborator in Azure. Highly recommended for professionals who want to stay ahead of the curve in the AI-driven cloud era.

In conclusion, I would like to highlight a series of points for and against the book.

✅ Good Points

Comprehensive coverage: From fundamentals of LLMs and Copilot architecture to advanced use cases like scaling, troubleshooting, and cost optimization.
Hands-on approach: Includes step-by-step examples, scenarios, and code snippets that can be applied directly in real Azure environments.
Wide scope across Azure services: Covers VMs, AKS, App Service, Functions, SQL/MySQL, storage, monitoring, and security.
Strong focus on governance and security: Explains how Copilot respects RBAC, integrates with Defender for Cloud, and aligns with compliance policies.
Clear explanations of AI concepts: Demystifies prompts, tokens, completions, and how LLMs integrate with Azure.
Future-looking perspective: Discusses potential enhancements, multi-cloud adoption, and agentic solutions.

⚠️ Possible Limitations

Not for complete beginners: Requires prior knowledge of Azure fundamentals (VMs, App Service, networking, RBAC, etc.).
Focus is on Copilot: Doesn’t aim to be a general-purpose Azure manual, so readers new to the platform may need additional resources.
AI-generated code caveats: The book itself notes that Copilot’s outputs may need manual review or adjustment to be production-ready.
Fast-evolving field: As Azure Copilot and AI services evolve rapidly, some details may change over time.

Book Review: Cloud Solution Architect's Career Master Plan

Massimo Bonanni — Mon, 25 Mar 2024 08:00:00 +0000

As someone who's been in the tech industry for a while, I was curious to see what 'Cloud Solution Architect's Career Master Plan' had to offer, and I must say, it doesn't disappoint. The author has done a commendable job in creating a resource that is not just informative but also practical for individuals looking to forge a career in cloud solution architecture.

What stands out is the book's structured approach, starting with the fundamentals in Chapter 1, where it lays down the responsibilities of a Cloud Solution Architect (CSA). It's particularly insightful as it goes beyond the basics, delving into core concepts and the pros and cons of the role.

The subsequent chapters are equally valuable, with Chapter 2 discussing the various CSA roles and Chapter 3 advising on educational paths. For those like me, who value hands-on experience, Chapter 4's focus on gaining real-world experience is golden. It's refreshing to see a technical book emphasize the importance of practical knowledge.

Chapter 5's strategic approach to seizing opportunities and Chapter 6's guide on the job hunt process, including optimizing online presence, are timely in today's digital age. Chapter 7 provides an in-depth look at the interview process, which is a great tool for preparation.

Lastly, the book's call to 'give back' in Chapter 8 resonates with me personally, as it aligns with the ethos of contributing to the community and the broader tech society.

The text conventions used, such as code in text and bold for new terms, make the content accessible and the tips provided throughout are like having a mentor guiding you through the pages.

I appreciate that the author has made example code files available for download, which complements the theoretical knowledge with practical examples.

In conclusion, 'Cloud Solution Architect's Career Master Plan' is a thorough and insightful read for anyone serious about a career in cloud solution architecture, regardless of their experience level. It's a book that not only educates but also inspires action. Highly recommend it to any tech enthusiast looking to elevate their career.

Book Review: Azure Architecture Explained

Massimo Bonanni — Mon, 13 Nov 2023 07:00:00 +0000

The book is an excellent material for those who create solutions in Azure.

It is a collection of the necessary information, service by service, to better create one's own solutions.
Particular attention is paid to the aspect of security and compliance (which I think is rightly so) and I want to mention the chapter on Azure DevOps (increasingly important from an enterprise perspective) and the chapter on 'tips from the field'.
The latter is not very extensive, but still useful.

The book does not go into too much detail on the topics covered (but I think that's right) as it is a book intended for Azure solution architects and not for those who manage the resources, but there are practical parts that allow for a better understanding of the theoretical part.

The book can also be useful for those who have to take the Azure Architecture certification exam.

Book Review: Azure Cloud Adoption Framework Handbook

Massimo Bonanni — Mon, 25 Sep 2023 11:00:00 +0000

The Cloud Adoption Framework (CAF) provides a structured approach for organizations moving to Azure, ensuring alignment with business objectives, offering best practices, governance models and actionable guidance when adopting Azure.
Using CAF minimizes risk, optimizes costs, and lays the foundation for successful cloud adoption and management. But it is important to know it well and understand the concepts proposed in it in depth.

This book is an excellent manual for understanding what CAF is and how to use it.
The importance of the cloud and its correct adoption are the contents of the first section of the book, very useful for those who need to understand "why" to use the CAF. In particular, I found the scenarios in chapter 2, relating to the strategy for using the CAF, useful.

The strategy, when you decide to "adopt" a cloud solution, is fundamental and a strategy without a plan is useless.
The second part of the book is precisely focused on this: planning the move to the cloud, migrating your solutions and innovating by becoming "cloud native". In my opinion, chapters 4 and 5 are among the most important of the book because they are the essence of the cloud approach strategy: moving towards the cloud is a journey and migration is only the first step, not the target. All this is very clear in these chapters.

Finally, in the third part of the book, we find excellent references to Well-Architected Framework, as it rightly must be when we arrive at a "cloud native" approach and need to manage our environments.
I really liked the closing chapter which contains a summary of the various topics previously addressed, a sort of very well done summary of the book.

The book has less than 200 pages and is a smooth read. It is a handbook, and as such it should be considered: it explains the concepts precisely so that they are clear, then it is up to the reader, if he wants, to use the official documentation to go and split the bit on the specific aspect.

For me very well done and worth reading if your role is to make decisions on Azure adoption.

The page of the book on Packt website

Book Review: FinOps Handbook for Microsoft Azure

Massimo Bonanni — Wed, 28 Jun 2023 09:44:00 +0000

"FinOps Handbook for Microsoft Azure" by Maulik Soni is an invaluable resource for anyone wishing to understand and master the art of financial management in the cloud. Structured in three parts and encompassing 13 chapters, this manual offers a comprehensive and accessible coverage of the FinOps discipline, particularly as applied to the Microsoft Azure environment.

The first section of the book is dedicated to an overview of the tools and guidelines for cost management in Azure. Particularly noteworthy is the attention given to the cost assessment of the Well-Architected Framework, an analysis that readers will certainly find beneficial.

The second part, focused on cost optimization, stands out thanks to a detailed analysis of the top 10 targets for optimization. Soni tackles the subject with a very practical and useful approach, providing the reader with a valuable set of operational tools.

The third section of the book deals with cost optimization based on monitoring metrics, a concept known as Metric Driven Cost Optimization. This operational approach contributes to enriching the panorama of the FinOps discipline.

Each part concludes with a case study. Despite their simplicity, these case studies prove to be extremely useful for concretizing the previously discussed theoretical concepts, providing a helpful example of practical application.

Even though the subject matter may seem complex, "FinOps Handbook for Microsoft Azure" by Soni is surprisingly light and readable. It is an extremely useful text for both newcomers and seasoned FinOps professionals, who can consolidate and enrich their knowledge. The author's ability to simplify complex concepts without losing their essence is a strength of this manual, making Soni's work an essential reference in the field of cloud financial management.

When you work with Cloud technologies (no matter what cloud you are using), the cost is one of the thing you need to take care! Managing costs in the right way can be the winner weapon!!

Azure Functions Tips: override the host.json settings!!

Massimo Bonanni — Thu, 01 Jun 2023 13:28:35 +0000

The host.json file in Azure Functions is a configuration file that provides runtime-specific settings for your function app.
This file is located at the root of a function app project.
Some of the settings that can be configured in the host.json file include the version of the Azure Functions runtime, logging settings, function timeout duration, and settings for bindings and triggers.
The settings in the host.json file apply to all functions within a function app.

Every time you need to change some settings inside it, you need to redeploy the entire Functions App (I know that you can access to the files in the deploy directly from the portal, but it isn't a good idea!!). Fortunately, you can override the values you have in the host.json thought the appsettigs.json file (or using the configuration blade in the portal).

In particular, you can set the configuration value similar to the following:

AzureFunctionsJobHost__<HOST-CONFIG-VALUE> = value

where <HOST-CONFIG-VALUE> is the host.json value you want to override.
For example, suppose you have the following host.json:

{
  "version": "2.0",
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "excludedTypes": "Request"
      }
    }
  },
  "functionTimeout": "00:05:00",
  ....
}

In that file, you set the timeout for your functions to 5 minutes. If you want to override that value to have 3 minutes of timeout, you can add the following setting in the appsetting.json file:

{
  "IsEncrypted": false,
  "Values": {
    ...
    "AzureFunctionsJobHost__functionTimeout": "00:03:00",
    ...
  }
}

In that case <HOST-CONFIG-VALUE> is functionTimeout.
If the value you want to override is a property of a section in the host.json config, you need to use the __ string to describe the hierarchy.

ERROR_USER_UNAUTHORIZED error using publish profile in App Service

Massimo Bonanni — Fri, 26 May 2023 09:43:15 +0000

If you try to publish an App Service using the Publish Profile and you receive the ERROR_USER_UNAUTHORIZED error, you need to enable the Basic Authentication on App Service to solve it.

You can receive this error, for example, if you are deploying your App Service using Visual Studio.
You create the Publish Profile in Visual Studio with the Publish menu:

This Visual Studio feature, behind the scene, use the Publish Profile of the App Service to deploy your code.
Up until a couple of weeks ago, the Basic authentication in App Service was active by default and this always allowed this option to be used without errors. For a couple of weeks now, if you create an App Service from the Azure portal and try to do this type of publication, you get the following error:

This happens because the Basic Authentication is, now, disable by default.
If you want to continue to deploy your app using this way, you need to open the Configuration blade of your App Service, click on the General settings tab and enable the Basic Authentication option.

This configuration should solve your problem.

Read secrets from Azure Key Vault in your GitHub Action

Massimo Bonanni — Wed, 24 May 2023 08:40:00 +0000

GitHub allows you to use secrets in your Actions and manage them directly in the repo using the feature you can find in Settings-->Secrets and variables-->Actions.

But, often, you need to manage your secrets outside the repo (for example because the people who manage the secrets are different from the people who manage the Actions) and, in those scenarios, using Azure Key Vault is a good idea.
Let's imagine we have a Key Vault called GitHubKeyVaultin which we have stored a secret called GitHubSecret.

Setting credentials and role

Before you can access and use the secret in the Key Vault, you must define a service principal you want to use in the GitHub Action and set the right role (or access policies) in the Key Vault.
To understand how you can create a Service principal for the Action and set the credentials in GitHub, look at my previous post.

Let's suppose that the Service Principal is called GitHubWorkflowDemo. To set the right permission for the Service Principal in the Key Vault, you can use or RBAC approach or the Key Vault access policies.
We use Access Policies in this post, but using RBAC is very similar.
Open the Key Vault page and select the Access policies blade and click on "+ Create" button:

In the permission step, we need to configure the permissions we want to assign to our Action. Because, it only needs to read secrets, we can select Get options in Secret permissions:

In the next step, you need to select the Service Principal created earlier (the Service Principal we use in the Action):

You can skip the next step (Application), because setting the principal you already set an application for the access policy and you can continue creating the policy.

Now you are ready to read and use the secret in the Action.

Using the `Azure/get-keyvault-secrets` action

One of the way you can achieve your goal is using the Azure/get-keyvault-secrets action in your GitHub workflow.
You can write something like this:



name: Secret from KeyVault
on: 
  workflow_dispatch

env:
  SECRETVALUE: ''

jobs:
  retrieveWithAction:
    runs-on: ubuntu-latest
    steps:  
    - uses: Azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}
    - uses: Azure/get-keyvault-secrets@v1
      with: 
        keyvault: 'GitHubKeyVault'
        secrets: 'GitHubSecret'
      id: mySecrets
    # Starting from here you can use the secret using the 
    # steps.mySecrets.outputs.GitHubSecret variable 
    ...

The first step of the retrieveWithAction job of the Action creates a session in Azure using the Service Principal credentials stored in the AZURE_CREDENTIALS secret.
The second step uses the Azure/get-keyvault-secrets action to access the Key Vault whose name is contained in the keyvault parameter to read the secrets listed in the secrets parameter. The secret will be available in the steps variables and, in particular, in outputs collection of the variable whose name is contained in the id parameter.

You can find more info about this action in its GitHub repo.
Unfortunately this action is no longer maintained (the repository is archived) and is considered deprecated. It works, but it will not be evolved or supported in the future.

Using Azure CLI

Another way you have to read secret from Key Vault is using the az keyvault secret show command (more info on it here).

You can write something similar to this:



name: Secret from KeyVault
on: 
  workflow_dispatch

env:
  SECRETVALUE: ''

jobs:
  retrieveWithCLI:
    runs-on: ubuntu-latest
    steps:
      - uses: Azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
      - name: Retrieve secret from KV
        uses: azure/CLI@v1
        with:
          inlineScript: |
            secretValue=$(az keyvault secret show --name "GitHubSecret" --vault-name "GitHubKeyVault" --query "value")
            echo "SECRETVALUE="$secretValue >> $GITHUB_ENV
      # Starting from here you can use the secret using the 
      # SECRETVALUE variable

Similar to the previous approach, you create a session in Azure using the Azure/login action, but in the second step you use the Azure/CLI action to retrieve the secret from the Key Vault with the previous CLI command and save it in the SECRETVALUE variable.

In this approach you need to have a call for each secret and differently from the first approach in which the secrets remain secrets within the action, in this second approach the secrets end up in common variables.

Azure Functions Tips: how to store the Functions App keys into KeyVault

Massimo Bonanni — Wed, 17 May 2023 09:28:00 +0000

Introduction

In a previous post, we talked about Function App keys and the default store.
The default store for all the keys in your Function app is a Storage Account. You can change it, you can have two different Storage Accounts for the keys and for other stuff of your Function App, but it is a Storage Account.
One of the best practices about secrets management in Azure is to store them in a Key Vault and the Function App keys are, at the end, secrets.

Key Vault as keys store

You can change the service you use to store the Function App keys using the AzureWebJobsSecretStorageType config value.
Setting this value in the Function App configuration, you che choose the following services:

blob: this is the default value and allows you to use Storage Account as secret store (as show in the previous post);
files: use the file system to persist the secrets. This is the default for the function runtime v.1.x;
keyvault: using this value, you can store the keys into a Key Vault;
kubernetes: this is supported only if your functions run in Kubernetes.

In our case, we set the value on keyvault and we use AzureWebJobsSecretStorageKeyVaultUri key to store the Key Vault reference.

It's just identity

Now you set the Key Vault as secret store, but all this is useless if the function app doesn't have privileges to access the Key Vault itself.

You can use both Managed Identity or Service Principal (App Registration) to provide permission on the Key Vault site.

Managed Identity

In this scenario we can either use a System-assigned or a User-assigned Managed Identity.
In the first case, we don't need to do anything except configure the access credentials on the Key Vault service (we'll see later).
If, on the other hand, we have defined our Function App as a User-assigned Managed Identity, we need to retrieve the client id of the identity and use it in the AzureWebJobsSecretStorageKeyVaultClientId configuration.
To retrieve the Client ID, you can use the portal:

or you can use the CLI command:

az identity show --name <identity name> --resource-group <resource group name> --query "{ClientID:clientId}"

Once you have the client id, you add it to the Function App configuration:

App Registration

If you need, you can also use a Service Principal (App Registration).
In this scenario, you need to have Client ID, Tenant ID and Client Secret (as usual) from the portal and, then add the following settings in the Function App configuration:

AzureWebJobsSecretStorageKeyVaultClientId
AzureWebJobsSecretStorageKeyVaultClientSecret
AzureWebJobsSecretStorageKeyVaultTenantId

Note: System-assigned Managed Identiy works perfectly with runtime version 3.x and 4.x, while the other two (User-assigned and App Registration) work only with runtime 4.x.

Set the right credential

Once you have an identity for your Function App you need to set the right credential into the Key Vault.
The Function App needs to:

retrieve the list of the keys (it shows you the keys in the portal);
read a key (it need to check the single key every time you make a call);
add/update a key (you can add or change an existing key from the portal);
delete a key (you can remove a key).

You can configure these permission using RBAC or access policy.
If you use RBAC, the right role for the Function App need to have, at least, the following DataActions:

Microsoft.KeyVault/vaults/secrets/delete
Microsoft.KeyVault/vaults/secrets/getSecret/action
Microsoft.KeyVault/vaults/secrets/setSecret/action
Microsoft.KeyVault/vaults/secrets/readMetadata/action

You can use the built-in role "Key Vault Secrets Officer" even it has more operations than you need.

If you use the Key Vault Access policy approach, the following picture shows you the right settings:

How the keys are stored

The Function App creates a secret for each keys you have in the host part (for example the master key) and for each key you create in each function inside the Function App.
For example, if you have the following keys:

you have the following secret definitions in the Key Vault secrets page:

Azure Functions Tips: where are our Function App keys?

Massimo Bonanni — Wed, 10 May 2023 09:15:00 +0000

Introduction

Azure Functions give you a built-in way to secure the calls for Http trigger functions. If you look at the following simple Azure Functions:



[FunctionName("Echo")]
public IActionResult Echo(
    [HttpTrigger(AuthorizationLevel.Function, "post", Route = "echo")] HttpRequest req,
    ILogger log)
{
    log.LogInformation("C# HTTP trigger function processed a request.");

    return new OkObjectResult(req.Body);
}

You can notice the argument AuthorizationLevel.Function of the HttpTrigger attribute. According to the official documentation (here for more info), that value:

is a string value that indicates the kind of authorization key that's required to access the function endpoint.

It means that, if you enable that feature, you need to invoke the Http endpoint with an URL like the following:



https://myfunctionapp.azurewebsites.net/api/echo?code=<API_KEY>

If you prefer, you can send the key using the header x-functions-key instead the query string.
The possible values for the AuthorizationLevelenumeration are:

Value	Description
anonymous	No API key is required
function	A function-specific API key is required. This is the default value when a level isn't specifically set.
admin	The master key is required

Azure portal gives you the capability to manage both function-specific keys and master keys:

Default keys store

As you can see from the previous images, you can add more than one key both in the system group than for each single function.
But the question is: where are stored these keys?

By default, the Function App retrieves (and saves, of course) all the keys you create in a Storage Account.
The connection string of the Storage Account is stored in the AzureWebJobsStorage configuration.
The Function App uses this Storage Account for the timer triggers info, the Event Hub checkpoint and, also, as store for the different Keys you have in it.
If you open the Storage Account page, you can find a container called azure-webjobs-secrets as shown in the following picture:

In this container you find a folder for each Function App that uses it as store and inside folders you can see the JSON blobs that contain the secrets:

As you can see in the previous image, you have one blob for each function (in our sample, we have only the echo.json blob for the echo function) and one blob (host.json) for the system keys.
The echo.json has the following schema:



{
  "keys": [
    {
      "name": "default",
      "value": "CfDJ.........HaTQ",
      "encrypted": true
    }
  ],
  "hostName": "keyvaultkeysfuncapp.azurewebsites.net",
  "instanceId": "1cb21680e4253c2794483f9b01c5c800",
  "source": "runtime",
  "decryptionKeyId": "MACHINEKEY_DecryptionKey=Qzlp8wEKnbM33X1gHAREIGNJee8Ii6e6GEmnt5jT4j8=;"
}

You have the array keys that contains all the keys you create for the specific function.
The key is a JSON Web Key (JWK) key (rfc definition) and you can add, remove or modify a key changing the JSON blob (I suggest to use the Azure portal or the CLI command, but if you want you can change directly in the blob).

To generate a JWK kay you can use the following C# snippet (or you can find a lot of on-line tools):



using System.Security.Cryptography;
using System.Text.Json;

class Program
{
    static void Main()
    {
        // Create a new RSA key pair
        using (var rsa = RSA.Create())
        {
            // Export the public key as a JWK
            var jwk = Base64UrlEncode(rsa.ExportRSAPublicKey());
            Console.WriteLine(jwk);
        }
    }

    static string Base64UrlEncode(byte[] data)
    {
        return Convert.ToBase64String(data)
            .Replace('+', '-')
            .Replace('/', '_')
            .Replace("=", "");
    }
}

If you set a key with wrong format, the Azure portal doesn't show it.

Change the default storage

You can use a secondary storage for the secrets.
To do that, you can set the setting called AzureWebJobsSecretStorageSas with the Shared Access Signature of the secondary storage.

So, imagine you create the storage account called myfunckeysstorage.
You need a container inside it (to store the JSON blobs) as shown in the following picture:

Of course, you can call it as you want.
Now you need to generate the Shared Access Token to use in the Function App setting. To generate the SAS, you can open the container and use the option "Shared access tokens" as shown in the following picture:

To set the new storage as secret store for the Function App, you need to add the setting AzureWebJobsSecretStorageSas with the value of the URL with SAS you generate in the previous step.

Azure Functions Tips: change the limit for the size of body in a function

Massimo Bonanni — Wed, 03 May 2023 09:31:00 +0000

When you implement an Http Trigger Function that manages a request with a body, you have a size limit for the body itself. The default value for this limit is 100Mb (actually 104857600 bytes and you can read it in the Http Trigger documentation).

You can manage this limit using the Function App configuration. In particular, you can add the setting FUNCTIONS_REQUEST_BODY_SIZE_LIMIT to set the maximum number of bytes you support in a single Http request.

Just to test how this setting works, use the following simple function:



[FunctionName("PostSomething")]
public IActionResult PostSomething(
    [HttpTrigger(AuthorizationLevel.Function, "post", Route = "post")] HttpRequest req,
    ILogger log)
{
    log.LogInformation("C# HTTP trigger function processed a request.");

    return new OkResult();
}

You can do it also in your machine:

Add the config to your local setting file of the Function project:



{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet",
    "FUNCTIONS_REQUEST_BODY_SIZE_LIMIT": 100
  }
}

Run the project:

Make a POST Http request (for example using curl):



curl -X POST http://localhost:7077/api/post --data "This is the payload of the request and its size is more than 100 bytes. The function should throw an exception!!"

The function's log should display the error related to the size of the body:

You can have the same behavior if you set the application setting value in a Function App on Azure:

and then you can test the function:

having the error:

DEV Community: Massimo Bonanni

Book Review: Azure or Developers (third edition)

Overall Assessment

Strengths

1. Clear developer-oriented scope

2. Strong CLI and automation mindset

3. Practical progression and learning flow

4. Modern Azure coverage

Areas for Improvement (Constructive Feedback)

1. Architecture-level context could be expanded

2. Cost and governance considerations are implicit rather than explicit

3. Advanced enterprise scenarios

Audience Fit

Final Verdict

Book Review: Microsoft Copilot in Azure: AI-powered cloud automation and optimization

Book Review: Cloud Solution Architect's Career Master Plan

Book Review: Azure Architecture Explained

Book Review: Azure Cloud Adoption Framework Handbook

Book Review: FinOps Handbook for Microsoft Azure

Azure Functions Tips: override the host.json settings!!

ERROR_USER_UNAUTHORIZED error using publish profile in App Service

Read secrets from Azure Key Vault in your GitHub Action

Setting credentials and role

Using the Azure/get-keyvault-secrets action

Using Azure CLI

Azure Functions Tips: how to store the Functions App keys into KeyVault

Introduction

Key Vault as keys store

It's just identity

Managed Identity

App Registration

Set the right credential

How the keys are stored

Azure Functions Tips: where are our Function App keys?

Introduction

Default keys store

Change the default storage

Azure Functions Tips: change the limit for the size of body in a function

Using the `Azure/get-keyvault-secrets` action