Marsh McLennan Platform Engineer Interview: Questions, Experience & Prep (2026)

Marsh McLennan is a global professional services firm operating four major businesses: Marsh (insurance broking), Guy Carpenter (reinsurance), Mercer (HR consulting), and Oliver Wyman (management consulting). Platform Engineers here build and maintain the internal developer platforms, cloud infrastructure, automation pipelines, and observability tools that keep these businesses running at scale for clients worldwide.

The interview process typically runs across 3-4 rounds. Candidates report starting with a recruiter screen focused on background and role fit, followed by one or two technical rounds covering cloud platforms, infrastructure as code, Kubernetes, CI/CD, and systems design. A final behavioral or leadership round is commonly reported toward the end. The entire process typically happens over video calls.

As of July 2026, knok jobradar tracked 70 open roles at Marsh McLennan across India. Platform Engineer roles across India overall numbered 204, with Bangalore hosting the largest share at 29 openings, followed by Delhi (12) and Pune (10).

1. Walk us through a CI/CD pipeline you built or improved end to end. What tools did you choose and why?

1. How have you used infrastructure as code (Terraform, Pulumi, or similar) in a production environment? What challenges came up?

1. Marsh McLennan handles sensitive client data across insurance and financial services. How have you built security and compliance into your platform work?

1. Describe a time your platform had a significant outage. How did you identify the root cause and prevent recurrence?

1. How do you manage Kubernetes clusters at scale? What day-to-day operational challenges have you solved?

1. Which cloud provider (AWS, Azure, GCP) have you worked with most, and what platform services did you rely on?

1. How do you approach monitoring and observability? Walk us through how you would set up alerting for a new service.

1. Tell us about a time you collaborated with development teams to improve their developer experience. What changed and what was the outcome?

1. How do you handle cost optimization in cloud infrastructure without sacrificing reliability?

1. Describe your experience with secrets management and IAM policies in a large organization.

1. How would you design a multi-tenant platform that isolates workloads across different business units?

1. Tell us about a time you had to make a build-vs-buy decision for a platform component. How did you think through it?

Q: Walk us through a CI/CD pipeline you built or improved end to end.

*Situation:* My team was deploying a microservices application manually, which caused frequent errors and deployment delays stretching over multiple days.

*Task:* I was asked to design and implement an automated CI/CD pipeline that could handle multiple services with different tech stacks.

*Action:* I set up GitHub Actions as the orchestrator, added Docker build stages with layer caching to reduce build time, and used Helm charts for Kubernetes deployments. I introduced environment-specific approval gates for staging and production, and wired in Slack notifications so teams stayed informed throughout the process.

*Result:* Deployments that used to take days came down to under an hour. Rollback became a single command, and deployment-related incidents fell noticeably in the quarter that followed.

---

Q: How have you built security and compliance into your platform work?

*Situation:* My previous company processed financial data and faced an audit finding that secrets were hardcoded in some application configs.

*Task:* I was responsible for rolling out a secrets management solution and enforcing it across all services within a tight deadline.

*Action:* I evaluated HashiCorp Vault and AWS Secrets Manager, and chose Vault for its audit logging and dynamic secrets support. I created a migration guide for developers, ran knowledge-sharing sessions, and added a pre-commit hook that scanned for hardcoded credentials. I also worked with the security team to set rotation schedules for each secret type.

*Result:* Within three months, all services had migrated off hardcoded secrets. The next audit returned zero findings on secrets management, and the team had a repeatable process that new joiners could follow from day one.

---

Q: Describe a time your platform had a significant outage.

*Situation:* A misconfigured Kubernetes resource quota caused a production namespace to reject new pods during a high-traffic period.

*Task:* I was on call and needed to restore service quickly while keeping stakeholders informed throughout.

*Action:* I checked pod events, saw 'Exceeded quota' errors immediately, and temporarily raised the quota to restore service. I then traced the root cause to a recent Helm chart change that had set incorrect resource requests. I rolled back the chart, wrote up the incident, and added a CI check to validate resource configurations before any chart could merge.

*Result:* Total downtime was short. I documented a blameless postmortem and the CI check caught two similar misconfigurations in the following sprint, preventing future incidents.

For behavioral questions, use STAR. Keep each element tight: one or two sentences for Situation and Task, spend most of your time on Action (the 'how'), and close with a Result that is concrete and observable. Avoid vague endings like 'it went well.' Ground the result in something measurable or verifiable.

For technical questions, use Context-Approach-Trade-offs. Open by briefly describing the environment you worked in (scale, constraints, team size). Explain the approach you took and why you chose it over the alternatives. Then acknowledge the trade-offs you accepted. This signals real-world thinking rather than textbook recall.

For systems design questions, clarify before diving in. Ask about scale, regulatory constraints, existing tooling, and team ownership. Marsh McLennan operates in regulated industries, so proactively mentioning compliance, audit logging, and data isolation signals the right instincts and shows you understand the business domain.

Platform Engineers at Marsh McLennan serve internal developers the way a product team serves customers. Interviewers typically look for several clear signals.

Cloud-native depth. Hands-on experience with at least one major cloud provider, Kubernetes operations, and infrastructure as code. Knowing the theory is not enough. Interviewers want to hear what you actually built and what broke along the way.

Security instinct. Financial and insurance platforms operate under strict regulatory requirements. Candidates who proactively mention IAM, audit logging, secrets rotation, and compliance controls stand out. Do not wait to be asked about security.

Developer empathy. The platform exists to help application teams move faster. Candidates who can explain how they reduced friction, improved deployment confidence, or built self-service tooling show they understand the real purpose of the role.

Reliability mindset. Experience with SLOs, on-call processes, blameless postmortems, and incident reviews signals maturity. Stories where you improved reliability over time, not just resolved a single incident, carry more weight.

Ownership. Interviewers want to see that you followed problems from identification through resolution, not just handed them off or waited for others to act.

A focused two-to-three week plan typically covers the key areas well.

Week 1: Technical depth. Revisit your cloud provider's core services (compute, networking, IAM, storage). Practice writing Terraform or Pulumi modules from scratch without looking at docs. Review Kubernetes concepts in depth: namespaces, resource quotas, RBAC, network policies, and Helm chart structure.

Week 2: Design and systems thinking. Practice one or two platform design scenarios. A good starting point is designing an internal developer platform, a multi-tenant Kubernetes setup, or a secrets management rollout for a large organisation. Think through compliance and audit logging at each step, since Marsh McLennan operates in regulated industries where these topics come up naturally in interviews.

Week 3: Behavioral prep and company context. Prepare 6-8 STAR stories covering outages, cross-team collaboration, build-vs-buy decisions, and process improvements. Research Marsh McLennan's four business units and think about what 'internal platform customers' look like inside a global financial services firm. Knowing the business context helps you tailor your answers in a way generic prep does not.

Mock interviews with peers or on a practice platform like Pramp can sharpen your delivery before the real thing.

1. Skipping the 'why.' Listing tools (Terraform, Helm, Prometheus) without explaining why you chose them over alternatives. Interviewers want your reasoning, not a resume recitation.

1. Ignoring security until asked. In a regulated industry like financial services, proactively mentioning compliance, encryption, and audit logging is expected. Waiting to be prompted signals you see it as optional rather than core to the job.

1. Vague outcomes. Answers that end with 'it went well' or 'the team was happy.' Always anchor your result to something observable: uptime improvement, deployment frequency, incident count, or specific feedback from stakeholders.

1. Designing in a vacuum. During systems design questions, not asking clarifying questions about scale, regulatory constraints, or existing tooling signals a lack of real-world experience. Marsh McLennan interviewers value candidates who probe context before proposing solutions.

1. Underplaying collaboration. Platform engineers work across many teams. Candidates who only talk about solo technical work miss a key signal interviewers look for, especially at a firm where the platform must serve diverse business units with different needs.