Question 1

What is a NestJS module and why does it exist?

Accepted Answer

A class annotated with @Module that groups providers, controllers, and imports/exports — the DI boundary. Modules organize features and control which providers are visible. Root AppModule imports feature modules. Without modular boundaries, the DI graph becomes unmaintainable.

Question 2

imports vs exports vs providers in @Module — differences?

Accepted Answer

providers: created in this module; exports: make providers available to importers; imports: bring in other modules' exports. Forgetting to export a shared service is a classic DI error. Controllers are not exported — only providers are.

Question 3

What are global modules and when are they appropriate?

Accepted Answer

Modules marked @Global() export providers everywhere without re-importing — use sparingly for cross-cutting infra. Config, logging, and database modules are common. Overusing globals hides dependencies and hurts testability.

Question 4

Dynamic modules (forRoot/forRootAsync) — why?

Accepted Answer

Configure providers at runtime (e.g., connection options) while keeping a clean static API for consumers. forRootAsync injects ConfigService. Return DynamicModule with module/providers/exports. Essential for libraries.

Question 5

Feature module vs shared module vs core module — how do you split?

Accepted Answer

Feature: domain verticals; shared: reusable helpers used by many features; core: singleton infra imported once. Avoid circular feature imports — extract shared kernels. Align modules with bounded contexts when possible.

Question 6

Lead: structure Nest modules for a multi-team monorepo API.

Accepted Answer

App shell + domain libraries as Nest packages, clear public module APIs, no deep cross-feature imports. Enforce dependency rules in lint. Version shared libs. Keep Auth/Config as platform modules. Document module ownership.

Modules NestJS Interview Questions

Other NestJS interview topics