This blog contains some questions and answers about azure. It is a running document. It is being updated now and then with new questions. Hope you find it useful.
Question 1:
Why does a resource group need a location? And, if the resources can have different locations than the resource group, why does the resource group location matter at all?
Answer:
The resource group stores metadata about the resources. Therefore, when you specify a location for the resource group, you’re specifying where that metadata is stored. For compliance reasons, you may need to ensure that your data is stored in a particular region.
If the resource group’s region is temporarily unavailable, you can’t update resources in the resource group because the metadata is unavailable. The resources in other regions will still function as expected, but you can’t update them.
Question 2 :
What is the difference between azure service and azure resource ?
Answer:
In general there is no difference in azure service and azure resource. But you can say that azure service is the compute service provided over internet by azure and Azure resource is an instance of the service(Or its components.) When you pay for a service and use it for something it becomes a ‘resource’ for you.
You can also see the difference on the Azure portal when you click ‘Azure Services’ (It lists what they can provide) and ‘All Resources’ (It lists what you already have).
Question 3:
What is the difference between azure web jobs and timer triggered azure functions ?
Answer:
Webjobs are associated with app services. So if you have another web app deployed in the same app service, its performance will be affected by the web job. Web job is not an independent component.
Where as function apps are independent resources and easy to code and deploy than a web job. It will not impact any other services like web jobs might.
Question 4:
What happens to the workflow which is running, when you stop the logic app ?
Answer:
Stopping the logic app only disables the trigger, which means no workflow will be triggered even if the trigger conditions are met, if the logic app is stopped. However, the workflows which are already triggered, will complete their execution, even after the logic app is turned off.
Ref : https://docs.microsoft.com/en-us/azure/logic-apps/manage-logic-apps-with-azure-portal
Question 5:
Can you resubmit a run if the workflow is disabled ?
Answer:
Yes, when the workflow is disabled, you still can resubmit the runs.
Ref : https://docs.microsoft.com/en-us/azure/logic-apps/manage-logic-apps-with-azure-portal
Question 6:
How can you check the run history of a stateless workflow of a standard logic app ?
Answer:
You can see the run history of a stateless workflow in debug mode.
To enable the debus mode, you need to add the following key value pair in the config of logic app.
Key : Workflows.<workflow_name>.OperationOptions
Value : WithStatelessRunHistory
However, it will have some impact on the performance as compare to the stateless workflow running without debug mode, since it will have to make additional call to the storage account to write the state of the logic app as similar to the stateful workflow.
Ref : https://docs.microsoft.com/en-us/azure/logic-apps/create-single-tenant-workflows-visual-studio-code
Question 7:
What is the main drawback of stateless workflow ?
Answer:
Stateless workflow supports managed connector actions but not support managed connector triggers. So you will have to use only built in triggers when you choose stateless workflow.
It is suitable only for short runs (max 5 min) for processing small chunk of data (under 64 KB), where you don’t have to store state, input and outputs. Which is why you can not resubmit a workflow run.
Ref : https://docs.microsoft.com/en-us/azure/logic-apps/single-tenant-overview-compare
Cloud and DevOps Space 