Practice Test #4

Governance focuses on decision-making mechanisms, policies, risk management, compliance oversight, and aligning cloud investments with business strategy through guardrails and controls. It can influence KPI alignment at a portfolio level, but it does not primarily target building a learning culture or creating guilds for upskilling. Those culture-and-skills elements are more squarely People perspective concerns.

Operations is about operating and supporting cloud workloads: monitoring, incident and problem management, change management processes, reliability practices, and operational readiness. While Operations supports continuous improvement through operational feedback, it is not the primary CAF perspective for workforce upskilling, organizational structure, or establishing cross-functional guilds. The question emphasizes culture and learning rather than runtime operations.

Security covers security strategy, identity and access management, data protection, threat detection, and compliance controls. Security teams may participate in cross-functional models (e.g., DevSecOps), but the core of the question is cultivating continuous growth and learning and bridging business and technology via people and culture. That is not the primary focus of the Security perspective.

Amazon Route 53 is a highly available DNS service that can route users to endpoints using policies like latency-based routing or geolocation. However, Route 53 does not cache and serve static files from edge locations. Even if Route 53 directs users to the “closest” Region, the company is not deploying multi-Region origins, and DNS routing alone cannot achieve sub-60 ms median latency globally for static assets.

Elastic Load Balancing distributes traffic across targets (EC2, containers, IPs) and can span multiple Availability Zones, improving availability and scaling within a Region. But ELB does not provide global edge caching or accelerate delivery to distant geographies. Users in Europe and Asia would still fetch static assets from the single Region, likely exceeding the 60 ms median latency requirement.

AWS Lambda is a serverless compute service and can be used with Lambda@Edge to customize requests/responses at CloudFront edge locations. However, Lambda alone is not a content delivery solution and does not inherently provide caching or global acceleration for static assets. The primary service needed here is CloudFront; Lambda@Edge is optional for advanced logic (headers, auth, rewrites).

Amazon EFS is a managed NFS file system for Linux workloads that need shared POSIX file access from multiple instances. While EFS can scale to large sizes, it is not an object store and does not provide S3-style REST object access, object-level metadata semantics, or S3 Lifecycle transitions to infrequent-access object tiers. EFS has its own storage classes (Standard/IA) but the access model is file-based, not object-based.

Amazon EBS is block storage designed to be attached to a single EC2 instance (or limited multi-attach scenarios) and used like a disk volume. It does not provide direct HTTPS/REST access, object-level metadata, or lifecycle rules to transition objects to infrequent-access tiers. EBS durability/availability characteristics differ from S3 and it is not intended for large-scale, internet-accessible object repositories.

Amazon FSx provides managed file systems (e.g., Windows File Server via SMB, Lustre, NetApp ONTAP, OpenZFS) for specialized file workloads. Like EFS, it is file storage rather than object storage and does not natively meet requirements for REST/HTTPS object access, S3 object metadata, or S3 Lifecycle transitions. FSx is chosen for file protocol compatibility and performance features, not for object storage durability and lifecycle tiering.

Scalability is the ability of an application to handle increased load by adding resources (vertical or horizontal) and is often discussed in the context of long-term growth or designing systems to support higher throughput. While the scenario involves handling spikes, the key requirement is automatic scale out and scale in based on CPU thresholds and time windows. That dynamic, bidirectional behavior is more precisely elasticity than scalability.

Sustainability is an AWS Well-Architected Framework pillar focused on minimizing environmental impacts, improving energy efficiency, and optimizing resource utilization over time. Although scaling down unused capacity can indirectly support sustainability goals, the question is fundamentally about automatically adjusting compute capacity to match demand and cost. The primary concept being tested is elasticity, not sustainability practices or reporting.

Operational excellence is a Well-Architected pillar emphasizing operational processes, automation, monitoring, and continuous improvement. Auto Scaling can be part of operational excellence, but the scenario’s core goal is not about operational processes or governance; it is about dynamically matching capacity to demand and cost efficiency. Therefore, operational excellence is adjacent but not the best representation of the described objective.

Amazon Cognito is an identity service for authentication, authorization, and user management (user pools, identity pools, federation). It does not record AWS resource configuration changes, maintain configuration history, or produce compliance reports for EC2/RDS. Cognito can be part of an application’s security architecture, but it is not an audit evidence system for infrastructure configuration drift or compliance monitoring.

Amazon FSx provides managed file systems (e.g., FSx for Windows File Server, Lustre, NetApp ONTAP, OpenZFS). While it can store files, it does not natively track AWS resource configuration changes or evaluate compliance. Using FSx as a storage target would still require another service to generate the configuration history and compliance data; AWS Config is the service that produces that evidence.

Amazon Inspector is a vulnerability management service that scans workloads (e.g., EC2, container images, and Lambda) for software vulnerabilities and unintended network exposure. It is valuable for security posture, but it does not provide authoritative configuration timelines, configuration snapshots, or compliance reporting for resource configuration drift across Regions. For SOC 2 evidence of configuration changes and compliance states, AWS Config is the correct service.

Amazon RDS is a managed relational database service primarily intended for OLTP workloads (e.g., application backends) using engines like MySQL, PostgreSQL, and SQL Server. While it can run SQL queries, it is not optimized for petabyte-scale analytics, columnar storage, or MPP execution. For 20 TB clickstream analytics with many concurrent analysts and BI reporting, RDS typically becomes cost-inefficient and performance-limited compared to a purpose-built warehouse.

Amazon DynamoDB is a fully managed NoSQL database optimized for low-latency key-value and document access patterns at massive scale. It does not provide a traditional analytical SQL data warehouse experience with complex joins, large aggregations, and columnar storage. Although DynamoDB has PartiQL and can support some query patterns, it is not designed for MPP analytics over 20 TB of historical clickstream data or for standard BI warehouse workloads.

Amazon Aurora is a high-performance managed relational database compatible with MySQL/PostgreSQL, optimized for OLTP and high availability. While Aurora can support read scaling and some reporting, it is not a columnar, MPP data warehouse and is not the best fit for large-scale clickstream analytics with nightly S3 batch loads and heavy aggregation queries. For warehouse-style BI analytics at this scale, Redshift is the intended service.

Rehost (“lift and shift”) moves the application largely as-is to AWS (e.g., onto EC2) with minimal or no code changes. It’s chosen for speed and low risk, not for major architectural modernization. Decomposing a monolith into microservices, implementing event-driven patterns, and building independent CI/CD pipelines goes far beyond rehosting, so this option does not align with the stated goals.

Repurchase means replacing the existing application with a different product, typically a SaaS solution (e.g., moving from a custom CRM to Salesforce). This strategy reduces operational burden but requires adopting a new product’s capabilities and constraints. The question describes containerizing and decomposing the existing application into microservices on EKS, not replacing it with a commercial off-the-shelf or SaaS reporting platform.

Replatform (“lift, tinker, and shift”) involves making a few optimizations to take advantage of cloud services without changing the core architecture—e.g., moving a monolith to containers or switching the database to a managed service with minimal code changes. While EKS and autoscaling could fit replatforming, the explicit microservices decomposition and event-driven redesign indicate a deeper re-architecture than replatforming typically implies.

AWS CodeDeploy automates application deployments (e.g., to EC2, on-premises, Lambda, ECS) and focuses on rolling updates, traffic shifting, and deployment hooks. It does not define or provision foundational infrastructure like VPCs, IAM roles, or RDS from YAML templates, nor does it provide CloudFormation-style change sets for infrastructure updates. CodeDeploy is CI/CD for code, not primary IaC for AWS resources.

AWS Elastic Beanstalk is a managed application platform that deploys web apps and creates supporting resources (like EC2, ALB, Auto Scaling) based on environment configuration. While it can create infrastructure, it is opinionated around application environments and is not intended for repeatable, version-controlled provisioning of arbitrary resources such as custom VPC architectures, IAM roles, and RDS with explicit change sets and rollback semantics like CloudFormation.

Amazon API Gateway is a service for creating, publishing, and securing APIs (REST, HTTP, WebSocket). It is not an infrastructure provisioning tool and does not manage multi-resource deployments via YAML templates, change sets, or rollback. Although API Gateway can be defined within IaC tools (including CloudFormation), API Gateway itself is not the service used to implement infrastructure as code across accounts and Regions.

Stopping spending money running and maintaining data centers refers to eliminating the operational burden and costs of owning/operating facilities (power, cooling, physical security, hardware refresh, racking/stacking). While the company did retire a colocation setup, the question’s primary emphasis is that charges varied directly with EC2 hours and S3 TB-month. That points more specifically to usage-based variable cost, not just avoiding data center operations.

Increase speed and agility is about rapidly provisioning resources (minutes instead of weeks), experimenting quickly, and shortening time-to-market using services like EC2, Auto Scaling, and managed services. The scenario does not discuss faster provisioning, deployment velocity, or iterative experimentation. Instead, it highlights billing that tracks consumption, which is a cost model advantage rather than an agility advantage.

Go global in minutes refers to deploying workloads across multiple AWS Regions and edge locations quickly to serve users worldwide with low latency and resilience. Nothing in the prompt mentions Regions, global expansion, or international user reach. The metrics provided (compute hours and S3 TB-month) and the finance team’s observation are about metered billing, not global infrastructure reach.