Stop Using Static Secrets: Acing the GitHub OIDC Interview Question

Welcome back to The Cloud Edge.

If you are stepping into a DevOps or Cloud Engineering interview this year, there is one architectural shift you absolutely must be ready to discuss: the death of the static credential.

If an interviewer asks you how to connect a CI/CD pipeline to a cloud provider, and your first instinct is to generate an IAM user and paste the keys into your CI/CD secrets manager, you are walking into a trap. Modern infrastructure demands zero-trust architecture, and for GitHub Actions, that means OpenID Connect (OIDC).

Here is how to break down the OIDC interview question and prove you understand enterprise-grade security.

The Hook: Why Static Keys are a Red Flag

Historically, deploying to AWS from GitHub Actions meant creating an IAM User, generating an AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, and storing them in GitHub Secrets.

The problem? Those keys never expire. If a developer accidentally logs the environment variables, or a bad actor gains access to your repository, those credentials are a ticking time bomb. Today, interviewers expect you to build “secretless” pipelines.

The Concept: How OIDC Actually Works

You don’t need to recite the underlying RFCs, but you do need to be able to explain the OIDC handshake in plain English:

1. The Request: When your GitHub Actions workflow runs, it requests a JSON Web Token (JWT) directly from GitHub’s OIDC provider.
2. The Handshake: The workflow presents this JWT to your cloud provider (like AWS STS).
3. The Validation: AWS checks the token against a pre-configured Identity Provider (IdP) and evaluates the IAM Role’s Trust Policy to see if this specific repository is allowed to assume the role.
4. The Exchange: If everything matches up, AWS issues short-lived, temporary credentials back to the runner for that specific job.

The credentials exist only for the duration of the deployment and then vanish.

The Interview Scenario

The Question: “Walk me through how you would authenticate a GitHub Actions workflow to AWS without storing any long-lived IAM keys. Why is this approach superior?”

The interviewer isn’t just testing whether you know what OIDC stands for. They are evaluating your grasp of credential lifecycles, identity federation, and blast radius reduction.

The “Good” Answer (Mid-Level)

A solid, passing answer covers the basics:

“I would use OpenID Connect. Instead of creating an IAM user and storing static access keys in GitHub Secrets, I would configure an OIDC provider in AWS. The workflow authenticates to AWS to assume an IAM role, which issues temporary, short-lived credentials. This is superior because there are no static secrets to rotate, leak, or manage.”

The “Great” Answer (Senior/Lead)

To stand out, dive into the mechanics of the IAM Trust Policy and security boundaries:

“I’d implement OIDC federation using AssumeRoleWithWebIdentity. I’d first establish GitHub as an Identity Provider in AWS. The most critical part is the IAM Role’s Trust Policy. I would tightly scope the sub (subject) claim to ensure that only a specific repository—and specifically the main branch of that repository—can assume the role. If we don’t lock down the sub claim, any repository in our GitHub organization could potentially assume the production deployment role. This approach entirely eliminates long-lived credentials while enforcing strict least-privilege deployment paths.”

The “Gotcha” Follow-Up Questions

If you give the “Great” answer, expect the interviewer to poke at your operational experience with a few follow-ups:

• “What happens if a developer forks the repository? Can their workflow assume your AWS role?”

• The Answer: No. The Trust Policy’s sub claim is bound to the original organization and repository name (repo:your-org/your-repo:ref:refs/heads/main). A fork changes the organization/user path, so the sub claim will no longer match, and AWS will return an AccessDenied error.

• “How long do these credentials last?”
• The Answer: They are tied to the session duration defined in the AWS IAM role, which defaults to 1 hour (but can be configured anywhere from 1 to 12 hours). Regardless, the credentials expire automatically when the session ends.

The Wrap-Up

Shifting from static keys to dynamic, federated identities is a hallmark of mature cloud engineering. If you haven’t built an OIDC pipeline yet, make it your homework this weekend. Wire up a simple GitHub Action to read an S3 bucket or describe an EC2 instance using OIDC. Having that muscle memory will make your interview answers significantly more confident.