NestJS Professional Standards & Competencies 5 — Questions and Answers
Question 1: What professional practice should NestJS developers follow when exposing sensitive configuration such as JWT secrets?
- Hardcode secrets in the source code for reliability
- Load secrets from environment variables or a secrets manager and never commit them to version control (Correct answer)
- Store secrets in a config JSON file committed to the repository
- Share secrets via Slack messages to team members
Correct answer: Load secrets from environment variables or a secrets manager and never commit them to version control
Secrets must be externalized via environment variables or vaults to prevent exposure through version control or logs.
Question 2: A NestJS team wants to enforce coding standards automatically. Which tooling combination is considered a professional standard?
- Rely on code reviews alone for enforcement
- ESLint with @typescript-eslint rules, Prettier for formatting, and pre-commit hooks via Husky (Correct answer)
- Manual formatting by the senior developer before each release
- Use a single shared IDE setting file
Correct answer: ESLint with @typescript-eslint rules, Prettier for formatting, and pre-commit hooks via Husky
Automated linting, formatting, and pre-commit hooks enforce standards consistently without relying on human memory.
Question 3: When building a NestJS API that will be consumed by mobile clients on unreliable networks, which response design practice improves resilience?
- Return all data in a single massive response to minimize round trips
- Support pagination, sparse fieldsets, and idempotent retry-safe endpoints (Correct answer)
- Disable timeouts so requests always complete
- Use WebSockets exclusively to avoid HTTP reliability issues
Correct answer: Support pagination, sparse fieldsets, and idempotent retry-safe endpoints
Pagination limits payload size, sparse fieldsets reduce bandwidth, and idempotent endpoints allow safe client retries on network failure.
Question 4: What does professional API versioning look like in a NestJS REST application?
- Change existing endpoints in place without version markers
- Use URI versioning (/v1/), header versioning, or media type versioning consistently across the codebase (Correct answer)
- Version only breaking changes and leave stable endpoints unversioned
- Use query parameter versioning exclusively
Correct answer: Use URI versioning (/v1/), header versioning, or media type versioning consistently across the codebase
NestJS has built-in versioning support; choosing a consistent strategy prevents consumer confusion and allows parallel version support.
Question 5: A NestJS service makes external HTTP calls. What professional pattern prevents cascading failures when the downstream service is slow?
- Increase server timeout to 5 minutes to ensure completion
- Implement a circuit breaker pattern with timeout and fallback using a library like Cockatiel or Nest's HttpModule with timeout (Correct answer)
- Cache the last successful response permanently
- Retry the request indefinitely until it succeeds
Correct answer: Implement a circuit breaker pattern with timeout and fallback using a library like Cockatiel or Nest's HttpModule with timeout
Circuit breakers halt calls to failing services and return fallbacks, preventing slow dependencies from exhausting the calling service's resources.
Question 6: Which practice ensures NestJS application observability in production beyond basic logging?
- Read server logs manually after incidents
- Integrate distributed tracing (OpenTelemetry), metrics (Prometheus/Grafana), and structured logs with correlation IDs (Correct answer)
- Monitor only HTTP 500 errors
- Use console.error for all errors and grep logs when needed
Correct answer: Integrate distributed tracing (OpenTelemetry), metrics (Prometheus/Grafana), and structured logs with correlation IDs
The three pillars of observability — traces, metrics, and logs — with correlation IDs enable root-cause analysis of production issues.
Question 7: What is the professional approach to handling breaking schema migrations in a NestJS application with a live production database?
- Apply all schema changes in a single deployment step
- Use expand-contract migrations: add new columns/tables first, migrate data, then remove old structures in a later deployment (Correct answer)
- Drop and recreate the entire schema during a maintenance window
- Let TypeORM synchronize the schema automatically in production
Correct answer: Use expand-contract migrations: add new columns/tables first, migrate data, then remove old structures in a later deployment
Expand-contract migrations allow zero-downtime deployments by making additive changes first and removing old structures only after all consumers have migrated.
NestJS Professional Standards & Competencies 5
What professional practice should NestJS developers follow when exposing sensitive configuration such as JWT secrets?