If you are preparing for a senior AWS Cloud Engineer, DevOps Engineer, or Cloud Architect interview in 2026, this is the most comprehensive question bank you will need. We have collected 31 questions across four themes - AWS Infrastructure Management, CloudFormation / Infrastructure as Code, Monitoring & Observability, and Technical Leadership - plus 5 real-world scenario questions that appear in senior rounds at MNCs + hyperscalers hiring in India.
Each answer is written the way an actual senior engineer would answer at an interview - concrete, structured, and with the numbers, service names, and trade-offs that interviewers listen for. Bookmark this page; use it as your revision cheat sheet.
Table of Contents
- AWS Infrastructure Management (Q1-Q9)
- CloudFormation & Infrastructure as Code (Q10-Q19)
- Monitoring & Observability (Q20-Q26)
- Technical Leadership (Q27-Q31)
- Scenario Questions for Senior Rounds
- Next Steps + Cloudsoft AWS Training
1. AWS Infrastructure Management
Q1. Walk me through how you would design a highly available, enterprise-grade 3-tier application on AWS.
I start with the account structure: AWS Organizations or Control Tower, with separate accounts for prod, non-prod, security/logging, and shared networking. Inside the workload account I build a VPC spanning three Availability Zones, with public subnets for the ALB and NAT gateways, private app subnets, and isolated data subnets.
The web/app tier runs in an Auto Scaling Group across all three AZs behind an Application Load Balancer, with WAF in front and CloudFront for static content from S3. The data tier is Aurora or RDS Multi-AZ, plus ElastiCache for sessions and caching.
I use one NAT gateway per AZ so a single AZ failure doesn't break outbound traffic, and VPC endpoints for S3, DynamoDB, and SSM to keep traffic private and cut NAT costs. Route 53 handles DNS with health checks. Everything is deployed through CloudFormation, so the whole environment can be rebuilt.
Q2. How do you manage IAM and user access in a large organization?
The principle is no long-lived credentials and least privilege by default. Humans sign in through IAM Identity Center, federated with the corporate IdP (Azure AD/Okta), and get permission sets mapped to job functions such as ReadOnly, Developer, or PlatformAdmin.
Workloads use IAM roles: instance profiles for EC2, task roles for ECS, IRSA or Pod Identity for EKS. Service Control Policies at the OU level act as guardrails, for example denying the disabling of CloudTrail, restricting regions, or blocking root-user actions. For teams that create their own roles, I enforce permission boundaries so they can't escalate privileges. IAM Access Analyzer flags external access and unused permissions, and I run quarterly access reviews.
Q3. Explain how AWS evaluates an IAM request.
Everything starts as an implicit deny. An explicit deny anywhere wins immediately, whether it's in an SCP, resource policy, permission boundary, session policy, or identity policy.
Beyond that, the action must be allowed by the SCPs (if in an Organization), and then by the identity policy or a resource-based policy. If a permission boundary or session policy exists, the action must fall within those too. The effective permission is the intersection of these layers.
A common interview trap: an admin policy on a user doesn't help if an SCP denies the action.
Q4. Security Groups vs NACLs: when do you use which?
- Security groups are stateful, attached to ENIs, support allow rules only, and evaluate all rules together.
- NACLs are stateless, work at the subnet level, support both allow and deny, and are evaluated in rule-number order until the first match.
- Since NACLs are stateless, you must allow ephemeral ports (1024-65535) for return traffic.
In practice, security groups are my primary control, and I reference other security group IDs rather than CIDRs, for example allowing the DB SG to accept 5432 only from the app SG. I use NACLs sparingly as a coarse subnet-level guardrail or to quickly block a malicious IP range during an incident.
Q5. How do you approach AWS cost optimization?
I work in three phases:
- Visibility: enforced cost-allocation tags (via tag policies), Cost Explorer, the Cost and Usage Report into Athena, AWS Budgets, and Cost Anomaly Detection.
- Quick wins: rightsizing with Compute Optimizer, moving EBS from gp2 to gp3 (about 20% cheaper per GB), deleting unattached volumes and old snapshots, setting CloudWatch Logs retention (the default is "never expire"), S3 lifecycle rules or Intelligent-Tiering, and replacing NAT traffic to S3 with gateway endpoints.
- Pricing models: Compute Savings Plans for the steady baseline, Spot for stateless and batch workloads, Graviton instances for better price-performance, and scheduling non-prod to shut down nights and weekends.
In a real answer, quote a number: "we reduced monthly spend by 28% in one quarter, mostly from rightsizing and Savings Plans."
Q6. Explain the DR strategies on AWS and how you choose one.
There are four, in increasing cost and decreasing RTO/RPO:
- Backup and restore - hours of RTO; AWS Backup with cross-region copies is enough.
- Pilot light - core data replicated to a second region; compute defined in CloudFormation and launched only when needed.
- Warm standby - runs a scaled-down but fully functional copy in the DR region.
- Multi-site active-active - serves traffic from both regions.
The choice is driven by the business's RTO/RPO per application, not by technology. A payments system might need warm standby with Aurora Global Database (typically under a second of replication lag), while an internal reporting tool is fine with backup and restore.
The part interviewers really listen for: DR is only real if you test it. I run scheduled DR drills and document the actual RTO achieved.
Q7. What's the difference between high availability and disaster recovery?
- HA protects against component or AZ failure within a region through Multi-AZ, Auto Scaling, and load balancing. Usually automatic, no data loss.
- DR protects against region-wide failure, data corruption, or ransomware. Involves a deliberate failover process with a defined RTO/RPO.
Multi-AZ RDS is HA. A cross-region read replica or backup copy is DR. Note that replication alone isn't DR against corruption, because a bad write gets replicated too. You also need point-in-time backups.
Q8. How do you give engineers access to EC2 instances securely?
I avoid SSH keys and bastion hosts entirely and use SSM Session Manager. Access is controlled by IAM, no inbound port 22 is needed, sessions are logged to S3 or CloudWatch Logs for audit, and it works for instances in private subnets through VPC endpoints. For emergency access I have a break-glass role with MFA and alerting on its use.
Q9. How do you connect dozens of VPCs and on-prem networks?
VPC peering doesn't scale because it's non-transitive and becomes a full mesh. I use Transit Gateway as a hub, with route tables to segment prod from non-prod, connected to on-prem via Direct Connect (with a Site-to-Site VPN as backup). For exposing a single service privately to other accounts without full network connectivity, I use PrivateLink. I also plan CIDR ranges centrally, using IPAM, to avoid overlaps.
2. CloudFormation & Infrastructure as Code
Q10. How do you structure CloudFormation for a large enterprise environment?
I split by lifecycle and ownership into layered stacks: network (VPC, subnets, TGW attachments), security (IAM roles, KMS keys, security groups), data (RDS, S3), and application (ASG, ALB, ECS). Layers that change at different rates stay separate so an app deploy can't accidentally touch the VPC.
For sharing values between stacks I use Exports and Fn::ImportValue for stable values like VPC IDs, or SSM Parameter Store for looser coupling. The trade-off with exports: you can't change or delete an exported value while another stack imports it. Nested stacks work well for reusable components deployed together as one unit. For multi-account and multi-region baselines (CloudTrail, Config, GuardDuty roles), I use StackSets.
Q11. How do you safely update production stacks?
I always use change sets, never direct updates, so I can review exactly what will be modified and, critically, what will be replaced. Replacement of an RDS instance or a named resource is the biggest risk. On stateful resources I set DeletionPolicy and UpdateReplacePolicy to Retain or Snapshot.
I apply stack policies to prevent updates to critical resources, and enable termination protection on production stacks. I also run drift detection regularly to catch manual console changes before they cause update failures.
ProdDatabase:
Type: AWS::RDS::DBCluster
DeletionPolicy: Snapshot
UpdateReplacePolicy: Snapshot
Properties:
MasterUserPassword: '{{resolve:secretsmanager:prod/db:SecretString:password}}'
Q12. A stack update failed and is stuck in UPDATE_ROLLBACK_FAILED. What do you do?
This usually happens because a resource can't be rolled back - for example someone manually deleted it, or a dependency changed outside CloudFormation. I check the stack events to find the failing resource, fix the underlying cause if possible, and then run continue-update-rollback. If a resource genuinely can't be restored, I use the --resources-to-skip option, which marks it as rolled back so the stack becomes usable again, and then I reconcile that resource manually.
Prevention is the better answer: drift detection, and restricting console write access in production.
Q13. How do you make templates reusable across teams?
- Parameterize environment-specific values and keep per-environment parameter files in Git.
- Use Mappings for things like AMI IDs or instance sizes per environment.
- Use Conditions for environment-specific resources (creating a NAT gateway per AZ only in prod).
- For standard building blocks, use CloudFormation Modules or a library of nested-stack templates in S3.
- For self-service, publish approved patterns through Service Catalog so teams can launch a compliant "standard web app" without writing templates themselves.
Q14. What are custom resources, and what's the common pitfall?
A custom resource lets CloudFormation call a Lambda function (or SNS topic) for anything CloudFormation doesn't natively support - such as looking up a value from an external system, seeding a database, or cleaning out an S3 bucket before deletion. The Lambda must send a SUCCESS or FAILED response to the pre-signed S3 URL CloudFormation provides.
The classic pitfall: an unhandled exception that never sends a response leaves the stack hanging until timeout (an hour by default, now configurable with ServiceTimeout). So I always wrap the handler in try/except and send FAILED on error, and I handle Delete events properly so stack deletion doesn't break.
Q15. How do you handle secrets in CloudFormation?
Never hardcode them or pass them as plain parameters. I use dynamic references, {{resolve:secretsmanager:...}} or {{resolve:ssm-secure:...}}, so the value is resolved at deploy time and never stored in the template. For RDS, I can use ManageMasterUserPassword so RDS manages the secret in Secrets Manager itself. Any parameter that must be sensitive gets NoEcho: true - keeping in mind that it only masks display and isn't encryption.
Q16. Describe your CI/CD pipeline for infrastructure code.
Templates live in Git with branch protection. A pull request triggers validation: cfn-lint for syntax and best practices, and cfn-guard or cfn-nag for security and compliance rules (for example, no public S3 buckets, encryption required).
After peer review and merge, the pipeline (CodePipeline, GitHub Actions, or Jenkins) creates a change set in dev, deploys, runs smoke tests, then promotes to staging and prod. Production has a manual approval step where the reviewer looks at the change set output. Every stack is tagged with the Git commit, so we can trace any resource back to the code that created it.
Q17. CloudFormation vs Terraform vs CDK: how would you choose?
- CloudFormation is AWS-native with managed state, day-one support for many services, drift detection, and StackSets - but verbose and AWS-only.
- Terraform is multi-cloud, has a strong module ecosystem, and plan output is very readable - but you have to manage state files (S3 plus DynamoDB locking) and provider versions.
- CDK lets you write infrastructure in TypeScript or Python with real abstractions and synthesizes to CloudFormation - great for developer-heavy teams but adds a layer to debug.
My honest answer: the org's existing skills and multi-cloud needs matter more than the tool. For an AWS-only enterprise already on CloudFormation, I'd standardize on it and consider CDK for complex, logic-heavy stacks.
Q18. How do you ensure an EC2 instance is fully configured before CloudFormation marks it complete?
I use a CreationPolicy with a resource signal, or on an ASG, an UpdatePolicy with rolling updates. The instance's user data runs cfn-init for configuration and then cfn-signal to report success. If the signal doesn't arrive within the timeout, the stack fails and rolls back instead of reporting success with a half-configured server.
Q19. You inherit infrastructure built manually in the console. How do you bring it under IaC?
CloudFormation supports resource import, where I write the template to match the existing resources, set DeletionPolicy: Retain, and import them into a new or existing stack. The IaC generator can scan the account and produce a starting template. I do this incrementally, starting with low-risk resources, run drift detection after each import to confirm the template matches reality, and then lock down console write access so drift doesn't return.
3. Monitoring & Observability
Q20. How do you establish performance baselines and key metrics?
I use the four golden signals (latency, traffic, errors, saturation) for services, and USE (utilization, saturation, errors) for infrastructure. Concretely:
- ALB: request count, TargetResponseTime at p50/p95/p99, HTTP 5xx rate, healthy host count
- EC2: CPU, memory, and disk (memory and disk need the CloudWatch agent - a common interview point)
- RDS: CPU, connections, read/write latency, free storage, and replica lag
I collect two to four weeks of data across normal and peak cycles to set the baseline, then define SLOs, for example 99.9% of requests under 500 ms. Watch percentiles, not averages, because averages hide tail latency.
Q21. How do you design alarms without causing alert fatigue?
Every alarm must be actionable, and if nobody needs to act, it's a dashboard metric, not an alarm. I use "M out of N datapoints" evaluation to avoid flapping on single spikes, anomaly detection alarms for metrics with daily patterns, and composite alarms so one underlying problem produces one page instead of twenty.
Alarms are tiered by severity: critical goes to PagerDuty or Opsgenie, warnings go to Slack via Amazon Q Developer in chat applications (formerly AWS Chatbot). I set "treat missing data" deliberately, since missing data can itself mean an outage. Each critical alarm links to a runbook.
Q22. How do you implement centralized logging?
All accounts send logs to CloudWatch Logs with explicit retention per log group, since the "never expire" default is a silent cost leak. For org-wide visibility I use CloudWatch cross-account observability, where a central monitoring account sees metrics, logs, and traces from source accounts. For long-term or compliance storage, subscription filters stream logs through Kinesis Data Firehose to S3 (and to OpenSearch if the team needs full-text search). CloudTrail and VPC Flow Logs go to a dedicated log-archive account with an S3 bucket that has Object Lock enabled.
Sample CloudWatch Logs Insights query for finding the slowest endpoints:
fields @timestamp, path, duration
| filter status >= 500 or duration > 1000
| stats count() as errors, avg(duration) as avg_ms, pct(duration, 99) as p99 by path
| sort errors desc
| limit 20
Q23. The ALB's 5xx errors suddenly spike. Walk me through your troubleshooting.
First I separate HTTPCode_ELB_5XX_Count from HTTPCode_Target_5XX_Count.
- ELB 5xx (502/503/504) - no healthy targets, targets resetting connections, or timeouts.
- Target 5xx - the application itself is returning errors.
Next, I check whether anything changed - a recent deployment, CloudFormation update, or ASG scaling event, since most incidents correlate with a change. Then I look at HealthyHostCount and the target health reasons, TargetResponseTime, and resource saturation on the instances. Downstream, I check RDS connections and CPU - connection exhaustion is a common cause. Logs Insights on the application logs and X-Ray traces show where the latency or errors originate.
If a deploy is the cause, I roll back first and investigate after, because restoring service comes before root cause.
Q24. How do you publish custom application metrics?
For Lambda and containers, I prefer the Embedded Metric Format: the app writes structured JSON logs, and CloudWatch automatically extracts metrics from them, which is cheaper and simpler than calling PutMetricData. For existing logs, metric filters turn patterns like "ERROR" or "PaymentFailed" into metrics. I'm careful with high-cardinality dimensions such as user ID, because every unique combination is billed as a separate metric.
Q25. What makes monitoring proactive rather than reactive?
- CloudWatch Synthetics canaries - test critical user journeys (login, checkout) every few minutes, so we know before customers do.
- Anomaly detection - catches unusual patterns before thresholds are breached.
- Capacity trend alarms - "disk will be full in 7 days."
- Auto-remediation - EventBridge rules trigger SSM Automation runbooks (restart a hung service, expand a volume).
- AWS Health events for scheduled maintenance and service issues.
- Trusted Advisor findings reviewed regularly.
After every incident, the postmortem asks what signal could have warned us earlier, and we add it.
Q26. How do SLIs, SLOs, and error budgets fit into your work?
An SLI is the measurement (percentage of successful requests under 300 ms). The SLO is the target (99.9% over 30 days). The error budget is the allowed failure - roughly 43 minutes a month at 99.9%. I track SLOs in CloudWatch, where Application Signals supports SLOs natively, and alert on burn rate rather than raw errors.
The error budget also becomes a leadership tool: if a team has burned its budget, the priority shifts from features to reliability work, and that decision is backed by data rather than opinion.
4. Technical Leadership
Q27. How do you mentor junior engineers on AWS?
I pair them on real tickets rather than giving only theory, starting with low-risk changes in non-prod and gradually moving to production changes under review. Code reviews on CloudFormation are a big teaching moment, so I explain the why behind comments ("this will cause replacement of the database") rather than just approving or rejecting.
I encourage certifications as a structured path (Solutions Architect Associate, then SysOps or DevOps Professional), run short internal knowledge-sharing sessions, and have juniors own runbooks - because writing one forces deep understanding. I measure success by how often they can handle issues without escalating to me.
Q28. How do you run an architecture review?
I use the AWS Well-Architected Framework's six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Before the meeting, the team shares a design doc with a diagram, expected load, RTO/RPO, data classification, and cost estimate.
In the review, I focus on failure modes ("what happens when this AZ or this dependency goes down?"), security boundaries, scaling limits and service quotas, and operational readiness (monitoring, runbooks, rollback plan). Decisions and trade-offs are recorded as Architecture Decision Records so future engineers understand why choices were made.
Q29. The business wants to cut costs, but you believe it will hurt reliability. How do you handle it?
I translate the trade-off into business terms instead of arguing technically. For example: "Removing the Multi-AZ standby saves Rs.X per month, but an AZ outage would mean about 30-60 minutes of downtime, and during our peak hour that's Rs.Y in lost transactions."
I present options rather than a flat no: keep Multi-AZ for revenue-critical databases and save elsewhere through Savings Plans or by scheduling non-prod. Ultimately the business owns the risk decision - my job is to make sure it's an informed one, documented.
Q30. How do you keep up with AWS changes and bring innovation to the team?
I follow the AWS What's New feed and blogs, watch re:Invent sessions relevant to our stack, and try new services in a sandbox account. The key is filtering - I don't adopt services because they're new. When something looks useful, I run a small proof of concept with a measurable goal, for example migrating one workload to Graviton to measure cost and performance, and share the results with the team before proposing wider adoption.
Q31. Tell me about a major production incident you handled.
Use the STAR structure (Situation, Task, Action, Result) with a real example. A sample shape:
"Our checkout API started returning 503s during a sale. I led the incident bridge. CloudWatch showed healthy hosts dropping and RDS connections at maximum. A new release had removed connection pooling. We rolled back within 12 minutes, then scaled the ASG to drain the backlog. In the blameless postmortem, we added an RDS connections alarm at 80%, a load test stage in the pipeline, and deployed RDS Proxy. We had no recurrence."
Interviewers look for calm coordination, rollback-first thinking, and the concrete preventive actions afterward.
Scenario Questions to Practice Aloud
These appear in senior rounds. Rehearse using the frameworks above:
Scenario 1 - S3 Bucket Deletion Recovery
Q: Someone accidentally deleted a production S3 bucket's objects. How do you recover, and how do you prevent it?
A: Versioning + MFA delete + Object Lock + AWS Backup + SCPs denying deletion. If versioning was on, restore prior versions; if not, hope for AWS Backup or point-in-time. Prevention layers: SCP deny on s3:DeleteBucket for prod accounts, Object Lock in compliance mode, replication to a locked cross-region bucket.
Scenario 2 - AWS Bill Jumped 40% Overnight
Q: Your AWS bill jumped 40% overnight. What do you check first?
A: Cost Anomaly Detection, Cost Explorer by service and by tag, CloudTrail for new resources (especially cross-region), NAT and data transfer surges, and CloudTrail for compromised credentials launching unauthorized instances. Immediate action: rotate keys, scope down permissions, terminate rogue resources, engage AWS Support if suspected abuse.
Scenario 3 - Access Key Leaked on GitHub
Q: An access key was leaked on GitHub. What are your first 30 minutes?
A: (1) Deactivate the key immediately in IAM. (2) Rotate + scope-down the associated principal. (3) Check CloudTrail for the key's recent activity - what was accessed. (4) Look for new IAM users, roles, or instances launched in all regions (attackers stage backup access). (5) Rotate downstream secrets accessed by that principal. (6) Long-term: move to IAM roles or OIDC federation with GitHub Actions, and add GitHub secret scanning + AWS credential scanners.
Scenario 4 - DR for 15-min RTO / 1-min RPO
Q: Design DR for an app requiring RTO of 15 minutes and RPO of 1 minute.
A: Warm standby + Aurora Global Database (sub-second replication lag) + cross-region S3 replication for static assets + Route 53 failover with health checks + a pre-built CloudFormation stack in the DR region for compute + regular DR drills to validate actual RTO. Prefer Application Recovery Controller for coordinated failover.
Scenario 5 - CloudFormation Change Would Replace Production RDS
Q: Deploying a CloudFormation change would replace your production RDS instance. How do you proceed?
A: Stop. Identify the property causing replacement (DB engine version, instance class in some cases, subnet group, DB name change). Take a fresh snapshot. Plan a maintenance window OR - much preferred - use RDS Blue/Green Deployments to stage the new instance, replicate, switchover atomically. Update the CloudFormation template afterwards with DeletionPolicy: Snapshot before ever running it again.
Next Steps + Cloudsoft AWS Training
These questions represent about 4-5 rounds' worth of senior AWS interviews at major MNCs and cloud consultancies hiring in India. The candidates who consistently clear them share three traits:
- They've built something real - not just watched courses. A live 3-tier app in a personal AWS account speaks louder than any certificate alone.
- They can explain trade-offs, not just facts. Interviewers ask "why" until they hit bedrock.
- They've practiced the scenario questions aloud - the framework is what stops you from freezing.
Cloudsoft's AWS + Multi-Cloud Track
Cloudsoft Solutions (Hyderabad) runs AWS + Azure + GCP instructor-led programs specifically designed for freshers + working professionals targeting cloud engineer, DevOps, and cloud architect roles. Programs include real-world CloudFormation projects, DR simulation labs, and mock interview cycles that mirror the questions above.
- Cloudsoft APEX - AI + Cloud + Security 2026 Flagship
- All Interview Questions Library
- Fresher Cloud + DevOps Job Alerts
- Cloudsoft Blog
If you're preparing for a specific company or role, contact Cloudsoft - we can design a targeted 6-8 week interview prep track around your target JD.
Disclaimer: These are model answers for interview preparation. Verify current AWS service behavior, pricing, and best practices against official AWS documentation before production use.
