Questions
18 of 25
1What are dynamic modules in NestJS and when do you use them?
2How would you lazy-load a module in NestJS to improve startup time?
3What are the four properties inside @Module() decorator?
4What is the difference between a shared module and a global module in NestJS?
5What is a NestJS module, and why is it needed?
6What is the difference between exports in a module and making a provider global with @Global()?
7What is the purpose of a module in NestJS and what does the @Module() decorator do?
8Are NestJS modules singletons? What does that mean practically?
9What is a feature module in NestJS and why should you use them instead of putting everything in AppModule?
10Can a feature module re-export an imported module in NestJS? When is this useful?
11What does the @Global() decorator do and how does it change module behaviour in NestJS?
12What are the risks of overusing @Global() modules in NestJS?
13How do you register a global module exactly once in NestJS and what happens if you register it twice?
14What is the naming convention for dynamic module static methods in NestJS and what does each name signal?
15How do you structure a feature module that has sub-features in NestJS?
16What is the difference between a shared module and a global module in NestJS?
17How can a dynamic module expose a forFeature() method that works alongside a forRoot() registration in NestJS?
18What is the module encapsulation rule in NestJS and why does it matter?
19What must the object returned by a dynamic module's static method always include in NestJS?
20What is the difference between imports and providers inside @Module()?
21What is a shared module in NestJS?
22When should you export a module vs export individual providers from a module in NestJS?
23What is a dynamic module in NestJS and how is it different from a static module?
24How do you implement forRootAsync() in a dynamic module so that options can be loaded asynchronously from ConfigService?
25How do you write a dynamic module that supports both sync (register) and async (registerAsync) configuration sharing the same internal providers?
18 / 25

What is the module encapsulation rule in NestJS and why does it matter?

Difficulty: 5/10
module imports, provider scope, circular dependencies

A provider is only injectable within the module that declares it unless it is explicitly listed in that module's exports. Trying to inject an unexported provider from another module throws a dependency resolution error at startup. This rule keeps modules honest — you can read a module's public API just by looking at its exports array.

Encapsulation violation and fix
Why encapsulation matters:
  1. 1

    Provides a clear public API — exports array is a module's contract with the outside world.

  2. 2

    Prevents accidental coupling — internal helpers stay private and can be changed freely.

  3. 3

    Startup-time enforcement — NestJS throws immediately if a dependency boundary is violated.

  4. 4

    Improves testability — modules can be tested in isolation by mocking only their declared exports.

Scenario Questions

0-2 years experience

  1. 1You need to add a new service that should only be used inside the UsersModule. How would you set up the module so that other modules can't accidentally inject it?
  2. 2If you forget to export a provider from a shared module and then try to use it in another module, what runtime error do you expect to see?
  3. 3When you generate a feature module with the Nest CLI, what files are created and how do they help enforce encapsulation?

2-5 years experience

  1. 1Your team added a LoggerService to a CoreModule and exported it, but a feature module that also defines its own LoggerService is getting the wrong instance. How would you diagnose and fix the issue?
  2. 2During a refactor you moved a provider from one module to another and suddenly a controller throws 'Nest can't resolve dependencies' error. Walk me through how the module encapsulation rule could cause this.
  3. 3You notice a circular‑dependency warning after importing ModuleA into ModuleB and vice versa. How does encapsulation relate to this, and what strategies would you use to break the cycle?

5-8 years experience

  1. 1We are building a large monorepo with dozens of feature modules. How would you structure shared modules and decide what to export to balance encapsulation with reusability, and what pitfalls could arise at scale?
  2. 2A performance‑critical request traverses many modules and you suspect providers are being instantiated multiple times due to improper imports. Explain how the encapsulation rule affects provider scope and how you'd audit and optimise it.
  3. 3When migrating a legacy NestJS app to a microservice architecture, how would you use module encapsulation to isolate domain boundaries and prevent accidental coupling across services?

8+ years experience

  1. 1Our organization has multiple teams owning different domains in a shared NestJS codebase. How would you define module boundaries and enforce encapsulation to minimise cross‑team breakage, and what governance processes would you put in place?
  2. 2We plan to version our public API modules while keeping internal modules private. How does the encapsulation rule guide your strategy for exporting versus keeping modules internal, and how would you handle backward compatibility?
  3. 3If we need to gradually replace a core authentication module with a new implementation, how would you leverage Nest's encapsulation to perform a safe, incremental rollout without disrupting existing consumers?

Follow-up Questions

  • What would happen if you exported every provider from a module?
  • Can you describe a time you had to decide whether to make a module global?
  • How does encapsulation affect unit testing of a feature module?
Share

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.