🎓 Azure Developer Associate

Azure App Service

Azure App Service is an HTTP-based service for hosting web applications, REST APIs, and mobile back ends. You can develop in your favorite programming language or framework. Applications run and scale with ease on both Windows and Linux-based environments.

Key features

• Built-in auto scale support The ability to scale up/down or scale out/in is baked into Azure App Service.
  • Scaling out/in is the ability to increase or decrease the number of machine instances that are running your web app.
  • Scaling up/down is scaling the resuorces of the underlying machine that is hosting your web app.
• Container Support With azure App Service, you can deploy and run containerized web apps on Windows and Linux
• Continuous integration/deployment support The Azure portal provides out-of-the-box cotinuous integration and deployment with Azure DevOps Services, Github, Bitbucket, FTP, or a local Git repository on your development machine.
• Deployment Slots When deploying a web app, you can use a separate deployment slot instead of the default production slot when you’re running in the Standard App Service Plan tier or better.
• App Service on Linux App Service can also host we apps natively on Linux for supported application Stacks. .Net Core, Java (Tomcat, JBoss EAP or Java SE with an embedded web server), Node.js, Python, and PHP.
  • az webapp list-runtimes --os-type linux
  • App Service on linux have some limitations
    • Shared pricing tier has no support
    • Portal only shows featurs that currently work forlinix apps.
    • When deployed to built-in images, your code and content are allocated as a storage volume for web content, backy by Azure Storage.

App Service Plans

In App Service, an app always runs in an App Service Plan. An App Service plan defines a set of compute resources for a web app to run. One or more apps can be configured to run on the same computing resoures (or in the same App Service plan).

Each app service plan defines

• Operating System ( Windows, Linux)
• Region ( West US, East US, etc.)
• Number of VM instances
• Size of VM instances (Small, Medium, Large)
• Pricing Tier (Free, Shared, Basic, Standard, Premium, Premium V2, PremiumV3, Isoleted, IsolatedV2)

Pricing Tiers

• Shared compute: Free and Shared, the two base tiers, runs an app on the same Azure VM as other App Service apps, including apps of other customers. These tiers are intended to be used only for development and testing purposes
• Dedicated compute: The Basic, Standard, Premium, PremiumV2 and PremiumV3 tiers run apps on dedicated Azure VMs.
• Isolated: The Isolated and Isolatedv2 tiers run dedicated Azure VMs on dedicated Azure Virtual Networks.

Deploy to App Service

App service supports both automated and manual deployment.

Automated deployment

Azure App Service supports automated deployment from several source control systems as part of a continuous integration and deployment (CI/CD) pipeline.

• Azure DevOps services
• Github
• Bitbucket

Manual deployment

• Git
• CLI az webapp up
• Zip Deploy
• FTP/S

Sidecar containers enable deploying extra services and features without making them tightly coupled to your main application container.

Multitenant App Service networking features

• Inbound Features App-assigned Address, Access restrictions, Service endpoints, Private endpoints
• Outbound Features Hybrid connections, Gateway-required virtual network integration, Virtual

Find outbound IPs

az webapp show --resource-group "<group_name>" --name "<app_name>" --query outboundIpAddresses --output tsv

az webapp show --resource-group "<group_name>" --name "<app_name>" --query possibleOutboundIpAddresses --output tsv

Web app settings

In App Service, app settings are variables passed as environment variables to the application code.

Configure application settings

In App Service, app settings are variables passed as environment variables to the application code, They’re injected into app environment at app startup. When you add, remove or edit app settings, App Service triggeres an app restart.

App service override settings in Web.config or appsettings.json. App settings are always encrypted when stored (encrypted-at-rest)

! In a default Linux app service or a custome linux container, any nested JSON key structure in the app settings name like ApplicationInsights:InstrumentationKey needs to be configured in App Service as Application__InstrumentationKey for the key name. (replace any : with __ double underscore

At runtime, connection strings are available as environment variables, prefixed with:

• SQLServer: SQLCONNSTR_
• MySQL: MYSQLCONNSTR_
• SQLAzure: SQLAZURECONNSTR_
• Custom: CUSTOMCONNSTR_
• PostgreSQL: POSTGRESQLCONNSTR_
• Notification Hub: NOTIFICATIONHUBCONNSTR_
• Service Bus: SERVICEBUSCONNSTR_
• Event Hub: EVENTHUBCONNSTR_
• Document DB: DOCDBCONNSTR_
• Redis Cache REDISCACHECONNSTR_

Used like MYSQLCONNSTR_connectionstring1.

Configure environment variables for custom containers

az webapp config appsettings set --resource-group "<group-name>" --name "<app-name>" --settings key1=value1 key2=value2

In the Configuration > Path mappings section you can configure handler mappings, and virtual application directory mappings. Each app has the default root path (/) mapped to D:\home\site\wwwroot, you can edit or add virtual applications and directories.

Diagnostic logging

There are built-in diagnostics to assist with debugging an App Service app.

• ASP.NET applications can use the System.Diagnostics.Trace class to log information to the application diagnostics log.

	System.Diagnosics.Trace.TraceError("some error");

• Python applications can use the OpenCensus package to send logs to the application diagnostics log.

! Some types of logging buffer write to the log file, which can result in out of order events in the stream.

Stream logs:

	az webapp log tail --name "appname" --resource-group "myResourceGroup"

For logs stored in the App Service file system, the easiest way is to download the ZIP file in the browser at:

• Linux/container apps: https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip
• Windows apps: https://<app-name>.scm.azurewebsites.net/api/dump

Add and manage TLS/SSL certificates in Azure App Service

Azure App Service has tools that let you create, upload or import private certificate or a public certificate into App Service.

Options to add certificates in App Service

• Create a free App Service managed certificate
• Import/Purchase an App Service certificate
• Import a certificate from Azure Key Vault
• Upload a private certificate
• Upload a public certificate

Create a free App Service managed certificate

A private certificate that’s free of charge and easy to use if you just need to secure your custom domain in App Service.

Free certificate limitations

• Doesn’t support wildcard certificates
• Doesn’t support use as a client certificate by using certificate thumbprints, which is planned for deprecation and removal
• Doesn’t support private DNS
• Isn’t exportable
• Isn’t supported in App Service Environment
• Supports only alphanumeric characters, dashes(-), and periods (.)
• Supporst custom domains of a length up to 64 characters

! Azure fully manages the certificates on your behalf, Make sure to avoid hard dependencies and “pinning” practice certificates to the managed certificate or any part of the certificate hierarchy.

Import an App Service Certificate

App Service Certificate combines the simplicity of automated certificate management and the flexibility of renewal options.

If you purchase an App Service Certificate from Azure, Azure manages the following tasks:

• Takes care of the purchase process from certificate provider
• Performs domain verification of the certificate
• Maintains the certificate in Azure Key Vault
• Manages certificate renewal
• Synchronize the certificate automatically with the imported copies in App Service apps.

Certificates from Key Vault

If you use Key Vault to manage your certificates, you can import a PKCS12 certificate into App Service from Key Vault if you meet the requirements.

By Default, the App Service resources provider doesn’t have access to your key vault. To use a key vault for a certificate deployment, you must auhtorize read access for the resource provider (App Service) to the key vault. You can grant access with an access policy or role-based access control (RBAC)

az role assignment create --role "Key Vault Certificate User" --assignee "abfa0a7c-a6b6-4736-8310-5855508787cd" --scope "/subscriptions/{subscriptionid}/resourcegroups/{resource-group-name}/providers/Microsoft.KeyVault/vaults/{key-vault-name}"

    #Assign by Service Principal ApplicationId
    New-AzRoleAssignment -RoleDefinitionName "Key Vault Certificate User" -ApplicationId    "abfa0a7c-a6b6-4736-8310-5855508787cd" -Scope "/subscriptions/{subscriptionid}/resourcegroups/{resource-group-name}/   providers/Microsoft.KeyVault/vaults/{key-vault-name}"

Private certificate requirements

• Exported as a password-protected PFX file, encrypted using triple DES.
• Contains private key at lease 2048 bits long
• Contains all intermediate certificates and the root certificate in the certificate chain.

To secure a custom domain in a TLS Binding, the certificate has other requirements:

• Contains an Extended Key Usage for server authentication (OID = 1.3.6.1.5.5.7.3.1)
• Signed by a trusted certificate authority

Autoscaling

Autoscaling is a cloud system or process that adjusts available resources based on the current demand. Autoscaling performs scaling in and out, as opposed to scaling up and down.

Autoscaling enables a system to adjust the resources required to meet the varying demand from users, while controlling the costs associated with these resources.

A scale-out action increases the number of instances, and a scale-in action reduces the instance count

Scale out options are;

• Manual
• Azure Autoscale. Makes decisions based on rules that you define.
• Azure App Service automatic scaling. Makes decisions based on the parameters that you select.

! Autoscaling responds to changes in the environment by adding or removing web servers and balancing the load between them. Autoscaling doesn’t have any effect on the CPU power, memory, or storage capacity of the web servers powering the app, it only changes the number of web servers.

! If your web apps perform resource-intensive processing as part of each request, then autoscaling might not be an effective approach.

Autoscaling works by analyzing trends in metric values over time accross all instances.

Metrics for autoscale rules

• CPU Percentage
• Memory Percentage
• Disk Queue length
• Http Queue length
• Data in
• Data out

A single autoscale condition can contain several autoscale rules, the autoscale rules in an autoscale condition don’t have to be directly related.

! Not all pricing tiers support autoscaling. The development pricing tiers are either limited to a single instance (the F1 and D1 tiers), or they only provide manual scaling (the B1 tier). If you selected one of these tiers, you must first scale up to the S1 or any of the P level production tiers.

Best practices

If you’re not following good practices when creating autoscale settings, you can create conditions that lead to undesirable results. (like flapping where scale-in and scale out actions continually go back and forth. )

• Ensure the maximum and minimum values are different and have an adequate margin between them.
• Choose the appropriate statistic for your diagnostic metric
• Choose the thresholds carefully for all metric types
• Always select a safe default instance count
• Configure autoscale notifications

Deployment Slots

The deployment slot functionality in App Service is a powerful tool that enables you to preview, manage, test and deploy different development environments. Deployment slots are live apps with their own host names.

Deployment slots are available in Standard, Premium, or Isolated App Service tier.

Benefits

• Staging slot for testing
• Warm-up before slot swapping
• Swap immediatly back to get your “last known good site”

There is no extra charge for using deployment slots.

Each plan tier supports different number of slots;

• Flex Consumption: n\a
• Consumption Plan 2
• Premium 3
• Dedicated 1-20
• Container Apps not supported

The slot’s URL has the format http://sitename-slotname.azurewebsites.net

Slot swapping

When you swap two slots, App Service completes the following processes;

1- Apply the following settings from the target

• Slot-specific app settings and connection strings, if applicable
• Continuous deployment settings, if enabled
• App Service authentication settings, if enabled

During swap with preview, this marks the end of the first phase. The swap operation is paused, and you can validate that the source slot works correctly with the target slot’s settings.

2- Wait for every instance in the source slot to complete its restart.

3- Trigger local cache initialization.

4- If auto swap is enabled with custom warm-up

• If applicationInitialization isn’t specified, trigger an HTTP request to the application root of the source slot on each instance
• An instance is considered warmed up if it returns any HTTP response.

5- Swap the two slots by switching the routing rules for the two slots.

6- Perform the same operation to the target slot.

! Make sure that the production slot is always the target slot. This way, the swap operation doesn’t affect your production app.

To make settings swappable, add the app setting WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS in every slot of the app and set its value to 0 or false. These settings are either all swappable or not at all. You can’t make just some settings swappable and not the others. Managed identities are never swapped and aren’t affected by this override app setting.

Deployment slot settings tells App Service that the setting isn’t swappable.

Auto swap

Auto swap streamlines Azure DevOps Services scenarios where you want to deploy your app continuously with zero cold starts and zero downtime for customers of the app.

! Auto swap isn’t currently supported in web apps on Linux and Web App for Containers

Custom warm-up

The applicationInitialization configuration element in web.config lets you specify custom initialization actions.

<system.webServer>
	<applicationInitialization>
        <add initializationPage="/" hostName="[app hostname]" />
        <add initializationPage="/Home/About" hostName="[app hostname]" />
    </applicationInitialization>
</system.webServer>

You can also customize the warm-up with app settings;

• WEBSITE_SWAP_WARMUP_PING_PATH The path to warm up your site.
• WEBSITE_SWAP_WARMUP_PING_STATUSES Valid HTTP response codes for the warm-up operation.
• WEBSITE_WARMUP_PATH A relative path on the site that should be pinged whenever the site restarts.

Route traffic in App Service

You can route a portition of the traffic to another slot. Using the Traffic % (0-100) setting. Production slot has 100 by default.

To be able to redirect the traffic to different slots you can use x-ms-routing-name=staging cookie . A request routed to the production slot has the cookie x-ms-routing-name=self.

<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>

Azure Functions

Azure Functions is a serverless solution that allows you to write less code, maintain less infrastructure, and save on costs, you can write just the code you need for the problem at hand, without worrying about a whole application or the infrastrucre to run it.

Azure Functions supports triggers, which are ways to start execution of your code, and bindings, which are ways to simplify coding for input and output data.

Differences between Azure Functions and Logic Apps

Both Functions and Logic Apps are Azure Services that enable serverless workloads. Azure Functions is a serverless compute service, whereas Azure Logic Apps is a serverless workflow integration platform.

Differences between Azure Functions and WebJobs

Like Azure Functions, Azure App Service WebJobs with the WebJobs SDK is a code-first integration service that is designed for developers.

Azure Functions is built on the WebJobs SDK.

Azure Functions hosting options

The hosting option you choose dictates;

• How your function app is scaled
• The resources available to each function app instance
• Support for advanced functionality, such as Virtual Network Connectivity
• Support for Linux containers

Overview of plans

Consumption plan

The Consumption plan is the default hosting plan. Pay for compute resources only when your functions are running (pay-as-you-go) with automatic scale. Instances are dynamically added and removed based on the number of incoming events.

Flex Consumption plan

Get high scalability with compute choices, virtual networking, and pay-as-you-go billing. Instances are dynamically added and removed based on the configured per instance concurrency and the number of incoming events.

Premium plan

Automatically scales based on demand using prewarmed workers, which run applications with no delay after being idle, runs on more powerful instances, and connect to virtual networks.

Consider this plan in the following situations;

• Your function apps run continuously, or nearly continuously.
• You want more control of your instances and want to deploy multiple function apps on the same plan with event-driven scaling.
• You have a high number of small executions and a high execution bill, but low GB seconds in the Consumption plan.
• You need more CPU or memory options than are provided by consumption plans.
• Your code needs to run longer than the maximum execution time allowed on the Consumption plan.
• You require virtual network connectivity.
• You want to provide a custom Linux image in which to run your functions.

Dedicated plan

Run your functions within an App Service plan at regular App Service plan rates.

Consider this plan in the following situations;

• You must have fully predictable billing, or you need to manually scale instances.
• You want to run multiple web apps and function apps on the same plan
• You need access to larger compute size choices.
• Full compute isolation and secure network access provided by an App Service Environment (ASE).
• High memory usage and high scale (ASE).

Container Apps

Create and deploy containerized function apps in a fully managed environment hosted by Azure Container Apps.

Consider this plan in the following situations;

• You want to package custom libraries with your function code to support line-of-business apps.
• You need to migrate code execution from on-premises or legacy apps to cloud native microservices running in containers.
• You want to avoid the overhead and complexity of managing Kubernetes clusters and dedicated compute.
• You need the high-end processing power provided by dedicated CPU compute resources for your functions.

Authentication and authorization

Azure app service provides built-in authentication and authorization support, uses federated identity, in which a third-party identity provider manages the user identities and authentication flow.

Microsoft Entra, Facebook, Google, X, Any OpenID Connect Provider, Github, Apple

• The OAuth 2.0 On-Behalf-Of flow (OBO) is used when an application invokes a service or web API, which in turn needs to call another service or web API. The idea is to propagete the delegated user identity and permissions through the request chain.
• The OAuth 2.0 authorization code grant can be used in apps that are installed on a device to gain access to protected resources, such as web APIs.
• The OAuth 2.0 client credentials grant flow permis a web service (confidential client) to use its own credentials, instead of impersonating a user, to authenticate when calling another web service.

Delegated permissions

Delegeted permissions are used by apps that have a signed-in user present. For these apps, either the user or an administrator consents to the permissions that the app requests and the app can function as the signed-in user when making calls to Microsoft Graph.

Application Insights

• COHORT - Be able to see the engaged users based on the usage of the applications
• IMPACT - Be able to see how load times of the application interfere with the conversion rates for various parts of the application
• FUNNELS - Be able to see how users progress through multiple stages of application
• RETENTION - Be able to compare the number of users who return to your application

Preaggregated standard metrics are not affacted by telemetry sampling and provide accurate real-time data, which makes them suitable for dashboarding and alerting.*

Azure Event Hubs

Azure Event Hubs is a native data-streaming service in the cloud that can stream millions of events per second, with low latency, from any source to any destination. Event Hubs is compatible with Apache Kafka. It enables you to run existing Kafka workloads without any code change.

Key Components

• Event Hub namespace - This is a container for multiple Event Hubs
• Event Publisher - This sends data to the Event Hub (producer)
• Event Retention - Standard 7 days. Premium, Dedicated 90 days maximum
• Event Consumer - These consume the events from Event Hub (consumer)
• Consumer Group - This is a logical grouping of consumers that read data from the event hub

Throughput

Throughput capacity of the Event hub is controlled via number of throughput units you assign. These are prepurchased but billed per hour.

• Ingress (input) - 1MB per second or 1000 events per second
• Egress (output) - 2MB per second or 4096 events per second

NuGet Packages

dotnet add package Azure.Messaging.EventHubs
dotnet add package Azure.Messaging.EventHubsProcessor

Notable Classes

EventHubProducerClient, EventDataBatch, EventData, EventHubConsumerClient, PartitionEvent, EventProcessorClient

Important Notes

• Events are not deleted after reading, consumer needs to keep track of events being read. Events will be removed after retention period. It’s not a persistence storage

• Multiple partitions increase throughput

• The number of partitions is specified at the time of creating an event hub. It must be between one and maximum partition count allowed for each pricing tier

• EventProcessorClient uses storage account to store the position of the reads

• Capture Feature Basic pricing tier doesn’t support this feature, has to be at least Standard pricing tier. Avro, Parquet, Delta Lake are the data formats. Stores in a storage account, time based or size based limitations available

• Azure Service Bus comparison - Used for messages, Azure Service Bus is fully managed enterprise message broker. Has topics and messages. Azure Event Hub is used for receiving events, this is a data streaming service that can stream millions of events per second. This can be from any source or destination

Azure Event Grid (MQTT)

Azure Event Grid is a highly scalable, fully managed Pub Sub message distribution service that offers flexible message consumption patterns using the MQTT and HTTP Protocols.

It can be used with Azure services as publisher, and Azure functions as subscriber.

Key Components

• System Topic - Events from Azure Services
• Custom Topic - Here you can publish your own Application-based events
• Subscribers - Multiple subscribers can subscribe to a topic

Event Grid Schema

[
    {
        "topic": "string",
        "subject": "string",
        "id": "string",
        "eventType": "string",
        "eventTime": "string",
        "data": { "object-unique-to-each-publisher" },
        "dataVersion": "string",
        "metadataVersion": "string"
    }
]

Event sources send events to Azure Event Grid in array, which can have several event objects. When posting events to an Event Grid topic, the array can have a total size of up to 1MB.

NuGet Package

dotnet add package Azure.Messaging.EventGrid

Notable Classes

EventGridEvent, SubscriptionValidationEventData, EventGridPublisherClient

Important Notes

• Endpoint validation - For HTTP based subscribers, on first subscription Event Grid sends validation code, and you respond with that validation code back (handshake). Once hub receives the code, the subscription starts
• To send custom topics we need to create a topic before sending. Topic Endpoint and access key will be used to send/receive events to this topic

Change Feed support in Azure Blob Storage

The purpose of the change feed is to provide transaction logs of all the changes that occur to the blobs and the blob metadata in your storage account.

Stored under $blobchangefeed

NuGet Packages

dotnet add package Azure.Storage.Blobs
dotnet add package Azure.Storage.Blobs.ChangeFeed

Notable Classes

BlobServiceClient, BlobChangeFeedClient, BlobChangeEvent

API Management Service

With Azure API Management, you get an API Gateway. All requests to the APIs can flow via the API Gateway.

https://azure.microsoft.com/en-us/pricing/details/api-management/

• Has built in security, validates API keys or JWT tokens
• Cache responses
• You can enforce usage quotas and rate limits

To enable access only from the API Management to a web app instance:

Networking > Public Network Access > Enabled from select virtual networks and IP Addresses >

• Add Rule > Action: Allow > Enter the API Management Public IP Address
• Add Rule > Action: Deny > 0.0.0.0/0

Policies in Azure API Management

API publishers can change API behavior through configuration using policies. Policies are a collection of statements that run sequentially on the request or response of an API.

• inbound - Modify the behavior of the request as it comes to API Management Service
• backend - Modify the way of the requests are forwarded to the web application
• outbound - Modify the way of the responses of the API Management Services
• on-error - Modify the way error is handled

Policies can be defined for All Operations or per operation.

<policies>
    <inbound>
    <!-- statements to be applied to the request go here -->
    </inbound>
    <backend>
    <!-- statements to be applied before the request is forwarded to 
        the backend service go here -->
    </backend>
    <outbound>
    <!-- statements to be applied to the response go here -->
    </outbound>
    <on-error>
    <!-- statements to be applied if there's an error condition go here -->
    </on-error>
</policies>

Example Policies

IP Filter

<inbound>
    <base />
    <ip-filter action="forbid">
        <address>127.0.0.1</address>
    </ip-filter>
</inbound>

Rewrite URL

<inbound>
    <base />
    <set-variable name="id" value="@(context.Request.Url.Query.GetValueOrDefault("id"))" />
    <rewrite-uri template="@{return "/api/Course/"+ context.Variables.GetValueOrDefault<string>("id");}" />
</inbound>

Return Response

<outbound>
    <base />
    <choose>
        <when condition="@(context.Response.StatusCode == 200)">
            <return-response>
                <set-status code="200" reason="OK" />
                <set-header name="Response-reason" exists-action="override">
                    <value>"Returned course list"</value>
                </set-header>
                <set-body>@{ 
                string text = context.Response.Body.As<string>(preserveContent: true);                      
                return text; 
                }</set-body>
            </return-response>
        </when>
    </choose>
</outbound>

Cache (internal cache example)

*duration is in seconds

<policies>
    <inbound>
        <base />
        <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" must-revalidate="true" caching-type="internal" />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <cache-store duration="60" />
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

Azure Cosmos DB

Azure Cosmos DB offers five well-defined levels. From strongest to weakest, the levels are:

• Strong reads are guaranteed to retun the most recent committed version of an item.
• Bounded staleness reads might lag behind the writes by at most “K” versions of an item or “T” time interval. This consistency level is used to manage the lag of data between any two regions based on an updated version of an item or the time intervals between read and write.
• Consistent Prefix different regions might see different versions or updates of the item, but they will never see an out of order write. This level ensures that updats made as a batch within a transaction are returned consistently with transaction in which they are committed.
• Eventual clients in other regions might see older versions of an item, eventually the item will be of the most recent update. This consistency level is used when no ordering guarantee is required.

Components

• Lease Container component serves as a storage mechanism to manage state accross multiple change feed consumers.
• Delegate component is the code within the client application that implements business logic for each batch of changes.
• Compute Instance is a client application instance that listens for changes from the change feed.
• Monitored Container componenet is monited for any insert or update operations.

Azure Storage

Delegate access with a shared access signature

A shared access singature (SAS) is a URI that grants restricted access right to Azure Storage resources.

• Account SAS Account level access, Blobstorage ( including Data Lake Storage and dfs endpoints), Queue Storage, Table Storage, or Azure Files are supported. With account SAS, you can:

  • Delegate access to service-level operations that aren’t currently available with a service-specific SAS, such as the Get/Set Service Properties and Get Service Stats Operations
  • Delegate access more than one service, i.e: BLob storage and Azure Files
  • Delegate access to write and delete operations for containers, queues, tables and file shares, which are not available with an object-specific SAS
  • Specify an IP address pr a range of IP addresses from which to accept requests.
  • Specify the HTTP protocol

• Service SAS delegates access to a resource in just one of the storage services.

• User Delegation SAS delegated by Microsoft Entra credentials or an account key. Blob Storage and Data Lake storage are supported.

• Stored Access Policy provides an additional level of control over service-level shared access signatures (SASs) on the server side. You can use a stored access policy to change the start time, expiry time, or permissions for a signature. You can also use a stored accss policy to revoke a signature after it has been issued. Blob Containers, File Shares, Queues and Tables are supported.

Monitoring

• Applications Insights allows you to create web tests that simulate user intereactions with your application and then set up alerts based on the results of these tests.
• Azure Monitor Resourse Health alerts are used for infrastructure monitoring
• Azure Service Health provides information about Azure services issues and planned maintanance
• Azure Advisor provides best practice recommendations
• Live Metrics provides real-time observation of application’s activity, allowing for immediate detection and response to performance issues.

Powershell Commands

Navigating with the account

• az logout
• az login --tenant "<tenantId>" --scope "https://management.core.windows.net//.default"
• Show current subscription az account show
• List all subscriptions az account list
• Switch to another subscription az account set --subscription "<name>" you get name from the list above, name field

Create an App Configuration store

• az group create --name <resourceGroupName> --location <location>

• az appconfig create --location <location> --name <name> --resource-group <resourceGroupName>

  (MissingSubscriptionRegistration) The subscription is not registered to use namespace ‘Microsoft.AppConfiguration’.

  When there is an error like this about any other service;

  1- Go to portal

  2- Find the subscription

  3- Go to details

  4- Find Resource Providers, and search for the missing registration item

  5- Select and Click register, and re-try

• az appconfig kv set --name <name> --key TestApp:Settings:TextAlign --value center