Amazon Cloud Architect (Entry Level) - Comprehensive Interview Preparation Guide

Cloud Architect

Amazon

entry

6 rounds

Updated 6/24/2026

Amazon's interview process for a Cloud Architect (Entry Level) typically consists of a recruiter screening phase followed by technical phone screens and onsite interviews. The process evaluates foundational cloud architecture knowledge, AWS service proficiency, basic system design thinking, ability to explain technical concepts clearly, and cultural alignment with Amazon's Leadership Principles. For an entry-level role, interviewers focus on learning potential, problem-solving approach, and ability to work collaboratively rather than advanced expertise.

Interview Rounds

Recruiter Screening

30 min3 focus topicsculture fit

Technical Phone Screen 1: AWS Fundamentals

45 min4 focus topicstechnical

What to Expect

First technical phone screen conducted by an AWS-experienced engineer or architect. Focuses on foundational AWS services, basic architectural concepts, and your ability to think through cloud design problems. You'll be asked about AWS services commonly used in enterprise solutions, basic architectural patterns, and your understanding of when to use specific services. Expect a mix of conceptual questions and simple design scenarios.

Tips & Advice

Review core AWS services thoroughly: EC2, S3, RDS, Lambda, API Gateway, CloudFront, VPC, IAM, CloudWatch, and Auto Scaling[1][2]. Be able to explain what each service does and when to use it. For design questions, think aloud and ask clarifying questions before diving into a solution. Explain your reasoning for architectural choices (e.g., why use Lambda vs EC2 for this use case?). Reference the AWS Well-Architected Framework pillars when discussing design decisions[1]. For entry-level, demonstrating clear thinking and learning ability is more important than perfect answers.

Focus Topics

Infrastructure as Code Concepts

Basic understanding of IaC tools (CloudFormation, Terraform) and why treating infrastructure as code matters[1]. No deep expertise needed at entry level.

Practice Interview

Study Questions

Basic Architecture Patterns and Design Decisions

Understand simple architectural patterns: high availability with multiple AZs, auto-scaling for resilience, content delivery with CloudFront, database replication for reliability[1].

Practice Interview

Study Questions

AWS Well-Architected Framework Pillars

Understand the five pillars: Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization. Know examples and practices for each[1].

Practice Interview

Study Questions

AWS Core Services Knowledge

Deep understanding of EC2, S3, RDS, Lambda, API Gateway, CloudFront, VPC, IAM, Auto Scaling, CloudWatch—what each does, when to use, basic configuration.

Practice Interview

Study Questions

Technical Phone Screen 2: Practical Architecture Scenarios

50 min5 focus topicssystem design

What to Expect

Second technical phone screen focusing on practical application of architectural knowledge. You'll be presented with realistic but simpler business scenarios and asked to design cloud solutions. Examples might include designing a scalable web application, planning a migration from on-premises to AWS, or addressing performance and cost challenges. The interviewer assesses your problem-solving approach, ability to ask clarifying questions, and how well you balance competing requirements.

Tips & Advice

When given a design scenario: (1) Ask clarifying questions about scale, requirements, constraints, and business goals before proposing solutions. (2) Start with a simple design and iteratively improve it based on feedback. (3) Discuss trade-offs explicitly (availability vs. cost, consistency vs. performance). (4) Mention relevant AWS services and explain why you chose them. (5) Consider security, reliability, and cost in your designs[1]. (6) Draw or verbally describe architectures clearly. (7) For entry-level, showing good problem-solving process is more valuable than a perfect solution. Acknowledge limitations of your design and discuss improvements.

Focus Topics

Security and Compliance Considerations in Architecture

Basic security thinking: IAM roles and policies, network security (VPCs, security groups), encryption at rest and in transit, data isolation, compliance requirements.

Practice Interview

Study Questions

Cost Optimization and Resource Efficiency

Understanding how to design for cost efficiency: right-sizing instances, using serverless where appropriate, choosing storage options wisely, monitoring costs[1].

Practice Interview

Study Questions

Problem-Solving and Communication Skills

Ability to ask clarifying questions, think through problems systematically, communicate reasoning clearly, and adapt based on feedback.

Practice Interview

Study Questions

Cloud Migration Strategy Basics

Understand basic migration approaches: lift-and-shift, re-platforming, refactoring. Know how to assess what should migrate and in what order. Consider dependencies and risks.

Practice Interview

Study Questions

Designing Highly Available and Scalable Web Applications

Design end-to-end architectures for web applications: load balancing, multi-AZ deployment, auto-scaling, content delivery, database design, considering resilience and growth[1].

Practice Interview

Study Questions

Onsite Interview 1: Behavioral and Culture Fit

45 min5 focus topicsbehavioral

What to Expect

First onsite interview focusing on behavioral competencies and alignment with Amazon's Leadership Principles. The interviewer asks about past experiences using the STAR method (Situation, Task, Action, Result) to understand how you've handled challenges, collaborated with teams, learned from failures, and demonstrated leadership qualities. For entry-level, expect questions about academic projects, internships, or work experiences where you showed initiative, learning ability, and problem-solving.

Tips & Advice

Prepare 6-8 concrete stories from your background (projects, internships, coursework, volunteering) that demonstrate Amazon's Leadership Principles[3]. Use the STAR method: Situation (context), Task (your role/responsibility), Action (what you did), Result (outcome and learning). Focus on: taking ownership, delivering results even with limitations, learning from mistakes, collaborating effectively, showing customer obsession, and thinking long-term. For entry-level, it's acceptable to use academic or small project examples. Be specific with details and quantifiable results where possible. Practice out loud to improve delivery.

Focus Topics

Handling Failure and Problem-Solving

Discuss a specific project or challenge that didn't go as planned. Explain what went wrong, what you learned, and how you'd approach it differently. Show resilience and growth mindset.

Practice Interview

Study Questions

Collaboration and Communication in Technical Teams

Share examples of working effectively with team members, communicating technical ideas clearly, handling disagreements professionally, and supporting others.

Practice Interview

Study Questions

Amazon Leadership Principle: Learning and Growth

Discuss experiences where you learned new technologies, admitted knowledge gaps, sought mentorship, or grew from feedback. Entry-level candidates should emphasize learning potential.

Practice Interview

Study Questions

Amazon Leadership Principle: Ownership

Show examples of taking responsibility for outcomes, being proactive, going beyond your specific role, and following through on commitments.

Practice Interview

Study Questions

Amazon Leadership Principle: Customer Obsession

Demonstrate understanding that at Amazon, everything starts with customer needs. Share an example where you prioritized customer needs or user experience in a project or decision.

Practice Interview

Study Questions

Onsite Interview 2: Technical Depth - AWS Architecture

60 min5 focus topicstechnical

What to Expect

Second onsite interview with an AWS architect or senior engineer diving deeper into technical architecture knowledge. Expect detailed questions about AWS service selection, architectural trade-offs, reliability and disaster recovery, microservices patterns, and resolving real architectural challenges. You might be given a more complex scenario than phone screens and need to discuss multiple solutions with pros/cons. The interviewer assesses depth of AWS knowledge, architectural thinking, and ability to make principled technical decisions.

Tips & Advice

Review advanced topics: disaster recovery strategies (RTO/RPO, Backup & Restore, Pilot Light, Warm Standby, Active-Active)[1], microservices architecture patterns[1], database selection trade-offs (RDS vs DynamoDB), performance optimization, and reliability design. Be prepared to discuss real scenarios: how would you handle a traffic spike? How would you design for multi-region resilience? What are the trade-offs of different approaches? For entry-level, don't be expected to know every detail, but demonstrate systematic thinking. Ask clarifying questions, discuss trade-offs explicitly, and explain your reasoning. Reference the Well-Architected Framework[1].

Focus Topics

AWS Lambda and Serverless Architecture Patterns

Understand when to use serverless (Lambda, managed services) vs traditional compute. Know limitations, cold starts, event-driven patterns, and cost implications[1].

Practice Interview

Study Questions

Performance, Reliability, and Scalability Design

Design patterns for high availability (multi-AZ, auto-scaling), performance optimization (caching, CDN, database optimization), and handling scale.

Practice Interview

Study Questions

Database Architecture and Selection

Understand when to use RDS (relational), DynamoDB (NoSQL), ElastiCache (caching), and other storage solutions. Know replication, consistency models, and scaling characteristics.

Practice Interview

Study Questions

Disaster Recovery and Business Continuity Architecture

Understand RTO (Recovery Time Objective) and RPO (Recovery Point Objective), different DR strategies on AWS from simple Backup & Restore to multi-region Active-Active[1]. Know trade-offs in cost and complexity.

Practice Interview

Study Questions

Microservices Architecture and Service Design

Understand microservices patterns: compute layer choices (ECS vs EKS vs Lambda)[1], API management (API Gateway), inter-service communication (sync vs async), database per service pattern, observability with X-Ray and CloudWatch[1].

Practice Interview

Study Questions

Onsite Interview 3: Architecture Design Case Study

60 min5 focus topicssystem design

What to Expect

Final onsite interview featuring an extended architecture case study or design exercise. You'll be presented with a more complex, realistic business scenario (e.g., designing infrastructure for a new product, planning migration of an enterprise application, or addressing scalability challenges). You'll have 45-60 minutes to think through the problem, ask clarifying questions, propose architectural solutions, and discuss trade-offs. The interviewer acts as a stakeholder, asking follow-up questions and pushing on your decisions. This round assesses holistic architectural thinking, ability to handle ambiguity, decision-making framework, and communication.

Tips & Advice

Structure your approach: (1) Ask clarifying questions about business requirements, scale, constraints, timeline, and existing systems. (2) Outline assumptions explicitly. (3) Propose a baseline architecture, then iteratively enhance it. (4) Discuss multiple approaches and trade-offs (cost vs. complexity, consistency vs. availability, time-to-market vs. optimization). (5) Draw diagrams or describe architecture clearly. (6) Address non-functional requirements: security, compliance, monitoring, disaster recovery, cost. (7) Consider the full lifecycle: not just initial design but evolution and ops. (8) For entry-level, show solid thinking and acknowledge what you'd need to research further. Be confident but humble—it's fine to say 'I'd need to investigate this further' or 'Let me think about that.'

Focus Topics

Communicating Architecture Decisions and Rationale

Ability to explain architectural choices clearly and persuasively, justify decisions to stakeholders, and adapt explanations for different audiences.

Practice Interview

Study Questions

Technology Trade-Off Analysis

Ability to evaluate different technology choices, understand their trade-offs (e.g., consistency vs. availability, cost vs. complexity), and recommend based on requirements.

Practice Interview

Study Questions

Handling Ambiguity and Asking Clarifying Questions

Comfort with incomplete information; ability to identify what's unclear, ask relevant questions, and make reasonable assumptions.

Practice Interview

Study Questions

End-to-End Architecture Design and Decision Making

Ability to design complete cloud solutions from scratch: define requirements, propose architecture, discuss trade-offs, and justify decisions with reasoning.

Practice Interview

Study Questions

Non-Functional Requirements: Security, Reliability, Cost, Performance

Incorporate security (IAM, encryption, network isolation), reliability (multi-AZ, failover), cost optimization, and performance into architectural designs.

Practice Interview

Study Questions

Frequently Asked Cloud Architect Interview Questions

Amazon Web Services Core ServicesMediumTechnical

74 practiced

Describe AWS S3 performance best practices to handle very high PUT/GET throughput (tens of thousands of requests per second). Discuss object key naming strategies, multipart upload, parallelism, S3 Transfer Acceleration, use of range GETs, and how S3 scaling behavior has evolved (prefix limits changes).

Sample Answer

**Overview (role framing)** As a Cloud Architect I design S3-heavy systems for tens of thousands RPS by combining smart key design, parallelism, multipart uploads, and network optimizations while relying on S3’s evolved autoscaling and resilient retry patterns.

**Object key naming strategies**- Avoid monotonically increasing prefixes (e.g., timestamp-first) that historically clustered requests. - Use hashed/randomized prefixes, UUID sharding, or natural fan-out (e.g., tenant-id/hash/objectid) to distribute load across internal partitions. - Prefer meaningful partitioning for lifecycle/queries while ensuring high cardinality at the first few characters.

**Multipart upload & parallelism**- Use multipart upload for large objects; choose part sizes (8–100+ MB typical) to balance concurrency and overhead. - Upload parts in parallel threads/processes; retry individual parts on failure. - For downloads, use parallel ranged GETs to fetch different byte ranges concurrently.

**S3 Transfer Acceleration & network**- Enable S3 Transfer Acceleration for high-latency/global clients to reduce RTT via AWS Edge -> optimized path. Cost vs benefit analysis required. - Use enhanced networking, VPC endpoints, and colocated EC2/EKS in same region to reduce latency for service-to-S3 traffic.

**Range GETs**- For very large objects or high read concurrency, split reads into range GETs to parallelize throughput and reduce per-request latency; reassemble client-side.

**Scaling behavior & prefix limits evolution**- Historically S3 had recommended per-prefix request guidance; since 2018 S3 automatically scales to handle very high request rates per prefix and removed strict per-prefix limits. Still, good key distribution reduces hotspots and variability.

**Operational best practices**- Use exponential backoff and jitter for retries, instrument with CloudWatch metrics (RequestCount, 4xx/5xx, 4xx/5xx per key), enable S3 server access logs or CloudTrail for hotspots, and load-test (e.g., s3-perf) to validate architecture.

Security and Compliance ArchitectureHardSystem Design

46 practiced

Design a robust process and technical controls to handle legal holds and guaranteed deletion in cloud environments, covering primary data, backups, snapshots, caches, and third-party processors. Explain how you'd prove deletion or preservation to legal teams and auditors.

Sample Answer

**Clarify requirements & constraints**- Scope: primary data, backups/snapshots, caches/CDNs, ephemeral stores, third‑party processors- SLAs: retention vs legal‑hold durations, jurisdictional compliance, e‑discovery timelines, need for deletion proof

**High‑level process**1. Central Legal‑Hold Service: single source of truth storing holds, scope (IDs, types, tenants), start/end, custodians, and escalation. Exposes APIs consumed by systems and auditors.2. Policy Engine: translates holds into enforcement (prevent deletion, mark immutable, quiesce backups) and communicates to storage/KMS/CDN/third parties.3. Provenance & Audit Trail: tamper‑evident append‑only ledger (e.g., cloud KVS + cryptographic hashing or ledger service) recording hold creation, scope changes, deletion requests, and all erase actions.

**Technical controls per surface**- Primary data: mark object metadata with hold flags; place objects into immutable containers (WORM/Retention). Deny delete via RBAC + policy engine.- Backups/snapshots: snapshot lifecycle manager checks active holds before pruning; create protected snapshots tagged with hold IDs; store backups in immutable storage tier.- Caches/CDNs/ephemeral: on hold apply bypass markers; ensure cache TTLs set to 0 or purge endpoints honor hold; record purge suppression in audit.- Encryption key destruction: for guaranteed deletion, support crypto‑shredding by destroying KMS key version; log key destruction event and link to data key IDs and manifests.- Third‑party processors: contractual SLOs + API hooks; require attestation, X‑509 signed deletion confirmations, and push manifests back to central ledger.

**Proving deletion/preservation**- Preservation proof: export signed manifests listing object IDs, hashes, storage locations, timestamps, and hold IDs; store manifest in append‑only ledger. Provide immutable snapshots of storage metadata.- Deletion proof: for physical deletion, provide deletion manifest with object IDs, timestamps, storage node IDs, and operation hashes; for crypto‑shred, provide signed KMS key destruction certificate plus mapping of keys -> object envelopes and previous object hashes.- Audit evidence: ledger proofs (Merkle roots), access control logs, backup lifecycle records, network egress records to show no exfiltration, and third‑party signed attestations.

**Scalability & reliability**- Event‑driven propagation (queue + retries) to enforce holds across regions.- Periodic reconciliations and sampling-based proofing at scale.- Playbooks for legal/unexpected failures (freeze, export, manual quarantine).

**Trade‑offs**- Immutable retention vs storage cost; crypto‑shred faster but may not satisfy physical media requirements in some jurisdictions—keep dual strategy (logical & physical where needed).

Outcome: single authoritative hold system + immutable provenance ledger + enforced technical controls across all data surfaces, producing cryptographically signed manifests and KMS attestations auditors and legal teams can verify.

OwnershipHardSystem Design

23 practiced

Design an enterprise governance model that balances team autonomy with centralized ownership of critical cloud practices. Cover policy enforcement (policy-as-code), exception processes, landing zones, guardrails, centralized vs decentralized responsibilities, and how you would evolve governance without slowing innovation.

Sample Answer

**Clarify goals & constraints**- Balance developer autonomy and fast delivery with centralized risk control for security, cost, compliance, and reliability.- Target: self-service, automated guardrails, measurable exceptions, and evolutionary governance.

**High-level model**- Federated governance: central Cloud Platform Team (CPT) owns critical practices, standards, landing-zone templates, policy-as-code, shared services; product teams own workloads and day-to-day infra within constraints.

**Core components**- Landing zones: opinionated, modular blueprints (IaC modules + reference architectures) offering network, identity, logging, observability, and shared services. Ship via managed catalog (e.g., Terraform Registry / Private Module Registry).- Policy-as-code: central repo of policies encoded with OPA/Conftest/Cloud-native policy engines and enforced by CICD and runtime (gate + admission). Policy tiers: Mandatory (block), Recommended (warn), Informational.- Guardrails: automated preventive controls (network ACLs, IAM least-privilege templates, encryption), and detective controls (SIEM alerts, cost anomalies).- Exception process: standardized, auditable exception workflow with TTL and compensating controls. Exceptions requested via ticket and policy metadata; gated by risk owners; auto-expire and require evidence for renewal.- Responsibilities: - Central: policy definition, core platform, shared services, compliance mappings, audit/telemetry, policy infra. - Teams: adopt landing zones, implement workload infra, own runtime ops, propose policy changes via RFC.

**Evolving without slowing innovation**- Shift-left policies into developer pipelines; provide local policy-as-code mocks and pre-commit checks.- Canary policies: roll policies as warn-first, collect telemetry and false-positive metrics, then promote to block.- Self-service extensions: allow teams to propose and publish vetted modules to central catalog after review.- Metrics & feedback loop: measure policy failures, time-to-approve exceptions, deployment velocity; review in monthly Governance Board with engineering reps.- Automation-first: automatic remediation for low-risk drift; human review only for high-risk exceptions.

**Trade-offs & governance hygiene**- Trade-off: stricter controls reduce risk but add friction—mitigate with good templates, fast exception SLA, and developer education.- Keep governance as code, versioned, test-covered, and backed by telemetry for continuous improvement.

Cloud Cost Optimization and Financial OperationsMediumTechnical

49 practiced

As a Cloud Architect, write a Python script (using boto3) that scans a list of AWS account IDs (assume role ARN pattern) and identifies EC2 instances, S3 buckets, and RDS instances missing mandatory tags: project, cost-center, environment. The script should output CSV rows: account_id, resource_type, resource_id, missing_tags. Describe how you handle STS AssumeRole for each account and pagination for each API. Provide a production-ready code snippet for scanning EC2 instances.

Sample Answer

**Approach (brief)** - AssumeRole into each target account using STS to obtain short-lived creds. Use those creds to create service clients. - For each resource type call the appropriate list/describe API and handle pagination with Paginators (boto3) or NextTokens. - Inspect tags, build CSV rows for resources missing any of: project, cost-center, environment.

**STS AssumeRole & pagination handling** - Use sts_client.assume_role(RoleArn=arn, RoleSessionName=...) to get temporary creds, then create clients with boto3.Session(aws_access_key_id=..., aws_secret_access_key=..., aws_session_token=...). - Use boto3 Paginators (client.get_paginator('describe_instances') etc.) to iterate all pages reliably and efficiently.

**Production-ready EC2 scanner (snippet)**

python

import boto3
import csv

MANDATORY = {"project", "cost-center", "environment"}

def assume_role(role_arn, session_name="scan-session", external_id=None):
    sts = boto3.client("sts")
    params = {"RoleArn": role_arn, "RoleSessionName": session_name}
    if external_id:
        params["ExternalId"] = external_id
    resp = sts.assume_role(**params)
    creds = resp["Credentials"]
    return boto3.Session(
        aws_access_key_id=creds["AccessKeyId"],
        aws_secret_access_key=creds["SecretAccessKey"],
        aws_session_token=creds["SessionToken"],
    )

def scan_ec2(session, account_id, writer):
    ec2 = session.client("ec2")
    paginator = ec2.get_paginator("describe_instances")
    for page in paginator.paginate():
        for resv in page.get("Reservations", []):
            for inst in resv.get("Instances", []):
                tags = {t["Key"]: t["Value"] for t in inst.get("Tags", [])}
                missing = sorted(MANDATORY - tags.keys())
                if missing:
                    writer.writerow([account_id, "ec2", inst["InstanceId"], ";".join(missing)])

# Example usage: iterate account ids and assume role per account
def main(account_ids, role_name_template="arn:aws:iam::{}:role/OrganizationAccountAccessRole", output="missing_tags.csv"):
    with open(output, "w", newline="") as f:
        writer = csv.writer(f)
        writer.writerow(["account_id","resource_type","resource_id","missing_tags"])
        for acct in account_ids:
            role_arn = role_name_template.format(acct)
            sess = assume_role(role_arn, session_name=f"scan-{acct}")
            scan_ec2(sess, acct, writer)

Explanation, complexity & edge cases - Uses STS per account (O(N) assume calls). Paginators ensure complete results; network-limited. - Handle rate limits with retries/backoff (botocore config) and permissions errors per account (log and continue). - Extend similarly for S3 (list_buckets + get_bucket_tagging; handle 404/no-tagging) and RDS (describe_db_instances + list_tags_for_resource with ARN). - Consider concurrency (ThreadPoolExecutor) with careful rate-limit handling for large fleets.

Collaboration and Communication SkillsEasyTechnical

75 practiced

You are handing off a live cloud environment to an operations team after initial build. List the documentation, runbooks, diagrams, and meetings you would prepare to ensure an effective handoff and describe how you would validate the team's readiness to operate and support the environment.

Sample Answer

**Overview — goal**Ensure the operations team can reliably run, monitor, troubleshoot, and evolve the live cloud environment with minimal escalation.

**Documentation to deliver**- High-level architecture summary: services, regions, VPC/subnet layout, identity model, tenancy, cost center mapping.- Configuration inventory: IaC references (repo, commit hash), AMIs/images, parameters, secrets locations.- Operational policies: backup/retention, scaling, maintenance windows, change control, compliance and tagging standards.- Contact & escalation matrix: owners, SRE on-call rota, vendor/partner support SLAs.

**Runbooks (for immediate use)**- Boot/restore workflow: instance/node replacement, DB failover, restore from backup (step-by-step).- Incident playbooks: high CPU/network/storage, certificate expiry, authentication failures, failed deployments.- Deployment & rollback: deploying via pipeline, feature flags, canary promotion, rollback steps.- Security response: vulnerability detection, patching, key rotation, breach containment.

**Diagrams**- Logical architecture (services, dataflows).- Network diagram (subnets, routing, peering, NACLs, SGs).- Dependency map (3rd-party APIs, internal services).- Observability topology (metrics, logs, traces ingest, retention).

**Meetings & knowledge transfer**- Handoff walkthrough (architecture + live demo) with recording.- Runbook tabletop: simulate 2 common incidents with ops team driving steps.- Weekly Q&A for 2 sprints, plus a retrospective after 30 days.- Access and tooling onboarding: dashboards, runbook repo, CI/CD, ticketing.

**Validating readiness**- Checklist sign-off: access, monitoring alerts, runbook accessibility, recovery RTO/RPO targets.- Practical drills: one successful failover test, one restore-from-backup, one deploy+rollback — observed and scored.- Metrics-based acceptance: alerting false-positive rate < X, mean time to detect (MTTD) and mean time to recover (MTTR) within agreed targets.- Shadowing period: 2 weeks where ops leads run incidents with architect available; follow-up gap remediation plan.

This ensures documented knowledge, practiced procedures, measurable readiness, and a clear support path for long-term operations.

Cloud Migration Strategy and PlanningEasyTechnical

24 practiced

Write a Terraform module (in HCL) that provisions an AWS S3 'migration-bucket' with versioning enabled, server-side encryption using a provided KMS key, a lifecycle rule to transition objects to Infrequent Access after 30 days and to Glacier after 365 days, and public-access-block enabled. Specify input variables (bucket name, kms_key_arn, tags) and outputs. Pseudo-code is acceptable but show resource names, variables, and the lifecycle rules.

Sample Answer

**Approach (brief)**

Below is a concise Terraform module (HCL) that creates an S3 bucket named by input, enables versioning, applies server-side encryption with a provided KMS key, adds lifecycle rules (30d -> IA, 365d -> Glacier) and enforces public access block. Inputs and outputs are declared.

hcl

# variables.tf
variable "bucket_name" {
  type = string
}
variable "kms_key_arn" {
  type = string
}
variable "tags" {
  type = map(string)
  default = {}
}

# main.tf
resource "aws_s3_bucket" "migration" {
  bucket = var.bucket_name
  tags   = merge(var.tags, { "Name" = "migration-bucket" })
}

resource "aws_s3_bucket_versioning" "migration" {
  bucket = aws_s3_bucket.migration.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "migration" {
  bucket = aws_s3_bucket.migration.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = var.kms_key_arn
    }
  }
}

resource "aws_s3_bucket_lifecycle_configuration" "migration" {
  bucket = aws_s3_bucket.migration.id

  rule {
    id     = "transition-to-ia-and-glacier"
    status = "Enabled"

    filter {
      prefix = ""   # applies to all objects; change if needed
    }

    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }

    transition {
      days          = 365
      storage_class = "GLACIER"
    }

    abort_incomplete_multipart_upload {
      days_after_initiation = 7
    }
  }
}

resource "aws_s3_bucket_public_access_block" "migration" {
  bucket = aws_s3_bucket.migration.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# outputs.tf
output "bucket_id" {
  value = aws_s3_bucket.migration.id
}
output "bucket_arn" {
  value = aws_s3_bucket.migration.arn
}
output "bucket_region" {
  value = aws_s3_bucket.migration.region
}

Reasoning and notes:- Use kms_key_arn to enforce KMS-based SSE for compliance and auditability.- Lifecycle: 30 days -> STANDARD_IA reduces cost for infrequently accessed data; 365 days -> GLACIER for long-term archival.- Public access block enforces organization security posture.- Consider adding bucket policy to restrict access to specific roles/accounts and enabling logging/monitoring in production.

Cloud Architecture and Design PatternsHardSystem Design

46 practiced

Design a robust approach to run stateful relational databases (e.g., Postgres) on Kubernetes across multiple availability zones with automatic failover, backups, performance isolation, and acceptable operational complexity. Discuss storage choices (replicated block, distributed filesystem), pod/node affinity, CSI drivers, backup/restore strategy, replication, and the trade-offs vs using managed database services.

Sample Answer

**Clarify requirements**- RPO/RTO targets, expected TPS/IOPS, dataset size, cross‑AZ latency tolerance, maintenance windows, compliance (encryption, retention), ops team skill level.

**High‑level architecture**- Multi‑AZ Kubernetes cluster (control plane HA + worker nodes across AZs) hosting Postgres StatefulSets with Patroni for leader election and automatic failover.- External high‑performance storage via Cloud provider replicated block volumes (e.g., AWS EBS Multi‑AZ or Azure Ultra Disk zone‑redundant) where available; otherwise use networked filesystems only for read replicas.

**Storage choices & CSI**- Preferred: Replicated block storage (PV per pod) for single‑node primary with synchronous or semi‑sync WAL shipping. Use CSI drivers from cloud vendor for volume provisioning, encryption, snapshots, and topology awareness.- Alternative: Distributed filesystem (Ceph/Rook, Longhorn) if you need PV mobility and cross‑AZ mounts — tradeoff increased complexity and potential latency.

**Pod/node affinity & topology**- Use podAntiAffinity to avoid colocating primary and replicas in same AZ/node.- Use volumeBindingMode: WaitForFirstConsumer + topologyKeys to ensure PV provisioned in same AZ as pod.

**Replication & HA**- Patroni + etcd/consul/DCS for cluster state; async replicas in other AZs for reads; quorum kept across AZs for safe failover. Use synchronous replication to an AZ‑local replica for zero data loss when latency allows.

**Backup/Restore**- Regular base backups (pg_basebackup / WAL‑archiving) + continuous WAL shipping to object storage (S3), complemented by automated CSI snapshots for fast restores.- Test restores frequently; stage point‑in‑time recovery (PITR) playbooks and runbooks.

**Performance isolation**- Use CPU/memory requests & limits, Pod QoS, storage class with IOPS guarantees, separate node pools for DB with tuned kernel/CPU settings, and dedicated network paths.

**Operational complexity vs managed services**- Self‑managed on K8s gives flexibility, control over tuning/compliance, and potential cost savings for large scale, but increases operational burden: upgrades, backups, failover testing, tuning, and operator expertise.- Managed DB (RDS/Azure Database) reduces operational risk, offers automated backups, cross‑AZ replicas, and SLA but less control and higher cost.

I would recommend self‑managed Kubernetes Postgres only when business needs require custom tuning, extensions, or data locality; otherwise prefer managed DB for lower operational overhead.

Amazon Web Services Core ServicesMediumTechnical

75 practiced

Explain AWS Lambda's concurrency model and the causes of cold starts. Describe reserved concurrency, provisioned concurrency, and account concurrency limits. Offer concrete mitigation strategies to reduce cold-start latency for Java and Node.js runtimes and discuss the cost and operational trade-offs.

Sample Answer

**Concurrency model & cold-start causes**

AWS Lambda scales by creating concurrent execution environments (one environment per concurrent invocation). Cold starts occur when Lambda must initialize a new execution environment: container creation, runtime startup, JIT/AOT class loading, dependency initialization, and any client/SDK/network warmups. Language runtime, package size, init code, and VPC ENI attachment are common causes.

**Limits and features**

- Account concurrency limit: regional cap (default 1,000) shared across functions. - Reserved concurrency: caps or guarantees concurrency for a specific function (sets a max and isolates from others). - Provisioned concurrency: pre-creates and initializes execution environments to eliminate cold starts for configured capacity.

**Mitigation strategies (Java & Node.js)**

- Java: - Use GraalVM native-image (AOT) to reduce JVM startup. - Reduce cold-path classloading; move heavy work out of handler init. - Use smaller runtimes (Amazon Corretto 11+), tune heap, enable tiered compilation off for short-lived lambdas. - Provisioned concurrency for critical latency-sensitive functions.- Node.js: - Keep handler code minimal; lazy-load nonessential modules. - Bundle dependencies, tree-shake, and reduce package size. - Reuse connections (DB, HTTP) in global scope. - Use provisioned concurrency or scheduled warmers for sporadic traffic.

**Trade-offs**

- Provisioned concurrency: predictable low latency but higher cost (billed for configured capacity while provisioned) and operational overhead to autoscale with traffic patterns.- Reserved concurrency: protects critical functions from noisy neighbors but reduces available pool for others.- Warming strategies (scheduled invocations): cheaper but brittle, not perfect for scale and may waste invocations.- Runtime changes (GraalVM): complexity, compatibility testing, build pipeline changes.

As a Cloud Architect I'd recommend combining capacity planning (reserved/provisioned where SLAs demand), runtime tuning, and observability (init latency metrics) to balance cost and latency.

Security and Compliance ArchitectureEasyTechnical

49 practiced

As a Cloud Architect, explain what a data classification scheme is and how you would design a classification taxonomy for an enterprise cloud environment. Describe categories, handling rules, ownership, automated enforcement (tagging, labels) and how classification maps to technical controls and monitoring.

OwnershipMediumTechnical

40 practiced

You are accountable for cloud cost optimization across business units. Describe how you would structure ownership of cloud cost, implement chargeback or showback mechanisms, set budgets and alerts, and create incentives or guardrails so teams reduce waste while preserving delivery velocity.

Sample Answer

**Ownership model**- I’d establish a central FinOps team (reporting to Cloud Architect/Finance) responsible for governance, tooling, reporting, and policy. - Each business unit has a Cost Owner (engineering manager/tech lead) accountable for their cost KPIs and tagging accuracy. - A Cloud Platform team provides self-service capabilities, automated optimizations, and guardrails.

**Chargeback vs Showback**- Start with showback for 3–6 months to build awareness and trust. Transition to chargeback for discretionary spend (dev/test, analytics) while keeping shared infra on central budget. - Use unit-level billing exports + tags to generate monthly reports.

**Budgets & Alerts**- Set monthly budgets per BU from forecasts; enforce via cloud-native budgets (AWS Budgets/GCP Alerts/Azure Cost Alerts) with staged notifications: owner → manager → FinOps. - Auto actions for threshold breaches: suspend non-critical dev accounts or disable new resource creation.

**Incentives & Guardrails**- Incentives: quarterly cost-efficiency bonus tied to validated savings and service-level delivery (not just cuts). Public leaderboard and “cost improvement” awards. - Guardrails: mandatory tagging, approved instance types, policies for RI/Savings Plans, mandatory autoscaling and scheduled off-hours for non-prod. Implement policy-as-code (AWS Config/Policy Library) to prevent risky launches.

**Preserve velocity**- Provide curated catalogs (approved AMIs, machine types), self-serve reservation UI, and automation (rightsizing recommendations, autoscaler templates). Integrate cost checks into CI/CD pipelines to block expensive configurations while allowing overrides with justification.

**Metrics I track**- Cost per business transaction, untagged spend %, idle/underutilized % CPU/DB, forecast variance, and savings realized from optimizations.

Example: I led a program that used showback for 4 months, rolled out tagging enforcement via Terraform policies, introduced scheduled shutdown for 60% of dev VMs and achieved 28% monthly savings without slowing feature delivery.

Practice Cloud Architect questions across all topics

Want to create your own tailored preparation guide using our deep research?

Get Started for Free

Interview-Ready Courses

Visual-first, interactive, structured learning paths

Browse Cloud Architect jobs

AI-enriched listings across hundreds of company career pages

Explore Jobs

Amazon Cloud Architect (Entry Level) - Comprehensive Interview Preparation Guide

Interview Process Overview

Interview Rounds

Recruiter Screening

What to Expect

Tips & Advice

Focus Topics

Understanding of Cloud Architecture Role

Practice Interview

Study Questions

Career Motivation and Role Fit

Practice Interview

Study Questions

Relevant Background and Experience

Practice Interview

Study Questions

Technical Phone Screen 1: AWS Fundamentals

What to Expect

Tips & Advice

Focus Topics

Infrastructure as Code Concepts

Practice Interview

Study Questions

Basic Architecture Patterns and Design Decisions

Practice Interview

Study Questions

AWS Well-Architected Framework Pillars

Practice Interview

Study Questions

AWS Core Services Knowledge

Practice Interview

Study Questions

Technical Phone Screen 2: Practical Architecture Scenarios

What to Expect

Tips & Advice

Focus Topics

Security and Compliance Considerations in Architecture

Practice Interview

Study Questions

Cost Optimization and Resource Efficiency

Practice Interview

Study Questions

Problem-Solving and Communication Skills

Practice Interview

Study Questions

Cloud Migration Strategy Basics

Practice Interview

Study Questions

Designing Highly Available and Scalable Web Applications

Practice Interview

Study Questions

Onsite Interview 1: Behavioral and Culture Fit

What to Expect

Tips & Advice

Focus Topics

Handling Failure and Problem-Solving

Practice Interview

Study Questions

Collaboration and Communication in Technical Teams

Practice Interview

Study Questions

Amazon Leadership Principle: Learning and Growth

Practice Interview

Study Questions

Amazon Leadership Principle: Ownership

Practice Interview

Study Questions

Amazon Leadership Principle: Customer Obsession

Practice Interview

Study Questions

Onsite Interview 2: Technical Depth - AWS Architecture

What to Expect

Tips & Advice

Focus Topics

AWS Lambda and Serverless Architecture Patterns

Practice Interview

Study Questions

Performance, Reliability, and Scalability Design

Practice Interview

Study Questions