NestJS Professional Standards & Competencies 2 — Questions and Answers
Question 1: Which NestJS pattern ensures that a service's public interface remains stable while its internal implementation can change freely?
- Repository pattern
- Interface-based injection tokens (Correct answer)
- Concrete class injection
- Global modules
Correct answer: Interface-based injection tokens
Using interface-based injection tokens decouples consumers from concrete implementations, stabilizing the public contract.
Question 2: A NestJS team wants to enforce consistent error response shapes across all controllers. What is the professional best practice?
- Handle errors individually in each controller method
- Use a global exception filter with a standardized error DTO (Correct answer)
- Return error objects directly from services
- Use try/catch in every route handler
Correct answer: Use a global exception filter with a standardized error DTO
A global exception filter applied via APP_FILTER ensures all unhandled exceptions produce a consistent, structured response.
Question 3: When should a NestJS developer choose `forwardRef()` to resolve circular dependencies?
- Whenever two modules import each other
- Only when two providers mutually depend on each other and restructuring is not feasible (Correct answer)
- To improve performance between lazy-loaded modules
- When using dynamic modules
Correct answer: Only when two providers mutually depend on each other and restructuring is not feasible
`forwardRef()` is a last resort for genuine circular dependencies that cannot be resolved by restructuring the dependency graph.
Question 4: What is the professional reason to prefer `ConfigService` over `process.env` direct access inside NestJS services?
- ConfigService is faster at runtime
- It centralizes validation, typing, and testability of environment variables (Correct answer)
- process.env is not available in NestJS
- ConfigService automatically reloads env vars on change
Correct answer: It centralizes validation, typing, and testability of environment variables
ConfigService (backed by @nestjs/config) supports schema validation, typed access, and easy mocking in unit tests.
Question 5: Which approach best supports horizontal scalability when NestJS applications need to share session state?
- Store sessions in the NestJS process memory
- Use in-process caching with a Map
- Externalize session state to Redis or a distributed cache (Correct answer)
- Disable sessions and use JWTs for all state
Correct answer: Externalize session state to Redis or a distributed cache
Externalizing session state to Redis allows multiple NestJS instances to share state without sticky sessions.
Question 6: A NestJS application exposes a public API. What professional practice should be applied to all incoming DTOs?
- Trust client-provided data and pass it directly to the service
- Validate and transform DTOs using class-validator and class-transformer via ValidationPipe (Correct answer)
- Manually validate each field in the controller method
- Disable validation for performance in production
Correct answer: Validate and transform DTOs using class-validator and class-transformer via ValidationPipe
Applying ValidationPipe globally with class-validator decorators enforces input integrity at the boundary of the application.
Question 7: Why should NestJS developers avoid defining providers directly in the root AppModule when building large applications?
- Root AppModule does not support providers
- It creates tight coupling and makes the codebase harder to maintain and test in isolation (Correct answer)
- Providers in AppModule are not injectable into other modules
- NestJS limits the number of providers in AppModule
Correct answer: It creates tight coupling and makes the codebase harder to maintain and test in isolation
Organizing providers into feature modules improves cohesion, encapsulation, and the ability to test modules independently.
NestJS Professional Standards & Competencies 2
Which NestJS pattern ensures that a service's public interface remains stable while its internal implementation can change freely?