AWS Well-Architected Framework Principles Questions

Principles and guidelines from the AWS Well-Architected Framework for designing, building, and operating robust, secure, efficient, and cost-optimized systems on AWS. Covers the five pillars—Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization—and related architecture decisions, patterns, and best practices.

MediumTechnical

66 practiced

A high-throughput real-time analytics pipeline using Kinesis is experiencing intermittent throttling when traffic spikes. Describe how you'd investigate and remediate this to improve Performance Efficiency and Reliability. Include short-term and longer-term fixes.

Sample Answer

Start with targeted investigation, then apply immediate mitigations and longer-term architectural fixes.

Investigation- Collect metrics from CloudWatch: IncomingRecords/Bytes, PutRecord/PutRecords throttles, WriteProvisionedThroughputExceeded, ReadProvisionedThroughputExceeded, GetRecords.IteratorAgeMilliseconds, NumberOfShards. Correlate throttles with traffic spike times.- Inspect client-side errors/logs for ProvisionedThroughputExceededException and retry patterns.- Examine partition key distribution to detect hot shards and look at per-shard IncomingRecords/Bytes.- Check consumer lag (iterator age) and consumer error/retry behavior that could exacerbate pressure.

Short-term (fast remediation)- Add shards (rescale) to increase write throughput temporarily—use on-demand or increase shard count via split/merge to handle immediate load.- Implement (or tune) client-side exponential backoff and jitter for PutRecords retries to reduce retry storms.- Throttle producers at the edge: impose rate limiting or buffer writes in an intermediate queue (SQS, DynamoDB, or local buffer) to smooth bursts.- Use Kinesis Enhanced Fan-Out for consumers if read-side throttling is observed to decouple consumers from shard read limits.- Turn on faster monitoring/alarms for throttling metrics and create automated scaling actions where possible.

Longer-term (robust architecture)- Fix partition key strategy: move from hot keys to more even hashing (add salt, use composite keys) or aggregate small events client-side before send.- Consider batching with PutRecords to improve write efficiency.- Adopt Kinesis Data Streams on-demand mode (if unpredictable spikes) or autoscaling policies tied to CloudWatch metrics.- Evaluate moving very high-throughput workloads to alternative platforms (MSK/Kafka, DynamoDB streams, or Kinesis Data Firehose) depending on retention, ordering, and latency needs.- Improve consumer design: use KCL with multi-threaded processors, checkpointing, and autoscaling consumers (ECS/EKS/Lambda with reserved concurrency tuned).- Implement end-to-end backpressure and SLAs: propagate capacity information to producers, design graceful degradation for non-critical events.

Trade-offs and reasoning- Resharding and enhanced fan-out increase cost but restore reliability quickly. Balancing cost vs. latency guides on-demand vs. fixed shards.- Changing partition keys or adding intermediary buffers reduces risk of hot shards at design level and prevents repeated manual scaling.

Expected outcomes- Short-term: drop throttling incidents within minutes/hours, reduced errors, smoother ingestion.- Long-term: predictable capacity, fewer manual interventions, improved performance efficiency and reliability.

MediumSystem Design

83 practiced

Design an approach to secure cross-account access for a partner who needs to read specific S3 prefixes in several customer accounts without giving broad IAM permissions. Include use of IAM roles, resource policies, and how you'd audit access.

Sample Answer

Requirements & constraints:- Partner (external AWS account) needs read-only access to specific S3 prefixes across multiple customer accounts- No broad IAM permissions, least-privilege, auditable- Scalable (many customers), easy onboarding/offboarding- Prevent privilege escalation and lateral access

High-level approach:1. Use cross-account IAM Roles in each customer account that the partner assumes (role-per-customer).2. Use S3 bucket/resource policies (or S3 Access Points) to restrict access to only the allowed prefixes and only when assumed by the designated role.3. Enforce additional protections: ExternalId for anti-confused-delegation, MFA required for assume-role if needed, deny rules for other principals.4. Centralized auditing via CloudTrail + S3 access logs + CloudWatch Logs/Athena for queries and alerts.

Design details

A. IAM Role (customer account)- Create a role in each customer account with a trust policy that allows the partner's AWS account (or specific ARN) to assume it and requires an ExternalId.- Attach a least-privilege inline policy granting only s3:ListBucket (with Prefix condition) and s3:GetObject on the allowed prefix ARNs.

Example trust policy (customer account):

json

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::PARTNER_ACCOUNT_ID:root" },
    "Action": "sts:AssumeRole",
    "Condition": { "StringEquals": { "sts:ExternalId": "unique-external-id-per-customer" } }
  }]
}

Example role permissions (inline):

json

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Effect":"Allow",
      "Action":["s3:ListBucket"],
      "Resource":["arn:aws:s3:::customer-bucket"],
      "Condition":{ "StringLike":{ "s3:prefix":["allowed/prefix/*"] } }
    },
    {
      "Effect":"Allow",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::customer-bucket/allowed/prefix/*"]
    }
  ]
}

B. S3 Bucket/Access Point policy (defense-in-depth)- Put a bucket policy that only allows GetObject/ListBucket when the request is from that role ARN (or account + external principal) and limits object key prefix.- This prevents other principals in partner account from using broader permissions.

Example bucket policy snippet:

json

{
  "Version":"2012-10-17",
  "Statement":[{
    "Effect":"Allow",
    "Principal": { "AWS": "arn:aws:iam::CUSTOMER_ACCOUNT_ID:role/PartnerReadRole" },
    "Action":["s3:GetObject","s3:ListBucket"],
    "Resource":["arn:aws:s3:::customer-bucket","arn:aws:s3:::customer-bucket/allowed/prefix/*"],
    "Condition": { "StringLike": { "s3:prefix": ["allowed/prefix/*"] } }
  }]
}

C. Onboarding and Scale- Automate role and policy creation via IaC (CloudFormation/Terraform) or an onboarding API that generates per-customer ExternalId and role name.- Use S3 Access Points for complex multi-prefix or multi-tenant rules; Access Points can simplify network controls (VPC restrictions).

D. Auditing & Monitoring- Enable CloudTrail in each customer account with management and data events for S3 (read-object events).- Deliver CloudTrail logs to a centralized logging account/S3 bucket (immutable) and enable S3 server access logs for the customer buckets as secondary source.- Use AWS Athena / AWS Glue to run queries on CloudTrail logs (who assumed role, which object keys accessed, timestamps).- Create CloudWatch metric filters/Alarms for anomalous behavior: access outside allowed times, large data downloads, requests to other prefixes, failed assume-role attempts.- Periodic reports: daily summary of role assumes, top objects read, byte volumes per partner. Keep retention for compliance.

E. Security controls & hardening- Require ExternalId and rotate it if compromise suspected.- Restrict assume-role to partner account or to an explicit role ARN so partner can’t create different principals.- Use session tags and require tag-based conditions on S3 bucket policy if needed (e.g., enforce customer-id tag on session).- Limit session duration on the IAM role (e.g., 1 hour).- Use least-privilege policies and deny statements to prevent s3:* or access to other buckets.- Optionally use AWS Resource Access Manager / AWS Organizations if partner is within an org (rare).

Trade-offs:- Per-customer roles scale operationally but are more secure because ExternalIds and per-customer mapping prevent cross-customer access by the partner. Automate to reduce overhead.- Relying only on role policies or only bucket policies is weaker; combining both provides defense-in-depth.- Extra logging increases cost and storage; tune retention and use tiered storage and aggregated queries.

This design gives the partner the minimal read access they need, enforces prefix-level restrictions via both IAM and resource policies, secures cross-account access with ExternalId and short sessions, and provides centralized, queryable audit trails for compliance and detection.

MediumTechnical

58 practiced

A customer needs to ensure cost transparency across multiple teams. Suggest an approach using tag-based cost allocation, Cost Explorer, budgets, and organizational-level reporting. How would you enforce tagging discipline and handle untagged resources?

Sample Answer

Requirements & constraints:- Provide team-level cost visibility across an organization, enforce consistent tags, produce org-level reports, and control costs.

Approach (high-level):1. Tagging taxonomy & rules- Define mandatory cost-allocation tags (e.g., CostCenter, Team, Project, Environment, Owner) with allowed values and patterns.- Publish a tag dictionary mapping teams to allowed values and examples.

2. Instrumentation: Cost Explorer & Budgets- Enable Cost Explorer at the org level; activate “Cost Allocation Tags” so the chosen tags appear in reports.- Create Cost Explorer reports (by Team/CostCenter/Environment) and schedule exports to S3 for dashboards.- Create budgets per Team and per Project using those tags; enable alerts via SNS/email/Slack and automated remediation runbooks.

3. Organization-level reporting- Aggregate billing via consolidated billing or AWS Organizations (or equivalent). Build a central reporting pipeline: export CUR (Cost and Usage Report) to S3, ETL into a data warehouse, and expose dashboards (QuickSight/Looker/Tableau) filtered by tag dimensions.

Enforcement & governance:- Preventative controls: - Enforce tag requirements in infrastructure-as-code templates (CloudFormation/Terraform modules) and CI/CD pipelines; include automated validators. - Implement Service Control Policies (SCPs) or IAM policies that deny resource creation unless required tags are present (where cloud supports tag-on-create enforcement). - Use Tag Policies (AWS Organizations) to enforce allowed keys/values.- Detective/automated remediation: - Lambda/Cloud Functions triggered on resource creation (EventBridge) to check tags; if missing, try to auto-tag using owner directory or creation metadata, otherwise add a “quarantine” tag and notify owner. - Daily job scanning CUR for untagged costs and attributing them to a fallback cost center (e.g., “Unallocated”) for reporting and charging. - Integrate with ticketing: auto-create tickets for owners to fix missing tags; escalate if budgets are hit.

Handling untagged resources:- Short-term: use Cost Categories and dimension fallbacks in Cost Explorer to group untagged spend into “Unallocated” so teams see exposures.- Medium-term: run automated remediation to tag resources where safe; if tagging impossible (some resources immutable), document and include in chargebacks with owner identification via account/creator metadata.- Long-term: enforce zero-tolerance via SCPs/CI gates and tie budget/approval workflows to tag compliance before provisioning.

Example flow:- Developer requests infra via Terraform module that requires Team and Project variables. CI linter validates tags; PR merges deploys resources. EventBridge rule triggers a tagging-check Lambda that logs success. Cost Explorer report shows spend by Team tag; when Team budget >80%, SNS alerts team lead and triggers autoscaling/stop policies for non-prod resources.

Trade-offs:- Deny-on-create is strict and reduces untagged spend but can impede developer speed — mitigate with self-service tag templates.- Automated tagging may misattribute costs if heuristics fail; maintain audit trail and owner confirmation.

Metrics to track:- % resources tagged (key tags) daily- % spend categorized vs unallocated- Number of budget breaches and mean time to remediation- Time-to-tag for new resources

This combination of preventative policy, CI/CD controls, automated remediation, and org-level reporting provides transparent, enforceable cost allocation and a pragmatic path to eliminate untagged spend.

MediumSystem Design

65 practiced

A customer uses multiple SaaS and AWS services and wants centralized security visibility. Propose a hub-and-spoke architecture for centralized logging and security detection using AWS Security Hub, GuardDuty, CloudTrail aggregation, and an S3 centralized logging bucket. Include cross-account aggregation mechanism.

Sample Answer

Requirements:- Centralize logs from multiple AWS accounts and SaaS (application, CI/CD, third-party) for security detection and compliance.- Use AWS Security Hub, GuardDuty, CloudTrail aggregation, and a central S3 logging bucket.- Cross-account aggregation, least privilege, tamper-evidence, low-latency detections.

High-level architecture (hub-and-spoke):- Hub account (security): Security account owns Security Hub, central S3 logging bucket (encrypted), central CloudWatch Logs/Logs Insights, and the master GuardDuty.- Spoke accounts (workloads): Enable CloudTrail, CloudWatch, GuardDuty sensors, and send logs/Findings to the hub.

ASCII:Spoke A/B/C --> (CloudTrail S3 + CloudWatch Logs/Firehose) --> Hub S3 (central-logs) --> Security Hub / SIEMGuardDuty (member) in spokes -> Aggregated to GuardDuty master in HubSecurity Hub in Hub aggregates findings from GuardDuty, Inspector, and 3rd-party integrations.

Core components & cross-account mechanics:- CloudTrail: Each spoke has an organization trail or account-specific trail delivering to the central S3 bucket in hub via a bucket policy allowing PutObject from spoke account principals. Use object locking + SSE-KMS (CMK in hub) to prevent tampering.- CloudWatch Logs / Kinesis Data Firehose: For high-volume logs, Firehose in spoke uses role with PutRecord to Firehose in hub or directly to central S3; use cross-account IAM role with strict trust policy.- GuardDuty: Enable GuardDuty organization feature to designate hub as the GuardDuty delegated administrator; member accounts are auto-invited and findings pushed to hub.- Security Hub: Enable Security Hub in the management (hub) account and enable Security Hub organization integration; member accounts send standardized findings to hub. Integrate 3rd-party SaaS via Security Hub partner connectors or via CloudWatch Events/EventBridge custom bus.- Findings normalization: Use Security Hub’s standard findings and use EventBridge rules to route to central SIEM, ticketing, or Lambda for enrichment.

Data flow:- Audit logs from CloudTrail + VPC Flow Logs + App logs -> Firehose/CloudWatch -> Central S3 and CloudWatch Logs in hub.- GuardDuty findings created in member accounts appear in hub GuardDuty and Security Hub aggregated view.- Security Hub aggregates findings (GuardDuty, Inspector, SaaS) and presents unified dashboard; automated response via EventBridge -> Lambda/Systems Manager Automation.

Security, compliance & controls:- S3 bucket: enforce MFA Delete, object lock retention, SSE-KMS with CMK keys in hub; key policies disallow deletion by spokes.- IAM: use cross-account IAM roles with least privilege and assume-role patterns. Monitor role usage via CloudTrail.- Networking: use VPC endpoints for S3 and Kinesis to avoid public egress.- Logging integrity: enable CloudTrail Insights, CloudTrail log file validation.- Data residency: lifecycle rules, encryption in transit (TLS).

Scalability & operations:- Partition logs by account/year/month/prefix for performance; use lifecycle to move to Glacier.- Use Athena + Glue for ad-hoc queries; use Lake Formation if fine-grained access needed.- Automate onboarding via AWS Organizations SCPs and CloudFormation StackSets or Control Tower to deploy roles, trails, and member enrollment.- Cost controls: compress logs, filter non-essential logs at source, use aggregated metrics and Alerts.

Trade-offs:- Central S3 simplifies retention and analytics but increases cross-account IAM complexity.- Using organization-level trails (AWS Organizations) reduces duplication but requires Organizations structure and IAM governance.- Pushing all logs increases cost and ingest latency; selective forwarding with Firehose transforms can reduce noise.

Why this fits:- Uses native AWS aggregation features (GuardDuty/ Security Hub orgs) for low-friction centralized detection, provides tamper-evidence and KMS-based control, and supports SaaS integrations and automation for response—aligned with enterprise security and compliance needs.

HardTechnical

77 practiced

Write a short Terraform plan (outline, pseudocode or HCL) to implement a cross-region read-replica for an RDS PostgreSQL instance and automate snapshot copy for backups. Briefly describe failover steps and considerations for preserving data integrity.

Sample Answer

Approach: create a primary RDS Postgres in region A, a cross-region read-replica in region B (using a provider alias), and automate copying daily snapshots from region A to region B via a small Lambda triggered by EventBridge. Include KMS re-encryption and IAM. Outline in Terraform HCL (pseudocode), then failover steps and integrity considerations.

Terraform outline (pseudocode/HCL):provider "aws" { region = "us-east-1" }provider "aws" { alias = "replica" region = "us-west-2" }

resource "aws_db_instance" "primary" { identifier = "pg-primary" engine = "postgres" engine_version = "15" instance_class = "db.t4g.medium" allocated_storage = 100 skip_final_snapshot = false backup_retention_period = 7 storage_encrypted = true kms_key_id = aws_kms_key.primary.arn parameter_group_name = aws_db_parameter_group.pg.name # enable automated backups and appropriate WAL settings}

resource "aws_db_instance" "read_replica" { provider = aws.replica identifier = "pg-replica" replicate_source_db = aws_db_instance.primary.arn instance_class = "db.t4g.medium" publicly_accessible = false storage_encrypted = true kms_key_id = aws_kms_key.replica.arn # read-only replica config}

# KMS keys in both regions for encryption & snapshot copyresource "aws_kms_key" "primary" { }resource "aws_kms_key" "replica" { provider = aws.replica }

# Lambda to copy latest snapshot to replica region (Python pseudocode)resource "aws_iam_role" "lambda_role" { /* permissions: rds:DescribeDBSnapshots, rds:CopyDBSnapshot, kms:GenerateDataKey, kms:Decrypt */ }

resource "aws_lambda_function" "copy_snapshot" { filename = "copy_snapshot.zip" handler = "handler.lambda_handler" runtime = "python3.11" role = aws_iam_role.lambda_role.arn environment = { SOURCE_REGION = "us-east-1" TARGET_REGION = "us-west-2" TARGET_KMS_KEY = aws_kms_key.replica.arn DB_IDENTIFIER = aws_db_instance.primary.identifier }}

resource "aws_cloudwatch_event_rule" "daily_snapshot_copy" { schedule_expression = "cron(0 2 * * ? *)" # daily at 02:00 UTC}resource "aws_cloudwatch_event_target" "target_copy" { rule = aws_cloudwatch_event_rule.daily_snapshot_copy.name, arn = aws_lambda_function.copy_snapshot.arn }

Lambda logic (summary, included in zip):- DescribeDBSnapshots for SOURCE_REGION filtered by DB_IDENTIFIER and most recent automated snapshot- Call rds:CopyDBSnapshot with SourceRegion, SourceDBSnapshotIdentifier, TargetRegion, TargetDBSnapshotIdentifier, KmsKeyId (target)- Re-encrypt if necessary and tag copy for retention

Failover steps (operational playbook):1. Verify replica replication lag is minimal: describe-replication for replica; ensure last_wal_receive and replay are current.2. Promote read-replica to standalone: aws rds promote-read-replica --db-instance-identifier pg-replica (in target region).3. Run integrity checks: run pg_isready, run consistency queries, validate critical transactions.4. Update DNS / application config to point to promoted instance (use Route53 failover alias with low TTL or weighted/health-checked record).5. If necessary, restore latest cross-region snapshot to new instance for point-in-time: use copied snapshot or automated PITR.6. Reconfigure backups, monitoring, and re-create replica(s).

Data integrity & operational considerations:- Replication lag: monitor CloudWatch ReplicaLag and set alert thresholds. Avoid promoting if lag > acceptable window.- WAL settings: ensure rds.wal_level supports replication (usually "replica"), and max_wal_senders, wal_keep_size tuned.- Backups & consistency: automated snapshot copy uses storage snapshots; ensure snapshot is recent and consistent. For point-in-time recovery, enable continuous backups (automated backups + sufficient retention).- Encryption/KMS: snapshot copies across regions require a KMS key in target region; Lambda must have decrypt/generate permissions and you must re-encrypt the snapshot with target KMS.- IAM least privilege for Lambda and RDS actions.- Test failover regularly (DR drills) and document RTO/RPO targets.- DNS TTL and application connection handling: prepare apps for transient failover and DB credentials/replica read-only flags.- Consider Multi-AZ for primary to handle AZ failures; cross-region replica is for region-level DR.

This design balances automated backup transfer, cross-region read capacity, and an operationally-safe promotion path while preserving encryption and data integrity.

Unlock Full Question Bank

Get access to hundreds of AWS Well-Architected Framework Principles interview questions and detailed answers.

Join thousands of developers preparing for their dream job.