35 Azure Developer Interview Questions (ANSWERED) To Crack Your Cloud Interview

If you're just trying to look around, and see the various directories and files in your deployment, you can enter the site's "Kudu" dashboard (called Advanced Tools), using the url format http://<yoursitename>.scm.azurewebsites.net

Kudu is the engine behind git deployments in Azure Web Sites. This will give you a web-based dashboard, including a debug console (web-based) where you can explore your various directories (and the directories will show up visually as well).

ARM templates are a form of infrastructure as code, a concept where you define the infrastructure you need to be deployed. The template defines the resources, and the Azure ARM management layer is responsible for creating the infrastructure. Templates use a JavaScript Object Notation (JSON) syntax that also includes advanced capabilities. Templates use declarative syntax. In this way, you can specify what to deploy without writing a series of commands that specify how to deploy it.

The template includes the following parts:

• Parameters - values that allow you to use the same template in different environments during deployment.
• Variables - values to be reused in different templates. Variables can use values from parameters.
• User-Defined Functions - lets you define customized elements to simplify templates.
• Resources - specifies Azure resources to be deployed.
• Outputs - the return value of the deployed resource.

Almost each and every site has HTML, JS, CSS, image, video and font files that do not change much from user to user. To minimize the application load time we should use CDN.

Azure Content Delivery Network (CDN) is CDN service provided by Azure Cloud Platform that enables in storing and accessing data on different content servers and locations – used by online or cloud services. It provides:

• Better performance and user experience for end-users who are far from the destination content source or where there are many intermediary nodes in between to reach the content.
• Ability to scale to handle instantaneous high load and demand
• Caching content from publicly available Azure storage blobs
• Caching web content, images, scripts, and other website content from CDN
• Enables in caching objects to the CDN that are provided by an Azure cloud service
• Cache content based on specific query strings
• Accessing cached content from a custom domain name by mapping the CDN HTTP Endpoint.

WebJobs is a feature of Azure App Service that enables you to run a program or script in the same instance as a web app, API app, or mobile app. There is no additional cost to use WebJobs. You can use the Azure WebJobs SDK with WebJobs to simplify many programming tasks. Azure Functions provides another way to run programs and scripts.

Azure Cosmos DB normalizes the cost of all database operations using Request Units (or RUs, for short). The request unit is a performance currency abstracting the system resources such as CPU, IOPS, and memory that are required to perform the database operations supported by Azure Cosmos DB.

The cost to do a point read (fetching a single item by its ID and partition key value) for a 1-KB item is one Request Unit (or one RU).

You typically use delegated permissions when you want to call the Web API as the logged-on user. Say for example that the Web API needs to filter the data it returns based on who the user is, or execute some action as the logged-in user. Or even just to log which user was initiating the call.

Application permissions are used when the application calls the API itself. For example to get the weather forecast for a certain zipcode (it does not matter which user is logged on). The client can even call the API when there's no user present (some background service calling the API to update some status).

Logic Apps:

Logic Apps provide a way to simplify and implement scalable integrations and workflows in the cloud. It provides a visual designer to model and automates your process as a series of steps known as a workflow. There are many connectors across the cloud and on-premises to quickly integrate across services and protocols. A logic app begins with a trigger (like 'When an account is added to Dynamics CRM') and after firing can begin many combinations of actions, conversions, and condition logic.

API Apps:

API apps in Azure App Service offer features that make it easier to develop, host, and consume APIs in the cloud and on-premises. With API apps you get enterprise-grade security, simple access control, hybrid connectivity, automatic SDK generation, and seamless integration with Logic Apps.

Web Apps:

App Service Web Apps is a fully managed to compute platform that is optimized for hosting websites and web applications. This platform-as-a-service (PaaS) offering of Microsoft Azure lets you focus on your business logic while Azure takes care of the infrastructure to run and scale your apps.

Functions:

Azure Functions is a solution for easily running small pieces of code, or "functions," in the cloud. You can write just the code you need for the problem at hand, without worrying about a whole application or the infrastructure to run it. Functions can make development even more productive, and you can use your development languages of choice, such as C#, F#, Node.js, Python or PHP. Pay only for the time your code runs and trust Azure to scale as needed. Azure Functions lets you develop serverless applications on Microsoft Azure.

Both, Azure CLI and the PowerShell package use the REST API of Azure.

• Azure CLI is a PowerShell-like-tool available for all platforms. You can use the same commands no matter what platform you use: Windows, Linux or Mac and it's open-source
• The real biggest benefit of Powershell is that it operates on objects, not on strings. Therefore it's really easy to work with the output of commands
• You might end up replacing all my ARM Templates with Azure CLI scripts as it is less verbose and easy to read

PowerShell has some significant advantages over CLI:

• PowerShell is a language of Azure Functions. So you can easily write a module or code and push it to a secured Azure Function. CLI is not a supported language.
• Same goes for Azure Automation Runbooks, whereas CLI is not a supported language.
• If you want to orchestrate a hybrid workload covering on premise and cloud, i.e. deploy a Service to a Windows Server and then deploy an endpoint in Azure for it to interact with, PowerShell can but CLI can't (and I would surprised if it did).
• If you want to invest in one language that can call legacy Modules for management, PowerShell can but CLI can't.
• If you want to create your own DLL in C# or any other language and incorporate that into your scripts. I've had to reverse engineer DLLs and wrap them in PowerShell to incorporate them into orchestrations.
• I've had significantly more success extending DevOps pipelines with PowerShell than CLI.
• PowerShell has very good multithreaded workload support for scenarios such as Azure unit and smoke testing and large Azure parallel deployments (beyond DevOps parallel tasks which get clunky). TBH, I am not aware of native multithreading in Azure CLI.
• I can develop a module, use it in all the above scenarios and then give it to an end client; TBH, I don't believe I can do that for CLI (create a module, digitally sign it and then nuget feed distro).

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. For most scenarios, it's the best choice.

Here are two scenarios for which WebJobs may be the best choice:

• You need more control over the code that listens for events, the JobHost object. Functions offers a limited number of ways to customize JobHost behavior in the host.json file. Sometimes you need to do things that can't be specified by a string in a JSON file. For example, only the WebJobs SDK lets you configure a custom retry policy for Azure Storage.
• You have an App Service app for which you want to run code snippets, and you want to manage them together in the same Azure DevOps environment.

Azure Functions is built on the WebJobs SDK, so it shares many of the same event triggers and connections to other Azure services. Here are some factors to consider when you're choosing between Azure Functions and WebJobs with the WebJobs SDK:

• WebJobs (without the WebJobs SDK) supports C#, Java, JavaScript, Bash, .cmd, .bat, PowerShell, PHP, TypeScript, Python, and more. This is not a comprehensive list. A WebJob can run any program or script that can run in the App Service sandbox.
• WebJobs (without the WebJobs SDK) supports NPM and NuGet.

Claim Check Pattern (aka Reference-Based Messaging) is used to keep events and messages small in order to make them fit into the service size limits. The idea is to use intermediate storage to save the event/message payload and send the event/message with the stored reference.

According to the official Microsoft documentation, an event is a lightweight notification of a condition or a state change. Accordingly, Event Grid limits the event's size to 1 MB and are billed on 64 KB slices. Therefore, if we want to keep things cost-efficient the idea is to keep events light and under the limit.

Event Grid automatically generates a tag/reference and sends it to a supported message bus, such as Azure Storage Queues. The receiver can poll the queue, get the message, and then use the stored reference data to download the payload directly from Blob Storage.

• An Azure function is triggered by an external event or a timer. It then executes the code of the function. When hosted on a consumption plan this execution is allowed to run for 5 or 10 minutes max. When you need a longer execution time you need to run it on an App Service Plan.
• An App Service can host any app you've created. Like a website (that runs continuously and doesn't need to be triggered before it starts doing something) or an API for example.
• Azure Functions consumption plan you pay per execution
• Azure Functions in an App Service (dedicated plan) you pay for the allocated hardware per minute.

So, for the integration scenario azure functions are a very natural fit. For websites an App Service might be the best solution.

To do it using Azure CLI:

az webapp config appsettings set -n $webappname -g $resourceGroupName --settings ConnectionStrings__Default=$connectionString

To set an environment variable ConnectionStrings__Default to the variable $connectionString

CosmosDB only supports transactions within the same partition.

This means that you cannot have cross containers transactions and you also cannot have transactions between two documents with different partition key values.

If you need something to execute transactionally in Cosmos DB then you need to make sure it all lives in the same container and the same partition key value. In that case, you may want to mix different document types in the same collection; this is usually the case when you want multiple, related documents (like customers and customer orders) to sit in the same partition (customerId).

1. You can't mount Azure Blob Storage as a native share on a virtual machine.
2. Pricing: Blob storage is much cheaper than file storage.
3. Azure Blob Storage isn't hierarchical beyond containers. You can add files that have / or \ characters in them that are interpreted as folders by many apps that read blob storage.
4. Azure File Service provides a SMB protocol interface to Azure Blob Storage which solves the problem with (1).
5. Portability:
   • With blob storage, if you decide to migrate to a diff platform in future you may have to change your app code but
   • with File storage you can migrate your app to any other platform that supports SMB (assuming you are using native file system APIs in your app)

Use this rule of thumb:

• If you are developing a new application then leverage the native Azure API directly into Blob Storage.
• If you are porting an existing application that needs to share files then use Azure File Service.

Azure Resource Manager (ARM) is an Azure service you can use to manage and deploy resources using an infrastructure as code paradigm. It enables you to provision, modify, and delete resources using a variety of features including access controls, tags, and locks.

When using Azure Resource Manager, there is some specific terminology you should be aware of. The most common terms include:

• resource—an asset that can be managed. Assets include virtual machines (VMs), virtual networks, databases, web apps, and storage accounts. Resources may also refer to tags, subscriptions, resource groups, or management groups.
• resource group—a container that groups together related resources. An Azure resource group enables you to manage multiple resources as a whole.
• resource provider—an individual service in Azure that you can create resources in. For example, Microsoft Storage or Microsoft Compute.
• Resource Manager template—a file that defines how resources should be deployed to groups, subscriptions or tenants. This file is defined in JavaScript Object Notation (JSON).
• declarative syntax—the syntax used for Resource Manager templates. It enables you to define how resources should be handled without having to know programming commands.

Triggered WebJobs are WebJobs which are run once when a URL is called or when the schedule property is present in schedule.job. Scheduled WebJobs are just WebJobs which have had an Azure Scheduler Job created to call URL on a schedule.

Summary:

• + Executable/Script on demand
• + Scheduled executions
• - Have to trigger via .scm endpoint
• - Scaling is manual
• - VM is always required

• Classic storage accounts are created using existing Service Management API's (the REST API stack that's been available for the past several years).
• The newer storage accounts are created with the new Azure Resource Manager (ARM) API's (which are also wrapped in PowerShell and CLI now). One advantage of the new over the classic storage accounts is Storage Service Encryption (SSE) (to automatically encrypt your data when it is persisted to the cloud).

Ultimately they provide the same resources to your apps, but they're created/managed differently, and there are a few nuanced differences (such as the ability to tag resources that are created via ARM scripts).

The Azure Key Vault (KV) can store 3 types of items: (1) secrets, (2) keys, & (3) certificates (certs).

1. Secrets - provides secure storage of secrets, such as DB connection strings, account keys, or passwords for PFX (private key files). An auth app can retrieve a secret for use in its operation.
2. (Cryptographic) Keys - keys represented as JWK (JSON Web Key). Supports multiple key types and algorithms, and enables the use of Hardware Security Modules (HSM) for high value keys.
3. Cert - is a managed X.509 certificate, which are built on top of keys and secrets and add an automated renewal feature/auto-rollover.

App Services now replaces all Mobile, Api and Web Apps flavors as a single app framework with all the functionality rolled over to make things more accessible across application types. Currently all of Web, Mobile and Api Apps are collectively called App Services.

Function apps are now the exception. Creating a function app changes the user interface in the portal. The underlying web app, however, is no different. Setting an app setting named FUNCTIONS_EXTENSION_VERSION = ~1 turns any web app into a function app (minus the user interface in the portal).

You must consider:

• From a scalability/parallelization perspective, it doesn't matter because partitioning in Win Azure blobs storage is done at the blob level, not the container, which means you could (and often will) have two different blobs in a same container being served out by different servers.
• The extra containers can be nice as additional security boundaries and access control (for public anonymous access or different SAS signatures for instance),
• If you need to list blobs in a container, you will likely see better performance with the many-container model,
• Extra containers can also make housekeeping a bit easier when pruning (deleting a single container versus targeting each blob),
• In extreme cause you can pay a lot more if you create and delete many containers

• Physical partitions are partitions that our logical partitions map to. This sits within a replica set and each replica set hosts an instance of the Cosmos DB Engine. This ensures that the data stored within each physical partition is durable, consistent, and highly available. Unlike logical partitions, physical partitions are an internal implementation of the system and Azure Cosmos DB entirely manages physical partitions.

• Logical partitions are partitions that consist of a set of items that have the same partition key. Say if all our items have a “Category” property, we can use that as the partition key. Say if we have values for “Sport”, “Tech” and “Financial” categories, these group of items will form their own distinct logical partitions. Internally, one or more logical partitions are mapped to a single physical partition.

• With Azure SQL Managed Instance, you essentially get a full-fledged SQL Server that you can control any way you want, just like you would control a locally configured SQL Server. All the power and access and customization you want. With SQL Managed Instance, auditing happens at the server level, because, you are getting the full database server.

• With, Azure SQL DB PaaS, you are essentially getting a database service, so, you give up a lot of control. Resources dedicated to individual DBs like a container. They are grouped under an Azure SQL Server but that SQL Server is shared.

• SQL Azure is great when you want to work with structured data using relations, indexes, constraints, etc.
• Azure Storage Table is great when you need to work with centralized structured data without relations and usually with large volumes.

I would always use azure tables as a much cheaper solution if:

• I perform table selects ONLY by PK (select on the property is slow due to the of the whole deserialization),
• I can live with a limited Linq set (Query Operators (Table Service Support),
• I don't need to join tables and perform complex queries on the server,
• I need horizontal partitioning "sharding" of my data (SQL Azure Federations is a step in that direction by Tables have PartionKey from day 0),
• Azure Tables are only cheaper than SQL Azure if the data access pattern is relatively light since tables have a per-transaction fee and SQL Azure doesn't.

• WebJobs are good for lightweight work items that don't need any customization of the environment they run in and don't consume a lot of resources. They are also really good for tasks that only need to be run periodically, scheduled, or triggered. They are cheap and easy to set up/run. They run in the context of your Website which means you get the same environment that your Website runs in, and any resources they use are resources that your Website can't use.
• Worker Roles are good for more resource-intensive workloads or if you need to modify the environment where they are running (ie. a particular .NET framework version or something installed into the OS). Worker Roles are more expensive and slightly more difficult to set up and run, but they offer significantly more power.
• A Worker Role is self-hosted on a dedicated VM, and a Web Job is hosted in a Web App container.
• A Worker Role will scale independently, a Web Job will scale along with the Web App container.

In general, I would start with WebJobs and then move to Worker Roles if you find that your workload requires more than WebJobs can offer.

Both services deal with messages but have very different purposes:

• Azure Service Bus is an enterprise messaging product. It covers queuing, pub/sub, and has multiple compute-based features. Receiving is done via polling (long polling) and usually, a namespace is accessed within/by a single organization. Azure Service Bus namespace is constrained to a single region. If you need pub/sub within an organization, Service Bus would do. The last Service Bus pros is that there are better event viewers like Service Bus Explorer, whereas there is nothing similar for Event Grid.

• Azure Event Grid is a notification service. Its sole purpose is to enable pub/sub between event generators and subscribers. It has no queuing semantics. Message delivery is push-based and only a few compute-based features are available unlike with Service Bus. The service is designed to allow communication between multiple parties and can span multiple organizations as published and/or subscribers. Event Grid is global and doesn't have that kind of constraint. Once you need to push notifications about certain events outside of the organization, that's where Event Grid shines. When you have multiple subscribers interested in events that are outside of your trust network, you are not going to hand them out a connection string to your service bus. Rather you'd like to push a notification/message to a webhook that the subscriber will provide.

The two can also be mixed. Events from Event Grid can be queued up using Service Bus queues or topics for leveling workloads.