This collection keeps the original 2025 interview-guide title but uses current AWS DevOps principles and documented service behavior in its answers. The AWS Certified DevOps Engineer – Professional DOP-C02 guide provides a useful competency reference: SDLC automation, configuration management and infrastructure as code, resilient cloud solutions, monitoring and logging, incident and event response, and security and compliance. Interviewers may ask those subjects without expecting a particular AWS certification. A convincing response starts with a business requirement, explains the design, states what could fail and names evidence that would show the chosen remedy worked.
The 25 questions below are original educational interview prompts, not confidential certification items and not assertions about what a particular employer will ask. Each answer illustrates one defensible approach under stated conditions. Many alternatives can be valid when traffic, security policy or recovery objectives change. Candidates should practice explaining the assumptions and limitations instead of memorizing every word. A green build or a healthy EC2 instance is not enough to prove customer value; business behavior and operational safety must remain visible.
DevOps foundations and delivery workflow
1. What is the DevOps engineer’s responsibility on AWS? A DevOps engineer makes application changes repeatable, observable and recoverable through collaboration between development, platform and security teams. They may manage pipelines, infrastructure definitions, access controls, monitoring and incident response, but not every team assigns all those areas to one role. I would ask which business service must remain available and what release frequency and risk tolerance it has. Then I would make source identity, approvals, deployment history and rollback behavior visible. Success means reducing lead time while preserving service reliability, not maximizing the number of automated steps.
2. How would you design continuous integration for a web service? Start with a protected repository workflow. Each proposed change triggers a build, dependency resolution, unit tests and a relevant integration or contract test, with results returned to the pull request. CodeBuild may execute build tasks and a repository integration may initiate them, while CodePipeline can orchestrate the broader release path. Cache dependencies only with version control and a clear invalidation policy; a fast but nonreproducible build is not trustworthy. I would deliberately fail one test to prove merging and promotion stop, and record which commit and artifact passed every required check.
3. What is continuous delivery compared with continuous deployment? Continuous delivery means that a tested, versioned change is ready for a controlled release on demand. Continuous deployment automates its release after defined conditions pass. A regulated payment service might require an explicit production approval even when the build and integration checks are complete; a low-risk service might deploy automatically behind measured health gates. Neither model excuses unsafe secrets, broken rollback or incomplete testing. An explanation of CI/CD pipeline architecture should connect source, artifact, environment and release decision rather than imply one mode is inherently more mature.
4. How do CodePipeline and CodeDeploy differ? CodePipeline coordinates source, build, test, approval, invoke and deployment actions across stages. CodeDeploy performs deployments to supported EC2/on-premises, Lambda and ECS targets with platform-specific strategies and lifecycle definitions. A company might use CodePipeline to validate a release and delegate the rollout to CodeDeploy, but not every pipeline requires it. I would identify which component is responsible for a failure: a missing source artifact is not the same as an AppSpec error or unhealthy replacement instances. The CodeDeploy execution model helps separate those stages.
5. How do you prevent a newer commit from overwriting an approved release? Use immutable, versioned artifacts associated with source revisions, promote that same output between environments and control execution concurrency. CodePipeline execution modes differ: superseded, queued and parallel can produce different ordering guarantees, and rollback availability has constraints. I would choose a mode based on whether every change must deploy or only the latest approved version should reach production. Deployment receipts should record the input artifact, approval and actual running version. Rerunning a build from a moving branch at promotion time would undermine the fact that the originally tested artifact was approved.
Infrastructure, reliability and deployment decisions
6. When would you choose CloudFormation over a shell script? CloudFormation declaratively models AWS resources, dependencies and lifecycle updates. A shell script may be useful for a bounded operational task but can be hard to make idempotent or reversible. I would prefer an infrastructure definition when a team needs a repeatable VPC, IAM roles, load balancer and Auto Scaling group. The review should inspect change sets and resource replacement risk, particularly for stateful databases or access permissions. Infrastructure as code is valuable because the desired state is reviewable and source controlled, not because every template update is automatically safe. See CloudFormation fundamentals for the underlying model.
7. How does Auto Scaling help application availability? An Auto Scaling group maintains desired EC2 capacity and can react to metrics or schedules when appropriately configured. I would combine it with health checks, a multi-AZ placement strategy, application bootstrapping and load balancer target registration. Scaling cannot repair an application image that always fails its readiness check, and aggressive policies can increase cost without resolving a slow database. I would test instance replacement, cooldown behavior and sufficient capacity for an AZ disruption. A relevant service-level metric, not an arbitrary instance count, should govern success. The subject is deeper than simply turning on scaling.
8. How do you decide between blue/green and in-place deployment? In-place CodeDeploy for EC2/on-premises updates existing instances, generally stopping or taking them out of service while applying a revision. Blue/green prepares replacement capacity and shifts traffic, allowing validation before full cutover where supported. Lambda and ECS use blue/green patterns, not in-place CodeDeploy. I would ask about traffic availability, deployment time, rollback cost and database compatibility. A traffic shift is not a complete rollback when the new code migrated data to a schema the old code cannot read. A safe choice identifies both application and persistent-state recovery requirements.
9. How would you protect a production deployment from a failing integration test? Make the result a required pipeline gate, and require that test output be associated with the precise candidate artifact. A failing test should block promotion before the production stage begins. If the test is flaky, investigate its environment, dependencies and ownership instead of silently disabling it. For truly urgent changes, a formally approved exception might be justified, but it should be narrow and recorded. I would demonstrate the gate with a disposable failing build and verify that it cannot reach the target environment. Evidence of an enforced block is more useful than a dashboard that reports a pass percentage.
10. What is your approach to disaster recovery for a stateful service? Start with recovery time and recovery point objectives. Multi-AZ resources protect against some local failures, but they cannot undo a mistaken delete or corrupted data replicated to every copy. Establish backups, tested restoration, cross-region strategy where warranted, client reconnection and a responsible recovery owner. I would run a controlled recovery exercise and reconcile important business records rather than measure only instance startup time. The application should be able to tolerate retries and avoid duplicating transactions after restoration. Recovery architecture should follow the business’s data-loss tolerance and legal placement requirements, not a generic demand for maximum redundancy.
Security and identity across the automation plane
11. How would you authenticate a deployment pipeline without static AWS access keys? Where the execution environment supports it, use a trusted identity federation mechanism or a narrowly scoped role assumption that issues short-lived credentials. Constrain which repository or workflow identity may request the role, and limit permissions to the destination resources. Avoid putting long-lived administrator credentials in build variables, source files or artifacts. I would prove both the intended authorized deployment and a deliberately denied operation. A successful deployment under an unrestricted role is not evidence of good security; the negative test shows the boundary is actually enforced.
12. When should an application use AWS Secrets Manager? Use Secrets Manager when an application needs to store and retrieve a secret such as a database password or external API token with controlled access and lifecycle handling. The Lambda execution role should be limited to the specific secret and relevant decryption permissions; do not print the value or return it in an exception. Where an AWS service supports IAM-based authentication, a stored password might be avoidable. Rotation must be coordinated with the consuming application and external target. Compare the requirements with Secrets Manager and Parameter Store instead of assuming every parameter is a secret.
13. How do KMS key policies affect access? KMS authorization can involve key policies, IAM permissions and grants; key ownership is not just a toggle on an S3 bucket. The design should identify who may administer a key, who may encrypt, who may decrypt and which service principal has the necessary scope. Envelope encryption lets AWS services and applications protect data keys without putting plaintext master-key material into application code. A failure to decrypt can result from an incorrect role, key policy, region or encryption context. I would investigate the denied request and audit evidence before expanding permissions. Least privilege must be tested in both directions.
14. What is the difference between a security group and a network ACL? Security groups are stateful network controls associated with resources such as ENIs; they use allow rules for inbound and outbound traffic, and response traffic is handled in their stateful model. Network ACLs are stateless subnet-level controls with ordered allow and deny entries; both directions and ephemeral response ports may matter. I would trace the actual application flow through route tables, security group rules and NACL evaluation. A reachable host but failing response could result from an asymmetric or incomplete network policy. Use security group and NACL examples for specific diagnostics.
15. How would you integrate vulnerability scanning into a release? First identify the assets being assessed: source dependencies, container image, infrastructure definition or deployed workload. Choose a supported scanning tool and place its result where a fix can be applied before promotion, with triage procedures for false positives and compensating controls. Do not assume every high severity score has identical business urgency; exploitability and critical asset exposure matter. Track findings to a ticket, patch or approved exception and retest. I would explain how the gate behaves when the scanning service is unavailable, because a security system that fails unpredictably can block vital emergency maintenance without adding useful protection.
Monitoring, incident handling and cost decisions
16. Which metrics tell you a deployment is healthy? Host CPU and memory are useful but insufficient. I would observe application request success, latency, dependencies, transaction or queue correctness, deployment version and relevant business measures. CloudWatch can collect supported signals, with structured logs and traces helping explain failures. A green health endpoint may conceal broken checkout functionality or stale data. During a canary, promotion should depend on a meaningful comparison against the old version with enough traffic to detect defects. I would ensure the monitoring pipeline itself receives data before interpreting zero alerts as zero problems.
17. How do you investigate a sudden rise in Lambda errors? Check the affected versions, event sources, throttling, timeout and memory configuration, IAM denials, downstream dependency behavior and CloudWatch logs. Differentiate a function invocation failure from a successfully invoked function producing an incorrect business result. If retries are automatic, determine whether events can be repeated and whether the sink is idempotent. Recent deployment changes and dependency releases can guide investigation, but a correlation alone is not proof of causation. Use the smallest safe rollback or fix that matches the evidence, then verify with the customer operation as well as the Lambda metric.
18. How would you investigate an unexpected AWS bill increase? Attribute cost by account, service, region and tags where possible, compare the period against recent changes, and check new capacity or high-volume data transfer. A runaway query, untuned Auto Scaling policy or persistent test environment may each have different remedies. Confirm ownership before shutting down a resource, because deleting the wrong database to reduce cost can create a larger incident. Budgets and alerts are useful preventive controls, but they should be paired with service-level expectations. I would record the root cause and change a guardrail or retention policy to prevent recurrence.
19. What does an incident response runbook contain? A useful runbook names symptoms, severity criteria, responsible team, initial safe checks, evidence to preserve, approved containment steps, escalation paths and recovery validation. For a release incident, it should identify the deployed artifact and its stateful dependencies. For a security incident, preserve relevant logs and avoid actions that destroy forensic evidence. Automate only bounded actions whose prerequisites can be verified. The runbook should be rehearsed with a harmless simulation, and its outcome should generate a corrective task. The most valuable document is one another responder can use when the original engineer is unavailable.
20. How do you handle an overloaded SQS consumer? Inspect queue depth, age of oldest message, visibility timeout, dead-letter behavior, consumer concurrency and downstream rate limits. Increasing Lambda concurrency can help some workloads but may overwhelm a database or third-party API; it should follow measured throughput and failure patterns. Ensure messages that retry do not duplicate a business-side effect. A poison message should not starve every valid message indefinitely. I would tune retry and dead-letter policies, compare recovery under load and monitor business completion instead of relying solely on the number of messages pulled.
Professional judgment and scenario trade-offs
21. How would you migrate an application from manual deployments to CI/CD? Inventory the current steps, dependencies, configuration, credentials and rollback procedures. Move source and infrastructure definitions into reviewable version control, produce immutable build artifacts, then automate tests and nonproduction release. Add approvals and canary gates to production only after end-to-end recovery is tested. A one-click script that repeats undocumented manual assumptions can be more dangerous than a careful staged migration. I would measure lead time, deployment failure frequency and recovery outcomes before and after change, alongside operational cost. The goal is a safer repeatable process rather than simply eliminating human involvement.
22. How would you prevent configuration drift across environments? Define infrastructure and application configuration in controlled sources, enforce reviews and compare actual state against declared state. Not every difference should be auto-remediated; a manual emergency fix or stateful resource may require investigation. CloudFormation drift detection can assist for supported resource properties, while Systems Manager can help inventory or manage appropriate instance configuration. Separate secrets from general settings and ensure a production change cannot accidentally reuse a development credential. I would demonstrate how an unauthorized change is detected and how the team safely restores approved behavior, not merely assume that Infrastructure as Code eliminates drift.
23. How do you choose between ECS, EKS, Lambda and EC2? Start with runtime, scale, networking, operational skills, deployment control and cost constraints. Lambda fits supported event-driven tasks with its execution model and limits, while ECS and EKS orchestrate containers with different management and ecosystem requirements. EC2 provides greater operating-system control but also more patching and capacity responsibility. No service is inherently the most mature choice for every workload. I would identify stateful dependencies and operational access before picking a deployment path, and explain why an alternative either exceeds the needed complexity or fails a hard requirement. The decision must remain supportable after the application changes.
24. How would you diagnose a failed CodePipeline rollback? First check whether the stage is eligible for rollback and whether the previous successful execution belongs to the current pipeline structure version. A source stage cannot be rolled back this way, and parallel execution mode has important rollback restrictions. Inspect action results, artifacts, variables and deployment-specific state; rolling back a pipeline execution does not automatically reverse an incompatible database migration. I would protect current evidence, choose a supported recovery path and verify the running application and data. A good explanation distinguishes pipeline history from the real customer-facing state rather than treating a rollback button as a universal undo operation.
25. What makes a strong senior DevOps interview answer? A senior response names assumptions and business objectives, compares realistic alternatives, identifies the blast radius of a change and specifies verification. It acknowledges security and data loss instead of promising zero downtime under any architecture. I would discuss one actual or safely simulated incident using facts: symptom, hypothesis, evidence, controlled fix, validation and prevention. A hiring team can then ask how I would change the approach under a tighter budget or stricter compliance boundary. The ability to revise a design under those constraints is more meaningful than memorized statements about speed, cloud agility or certification credentials.