エピソード

  • AWS Service Control Policies: Prevent Region Sprawl

    AWS Service Control Policies: Prevent Region Sprawl
    2026/11/04
    A walkthrough of writing AWS Service Control Policies that restrict resource creation to approved regions while carving out exceptions for global services like IAM, CloudFront, and Route 53. Covers the aws:RequestedRegion condition key, common SCP mistakes, and how to answer this question in a DevOps or cloud security interview.Full interview prep guides and scenario walkthroughs: DevOpsInterview.CloudDaily 30-second interview drills: DevOps Interview Cloud on YouTubeTranscriptAn audit runs across your AWS Organization and the output is ugly. Resources sitting in fifteen regions nobody approved. EC2 instances in ap-southeast-2, an RDS cluster in sa-east-1, a stray VPC in eu-north-1. Nobody remembers creating most of it. That's region sprawl, and it's one of the most common findings in a cloud security review, because by default AWS lets any account with the right IAM permissions spin up resources in any region on earth.Interviewers ask about this because it tests three things at once. Do you understand the difference between IAM policies and Service Control Policies, or SCPs. Do you know how AWS evaluates deny logic across an Organization. And can you actually write a policy that blocks sprawl without breaking services that are inherently global, like IAM or CloudFront. A lot of candidates can say "use an SCP" but fall apart the moment you ask them to handle the global service exceptions. That's the part that separates people who've read about SCPs from people who've actually deployed one.Here's the mental model. An SCP doesn't grant any permissions. It's a guardrail, not a grant. Every account in your Organization already gets whatever IAM policies and roles say it can do. The SCP sits above that, at the Organization or Organizational Unit level, and it filters the maximum available permissions. Think of IAM as the accelerator and SCP as a speed limiter bolted onto the engine. If the SCP denies an action, it doesn't matter what the IAM policy says, even a full admin role can't override an SCP denial. That's why SCPs are the right tool for org-wide guardrails like region restriction, instead of trying to chase down every IAM policy in every account.The core mechanism is a condition key called aws colon RequestedRegion. You write a deny statement with a wildcard action, a wildcard resource, and a condition that says: if the requested region is not in my approved list, deny everything. Something like this. Effect deny, action star, resource star, condition StringNotEquals on aws colon RequestedRegion, with a list of your approved regions, say us-east-1, us-west-2, and eu-west-1 if you're a US and UK facing company. Attach that SCP to the root of the Organization, or to a specific Organizational Unit if you want different rules per business unit, and now any API call targeting a region outside that list gets an explicit deny, no matter which account or which IAM role makes the call.But if you stop there, you break your own Organization. A chunk of AWS services are global and don't have a regional home the way EC2 or RDS do. IAM itself is global. Organizations is global. Route 53 is global. CloudFront is global, and if you're using CloudFront with a custom certificate, that certificate has to live in ACM in us-east-1 specifically, regardless of where your users are. AWS Support, AWS Billing, AWS WAF when attached to CloudFront, and AWS Shield also operate globally or default to us-east-1 under the hood. If your deny statement doesn't carve these out, you'll lock yourself out of managing users, you'll break certificate issuance for your content delivery network, and you'll have people filing tickets within the hour.The fix is to add a NotAction clause, or layer a second condition, that excludes the actions belonging to those global services from the region check. In practice this looks like a list of service prefixes you exclude: iam colon star, organizations colon star, route53 colon star, cloudfront colon star, support colon star, and the global billing and cost management actions. You put those under NotAction in the same deny statement, so the statement reads: deny everything, on every resource, when the region isn't approved, except for these specific global service actions. That's the version that actually survives contact with a real Organization.Let's walk through the logic step by step the way you'd explain it on a whiteboard. First, decide your approved region list based on where your actual customers and compliance requirements sit. For a company serving the US and UK, that might be us-east-1 for primary workloads, us-west-2 for disaster recovery, and eu-west-1 for UK and EU data residency. Second, write the deny statement with action star and resource star, scoped by the RequestedRegion condition using StringNotEquals against that list. Third, add the NotAction exclusion list for IAM, Organizations, Route 53, CloudFront, Support, Trusted Advisor, and the Billing console actions, because none of ...
    続きを読む 一部表示
    10 分
  • SQS Dead Letter Queue Storm: Diagnose and Recover

    SQS Dead Letter Queue Storm: Diagnose and Recover
    2026/10/31
    You wake up to 10,000 messages in your SQS dead letter queue — here's the systematic CloudWatch-driven approach to diagnosing the root cause and safely replaying messages without triggering a second storm.You'll learn:Which four CloudWatch metrics to pull first (ApproximateNumberOfMessagesVisible, NumberOfMessagesReceived, NumberOfMessagesDeleted, ApproximateAgeOfOldestMessage) and how to read the curve shape to distinguish a deploy failure from resource exhaustionWhy redriving immediately is the most common wrong answer — and how to confirm the root cause is actually resolved before touching the DLQHow visibility timeout math interacts with Lambda timeouts to silently manufacture poison pill storms at scaleUsing StartMessageMoveTask (or the console's Start DLQ redrive) for rate-controlled replay instead of a manual receive-delete-republish loopHow to set maxReceiveCount deliberately — why 1-2 is too aggressive and 10 is too lax, and how to align visibility timeout to your p99 processing timeKeywords: SQS dead letter queue, DLQ redrive policy, SQS visibility timeout, AWS SQS CloudWatch metrics, SRE interview questions AWS🎧 Listen, then go deeper — DevOps & Cloud interview-prep ebooks at DevOpsInterview.Cloud▶ Daily 30-second interview drills: DevOps Interview Cloud on YouTubeTranscriptYou wake up to a Slack alert. Your dead letter queue, the DLQ, has ten thousand messages sitting in it. Somewhere overnight, a queue that normally holds zero items quietly filled up, and nobody got paged until the number crossed a threshold. This is one of those incidents that looks small until you realize it might mean ten thousand failed payments, ten thousand missed notifications, or ten thousand orders stuck in limbo.Interviewers love this scenario because it tests three things at once. Can you read CloudWatch metrics fast enough to find the actual root cause instead of guessing. Do you understand how a redrive policy and visibility timeout interact. And can you recover the messages without making the outage worse by replaying them straight into the same failure loop.Start with the mental model. In SQS, every queue can have a redrive policy pointing to a dead letter queue, along with a maxReceiveCount. Every time a consumer pulls a message and fails to delete it, either by crashing, throwing an error, or just running past the visibility timeout, the receive count on that message goes up by one. Once it crosses maxReceiveCount, SQS automatically moves that message to the DLQ. The DLQ is not where messages go when something is broken right now, it is where they go after they have already failed a set number of times. So by the time you see ten thousand messages there, the failures happened earlier and repeated, meaning you are looking at an aftermath, not a live fire.First move: resist the instinct to immediately redrive the messages back to the source queue. That is the single most common wrong answer, and it will just refill the DLQ again if the underlying cause is still active. Diagnose first.Open CloudWatch and pull four metrics for the source queue: ApproximateNumberOfMessagesVisible, NumberOfMessagesReceived, NumberOfMessagesDeleted, and ApproximateAgeOfOldestMessage. Then pull ApproximateNumberOfMessagesVisible for the DLQ itself, graphed over the last twelve hours. You are looking for the shape of the curve. A sudden vertical jump around a specific timestamp tells you something changed at that moment, like a deploy, a dependency outage, or a config push. A slow staircase climbing over hours usually points to a resource exhaustion problem, like a database connection pool filling up under load.Next, check your consumer's own logs or traces around that timestamp. In a Lambda-based consumer, look at Errors and Throttles in CloudWatch for the function, plus Duration against your function timeout. A classic failure pattern: someone set the Lambda timeout to three seconds, a downstream API started taking four seconds under load, every invocation started timing out, SQS saw the message never get deleted, the visibility timeout expired, the message came back, failed again, and after three or five retries it landed in the DLQ. Multiply that by every message hitting the same slow endpoint and you get your ten thousand.Another classic: a single malformed message, a poison pill, causes a parsing exception on every attempt. But a poison pill alone usually only produces one or two hundred failures before someone notices, not ten thousand, unless the queue has heavy throughput. If you see ten thousand nearly identical failures with the same exception type and the same payload shape, that is a code or schema problem, not a flaky dependency. If you see varied payloads but a shared downstream timeout pattern, that is capacity, not code.Once you know the category, check whether it is still happening. Look at the error rate for the last fifteen minutes, not twelve hours ago. If errors are still climbing, fix the root ...
    続きを読む 一部表示
    8 分
  • RDS Proxy: Fixing Lambda Connection Exhaustion

    RDS Proxy: Fixing Lambda Connection Exhaustion
    2026/10/28
    RDS Proxy solves the Postgres connection exhaustion that hits when Lambda bursts from 10 to 2,000 concurrent invocations faster than your database can fork new OS processes.You'll learn:Why Lambda's parallelism model collides with Postgres's per-connection process model — and why this is a common senior interview trapHow RDS Proxy multiplexes thousands of client-side Lambda connections onto a small warm pool of real backend connectionsExactly what causes pinning — session variables, temp tables, advisory locks, multi-statement transactions, and some prepared statement patterns — and how pinning defeats pooling entirelyHow to set max connections percent and max idle connections percent to leave headroom for non-proxy clients like migration jobsWhy connection borrow timeout should be kept short so failures surface as fast, retriable errors rather than Lambda timeouts holding resourcesKeywords: RDS Proxy interview questions, Lambda database connection pooling, Postgres connection exhaustion serverless, RDS Proxy pinning causes, Aurora Lambda architecture🎧 Listen, then go deeper — DevOps & Cloud interview-prep ebooks at DevOpsInterview.Cloud▶ Daily 30-second interview drills: DevOps Interview Cloud on YouTubeTranscriptPicture a Lambda function behind an API Gateway, and it spikes from ten concurrent invocations to two thousand in under a minute. Every one of those invocations opens its own connection to a Postgres RDS instance. Within seconds, Postgres hits its max connections limit, new invocations start throwing connection refused errors, and your error rate graph goes vertical. Nothing about your code changed. Traffic just moved faster than your database could handle new sessions.Interviewers ask about this because it's a trap that catches people who understand Lambda and people who understand databases separately, but not the seam between them. Lambda scales by running many isolated execution environments in parallel, and each one that needs a database connection opens a fresh TCP connection and does a Postgres handshake. Postgres, unlike a typical application server, forks a full OS process per connection, which is expensive in memory and CPU. That's why Postgres defaults usually cap out around one hundred connections, sometimes a few hundred on larger instance classes. Lambda doesn't know or care about that number. You get a mismatch between a scale-to-zero compute model and a stateful, connection-limited database.The mental model here is pooling versus parallelism. Lambda gives you parallelism almost for free. Postgres gives you a hard ceiling on parallel connections. You need something in between that absorbs the burst and smooths it into a connection count the database can sustain. That's the job of RDS Proxy. It sits between your Lambda functions and your RDS or Aurora instance, maintains a warm pool of real database connections, and lets many client-side connections from Lambda multiplex onto a much smaller number of actual backend connections. Lambda thinks it's getting its own connection. Underneath, the proxy is reusing a handful of real ones.Here's how it works. Your Lambda function talks to the proxy endpoint, not Postgres directly. The proxy accepts that connection cheaply because it already holds a pool of established, authenticated backend connections. When your function sends a query, the proxy borrows a pooled backend connection, runs the query, returns the result, and hands that connection back to the pool once your logical unit of work is done. So two thousand invocations each making a quick query might only need twenty or thirty actual Postgres connections, because the proxy cycles them fast.Now the part that actually gets tested: pinning. Pinning happens when the proxy can no longer safely multiplex a client connection onto different backend connections, so it locks that client to one specific backend connection for the rest of its session. Once pinned, you lose the pooling benefit for that session entirely, and if enough sessions pin at once, you're back to the same exhaustion problem you were trying to avoid.Know these triggers cold. Session-level state, like session variables, temp tables, or a changed search path, forces a pin because the proxy can't guarantee that state exists on a different backend next time. Explicit multi-statement transactions pin you to one backend until the transaction resolves. Session-scoped functions and settings, like changing client encoding or using advisory locks, pin because they're tied to a specific backend session. And prepared statements, depending on driver behavior, can pin because the statement lives on a specific backend connection.The practical fix is mostly behavioral. Keep Lambda database interactions short and stateless: open a connection, run your query or a tightly scoped transaction, close it, done. Avoid session-level variables, set things like statement timeout per-query instead of per-session, and commit promptly ...
    続きを読む 一部表示
    8 分
  • EKS Control Plane Logs: Audit Trail for a Compliance Breach

    EKS Control Plane Logs: Audit Trail for a Compliance Breach
    2026/09/16
    A walkthrough of EKS control plane logging for security investigations: which of the five log types actually capture who did what, how to write CloudWatch Logs Insights queries against audit logs, and how to build a metric filter alert on sensitive verbs like delete and create against secrets, roles, and the aws-auth configmap. Visit https://devopsinterview.cloud for interview prep ebooks, roadmaps and hands-on incident labs. Transcript A compliance audit flags a handful of API calls on your EKS cluster that nobody can explain. Someone created a cluster role binding last month. Someone else deleted a secret three weeks ago. The security team wants a name, a timestamp, and a source IP, and you go looking for the trail only to find that nobody turned on the logging that would have captured any of it. That gap is exactly what this question is testing, and it comes up constantly in SRE and platform interviews because it sits at the intersection of Kubernetes internals, AWS billing tradeoffs, and actual incident response. Interviewers ask this because almost everyone can say the phrase enable control plane logging, but very few can explain which of the five log types actually gives you an audit trail versus which ones are just operational noise. It also tests whether you understand that CloudTrail and Kubernetes audit logs are answering two completely different questions, which is a mistake that trips up even experienced engineers. Here's the mental model. EKS gives you five control plane log types: api server, audit, authenticator, controller manager, and scheduler. The controller manager and scheduler logs are mostly useful for debugging cluster behavior, like why a deployment isn't scaling or why pods are stuck pending. They're not what you want for a security investigation. The api server log shows you raw requests hitting the API server, which is useful but incomplete on its own. The two log types that actually matter for a compliance breach are audit and authenticator. The audit log is the Kubernetes API server's own audit trail. Every request that mutates or reads cluster state gets recorded with the verb, like get, create, update, patch, or delete, the object reference, meaning the resource type and namespace, the user identity, the source IP, the user agent, and a timestamp. This is your who-did-what record. The authenticator log is specific to EKS and shows you how IAM identities get mapped into Kubernetes RBAC through the aws-auth configmap or access entries. If someone's IAM role suddenly started acting like cluster-admin, the authenticator log is where you see that mapping happen. A critical point that trips people up in interviews: CloudTrail does not give you this. CloudTrail logs calls to the EKS control plane itself, things like CreateCluster, UpdateNodegroupConfig, or DescribeCluster. It has no visibility into what happens once a request reaches the Kubernetes API server inside the cluster. If someone uses kubectl to delete a secret or create a role binding, that's a Kubernetes API call, not an AWS API call, and CloudTrail simply won't see it. This distinction alone is a good signal in an interview because it shows you actually understand where the AWS control plane ends and the Kubernetes control plane begins. Now the walkthrough. First you enable the logging. Using the AWS command line, you'd run something like aws eks update-cluster-config, specifying your cluster name and a logging block that turns on the api, audit, and authenticator types, and explicitly turns off controller manager and scheduler if you don't need them. Once that's live, EKS starts streaming logs into a CloudWatch log group named something like slash aws slash eks slash your-cluster-name slash cluster, with separate log streams per type. Here's where the cost conversation matters, because interviewers love asking about this tradeoff. A moderately busy cluster, say fifty nodes with a healthy mix of workloads and controllers reconciling state, can easily generate two to five gigabytes of audit log data per day. CloudWatch charges roughly fifty cents per gigabyte ingested, plus storage costs on top, and audit logs are chatty by nature because every single API interaction, including read-only list and watch calls from system components, gets recorded. If you don't set a retention policy on that log group, you're paying to store that indefinitely. A sensible default is something like ninety days retention for audit logs to satisfy most compliance frameworks like SOC 2 or PCI DSS, then export older data to S3 if you need longer retention for legal reasons. Once the logs are flowing, you go to CloudWatch Logs Insights to actually investigate. This is a query language, not full text search, and it's worth knowing the syntax cold for an interview. A basic investigative query looks like this: you select fields for timestamp, the username under user, the verb, the object reference resource, the object reference namespace, and ...
    続きを読む 一部表示
    10 分
  • AWS Network Firewall: Stop Exfil Without Breaking Egress

    AWS Network Firewall: Stop Exfil Without Breaking Egress
    2026/09/09
    AWS Network Firewall in a centralized inspection VPC is the right answer when security hands you a ticket to block unexpected egress — here's how to design it without taking down production at 2am. You'll learn: Why the firewall lives in one centralized inspection VPC behind AWS Transit Gateway, not deployed per spoke VPC — and how the route tables enforce that How stateful domain-list rules use TLS SNI to allow *.github.com and *.pypi.org while dropping everything else on 443 — without decrypting traffic The encrypted client hello (ECH) blind spot: why SNI-based rules can silently stop matching and what you need as a backstop How to roll out in alert/count mode first, capture a full week of egress patterns to CloudWatch, and flip rule groups to drop one at a time Pricing gotcha: endpoint hours per AZ plus data processed means centralized inspection is cheaper, but you must size for combined peak across all VPCs Keywords: AWS Network Firewall interview questions, TLS SNI egress filtering, centralized inspection VPC, cloud security engineer interview, data exfiltration AWS 🎧 Listen, then go deeper — DevOps & Cloud interview-prep ebooks at DevOpsInterview.Cloud ▶ Daily 30-second interview drills: DevOps Interview Cloud on YouTube Transcript Security just sent you a ticket. Block all unexpected egress across every VPC. No more instances calling out to random IPs on the internet. Sounds simple until you realize your build servers pull from package registries, your app calls three SaaS APIs, and nobody has a full list of what's actually supposed to be leaving the network. Ship the wrong rule set and you either miss real exfiltration paths, or you break a deploy at two in the morning and get paged for it. This question shows up in senior DevOps and cloud security interviews because it tests three things at once. Can you design for centralized inspection instead of bolting a firewall onto every VPC. Do you understand the tradeoff between IP-based and domain-based filtering. And do you have a rollout process that doesn't nuke production traffic on day one. Anyone can say "add a firewall." Fewer people can explain why it goes in one place, and how you prove it's safe before you flip it to blocking mode. Start with the mental model. In a multi-VPC setup, you do not want AWS Network Firewall deployed separately in every spoke VPC. That's operationally painful, it's expensive, and every team ends up writing slightly different rules. The standard pattern is a centralized inspection VPC, sitting between your spoke VPCs and the internet, usually paired with AWS Transit Gateway. Every spoke VPC routes its default egress through the transit gateway to the inspection VPC. The firewall endpoints live there, traffic gets inspected once, using one shared rule set, and then it's routed out through a NAT gateway to the internet. The firewall itself has two kinds of rules. Stateless rules operate on packet headers, source and destination IP, ports, protocol. They're fast, but they don't know anything about the content or the destination domain. Stateful rules track connections and can inspect protocol details, and this is where domain filtering comes in. AWS Network Firewall supports domain-based stateful rules using the HOME_NET and TLS SNI, the Server Name Indication field. Since most traffic is encrypted, the firewall reads the SNI in the TLS handshake to figure out what domain a connection is headed to, without decrypting the actual payload. Here's the walkthrough security actually wants. Instead of writing rules like "allow this IP range," which breaks the moment a SaaS vendor rotates their infrastructure behind a content delivery network, you write domain allow lists. Something like: allow egress to star dot amazonaws dot com, star dot github dot com, star dot pypi dot org, your internal artifact registry domain, and your approved SaaS endpoints like star dot datadoghq dot com. Everything else on port 443 and port 80 gets dropped by a default deny rule at the bottom of the rule group. That's the actual control that stops exfiltration. An attacker who compromises a workload can't just open a connection to some random domain and quietly ship data out, because the SNI doesn't match anything on the allow list and the connection gets reset. A concrete example: say you've got an application VPC running ECS tasks that call out to a payments API and pull container images from Amazon ECR. You'd build a stateful rule group with domain list rules, action equals pass, targeting star dot amazonaws dot com for ECR and S3 access, plus the specific payments vendor domain. Then a second rule group, lower priority, with a drop-all rule for anything else on 443. You attach both rule groups to a firewall policy, and that policy gets applied to the firewall in the inspection VPC. Every spoke VPC's route table sends 0.0.0.0/0 traffic to the transit gateway attachment for the inspection VPC, so nothing bypasses the firewall. Now ...
    続きを読む 一部表示
    8 分
  • VPA vs HPA for Stateful Workloads: Autoscaler Deep Dive

    VPA vs HPA for Stateful Workloads: Autoscaler Deep Dive
    2026/07/22
    Your Cassandra node is getting evicted at 2 a.m. or your PostgreSQL replica is sitting on 4× the memory it needs — this episode breaks down exactly which autoscaler to reach for and why VPA vs HPA is a staple senior SRE interview question. You'll learn: Why HPA's scale-out model breaks for StatefulSets (token rings, replication slots, unacknowledged messages) and when vertical scaling is the only safe lever VPA's three components — recommender, admission controller, updater — and why update mode auto is the one that pages you at 2 a.m. for stateful workloads The safe progression: start in Off mode for two weeks, apply recommendations manually, then consider Initial mode — and why Auto is rarely worth it for anything with persistent state The HPA + VPA feedback loop failure: both watching CPU on the same workload, pod count oscillating, resource allocation in chaos The clean split that actually works: HPA on queue depth (custom metric), VPA managing memory requests — distinct signals, no interference Keywords: VPA vs HPA Kubernetes, vertical pod autoscaler stateful workloads, autoscaler SRE interview, HPA VPA conflict, Kubernetes StatefulSet autoscaling 🎧 Listen, then go deeper — DevOps & Cloud interview-prep ebooks at DevOpsInterview.Cloud ▶ Daily 30-second interview drills: DevOps Interview Cloud on YouTube Transcript Your stateful app is getting evicted every few hours, or it's sitting on four times the memory it actually needs, and you're not sure which autoscaler to reach for. That's the exact scenario interviewers love, because most candidates only know one half of the answer. Let's set the stage. You have a Cassandra node, a RabbitMQ broker, or a PostgreSQL read replica running in Kubernetes. It's a StatefulSet. Traffic is not uniform. Some days it's busy, some days it's quiet. Someone on your team says "just add HPA" and someone else says "we need VPA." Who's right? That question shows up in senior SRE and platform engineer interviews constantly, because the answer is not obvious and the wrong choice causes real incidents. Interviewers ask this because autoscaling is one of those topics where surface-level knowledge falls apart fast. Saying "HPA scales pods out, VPA scales pods up" is correct but incomplete. The follow-up is always: okay, so which one do you use for a stateful workload, and why? And then: what happens if you use both at the same time? If you can't answer those, you signal that you've only worked with stateless services. Here's the mental model you need. The HPA, the Horizontal Pod Autoscaler, works by changing the number of pod replicas. It watches a metric, CPU or memory or a custom one, and when that metric crosses a threshold it adds or removes pods. That works beautifully for stateless services. Each replica is identical, sessions don't matter, and spinning up a new pod behind a load balancer is invisible to users. Stateful workloads break that assumption. A Cassandra node owns a subset of the token ring. A RabbitMQ broker may hold unacknowledged messages. A PostgreSQL replica has an open replication slot. Adding a new pod doesn't instantly help because the new pod has to join the cluster, sync data, or acquire state before it can carry load. Scaling out fast is often dangerous. Scaling in is even worse because you might be removing a pod that holds data not yet replicated elsewhere. So for stateful workloads, the more useful lever is usually vertical. Give the existing pod more CPU or more memory so it can handle the load without needing a new replica. That's where the VPA, the Vertical Pod Autoscaler, comes in. VPA has three components. The recommender watches historical resource usage and calculates what your requests and limits should be. The admission controller patches those values into new pods at scheduling time. And the updater, this is the dangerous one, can evict running pods so they restart with the new resource values. The key knob is the update mode, and this is a common interview question on its own. Update mode off means the VPA only calculates recommendations. It never touches your pods. You query the VPA object and apply changes yourself. This is the right starting point for any stateful workload. You get the data without the risk. Update mode initial means the admission controller sets resource values when a pod is first created, but the VPA never evicts a running pod. The pod keeps whatever resources it started with until it's naturally replaced, for example during a rollout. This is a reasonable middle ground for apps that tolerate restarts as part of deployments but not random evictions. Update mode auto, and this is the one that bites teams, allows the VPA updater to evict pods at any time to apply new recommendations. For a stateless deployment this is often fine. For a stateful pod it can be catastrophic. Imagine your primary Redis instance getting evicted at two in the morning because the VPA decided it needed fifty percent more ...
    続きを読む 一部表示
    10 分
  • Kubernetes Scheduler Extenders: Custom Placement Logic

    Kubernetes Scheduler Extenders: Custom Placement Logic
    2026/07/15
    Learn how to write a Kubernetes scheduler extender webhook that restricts GPU pods to nodes with NVLink interconnects. This episode covers the extender contract, KubeSchedulerConfiguration registration, filter and prioritize endpoints, and the latency tradeoffs interviewers probe in senior SRE and platform engineering interviews. Full interview prep guides and scenario walkthroughs: DevOpsInterview.Cloud
    続きを読む 一部表示
    10 分