Question 1

What are the AWS developer tools for CI/CD?

Accepted Answer

CodePipeline orchestrates stages and actions; CodeBuild runs build and test in managed containers; CodeDeploy deploys to EC2, on-premises servers, ECS and Lambda with in-place or blue/green strategies; CodeArtifact hosts package repositories; and CodeConnections links to GitHub, GitLab and Bitbucket. The honest framing is that many teams use GitHub Actions or GitLab for build and test and CodeDeploy or CodePipeline only for the deployment half, because the developer experience of the AWS tools is weaker. Being able to say that rather than presenting them as the obvious choice is a credible position.

Question 2

What is a buildspec file?

Accepted Answer

buildspec.yml defines what CodeBuild does: phases for install, pre_build, build and post_build, environment variables including references to Parameter Store and Secrets Manager, artifacts to output, cache configuration, and reports for test results. Caching dependencies between builds is usually the largest speed win and is configured here. Referencing secrets by parameter rather than as plain environment variables is the security detail, since plain values appear in the build configuration.

Question 3

What deployment strategies does CodeDeploy support?

Accepted Answer

For EC2 and on-premises: in-place, which updates instances in a deployment group in configurable batches, and blue/green, which provisions a replacement fleet and shifts the load balancer. For Lambda and ECS: canary, which shifts a percentage then the rest after an interval, linear, which shifts equal increments, and all-at-once. The differentiating feature is automatic rollback on CloudWatch alarm, plus lifecycle hooks — BeforeAllowTraffic and AfterAllowTraffic — that run validation functions and can fail the deployment. That validation gate is what makes a canary real rather than decorative.

Question 4

What is a blue/green deployment and what are its trade-offs?

Accepted Answer

Blue/green runs two complete environments and switches traffic all at once, so rollback is instant because the old environment is still running. The trade-offs are double capacity during the switch, and that database schema changes must be compatible with both versions since they share the data tier. The shared database is the constraint people forget: the compute layer is duplicated but the data layer is not, so an incompatible migration breaks blue while green is live. Expand-and-contract migrations are what make blue/green safe.

Question 5

What is a canary deployment and how do you decide to promote?

Accepted Answer

A canary sends a small percentage of real traffic to the new version, monitors it, then increases the share. Promotion should be gated on automated metrics — error rate and latency compared against the stable version — with automatic rollback if they degrade, rather than on a human watching a dashboard. The automated promotion criterion is what makes it valuable; a canary that a human eyeballs for five minutes catches only obvious failures. Naming a specific criterion, such as p99 latency within a tolerance of the baseline, is what shows you have implemented it.

Question 6

What is the difference between deployment and release?

Accepted Answer

Deployment puts new code into an environment; release makes a feature available to users. Feature flags separate them, so you can deploy continuously and turn a feature on for a segment, or off in seconds, without another deployment. This separation is what makes trunk-based development with continuous deployment safe, because incomplete work ships behind a flag. It also means a bad feature is disabled in seconds rather than requiring a rollback, which is a materially faster mitigation.

Question 7

How do you deploy safely to Lambda?

Accepted Answer

Publish an immutable version, point an alias at it, and use CodeDeploy with a canary or linear configuration to shift alias traffic gradually, with a CloudWatch alarm triggering automatic rollback and pre- and post-traffic hooks running validation functions. The alias indirection is what makes rollback instant, because clients reference the alias rather than a version. SAM configures the whole gradual deployment in a few lines, which is the practical way most teams enable it.

Question 8

How do you deploy safely to ECS?

Accepted Answer

Rolling update with minimumHealthyPercent and maximumPercent controlling surge and availability, plus load-balancer health checks and a deregistration delay longer than the slowest request. For stronger control, CodeDeploy blue/green shifts traffic between two target groups with test listeners and automatic rollback on alarm. The test listener in the blue/green configuration is the useful detail: you can validate the replacement task set through a separate port before shifting production traffic. The application must also handle SIGTERM or every deployment drops in-flight requests.

Question 9

What is CodeArtifact?

Accepted Answer

CodeArtifact is a managed artifact repository for npm, PyPI, Maven, NuGet, Ruby and generic packages, with upstream repositories that proxy and cache public registries, IAM-based access control, and domain-level sharing across accounts. The upstream proxy is the supply-chain control: builds pull through your repository, so you have a record of exactly what was consumed, protection from an upstream outage or rate limit, and a point at which to apply scanning and policy.

Question 10

How do you authenticate a CI system outside AWS to deploy?

Accepted Answer

OIDC federation: register the provider — GitHub, GitLab, Bitbucket — as an IAM identity provider, create a role whose trust policy allows AssumeRoleWithWebIdentity with a condition restricting the subject claim to a specific repository and branch or environment, and let the workflow exchange its token for temporary credentials. The subject-claim condition is security-critical: without restricting repository and ref, other repositories can assume the role. That misconfiguration has caused real production compromises, which is why the scoping is the substance of the answer.

Question 11

What is build-once-deploy-many and why does it matter?

Accepted Answer

Build the artefact once, tag it immutably with the commit SHA, publish it, and promote that exact artefact through environments with configuration injected at deploy time. Rebuilding per environment means the artefact reaching production was never tested, because dependency resolution and base images can differ. This is a core delivery principle and interviewers listen for it specifically. The corollary is that configuration must be external — environment variables, Parameter Store, Secrets Manager — so the same image runs everywhere.

Question 12

How do you version container images and why does the tag strategy matter?

Accepted Answer

Tag with the commit SHA or a semantic version, never deploy "latest", and prefer deploying by image digest because a tag can be moved but a digest cannot. Enable immutable tags in ECR so a tag cannot be overwritten at all. Digest pinning is the strongest form because it is cryptographically bound, so even a compromised registry cannot substitute a different image under the same tag. Naming digest pinning rather than just "avoid latest" is the deeper answer.

Question 13

What is supply-chain security in a pipeline and what does AWS provide?

Accepted Answer

It is assurance that what runs in production was built from reviewed source by a trusted system. AWS provides ECR image scanning with Inspector, CodeArtifact for controlled dependencies, Signer for signing container images and Lambda code, and ECR image signature verification, alongside least-privilege pipeline roles. The SLSA framework is the vocabulary, and the chain is signed source, verified build, generated provenance, scanned artefact, verified deploy. Naming the break-glass path is important too, since an emergency deploy will eventually be needed and an undesigned bypass becomes permanent.

Question 14

How do you handle database migrations in a pipeline?

Accepted Answer

Run them as an explicit versioned step separate from the application deploy, and make every migration backwards-compatible with the currently running version using expand-and-contract. Deploy the migration first, then the code, remove the old shape in a later release, and require approval for destructive changes. Backwards compatibility is the requirement because during a rolling or blue/green deployment both versions run against the same database. Candidates who describe deploying schema and code atomically have not thought about that overlap.

Question 15

What tests would you run at which pipeline stage?

Accepted Answer

Linting, static analysis and unit tests on every commit, fast enough to run in a couple of minutes. Build and integration tests after that. Contract tests between services. Smoke tests against the deployed artefact in staging. Canary with automated metric checks in production. Load and security scans on a slower cadence. The principle is fail fast and cheap: anything catchable in seconds should be, so slow tests only run on candidates that already passed. Treating production smoke tests and canary checks as part of testing, rather than testing ending at deployment, is the modern view.

Question 16

How do you speed up a slow pipeline?

Accepted Answer

Cache dependencies and Docker layers; parallelise independent stages and split long test suites; use path filters so only affected components build in a monorepo; use larger CodeBuild compute for CPU-bound steps; build smaller images with multi-stage Dockerfiles; and move slow non-blocking checks after merge. The constraint driving design is developer attention: a pipeline over roughly ten minutes causes context switching and batching, which defeats continuous integration. Separating the fast pre-merge gate from the slower post-merge suite is the structural answer.

Question 17

How do you manage environment-specific configuration?

Accepted Answer

Keep it out of the artefact. Inject at deploy time through environment variables, Parameter Store, Secrets Manager or AppConfig, with values held in version-controlled per-environment files or in IaC. The same image then runs in every environment. AWS AppConfig is worth naming because it adds validated, gradually-rolled-out configuration changes with automatic rollback — configuration deployed like code rather than changed in place, which is where a lot of outages originate.

Question 18

What is AWS AppConfig?

Accepted Answer

AppConfig manages application configuration and feature flags as a deployment: configuration is validated against a schema or Lambda validator, rolled out gradually to a percentage of targets, monitored against CloudWatch alarms, and rolled back automatically if an alarm fires. Treating configuration changes as deployments with validation and rollback is the insight, because a bad configuration change is a common outage cause and traditionally has none of the safety of a code deploy. Feature-flag support makes it a lightweight alternative to a third-party service.

Question 19

How do you implement approval gates for production?

Accepted Answer

A manual approval action in CodePipeline that notifies via SNS and blocks until approved by an identity, with the approver distinct from the author for separation of duties. Combine it with automated gates — tests passed, security scan clean, change record referenced — so approval is a decision rather than a rubber stamp. Separation of duties enforced by the tool, rather than by policy, is what auditors care about. Naming that every approval is recorded with the identity and timestamp for the audit trail is the compliance completion.

Question 20

What is trunk-based development and what does it require?

Accepted Answer

Developers integrate small changes into a single main branch frequently, with incomplete work behind feature flags and at most very short-lived branches. It requires a fast and reliable test suite, feature flags, and progressive delivery with fast rollback, or it means shipping broken code. Naming the preconditions rather than advocating the practice unconditionally is what makes the answer credible. The alternative — long-lived branches — guarantees painful merges and large, risky releases, which is the cost being traded against.

Question 21

What DORA metrics would you track?

Accepted Answer

Deployment frequency, lead time for changes, change failure rate and time to restore service. Together they measure both speed and stability, and the research finding is that high performers improve both simultaneously rather than trading one against the other. The insight to state is that speed and stability are not opposed: smaller, more frequent changes are easier to test, review and roll back, so they fail less and recover faster. That reframing is exactly what a DevOps interviewer wants.

Question 22

How do you handle a flaky test suite?

Accepted Answer

Quarantine flaky tests so they do not block the pipeline, but track them as defects with owners rather than deleting them; find the cause — shared state, timing assumptions, real network calls, test ordering — and fix it; and measure flakiness rate as a first-class metric. The reason it matters is trust: once a red build is assumed to be flaky, real failures are ignored and the pipeline stops protecting anything. Framing flakiness as a reliability problem rather than an annoyance is the mature position.

Question 23

How would you structure CI/CD for a monorepo?

Accepted Answer

Use path filters or a build tool that understands the dependency graph so only affected components build; cache aggressively; run component pipelines in parallel; and version and deploy components independently rather than releasing the whole repository together. Without this the pipeline duration grows with repository size until developers batch changes to avoid waiting. Computing the affected target set from the dependency graph, rather than only path filters, is the more accurate approach.

Question 24

What is CodeBuild caching and what types exist?

Accepted Answer

S3 caching stores specified paths between builds and works across build hosts. Local caching keeps a Docker layer, source or custom cache on the build host, which is faster but only helps when the same host is reused. Docker layer caching requires privileged mode. The trade-off is that local caching is faster but not guaranteed to be available, while S3 caching is reliable but adds download time. Caching correctness matters too — a stale cache producing a build that works locally and fails in production is worse than a slow build.

Question 25

How do you deploy to multiple regions safely?

Accepted Answer

Deploy region by region rather than everywhere at once, starting with the lowest-traffic region, with a soak period and automated metric verification between each. CodePipeline supports cross-region actions, and StackSets can stage deployments with concurrency and failure tolerance. The reason is blast radius: a simultaneous global deploy makes a bad change a global outage, while a staged one makes it a single-region incident you can shift traffic away from. The soak period and abort criterion are what make it a real strategy.

Question 26

What is an ephemeral or preview environment and how would you build one?

Accepted Answer

A short-lived environment created per pull request so reviewers can exercise the change. On AWS, deploy the built image to a per-PR ECS service or Lambda alias with its own path on a shared ALB, or an App Runner service, with a seeded test database, torn down automatically when the pull request closes. Automatic teardown is what stops preview environments becoming permanent cost and orphaned resources. Using a shared load balancer with per-PR routing rules is cheaper than a load balancer per environment, which is the practical cost detail.

Question 27

What is the difference between continuous integration, delivery and deployment?

Accepted Answer

Continuous integration is merging and automatically testing every change frequently. Continuous delivery means every passing build is automatically prepared and could be released, with a human decision to release. Continuous deployment releases every passing build automatically with no manual gate. The distinction people blur is delivery versus deployment, and the honest point is that continuous deployment requires very high confidence in automated testing plus progressive delivery and fast rollback. Recommending it without those is reckless.

Question 28

How do you roll back quickly?

Accepted Answer

Blue/green or traffic shifting so rollback is a traffic change rather than a redeploy; immutable artefacts so the previous version still exists; automatic rollback on CloudWatch alarms in CodeDeploy; feature flags to disable a feature without deploying; and backwards-compatible schema so the old code still works. The schema compatibility point is what makes rollback genuinely possible — if the deploy included a destructive migration, reverting the code does not restore service. That coupling is the most common reason a rollback fails when it is actually needed.

Question 29

What is GitOps and can you do it on AWS?

Accepted Answer

GitOps makes a Git repository the source of truth for desired state with an agent continuously reconciling the cluster to match. On EKS you would use Flux or Argo CD, and AWS offers Flux as an EKS add-on. Drift is corrected automatically and every change is a reviewed commit. The properties to name are drift correction and auditability. The trade-off is that emergency manual changes are reverted unless you have a defined break-glass procedure, which is worth acknowledging rather than presenting reconciliation as purely beneficial.

Question 30

How do you secure a CI/CD pipeline?

Accepted Answer

Least-privilege per-environment deployment roles; OIDC federation instead of stored keys; secrets from Secrets Manager rather than environment variables; require review on pipeline configuration changes since they are as powerful as code; scan for committed secrets and vulnerable dependencies; and separate the identity that can deploy to production from the one used for lower environments. The point that most pipelines get wrong is that a build with production deployment permission effectively grants production access to anyone who can merge a change to the build configuration. Requiring review on pipeline files specifically is the control.

Question 31

How do you handle a dependency with a critical vulnerability in production?

Accepted Answer

Assess exploitability in your context first — is the vulnerable code path reachable. Then patch by updating and running the pipeline; if no patch exists, mitigate with a WAF rule, configuration change or feature disablement. Inspector identifies which running images and functions are affected. The assessment-before-panic step distinguishes a senior answer: not every critical CVE is exploitable in a given deployment, and treating them all as emergencies exhausts the team. Having an inventory that answers "which of our artefacts contain this" is the capability being tested.

Question 32

What is the difference between CodePipeline V1 and V2, or when would you use a third-party CI?

Accepted Answer

CodePipeline V2 adds parameterised executions, triggers with filters, stage-level conditions and rollback, and per-action pricing. Many teams still use GitHub Actions or GitLab for build and test because of developer experience and ecosystem, using AWS tooling only for deployment. Being willing to say the AWS developer tools are not always the best choice is a credible answer rather than a disloyal one. The hybrid pattern — GitHub Actions building and CodeDeploy deploying with OIDC — is extremely common in practice.

Question 33

How do you measure and improve pipeline reliability?

Accepted Answer

Track build success rate, duration percentiles, flakiness rate and queue time. Treat pipeline failures not caused by the change as incidents with owners. Reduce duration with caching and parallelism, reduce flakiness by fixing shared state and timing assumptions, and alert when main is red. Treating the pipeline as a production system with its own SLO is the framing that matters, because every developer depends on it. A team tolerating a 70% build success rate has effectively lost continuous integration.

Question 34

What is immutable infrastructure and how does it change deployment?

Accepted Answer

Servers and containers are never modified after deployment — to change anything you build a new artefact and replace the old one. Deployment becomes replacement rather than mutation, rollback becomes redeploying the previous artefact, and configuration drift becomes impossible. On AWS this means golden AMIs built by Image Builder or containers, deployed by replacing instances or tasks. The contrast is in-place configuration management, where every server's state is the result of a unique history nobody can reproduce.

Question 35

How do you deploy a change that affects multiple services?

Accepted Answer

Design so ordering does not matter: make APIs backwards and forwards compatible, use expand-and-contract for contract changes, and have services tolerate a dependency being briefly on the old version. Where ordering genuinely matters, express it in the pipeline explicitly rather than relying on timing. The general rule is that a deployment requiring a specific cross-team order will eventually be done in the wrong order. Designing for order-independence is more robust than coordinating, and saying so demonstrates systems thinking.

Question 36

What is a deployment lifecycle hook in CodeDeploy?

Accepted Answer

Lifecycle hooks run scripts or Lambda functions at defined points — BeforeInstall, AfterInstall, ApplicationStart, ValidateService for EC2; BeforeAllowTraffic and AfterAllowTraffic for Lambda and ECS. A hook returning failure aborts the deployment and triggers rollback. The validation hook is what turns a deployment into a gated one: a function that exercises the new version and fails the deployment if it misbehaves. That automated verification is the difference between a canary and simply shifting traffic and hoping.

Question 37

How would you introduce CI/CD to a team doing manual deployments?

Accepted Answer

Start with the pain: automate the deployment itself first, because manual deployment is both risky and limits release frequency. Then automate tests, then environment provisioning. Do it incrementally on a low-risk service, demonstrate the benefit, and pair with the team rather than mandating a standard. The paved-path idea is the important one: adoption happens when the automated way is also the easiest way. Naming that you would measure current lead time and change failure rate first, so improvement is demonstrable, turns advocacy into evidence.

Question 38

Design an end-to-end CI/CD pipeline for a containerised service on AWS.

Accepted Answer

Pull request triggers lint, unit tests, dependency and secret scanning, and a build that is not published. On merge, build once and push to ECR tagged with the commit SHA, scan with Inspector, and sign with Signer. CodePipeline or GitHub Actions promotes the same digest: automatic to dev, automatic to staging with smoke tests, and to production behind an approval gate with a CodeDeploy blue/green or canary strategy and automatic rollback on alarm. Infrastructure deploys through a separate IaC pipeline. Secrets from Secrets Manager, authentication via OIDC with per-environment least-privilege roles, and DORA metrics tracked. The closing scenario. The senior markers are build-once-promote-many by digest, a separate infrastructure pipeline, per-environment identities, and automatic rollback tied to alarms — because a single build identity with production access is the most common weakness in otherwise well-built pipelines.

AWS CI/CD & Deployment Strategies Interview Questions and Answers

How to use this set