Give a Kubernetes Pod a Token to Call an External Service Securely

Read the full interview experience this question came from →

Quick Overview

Decide how a Kubernetes pod should obtain a token for calling an external service. Tests knowledge of Secrets delivered as volumes or environment variables, RBAC and encryption at rest, external secret managers, workload identity with projected service account tokens, and rotating the token without downtime.

Give a Kubernetes Pod a Token to Call an External Service Securely

Company: Apple

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Technical Screen

An application running in a Kubernetes pod has to call an external service, outside the cluster, that authenticates every request with a token. How do you get that token to the pod? Lay out the options, compare them on security, rotation and operational cost, and recommend one, explaining when you would choose differently. ```hint Follow the token Trace the token from where it is issued to the process that sends it, and at each step ask where it is stored and who else can read it. ``` ```hint Does the pod need a long-lived secret at all? Consider whether the pod's own identity in the cluster could be exchanged for a short-lived credential. ``` ### Clarifying Questions - Is the token a long-lived static key issued by the external service, or can the service accept short-lived credentials from an identity provider, through OIDC federation or a cloud IAM role? - Does the cluster run on a cloud provider with workload identity, and is a secrets manager already in use? - How often must the token be rotated, and can the application pick up a new token without a restart? - Who else can create pods or read Secrets in the namespace? ### What a Strong Answer Covers - The ways a Kubernetes Secret reaches a container (volume mount or environment variable) and how they differ in exposure and rotation - Access control and storage: RBAC on Secrets, who can mount them, namespace boundaries, encryption at rest - External secret managers and the ways they deliver secrets into pods, with their operational cost - Short-lived credentials through workload identity or projected service account tokens exchanged via OIDC federation - Rotation without downtime, auditing, and keeping the token out of images, Git and logs ### Follow-up Questions - If the token comes from a Secret mounted into the pod as a volume, who else can read it, and how does a rotated value reach the running process? - The external service supports OIDC federation. How can the pod authenticate without any stored secret? - How do you keep the token out of the Git repository that holds your manifests? - The token has leaked. What can an attacker do with it, and how do you respond?

Overview: Decide how a Kubernetes pod should obtain a token for calling an external service. Tests knowledge of Secrets delivered as volumes or environment variables, RBAC and encryption at rest, external secret managers, workload identity with projected service account tokens, and rotating the token without downtime.

Read the full Apple Software Engineer interview experience this question came from

|Home/Software Engineering Fundamentals/Apple
Apple logo
Apple
Jul 3, 2026
mediumSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals
0
0

An application running in a Kubernetes pod has to call an external service, outside the cluster, that authenticates every request with a token. How do you get that token to the pod?

Lay out the options, compare them on security, rotation and operational cost, and recommend one, explaining when you would choose differently.

Clarifying Questions Guidance

  • Is the token a long-lived static key issued by the external service, or can the service accept short-lived credentials from an identity provider, through OIDC federation or a cloud IAM role?
  • Does the cluster run on a cloud provider with workload identity, and is a secrets manager already in use?
  • How often must the token be rotated, and can the application pick up a new token without a restart?
  • Who else can create pods or read Secrets in the namespace?

What a Strong Answer Covers Guidance

  • The ways a Kubernetes Secret reaches a container (volume mount or environment variable) and how they differ in exposure and rotation
  • Access control and storage: RBAC on Secrets, who can mount them, namespace boundaries, encryption at rest
  • External secret managers and the ways they deliver secrets into pods, with their operational cost
  • Short-lived credentials through workload identity or projected service account tokens exchanged via OIDC federation
  • Rotation without downtime, auditing, and keeping the token out of images, Git and logs

Follow-up Questions Guidance

  • If the token comes from a Secret mounted into the pod as a volume, who else can read it, and how does a rotated value reach the running process?
  • The external service supports OIDC federation. How can the pod authenticate without any stored secret?
  • How do you keep the token out of the Git repository that holds your manifests?
  • The token has leaked. What can an attacker do with it, and how do you respond?