Virtusa: DevOps Engineer (Golang)

Role shape: DevOps / Platform Engineer with mandatory Golang
Stated experience: 15+ years hands-on
Core stack: AWS, Kubernetes (EKS/ECS), Terraform, PostgreSQL/Aurora, DynamoDB, MongoDB, Kafka, Jenkins, GitLab CI, Docker, Spring Boot microservices, Python/Shell
Domain: Banking / financial services products
Nice-to-have: TOGAF, AWS Certified Solutions Architect, data architecture and AI/ML exposure

Decoding the JD — what each line is really testing

1. "DevOps engineers mandatorily with Golang" — they have Go services in the estate, or they want tooling and operators written in Go rather than Bash. Expect real Go questions: concurrency, context, graceful shutdown, error handling, building small static binaries. This is your strongest ground. Do not let it pass in two minutes.
2. "EC2, Lambda, Glue Jobs, S3, RDS" — the Glue mention is the tell. This is a banking data platform: S3 data lake, Glue crawlers and Spark ETL, RDS/Aurora as the system of record, Lambda for glue-code and event handling. Not a generic web stack.
3. "Provisioning AWS infrastructure through Terraform" — they want state management, modules, and a plan/apply pipeline story, not terraform apply from a laptop.
4. "EKS and ECS" — both, which means a mixed estate: legacy services on ECS Fargate, newer ones on EKS. Be ready to argue when each is correct.
5. "RDS, Aurora, DynamoDB, MongoDB" + "24/7 availability" + "backup and disaster recovery" — the heart of the role. RTO/RPO, failover, PITR, cross-region. If you prepare one area deeply, make it this one.
6. "Kafka for event-driven architectures" — you already have this. Your outbox, at-least-once and idempotent-consumer experience is directly relevant and is a genuinely senior conversation.
7. "Spring Boot" — you are not being asked to write Java. You are being asked to operate JVM services: containerising them correctly, heap and cgroup settings, actuator health endpoints, GC pauses showing up as latency.
8. "Performance, security, reliability, availability, observability, compliance" — these six words are the AWS Well-Architected pillars in disguise. Answer design questions by walking those axes explicitly; it signals you think in the vocabulary their architects use.
9. "Mentor junior architects, enforce standards and governance" — the architect half. Prepare ADRs, golden paths, paved-road platform thinking, review gates.
10. "Regulatory changes impacting banking" — in India: RBI data localisation, audit trails, change management, segregation of duties. Knowing the vocabulary is enough at interview stage.

Coverage map — what you have, what you must build

P0 will be tested in round one and you cannot fake it • P1 will come up and needs a credible answer • P2 bonus signal

21-day prep plan

Weight it towards the P0 rows. You will not become a 15-year AWS architect in three weeks, but you can absolutely become someone who has built the thing once, end to end — and that changes how you answer every question.

1. Golang — your differentiator, so lead with it

The JD says Golang is mandatory. On a DevOps pipeline that is unusual, and it is the single reason you are competitive here. Do not answer Go questions like a web developer; answer them like someone who writes the tools that operate the platform.

Why Go is the infrastructure language

• Single static binary — no runtime, no interpreter, no dependency hell in the image. A FROM scratch image of 8 MB versus a 400 MB Python image.
• Concurrency that fits operations — polling hundreds of endpoints, draining queues, watching Kubernetes resources, all with goroutines instead of thread pools.
• The ecosystem is Go — Kubernetes, Docker, containerd, etcd, Terraform, Prometheus, Consul, Vault, ArgoCD. When something misbehaves you can read the source.
• Cross-compilation — GOOS=linux GOARCH=arm64 go build gives you a Graviton binary from a Mac, which ties straight into the cost conversation.

The graceful-shutdown pattern — expect this exact question

A pod being rolled gets SIGTERM, then SIGKILL after the grace period. A service that ignores SIGTERM drops in-flight requests on every deploy. This is the most common Go-in-Kubernetes question there is.

func main() {
    srv := &http.Server{Addr: ":8080", Handler: router()}

    go func() {
        if err := srv.ListenAndServe(); err != nil && !errors.Is(err, http.ErrServerClosed) {
            log.Fatalf("listen: %v", err)
        }
    }()

    stop := make(chan os.Signal, 1)
    signal.Notify(stop, syscall.SIGINT, syscall.SIGTERM)
    <-stop
    log.Println("shutdown signal received")

    // Readiness must fail BEFORE we stop accepting connections, so the
    // endpoints controller pulls this pod out of the Service first.
    atomic.StoreInt32(&ready, 0)
    time.Sleep(5 * time.Second) // let kube-proxy/ALB converge

    ctx, cancel := context.WithTimeout(context.Background(), 20*time.Second)
    defer cancel()
    if err := srv.Shutdown(ctx); err != nil {
        log.Printf("forced shutdown: %v", err)
    }
}

The detail that wins the point: flip readiness to false and sleep before shutting down. Kubernetes removes the pod from Service endpoints asynchronously, so if you shut down immediately you still receive traffic for a second or two and 502s appear on every rollout.

A Go tool that talks to the cluster

Write one of these before the interview so you can say "I wrote a small controller" instead of "I have read about controllers."

// Lists pods that are not Ready across all namespaces — the seed of every
// internal platform CLI.
cfg, err := rest.InClusterConfig()
if err != nil {
    cfg, err = clientcmd.BuildConfigFromFlags("", os.Getenv("KUBECONFIG"))
    if err != nil {
        return fmt.Errorf("load kubeconfig: %w", err)
    }
}

clientset, err := kubernetes.NewForConfig(cfg)
if err != nil {
    return fmt.Errorf("build client: %w", err)
}

pods, err := clientset.CoreV1().Pods("").List(ctx, metav1.ListOptions{})
if err != nil {
    return fmt.Errorf("list pods: %w", err)
}

for _, p := range pods.Items {
    for _, c := range p.Status.Conditions {
        if c.Type == corev1.PodReady && c.Status != corev1.ConditionTrue {
            fmt.Printf("%s/%s not ready: %s\n", p.Namespace, p.Name, c.Reason)
        }
    }
}

The next level up, and worth knowing by name: an operator built with controller-runtime, which watches a Custom Resource and drives the cluster towards the declared state through a reconcile loop. The loop must be idempotent and level-triggered — it reads current state and converges, rather than reacting to an event once. That is the same discipline as your Kafka consumers.

The container image

FROM golang:1.23-alpine AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
# Static binary, no cgo, symbols stripped
RUN CGO_ENABLED=0 GOOS=linux go build -trimpath -ldflags="-s -w" -o /app ./cmd/api

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /app /app
USER nonroot:nonroot
EXPOSE 8080
ENTRYPOINT ["/app"]

Talking points: distroless has no shell, so a compromised container has nothing to pivot with; nonroot satisfies a runAsNonRoot admission policy; -trimpath gives reproducible builds; and the final image is single-digit megabytes, which shortens every node pull and every scale-out.

2. AWS — the services this JD actually names

The mental model

Do not memorise the service catalogue. Learn the five they named plus the two that underpin everything (IAM and VPC), and be able to place each in an architecture.

• IAM — identity and permission. Roles over users, temporary credentials over keys. Long-lived access keys in a pipeline are the finding an auditor opens with.
• VPC — private subnets for compute and data, public subnets for load balancers only, NAT gateway for egress, security groups as stateful instance firewalls, NACLs as stateless subnet firewalls. VPC endpoints to reach S3 and DynamoDB without traversing NAT, which is both a security and a cost answer.
• EC2 — instance families (m = general, c = compute, r = memory), Graviton (m7g) for roughly 20% better price-performance on Go workloads, Auto Scaling Groups, AMIs baked with Packer.
• S3 — eleven nines of durability, storage classes and lifecycle policies, versioning, Object Lock for write-once audit data (a banking favourite), SSE-KMS, and the fact that it is the substrate of the data lake.
• RDS — managed Postgres/MySQL. Multi-AZ, automated backups, PITR, read replicas, parameter groups, maintenance windows.
• Lambda — event-driven compute. Know cold starts, provisioned concurrency, concurrency limits, and that Go runs on the provided.al2023 custom runtime now that the go1.x runtime is retired.
• Glue — serverless Spark ETL plus the Data Catalog. Crawlers infer schema from S3 and populate the catalog; jobs transform between lake zones; job bookmarks stop you reprocessing the same files.

The banking data-platform shape they are hinting at

Source systems (Aurora, Kafka, SFTP drops)
        │
        ▼
   S3  raw zone          ← immutable landing, Object Lock, KMS
        │  Glue crawler → Data Catalog
        ▼
   S3  curated zone      ← Glue Spark job: clean, dedupe, conform, Parquet
        │
        ▼
   S3  consumption zone  ← partitioned by dt, queried by Athena / Redshift
        │
        ├── Athena (analyst SQL)
        ├── QuickSight (dashboards)
        └── SageMaker (fraud / credit models)

If asked about AI/ML in banking, the honest and useful answers are fraud and anomaly detection, credit risk scoring, AML transaction monitoring, customer churn and next-best-action, and document processing for KYC. The engineering point to make is that in a regulated bank the hard part is not the model, it is explainability, model governance, drift monitoring and audit — a model that cannot justify a rejected loan is not deployable.

Well-Architected, as an answering framework

When a design question lands, walk the six pillars out loud. It converts a rambling answer into a structured one and it maps word-for-word onto the JD sentence about performance, security, reliability, availability, observability and compliance.

3. Terraform — state is the whole interview

Every Terraform interview converges on state. If you can talk about state, locking, drift and blast radius with confidence, you sound experienced even without years of it.

Backend and locking

terraform {
  required_version = "~> 1.9"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }

  backend "s3" {
    bucket       = "acme-tfstate-prod"
    key          = "platform/eks/terraform.tfstate"
    region       = "ap-south-1"
    encrypt      = true
    use_lockfile = true   # native S3 locking (Terraform 1.10+)
    # Older estates still use: dynamodb_table = "tf-locks"
  }
}

• Why remote state: it is shared truth for the team, it is versioned, and it can be encrypted. Local state on a laptop means two engineers can destroy each other's infrastructure.
• Why locking: two concurrent applies against the same state corrupt it. S3 native locking (or the legacy DynamoDB table) serialises them.
• State contains secrets — RDS passwords land in state in plaintext. So the bucket is encrypted, versioned, access-logged and locked down. This is a favourite follow-up.
• Split state by blast radius — networking, cluster, data and application in separate state files, wired together with terraform_remote_state or SSM parameters. One state file for the whole estate means one bad apply can take down everything.

Module structure that a reviewer recognises

infra/
├── modules/
│   ├── network/        # VPC, subnets, NAT, endpoints
│   ├── eks/            # cluster, node groups, IRSA roles
│   ├── rds-aurora/     # cluster, parameter group, backups
│   └── service/        # ECR repo, IAM role, ALB target group
└── live/
    ├── dev/
    │   └── ap-south-1/{ network/, eks/, rds/ }
    ├── uat/
    └── prod/           # same modules, different tfvars — that is the point

The principle: environments differ by variables, not by copied code. If prod and dev drift into different HCL, prod is untested. Version your modules with Git tags so an upgrade is a deliberate, reviewable bump.

The commands and constructs to have ready

• terraform plan -out=tfplan then terraform apply tfplan — apply exactly what was reviewed, never a re-planned surprise.
• import blocks (1.5+) — bring existing hand-built resources under management declaratively rather than with the old imperative terraform import.
• moved blocks — refactor or rename resources without destroy-and-recreate.
• lifecycle — create_before_destroy for zero-downtime replacement, prevent_destroy on databases, ignore_changes for fields mutated outside Terraform.
• Drift — someone changed a security group in the console. Detect it with a scheduled plan in CI that alerts on a non-empty diff; fix it by re-applying, and fix the cause by removing console write access in prod.
• -target — say out loud that it is an emergency tool, not a workflow. Routine targeting means your state is badly split.

Terraform in the pipeline

# .gitlab-ci.yml (fragment)
stages: [validate, plan, apply]

.tf_auth: &tf_auth
  id_tokens:
    AWS_ID_TOKEN: { aud: https://gitlab.com }        # OIDC — no static keys
  before_script:
    - export AWS_ROLE_ARN=$TF_ROLE_ARN
    - echo "$AWS_ID_TOKEN" > /tmp/token
    - export AWS_WEB_IDENTITY_TOKEN_FILE=/tmp/token

validate:
  stage: validate
  script: [terraform init -backend=false, terraform validate, terraform fmt -check]

plan:
  stage: plan
  <<: *tf_auth
  script:
    - terraform init
    - terraform plan -out=tfplan -lock-timeout=5m
    - terraform show -no-color tfplan > plan.txt
  artifacts: { paths: [tfplan, plan.txt], expire_in: 1 week }

apply:
  stage: apply
  <<: *tf_auth
  when: manual                # human gate for prod
  only: [main]
  script: [terraform init, terraform apply -auto-approve tfplan]

Three things a senior reviewer looks for here and you should name them unprompted: OIDC federation instead of stored AWS keys, apply consumes the reviewed plan artefact, and a manual gate on production. Add policy-as-code (tfsec, Checkov or OPA) in the validate stage and you have described a governed pipeline, which is exactly the architect half of the JD.

4. Kubernetes, EKS and ECS

ECS versus EKS — have an opinion

The honest senior answer: Kubernetes is not free. It buys you a rich ecosystem and costs you a platform team, a quarterly upgrade cadence and a steep failure-mode curve. A bank with a mixed estate usually keeps stable legacy services on ECS and runs the newer, fast-moving platform on EKS — which is precisely why this JD names both.

The deployment manifest, annotated

apiVersion: apps/v1
kind: Deployment
metadata: { name: payments-api }
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }   # never dip below capacity
  template:
    spec:
      serviceAccountName: payments-api        # bound to an IAM role via IRSA
      securityContext:
        runAsNonRoot: true
        seccompProfile: { type: RuntimeDefault }
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule    # spread across AZs
          labelSelector: { matchLabels: { app: payments-api } }
      containers:
        - name: api
          image: 1234.dkr.ecr.ap-south-1.amazonaws.com/payments-api:sha-9f2c1ab
          resources:
            requests: { cpu: 200m, memory: 256Mi }
            limits:   { memory: 512Mi }        # memory limit yes, CPU limit deliberately not
          startupProbe:
            httpGet: { path: /healthz, port: 8080 }
            failureThreshold: 30
            periodSeconds: 2
          readinessProbe:
            httpGet: { path: /readyz, port: 8080 }
            periodSeconds: 5
          livenessProbe:
            httpGet: { path: /healthz, port: 8080 }
            periodSeconds: 10

• Liveness vs readiness vs startup — liveness restarts a wedged process; readiness removes a pod from the Service while it is warming or a dependency is down; startup covers slow boots so liveness does not kill the pod before it ever starts. Never point liveness at a database check — a database blip then restarts every pod in the fleet and turns a degradation into an outage.
• Image tagged by commit SHA, never latest — immutable, traceable, and rollback is a tag change.
• maxUnavailable: 0 — the rollout adds a pod before removing one, so capacity never dips.
• Why no CPU limit — CPU is compressible and a limit causes CFS throttling and tail latency even when the node is idle. Set requests for scheduling, limit memory (which is not compressible and gets you OOMKilled), and leave CPU unlimited. Say this and you sound like someone who has debugged p99 latency.

The EKS-specific things that get asked

• IRSA — an IAM role assumed by a Kubernetes ServiceAccount through the cluster OIDC provider. It is how a pod reads S3 without node-wide credentials or baked keys. Newer clusters may use EKS Pod Identity, which is simpler to administer; know both names.
• VPC CNI and IP exhaustion — each pod gets a real VPC IP from the subnet, so undersized subnets stop pod scheduling long before CPU runs out. Mitigate with prefix delegation or larger subnets. This is a classic real-incident question.
• Autoscaling, two layers — HPA scales pods on CPU or custom metrics (KEDA for queue depth and Kafka lag); Karpenter or Cluster Autoscaler scales nodes. Karpenter is the current answer: it provisions right-sized nodes directly and consolidates underused ones, which is a cost story as well as a scaling one.
• PodDisruptionBudget — minAvailable: 2 stops a node drain during an upgrade from taking all replicas at once. Voluntary disruptions only; it does not protect against a node dying.
• Upgrades — EKS minor versions have a support window, so upgrades are a scheduled obligation, not an option. Control plane first, then node groups (blue/green node groups or a rolling replacement), checking deprecated APIs with kubent beforehand.
• Secrets — base64 is encoding, not encryption. Use the External Secrets Operator or the Secrets Store CSI driver with AWS Secrets Manager, plus envelope encryption of etcd with KMS.
• Policy — Kyverno or OPA Gatekeeper as admission control to enforce "no root, no latest tag, resources required, images only from our ECR." That is governance made executable, which is a strong architect-track point.

Debugging a CrashLoopBackOff, out loud

kubectl get pods -n payments                # phase, restarts, age
kubectl describe pod <pod> -n payments      # events: image pull? OOMKilled? probe failing?
kubectl logs <pod> -n payments --previous   # the crashed container's logs, not the new one
kubectl get events -n payments --sort-by=.lastTimestamp
kubectl top pod <pod> -n payments           # memory near the limit?

The ordering matters more than the commands: describe before logs, because OOMKilled, ImagePullBackOff and a failing readiness probe are all visible in events and each sends you somewhere completely different. --previous is the flag candidates forget, and it is the only way to see why the container that already died, died.

5. CI/CD — Jenkins, GitLab CI and GitOps

The pipeline shape they want to hear

commit ──▶ lint + unit tests + race detector
        ──▶ SAST + dependency scan (gosec, govulncheck, Trivy)
        ──▶ build image, tag with the commit SHA
        ──▶ image scan; fail on HIGH/CRITICAL
        ──▶ push to ECR (immutable tags enabled)
        ──▶ deploy to dev            (automatic)
        ──▶ integration + contract tests
        ──▶ deploy to UAT            (automatic)
        ──▶ deploy to PROD           (manual approval + change record)
        ──▶ smoke tests, then watch SLOs; auto-rollback on error-budget burn

The two principles to state explicitly: build the artefact once and promote it — the exact image tested in dev is the image that reaches prod, never a rebuild per environment — and every stage is a gate that can fail the pipeline, otherwise it is decoration.

Jenkins, declarative

pipeline {
  agent { kubernetes { yamlFile 'build-pod.yaml' } }   // ephemeral agents on EKS

  environment {
    ECR  = '1234.dkr.ecr.ap-south-1.amazonaws.com/payments-api'
    TAG  = "sha-${GIT_COMMIT.take(7)}"
  }

  stages {
    stage('Test') {
      steps { sh 'go test -race -coverprofile=cover.out ./...' }
    }
    stage('Scan') {
      steps {
        sh 'govulncheck ./...'
        sh 'trivy image --exit-code 1 --severity HIGH,CRITICAL $ECR:$TAG'
      }
    }
    stage('Build & Push') {
      steps {
        sh 'docker build -t $ECR:$TAG .'
        sh 'docker push $ECR:$TAG'
      }
    }
    stage('Deploy PROD') {
      when { branch 'main' }
      steps {
        timeout(time: 30, unit: 'MINUTES') {
          input message: 'Promote to production?', submitter: 'release-managers'
        }
        sh 'kubectl set image deploy/payments-api api=$ECR:$TAG -n payments'
        sh 'kubectl rollout status deploy/payments-api -n payments --timeout=5m'
      }
    }
  }

  post {
    failure { slackSend channel: '#deploys', message: "FAILED ${env.JOB_NAME} ${env.BUILD_NUMBER}" }
  }
}

Jenkins talking points: ephemeral Kubernetes agents rather than long-lived static slaves that accumulate state; shared libraries so fifty repositories are not maintaining fifty copies of the same Groovy; credentials binding so nothing is echoed into a log; and an honest note that Jenkins is the legacy engine in most banks and the migration path is usually GitLab CI or GitHub Actions.

GitOps — the answer that marks you as current

Push-based deploys need cluster credentials in the CI runner, which is the credential you least want to leak. GitOps inverts it: ArgoCD or Flux runs inside the cluster, watches a Git repository of manifests, and reconciles continuously. CI only writes a new image tag to that repository.

• Git is the source of truth — the cluster state is auditable by git log, which is exactly what a banking change-management process wants.
• Drift self-heals — a manual kubectl edit in prod is reverted automatically, and you can see that it happened.
• Rollback is git revert.
• No cluster credentials in CI — the agent pulls, it is not pushed to.
• Progressive delivery — Argo Rollouts or Flagger do canary and blue/green with automated analysis: shift 5% of traffic, watch the error rate and latency against a Prometheus query, promote or roll back without a human.

6. Databases — the centre of gravity of this role

"Architect and manage enterprise-level databases with 24/7 availability" and "lead efforts on optimization, backup, and disaster recovery planning" are the two most demanding lines in the JD. Your Postgres knowledge is real; what you must add is the operations layer on top of it.

RDS versus Aurora

The decision rule to state: Aurora when you need fast failover, many read replicas or cross-region DR with a tight RPO; RDS when the workload is modest and cost dominates. For a bank's system of record with a 24/7 requirement, Aurora with a Global Database is the defensible default.

RTO and RPO — define them before you design anything

• RPO — how much data you can afford to lose, measured in time. Driven by backup and replication frequency.
• RTO — how long you can afford to be down. Driven by how fast you can promote or restore.

The sentence that separates a senior answer: "RTO and RPO are business decisions, not engineering ones. I ask the product and risk owners what an hour of downtime and five minutes of lost transactions cost, and the architecture follows from the answer." Then add the uncomfortable follow-up yourself: a backup you have never restored is not a backup. Schedule restore drills, measure the actual restore time, and record it — because in an audit, the evidence of the drill is what is asked for.

PostgreSQL operations to have ready

• PITR — automated backups plus WAL archiving let you restore to any second inside the retention window. That is your recovery path for a bad migration or a mistaken DELETE, which is a far more common disaster than an AZ failure.
• Connection pooling — Postgres forks a process per connection, so a few hundred connections hurt. PgBouncer or RDS Proxy in transaction mode; note that transaction-mode pooling breaks session-scoped features like prepared statements and advisory locks, so it is a design choice rather than a free win.
• Zero-downtime migrations — the banking-relevant version: add a nullable column, backfill in batches, dual-write, switch reads, then drop the old column in a later release. Never a long ALTER holding an ACCESS EXCLUSIVE lock on a hot table. Set lock_timeout and statement_timeout so a migration fails fast instead of queuing every request behind it.
• Index creation — CREATE INDEX CONCURRENTLY in production; the plain form locks writes for the duration.
• Vacuum and bloat — MVCC leaves dead tuples; autovacuum reclaims them. Long-running transactions block vacuuming and cause bloat and transaction-ID wraparound risk. Monitor pg_stat_user_tables and the oldest transaction age.
• Diagnosis — pg_stat_statements for the worst queries by total time, EXPLAIN (ANALYZE, BUFFERS) for the plan, Performance Insights on RDS for wait events.

DynamoDB — think in access patterns, not tables

• Design backwards from queries. In a relational database you model the data and then query it; in DynamoDB you list every access pattern first and design keys to serve them. Getting this backwards is the single most common mistake and interviewers probe for it.
• Partition key must spread. A key like status or a date creates a hot partition and throttles. Prefer high-cardinality keys, or add a suffix to shard.
• GSI vs LSI — a GSI has its own partition key and its own capacity and is eventually consistent; an LSI shares the partition key, must be created with the table, and supports strong consistency.
• Capacity — on-demand for spiky or unknown traffic, provisioned with auto-scaling for steady, predictable load (meaningfully cheaper at scale).
• Operational features — PITR, on-demand backups, Streams for change data capture into Lambda, Global Tables for multi-region active/active, DAX for microsecond reads.
• When not to use it — ad-hoc analytical queries, complex joins, or anything needing multi-entity transactions across arbitrary items. In a bank, ledgers usually stay in Aurora; DynamoDB serves session state, device registries, idempotency keys and high-volume event lookups.

MongoDB, briefly

Replica set of three members with automatic election on primary failure; write with w: "majority" for durability that survives a failover; read preference controls whether you accept stale secondary reads; sharding for horizontal scale, where the shard key choice is as consequential as a DynamoDB partition key. On AWS the choice is between self-managed, Atlas, or DocumentDB (API-compatible, not the same engine).

7. Kafka and event-driven architecture — your existing strength

You already work with the hard parts of this. Present the patterns you know, then extend into the operational vocabulary a platform engineer is expected to have.

What you already have, said in their language

• Transactional outbox — the event row is written in the same database transaction as the state change, and a relay publishes it. This removes the dual-write problem where the database commits and the broker publish fails, or the reverse.
• At-least-once delivery, idempotent effects — the broker will redeliver, so the consumer must make reprocessing harmless. A deterministic idempotency key checked before the effect is applied.
• The event is a trigger, not the authority — consumers re-read the source row rather than trusting a possibly stale payload.
• Saga compensation — no distributed ACID across services, so a failed step is undone by a compensating action, and ambiguity gets its own state rather than a guess.

The operational layer to add

• Partitions define parallelism and ordering. Ordering is guaranteed only within a partition, so anything that must be ordered — all events for one account — must share a partition key. Consumers in a group cannot usefully exceed the partition count.
• Durability settings — acks=all with min.insync.replicas=2 on a replication factor of 3. Anything less and an acknowledged write can be lost on a broker failure, which is not acceptable for money.
• Idempotent producer and transactions — enable.idempotence=true removes duplicates from producer retries; transactions give you exactly-once between Kafka topics, though not across Kafka and an external database — which is exactly why the outbox exists.
• Consumer lag is the health metric. Alert on lag trend, not absolute value. Burrow or the MSK/CloudWatch metrics; KEDA can scale consumers on lag directly.
• Rebalance storms — a slow consumer exceeding max.poll.interval.ms is ejected, triggering a rebalance that slows everyone further. Fix by shrinking batches, moving slow work off the poll loop, or using cooperative sticky assignment.
• Retention and compaction — time or size retention for event streams; log compaction when the topic is a changelog and only the latest value per key matters.
• Dead-letter topics — a poison message must not block a partition forever. Retry with backoff a bounded number of times, then route to a DLQ with the failure context, and alert.
• On AWS — MSK (provisioned or serverless) versus self-managed on EC2. MSK removes broker operations but you still own topic design, quotas and consumer health.

8. Observability and operational stability

The JD names observability explicitly alongside reliability and availability. The framing that lands: monitoring tells you a known thing broke; observability lets you ask a question you did not anticipate.

• Metrics — numeric time series, cheap, aggregatable, the basis of alerting. Prometheus, or CloudWatch/AMP on AWS. Watch cardinality: a label containing a user ID or a request ID will destroy your metrics store.
• Logs — structured JSON, correlated by trace ID. In Go that is log/slog. Logs are expensive at scale, so sample the noisy paths and keep the errors.
• Traces — OpenTelemetry, exported to Jaeger or X-Ray. This is how you find which of eleven services in the request path actually added the 900 ms.

What to measure

• RED for request-driven services — Rate, Errors, Duration.
• USE for resources — Utilisation, Saturation, Errors.
• The four golden signals — latency, traffic, errors, saturation.

SLI, SLO and error budgets

An SLI is the measurement (the proportion of requests served under 300 ms). An SLO is the target (99.9% over 30 days). The error budget is what is left over — 0.1% of 30 days is about 43 minutes of failure you are allowed to spend.

Why this matters to an interviewer: the error budget turns "should we ship?" from an argument into a policy. Budget remaining, ship. Budget exhausted, the next sprint is reliability work. It is how a platform team says no to a release without it being political, and describing it that way is a senior signal.

Alert on symptoms and burn rate, not causes. "Error budget burning at 14x, will exhaust in two hours" is actionable; "CPU is at 85%" wakes someone up for nothing. Every page should have a runbook, and an alert nobody acts on should be deleted.

9. Cloud security and banking compliance

Identity and secrets

• No long-lived credentials anywhere. Pipelines federate to AWS with OIDC; pods use IRSA or Pod Identity; humans use SSO with short-lived sessions and MFA. If you say only one security sentence in the interview, say this one.
• Least privilege, enforced structurally — permission boundaries so a team can create roles but not escalate, SCPs at the Organization level so even an account admin cannot disable CloudTrail or launch in an unapproved region (which is how you enforce data residency).
• Secrets — AWS Secrets Manager with rotation, or Vault. Never in environment variables committed to a repository, never in Terraform variables that land in state unencrypted, never in an image layer.
• KMS — customer-managed keys for regulated data, with key policies, rotation and an audit trail of every decrypt. Envelope encryption for EKS secrets, RDS, S3 and EBS.

Network and workload

• Private subnets for all compute and data; only load balancers are public. No SSH — use SSM Session Manager, which gives you an audited session and no open port 22.
• Security groups referencing other security groups rather than CIDR ranges, so the rules survive re-addressing.
• WAF in front of public endpoints; Shield for DDoS; rate limiting at the edge.
• Kubernetes NetworkPolicies for east-west segmentation — default deny, then allow explicitly. Without them, any compromised pod can reach every other pod.
• Image provenance — scan in CI, block HIGH and CRITICAL, sign with Cosign and verify at admission so only images your pipeline built can run.

The banking layer

• Data residency — Indian regulation requires payment data to be stored in India; enforce with an SCP restricting regions rather than with a wiki page.
• Audit trail — CloudTrail organisation-wide to a locked, versioned S3 bucket with Object Lock, so the log of what happened cannot be edited by whoever did it. Application-level admin action logging on top.
• Segregation of duties — the engineer who writes the change does not approve their own production deploy. This is why the manual gate in the pipeline exists and why GitOps with pull-request review is attractive to auditors.
• Change management — a production change carries a change record, a rollback plan and a tested backout. Automating the evidence collection rather than fighting the process is the mature position.
• Standards to name — PCI-DSS for card data, SOX for financial reporting controls, ISO 27001, RBI cyber-security framework, and the general principle of data minimisation.

You are not expected to be a compliance officer. You are expected to know that these constraints exist, to design so they are satisfiable, and to not be surprised when a control blocks a convenient shortcut.

10. Cost optimisation

Explicitly in the JD, and a topic where most engineers have nothing to say — so a prepared answer stands out disproportionately.

• Right-size first. Most savings come from instances provisioned for a peak that never happens. Compute Optimizer gives you the data; Karpenter consolidation does it continuously on EKS.
• Commit for the baseline — Compute Savings Plans (flexible across instance family and region) or Reserved Instances for steady load, at roughly 30–50% off. Cover the floor, leave the peak on-demand.
• Graviton — ARM instances at better price-performance. Go cross-compiles to ARM64 trivially, so for a Go estate this is close to free money. Java is usually fine too; native dependencies are the risk.
• Spot for anything interruptible — CI runners, batch, Glue, stateless workers behind a queue. Up to 90% off, in exchange for handling a two-minute interruption notice.
• Storage lifecycle — S3 Intelligent-Tiering or lifecycle rules to Glacier for the raw and archive zones; delete orphaned EBS volumes and old snapshots, which accumulate silently.
• Network — cross-AZ data transfer is billed and is invisible until you look. Keeping chatty services and their reads zone-aware is a real saving. VPC endpoints for S3 and DynamoDB avoid NAT gateway charges, which are frequently among the top line items.
• Non-production off out of hours — dev and UAT do not need to run overnight or at weekends; that is roughly a 65% cut on those environments for a scheduled scale-to-zero.
• Make it visible — a mandatory tagging policy enforced by SCP, then per-team showback dashboards and Cost Anomaly Detection. Cost is a behaviour problem before it is a technology problem; teams that cannot see their spend cannot manage it.

11. Spring Boot — operate it, do not pretend to write it

If asked, be direct: "I am not a Java developer. I can operate Spring Boot services competently, and here is what that involves." That answer is respected; a bluffed one is not.

• JVM in a container — modern JVMs are cgroup-aware, but you still set -XX:MaxRAMPercentage=75 rather than a fixed -Xmx, so the heap tracks the container limit. Leave headroom for metaspace, thread stacks and direct buffers, or the container is OOMKilled while the heap looks healthy — a genuinely common incident.
• Health endpoints — Actuator exposes /actuator/health/liveness and /actuator/health/readiness, which map directly onto the two Kubernetes probes. Wire readiness to dependency health and liveness to process health, not the reverse.
• Slow starts — Spring context initialisation can take tens of seconds, which is what startupProbe is for. Class Data Sharing or a native image with GraalVM if cold start genuinely matters.
• GC as a latency source — a p99 spike that correlates with nothing in the application is often a garbage-collection pause. G1 by default; ZGC or Shenandoah for low-pause requirements.
• Connection pools — HikariCP sizing multiplied by replica count is what the database actually sees. Ten pods with a pool of 20 is 200 connections, which will exhaust a default Postgres configuration.

12. The architect half — governance, standards, mentoring

These lines are why the requisition says 15+ years. You cannot manufacture two decades, but you can demonstrate that you think at this altitude, and that is often enough to be taken seriously for the level below.

Architecture Decision Records

The single most credible artefact you can talk about. One short document per significant decision: context, options considered, decision, consequences. Stored in the repository, reviewed like code. It answers the question every organisation eventually asks — "why is it built this way?" — long after the people who decided have left.

# ADR-014: Aurora Global Database for the payments store

## Context
Payments must survive a regional failure with RPO under 5 minutes and
RTO under 15. The current single-region Aurora cluster has neither.

## Options
1. Cross-region Aurora read replica — cheaper, RPO minutes, manual promotion.
2. Aurora Global Database — RPO ~1s, RTO <1min, managed failover, ~35% more cost.
3. Active/active multi-region with conflict resolution — meets everything,
   but the application is not written for write conflicts.

## Decision
Option 2. Option 3 is rejected as an application rewrite we are not funding.

## Consequences
+ Meets the stated RPO/RTO with a documented failover runbook.
- ~35% higher database cost; secondary region capacity sits mostly idle.
- Failover is regional and all-or-nothing; per-service failover is not possible.
- Requires a quarterly failover drill to keep the runbook honest.

Standards and the paved road

Governance that is a document nobody reads fails. Governance that is a golden pathsucceeds: a service template that already has the Dockerfile, the pipeline, the Terraform module, the health endpoints, the dashboards and the alerts wired up. Teams follow the standard because it is the fastest route, not because a committee told them to. Then encode the non-negotiables as automated gates — admission policies, pipeline checks, policy-as-code on Terraform plans — so compliance is verified rather than asserted.

Mentoring, described concretely

Do not say "I mentor juniors." Say what you actually do: code review that explains the reasoning rather than just requesting a change, pairing on the first incident someone takes, writing the runbook together after it, and deliberately handing over a piece of work that is slightly beyond what the person has done before with a safety net underneath. If you have done this at 1Finance, that is your story — tell it in STAR form.

TOGAF in one paragraph

A framework for enterprise architecture built around the ADM — an iterative cycle moving through architecture vision, business architecture, information systems architecture (data then application), technology architecture, opportunities and solutions, migration planning, implementation governance and change management. It also gives you an Architecture Repository and a governance body, usually an Architecture Review Board. You do not need the certification to speak about it; you need to know that it is a process framework for aligning technology to business capability, and that in a bank it exists to make architecture decisions traceable and reviewable.

13. Interview questions and answers

Click a question to expand. Read the answer once, then close it and say it out loud from memory — the second pass is where the preparation actually happens.

Golang

AWS and Terraform

Kubernetes and containers

Databases, HA and disaster recovery

Pipelines, events and security

14. Design scenarios — rehearse these out loud

Architect-track interviews are won in the scenario round. Use the same opening every time: clarify requirements, state assumptions, sketch the happy path, then attack your own design with failure modes. Interviewers reward candidates who find the holes themselves.

15. Behavioural and STAR stories

At this level the behavioural round is testing judgment and scope, not enthusiasm. Prepare five stories, each in Situation, Task, Action, Result form, with a real number in the result. Draw them from what you have actually done.

For the "biggest weakness" question, this JD hands you an honest and strong answer: "Depth of hands-on cloud operations. I have strong software and data fundamentals and I have been closing the infrastructure gap deliberately — here is what I built and what I learned from it." Naming the real gap and showing the work against it is far more convincing than a rehearsed weakness that is secretly a strength.

16. Questions to ask them

These also let you find out which of the two jobs in this JD is the real one, which you need to know before an offer.

• This requisition reads as both a hands-on DevOps role and an enterprise architecture role. Which is the day-to-day, and is there a separate person doing the other half?
• Where is the Golang in the estate today — platform tooling, product services, or both? How much Go would I be writing in a typical month?
• What is the split between EKS and ECS, and is there a direction of travel?
• What is the current state of Terraform — is everything in code, or is there a legacy footprint that was click-built?
• What are the stated RTO and RPO for the tier-one services, and when was the last failover drill?
• Is there an on-call rotation, what does the page volume look like, and who owns production for these services?
• How are architecture decisions made and recorded — is there an ARB, are there ADRs?
• What does success in this role look like at six months?
• Is this a Virtusa-badged role on a specific banking client, and how long is the engagement?

17. Certifications, in priority order

1. AWS Certified Solutions Architect – Associate — explicitly named in the JD, broadest return, and it forces you to learn the service catalogue properly. Four to six weeks of evening study is realistic. Start here.
2. HashiCorp Terraform Associate — small, cheap, and directly relevant to a named requirement. Two weeks.
3. CKA (Certified Kubernetes Administrator) — hands-on and practical, and the one that most changes how you actually answer cluster questions. Six to eight weeks.
4. AWS Solutions Architect – Professional — only after the Associate and real experience; it is a genuinely hard exam and premature attempts waste months.
5. TOGAF 9/10 Foundation — worth it if you are targeting the architect track long-term and the account values it. Low priority against the others for a hands-on seat.

A certification never beats a built thing. If you have three weekends, a working Terraform-provisioned EKS cluster running your own Go service with a pipeline behind it will do more for this interview than a badge, because it gives you specifics to answer with.

18. Traps to avoid