TL;DR: Cluster Autoscaler scales pre-defined node groups, so it can only add more of a shape you chose in advance and it simulates whether pending pods fit the available group templates before selecting a group. Karpenter reads the pending pods directly and provisions an instance sized for them, then consolidates when utilisation drops. Compare scheduling-to-ready latency and node cost under the actual constraints.
How to approach it
Explain what each one is actually deciding, since the difference in outcome follows entirely from that. Then cover consolidation, which is where the cost saving comes from and which candidates usually omit.
A strong answer
Cluster Autoscaler works with node groups: an autoscaling group per instance type and zone, each with a min and max. When pods are Pending it simulates which group would fit them and increases that group's desired count. The constraints follow: you must define the shapes in advance, a group is homogeneous, and scaling means launching another of that shape whether or not it fits the workload well. A pod needing 2 cores and 32GB on a cluster of general-purpose nodes gets a node with far more CPU than it needs, and you pay for the whole thing.
Karpenter removes the group. It watches unschedulable pods, computes their combined requirements including affinities and topology constraints, and provisions an instance chosen from a broad set of permitted types that actually fits. Fewer, better-sized nodes, and no advance combinatorial planning of groups across types and zones.
Two mechanisms matter beyond the initial provisioning.
Consolidation is the cost lever and it is the part people miss. Karpenter continuously evaluates whether the current pods could run on fewer or cheaper nodes, and if so it cordons, drains and replaces. That reclaims the fragmentation that accumulates as workloads come and go, while Cluster Autoscaler can also remove underutilized nodes when their pods can move elsewhere. It is also the behaviour you must understand before enabling it, because it deliberately moves running pods: PodDisruptionBudgets and graceful termination are prerequisites rather than nice-to-haves, and a do-not-disrupt annotation can restrict voluntary disruption. It cannot prevent forced Spot reclamation; verify the configured termination and disruption policies.
Spot handling. Karpenter can select across many instance types, which materially improves spot availability because you are not tied to one shape, and it handles interruption notices by draining ahead of reclamation. Pool diversity reduces concentration risk; fallback capacity, quotas and interruption recovery still matter.
The honest limits. It is tightly coupled to the cloud provider's API, so it is not a portable abstraction. Giving a controller permission to launch instances is a real privilege that needs scoping. And consolidation churn can surprise a team that has never seen pods move for reasons unrelated to deployment, which is a communication problem as much as a technical one.
See the Cluster Autoscaler FAQ and Karpenter disruption documentation for the deployed versions.
Where Cluster Autoscaler still fits: environments with strict node standardisation for compliance reasons, or clusters small and static enough that the complexity is not worth it.
What interviewers probe next
"Why is scheduling faster?" No group selection step and no waiting for an autoscaling group to reconcile. It calls the instance API directly for a shape it already knows fits.
"How does this interact with requests?" Completely. Karpenter provisions against requests, so inflated requests buy larger instances than the workload needs. Right-sizing requests is a prerequisite for the cost benefit, not an alternative to it.
"What breaks if you enable consolidation blindly?" Anything without a PodDisruptionBudget, anything with long graceful shutdown, and anything stateful that assumed it would stay put.
Common mistakes
Assuming one controller always scales faster. Both evaluate fit and can remove unneeded capacity; their provisioning models and supported constraints differ.
Enabling consolidation without PDBs, which produces disruption nobody expected.
Expecting savings while requests are wrong. It will faithfully buy capacity for what you asked for.