Free Practice Questions for Amazon Web Services SOA-C03 Exam

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

The requirement is classic active-passive (production in us-east-1, DR in us-west-2 “only for failover”). The most operationally efficient and purpose-built solution is Route 53 failover routing combined with health checks. With failover routing, Route 53 designates one record as PRIMARY (us-east-1) and another as SECONDARY (us-west-2). Route 53 continuously evaluates the health check associated with the primary endpoint (commonly the ALB DNS name or a specific health-check path). If the primary fails, Route 53 automatically returns the secondary record, directing client DNS resolution to the DR region. This ensures us-west-2 is used only when us-east-1 is unhealthy, directly matching the requirement.

Latency routing (Option B) is designed to route users to the region with the lowest latency, which can actively send traffic to us-west-2 even when us-east-1 is healthy—violating the “DR only” constraint. Options C and D introduce custom automation (CloudWatch + Lambda + DNS record updates) that increases operational overhead, adds failure modes, and is unnecessary because Route 53 already provides managed health-check-based failover. Additionally, “EC2 instance terminated” is not a reliable proxy for full application availability, and DNS modification automation is more complex than using native Route 53 failover policies.

AWS Systems Manager provides a built-in capability to automatically update the SSM Agent on managed instances. Enabling Auto update SSM Agent ensures that instances receive the latest agent version without manual intervention or custom automation.

This setting is centrally managed and applies across the fleet, making it the most scalable and operationally efficient solution. It eliminates the need for external notifications, custom Lambda functions, or scheduled automation workflows.

Options B and D introduce unnecessary complexity and operational burden. Option C is incorrect because Patch Manager is designed for operating system patching, not for managing SSM Agent updates.

Therefore, enabling automatic SSM Agent updates is the best solution.

According to AWS Cloud Operations and Systems Manager documentation, Session Manager requires that each managed instance be associated with an IAM instance profile that grants Systems Manager core permissions. The required permissions are provided by the AmazonSSMManagedInstanceCore AWS-managed policy.

If this policy is missing or misconfigured, the Systems Manager Agent (SSM Agent) cannot communicate with the Systems Manager service, causing connection failures even if the agent is installed and running. This explains why other instances work—those instances likely have the correct IAM role attached.

Enabling port 22 (Option A) violates the company’s security policy, while configuring user names (Option C) and key pairs (Option D) are irrelevant because Session Manager operates over secure API channels, not SSH keys.

Therefore, the correct resolution is to attach or update the instance profile with the AmazonSSMManagedInstanceCore policy, restoring Session Manager connectivity.

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).

The PrivateDnsName attribute of an EC2 instance is automatically assigned by AWS at launch time and is a read-only property. CloudFormation does not allow users to specify this value manually.

Including PrivateDnsName in the EC2 instance properties causes validation to fail during stack creation. Outputs and Parameters sections are optional, and the VPC is implicitly defined through the subnet ID.

Therefore, attempting to set PrivateDnsName results in stack creation failure.

A NAT gateway uses an Elastic IP address for outbound internet access from private subnets. By creating one NAT gateway in a public subnet in each Availability Zone and routing private subnet outbound traffic through the NAT gateway in the same Availability Zone, the company gets a small, stable list of public source IP addresses to give to the third party. This is also highly available because each Availability Zone has its own NAT gateway path. Option B is impossible because a single Elastic IP address cannot be associated with hundreds of instances simultaneously. Option C is wrong because Network Load Balancers handle inbound traffic distribution, not outbound internet NAT for API calls. Option D is operationally poor and does not provide a scalable centralized static egress pattern.

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

Because the application workload is 95% reads, the best database scaling approach is to add or remove Aurora Replicas. Aurora Auto Scaling can automatically adjust the number of Aurora Replicas in a DB cluster based on metrics such as average CPU utilization or average connections across replicas. This allows the read tier to scale as campaign traffic increases while the primary writer continues to handle the smaller write workload. Option B is incorrect because Aurora Auto Scaling scales the number of replicas; it does not vertically resize existing replicas. Options C and D are worded around generic AWS Auto Scaling rather than Aurora Auto Scaling and use less appropriate metric relationships. Scaling based on replica CPU utilization directly addresses read pressure. Therefore, configure Aurora Auto Scaling for Aurora Replicas.

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

According to the AWS Cloud Operations and Compute Optimizer documentation, Compute Optimizer provides right-sizing recommendations by analyzing Amazon CloudWatch metrics and instance configuration data. However, AWS explicitly notes that only supported instance types are included in Compute Optimizer analyses. If an EC2 instance type is newly released or not yet supported by Compute Optimizer, it will not appear in the Compute Optimizer dashboard until official support is added.

The documentation explains that “Compute Optimizer analyses only supported resource types and instance families. Instances using unsupported or newly launched instance types will not appear in the Compute Optimizer console.” This ensures the service provides accurate recommendations based on sufficient performance history and benchmark data.

While CloudWatch metrics are required for analysis, the complete absence of instances from the dashboard — rather than “insufficient metric data” notifications — indicates unsupported instance types. Compute Optimizer would normally still display those with limited metrics but would flag them as “insufficient data,” not remove them entirely.

Therefore, the most accurate cause of missing instances in this case is that Compute Optimizer does not support the newly released instance types, making option B correct.

AWS Secrets Manager is designed to securely store and automatically rotate database credentials. It integrates natively with Amazon RDS and supports scheduled credential rotation without application changes.

RDS Proxy manages database connections by pooling and reusing connections, which is critical for write-intensive workloads with sudden spikes in client connections. It improves scalability and reduces database resource exhaustion.

KMS rotates encryption keys, not database credentials. Read replicas do not help with write scaling or connection spikes.

Therefore, Secrets Manager combined with RDS Proxy is the correct solution.

Instances in private subnets do not have direct routes to an internet gateway, so they cannot reach public internet endpoints unless the VPC provides a managed egress path. The standard AWS architecture for private-subnet outbound internet access is to use a NAT device (typically a NAT gateway) placed in a public subnet, with an Elastic IP address and a route from the private subnet to that NAT gateway for 0.0.0.0/0 traffic. The NAT gateway then forwards traffic to the internet through the VPC’s internet gateway while preventing unsolicited inbound connections to the private instances.

The scenario states that the VPC has a NAT gateway in each private subnet. That placement prevents proper egress because a NAT gateway itself must be in a public subnet with a route to the internet gateway to function for internet-bound traffic. Without that, private instances will fail to reach external services such as a third-party API, exactly as observed.

Option C corrects the architecture by deploying NAT gateways in the public subnets with Elastic IPs and updating the private subnet route tables so that outbound internet traffic targets the NAT gateways. This enables private workloads to initiate outbound connections while remaining unreachable from the public internet directly, maintaining the intended security posture.

Option A is incorrect because an outbound-only internet gateway is designed for IPv6 egress, not IPv4 internet access. Option B misunderstands routing: API Gateway is an application-layer proxy service and is not a target for VPC route tables to provide generic internet access. Option D is not applicable because VPC interface endpoints provide private connectivity to supported AWS services via PrivateLink, not to arbitrary external public APIs.

Therefore, deploying NAT gateways in the public subnets and routing private subnet egress through them is the correct solution.