Introduction

In my previous article, we covered the basics of Terraform—what it is, why it is useful, and how to define infrastructure as code. In this article, we will move beyond the basics and look at a real‑world use case, where we deploy cloud resources using Terraform on Microsoft Azure.

The goal of this article is not to deep‑dive into business logic or financial calculations, but to demonstrate how Terraform can be used to provision and manage infrastructure for a microservices‑based financial application.

Link of previous article : https://www.c-sharpcorner.com/article/infrstructure-as-code-using-terraforms/

Full Sourec code : https://github.com/iamuttamchaturvedi9/IaCWithTerraform

We will consider a simplified balance transfer system, similar to what is commonly used in financial institutions.

At a high level:

• A user interacts with the system through an API Gateway.

• The API Gateway forwards requests to different microservices.

• Each microservice is responsible for a specific function, such as transactions, balance checks, transfers, and notifications.

• Based on the available balance, a transaction is either completed or rejected.

• The user is notified about the outcome of the transaction.

This architecture is intentionally kept simple so that we can focus on infrastructure deployment using Terraform, rather than application‑level implementation details.

Architecture Flow

The following steps describe the request flow in the system:

1. The user sends a request (for example, a balance transfer) to the system.

2. The request reaches the API Gateway, which acts as a single entry point.

3. The API Gateway forwards the request to the appropriate transaction microservice.

4. The transaction service communicates asynchronously with other services:

   • Balance Service – checks the available balance

   • Transfer Service – performs the fund transfer

   • Notification Service – sends success or failure notifications

5. Each service stores or retrieves data from its respective database:

   • SQL databases for transaction‑related data

   • Cosmos DB for notifications

Scope of This Article

In this article, we will:

• Focus on deploying Azure resources using Terraform

• Define infrastructure using Terraform configuration files

• Understand how real‑world microservices map to cloud resources

We will not:

• Implement application code

• Discuss transaction logic in detail

• Cover CI/CD pipelines (this can be explored in a future article)

Setting Up Azure Environment Variables

To allow Terraform to authenticate with Azure, we need to set the required environment variables.

After logging in using Azure CLI:

az login --tenant <tenant-id>

Replace with your own tenant-id

Set the following environment variables:

export ARM_SUBSCRIPTION_ID="<your-subscription-id>"
 export ARM_TENANT_ID="<your-tenant-id>"
 export ARM_CLIENT_ID="<your-client-id>"
 export ARM_CLIENT_SECRET="<your-client-secret>"

Use below command to create service principle

az ad sp create-for-rbac --name financeapp  --role Contributor  --scopes "subscriptions/<subscription-id>"

Output would be shown as respective values

Replace with your own subscription-id and tenant id in azure subscription

Client Id is equal to App Id created as shown above

Client Secret is password created as shown above

Terraform Providers have 3 main componenets which work together.

Terraform Block - Configures Terraform settings and declares which providers you need

Provider - Authenticates and configures your connection to cloud platforms (AWS, Azure, GCP, etc.). In our case we will use azure resurce manager

Resources - The actual infrastructure components you want to create (servers, storage, networks, etc.)

Now lets dive into real implementation:

Add following files named as data.txt and main.tf

Now we can run following command to deploy our resources using terraform like terraform init ,terraform plan,terraform apply to deploy our resources. Files and details are described below.

After running final command. Output would look like this:

Till now we have created resource group and appservice plan . Now lets create other services .

# API Gateway

resource "azurerm_service_plan" "plan_apigateway" {
    name = "plan_apigateway-northeurope"
    location = "northeurope"
    resource_group_name = azurerm_resource_group.rg.name
    os_type = "Linux"
    sku_name = "F1"
}

This resource creates an Azure App Service Plan, which defines the compute resources used by one or more web applications.

• Linux-based plan: The os_type = "Linux" enables containerized workloads and modern application stacks.

• Free tier (F1): Using the F1 SKU keeps costs at zero, making it ideal for development, testing, or proof-of-concept environments.

• Regional deployment: The plan is deployed to the North Europe region, ensuring consistency with other resources.

The App Service Plan acts as the underlying infrastructure that hosts our API Gateway application.

resource  "azurerm_linux_web_app" "appservice-apigateway" {
    name = "appserv-apigateway-northeurope"
    location = "northeurope"
    resource_group_name = azurerm_resource_group.rg.name
    service_plan_id = azurerm_service_plan.plan_apigateway.id
    site_config {
        always_on = false
        application_stack {
            docker_image_name = "nginx:latest"
        }
    }
}

This resource provisions an Azure Linux Web App that acts as the API Gateway.

Key points:

• Hosted on the App Service Plan: The service_plan_id links the web app to the previously defined App Service Plan.

• Container-based deployment: The application runs the nginx:latest Docker image, demonstrating how Azure App Service can host containerized workloads without managing servers.

• Lightweight configuration: always_on is disabled, which is appropriate for free-tier or non-production environments.

Using NGINX as the container image makes this setup ideal for:

• API routing and reverse proxy scenarios

• Acting as a lightweight API Gateway

• Future expansion with custom NGINX configurations or additional containers

Similarly, we need to create additional App Services for Transaction, Balance, Transfer, and Notification. Each App Service must be deployed under its own dedicated App Service Plan. All required source code is available in the repository for reference.

https://github.com/iamuttamchaturvedi9/IaCWithTerraform

Now let’s jump into creating DB server and databases

# Database transaction
resource  "azurerm_mssql_server" "sql_server_transaction" {
    name = "sqlserver-transaction"
    resource_group_name = azurerm_resource_group.rg.name
    location = "northeurope"
    version = "12.0"
    administrator_login = "adminuser"
    administrator_login_password = "admin.12345"
}
resource  "azurerm_mssql_database" "sql_database_transaction" {
    name = "sqlserver-transaction-northeurope"
    server_id =  azurerm_mssql_server.sql_server_transaction.id
    sku_name = "Basic"
}

# Database balance
resource  "azurerm_mssql_server" "sql_server_balance" {
    name = "sqlserver-balance"
    resource_group_name = azurerm_resource_group.rg.name
    location = "northeurope"
    version = "12.0"
    administrator_login = "adminuser"
    administrator_login_password = "admin.12345"
}

resource  "azurerm_mssql_database" "sql_database_balance" {
    name = "sqlserver-balance-northeurope"
    server_id =  azurerm_mssql_server.sql_server_transaction.id
    sku_name = "Basic"
}

Similarly add above code fro transaction,balance and transfer databases and run terraform plan. Once plan is successful then run apply and say yes while asking for approval. It will create required resources

Ok now we have created all our resources. Its time to delete resources which cost money . Here we 2 ways to delete resources in terraform .

1. Using “terraform destroy “ command

tzerraform destroy -target = azurerm_mssql_database.sql_database_transaction

1. Commenting code and running “terraform plan” and “terraform apply” commands

# resource  "azurerm_mssql_database" "sql_database_transfer" {
#    name = "sqlserver-transfer-northeurope"
#    server_id =  azurerm_mssql_server.sql_server_transaction.id
#    sku_name = "Basic"
# }

Below command will destroy commented code resources

terraform plan

terraform apply

Final Note: pelase add subscrition id and required varibles values in data.txt

main.tf
provider "azurerm"{
    subscription_id = "<subscription_id>"
    features{
        resource_group{
            prevent_deletion_if_contains_resources = false
        }
    }
}
---------------------------------------------------------------------------------------------------------------------
data.txt

export ARM_SUBSCRIPTION_ID="<your-subscription-id>"
export ARM_TENANT_ID="<your-tenant-id>"
export ARM_CLIENT_ID="<your-client-id>"
export ARM_CLIENT_SECRET="<your-client-secret>"

Conclusion

Terraform makes infrastructure provisioning repeatable, predictable, and scalable by turning cloud resources into version-controlled code. By defining Azure components declaratively, you reduce manual effort, minimize configuration drift, and improve consistency across environments. With proper state management and secure authentication (for example, service principals or federated identity instead of user logins), Terraform becomes a reliable foundation for both day-to-day infrastructure changes and automated CI/CD deployments.

Problem Statement

The current API gateway does not provide user details along with incoming requests. As a result, it is not possible to reliably track which user is accessing specific APIs.

Solution:
We can implement an inbound policy in the API Gateway to capture trace information. These traces will be sent to Application Insights, where they can be later used to track and analyze user activity. We can also store thes logs to database for future references

Intro — Azure API Management (APIM) gateway (short & practical)

Azure API Management (APIM) is a managed gateway that sits in front of your APIs and provides a central place to secure, publish, transform, and observe traffic. With APIM you can:

• apply policies (XML fragments) at global, API, or operation level to throttle, rewrite, authenticate, cache, log, or transform requests and responses; Microsoft Learn+1

• enrich requests and responses (add headers, inject correlation IDs) so downstream services and telemetry systems can correlate traces; Microsoft Learn+1

This makes APIM an ideal place to add lightweight observability (user identity, correlation id, subscription id, client IP) for every incoming call, even when the backend or client doesn’t supply all the fields you need.

Now let’s dive into required steps to create api gateway, configure it with application insight and add traces.

Step by Step Process:

1. Create Http API with url detail in Gateway and Add operations

1. Select the operation inside All Operation and click on inbound processing => Polices (</>)

1. In Inbound polices, once you click (</>) your can paste code as shown below. Adding this policy will include the email of the user who logged In and forward it to related Application insight of the API .

<inbound>
    <base />
    <set-header name=”user-email” exists-action=”override”>
        <value>@(context.User != null ? context.User.Email : “unknown”)</value>
    </set-header>
    <trace source=”APIM” severity=”information”>
        <message>@($”userEmail:{(context.User != null ? context.User.Email : “unknown”)}”)</message>
    </trace>
</inbound>

4. In API Settings tab look for Diagnostics Logs => Application Insights and click on Enable checkbox . In the Destination dropdown select your application insight and save it

4. Navigate to application insight => Transaction search and look for traces of API request in last 24 hours. In traces you wil find all the details you added in inbound policy

Summary

In this article, we explored how to extend Azure API Management (APIM) Gateway with custom policies to improve user tracking and observability.

By combining APIM policies with Application Insights telemetry, you create a robust monitoring setup that allows you to trace user activity across every API call, troubleshoot issues quickly, and gain better insights into how APIs are being consumed.

When I first encountered the term “Service Principal”, I was completely confused.
Was it a user? Was it an app? Was it a login account?
And why did it need its own password or secret key?

If you’re getting started with cloud infrastructure, especially in Azure, the concept of a Service Principal can feel vague and overly abstract.

You’re not alone — many professionals, especially those coming from traditional development or sysadmin backgrounds, struggle to understand:

What exactly is a Service Principal?

When and why should you use one?

In this post, I’ll break it down in plain language, using real-world example and code snippets— so by the end, you’ll never be confused by the term again.

Service Principal is like a user account for apps or services that need to access Azure resources. For example in order to login in the system user need user name and password, similarly its kind of user name and password for the app to access resource in azure

Very Simple Definition:
A service principal is a special account that lets an app or automation tool sign in to Azure and do things, like start a virtual machine or deploy code — but only what you allow it to do.
It’s not a person, but it has its own ID and password (called a client ID and secret), and you can control what it’s allowed to access using roles and permissions.

Scenarios:

1. When You Register an Application in Azure AD
• Scenario: You create an app registration (e.g., for a web app, API, or daemon service).
• Result: Azure automatically creates a corresponding Service Principal in your tenant.
• Purpose: The app can then authenticate and access resources based on the permissions you assign to the service principal.
App Registration = Identity
Service Principal = Role-playing identity inside a tenant

2. When You Create an Azure Resource That Needs to Access Other Resources
Examples:
• Azure Kubernetes Service (AKS)
• Azure App Service with managed identity
. Azure Data Factory with linked services
• Result: Azure automatically creates a Managed Identity, which is essentially a Service Principal under the hood.

System-assigned managed identity is tightly coupled with the resource and gets deleted if the resource is deleted.

3. When Using Azure DevOps Service Connections
• Scenario: You create a Service Connection in Azure DevOps to deploy resources to Azure.
• Result: Azure DevOps automatically creates a service principal and assigns it the required permissions (e.g., Contributor role).
It’s best practice to regularly audit these service principals and rotate secrets if not using managed identity.

Create a Service Principal with permissions to access a specific Azure subscription or resource group.

bash

az ad sp create-for-rbac — name “terraform-deployer” — role=”Contributor” — scopes=”/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>”

This command outputs:json
CopyEdit
{
“appId”: “xxxxx-xxxx-xxxx-xxxx”,
“displayName”: “terraform-deployer”,
“password”: “xxxxxxx”,
“tenant”: “xxxxx-xxxxx”
}
These credentials are saved as secrets in your CI/CD pipeline.

2. Configure Terraform with the Service Principal:
In your pipeline or terminal, set these environment variables:

bash
CopyEdit
export ARM_CLIENT_ID=xxxxx-xxxx
export ARM_CLIENT_SECRET=xxxxxxx
export ARM_SUBSCRIPTION_ID=xxxxx-xxxx
export ARM_TENANT_ID=xxxxx-xxxx
Now, Terraform can authenticate to Azure securely and automatically using the Service Principal

Summary
Using a Service Principal (either directly or via Managed Identity) is a secure and scalable way to let your Azure applications access other Azure resources — like Key Vault, Storage, or SQL — without using hardcoded credentials. This approach enhances security, supports automation, and aligns with DevSecOps best practices

Terraform is an open-source IaC (Infrastructure-as-Code) tool for configuring and deploying cloud infrastructure. It codifies infrastructure in configuration files that describe the desired state for your topology. Terraform allows you to use a consistent workflow over your infrastructure lifecycle, regardless of the resource provider. The infrastructure as code workflow lets your declaratively manage a variety of services and automate your changes to them, reducing the risk of human error through manual operations.

Advantages:

1. IAC is crucial because it helps to speed deployment and release of software

2. Terraforms support provide multi-cloud platforms like AWS, AZURE and Google etc..

3. IAC assist to restrict user to delete resources accidentally

4. Provide template to write code and use it many times

5. Unified template also provide security

• Workflows

1. In HCP Terraform, your resources are organized by workspaces, which contain your resource definitions, environment and input variables, and state files. A Terraform operation occurs within a workspace, and Terraform uses the configuration and state for that workspace to modify your infrastructure.

2. HCP Terraform supports three workflows for your Terraform runs:

• The CLI-driven workflow, which uses Terraforms standard CLI tools to execute runs in HCP Terraform.

• The UI/Version Control System(VCS)-driven workflow, in which changes pushed to version control repositories trigger runs in the associated workspace.

• The API-driven workflow, which allows you to create tooling to interact with the HCP Terraform API programmatically

Terraform Basic command:

Init : Validate working directory consisting of terraform config file. This is the first command to be executed after writing new file

Validate: Check for syntax and validate config file

Plan: Create execution plan

Apply: Apply changes and execute command to create resources

Destroy: Remove terraform managed resources. It will ask for confirmation before removing resources

Terraform Module Definition

A Terraform module is a container for multiple resources that are used together.

A module can be as simple as a single resource or as complex as a complete infrastructure stack.

Modules provide a modular structure with a clear separation of concerns, making infrastructure easier to manage, reuse, and maintain.

Example: Deploying a Resource Group with Terraform Modules

In this example, we use Terraform modules to deploy a Resource Group.
The project repository for the Resource Group creation is available here:
https://github.com/uttamchaturvedi9/terraformforcommunity

├── main.tf # Main Terraform configuration
├── variables.tf # Variable definitions
├── terraform.tfvars # variable values
├── modules/ # Terraform modules
│ └── resource-group/ # Resource Group module
│ ├── main.tf # Module main configuration
│ ├── variables.tf # Module variables
│ └── outputs.tf # Module outputs
└── README.md # This file

This repository demonstrates how to:

Define a Terraform module for Resource Group creation.

Use input variables for flexibility.

Apply modular structure for better reusability.

Summary
Terraform, as an Infrastructure as Code (IAC) tool, allows infrastructure provisioning and management through declarative configuration files. By defining resources in reusable modules, teams achieve:

Consistency: Repeatable deployments across environments.

Modularity : Clear separation of concerns, making code reusable and maintainable.

Scalability: Ability to orchestrate simple to complex infrastructure stacks.

Collaboration: Version-controlled infrastructure code shared across teams.

Conclusion
Using Terraform as IAC empowers organizations to manage infrastructure in the same way they manage application code. This approach reduces manual effort, minimizes errors, and accelerates delivery. With its modular design, state management, and provider ecosystem, Terraform provides a scalable, reliable, and automated way to orchestrate infrastructure, making it a cornerstone of modern DevOps practices.

Running code can be found here:

https://github.com/uttamchaturvedi9/terraformforcommunity

Problem Statement

An HTML file stored in Azure Blob Storage was not accessible when opened as a direct link.

The following issues were encountered:

• Without authentication, the blob was private and returned Authorization errors.

• When accessed via a generated SAS token, the browser attempted to download the file instead of rendering it as an HTML page.

• Direct access using a blob endpoint was not possible for users inside the network without special permissions.

The requirement was to make the file viewable in a browser as a web page via a shareable link while still controlling access.

The soultion is SAS tokens

After investigation, the following steps were taken to make the file accessible through a SAS token and open correctly in the browser.

Generate a SAS Token for the Blob

A Shared Access Signature (SAS) token grants time-limited and permission-scoped access to a specific blob without exposing the storage account key.

Steps (Azure Portal):

1. Navigate to the Azure Storage Account in the Azure Portal.

2. Go to Containers → open the target container (e.g., invetoryreport).

3. Locate and click on the HTML file (e.g., /stockdata/invetoryreport.html).

4. Click Generate SAS at the top.

5. Configure:

• Permissions: Read (r)

• Start time: A few minutes earlier than the current time (to avoid clock skew issues)

• Expiry time: As per requirement (e.g., 1 day or 1 week)

• Allowed protocol: HTTPS

• (Optional) Allowed IP addresses: Specify if restricting to certain networks

6. Click Generate SAS token and URL.

7. Copy the Blob SAS URL provided. This URL contains the file path and SAS token parameters.

Set Correct Content-Type for the Blob

By default, blobs may be served with the application/octet-stream MIME type, which forces browsers to download them. To make an HTML file render in a browser, the Content-Type must be set to text/html.

Steps (Azure Portal):

1. In the blob’s details page, click Properties.

2. Locate the Content-Type field.

3. Change the value to text/html

4. Save the changes.

Congratulations!!!! . Now you can access file directly in browser

Advantages of SAS Tokens

1. Granular Access Control You can grant access to specific resources (containers, blobs, queues, tables, files) without giving full account keys. Permissions can be fine-tuned (read, write, delete, list, etc.).

2. Time-Bound AccessTokens can expire automatically, reducing the risk of long-term exposure.

3. No Need to Share Account Keys Account keys give full access; a SAS token limits scope and reduces potential damage if compromised.

4. Temporary & Revocable You can revoke access by regenerating the storage account keys or changing stored policies.

5. Flexible Delivery Tokens can be passed via URLs, making them easy to use in applications, scripts, and APIs without extra authentication steps.

Disadvantages of SAS Tokens

1. Security Risk if Leaked Anyone with the SAS URL has the permissions until it expires — so tokens must be protected like passwords.

2. Difficult to Revoke Before Expiry For ad hoc SAS tokens (not tied to a stored access policy), you can’t revoke them without rotating the storage account key.

3. Potential for Over-Permissioning If not configured carefully, a token might allow more actions than intended.

4. Expiration Management Short expiry improves security but can cause operational issues if the token expires mid-process; long expiry increases risk if leaked.

5. Logging Limitations You can see when storage is accessed, but you can’t easily trace the identity of the person using the token — it’s just whoever has it.

💡 Best Practice:

• Use stored access policies where possible — they let you revoke a SAS without touching account keys.

• Always use HTTPS to prevent token sniffing.

• Keep SAS lifetimes short and permissions minimal.