Microsoft AZ-204 Practice Test - Questions Answers, Page 18

Number of VM instances: 4

You are not charged extra for deployment slots.

Pricing tier: Isolated The App Service Environment (ASE) is a powerful feature offering of the Azure App Service that gives network isolation and improved scale capabilities. It is essentially a deployment of the Azure App Service into a subnet of a customer's

Azure Virtual Network (VNet).

Reference:

https://azure.microsoft.com/sv-se/blog/announcing-app-service-isolated-more-power-scale-and-ease-of-use/

Box 1: Deployment

To deploy Azure Functions to Kubernetes use the func kubernetes deploy command has several attributes that directly control how our app scales, once it is deployed to Kubernetes.

Box 2: ScaledObject

With --polling-interval, we can control the interval used by KEDA to check Azure Service Bus Queue for messages.

Example of ScaledObject with polling interval

apiVersion: keda.k8s.io/v1alpha1

kind: ScaledObject

metadata:

name: transformer-fn

namespace: tt

labels:

deploymentName: transformer-fn

spec:

scaleTargetRef:

deploymentName: transformer-fn

pollingInterval: 5

minReplicaCount: 0

maxReplicaCount: 100

Box 3: Secret

Store connection strings in Kubernetes Secrets.

Example: to create the Secret in our demo Namespace:

# create the k8s demo namespace

kubectl create namespace tt

# grab connection string from Azure Service Bus

KEDA_SCALER_CONNECTION_STRING=$(az servicebus queue authorization-rule keys list \

-g $RG_NAME \

--namespace-name $SBN_NAME \

--queue-name inbound \

-n keda-scaler \

--query "primaryConnectionString" \

-o tsv)

# create the kubernetes secret

kubectl create secret generic tt-keda-auth \

--from-literal KedaScaler=$KEDA_SCALER_CONNECTION_STRING \

--namespace tt

Reference:

https://www.thinktecture.com/en/kubernetes/serverless-workloads-with-keda/

Box 1: az appservice plan create

The azure group creates command successfully returns JSON result. Now we can use resource group to create a azure app service plan

Box 2: az webapp create

Create a new web app..

Box 3: --plan $webappname

..with the serviceplan we created in step 1.

Box 4: az webapp deployment

Continuous Delivery with GitHub. Example:

az webapp deployment source config --name firstsamplewebsite1 --resource-group websites--repo-url $gitrepo --branch master --git-token $token

Box 5: --repo-url $gitrepo --branch master --manual-integration

Reference:

https://medium.com/@satish1v/devops-your-way-to-azure-web-apps-with-azure-cli-206ed4b3e9b1

Accessing the client certificate from App Service.

If you are using ASP.NET and configure your app to use client certificate authentication, the certificate will be available through the HttpRequest.ClientCertificate property. For other application stacks, the client cert will be available in your app through a base64 encoded value in the "X-ARR-ClientCert" request header. Your application can create a certificate from this value and then use it for authentication and authorization purposes in your application.

Reference:

https://docs.microsoft.com/en-us/azure/app-service/app-service-web-configure-tls-mutual-auth

You can host native Linux applications in the cloud by using Azure Web Apps. To create a Web App for Containers, you must run Azure CLI commands that create a group, then a service plan, and finally the web app itself.

Step 1: az group create

In the Cloud Shell, create a resource group with the az group create command.

Step 2: az appservice plan create

In the Cloud Shell, create an App Service plan in the resource group with the az appservice plan create command.

Step 3: az webapp create

In the Cloud Shell, create a web app in the myAppServicePlan App Service plan with the az webapp create command. Don't forget to replace with a unique app name, and <docker-ID> with your Docker ID.

Reference:

https://docs.microsoft.com/mt-mt/azure/app-service/containers/quickstart-docker-go?view=sql-server-ver15

Step 1: #bin/bash

The appName is used when the webapp-name is created in step 2.

Step 2: az webapp config hostname add

The webapp-name is used when the webapp is created in step 3.

Step 3: az webapp create

Create a web app. In the Cloud Shell, create a web app in the myAppServicePlan App Service plan with the az webapp create command.

Step : az webapp confing container set

In Create a web app, you specified an image on Docker Hub in the az webapp create command. This is good enough for a public image. To use a private image, you need to configure your Docker account ID and password in your Azure web app.

In the Cloud Shell, follow the az webapp create command with az webapp config container set.

Reference:

https://docs.microsoft.com/en-us/azure/app-service/containers/tutorial-custom-docker-image

Step 1: Create the Azure Functions app with a Consumption plan type.

Use the Consumption plan for serverless.

Step 2: Create a system-assigned managed identity for the application.

Create a system-assigned managed identity for your application.

Key Vault references currently only support system-assigned managed identities. User-assigned identities cannot be used.

Step 3: Create an access policy in Key Vault for the application identity.

Create an access policy in Key Vault for the application identity you created earlier. Enable the "Get" secret permission on this policy. Do not configure the "authorized application" or applicationId settings, as this is not compatible with a managed identity.

Reference:

https://docs.microsoft.com/en-us/azure/app-service/app-service-key-vault-references

Windows Azure Web Sites (WAWS) offers 3 modes: Standard, Free, and Shared.

Standard mode carries an enterprise-grade SLA (Service Level Agreement) of 99.9% monthly, even for sites with just one instance.

Standard mode runs on dedicated instances, making it different from the other ways to buy Windows Azure Web Sites.

Incorrect Answers:

B: Shared and Free modes do not offer the scaling flexibility of Standard, and they have some important limits.

Shared mode, just as the name states, also uses shared Compute resources, and also has a CPU limit. So, while neither Free nor Shared is likely to be the best choice for your production environment due to these limits.

Box 1: group

# Create a resource group.

az group create --location westeurope --name myResourceGroup

Box 2: appservice plan

# Create an App Service plan in STANDARD tier (minimum required by deployment slots).

az appservice plan create --name $webappname --resource-group myResourceGroup --sku S1

Box 3: webapp

# Create a web app.

az webapp create --name $webappname --resource-group myResourceGroup \

--plan $webappname

Box 4: webapp deployment slot

#Create a deployment slot with the name "staging".

az webapp deployment slot create --name $webappname --resource-group myResourceGroup \

--slot staging

Box 5: webapp deployment source

# Deploy sample code to "staging" slot from GitHub.

az webapp deployment source config --name $webappname --resource-group myResourceGroup \

--slot staging --repo-url $gitrepo --branch master --manual-integration

Reference:

https://docs.microsoft.com/en-us/azure/app-service/scripts/cli-deploy-staging-environment