Q: How does GitHub Actions compare to Jenkins? "GitHub Actions is tightly integrated with GitHub, configuration-as-code in YAML lives next to the code it deploys, and the marketplace has thousands of pre-built actions. Jenkins is more flexible — Groovy DSL, mature plugin ecosystem, runs anywhere — but requires more operational overhead. For most modern GitHub-hosted projects, Actions has lower setup cost. For complex multi-stage pipelines or polyglot environments, Jenkins still wins. I've used both at Airinmar and RHS."
Q: How do you handle secrets in CI/CD? "For AWS specifically, I use OIDC to let workflows assume an IAM role with short-lived credentials, so there are no static keys in GitHub secrets. For other secrets — API keys, database passwords — use GitHub environment secrets scoped to the deployment environment, with required reviewers on production. Never echo secrets in logs. For runtime secrets, the application should pull from AWS Secrets Manager or HashiCorp Vault rather than have them baked into the deployment."
Q: How would you design a CI/CD pipeline for a containerised app? "On push to a feature branch: lint, run unit tests, build the container image, scan for vulnerabilities (Trivy or similar), push to a private registry tagged with the git SHA. On merge to main: re-run the build, push with a latest tag and a semantic version, deploy to staging via ArgoCD or Helm. Promotion to production gated on manual approval and successful staging smoke tests. Rollback via Git revert on the GitOps repo."
Q: How do you avoid duplicating workflow code across repos? "Two main tools: reusable workflows called via workflow_call, and composite actions that bundle multiple steps. For a team running many similar services, I'd keep deployment workflows in a single shared-workflows repo and call them from each service repo, passing service-specific inputs. That centralises updates — fix once, deploy everywhere."