Validation & Shutdown — Series 3

Preview — 3 of 10 questions

What does this give over a decorator-based schema?

javascript

const envSchema = z.object({
  NODE_ENV: z.enum(['development', 'test', 'production']),
  PORT: z.coerce.number().int().positive().max(65535).default(3000),
  DATABASE_URL: z.string().url(),
});

ConfigModule.forRoot({
  validate: (raw) => {
    const parsed = envSchema.safeParse(raw);
    if (!parsed.success) throw new Error(JSON.stringify(parsed.error.issues, null, 2));
    return parsed.data;
  },
});

AIt validates lazily, on first access to each key

BIt is the only approach that supports coercion

CIt permits unknown environment variables, which a class-based schema cannot

DThe schema is a value rather than a class, so the validated type is inferred from it (z.infer<typeof envSchema>) with no decorators to keep in step — and z.coerce converts while validating, so what the ConfigService serves is already correctly typed

What is the conventional precedence, and why?

javascript

factory default (3000)  |  .env file (4000)  |  process environment (5000)  |  CLI flag

AThe file wins, since it is the most explicit declaration of intent

BNarrower and more explicit sources override broader ones: a default is the fallback, a file overrides it for a checkout, the real environment overrides the file for a deployment, and an explicit flag overrides everything for one invocation — so the closer a source is to the individual run, the higher it ranks

CThe first source consulted wins, and later ones are ignored entirely

DValues from every source are merged, with objects deep-merged and scalars concatenated

What is the correct configuration?

javascript

The application runs migrations and warms a cache before becoming ready,
taking about 90 seconds. The orchestrator restarts it after 30.

AA startup probe with a generous failure budget, which suspends the liveness and readiness checks until the application first reports healthy — so a slow boot is tolerated without also loosening the liveness timeout that protects a running instance from hanging

BRaise the liveness probe's timeout to 120 seconds

CRemove the liveness probe and rely on readiness alone

DMove the warm-up into the first request so startup is immediate

Answer all 10 questions (7 more), see explanations for every answer, and track your score.