『DevOps & Cloud Interview Prep: Real Scenarios & Answers』のカバーアート

DevOps & Cloud Interview Prep: Real Scenarios & Answers

DevOps & Cloud Interview Prep: Real Scenarios & Answers

著者： DevOpsInterview.Cloud
無料で聴く

概要
 Real DevOps and cloud interview scenarios, broken down the way a senior engineer would answer them. Kubernetes, AWS, Terraform, CI/CD, observability and incident response, with the trade-offs interviewers actually probe for. More prep material at devopsinterview.cloud.
エピソード
  • 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 分
adbl_web_anon_alc_button_suppression_t1
まだレビューはありません