CI/CD on AWS preview

AWS offers CodePipeline, CodeBuild, and CodeDeploy for native CI/CD. Many teams also use GitHub Actions or GitLab CI with OIDC roles—no long-lived AWS keys in CI secrets.

Pipeline stages

1. Source — CodeCommit, GitHub, S3 zip
2. Build — CodeBuild runs tests, docker build, artifacts
3. Deploy — CodeDeploy, Elastic Beanstalk, ECS, CloudFormation
4. Approval — manual gate before production (optional)

OIDC federation (modern pattern)

GitHub Actions assumes an IAM role via OIDC trust—temporary credentials per workflow run. Eliminates static AWS_ACCESS_KEY_ID in repository secrets.

List pipelines

aws codepipeline list-pipelines \
  --query 'pipelines[].name' \
  --output table

Practice: Run SDK examples locally with sandbox credentials via AWS_PROFILE=sandbox. Never commit real keys—use IAM roles in deployed environments.

Infrastructure as Code

CloudFormation and CDK (TypeScript/Python) define stacks declaratively—review infrastructure diffs in PRs like application code.

Important interview questions and answers

1. Q: Why OIDC for CI?
   A: Short-lived tokens per job—compromised repo secret does not leak permanent admin keys.
2. Q: CodeBuild role?
   A: IAM role CodeBuild assumes to pull source, write logs, push ECR images.

Self-check

1. Name three CodePipeline stage types.
2. Why prefer OIDC over access keys in GitHub Actions?

Tip: Prefer GitHub OIDC role over long-lived AWS_ACCESS_KEY_ID in repository secrets.