DEV Community: Manohari Jayachandran

Swagger and OpenAPI: The Docs That Write Themselves

Manohari Jayachandran — Thu, 03 Sep 2026 14:29:13 +0000

"Swagger" and "OpenAPI" get used interchangeably, and untangling that is actually the first useful thing to do here, one is a specification, the other is a tool that renders it. This post uses the Product API from an earlier CRUD post as the running example throughout, since the goal is showing exactly how documentation gets generated from code you've already written, not introducing a new domain to learn alongside a new concept.

What Swagger and OpenAPI Actually Are

OpenAPI is a specification, a structured JSON or YAML document that precisely describes an API: every endpoint, every parameter, every request body shape, every possible response. Swagger UI is one specific tool that takes that OpenAPI document and renders it as an interactive, browsable webpage, letting someone read the docs and actually try a request right from the browser. Swagger existed before OpenAPI became the open, vendor-neutral standard name for the specification format, which is exactly why people still say "Swagger" when they technically mean "OpenAPI."

Think of a restaurant's recipe card versus its printed menu. The recipe card in the kitchen is the precise, structured truth, exact ingredients, exact quantities, exact steps. The printed menu a customer reads is a different, friendlier presentation of that same underlying information, letting the customer browse and choose without ever seeing the recipe card itself. OpenAPI is the recipe card. Swagger UI is the printed menu.

What the Actual Generated Document Looks Like

Before going further, it helps to actually see one. This is a trimmed excerpt of the real JSON that AddSwaggerGen() would produce for the GetById endpoint used throughout this post, the file a browser fetches at /swagger/v1/swagger.json, and the exact same file Swagger UI reads to render its interactive page.

{
  "openapi": "3.0.1",
  "info": {
    "title": "Products API",
    "version": "v1"
  },
  "paths": {
    "/api/Products/{id}": {
      "get": {
        "tags": ["Products"],
        "operationId": "GetById",
        "parameters": [
          {
            "name": "id",
            "in": "path",
            "required": true,
            "schema": { "type": "integer", "format": "int32" }
          }
        ],
        "responses": {
          "200": {
            "description": "Success",
            "content": {
              "application/json": {
                "schema": { "$ref": "#/components/schemas/ProductDto" }
              }
            }
          },
          "404": {
            "description": "Not Found"
          }
        }
      }
    }
  },
  "components": {
    "schemas": {
      "ProductDto": {
        "type": "object",
        "properties": {
          "id": { "type": "integer", "format": "int32" },
          "name": { "type": "string", "nullable": true },
          "price": { "type": "number", "format": "double" },
          "stockQuantity": { "type": "integer", "format": "int32" }
        }
      }
    }
  }
}

Every piece of this document maps directly to something already written in the code, "paths" comes from the controller's routes and HTTP verbs, the "200" and "404" entries come straight from the ProducesResponseType attributes covered next, and the ProductDto schema under "components" is a direct reflection of the DTO class itself, one property per line. This is genuinely the entire point of the post: nothing here was typed by hand into a documentation tool, it was all generated from code that already existed for other reasons.

How the Documentation Actually Gets Generated

The key thing to understand: you don't hand-write this specification. It's generated automatically by reflecting over your existing controllers, DTOs, and attributes, which is exactly why it can't silently drift out of date the way a manually maintained wiki page does.

// Program.cs - the two lines that turn this on
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.MapControllers();
app.Run();

// Visiting /swagger now shows a full interactive UI,
// built entirely from the ProductsController and DTOs
// already written for the CRUD post - nothing new to write

The Attributes That Shape the Generated Docs

By default, Swagger generates something reasonable but generic. Specific attributes let you control exactly what shows up, the response shapes, the possible status codes, and human-readable descriptions.

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [HttpGet("{id}")]
    [ProducesResponseType(typeof(ProductDto), StatusCodes.Status200OK)]
    [ProducesResponseType(StatusCodes.Status404NotFound)]
    public async Task<ActionResult<ProductDto>> GetById(int id)
    {
        var product = await _productService.GetByIdAsync(id);

        if (product == null)
            return NotFound();

        return Ok(product);
    }
}

These two ProducesResponseType attributes document both outcomes directly, a successful call returns a ProductDto shape with a 200, and a 404 is a documented, expected possibility, not a surprise. A frontend developer reading these generated docs never has to guess what a 404 from this specific endpoint means, or reverse-engineer it by triggering the error themselves.

// Adding a human-readable summary per endpoint
[HttpPost]
[SwaggerOperation(
    Summary = "Creates a new product",
    Description = "Validates the input and persists a new product record."
)]
public async Task<ActionResult<ProductDto>> Create(CreateProductDto dto)
{
    var created = await _productService.CreateAsync(dto);
    return CreatedAtAction(nameof(GetById), new { id = created.Id }, created);
}

// Requires the Swashbuckle.AspNetCore.Annotations NuGet package
// for [SwaggerOperation] specifically

Validation Attributes Show Up in the Docs Automatically

Here's a nice callback to the CRUD post: CreateProductDto's validation attributes weren't just added there to reject bad requests server-side, they do double duty, since Swagger reads them too and documents the actual constraints directly.

public class CreateProductDto
{
    [Required, MaxLength(200)]
    public string Name { get; set; }

    [Range(0.01, 1000000)]
    public decimal Price { get; set; }

    [Range(0, int.MaxValue)]
    public int StockQuantity { get; set; }
}

// In the generated Swagger UI, the Name field now shows
// as required with a 200-character max, and Price shows
// its valid range - all from attributes that were ALREADY
// there for a completely different reason (server-side
// validation), now also serving as documentation

Documenting Security Schemes

Without configuration, Swagger UI has no "Authorize" button and no way to actually test an authenticated endpoint from the browser. Adding a security scheme fixes this.

builder.Services.AddSwaggerGen(options =>
{
    options.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme
    {
        Name = "Authorization",
        Type = SecuritySchemeType.Http,
        Scheme = "Bearer",
        BearerFormat = "JWT",
        In = ParameterLocation.Header,
        Description = "Enter a valid JWT token"
    });

    options.AddSecurityRequirement(new OpenApiSecurityRequirement
    {
        {
            new OpenApiSecurityScheme
            {
                Reference = new OpenApiReference
                {
                    Type = ReferenceType.SecurityScheme,
                    Id = "Bearer"
                }
            },
            new string[] { }
        }
    });
});

// Swagger UI now shows an "Authorize" button - a caller
// can paste in a token once, and every subsequent
// "Try it out" request in the UI includes it automatically

Showing Multiple API Versions Side by Side

The same versioning concept from the APIM Part 2 post applies directly here, Swagger can present multiple documented versions of an API, letting a caller see exactly what changed between v1 and v2.

builder.Services.AddSwaggerGen(options =>
{
    options.SwaggerDoc("v1", new OpenApiInfo { Title = "Products API", Version = "v1" });
    options.SwaggerDoc("v2", new OpenApiInfo { Title = "Products API", Version = "v2" });
});

app.UseSwaggerUI(options =>
{
    options.SwaggerEndpoint("/swagger/v1/swagger.json", "Products API v1");
    options.SwaggerEndpoint("/swagger/v2/swagger.json", "Products API v2");
});

// A dropdown in Swagger UI now lets a caller switch between
// documented versions directly, rather than needing separate
// documentation pages maintained independently

The Practical Payoff: Exporting Into Postman

A well-documented OpenAPI spec isn't just for humans reading a webpage, it's a structured document another tool can consume directly. Postman can import it and build a complete, ready-to-use collection automatically.

With the app running, the raw spec is available at /swagger/v1/swagger.json. In Postman, choose Import and paste that URL, or upload the downloaded JSON file directly. Postman then generates a full collection automatically, every endpoint from ProductsController, correct HTTP verbs, correct routes, even example request bodies shaped according to CreateProductDto's properties.

This is the direct bridge between writing good Swagger documentation and having a genuinely useful Postman collection, without manually building every request by hand.

Problem Scenario and Solving Strategy

The problem: a frontend team keeps asking what fields the Create Product endpoint actually expects, what a 404 means specifically on GetById, and what the exact shape of a successful response looks like. Answers currently live in a wiki page that was accurate three months ago and hasn't been touched since.

The strategy, step by step:

First, recognize this is a documentation freshness problem, not a communication problem, the wiki isn't wrong because nobody cares, it's wrong because nothing keeps it in sync with the actual code.
Second, enable Swagger generation if it isn't already, AddSwaggerGen and UseSwaggerUI, since this alone produces accurate docs for every route, verb, and DTO shape, generated directly from the real, currently-running code.
Third, add ProducesResponseType attributes to each action for every realistic outcome, 200, 404, 400, since this is what actually documents what a given status code means for this specific endpoint, not just that it's possible.
Fourth, confirm CreateProductDto's existing validation attributes are already doing double duty as documentation, no extra work needed here, just point the frontend team at the generated docs instead of the stale wiki page.
Finally, delete or clearly mark the old wiki page as deprecated, redirecting to the live Swagger UI, since the single source of truth is now the running application itself, not a separate document someone has to remember to update.

Key Lessons

OpenAPI is the specification, a structured document, while Swagger UI is one tool that renders it as a browsable page, the two terms get used interchangeably but describe different things.

The documentation is generated from code that already exists, controllers, DTOs, attributes, which is exactly why it can't silently go stale the way a manually maintained wiki page does.

ProducesResponseType documents both success and failure shapes explicitly, turning "this might return a 404" into a documented, expected part of the contract.

Validation attributes on a DTO do double duty, the same Required and Range attributes enforcing rules server-side also document those exact constraints automatically.

A security scheme definition is what actually makes the Authorize button in Swagger UI functional for testing authenticated endpoints directly in the browser.

The OpenAPI spec is machine-readable, not just human-readable, Postman and other tools can import it directly to generate a complete, accurate collection automatically.

What's Next

The next post covers Postman itself in depth, collections, environment variables, where secrets actually belong, auth headers, request building, status codes, and writing tests, including the exact import workflow referenced at the end of this post.

Summary

Swagger and OpenAPI solve a problem every API eventually has, documentation that's accurate the day it's written and wrong a month later. Generating the docs directly from the code, rather than writing them separately, is what actually keeps that from happening: a validation attribute, a response type, a security scheme, each one written once for a different practical reason, and each one automatically becoming part of the documentation too. The real payoff shows up at the boundary between tools, a well-documented API can hand its entire shape directly to something like Postman, turning "read the docs and manually build a request" into "import the spec and get a working collection immediately."

Originally published at TechStack Blog:
https://www.techstackblog.com/post.html?slug=swagger-openapi-explained-with-example
More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

SOLID, the Repository Pattern, and Dependency Injection: One Complete Example, Every Principle Explained in Place

Manohari Jayachandran — Tue, 01 Sep 2026 13:30:19 +0000

Two things get confused constantly: the Repository Pattern gets used without anyone explaining what it actually is, and Dependency Inversion (a design principle) gets treated as the same thing as Dependency Injection (a technique), when they're genuinely different ideas that happen to work together. This post explains both properly, then builds one complete example, a small library book reservation system, and walks through exactly where each of the five SOLID principles shows up in that one piece of code, with an analogy and a concrete "how it's achieved" for each.

What the Repository Pattern Actually Is

A repository is a class whose only job is talking to a data source, a database, an API, a file, whatever it happens to be, and handing back plain objects. Everything else in the application, business logic, services, controllers, talks to the repository, never to the data source directly.

Think of a librarian. You don't walk into the archive room and dig through the shelves yourself. You ask the librarian, "get me this book," and they know exactly where it is and how to retrieve it. You don't need to know how the archive is organized internally, alphabetically, by genre, by acquisition date, none of that is your concern. The repository is the librarian. Your business logic is the visitor asking for a book.

How you actually achieve this: define an interface describing what can be asked for, get a book, save a book, mark a book reserved, then write one class that implements that interface using your real data source. Anything that needs data depends on the interface, never on the concrete data-access class directly.

DIP vs DI: Two Different Things That Work Together

The Dependency Inversion Principle, DIP, is a design rule. It says high-level code should depend on abstractions, interfaces, not on concrete, low-level classes. It's a statement about how your code should be shaped.

Dependency Injection, DI, is the mechanism that actually makes DIP work in practice. Instead of a class creating its own dependency directly inside itself, something external hands that dependency to the class, usually through its constructor.

Think of it this way. DIP is the rule that a lamp should plug into a standard wall socket, not have its wires hardwired directly into the wall. DI is the actual electrician who wires the socket and plugs the lamp in for you. DIP says what shape the connection should take. DI is who actually makes the connection happen. You can state the rule (DIP) without ever building the socket, and building the socket (DI) is what turns the rule into something real and usable.

The Example: A Library Book Reservation System

A small, complete system: a Book entity, a repository for storing and retrieving books, a notification piece that tells a member when their reserved book becomes available, and a service that ties the two together.

// Book.cs - the entity
public class Book
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string Author { get; set; }
    public bool IsAvailable { get; set; }
    public string? ReservedByMemberEmail { get; set; }
}

// IBookRepository.cs - the repository's contract
public interface IBookRepository
{
    Task<Book?> GetByIdAsync(int id);
    Task<List<Book>> GetAllAvailableAsync();
    Task<bool> ReserveAsync(int bookId, string memberEmail);
}

// BookRepository.cs - the concrete implementation
public class BookRepository : IBookRepository
{
    private readonly LibraryDbContext _context;

    public BookRepository(LibraryDbContext context)
    {
        _context = context;
    }

    public async Task<Book?> GetByIdAsync(int id)
        => await _context.Books.FindAsync(id);

    public async Task<List<Book>> GetAllAvailableAsync()
        => await _context.Books.Where(b => b.IsAvailable).ToListAsync();

    public async Task<bool> ReserveAsync(int bookId, string memberEmail)
    {
        var book = await _context.Books.FindAsync(bookId);
        if (book == null || !book.IsAvailable)
            return false;

        book.IsAvailable = false;
        book.ReservedByMemberEmail = memberEmail;
        await _context.SaveChangesAsync();
        return true;
    }
}

// INotificationSender.cs - the notification contract
public interface INotificationSender
{
    Task SendAsync(string recipient, string message);
}

// EmailNotificationSender.cs - one implementation
public class EmailNotificationSender : INotificationSender
{
    public async Task SendAsync(string recipient, string message)
    {
        // real email-sending logic would go here
        Console.WriteLine($"Email to {recipient}: {message}");
        await Task.CompletedTask;
    }
}

// SmsNotificationSender.cs - a second implementation, added later
public class SmsNotificationSender : INotificationSender
{
    public async Task SendAsync(string recipient, string message)
    {
        // real SMS-sending logic would go here
        Console.WriteLine($"SMS to {recipient}: {message}");
        await Task.CompletedTask;
    }
}

// BookReservationService.cs - the business logic, tying it together
public class BookReservationService
{
    private readonly IBookRepository _bookRepository;
    private readonly INotificationSender _notificationSender;

    public BookReservationService(
        IBookRepository bookRepository,
        INotificationSender notificationSender)
    {
        _bookRepository = bookRepository;
        _notificationSender = notificationSender;
    }

    public async Task<bool> ReserveBookAsync(int bookId, string memberEmail)
    {
        var success = await _bookRepository.ReserveAsync(bookId, memberEmail);

        if (success)
        {
            await _notificationSender.SendAsync(
                memberEmail,
                "Your book reservation is confirmed."
            );
        }

        return success;
    }
}

// Program.cs - registration
builder.Services.AddDbContext<LibraryDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("LibraryDb")));

builder.Services.AddScoped<IBookRepository, BookRepository>();
builder.Services.AddScoped<INotificationSender, EmailNotificationSender>();
builder.Services.AddScoped<BookReservationService>();

That's the whole example. Every SOLID principle below points back into this same code, nothing new gets introduced from here on, only explanation.

S: Single Responsibility Principle

What it means: a class should have exactly one reason to change.

Think of a chef who only cooks, versus a chef who also has to answer phones, manage the register, and clean tables. The moment the chef is responsible for four unrelated things, a change to any one of them, a new phone system, a new register, risks disrupting the cooking too. One job per role means a change in one area never accidentally breaks another.

Where it shows up here: BookRepository has exactly one job, talking to the database. BookReservationService has exactly one job, the actual reservation business rule, check availability, reserve, then notify. EmailNotificationSender has exactly one job, sending an email. None of these classes know or care about the others' internal details.

How it's achieved: by drawing a boundary around each distinct concern, data access, business rules, notification delivery, and giving each its own class rather than letting one class quietly grow to handle all three.

O: Open/Closed Principle

What it means: a class should be open for extension but closed for modification. You should be able to add new behavior without editing code that already works and is already tested.

Think of a power strip. Adding a new device means plugging into an open socket, not opening the strip and rewiring it. The strip itself never needs to change to support a new device.

Where it shows up here: SmsNotificationSender was added as a brand new class, implementing the same INotificationSender interface EmailNotificationSender already implements. BookReservationService, which depends only on INotificationSender, needed zero changes to support this new notification method.

How it's achieved: by depending on an interface, INotificationSender, rather than a specific class, so a new implementation can be introduced entirely alongside the old one, with the consuming code never needing to be touched or re-tested.

L: Liskov Substitution Principle

What it means: anywhere a base type or interface is expected, any implementation of it should be usable without breaking the correctness of the code using it.

Think of a universal TV remote. Pressing power should turn the TV off, regardless of which TV brand is actually connected. If pressing power on one specific brand instead changed the channel, that brand would violate the substitutability the remote's design depends on.

Where it shows up here: BookReservationService calls the notification sender's SendAsync method without knowing or caring whether it's actually an EmailNotificationSender or a SmsNotificationSender. Swapping the registration in Program.cs from one to the other requires zero changes to BookReservationService, and the reservation logic behaves correctly either way.

How it's achieved: by making sure every implementation of INotificationSender genuinely fulfills the same contract, send this message to this recipient, without secretly requiring different treatment or producing different side effects the caller wasn't told to expect.

I: Interface Segregation Principle

What it means: no class should be forced to depend on methods it doesn't actually use. Prefer several small, focused interfaces over one large one that tries to do everything.

Think of a restaurant menu split into starters, mains, and desserts, rather than one enormous single list. A customer who only wants dessert can look at exactly the dessert section, without wading through everything else to find what's relevant to them.

Where it shows up here: INotificationSender has exactly one method, SendAsync. It was deliberately not designed as a bloated interface with unrelated methods bolted on, like getting notification history, scheduling reminders, or configuring retry policies. If those needs arise later, they belong in their own separate interface, so a simple SmsNotificationSender is never forced to implement functionality that has nothing to do with sending a message.

How it's achieved: by keeping each interface scoped to one coherent capability, and introducing a new, separate interface when a genuinely different capability appears, rather than expanding an existing one to cover it.

D: Dependency Inversion Principle, and Where DI Actually Delivers It

What it means, again: BookReservationService, the high-level class containing the actual business rule, depends on IBookRepository and INotificationSender, the abstractions, not on BookRepository or EmailNotificationSender, the concrete low-level classes.

Where it shows up here: look at BookReservationService's constructor. Both parameters are interfaces. The class has no idea whether it's talking to a real SQL database or an in-memory test double, and no idea whether it's sending an email or a text message. That not-knowing is DIP, working correctly.

How DI actually delivers this: the constructor doesn't create a new BookRepository or a new EmailNotificationSender anywhere inside itself. Something external has to hand BookReservationService its dependencies. That's exactly what the three lines in Program.cs do, registering each interface against a concrete implementation, so that when the DI container builds a BookReservationService, it automatically supplies a real BookRepository and a real EmailNotificationSender, without BookReservationService itself ever needing to know how those objects got constructed.

This is the concrete answer to the DIP-versus-DI confusion from earlier: DIP is the fact that the constructor only asks for interfaces. DI is the three registration lines in Program.cs, plus the container's own internal machinery, that actually make those interfaces resolve to real objects at runtime.

Every Principle, At a Glance

S, Single Responsibility: BookRepository only accesses data, BookReservationService only contains the reservation rule, each notification sender only sends one kind of message.

O, Open/Closed: SmsNotificationSender was added as a new class, with zero changes to BookReservationService or EmailNotificationSender.

L, Liskov Substitution: EmailNotificationSender and SmsNotificationSender are both fully substitutable wherever INotificationSender is expected, BookReservationService behaves correctly with either one.

I, Interface Segregation: INotificationSender stays narrow, one method, one capability, rather than growing into an unrelated grab-bag interface.

D, Dependency Inversion: BookReservationService's constructor depends only on IBookRepository and INotificationSender, never on a concrete class.

DI, the mechanism: the three registration lines in Program.cs are what actually supply BookReservationService with real implementations at runtime, turning the DIP design rule into working code.

Key Lessons

A repository's entire purpose is to be the one place that knows how to talk to the actual data source, so everything else in the application can depend on a simple, plain-object contract instead.

DIP is a rule about how code should be shaped, depend on abstractions. DI is the mechanism, usually constructor injection plus a container, that actually fulfills that rule at runtime. They are not the same thing, even though they're almost always discussed together.

Every SOLID principle in this example points at a specific, real design decision in the code, not an abstract definition floating on its own, Single Responsibility is visible in how the classes are split, Open/Closed is visible in how a new notification type was added, and so on through all five.

A genuinely narrow interface, like INotificationSender with its one method, is what makes both Open/Closed and Interface Segregation possible at the same time, a bloated interface would have made adding SmsNotificationSender harder, not easier.

Summary

The Repository Pattern is a data-access class hiding behind a simple interface, so business logic never needs to know how or where data actually lives. DIP is the design rule that high-level code should depend on that interface, not on a concrete implementation. DI is the actual mechanism, constructor injection plus a container, that supplies the real implementation at runtime, making DIP something that genuinely happens rather than something merely stated. Built together into one small library reservation example, all five SOLID principles stop being five separate definitions to memorize and become five specific, visible decisions inside one coherent piece of working code.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=solid-repository-pattern-dependency-injection-library-example
More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

C# API CRUD Done Wrong, Then Done Right: A Complete Bad-Practices-vs-Best-Practices Walkthrough

Manohari Jayachandran — Sat, 29 Aug 2026 14:33:06 +0000

Most bad-code examples in tutorials are contrived - obviously wrong in a way real code never actually looks. This post takes a different approach: a complete, realistic Product CRUD API, built with thirteen anti-patterns that genuinely show up in codebases. Each endpoint is walked through one at a time - the bad version, exactly what's wrong with it and why, then the good version, right next to each other, so nothing needs to be hunted down elsewhere on the page.

The scope: a Product entity, five CRUD endpoints - GetAll, GetById, Create, Update, Delete.

Shared Setup: Program.cs

Bad version:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddSingleton<ProductsController>();

var app = builder.Build();
app.MapControllers();
app.Run();

// Inside ProductsController itself:
private readonly string _connectionString =
    "Server=prod-sql-01;Database=Products;User Id=sa;Password=Passw0rd123!;";

Issues:

Hardcoded connection string. A literal password is committed directly into source code. Anyone with repository access, including, eventually, anyone the repository is ever accidentally exposed to, has the production database password in plain text.
The fix: load the connection string from configuration, appsettings.json locally, environment variables or Key Vault in production, never as a literal string in a class.
Incorrect service lifetime, AddSingleton for a controller. Manually registering the controller itself with AddSingleton means exactly one instance of ProductsController is created and shared across every single request for the entire lifetime of the application, rather than the framework creating a fresh instance per request the normal way. This becomes genuinely dangerous the moment that controller, or anything it depends on, holds any per-request state, and it gets worse once a Scoped dependency like a DbContext enters the picture, since DbContext is explicitly not thread-safe and is designed to live for exactly one request. A Singleton capturing a Scoped dependency is a well-known anti-pattern called a "captive dependency" - the Scoped service effectively gets trapped inside the Singleton's lifetime, silently becoming a de facto singleton itself, shared across requests and threads it was never designed to be shared across.
The fix: never manually register a controller at all, AddControllers() already handles controller instantiation correctly per request, and give each dependency the lifetime that actually matches how it's meant to be used, which for something wrapping a DbContext means Scoped.

Good version:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddDbContext<ProductDbContext>(options =>
    options.UseSqlServer(
        builder.Configuration.GetConnectionString("ProductsDb")));

builder.Services.AddScoped<IProductService, ProductService>();
builder.Services.AddControllers();

var app = builder.Build();
app.MapControllers();
app.Run();

The connection string now comes from configuration. IProductService is registered as Scoped, not Singleton, one instance per HTTP request, matching the lifetime of the DbContext it wraps, and avoiding the captive dependency problem entirely. The controller itself is never manually registered at all; AddControllers() handles that correctly on its own.

Shared Setup: The Product Entity

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
    public int StockQuantity { get; set; }
    public string InternalSupplierNotes { get; set; }
    public decimal CostPrice { get; set; }
}

Identical in both versions - the entity itself isn't the problem. InternalSupplierNotes and CostPrice are genuinely internal fields, what the business actually pays a supplier, never meant for a customer-facing API to expose. What differs between versions is whether this exact class ever gets returned to a caller directly, covered in the GetById section below.

Endpoint 1: GetAll

Bad version:

[HttpGet]
public IActionResult GetAll()
{
    var products = GetAllProductsAsync().Result;
    return Ok(products);
}

private async Task<List<Product>> GetAllProductsAsync()
{
    var products = new List<Product>();
    using var connection = new SqlConnection(_connectionString);
    await connection.OpenAsync();

    var command = new SqlCommand("SELECT * FROM Products", connection);
    var reader = await command.ExecuteReaderAsync();

    while (await reader.ReadAsync())
    {
        products.Add(new Product
        {
            Id = reader.GetInt32(0),
            Name = reader.GetString(1),
            Price = reader.GetDecimal(2)
        });
    }
    return products;
}

Issues:

Missing await, .Result blocks the thread. GetAllProductsAsync().Result synchronously blocks the calling thread while waiting for the async method to complete, defeating the entire purpose of async and await, since the thread sits idle instead of being released back to the pool. In certain synchronization contexts, classic ASP.NET, WPF, WinForms, this specific pattern can cause a genuine deadlock.
The fix: use await all the way up the call chain, never call .Result or .Wait() on an async method.
Undisposed SqlCommand and SqlDataReader. Both command and reader implement IDisposable, but only connection gets a using statement here. SqlDataReader in particular keeps the underlying connection in a busy state until it's explicitly closed, so under real load, with many concurrent requests each doing this, connections return to the pool later than they need to, risking pool exhaustion faster than necessary. The outer using on connection happens to clean these up indirectly when it disposes, which is what keeps this specific method from actively breaking right now, but relying on that indirect cleanup rather than disposing each IDisposable explicitly is fragile, and won't hold up if the method returns early or the pattern changes later.
The fix: wrap every IDisposable in its own using statement, not just the outermost one.

Good version:

[HttpGet]
public async Task<ActionResult<List<ProductDto>>> GetAll()
{
    var products = await _productService.GetAllAsync();
    return Ok(products);
}

// Inside ProductService:
public async Task<List<ProductDto>> GetAllAsync()
{
    return await _context.Products
        .Select(p => new ProductDto
        {
            Id = p.Id,
            Name = p.Name,
            Price = p.Price,
            StockQuantity = p.StockQuantity
        })
        .ToListAsync();
}

Genuinely awaited from the controller all the way through the service call. EF Core's LINQ query is also parameterized automatically and projects directly to ProductDto - a preview of the DTO pattern the next endpoint introduces properly. There's also no manual connection, command, or reader to dispose at all here - EF Core's DbContext and its query execution manage the underlying ADO.NET resources internally, which is one more reason the disposal issue from the bad version simply can't occur in this version.

Endpoint 2: GetById

Bad version:

[HttpGet("{id}")]
public IActionResult GetById(int id)
{
    using var connection = new SqlConnection(_connectionString);
    connection.Open();

    var query = "SELECT * FROM Products WHERE Id = " + id;
    var command = new SqlCommand(query, connection);
    var reader = command.ExecuteReader();

    if (!reader.Read())
    {
        return Ok(null);
    }

    var product = new Product
    {
        Id = reader.GetInt32(0),
        Name = reader.GetString(1),
        Price = reader.GetDecimal(2)
    };

    return Ok(product);
}

Issues:

SQL injection. The id parameter is concatenated directly into the query string. A request to /api/products/1;DROP TABLE Products-- executes exactly that.
The fix: never build SQL by concatenating user input, use a parameterized query, or an ORM like EF Core that parameterizes automatically.
Ok(null) instead of NotFound(). When the product doesn't exist, this returns a 200 OK with an empty body. The caller can't distinguish "found nothing" from "succeeded, and the answer happens to be nothing," both look identical on the wire.
The fix: return NotFound(), a genuine 404, so the status code itself carries the information.
No DTO, full entity exposed. The returned product is the raw entity, including InternalSupplierNotes and CostPrice, fields that should never reach an API caller.
The fix: map to a ProductDto containing only the fields meant to be public.

Good version:

public class ProductDto
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
    public int StockQuantity { get; set; }
}

[HttpGet("{id}")]
public async Task<ActionResult<ProductDto>> GetById(int id)
{
    var product = await _productService.GetByIdAsync(id);

    if (product == null)
        return NotFound();

    return Ok(product);
}

// Inside ProductService:
public async Task<ProductDto?> GetByIdAsync(int id)
{
    var product = await _context.Products.FindAsync(id);
    // FindAsync uses the primary key safely - parameterized
    // automatically, no string concatenation anywhere

    if (product == null)
        return null;
    // Returning null here is fine - it's the CONTROLLER's
    // job to translate this into the correct HTTP response,
    // not the service's

    return new ProductDto
    {
        Id = product.Id,
        Name = product.Name,
        Price = product.Price,
        StockQuantity = product.StockQuantity
    };
}

All three issues fixed together: FindAsync makes SQL injection structurally impossible, NotFound() makes the response honest, and ProductDto makes leaking internal fields impossible rather than something to remember not to do.

Endpoint 3: Create

Bad version:

[HttpPost]
public IActionResult Create(Product product)
{
    using var connection = new SqlConnection(_connectionString);
    connection.Open();

    var query = $"INSERT INTO Products (Name, Price) " +
                 $"VALUES ('{product.Name}', {product.Price})";
    var command = new SqlCommand(query, connection);
    command.ExecuteNonQuery();

    _logger.LogInformation(
        "Product created by user {Email} with auth token {Token}: {Name}",
        currentUser.Email, currentUser.AuthToken, product.Name);

    return Ok(product);
}

Issues:

No validation. A request with an empty Name, a negative Price, or missing fields is accepted exactly as-is.
The fix: add validation attributes to a dedicated input DTO, paired with ApiController's automatic model validation.
SQL injection, again. Same pattern as GetById, product.Name concatenated directly, and this version breaks entirely if the name contains a single quote.
The fix: same as before, EF Core, parameterized automatically.
Wrong status code. Returns 200 OK for a successful creation.
The fix: 201 Created, with a Location header pointing to the new resource, since 200 doesn't communicate "a new thing was created."
Sensitive data logged in plain text. The user's email is reasonable to log, but the auth token is a genuine secret, and it's now sitting in plain text inside Application Insights or Log Analytics, visible to anyone with read access to logs, often retained for weeks or months. A leaked or overly-permissioned log query becomes a credential leak.
The fix: never log secrets, tokens, passwords, or other sensitive fields, log an identifier (a user ID) instead of the credential itself, and if a field must be referenced for debugging, mask or redact it before it reaches the logger.

Good version:

public class CreateProductDto
{
    [Required, MaxLength(200)]
    public string Name { get; set; }

    [Range(0.01, 1000000)]
    public decimal Price { get; set; }

    [Range(0, int.MaxValue)]
    public int StockQuantity { get; set; }
}

[HttpPost]
public async Task<ActionResult<ProductDto>> Create(CreateProductDto dto)
{
    // No manual validation check needed - [ApiController]
    // automatically returns 400 Bad Request if the DTO's
    // validation attributes aren't satisfied, before this
    // method body even runs

    var created = await _productService.CreateAsync(dto);

    _logger.LogInformation(
        "Product {ProductId} created by user {UserId}",
        created.Id, currentUser.Id);
    // Logs an IDENTIFIER, never a credential or token -
    // enough to trace who did what, without exposing
    // anything an attacker or an over-permissioned log
    // reader could actually use

    return CreatedAtAction(
        nameof(GetById),
        new { id = created.Id },
        created);
}

// Inside ProductService:
public async Task<ProductDto> CreateAsync(CreateProductDto dto)
{
    var product = new Product
    {
        Name = dto.Name,
        Price = dto.Price,
        StockQuantity = dto.StockQuantity
    };

    _context.Products.Add(product);
    await _context.SaveChangesAsync();

    return new ProductDto
    {
        Id = product.Id,
        Name = product.Name,
        Price = product.Price,
        StockQuantity = product.StockQuantity
    };
}

CreateProductDto's Required, MaxLength, and Range attributes are checked automatically by ApiController. CreatedAtAction returns the correct 201 with a Location header built from the GetById action. The log statement now records a user ID, not a credential, and EF Core removes the SQL injection path entirely.

Endpoint 4: Update

Bad version:

[HttpPut("{id}")]
public IActionResult Update(int id, Product product)
{
    try
    {
        using var connection = new SqlConnection(_connectionString);
        connection.Open();

        var query = $"UPDATE Products SET Name = '{product.Name}', " +
                    $"Price = {product.Price} WHERE Id = {id}";
        var command = new SqlCommand(query, connection);
        command.ExecuteNonQuery();
    }
    catch (Exception ex)
    {
        return Ok(new { error = ex.ToString() });
    }

    return Ok();
}

Issues:

Swallowed exception behavior masked as a response. The catch block doesn't silently discard the exception here, but it does something almost as problematic in a different way, it converts a failure into a 200 OK response body, meaning the HTTP status code itself claims success while the actual content says otherwise. Callers checking only the status code, which is the normal way to check for success, will treat this as a successful update.
The fix: return an actual error status code, and don't rely on the response body alone to communicate failure.
SQL injection, again. Same string-concatenation pattern as the previous two endpoints.
Full exception details leaked to the caller. ex.ToString() returns the complete exception message and full stack trace, including internal file paths, method names, and sometimes literal fragments of the failed SQL query itself, all sent directly to whoever called this endpoint. This is genuinely useful reconnaissance for an attacker probing the API, and it's an accidental disclosure of internal implementation detail even to a well-meaning caller.
The fix: log the full exception detail internally, server-side, and return only a generic, safe error message to the caller.

Good version:

[HttpPut("{id}")]
public async Task<IActionResult> Update(int id, CreateProductDto dto)
{
    var success = await _productService.UpdateAsync(id, dto);

    if (!success)
        return NotFound();

    return NoContent();
}

// Inside ProductService:
public async Task<bool> UpdateAsync(int id, CreateProductDto dto)
{
    var product = await _context.Products.FindAsync(id);
    if (product == null)
        return false;

    product.Name = dto.Name;
    product.Price = dto.Price;
    product.StockQuantity = dto.StockQuantity;

    try
    {
        await _context.SaveChangesAsync();
        return true;
    }
    catch (DbUpdateException ex)
    {
        // The FULL exception, including stack trace, is
        // logged INTERNALLY here - visible to the team via
        // Application Insights, never sent to the caller
        _logger.LogError(ex, "Failed to update product {Id}", id);
        return false;
    }
}

The exception is now caught narrowly, DbUpdateException, not the broad Exception base class, logged internally in full detail with _logger.LogError, and the method returns false so the controller responds with a correct NotFound or, in a fuller version, a generic 500 with a safe message, never the raw exception content itself.

Endpoint 5: Delete

Bad version:

[HttpDelete("{id}")]
public IActionResult Delete(int id)
{
    using var connection = new SqlConnection(_connectionString);
    connection.Open();

    var query = "DELETE FROM Products WHERE Id = " + id;
    var command = new SqlCommand(query, connection);
    command.ExecuteNonQuery();

    return Ok();
}

Issues:

SQL injection, again. The same concatenation pattern as every other endpoint above.
Wrong status code. Returns 200 OK with no body for a successful delete. The fix: 204 No Content, the correct response when an operation succeeds and there's genuinely nothing further to return.

Good version:

[HttpDelete("{id}")]
public async Task<IActionResult> Delete(int id)
{
    var success = await _productService.DeleteAsync(id);

    if (!success)
        return NotFound();

    return NoContent();
}

// Inside ProductService:
public async Task<bool> DeleteAsync(int id)
{
    var product = await _context.Products.FindAsync(id);
    if (product == null)
        return false;

    _context.Products.Remove(product);
    await _context.SaveChangesAsync();
    return true;
}

The Complete Good-Version Service Interface

Pulling every service method from above together into the one interface the controller actually depends on:

public interface IProductService
{
    Task<List<ProductDto>> GetAllAsync();
    Task<ProductDto?> GetByIdAsync(int id);
    Task<ProductDto> CreateAsync(CreateProductDto dto);
    Task<bool> UpdateAsync(int id, CreateProductDto dto);
    Task<bool> DeleteAsync(int id);
}

This is the layer that never existed in the bad version at all, the bad controller talked directly to SqlConnection. Having this interface is also what makes the controller genuinely unit-testable with a mock, something effectively impossible against the bad version's design.

Attribute Reference: What's Doing the Actual Work

ApiController enables automatic model validation, checking a DTO's validation attributes and returning 400 automatically if they fail, before the action method body runs. Present in both versions, but only doing real work in the good one, since the bad version's Product parameter has no validation attributes for it to check.

Route with the controller token sets the base route, "api/products," identical in both versions.

HttpGet, the id-scoped HttpGet, HttpPost, the id-scoped HttpPut, and the id-scoped HttpDelete map each method to its HTTP verb and route, the routing itself was never the problem in the bad version.

Required, MaxLength, and Range on CreateProductDto are declarative validation rules, good version only, paired with ApiController to reject invalid requests automatically, with zero manual if-checks.

Every Issue, At a Glance

Hardcoded connection string, in Program.cs and setup.
Bad: literal password committed in source code.
Good: loaded from configuration or Key Vault.
Incorrect service lifetime, AddSingleton for a controller, in Program.cs and setup.
Bad: the controller manually registered as Singleton, one shared instance forever, risking a captive dependency once a Scoped DbContext enters the picture.
Good: the controller is never manually registered at all, and IProductService is registered as Scoped, matching the DbContext's own lifetime.
Missing await / .Result, in GetAll.
Bad: .Result blocks the thread synchronously.
Good: await released the thread properly, all the way through.
Undisposed SqlCommand and SqlDataReader, in GetAll.
Bad: only connection wrapped in a using, command and reader never explicitly disposed, relying on indirect cleanup that isn't reliable.
Good: EF Core manages the underlying ADO.NET resources internally, so there's no manual disposal to get wrong.
SQL injection, appearing in GetById, Create, Update, and Delete.
Bad: string-concatenated raw SQL.
Good: EF Core LINQ or FindAsync, parameterized automatically.
Ok(null) instead of NotFound(), in GetById.
Bad: 200 OK with a null body when not found.
Good: NotFound(), a genuine 404.
No DTOs, full entity exposed, in GetById.
Bad: internal fields like CostPrice and supplier notes exposed.
Good: ProductDto excludes them entirely, structurally impossible to leak.
No validation, in Create.
Bad: any data accepted as-is.
Good: Required, MaxLength, and Range attributes plus ApiController auto-reject invalid requests.
Wrong status codes, in Create and Delete.
Bad: 200 OK for create and delete.
Good: 201 Created with a Location header for create, 204 No Content for delete.
Sensitive data logged in plain text, in Create.
Bad: an auth token logged directly, sitting in plain text in Application Insights.
Good: only a user ID logged, never a credential or token.
Swallowed exception behavior masked as a response, in Update.
Bad: a failure converted into a 200 OK response body, status code claims success while content says otherwise.
Good: an honest result returned, false propagated up so the controller can respond correctly.
Full exception details leaked to the caller, in Update.
Bad: ex.ToString(), including the full stack trace, returned directly in the API response.
Good: the full exception logged internally only, a generic safe message, if any, returned to the caller.
No service layer, structural, underneath all endpoints.
Bad: controller does raw data access directly.
Good: IProductService and ProductService, separated, testable, the natural home for every other fix.

Key Lessons

Every anti-pattern here is realistic, these are mistakes that genuinely appear in real production code, not exaggerated examples built just to be wrong.

The missing service layer is structurally connected to most of the other issues, a controller doing raw data access directly removes the natural place validation, parameterization, and error handling would otherwise live.

A DTO isn't just extra code, it's what makes leaking internal fields structurally impossible, rather than something a developer has to remember not to do.

Status codes are information, not decoration, Ok(null), 200 for a create, and 200 for a delete each communicate something genuinely false or ambiguous to the caller.

Logging and error responses are both genuine attack surfaces, not just debugging conveniences, a logged token or a leaked stack trace can hand an attacker exactly what they need, even when the code otherwise "works."

A swallowed exception, or one disguised as a success response, is worse than a crash, a crash is visible immediately, a silently hidden failure looks like success and can go unnoticed for a long time.

Summary

Every issue in the bad version compiles, runs, and looks like reasonable code at a glance, which is exactly why these patterns survive in real codebases far longer than obviously broken code ever would. Rebuilding the same five endpoints with a real service layer, correct dependency lifetimes, disciplined resource disposal, DTOs, parameterized queries, genuine async, proper validation, correct status codes, and careful logging doesn't just fix thirteen individual bugs, it changes the shape of the code so that several of those bugs become structurally difficult to reintroduce by accident.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=csharp-api-crud-bad-vs-good-practices
More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Azure Integration Services Interview Prep Part 4: Application Insights, Log Analytics, Distributed Tracing, and Debugging a Broken Pipeline

Manohari Jayachandran — Mon, 24 Aug 2026 23:37:15 +0000

Part 1 covered the messaging services. Part 2 covered orchestration. Part 3 covered how the whole pipeline gets secured. None of that matters if something breaks at 2am and there's no way to find out why. This part covers the actual toolkit for debugging and monitoring a real Azure integration pipeline, and deliberately ties every tool back to the specific services already built across Parts 1 through 3, the same pattern the whole series has followed.

Topic 1: Application Insights

Application Insights is Azure's Application Performance Monitoring service, covered in real depth in an earlier post on this blog. It automatically collects telemetry from your applications - every request, every dependency call, every exception, every custom log message.

Think of a flight data recorder, continuously capturing everything happening during a flight, automatically, without the pilot needing to manually log anything - so if something goes wrong, there's a complete, detailed record to investigate afterward.

Application Insights fits anywhere in the pipeline that runs actual code - Function Apps, and any custom API behind APIM - anywhere telemetry needs to be automatically captured without manual logging discipline being the only safety net.

To activate it in a Function App or any ASP.NET Core project, install the NuGet package Microsoft.ApplicationInsights.AspNetCore, then in Program.cscall AddApplicationInsightsTelemetry with the connection string, linked either directly in App Service Configuration or via a Key Vault reference, which is the same Managed Identity plus Key Vault pattern covered in Part 3. Logic Apps get enabled differently, through Diagnostic Settings instead of code, since Logic Apps don't run custom compiled code - Diagnostic settings, Add diagnostic setting, Send to Log Analytics workspace, covered next.

// Function App / any ASP.NET Core project
// 1. Install NuGet: Microsoft.ApplicationInsights.AspNetCore
// 2. In Program.cs:
builder.Services.AddApplicationInsightsTelemetry(
    builder.Configuration["ApplicationInsights:ConnectionString"]
);

What kind of debugging and monitoring it does: it captures the four core telemetry types -

requests, every HTTP call in or out;
dependencies, every outbound call your code makes, SQL, Service Bus, an external API;
exceptions, full stack traces;
traces, your own ILogger output.

This is the raw material every other debugging technique in this post is actually built on top of.

How this connects to Parts 1 through 3: a Function App triggered by Service Bus, from Parts 1 and 2, automatically logs that trigger as a dependency call. A call to Key Vault for a secret, from Part 3, shows up as a dependency too. Nothing needs manual instrumentation for these - App Insights captures the entire pipeline's activity automatically, the moment it's wired in.

Topic 2: Log Analytics Workspace

A Log Analytics workspace is the actual queryable data store that Application Insights telemetry, and diagnostic logs from many other Azure services, gets written into. This is a genuinely common point of confusion worth being precise about: Application Insights is the collector; Log Analytics is the warehouse the collected data actually lives in, queried using KQL.

Think of it this way: if Application Insights is the flight data recorder capturing everything during the flight, Log Analytics is the secure archive facility where every recorder's data actually gets stored and can be pulled up for analysis later - and critically, multiple flight recorders, multiple Azure resources, can all feed into the same archive facility.

This one-workspace, multiple-sources model matters because a single Log Analytics workspace can receive telemetry from Application Insights, your Function Apps' code-level telemetry, Logic Apps diagnostic logs covering run history and trigger or action outcomes, Service Bus diagnostic logs covering message counts and dead-letter activity, Azure SQL diagnostic logs covering query performance and errors, and APIM diagnostic logs covering every gateway request. This means one KQL query, against one workspace, can correlate data across services that would otherwise live in completely separate places.

To activate it, first create a Log Analytics workspace, or use an existing one, through Azure Portal, Log Analytics workspaces, Create. Then for each service in the pipeline, point its diagnostic settings at this same workspace - Service Bus namespace, Diagnostic settings, Add, Send to Log Analytics workspace, and repeat this for Logic Apps, SQL, and APIM. Application Insights resources can also be workspace-based, meaning their data lands in this same shared Log Analytics workspace automatically rather than a separate silo.

What kind of debugging and monitoring it does: it's not itself a monitoring feature - it's the foundation that makes cross-service KQL querying possible at all. Its actual monitoring value shows up entirely through the queries run against it, covered in the next topic.

How this connects to Parts 1 through 3: a single Log Analytics workspace receiving diagnostic data from every service across the Part 2 end-to-end pipeline, APIM, Logic App, Function App, Service Bus, SQL, is what makes it possible to write one query tracing a single request across all of those services together, rather than needing to check five separate places manually.

Topic 3: KQL Query Patterns for This Pipeline

This is Kusto Query Language, covered in general depth in an earlier post on this blog, applied here specifically to the multi-service pipeline built across Parts 1 through 3, rather than a single application's logs in isolation.

Think of it the same way it was covered in the earlier KQL post - SQL for your telemetry, reading left to right through pipe operators.

KQL fits the Log Analytics workspace's Logs blade, or directly within Application Insights' own Logs view, which queries the same underlying data when workspace-based.

// Failed requests across the WHOLE pipeline, not just
// one service, in the last hour
union requests, dependencies
| where timestamp > ago(1h)
| where success == false
| project timestamp, itemType, name, resultCode, duration
| order by timestamp desc

// Service Bus dependency calls specifically, filtered
// from the general dependencies stream
dependencies
| where timestamp > ago(1h)
| where type == "Azure Service Bus"
| where success == false
| project timestamp, name, target, resultCode

// Correlate a Function App exception to the specific
// Service Bus message that triggered it
exceptions
| where timestamp > ago(1h)
| where operation_Name == "ProcessOrder"
| project timestamp, outerMessage, operation_Id
// operation_Id here is the thread to pull -
// covered fully in the next topic

What kind of debugging and monitoring it does: ad-hoc investigation, answering a specific question about what happened, when, and how often, across however many services the query is scoped to touch.

How this connects to Parts 1 through 3: every problem scenario across Parts 1 and 2, a stuck order, a failed transformation, a dead-lettered message, ultimately gets investigated by writing a KQL query shaped like the ones above, filtered to the specific service, time window, and operation involved.

Topic 4: Distributed Tracing with operation_Id

Every request entering the pipeline gets a unique operation_Id automatically. Every dependency call, log message, and exception that happens while that request is being handled, across every service it touches, shares that same identifier.

Think of a single tracking number on a package that gets handed off between multiple couriers, warehouses, and delivery trucks. Each handoff point logs an update against that same tracking number, so the package's entire journey can be reconstructed from pickup to delivery, regardless of how many different companies handled it along the way.

This is automatic once Application Insights is wired in, from Topic 1, with no additional activation step needed. The operation_Id propagates automatically across HTTP calls, Service Bus messages, and Function App executions within the same Azure telemetry ecosystem. To make it explicitly visible in your own logs, you can log it directly alongside your own structured logging.

_logger.LogInformation(
    "Processing order {OrderId} with operation {OperationId}",
    order.Id,
    Activity.Current?.RootId ?? "unknown"
);

// Tracing ONE request's complete journey across
// every service it touched
union requests, dependencies, exceptions, traces
| where timestamp > ago(1h)
| where operation_Id == "abc123-def456"
| project timestamp, itemType, name, message, success
| order by timestamp asc

// Output reconstructs the ENTIRE path:
// 08:00:01 request   POST /orders (APIM)
// 08:00:02 dependency Logic App triggered
// 08:00:03 dependency Function App: ValidateOrder
// 08:00:04 dependency Service Bus: message sent
// 08:00:05 dependency Azure SQL: INSERT
// 08:00:05 request   200 OK returned

What kind of debugging and monitoring it does: answers "what actually happened to this specific request" - the single most useful debugging technique when a specific customer or specific order is reported as broken, rather than a general pattern across many requests.

How this connects to Parts 1 through 3: this is the technique that makes the entire Part 2 complete-picture pipeline, APIM to Logic App to Function App to Service Bus to SQL, genuinely traceable end to end, exactly as referenced when that pipeline was first built - this topic is where that promise actually gets fulfilled with a real, runnable query.

Topic 5: Investigating a Failed Logic App Run

Logic Apps maintain a Run History - a literal, step-by-step record of every trigger and action for every execution, including the exact input and output of each individual step.

Think of a black-box flight recorder specifically for one single flight, showing every single instrument reading at every point during that one flight - not a general log, a complete replay of exactly what happened, action by action.

To access it, go to your Logic App's Overview page in the Azure Portal, where Runs history is shown automatically, no separate activation needed, since this is built in by default. Click any run, especially one marked Failed, to see every action in the workflow, color-coded green for succeeded or red for failed. Click the red action specifically to see its exact input, what data it received, and exact output, the error it actually threw.

The actual investigation flow looks like this: open Runs history and filter to Status Failed, click the specific failed run, visually scan for the red failed action in the sequence, click it and expand Inputs to see exactly what this action received from the previous step, expand Outputs to see the exact error message and status code returned, and use Resubmit to re-run this exact same run, with the same input, after fixing the underlying issue, without needing to wait for a new trigger.

What kind of debugging and monitoring it does: deterministic, step-by-step replay of exactly what happened in one specific Logic App execution - genuinely the fastest way to debug a Logic App failure, since it requires no KQL query at all, just clicking through the visual designer's own run history.

How this connects to Parts 1 through 3: in the Part 2 Logic Apps problem scenario, polling a partner API, validating, writing to SQL, a failure here, the partner API returning an unexpected shape, a validation condition behaving unexpectedly, is diagnosed by opening exactly this Run History view and inspecting the specific action that failed.

Topic 6: Investigating a Function App Failure

There are two complementary tools here - Live Metrics for what's happening right now, and Application Insights' Failures blade for investigating what already happened, down to the actual stack trace.

Think of Live Metrics as watching a patient's vital signs monitor in real time during a procedure. The Failures blade is the detailed medical chart reviewed afterward to understand exactly what went wrong and when.

Live Metrics, for real-time monitoring during an active incident, is accessed through your App Insights resource, Live Metrics, showing incoming request rate, failure rate, CPU and memory per instance, and exception rate, all with sub-second latency, genuinely real-time, with no activation needed beyond Application Insights already being wired in from Topic 1. The Failures blade, for after-the-fact investigation, is accessed through your App Insights resource, Failures, showing failed requests grouped by operation, exception types grouped and counted, and clicking into any one shows the full stack trace down to the exact line of code that threw.

// The KQL equivalent of what the Failures blade
// shows visually, if querying directly
exceptions
| where timestamp > ago(24h)
| where operation_Name == "ProcessOrder"
| summarize Count = count() by type, outerMessage
| order by Count desc
// Groups thousands of raw exception rows into a
// handful of actual distinct problems - the same
// technique covered in the earlier KQL post

What kind of debugging and monitoring it does: Live Metrics answers "is this actively getting worse right now" during a live incident, particularly useful right after a deployment. The Failures blade answers "what specifically broke, how often, and where in the code" after the fact.

How this connects to Parts 1 through 3: the Part 2 Function Apps problem scenario, complex order transformation logic, if that transformation throws an unexpected exception on a specific SKU format, the Failures blade's stack trace points to the exact line in the OrderTransformer class, from Part 2's example, where it happened.

Topic 7: Dead-Letter Queue Investigation

This is a direct callback to Service Bus from Part 1 - when a message exhausts its retry attempts, it moves to the Dead Letter Queue rather than disappearing, and it carries specific metadata explaining exactly why.

Think of a returned-mail bin at a post office, where every piece of undeliverable mail gets a stamped note explaining specifically why it couldn't be delivered, refused, address not found, damaged, rather than just being discarded with no explanation.

To access it through the portal, go to your Service Bus namespace, your queue, and look for the message count next to Dead-letter messages specifically, separate from the main queue's active message count. Programmatically, you create a receiver scoped to the dead-letter sub-queue directly.

var receiver = client.CreateReceiver(
    "myqueue",
    new ServiceBusReceiverOptions {
        SubQueue = SubQueue.DeadLetter
    }
);

var messages = await receiver.ReceiveMessagesAsync(10);
foreach (var msg in messages)
{
    // These two fields are the actual answer to
    // "why did this fail" - always check them FIRST
    Console.WriteLine($"Reason: {msg.DeadLetterReason}");
    Console.WriteLine($"Description: {msg.DeadLetterErrorDescription}");
    Console.WriteLine($"Body: {msg.Body}");
}

The actual investigation decision, once you know why, breaks into three paths. A genuine data problem, a bad SKU format or a missing field, means fixing the source data and manually resubmitting the message. A transient issue now resolved, a downstream API briefly down during the original attempts, means simply resubmitting the message as-is, with no data change needed. An actual bug in the processing code means fixing the code, redeploying, and only then resubmitting affected messages, since resubmitting before the fix just dead-letters them again.

What kind of debugging and monitoring it does: root-cause investigation for messages that definitively failed processing - the DeadLetterReason and DeadLetterErrorDescription fields specifically exist to turn "something failed" into a precise, actionable reason.

How this connects to Parts 1 through 3: this directly extends the Part 1 Service Bus problem scenario, per-customer ordered processing with a dead-letter queue configured - this topic is literally "what do you actually do once something lands there," which the earlier scenario's strategy stopped short of covering.

Topic 8: Alerting Strategy

Alerting means proactive notification when something goes wrong, rather than only finding out when a customer complains or someone happens to check a dashboard.

Think of a smoke detector versus manually checking every room for fire periodically. Alerting means the system tells you the moment something crosses a genuinely concerning threshold, rather than you needing to remember to go looking.

To activate it, go to the specific resource, or the Log Analytics workspace for cross-service alerts, in the Azure Portal, then Alerts, Create, Alert rule. You define a signal or condition, either a metric threshold or a KQL log query returning results, an action group specifying who gets notified, email, SMS, a Teams webhook, or triggering another Function App, and a severity level.

// A genuinely useful custom log alert - fires when
// the Service Bus Dead Letter Queue has ANY messages
Custom log search alert, KQL:
AzureMetrics
| where MetricName == "DeadletteredMessages"
| where Total > 0

// A DLQ alert should almost always exist, given
// Topic 7 - a message sitting there with nobody
// notified defeats the purpose of having a DLQ
// at all instead of just losing the message silently

The key distinction worth getting right is rate versus raw count. Alerting on "5 failures" means the same rule fires identically whether that's 5 failures out of 10 requests, a genuinely broken 50% failure rate, or 5 failures out of 50,000 requests, likely normal background noise. Alerting on failure rate, not raw count, is what actually distinguishes a real incident from expected noise.

// Rate-based alert, not raw count
requests
| where timestamp > ago(5m)
| summarize Total = count(), Failed = countif(success == false)
| extend FailureRate = round(100.0 * Failed / Total, 1)
| where FailureRate > 10
// Fires only when MORE THAN 10% of requests failed
// in the last 5 minutes, not just "5 failures happened"

What kind of debugging and monitoring it does: it shifts from reactive, someone reported a problem, let's investigate, to proactive, the team knows within minutes, often before a customer notices at all.

How this connects to Parts 1 through 3: a genuinely complete pipeline built across this series would have alerts on at minimum Service Bus DLQ count greater than 0, from Topic 7, Function App failure rate exceeding a threshold, from Topic 6, and Logic App run failure count, from Topic 5 - alerting is what turns everything else in this post from tools available if you go looking into the team finding out automatically.

Putting It Together: "Something Is Broken, Walk Me Through Your Process"

This exact question shape is one of the most common in a panel interview for this topic area. Here's the structured answer, built entirely from this post's tools.

First, an alert fires, from Topic 8 - failure rate on the order-processing Function App exceeded 10% in the last 5 minutes.
Second, open the Failures blade, from Topic 6, in Application Insights, and immediately see the exception type and count driving this, say, a specific ValidationException spiking.
Third, click into one specific failed request and note its operation_Id.
Fourth, run a distributed tracing query, from Topic 4, using that operation_Id, reconstructing the full path this specific request took: APIM, Logic App, Function App, and where it actually failed.
Fifth, if the failure happened inside a Logic App action specifically, open Run History, from Topic 5, for that exact run, and inspect the failing action's input and output directly.
Sixth, if the message was ultimately dead-lettered, from Topic 7, check DeadLetterReason and DeadLetterErrorDescription for the precise cause.
Seventh, once the root cause is identified, say a partner started sending a new SKU format the validation logic doesn't recognize, fix the code, redeploy, then resubmit the affected dead-lettered messages.
Eighth, write, or confirm the existence of, a KQL-based alert, from Topic 8, that would catch this specific failure pattern earlier next time.

This is the shape of answer, naming specific tools in a specific order, each connected to a specific part of the pipeline already built across this series, that demonstrates real operational thinking, not just naming Application Insights as a one-word answer.

Key Lessons

Application Insights collects telemetry automatically; Log Analytics is the queryable store that telemetry lives in - understanding this relationship matters more than most people initially assume.

operation_Id is what makes a request genuinely traceable across every service it touches - this is the technique that fulfills the complete-picture promise from Part 2's pipeline diagram.

A Logic App's Run History gives deterministic, step-by-step replay with exact input and output per action - often faster to debug than writing a KQL query at all.

Live Metrics answers "what's happening right now"; the Failures blade answers "what already happened and exactly where in the code" - different tools for different moments in an incident.

A dead-lettered message's DeadLetterReason and DeadLetterErrorDescription should always be checked first, before any other investigation - they often directly answer why without further digging.

Alert on failure rate, not raw error count - the same absolute number means something completely different depending on total volume.

The strongest interview answer to "something is broken, walk me through it" names specific tools in a specific sequence, each tied to a specific part of a real pipeline, not a generic list of Azure service names.

The Series, Complete

This closes out the Azure integration interview prep series. Part 1 covered the messaging services - Service Bus, Storage Queues, Event Hub, Event Grid. Part 2 covered the orchestration layer - Logic Apps, Function Apps, Durable Functions. Part 3 covered how that pipeline actually gets secured - Managed Identity, Key Vault, VNet Integration, Private Endpoints, NSGs, RBAC, and token validation. Part 4 covered debugging and monitoring the pipeline once something inevitably goes wrong - Application Insights, Log Analytics, distributed tracing, and a structured process for the "something is broken" question. Four parts, one complete architecture story, from how data enters the system to how a failure gets traced back to its exact root cause.

Summary

Debugging and monitoring complete the picture built across this entire series - a pipeline that moves data reliably, from Part 1, processes it with the right orchestration tool, from Part 2, and is genuinely secured end to end, from Part 3, still needs a real answer for "how do you know when it breaks, and how do you find out why." Application Insights and Log Analytics capture and store the telemetry. operation_Id makes any single request traceable across every hop. Run History, Live Metrics, and the Failures blade each answer a different shape of investigative question. Dead-letter queues carry their own answer if you know where to look. Alerting closes the loop, turning "someone eventually notices" into "the team knows within minutes." Together, these four parts describe a complete, real Azure integration architecture, which is exactly the shape of answer a panel interview is listening for.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=azure-integration-interview-prep-part4
More from TechStack Blog: Azure: https://www.techstackblog.com/category.html?cat=azure
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Azure Integration Services Interview Prep Part 3: Managed Identity, Key Vault, VNet , Private Endpoints, NSGs, RBAC and Token Validation

Manohari Jayachandran — Sun, 23 Aug 2026 02:42:47 +0000

Part 1 covered the messaging services - Service Bus, Storage Queues, Event Hub, Event Grid. Part 2 covered the orchestration layer that processes what those services move - Logic Apps, Function Apps, Durable Functions. Neither part addressed a question every panel interview eventually asks: how does any of this actually get secured. This part covers exactly that, and deliberately ties every concept back to the specific services already covered, rather than treating security as an abstract, separate topic.

Topic 1: Managed Identity

Managed Identity is a feature that gives an Azure resource, a Function App, a Logic App, a VM, its own automatically-managed identity in Azure AD, letting it authenticate to other Azure services without any developer ever storing, rotating, or managing a password, connection string secret, or certificate.

Think of a hotel employee's own building access badge, versus needing to carry a physical master key that could be lost, copied, or stolen. The badge is tied to that specific employee's identity, can be individually revoked without affecting anyone else, and nobody needs to manage a shared physical key that everyone has to protect.

There are two types of Managed Identity.

System-assigned is tied directly to one specific resource's lifecycle - created when the resource is created, deleted when the resource is deleted, and cannot be shared across multiple resources.
User-assigned is created as its own standalone Azure resource, then assigned to one or more other resources, surviving independently of any single resource's lifecycle - useful when several Function Apps need to share the same identity and permission set.

// Enabling system-assigned identity - Azure Portal:
// Function App -> Identity -> System assigned -> On -> Save

// Using it in C# - DefaultAzureCredential automatically
// discovers and uses the Managed Identity when running
// in Azure, no connection string, no client secret
using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

var client = new SecretClient(
    new Uri("https://your-vault.vault.azure.net/"),
    new DefaultAzureCredential()
);

KeyVaultSecret secret = await client.GetSecretAsync("SqlConnectionString");
// No password anywhere in this code. The Function App's
// Managed Identity IS the credential.

// Granting access - Azure RBAC, not a stored key
// Key Vault -> Access control (IAM) -> Add role assignment
// Role: Key Vault Secrets User
// Assign to: the Function App's Managed Identity

The tradeoff: Managed Identity is genuinely close to strictly better than a stored secret for Azure-to-Azure authentication - the honest limitation is that it only works for authenticating to Azure services, or anything supporting Azure AD auth. A third-party, non-Azure API that only accepts an API key still needs that key stored somewhere, which is exactly where Key Vault comes in next.

How this connects to Parts 1 and 2: a Function App with a Service Bus Trigger, authenticates to Service Bus, using Managed Identity rather than a stored Shared Access Signature connection string - the same pattern applies to that Function App writing to Azure SQL as an exit point, or a Logic App's Azure Function connector calling into a Function App. Every service-to-service hop in the pipelines built across Parts 1 and 2 is a candidate for Managed Identity instead of a stored credential.

Topic 2: Azure Key Vault

Azure Key Vault is a managed service for storing secrets, encryption keys, and certificates securely, covered in depth in an earlier post on this blog. Worth revisiting here specifically in relation to Managed Identity: Key Vault is where the secrets that genuinely can't be eliminated by Managed Identity still need to live.

Think of a bank vault, with your application holding a key card, the Managed Identity, that lets it walk in and request a specific secret, rather than holding the secret itself.

Managed Identity eliminates the need to store Azure SQL connection strings when using Azure AD auth, Service Bus connection strings when using RBAC and identity, and Storage account access keys when using RBAC and identity. What still needs to live in Key Vault includes a partner's external API key, since Salesforce or ServiceNow don't know what an Azure Managed Identity is, a third-party webhook signing secret, and any credential for a system outside Azure entirely.

// Key Vault reference in App Service Configuration -
// no SDK code needed for this pattern
// App Service -> Configuration -> Application settings
// Name: SalesforceApiKey
// Value: @Microsoft.KeyVault(SecretUri=https://your-vault.vault.azure.net/secrets/SalesforceApiKey/)

// Read exactly like any other configuration value
var apiKey = builder.Configuration["SalesforceApiKey"];
// App Service resolves the Key Vault reference at
// startup automatically, using ITS OWN Managed Identity
// to authenticate to Key Vault - the two concepts
// working together directly

The tradeoff: Key Vault has real per-operation costs and API rate limits - it's for genuine secrets, not general configuration values like a page size or a feature flag, which belong in normal App Service Configuration instead.

How this connects to Parts 1 and 2: in the Part 2 Logic Apps problem scenario, polling a partner's REST API, the partner's API key is exactly the kind of secret that belongs in Key Vault - Managed Identity can't eliminate it, since the partner system has no concept of Azure AD identity.

Topic 3: VNet Integration

VNet Integration is a feature that lets Azure PaaS services, Function Apps, Logic Apps Standard, App Service, send their outbound traffic through a Virtual Network, rather than over the public internet, meaning they can reach resources that are locked down to only accept traffic from within a specific private network.

Think of the difference between mailing a letter through the public postal system versus using a company's internal, private courier route between two buildings on the same secured campus. The destination might be completely unreachable to the public postal system at all - only the private internal route can get there.

Without VNet Integration, a Function App reaches Azure SQL over the public internet, and Azure SQL's firewall must allow some public IP range to reach it, even if narrowly scoped. With VNet Integration, the Function App reaches Azure SQL through a private VNet route, paired with a Private Endpoint covered next, and Azure SQL can be configured to reject all public internet traffic entirely, reachable only via the private network path.

// Enabling VNet Integration - Azure Portal:
// Function App -> Networking -> VNet Integration -> Add VNet
// Select an existing VNet and a delegated subnet

// This affects OUTBOUND calls FROM the Function App -
// calls made to Azure SQL, Service Bus, Key Vault, or
// any other service can now route through the VNet
// instead of the public internet, IF those services
// are also configured to accept that private path
// (via Private Endpoints, covered next)

The tradeoff: VNet Integration requires a Premium or higher App Service or Function App plan - it's not available on the Consumption tier, so it's a genuine cost and architecture decision, not just a checkbox.

How this connects to Parts 1 and 2: a Function App processing sensitive order data, from the Part 2 problem scenarios, can use VNet Integration to reach Azure SQL entirely privately, meaning even if the Function App's HTTP endpoint were somehow compromised, an attacker still couldn't reach the database over the public internet at all - the network path itself doesn't exist publicly.

Topic 4: Private Endpoints vs Service Endpoints, the Interview Trap

Both features let traffic from a VNet reach an Azure PaaS service more directly than the general public internet path, but they work in genuinely different ways, and mixing them up is a common, specific interview trap.

A Service Endpoint means traffic still travels to the service's public IP address - it just takes an optimized route while doing so, and the service can be configured to only accept traffic originating from specific VNet subnets. The service still has a public IP and public DNS name, and a firewall rule on the service, such as Azure SQL's firewall, is what actually restricts access.

A Private Endpoint means the Azure service gets an actual private IP address, genuinely inside your VNet's address space. DNS resolution for the service now resolves to that private IP, not a public one, when queried from within the VNet. The service can be configured to reject all public internet traffic entirely - not just restrict it by source, but genuinely have no public path at all.

Think of a Service Endpoint as a VIP lane at a public building's entrance - you still arrive at the same public building, just through a faster, monitored door. A Private Endpoint is like the building itself being moved entirely inside a private, gated campus - there is no public entrance to speak of anymore.

// Private Endpoint setup - Azure Portal:
// Azure SQL Server -> Networking -> Private access
// -> Create a Private Endpoint -> select VNet + subnet

// After this, the SQL server's DNS name resolves to
// a PRIVATE IP address (e.g. 10.0.1.5) when queried
// from inside the VNet, instead of its public IP

// The SQL Server can then have "Deny public network
// access" enabled entirely - genuinely unreachable
// from the public internet, regardless of firewall
// rules, since there is no public path left at all

The tradeoff: Private Endpoints cost more, a per-hour charge per endpoint, and add real DNS configuration complexity, often requiring a Private DNS Zone to resolve correctly. Service Endpoints are simpler and free, but offer a weaker security boundary since the service technically remains publicly reachable in principle.

How this connects to Parts 1 and 2: Service Bus, Azure SQL, and Key Vault, every exit point and dependency across the Part 1 and Part 2 pipelines, can each individually be configured with a Private Endpoint, meaning the entire pipeline from Part 2's complete picture diagram can be rebuilt to never touch the public internet at any internal hop, with only the true entry point, APIM, if external-facing, remaining publicly reachable.

Topic 5: Network Security Groups, NSGs

A Network Security Group is a set of firewall rules applied at either a subnet level or an individual network interface level, controlling inbound and outbound traffic by source and destination IP, port, and protocol.

Think of a building's security desk with a specific list of who's allowed in, through which door, carrying what. Traffic that doesn't match an explicit allow rule, and doesn't match a higher-priority deny rule, simply doesn't get through.

A few core NSG concepts worth knowing precisely: rules have priority numbers from 100 to 4096, where lower numbers are evaluated first, and the first matching rule wins with evaluation stopping there. Rules specify direction, inbound or outbound, source, destination, port, protocol, and allow or deny. Default rules exist automatically and cannot be deleted, only overridden by a higher-priority custom rule - these include allowing VNet-to-VNet traffic, allowing Azure Load Balancer traffic, and denying all other inbound traffic by default. NSGs can be applied at two levels simultaneously, subnet level affecting everything in that subnet, and network interface level affecting one specific resource - both are evaluated if both exist, and traffic must pass both to actually get through.

// Example NSG rule (conceptual, via Azure Portal or CLI)
Priority: 100
Name: Allow-HTTPS-Inbound
Direction: Inbound
Source: Internet
Destination: 10.0.1.0/24 (a specific subnet)
Port: 443
Protocol: TCP
Action: Allow

Priority: 200
Name: Deny-All-Other-Inbound
Direction: Inbound
Source: Any
Destination: Any
Port: Any
Action: Deny
// (this duplicates default behavior, but shown
// explicitly here for clarity)

The tradeoff: NSGs are coarse-grained, IP, port, and protocol, compared to something like APIM's subscription key or OAuth validation, covered in the APIM posts on this blog. NSGs control whether traffic can reach a network destination at all, not who is making an authenticated request once it arrives. Real architectures layer both.

How this connects to Parts 1 and 2: if Function Apps and Logic Apps in the Part 2 pipeline are deployed with VNet Integration into a specific subnet, an NSG on that subnet is what actually restricts which other subnets or IP ranges those services can communicate with - the network-level enforcement underneath the VNet Integration and Private Endpoint configuration already discussed.

Topic 6: Encryption in Transit vs At Rest

These are two genuinely different protections, both necessary, neither substituting for the other. Encryption in transit protects data while it's actively moving between two points over a network. Encryption at rest protects data while it's sitting stored somewhere, on disk, in a database.

Think of a sealed, tamper-evident courier bag that protects a letter while it travels, in transit, but once it arrives and gets filed away, the bag itself does nothing to protect the letter sitting in an unlocked filing cabinet, at rest. Both protections are needed, and they protect against different threats at different moments.

Encryption in transit covers HTTPS and TLS for API calls, which APIM, Function Apps, and Logic Apps all enforce by default for their endpoints, and Service Bus and Azure SQL connections, encrypted via TLS by default. This is mostly already on by default across Azure services - the interview-relevant knowledge is knowing it's the default, and knowing how to verify it hasn't been accidentally disabled somewhere.

Encryption at rest covers Azure Storage, Azure SQL, and Service Bus messages at rest, all encrypted by default using Microsoft-managed keys. Customer-managed keys, via Key Vault, are available for organizations needing to control their own encryption keys specifically - a real, sometimes compliance-driven choice, not the default.

The tradeoff: Microsoft-managed keys, the default, require zero setup and are genuinely secure for most scenarios. Customer-managed keys add real operational overhead, since you're now responsible for key rotation and availability, in exchange for direct control - typically only worth it when a specific compliance requirement mandates it.

How this connects to Parts 1 and 2: every message sitting in a Service Bus queue, from Part 1, every order record written to Azure SQL by a Function App, from Part 2, is encrypted at rest by default without any explicit configuration - worth knowing this is already true, rather than assuming it needs to be manually enabled.

Topic 7: Azure RBAC, Role-Based Access Control

Azure RBAC is the actual mechanism that decides what a given identity, a Managed Identity, a user, a group, is allowed to do once it has authenticated. Every grant-access step mentioned so far, a Function App reading a Key Vault secret, a Managed Identity publishing to Service Bus, has been RBAC quietly doing the actual authorization work underneath.

Think of a hospital ID badge system, distinct from the building access badge used earlier for Managed Identity. The badge, the identity, gets you through the front door, but RBAC is the separate system deciding whether that specific badge lets you into the pharmacy, the operating room, or only the waiting area. Having a valid badge and being authorized for a specific room are two different checks.

A few core RBAC concepts matter here. A Role Definition is a named set of permissions - "Key Vault Secrets User" can read secrets but not manage access policies, while "Key Vault Administrator" can do both. A Role Assignment binds a specific identity to a specific role at a specific scope - "this Managed Identity has the Storage Blob Data Reader role on this storage account." Scope determines where a role assignment applies, running from Management Group down through Subscription, Resource Group, to an individual Resource, and a role granted at a higher scope is inherited by everything underneath it.

# Granting RBAC access via Azure CLI - conceptually
# what happens when you click "Add role assignment"
# in the portal

az role assignment create \
  --assignee <function-app-managed-identity-object-id> \
  --role "Service Bus Data Sender" \
  --scope /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.ServiceBus/namespaces/{namespace}

# This Function App's Managed Identity can now SEND
# messages to this specific Service Bus namespace -
# nothing more, nothing less, and no connection
# string was involved anywhere in granting this access

The principle of least privilege, made concrete: a Function App that only ever needs to send messages to Service Bus should get the "Service Bus Data Sender" role specifically, not the broader "Service Bus Data Owner" role - even though both would technically make the code work, the narrower role means a compromised Function App identity still can't delete queues or read messages meant for other consumers.

The tradeoff: RBAC role assignments add real setup overhead compared to a shared connection string that just works everywhere - the honest payoff is that a leaked or compromised identity has precisely bounded damage potential, rather than full access to whatever the shared secret happened to unlock.

How this connects to everything already covered: RBAC is the actual authorization layer underneath every Managed Identity example in this post - granting the Function App access to Key Vault, or the Managed Identity being able to publish to Service Bus, are both RBAC role assignments happening behind the portal UI. Managed Identity answers who is this, RBAC answers what are they allowed to do, the same Authentication vs Authorization distinction covered in depth in an earlier post on this blog, now applied specifically to Azure resource-to-resource access.

Topic 8: Token Validation, Revisited in This Context

The JWT validation happening at the APIM gateway, covered in real depth in the APIM Part 1 post on this blog, deserves an explicit callback here, since Topic 7's RBAC and this token validation answer genuinely parallel questions at two different layers of the same pipeline.

There are two layers here, answering two different questions, running at two different points in the same request. APIM's validate-jwt policy, the external entry point, validates a token presented by an external caller - is this token signed correctly, not expired, issued for the right audience - covered in depth in the APIM Part 1 post. Azure RBAC, internal and resource-to-resource, operates once inside the pipeline, deciding what an already-authenticated Azure resource, via Managed Identity, is allowed to do to another Azure resource. Both are genuinely "authorization" in the AuthN and AuthZ sense covered in an earlier dedicated post - one happens at the public edge, checking an external caller's claims; the other happens entirely within Azure's own control plane, checking a resource's own identity against RBAC role assignments.

Where this distinction actually gets tested in an interview: being asked how an API is secured and only mentioning APIM's token validation misses half the real answer - a fully secured pipeline validates the external caller at the edge, APIM's JWT validation, and enforces least-privilege access for every internal hop afterward, RBAC on each Managed Identity. Mentioning only one of the two is the incomplete answer a panel interviewer is specifically listening for.

How this connects to Parts 1 and 2: in the Part 2 end-to-end example, the external partner's token gets validated once, at APIM, at the very start of the pipeline - but every single hop afterward, Logic App to Function App, Function App to Key Vault, Function App to SQL, Function App to Service Bus, is a separate authorization decision, made by RBAC, not by re-checking that same original token. This is why both topics genuinely need to be understood together, not treated as the same concept covered twice.

Putting the Whole Security Picture Together

Revisiting the Part 2 end-to-end pipeline, now with security layered on top of every hop, tells the complete story. An external partner calls APIM as the entry point, with TLS enforced for encryption in transit, and a subscription key plus OAuth validated at the gateway. APIM forwards to a Logic App, ideally over a private path if the Logic App is VNet-integrated. The Logic App calls a Function App for complex transformation, authenticating using Managed Identity rather than a stored key. The Function App needs a partner API key for one step, retrieved from Key Vault, referenced via the Function App's own Managed Identity. The Function App writes the result to Azure SQL, reached via a Private Endpoint, with SQL configured to reject all public internet traffic entirely, and an NSG on the Function App's subnet permitting this specific outbound path. The Function App publishes to a Service Bus topic for the next stage, authenticated via Managed Identity and Azure RBAC, with no connection string secret anywhere. Every step logs to Application Insights regardless - security doesn't remove the need for observability from Part 2, it adds to it.

This is the shape of answer, describing security as a layer across an already-understood pipeline rather than a separate topic, that demonstrates real architectural thinking in a panel interview.

Key Lessons

Managed Identity eliminates stored secrets for Azure-to-Azure authentication entirely - it doesn't help for non-Azure, third-party systems, which is exactly where Key Vault still matters.

Key Vault and Managed Identity work together - the Managed Identity is the credential that authenticates to Key Vault, which then holds whatever secrets genuinely can't be eliminated.

VNet Integration affects outbound traffic from a PaaS service; Private Endpoints affect how that service is reached - the two work together to keep an entire pipeline off the public internet.

Service Endpoints and Private Endpoints are not the same thing - a Service Endpoint optimizes a still-public path, a Private Endpoint gives the service an actual private IP with no public path required at all.

NSGs control network-level reachability, whether traffic can get there at all, while APIM's subscription keys and OAuth validation control authenticated access, who is allowed once traffic arrives - real architectures need both layers, not one instead of the other.

Encryption in transit and at rest are both already on by default for most Azure services - the interview-relevant knowledge is knowing that default exists, not assuming it needs manual setup.

RBAC is the authorization layer underneath every Managed Identity grant covered in this post - Managed Identity answers who is this, RBAC answers what are they allowed to do, and least-privilege role selection genuinely bounds the damage a compromised identity can do.

Token validation at APIM, the external edge, and RBAC, internal and resource-to-resource, are both authorization but operate at genuinely different layers of the same pipeline - a complete answer to how something is secured needs both, not just one.

What's Next

Future parts of this series will cover additional Azure integration topics based on continued interview prep needs - debugging and monitoring the secured pipeline built across this and earlier parts, or deeper API Management security patterns specifically.

Summary

Security and networking aren't a separate concern from the messaging and orchestration services covered in Parts 1 and 2 - they're a layer that sits directly on top of that same architecture. Managed Identity removes stored secrets between Azure services. Key Vault holds what genuinely can't be eliminated. VNet Integration and Private Endpoints keep traffic off the public internet entirely. NSGs enforce network-level reachability underneath all of it. Encryption in transit and at rest protect data whether it's moving or sitting still. Describing how these layer onto a specific, already-understood pipeline, rather than reciting them as abstract concepts, is what turns a security question into a demonstration of real architectural thinking in a panel interview.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=azure-integration-interview-prep-part3
More from TechStack Blog: Azure: https://www.techstackblog.com/category.html?cat=azure
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Azure Integration Services Interview Prep Part 2: Logic Apps, Function Apps, Durable Functions, and the Complete Orchestration Picture

Manohari Jayachandran — Fri, 21 Aug 2026 22:35:49 +0000

Part 1 covered Service Bus, Storage Queues, Event Hub, and Event Grid - the services that move data around a system. None of them actually do anything with that data once it arrives. This part covers the two services that do - Logic Apps and Function Apps - and just as importantly, connects them into the complete picture: what typically triggers this orchestration layer, and where the result actually goes afterward. A panel interview rarely asks about one service in isolation; it asks you to describe a whole pipeline, start to finish.

Service 1: Azure Logic Apps

Azure Logic Apps is a low-code, visual workflow orchestration service. Triggers and actions are connected in a designer, backed by hundreds of prebuilt connectors, Salesforce, ServiceNow, SQL, Service Bus, and many more, with retry policies and error handling configurable without writing code.

Think of a flowchart that actually runs itself. Instead of drawing a diagram of "if this, then that" and handing it to a developer to implement, the flowchart is the running system - each box is a real, executing step, and the connectors are pre-wired plugs into other systems rather than something you build a client for yourself.

Logic Apps fit connector-heavy orchestration where the actual logic is relatively straightforward, sequence, conditions, simple transformation, and being readable by a non-developer stakeholder, or having built-in retry and error handling with zero code, is a genuine advantage.

Logic Apps' strengths include hundreds of prebuilt connectors for SaaS systems, databases, and Azure services with no custom auth or client code needed, a visual design reviewable by non-developers, built-in retry policies per action configurable without code, and fast build time for straightforward orchestration. The weaknesses are real too - complex branching logic becomes hard to read as a diagram, genuine unit testing is awkward compared to real code, and complex data transformation is technically possible in the expression language but painful compared to the equivalent C#.

Logic Apps: A Real Example

Consider a scenario where a new case is created in Salesforce. If the case priority is High, the workflow needs to create a matching incident in ServiceNow and notify the on-call engineer via Teams.

Built as a Logic App, this becomes four steps: a trigger firing when a new record is created via the Salesforce connector, a Condition action checking whether Priority equals High, a Create Record action against the ServiceNow connector if true, and a Post Message action through the Microsoft Teams connector. All four steps are entirely visual, each with its own configurable retry policy, with no custom HTTP client code written for either Salesforce or ServiceNow - the connectors handle authentication and API specifics automatically.

Logic Apps: Problem Scenario and Solving Strategy

The problem: a partner integration needs to pull new orders from an external partner's REST API every 15 minutes, check each order against three different validation rules, and if valid, insert it into Azure SQL - if invalid, send an email to the operations team with the specific reason. The integration needs to be reviewable by a non-technical operations lead, and built quickly, since this is a short-term partner relationship.

The strategy, step by step:

First, recognize the shape of this problem - scheduled polling, simple sequential validation, a database write, a conditional notification - this is connector-heavy orchestration with straightforward logic, not complex custom computation.
Second, use a Logic App with a Recurrence trigger set to 15 minutes. Third, add an HTTP action to call the partner's REST API and retrieve new orders.
Fourth, use a For Each loop over the returned orders, with three Condition actions checking each validation rule in sequence.
Fifth, branch on the combined result - valid orders go through a SQL connector action inserting a row into the Orders table, invalid orders trigger an Outlook or Office 365 connector action sending an email with the specific failed rule included in the message body.
Sixth, configure a retry policy on the HTTP action specifically, exponential backoff with 3 retries, in case the partner's API is briefly unavailable.
Finally, the non-technical reviewability requirement is satisfied inherently by the visual designer, requiring no additional work for that specific requirement.

Service 2: Azure Function Apps

Azure Function Apps provide serverless compute that runs a specific piece of C#, or other language, code in response to a trigger, billed per execution rather than for a server sitting idle. This was covered in more depth in an earlier post on this blog.

Think of a specialist called in for one specific job, paid only for the time actually worked, rather than a full-time employee sitting at a desk waiting for something to do. The specialist shows up when triggered, does the specific task, and leaves, with no idle overhead.

Function Apps fit genuinely complex logic, custom validation with many conditions, algorithms too sophisticated for a visual designer's expression language, and anywhere real unit testing of the logic matters.

Function Apps' strengths include real C# with full language power and genuine testability, six trigger types covering HTTP, Timer, Service Bus, Blob, Queue, and Event Grid, bindings that eliminate boilerplate connection code, and Durable Functions handling workflows beyond the 10-minute execution limit. The weaknesses include no built-in visual retry configuration, requiring retry logic to be written explicitly in code, commonly with Polly, less transparency to a non-developer reviewer, and more upfront setup than dragging in a connector.

Function Apps: A Real Example

[Function("ValidateAndTransformOrder")]
public async Task Run(
    [ServiceBusTrigger("incoming-orders")] string message,
    ILogger log)
{
    var order = JsonSerializer.Deserialize<RawOrder>(message);

    // Complex validation logic - genuinely easier to
    // read, test, and maintain as real code than as a
    // Logic App expression chain
    if (order.Amount <= 0 || order.Amount > 100000)
        throw new ValidationException("Amount out of range");

    if (!IsValidSku(order.ProductCode))
        throw new ValidationException("Unknown product code");

    var transformed = new Order
    {
        Id = order.ExternalId,
        Amount = order.Amount,
        NormalizedSku = NormalizeSkuFormat(order.ProductCode),
        ProcessedAt = DateTime.UtcNow
    };

    await SaveToDbAsync(transformed);
    log.LogInformation("Order {Id} processed successfully", transformed.Id);
}

Function Apps: Problem Scenario and Solving Strategy

The problem: incoming order data from Service Bus needs to go through a genuinely complex transformation - reconciling product codes against three different SKU formats used historically, applying a multi-step pricing adjustment algorithm with several conditional tiers, and validating against business rules that involve checking multiple related fields together. The team needs to unit test this logic directly, since a bug here has real financial impact.

The strategy, step by step:

First, recognize this is not connector-heavy orchestration - it's genuinely complex, multi-step business logic that needs to be read, tested, and maintained as real code, which immediately points to Function Apps over Logic Apps.
Second, use a Function App with a Service Bus Trigger, consuming messages from the incoming-orders queue directly, since Part 1 already covered why Service Bus fits this scenario upstream, given ordering and reliability matter for order data.
Third, structure the transformation logic as a separate, independently testable class, such as OrderTransformer, rather than inline in the function itself, since this is what actually enables genuine unit testing.
Fourth, write xUnit tests directly against OrderTransformer, covering each SKU format, each pricing tier boundary, and each validation rule combination - something not realistically possible against a Logic App's visual workflow.
Fifth, use Polly for explicit retry logic around any external call within the transformation, such as an external SKU lookup service, since Function Apps don't get this for free the way Logic Apps' connectors do.
Finally, on successful transformation, complete the Service Bus message; on failure, let it retry per Service Bus's own retry policy, eventually dead-lettering after max attempts for manual investigation.

Durable Functions: State Management Beyond a Single Execution

A Durable Function is a Function App extension that lets you write long-running, stateful workflows in code - workflows that can span minutes, hours, or even months, well beyond a regular function's execution time limit. Durable Functions automatically checkpoints progress to Azure Storage, meaning the workflow's state survives restarts, scaling events, or the host process recycling entirely.

Think of a video game's save file. A regular Function App is like a game with no save feature - if you close it, all progress is lost, you start over from the beginning. Durable Functions automatically saves your progress at each checkpoint, so if the process restarts, equivalent to your console crashing, the workflow resumes exactly where it left off, rather than starting over.

There are three function types in Durable Functions.

The Orchestrator Function coordinates the overall workflow, calling Activity Functions in sequence or in parallel, handling retries and timeouts, with its own execution state automatically checkpointed.
The Activity Function does the actual work - calling an external API, querying a database, running a calculation - and each one is a normal, stateless function under the hood.
The Client Function starts a new orchestration instance, typically an HTTP trigger that kicks off the workflow and returns an instance ID for checking status later.

// Client function - starts the workflow
[Function("StartOrderWorkflow")]
public async Task<HttpResponseData> StartWorkflow(
    [HttpTrigger] HttpRequestData req,
    [DurableClient] DurableTaskClient client)
{
    var order = await req.ReadFromJsonAsync<Order>();

    string instanceId = await client.ScheduleNewOrchestrationInstanceAsync(
        "ProcessOrderOrchestrator", order);

    return client.CreateCheckStatusResponse(req, instanceId);
}

// Orchestrator function - coordinates the workflow
[Function("ProcessOrderOrchestrator")]
public static async Task RunOrchestrator(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var order = context.GetInput<Order>();

    // Sequential activity calls - each one checkpointed
    var validated = await context.CallActivityAsync<bool>(
        "ValidateOrder", order);

    if (!validated)
        throw new Exception("Order validation failed");

    var paymentResult = await context.CallActivityAsync<string>(
        "ChargePayment", order);

    // A durable TIMER - the orchestrator can genuinely
    // "sleep" for hours or days without consuming any
    // compute during the wait, unlike Task.Delay
    await context.CreateTimer(
        context.CurrentUtcDateTime.AddHours(24), CancellationToken.None);

    var confirmed = await context.CallActivityAsync<bool>(
        "SendConfirmationAndAwaitAck", order);

    // Fan-out/fan-in - run several activities in
    // PARALLEL, then wait for all to complete
    var tasks = new List<Task>
    {
        context.CallActivityAsync("UpdateInventory", order),
        context.CallActivityAsync("NotifyWarehouse", order),
        context.CallActivityAsync("UpdateAnalytics", order)
    };
    await Task.WhenAll(tasks);
}

// Activity function - the actual work, stateless
[Function("ValidateOrder")]
public static bool ValidateOrder([ActivityTrigger] Order order)
{
    return order.Amount > 0 && !string.IsNullOrEmpty(order.ProductCode);
}

The checkpointing works like this: every time an orchestrator awaits an activity or a timer, its current execution state is saved to Azure Storage automatically. If the process crashes or restarts mid-workflow, the orchestrator function actually replays from the beginning when it resumes - but any activity call that already completed simply returns its already-saved result instantly instead of re-executing, so the orchestrator effectively fast-forwards back to exactly where it left off. This replay behavior is why activity functions, the actual work, must be deterministic-safe to call multiple times, or genuinely idempotent, and why non-deterministic operations like DateTime.Now or Guid.NewGuid() should be called through provided context methods rather than directly, inside an orchestrator specifically.

Durable Functions: Problem Scenario and Solving Strategy

The problem: an order approval workflow needs to send a request to a manager for approval, then wait for up to 5 business days for a response. If approved, proceed with fulfillment. If no response within 5 days, escalate to a senior manager automatically. A regular Function App's 10-minute execution limit makes this directly impossible to build as a single running function, and the system needs to survive deployments, restarts, and scaling events without losing track of orders waiting on approval.

The strategy, step by step:

First, recognize this is fundamentally a long-running, stateful workflow problem - the multi-day wait alone rules out a regular Function App entirely, and rules out Logic Apps too if genuinely complex branching logic around the escalation needs real code.
Second, use Durable Functions specifically for its durable timer capability, since the orchestrator can wait for days without consuming compute the whole time, and survives restarts because its state is checkpointed to storage.
Third, build a Client Function, an HTTP trigger, that starts the orchestration when an order needs approval, returning an instance ID.
Fourth, build the Orchestrator Function to call an Activity Function that sends the approval request via email or Teams notification to the manager, then use context.WaitForExternalEvent for an "ApprovalReceived" event combined with context.CreateTimer for the 5-day deadline, racing both with Task.WhenAny.
Fifth, if the ApprovalReceived external event arrives first, proceed to a ProcessApproval Activity Function.
Sixth, if the timer fires first, 5 days passed with no response, call an EscalateToSeniorManager Activity Function instead. Seventh, the manager's actual approval action, such as clicking a link in an email, calls a separate HTTP-triggered function that raises the external event back into the waiting orchestration instance using its instance ID - this is what wakes up the specific waiting workflow.
Finally, because state is checkpointed automatically, this entire multi-day wait survives app restarts, deployments, or scaling events with zero custom state-persistence code written by hand.

Logic Apps, Function Apps, or Durable Functions

Choose Logic Apps when the work is connector-heavy orchestration, the branching logic is straightforward, and visual reviewability matters. Choose regular Function Apps when the logic is complex, genuine unit testing is needed, and execution completes well within the 10-minute limit. Choose Durable Functions when the workflow needs to span minutes to months, requires genuine state that survives restarts, needs fan-out and fan-in parallelism with a final aggregation step, or needs to wait for an external event, like a human approval, without holding compute the whole time. Choose Logic Apps and Function Apps together when a Logic App can orchestrate the overall connector-heavy flow, calling out to a Function App as one action for the specific step complex enough to warrant real code - a common, often correct real-world pattern, covered in more depth in an earlier post on this blog comparing the two services directly.

The Complete Picture: Entry Points

A panel interview rarely stops at "which orchestration service" - it typically wants the whole pipeline. Here's what actually triggers this layer in real architectures.

Azure API Management as an entry point means an external caller hits an API exposed through APIM, covered in depth in earlier posts on this blog. APIM validates the caller through a subscription key or OAuth, applies rate limiting, then forwards to a Logic App or Function App as the actual backend. This fits external, internet-facing integrations needing authentication and governance at the edge.

Service Bus as an entry point means a message arrives on a queue or topic, and a Function App with a Service Bus Trigger, or a Logic App's Service Bus connector trigger, picks it up automatically. This fits internal, decoupled, asynchronous processing, where the sender doesn't need to wait for the orchestration to complete.

Event Grid as an entry point means a discrete event fires - a blob uploaded, an Azure resource changed, a custom application event - and Event Grid pushes it directly to a subscribed Function App or Logic App. This fits reacting to something happening, not processing a queued backlog of work.

Timer or Recurrence as an entry point means a scheduled trigger fires on a defined interval, independent of any external event. This fits polling an external system, running a nightly batch job, or periodic cleanup and reconciliation.

Blob Storage as an entry point means a file lands in a specific container, triggering processing directly. This fits file-based integrations, where a partner drops a CSV or an export needs processing on arrival.

The Complete Picture: Exit Points

Azure SQL or Cosmos DB as an exit point means the orchestration's result is persisted, and the actual business record now exists in a queryable store. The choice between SQL and Cosmos DB follows the reasoning covered in an earlier post on this blog - relational, consistent shape versus flexible, fast-changing document data.

Service Bus as an exit point means the orchestration hands off to the next stage rather than the pipeline ending here, publishing a message for a downstream process to pick up - common in multi-stage pipelines where each stage does one focused job.

An external API as an exit point means the orchestration calls out to a partner system - ServiceNow, Salesforce, a third-party vendor API - completing the actual business integration the whole pipeline exists to support.

Application Insights as an exit point applies always, regardless of the above. Every step logs its outcome, success, failure, duration, covered in depth in an earlier post on this blog about KQL and observability. This isn't optional in a well-built pipeline; it's how anyone, including you at 2am, actually knows what happened.

Putting the Whole Picture Together

Here's a realistic end-to-end example, tying Part 1 and Part 2 together completely. An external partner calls an API exposed through APIM, with a subscription key and OAuth validated at the gateway. APIM forwards the validated request to a Logic App. The Logic App orchestrates the flow: it calls a validation step, then hands off the complex transformation to a Function App as one action within the same workflow. The Function App applies business logic, then publishes the transformed result to a Service Bus topic from Part 1, decoupling this pipeline from whatever consumes the result next. A separate Function App, triggered by a Service Bus subscription on that topic, picks up the message, writes the final record to Azure SQL, and calls an external API to notify the partner's system the order was received. Every step along this entire chain logs to Application Insights, so the complete journey of one specific order can be traced end to end using operation_Id, exactly as covered in the KQL monitoring post on this blog.

This is the shape of answer that actually lands well in a panel interview - not naming one service in isolation, but describing how several connect into a coherent, traceable pipeline.

Key Lessons

Logic Apps and Function Apps solve overlapping but genuinely different problems - connector-heavy visual orchestration versus complex, testable custom code.

Durable Functions solve a third, distinct problem - genuine state that survives restarts, workflows spanning minutes to months, and waiting for external events without holding compute the whole time - none of which regular Function Apps or Logic Apps handle natively.

Many real production architectures use both together - a Logic App orchestrating the overall flow, calling into a Function App for the specific step complex enough to warrant real code.

A complete integration pipeline has an entry point, APIM, Service Bus, Event Grid, Timer, or Blob Storage, an orchestration layer, Logic App and/or Function App, and an exit point, SQL/Cosmos DB, Service Bus, or an external API, with Application Insights watching every step regardless.

Describing the full pipeline, not just one isolated service, is what a panel interview is actually listening for when it asks an open-ended architecture question.

The entry point shapes what's realistic downstream - a Service Bus entry implies async, decoupled processing; an APIM entry implies a synchronous external caller waiting for a response.

What's Next

Future parts of this series will cover additional Azure integration topics - deeper API Management patterns, Azure AD and Entra ID authentication flows applied specifically to service-to-service integration scenarios, and more complete end-to-end architecture walkthroughs.

Summary

Logic Apps and Function Apps are the orchestration layer sitting between Part 1's messaging services and wherever the result of an integration actually needs to go. Logic Apps excel at connector-heavy, visually reviewable workflows; Function Apps excel at complex, genuinely testable business logic, and real architectures frequently combine both. The complete picture matters as much as any individual service choice: knowing what typically triggers this layer, and where the result goes afterward, is what turns a list of memorized services into a coherent architecture a panel interviewer can follow from entry to exit.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=azure-integration-interview-prep-part2
More from TechStack Blog: Azure: https://www.techstackblog.com/category.html?cat=azure
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Azure Integration Services Interview Prep Part 1: Service Bus, Storage Queues, Event Hub, and Event Grid

Manohari Jayachandran — Fri, 21 Aug 2026 03:19:35 +0000

Azure integration services get confused with each other constantly, in interviews and in real architecture decisions - four different services can all technically "move data between two systems," but they solve different problems, at different scales, with different guarantees. This is Part 1 of a series built for panel-level interview prep, covering the services that come up most often, starting with the four that most directly overlap in what they sound like they do: Service Bus, Storage Queues, Event Hub, and Event Grid.

Service 1: Azure Service Bus

Azure Service Bus is an enterprise message broker built for reliable, ordered delivery of discrete business messages between applications, with genuine guarantees - transactions, sessions, dead-letter queues, and topic and subscription fan-out.

Think of a certified mail service. Each message is a specific, individually important letter - tracked, guaranteed to arrive, with a documented trail if delivery fails, and optionally requiring a signature, a transaction, confirming it was genuinely received and processed correctly.

Service Bus fits when the correctness of an individual message actually matters - an order confirmation, a payment event, an integration handoff between two business systems - not just "get this data over there eventually."

Core capabilities that set it apart: queues for one sender and one logical consumer group, topics for one message reaching many independent subscribers, sessions guaranteeing ordered processing for related messages, dead-letter handling so failed messages are quarantined rather than silently lost, and transactions ensuring multiple operations succeed or fail together.

// Sending a message
var client = new ServiceBusClient(connectionString);
var sender = client.CreateSender("order-queue");

var message = new ServiceBusMessage(
    JsonSerializer.Serialize(new { OrderId = "ORD-001", Amount = 49.99 })
);
message.MessageId = Guid.NewGuid().ToString();
message.ApplicationProperties["Priority"] = "High";

await sender.SendMessageAsync(message);

// Receiving and processing
var processor = client.CreateProcessor("order-queue");

processor.ProcessMessageAsync += async args =>
{
    var order = JsonSerializer.Deserialize<Order>(args.Message.Body.ToString());
    await ProcessOrderAsync(order);
    await args.CompleteMessageAsync(args.Message);
    // Not completing (or an exception) = automatic retry,
    // eventually dead-lettered after max retries
};

await processor.StartProcessingAsync();

Service Bus: Problem Scenario and Solving Strategy

The problem: an order-processing system needs every order to be processed exactly once, in the order it was placed per customer, and if processing fails, the order must never be silently lost - someone needs to be able to see and investigate exactly which orders failed and why.

The strategy, step by step:

First, recognize this needs real delivery guarantees, not just "a queue" - the ordering-per-customer requirement alone rules out Storage Queue and Event Hub immediately.
Second, use Azure Service Bus with sessions enabled, setting SessionId to CustomerId on every message, since Service Bus guarantees all messages with the same SessionId are processed in order by the same consumer.
Third, configure a dead-letter queue with a reasonable max delivery count, around 5 attempts, so failed messages move to the dead-letter queue automatically after exhausting retries rather than disappearing.
Fourth, build a monitoring dashboard or alert on dead-letter queue message count, since anything landing there needs human investigation.
Finally, for true exactly-once semantics, combine this with an idempotency check on the consumer side, checking that an OrderId hasn't already been processed - Service Bus guarantees at-least-once delivery by default, so a rare duplicate delivery is still technically possible, and the consumer itself should be idempotent as a final safety net.

Service 2: Azure Storage Queues

Azure Storage Queues provide a simple, extremely cheap, high-volume queue built on top of Azure Storage - basic FIFO-ish delivery, no transactions, no sessions, no dead-letter queue as a first-class feature, though a manual pattern can approximate one.

Think of a basic ticket dispenser at a deli counter. It hands out numbers in order and gets the job done reliably for simple cases - but there's no certified tracking, no guaranteed same-person-handles-related-tickets behavior, and no built-in "this ticket was never claimed, someone should look into it" process.

Storage Queues fit genuinely simple task queues at high volume, where the cost difference versus Service Bus actually matters, and the missing enterprise features, sessions, transactions, native dead-lettering, aren't needed.

Core characteristics: meaningfully cheaper than Service Bus at scale, a minimal API surface that's easy to reason about, a max message size of 64 KB versus Service Bus's much larger limit, and no native dead-letter queue, sessions, or topics.

// Sending a message
var queueClient = new QueueClient(connectionString, "task-queue");
await queueClient.CreateIfNotExistsAsync();

await queueClient.SendMessageAsync(
    JsonSerializer.Serialize(new { TaskId = 123, Action = "Resize" })
);

// Receiving and processing
QueueMessage[] messages = await queueClient.ReceiveMessagesAsync(maxMessages: 10);

foreach (var message in messages)
{
    var task = JsonSerializer.Deserialize<TaskItem>(message.MessageText);
    await ProcessTaskAsync(task);

    // Must explicitly delete - otherwise the message
    // reappears after its visibility timeout expires
    await queueClient.DeleteMessageAsync(message.MessageId, message.PopReceipt);
}

Storage Queue: Problem Scenario and Solving Strategy

The problem: a system needs to process millions of simple image-resize tasks per day. Each task is independent - order between tasks doesn't matter, tasks don't need to relate to each other, and losing an occasional task isn't business-critical as long as the vast majority succeed. Cost efficiency at this volume matters significantly.

The strategy, step by step:

First, recognize the requirements don't need Service Bus's heavier feature set - no ordering, no sessions, no strict zero-loss guarantee, high volume, cost-sensitive.
Second, use Azure Storage Queue specifically because of this mismatch, since paying for Service Bus's guarantees here would be genuine overkill.
Third, use a Function App with a Queue Trigger to process messages as they arrive, auto-scaling with volume.
Fourth, implement a simple manual poison-message pattern - Storage Queue tracks a DequeueCount automatically, so check this count and move a message to a separate failed-tasks queue manually if it exceeds a threshold, approximating the dead-letter behavior Service Bus would give natively.
Finally, monitor queue length as the primary health signal, since a queue that keeps growing faster than it's being drained indicates the processing side needs to scale up or investigate a bottleneck.

Service 3: Azure Event Hub

Azure Event Hub is a big-data streaming platform built to ingest and process massive volumes of events per second - millions of small events, not individual important business messages. It's built around the concept of a continuous, ordered log that multiple independent consumers can read from, at their own pace, without removing data from the stream.

Think of a continuously running river of water, versus Service Bus's individually addressed certified letters. You don't pick up one specific event and remove it - you dip a bucket in at whatever point in the river you're currently reading from, and the river keeps flowing regardless of who's watching.

Event Hub fits telemetry ingestion, application logs at scale, IoT sensor data, and clickstream analytics - anywhere the meaningful unit is the aggregate pattern across millions of events, not any single event's individual fate.

Core characteristics: the stream is split into partitions for parallel throughput, consumer groups allow multiple independent readers each tracking their own position in the stream, retention keeps events for a configured window of hours to days rather than removing them on read, and the whole service is built for massive throughput of millions of events per second.

// Sending events
var producerClient = new EventHubProducerClient(connectionString, "telemetry-hub");

using EventDataBatch eventBatch = await producerClient.CreateBatchAsync();
eventBatch.TryAdd(new EventData(
    JsonSerializer.Serialize(new { DeviceId = "sensor-42", Temp = 21.5 })
));
await producerClient.SendAsync(eventBatch);

// Reading events - note the CONSUMER GROUP concept,
// each independent reader tracks its own position
var consumerClient = new EventHubConsumerClient(
    EventHubConsumerClient.DefaultConsumerGroupName,
    connectionString,
    "telemetry-hub"
);

await foreach (PartitionEvent partitionEvent in consumerClient.ReadEventsAsync())
{
    var data = Encoding.UTF8.GetString(partitionEvent.Data.EventBody.ToArray());
    Console.WriteLine(data);
}

Event Hub: Problem Scenario and Solving Strategy

The problem: a fleet of 50,000 IoT sensors each sends a temperature reading every 5 seconds - roughly 10,000 events per second sustained. This data needs to be ingested reliably at that volume, and multiple independent systems need to read the same stream: one for real-time alerting, one for long-term storage and analytics, without either consumer affecting the other or removing data the other still needs to read.

The strategy, step by step:

First, recognize this is fundamentally a streaming and volume problem, not a discrete-message problem - 10,000 events per second immediately rules out Service Bus and Storage Queue, since neither is built for this throughput.
Second, use Azure Event Hub specifically for its partition-based architecture, built to sustain this event rate.
Third, configure multiple partitions so ingestion can happen in parallel, with partition count chosen based on expected throughput and downstream consumer count.
Fourth, create two separate consumer groups - one for the real-time alerting system, one for the analytics and storage pipeline - since each consumer group tracks its own independent read position, neither interferes with the other's pace or progress.
Fifth, use Event Hubs Capture, a built-in feature, to automatically archive raw events to Blob Storage for long-term retention, decoupling the archival need from requiring a custom consumer to handle it manually.
Finally, size the retention window based on how far behind a consumer might realistically fall before catching up, since this determines how much buffer exists before older events age out of the stream.

Service 4: Azure Event Grid

Azure Event Grid is a reactive event routing service - "when X happens, notify these subscribers." It doesn't hold messages waiting to be pulled, and it isn't built for high-volume streaming - it's a lightweight, push-based notification layer that reacts to discrete events and routes them to interested subscribers.

Think of a building's fire alarm system, versus Service Bus's certified mail or Event Hub's continuous river. Nothing sits in a queue waiting - the moment smoke is detected, every subscribed system, sprinklers, the fire department, building announcements, is notified simultaneously and immediately. The alarm doesn't store history of past fires; it reacts to the event as it happens.

Event Grid fits reacting to a specific occurrence - a blob was uploaded, a resource was created or deleted, a custom application event happened - and triggering downstream systems, often Function Apps or Logic Apps, in near real time.

Core characteristics: push-based delivery means subscribers are notified immediately rather than polled, many Azure services publish built-in resource events to Event Grid automatically, custom topics let your own application publish its own custom events too, and it is not designed for high-volume streaming or as a durable queue.

// Publishing a custom event
var client = new EventGridPublisherClient(
    new Uri(topicEndpoint),
    new AzureKeyCredential(topicKey)
);

var eventGridEvent = new EventGridEvent(
    subject: "Posts/NewPostPublished",
    eventType: "TechStackBlog.PostPublished",
    dataVersion: "1.0",
    data: new { PostId = 34, Slug = "azure-integration-interview-prep-part1" }
);

await client.SendEventAsync(eventGridEvent);

// A Function App reacting to a BUILT-IN Azure event -
// this example reacts automatically when a blob is
// uploaded to storage, no polling required
[Function("OnBlobUploaded")]
public async Task Run(
    [EventGridTrigger] EventGridEvent eventGridEvent)
{
    if (eventGridEvent.EventType == "Microsoft.Storage.BlobCreated")
    {
        var blobUrl = eventGridEvent.Data.ToString();
        await ProcessNewBlobAsync(blobUrl);
    }
}

Event Grid: Problem Scenario and Solving Strategy

The problem: whenever a new image is uploaded to Blob Storage, three completely independent things need to happen immediately - generate a thumbnail, run content moderation, and update a search index. These three actions are unrelated to each other, each can fail or succeed independently, and there's no need to hold onto historical upload events, only new uploads matter, reacted to as they happen.

The strategy, step by step:

First, recognize this is a reactive routing problem, not a volume or ordering problem - a blob upload is a discrete event that needs to fan out to multiple independent reactions, immediately, with no need for historical replay or streaming.
Second, use Azure Event Grid, leveraging its built-in integration with Blob Storage, since no custom code is needed to detect that a blob was uploaded - Azure Storage already publishes this event to Event Grid automatically.
Third, create three separate Event Grid subscriptions against the same Blob Storage source event: one triggering a Generate Thumbnail Function App, one triggering a Content Moderation Function App, and one triggering an Update Search Index Function App.
Fourth, note that each subscription operates completely independently - if content moderation fails, thumbnail generation is entirely unaffected, since Event Grid delivers to each subscriber separately.
Fifth, configure Event Grid's built-in retry policy, exponential backoff with a configurable max retry count, on each subscription individually, tuned to how critical and how flaky each specific downstream action actually is.
Finally, for any subscription needing to survive multiple retry failures, configure a dead-letter destination, typically a Storage Blob container, so failed events aren't silently lost - this is Event Grid's equivalent to Service Bus's dead-letter queue, configured per-subscription rather than being automatic.

Choosing Between All Four: The Actual Decision Framework

Ask these questions, in this order. Is this a reaction to a discrete event happening, needing to fan out to multiple independent subscribers immediately? That's Event Grid. Is this a massive volume of small events, thousands or more per second, where the aggregate stream matters more than any single event's individual fate? That's Event Hub. Does this need real delivery guarantees - ordering, transactions, sessions, native dead-lettering - for individually important business messages? That's Service Bus. Is this a simple, high-volume task queue where cost efficiency matters and Service Bus's extra features genuinely aren't needed? That's Storage Queue.

Key Lessons

All four services move data between systems, but they solve genuinely different problems - the real interview skill is matching volume, ordering needs, and delivery guarantees to the correct service, not memorizing a feature comparison table.

Service Bus is the right choice specifically when individual message correctness, ordering, or transactional guarantees matter - Storage Queue is the lighter, cheaper alternative when they don't.

Event Hub and Event Grid are both "event" services but solve opposite-shaped problems - Event Hub handles massive continuous streams, Event Grid handles discrete reactive notifications fanning out to multiple subscribers.

Every problem scenario in this post started with identifying the actual constraint, ordering, volume, fan-out, cost, before picking a service - that ordering of reasoning is what a panel interview is actually listening for.

Native dead-lettering, sessions, and transactions are real, meaningful differentiators, not just checkbox features - they solve specific correctness problems the simpler services genuinely cannot.

What's Next

Future parts of this series will cover additional Azure integration services - Logic Apps and Function Apps as orchestration layers, API Management as the gateway layer, and deeper production patterns for combining these services together in real architectures.

Summary

Service Bus, Storage Queues, Event Hub, and Event Grid all sound similar on the surface, since all four move data between systems, but they solve genuinely different problems at genuinely different scales. Service Bus guarantees correctness for individually important messages. Storage Queue trades those guarantees for simplicity and cost at high volume. Event Hub ingests and streams massive volumes of small events. Event Grid reactively routes discrete events to multiple independent subscribers. Knowing which constraint actually matters in a given scenario, and reasoning through that out loud, is what separates a memorized answer from a genuinely confident one in a panel interview.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=azure-integration-interview-prep-part1
More from TechStack Blog: Azure: https://www.techstackblog.com/category.html?cat=azure
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

C# Coding Interview Prep Part 3: Async/Await, Task, CancellationToken, Reflection, Records, Iterators, and Dependency Injection

Manohari Jayachandran — Mon, 17 Aug 2026 13:31:17 +0000

Part 1 covered the basics. Part 2 covered mid-level concepts - LINQ, generics, delegates, OOP pillars. This closing part covers the topics that come up specifically once an interview turns toward concurrency and production-shaped code - the concepts that separate "I've used async/await" from "I understand what it's actually doing, and where it can quietly go wrong." Same format throughout: a plain-English explanation, an analogy, a real code example, and a practice question for every topic.

Topic 1: async and await, What's Actually Happening

The single most important thing to internalize about async/await: it does not create a new thread. When code hits an await, the current thread is released back to the thread pool to go do other work, and execution resumes later, possibly on a different thread, once the awaited operation completes. This is what makes async code scale: a thread isn't sitting idle, blocked, doing nothing while waiting for a slow database call or HTTP request.

Think of a restaurant waiter who takes an order, hands it to the kitchen, and immediately goes to serve other tables instead of standing at the kitchen window waiting for the dish to finish cooking. The waiter, the thread, is never blocked - they're released to do other useful work, and come back once notified the food is ready.

// WITHOUT async - the thread BLOCKS entirely for
// the full duration of the slow operation
public IActionResult GetPosts()
{
    var posts = _context.Posts.ToList();  // thread
                                            // sits idle
                                            // the WHOLE time
    return Ok(posts);
}

// WITH async - the thread is RELEASED during the wait
public async Task<IActionResult> GetPostsAsync()
{
    var posts = await _context.Posts.ToListAsync();
    // ^ thread released HERE, goes to serve other
    // requests, resumes here once the DB responds
    return Ok(posts);
}

// async void - AVOID, except for actual event handlers
// Cannot be awaited, exceptions are difficult to catch
async void BadExample() { await DoSomethingAsync(); }

// The rule: "await all the way up" - once one method
// in a call chain is async, everything calling it
// should be async too, all the way to the entry point

Practice question: Explain, in your own words, why async/await improves scalability for a web API even though the actual database query still takes the same amount of time either way.

Topic 2: Task, Task, ValueTask, and Task

Task represents an asynchronous operation with no return value. Task represents one that returns a value of type T once complete. Task specifically is the standard return type for an async ASP.NET Core controller action, since IActionResult is what represents the actual HTTP response being built.

// Task - async work, no return value
public async Task SaveLogAsync(string message)
{
    await _logService.WriteAsync(message);
}

// Task<T> - async work that returns a value
public async Task<Post> GetPostAsync(int id)
{
    return await _context.Posts.FindAsync(id);
}

// Task<IActionResult> - the standard shape of an
// async ASP.NET Core controller action
[HttpGet("{id}")]
public async Task<IActionResult> GetPost(int id)
{
    var post = await _postService.GetByIdAsync(id);

    if (post == null)
        return NotFound();      // IActionResult

    return Ok(post);            // ALSO IActionResult -
                                  // this is exactly why
                                  // the return type needs
                                  // to be the interface,
                                  // not one specific result
                                  // type - both NotFound()
                                  // and Ok() implement it
}

// ValueTask<T> - a struct-based alternative to Task<T>,
// avoids a heap allocation when the result is ALREADY
// available synchronously (like a cache hit) - a real
// performance optimization for hot paths, but adds
// complexity, so it's used selectively, not by default
public ValueTask<int> GetCachedValueAsync(string key)
{
    if (_cache.TryGetValue(key, out int value))
        return new ValueTask<int>(value);  // no allocation,
                                              // result is
                                              // already here

    return new ValueTask<int>(FetchFromDatabaseAsync(key));
}

Practice question: Why does NotFound() and Ok(post) both being valid return values inside the same method require the method's return type to be Task rather than something more specific?

Topic 3: Task.WhenAll and Task.WhenAny

When multiple independent async operations don't depend on each other's results, running them sequentially with separate await calls wastes time - the total wait becomes the sum of every operation. Task.WhenAll starts them all at once and waits for every one to finish, so the total time becomes the slowest one, not the sum.

// Sequential - SLOW, adds up every wait
var posts = await GetPostsAsync();       // waits 100ms
var tags = await GetTagsAsync();         // THEN waits 80ms
var comments = await GetCommentsAsync(); // THEN waits 60ms
// Total: 240ms

// Parallel with Task.WhenAll - FAST, runs together
var postsTask = GetPostsAsync();      // starts immediately
var tagsTask = GetTagsAsync();        // starts immediately
var commentsTask = GetCommentsAsync(); // starts immediately

await Task.WhenAll(postsTask, tagsTask, commentsTask);

var posts = postsTask.Result;      // already complete,
var tags = tagsTask.Result;        // safe to read
var comments = commentsTask.Result; // .Result here now

// Total: 100ms - the duration of the SLOWEST one

// Task.WhenAny - resolves as soon as the FIRST task
// completes, useful for timeout patterns or "whichever
// responds first" scenarios
var timeoutTask = Task.Delay(5000);
var dataTask = GetDataFromSlowServiceAsync();

var winner = await Task.WhenAny(dataTask, timeoutTask);
if (winner == timeoutTask)
{
    throw new TimeoutException("Operation took too long");
}

Practice question: Given three independent async methods that each take about 200ms, write code using Task.WhenAll to run them concurrently, and explain roughly how much total time this saves compared to awaiting each one sequentially.

Topic 4: CancellationToken

A CancellationToken represents a request for cancellation, not a forced stop. Nothing gets automatically killed the moment cancellation is requested - the running async code has to actively check the token, or call something that checks it internally like ToListAsync(token), and choose to stop.

// A method that respects cancellation
public async Task ProcessItemsAsync(
    List<int> items, CancellationToken cancellationToken)
{
    foreach (var item in items)
    {
        // Actively checking - throws OperationCanceledException
        // if cancellation was requested, stopping the loop
        cancellationToken.ThrowIfCancellationRequested();

        await ProcessOneItemAsync(item);
    }
}

// Passing the token INTO async framework methods -
// many built-in async methods accept a token and
// check it internally for you
public async Task<List<Post>> GetPostsAsync(
    CancellationToken cancellationToken)
{
    return await _context.Posts
        .ToListAsync(cancellationToken);
        // EF Core checks this token during the DB call
}

// Where the token actually comes from - ASP.NET Core
// automatically provides one tied to the HTTP request,
// cancelled if the client disconnects early
[HttpGet]
public async Task<IActionResult> GetAll(
    CancellationToken cancellationToken)
{
    var posts = await _postService.GetAllAsync(cancellationToken);
    return Ok(posts);
}

// Manually creating and triggering cancellation
using var cts = new CancellationTokenSource();
cts.CancelAfter(TimeSpan.FromSeconds(5));  // auto-cancel
                                             // after 5 seconds

try
{
    await LongRunningOperationAsync(cts.Token);
}
catch (OperationCanceledException)
{
    Console.WriteLine("Operation was cancelled");
}

Practice question: Why does calling cancellationToken.ThrowIfCancellationRequested() inside a loop matter, versus just checking the token once at the very start of a long-running method?

Topic 5: Thread Safety and lock

When multiple threads access and modify the same shared data at the same time, without coordination, the result can be corrupted or unpredictable - a race condition. The lock keyword ensures only one thread can execute a specific block of code at a time.

public class Counter
{
    private int _count = 0;
    private readonly object _lockObject = new();

    public void Increment()
    {
        lock (_lockObject)
        {
            _count++;
            // Only ONE thread can be inside this block
            // at any given moment - other threads trying
            // to enter WAIT until this one exits
        }
    }
}

// Without the lock, this specific line:
// _count++;
// is NOT actually atomic - it's really three steps:
// read _count, add 1, write it back. Two threads
// interleaving those three steps can genuinely LOSE
// an increment, producing a wrong final count

Think of a single-occupancy restroom with a lock on the door. Only one person can be inside at a time - anyone else who arrives waits outside until the door unlocks, preventing the chaos of two people trying to use the same space simultaneously.

Practice question: Explain why _count++ can produce an incorrect final result when called from multiple threads simultaneously without a lock, even though it looks like one simple operation.

Topic 6: ConcurrentDictionary and Thread-Safe Collections

A regular Dictionary is not thread-safe - concurrent reads and writes from multiple threads can corrupt its internal state or throw exceptions. ConcurrentDictionary is specifically designed to handle concurrent access safely, without you needing to manually add locks around every operation.

// A regular Dictionary under concurrent access -
// GENUINELY UNSAFE, can throw or corrupt data
var unsafeDict = new Dictionary<string, int>();
// Multiple threads calling unsafeDict[key] = value
// simultaneously can throw InvalidOperationException
// or leave the dictionary in a broken internal state

// ConcurrentDictionary - safe by design
var safeDict = new ConcurrentDictionary<string, int>();

// Thread-safe add or update in one atomic operation
safeDict.AddOrUpdate(
    "views",
    addValue: 1,                          // if key doesn't exist
    updateValueFactory: (key, oldValue) => oldValue + 1
);                                          // if it does

// Thread-safe get-or-add
int value = safeDict.GetOrAdd("counter", 0);

// TryGetValue, TryAdd, TryRemove - all thread-safe,
// non-throwing variants
bool found = safeDict.TryGetValue("views", out int views);

// Other thread-safe collections worth knowing:
// ConcurrentBag<T>   - unordered thread-safe collection
// ConcurrentQueue<T> - thread-safe FIFO queue
// ConcurrentStack<T> - thread-safe LIFO stack

Practice question: Why would a regular Dictionary used as a page-view counter, incremented by many concurrent web requests, eventually produce an incorrect total count?

Topic 7: The Classic Async Deadlock

Calling .Result or .Wait() on an async method, instead of awaiting it, can cause a genuine deadlock in certain contexts - classic ASP.NET, WPF, WinForms, contexts with a synchronization context. This is one of the most commonly tested async gotchas in interviews specifically because it's a real, painful production bug pattern.

// THE DEADLOCK TRAP
public IActionResult GetPost(int id)
{
    var post = GetPostAsync(id).Result;  // BLOCKS the
                                           // current thread,
                                           // waiting for the
                                           // async method
    return Ok(post);
}

public async Task<Post> GetPostAsync(int id)
{
    await Task.Delay(100);  // simulate async work
    return await _context.Posts.FindAsync(id);
    // In certain contexts, THIS await tries to resume
    // back on the SAME thread that called .Result -
    // but that thread is BLOCKED waiting for .Result
    // to return. Neither side can proceed. Deadlock.
}

// THE FIX - await all the way up, never mix
// synchronous blocking with async code
public async Task<IActionResult> GetPost(int id)
{
    var post = await GetPostAsync(id);  // correctly
                                          // awaited, no
                                          // blocking, no
                                          // deadlock risk
    return Ok(post);
}

// ConfigureAwait(false) - a partial mitigation seen in
// older library code, tells the awaited task "you don't
// need to resume on the original context" - reduces
// deadlock risk in SOME cases, but "await all the way
// up" is the more reliable, modern fix

Practice question: Explain, step by step, why calling .Result on an async method from within an ASP.NET (classic, non-Core) request context can deadlock, while calling the same async method from a Console app usually does not.

Topic 8: Reflection

Reflection lets code inspect and interact with types, methods, and properties at runtime, rather than everything being fixed at compile time. It's genuinely powerful, and genuinely has a real performance cost - it's a tool reached for deliberately, not a default approach.

// Getting type information at runtime
Type postType = typeof(Post);
Console.WriteLine(postType.Name);          // "Post"
Console.WriteLine(postType.Namespace);

// Inspecting properties dynamically
foreach (var property in postType.GetProperties())
{
    Console.WriteLine($"{property.Name}: {property.PropertyType}");
}

// Creating an instance dynamically, without knowing
// the concrete type at compile time
object instance = Activator.CreateInstance(postType);

// Reading and setting a property value via reflection
var titleProperty = postType.GetProperty("Title");
titleProperty.SetValue(instance, "Hello via Reflection");
var value = titleProperty.GetValue(instance);

// Where reflection actually shows up in real code -
// this is EXACTLY how many frameworks work under
// the hood, including:
// - JSON serializers (reading property names/values)
// - Dependency injection containers (finding constructors)
// - ORMs like EF Core (mapping properties to columns)
// - Unit testing frameworks (finding [Test] methods)

Practice question: Using reflection, write code that lists the names of all public methods defined on a given class.

Topic 9: Attributes

Attributes attach metadata to code - classes, methods, properties - that can be read at runtime, commonly via reflection. They don't change what the code does directly; they annotate it with information other code can act on.

// Built-in attributes you already use constantly
[HttpGet]
[Route("posts/{id}")]
public async Task<IActionResult> GetPost(int id) { }

[Required]
[MaxLength(200)]
public string Title { get; set; }

[Obsolete("Use GetByIdAsync instead")]
public Post GetById(int id) { }

// Defining your own custom attribute
[AttributeUsage(AttributeTargets.Method)]
public class LogExecutionTimeAttribute : Attribute { }

public class PostService
{
    [LogExecutionTime]
    public void SlowOperation() { }
}

// Reading a custom attribute via reflection - this is
// how frameworks actually ACT on attributes, since an
// attribute alone does nothing without something
// reading and reacting to it
var method = typeof(PostService).GetMethod("SlowOperation");
var hasAttribute = method.GetCustomAttribute<LogExecutionTimeAttribute>() != null;

if (hasAttribute)
{
    Console.WriteLine("This method should have its execution time logged");
}

Practice question: What is the relationship between attributes and reflection? Can an attribute do anything on its own without reflection, or something equivalent, reading it?

Topic 10: Records

A record is a reference type, by default, specifically designed for immutable data, with built-in value-based equality - meaning two records with identical property values are considered equal, without you needing to hand-write Equals() and GetHashCode() yourself.

// Traditional class - reference equality by default,
// requires manually overriding Equals/GetHashCode
// for value-based comparison (covered in Part 2)
public class PostClass
{
    public string Title { get; set; }
    public string Slug { get; set; }
}

// Record - concise syntax, VALUE-based equality
// built in automatically
public record Post(string Title, string Slug);

var post1 = new Post("Hello", "hello");
var post2 = new Post("Hello", "hello");

Console.WriteLine(post1 == post2);        // TRUE -
                                            // value equality,
                                            // automatically
Console.WriteLine(post1.Equals(post2));   // TRUE

// Records are IMMUTABLE by default - properties are
// init-only, cannot be changed after construction
// post1.Title = "New Title";  // does NOT compile

// "with" expressions - create a MODIFIED COPY,
// original stays completely unchanged
var post3 = post1 with { Title = "Updated Title" };
Console.WriteLine(post1.Title);  // still "Hello"
Console.WriteLine(post3.Title);  // "Updated Title"

// Records also get a useful ToString() automatically
Console.WriteLine(post1);  // "Post { Title = Hello, Slug = hello }"

Practice question: Why might a record be a better choice than a class for representing an immutable DTO, data transfer object, passed between layers of an application?

Topic 11: Memory Fundamentals - Stack vs Heap

This ties directly back to the value vs reference type distinction from Part 1, but from the memory allocation angle specifically. Value types typically live on the stack, fast, automatically reclaimed when a method returns. Reference types live on the heap, managed by the garbage collector, covered in Part 2.

void ExampleMethod()
{
    int number = 5;              // value type - lives on
                                   // the STACK, in this
                                   // method's own frame

    var post = new Post();       // reference type - the
                                   // ACTUAL Post object
                                   // lives on the HEAP;
                                   // 'post' itself (the
                                   // reference/pointer) is
                                   // on the stack

}   // when ExampleMethod() returns, the STACK FRAME
    // is simply popped - 'number' and the 'post'
    // REFERENCE are gone instantly. The actual Post
    // OBJECT on the heap survives until the garbage
    // collector determines nothing references it anymore

// Why this matters for interview-level understanding:
// Stack allocation/deallocation is extremely fast -
// just moving a pointer. Heap allocation requires the
// GC to eventually track and reclaim that memory,
// which is real, measurable overhead at scale - this
// is exactly WHY boxing (Part 2) has a real cost, and
// why minimizing unnecessary heap allocations matters
// in performance-sensitive code

Practice question: Explain why creating a million small, short-lived objects inside a tight loop can create real garbage collection pressure, connecting this back to what you learned about GC generations in Part 2.

Topic 12: yield return and Iterators

yield return lets you write a method that produces a sequence of values one at a time, lazily - each value is only computed when actually requested, rather than the whole sequence being built and held in memory upfront. This is exactly the mechanism that makes IEnumerable and deferred execution, from Part 2, actually possible under the hood.

// WITHOUT yield - builds the ENTIRE list in memory
// before returning anything at all
public List<int> GetSquaresList(int count)
{
    var result = new List<int>();
    for (int i = 0; i < count; i++)
    {
        result.Add(i * i);
    }
    return result;  // all 'count' values already computed
                     // and held in memory before the
                     // caller gets anything back
}

// WITH yield - produces ONE value at a time, on demand
public IEnumerable<int> GetSquares(int count)
{
    for (int i = 0; i < count; i++)
    {
        yield return i * i;
        // execution PAUSES here after each value,
        // resuming only when the NEXT value is
        // actually requested by the caller
    }
}

// Calling it - values are computed lazily, one at a
// time, as the foreach loop actually asks for each one
foreach (var square in GetSquares(1000000))
{
    if (square > 100) break;
    // Because of yield, this STOPS the underlying
    // method early too - only a handful of squares
    // were ever actually computed, not all 1,000,000
}

// This is EXACTLY the mechanism behind LINQ's
// deferred execution from Part 2 - Where, Select, and
// most LINQ methods are implemented using yield return
// internally, which is WHY they don't run until iterated

Practice question: Write a method using yield return that produces an infinite sequence of Fibonacci numbers, and explain why this would be impossible to write using a regular method that returns a List.

Topic 13: Dependency Injection

Dependency Injection, DI, is a pattern where a class receives, is "injected with," the objects it depends on from the outside, rather than creating those dependencies itself internally. ASP.NET Core has a built-in DI container, and understanding the three standard lifetimes is a near-universal interview topic for anyone working with the framework.

// WITHOUT DI - PostService creates its own dependency
// directly, tightly coupled to one specific
// implementation, hard to swap or test in isolation
public class PostService
{
    private readonly SqlPostRepository _repository = new();

    public List<Post> GetAll() => _repository.GetAll();
}

// WITH DI - the dependency is INJECTED via the
// constructor, PostService depends only on the
// ABSTRACTION (interface), not a specific implementation
public class PostService
{
    private readonly IPostRepository _repository;

    public PostService(IPostRepository repository)
        => _repository = repository;
        // ^ this dependency is provided from OUTSIDE,
        // not created here - makes swapping
        // implementations, and unit testing with a
        // mock IPostRepository, straightforward

    public List<Post> GetAll() => _repository.GetAll();
}

// Registering services in Program.cs, and the three
// standard lifetimes
builder.Services.AddTransient<IPostRepository, SqlPostRepository>();
// Transient - a NEW instance created every single
// time it's requested, anywhere

builder.Services.AddScoped<IPostRepository, SqlPostRepository>();
// Scoped - ONE instance per HTTP request, shared
// across everything within that same request, but a
// NEW one for the next request - the most common
// choice for things like a DbContext

builder.Services.AddSingleton<IPostRepository, SqlPostRepository>();
// Singleton - ONE instance for the ENTIRE application
// lifetime, shared by every request - use carefully,
// since shared mutable state across concurrent
// requests needs to be genuinely thread-safe

Practice question: Explain the practical difference between Scoped and Singleton lifetimes, and why registering a class that holds a database connection as Singleton could cause serious problems under concurrent web traffic.

Key Lessons

async/await releases the current thread during a wait rather than creating a new one - this is the entire mechanism behind why async scales.

Task.WhenAll runs independent async operations in parallel, reducing total wait time from the sum of every operation to just the slowest one.

CancellationToken is a cooperative signal, not a forced stop - code must actively check it or pass it into something that does.

Regular Dictionary is not thread-safe; ConcurrentDictionary is designed specifically for concurrent access without manual locking.

Calling .Result or .Wait() on async code instead of awaiting it is a real, well-known deadlock trap in certain synchronization contexts.

Reflection and attributes work together - attributes are inert metadata until something using reflection actually reads and acts on them.

Records give built-in, value-based equality and immutability with far less code than a hand-written class doing the same thing.

Stack allocation, value types and local variables, is fast and automatic; heap allocation, reference types, is managed by the garbage collector and carries real, measurable overhead at scale.

yield return is the actual mechanism behind LINQ's deferred execution from Part 2 - it produces values lazily, one at a time, rather than building an entire collection upfront.

Dependency Injection lifetimes - Transient, Scoped, Singleton - control how long a registered service instance is shared, and choosing the wrong one, especially Singleton for something not genuinely thread-safe, is a real, common production bug source.

The Series, Complete

This closes out the full three-part C# interview prep series. Part 1 covered the basics - variables, strings, collections, control flow, methods, enums, structs. Part 2 covered mid-level concepts - LINQ, IEnumerable vs IQueryable, generics, delegates, interfaces vs abstract classes, garbage collection, the four pillars of OOP, and lambda expressions. Part 3 covered advanced concepts - async/await, Task-based patterns, concurrency, thread safety, reflection, memory fundamentals, iterators, and dependency injection.

Summary

The advanced concepts in this part are where interview questions stop testing whether you know C# syntax and start testing whether you understand what's actually happening at runtime - which thread is doing what, when memory gets allocated and reclaimed, and what a keyword like await or lock genuinely does underneath the syntax. Together, all three parts of this series cover the range of C# knowledge that shows up constantly in real coding interviews, not as a syntax quiz, but as a test of whether the underlying mental model is genuinely there.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=csharp-interview-prep-advanced-part3

Part 1 of this series (Basics): https://www.techstackblog.com/post.html?slug=csharp-interview-prep-basics-part1
Part 2 of this series (Mid-Level): https://www.techstackblog.com/post.html?slug=csharp-interview-prep-midlevel-part2

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

C# Coding Interview Prep Part 2: LINQ, Generics, Delegates, Interfaces, Garbage Collection, OOP Pillars, and IEnumerable vs IQueryable

Manohari Jayachandran — Fri, 14 Aug 2026 01:38:49 +0000

Part 1 covered the basics - variables, strings, collections, control flow, methods. This part covers the concepts that separate "I can write C#" from "I understand what's actually happening underneath" - the topics that come up constantly in real coding interviews and rarely get explained clearly in one place. Same format as Part 1 throughout: a plain-English explanation, an analogy, a real code example, and a practice question for every topic.

Topic 1: LINQ and Deferred Execution

LINQ, Language Integrated Query, lets you query collections using a consistent, readable syntax. The critical concept most people miss: LINQ queries do not execute when defined - they execute when iterated with foreach or materialized with ToList, Count, or First.

Think of writing a shopping list versus actually going to the store. Defining a LINQ query is writing the list - nothing happens yet. The query only actually runs the moment you walk into the store and start picking items off the shelf, which is iterating the results.

var posts = GetAllPosts(); // List<Post>

// This line does NOT query anything yet - it just
// builds up a description of what to do
var query = posts.Where(p => p.IsPublished);

// The query actually EXECUTES here, when iterated
foreach (var post in query) { }

// Or when materialized
var list = query.ToList();   // executes now
var count = query.Count();   // executes now

// Why this matters - data can change between
// definition and execution
posts.Add(new Post { IsPublished = true, Title = "New" });
var results = query.ToList();  // includes the new post,
                                 // because the query only
                                 // ran just now, AFTER the add

// Common LINQ methods
var published = posts.Where(p => p.IsPublished);
var titles = posts.Select(p => p.Title);
var sorted = posts.OrderByDescending(p => p.CreatedAt);
var first = posts.FirstOrDefault(p => p.Slug == "csharp-basics");
var grouped = posts.GroupBy(p => p.Tech);
var any = posts.Any(p => p.Tech == "Azure");
var total = posts.Sum(p => p.ReadingTime);

Practice question: Write a LINQ query that groups a list of posts by their Tech tag, then returns only the groups with more than 2 posts.

Topic 2: IEnumerable vs IQueryable

This is the distinction that matters enormously once Entity Framework is involved. IEnumerable represents an in-memory sequence - once data is loaded, filtering happens in application memory. IQueryable represents a query that can be translated into another language, SQL for a database, and executed at the source, with the actual filtering happening there instead.

Think of IEnumerable as receiving an entire filing cabinet's contents shipped to your desk, then sorting through the papers yourself. IQueryable is like sending instructions to the filing clerk - "bring me only the folders from 2026" - so the clerk does the filtering before anything is even shipped to you.

// IQueryable - this does NOT hit the database yet,
// it builds an expression tree describing the query
IQueryable<Post> query = dbContext.Posts
    .Where(p => p.IsPublished);

// Still IQueryable - EF Core keeps building the SQL
query = query.Where(p => p.Tech == "Azure");

// NOW it executes - EF Core translates the WHOLE
// thing into ONE SQL query, filtering happens
// IN THE DATABASE
var results = query.ToList();
// SQL: SELECT * FROM Posts
//      WHERE IsPublished = 1 AND Tech = 'Azure'

// THE MISTAKE - calling ToList() too early
IEnumerable<Post> earlyList = dbContext.Posts.ToList();
// ^ This ALREADY hit the database and loaded
//   EVERY post into memory, no filtering applied yet

var filtered = earlyList.Where(p => p.Tech == "Azure");
// This filtering now happens IN MEMORY, in C#,
// AFTER all posts were already pulled from SQL -
// far more data transferred than necessary

// The rule: keep building your query with IQueryable
// as long as possible, call ToList()/ToListAsync()
// LAST, once every filter is already applied

Practice question: Given a method that accepts IQueryable as a parameter, explain what happens differently if that method internally calls .ToList() before applying additional filters, versus applying filters first and calling .ToList() last.

Topic 3: Generics

Generics let you write one class or method that works safely across many types, without duplicating code for each type or giving up compile-time type checking by using object.

// Generic class - T is decided at the moment of use
public class Box<T>
{
    private T _item;
    public void Store(T item) => _item = item;
    public T Retrieve() => _item;
}

var postBox = new Box<Post>();
var numberBox = new Box<int>();

// Generic method
public T GetFirstOrDefault<T>(List<T> items)
{
    return items.Count > 0 ? items[0] : default(T);
}

// Constraints - restricting what T can be
public class Repository<T> where T : class, new()
{
    public T CreateNew() => new T();
    // class = T must be a reference type
    // new() = T must have a parameterless constructor,
    //         which is what makes "new T()" legal here
}

public T GetMax<T>(List<T> items) where T : IComparable<T>
{
    T max = items[0];
    foreach (var item in items)
        if (item.CompareTo(max) > 0) max = item;
    return max;
    // IComparable<T> constraint is what makes
    // .CompareTo() legal to call here
}

Practice question: Write a generic method Swap that takes two ref parameters of type T and swaps their values.

Topic 4: Delegates and Events

A delegate is a type-safe reference to a method - it lets you pass behavior around as if it were data. Events build on delegates to create a publish-subscribe relationship where a publisher notifies subscribers without knowing who they are.

// Built-in delegate types cover almost every case
Func<int, int, int> add = (a, b) => a + b;   // has a return value
Action<string> log = msg => Console.WriteLine(msg); // no return value
Predicate<int> isEven = n => n % 2 == 0;      // always returns bool

Console.WriteLine(add(3, 4));  // 7
log("Hello");

// Every LINQ lambda is secretly a delegate
posts.Where(p => p.IsPublished);  // this lambda IS a
                                     // Func<Post, bool>

// Events - a delegate only the publisher can raise
public class PostPublisher
{
    public event EventHandler<string> PostPublished;

    public void Publish(string title)
    {
        PostPublished?.Invoke(this, title);
        // ?. prevents a crash if nobody subscribed
    }
}

var publisher = new PostPublisher();
publisher.PostPublished += (sender, title) =>
    Console.WriteLine($"Published: {title}");

publisher.Publish("New Post");  // triggers the subscriber

Practice question: What's the actual difference between a delegate and an event? Why can't code outside the publisher class directly call PostPublished.Invoke()?

Topic 5: Interfaces vs Abstract Classes

Both define a contract other classes must fulfill, but an interface has no implementation of its own, traditionally, and a class can implement many interfaces, while an abstract class can provide shared, partial implementation, and a class can inherit from only one.

public interface IShape
{
    double GetArea();  // no implementation - a pure contract
}

public abstract class ShapeBase
{
    public string Name { get; set; }

    // Shared, concrete implementation every subclass gets for free
    public void PrintName() => Console.WriteLine(Name);

    // Abstract member - subclasses MUST provide this
    public abstract double GetArea();
}

public class Circle : ShapeBase, IShape
{
    public double Radius { get; set; }
    public override double GetArea() => Math.PI * Radius * Radius;
}

// A class can implement MANY interfaces
public class Employee : IWorkable, IFeedable, IRestable { }

// But only ONE base class
public class Manager : Employee /* cannot also : Contractor */ { }

Reach for an interface when unrelated classes need to fulfill the same contract with no shared code - a Circle and a Square both have an area but share nothing else. Reach for an abstract class when related classes genuinely share common implementation, not just a shape.

Practice question: Design a small example, interface or abstract class, for a payment system with CreditCardPayment and PayPalPayment - explain which you'd choose and why.

Topic 6: Garbage Collection

.NET automatically manages memory - you don't manually free objects. The garbage collector, GC, periodically identifies objects no longer reachable from your running code and reclaims their memory. It organizes objects into generations to make this efficient.

Generation 0 is where newly created objects start. They're collected very frequently and cheaply, since most objects die young - a temporary variable inside a method, for instance. Generation 1 holds objects that survived a Generation 0 collection, a middle ground collected less often. Generation 2 holds long-lived objects, like a Singleton or a cache, something alive for the app's whole lifetime, collected rarely and expensively when it happens.

This generational design exists because most objects are genuinely short-lived - checking Generation 0 constantly and Generation 2 rarely is far more efficient than treating every object identically.

// IDisposable - for resources the GC does NOT
// know how to clean up on its own (file handles,
// database connections, network sockets)
public class FileLogger : IDisposable
{
    private StreamWriter _writer;

    public FileLogger(string path)
        => _writer = new StreamWriter(path);

    public void Log(string message) => _writer.WriteLine(message);

    public void Dispose()
    {
        _writer?.Dispose();  // release the file handle
                              // DETERMINISTICALLY, not
                              // whenever GC happens to run
    }
}

// using statement - guarantees Dispose() is called,
// even if an exception occurs
using (var logger = new FileLogger("log.txt"))
{
    logger.Log("Application started");
}  // Dispose() called automatically HERE

// Modern C# - using declaration, disposes at end of scope
using var logger2 = new FileLogger("log.txt");
logger2.Log("Started");

A finalizer, written as a destructor-style method, does eventually run before an object's memory is reclaimed, but "eventually" could be a long time, since it depends on GC timing, not your code's timing - a file handle held open for an unpredictable extra period is a real problem. IDisposable with a using block releases the resource deterministically, the moment you're actually done with it.

Practice question: Why would a class holding a database connection want to implement IDisposable rather than relying purely on the garbage collector and a finalizer?

Topic 7: Exception Handling in Depth

Beyond basic try/catch, real production code needs custom exception types, exception filters, and correct rethrowing that preserves the original stack trace.

// Custom exceptions - carry meaningful, specific
// information beyond a generic Exception
public class InsufficientFundsException : Exception
{
    public decimal RequestedAmount { get; }
    public decimal AvailableBalance { get; }

    public InsufficientFundsException(
        decimal requested, decimal available)
        : base($"Cannot withdraw {requested:C}, only {available:C} available")
    {
        RequestedAmount = requested;
        AvailableBalance = available;
    }
}

// Exception filters - catch only under a specific
// condition, without catching and immediately
// rethrowing everything else
try
{
    CallExternalApi();
}
catch (HttpRequestException ex) when (ex.Message.Contains("timeout"))
{
    // only handles TIMEOUT-related HTTP failures,
    // other HttpRequestExceptions pass through uncaught
    RetryRequest();
}

// Rethrowing CORRECTLY - preserves the original
// stack trace, showing where the error ACTUALLY
// originated
try
{
    DoSomething();
}
catch (Exception ex)
{
    LogError(ex);
    throw;              // CORRECT - preserves original
                          // stack trace

    // throw ex;         // WRONG - resets the stack
                          // trace to HERE, hiding
                          // where it actually happened
}

// finally always runs, exception or not
try { RiskyOperation(); }
finally { CleanUp(); }  // always executes

Practice question: What is the practical difference between throw; and throw ex; inside a catch block? Write a short example showing why this matters when debugging a production error.

Topic 8: Boxing and Unboxing

Boxing wraps a value type - int, bool, struct - inside an object on the heap, so it can be treated as a reference type. Unboxing extracts the value type back out. Both have a genuine, measurable performance cost - a real heap allocation happens on every box.

int number = 42;

// Boxing - value type wrapped in an object,
// a REAL heap allocation happens here
object boxed = number;

// Unboxing - extracting the value back out,
// requires an explicit cast
int unboxed = (int)boxed;

// Where this quietly happens without you noticing -
// non-generic collections
ArrayList list = new ArrayList();
list.Add(42);        // BOXES the int automatically
int value = (int)list[0];  // UNBOXES it back

// Generic collections AVOID this entirely - this is
// a real, meaningful reason List<T> beats ArrayList
List<int> genericList = new List<int>();
genericList.Add(42);  // stored directly as int,
                        // NO boxing at all

Practice question: Explain why storing a million integers in an ArrayList is slower and uses more memory than storing them in a List.

Topic 9: Equality - ==, Equals, and GetHashCode

C# has multiple ways to check equality, and they don't always agree - understanding when each applies, and why they can disagree, is a genuinely common interview probe.

// For value types, == and Equals() check VALUE equality
int a = 5, b = 5;
Console.WriteLine(a == b);        // true
Console.WriteLine(a.Equals(b));   // true

// For reference types (by default, unless overridden),
// == and Equals() check REFERENCE equality - are these
// the SAME object in memory, not just "look the same"
var post1 = new Post { Title = "Hello" };
var post2 = new Post { Title = "Hello" };
Console.WriteLine(post1 == post2);        // false -
                                            // different objects
Console.WriteLine(post1.Equals(post2));   // false - same
                                            // default behavior

// string is a SPECIAL CASE - == is overridden to
// check VALUE equality even though string is a
// reference type
string s1 = "hello";
string s2 = "hello";
Console.WriteLine(s1 == s2);  // true - value equality,
                                // special-cased for string

// Overriding equality for your own class
public class Post
{
    public string Slug { get; set; }

    public override bool Equals(object obj)
    {
        if (obj is not Post other) return false;
        return Slug == other.Slug;
    }

    // MUST override GetHashCode consistently with
    // Equals, or Dictionary/HashSet lookups silently
    // break - two "equal" objects must produce the
    // SAME hash code
    public override int GetHashCode() => Slug?.GetHashCode() ?? 0;
}

// ReferenceEquals - explicitly checks "same object
// in memory", ignoring any Equals override
Console.WriteLine(ReferenceEquals(post1, post2));  // false

Practice question: Why does overriding Equals() without also overriding GetHashCode() cause a class to behave incorrectly when used as a Dictionary key?

Topic 10: Extension Methods

Extension methods let you add new methods to an existing type, including types you don't own like built-in .NET types, without modifying the original class or using inheritance.

// Defining an extension method - static class,
// static method, "this" before the first parameter
public static class StringExtensions
{
    public static bool IsValidSlug(this string input)
    {
        return !string.IsNullOrWhiteSpace(input)
            && input == input.ToLower()
            && !input.Contains(" ");
    }
}

// Calling it - looks exactly like a real instance method,
// even though string itself was never modified
string slug = "csharp-basics";
bool valid = slug.IsValidSlug();  // true

// This is EXACTLY how all the built-in LINQ methods
// work - Where, Select, OrderBy are all extension
// methods on IEnumerable<T>, defined in the Enumerable
// class, not actual members of List<T> itself

Practice question: Write an extension method TruncateWithEllipsis(this string input, int maxLength) that shortens a string to a max length and appends "..." if it was actually truncated.

Topic 11: Stack, Queue, and LinkedList

Beyond List, Dictionary, and HashSet, a few more built-in collections come up specifically for order-of-operations problems in interviews.

// Stack<T> - Last In, First Out (LIFO)
var undoHistory = new Stack<string>();
undoHistory.Push("Action 1");
undoHistory.Push("Action 2");
string lastAction = undoHistory.Pop();  // "Action 2" -
                                          // most recent

// Queue<T> - First In, First Out (FIFO)
var taskQueue = new Queue<string>();
taskQueue.Enqueue("Task 1");
taskQueue.Enqueue("Task 2");
string nextTask = taskQueue.Dequeue();  // "Task 1" -
                                          // first one in

// LinkedList<T> - doubly-linked list, efficient
// insertion/removal at any point WITHOUT shifting
// every other element, unlike List<T>, which shifts
// elements when inserting in the middle
var linked = new LinkedList<int>();
linked.AddLast(1);
linked.AddLast(2);
linked.AddFirst(0);
// Genuinely useful when frequent insertion/removal
// in the middle of a sequence matters more than
// indexed random access

Practice question: Using a Stack, write a method that checks whether a string of parentheses like "(())" or "(()" is properly balanced.

Topic 12: String Formatting

Beyond basic interpolation, C# offers format specifiers for numbers, dates, and custom types, worth knowing for anything display-facing.

decimal price = 1234.5m;
DateTime date = DateTime.Now;

Console.WriteLine($"{price:C}");      // $1,234.50
Console.WriteLine($"{price:N2}");     // 1,234.50
Console.WriteLine($"{date:yyyy-MM-dd}"); // 2026-08-13
Console.WriteLine($"{date:MMMM dd, yyyy}"); // August 13, 2026

// Alignment and padding in interpolation
string name = "Alex";
Console.WriteLine($"{name,10}");   // right-aligned, 10 wide
Console.WriteLine($"{name,-10}|"); // left-aligned, 10 wide

// ToString overrides for custom types
public class Post
{
    public string Title { get; set; }
    public override string ToString() => $"Post: {Title}";
}
var post = new Post { Title = "Hello" };
Console.WriteLine(post);  // "Post: Hello" - uses the override

Practice question: Given a decimal representing a price, write code that formats it as currency with exactly 2 decimal places, and explain the difference between the "C" and "N" format specifiers.

Topic 13: The Four Pillars of OOP

C# is an object-oriented language, and four principles show up in nearly every interview at some point, sometimes named directly, sometimes just probed through a design question. Interfaces vs Abstract Classes, covered earlier, already touched two of these indirectly - this topic names all four properly.

Encapsulation means bundling data and the methods that operate on it together, while restricting direct outside access to internal details. Inheritance means a class acquiring the members and behavior of another class, forming an "is-a" relationship. Polymorphism means the same method call producing different behavior depending on the actual runtime type of the object. Abstraction means exposing only what a caller needs to know, hiding implementation detail behind a simpler interface.

Think of encapsulation as a car's dashboard. The driver interacts with a steering wheel and pedals - simple, controlled surfaces - without needing direct access to the engine's internals. The engine's complexity is fully encapsulated behind that dashboard.

public class BankAccount
{
    // private - internal detail, hidden from outside code
    private decimal _balance;

    // public - the controlled, exposed surface
    public decimal Balance => _balance;

    public void Deposit(decimal amount)
    {
        if (amount <= 0)
            throw new ArgumentException("Amount must be positive");
        _balance += amount;
    }

    // Outside code CANNOT do "_balance = -1000" directly -
    // it can only interact through the controlled methods,
    // which enforce the actual business rules
}

Think of inheritance as a job title hierarchy. A Manager is a specific kind of Employee - inheriting everything an Employee has, a name, a salary, while adding something extra, a team to manage. This "is-a" relationship is exactly what class inheritance models.

public class Employee
{
    public string Name { get; set; }
    public decimal Salary { get; set; }
    public virtual void Work() => Console.WriteLine($"{Name} is working");
}

public class Manager : Employee
{
    public List<Employee> DirectReports { get; set; } = new();

    // override - replacing the inherited behavior
    public override void Work()
        => Console.WriteLine($"{Name} is managing the team");
}

Think of polymorphism as a universal play button on different music apps. Pressing play does something different depending on which app you're actually in - the button, the interface, stays consistent, but the underlying behavior varies by the actual object receiving the call.

List<Employee> staff = new List<Employee>
{
    new Employee { Name = "Alex" },
    new Manager  { Name = "Priya" }
};

foreach (var person in staff)
{
    person.Work();
    // Alex is working        (Employee's own Work())
    // Priya is managing the team  (Manager's OVERRIDDEN Work())
}
// Same method call - person.Work() - genuinely different
// behavior depending on the ACTUAL runtime type, decided
// automatically, without any if/else checking "what type
// is this" anywhere in this loop

Think of abstraction as ordering coffee at a counter. You say "one latte" - you don't need to know which specific brewing process, grinder settings, or milk steaming technique happens behind the counter. The complexity is abstracted away behind a simple request.

public interface ICoffeeMachine
{
    void MakeCoffee(string type);
    // The CALLER only needs this simple contract -
    // not the actual grinding, heating, and brewing
    // steps happening underneath
}

public class EspressoMachine : ICoffeeMachine
{
    public void MakeCoffee(string type)
    {
        GrindBeans();
        HeatWater();
        Brew();
        Console.WriteLine($"{type} ready");
    }

    private void GrindBeans() { }
    private void HeatWater() { }
    private void Brew() { }
    // These private methods are the hidden complexity -
    // completely invisible to whoever just calls MakeCoffee()
}

Practice question: Design a small class hierarchy for Shape, Circle, and Rectangle that demonstrates all four pillars - identify specifically which part of your design represents each one.

Topic 14: Lambda Expressions

A lambda expression is a concise, inline, unnamed function - syntactic shorthand for creating a delegate without formally declaring a named method first. Every LINQ call used throughout this post, Where(p => p.IsPublished), is a lambda expression, assigned to a delegate parameter behind the scenes.

Think of a sticky note with a quick instruction, used once exactly where needed, versus writing a full recipe card with a name that gets filed away for reuse later. A lambda is the sticky note - defined and used immediately, inline, with no separate named method cluttering the class.

// A regular named method
bool IsPublished(Post post)
{
    return post.IsPublished == true;
}

// The EXACT same logic as a lambda expression
Func<Post, bool> isPublished = post => post.IsPublished == true;

// Lambda syntax variations
x => x * 2;                    // expression lambda, single expression
x => { return x * 2; };        // statement lambda, needs braces + return
() => DateTime.UtcNow;          // no parameters
(x, y) => x + y;                // multiple parameters
(int x, int y) => x + y;        // explicit parameter types

// Where lambdas actually show up constantly
var published = posts.Where(p => p.IsPublished);
var titles = posts.Select(p => p.Title);
var sorted = posts.OrderByDescending(p => p.CreatedAt);

// Captured variables - a lambda can use variables
// from its surrounding scope, called a CLOSURE
string techFilter = "Azure";
var azurePosts = posts.Where(p => p.Tech == techFilter);
// the lambda "remembers" techFilter even if it were
// captured from a method that has already returned

// The classic closure-in-a-loop mistake
var actions = new List<Action>();
for (int i = 0; i < 3; i++)
{
    int captured = i;  // capture a COPY, not the loop variable
    actions.Add(() => Console.WriteLine(captured));
}
// Without "int captured = i", every lambda would capture
// the SAME shared loop variable, and all three would
// print the SAME final value instead of 0, 1, 2

Practice question: Write a lambda expression assigned to a Func that returns true if the first number is divisible by the second. Then explain, in your own words, why a lambda expression is really just a delegate with shorter syntax.

Key Lessons

LINQ queries use deferred execution - they run when iterated or materialized, ToList or Count, not when defined, which explains a lot of "unexpected" behavior around data changing mid-query.

IQueryable lets filtering happen at the source, SQL for EF Core, while IEnumerable means the data is already loaded and filtering happens in memory - calling ToList() too early is a genuine, common performance mistake.

Generic constraints - where T : class, new(), IComparable - are what let you safely call specific operations inside a generic method.

Garbage collection uses generations - short-lived objects, Generation 0, are collected cheaply and often; long-lived objects, Generation 2, rarely and expensively - IDisposable with using gives deterministic cleanup for unmanaged resources.

Overriding Equals() without GetHashCode() breaks Dictionary and HashSet lookups silently - the two must stay consistent.

Boxing has a real, measurable cost - generic collections like List avoid it entirely, which is a genuine reason to prefer them over legacy non-generic collections.

Encapsulation, Inheritance, Polymorphism, and Abstraction are the four pillars underneath every class design decision in C# - interview design questions are frequently just these four pillars in disguise.

A lambda expression is shorthand syntax for a delegate - every LINQ call throughout this entire series has quietly been a lambda the whole time.

What's Next

Part 3 covers advanced concepts - async/await and Task in depth, Task.WhenAll and Task.WhenAny, CancellationToken, ConcurrentDictionary and thread-safe collections, reflection, and memory and performance considerations.

Summary

These mid-level concepts are where C# knowledge genuinely starts to separate candidates in interviews, not because they're obscure, but because they require understanding the mechanism underneath, not just the syntax on top. LINQ's deferred execution, the IEnumerable and IQueryable split, generic constraints, garbage collection generations, and correct equality overrides all reward the same kind of thinking: knowing not just what a line of code does, but when it actually runs and why.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=csharp-interview-prep-midlevel-part2

Part 1 of this series (Basics): https://www.techstackblog.com/post.html?slug=csharp-interview-prep-basics-part1

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

C# Coding Interview Prep Part 1: Variables, Strings, Arrays, Lists, Dictionaries, and Every Basic Building Block

Manohari Jayachandran — Wed, 12 Aug 2026 13:15:07 +0000

This is a refresher built while preparing for C# coding interviews, and shared as a resource, because a genuinely comprehensive, practice-oriented guide is hard to find in one place. This series doesn't skip the basics to get to the "interesting" parts - the basics are exactly what trips people up under interview pressure, when a simple question about arrays suddenly requires recalling details nobody thinks about in day-to-day coding. Every topic in this series follows the same format: a plain-English explanation, an analogy, a code example, and a practice question at the end, so this can genuinely be used to test yourself, not just read passively.

This is Part 1 of three. Part 1 covers the _basics _- variables, data types, strings, arrays, List, Dictionary, HashSet, tuples, value vs reference types, operators, control flow, loops, methods, enums, structs vs classes, nullable types, type conversion, and basic exception handling. Part 2 covers mid-level concepts - LINQ, generics, delegates and events, interfaces vs abstract classes, and exception handling in depth. Part 3 covers _advanced _concepts - async and Task, reflection, memory management and garbage collection, design patterns in practice, and performance considerations.

Topic 1: Variables and Data Types

A variable is a named storage location holding a value of a specific type. C# is statically typed - once a variable is declared with a type, it can only ever hold values of that type, or something compatible with it.

Think of a labeled storage box. A box labeled "int" can only hold integers - trying to put a sentence in it doesn't work, the same way a shoebox labeled for shoes doesn't neatly fit a stack of books.

// Value types - the actual data lives directly
// in the variable
int age = 30;
double price = 19.99;
bool isPublished = true;
char grade = 'A';
decimal exactMoney = 19.99m;  // decimal for money -
                               // no floating point
                               // rounding errors

// var - the compiler infers the type at compile
// time, this is still statically typed, NOT dynamic
var name = "Alex";  // compiler infers string

// Reference types - the variable holds a reference
// (address) to where the actual data lives
string title = "C# Basics";
int[] numbers = { 1, 2, 3 };
Post post = new Post();

// Constants - value is fixed at compile time,
// cannot ever change
const double Pi = 3.14159;

// Nullable value types - value types normally
// cannot be null, this opts in
int? nullableAge = null;

Practice question: What is the difference between const and readonly in C#? Write one example of each.

Topic 2: Strings and String Methods

A string is a sequence of characters, and in C# it's a reference type - but with a critical twist: strings are immutable. Once created, a string's actual content in memory never changes. Every operation that appears to modify a string actually creates a brand new string.

Think of a printed book page. You cannot erase and rewrite a word on a printed page - if you want different text, you print an entirely new page. Modifying a string works the same way: the old string still exists in memory until garbage collected, and a new one is created for the result.

string greeting = "Hello";
string name = "Manohari";

// Concatenation - creates a NEW string, does not
// modify 'greeting'
string message = greeting + ", " + name;

// String interpolation - cleaner syntax, same result
string message2 = $"{greeting}, {name}";

// Common string methods
string text = "  C# Interview Prep  ";
Console.WriteLine(text.Trim());           // "C# Interview Prep"
Console.WriteLine(text.ToUpper());        // "  C# INTERVIEW PREP  "
Console.WriteLine(text.Contains("Prep")); // true
Console.WriteLine(text.Replace("C#", "CSharp"));
Console.WriteLine(text.Split(' ').Length);
Console.WriteLine(text.Substring(2, 4));  // extracts a portion
Console.WriteLine(text.IndexOf("Prep"));  // position found at

// String comparison - == checks VALUE equality
// for strings specifically (special-cased), not
// reference equality
string a = "hello";
string b = "hello";
Console.WriteLine(a == b);         // true - value equality
Console.WriteLine(a.Equals(b));    // true - same result

// StringBuilder - for heavy concatenation, avoid
// creating thousands of throwaway strings in a loop
var sb = new StringBuilder();
for (int i = 0; i < 1000; i++)
{
    sb.Append(i).Append(", ");
}
string result = sb.ToString();

Practice question: Write a method that reverses a string without using any built-in reverse method.

Topic 3: Arrays

An array is a fixed-size, ordered collection of elements of the same type. The size is set at creation and cannot change afterward - to "resize," a new array must be created and the old data copied over.

Think of a row of numbered parking spaces painted onto pavement. The number of spaces is fixed the moment the lot is built - adding more spaces means literally repaving with a new, larger layout, not just adding to the existing one.

// Declaration and initialization
int[] numbers = { 1, 2, 3, 4, 5 };
string[] names = new string[3];  // size 3, all null initially
names[0] = "Alex";
names[1] = "Priya";
names[2] = "Sam";

// Accessing and modifying
Console.WriteLine(numbers[0]);   // 1
numbers[0] = 100;                // arrays ARE mutable in
                                  // content, just fixed size

// Iterating
foreach (var n in numbers)
{
    Console.WriteLine(n);
}

// Multi-dimensional array
int[,] grid = new int[3, 3];
grid[0, 0] = 1;
grid[1, 1] = 5;

// Jagged array - array of arrays, each inner
// array can be a different length
int[][] jagged = new int[3][];
jagged[0] = new int[] { 1, 2 };
jagged[1] = new int[] { 1, 2, 3, 4 };

// Common Array methods
Array.Sort(numbers);
Array.Reverse(numbers);
int index = Array.IndexOf(numbers, 100);
bool found = Array.Exists(numbers, n => n > 50);

Practice question: Given an integer array, write a method that finds the second largest number without sorting the entire array.

Topic 4: List

List is a resizable, ordered collection - the generic, flexible alternative to a fixed-size array. Internally it's backed by an array that gets replaced with a larger one automatically as items are added beyond current capacity.

Think of an expandable file folder versus a fixed shoebox. As more documents come in, the expandable folder just grows - you never have to buy a new one and manually move everything over, even though internally that's conceptually similar to what List does behind the scenes automatically.

var posts = new List<string>();

posts.Add("First Post");
posts.Add("Second Post");
posts.Insert(0, "Inserted at start");

posts.Remove("First Post");     // removes by value
posts.RemoveAt(0);               // removes by index

bool exists = posts.Contains("Second Post");
int index = posts.IndexOf("Second Post");

Console.WriteLine(posts.Count);  // current item count

// Iterating
foreach (var post in posts)
{
    Console.WriteLine(post);
}

// Converting between List and Array
int[] array = { 1, 2, 3 };
List<int> fromArray = array.ToList();
int[] backToArray = fromArray.ToArray();

// Sorting and searching
var numbers = new List<int> { 5, 2, 8, 1 };
numbers.Sort();
numbers.Sort((a, b) => b.CompareTo(a));  // descending,
                                            // custom comparer

Practice question: Write a method that removes all duplicate values from a List while preserving the original order.

Topic 5: Dictionary

A Dictionary stores key-value pairs and provides fast, close-to-O(1) lookup by key, using a hash table internally. Every key must be unique.

Think of a labeled filing cabinet drawer system, where every drawer has exactly one unique name on it. Finding "the invoices drawer" doesn't require checking every drawer one by one - you go directly to the one labeled correctly.

var postsBySlug = new Dictionary<string, string>();

postsBySlug["csharp-basics"] = "C# Basics Post";
postsBySlug["csharp-linq"] = "LINQ Deep Dive";

// Safe lookup - does not throw if key is missing
if (postsBySlug.TryGetValue("csharp-basics", out var title))
{
    Console.WriteLine(title);
}

// Direct access - throws KeyNotFoundException if missing
string result = postsBySlug["csharp-basics"];

bool hasKey = postsBySlug.ContainsKey("csharp-linq");
postsBySlug.Remove("csharp-linq");

// Iterating - gives KeyValuePair<TKey,TValue>
foreach (var kvp in postsBySlug)
{
    Console.WriteLine($"{kvp.Key}: {kvp.Value}");
}

// Just keys or just values
foreach (var key in postsBySlug.Keys) { }
foreach (var value in postsBySlug.Values) { }

// Update or add in one call
postsBySlug["csharp-basics"] = "Updated Title";  // overwrites

Practice question: Given an array of words, write a method using a Dictionary that counts how many times each word appears.

Topic 6: HashSet

A HashSet stores unique values only, with no guaranteed order, and provides fast O(1) average lookup for "does this exist" checks - much faster than checking a List with Contains for large collections.

Think of a guest list at the door of an event, where a bouncer just needs to answer "is this name already checked in" as fast as possible - not caring about the order names were added, just whether a given name is present at all.

var uniqueTags = new HashSet<string>();

uniqueTags.Add("Azure");
uniqueTags.Add("C#");
uniqueTags.Add("Azure");  // silently ignored - duplicate

Console.WriteLine(uniqueTags.Count);  // 2

bool hasAzure = uniqueTags.Contains("Azure");  // O(1) check

// Set operations
var setA = new HashSet<int> { 1, 2, 3, 4 };
var setB = new HashSet<int> { 3, 4, 5, 6 };

setA.IntersectWith(setB);  // setA becomes {3, 4}
// UnionWith, ExceptWith also available

Practice question: Given two integer arrays, write a method that returns only the numbers that appear in both arrays, using a HashSet.

Topic 7: Tuples

A tuple bundles multiple values together into one object without needing to define a custom class. Modern C# tuples support named elements, making them readable at the point of use.

Think of a small labeled tray carrying a few different items together - a tray with "coffee" and "muffin" compartments lets you carry both at once without needing a whole custom carrying case built just for that specific combination.

// Named tuple
(string Name, int Age) person = ("Alex", 30);
Console.WriteLine(person.Name);  // "Alex"
Console.WriteLine(person.Age);   // 30

// Returning multiple values from a method
(int Min, int Max) FindMinMax(int[] numbers)
{
    return (numbers.Min(), numbers.Max());
}

var result = FindMinMax(new[] { 5, 2, 8, 1 });
Console.WriteLine($"Min: {result.Min}, Max: {result.Max}");

// Deconstruction
var (min, max) = FindMinMax(new[] { 5, 2, 8, 1 });
Console.WriteLine(min);
Console.WriteLine(max);

// Tuple vs custom class - when to use which
// Tuple: quick, internal, 2-3 short-lived values
// Class: the shape has real meaning, gets passed
// around broadly, or needs its own behavior/methods

Practice question: Write a method that takes a list of numbers and returns a tuple containing the sum, average, and count in one call.

Topic 8: Value Types vs Reference Types

This is one of the most frequently tested distinctions in C# interviews. Value types - int, bool, double, struct - store their actual data directly in the variable. Reference types - class, array, string, List, Dictionary - store a reference, a memory address, to where the actual data lives on the heap. The variable itself just holds that address.

Think of a value type as writing a number directly on a sticky note - the note is the data. A reference type is like writing a house address on a sticky note - the note points to where the actual house is, and copying the note just copies the address, not the house itself.

// Value type - assignment COPIES the actual value
int a = 5;
int b = a;   // b gets its OWN copy of 5
b = 10;
Console.WriteLine(a);  // still 5 - a was never touched

// Reference type - assignment copies the REFERENCE,
// both variables point to the SAME object
var list1 = new List<int> { 1, 2, 3 };
var list2 = list1;   // list2 points to the SAME list
list2.Add(4);
Console.WriteLine(list1.Count);  // 4 - list1 sees the
                                   // change too, because
                                   // it's the same object

// Passing to methods - same rule applies
void ModifyValue(int x) { x = 100; }
void ModifyReference(List<int> list) { list.Add(999); }

int number = 5;
ModifyValue(number);
Console.WriteLine(number);  // still 5

var myList = new List<int> { 1, 2 };
ModifyReference(myList);
Console.WriteLine(myList.Count);  // 3 - the SAME list
                                    // object was modified

// string is a special case - reference type, but
// immutable, so it BEHAVES like a value type in
// most practical situations
string s1 = "hello";
string s2 = s1;
s2 = s2 + " world";  // creates a NEW string for s2
Console.WriteLine(s1);  // still "hello" - unaffected

Practice question: Without running the code, predict the output: create a struct Point with a public int X, create var p1 = new Point with X set to 1, assign var p2 = p1, then set p2.X to 99. What is p1.X afterward, and why?

Topic 9: Operators

Operators perform operations on values - arithmetic, comparison, logical, and a few special ones worth knowing well for interviews specifically.

// Arithmetic
int sum = 5 + 3;
int remainder = 10 % 3;   // modulo - remainder after division

// Comparison
bool isEqual = (5 == 5);
bool isGreater = (5 > 3);

// Logical
bool result = true && false;   // AND
bool result2 = true || false;  // OR
bool result3 = !true;           // NOT

// Null-coalescing - returns left if not null,
// otherwise returns right
string name = null;
string display = name ?? "Unknown";  // "Unknown"

// Null-conditional - safely accesses a member,
// returns null instead of throwing if the object
// itself is null
Post post = null;
string title = post?.Title;  // null, no exception thrown

// Null-coalescing assignment
string cachedValue = null;
cachedValue ??= "default";  // assigns only if currently null

// Ternary conditional
int age = 20;
string category = age >= 18 ? "Adult" : "Minor";

// Increment/decrement
int count = 0;
count++;      // post-increment
++count;      // pre-increment - subtle difference in
              // expressions, same end result standalone

Practice question: What is the difference between x++ and ++x when used inside a larger expression, like int y = x++ + 1 versus int y = ++x + 1? Write out what each assigns to x and y given x starts at 5.

Topic 10: Control Flow - if, else, switch

Control flow statements decide which code actually runs based on conditions.

int score = 85;

// if / else if / else
if (score >= 90)
{
    Console.WriteLine("A");
}
else if (score >= 80)
{
    Console.WriteLine("B");
}
else
{
    Console.WriteLine("C or below");
}

// switch statement
string grade;
switch (true)
{
    case bool _ when score >= 90:
        grade = "A";
        break;
    case bool _ when score >= 80:
        grade = "B";
        break;
    default:
        grade = "C or below";
        break;
}

// switch expression (modern C#, more concise)
string grade2 = score switch
{
    >= 90 => "A",
    >= 80 => "B",
    _ => "C or below"
};

// Pattern matching in switch
object value = 42;
string description = value switch
{
    int i when i > 0 => "positive integer",
    int i when i < 0 => "negative integer",
    string s => $"a string: {s}",
    null => "null value",
    _ => "something else"
};

Practice question: Write a method using a switch expression that takes an integer representing a day of the week (1-7) and returns whether it's a "Weekday" or "Weekend".

Topic 11: Loops

Loops repeat a block of code, either a fixed number of times, while a condition holds, or once per element in a collection.

// for loop - when you know the iteration count
// or need the index
for (int i = 0; i < 5; i++)
{
    Console.WriteLine(i);
}

// while loop - condition checked BEFORE each iteration
int count = 0;
while (count < 5)
{
    Console.WriteLine(count);
    count++;
}

// do-while - condition checked AFTER each iteration,
// so the body ALWAYS runs at least once
int x = 10;
do
{
    Console.WriteLine(x);
    x++;
} while (x < 5);  // runs once even though condition
                    // is false from the start

// foreach - iterates every element in a collection,
// no manual index management
var posts = new List<string> { "A", "B", "C" };
foreach (var post in posts)
{
    Console.WriteLine(post);
}

// break and continue
for (int i = 0; i < 10; i++)
{
    if (i == 3) continue;  // skip this iteration
    if (i == 7) break;     // exit the loop entirely
    Console.WriteLine(i);
}

Practice question: Write a program using a loop that prints the Fibonacci sequence up to the 10th number.

Topic 12: Methods and Parameters

A method is a named, reusable block of code. Parameters pass data into a method; a return type defines what comes back out.

// Basic method
int Add(int a, int b)
{
    return a + b;
}

// Optional parameters - must come after required ones
void Greet(string name, string greeting = "Hello")
{
    Console.WriteLine($"{greeting}, {name}");
}
Greet("Alex");               // uses default "Hello"
Greet("Alex", "Hi");         // overrides default

// Named arguments - can be passed in any order
Greet(greeting: "Hey", name: "Alex");

// params - accepts a variable number of arguments
int Sum(params int[] numbers)
{
    int total = 0;
    foreach (var n in numbers) total += n;
    return total;
}
Sum(1, 2, 3);        // works
Sum(1, 2, 3, 4, 5);  // also works, any count

// ref - passes by REFERENCE, method can modify
// the caller's actual variable
void Double(ref int number)
{
    number = number * 2;
}
int value = 5;
Double(ref value);
Console.WriteLine(value);  // 10 - actually changed

// out - similar to ref, but the method MUST assign
// a value before returning, commonly used for
// "try" pattern methods
bool TryParse(string input, out int result)
{
    return int.TryParse(input, out result);
}

// Method overloading - same name, different
// parameter signatures
int Multiply(int a, int b) => a * b;
double Multiply(double a, double b) => a * b;

Practice question: What is the actual difference between ref and out parameters? Write a method using each that demonstrates the difference.

Topic 13: Enums

An enum defines a named set of related constant values, making code more readable than using raw numbers or strings for a fixed set of options.

public enum OrderStatus
{
    Pending,     // 0 by default
    Processing,  // 1
    Shipped,     // 2
    Delivered    // 3
}

var status = OrderStatus.Processing;
Console.WriteLine(status);          // "Processing"
Console.WriteLine((int)status);      // 1

// Assigning explicit values
public enum HttpStatusCode
{
    Ok = 200,
    NotFound = 404,
    ServerError = 500
}

// Converting from an int
var code = (HttpStatusCode)404;
Console.WriteLine(code);  // NotFound

// Parsing from a string
var parsed = Enum.Parse<OrderStatus>("Shipped");

// Switching on an enum
string GetMessage(OrderStatus status) => status switch
{
    OrderStatus.Pending => "Order received",
    OrderStatus.Shipped => "On its way",
    OrderStatus.Delivered => "Completed",
    _ => "Unknown status"
};

Practice question: Create an enum for days of the week, and write a method that returns true if a given day is a weekend.

Topic 14: Structs vs Classes

Both structs and classes group related data and behavior together, but a struct is a value type, copied on assignment, while a class is a reference type, shared on assignment - the same fundamental distinction as value types versus reference types, applied to your own custom types.

// struct - value type, typically small, simple data
public struct Point
{
    public int X;
    public int Y;
}

var p1 = new Point { X = 1, Y = 2 };
var p2 = p1;       // COPIES the values
p2.X = 99;
Console.WriteLine(p1.X);  // still 1 - p1 untouched

// class - reference type, typically larger objects
// with behavior, identity, and mutable state over time
public class Post
{
    public string Title;
    public int ViewCount;
}

var post1 = new Post { Title = "Hello", ViewCount = 0 };
var post2 = post1;  // SHARES the same object
post2.ViewCount = 5;
Console.WriteLine(post1.ViewCount);  // 5 - same object

Use a struct for small, immutable-feeling data with no real identity - a Point, a Color, a Money amount. Use a class for anything with real identity, larger data, or behavior that changes over the object's lifetime - a Post, a Customer, a Service. Most day-to-day domain modeling uses classes; structs are the exception, reached for deliberately.

Practice question: Explain why using a struct for a large object with 15 fields would generally be a bad idea, based on what you know about value type copying.

Topic 15: Nullable Types

Value types - int, bool, DateTime - cannot normally hold null; they always have some default value. Nullable value types, written as int?, opt into allowing null, useful for representing "no value provided" distinctly from an actual zero or false.

int? age = null;
int regularAge = 0;  // 0 is a real value,
                       // different from "no value"

if (age.HasValue)
{
    Console.WriteLine(age.Value);
}

// GetValueOrDefault - safe access with a fallback
int actualAge = age.GetValueOrDefault(18);

// Null-coalescing works here too
int displayAge = age ?? 18;

// Nullable reference types (C# 8+) - a compiler
// feature (not a runtime type change) that WARNS
// when a reference type that should never be null
// might actually be null
string? nullableName = null;   // explicitly allowed
string nonNullableName = "Alex"; // compiler warns if
                                   // this is ever assigned
                                   // null somewhere

Practice question: Why might a nullable int? be a better choice than a regular int for a "discount percentage" field on an order, where most orders have no discount at all?

Topic 16: Type Conversion and Casting

Converting a value from one type to another - sometimes safe and implicit, sometimes requiring an explicit cast, and sometimes needing a parsing method entirely.

// Implicit conversion - safe, no data loss possible,
// compiler does it automatically
int number = 100;
double asDouble = number;  // int fits safely into double

// Explicit conversion (casting) - REQUIRED when data
// loss is possible, forces you to acknowledge the risk
double price = 19.99;
int roundedDown = (int)price;  // 19 - truncates,
                                 // does not round

// Parsing strings to numbers
string input = "42";
int parsed = int.Parse(input);        // throws if invalid
bool success = int.TryParse(input, out int result);
                                        // safe, returns
                                        // false instead of
                                        // throwing

// Convert class - handles more conversions, including
// null handling
string text = Convert.ToString(42);
int fromString = Convert.ToInt32("42");

// as vs cast for reference types
object obj = "hello";
string s1 = (string)obj;      // throws if obj isn't
                                // actually a string
string s2 = obj as string;    // returns null instead
                                // of throwing if it fails

// is keyword with pattern matching
if (obj is string str)
{
    Console.WriteLine(str.Length);
}

Practice question: What is the actual difference between int.Parse() and int.TryParse()? When would you genuinely prefer one over the other?

Topic 17: Basic Exception Handling

Exceptions represent errors that occur during execution. try/catch lets code handle an error gracefully instead of crashing the entire program.

try
{
    int result = 10 / int.Parse("0");
}
catch (DivideByZeroException ex)
{
    Console.WriteLine($"Cannot divide by zero: {ex.Message}");
}
catch (FormatException ex)
{
    Console.WriteLine($"Invalid number format: {ex.Message}");
}
catch (Exception ex)
{
    // Generic catch-all - should be LAST, since more
    // specific catches above it would never be reached
    // if this came first
    Console.WriteLine($"Unexpected error: {ex.Message}");
}
finally
{
    // ALWAYS runs, whether an exception occurred or not -
    // used for cleanup (closing files, connections, etc.)
    Console.WriteLine("Cleanup runs here regardless");
}

// Throwing your own exceptions
void ValidateAge(int age)
{
    if (age < 0)
    {
        throw new ArgumentException("Age cannot be negative", nameof(age));
    }
}

// Custom exception types
public class InsufficientFundsException : Exception
{
    public InsufficientFundsException(string message) : base(message) { }
}

Practice question: Write a method that safely divides two numbers, catching a divide-by-zero error and returning 0 instead of letting the exception propagate.

Key Lessons

Value types copy on assignment; reference types share the same underlying object - this single distinction explains a huge share of "unexpected" C# behavior.

Arrays are fixed size; List resizes automatically - default to List unless the size is genuinely fixed and known.

Dictionary gives fast key-based lookup; HashSet gives fast existence checks with no duplicates.

Strings are immutable - every apparent modification creates a new string, which is exactly why StringBuilder exists for heavy concatenation.

ref and out both pass by reference, but out requires the method to assign a value before returning, commonly used in the TryParse pattern.

Structs and classes mirror the value versus reference type distinction for your own custom types - most everyday modeling uses classes.

What's Next

Part 2 covers mid-level concepts - LINQ, generics, delegates and events, interfaces versus abstract classes, and exception handling in real depth.

Summary

Every C# codebase, no matter how advanced, is built from these same basic pieces - variables and types, strings, collections, control flow, methods, and basic error handling. Interview questions on these topics aren't testing whether you've memorized syntax - they're testing whether the underlying model, value versus reference, mutable versus immutable, fixed versus resizable, is genuinely internalized, since that's what actually predicts whether unfamiliar code will behave the way you expect it to.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=csharp-interview-prep-basics-part1

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Authentication vs Authorization: Basic Auth, Sessions, OAuth, OIDC, JWT, SSO, and RBAC vs ABAC Explained

Manohari Jayachandran — Fri, 07 Aug 2026 21:50:04 +0000

Authentication and authorization get used almost interchangeably in casual conversation, and confused constantly in interviews, despite being genuinely different questions with different mechanisms answering each one. This post draws that line clearly first, then covers every major method under each - Basic Auth, Sessions, OAuth, OAuth 2.0, OpenID Connect, JWT, SSO, and how authorization decisions actually get made via RBAC and ABAC - with analogies, real examples, and how each one shows up in Azure specifically.

The One-Sentence Distinction

Authentication proves who you are. Authorization proves what you're allowed to do. These are checked separately, even when they happen back to back. A user can be fully, successfully authenticated and still get a 403 Forbidden trying to access something they're not authorized for.

Think of a concert venue. Showing your ticket at the door proves you're a legitimate attendee - that's authentication. Once inside, your wristband color determines whether you can access the VIP lounge or only the general floor - that's authorization. Having a valid ticket says nothing about which areas you're allowed into - those are two separate checks, at two separate points, even though they happen close together.

Basic Auth: The Oldest, Simplest Method

Basic Auth combines a username and password, base64-encodes them together, and sends the result in the Authorization header on every single request.

-- The credentials "alex:mypassword" become:
Authorization: Basic YWxleDpteXBhc3N3b3Jk

-- Base64 is ENCODING, not ENCRYPTION - it is
-- trivially reversible by anyone who intercepts it.
-- This ONLY becomes safe over HTTPS, where the
-- transport layer itself is encrypted.

Think of writing your password on a postcard instead of sealing it in an envelope. Base64 makes it slightly less immediately readable at a glance, but anyone who actually picks it up can read it in seconds. HTTPS is the sealed, tamper-evident courier bag around that postcard - without it, Basic Auth is genuinely dangerous.

Basic Auth still shows up in internal tooling, simple server-to-server calls behind a firewall, or as a stopgap for low-risk endpoints. It's rarely appropriate for anything user-facing or handling sensitive data, since credentials are resent on every single request rather than exchanged once for a limited-scope token.

A Quick, Clarification: API Keys vs Basic Auth vs Subscription Keys

These three terms get used almost interchangeably in casual conversation, but they're not quite the same thing, and mixing them up causes real confusion in practice.

Basic Auth is a username and password, base64-encoded, sent every request, as covered above. An API key is a single opaque string with no username involved, usually sent as a header or query parameter, identifying which application or account is calling, not a specific human user. A subscription key, specifically in Azure API Management, is a particular flavor of API key scoped to a Product, covered in an earlier post on this blog about APIM - it answers which subscription plan a caller is on, not who the caller is.

None of these three actually prove identity in any strong sense - they prove possession of a credential, whether a password, a key, or a subscription key. This is exactly why real production systems frequently combine one of these with OAuth2/OIDC - the API key or subscription key controls access tier and rate limits, while the OAuth token establishes actual, verifiable identity. This same layered pattern was covered concretely in an earlier post on this blog about Azure APIM, where a subscription key and an OAuth token are validated together, answering two different questions in the same request.

Session-Based Authentication: The Server Remembers You

In session-based authentication, a user logs in once with credentials, the server creates a session and stores its state server-side, then gives the browser a session ID, usually via a cookie, to present on every subsequent request instead of re-sending credentials each time.

A login request verifies credentials and creates a session, stored in memory, a database, or a cache like Redis, and returns a Set-Cookie header containing something like sessionId=abc123. Every future request automatically includes that cookie. The server looks up "abc123" in its session store, finds the associated user, and knows who's making the request without re-checking a password every time.

Think of a coat check at a restaurant. Handing over your coat once, logging in, gets you a numbered ticket. Presenting that ticket, the session ID, for the rest of the evening retrieves your coat without needing to re-prove ownership each time - the coat check itself, the server, is what's actually holding onto the state.

The real limitation is that because the server holds the actual session state, scaling horizontally across multiple servers requires that every server can access the same shared session store. A server that doesn't have "abc123" in its own memory can't recognize that session unless the store is centralized, like Redis, or the session is somehow shared across instances. This is a genuine architectural constraint sessions introduce that token-based approaches largely avoid.

OAuth vs OAuth 2.0: Not the Same Protocol

The distinction people miss most often: "OAuth" without a version number technically refers to OAuth 1.0, an older protocol that required cryptographically signing every single request - genuinely painful to implement correctly. OAuth 2.0 is a substantially different, simpler protocol built around bearer tokens sent over HTTPS instead of signed requests. When anyone says "OAuth" today without qualification, they almost always mean OAuth 2.0 - OAuth 1.0 is effectively extinct in modern development.

OAuth 1.0 required every request to be cryptographically signed using a shared secret, complex to implement correctly, with no built-in token expiration concept. OAuth 2.0, what "OAuth" means today, uses bearer tokens - "whoever holds this token is authorized" - sent over HTTPS, with a built-in concept of token expiration and refresh, and multiple grant types for different scenarios, including client credentials and authorization code flows.

OAuth 2.0 is fundamentally a framework for delegated authorization - letting one application access resources on behalf of a user, or another system, without ever handling that user's actual password. An earlier post on this blog covered the mechanics of this in detail: Client Credentials Flow for service-to-service scenarios, Authorization Code Flow for real user logins, access tokens, and refresh tokens.

OpenID Connect (OIDC): The Piece That Makes OAuth2 Usable for Login

OAuth 2.0, by itself, is an authorization framework - it's designed to grant an application access to a resource, not to prove who a user is. A raw OAuth2 access token technically doesn't guarantee anything about identity; it only proves the holder was granted some scope of access. This is a genuinely common point of confusion - "Sign in with Google" and "Sign in with Microsoft" buttons are commonly described as using OAuth, but strictly speaking, they're using OpenID Connect, a layer built directly on top of OAuth 2.0 specifically to add authentication.

OAuth 2.0 alone answers whether an application is allowed to access a resource on the user's behalf. It does not reliably answer who the user is, specifically. OpenID Connect adds a standardized identity layer on top of OAuth 2.0's existing authorization flow, introducing the ID token - a JWT specifically containing identity claims like name, email, and a unique user ID - distinct from the access token.

Where OAuth2 alone issues an access token for calling APIs, OIDC additionally issues an ID token, a JWT whose entire purpose is describing who the user is, not what they can access. Both tokens are often returned together in the same OIDC flow, but they answer different questions and are used differently: the access token gets sent to APIs to prove authorization, while the ID token gets read by the application itself to know who just logged in.

{
  "access_token": "eyJhbGciOiJ...",
  "id_token": "eyJhbGciOiJ...",
  "token_type": "Bearer",
  "expires_in": 3600
}

The decoded ID token payload carries identity claims rather than authorization scopes:

{
  "sub": "a1b2c3d4",
  "name": "Manohari Jayachandran",
  "email": "user@example.com",
  "iss": "https://login.microsoftonline.com/...",
  "aud": "your-app-client-id",
  "exp": 1719399600
}

The one-sentence summary worth remembering: OAuth 2.0 answers whether an app is allowed to do something - it's authorization. OpenID Connect adds who the user doing it actually is - it's authentication, layered on top of OAuth2's existing machinery rather than replacing it. This is exactly why "Sign in with Google" or "Sign in with Microsoft" buttons work the way they do - they're OIDC flows, using OAuth2 underneath to handle the actual token exchange.

JWT: A Token Format, Not an Authentication Method

The distinction that trips people up in interviews most often: JWT, JSON Web Token, is not itself a way of authenticating anyone. It's a specific, structured format that a token can take. OAuth 2.0 is commonly used to issue a JWT as the resulting access token, but OAuth2 and JWT are answering different questions - OAuth2 is the protocol for how a token gets issued and exchanged; JWT is simply the shape that token happens to be in.

A JWT has three parts, separated by dots - header, payload, and signature. This is the same structure covered in more depth in an earlier post on this blog about OAuth token flows: the header names the signing algorithm, the payload carries claims about who issued it, who it's for, when it expires, and what scopes or roles it grants, and the signature cryptographically proves the token hasn't been tampered with.

Critically, a JWT is signed, not encrypted. Anyone holding the token can read every claim inside it, even without the ability to forge a new one. This is why sensitive data should never be placed directly in a JWT's payload.

Stated plainly: Basic Auth and Sessions are both complete authentication mechanisms on their own. OAuth2 is a framework for authorization and delegated access. JWT is neither of those - it's a data format that OAuth2, and other systems, commonly use to package the result of a successful authentication or authorization decision into something portable and independently verifiable.

SSO: Single Sign-On, Built on Top of What's Already Covered

Single Sign-On lets a user authenticate once, with one identity provider, and gain access to multiple separate applications without logging in again for each one. SSO is not a new authentication mechanism of its own - it's an architecture built on top of session-based auth and OpenID Connect, covered just above, applied across multiple applications instead of just one.

Think of a single hotel key card that opens the room, the gym, the pool area, and the parking garage - one check-in at the front desk, the identity provider, and every other door on the property recognizes that same card without asking for ID again. Without SSO, it would be like getting a separate, differently-shaped key for every single door, each requiring its own check-in process.

Without SSO, a user manages separate logins and separate passwords for every application, logging in repeatedly across each one. With SSO, the user logs into the Identity Provider once, and every application trusting that same Identity Provider recognizes the user's session or token without asking them to log in again.

Mechanically, the first application a user visits redirects them to a central Identity Provider if they aren't already authenticated. The user logs in once at the Identity Provider, which issues a token, commonly a JWT via OAuth2 or OpenID Connect, or sets a session with itself. When the user then visits a second application, that application also redirects to the same Identity Provider - but since the user already has a valid session or token from the first login, they're recognized immediately and redirected back, fully authenticated, without ever seeing a login form the second time.

Two protocols are commonly used to implement SSO. SAML, Security Assertion Markup Language, is older and XML-based, still common in large enterprise environments. OpenID Connect, built directly on top of OAuth 2.0, adds a standardized identity layer onto OAuth's authorization framework - this is the modern, most common way SSO is implemented today, and it's why OpenID Connect is often described as "OAuth2 plus authentication."

Azure AD, now Microsoft Entra ID, plays exactly this role across Microsoft 365, the Azure Portal, and any custom application registered against the same tenant - logging into one Microsoft-connected application means every other application trusting that same Azure AD tenant recognizes the session without a repeated login. This is the same Azure AD covered in an earlier post on this blog about OAuth token flows, now applied across multiple applications instead of just one.

How This Connects to Azure Specifically

The full picture ties together two earlier posts on this blog. Azure AD, now called Microsoft Entra ID, issues a token after verifying identity - this is authentication, using OAuth 2.0 as the protocol, covered in depth in an earlier post on Azure AD and OAuth token flows. That token is a JWT - the format, not the method. Azure API Management's validate-jwt policy checks the token's signature, expiry, issuer, and audience at the gateway, before the backend ever runs, covered in depth in an earlier post on Azure APIM. Claims inside that JWT, like app roles or scopes, determine what the caller is actually allowed to do once authenticated - checking those specific claims is authorization, layered on top of the authentication that already happened.

Where authentication ends and authorization begins in this Azure flow is worth being precise about. Azure AD verifying the caller's identity and issuing a valid, signed JWT is authentication - it answers who this is. APIM's validate-jwt policy checking that the token is genuinely valid, not expired, correctly signed, right audience, is still part of confirming the authentication is real. The moment a policy checks a specific claim, such as whether this token has the Orders.Read role, that's authorization - a separate question answered using data carried inside the already-authenticated token.

RBAC vs ABAC: How Authorization Decisions Actually Get Made

Everything above establishes who a caller is. This section covers how a system actually decides what that caller can do - the real mechanism behind checking whether a token has a specific role, mentioned just above.

Role-Based Access Control, RBAC, attaches permissions to roles, and users are assigned to one or more of those roles. An Admin role can read, write, and delete. An Editor role can read and write. A Viewer role can only read. A user's permissions are whatever their assigned role or roles grant - simple, predictable, and easy to reason about.

Think of a hospital ID badge. A badge marked Nurse opens certain doors and certain systems. A badge marked Doctor opens more. The badge doesn't know anything about the specific person wearing it beyond their assigned role - two different nurses with the same role badge get identical access, no matter how their individual situations might differ.

Attribute-Based Access Control, ABAC, decides permissions dynamically, based on a combination of attributes evaluated at the moment of the request, rather than a fixed role assignment. A rule might allow access to a patient record only if the requesting user's department matches the patient's assigned department, the request happens during business hours, and the record isn't flagged as restricted. The same user might be allowed access to one record and denied access to another, based on attributes of the specific resource and context, not a single fixed role.

Think of airport security screening. Whether a specific bag gets flagged for additional screening depends on a combination of factors evaluated in that specific moment - what's in the bag, which flight, current threat level, random selection - not a single fixed role the passenger was permanently assigned at check-in. The decision is made fresh, per situation, based on multiple attributes together.

RBAC fits when a permission structure is genuinely role-shaped - a manageable number of roles, each with a clear, fairly static set of permissions. ABAC fits when access decisions genuinely depend on context that changes per request - resource ownership, time, location, sensitivity level, or the relationship between the user and the specific resource. Many real systems use both together, a coarse RBAC layer for broad access tiers like Admin versus Standard User, with finer ABAC-style rules layered on top for specific sensitive resources.

This connects directly back to the Azure JWT example above: a role claim inside a JWT, like Orders.Read, being checked by APIM is RBAC in action - the caller was assigned that role, and the token carries proof of it. A more advanced setup might layer ABAC on top - even with a valid Orders.Read role, a specific policy might further restrict access based on which region the order belongs to, matching an attribute on the caller's own token against an attribute on the specific resource being requested.

Choosing the Right Approach

Basic Auth fits internal tooling, simple server-to-server calls behind a firewall, and low-risk scenarios only. Session-based auth fits traditional server-rendered web apps, where the server already controls the full request lifecycle and horizontal scaling isn't a primary concern. OAuth 2.0 combined with JWT fits APIs, single-page applications, mobile apps, service-to-service integration, and anything needing delegated access without sharing real passwords, or anything that needs to scale horizontally without shared server-side session state.

Key Lessons

Authentication proves identity; authorization proves permission - they're checked separately, and passing one doesn't guarantee passing the other.

API keys, subscription keys, and Basic Auth all prove possession of a credential, not identity - none of the three is a strong identity check on its own.

Basic Auth is simple but only safe over HTTPS, since base64 encoding is trivially reversible, not real encryption.

Session-based auth keeps state on the server, which is simple for single-server apps but requires a shared session store to scale horizontally.

OAuth and OAuth 2.0 are genuinely different protocols - OAuth 2.0 is what "OAuth" means today, using bearer tokens instead of OAuth 1.0's cryptographic request signing.

OAuth 2.0 alone only handles authorization - OpenID Connect is the layer built on top of it that adds real authentication, via a separate ID token distinct from the access token.

JWT is a token format, not an authentication method - OAuth2 is a common way to issue one, but the two answer different questions.

SSO is not a separate mechanism - it's session and OAuth concepts applied across multiple applications trusting one shared identity provider, commonly implemented today via OpenID Connect on top of OAuth 2.0.

In a real Azure setup, Azure AD handles authentication and issues a JWT, while claims inside that JWT, checked by APIM or the backend, handle authorization - two distinct steps using the same token.

RBAC assigns fixed permissions to roles, simple and predictable; ABAC decides access dynamically based on multiple attributes at request time - real systems often layer both together.

Summary

Authentication and authorization are two separate questions - who are you, and what are you allowed to do - answered by different mechanisms that often work together but are never the same check. Basic Auth and session-based authentication are complete, older methods of proving identity. OAuth 2.0 is a modern framework for delegated authorization, built around bearer tokens rather than OAuth 1.0's cryptographic signing. JWT is not a method at all - it's the structured format a token commonly takes, readable by anyone holding it but not forgeable without the signing key. Seeing how Azure AD, JWTs, and APIM's validation policy fit together, authentication first, authorization layered on top using claims inside the same token, is what turns these five terms from a list of buzzwords into a coherent system.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=authentication-vs-authorization-explained

Related reading on TechStack Blog:
Azure AD and OAuth Token Flows: https://www.techstackblog.com/post.html?slug=azure-ad-oauth-token-flows-explained
Azure API Management Part 1: https://www.techstackblog.com/post.html?slug=azure-apim-explained-part1

More from TechStack Blog: CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals
Azure: https://www.techstackblog.com/category.html?cat=azure

Azure API Management Part 2: A Complete CRUD API, Built and Deployed Behind APIM End to End

Manohari Jayachandran — Wed, 05 Aug 2026 16:31:04 +0000

Part 1 covered the concepts - what APIM is, the Product and API and Operation hierarchy, policies, subscription keys, OAuth validation, CORS, and rate limiting. This part builds something real: a complete CRUD API in ASP.NET Core, imported into APIM, wrapped in a Product, and secured with every policy from Part 1 actually applied and working - the full path from code to a production-shaped, secured API.

Step 1: Building a Minimal CRUD API

A small Notes API - Create, Read, Update, Delete - is enough to demonstrate every APIM concept without unnecessary complexity. Swagger and OpenAPI support are enabled from the start, since that's what makes importing into APIM trivial in the next step.

// Program.cs - minimal API style, ASP.NET Core

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();
app.UseSwagger();
app.UseSwaggerUI();

var notes = new List<Note>();

app.MapGet("/notes", () => notes);

app.MapGet("/notes/{id}", (int id) =>
{
    var note = notes.FirstOrDefault(n => n.Id == id);
    return note is not null ? Results.Ok(note) : Results.NotFound();
});

app.MapPost("/notes", (Note note) =>
{
    note.Id = notes.Count + 1;
    notes.Add(note);
    return Results.Created($"/notes/{note.Id}", note);
});

app.MapPut("/notes/{id}", (int id, Note updated) =>
{
    var note = notes.FirstOrDefault(n => n.Id == id);
    if (note is null) return Results.NotFound();
    note.Title = updated.Title;
    note.Content = updated.Content;
    return Results.Ok(note);
});

app.MapDelete("/notes/{id}", (int id) =>
{
    var note = notes.FirstOrDefault(n => n.Id == id);
    if (note is null) return Results.NotFound();
    notes.Remove(note);
    return Results.NoContent();
});

app.Run();

record Note
{
    public int Id { get; set; }
    public string Title { get; set; } = "";
    public string Content { get; set; } = "";
}

Deployed to an App Service, the same pattern covered when this blog's own API was set up, the Swagger UI at /swagger now serves a machine-readable OpenAPI spec at /swagger/v1/swagger.json - this file is what APIM will import directly in the next step.

Step 2: Importing the API Into APIM

In the Azure Portal, inside an existing APIM instance, the import flow starts at APIs, then Add API, then OpenAPI. Pasting the URL to the swagger.json file, or uploading it directly, along with a Display Name like "Notes API" and an API URL suffix like "notes," is enough for APIM to read the spec and automatically create every Operation - GET /notes, GET /notes/{id}, POST /notes, PUT /notes/{id}, and DELETE /notes/{id} - with their parameters already defined.

No manual operation-by-operation setup is required. This is the entire benefit of enabling Swagger and OpenAPI on the API itself before ever touching APIM - the import step becomes almost entirely automatic.

Step 3: Creating a Product and Adding the API to It

A new Product named "Partner Notes Access" is created, with a description explaining it grants access to the Notes API for approved partners, subscription required, and approval required so that a partner requesting access gets manually reviewed before being granted a key. The Notes API is then added to that Product directly. The Notes API is now reachable only through a valid subscription to this specific Product, not by anyone who simply discovers the URL.

Step 4: Layering the Policies From Part 1

The Product-level policy handles the subscription key check, which is largely automatic once "Requires subscription" is enabled on the Product itself. The underlying policy structure still exists as an inbound block with a base element, even though the actual key validation happens automatically based on that Product setting.

The API-level policy handles OAuth validation, applying to every operation in the Notes API, layered on top of the product-level subscription check:

<!-- Notes API-level policy.xml -->
<policies>
  <inbound>
    <base />
    <validate-jwt header-name="Authorization"
        failed-validation-httpcode="401"
        failed-validation-error-message="Unauthorized">
      <openid-config url="https://login.microsoftonline.com/{tenantId}/v2.0/.well-known/openid-configuration" />
      <audiences>
        <audience>api://notes-api</audience>
      </audiences>
    </validate-jwt>
  </inbound>
</policies>

The Operation-level policy applies a stricter rate limit specifically to the write operations - POST, PUT, and DELETE - leaving GET at the product's default limit:

<!-- Applied to POST /notes, PUT /notes/{id},
     DELETE /notes/{id} individually -->
<policies>
  <inbound>
    <base />
    <rate-limit-by-key calls="5"
        renewal-period="60"
        counter-key="@(context.Subscription.Id)" />
  </inbound>
</policies>

Write operations get five calls per minute, meaningfully stricter than the read-only GET operations, since writes are more expensive and more consequential if something calls them in a runaway loop.

The actual effective policy for a POST request, once all three levels combine, runs in a specific order: the subscription key is checked first at the Product level, inherited automatically; then the OAuth token is validated at the API level, also inherited; then the stricter rate limit applies at the Operation level, specific to this operation alone - all three running in sequence before the request ever reaches the real backend.

Step 5: Adding CORS for a Real Frontend Origin

<!-- API-level policy, added alongside the JWT validation -->
<inbound>
  <base />
  <validate-jwt ... />

  <cors allow-credentials="true">
    <allowed-origins>
      <origin>https://partner-app.example.com</origin>
    </allowed-origins>
    <allowed-methods>
      <method>GET</method>
      <method>POST</method>
      <method>PUT</method>
      <method>DELETE</method>
    </allowed-methods>
    <allowed-headers>
      <header>Content-Type</header>
      <header>Authorization</header>
    </allowed-headers>
  </cors>
</inbound>

Setting allow-credentials to true means the Authorization header, carrying the OAuth token, is permitted - which is exactly why the origin must be named explicitly as https://partner-app.example.com rather than a wildcard, per the CORS rule covered in Part 1: browsers explicitly forbid combining a wildcard origin with credentialed requests.

Step 6: Versioning Before the Breaking Change Ships

Consider a scenario where the Notes API's response shape needs to change - "Content" is being renamed to "Body" to better match a new internal naming convention. This breaks every existing caller still expecting "Content."

The fix starts under APIs, then Notes API, then Add Version, choosing a Path-based versioning scheme for the discoverability reasoning covered in Part 1, with a version identifier of v2. The v2 API is now live at /v2/notes, completely separate from the original, which APIM automatically prefixes as v1 once a second version exists.

The v2 backend returns a response shaped as Id, Title, and Body, while the v1 backend still returns Id, Title, and Content - both versions can point to different backend deployments, or the same backend with a version-aware response transformation. Existing partners keep calling /v1/notes with zero changes required on their end. New partners, or partners ready to migrate, start using /v2/notes explicitly and get the new Body field name.

Step 7: Testing the Complete Flow End to End

What a caller actually experiences, request by request, demonstrates every layer working together.

A POST request with no subscription key returns 401 Unauthorized, blocked at the Product level before the backend is ever called.
The same request with a subscription key added but no Authorization header still returns 401 Unauthorized, this time blocked at the API level.
The same request with both a valid subscription key and a valid OAuth token, called six times within one minute, succeeds for the first five calls but the sixth returns 429 Too Many Requests, blocked at the Operation level's rate limit.
Only a request with a valid key, a valid token, and within the rate limit actually reaches the backend and returns 201 Created with the note genuinely persisted.

Every failure in that sequence was caught by APIM before the backend ever ran - exactly the architectural benefit covered conceptually in Part 1, now demonstrated with an actual request sequence.

Key Lessons

Enabling Swagger and OpenAPI on an API before importing into APIM turns manual operation-by-operation setup into an automatic import.

Real production APIM setups layer policies across all three levels deliberately - subscription key at the product level, identity at the API level, fine-grained limits at the operation level.

Write operations often warrant stricter rate limits than reads, applied specifically at the operation level rather than uniformly across the whole API.

CORS with credentials requires a named origin, never a wildcard - this is not optional, browsers enforce it directly.

Versioning before a breaking change ships, not after, is what lets existing callers continue working completely unaffected while new callers adopt the new version deliberately.

Testing the full request sequence - missing key, missing token, rate limit exceeded, successful call - demonstrates that every layer of protection actually runs before the backend, not just in theory.

The Two-Part Series, Complete

Part 1 covered the concepts - what APIM is, the Product and API and Operation hierarchy, policies, subscription keys, OAuth, CORS, and rate limiting. Part 2 built all of it into a real, working example - a CRUD API imported into APIM, secured with layered policies, versioned safely, and tested end to end.

Summary

The concepts from Part 1 only fully make sense once they're applied together against something real. A minimal CRUD API, imported via its OpenAPI spec, becomes a fully governed API once it sits inside a Product with a subscription requirement, an API-level OAuth check, an operation-level rate limit on the expensive write paths, and a properly scoped CORS policy for its actual frontend. Versioning before a breaking change ships, rather than scrambling after callers start failing, is what keeps that governance sustainable over time. This is the complete, real path from a few lines of C# to a production-shaped, secured API, not just the individual pieces in isolation.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=azure-apim-explained-part2

Part 1 of this series (Concepts): https://www.techstackblog.com/post.html?slug=azure-apim-explained-part1