Advanced everything in DevOps & Cloud, page 8
Discuss security implications of developer-defined PaC pipelines
It tests balancing CI/CD flexibility with defense-in-depth against secret exfiltration. Cover scoped build identities, branch policies, approval gates, and sandboxed fork builds. Red flag: shared service connections or unrestricted pipeline admin rights.
Standardize and update CI/CD across hundreds of microservices without per-repo edits
Repos use a thin wrapper importing versioned shared-library templates; a control plane rolls out updates with canary validation.
How do you manage multi-arch container images under a single tag?
This tests image distribution and registry semantics. A strong answer covers manifest lists pointing to per-arch digests, Buildx as the builder driver, and the registry serving correct layer blobs.
Integrate artifact signing and vulnerability scanning into CI/CD
Build SBOMs, sign with ephemeral keys, scan registries, and enforce policy before deploy.
How would you diagnose, report, and mitigate E2E flakiness at scale?
Tests metric-driven pipeline hygiene versus retry band-aids. Strong answers baseline flakiness rates, identify offenders via CI history, quarantine chronic flakes from presubmit, and fix root causes like concurrency.
Smoke test fails after canary deployment. Design the automated rollback.
Tests self-healing pipeline design: freeze canary traffic, auto-redeploy the last good release, verify rollback health, and keep failed pods for forensics. Red flag: requiring manual approval or in-place fixes instead of an atomic rollout swap.
Compare git submodules and git subtree for CI/CD
Tests dependency integration trade-offs in CI. Submodules need recursive clones and pinned commits, complicating checkout; subtree inlines code, simplifying clone but bloating history. Red flag: omitting submodule detached HEAD pain or calling subtree free.
How do you fully remove leaked credentials from Git history?
This tests Git history rewriting and incident response. Rotate the secret first, then use git-filter-repo to purge the file, force-push main, and require all teammates to re-clone before resuming. A red flag is recommending git revert or skipping rotation.
How does your CI/CD strategy differ between monoliths and microservices?
Contrast monolith unified builds with microservice independent deploys, side-by-side versions, and service gates.
Pipeline is green but lead time grows. Three areas to investigate?
This tests distinguishing pipeline health from delivery flow efficiency. A strong answer targets pre-merge wait states, slow green pipeline stages, and post-merge deployment friction, using time-in-stage metrics.
The Ironies of Automation: More Automation, More Problems?
Automating a system to reduce human error makes the human's role more critical, not less. The more reliable the automation, the less practice operators get for the rare, high-stakes moment it inevitably fails, leaving them unprepared to take control.
Customer Reliability Engineering: SRE for Your Customers
CRE extends SRE principles to your customers, making their reliability a shared goal. A provider partners with a key customer to co-engineer resilient services on their platform.
Just Culture: Fix the System, Not the Blame
Just Culture treats human error as a system failure, not a personal one. It's key for incident post-mortems, encouraging honest reporting to improve reliability.
Shift-Left Resilience: Chaos in Your CI/CD Pipeline
Think of it as an automated stress test in your build pipeline that breaks things on purpose. It runs alongside integration tests, injecting faults like pod failures to find weaknesses before a merge.
Resilience Engineering: Studying Success, Not Just Failure
Resilience Engineering studies how systems succeed despite surprises, not just why they fail. It applies to incident analysis and chaos engineering, focusing on building adaptive capacity for unknown events rather than just preventing known failure modes.
FMEA: Systematically Mapping What Could Go Wrong
FMEA is a structured pre-mortem for system components, cataloging potential failures, their causes, and their effects. It's used in system design to proactively identify risks before they become outages. The footgun is treating it as a one-time task.
Threat Modeling for Reliability: Find Failures Before They Happen
Threat modeling for reliability is like pre-gaming an outage: you systematically ask "how will this break?" before shipping code. Instead of attackers, you model failures like a database failing or a cloud region going down, then design mitigations.
Data Sharding: Splitting a Database for Scale
Sharding splits a huge database into smaller, independent databases (shards), each on its own server. It's like giving different volumes of a phone book to different librarians. This is critical for massive datasets, but a bad shard key creates 'hot spots'.
Bulkhead Pattern: Isolate Failures, Protect Your System
The Bulkhead pattern partitions a system like a ship's hull, containing failures to prevent a total outage. By isolating resource pools for each service or consumer, a fault in one component won't cascade and take down the entire application.
Universal Scalability Law: The Physics of Scaling
The Universal Scalability Law (USL) models throughput by quantifying the two costs of parallelism: contention and coherency. Use it to forecast performance and diagnose bottlenecks.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles