Amazon Web Services SOA-C03 AWS Certified CloudOps Engineer - Associate Exam Practice Test

When an AWS Lambda function is configured to run inside a VPC, it loses default internet access. All outbound traffic must be explicitly routed. In this scenario, the Lambda function resides in a private subnet and successfully connects to Amazon RDS, but it times out when attempting to publish messages to Amazon SQS. This indicates a lack of network connectivity to the SQS service endpoint.

There are two valid AWS-supported ways to restore connectivity. The first is to deploy a NAT gateway in a public subnet and update the private subnet route table to send outbound internet-bound traffic (0.0.0.0/0) to the NAT gateway. This allows the Lambda function to reach public AWS service endpoints, including SQS.

The second option is to create an interface VPC endpoint (AWS PrivateLink) for Amazon SQS. This enables private, secure connectivity to SQS directly within the AWS network without traversing the internet. This approach is often preferred for security-sensitive workloads and removes dependency on NAT gateways.

Option A would break database connectivity because the Lambda function must remain in the VPC to access the private RDS instance. Option B does not address outbound connectivity to SQS. Option E is incorrect because Amazon SQS does not support gateway endpoints; only interface endpoints are supported.

Therefore, deploying a NAT gateway or creating an SQS interface endpoint resolves the timeout issue.

IAM user groups allow permissions to be managed centrally and applied to multiple users simultaneously, making them ideal for scalable access management. Attaching policies to groups ensures that changes propagate automatically to all members.

A customer managed policy supports versioning, reuse, and centralized updates, which meets the requirement to modify policies and manage versions over time. AWS managed policies cannot be edited, and inline policies do not support reuse or versioning across multiple principals.

Option A is invalid because service-linked roles are AWS-managed and not designed for user access. Option E lacks versioning and reusability. Option C does not allow customization.

Therefore, using IAM groups with a customer managed policy is the correct and secure solution.

According to AWS Cloud Operations and Governance documentation, AWS Trusted Advisor provides automated checks for security group rules across all accounts, including identifying ports open to 0.0.0.0/0.

When viewed in organizational mode, Trusted Advisor integrates with AWS Organizations, allowing administrators to access organization-wide security findings from a central management account. This approach requires no custom code, additional infrastructure, or manual inspection, providing immediate visibility and the lowest operational overhead.

AWS CLI scripts (Option A) or Lambda automation (Option C) introduce additional maintenance, and Amazon Inspector (Option D) is focused on instance-level vulnerabilities, not network access rules.

Therefore, Option B is the AWS-recommended CloudOps best practice for centralized and low-effort open-port auditing.

Comprehensive and Detailed Explanation From Exact Extract of AWS CloudOps Documents:

The requirement is to alert before throttling occurs. For a DynamoDB table in provisioned capacity mode, throttling happens when demand approaches or exceeds provisioned throughput. CloudWatch provides direct table metrics such as ConsumedReadCapacityUnits and ProvisionedReadCapacityUnits (and related utilization signals). Creating an alarm on ConsumedReadCapacityUnits with a threshold set close to the table’s provisioned read capacity provides an early warning that the table is nearing its limit—before actual throttling prevents reads. The alarm can publish directly to the existing SNS topic so the operations team is notified proactively.

Option C and D focus on detecting throttling after it occurs by matching throttling exceptions in logs. That is reactive and violates “before throttled.” Option B (auto scaling) may reduce the likelihood of throttling, but it does not directly satisfy the alerting requirement and “scaling events” notifications are not a reliable proxy for “approaching throttle” (and may not fire early enough depending on scaling configuration). The simplest, most direct CloudOps approach is a CloudWatch alarm on consumption nearing provisioned capacity.

According to the AWS Cloud Operations and Networking documentation, instances in a private subnet do not have a direct route to the internet gateway and thus require a NAT gateway for outbound internet access.

The correct configuration is to create a NAT gateway in the public subnet, associate an Elastic IP address, and then update the private subnet’s route table to send all 0.0.0.0/0 traffic to the NAT gateway. This enables instances in the private subnet to initiate outbound connections while keeping inbound traffic blocked for security.

Placing the NAT gateway inside the private subnet (Options C or D) prevents connectivity because it would not have a route to the internet gateway. Configuring routes from the public subnet to the NAT gateway (Option B) does not serve private subnet traffic.

Hence, Option A follows AWS best practices for enabling secure, managed, outbound-only internet access from private resources.

AWS Secrets Manager rotation is an API-driven activity that is recorded as an audit event. When the secret rotation workflow is initiated, AWS API activity is captured by AWS CloudTrail, which provides an authoritative source of “who did what and when” for compliance evidence. By creating an Amazon EventBridge rule that matches the relevant CloudTrail event for the rotation operation, the company can automatically detect rotation activity and trigger downstream actions without building a polling system. EventBridge can route matched events directly to Amazon SNS, which then fan-outs the notification to email, SMS, chat integrations, or incident tooling used by the database team.

Option A fits the requirement because it creates an event-driven compliance notification path specifically tied to the rotation operation. It also allows more precise filtering than log scanning: the rule can match the event name and include conditions that reflect successful completion, reducing noise and false positives. EventBridge rules are managed, highly available, and require minimal operational work once configured.

Option B is not the best fit because Secrets Manager does not rely on a “native SNS rotation notification toggle” as a primary mechanism for compliance notifications in the way described; the standard event-driven pattern is to use EventBridge/CloudTrail signals rather than expecting Secrets Manager to publish directly to SNS for every rotation outcome. Options C and D propose filtering CloudWatch Logs, which adds operational overhead (log ingestion, metric filters or subscription filters, and parsing) and is less direct than matching structured API events. CloudWatch Logs filtering is also more brittle because it depends on log formats and correct log routing for the relevant services.

Therefore, using EventBridge to match CloudTrail rotation events and forward them to SNS is the most reliable and low-maintenance solution.

=================

According to the AWS Cloud Operations and Deployment documentation, EC2 Image Builder is the AWS-managed service for automating the creation, maintenance, validation, and deployment of secure and compliant Amazon Machine Images (AMIs).

It allows CloudOps teams to define image pipelines that include only approved software modules and configuration scripts. EC2 Image Builder automatically tests and verifies these AMIs for compliance before deployment.

This process ensures configuration consistency, eliminates manual installation errors, and simplifies ongoing patch management. The service integrates with AWS Systems Manager, Amazon Inspector, and AWS CloudFormation for end-to-end automation.

In contrast:

Amazon Detective and GuardDuty (Options A & B) are security monitoring tools, not image management solutions.

Run Command (Option C) applies ad-hoc updates but does not create standard, reusable AMIs.

Therefore, Option D is correct—EC2 Image Builder provides the most operationally efficient and compliant way to create an approved baseline AMI for future deployments.

Comprehensive and Detailed Explanation From Exact Extract of AWS CloudOps Doocuments:

With simple scaling policies, an Auto Scaling group performs one scaling activity when the alarm condition is met, then observes a default cooldown period (300 seconds) before another scaling activity of the same type can begin. CloudOps guidance explains that cooldown prevents rapid successive scale-outs by allowing time for the newly launched instance(s) to register with the load balancer and impact the metric. Even if the alarm breaches multiple times during the cooldown window, the group waits until the cooldown completes before evaluating and acting again. In this case, although RequestCountPerTarget exceeded the threshold twice within 180 seconds, the group will launch a single instance and then wait for cooldown before any additional scale-out can occur. Options A, C, and D do not reflect the behavior of simple scaling with cooldowns; A describes step/target-tracking-like behavior, and C/D are not Auto Scaling mechanics.

The key requirements are daily patching, zero downtime, and least operational overhead. The most operationally efficient way to achieve frequent patch compliance in an Auto Scaling environment is to adopt an immutable infrastructure approach: bake patches into a new AMI and then roll the fleet to that AMI in a controlled, health-checked manner. AWS Systems Manager Automation can orchestrate patching steps reliably and repeatedly, producing a patched AMI on a schedule without engineers manually logging into instances. After the AMI is created, updating the Auto Scaling group launch template ensures that all newly launched instances use the patched image.

Auto Scaling instance refresh then performs the rollout across the group with guardrails: it replaces instances gradually, can respect minimum healthy percentages, and works with load balancer health checks so traffic remains served while instances are rotated. This satisfies “no downtime” because capacity stays available and requests are routed only to healthy instances during the replacement process.

Option B introduces unnecessary complexity by combining CloudFormation provisioning with patching and then relying on AWS Config to replace instances. AWS Config is a compliance and configuration tracking service, not a primary fleet-replacement mechanism for daily patching. Option C increases operational overhead by requiring custom Lambda logic and manual initiation of the rolling update, which is explicitly more work and more error-prone than a managed instance refresh workflow. Option D again uses AWS Config to replace instances, which does not align well with least overhead or the standard operational model for controlled rolling updates in Auto Scaling groups.

Therefore, the lowest-overhead, highly reliable solution is to use Systems Manager Automation to create a patched AMI, update the launch template, and run an Auto Scaling instance refresh.

=================

The least-effort, most scalable approach to ensure consistent software installation and ongoing updates across tagged Windows instances is to use AWS Systems Manager’s native software distribution and desired-state capabilities. Systems Manager Distributor lets you package third-party software as an “SSM package,” version it, and publish updates in a controlled way. This directly supports the requirement to install a third-party agent and deploy periodic updates when new versions are available.

State Manager Associations let you enforce configuration continuously or on a schedule across a fleet, targeting instances by tags (which the scenario explicitly says are in place). By creating an association that runs AWS-ConfigureAWSPackage, you instruct Systems Manager to install (and optionally update) a specific SSM package on all instances that match the Windows tag criteria. This provides ongoing compliance: newly launched instances that receive the tag will automatically get the agent installed, and existing instances will receive updates according to the association’s frequency and the package version strategy.

Option C (custom Lambda that logs in) is high operational overhead and poor practice (credentials, connectivity, error handling, scaling, and security concerns). Option D (RunRemoteScript) can work but is more brittle than ConfigureAWSPackage because it shifts lifecycle management (versioning, state, idempotency) into scripts. Option B (OpsItem + Inventory) is not an enforcement mechanism for installation/updating; it’s for operations tracking and visibility.

Therefore, Distributor (A) + State Manager association using AWS-ConfigureAWSPackage targeted by tags (E) is the cleanest and lowest-ops solution.

The AWS Cloud Operations and Security documentation specifies that for Amazon CloudFront, automatic certificate renewal is only supported for certificates issued by AWS Certificate Manager (ACM). When a certificate is managed by ACM and validated through DNS validation, ACM automatically renews the certificate before expiration without requiring manual intervention.

Option A ensures that the certificate is issued and managed by ACM, enabling full integration with CloudFront. Option E (DNS validation) is essential for automation; AWS performs revalidation automatically as long as the DNS validation record remains in place.

By contrast, email validation (Option D) requires manual user confirmation upon renewal, which prevents automatic renewals. Certificates issued by third-party certificate authorities (Option B) are manually managed and must be reimported into ACM after renewal. CloudFront does not have a direct feature (Option C) to renew certificates; it relies on ACM’s lifecycle management.

Thus, combining ACM-issued certificates (A) with DNS validation (E) ensures continuous, automated renewal with no downtime or human action required.

EC2 Image Builder is a managed service that automates the creation, testing, vulnerability scanning, and distribution of AMIs. It supports scheduled image pipelines, which makes it ideal for weekly application updates.

Image Builder integrates with Amazon Inspector to perform vulnerability scans during image creation, fulfilling the security requirement. Custom image recipes define application dependencies and installation steps, ensuring consistency across deployments.

Manual AMI creation, cron-based scripts, or direct API calls require ongoing maintenance and do not natively support vulnerability scanning.

Therefore, EC2 Image Builder is the most operationally efficient solution.

Comprehensive and Detailed Explanation From Exact Extract of AWS CloudOps Documents:

AWS Lambda automatically publishes operational metrics to Amazon CloudWatch, including Duration, which represents the time a function invocation takes to run. To alert when processing time exceeds 10 seconds, the most direct and operationally efficient solution is to create a CloudWatch alarm on the Lambda Duration metric and configure the alarm action to publish to an SNS topic. This meets the monitoring requirement without requiring log parsing or additional query mechanisms.

Option B fits best because it uses the built-in metric stream for Lambda observability: CloudWatch metrics are near real-time, require minimal configuration, and alarms are a standard CloudOps practice for proactive notification. The alarm can be configured with the appropriate statistic (for example, Maximum or p99 via metric math where applicable) and a threshold of 10,000 milliseconds, ensuring the operations team is notified before performance degrades further.

Option A is incorrect because PostRuntimeExtensionsDuration is not the primary runtime metric for function execution time, and extracting runtime from logs is unnecessary. Option C changes the function timeout to 10 seconds, which would cause failures rather than simply notifying on slow executions. Option D is more operationally complex because it relies on log queries; CloudWatch alarms are more straightforward when a native metric exists.

Comprehensive and Detailed Explanation From Exact Extract of AWS CloudOps Documents:

The most operationally efficient solution is C because AWS Systems Manager Session Manager is purpose-built for secure, auditable interactive access to EC2 instances at scale—without managing bastion hosts or distributing SSH keys. Session Manager can be configured to log session activity, including commands and output, to durable destinations such as Amazon CloudWatch Logs (and optionally Amazon S3). This directly satisfies the requirement to record interactive sessions and store logs durably.

For automated notifications and alarms, CloudWatch Logs supports metric filters that transform matching log patterns into CloudWatch metrics. Those metrics can then drive CloudWatch alarms and notifications (for example, via Amazon SNS). This is a standard CloudOps pattern: centralize logs, derive metrics from security-relevant patterns, and alert automatically.

Option A and D require installing and operating agents and building a more complex analytics path (Athena queries for alerting), which is less efficient and introduces more moving parts across thousands of instances. Option B adds a bastion host dependency that becomes an operational burden (scaling, patching, hardening, HA) and a potential choke point. Session Manager reduces these burdens by using SSM Agent already installed, IAM-based access control, and centralized logging/monitoring integrations.

AWS CloudOps automation best practices recommend using AWS Systems Manager Quick Setup for organization-wide management and configuration of EC2 instances. The Default Host Management Configuration Quick Setup automatically enables Systems Manager capabilities such as Patch Manager, Inventory, Session Manager, and Automation across all managed instances within the organization.

When deployed from the management account, Quick Setup automatically integrates with AWS Organizations to propagate configuration and permissions to existing and future accounts. This meets the requirement for organization-wide management with no manual configuration or SSH access. AWS documentation notes:

“You can use Quick Setup in the management account of an organization in AWS Organizations to configure Systems Manager capabilities for all accounts and Regions. Quick Setup automatically keeps configurations up to date.”

Options B, C, and D require custom deployments or manual IAM updates, lacking centralized automation. Therefore, Option A fully satisfies CloudOps standards for automated provisioning and ongoing management of EC2 instances across an organization.

Layer 7 (application-layer) HTTP status codes such as 200, 404, and 500 are generated by web-facing services that process HTTP requests. In this architecture, both CloudFront and the Application Load Balancer (ALB) operate at Layer 7 and record HTTP response information in their access logs.

ALB access logs include detailed request and response data such as client IP address, request path, target response status code, and latency. These logs are essential for analyzing how backend EC2 instances respond to client requests.

CloudFront access logs record viewer requests and responses at the edge locations. These logs also include HTTP status codes returned to the client, making them critical for understanding end-user experience and edge-level behavior.

VPC Flow Logs capture network-level (Layer 3 and 4) traffic metadata such as source IP, destination IP, ports, and protocol. They do not contain HTTP status codes. AWS CloudTrail logs API calls to AWS services and does not capture application response codes. RDS logs contain database-related information, not HTTP responses.

Therefore, the correct sources for HTTP Layer 7 status codes are ALB access logs and CloudFront access logs.

An Application Load Balancer (ALB) operates at Layer 7 (HTTP/HTTPS) and supports advanced routing features, including HTTP-to-HTTPS redirection. To meet the requirement of protecting traffic with ACM certificates and automatically redirecting HTTP requests, the ALB must be configured with two listeners.

The correct design is to create an HTTP listener on port 80 and an HTTPS listener on port 443. The SSL/TLS certificate from AWS Certificate Manager is attached to the HTTPS listener. A listener rule on port 80 redirects incoming HTTP requests to HTTPS on port 443, ensuring all client connections are encrypted.

Option A is invalid because HTTPS cannot operate on port 80. Option C uses TCP listeners, which do not support HTTP-level redirects. Option D uses a Network Load Balancer, which operates at Layer 4 and does not support HTTP redirects.

Therefore, Option B is the only solution that satisfies all requirements using AWS-native features with minimal complexity.

EC2 instances in private subnets cannot send traffic directly to the internet gateway because private subnets do not have a direct 0.0.0.0/0 route to the internet gateway. Instead, outbound IPv4 internet access from private subnets is typically provided by a NAT gateway that is deployed in a public subnet. Private subnet route tables then send default internet-bound traffic (0.0.0.0/0) to the NAT gateway as the target. The NAT gateway uses its Elastic IP address and the public subnet’s route to the internet gateway to enable outbound connectivity while still preventing inbound internet-initiated connections to the private instances.

When the company reduced multiple NAT gateways to a single NAT gateway, the routing design likely became inconsistent across Availability Zones. In multi-AZ architectures, it is common to have one NAT gateway per AZ and have each private subnet route to the NAT gateway in the same AZ to maintain zonal resiliency and avoid cross-AZ dependencies. If NAT gateways were removed, some private subnets may still have route table entries that point to NAT gateways that no longer exist. Those subnets would immediately lose outbound internet connectivity. The fix is to update the route tables associated with the affected private subnets so that their 0.0.0.0/0 route targets the remaining NAT gateway.

Option C would violate the requirement that instances must be in private subnets; routing private subnet traffic directly to an internet gateway effectively makes the subnet public. Option A is unnecessary and adds operational burden; NAT instances require patching, scaling, and availability management. Option D does not address the routing target problem and is not how NAT gateway egress is restored for multiple subnets.

Therefore, correcting the private subnet route tables to send internet-bound traffic to the existing NAT gateway is the appropriate solution.

=================

In this scenario, the EC2 instances pass their EC2 status checks, indicating that the operating system is responsive. However, the application hosted on the instance is failing intermittently, returning HTTP 500 errors. This demonstrates a discrepancy between the instance-level health and the application-level health.

According to AWS CloudOps best practices under Monitoring, Logging, Analysis, Remediation and Performance Optimization (SOA-C03 Domain 1), Auto Scaling groups should incorporate Elastic Load Balancing (ELB) health checks instead of relying solely on EC2 status checks. The ELB health check probes the application endpoint (for example, HTTP or HTTPS target group health checks), ensuring that the application itself is functioning correctly.

When an instance fails an ELB health check, Amazon EC2 Auto Scaling will automatically mark the instance as unhealthy and replace it with a new one, ensuring continuous availability and performance optimization.

Extract from AWS CloudOps (SOA-C03) Study Guide – Domain 1:

“Implement monitoring and health checks using ALB and EC2 Auto Scaling integration. Application Load Balancer health checks allow Auto Scaling to terminate and replace instances that fail application-level health checks, ensuring consistent application performance.”

Extract from AWS Auto Scaling Documentation:

“When you enable the ELB health check type for your Auto Scaling group, Amazon EC2 Auto Scaling considers both EC2 status checks and Elastic Load Balancing health checks to determine instance health. If an instance fails the ELB health check, it is automatically replaced.”

Therefore, the correct answer is B, as it ensures proper application-level monitoring and remediation using ALB-integrated ELB health checks—a core CloudOps operational practice for proactive incident response and availability assurance.

References (AWS CloudOps Verified Source Extracts):

AWS Certified CloudOps Engineer – Associate (SOA-C03) Exam Guide: Domain 1 – Monitoring, Logging, and Remediation.

AWS Auto Scaling User Guide: Health checks for Auto Scaling instances (Elastic Load Balancing integration).

AWS Well-Architected Framework – Operational Excellence and Reliability Pillars.

AWS Elastic Load Balancing Developer Guide – Target group health checks and monitoring.

Comprehensive and Detailed Explanation From Exact Extract of AWS CloudOps Documents:

To secure inbound web traffic over HTTPS when using an Application Load Balancer, AWS CloudOps best practices recommend terminating TLS at the load balancer. This is achieved by attaching an SSL/TLS certificate directly to the ALB listener. Therefore, option B is required. By terminating HTTPS at the ALB, traffic between clients and the load balancer is encrypted, and the ALB can then forward traffic to backend EC2 instances using HTTP or HTTPS based on design requirements.

The certificate used for a public-facing retail website must be trusted by internet browsers. AWS Certificate Manager (ACM) public certificates are specifically designed for this purpose and are trusted by common browsers and operating systems. Therefore, option D is required. ACM manages certificate provisioning, renewal, and deployment automatically, which significantly reduces operational overhead.

Option A is incorrect because attaching certificates to each EC2 instance is unnecessary and does not scale well. Option C is incorrect because private certificates are intended for internal use cases and are not trusted by public browsers. Option E is incorrect because ACM-managed public certificates cannot be exported; they must be attached directly to supported AWS services such as ALBs.

This approach aligns with AWS CloudOps guidance for secure, scalable, and highly available HTTPS architectures.

Tagging is essential for governance, cost management, and automation in CloudOps operations. The AWS Organizations tag policies feature allows centralized definition and enforcement of required tag keys and accepted values across all accounts in an organization. According to the AWS CloudOps study guide under Deployment, Provisioning, and Automation, tag policies enable automatic validation of tags, ensuring consistency with minimal manual overhead.

Once tagging consistency is enforced, enabling cost allocation tags in the AWS Billing and Cost Management console allows accurate cost distribution per business unit. AWS documentation states:

“Use AWS Organizations tag policies to standardize tags across accounts. You can activate cost allocation tags in the Billing console to track and allocate costs.”

Option B introduces unnecessary complexity with Lambda automation. Option C detects but does not enforce tagging. Option D limits flexibility to Service Catalog resources only. Therefore, Option A provides a centrally managed, automated, and low-overhead solution that meets CloudOps tagging and cost-tracking requirements.

To detect CPU utilization issues within a 2-minute window, detailed monitoring is required. Basic monitoring publishes metrics at 5-minute intervals, which is too coarse to reliably detect a condition lasting only 2 minutes. Detailed monitoring publishes metrics at 1-minute granularity, allowing precise detection.

Amazon CloudWatch alarms support EC2 reboot actions directly, eliminating the need for custom Lambda functions. This minimizes administrative overhead and leverages native AWS integrations.

Options C and D introduce unnecessary complexity and delay. Option A cannot meet the timing requirement due to metric granularity.

Therefore, using a CloudWatch alarm with detailed monitoring and an EC2 reboot action is the correct solution.

CloudWatch Logs metric filters allow log data to be converted into CloudWatch metrics in near real time. This enables continuous monitoring without custom code or scheduled queries. Metric filters are ideal when log events have a consistent structure and specific patterns, such as HTTP response codes.

By defining a metric filter that matches HTTP 404 responses, CloudWatch can increment a metric each time a 404 occurs. This metric can then be used for dashboards, alarms, and trend analysis. This approach is fully managed, scalable, and requires minimal operational effort.

Options B, C, and D rely on subscription filters or periodic queries, which introduce unnecessary complexity, latency, and maintenance overhead. Therefore, metric filters are the most efficient solution.

In cross-account S3 replication, a common cause of “Access Denied” when reading replicated objects is object ownership. By default, the replicated objects can remain owned by the source account (the account that originally wrote the objects). Even though the objects are physically stored in the destination bucket, the destination account’s users can be blocked from accessing them unless the correct ACLs or ownership controls are in place. This becomes especially visible in disaster recovery or nonproduction copy scenarios where the destination account expects to independently read and manage replicated data.

Amazon S3 provides an option in replication configuration to change the replica object ownership to the destination bucket owner. When enabled, the destination account becomes the owner of the replicated objects, which aligns access control with the bucket ownership and the destination account’s IAM policies. This removes the common cross-account ownership mismatch and resolves Access Denied errors for legitimate users in the destination account who have permissions on the destination bucket.

Option B relates to which objects are included in replication (prefix scoping). If replication were scoped incorrectly, the symptom would typically be missing objects rather than Access Denied on objects that are present. Option C (S3 RTC) is about replication time guarantees and monitoring; elapsed time does not change ownership or permissions and therefore does not resolve Access Denied. Option D (storage class changes) affects cost and retrieval characteristics, not authorization; it would not typically produce Access Denied for standard reads solely because the storage class differs.

Therefore, updating the replication configuration to ensure replicated objects are owned by the destination bucket owner is the correct fix to restore access.

=================

The AWS Cloud Operations and Systems Manager documentation states that to use Session Manager privately within a VPC (without internet access), three interface VPC endpoints must be configured:

com.amazonaws.<region>.ssm – enables Systems Manager core API communication.

com.amazonaws.<region>.ec2messages – allows the agent to send and receive messages between EC2 and Systems Manager.

com.amazonaws.<region>.ssmmessages – enables real-time interactive communication for Session Manager connections.

These endpoints ensure secure, private connectivity over the AWS network, eliminating the need for public internet routing.

Endpoints for S3, Step Functions, or EC2 API (Options C, E, F) are not required for Session Manager functionality.

Thus, the correct combination is A, B, and D, aligning with AWS CloudOps best practices for secure, private Systems Manager access.

The AWS Cloud Operations and Monitoring documentation specifies that the Amazon CloudWatch Agent is the recommended tool for collecting system and application logs from EC2 instances. The agent pushes these logs into a centralized CloudWatch Logs group, providing durable storage and real-time monitoring.

Once the logs are centralized, a CloudWatch Metric Filter can be configured to search for specific error keywords (for example, “ERROR” or “FAILURE”). This filter transforms matching log entries into custom metrics. From there, a CloudWatch Alarm can monitor the metric threshold and publish notifications to an Amazon SNS topic, which can send email or SMS alerts to subscribed recipients.

This combination provides a fully automated, managed, and serverless solution for log aggregation and error alerting. It eliminates the need for manual cron jobs (Option B), custom scripts (Option D), or Lambda-based log streaming (Option C).

For IPv4 traffic, private subnets require a NAT gateway in a public subnet to access the internet. NAT gateways must be deployed in public subnets and associated with an Elastic IP address. Private subnet route tables must direct 0.0.0.0/0 traffic to the NAT gateway.

The question states that NAT gateways are incorrectly placed in private subnets, which cannot provide internet access. Deploying NAT gateways in public subnets resolves this issue and restores outbound connectivity to external APIs.

Option A applies only to IPv6. Option B adds unnecessary complexity. Option D is not applicable because external APIs are not AWS services.

Comprehensive and Detailed Explanation From Exact Extract of AWS CloudOps Documents:

To ensure users can launch instances only from approved AMIs, the control must be enforced at authorization time, not after the fact. An IAM policy with a condition that evaluates the resource tags on the AMI is the correct method. By using an aws:ResourceTag/ApprovedAMI condition (paired with allowing ec2:RunInstances only when the chosen AMI has the required tag/value), the organization can prevent launches from untagged or unapproved images. This implements preventative control and aligns with least privilege.

Option A (Organizations tag policy) is not an enforcement mechanism for EC2 API authorization; tag policies primarily help standardize tagging and report compliance rather than block API calls. Option C (AWS Config required-tags) evaluates resources for compliance after creation and cannot reliably prevent a launch at the time of the API call. Option D is unrelated; GuardDuty detections do not enforce AMI usage policy.

The requirement is to produce cost optimization recommendations for EBS volumes based on IOPS and throughput, and to do so with the most operational efficiency across potentially many instances and volumes. AWS Compute Optimizer is the most suitable service because it analyzes historical utilization metrics and configuration characteristics to generate rightsizing recommendations. When enabled, Compute Optimizer evaluates EBS volume performance patterns (including throughput and IOPS consumption) and can recommend more appropriate volume types or settings to reduce cost while meeting performance needs.

Option C is operationally efficient because it centralizes analysis. Instead of manually inspecting per-volume graphs, Compute Optimizer aggregates and evaluates data over time, reducing human effort and improving consistency. After sufficient observation time, the CloudOps engineer can review the findings and translate them into concrete actions such as reducing provisioned IOPS on io1/io2, selecting gp3 with tuned IOPS/throughput, or resizing volumes that are over-provisioned relative to actual demand.

Option A is manual and does not directly address IOPS/throughput rightsizing; it also incorrectly focuses on consumed space versus provisioned space, which is more relevant to capacity than performance provisioning. Option B is unrelated: EBS-optimized is an EC2 feature for dedicated EBS bandwidth and does not rightsize EBS volume performance or reduce over-provisioned IOPS/throughput. Option D introduces significant operational overhead by installing benchmarking tools and running synthetic tests, which is not scalable, can affect production performance, and still may not reflect real workload patterns.

Therefore, enabling AWS Compute Optimizer and using its EBS volume recommendations is the most operationally efficient approach.

The AWS Cloud Operations and Governance documentation defines that enabling Organizational View in AWS Health allows the management account in AWS Organizations to view and aggregate health events from all member accounts.

This feature provides a single-pane-of-glass view of service health issues, account-specific events, and planned maintenance across the organization — without requiring additional automation or data pipelines.

Alternative options (B, C, and D) require custom integration and ongoing maintenance. CloudTrail does not natively forward AWS Health events, and custom Lambda or DynamoDB approaches increase complexity.

Therefore, Option A — enabling the Organizational View feature in AWS Health — is the most operationally efficient and AWS-recommended solution.

The Instance Scheduler on AWS is an AWS-provided solution designed specifically to start and stop AWS resources such as Amazon RDS instances on a defined schedule. This directly aligns with the requirement to automatically manage RDS instances during predictable idle periods, such as weekends, to reduce costs.

RDS instances incur compute charges while running, even if idle. Stopping them during weekends eliminates those charges while retaining storage and backups. Instance Scheduler supports tag-based scheduling, centralized management, and automated start/stop workflows without custom scripting.

Option A introduces custom automation and ongoing maintenance overhead. Option C (Reserved Instances) is unsuitable because the databases are idle for long, predictable periods and Reserved Instances charge regardless of usage. Option D is incorrect because RDS does not support auto scaling of DB instance classes based on utilization.

Instance Scheduler is the most cost-effective and operationally efficient solution for this use case.

Because all instances are already managed by AWS Systems Manager, the lowest-overhead approach is to use Systems Manager Patch Manager end-to-end. Patch Manager is built specifically to scan managed instances for missing patches and to apply operating system patches according to defined rules. By defining a patch baseline, the CloudOps engineer establishes which patches are approved (and how quickly critical patches are approved), plus any exclusions and compliance rules. A Patch Manager scan can then be run to determine which instances are noncompliant and therefore likely affected by the vulnerability, without the engineer needing to manually inventory hosts.

After identifying affected (noncompliant) instances through the scan results, Patch Manager can apply patches directly using Patch Now (or an equivalent on-demand patch operation) in each Region. This matches the multi-Region requirement while keeping operations simple: no custom code, no additional services, and no complex event orchestration. It also produces compliance visibility in Systems Manager, which helps track remediation status for incident response.

Option B adds AWS Config unnecessarily. AWS Config is useful for recording and evaluating configuration changes and can report compliance against configuration rules, but it is not the most direct tool for identifying missing OS patches on instances already under Systems Manager management. Option C introduces additional moving parts (EventBridge rules and event-driven automation). While it can be powerful, it is more complex than a straightforward Patch Manager scan-and-patch workflow, and it assumes the right compliance events exist for this scenario before remediation begins. Option D is the highest operational burden because it requires rebuilding AMIs, launching replacement instances, and coordinating replacements across two Regions. That approach aligns to immutable infrastructure patterns, but it is not the least overhead for rapid remediation of existing instances.

Therefore, using Patch Manager with a patch baseline, scanning to identify affected instances, and applying patches in each Region is the simplest and most operationally efficient solution.

=================

Comprehensive and Detailed Explanation From Exact Extract of AWS CloudOps Doocuments:

AWS CloudFormation supports the DeletionPolicy attribute to control what happens to a resource when a stack is deleted. For Amazon RDS DB instances, setting DeletionPolicy: Snapshot instructs CloudFormation to retain a final DB snapshot automatically at stack deletion. CloudOps best practice recommends using this native mechanism for data retention and auditability, avoiding manual scripts or out-of-band processes. Options A, B, and D introduce operational overhead and potential human error. With DeletionPolicy set to Snapshot, the environment can be repeatedly created and torn down while preserving data states for later restoration with minimal manual steps. This aligns with IaC principles—declarative, repeatable, and reliable—and supports efficient lifecycle management of ephemeral development stacks.

An Auto Scaling warm pool keeps pre-initialized instances in a stopped or running state, allowing them to be quickly attached to the Auto Scaling group when scaling events occur. This significantly reduces scale-out latency caused by long bootstrapping scripts.

Unlike increasing the minimum instance count, warm pools do not permanently overprovision resources. Predictive scaling improves timing but does not eliminate boot time delays.

Therefore, warm pools provide the fastest scale-out with minimal cost overhead.

Auto Scaling groups with target tracking scaling policies automatically adjust capacity based on real-time demand. This solution is ideal for handling unpredictable and random traffic spikes.

Target tracking scaling maintains a metric, such as average CPU utilization or request count per target, at a defined target value. The Auto Scaling group automatically launches or terminates instances as traffic fluctuates.

Manual scaling, EventBridge-based scaling, or scheduled scaling do not respond dynamically to random traffic patterns.

Therefore, an Auto Scaling group with a target tracking scaling policy is the correct solution.

Amazon Machine Images (AMIs) are Region-specific. An AMI ID that exists in us-west-2 does not automatically exist in eu-west-1. If a CloudFormation template references a hardcoded AMI ID from one Region, stack creation in another Region will fail when that AMI cannot be found.

Additionally, not all AWS services or service features are available in every AWS Region. If the template includes a resource type or feature that is unsupported in eu-west-1, CloudFormation will fail during stack creation.

IAM users are global resources, not Region-specific, so Option A is incorrect. Permission issues would typically fail immediately and are not Region-dependent. Option E is incorrect because CloudFormation can both create and update resources.

Therefore, Region-specific AMIs and unavailable services are the valid reasons for failure.

Comprehensive and Detailed Explanation From Exact Extract of AWS CloudOps Documents:

The correct answer is A because AWS Systems Manager Patch Manager natively supports tag-based targeting, which automatically includes both existing and future instances that match specified tag criteria. AWS CloudOps documentation states that patch policies can target managed nodes by instance tags, allowing administrators to dynamically scope patching operations without additional automation.

By defining the patch policy target as instances with an environment tag value of “Prod,” Patch Manager automatically applies patch baselines to all matching instances. Any new EC2 instance launched with the same tag is included automatically, requiring no manual intervention or additional services. This approach delivers the least operational overhead while remaining fully scalable and compliant.

Options B, C, and D are incorrect because they introduce unnecessary complexity by adding AWS Lambda functions, resource groups, or EventBridge rules. AWS CloudOps best practices emphasize using native Systems Manager capabilities whenever possible to reduce operational burden and failure points.

The reporting workload is read-heavy, and the database shows high Read IOPS even outside the report window, suggesting sustained read pressure from other workloads or inefficient read patterns. The requirement is to improve both performance and availability of the RDS for MySQL instance. An RDS read replica is designed specifically to offload read traffic from the primary database instance and to provide additional capacity for read-heavy use cases such as reporting, analytics queries, and dashboards.

By deploying one or more read replicas, the company can direct the reporting job to a replica (Option B). This reduces contention on the primary instance, lowers read I/O demand on the writer, and can improve overall query latency and throughput. In addition, read replicas can contribute to availability objectives: if the primary instance has issues, replicas can be promoted (manually or as part of certain DR patterns) to become a new standalone database, reducing recovery time for read availability and providing a practical resilience option.

Option A (ElastiCache) can help for highly cacheable and repetitive queries, but it requires application/query redesign and cache invalidation strategy, and it does not inherently improve database availability. Option C is not valid because CloudFront is a CDN for HTTP content and is not an appropriate layer for database queries. Option D (vertical scaling) can improve performance, but it does not offload reads and often involves higher cost; it also does not provide the same availability and read scaling benefits as replicas.

Therefore, adding an RDS read replica and pointing the reporting workload to the reader endpoint best meets the performance and availability requirements.

The AWS Cloud Operations and Governance documentation specifies that AWS Config can be paired with AWS Systems Manager Automation runbooks for automatic remediation of noncompliant resources.

For SSH restrictions, the restricted-ssh managed rule detects any security group allowing inbound traffic on port 22. To automatically remediate these findings, AWS provides the AWS-DisableIncomingSSHOnPort22 runbook. This runbook programmatically removes inbound rules that allow port 22 traffic from affected security groups.

This approach achieves continuous compliance with minimal human intervention. By contrast, sending notifications (Option A) does not enforce remediation, API-based scripts (Option C) add operational overhead, and manual remediation (Option D) violates automation best practices.

Therefore, the most efficient CloudOps solution is Option B, using AWS Config with the AWS-DisableIncomingSSHOnPort22 automation runbook for automatic, scalable enforcement.

AWS Systems Manager Patch Manager provides a centralized and automated way to scan, identify, and remediate missing patches across managed instances. Patch baselines define which patches are approved, and scan operations identify affected instances without applying changes.

Using Patch Now allows immediate remediation across Regions with minimal setup. Other options introduce unnecessary complexity or require manual intervention.

Therefore, Patch Manager with scan and Patch Now is the least operationally intensive solution.

AWS Security Hub is the native AWS service that provides continuous compliance checks against security standards, including the CIS AWS Foundations Benchmark. When integrated with AWS Organizations, Security Hub can automatically enroll existing and newly created accounts, eliminating manual invitations and scripts.

By designating a Security Hub administrator account and enabling automatic account onboarding, the organization ensures consistent security posture monitoring across all accounts. CIS benchmark checks are run continuously, and findings are aggregated centrally, simplifying governance and remediation workflows.

Amazon Inspector focuses on vulnerability scanning for EC2, container images, and Lambda functions—not CIS compliance. GuardDuty is a threat detection service and does not run CIS benchmarks.

Therefore, using AWS Security Hub with automatic organization-wide enrollment is the most efficient solution.

Per the AWS Cloud Operations and Event Management documentation, Amazon EventBridge provides native scheduling capabilities that can trigger events at defined intervals—such as weekly, daily, or cron-based schedules.

Creating an EventBridge rule that runs every Saturday and publishes a message to an SNS topic fully automates the notification process without maintaining servers or manual jobs. This approach is serverless, highly reliable, and fully managed by AWS.

By contrast:

EC2 cron jobs (Option A) require instance management, patching, and cost overhead.

SNS subscriptions (Option C) handle message delivery, not scheduling.

Step Functions (Option D) are designed for complex workflows, not simple scheduled triggers.

Thus, Option B provides the most operationally efficient CloudOps solution by integrating EventBridge scheduled events with SNS topics for automated, recurring notifications.

When a CloudFormation stack is deleted, CloudFormation’s default behavior is to delete the resources it created, including EC2 instances and attached resources defined in the template. The requirement is explicit: the company must keep the instances and all of the instances’ data even if someone deletes the stack. The CloudFormation mechanism intended for this outcome is the DeletionPolicy attribute, which controls what happens to a resource when the stack is deleted or when the resource is replaced during an update.

Setting DeletionPolicy: Retain on the EC2 instance resource instructs CloudFormation to preserve that resource instead of deleting it during stack deletion. With Retain, CloudFormation removes the resource from stack management but leaves the instance running (and therefore keeps the data that remains on the instance and its configured storage). This directly satisfies the requirement because the instance is not terminated as part of stack deletion.

Option A is incorrect for EC2 instances because Snapshot is applicable to certain resource types (commonly storage and database resources where snapshot semantics exist), not as a general “keep my instance” control for EC2 instance resources. Options B and C (DLM and AWS Backup) are valuable for backup and recovery strategies, but they do not prevent CloudFormation from terminating the instances when the stack is deleted. Backups could help restore later, but the requirement is to keep the original instances and their data even after deletion of the stack.

Therefore, the correct solution is to set DeletionPolicy to Retain for the EC2 instance resource in the CloudFormation template.

Comprehensive and Detailed Explanation From Exact Extract of AWS CloudOps Documents:

The most operationally efficient approach is A: copy the AMI to each target Region using copy-image and update the CloudFormation template to reference the correct AMI IDs per Region (commonly via Mappings or parameters). AMIs are regional resources, so an AMI built in us-east-1 cannot be launched directly in other Regions without copying. The copy-image operation is the standard, supported method to replicate an AMI across Regions while preserving the image configuration and backing snapshots in the destination Region.

Once AMIs exist in each Region, CloudFormation can be executed in each Region using the same template logic. Adding mappings for AMI IDs keeps the deployment consistent and repeatable, aligning with Infrastructure as Code practices and minimizing manual steps.

Option B is more work than necessary because copying snapshots and re-creating AMIs adds extra steps and increases the chance of inconsistency. Option C is incomplete because the template will fail or launch incorrect resources if it references an AMI ID that does not exist in the target Region. Option D is not feasible because an Auto Scaling group is a regional construct and cannot span multiple Regions from a single stack update in us-east-1.

EC2 does not publish RAM utilization as a native CloudWatch metric by default. Memory metrics such as mem_used_percent are typically collected by the CloudWatch Agent, which runs on the instance and publishes custom metrics to CloudWatch. Because the requirement is RAM utilization at 5-minute intervals, the CloudWatch Agent can be configured to emit metrics at that cadence (or faster).

“Detailed monitoring” for EC2 mainly affects EC2-provided metrics (like CPU) by changing the period from 5 minutes (basic) to 1 minute (detailed). It does not magically provide memory utilization. Therefore, the key requirement is installing/configuring the CloudWatch Agent and ensuring it has permissions to publish metrics (via an IAM role attached to the instance / instance profile).

Option C correctly combines: (1) basic monitoring (fine for the ask), (2) CloudWatch Agent to publish mem_used_percent, (3) IAM role permissions to allow publishing, and (4) Auto Scaling policy that scales based on the memory metric.

Option B incorrectly implies detailed monitoring provides mem_used_percent (it does not). Option D assumes a “standard” memory metric exists without the agent, which is not correct. Option A references mem_active, which is not the typical metric name exposed by CloudWatch Agent’s standard memory measurements for scaling policies, and also omits the IAM role requirement needed for publishing custom metrics.

Thus, C is the AWS-correct path for memory-based scaling using CloudWatch custom metrics.

The symptoms point to two common database pressure sources: inefficient queries (driving high CPU and latency) and excessive concurrent connections (driving connection management overhead, read contention, and timeouts). The most effective remediation is to address both the SQL workload and the connection surge behavior.

Amazon RDS Performance Insights (Option A) is designed to help identify which SQL statements and wait events contribute most to database load. It provides a database-centric view of performance that highlights top SQL, top waits, and the relative impact of sessions on CPU and other resources. By using Performance Insights to pinpoint the highest-impact SQL and then tuning those queries (for example, improving indexes, reducing full scans, and optimizing query patterns), the company can lower CPU utilization and reduce query latency during peak hours.

Connection surges are best addressed with a managed connection pooling layer. RDS Proxy (Option E) provides connection pooling and multiplexing between application connections and the database, which reduces the overhead of establishing and maintaining a large number of database connections. During spikes, the proxy can smooth bursty connection behavior, improve failover handling, and reduce the risk of overwhelming the database with too many concurrent connections. This directly targets the observed timeouts and read performance degradation tied to surges.

Option B is not the best fit because CloudWatch Logs Insights is a log analytics tool; it is not the primary mechanism for deep SQL performance attribution in RDS and typically requires extensive logging configurations that add overhead. Option C would reduce availability and does not improve performance. Option D would make the problem worse: disabling pooling increases connection churn and overhead, amplifying timeouts and latency during peak traffic.

Therefore, combining Performance Insights query analysis/tuning with RDS Proxy connection pooling best resolves both root causes.

=================

CloudFormation StackSets are designed specifically to deploy and manage the same CloudFormation stack across multiple AWS accounts and Regions from a centralized administration point. When accounts are managed under AWS Organizations, StackSets can integrate directly with Organizations to target Organizational Units (OUs) or specific accounts, which minimizes operational overhead. This removes the need to manually assume roles and deploy stacks one-by-one, and avoids building custom automation (Lambda + cross-account role assumption + account enumeration + error handling + retries + idempotency).

With StackSets, you define the template once and then create stack instances across many accounts in a controlled and consistent manner. StackSets provide built-in features for: (1) centralized rollout and updates, (2) drift detection, (3) automatic deployment to new accounts (when using Organizations integration), and (4) standardized execution roles. This is operationally simpler and safer than scripting because StackSets handle orchestration and track deployment state per account/Region.

Option A increases manual work and is error-prone at scale. Options B and C require custom Lambda orchestration, cross-account permissions, and ongoing maintenance for failure modes and change management. StackSets provide the native “least ops” approach to multi-account CloudFormation deployments under Organizations.

Comprehensive and Detailed Explanation From Exact Extract of AWS CloudOps Documents:

The correct answer is C. Create a store image task. Specify the image ID and the destination S3 bucket, because this is the only AWS-supported solution that allows an AMI to be backed up to Amazon S3 and later restored while preserving the original AMI ID. This capability is essential for regulatory and compliance requirements where immutable identifiers must be retained.

According to AWS CloudOps documentation for Amazon EC2 AMI lifecycle management, the AMI store and restore feature is specifically designed for long-term retention, audit, and compliance scenarios. When an AMI is stored using a store image task, AWS packages the AMI’s configuration, metadata, and associated snapshots and saves them as encrypted objects in an Amazon S3 bucket. When the AMI is restored, AWS explicitly states that the restored AMI retains the same AMI ID as the original image, ensuring continuity for compliance tracking and operational dependencies.

Option A is incorrect because copying an AMI always results in a new AMI ID, even when copied within the same AWS Region. Option B is incorrect because archiving snapshots to Amazon S3 does not preserve AMI metadata or identity; restoring from snapshots requires creating a new AMI with a different ID. Option D is incorrect because the copy-image command is intended for cross-Region or cross-account AMI duplication and also generates a new AMI ID.

AWS CloudOps best practices clearly identify store image tasks as the correct mechanism when AMI identity preservation is required for governance, auditability, and compliance controls.

CloudFront caches content at edge locations to reduce origin requests and improve performance. When a static website is updated by overwriting existing object keys (for example, updating index.html in the same S3 path), CloudFront may continue to serve the cached versions of those objects until the cache’s time-to-live (TTL) expires. This behavior commonly produces a delay where some viewers still receive the old site version, sometimes for many hours, depending on the configured TTLs and any cache headers that CloudFront is honoring.

A CloudFront invalidation (Option D) is designed to address exactly this situation: it removes cached objects from CloudFront edge caches so that the next request for those objects forces CloudFront to retrieve the latest versions from the S3 origin and cache them again. By invalidating key objects such as /index.html (and potentially additional paths if needed), the company can ensure users see the newest deployment quickly without waiting for TTL expiration.

Option A is not the best answer because “adding a Cache-Control header to requests” does not immediately clear content already cached at edge locations; it primarily influences caching behavior for future fetches and can still leave existing cached objects in place until they expire. Option B only enforces HTTPS and does not affect cache freshness or object replacement visibility. Option C (CachingOptimized) is intended to improve caching efficiency and performance for typical workloads; it does not provide immediate propagation of updated objects and can result in CloudFront serving cached responses until TTLs expire.

Therefore, the most direct solution to display the updated website as quickly as possible is to create a CloudFront invalidation.