Param-level applies the pipe to a single argument only. Handler-level (@UsePipes on the method) runs the pipe for all arguments of that handler. Controller-level applies to all handlers in the controller. Global applies to every request across the entire app. The global ValidationPipe is the standard for most apps.
Param-level — for transformation pipes like ParseIntPipe, ParseUUIDPipe on specific params.
Handler-level — when only some routes need validation with specific options.
Controller-level — when all routes in the controller share the same validation rules.
Global — for ValidationPipe in most apps; register via APP_PIPE for DI support.
If you need to validate a single DTO property in a controller method, how would you apply a pipe, and what would happen if you mistakenly applied it globally instead?
Show me how you would add a built‑in ValidationPipe to just one route parameter. What does Nest do when the request reaches that handler?
Suppose you have a simple GET endpoint that returns a number. How would you ensure the incoming query param is transformed to an integer using a pipe at the param level, and what error would the client see if the pipe is missing?
We have a POST endpoint that creates a user and we want to validate the whole body. The team tried moving the ValidationPipe from the controller method to the module level, but validation stopped working for some fields. Walk me through why that happened and how you’d fix it.
During a code review you notice a custom logging pipe applied at the handler level, but the same pipe is also registered globally. The logs are duplicated. How would you identify and resolve this conflict?
Our microservice uses a global pipe to strip unknown properties, but a specific route needs to allow extra fields. How would you configure the pipe scopes to achieve this without breaking other routes?
Imagine a high‑traffic API gateway that applies a global transformation pipe to every request. Some downstream services need raw payloads for performance. How would you redesign the pipe usage to balance global concerns with per‑handler exceptions?
You’re refactoring a large monolith into feature modules. Several modules rely on a custom authentication pipe applied at the handler level, but you want to move it to a global scope to reduce boilerplate. What edge cases and performance implications would you evaluate before making that change?
A bug appears only when a request passes through both a param‑level ParseIntPipe and a globally applied ValidationPipe that also tries to coerce types. Explain how pipe execution order could cause the issue and how you’d restructure the pipeline.
Our organization is standardizing on a global exception‑handling pipe, but some legacy services still use their own handler‑level pipes for validation. How would you plan a migration strategy that minimizes downtime and ensures consistent behavior across teams?
Design a policy for pipe registration (global vs handler vs param) that scales across dozens of microservices, considering versioning, testing, and cross‑team ownership. What guidelines would you set and why?
During a security audit you discover that a globally applied sanitization pipe is being bypassed on certain routes because developers added param‑level pipes that short‑circuit the pipeline. How would you enforce a contract to prevent such bypasses at the architecture level?