Why Every Cloud Engineer Should Practice Explaining Their Pipeline Aloud

Interviewer: Walk me through your pipeline.

Candidate: So we have a YAML file. In that we have jobs.
First job is build. Then deploy. It deploys to AWS.
We used access keys in secrets.

Interviewer: What does the deploy job actually change?

Candidate: It... deploys the application.

Interviewer: Walk me through your pipeline.

Candidate: It has four parts. A pull request triggers lint
and unit tests, so broken code never reaches main.
A merge to main builds a Docker image tagged with the
commit SHA and pushes it to ECR.

The deploy job assumes an IAM role through OIDC, so there
are no long-lived keys in GitHub. It updates the ECS
service to the new image tag.

If health checks fail, the deployment circuit breaker
rolls back to the last working task definition.

name: terraform
on:
  pull_request:
    paths: ['infra/**']
  push:
    branches: [main]
    paths: ['infra/**']

permissions:
  id-token: write
  contents: read

jobs:
  plan:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: infra
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.TF_ROLE_ARN }}
          aws-region: ap-south-1
      - run: terraform init -input=false
      - run: terraform fmt -check
      - run: terraform validate
      - run: terraform plan -input=false

  apply:
    if: github.event_name == 'push'
    needs: plan
    runs-on: ubuntu-latest
    environment: production
    defaults:
      run:
        working-directory: infra
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.TF_ROLE_ARN }}
          aws-region: ap-south-1
      - run: terraform init -input=false
      - run: terraform apply -input=false -auto-approve

"Any change under the infra folder triggers this workflow.

On a pull request, it only runs the plan job: init, a format
check, validate, and plan. The plan output is what my
reviewer reads, so nobody approves code they cannot see
the effect of.

When the PR merges, the apply job runs. It is tied to the
production environment, which has a required reviewer, so
the job waits for approval.

Authentication is OIDC with a role, not stored keys.
State is in an S3 backend with locking, so two merges
cannot apply at the same time."

# Add at the top level of the workflow so only one
# run per branch touches the cloud at a time.
concurrency:
  group: terraform-${{ github.ref }}
  cancel-in-progress: false

# cancel-in-progress is false on purpose: cancelling an
# apply halfway can leave resources half-created.

Q: Your deploy went out and the app is returning errors.
   What do you do?

Strong answer:
1. Check the deployment events and target health first.
2. If the new version is the cause, roll back by
   redeploying the previous image tag. Because images are
   tagged with the commit SHA, I know exactly which one.
3. Revert the commit on main so the pipeline and the
   running service agree again.
4. Write down what the tests missed and add a check.

MY PIPELINE IN FOUR BEATS

Trigger:  What starts it? ______________________
          Which branches or paths? _____________
Checks:   What runs before anything is deployed?
          ______________________________________
Change:   What does it create or update in the cloud?
          ______________________________________
          Who approves it? _____________________
Recovery: How do I undo a bad change?
          ______________________________________

One thing I would improve: _____________________

ANSWER EACH OUT LOUD IN UNDER 30 SECONDS

[ ] How does the runner log in to the cloud?
[ ] Where is Terraform state kept, and is it locked?
[ ] What does the reviewer actually look at?
[ ] What happens on a failed health check?
[ ] Which secret would hurt most if leaked?
[ ] How would you add a staging environment?

Any box you cannot tick = open the project and
find the real answer before the interview.

PARTNER DRILL (20 minutes)

1. Draw your pipeline on paper: boxes and arrows only.
2. Explain it to your partner in two minutes.
3. Partner picks any arrow and asks: 'What if this fails?'
4. Answer, then partner picks another arrow.
5. Repeat four times.

Score yourself:
- Did I give a reason for every stage?
- Did I mention permissions without being asked?
- Did I describe a rollback in concrete steps?