AWS, Docker & CI/CD

That last paragraph is worth more than pretending. Every interviewer has been burned by a candidate who listed Kubernetes and could not explain a pod — and they test for it, so the downside of overclaiming is severe and the upside of honesty is real.

Have the specific levers ready, and name which one accounted for most of it. The credible ones for your setup:

• Right-sizing. Instance sizes chosen at project start and never revisited against actual CloudWatch utilisation. This is usually the biggest single win and it is the most honest answer.
• Non-production environments. Five environments running production-sized instances 24/7. Shrink them, and shut them down outside working hours — that alone is roughly a 65% saving on those instances.
• S3 lifecycle rules moving old assets to infrequent-access or Glacier.
• Orphaned resources — unattached EBS volumes, idle Elastic IPs, old snapshots, unused load balancers. Every long-running AWS account has these.
• Savings plans or reserved instances for the steady-state baseline, on-demand for the rest.
• Data transfer — often the invisible line item. Serving assets from S3 and CloudFront instead of from the instance.

Score the points explicitly as you go:

• Multi-stage, so build tooling and dev dependencies never ship. Often a 10× size difference.
• Copy the manifest before the source, so the npm ci layer is reused when only code changes. This is the single biggest build-time win and the thing most Dockerfiles get wrong.
• npm ci not npm install — reproducible from the lockfile, and it fails rather than silently updating.
• Non-root user.
• Exec-form CMD. Shell form wraps the process in /bin/sh, which does not forward SIGTERM — so your graceful shutdown from R5 never runs and every deploy kills in-flight requests.
• .dockerignore with node_modules, .git, .env — otherwise you copy the host's node_modules into the build context and both slow the build and risk shipping secrets.

# ---- build ----
FROM node:26-alpine AS build
WORKDIR /app
COPY package*.json ./          # before the source: this layer caches
RUN npm ci
COPY . .
RUN npm run build

# ---- run ----
FROM node:26-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm ci --omit=dev && npm cache clean --force
COPY --from=build /app/dist ./dist
USER node                      # never run as root
EXPOSE 3000
HEALTHCHECK --interval=30s CMD node healthcheck.js
CMD ["node", "dist/main.js"]   # exec form — receives SIGTERM directly

Nothing in the repository, ever. Then a layered answer:

• Pipeline secrets — GitHub Actions encrypted secrets or environments with required reviewers for production.
• Runtime secrets — AWS Systems Manager Parameter Store (cheap) or Secrets Manager (rotation built in), read at boot or injected by the deploy.
• IAM roles, not long-lived access keys. An instance profile or OIDC federation from GitHub Actions means there is no static key to leak.
• A committed .env.example documenting required keys without values, so a new developer knows what is needed.
• Boot-time validation — ConfigModule with a Joi or Zod schema, so a missing variable fails the process immediately with a clear message rather than causing a null-pointer at 3am inside one request path.

If they push on what you would do differently: per-environment parameter paths (/app/prod/DB_URL) with IAM policies scoped to the path, so the staging role literally cannot read production secrets. That is the control that turns a mistake into a permission error.

• Image vs container vs layer. An image is a read-only template built from stacked layers; a container is a running instance of one with a writable layer on top.
• docker-compose in development, not production. It has no rolling updates, no health-based routing, no multi-host scheduling. Fine for local dependencies; not a deployment strategy.
• Blue-green vs rolling vs canary. Blue-green: two full environments, switch traffic, instant rollback, double the cost. Rolling: replace instances gradually, cheap, but both versions run at once so your database schema must support both. Canary: a small percentage first, watch the error rate, then proceed.
• Rollback in under five minutes. Because images are tagged by commit SHA, rollback is re-deploying the previous tag. The thing that makes rollback hard is a database migration that already ran — which is why expand-migrate-contract from R6 matters.
• EC2 vs ECS vs Lambda. EC2 when you want full control and a steady load. ECS/Fargate when you want containers without managing the hosts — the natural next step from where you are. Lambda for spiky, short, stateless work; watch cold starts and the 15-minute limit.
• What a load balancer buys you. Health-checked routing, TLS termination, zero-downtime deploys, and a place to put WAF rules. Without one you cannot deploy without dropping requests.
• S3 + CloudFront over serving from Node. Your process should never spend its single thread pushing static bytes. The CDN also puts the asset physically closer to the user.
• IAM role vs user. A user has long-lived credentials; a role is assumed temporarily and its credentials rotate automatically. Prefer roles everywhere — a leaked role session expires, a leaked access key does not.
• Monitoring — be honest. "Today it is structured logs, and I know that is the gap. What I would add first is error tracking (Sentry), then p95 latency and error rate per endpoint with alerts, then an uptime check. I would add tracing last, because it costs the most to instrument and pays off only once you have several services."
• Have you been on call? Answer truthfully. If not: "not on a formal rota — I have been the person called when a client system broke, which is the same job without the pager." Then describe an actual incident.
• Zero-downtime deploy with a migration in it. The expand-migrate-contract sequence, plus: migrations run as a separate step before the new code deploys, never on application boot — otherwise five instances start migrating simultaneously.
• Infrastructure as code. If you have not used Terraform, say so, and say what you did instead (console plus documented steps) and why that is worse — drift, no review, no reproducibility.