10 GitHub Actions Workflows for Pune DevOps (2026)
The short version
The list
- 1
CI workflow: test + lint + build on every PR
Triggered on pull_request to main: checkout → setup language runtime → cache dependencies → install → run linter → run tests → upload coverage. Fail-fast: cheap checks before slow tests. Block PR merge if any step fails.
Why it matters: Asked at ~80% of Pune GitHub Actions interviews. The foundational pattern; every modern repo should have this.
Best for: Foundation; first workflow to build for any project.
- 2
CD workflow: deploy on push to main
Triggered on push to main branch: build artifact → run smoke tests → deploy to staging → integration tests → deploy to production. Use environments + required approvals for production gating.
Why it matters: Asked at ~65% of Pune rounds. Walk through how you'd add a manual approval step before production via environment protection rules.
Best for: Production deployment automation; the canonical CD pattern.
- 3
Build + push Docker image to a registry
Build a Docker image, tag with commit SHA + branch + latest, push to ECR / GHCR / Docker Hub / GAR. Use buildx for multi-arch (amd64 + arm64). Cache layers via cache-from / cache-to for faster builds.
Why it matters: Asked at ~55% of Pune product company rounds. Mention BuildKit cache mounting + layer caching for senior-fresher signal.
Best for: Containerised application deployment; modern Pune cloud-native default.
- 4
Matrix builds for multiple language versions / OSes
Run the same workflow across multiple configurations in parallel: `strategy: { matrix: { node: [18, 20, 22], os: [ubuntu, windows, macos] } }`. Catches compatibility issues early.
Why it matters: Asked at ~40% of Pune rounds. Library / open-source maintainer signal; less common at services-major fresher tier.
Best for: Library maintenance + cross-platform applications.
- 5
Scheduled workflow for periodic tasks (cron)
Triggered on schedule: `on: schedule: - cron: '0 2 * * *'` (daily 2 AM UTC). Common uses: nightly integration tests, dependency updates via Renovate / Dependabot, weekly security scans, backup verifications.
Why it matters: Asked at ~35% of Pune rounds. Walk through scheduled-task time-zone gotchas (GitHub Actions uses UTC; account for IST offset).
Best for: Maintenance automation; cost-controlled background processing.
- 6
Security scanning: CodeQL + dependency review
Built-in CodeQL action for static analysis (SAST). Dependency Review action for PR-level dependency change detection. Pair with Dependabot for automatic security update PRs. Free for public + GitHub Enterprise + many private repos.
Why it matters: Asked at ~45% of Pune product company rounds. Pune BFSI tech roles probe security workflows specifically.
Best for: Security-conscious teams; BFSI + healthcare hiring.
- 7
Reusable workflows + composite actions for DRY
Reusable workflow: another workflow can call your workflow with inputs (`workflow_call`). Composite action: a sequence of steps packaged as a single action. Both reduce duplication across multiple repos / workflows.
Why it matters: Asked at ~30% of Pune rounds. Senior-fresher organisational signal; less common at services-major fresher tier.
Best for: Multi-repo + monorepo organisations; DevOps tooling teams.
- 8
Secret + environment variable management
Repository secrets: `${{ secrets.AWS_ACCESS_KEY_ID }}`. Environment-scoped secrets: separate values per environment (dev / staging / prod). Never echo secrets in workflow output (GitHub auto-masks but echo can leak via other commands).
Why it matters: Asked at ~50% of Pune rounds. Security awareness signal; most-failed when candidates leak secrets via debug echo.
Best for: Production credential management; security-discipline signal.
- 9
Workflow concurrency control (cancel stale runs)
Prevent multiple overlapping runs of the same workflow: `concurrency: { group: '${{ github.workflow }}-${{ github.ref }}', cancel-in-progress: true }`. Stops queued/running workflows when newer commit arrives — saves CI minutes + faster feedback.
Why it matters: Asked at ~25% of Pune rounds. Cost optimisation + dev-velocity signal; rarely asked at services-major fresher tier.
Best for: Cost-conscious teams; high-PR-velocity product companies.
- 10
OIDC for cloud authentication (no long-lived secrets)
Use OpenID Connect to authenticate to AWS / Azure / GCP without storing long-lived access keys. Workflow assumes an IAM role for the duration of the run. Most secure pattern; rotates credentials automatically.
Why it matters: Asked at ~30% of Pune product company + security-conscious rounds. Modern best-practice signal; differentiates from candidates who hardcode keys.
Best for: Security-mature teams; AWS / cloud deployment workflows.
How we built this list
Workflows ranked by Pune CI/CD interview-frequency + production-use prevalence from Archer Infotech's placement-cell debriefs over 2024-2026 cycles + Pune product company DevOps engagements (Druva, BrowserStack, Helpshift, Persistent product, BFSI tech teams). GitHub Actions is now the dominant Pune CI/CD platform at product cos + AI startups; Jenkins still leads at established services-major engagements. Frequencies skew toward modern + product company contexts.
FAQs
Common questions about github actions for devops.
Should I learn GitHub Actions or Jenkins first for Pune CI/CD work?
GitHub Actions first — ~55% of new Pune CI/CD postings reference it; the modern default at product companies + AI startups. Add Jenkins as a 2-3 week secondary skill if you're targeting services-major engagements where Jenkins remains entrenched. Both teach the same fundamentals (workflows, stages, agents, secrets) — switching between them is days, not weeks.
Are GitHub Actions free for fresher portfolio projects?
Yes for public repos (unlimited free minutes). For private repos: 2,000 free minutes/month on Free plan + ~3,000 on Pro plan. Most fresher portfolio projects will fit comfortably in the free tier; only heavy workflow + matrix builds approach limits. For practice: public repos give unlimited free CI.
How do I debug a failing GitHub Actions workflow?
Three-step flow: (1) Read the failed step's logs in the Actions UI — most issues surface directly. (2) Add `- run: echo "DEBUG: $VAR"` lines around the failure point for runtime context. (3) Use `act` (local GitHub Actions runner) to reproduce + iterate without pushing commits. For complex issues, enable runner diagnostic logging via repository secret.
What's the most-failed GitHub Actions question at Pune DevOps fresher interviews?
Secret management + leakage. Candidates know to use `secrets.X` but miss: (1) secrets aren't masked from forks (PR workflows from forks don't have access to secrets by default — security feature), (2) debug echo can leak via concatenation, (3) `pull_request_target` is more dangerous than `pull_request` because it runs against the base repo's workflow with secrets. Articulating these signals real production security awareness.