Practice Test #6

AWS Systems Manager Automation is best for executing operational workflows (patching, AMI baking steps, instance recovery actions) using runbooks. While it can orchestrate API calls, it is not designed to model and version an entire multi-resource architecture as a reusable, declarative blueprint. It also does not inherently provide the same repeatable, environment-parameterized stack lifecycle management that CloudFormation provides.

AWS Config primarily records configuration history, evaluates resources against rules, and reports compliance. Although Config remediation can trigger automation to correct specific noncompliant settings, it is not intended to provision an entire application stack from scratch across multiple AZs. Using Config as a deployment mechanism is a misuse and would be complex, brittle, and not aligned with standard IaC best practices.

Elastic Beanstalk is a managed application deployment service that provisions underlying resources for supported web/app platforms. It is not well-suited for a bespoke architecture requiring explicit control of a Network Load Balancer configuration, Auto Scaling details, and an Aurora cluster designed for banking transactions. Beanstalk can deploy across multiple AZs, but it abstracts infrastructure and is not the best fit for replicating a validated prototype exactly.

EC2 with Docker Engine and Auto Scaling Groups can scale the number of instances, but it leaves significant operational work: AMI maintenance, OS patching, capacity planning, container scheduling, service discovery, and rolling deployments. You would also need additional tooling (or build your own) to orchestrate containers across instances. This contradicts the requirement to eliminate server provisioning and minimize infrastructure management.

ECS with EC2 launch type improves orchestration versus raw EC2 + Docker, but you still manage the EC2 cluster: instance selection, patching, scaling policies, and ensuring enough spare capacity for task placement during spikes. Cluster Auto Scaling helps, yet it remains more operationally heavy than Fargate and can require careful tuning to avoid capacity shortages during rapid traffic surges.

Using ECS-optimized AMIs on EC2 and manually configuring orchestration is the highest operational burden among the options. Even if ECS is used, “manually configure” implies more hands-on management of cluster capacity, deployments, and maintenance. This directly conflicts with the requirement to focus on application logic and avoid server provisioning and ongoing infrastructure maintenance.

This is not suitable because high-frequency trading systems that require sub-millisecond latency are not a match for a data warehouse platform like Redshift. Redshift is optimized for analytical query throughput, not ultra-low-latency event processing or transaction execution. Real-time streaming and HFT-style decisioning are better served by services such as Kinesis, Apache Flink, in-memory databases, or specialized low-latency architectures.

This is not one of the best answers because the wording focuses on 'data sharing APIs' for application access, which is not a primary Redshift use case in the way the option suggests. Redshift can be queried by applications and supports data sharing features, but it is fundamentally an analytical warehouse rather than an API-serving platform for operational application integration. In this question, scheduled analytics, security, and petabyte-scale historical analysis are more direct and canonical Redshift capabilities.

This is not suitable because Redshift is not designed to act as a high-performance cache for frequently accessed customer profile data. Caching and low-latency key-value access patterns are better handled by services such as Amazon ElastiCache, DynamoDB, or Aurora depending on the access model. Using Redshift for this purpose would be inefficient, costly, and misaligned with its OLAP-oriented design.

AWS CloudFormation templates provide infrastructure as code and parameterized deployments, so they can standardize LMS stacks. However, CloudFormation alone does not provide a governed self-service catalog experience, portfolio distribution, product version lifecycle management, or built-in constraints for many independent institutions. You would need to build additional tooling and access controls to approximate what Service Catalog provides natively.

AWS Systems Manager focuses on operational management (e.g., Patch Manager, State Manager, Automation runbooks, Parameter Store) and can help configure and maintain deployed resources. It is not intended as a primary mechanism for distributing standardized deployable “products” with centralized governance and self-service provisioning across many institutions. It complements provisioning tools but does not replace Service Catalog for catalog-based deployments.

AWS Config records configuration changes, evaluates resources against rules, and supports compliance reporting and remediation workflows. It helps enforce and audit regional compliance requirements after resources exist, but it does not provide a self-service deployment mechanism or centralized version-controlled product distribution. Config is a governance/compliance monitoring service, not a provisioning/catalog service.

Amazon CloudWatch Container Insights is primarily an observability solution, not a deployment management platform. It can centralize metrics and logs, but it does not provide a single dashboard to manage container deployments across ECS and on-premises clusters. The question explicitly requires both visibility and management, so monitoring alone is insufficient. It also would require additional custom setup for non-ECS Docker Swarm environments, which weakens the 'least operational overhead' claim for full management needs.

AWS App2Container is a migration and modernization tool that helps convert existing applications into containerized workloads for ECS or EKS. It does not provide centralized ongoing management of existing multi-environment container clusters. Using it would introduce significant migration effort and does not directly solve the need for unified monitoring and deployment control across current AWS and on-premises environments. Therefore, it is not the lowest-overhead operational solution.

AWS Systems Manager is useful for managing servers and operational tasks such as patching, inventory, and remote command execution. However, it is not a container orchestration platform and does not provide native multi-cluster container deployment management comparable to ECS. Building a unified container management solution with Systems Manager would require substantial custom engineering and integration. That makes it higher overhead and less aligned with the stated requirement.