Develop Azure Compute Solutions Flashcards

Question 1

Q

What are the azure Container Registry service tiers and what differentiates them? [5]

Answer

A

1) Basic
2) Standard ([4] has more storage and image throughput than basic)
3) Premium ([5] adds features such as geo-replication, supports content-trust for image-tag-signing and it supports private link with private end points)

Question 2

Q

Is an Azure Container Registry image read-only? [1]

Answer

A

[1] Yes, it is a read-only snapshot of a Docker-compatible container.

Question 3

Q

Can Azure container registries support Windows images, Linux images or both types of images? [1]

Answer

A

[1] Both are supported.

Question 4

Q

What other than container images do Azure Container Registries store? [2]

Answer

A

[1] Helm charts and [2] images built on the Open Container Initiative (OCI) Image Format Specification.

Question 5

Q

What do Azure Container Registry Tasks (ACR Tasks) allow for? [4]

Answer

A

The streamlining of [1] building, [2] testing, [3] pushing, and [4] deploying images in Azure

Question 6

Q

What are the features of Azure Container Instances? [8] + [1] updated

Answer

A

[1] Fast startup times – Containers can start in seconds, no need to provision a VM.
[2] Public IP connectivity and DNS – Containers can be exposed to the internet with IP and domain name.
[3] Hypervisor-level security – Container applications are as isolated as they would be in a VM.
[4] Custom sizes – Containers can scale dynamically to match resource demand for an application.
[5] Persistent storage – Containers support direct mounting of Azure file shares.
[6] Linux and Windows Containers – The same API is used to schedule both Linux and Windows containers.
[7] Co-scheduled groups - Container Instances support multi-container container groups that share host machine resources.
[8] Virtual network deployment – Container instances can be deployed into an Azure virtual network.
[9] Customer data: The ACI service stores the minimum customer data required to ensure your container groups are running as expected

Question 7

Q

What are the two common ways to deploy a multi-container group? [2]

Answer

A

[1] ARM template or [2] YAML file.

Question 8

Q

In Container Instances, what is a container group? [3]

Answer

A

A container group is a [1] collection of containers [2] that get scheduled on the same host machine. [3] The containers in a container group share a lifecycle, resources, local network, and storage volumes. It’s similar in concept to a pod in Kubernetes.

https://learn.microsoft.com/en-us/azure/container-instances/container-instances-container-groups

Question 9

Q

How do resources such as CPUs and memory get allocated to a container group? [1]

Answer

A

Azure Container Instances allocates resources such as CPUs, memory, and optionally GPUs (preview) to a multi-container group [1] by adding the resource requests of the instances in the group. Taking CPU resources as an example, if you create a container group with two container instances, each requesting 1 CPU, then the container group is allocated 2 CPUs.

https://learn.microsoft.com/en-us/azure/container-instances/container-instances-container-groups

Question 10

Q

In Container Instance networks, what two things do container groups share? [2]

Answer

A

[1] IP address and [2] port namespace.

Question 11

Q

In Container Instance storage, what external volumes can you specify to mount within a container group? [4]

Answer

A

[1] Azure file share

[2] Secret

[3] Empty directory

[4] Cloned git repo

You can map those volumes into specific paths within the individual containers in a group.
https://learn.microsoft.com/en-us/azure/container-instances/container-instances-container-groups

Question 12

Q

In Container Instances, when are multi-container groups useful? [1]

Answer

A

[1] In cases where you want to divide a single functional task into a small number of container images.

Example usage could include:

A container serving a web application and a container pulling the latest content from source control.

An application container and a logging container. The logging container collects the logs and metrics output by the main application and writes them to long-term storage.

An application container and a monitoring container. The monitoring container periodically makes a request to the application to ensure that it’s running and responding correctly, and raises an alert if it’s not.

A front-end container and a back-end container. The front end might serve a web application, with the back end running a service to retrieve data.

https://learn.microsoft.com/en-us/azure/container-instances/container-instances-container-groups

Question 13

Q

What 4 things can you dynamically scale an Azure Container App on? [4]

Answer

A

[1] HTTP traffic

[2] Event-driven processing

[3] CPU or memory load

[4] Any Kubernetes Event-driven Autoscaling (KEDA) supported scaler

Question 14

Q

What is Kubernetes Event-driven Autoscaling (KEDA)? [4]

Answer

A

Kubernetes Event-driven Autoscaling (KEDA) is a single-purpose and lightweight component that [1] strives to make application autoscaling simple and is a CNCF Incubation project.

[2] It applies event-driven autoscaling to scale your application to meet demand [3] in a sustainable

[4] and cost-efficient manner with scale-to-zero.
https://learn.microsoft.com/en-us/azure/aks/keda-about

Question 15

Q

What can Azure Container Apps allow you to do? [4]

Answer

A

[1] Deploy API endpoints

[2] Host background processing applications

[3] Handle event-driven processing

[4] Run microservices

Question 16

Q

What is an App Service Plan?

Answer

A

It defines [1] a set of compute resources for a web app to run. One or more apps can be configured to run on the same computing resources.

Question 17

Q

In terms of app service plans, how does a web service web app run and scale? [5] UPDATED

Answer

A

[1] In free and shared tiers, an app receives CPU minutes on a shared VM instance and can’t scale out. [2] In other tiers, an app runs on all the VM instances configured in the App Service plan.

[3] If multiple apps are in the same App Service plan, they all share the same VM instances.

[4] If you have multiple deployment slots for an app, all deployment slots also run on the same VM instances.

[5] If you enable diagnostic logs, perform backups, or run WebJobs, they also use CPU cycles and memory on these VM instances.

In this way, the App Service plan is the scale unit of the App Service apps. If the plan is configured to run five VM instances, then all apps in the plan run on all five instances. If the plan is configured for autoscaling, then all apps in the plan are scaled out together based on the autoscale settings.

Question 18

Q

What if a web service web app needs more capabilities or features? [1]

Answer

A

[1] Your App Service Plan can be scaled up and down at any time.

Question 19

Q

Can an App Service Plan host multiple web apps? [1]

Answer

A

[1] Yes, it can.

Question 20

Q

Can an App Service Plan host multiple web apps? [1]

Answer

A

[1] Yes, it can.

Question 21

Q

Do web apps support near instant scaling as well as auto scaling? [1]

Question 22

Q

Why might you separate different app service web apps into their own app service plan? [2]

Answer

A

[1] Because the different web apps in the app service plan will share and compete for the resources in that plan. [2] And all those app will scale together making it uneconomical.

Question 23

Q

What is Azure App Service? [4]

Answer

A

[1] It is a HTTP-based service for [4] hosting web application, [2] REST APIs and [3] mobile back ends.

Question 24

Q

What tiers support auto scaling in app service web apps? And what kind of scaling does it support? [2]

Answer

A

[1] Standard tier and above and [2] only supports scaling in/out.

Question 25

Q

Can you autoscale up/down in app service web apps? [1]

Answer

A

[1] No, it can only be done manually.

Question 26

Q

What does CI/CD stand for? [1]

Answer

A

[1] Continuous Integration / Continuous Delivery

Question 27

Q

Does app service web apps support Continuous Integration / Continuous Delivery (CI/CD) and if so, from what technologies? [6]

Answer

A

[1] Yes, [2] Azure DevOps, [3] GitHub, [4] Bitbucket, [5] FTP (file transfer protocol, a standard for the exchange of program and data files across a network), or [6] local Git repository on your local machine.

Question 28

Q

Can you use deployment slots in app service web apps? [1]

Question 29

Q

Can you host an App Service natively on Linux? [1]

Question 30

Q

Can you mix Windows and Linux apps on the same app service plan? [1]

Question 31

Q

What do you need to remember about setting Application Settings in App Service, App settings? [2]

Answer

A

[1] It sets environmental settings in the App. [2] What you add in Applications will override settings put in the .config ect.

Question 32

Q

Can you tie Application Settings in App Service to a specific deployment slot? [1]

Answer

A

[1] Yes, you can.

Question 33

Q

Is it possible to store a secrete in Azure Key Vault and then reference the secret in Application Settings in App Service? [1]

Question 34

Q

What are the automated deployment tools that App Service offers? [3]

Answer

A

[1] Azure DevOps
[2] GitHub
[3] Bitbucket

Question 35

Q

What are the manual deployment tools that App Service offers? [4]

Answer

A

[1] Git
[2] CLI
[3] ZipDeploy
[4] FTP/S

Question 36

Q

In App Service configuration settings, what are the options for configuring Secure Socket Layer (TLL/SSL)? [7]

Answer

A

[1] Buy and import App Service certificate
[2] Import a certificate from Key Vault
[3] Upload a public/private certificate
[4] Renew an expiring/uploaded/App Service certificate
[5] Renew a certificate imported from Key Vault
[6] Manage App Service certificates
[7] Automate with scripts

Question 37

Q

In App Service configuration settings, which of these allows you to set the software stack to run the app, including the language and SDK version? [1]

[1] Platform setting [2] Stack settings [3] Incoming client certificates [4] Debugging.

Answer

A

Stack settings

Question 38

Q

In App Service configuration settings, which of these allows you to set Configuration settings for hosting the platform, Bit (32/64 bit), WebSocket protocol, always on, managed pipeline version, HTTP version, ARR affinity. [1]

[1] Platform setting [2] Stack settings [3] Incoming client certificates [4] Debugging

Answer

A

Platform settings

Question 39

Q

In App Service configuration settings, which of these allows you to set Configuration settings for Enabling remote debugging for ASP.NET, ASP,NET Core, or Node.js apps. [1]

[1] Platform setting [2] Stack settings [3] Incoming client certificates [4] Debugging

Answer

A

Debugging

Question 40

Q

In App Service configuration settings, which of these allows you to set Configuration settings for requiring client certificates in mutual authentication. TLS mutual authentication is used to restrict access to your app by enabling different types of authentications for it. [1]

[1] Platform setting [2] Stack settings [3] Incoming client certificates [4] Debugging

Answer

A

Incoming client certificates

Question 41

Q

What is the difference between SSL and TLS? [1]

Answer

A

[1] TLS is an updated, more secure version of SSL.

Question 42

Q

What is autoscaling? [1]

Answer

A

[1] Adjust available resources based on current demand. Autoscale performs scaling in and out as apposed to scaling up and down.

Question 43

Q

In Azure App Service, what does autoscaling use to scale resources? And what would happen if you didn’t autoscale an application?[2]

Answer

A

It uses [1] resource Metrix to detect when additional resources are required to handle increasing workloads [2] and ensure that those resources are available before the system become overloaded.

Question 44

Q

What are the three main characteristics of autoscaling? [3]

Answer

A

[1] Provides elasticity.
[2] Improves Availability and [3] fault tolerance.

Question 45

Q

How does autoscaling work? [1]

Answer

A

[1] Autoscaling works by adding and removing servers.

Question 46

Q

When is autoscaling not the best approach? [1]

Answer

A

[1] When handling long-term growth

Question 47

Q

In Azure App Service, where can you monitor autoscaling activity? [2]

Answer

A

[1] The ‘Run History’ chart shows how the number of instances varies over time [2] and which autoscale conditions caused each change.

Question 48

Q

In Azure App Service, what is the difference between a scale condition and a scale rule? [2]

Answer

A

[1] The scale condition is the point in which autoscaling will occur, and [2] the scale rule is what will happen once the condition has been met.

Question 49

Q

Where can you configure these options when deploying an App Service ?

[1] Buy and import App Service certificate
[2] Import a certificate from Key Vault
[3] Upload a public/private certificate
[4] Renew an expiring/uploaded/App Service certificate
[5] Renew a certificate imported from Key Vault
[6] Manage App Service certificates
[7] Automate with scripts

Answer

A

App Service configuration settings, for configuring Secure Socket Layer (TLS/SSL)

Question 50

Q

In Azure App Service, if there are multiple auto scale rules that trigger at the same time. Which rule will be triggered? [1]

Answer

A

[1] The rule that allocates the most resources.

Question 51

Q

What are the best practices in Autoscaling? [6]

Answer

A

Ensure that the maximum and minimum values are different and have an adequate margin between them.
Chose the appropriate statistic for your diagnosis metric.
Choose the threshold carefully for all metric types.
Remember the rules for scaling when multiple rules are configured in a profile.
Always set a safe default instance count.
Configure autoscale notifications.

Question 52

Q

What does the term ‘flapping’ mean in autoscaling? [1]

Answer

A

[1] Flapping is when you have set the same minimum and maximum value for an autoscale condition, causing the service to scale in and out really quickly.

Question 53

Q

In Azure Functions, what are the two parts of a function? [2]

Answer

A

Your code
Some config (function.json)

Question 54

Q

In Azure Functions, what does function.json file do? [2]

Answer

A

It defines the functions [1] trigger, bindings, and [2] other configuration settings. The runtime uses the config (function.json) file to determine the events to monitor and how to pass data and return data from the function execution.

Question 55

Q

Do functions, in a Function App, share the same pricing plan, deployment method and runtime version? [1]

Answer

A

[1] Yes, they do.

Question 56

Q

What is a binding in an Azure function? And what can be set? [4]

Answer

A

[1] It’s a way of connecting to another resource to the function. They [2] can be input [3] or output bindings [4] or both.

Question 57

Q

In a Function App, what languages are supported for creating functions and how are the triggers and bindings defined? [6]

Answer

A

[1] C# class library – decorating methods and parameters
[2] Java – decorating methods and parameters
[3] JavaScript, [4] PowerShell, [5] Python, [6] TypeScript – Updating function.json schema

Question 58

Q

Which Azure Service Plan pricing tier is available only to the function apps? [1]
1. Shared compute
2. Dedicated Compute
3. Consumption
4. Isolated

Answer

A

[1] Consumption

Question 59

Q

What are the steps that you need to follow to create a container? And also publish it to ACR [7]

Answer

A

[1] Create your application
[2] Install and Run Docker Desktop
[3] Run Visual Studio Container Tools
[4] Add Docker Support to the application and select target OS (Docker file will then be added to solution containing the details for building for Docker)
[5] Publish to Azure Container Registry
[6] In the Azure Portal enable Admin User under the Access Key Settings (Allows me to add image to Azure using Azure CLI, PowerShell or Portal)
[7] Now Create Container Instance or Azure Web App and deploy Container image that is in the Azure Container Registry

Question 60

Q

In Azure Container Registry, what are the use cases and the applications that would pull container images? [9]

Answer

A

[1] Scalable orchestration systems that manage containerized applications across clusters of hosts, [2] including Kubernetes, [3] DC/OS, [4] and Docker Swarm.

[5] Azure services that support building and running applications at scale, including [6] Azure Kubernetes Service (AKS), [7] App Service, [8] Batch, [9] Service Fabric, and others.

Question 61

Q

In Azure Container Registry, developers can push to a container registry as part of a container development workflow as part of their continuous integration and delivery tools, where from? [2]

Answer

A

[1] Azure Pipelines or [2] Jenkins

Question 62

Q

In Azure Container Registry ACR Tasks, what kind of scenarios would you configure for? [3]

Answer

A

[1] Automatically rebuild application images when their base images are updated
[2] Automate image builds when your team commits code to a Git repository
[3] Create multi-step tasks to automate building, testing, and patching multiple container images in parallel in the cloud.

Question 63

Q

In Azure Container Registry ACR Tasks, what do build tasks do and when? [2]

Answer

A

Configure build tasks to [1] automate your container OS and framework patching pipeline, and [2] build images automatically when your team commits code to source control.

Question 64

Q

In Azure Container Registry, what storage capabilities does it have? [5]

Answer

A

[1] Encryption-at-rest: All container images in your registry are encrypted at rest. Azure automatically encrypts an image [2] before storing it, and decrypts it on-the-fly when you or your applications and services pull the image.

[3] Regional storage: Azure Container Registry stores data in the region where the registry is created, to help customers meet data residency and compliance requirements. In all regions except Brazil South and Southeast Asia.

[4] Zone redundancy: A feature of the Premium service tier, zone redundancy uses Azure availability zones to replicate your registry to a minimum of three separate zones in each enabled region.

[5] Scalable storage: Azure Container Registry allows you to create as many repositories, images, layers, or tags as you need, up to the registry storage limit.

High numbers of repositories and tags can impact the performance of your registry. Periodically delete unused repositories, tags, and images as part of your registry maintenance routine. Deleted registry resources like repositories, images, and tags can’t be recovered after deletion.

Answer 60

A

[1] Quick task - Build and push a single container image to a container registry on-demand, in Azure, without needing a local Docker Engine installation.
[2] Automatically triggered tasks - Enable one or more triggers to build an image:
Trigger on source code update
Trigger on base image update
Trigger on a schedule
[3] Multi-step task - Extend the single image build-and-push capability of ACR Tasks with multi-step, multi-container-based workflows.

Answer 61

A

[1] Its the location of a set of source files used to build a container image or other artifact. [2] Example contexts include a Git repository or [3] a local filesystem.

Answer 62

A

Trigger a container image build or multi-step task when [1] code is committed, or [2] a pull request is made or [3] updated, to a [4] Git repository in GitHub or [5] Azure DevOps Services.

For example, configure a build task with the Azure CLI command az acr task create by specifying a Git repository and optionally a branch and Dockerfile. When your team updates code in the repository, an ACR Tasks-created webhook triggers a build of the container image defined in the repo.

Answer 63

A

Optionally schedule a task [1] by setting up one or more timer triggers when you create or update the task. [2] Scheduling a task is useful for running container workloads on a defined schedule, [3] or running maintenance operations or [4] tests on images pushed regularly to your registry.

Answer 64

A

[1] Windows and [2] Linux

Answer 65

A

You can set up an ACR task to track a dependency on a base image when it builds an application image. [1] When the updated base image is pushed to your registry, or [2] a base image is updated in a public repo such as in Docker Hub, ACR Tasks can automatically build any application images based on it.

Answer 66

A

[1] It comes from a Docker Image. [2] A Dockerfile is a script that contains a series of instructions that are used to build a Docker image.

Answer 67

A

Use the .NET 6 runtime as a base image
FROM mcr.microsoft.com/dotnet/runtime:6.0

Set the working directory to /app
WORKDIR /app

Copy the contents of the published app to the container’s /app directory
COPY bin/Release/net6.0/publish/ .

Expose port 80 to the outside world
EXPOSE 80

Set the command to run when the container starts
CMD [“dotnet”, “MyApp.dll”]

//////////////////////////////////////////////////////////////////
FROM mcr.microsoft.com/dotnet/runtime:6.0: This command sets the base image to the .NET 6 runtime, which is needed to run .NET 6 apps.
WORKDIR /app: Sets the working directory to /app, which is where app files are copied.
COPY bin/Release/net6.0/publish/ .: Copies the contents of the published app to the container’s /app directory. We assume that the .NET 6 app has already been built and published to the bin/Release/net6.0/publish directory.
EXPOSE 80: Exposes port 80, which is the default HTTP port, to the outside world. Change this line accordingly if your app listens on a different port.
CMD [“dotnet”, “MyApp.dll”]: The command to run when the container starts. In this case, we’re running the dotnet command with the name of our app’s DLL file (MyApp.dll). Change this line to match your apps name and entry point.

Answer 68

A

az group create –name az204-acr-rg –location <myLocation></myLocation>

Answer 69

A

az acr create –resource-group az204-acr-rg –name <myContainerRegistry> --sku Basic</myContainerRegistry>

Answer 70

A

echo FROM mcr.microsoft.com/hello-world > Dockerfile

Answer 71

A

Multi-step tasks, [1] defined in a YAML file [2] specify individual build and push operations for container images or [3] other artifacts. [4] They can also define the execution of one or more containers, with each step using the container as its execution environment.

Build a web application image
Run the web application container
Build a web application test image
Run the web application test container, which performs tests against the running application container
If the tests pass, build a Helm chart archive package
Perform a helm upgrade using the new Helm chart archive package

Answer 72

A

The base or parent image we use to create the new image
Commands to update the base OS and install other software
Build artifacts to include, such as a developed application
Services to expose, such a storage and network configuration
Command to run when the container is launched

Answer 73

A

[1] When you use the echo command, it simply prints the text you provide as arguments to the terminal screen.

Answer 74

A

[1] The . at the end of the command tells the az acr build command that the current directory should be used as the build context, and it’s where the command will look for the specified Dockerfile and any other files needed for the build process.

[2] The backslash at the end of each line indicates to the shell that the command is not yet complete and continues on the next line.

Answer 75

A

az acr repository show-tags –name <myContainerRegistry> \
--repository sample/hello-world --output table</myContainerRegistry>

[1] A “tag” is a label applied to a specific version of an image. [2] Tags are used to identify and differentiate different versions of the same image within a container registry. They’re particularly useful for managing and referencing different states or variations of an application or service.

Answer 76

A

[1] az acr run –registry <myContainerRegistry> --cmd '$Registry/sample/hello-world:v1' /dev/null</myContainerRegistry>

/dev/null: This is used as the input file for the command. [1] When a command’s input is redirected from /dev/null, it effectively means that the command won’t receive any input. It’s like sending an empty stream to the command.

Answer 77

A

The –no-wait flag is used to instruct the Azure CLI to not wait for the completion of the resource group deletion operation before returning control to the user. In other words, [1] when you include the –no-wait flag, the command will initiate the deletion of the specified resource group and immediately return to the command prompt, allowing you to continue working without waiting for the deletion process to finish.

Answer 78

A

az acr repository show-tags –name <myContainerRegistry> \
--repository sample/hello-world --output table</myContainerRegistry>

Answer 79

A

az group delete –name az204-acr-rg –no-wait

Answer 80

A

[1] A Resource Manager template is recommended when you need to deploy additional Azure service resources (for example, an Azure Files share) when you deploy the container instances. [2] Due to the YAML format’s more concise nature, a YAML file is recommended when your deployment includes only container instances.

Answer 81

A

az acr repository list –name <myContainerRegistry> --output table</myContainerRegistry>

Answer 82

A

[1] With a configurable restart policy, you can specify that your containers are stopped when their processes have completed. Because container instances are billed by the second, you’re charged only for the compute resources used while the container executing your task is running.

Answer 83

A

Always - Containers in the container group are always restarted. This is the default setting applied when no restart policy is specified at container creation.

Never - Containers in the container group are never restarted. The containers run at most once.

OnFailure - Containers in the container group are restarted only when the process executed in the container fails (when it terminates with a nonzero exit code). The containers are run at least once.

Answer 84

A

az container create \
–resource-group myResourceGroup \
–name mycontainer \
–image mycontainerimage \
–restart-policy OnFailure

Answer 85

A

Terminated

Answer 86

A

Setting environment variables in your container instances [1] allows you to provide dynamic configuration of the application or script run by the container.

If you need to pass secrets as environment variables, Azure Container Instances supports secure values for both Windows and Linux containers.

Answer 87

A

You can only mount Azure Files shares to Linux containers.

Answer 88

A

[1] By default, Azure Container Instances are stateless. If the container crashes or stops, all of its state is lost. [2] To persist state beyond the lifetime of the container, you must mount a volume from an external store.

Answer 89

A

az container create \
–resource-group myResourceGroup \
–name mycontainer2 \
–image mcr.microsoft.com/azuredocs/aci-wordcount:latest
–restart-policy OnFailure \

//////////////////////////////////////////////////////////////////////////
[1] –environment-variables ‘NumWords’=’5’ ‘MinLength’=’8’\

Answer 90

A

[1] Objects with secure values are intended to hold sensitive information like passwords or keys for your application. Using secure values for environment variables is both safer and more flexible than including it in your container’s image.

[2] Environment variables with secure values aren’t visible in your container’s properties. [3] Their values can be accessed only from within the container. For example, container properties viewed in the Azure portal or Azure CLI display only a secure variable’s name, not its value.

Answer 91

A

YAML file
apiVersion: 2018-10-01
location: eastus
name: securetest
properties:
containers:
- name: mycontainer
properties:
environmentVariables:
- name: ‘NOTSECRET’
value: ‘my-exposed-value’
- name: ‘SECRET’
secureValue: ‘my-secret-value’
image: nginx
ports: []
resources:
requests:
cpu: 1.0
memoryInGB: 1.5
osType: Linux
restartPolicy: Always
tags: null
type: Microsoft.ContainerInstance/containerGroups

Answer 92

A

[1] Deploying by YAML template is the preferred method when deploying container groups consisting of multiple containers.

Answer 93

A

You must deploy using an [1] Azure Resource Manager template or [2] a YAML file.

Answer 94

A

Distributed Application Runtime

Answer 95

A

az provider register –namespace Microsoft.App

Answer 96

A

az provider register –namespace Microsoft.OperationalInsights

Answer 97

A

myRG=az204-appcont-rg

myLocation=<location></location>

myAppContEnv=az204-env-$RANDOM

Var name [1]
= [2]
Value [3]

Answer 98

A

–location $myLocation
[1] $

Answer 99

A

[1] An environment in Azure Container Apps creates a secure boundary around a group of container apps. Container Apps deployed to the same environment [2] are deployed in the same virtual network and [3] write logs to the same Log Analytics workspace.

Answer 100

A

[1] A federated identity provider is a trusted provider that lets you use single sign-on (SSO) to access other websites or applications1. It is a part of a federated identity management system, which is a configuration between two or more domains that allows users to use the same digital identity across them2. A federated identity provider authenticates the user and provides an authentication token to the service provider, which is the website or application that relies on the identity provider34.

Answer 101

A

az acr build –image sample/hello-world:v1 –registry <myContainerRegistry> --file Dockerfile .</myContainerRegistry>

Answer 102

A

az container create –resource-group myResourceGroup –file secure-env.yaml

Answer 103

A

[1] True

When a secret is updated or deleted, you can respond to changes in one of two ways:

[2] Deploy a new revision.

[3] Restart an existing revision.

Before you delete a secret, deploy a new revision that no longer references the old secret. Then deactivate all revisions that reference the secret.

Answer 104

A

–secrets

Answer 105

A

–secrets “secret1=$SECRET1_VALUE” “secret2=$SECRET2_VALUE” “secret3=$SECRET3_VALUE”

Answer 106

A

–secrets “queue-connection-string=$CONNECTIONSTRING” \
–env-vars “QueueName=myqueue” “ConnectionString=secretref:queue-connection-string”

Answer 107

A

az extension add –name containerapp –upgrade

Answer 108

A

[1] Yes, you can.

Azure Container Apps implements container app versioning by creating revisions. [2] A revision is an immutable snapshot of a container app version. You can use revisions to release a new version of your app, or quickly revert to an earlier version of your app. New revisions are created when you update your application with revision-scope changes. You can also update your container app based on a specific revision.
You can control which revisions are active, and the external traffic that is routed to each active revision. Revision names are used to identify a revision, and in the revision’s URL. You can customize the revision name by setting the revision suffix.

Answer 109

A

[1] Secrets are scoped to an application, outside of any specific revision of an application.

[2] Adding, removing, or changing secrets doesn’t generate new revisions.

[3] Each application revision can reference one or more secrets.

[4] Multiple revisions can reference the same secret(s).

Answer 110

A

[1] No

Container Apps doesn’t support Azure Key Vault integration. [2] Instead, enable managed identity in the container app [3] and use the Key Vault SDK in your app to access secrets.

Answer 111

A

[1] Container Apps CLI
[2] Infrastructure as Code (IaC) templates, as in Bicep or Azure Resource Manager (ARM) templates
[3] The Azure portal

Answer 112

A

Microservice architectures allow you to independently develop, upgrade, version, and scale core areas of functionality in an overall system. Azure Container Apps provides the foundation for deploying microservices featuring:
[1] Independent scaling, [2] versioning, [3] and upgrades
[4] Service discovery
[5] Native Dapr integration

Answer 113

A

[1] Free and [2] Shared

Answer 114

A

Microsoft Identity Platform
/.auth/login/aad

Facebook
/.auth/login/facebook

GitHub
/.auth/login/github

Google
/.auth/login/google

Twitter
/.auth/login/twitter

Any OpenID Connect provider
/.auth/login/<providerName></providerName>

Answer 115

A

az containerapp revision list \
–name <APPLICATION_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
-o table</RESOURCE_GROUP_NAME></APPLICATION_NAME>

Answer 116

A

[1] Two applications never share the same compute resources
[2] Two Dapr applications can’t communicate via the Dapr service invocation API

Answer 117

A

Dapr stands for “Distributed Application Runtime.”

Dapr is an open-source runtime and framework.

Dapr simplifies building distributed applications.

It helps developers write microservices-based applications.

Dapr abstracts complexities of distributed systems.

Dapr provides building blocks and APIs.

Developers can create resilient applications with Dapr.

Dapr enables the creation of portable applications.

Dapr supports the development of scalable applications.

Dapr is not tied to specific programming languages or frameworks.

Answer 118

A

[1] Run multiple container revisions and manage the container app’s application lifecycle.

[2] Autoscale your apps based on any KEDA-supported scale trigger. Most applications can scale to zero. (Applications that scale on CPU or memory load can’t scale to zero.)

[3] Enable HTTPS ingress without having to manage other Azure infrastructure.

[4] Split traffic across multiple versions of an application for Blue/Green deployments and A/B testing scenarios.

[5] Use internal ingress and service discovery for secure internal-only endpoints with built-in DNS-based service discovery.

[6] Build microservices with Dapr and access its rich set of APIs.

[7] Run containers from any registry, public or private, including Docker Hub and Azure Container Registry (ACR).

[8] Use the Azure CLI extension, Azure portal or ARM templates to manage your applications.

[9] Provide an existing virtual network when creating an environment for your container apps.

[10] Securely manage secrets directly in your application.

[11] Monitor logs using Azure Log Analytics.

Answer 119

A

az webapp list-runtimes –os-type linux

Answer 120

A

[1] Service-to-service invocation - Discover services and perform reliable, direct service-to-service calls with automatic mTLS authentication and encryption.
[2]State management - Provides state management capabilities for transactions and CRUD operations.
[3] Pub/sub - Allows publisher and subscriber container apps to intercommunicate via an intermediary message broker.
[4] Bindings - Trigger your applications based on events
[5] Actors - Dapr actors are message-driven, single-threaded, units of work designed to quickly scale. For example, in burst-heavy workload situations.
[6] Observability - Send tracing information to an Application Insights backend.
[7] Secrets - Access secrets from your application code or reference secure values in your Dapr components.

Answer 121

A

[1] Basic, [2] Standard, [3] Premium, [4] PremiumV2, and [5] PremiumV3

The tiers run apps on dedicated Azure VMs. Only apps in the same App Service plan share the same compute resources. The higher the tier, the more VM instances are available to you for scale-out.

Answer 122

A

[1] Isolated and [2] IsolatedV2

The tiers run dedicated Azure VMs on dedicated Azure Virtual Networks. It provides network isolation on top of compute isolation to your apps. It provides the maximum scale-out capabilities.

Answer 123

A

App Service [1] Free and [2] Shared (preview) hosting plans are base tiers that run on the same Azure virtual machines as other App Service apps. Some apps might belong to other customers. These tiers are intended to be used only for development and testing purposes.

Answer 124

A

You can potentially save money [1] by putting multiple apps into one App Service plan. [2] However, since apps in the same App Service plan all share the same compute resources you need to understand the capacity of the existing App Service plan and the expected load for the new app.

Answer 125

A

Individual container apps are deployed to a single Container Apps environment.

The Container Apps environment acts as a secure boundary around groups of container apps.

Container Apps in the same environment are deployed in the same virtual network.

They write logs to the same Log Analytics workspace.

You have the option to provide an existing virtual network when creating an environment.

Answer 126

A

[1] Privileged containers: Azure Container Apps can’t run privileged containers. If your program attempts to run a process that requires root access, the application inside the container experiences a runtime error.

[2] Operating system: Linux-based (linux/amd64) container images are required.

Answer 127

A

[1] The app is resource-intensive.
[2] You want to scale the app independently from the other apps in the existing plan.
[3] The app needs resource in a different geographical region.
This way you can allocate a new set of resources for your app and gain greater control of your apps.

Answer 128

A

[1] Whenever possible, use deployment slots when deploying a new production build. When using a Standard App Service Plan tier or better, you can deploy your app to a staging environment and then swap your staging and production slots. [2] The swap operation warms up the necessary worker instances to match your production scale, thus eliminating downtime.

Answer 129

A

[1] No. You’re not required to use App Service for authentication and authorization. Many web frameworks are bundled with security features, and you can use them if you like. If you need more flexibility than App Service provides, you can also write your own utilities.

Answer 130

A

[1] Yes. App Service provides a built-in token store, which is a repository of tokens that are associated with the users of your web apps, APIs, or native mobile apps. [2] When you enable authentication with any provider, this token store is immediately available to your app.

Answer 131

A

[1] True. If you enable application logging, authentication and authorization traces are collected directly in your log files. [2] If you see an authentication error that you didn’t expect, you can conveniently find all the details by looking in your existing application logs.

Answer 132

A

[1] False.

Answer 133

A

Because there are many different customers in the same App Service scale unit, you can’t connect the App Service network directly to your network.

Answer 134

A

Dapr uses a modular design where functionality is delivered as a component. The use of Dapr components is optional and dictated exclusively by the needs of your application.

Dapr components in container apps are environment-level resources that:

[1] Can provide a pluggable abstraction model for connecting to supporting external services.

[2] Can be shared across container apps or scoped to specific container apps.

[3] Can use Dapr secrets to securely retrieve configuration metadata.

By default, all Dapr-enabled container apps within the same environment load the full set of deployed components. To ensure components are loaded at runtime by only the appropriate container apps, application scopes should be used.

Answer 135

A

[1] Manage related services
[2] Deploy different applications to the same virtual network
[3] Instrument Dapr applications that communicate via the Dapr service invocation API
[4] Have applications to share the same Dapr configuration
[5] Have applications share the same log analytics workspace

Answer 136

A

The authentication and authorization module runs in the same sandbox as your application code. When it’s enabled, every incoming HTTP request passes through it before being handled by your application code. This module handles several things for your app:

[1] Authenticates users and clients with the specified identity provider(s)
[2] Validates, stores, and refreshes OAuth tokens issued by the configured identity provider(s)
[3] Manages the authenticated session
[4] Injects identity information into HTTP request headers

The module runs separately from your application code and can be configured using Azure Resource Manager settings or using a configuration file. No SDKs, specific programming languages, or changes to your application code are required.

Answer 137

A

[1] Allow unauthenticated requests: [2] This option defers authorization of unauthenticated traffic to your application code. For authenticated requests, App Service also passes along authentication information in the HTTP headers. This option provides more flexibility in handling anonymous requests. It lets you present multiple sign-in providers to your users.

[3] Require authentication: [4] This option rejects any unauthenticated traffic to your application. [5] This rejection can be a redirect action to one of the configured identity providers. In these cases, a browser client is redirected to /.auth/login/<provider> for the provider you choose. If the anonymous request comes from a native mobile app, the returned response is an HTTP 401 Unauthorized. You can also configure the rejection to be an HTTP 401 Unauthorized or HTTP 403 Forbidden for all requests.</provider>

Restricting access in this way applies to all calls to your app, which may not be desirable for apps wanting a publicly available home page, as in many single-page applications.

Answer 138

A

Azure App Service is a Platform as a Service (PaaS) offering from Microsoft’s Azure cloud platform.

It enables you to build.

It enables you to deploy.

It enables you to scale web applications.

It enables you to scale APIs without managing the underlying infrastructure.

Azure App Service is designed as a distributed system, with components across multiple servers and locations.

This design enhances performance.

It improves availability.

It enhances scalability.

Answer 139

A

[1] Front Ends:

[2] Handle incoming requests.
[3] Manage initial connections, routing, and load balancing.

[4] Workers:

[5] Host and execute the application code.
[6] Generate responses to incoming requests.

Answer 140

A

The -o tsv parameter specifies the output format as tab-separated values

Answer 141

A

The command “code index.html” typically opens the “index.html” file in a code editor.

Answer 142

A

[1] By navigating to your app’s management page and [2] selecting Configuration > [3] Application Settings.

Answer 143

A

The built-in authentication feature for App Service and Azure Functions can [1] save you time and effort by providing out-of-the-box authentication with federated identity providers, allowing you to focus on the rest of your application.

[2] Azure App Service allows you to integrate various auth capabilities into your web app or API without implementing them yourself.

[3] It’s built directly into the platform and doesn’t require any particular language, SDK, security expertise, or code.

[4] You can integrate with multiple login providers. For example, Azure AD, Facebook, Google, Twitter.

Answer 144

A

Separate Area: A tenant in Azure is like a distinct virtual area within the Azure cloud environment.

Organization or Individual: It’s where an organization, project team, or individual operates and manages their resources.

Isolation: Each tenant is isolated from others, ensuring that resources and data are kept separate and secure.

Resources: It contains its own set of resources, such as virtual machines, databases, and applications.

Independent Management: Resources within a tenant are managed, accessed, and secured independently of resources in other tenants.

User Groups: Tenants allow different groups of users to work on their projects and use services without interfering with each other.

Answer 145

A

[1] Web.config or [2] appsettings.json [3] using the <appSettings></appSettings> tags

Answer 146

A

Configuration > General settings

Answer 147

A

[1] Scale based on a metric, such as the length of the disk queue, or the number of HTTP requests awaiting processing.
[2] Scale to a specific instance count according to a schedule. For example, you can arrange to scale out at a particular time of day, or on a specific date or day of the week. You also specify an end date, and the system scales back in at this time.

Answer 148

A

To get started with autoscaling navigate to your App Service plan in the Azure portal and select Scale out

Answer 149

A

Autoscale’s scale-in rule estimates the final state if it were to scale-in. For example, 60 x 3 (current instance count) = 180 / 2 (final number of instances when scaled in) = 90. So autoscale doesn’t scale-in because it would have to scale out again immediately. Instead, it skips scaling in.

Answer 150

A

The next time autoscale checks, the CPU continues to fall to 50. It estimates again - 50 x 3 instance = 150 / 2 instances = 75, which is below the scale-out threshold of 80, so it scales in successfully to 2 instances.

Answer 151

A

Create a default resource group if one isn’t specified.
Create a default app service plan.
Create an app with the specified name.
Zip deploy files from the current working directory to the web app.

Answer 152

A

[1] You can validate app changes in a staging deployment slot before swapping it with the production slot.

[2] Deploying an app to a slot first and swapping it into production makes sure that all instances of the slot are warmed up before being swapped into production. This eliminates downtime when you deploy your app. The traffic redirection is seamless, and no requests are dropped because of swap operations. You can automate this entire workflow by configuring auto swap when pre-swap validation isn’t needed.

[3] After a swap, the slot with previously staged app now has the previous production app. If the changes swapped into the production slot aren’t as you expect, you can perform the same swap immediately to get your “last known good site” back.

Answer 153

A

Before you swap into production as the target slot, [1] validate that the app runs with the swapped settings. [2] The source slot is also warmed up before the swap completion, which is desirable for mission-critical applications.

Answer 154

A

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. When auto swap is enabled from a slot into production, [1] every time you push your code changes to that slot, App Service automatically swaps the app into production after it’s warmed up in the source slot.

Answer 155

A

Application logging
Web server logging
Detailed error logging
Failed request tracing
Deployment logging

Answer 156

A

az container create \
–resource-group $ACI_PERS_RESOURCE_GROUP \

–name hellofiles \

–image mcr.microsoft.com/azuredocs/aci-hellofiles \

–dns-name-label aci-demo \

–ports 80 \
[1] –azure-file-volume-account-name $ACI_PERS_STORAGE_ACCOUNT_NAME \

[2] –azure-file-volume-account-key $STORAGE_KEY \

[3] –azure-file-volume-share-name $ACI_PERS_SHARE_NAME \

[4] –azure-file-volume-mount-path /aci/logs/

Answer 157

A

To make settings swappable, [1] add the app setting WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS in every slot of the app and [2] 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 are not affected by this override app setting.

Answer 158

A

[1] You can swap deployment slots on your app’s Deployment slots page and the Overview page and select Swap.

[2] Select the desired Source and Target slots. Usually, the target is the production slot. [3] Also, select the Source Changes and Target Changes tabs and verify that the configuration changes are expected. When you’re finished, you can swap the slots immediately by selecting Swap.

[4] When you’re finished, close the dialog box by selecting Close.

Answer 159

A

[1] Windows, [2] Linux
[3] App Service file system and/or [4] Azure Storage blobs
[5] Logs messages generated by your application code. The messages are generated by the web framework you choose, or from your application code directly using the standard logging pattern of your language. Each message is assigned one of the following categories: Critical, Error, Warning, Info, Debug, and Trace.

Answer 160

A

[1] Windows
[2] App Service file system or [3] Azure Storage blobs
[4] Raw HTTP request data in the W3C extended log file format. Each log message includes data like the HTTP method, resource URI, client IP, client port, user agent, response code, and so on.

Answer 161

A

[1] Windows
[2] App Service file system
[3] Copies of the .html error pages that would have been sent to the client browser. For security reasons, detailed error pages shouldn’t be sent to clients in production, but App Service can save the error page each time an application error occurs that has HTTP code 400 or greater.

Answer 162

A

[1] Windows
[2] App Service file system
[3] Detailed tracing information on failed requests, including a trace of the IIS components used to process the request and the time taken in each component. One folder is generated for each failed request, which contains the XML log file, and the XSL stylesheet to view the log file with.

Answer 163

A

[1] Windows, [2] Linux
[3]App Service file system
[4] Helps determine why a deployment failed. Deployment logging happens automatically and there are no configurable settings for deployment logging.

Answer 164

A

To configure an app setting or connection string to stick to a specific slot (not swapped), [1] go to the Configuration page for that slot. [2] Add or edit a setting, [3] and then select Deployment slot setting. Selecting this check box tells App Service that the setting isn’t swappable.

Answer 165

A

System.Diagnostics.Trace.TraceError(“If you’re seeing this, something bad happened”);

Answer 166

A

To route production traffic manually, you use the [1] x-ms-routing-name query parameter.

To let users opt out of your beta app, for example, you can put this link on your webpage:

<a>Go back to production app</a>

The string x-ms-routing-name=self specifies the production slot. After the client browser accesses the link, it’s redirected to the production slot. Every subsequent request has the x-ms-routing-name=self cookie that pins the session to the production slot.

To let users opt in to your beta app, set the same query parameter to the name of the non-production slot. Here’s an example:

<webappname>.azurewebsites.net/?x-ms-routing-name=staging
</webappname>

Answer 167

A

In addition to automatic traffic routing, App Service can route requests to a specific slot. [1] This is useful when you want your users to be able to opt in to or opt out of your beta app.

Answer 168

A

[1] Go to your app’s resource page and select the deployment slot you want to configure to auto swap. The setting is on the Configuration > General settings page.

[2] Set Auto swap enabled to On. Then select the desired target slot for Auto swap deployment slot, and select Save on the command bar.

[3] Execute a code push to the source slot. Auto swap happens after a short time, and the update is reflected at your target slot’s URL.

Answer 169

A

[1] Yes

[2] If any errors occur in the target slot (for example, the production slot) after a slot swap, restore the slots to their pre-swap states by swapping the same two slots immediately.

[3] If the swap operation takes a long time to complete, you can get information on the swap operation in the activity log.

On your app’s resource page in the portal, in the left pane, select Activity log.

A swap operation appears in the log query as Swap Web App Slots. You can expand it and select one of the suboperations or errors to see the details.

Answer 170

A

To route production traffic automatically:

[1] Go to your app’s resource page and select Deployment slots.

[2] In the Traffic % column of the slot you want to route to, specify a percentage (between 0 and 100) to represent the amount of total traffic you want to route. Select Save.

After the setting is saved, the specified percentage of clients is randomly routed to the non-production slot.

Answer 171

A

By default, all client requests to the app’s production URL (http://<app_name>.azurewebsites.net) are routed to the production slot. You can route a portion of the traffic to another slot. [1] This feature is useful if you need user feedback for a new update, but you're not ready to release it to production.</app_name>

Answer 172

A

When implementing a system composed of microservices, function calls are distributed across the network.

To support the distributed nature of microservices, it is important to account for failures, retries, and timeouts.

Container Apps offer building blocks for running microservices.

The use of Dapr provides a more comprehensive microservices programming model.

Dapr includes features such as observability.

Dapr also includes features like pub/sub (publish/subscribe).

Dapr supports service-to-service invocation with mutual TLS (Transport Layer Security).

Dapr supports retries and more.

Answer 173

A

az webapp show \
–resource-group <group_name> \
--name <app_name> \
--query possibleOutboundIpAddresses \
--output tsv</app_name></group_name>

Answer 174

A

az webapp show \
–resource-group <group_name> \
--name <app_name> \
--query outboundIpAddresses \
--output tsv</app_name></group_name>

Answer 175

A

CPU Percentage. This metric is an indication of the CPU utilization across all instances. A high value shows that instances are becoming CPU-bound, which could cause delays in processing client requests.

Memory Percentage. This metric captures the memory occupancy of the application across all instances. A high value indicates that free memory could be running low, and could cause one or more instances to fail.

Disk Queue Length. This metric is a measure of the number of outstanding I/O requests across all instances. A high value means that disk contention could be occurring.

Http Queue Length. This metric shows how many client requests are waiting for processing by the web app. If this number is large, client requests might fail with HTTP 408 (Timeout) errors.

Data In. This metric is the number of bytes received across all instances.

Data Out. This metric is the number of bytes sent by all instances.

You can also scale based on metrics for other Azure services. For example, if the web app processes requests received from a Service Bus Queue, you might want to spin up more instances of a web app if the number of items held in an Azure Service Bus Queue exceeds a critical length.

Answer 176

A

Swap slots (e.g., staging to production) in App Service like this:
[1] Apply target slot’s settings (app settings, deployment, auth) to source slot, causing restart.
[2] Validate source slot works with target settings.
[3] Wait for source slot instances to restart.
[4] If enabled, initiate local cache and restart instances.
[5] If auto swap with warm-up, initiate App Initiation.
[6] If no appInitialization, trigger HTTP request. If an instance returns any HTTP response, it’s considered to be warmed up.
[7] Successful response means instance is warmed up.
[8] If all instances warmed up, switch slots by switching routing rules.
[9] Target slot now has pre-swap app.
[10] Now that the source slot has the pre-swap app previously in the target slot, perform the same operation by applying all settings and restarting the instances.

Answer 177

A

Publishing endpoints
Custom domain names
Non-public certificates and TLS/SSL settings
Scale settings
WebJobs schedulers
IP restrictions
Always On
Diagnostic log settings
Cross-origin resource sharing (CORS)
Virtual network integration
Managed identities
Settings that end with the suffix _EXTENSION_VERSION
Features marked with an asterisk (*) are planned to be unsnapped.

Answer 178

A

General settings, such as framework version, 32/64-bit, web sockets
App settings (can be configured to stick to a slot)
Connection strings (can be configured to stick to a slot)
Handler mappings
Public certificates
WebJobs content
Hybrid connections *
Azure Content Delivery Network *
Service endpoints *
Path mappings

Answer 179

A

[1] WEBSITE_SWAP_WARMUP_PING_PATH: The path to ping to warm up your site. Add this app setting by specifying a custom path that begins with a slash as the value. An example is /statuscheck. The default value is /.

[2] WEBSITE_SWAP_WARMUP_PING_STATUSES: Valid HTTP response codes for the warm-up operation. Add this app setting with a comma-separated list of HTTP codes. An example is 200,202 . If the returned status code isn’t in the list, the warmup and swap operations are stopped. By default, all response codes are valid.

[3] WEBSITE_WARMUP_PATH: A relative path on the site that should be pinged whenever the site restarts (not only during slot swaps). Example values include /statuscheck or the root path, /.

Answer 180

A

[1] Some apps might require custom warm-up actions before the swap. [2] The ‘applicationInitialization’ configuration element in web.config lets you specify custom initialization actions. [3] The swap operation waits for this custom warm-up to finish before swapping with the target slot. Here’s a sample web.config fragment.

Answer 181

A

Outbound features: These functionalities in Azure App Service govern how your application communicates with external resources beyond its immediate environment.

Hybrid Connections: Hybrid Connections provide a secure and reliable way for your application hosted in Azure to connect to on-premises resources, like databases or services, without exposing them directly to the internet.

Gateway-required virtual network integration: This feature establishes connectivity between your application and resources in your Azure virtual network, requiring the use of a gateway to ensure secure and controlled communication.

Virtual network integration: With virtual network integration, your Azure application can communicate with resources in an Azure virtual network, facilitating more seamless and secure interaction while maintaining network isolation.

Answer 182

A

Inbound features: These are functionalities in Azure App Service that control how incoming requests and data are managed and directed within the application environment.

App-assigned address: This feature allows you to assign a specific address to your application within Azure, which can be used for tasks like supporting SSL certificates or designating a dedicated inbound address.

Access restrictions: With this feature, you can set up rules to limit access to your application from a predefined set of IP addresses or address ranges, enhancing security and control.

Service endpoints: These enable you to tailor the communication of your application to specific Azure service resources, allowing for more focused and efficient interaction between your app and these resources.

Private endpoints: Private endpoints establish a secure and private connection between your Azure application and resources in your virtual network, enhancing security by avoiding exposure to the public internet.

Answer 183

A

Azure Functions offers more developer productivity than Azure App Service WebJobs does. It also offers more options for programming languages, development environments, Azure service integration, and pricing. [1] For most scenarios, it’s the best choice.

Answer 184

A

[1] Function code files are stored on Azure Files shares on the function’s main storage account. [2] When you delete the main storage account of the function app, the function code files are deleted and can’t be recovered.

Answer 185

A

Maximum instances: [1] A single function app only scales out to a maximum of 200 instances. [2] A single instance may process more than one message or request at a time though, so there isn’t a set limit on number of concurrent executions.
New instance rate: [3] For HTTP triggers, new instances are allocated, at most, once per second. [4] For non-HTTP triggers, new instances are allocated, at most, once every 30 seconds.

Answer 186

A

Every function has one and only one trigger.

Answer 187

A

[1]Triggers cause a function to run. A trigger defines how a function is invoked and a function must have exactly one trigger. Triggers have associated data, which is often provided as the payload of the function.

Answer 188

A

One or more

Answer 189

A

{
“dataType”: “binary”,
“type”: “httpTrigger”,
“name”: “req”,
“direction”: “in”
}

Answer 190

A

Durable Functions.

Answer 191

A

Azure Functions:
Code-first (imperative)
About a dozen built-in binding types, write code for custom bindings
Each activity is an Azure function; write code for activity functions
Azure Application Insights
REST API, Visual Studio
Runs in Azure, or locally

Logic Apps:
Designer-first (declarative)
Large collection of connectors, Enterprise Integration Pack for B2B scenarios, build custom connectors
Large collection of ready-made actions
Azure portal, Azure Monitor logs
Azure portal, REST API, PowerShell, Visual Studio
Runs in Azure, locally, or on premises

Answer 192

A

Serverless Architecture: Azure Functions is a serverless computing service that enables you to focus on writing code without the need to manage server infrastructure.

Reduced Code: With Azure Functions, you can write less code because you’re only creating the necessary functions or actions without building a complete application.

Minimal Infrastructure Management: Developers don’t need to worry about server provisioning, scaling, or maintenance tasks, as Azure manages the underlying infrastructure.

Cost Savings: Azure Functions follows a pay-as-you-go model, meaning you only pay for the computing resources used during the execution of your functions, potentially leading to cost savings.

Automatic Scaling: Azure Functions can automatically scale up or down based on the number of incoming events, ensuring optimal performance without manual intervention.

Event-Driven: Azure Functions are triggered by events, such as HTTP requests, timers, database changes, or messages from queues, making them ideal for event-driven architectures.

Cloud Resources: Azure provides all the necessary resources required to run your functions, including CPU, memory, and network resources.

Up-to-Date Infrastructure: Azure manages the infrastructure, ensuring that you’re always using the latest technologies and updates without manual intervention.

Faster Development: Since you’re primarily focusing on writing the code for specific functions, development cycles can be faster compared to building and managing a full application.

Scalability: Azure Functions can scale automatically based on demand, handling both small and large workloads efficiently.

High Availability: The serverless nature of Azure Functions inherently offers high availability, as the platform handles distribution across multiple servers and data centres.

Supported Languages: Azure Functions supports multiple programming languages, such as C#, JavaScript, Python, PowerShell, and more, giving developers flexibility in language choice.

Integration: Azure Functions can easily integrate with other Azure services and third-party services through triggers and bindings.

Stateless: Functions are designed to be stateless, which means they don’t store information between invocations. Any necessary state must be managed externally, such as through databases or storage services.

Monitoring and Logging: Azure provides monitoring tools and logging capabilities to help you track the performance and behaviour of your functions.

Event-Driven Costs: Costs are tied to the number of executions and the resources used during those executions, aligning with the event-driven nature of the functions.

Easy Deployment: Deploying Azure Functions is straightforward, and you can use various deployment methods, including Visual Studio, Azure DevOps, and direct deployment from source control.

Use Cases: Azure Functions are suitable for a wide range of use cases, including webhooks, data processing, automation, IoT data handling, and more.

Vendor Management: By using Azure Functions, you offload much of the infrastructure management to Microsoft Azure, allowing you to focus on your application logic.

Answer 193

A

Consumption plan - 5 - 10
Premium plan - 302 - Unlimited
Dedicated plan - 302 - Unlimited

Answer 194

A

Plan Benefits

Consumption plan This is the default hosting plan. It scales automatically and you only pay for compute resources
when your functions are running. Instances of the Functions host are dynamically added and
removed based on the number of incoming events.

Premium plan Automatically scales based on demand using pre-warmed workers, which run applications with
no delay after being idle, runs on more powerful instances, and connects to virtual networks.

Dedicated plan Run your functions within an App Service plan at regular App Service plan rates. Best for long-
running scenarios where Durable Functions can’t be used.

Answer 195

A

Hosting option Details

ASE App Service Environment (ASE) is an App Service feature that provides a fully
isolated and dedicated environment for securely
running App Service apps at high scale.

Kubernetes (Direct or Azure Arc) Kubernetes provides a fully isolated and dedicated environment running on
top of the Kubernetes platform.

Answer 196

A

Plan Scale out Max # instances

Consumption plan Event driven. Scale out automatically, even during periods of high load. Azure Functions
infrastructure scales CPU and memory resources by adding
more instances of the Functions host, based on the number of incoming trigger events.
Windows: 200, Linux: 100

Premium plan Event driven. Scale out automatically, even during periods of high load. Azure Functions
infrastructure scales CPU and memory resources by adding
more instances of the Functions host, based on the number of events that its functions are
triggered on.
Windows: 100, Linux: 20-100

Dedicated plan Manual/autoscale
10-20

ASE Manual/autoscale
100

Kubernetes Event-driven autoscale for Kubernetes clusters using KEDA.
Varies by cluster

Answer 197

A

Azure Functions uses a component called the scale controller to [1] monitor the rate of events and [2] determine whether to scale out or scale in. [3] The scale controller uses heuristics for each trigger type. For example, when you’re using an Azure Queue storage trigger, it scales based on the queue length and the age of the oldest queue message.

The unit of scale for Azure Functions is the function app. When the function app is scaled out, more resources are allocated to run multiple instances of the Azure Functions host. Conversely, as compute demand is reduced, the scale controller removes function host instances. The number of instances is eventually “scaled in” to zero when no functions are running within a function app.

Answer 198

A

[1] This is because Functions rely on Azure Storage for operations such as managing triggers and [2] logging function executions, but some storage accounts don’t support queues and tables.

Answer 199

A

A function app consists of one or more individual functions.

Functions within a function app are managed, deployed, and scaled together.

All functions in a function app share the same pricing plan.

They also share the same deployment method and runtime version.

A function app serves as a way to organize and collectively manage your functions.

Answer 200

A

Serverless app model with automatic scaling - Yes - No

Develop and test in browser - Yes - No

Pay-per-use pricing - Yes - No

Integration with Logic Apps - Yes - No

Trigger events -

Timer
Azure Storage queues and blobs
Azure Service Bus queues and topics
Azure Cosmos DB
Azure Event Hubs
HTTP/WebHook (GitHub
Slack)
Azure Event Grid

Timer
Azure Storage queues and blobs
Azure Service Bus queues and topics
Azure Cosmos DB
Azure Event Hubs
File system”

Brainscape's Knowledge GenomeTM

Develop Azure Compute Solutions Flashcards

Brainscape's Knowledge Genome^TM