random

Question 1

Settings that are swapped on app-service-slot-swapping

Answer 1

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

Question 2

Settings that aren’t swapped on app-service-slot-swapping

Answer 2

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

Question 3

hosting options for your Azure function code

Answer 3

Consumption plan
Flex Consumption plan
Premium plan
Dedicated plan

Question 4

The hosting option you choose dictates the following behaviors

Answer 4

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

Question 5

Consumption plan

Answer 5

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. On the Consumption plan, instances of the Functions host are dynamically added and removed based on the number of incoming events.

Question 6

Flex Consumption plan

Answer 6

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

You can reduce cold starts by specifying the number of pre-provisioned (always ready) instances. Scales automatically based on demand.

Question 7

Premium plan

Answer 7

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

Consider the Azure Functions Premium 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.

Question 8

Dedicated plan

Answer 8

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.

Consider an App Service 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).

Question 9

Container Apps

Answer 9

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

Use the Azure Functions programming model to build event-driven, serverless, cloud native function apps. Run your functions alongside other microservices, APIs, websites, and workflows as container-hosted programs.

Consider hosting your functions on Container Apps in the following situations:

You want to package custom libraries with your function code to support line-of-business apps.
You need to migration 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.