CH20-10: Architecture Review and Conversation Prompts
Goal
This chapter ends by turning service reference knowledge into clear architecture explanations. The goal is not to sound rehearsed. The goal is to explain a service choice with context, alternatives, trade-offs, and operations.
The durable idea is:
A strong service answer explains the workload need, the chosen service, the rejected alternatives, and the trade-off.
The Short Version
Avoid one-word answers such as:
Use AKS.
A stronger answer has shape:
Requirement:
Chosen service:
Why it fits:
Rejected alternative:
Trade-off:
Operational note:This shape works in design reviews and architecture conversations because it shows judgment, not memorization.
Service-Selection Answer Shape
Use this template when you need to explain a choice:
| Part | What to Say |
|---|---|
| Requirement | Name the workload need and constraint. |
| Chosen service | State the Azure service or combination. |
| Why it fits | Connect the service to the responsibility. |
| Rejected alternative | Name at least one option you considered. |
| Trade-off | Explain what the choice gives and what responsibility remains. |
| Operational note | Add monitoring, security, reliability, cost, or ownership. |
Example Answer: AKS Versus Container Apps
Requirement:
The team needs to run containerized APIs and background workers with autoscaling, private networking, monitoring, and a small platform team.
Chosen service:
I would start with Azure Container Apps.
Why it fits:
It runs containers with managed scaling and less Kubernetes platform ownership.
Rejected alternative:
AKS could work, but it is justified when the organization needs Kubernetes APIs, custom operators, cluster-level control, or a standard Kubernetes platform.
Trade-off:
Container Apps gives up some deep Kubernetes control, but it reduces platform operations for this team.
Operational note:
I would still design identity, secrets, networking, observability, deployment, and cost ownership around the workload.
That answer sounds architectural because it explains why the service fits and what the team still owns.
Practice Prompts
Use these prompts for architecture review or conversation practice:
| Prompt | What a Strong Answer Should Include |
|---|---|
| Design a public web application. | Edge entry, compute, identity, API boundary, data store, secrets, monitoring, scaling, cost, and fallback behavior. |
| Choose between Service Bus, Event Grid, and Event Hubs. | Command versus event versus stream, durability, consumer failure, scale, and replay needs. |
| Choose data services for a commerce platform. | Relational transactions, distributed document access, cache, object storage, analytics lake, governance, and reporting. |
| Secure secrets and service-to-service access. | Managed identities, Key Vault, RBAC, least privilege, rotation, and audit. |
| Make a workload observable. | Azure Monitor, Application Insights, Log Analytics, dashboards, alerts, correlation IDs, owners, and runbooks. |
| Control workload cost. | Tags, budgets, Cost Management, Advisor, right-sizing, scale rules, log retention, and ownership. |
| Decide when AKS is justified. | Kubernetes API need, platform team readiness, networking, security, upgrades, observability, and alternatives such as Container Apps. |
| Design private access to a database. | VNet integration, Private Endpoint, Private DNS, identity, firewall rules, routing, and monitoring. |
| Explain AI service choices. | Model access, retrieval, grounding, safety, evaluation, permissions, hosting, observability, and cost. |
Review Questions Before Implementation
Before a service choice becomes implementation, ask:
What requirement does this service satisfy?
What alternatives did we reject, and why?
What failure mode does this service handle?
What new operational responsibility does it create?
Who owns access control, networking, monitoring, cost, and incident response?
What is the rollback or fallback plan?
What documentation source confirms service behavior that matters to this design?
These questions keep the service decision connected to architecture quality.
Common Mistakes
Answering with only a service name.
Ignoring why alternatives were not chosen.
Forgetting non-functional requirements such as reliability, security, cost, and operations.
Claiming one service is always best.
Describing features without explaining workload fit.
Treating spoken answers differently from real design-review answers.
Forgetting that combined services often solve different responsibilities in one design.
If Someone Asks You
How do I explain an Azure service choice well?
A good answer is:
Explain the requirement, the chosen service, why it fits, which alternative you rejected, the trade-off, and the operational note. For example, do not only say "use Container Apps." Say that the workload needs managed container hosting without Kubernetes platform ownership, Container Apps fits that responsibility, AKS was rejected because Kubernetes control is not required, and the team still needs identity, networking, monitoring, deployment, and cost ownership.
What You Should Remember
Explain service choices as decisions with context, alternatives, trade-offs, and operations.
Questions to Check Understanding
What should a strong service-selection answer include?
Why should rejected alternatives be named?
How do operations and cost make an answer stronger?