Architect Interview Questions for Azure, .net

 

In 2026, the Saga and Event Sourcing patterns.

---

1. Saga Design Pattern

The Problem: In a microservices architecture, you can't use a single "Database Transaction" across multiple services (e.g., Order, Payment, and Inventory). If one fails, how do you "undo" the others?

The Solution: A Saga is a sequence of local transactions. If one local transaction fails, the Saga executes a series of compensating transactions to undo the changes made by the preceding transactions.

Two Types of Sagas:

1. Choreography (Decentralized): Each service produces an event that triggers the next service.
   • Best for: Simple workflows with few services.
2. Orchestration (Centralized): A central "Saga Manager" (Orchestrator) tells each service what to do and when.
   • Best for: Complex workflows (like Optum healthcare claims). In Azure, this is typically implemented using Durable Functions.

Saga Use Case: E-commerce Order Processing.

• 1. Order Service creates order (Pending).
• 2. Payment Service charges card.
• 3. Inventory Service reserves items.
• If Inventory fails: The Orchestrator tells Payment Service to "Refund" and Order Service to "Cancel."

---

2. Event Sourcing Pattern

The Problem: Traditional databases only store the current state. You don't know how you got there or what the data looked like 5 minutes ago without complex audit logs.

The Solution: Instead of storing the current state, you store a sequence of append-only immutable events. The "State" is just the result of replaying these events from the beginning.

Key Components:

• Event Store: A database (like Cosmos DB or Event Hubs) that only allows appending.
• Projections: Background workers that read events and build a "Read Model" (Current State) for the UI.

Event Sourcing Use Case: Banking / Healthcare Audit Trails.

• Instead of a Balance column, you store: MoneyDeposited($100), MoneyWithdrawn($20), InterestAdded($1).
• Benefit: You have a perfect, unchangeable audit log. You can "time travel" to see the balance at any exact second.

---

3. Comparing Saga vs. Event Sourcing

Feature	Saga Pattern	Event Sourcing
Primary Goal	Distributed Data Consistency	Auditability and State History
Logic	How to handle failures (Undo).	How to store truth (Events).
Data Style	Current State (Update/Delete allowed).	Append-Only (No Delete/Update).
Azure Tool	Durable Functions / Service Bus.	Cosmos DB Change Feed / Event Hubs.

---

4. Can they work together? (The "Pro" Architecture)

In 2026, Principal Engineers often combine them:

1. Use Event Sourcing to store the "Truth" of what happened in a service.
2. Use a Saga to coordinate those events across multiple services.

Interview Answer (PSE Role):

"I use the Saga Pattern with Orchestration (via Azure Durable Functions) for complex business workflows to ensure Eventual Consistency across microservices. If a transaction fails, the orchestrator triggers compensating logic. For high-audit domains like healthcare, I pair this with Event Sourcing using Cosmos DB, ensuring we have an immutable log of every state change for compliance and debugging."

In 2026, FinOps (Cloud Financial Management) has evolved from "looking at bills" to automated cost avoidance, with Azure Advisor serving as the primary AI-driven engine for these optimizations.

In 2026, SOLID principles remain the bedrock of maintainable, scalable software. For a Principal Engineer role, the interviewers aren't just looking for definitions; they want to know how these principles prevent Technical Debt in complex cloud architectures.

Here is the "Principal-level" breakdown of SOLID using C# and .NET 10.

---

1. S: Single Responsibility Principle (SRP)

"A class should have one, and only one, reason to change."

• The Beginner Mistake: Creating a UserService that validates email, saves to SQL, sends a Welcome email, and logs errors.
• The Pro Approach: Break these into specialized classes: UserRepository, EmailService, and NotificationOrchestrator.
• In 2026: Apply this to Microservices. A service should own one business capability (e.g., "Billing"), not "Billing and Shipping."

2. O: Open/Closed Principle (OCP)

"Software entities should be open for extension, but closed for modification."

• The Logic: You should be able to add new functionality without touching (and potentially breaking) existing, tested code.
• The Pattern: Use Interfaces and Inheritance.
• Example: Instead of a switch statement that checks if (type == "CreditCard"), create an IPaymentMethod interface. When you need to add "ApplePay" in 2026, you just create a new class implementing the interface—you don't change the core PaymentProcessor.

3. L: Liskov Substitution Principle (LSP)

"Objects of a superclass should be replaceable with objects of its subclasses without breaking the application."

• The Logic: Derived classes must fulfill the "contract" of the base class.
• The Violation: A ReadOnlyFile class inheriting from File, but throwing a NotImplementedException when Save() is called.
• The Fix: If a subclass can't do what the parent does, they shouldn't share that parent. Use smaller, more specific interfaces (Interface Segregation).

4. I: Interface Segregation Principle (ISP)

"Clients should not be forced to depend on methods they do not use."

• The Beginner Mistake: Creating one "Fat Interface" like IMachine with Print(), Fax(), and Scan(). A simple Printer class is now forced to implement Fax() even if it can't.
• The Pro Approach: Split them into IPrinter, IFax, and IScanner.
• Principal Insight: This reduces coupling. If you change the IFax interface, you don't have to re-test or re-deploy the SimplePrinter service.

5. D: Dependency Inversion Principle (DIP)

"High-level modules should not depend on low-level modules. Both should depend on abstractions."

• The Logic: This is the foundation of Dependency Injection (DI) in .NET.
• Example: Your OrderController (High-level) should not "New up" a SqlDatabase (Low-level). Instead, it should ask for an IDatabase in its constructor.
• Benefit: In 2026, you can swap your SqlDatabase for Cosmos DB or a Mock Database for testing just by changing one line in Program.cs.

---

SOLID vs. Cloud-Native (The 2026 Principal View)

Principle	Impact on 2026 Architecture
SRP	Leads to clean, small Azure Functions that are easy to debug.
OCP	Enables Plugin Architectures and easy integration of new AI models.
LSP	Ensures your Unit Tests remain valid as your system evolves.
ISP	Reduces "Dll Hell" and ensures Micro-frontends only load what they need.
DIP	The key to Unit Testing and Mocking in CI/CD pipelines.

Interview "Winning" Answer:

"I apply SOLID principles to ensure our code remains decoupled and testable. For example, by following DIP, we ensure our business logic is independent of the database provider, allowing us to migrate from on-prem SQL to Azure SQL with minimal code changes. Furthermore, ISP allows us to build lean Microservices that only expose the specific contracts required by our React frontend, reducing the payload and increasing performance."

1. What is Azure Advisor?

Azure Advisor is a personalized cloud consultant that scans your entire Azure environment and provides best-practice recommendations in five categories:

• Cost: Identifies idle or underutilized resources (e.g., "This VM is only 5% utilized—downsize it").
• Security: Integrates with Microsoft Defender for Cloud to find vulnerabilities (e.g., "Public port 3389 is open").
• Reliability: Ensures high availability (e.g., "Your SQL database should be Zone-Redundant").
• Performance: Suggests improvements for speed (e.g., "Switch to Premium SSD for this SQL workload").
• Operational Excellence: Helps with workflow efficiency and governance.

---

2. What is FinOps?

FinOps is a cultural practice that brings together Finance, Engineering, and Business teams to take ownership of cloud spend. It follows a three-phase lifecycle:

1. Inform: Visibility into spend. Allocation of costs to departments using Tags.
2. Optimize: Acting on data. Using Reserved Instances (RIs) or Rightsizing to reduce costs.
3. Operate: Continuous monitoring. Setting Azure Budgets and automated alerts.

---

3. Principal Engineer Strategy: How to Optimize Costs (The "Pro" Way)

A. Rightsizing (The "Easy" Win)

Azure Advisor will flag VMs, SQL Databases, and App Service Plans that are "over-provisioned."

• The Action: If a VM has consistently low CPU/Memory, downsize the instance type. In 2026, many teams move these to Azure Container Apps to "Scale to Zero" when not in use.

B. Commitment-Based Discounts

• Reserved Instances (RIs): If your SQL Database or VM will be running for 1–3 years, commit to it in advance for up to 72% savings.
• Azure Savings Plan for Compute: A more flexible 2026 option. You commit to spending a certain amount per hour (e.g., $5/hr) across any compute service (VMs, Functions, Container Apps). Azure automatically applies the discount to whatever you use.

C. Storage Lifecycle Management

Don't pay "Hot" prices for "Cold" data.

• The Action: Set a policy in Azure Storage to automatically move blobs to Cool storage after 30 days and Archive storage after 90 days. This can reduce storage costs by over 90%.

D. Identifying "Orphaned" Resources

Advisor is excellent at finding "Zombies":

• Unattached Managed Disks: You are still paying for a disk even if the VM was deleted.
• Idle Gateways: ExpressRoute or VPN Gateways that aren't carrying traffic.
• Static IPs: Azure charges for public IPs that aren't associated with a running resource.

---

4. Advanced 2026 FinOps Pattern: "Unit Economics"

As a Principal Engineer, you should move beyond "Total Spend" and talk about Unit Cost.

• Example: "It isn't about the $10k/month bill. It's about the fact that it costs us $0.02 to process one healthcare claim. Last month it was $0.03. We are 33% more efficient."

---

5. Interview Answer (Optum/PSE Level)

Question: "How do you manage cloud costs without slowing down engineering velocity?"

"I implement a FinOps-as-Code strategy. First, I enforce a strict Tagging Policy (Owner, Project, Environment) via Azure Policy to ensure 100% cost accountability. I use Azure Advisor to identify 'Right-sizing' opportunities and automate the deletion of orphaned disks using Azure Logic Apps. For our production workloads, I leverage Azure Savings Plans to maximize discounts while maintaining the flexibility to move from VMs to Container Apps as our architecture evolves."

Summary Cheat Sheet

• Advisor: The "What" (The specific recommendations).
• FinOps: The "How" (The team, process, and culture).
• Microsoft Cost Management: The "Where" (The tool to see the actual graphs and set budgets). Learn more about Azure FinOps.

This job description is for a Heavyweight Technical Leader who bridges the gap between high-level architecture and hands-on implementation. For a 18+ year role at this level, the interview will not be about "syntax"; it will be about trade-offs, strategy, and engineering maturity.

Based on the 2026 tech landscape, here are the most likely high-impact interview questions and "Principal-level" answers.

---

1. Cloud Migration & Architecture

Question: "We have a legacy monolith on-premises. Walk me through your 'Principal Engineer' framework for a full-cycle Azure migration while ensuring zero downtime."

• Answer Strategy: Use the 6Rs Framework (Rehost, Replatform, Refactor, etc.).
• Key points:
  1. Assessment: Use Azure Migrate to inventory dependencies.
  2. Strategy: I’d move toward Replatforming (using Azure Container Apps or App Services) rather than just "Lift and Shift" (VMs) to reduce operational overhead.
  3. Data Migration: Use Azure Data Migration Service (DMS). For zero downtime, I’d set up Transaction Replication or CDC (Change Data Capture) to keep the cloud DB in sync with on-prem until the cutover.
  4. Cutover: Use Azure Front Door to gradually shift traffic (90/10 split) to validate the new environment before final decommissioning.

2. Generative & Agentic AI (The 2026 "Must-Have")

Question: "How have you applied Agentic AI to solve a 'real-world' engineering bottleneck, rather than just using it for simple code completion?"

• Answer Strategy: Focus on workflow automation and Multi-Agent Orchestration.
• Key points:
  1. The Use Case: "I designed an Autonomous SRE Agent using Semantic Kernel and AutoGen."
  2. The Logic: "When a production alert hits Azure Monitor, the agent is triggered. It uses a Sentinel Agent to verify security, then calls tools to fetch logs from Application Insights and queries Kusto (KQL) to find the root cause."
  3. The Result: "The agent provides a pre-validated fix and a summary of the impact to the on-call engineer, reducing our MTTR (Mean Time to Recovery) by 40%."

3. System Design & Scalability

Question: "How do you design for 'High Availability' in a global .NET/React application while keeping Azure costs optimized?"

• Answer Strategy: Balance Redundancy vs. Cost.
• Key points:
  1. Compute: Use Azure Container Apps with "Scale to Zero" for intermittent APIs and Spot Instances for non-critical background processing.
  2. Database: Use Azure SQL Serverless with auto-pause for dev/test, and Elastic Pools for production to share resources across databases.
  3. Performance: Implement Redis Caching at the API layer and Azure Front Door at the edge to reduce the load on the origin servers.
  4. Storage: Use Lifecycle Management to move old files to the Archive Tier automatically.

4. Security & Governance

Question: "As the architecture owner, how do you enforce security 'by design' in a CI/CD pipeline?"

• Answer Strategy: Focus on Shift-Left Security and Identity.
• Key points:
  1. Zero Trust: "I enforce Managed Identities for all service-to-service communication. We never store connection strings in GitHub Actions or Azure Key Vault if we can avoid it."
  2. Pipeline Guardrails: "I integrate Checkov or Terrascan for IaC (Infrastructure as Code) scanning and GitHub Advanced Security for secret scanning."
  3. Network: "All backend resources are isolated using Private Endpoints and VNet Integration, ensuring no database or internal API is reachable from the public internet."

5. .NET & React Full-Stack Integration

Question: "In a large-scale React app talking to a .NET Microservices backend, how do you handle state synchronization and real-time updates?"

• Answer Strategy: Mention SignalR or Event-Driven UI.
• Key points:
1. Communication: For real-time healthcare updates, I’d use Azure SignalR Service to push notifications from .NET to React.
2. State: Use React Query (TanStack) for server-state caching to minimize redundant API calls.
3. Performance: Implement BFF (Backend-for-Frontend) pattern to aggregate multiple microservice calls into a single optimized payload for the mobile/web client.

Find 3 third largest Salary?

USING OFFSET AND FETCH 

-- Example: To find the 5th highest customer (N=5)

SELECT CustomerId, CustomerName, PostalCode

FROM Customers 

ORDER BY PostalCode DESC  -- Highest amount first

OFFSET 2 ROWS         -- Skip the top 4 (N-1)

FETCH NEXT 1 ROWS ONLY; -- Take the 5th one

Using DENSE RANK

SELECT CustomerId, CustomerName, PostalCode

FROM (

    SELECT CustomerId, CustomerName, PostalCode,

           DENSE_RANK() OVER (ORDER BY PostalCode DESC) as rnk

    FROM Customers

) AS RankedCustomers

WHERE rnk = 3; -- Change this number to find the Nth highest

---

Principal Level "Pro-Tips" for the Interview:

• Mention "Observability": Don't just say "logging." Talk about Distributed Tracing and OpenTelemetry.
• Cost Management: Mention Azure Advisor and FinOps. A Principal Engineer is responsible for the cloud bill.
• Leadership: When they ask about "mentoring," talk about establishing "The Golden Path"—creating templates and CLI tools so junior devs can't make mistakes.

Suggested "Winning" Closing Statement:

"My goal is to drive Engineering Excellence by making the 'right way' the 'easy way.' By leveraging Agentic AI to handle toil and Infrastructure as Code to ensure consistency, I enable the team to focus on solving complex business problems rather than managing infrastructure."