Comprehensive knowledge of the foundational Amazon Web Services that are commonly used to design, deploy, and operate cloud applications. This includes compute services such as Amazon Elastic Compute Cloud for virtual machines and instance families, Amazon Web Services Lambda for serverless functions, and Amazon Elastic Beanstalk for managed application platforms; storage services such as Amazon Simple Storage Service for object storage, Amazon Elastic Block Store for block volumes, and Amazon Elastic File System for shared file storage; database services such as Amazon Relational Database Service for managed relational databases, Amazon DynamoDB for NoSQL, and Amazon ElastiCache for in memory caching; networking and content delivery including Amazon Virtual Private Cloud networking concepts, subnets, security groups, load balancers, and Amazon CloudFront; container and orchestration options such as Amazon Elastic Container Service and Amazon Elastic Kubernetes Service; and management and security services including Identity and Access Management, Amazon CloudWatch monitoring and logging, Auto Scaling, and cost and service limit considerations. Candidates should understand core service characteristics, common configuration choices and trade offs, operational considerations such as high availability and fault tolerance, basic security and compliance approaches, performance and cost optimization, and guidance for selecting one service over another for typical application patterns.
MediumTechnical
54 practiced
You design a CI/CD pipeline that builds, scans, and deploys application artifacts to AWS. Describe how to handle secrets used in the pipeline, how to grant ephemeral credentials to build agents (including third-party runners), how to scan for secrets and vulnerabilities, and how to prevent code or build steps from exfiltrating production secrets during builds.
Sample Answer
**Situation overview (short)** Design a secure CI/CD pipeline on AWS that protects secrets, issues ephemeral creds to builders (including 3rd‑party runners), scans for secrets/vulns, and prevents exfiltration.**Secrets storage & access**- Store secrets in AWS Secrets Manager or Parameter Store (SecureString) encrypted with a dedicated KMS CMK.- Avoid embedding secrets in code/artifacts. Deliver values at runtime only.- Use resource-based policies and fine‑grained IAM policies (least privilege) scoped to specific secret ARNs.- Enable automatic rotation where supported and audit via CloudTrail.**Ephemeral credentials for agents**- Use OIDC federation: configure GitHub Actions / GitLab / third‑party to mint tokens and call STS:AssumeRoleWithWebIdentity to get short‑lived creds (minutes to hours).- Create specific IAM roles per pipeline/job with restrictive session policies and conditions (source repo, branch, subaudience). Example: allow sts:AssumeRoleWithWebIdentity only for token audience matching repo and workflow.- For self‑hosted runners, require mutual TLS / hardware-backed keys or run in ephemeral sandboxed VMs that fetch creds via instance role with IMDSv2 and metadata protections.**Secret and vulnerability scanning**- Prevent secrets entering repo: run pre‑commit hooks (git-secrets), enforce server-side checks in PR pipelines.- At pipeline runtime, run secret scanners (truffleHog, detect-secrets) and SCA/image scanners (Trivy, Clair, Amazon ECR image scanning, Snyk). Fail builds on high/critical findings.- Generate SBOM (CycloneDX/SPDX) and run dependency vulnerability checks; store results in centralized dashboard and ticketing.**Preventing exfiltration**- Do not provide production secrets to untrusted runs. Use environment-specific roles: dev/test roles separate from prod; require manual approval or multi‑party attestation for prod deploys.- Enforce network egress controls during builds: run builds in private subnets without Internet egress or only through approved proxy with logging (VPC endpoints, VPC NAT + proxy).- Enforce IAM session policies that deny actions like kms:Decrypt for prod secrets unless coming from trusted conditions (source IP, workflow, MFA).- Use allowlists for destination endpoints and DNS filtering; block upload to public cloud storage or external APIs by default.- Add runtime attestations and provenance: sign artifacts with cosign/Sigstore and verify before deploy; require signed SBOMs.- Monitor and alert: CloudTrail, GuardDuty, VPC Flow Logs, and ECR/Image scan alerts; integrate into CI to revoke sessions on suspicious activity.**Example control set**- OIDC trust for GitHub Actions -> Role: CI/CD-Runner-Role -> Session policy limits to specific repo/branch and KMS decrypt only for dev secrets.- Build hosts in ephemeral EKS pods with no outbound internet; allow ECR/ECR auth via VPC endpoint.- Pre‑merge secret scan + pipeline secret scan (truffleHog) + image scan (Trivy); artifact signed with cosign; deployment requires verification.This approach layers protection: secure storage, ephemeral least‑privilege creds, proactive scanning, network and policy controls, and provenance to reduce risk of secrets exfiltration.
HardSystem Design
69 practiced
Design a multi-account, multi-region secure architecture for a global application that must remain available during a region outage and meet strict compliance requirements such as separate key custody and audit trails. Cover VPC/account design, cross-region replication for S3/DynamoDB/RDS, KMS key management patterns (regional vs multi-region), Route53 failover or latency routing, and controls to prevent accidental cross-region data leakage.
Sample Answer
**Situation & goals (brief)** Design a secure multi-account, multi-region AWS architecture that remains available during region failure and satisfies strict compliance: separate key custody, immutable audit trails, no accidental cross‑region data leakage.**Account & VPC design** - Landing account: Identity (AWS SSO/IdP), org-level SCPs. - Security account: centralized CloudTrail (multi-region), AWS Config aggregator, SIEM ingestion, KMS root key custodianship. - Prod app accounts per region and per environment (prod-us-east-1, prod-eu-west-1). Each account owns its VPCs (private subnets, NGFW/Transit GW). Use Transit Gateway with VPC attachments per region; isolate cross-account VPC peering to minimum. **Replication & data services** - S3: Cross-region replication (CRR) with object lock enabled for compliance; use replication role scoped to source/destination account, and replication time control SLA. - DynamoDB: Global Tables (multi-master) for low-latency reads; encryption at rest with customer-managed keys per region/account. - RDS: Use cross-region read replicas for failover; synchronous within AZs only—promote replica in secondary region in DR runbook. Use snapshots copied to destination account bucket with encryption.**KMS key management** - Use regional CMKs per account to satisfy separate custody. For required cross-region decrypt, create multi-Region keys only when approved; cross-account access via grants/roles. Avoid automatic use of multi-region KMS unless legal permits; record key creation and grants in audit.**DNS & traffic failover** - Route53: Use latency-based routing + health checks with failover records. For strict RTO, combine latency routing with active-passive failover—primary region weight high; on health failure, failover to secondary region endpoints in separate accounts. Use signed responses (DNSSEC) where required.**Controls to prevent data leakage** - SCPs deny cross-region S3/DynamoDB writes unless exempted. - IAM Restricted roles for cross-account access; require MFA and Just-In-Time access via AWS SSO & permission ticketing. - VPC endpoints only; disallow internet egress from private subnets except via centralized egress with inspection (NGFW). - Automated config rules: detect cross-region resource creation, public buckets, and KMS grant changes. - Immutable CloudTrail in Security account with S3 replication to a separate cold-storage account and KMS keys held by Compliance team. Use Write-Once-Read-Many (WORM) where required.**Audit, monitoring & runbooks** - Central SIEM/SOC pulls CloudTrail, VPC Flow Logs, GuardDuty, Config. Maintain signed audit trails and quarterly key custody reviews. Document failover playbooks with automated scripts (runbooks in SSM) and test DR annually.**Trade-offs** - Multi-region data consistency vs compliance: prefer per-region keys and controlled replication to meet custody needs; increases operational complexity but meets strict compliance.
MediumSystem Design
102 practiced
Design a centralized logging and monitoring solution for a multi-account AWS environment that ingests CloudTrail, VPC Flow Logs, ELB logs, and application logs into a central account. Include secure log transport (cross-account roles or delivery), storage, indexing/search options (OpenSearch/3rd party), alerting architecture, retention, and analyst access controls.
Sample Answer
**Overview / Goals**Design a secure, central logging plane in a dedicated Security account that reliably ingests CloudTrail, VPC Flow Logs, ELB logs and application logs from multiple AWS accounts, provides indexed search, alerting, controlled analyst access, and enforces encryption/retention.**Ingest & Secure Transport**- Create an S3 logging bucket in Central account per log type (cloudtrail/, vpcflow/, elb/, app/). Enable bucket encryption with a KMS CMK in the Central account.- Use cross-account delivery: - CloudTrail: configure trails in each account with S3 destination set to central bucket using an IAM role the central account trusts (CloudTrail uses the PutObject ACL + kms:Encrypt via role). - VPC Flow / ELB: use CloudWatch Logs subscription filters → Kinesis Data Firehose in source account with cross-account role that writes to central S3 (or Firehose direct to OpenSearch). - Application logs: ship via Fluentd/Fluent Bit to Kinesis Firehose or Amazon MSK, with IAM role allowing PutRecords to central ingestion.- Enforce secure network path: use VPC endpoints (Gateway endpoint for S3, PrivateLink for Firehose/Opensearch) and restrict public access.**Storage & Retention**- Store raw logs in S3 with partitioning by account/date/type. Enable S3 Object Lock governance for critical logs if needed.- Lifecycle rules: hot (30d), infrequent (30–365d), Glacier archive beyond retention policy per compliance; separate retention by log type.- Enable S3 access logging and validate via AWS Config rules.**Indexing / Search**- Option A: Amazon OpenSearch Service in Central account (dedicated domain per environment, encryption at rest with CMK, node-to-node TLS, fine-grained access). - Firehose can deliver to OpenSearch for near real-time indexing.- Option B: 3rd-party SIEM (Splunk/QRadar) receiving from Firehose or CloudWatch Log Subscriptions — better analytics / threat detection at scale.- Maintain raw S3 as source-of-truth and use lifecycle for indices.**Alerting & Detection**- Stream important indexed events to a Detection Engine (Lambda or SIEM rules).- Use OpenSearch Watcher or SIEM correlation to trigger alerts → SNS topics → PagerDuty, Slack, Email. For automated containment, trigger Lambda runbooks (isolate instance, revoke keys).- Implement event-driven analytics: Athena queries on S3 + scheduled queries to detect anomalies.**Access Controls & Audit**- Centralize IAM in Security account: create roles for analysts with least privilege using IAM policies and OpenSearch fine-grained roles. Use SAML SSO and attribute-based access (RBAC: read-only vs investigative).- Cross-account read-only roles: assume-role into Central account for temporary credentials; require MFA and session tags for just-in-time auditing.- Encrypt with KMS keys and restrict decrypt to specified roles; use key grants for cross-account write only.- Logging access: require CloudTrail for Central account, enable OpenSearch audit logs to S3.**Monitoring & Reliability**- Monitor ingestion metrics (Firehose/Opensearch) with CloudWatch and set alerts for delivery failures.- Use lifecycle and backups: snapshot OpenSearch regularly to S3.- Design for scale: shard appropriately, use auto-scaling for OpenSearch or use managed SIEM.**Trade-offs & Rationale**- S3-first preserves immutable raw data for forensic needs and cost-efficiency.- Firehose → OpenSearch minimizes custom code; third-party SIEM adds advanced detection but costs more.- Cross-account roles + KMS centralize control and reduce attack surface; VPC endpoints prevent exfil over public internet.This design provides secure transport, immutable storage, indexed search, alerting, retention management, and least-privilege analyst access suitable for security operations and incident response.
MediumSystem Design
78 practiced
Design a secure, highly-available public web application on AWS. The app serves static content from S3/CloudFront and dynamic APIs backed by ECS/EKS or Lambda. For each layer (edge, load balancer, compute, storage, database, CI/CD) list the security controls you would deploy, justify TLS termination choices, WAF rules, DDoS mitigation, secrets handling, and how to integrate secure image and code scanning into the pipeline.
Sample Answer
**Edge (CloudFront + Route53)**- Controls: Enforce TLS1.2+/HTTP Strict Transport Security, Origin Access Identity to S3, Geo/IP restrictions, signed URLs for private content.- DDoS: AWS Shield Advanced for edge protection + anomaly detection; use rate-based CloudFront behaviors.- TLS termination: Terminate TLS at CloudFront (public cert in ACM) to hide origin IPs and leverage edge TLS performance and Shield—use TLS to origin (origin protocol policy HTTPS) for end-to-end encryption.**WAF**- Controls: OWASP CRS, custom rules for SQLi/XSS, size/rate limits, IP reputation lists, bot control.- Rule examples: block suspicious user-agents, rate-limit API paths, block common RCE payload patterns, CAPTCHA/challenge for suspicious flows.- Logging to S3 + Kinesis Firehose + Sentinel/Splunk for alerts.**Load Balancer (ALB)**- Controls: ALB with HTTPS listener (ACM cert), listener rules to enforce host/path, 401/429 responses.- TLS termination choice: If using CloudFront + ALB, terminate at CloudFront and re-encrypt to ALB; ALB can also terminate for direct clients in private setups.- Mutual TLS optional for internal microservices.**Compute (ECS/EKS/Lambda)**- Controls: Private subnets for tasks/pods, IAM least privilege, task roles, pod security policies, runtime scanning (Falco), EKS RBAC, Lambda VPC access only when needed.- Image security: Block deployment of images without SBOM and signed by CI (Cosign) and scanned vulnerability thresholds (Trivy/Snyk).- Container hardening: read-only filesystem, drop capabilities, resource limits.**Storage & Database**- S3: Bucket policies, encryption SSE-KMS, object ACL minimal, Bucket Access Logs, MFA delete for critical buckets.- Databases (RDS/Dynamo): Private subnets, IAM auth (where supported), encryption at rest (KMS), automated backups, parameter group auditing, network ACLs.**Secrets Handling**- Use AWS Secrets Manager / Parameter Store with KMS; rotate secrets automatically, grant access via IAM roles, never store in repo or images. Use environment variables injected at runtime.**CI/CD Integration**- Controls: Pipeline in least-privileged role, signed commits, branch protection, ephemeral runners.- Secure scanning: Integrate SCA + SAST (GitHub Actions/GitLab CI with CodeQL, SonarQube), container image scanning (Trivy/Clair) post-build, IaC scanning (tfsec/Checkov), policy-as-code (OPA/Gatekeeper) to block noncompliant changes.- Enforcement: Fail pipeline on high/critical findings, produce SBOM and Cosign signatures, promote artifacts through immutable registries.**Monitoring & Incident Response**- Centralized logs (CloudWatch, GuardDuty, Detective), SIEM alerts, automated playbooks (Lambda) to isolate compromised tasks, runbooks for key incidents.Justification summary: Terminate TLS at CloudFront to maximize edge protections and performance while re-encrypting to origin for confidentiality. WAF+Shield at the edge reduce attack surface before reaching ALB/compute. Secrets, image signing, and pipeline gating ensure only vetted code/images reach prod.
HardTechnical
69 practiced
Write a least-privilege IAM policy JSON (policy document only) that a Lambda execution role can have to: 1) GetObject from a specific S3 bucket prefix (arn:aws:s3:::example-bucket/secure-prefix/*), 2) PutItem into a specific DynamoDB table (arn:aws:dynamodb:region:acct:table/secure-table), and 3) Decrypt using a specific KMS key (arn:aws:kms:region:acct:key/abcd-1234). Include conditions to require secure transport for S3 and restrict S3 actions to calls from this role.
