Comparison questionEasy~7 min.NET Aspire & Distributed App Composition / 2 of 6

Interview question

How do the AppHost and ServiceDefaults projects differ in a .NET Aspire solution?

AppHost vs ServiceDefaults responsibilities in .NET Aspire

Separates application composition in AppHost from reusable in-process defaults for telemetry, health, resilience, and service discovery.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

The AppHost describes the distributed application from outside its services. It declares projects, executables, containers, databases, caches, endpoints, references, startup dependencies, and parameters, then builds and runs that application model. ServiceDefaults is referenced by service projects and runs inside those processes. It usually provides extension methods that register common OpenTelemetry instrumentation, health endpoints, service discovery, and standard HTTP resilience. I keep topology and resource relationships in AppHost, while ServiceDefaults contains small, production-safe conventions that each participating service deliberately enables. A service should not reference AppHost, and ServiceDefaults should not become a shared business-logic library.

Full answer below

Practice focus

Application-model ownership, process boundaries, shared service configuration, OpenTelemetry, health checks, resilience, and coupling trade-offs.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
The two projects are often created together, but they execute in different places and solve different problems. Mixing their responsibilities makes local composition opaque and can couple ordinary services to a development-only host.
The AppHost describes the distributed application from outside its services. It declares projects, executables, containers, databases, caches, endpoints, references, startup dependencies, and parameters, then builds and runs that application model. ServiceDefaults is referenced by service projects and runs inside those processes. It usually provides extension methods that register common OpenTelemetry instrumentation, health endpoints, service discovery, and standard HTTP resilience. I keep topology and resource relationships in AppHost, while ServiceDefaults contains small, production-safe conventions that each participating service deliberately enables. A service should not reference AppHost, and ServiceDefaults should not become a shared business-logic library.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, AppHost can add PostgreSQL and Redis resources, add an API project, pass resource references to that API, and wait for a dependency to become ready before starting a dependent process. The API receives connection and endpoint configuration through the normal .NET configuration system. Inside the API, AddServiceDefaults can register service discovery and telemetry, while MapDefaultEndpoints can expose health endpoints according to the team's policy. That separation matters because AppHost may be used during local orchestration and deployment generation, whereas the service defaults become part of the service runtime. I review every default rather than assuming the template is universal: health routes, retry behavior, exporters, and instrumentation need to fit the service and environment.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I would keep ServiceDefaults dependency-light and composable. A worker may need telemetry and service discovery but not ASP.NET endpoint mapping; a latency-sensitive service may need a different resilience policy; a non-.NET resource cannot consume the .NET project at all. When one extension method silently registers many unrelated behaviors, upgrades and incidents become difficult because no one knows which layer changed the runtime. I prefer focused extensions with explicit configuration and tests that prove service startup, health semantics, propagation, and exporter behavior. AppHost also stays declarative: resource definitions, references, parameters, and lifecycle relationships belong there, but migrations, seed rules, and destructive initialization need explicit ownership rather than arbitrary startup callbacks. Production deployment can reuse the app model while replacing resources with target-specific constructs, yet each service remains runnable and diagnosable without importing an AppHost assembly. This preserves a useful boundary between composition and implementation.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Putting business services and shared domain models into ServiceDefaults.
Referencing AppHost from an API or worker project.
Assuming every service needs every default registered by the template.
Using AppHost callbacks as an ungoverned migration or data-seeding mechanism.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Changing one shared extension unexpectedly changes retries, telemetry, and health behavior in every service.
A service cannot start outside AppHost because required configuration has no documented contract.
Health checks report healthy before required dependencies or startup work are usable.
Topology code contains credentials or application business decisions.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why should service defaults remain production-safe?
Should every service expose the same health endpoints?
How would you let a worker opt out of an HTTP-specific default?

Continue the section

Next in .NET Aspire & Distributed App Composition: References and Readiness

Step 3 of 6

Resource references, service discovery, and readiness in .NET Aspire

Opening drill

Comparison questionEasy~7 min.NET Aspire & Distributed App Composition / 2 of 6

Interview question

How do the AppHost and ServiceDefaults projects differ in a .NET Aspire solution?

AppHost vs ServiceDefaults responsibilities in .NET Aspire

Separates application composition in AppHost from reusable in-process defaults for telemetry, health, resilience, and service discovery.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Application-model ownership, process boundaries, shared service configuration, OpenTelemetry, health checks, resilience, and coupling trade-offs.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
The two projects are often created together, but they execute in different places and solve different problems. Mixing their responsibilities makes local composition opaque and can couple ordinary services to a development-only host.
The AppHost describes the distributed application from outside its services. It declares projects, executables, containers, databases, caches, endpoints, references, startup dependencies, and parameters, then builds and runs that application model. ServiceDefaults is referenced by service projects and runs inside those processes. It usually provides extension methods that register common OpenTelemetry instrumentation, health endpoints, service discovery, and standard HTTP resilience. I keep topology and resource relationships in AppHost, while ServiceDefaults contains small, production-safe conventions that each participating service deliberately enables. A service should not reference AppHost, and ServiceDefaults should not become a shared business-logic library.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, AppHost can add PostgreSQL and Redis resources, add an API project, pass resource references to that API, and wait for a dependency to become ready before starting a dependent process. The API receives connection and endpoint configuration through the normal .NET configuration system. Inside the API, AddServiceDefaults can register service discovery and telemetry, while MapDefaultEndpoints can expose health endpoints according to the team's policy. That separation matters because AppHost may be used during local orchestration and deployment generation, whereas the service defaults become part of the service runtime. I review every default rather than assuming the template is universal: health routes, retry behavior, exporters, and instrumentation need to fit the service and environment.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I would keep ServiceDefaults dependency-light and composable. A worker may need telemetry and service discovery but not ASP.NET endpoint mapping; a latency-sensitive service may need a different resilience policy; a non-.NET resource cannot consume the .NET project at all. When one extension method silently registers many unrelated behaviors, upgrades and incidents become difficult because no one knows which layer changed the runtime. I prefer focused extensions with explicit configuration and tests that prove service startup, health semantics, propagation, and exporter behavior. AppHost also stays declarative: resource definitions, references, parameters, and lifecycle relationships belong there, but migrations, seed rules, and destructive initialization need explicit ownership rather than arbitrary startup callbacks. Production deployment can reuse the app model while replacing resources with target-specific constructs, yet each service remains runnable and diagnosable without importing an AppHost assembly. This preserves a useful boundary between composition and implementation.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Putting business services and shared domain models into ServiceDefaults.
Referencing AppHost from an API or worker project.
Assuming every service needs every default registered by the template.
Using AppHost callbacks as an ungoverned migration or data-seeding mechanism.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Changing one shared extension unexpectedly changes retries, telemetry, and health behavior in every service.
A service cannot start outside AppHost because required configuration has no documented contract.
Health checks report healthy before required dependencies or startup work are usable.
Topology code contains credentials or application business decisions.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why should service defaults remain production-safe?
Should every service expose the same health endpoints?
How would you let a worker opt out of an HTTP-specific default?

Continue the section

Next in .NET Aspire & Distributed App Composition: References and Readiness

Step 3 of 6

Resource references, service discovery, and readiness in .NET Aspire

How do the AppHost and ServiceDefaults projects differ in a .NET Aspire solution?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How do the AppHost and ServiceDefaults projects differ in a .NET Aspire solution?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section