Free Practice Questions for Amazon Web Services SOA-C03 Exam

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.

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.

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

To ensure video files are cached at CloudFront edge locations after migrating the files to Amazon S3, CloudFront must be able to fetch those video objects directly from S3 as an origin. The most operationally straightforward pattern is to add S3 as a second origin and create a separate cache behavior that routes requests for video paths (for example, /video/* or /*.mp4) to the S3 origin. With this configuration, CloudFront caches the S3-served objects at edge locations according to the cache policy/headers, while the existing ALB origin continues serving dynamic application paths. This isolates static media delivery from the application tier and improves performance by maximizing cache hits at the edge.

Option A is not how CloudFront origin selection works: CloudFront does not “redirect” to S3 based on headers; it selects an origin per behavior. Option C (signed URLs) is an access-control mechanism and does not, by itself, ensure the objects are retrieved from S3 or cached correctly. Option D (origin groups) is for origin failover (primary/secondary) and does not provide path-based routing to ensure videos come from S3.

The CloudWatch agent supports modular configuration using the append-config option, which allows additional log sources to be added without overwriting the existing baseline configuration. This makes it ideal for incremental log collection changes across large fleets.

By creating a separate configuration file specifically for DHCP logs and using Systems Manager Run Command, the CloudOps engineer can remotely update only the relevant instances in a scalable and automated manner. This approach avoids manual login and preserves the existing baseline configuration.

Options B and C require manual intervention on each instance, which is not scalable or operationally efficient. Option D captures additional logs indiscriminately and does not specifically target DHCP logs, potentially increasing noise and cost.

Therefore, Option A is the most efficient and AWS-recommended approach.

Amazon EBS snapshots are stored in Amazon S3, and standard restores can experience higher latency until data blocks are fully retrieved. Fast Snapshot Restore (FSR) eliminates this latency by ensuring that all blocks are immediately available at full performance.

Because the production environment uses a General Purpose SSD (gp3) volume, creating the test database on the same volume type ensures performance characteristics are as similar as possible. Using FSR significantly reduces restore time and allows load testing to begin immediately.

Provisioned IOPS volumes would introduce different performance characteristics and unnecessary cost. Standard snapshot restore would delay testing due to gradual block hydration.

Therefore, using FSR with the same EBS volume type is the fastest and most accurate solution.

As documented in AWS Cloud Operations and Database Recovery, Aurora Backtrack allows you to rewind the existing database cluster to a chosen point in time without creating a new cluster. This feature supports fine-grained rollback for accidental data changes, making it ideal for scenarios like table deletions or logical corruption.

Backtracking maintains continuous transaction logs and permits rewinding within a configurable window (up to 72 hours). It does not require creating a new cluster or endpoint, and it preserves the same production environment, fulfilling the operational requirement for in-place recovery.

In contrast, Point-in-Time Recovery (Option D) always creates a new cluster, while replica promotion (Option A) and Lambda restoration (Option B) are unrelated to immediate rollback operations.

Therefore, Option C, using Aurora Backtrack, best meets the requirement for same-cluster restoration and minimal downtime.

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.

The AWS Cloud Operations and Security documentation confirms that AWS WAF (Web Application Firewall) is designed to protect web applications from application-layer threats, including SQL injection, cross-site scripting (XSS), and other OWASP Top 10 vulnerabilities.

When integrated with an Application Load Balancer, AWS WAF inspects incoming traffic using rule groups. The AWS Managed Rules for SQL Injection Protection provide preconfigured, continuously updated filters that detect and block malicious SQL patterns.

AWS Shield (Standard or Advanced) defends against DDoS attacks, not application-layer SQL attacks, and vulnerability scanners (Option C) only detect, not prevent, exploitation.

Thus, Option D provides the correct, managed, and automated protection aligned with AWS best practices.

AWS CloudFormation StackSets are designed specifically for deploying a single CloudFormation template across multiple AWS accounts and multiple AWS Regions. With service-managed permissions, StackSets integrate with AWS Organizations so the administrator does not need to manually create IAM roles in every target account. AWS documentation states that service-managed StackSets can deploy stacks to accounts managed by AWS Organizations in specific Regions and that CloudFormation creates the required IAM roles on your behalf. This directly satisfies central administration, multi-account deployment, and multi-Region deployment. Options A, B, and C add unnecessary complexity and do not provide native organization-wide lifecycle management. Nested stacks are useful for modular templates, not centralized deployment across many accounts and Regions. Therefore, StackSets with service-managed permissions is the correct CloudOps automation approach.

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

Amazon FSx for Windows File Server is a fully managed native Windows file system that supports SMB, Windows authentication, and Windows ACLs. The Multi-AZ deployment option automatically replicates data synchronously across Availability Zones and provides automatic failover with minimal downtime.

This architecture ensures continuous availability during AZ failures or maintenance events without manual intervention. Users experience consistent access and permissions through SMB, fully meeting the stated requirements.

Storage Gateway introduces on-premises dependencies. DFS Replication increases complexity and recovery time. Therefore, FSx for Windows Multi-AZ is the correct solution.