Chapter 18
The Job Decoded: OpenShift Platform Engineer at a Bank
Before you read, guessHow do the four job description areas relate to the questions and posts in this learning track?
Take ten seconds and guess — even a wrong guess makes the answer stick. Tap to see where the chapter lands, or just read on.
The JD's four areas (OpenShift platform engineering, EKS enablement, automation and DevOps, security and compliance) each map bullet by bullet to a likely question and a post in this track.
The requisition says "OpenShift Support Engineer." The bullets underneath describe a different job: upgrade production clusters, design EKS landing zones, write Terraform, run GitOps, remediate vulnerabilities, lead incident response. That is platform engineering with a modest title, and the interview will be graded like one. This post turns the job description into a study map for Posts 19–35, explains how a vendor-to-bank interview loop runs, and gives you the regulated-environment vocabulary that separates "has used OpenShift" from "has operated OpenShift for a bank." By the end you will know what every JD line is really asking, which post answers it, and the 25 questions to have ready before you walk in.
"Support" means you are the platform team
In a startup, "support engineer" means tickets. In a large bank it means the people who keep the runway open. Application teams (payments, mobile banking, fraud analytics, dozens of them) build and deploy onto the platform. When their Pods will not schedule, their Route returns 503, or their upgrade window is tomorrow, they call you. You are not the person who escalates to the platform team. You are the platform team.
Three things follow, and every section of this post comes back to them:
- You are a service provider with customers. The JD's "onboard application teams" and "platform standards, docs, reusable patterns" bullets are about making that service predictable: Projects with quotas, a golden path to production, a runbook for the ten things that go wrong most often.
- Production is regulated. Every production change needs a ticket, an approver, a window and evidence, because regulators and auditors will ask. The vocabulary comes later in this post.
- Incidents are formal. A Sev-1 has a bridge call, a major incident manager, 30-minute updates and a root-cause analysis with a due date. "Production incident response and RCA" is the part of the job that gets you noticed, for better or worse.
The JD, decoded line by line
The four areas below appear in the posting in this order. For each bullet you get what it looks like on a normal Tuesday, the question it most likely turns into, and the post that prepares you. You already have the Kubernetes half of every answer from Track 1 (RBAC in Post 11, the troubleshooting toolkit in Post 14); this track adds the OpenShift, EKS and bank half.
1. OpenShift platform engineering
The core of the role, where the client panel spends most of its time. "Large environments" means several clusters (development, UAT, production, sometimes per line of business) with hundreds of nodes and Projects. "Lifecycle" means you own the upgrade calendar: OpenShift ships a minor version roughly every four months and supports each for about 18 months, so a bank is always planning the next upgrade. "Troubleshoot" means you are the escalation point for the whole stack, from a stuck MachineConfigPool to a developer's CrashLoopBackOff.
| JD bullet | What they will probably ask | Covered in |
|---|---|---|
| Administer large Red Hat OpenShift environments | "What does OpenShift add on top of Kubernetes, and how do you check cluster health in the first minute?" | Post 19 |
| Cluster upgrades, patching, lifecycle | "Walk me through a production upgrade from 4.16 to 4.17: pre-checks, execution, rollback." | Post 20 |
| Troubleshoot cluster, node, network, storage and app deployment issues | "A node is NotReady." / "Pods cannot reach a Service across namespaces." / "A PVC is Pending." | Post 25, Post 21 |
| Manage Operators, MachineConfig, RBAC, SCCs, monitoring, logging | "What happens when you apply a MachineConfig?" / "Why does this Pod get restricted-v2 and fail?" / "Where do audit logs go?" | Post 23, Post 20, Post 22, Post 24 |
| Onboard application teams | "A new team needs a Project tomorrow. What do you give them and what do you refuse?" | Post 26 |
| Production incident response and RCA | "Tell me about a Sev-1 you led. First ten minutes, and what did the RCA change?" | Post 25, Post 34 |
oc not kubectl, ClusterOperator, ClusterVersion, MachineConfigPool. Post 19 has the translation table; use it until the OpenShift names come out first.2. AWS EKS enablement
"Enablement" is a tell: the bank runs EKS alongside OpenShift, almost certainly in ca-central-1 for data residency, and wants the platform team to own the operating model: clusters from Terraform, not the console; human access through access entries and IAM roles, not shared kubeconfigs; Pod permissions through IRSA or EKS Pod Identity, never the node's instance role. "Collaborate with cloud engineering and architecture" means those teams own the landing zone (accounts, VPCs, Transit Gateway, service control policies) and you meet them at the boundary.
| JD bullet | What they will probably ask | Covered in |
|---|---|---|
| Design, deploy and manage EKS clusters | "Design an EKS cluster for a regulated workload: VPC layout, private API endpoint, node groups, add-ons." | Post 27 |
| Networking, IAM integration, security controls, observability | "IRSA versus Pod Identity?" / "How do you stop the VPC CNI running out of IPs?" / "Which control-plane logs do you enable?" | Post 27, Post 28 |
| Platform operating models, governance | "Who can create a cluster? Who can be cluster-admin? How is that enforced across 40 AWS accounts?" | Post 28, Post 31 |
| Helm, manifests, IaC | "How does a team deploy to EKS here: Helm chart, Argo CD Application, Terraform, or all three?" | Post 30, Post 29, Post 12 |
| Collaborate with cloud engineering and architecture | "The network team owns the VPC. How do you get an EKS change through without owning their Terraform?" | Post 35 |
3. Automation and DevOps
Every bullet here says the same thing: nothing in production should depend on a person remembering to do it. Terraform builds the clusters, CI builds and scans images, Argo CD deploys from Git, and a script runs the health checks before and after every change and produces the evidence auditors will ask for. "Standards, docs, reusable patterns" is the same idea applied to humans: a template Project, a starter Helm chart, a runbook per failure mode.
| JD bullet | What they will probably ask | Covered in |
|---|---|---|
| Terraform IaC | "How do you structure state for many clusters and environments?" / "Plan shows drift in prod. Now what?" | Post 29 |
| CI/CD for containerized workloads | "Draw the pipeline from commit to running Pod, including scanning and approvals." | Post 30 |
| GitOps with Argo CD | "Why GitOps in a bank?" / "App-of-apps or ApplicationSets?" / "A prod app shows OutOfSync at 3 p.m. What do you do?" | Post 30 |
| Automate operational tasks, health checks, validation, compliance reporting | "Prove every cluster has audit logging on, every week, without logging in." | Post 32 |
| Platform standards, docs, reusable patterns | "What is in your golden path for a new microservice?" | Post 26 |
4. Security and compliance
At a bank, security is a set of controls you operate and must be able to prove. "Vulnerability remediation" means CVEs land in your queue with a due date by severity. "Container scanning" means unscanned images do not run. "Secrets management" means a vault, not Git or a ConfigMap, and etcd encrypted at rest. "Audit logging" means API-server audit logs leave the cluster for a SIEM (security information and event management system) the security team can search. "Regulatory requirements" means you know why: OSFI, SOC 2, PCI DSS and internal policy.
| JD bullet | What they will probably ask | Covered in |
|---|---|---|
| Kubernetes/OpenShift security best practices | "Explain SCCs. Why is restricted-v2 the default, and when is anyuid acceptable?" | Post 22 |
| Vulnerability remediation, hardening | "A critical CVE in a base image affects 60 Deployments. Walk me through remediation." | Post 31 |
| Container scanning, secrets management, audit logging, compliance controls | "Where do secrets live?" / "Where do audit logs go and for how long?" / "How do you block an unscanned image?" | Post 31 |
| Enterprise/regulatory requirements | "What does OSFI B-13 mean for how you run a cluster?" / "What evidence does an auditor ask for?" | Post 31, and this post |
How the interview loop usually runs
When a vendor such as HCL places you at a client bank you are interviewed twice: by the vendor, deciding whether to put you forward, and by the client, deciding whether to accept you. Not every bank runs every round, and two are sometimes merged into one 90-minute session, but prepare for all six.
| Round | Who and how long | What it is really grading |
|---|---|---|
| 1. Vendor recruiter screen | Recruiter, 15–30 min, phone or video | Keyword fit (OpenShift, EKS, Terraform, Argo CD), hybrid schedule, rate, start date, work authorization. The recruiter's one-paragraph summary decides whether you go forward, so be crisp and specific. |
| 2. Vendor technical screen | Vendor architect or delivery lead, 30–45 min, video | "Can we put this person in front of the client?" A checklist run: versions upgraded, MachineConfigs written, Argo CD patterns used. Fluency matters more than depth here. |
| 3. Client technical panel | 2–3 senior platform engineers, 45–60 min, video | Depth and honesty. Every answer gets a "why" and a "what if" until they find the edge of what you know. Reaching the edge is fine; bluffing there is not. OpenShift vocabulary is checked constantly. |
| 4. Scenario / troubleshooting round | 1–2 engineers, 45–60 min, video, often a shared doc | Method under pressure: how you scope blast radius, what you check first, how you communicate, when you escalate, whether you think about rollback and change control while fixing. Posts 25 and 34 exist for this round. |
| 5. Hiring manager / behavioral | Platform manager, sometimes with HR, 30–45 min | Will this person survive the bank's process, be trusted with production access, and be pleasant to app teams at 2 a.m.? STAR stories about incidents, changes gone wrong and conflicts with app teams. Post 35. |
| 6. Written or hands-on exercise (sometimes) | Take-home design doc, or a 60-min shared-screen lab | Can you write a runbook others can follow? Can you drive oc? The lab is usually a deliberately broken Deployment, a bad SCC or a stuck rollout. |
The loop takes two to four weeks, followed by a background check (criminal, credit and employment verification are standard for Canadian banks) that can take as long again. Rounds are almost always video: quiet room, working camera, a second monitor with notes and a terminal. If they share a screen, they are not testing typing speed. They are watching whether you run oc get co before anything else.
How banks run platforms
What makes bank platform work different from startup platform work is mostly process, and most of that process comes from ITIL, the IT service management vocabulary large enterprises standardize on. You do not need a certification; you need to speak it naturally.
Incidents, problems and changes
- Incident = an unplanned interruption or degradation of a service. It gets a severity (Sev-1 or P1 for a customer-facing outage, down to Sev-4), a ticket, an owner and, for serious ones, a bridge call run by a major incident manager who is deliberately not the person fixing things. Your job on the bridge is to lead the technical investigation and give clear status: "isolated to the ingress layer, checking the router Pods next, update in 15 minutes."
- Problem = the underlying cause of one or more incidents. A problem record is opened after resolution and the RCA (root-cause analysis) is delivered against it, usually within five business days, with tracked corrective actions. A good RCA is blameless, names contributing factors rather than just the trigger, and produces a change: a new alert, a fixed runbook, an automated check.
- Change = anything that could affect a service. Standard changes are pre-approved and repeatable (a Project from the template). Normal changes are assessed and approved in advance (a cluster upgrade, a new MachineConfig, a Terraform apply that touches node groups). Emergency changes fix production now and are documented and retrospectively approved within a day.
Change management in practice
Normal changes go to the CAB (Change Advisory Board), usually a weekly meeting where you present what you are changing, the risk, the test evidence, the rollback plan and the window. Approved changes run inside a change window (also called a maintenance window): late evening or a weekend, outside trading hours and batch-processing windows. Change freezes cover month-end, quarter-end, year-end and major launches. A cluster upgrade in the last week of a quarter is not happening, and knowing that without being told marks you as someone who has worked in the environment.
Segregation of duties means the person who builds a change does not approve it, and developers hold no write access to production; deployments flow through a pipeline with an approval gate. Four eyes means every production action is reviewed or witnessed by a second person: a pull-request approval, a change-ticket approval, a second engineer on the call during the window. When you describe a production action in an interview, put the second pair of eyes in the story.
Audit evidence is what auditors want instead of your word: the change-ticket number, the approval, the pipeline run, the pre- and post-check output, the Argo CD sync history, the CloudTrail entries, the API-server audit-log line. This is why the JD puts "compliance reporting" under automation: evidence should be produced by the pipeline, not assembled by hand the week before the audit.
Who is watching
Canada's federal banking regulator is OSFI (Office of the Superintendent of Financial Institutions). Its Guideline B-13, Technology and Cyber Risk Management, in force since January 2024, sets expectations for technology operations, change management, resilience, vulnerability management and incident reporting. Guideline B-10 covers third-party risk, which is why the bank cares how a vendor engineer reaches production: through a privileged-access system with a jump host, MFA and recorded, time-boxed sessions, not a kubeconfig on a laptop. SOC 2 is an independent auditor's report on a service provider's controls; the bank demands it from providers and often holds its own shared platforms to the same criteria. PCI DSS (version 4.x) governs anything touching cardholder data: network segmentation, quarterly vulnerability scans, twelve months of log retention with three months immediately searchable, strict access reviews. You are not expected to quote clauses. You are expected to know these names, know they become controls you operate, and never sound surprised that a change needs a ticket.
kubectl apply the fix to prod" or "I would hot-patch the node and open a ticket later" ends the interview at a bank, even if the fix is right. The phrasing they want: "I would raise an emergency change, get the on-call approver on the bridge, apply the fix through the pipeline or with a second engineer watching, capture the before-and-after output for the change record, and open the problem record for the RCA." Same fix, told by someone who has worked in regulated production.The mindset the JD keeps signalling
Read the JD's verbs again: automate, standardize, lead, document, collaborate, "independently." Four traits are being described, and interviewers listen for them in how you tell stories, not in whether you claim them.
- Automation-first. The phrase: "The second time I did it by hand I wrote it down; the third time I scripted it." The example: a pre-upgrade script that captures
oc get clusterversion,oc get co,oc get mcp,oc get nodesand Pending Pods into a timestamped file attached to the change ticket, then runs again afterwards and diffs. One story, three traits: automation, change discipline, audit evidence. - Independent but collaborative. The phrase: "I own the outcome, but I do not make production decisions alone." The example: you diagnose that an ingress problem is really an external load-balancer health check and, instead of working around it, bring the network team onto the bridge with the evidence and a proposed fix.
- Leads troubleshooting. The phrase: "I take the technical lead on the bridge: state the symptom, scope the blast radius, ask what changed, work the layers, timebox each hypothesis, update every 15 to 30 minutes." Post 25 turns that sentence into a method. In the scenario round, say it before you name a single command.
- Documents and standardizes. The phrase: "I turned the fix into a standard so it cannot recur." The example: after three teams hit the same SCC failure, you add the right
securityContextto the starter Helm chart, write a runbook entry with the exact error string, and add a pipeline check that rejectsrunAsUser: 0. Standardization is a story with a before and an after.
Your study plan for this track
Posts 19–35 are in dependency order: OpenShift internals, then operating and securing them, then EKS, then the automation layer that spans both, then three rehearsal posts. Total reading time is about 468 minutes, just under eight hours.
| Post | Topic | Time | Priority |
|---|---|---|---|
| 19 | OpenShift architecture: what Red Hat adds | 28 min | Must read |
| 20 | Cluster lifecycle: MachineConfig, upgrades, etcd | 30 min | Must read |
| 21 | Networking and storage end to end | 30 min | Must read (storage half doubles as a reference) |
| 22 | Security: SCCs, RBAC, OAuth, hardening | 30 min | Must read |
| 23 | Operators and OLM | 22 min | Skim if short on time |
| 24 | Monitoring and logging | 26 min | Should read |
| 25 | Troubleshooting playbook and incident response | 32 min | Must read; re-read the night before |
| 26 | Onboarding app teams and golden paths | 24 min | Skim if short on time |
| 27 | EKS part 1: architecture, networking, IAM | 30 min | Must read |
| 28 | EKS part 2: operations, upgrades, security, cost | 30 min | Must read |
| 29 | Terraform for platform engineers | 26 min | Should read |
| 30 | CI/CD and GitOps with Argo CD | 30 min | Must read |
| 31 | Security, compliance and hardening | 26 min | Must read |
| 32 | Automation: Python, shell, Ansible, the API | 22 min | Skim if short on time |
| 33 | Interview question bank | 35 min | Must read; re-read the night before |
| 34 | Scenario interviews: production incidents | 30 min | Must read; re-read the night before |
| 35 | Behavioral round and questions to ask | 17 min | Must read |
A comfortable schedule is six evenings of about 80 minutes: 19–21, 22–24, 25–26, 27–29, 30–32, 33–35. Keep the night before for re-reading 25, 33 and 34 only; start nothing new that night. With three evenings, read 19, 20, 21, 22, 25, 27, 28, 30, 31, 33, 34 and 35 in that order and skim 23, 24, 26, 29 and 32 on the morning of the interview.
Reading is not enough for the scenario round; you need oc in your fingers. Three labs, closest to the real thing first:
- OpenShift Local (formerly CodeReady Containers; the binary is still
crc) runs single-node OpenShift in a VM on your laptop. It needs a free Red Hat account for the pull secret and at least 16 GB of RAM, since the VM wants 9–11 GB. It is the only option with cluster-admin, ClusterOperators, MachineConfigs and the full console. - Red Hat Developer Sandbox is a free shared cluster in the cloud with a Project for 30 days. No cluster-admin, so no upgrades or MachineConfigs, but ideal for Routes, SCC behaviour and
ocfluency within five minutes. - minikube + Argo CD is the lightweight lab for Posts 30 and 32: no OpenShift objects, but GitOps end to end.
For OpenShift Local, download crc and your pull secret from console.redhat.com/openshift/create/local, then:
$ crc setup
$ crc start --pull-secret-file ~/Downloads/pull-secret.txt
INFO Starting CRC VM for openshift 4.18.2...
...
Started the OpenShift cluster.
The server is accessible via web console at:
https://console-openshift-console.apps-crc.testing
$ eval $(crc oc-env)
$ crc console --credentials
$ oc login -u kubeadmin https://api.crc.testing:6443
$ oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.18.2 True False 6m Cluster version is 4.18.2
$ oc get co | head -5
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE
authentication 4.18.2 True False False 4m
console 4.18.2 True False False 3m
dns 4.18.2 True False False 6m
etcd 4.18.2 True False False 6mIf your laptop cannot spare the memory, use minikube and install Argo CD from its documented manifest:
$ minikube start --cpus=4 --memory=8g
$ kubectl create namespace argocd
$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
$ kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo
$ kubectl port-forward svc/argocd-server -n argocd 8080:443Log in at https://localhost:8080 as admin with that password. Post 30 reuses this lab.
oc get co is not in the interview. On OpenShift Local, run oc get co, oc get mcp and oc get nodes and explain every column header to yourself; then run oc describe scc restricted-v2 and note which fields would block a container that wants to run as root. On minikube, create one Argo CD Application from any public Helm repo and watch OutOfSync appear when you edit the live Deployment by hand. Under an hour either way, and it pays for itself in round 4.The 25 questions most likely to be asked
These appear, in some form, in almost every loop for this role. The answers are the 30-second version; each points to the post with the five-minute version and the follow-ups. If you can answer all 25 without notes, you are ready for the client panel.
OpenShift administration
See Posts 19, 20, 24, 25 & 261. What does OpenShift add on top of Kubernetes?
An integrated, opinionated distribution: immutable RHCOS nodes managed by the Machine Config Operator, CRI-O, OVN-Kubernetes, a built-in OAuth server, Routes with the HAProxy Ingress Controller, an internal registry, Prometheus monitoring, Operator Lifecycle Manager, SCCs, and upgrades driven by the Cluster Version Operator. Post 19.
2. How do you check cluster health in the first minute?
oc get clusterversion, then oc get co (every ClusterOperator Available True, Progressing False, Degraded False), then oc get nodes, oc get mcp, and oc get pods -A | grep -v Running | grep -v Completed. Post 25.
3. Walk me through a production upgrade.
Pre-checks (ClusterOperators healthy, MachineConfigPools updated, fresh etcd backup, oc adm upgrade showing the target in the channel, removed-API acknowledgements in the admin-acks ConfigMap), then inside the window oc adm upgrade --to=<version> while the CVO rolls the control plane and the MCO rolls each pool one node at a time, one minor version per change, followed by post-checks and smoke tests. Post 20.
4. What happens when you apply a MachineConfig?
The MCO renders a new configuration for the pool, then for each node (up to maxUnavailable, default 1) cordons, drains, writes the config, reboots and uncordons. You never edit RHCOS by hand; a bad MachineConfig shows as a Degraded MachineConfigPool. Post 20.
5. How do you back up etcd?
On a control-plane node via oc debug node/<master> and chroot /host, run /usr/local/bin/cluster-backup.sh /home/core/assets/backup, then ship the snapshot off the node. Schedule it and rehearse the restore in non-prod; a restore rolls the whole cluster back in time and is a last resort. Post 20.
6. A node is NotReady. What do you do?
Scope first (one node, one pool, or one availability zone?), then oc describe node for conditions and taints, oc get mcp to rule out an in-progress rollout, oc adm node-logs <node> -u kubelet for the kubelet's view, and oc debug node/<node> to check the host. Post 25.
7. How does logging work on OpenShift today?
The Cluster Logging Operator runs Vector collectors, Loki (a LokiStack from the Loki Operator) stores the logs, and a ClusterLogForwarder routes application, infrastructure and audit logs to Loki and to an external SIEM for long-term retention. EFK is retired. Post 24.
8. A new team needs a Project. What do you give them?
A Project from the template with a ResourceQuota, a LimitRange, a default-deny NetworkPolicy, an RBAC binding for their directory group, an Argo CD Application and the starter Helm chart. Not cluster-admin, not anyuid, not host-mounted volumes. Post 26.
Amazon EKS
See Posts 27 & 289. How do Pods get AWS permissions on EKS?
IRSA (an IAM OIDC provider trusts the cluster, the ServiceAccount carries a role ARN annotation, the Pod gets a projected token) or EKS Pod Identity (an agent add-on plus a pod-identity association, no per-cluster OIDC trust policy). Either way, never the node's instance role. Post 27.
10. How does human access to EKS work now?
Access entries map IAM principals to Kubernetes identities and access policies such as AmazonEKSClusterAdminPolicy, replacing the aws-auth ConfigMap, which still works for compatibility but is no longer the design. Post 27.
11. The VPC CNI is running out of IP addresses. Options?
Pods consume VPC IPs, so size subnets generously, enable prefix delegation so each ENI hands out /28 blocks, add a secondary CIDR with custom networking so Pods draw from their own subnets, and pick instance types whose ENI limits match the Pod density. Post 27.
12. How do you upgrade EKS?
Control plane first, one minor at a time, in place; then managed node groups (rolling AMI replacement) or let Karpenter drift nodes; then the managed add-ons (VPC CNI, CoreDNS, kube-proxy). Stay inside the roughly 14-month standard support window, because extended support bills about six times the standard per-cluster-hour rate. Post 28.
13. Karpenter versus Cluster Autoscaler, and what is EKS Auto Mode?
Cluster Autoscaler resizes existing node groups; Karpenter provisions right-sized nodes straight from pending Pods and consolidates underused ones. Auto Mode has AWS manage nodes, networking and storage components for you; a bank will ask exactly what control it gives up. Post 28.
Terraform, CI/CD and GitOps
See Posts 29, 30 & 3214. How do you structure Terraform state for a platform?
Remote state in S3 with locking, one state per cluster per environment, modules for the repeatable parts (VPC, EKS, node groups, add-ons), no secrets in state, and applies that run only from a pipeline after a reviewed plan. Post 29.
15. Terraform plan shows drift in production. Now what?
Do not apply. Find what changed and who (CloudTrail, the change log), decide whether to import or revert, and treat it as a change-management event; prod drift is usually a break-glass action nobody documented. Post 29.
16. Draw the pipeline from commit to running Pod.
CI builds, tests, scans and signs the image, pushes it, and opens a pull request bumping the tag in the environment repo; a reviewer approves (four eyes), Argo CD syncs, and the production sync waits for the change window and an approval gate. Post 30.
17. Why GitOps in a bank?
Git becomes the audit trail (every prod state has a commit, author, reviewer and timestamp), Argo CD's sync history is evidence, drift is detected rather than silently applied, and segregation of duties holds because nobody applies by hand. Post 30.
18. Prove every cluster has audit logging enabled, weekly, without anyone logging in.
A scheduled job (CronJob, pipeline schedule or Ansible playbook) with a read-only ServiceAccount reads each cluster's APIServer configuration and ClusterLogForwarder, writes a dated report to the evidence store, and pages the platform channel on failure. Post 32.
Security and compliance
See Posts 22 & 3119. Explain SCCs.
Security Context Constraints are OpenShift's admission control over what a Pod may request (UID ranges, capabilities, host namespaces, volume types), and a Pod is admitted under the most restrictive SCC its ServiceAccount may use, restricted-v2 by default. Fix images to run as non-root rather than granting anyuid. Post 22.
20. A critical CVE affects 60 Deployments. Walk me through remediation.
The scanner lists affected images, you triage by exposure and severity, patch the shared base image once, rebuild through CI, roll out through Argo CD to non-prod then prod inside the SLA for that severity, and close with the rescan as evidence. Post 31.
21. Where do secrets live?
In a vault (HashiCorp Vault or AWS Secrets Manager) synced into the cluster by the External Secrets Operator or the Secrets Store CSI driver; never in Git or a ConfigMap; etcd encrypted at rest; secret reads audited. Post 31.
22. Where do audit logs go and for how long?
OpenShift API audit logs (profile set on the cluster APIServer resource) and EKS control-plane logs (to CloudWatch) are forwarded to the SIEM and retained per policy, typically a year with recent months searchable, which is what PCI DSS expects. Post 31.
Process and behavioral
See Posts 34 & 3523. Tell me about a production incident you led.
STAR with numbers: what broke and for whom, how you scoped it, what you checked first, how you communicated on the bridge, what the RCA changed. End on the prevention, not the fix. Post 35.
24. A developer asks you for cluster-admin. What do you say?
No, followed by what they actually need: the admin role scoped to their Project, view rights where they debug, a golden path, and twenty minutes of your time. Developer cluster-admin fails segregation of duties and would not survive an access review. Post 26.
25. An app team needs a change in prod today, outside the window. What do you do?
Ask what happens if it waits. Real customer or regulatory impact means an emergency change with the on-call approver, four eyes and captured evidence; anything less means booking the next window and helping them use it well. Post 35.
Key Takeaways
- "OpenShift Support Engineer" at a bank is a platform engineering role: you own the clusters, the guardrails and the incident bridge, and application teams are your customers.
- The JD's four areas (OpenShift platform engineering, EKS enablement, automation and DevOps, security and compliance) each map bullet by bullet to a likely question and a post in this track.
- A vendor placement means two loops: the vendor's screens decide whether you are forwarded, the client's technical panel, scenario round and manager round decide whether you are hired. Give versioned, specific answers in every round.
- Speak ITIL naturally: incident, problem, change; standard, normal and emergency changes; CAB, windows and freezes; segregation of duties, four eyes and audit evidence. Never describe a production fix without an approver and a record.
- Know the names behind the process (OSFI B-13 and B-10, SOC 2, PCI DSS 4.x) and that they become controls you operate, not paperwork someone else handles.
- Show the four traits the JD signals (automation-first, independent but collaborative, leads troubleshooting, documents and standardizes) through stories with a before and an after.
- Read Posts 19–35 in order (about eight hours), re-read 25, 33 and 34 the night before, and get
ocin your fingers on OpenShift Local or the Developer Sandbox before the scenario round.