Sessions, CI/CD Pipelines, Rollbacks & Secrets — Interview Questions

How to use this lesson

Deployment questions ask about your project, so prepare a concrete, honest description of your pipeline and runtime. Around it, show the principles interviewers look for: build once, automated gates, fast rollback, and secrets never in Git.

Q1. How do you configure session clustering in Spring Boot?

Short answer: Use Spring Session with a shared store, usually Redis. Add spring-session-data-redis plus spring-boot-starter-data-redis, and point it at Redis. Spring Boot 3 auto-detects the store (the old spring.session.store-type property was removed), and replaces the container's HttpSession with one backed by Redis. Every instance then sees the same sessions.

spring:
  data:
    redis:
      host: redis.internal
      port: 6379
  session:
    timeout: 30m
    redis:
      namespace: shop:sessions
      flush-mode: on-save

Key points to cover:

• Keep session data small and serialisable. Make Redis highly available (replication plus Sentinel, or a managed Redis service). Session reads add a network hop, so don't abuse the session as a cache.
• Better still, avoid server-side sessions for APIs, and use stateless tokens.

Q2. Users lose their sessions when the app runs on several servers. What's your strategy?

Short answer: The session lives in one instance's memory, so when the load balancer sends the next request to another instance, or the instance restarts, the session is gone. The options:

1. Externalise the sessions with Spring Session (Redis or JDBC). This is the proper fix.
2. Go stateless, with JWT or opaque tokens validated on each request.
3. Sticky sessions at the load balancer. This is a stop-gap only: failover, deployments and scale-in still lose sessions, and the load becomes uneven.

Key points to cover:

• Also check graceful shutdown during deploys, and the session cookie settings (domain, SameSite, Secure) behind the load balancer.

Q3. Does choosing YAML over .properties affect performance?

Short answer: Not in any way that matters. Configuration is parsed once at startup. YAML parsing is marginally slower, a matter of milliseconds, and it has zero runtime impact afterwards. Choose based on readability and team conventions: YAML for nested and list-heavy configuration, properties for simple flat keys. The real risks are correctness ones (YAML indentation and type coercion), not speed.

Q4. Which CI/CD tools do you use for continuous build and deployment?

Short answer (describe yours honestly): For example:

Key points to cover:

• Name each tool and its role: build tool, CI server, artifact or image registry, deployment mechanism, quality gates, notifications. Jenkins, GitLab CI, Azure DevOps, Tekton and Spinnaker are all valid choices. The principles matter more than the brand.

Learn it in depth → CI/CD Pipeline Design

Q5. What's your application's deployment structure?

Short answer (a model):

• Runtime: each microservice runs as a container in Kubernetes (EKS), as a Deployment with at least 3 replicas across AZs, an HPA, readiness and liveness probes, resource requests and limits, and a PodDisruptionBudget.
• Edge: a CDN, then a load balancer / ingress, then an API gateway.
• Data: managed PostgreSQL (RDS, Multi-AZ) per service, Redis for caching and sessions, Kafka (MSK) for events, S3 for files.
• Configuration and secrets: ConfigMaps plus AWS Secrets Manager through External Secrets.
• Observability: Prometheus and Grafana, logs to OpenSearch or Loki, OpenTelemetry traces to Tempo.
• Environments: dev, staging and prod in separate accounts or namespaces, built from the same images.

Q6. How do you create a pipeline in Jenkins?

Short answer: Create a Pipeline (or Multibranch Pipeline) job that reads a Jenkinsfile from the repository, as pipeline as code. Use the declarative syntax, with stages, agents, credentials, post-actions and quality gates.

pipeline {
    agent { label 'docker' }
    options { timeout(time: 30, unit: 'MINUTES'); disableConcurrentBuilds() }
    stages {
        stage('Build & Test') { steps { sh './mvnw -B verify' } }
        stage('Image') {
            when { branch 'main' }
            steps {
                withCredentials([usernamePassword(credentialsId: 'registry', usernameVariable: 'U', passwordVariable: 'P')]) {
                    sh 'docker build -t registry.acme/orders:${GIT_COMMIT} . && echo $P | docker login -u $U --password-stdin registry.acme && docker push registry.acme/orders:${GIT_COMMIT}'
                }
            }
        }
        stage('Deploy staging') { when { branch 'main' } steps { sh './deploy.sh staging ${GIT_COMMIT}' } }
    }
    post { always { junit '**/target/*-reports/*.xml' } failure { slackSend channel: '#orders-ci', message: "Build failed: ${env.BUILD_URL}" } }
}

Q7. A Jenkins pipeline fails intermittently. How do you diagnose and fix it?

Short answer: Treat flakiness as a bug, not bad luck:

1. Collect data. Which stage, which tests, which agents, and what time of day? Correlate the failures (test reports, a flaky-test tracker).
2. Classify the cause:
   • Flaky tests: time-dependent assertions, shared state, test ordering, Thread.sleep, async code without proper waiting (use Awaitility).
   • Environment: disk space, memory, Docker daemon issues, port clashes, dirty agents. Use ephemeral agents and containers.
   • External dependencies: network, rate-limited package mirrors, third-party sandboxes. Cache dependencies and mock external services.
   • Concurrency: parallel builds sharing resources.
3. Reproduce the failure by running the suspicious test in a loop.
4. Fix the root cause. Quarantine known-flaky tests with an owner and a deadline. Use retries only as a temporary measure, because they hide real bugs.

Q8. Scenario: you must roll back a deployment because of a critical bug. What do you do?

Short answer:

1. Decide quickly to roll back, rather than attempt a risky hotfix, and communicate on the incident channel.
2. Redeploy the last known-good artifact. Because images are immutable and versioned, this is quick:
   • Kubernetes: kubectl rollout undo deployment/orders, or re-point the image tag in GitOps.
   • Blue-green: switch traffic back.
   • Canary: abort.
3. Check the database compatibility. If the release ran a migration, the old version must still work with the new schema. This is why schema changes are backward-compatible (expand/contract). Or turn off the feature flag instead.
4. Verify with metrics, error rates and smoke tests.
5. Follow up: root cause, a test that catches it, a blameless post-mortem.

Q9. How do you secure sensitive information, such as API keys, in the deployment process?

Short answer:

• Never in Git or images. Use secret scanning (gitleaks, GitHub push protection).
• Store secrets in a secrets manager (Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager).
• Inject them at runtime, as environment variables or mounted files, through the platform (External Secrets Operator, the CSI driver) or Spring Cloud Vault.
• In CI, use the tool's credential store (Jenkins credentials, GitHub Actions secrets or OIDC federation, so no long-lived cloud keys exist at all). Mask secrets in the logs.
• Apply least privilege, rotation, audit logging, and short-lived dynamic credentials where possible.

Common trap: "Kubernetes Secrets are secure". By default they're only base64-encoded. Enable encryption at rest (KMS), and restrict access with RBAC, or source them from an external manager.

Q10. Describe automating deployments for a microservices architecture.

Short answer (a model story): "We had 18 services deployed by hand-run scripts, and releases took a day. I introduced a shared pipeline template (a reusable workflow), so each service repository got the same stages: build, test, SAST and dependency scans, image build with Jib, image scan, and pushing the image tagged with the commit SHA. Deployment moved to GitOps: Argo CD watching a repository of Helm values, with the pipeline opening an automated PR to bump the image tag. Staging deploys automatically. Production uses canary rollouts with Prometheus-based analysis, and automatic rollback. Deployments went from about 1 a week to about 20 a day, and failed changes are rolled back in minutes."

Key points to cover:

• Mention independent deployability (each service has its own pipeline), contract tests between services, and templating, to avoid 18 slightly different pipelines.

Follow-up questions this topic invites — and their answers

Q: What's the difference between continuous delivery and continuous deployment? A: Continuous delivery: every change is automatically built, tested and made ready to release, and a human approves production. Continuous deployment: every change that passes the pipeline goes to production automatically.

Q: Why tag images with the commit SHA rather than latest? A: SHA tags are immutable and traceable to the exact source. latest is mutable, so you can't tell what's running, and rollbacks become ambiguous.

Q: What is GitOps? A: The desired state of the environment (manifests, Helm values) lives in Git. An agent (Argo CD, Flux) continuously reconciles the cluster to match it. Changes and rollbacks are Git commits, which gives you audit trails and easy reverts.

Q: How do you keep a Jenkins controller secure? A: Run builds on ephemeral agents (never on the controller), keep the plugins minimal and updated, use RBAC, store credentials in Jenkins' credential store or an external vault, and enforce pipeline-as-code with review.