# kubeconform -strict: Reject Unknown Fields

> kubeconform -strict fails on fields not present in the schema, catching typos the API server would silently drop. Reference for the flag and its errors.

Source: https://latchkey.dev/learn/command-reference/kubeconform-strict  
Updated: 2026-06-30

kubeconform -strict treats unknown or misspelled fields as validation errors instead of ignoring them.

By default a typo like `replcas` validates fine because schemas allow additional properties. -strict turns those silent drops into hard failures, which is exactly what you want in CI.

## What it does

-strict sets `additionalProperties: false` semantics, so any field not defined in the resource schema fails validation. This catches the misspelled keys that the API server would otherwise accept and ignore, leaving your config inert.

## Common usage

```Terminal
kubeconform -strict -summary manifests/
kubeconform -strict -kubernetes-version 1.29.0 deploy.yaml
```

## Options

| Flag | What it does |
| --- | --- |
| -strict | Fail on fields absent from the schema |
| -summary | Print valid/invalid/skipped counts |
| -verbose | Print each resource as it is checked |
| -skip | Kinds to exempt from validation |

## In CI

Make -strict the default in pipelines. The classic catch is `replcas` instead of `replicas`: without -strict the Deployment validates and ships with the wrong replica count; with -strict the build fails with a clear message at the offending key.

## Common errors in CI

`problem validating schema. Check JSON formatting: ... additionalProperties "replcas" not allowed` is the typo case (good, that is the point). For genuinely valid custom fields (some CRDs), -strict will over-report; scope it to core kinds and validate CRDs separately, or supply their real schemas via -schema-location.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubeconform -strict: Reject Unknown Fields?

By default a typo like replcas validates fine because schemas allow additional properties. -strict turns those silent drops into hard failures, which is exactly what you want in CI.

### What it does?

-strict sets additionalProperties: false semantics, so any field not defined in the resource schema fails validation. This catches the misspelled keys that the API server would otherwise accept and ignore, leaving your config inert.

### In CI?

Make -strict the default in pipelines. The classic catch is replcas instead of replicas: without -strict the Deployment validates and ships with the wrong replica count; with -strict the build fails with a clear message at the offending key.

### Common errors in CI?

problem validating schema. Check JSON formatting: ... additionalProperties "replcas" not allowed is the typo case (good, that is the point). For genuinely valid custom fields (some CRDs), -strict will over-report; scope it to core kinds and validate CRDs separately, or supply their real schemas via -schema-location.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt