DevOps, Docker & AWS

Tests whether you can name the actual stages -- build, test, artifact, deploy, gate -- and who owns each one, instead of a vague 'we use Jenkins' answer.

Tests whether you can walk the full path from commit to production -- approvals, environments, rollback plan -- not just the happy-path deploy command.

Tests whether you reach for the rollback/abort mechanism and check what state was left partially applied, instead of re-running the pipeline and hoping it completes.

Tests whether you have a basic map of compute, storage, database, and networking service categories on AWS.

Tests whether you know AWS's physical infrastructure hierarchy and why it matters for latency and fault tolerance.

Tests whether you know exactly where AWS's security responsibility ends and the customer's begins.

Tests whether you know the framework AWS itself uses to evaluate architecture quality across reliability, security, and cost.

Tests whether you know the 5TB object limit and that anything over 5GB in a single PUT requires multipart upload.

Tests whether you know the basic pull-rebase-resolve-push workflow every engineer needs cold.

Tests whether you know git reflog can rescue commits even after the branch pointer itself is gone.

Tests whether you know these three references track genuinely different things during risky Git operations.

Tests whether you know annotated tags carry metadata (author, message, signature) that lightweight tags don't.

Tests whether you know signed commits, linear history, and mandatory PR reviews all contribute to an auditable trail.

Tests whether you know secret scanning, pre-commit hooks, and .gitignore each catch a different failure mode.

Tests whether you go straight to CI logs and reproduce locally, instead of just re-pushing and hoping.

Tests whether you understand your own rollout strategy and autoscaling thresholds, or just know the kubectl commands without the reasoning behind replica counts.

Tests whether you know a failing liveness probe triggers a container restart, and that misconfiguring it can cause crash loops on a merely slow-starting app.

Tests whether you know readiness controls traffic routing (not restarts), and why it matters for zero-downtime rollouts and warm-up periods.

Tests whether you know to compare the container memory limit against JVM heap/off-heap settings and check for OOMKilled events, rather than only looking at in-JVM heap dumps.

Tests whether you know the basics of AWS's core virtual machine service.

Tests whether you know the cost-versus-commitment-versus-interruption-risk tradeoff across EC2's four purchase models.

Tests whether you know how access frequency and retrieval time trade off against storage cost across S3's tiers.

Tests whether you know how to grant time-limited access to a private S3 object without changing bucket permissions.

Tests whether you know branch protection enforces required reviews, status checks, and linear history before merge -- not just that a toggle exists in settings.

Tests whether you reach for a state machine model with persisted transitions and retry/compensation semantics, rather than chaining service calls with in-memory control flow.

Tests whether you understand AZ-level HA means independent power/network/failure domains with multi-AZ deployment and health-check-driven failover, not just 'use more than one server'.

Tests whether you can identify the right caching pattern (cache-aside vs write-through) and invalidation strategy, not just that Redis makes things faster.

Tests whether you know the distinction between Delivery (ready to deploy) and Deployment (auto-deployed) specifically.

Tests whether you can actually write the YAML, not just describe CI/CD conceptually.

Tests whether you know how to wire the build step and where to actually push the resulting image.

Tests whether you know to use encrypted repository secrets rather than hardcoding credentials into workflow files.

Tests whether you've actually planned for the failure path, not just the happy deploy path.

Tests whether you can connect the build, push, and deploy stages into one working end-to-end pipeline.

Tests whether you know the tradeoff between instant-switch simplicity and gradual-rollout safety.

Tests whether you can chain telemetry tools together -- correlating an App Insights trace to a KQL query to a DevOps release -- rather than knowing each tool in isolation.

Tests whether you combine metrics, logs and trace IDs into one correlated view of a request, rather than treating CloudWatch as just a dashboard of CPU graphs.

Tests whether you can lay out a concrete path -- containerize, push to ECR, run on ECS/EKS, wire up a load balancer and config -- instead of naming services without a flow.

Tests whether you know subnets, route tables, internet gateways, and NAT gateways as the building blocks of a VPC.

Tests whether you know one is stateful and instance-level while the other is stateless and subnet-level.

Tests whether you know these four building blocks and how they combine to control access on AWS.

Tests whether you know how temporary credentials let a principal in one account securely act in another.

Tests whether you know Multi-AZ is for automatic failover, not read scaling — a very common point of confusion.

Tests whether you know when predictable low-latency NoSQL access patterns beat relational flexibility.

Tests whether you know how DynamoDB physically distributes and orders data based on your key design.

Tests whether you know how a poorly chosen partition key can bottleneck throughput even when overall capacity is fine.

Tests whether you know local storage breaks the moment you scale to multiple instances behind a load balancer.

Tests whether you know a signed, time-limited URL grants access without changing the bucket's actual permission policy.

Tests whether you know this pattern avoids routing large file bytes through your own application servers.

Tests whether you know large uploads are split into parallel chunks that can retry independently instead of restarting the whole upload.

Tests whether you know MinIO's S3-compatible API lets you develop against object storage without any cloud dependency or cost.

Tests whether you know how to trade retrieval speed for storage cost automatically as data ages.

Tests whether you can name a coherent stack (ELK/EFK, Loki+Grafana, CloudWatch Logs Insights) and explain why centralization matters once you have more than one instance.

Tests whether you know it wipes the target directory, runs the full lifecycle through test and package, and installs the artifact into the local repo for other projects to depend on.

Tests whether you have a real opinion grounded in build speed, incremental builds, and config style, rather than just naming the tool your last project happened to use.

Tests whether you know the basics of event-driven, pay-per-invocation serverless compute.

Tests whether you know why the first invocation after idle time is slower, and how provisioned concurrency addresses it.

Tests whether you know how to coordinate multiple Lambda functions with retries and branching instead of chaining them manually.

Tests whether you reach for externalized config (profiles, ConfigMaps, a config server) with secrets kept separate, instead of hardcoding environment-specific values in the jar.

Tests whether you know one is a pull-based queue and the other a push-based pub/sub topic.

Tests whether you know the tradeoff between managing your own EC2 capacity and letting AWS run containers serverlessly.

Tests whether you know EKS is managed Kubernetes while ECS is AWS's own simpler, non-portable orchestrator.

Tests whether you can actually read a query plan, not just know the command exists.

Tests whether you know a composite index is only useful for queries that filter on its leftmost columns first.

Tests whether you know OFFSET-based pagination gets progressively slower on large tables, and keyset pagination avoids that.

Tests whether you know each round trip has fixed overhead, and batching amortizes that cost across many rows.

Tests whether you know an index that already contains every selected column skips the extra trip to the actual table row.

Tests whether you know an implicit conversion on the indexed column forces a full scan even though an index exists.

Tests whether you know read-heavy systems can trade some redundancy for avoiding expensive joins at query time.

Tests whether you know a growing pile of never-really-deleted rows bloats indexes and slows every query that scans the table.

Tests whether you know moving cold data to a separate archive table keeps hot-path queries fast on the active table.

Tests whether you know replicas offload read traffic at the cost of potential replication lag on reads.

Tests whether you know the basics of how AWS manages encryption keys used across its services.

Tests whether you know WAF filters application-layer attacks like SQL injection and XSS at the edge, before they reach your app.

Tests whether you know Docker solves the 'works on my machine' environment-consistency problem specifically.

Tests whether you know containers share the host OS kernel while VMs each run their own full OS.

Tests whether you know an image is an immutable blueprint while a container is a running (or stopped) instance of it.

Tests whether you know a Dockerfile is a reproducible, version-controlled recipe for building an image.

Tests whether you know how these two instructions combine, and which one CLI arguments actually override.

Tests whether you know how to keep build tools out of your final image to drastically shrink its size.

Tests whether you know to order instructions from least to most frequently changing for faster rebuilds.

Tests whether you know the always-on-control versus event-driven-simplicity tradeoff between the two.

Tests whether you know one is AWS-native and simpler, the other is portable standard Kubernetes with more operational surface.

Tests whether you know these three solve fundamentally different storage access patterns, not just 'different AWS storage products.'

Tests whether you know this is really an access-pattern-and-scale question, not just a technology preference.

Tests whether you know which layer each operates at and what capability that gives or takes away.

Tests whether you know the messaging pattern each is purpose-built for, not just that they're all 'AWS messaging.'

Tests whether you know why AWS itself recommends roles over long-lived user credentials wherever possible.

Tests whether you know the different ways a container can (or can't) talk to the host and other containers.

Tests whether you know how to prevent one noisy container from starving every other container on the same host.

Tests whether you know Docker manages one for you while the other points at an arbitrary host filesystem path.

Tests whether you know how to define and run a multi-container application from a single YAML file.

Tests whether you know how Compose determines a container is actually ready, not just started.

Tests whether you know why a container breakout is far more dangerous when the process inside is running as root.

Tests whether you know how to configure a Dockerfile's USER instruction correctly for production hardening.

Tests whether you know HPA can scale on more than just CPU — custom and external metrics too.

Tests whether you know Secrets are only base64-encoded by default, not encrypted, and what that implies for real security.

Tests whether you know a helper container can extend a pod's behavior (logging, proxying) without touching the main app's code.

Tests whether you know multi-stage builds, slim base images, and layer ordering all contribute to a smaller final image.

Tests whether you understand the actual Linux kernel mechanism Docker relies on to enforce CPU/memory limits.

Tests whether you know Swarm's simplicity-versus-ecosystem tradeoff against Kubernetes for smaller, simpler deployments.

Tests whether you can describe the actual integration mechanism (SDK client, IAM role-based auth, specific config) for services you've used -- not just name-dropping S3/RDS/SQS without being able to explain how the Java app authenticates and talks to them.

Tests whether you can walk the full CI/CD path concretely -- build/test stage, artifact/image build, deployment to the target compute (ECS/EKS/EC2), and which stages you personally owned vs which were shared infra -- rather than a hand-wavy 'we use a pipeline.'

Tests whether you suspect the readiness probe is checking something too shallow (e.g. just TCP connect) that doesn't reflect actual app readiness -- the app may need more warm-up time (JIT, connection pool init) than the probe accounts for, so it's marked ready before it can actually serve traffic.

Tests whether you'd compare ss -s for socket state counts, lsof/ls /proc/<pid>/fd for file descriptor exhaustion, and netstat/ss for lingering TIME_WAIT or CLOSE_WAIT connections between the two pods -- a side-by-side diff is often faster than theorizing about the cause.

Tests whether you check for node-level issues affecting just that pod's host (noisy neighbor, disk I/O contention, that specific node's resource pressure) rather than assuming the application code itself is at fault, since identical pods behaving differently points at the environment, not the code.

Tests whether you look below the application -- LB-to-backend connection timeouts, keep-alive mismatches between the LB and app server, or backend connection resets -- since a clean app log with an LB-reported 502 usually means the failure happened at a layer the app never got to log.

Tests whether you check the service/ingress routing and endpoint registration first -- pods can be individually healthy while the service selector, endpoint list, or ingress config hasn't caught up with the new deployment, routing traffic nowhere or to terminated pods.