Develop Azure Compute Solutions Flashcards

Question

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

Answer 1

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

Answer 2

[1] Continuous Integration / Continuous Delivery

Answer 3

[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.

Answer 4

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

Answer 5

[1] Yes, you can.

Answer 6

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

Answer 7

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

Answer 8

[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 9

Stack settings

Answer 10

Platform settings

Answer 11

Incoming client certificates

Answer 12

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

Answer 13

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

Answer 14

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.

Answer 15

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

Answer 16

[1] Autoscaling works by adding and removing servers.

Answer 17

[1] When handling long-term growth

Answer 18

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

Answer 19

[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.

Answer 20

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

Answer 21

[1] The rule that allocates the most resources.

Answer 22

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

Answer 23

[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.

Answer 24

1. Your code 2. Some config (function.json)

Answer 25

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.

Answer 26

[1] Yes, they do.

Answer 27

[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.

Answer 28

[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

Answer 29

[1] Consumption

Answer 30

[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

Answer 31

[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.

Answer 32

[1] Azure Pipelines or [2] Jenkins

Answer 33

[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.

Answer 34

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.

Answer 35

[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 36

[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 37

[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 38

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 39

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 40

[1] Windows and [2] Linux

Answer 41

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 42

[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 43

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 44

az group create –name az204-acr-rg –location

Answer 45

az acr create –resource-group az204-acr-rg –name --sku Basic

Answer 46

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

Answer 47

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 48

- 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 49

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

Answer 50

[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 51

az acr repository show-tags –name \ --repository sample/hello-world --output table [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 52

[1] az acr run –registry --cmd '$Registry/sample/hello-world:v1' /dev/null /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 53

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 54

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

Answer 55

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

Answer 56

[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 57

az acr repository list –name --output table

Answer 58

[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 59

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 60

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

Answer 61

Terminated

Answer 62

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 63

You can only mount Azure Files shares to Linux containers.

Answer 64

[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 65

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 66

[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 67

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 68

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

Answer 69

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

Answer 70

Distributed Application Runtime

Answer 71

az provider register --namespace Microsoft.App

Answer 72

az provider register --namespace Microsoft.OperationalInsights

Answer 73

myRG=az204-appcont-rg myLocation= myAppContEnv=az204-env-$RANDOM Var name [1] = [2] Value [3]

Answer 74

--location $myLocation [1] $

Answer 75

[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 76

[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 77

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

Answer 78

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

Answer 79

[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 80

–secrets

Answer 81

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

Answer 82

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

Answer 83

az extension add –name containerapp –upgrade

Answer 84

[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 85

[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 86

[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 87

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

Answer 88

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 89

[1] Free and [2] Shared

Answer 90

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/

Answer 91

az containerapp revision list \ –name \ --resource-group \ -o table

Answer 92

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

Answer 93

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 94

[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 95

az webapp list-runtimes –os-type linux

Answer 96

[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 97

[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 98

[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 99

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 100

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 101

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 102

[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 103

[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 104

[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 105

[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 106

[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 107

[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 108

[1] False.

Answer 109

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 110

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 111

[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 112

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 113

[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/ 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. 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 114

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 115

[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 116

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

Answer 117

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

Answer 118

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

Answer 119

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 120

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 121

[1] Web.config or [2] appsettings.json [3] using the tags

Answer 122

Configuration > General settings

Answer 123

[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 124

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

Answer 125

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 126

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 127

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 128

[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 129

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 130

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 131

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

Answer 132

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 133

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 134

[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 135

[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 136

[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 137

[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 138

[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 139

[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 140

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 141

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

Answer 142

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: Go back to production app 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: .azurewebsites.net/?x-ms-routing-name=staging

Answer 143

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 144

[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 145

[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 146

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 147

By default, all client requests to the app’s production URL (http://.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.

Answer 148

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 149

az webapp show \ –resource-group \ --name \ --query possibleOutboundIpAddresses \ --output tsv

Answer 150

az webapp show \ –resource-group \ --name \ --query outboundIpAddresses \ --output tsv

Answer 151

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 152

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 153

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 154

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 155

[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 156

[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 157

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 158

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 159

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 160

[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 161

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 162

Every function has one and only one trigger.

Answer 163

[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 164

One or more

Answer 165

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

Answer 166

Durable Functions.

Answer 167

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 168

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 169

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

Answer 170

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 171

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 172

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 173

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 174

[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 175

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 176

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”

Develop Azure Compute Solutions Flashcards

(210 cards)