DevOps Consulting Services: What Should the First Month Deliver?

Most DevOps consulting services open the same way: two weeks of interviews, a slide deck with a maturity score, and a roadmap that starts with Kubernetes. We have written that deck. It is easy to produce, hard to argue with and, on its own, changes nothing in the account.

What a regulated company on AWS actually needs from the first month is one thing it can show an auditor. Every change to production goes through a pipeline it owns, from a pull request someone else reviewed, using a credential that expires in an hour, applying exactly the plan the reviewer read.

That is our position. If a consultant's first invoice does not come with that pipeline, ask what it came with instead.

Why do DevOps consulting services open with an assessment?

Because it is safe. An assessment cannot break production, it fills a month with billable interviews, and it puts off the moment anyone has to touch the account. The findings are usually right. They are also usually the ones the CTO could have listed from memory: IAM users with keys from 2023, Terraform state on someone's laptop, deploys run from a bastion by whoever is awake.

The deck earns its place only when it changes the order of work, and in the accounts we take over the order is nearly always the same. The first month should go on the pipeline instead, because everything you will later want, from infrastructure-as-code coverage to an audit trail, only becomes real once changes flow through it.

It is also the one deliverable you can test without the consultant in the room. Push a commit and watch what happens. A roadmap cannot be tested.

What should be true on day thirty?

Four things, and none of them is a migration.

• Every change to production goes through a repository in your organisation, from a pull request merged by someone other than its author. Whose name is on the commits and whose account holds the state are the questions in the post on what you should own when a consultant leaves.
• The workflow reaches AWS through a role that trusts GitHub's identity provider, scoped to that repository and one environment. No access key sits in repository secrets.
• A production apply runs the plan file a named reviewer approved, not a fresh one generated afterwards.
• The people who can still change production by hand are listed, and the list is shorter than on day one.

Not Kubernetes, not a service mesh, not a new region. Those come later, through this pipeline rather than around it. The first time we planned one of these, the pipeline went in week three, after a "quick" tidy-up. The tidy-up took five weeks.

How does the pipeline reach AWS without a key?

Through GitHub's OpenID Connect provider and an IAM role that trusts it. GitHub's guide to configuring OIDC in AWS puts the provider at token.actions.githubusercontent.com with the audience sts.amazonaws.com, and the role's trust policy checks the token's subject claim. For a branch the subject reads repo:org/repo:ref:refs/heads/main; for an environment it reads repo:org/repo:environment:prod.

The subject is the whole point. The same page warns that a wildcard there lets any branch, pull request merge branch or environment in the repository assume the role. Match one repository and one environment. The action that does the exchange, aws-actions/configure-aws-credentials, issues a session that lasts an hour by default and can be set anywhere from fifteen minutes to twelve hours. An hour is right for a deploy. Twelve is a key with extra steps.

Why a stored key is what a hijacked workflow goes looking for is in the post on the July checkout change. The trust policy is the credential, and the consultant should hand it to you as Terraform in your repository, not as a screenshot of the console.

Who gets to approve a production apply?

A named person who did not write the change, and GitHub records the click. The environments documentation allows up to six people or teams as required reviewers, of whom only one needs to approve; a "prevent self-review" option stops the person who triggered the run from approving it; and deployment branch rules restrict which branches may deploy to it at all.

Two things caught us the first time. GitHub's page says users on the Free plan "can only configure environments for public repositories", so on a private repository the gate silently does not exist; the Team plan is cheaper than discovering that during an audit. And "prevent self-review" is a box somebody has to tick. Until it is, a one-person platform team can approve its own production change, and for a regulated entity that box is where segregation of duties actually lives.

Why apply the plan the reviewer saw, not a fresh one?

Because the world can change between the review and the merge. Run a fresh plan in the apply job and the reviewer approved one diff while production received another. Terraform's plan command writes the plan to a file with -out, and apply takes that file and executes exactly those changes. With -detailed-exitcode the plan step exits 2 when there is a diff and 0 when there is none, so the workflow can skip the gate when nothing would change.

The plan file is sensitive. HashiCorp's page is blunt: anything sensitive in the plan "will be saved in cleartext in the plan file". Keep it for one run, with the shortest retention allowed, and never print it into a log. The rendered text is the review evidence; the binary file is the thing you apply and then discard.

AWS now routes its own least-privilege work this way. A post on the AWS Security Blog this month turns IAM Access Analyzer's unused-permission findings into automated pull requests against the infrastructure-as-code repository. If the cloud provider's answer to an over-broad role is "open a PR", a consultant's answer to a deploy should not be "SSH to the bastion".

What does the RBI want from all this?

More than a direction that never mentions a pipeline suggests. The RBI Cybersecurity Directions 2026 for NBFCs ask, at paragraph 41, for a board-approved change management policy covering "change implementation, monitoring, and reporting"; at paragraph 112 for changes "implemented and reviewed in a secure and timely manner with necessary approvals"; at paragraph 114 for personnel with elevated access to have "all their system activities logged and periodically reviewed"; and at paragraph 110 for audit trails "sufficiently detailed to facilitate the conduct of audits" and to "serve as forensic evidence".

A merged pull request with a reviewer, the plan output attached, a session tagged with the repository that opened it, and a CloudTrail record of what that session did is all four paragraphs. A deploy from a laptop with an admin key is none of them, however careful the engineer. The rest of the direction is in the post on the 2026 direction; the vendor's contract is in the outsourcing post.

What can you run on Monday?

This is the shape we hand over. Plan on every pull request and push to main; apply only on main, after the production environment's reviewer approves, and only the file the plan job produced in the same run.

name: terraform
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-terraform-plan
          aws-region: ap-south-1
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init -input=false
      - run: terraform plan -input=false -out=tfplan
      - run: terraform show -no-color tfplan > plan.txt
      - uses: actions/upload-artifact@v4
        with:
          name: tfplan
          path: |
            tfplan
            plan.txt
          retention-days: 1

  apply:
    if: github.event_name == 'push'
    needs: plan
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: tfplan
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-terraform-apply
          aws-region: ap-south-1
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init -input=false
      - run: terraform apply -input=false tfplan

Two roles, on purpose. The plan role is read-only plus write on the state lock, and trusts the pull_request subject and the main branch. The apply role can change things and trusts exactly one subject, because the job runs inside the environment:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
        "token.actions.githubusercontent.com:sub": "repo:your-org/infra:environment:production"
      }
    }
  }]
}

Pin the actions to commit SHAs before you rely on this. Then run it once against a change that does nothing. If the apply job starts without waiting for a person, the environment is not configured, or the repository is on a plan that ignores it.

When is the assessment the honest answer?

When the account is about to be rebuilt, when you are still choosing between two clouds, or when nobody can say how many AWS accounts there are. Then discovery is the work. It is also the answer when there is no infrastructure code at all: a workflow that applies nothing is theatre, and that month is better spent importing what exists so the second one has something to apply.

And if you already have a platform engineer who could build this in a fortnight, you do not need DevOps consulting services for it. You need the fortnight, protected from the sprint; the hire-or-partner comparison has that arithmetic. Choose the assessment on purpose, though. Chosen, it is fine. By default, it is a consultant putting off your account.

The short version

Before you sign, ask what will be true on day thirty, in this form: a repository you own, a trust policy you can read, an environment with a reviewer who is not the author, and a plan file that is the one applied. If the answer is a deck, ask for the pipeline as the second deliverable in the same month.

Then, on day thirty-one, push a commit that changes a tag on one bucket and watch where it goes. If it reaches production without a person clicking approve, or through a key, the first month is not finished.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.