TL;DR: A namespace is a scope for object names, RBAC rules, resource quotas and network policy. Choose boundaries around ownership, policy and lifecycle; a team or application environment is a common unit. It is not a security boundary against a container escape, and network traffic crosses it freely unless you write a policy.
How to approach it
Give what it scopes and what it does not, in that order. The second half is the part that matters and the part most answers miss, and an interviewer who asks this on a platform team is usually checking whether you would treat a namespace as isolation for something it cannot isolate.
A strong answer
What a namespace scopes:
Names. Two teams can both have a Deployment called api without colliding. Within one namespace, names must be unique per resource type.
RBAC. A Role and RoleBinding apply inside a namespace, so you can grant a team full control over their own space and nothing outside it. This is the most common reason to create one.
ResourceQuota and LimitRange. A quota caps the total CPU, memory and object counts a namespace may consume, and a LimitRange sets defaults so a pod submitted with no requests is either given some or rejected. Without quotas, one team's mistake consumes the cluster.
Network policy, if you write one. Policies are namespaced and select pods by label.
What it does not scope, which is the more useful list:
The kernel. Every pod on a node shares it. A container escape is not contained by a namespace, which is why untrusted workloads need a sandboxed runtime or a separate cluster.
Networking, by default. Kubernetes networking is flat: any pod can reach any other pod in any namespace by IP. The isolation people assume they are getting only exists once a NetworkPolicy with a default deny is in place.
Nodes. Pods from different namespaces land on the same machines and share page cache, disk and network bandwidth.
Cluster-scoped objects. Nodes, PersistentVolumes, StorageClasses, CustomResourceDefinitions and ClusterRoles are not in any namespace, so a team that needs its own CRD needs more than a namespace.
For the practical question of how to divide them: one per team, or one per team per environment if you run multiple environments in a cluster. A namespace per service can be justified by separate access, quota or lifecycle requirements. Automate its policies and weigh the administrative cost; a Deployment alone does not provide those controls.
Separate production and non-production clusters when their failure domains or security requirements demand it. They share a control plane otherwise, and a mistake in one can exhaust the API server for the other.
Two things that bite beginners. kubectl get pods only shows the current namespace, so a missing pod is usually in another one; -A shows all. And deleting a namespace deletes everything in it, including PersistentVolumeClaims, and the deletion blocks until every object's finalizers complete, which is why a namespace can sit Terminating for a long time.
Prove a team's boundary with negative tests
For a hypothetical payments-test namespace, give the team's deployment identity only the required namespaced permissions. Verify it can update its own Deployment and cannot read Secrets in payments-prod. Test the actual identity, including any ClusterRoleBindings; a restrictive Role does not cancel permissions granted elsewhere.
Then test network policy from both an approved caller and an unapproved pod. A default-deny ingress policy needs explicit allowances for the real request path, while egress restrictions must account for DNS and required dependencies. Confirm the installed network implementation enforces these policies.
Finally submit a disposable workload that exceeds the namespace's quota and confirm admission rejects it. These tests establish different controls: API authorization, traffic permission and resource admission. None proves that a compromised node kernel cannot affect another namespace. Use separate clusters or stronger runtime isolation where that threat or operational failure domain requires it.
What interviewers probe next
"Can a Service in one namespace be reached from another?" Yes, by its fully qualified name, payments.prod.svc.cluster.local. Short names only resolve within the same namespace, which is what the search domains in the pod's resolver configuration do.
"How would you stop that?" A NetworkPolicy with a default deny on ingress in the destination namespace, allowing only the namespaces or pod labels you name. It needs a CNI that enforces policy, which not all do.
"What is in the default namespace?" Whatever somebody created without specifying one. Named namespaces usually make ownership clearer. Objects in default need the same explicit access, quota and lifecycle decisions as objects elsewhere.
Common mistakes
Treating a namespace as a security boundary and running untrusted code in one.
Assuming pods in different namespaces cannot reach each other, when the default is that they can.
Creating namespace boundaries without assigning their access policies, quota ownership and lifecycle.
Expecting a quota to supply missing requests. Quotas that require resource accounting can reject such pods; a LimitRange can provide defaults.