SOA-C02 Practice Exam — SOA-C02：Sysops Administrator Associate

The core requirement in this scenario is to achieve high availability for the internal web application, which currently operates entirely within a single Availability Zone (AZ). A single AZ deployment creates a critical single point of failure, as any outage affecting that AZ will take all application instances offline. The suggested answer, updating the Auto Scaling group to launch instances in a second AZ in the same region, directly addresses this gap. AZs are isolated failure domains with redundant power, networking, and connectivity within a single AWS region. Spreading the Auto Scaling group across multiple AZs ensures that if one AZ experiences an outage, healthy instances will remain available in the second AZ, and the Application Load Balancer will automatically route traffic only to healthy, available instances. This implementation follows AWS best practices for high availability without introducing unnecessary cost or complexity. Option Analysis: A. Incorrect. Increasing the maximum number of instances in the Auto Scaling group only addresses peak capacity needs, not high availability. All instances still run in the single AZ, so an AZ outage will still take the entire application offline regardless of the maximum instance count. This option improves scalability, not fault tolerance. B. Incorrect. Increasing the minimum number of instances only guarantees baseline capacity, not availability. All instances remain hosted in the single AZ, so the application remains fully vulnerable to an AZ outage. This option addresses capacity requirements, not the high availability requirement specified. C. Correct. Configuring the Auto Scaling group to span a second AZ in the same region eliminates the single point of failure of the single AZ deployment. Auto Scaling groups automatically distribute instances across configured AZs, and replace any instances lost during an AZ outage in the remaining healthy AZ. The Application Load Balancer natively routes traffic to healthy instances across all configured AZs, ensuring the application remains available during single AZ outages, fully meeting the high availability requirement. D. Incorrect. Deploying instances to a second region is a disaster recovery measure, not a standard high availability solution for single-region workloads. This option introduces unnecessary complexity, including cross-region data synchronization, increased latency for internal users, and higher costs. Basic high availability for regional workloads is first achieved via multi-AZ deployment, not multi-region deployment, making this option unsuitable for the stated requirement. Key Concepts: 1. Availability Zone Fault Isolation: Each AZ is an independent, geographically separate failure domain within a single AWS region with redundant infrastructure. Failures in one AZ do not impact other AZs in the same region, so distributing workloads across multiple AZs is the foundational best practice for high availability in AWS. 2. Auto Scaling Group Multi-AZ Support: Auto Scaling groups can be configured to span multiple AZs, automatically balancing instance deployments across specified AZs and replacing failed instances in healthy AZs during outages, to maintain consistent application capacity and availability. 3. Application Load Balancer Cross-Zone Routing: Application Load Balancers automatically distribute incoming traffic across all healthy targets in all enabled AZs, removing the need for manual traffic adjustment during AZ outages and ensuring continuous access for end users. References: Amazon EC2 Auto Scaling User Guide: Distribute instances across multiple Availability Zones, https://docs.aws.amazon.com/autoscaling/ec2/userguide/choose-an-availability-zone.html AWS Well-Architected Framework Reliability Pillar: Use multi-AZ deployments for high availability, https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_multi_az.html

The scenario describes a predictable recurring peak load window occurring every weekend between 6 PM and 11 PM. The requirement is the most operationally efficient solution to improve performance during these peaks. Native scheduled scaling actions for Amazon EC2 Auto Scaling Groups are purpose-built for this exact use case. Scheduled scaling allows administrators to define cron-based recurrence rules to adjust desired, minimum, and maximum Auto Scaling Group capacity ahead of the predicted peak, ensuring sufficient compute resources are provisioned before load increases to eliminate slow response times. A second scheduled action can be configured to scale capacity back down after the peak ends to optimize cost. This solution requires no custom code, no additional third-party or auxiliary AWS services, and minimal ongoing maintenance, making it the most operationally efficient option that fully meets the requirements. Option Analysis: A. This approach is technically functional but not operationally efficient. It requires provisioning and maintaining multiple additional resources: an Amazon EventBridge rule, an AWS Lambda function with custom code to adjust Auto Scaling Group capacity, and IAM roles and policies to grant the required permissions for both resources. This introduces unnecessary operational overhead, maintenance burden, and risk of configuration errors compared to the native scheduled scaling feature built directly into Auto Scaling Groups, so this option is incorrect. B. This option is correct. Amazon EC2 Auto Scaling natively supports scheduled scaling actions with configurable recurrence settings, designed explicitly for predictable recurring load patterns like the weekend peak window outlined in the scenario. Administrators can configure two simple scheduled actions: one to increase desired capacity shortly before 6 PM on weekends to pre-provision sufficient resources for incoming load, and a second to reduce capacity after 11 PM to control costs. No additional services or custom code are required, which minimizes operational overhead and satisfies the efficiency requirement. C. Target tracking is a dynamic scaling policy that adjusts capacity in response to real-time metric thresholds, rather than pre-planned scheduled changes. This policy would only initiate scale-out activities after memory utilization crosses the 70% threshold, which means users would experience slow initial performance during the start of the peak window while new instances are being provisioned. Additionally, it fails to leverage the known predictable peak schedule, resulting in a less effective and less efficient solution than scheduled scaling, so this option is incorrect. D. The Auto Scaling Group cooldown period is a configuration setting that prevents overlapping or conflicting scaling activities by pausing additional scale-in or scale-out actions for a defined period after a scaling activity completes. It has no capability to modify desired capacity on a predefined schedule, so this option is entirely unrelated to the requirement and incorrect. Key Concepts: 1. Scheduled Auto Scaling: A native Amazon EC2 Auto Scaling feature that enables pre-defined adjustments to Auto Scaling Group capacity based on cron or rate-based recurrence schedules, intended for use cases with predictable, recurring load patterns to ensure capacity is available when needed without relying on real-time metric triggers. 2. Scaling Policy Type Selection: A core SysOps competency requiring alignment of scaling policy type to load characteristics: scheduled scaling for predictable recurring load, dynamic scaling for unpredictable variable load, and predictive scaling for load patterns that follow consistent trends over time. 3. AWS Operational Efficiency Best Practice: Prioritizing native managed service features over custom-built solutions reduces operational overhead, maintenance effort, and security or configuration risk, which is a key requirement for the SysOps Administrator role. References: Amazon EC2 Auto Scaling Scheduled Scaling, https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html AWS Certified SysOps Administrator - Associate Exam Guide

The scenario describes a content mismatch where mobile users receive desktop website content after implementing CloudFront in front of an ALB origin. The root cause is that by default, CloudFront does not forward the User-Agent HTTP header to the origin, nor include it in the cache key. The web application running on EC2 instances relies on the User-Agent header to identify client device type and serve the appropriate mobile or desktop content. When CloudFront does not forward this header, the origin cannot perform device detection, and CloudFront may cache a single version of the content (typically the desktop version requested first) for all users, regardless of device. The correct resolution modifies CloudFront behavior to pass the client's User-Agent header to the origin, enabling proper device detection and caching of content variants per device type. Option Analysis: A. Correct. CloudFront distribution behavior settings control which client request headers are forwarded to the origin and included in the cache key. Configuring the behavior to forward the User-Agent header passes the actual client device information to the ALB and EC2 origin, allowing the web application to serve the correct content for mobile and desktop users. CloudFront will also cache separate content variants based on the User-Agent value, ensuring the appropriate version is served to each user type. B. Incorrect. Origin custom headers are static, preconfigured headers that CloudFront adds to every request sent to the origin, rather than passing dynamic client-supplied header values. Adding a static User-Agent header here would send the same fixed device identifier for all requests, which does not allow the origin to distinguish between mobile and desktop users, so the issue persists. C. Incorrect. Enabling IPv6 on the ALB and using dualstack endpoints only supports connectivity for clients using IPv6 addresses. This has no impact on device detection or content versioning based on client device type, so it does not resolve the mismatch between mobile users and desktop content. D. Incorrect. Enabling IPv6 on CloudFront and updating the Route 53 record to a dualstack endpoint only enables IPv6 connectivity for end users. It does not address the missing User-Agent header that is required for device-specific content serving, so this does not fix the described issue. Key Concepts: 1. CloudFront Header Forwarding and Cache Key Configuration: CloudFront behaviors define which HTTP headers, query strings, and cookies are forwarded to the origin and included in the cache key used to identify cached content. By default, most client headers are not forwarded to optimize cache hit ratios, but headers required for origin content customization must be explicitly enabled for forwarding. 2. User-Agent Based Device Detection: Web applications commonly use the User-Agent HTTP header, which includes client device and browser information, to serve device-optimized content. Intermediate services like CloudFront must pass this header from the client to the origin for device detection to work correctly. 3. CloudFront Origin Custom Headers: These are static, administrator-defined headers that CloudFront attaches to all origin requests, used for use cases like verifying that requests come from a specific CloudFront distribution, rather than passing dynamic client request data. References: Configuring cache behavior based on request headers, https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html Adding custom headers to origin requests, https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html

The scenario requires automatic, immediate re-enablement of disabled CloudTrail without the use of custom code. The suggested answer B leverages native AWS Config capabilities to meet both requirements fully. AWS Config continuously monitors resource configuration changes, including CloudTrail enablement status. The AWS-ConfigureCloudTrailLogging is a pre-built managed remediation action provided by AWS, so no custom code is required for execution. The rule is triggered immediately when CloudTrail configuration changes are detected, so remediation occurs as soon as CloudTrail is flagged as disabled, satisfying the immediate re-enablement requirement outlined in the scenario. Option Analysis: A. This option is incorrect. Enabling an organization-level CloudTrail in the AWS Organizations management account applies a default CloudTrail configuration to member accounts, but it does not include any automatic remediation functionality if a user disables CloudTrail in a member account. There is no built-in mechanism to re-enable CloudTrail automatically with this setup, so it fails the core requirement of immediate automatic re-enablement. B. This option is correct. AWS Config natively supports tracking CloudTrail resource configuration changes. The managed CloudTrail configuration rule detects when CloudTrail is disabled and flags the resource as non-compliant. The AWS-ConfigureCloudTrailLogging automatic remediation action is a pre-built, no-code solution that automatically re-enables CloudTrail as soon as the non-compliant state is detected, meeting both the immediate re-enablement and no custom code requirements. C. This option is incorrect. While an AWS Config rule triggering a Lambda function can successfully re-enable CloudTrail, the requirement explicitly states no custom code may be used. Developing a Lambda function to enable CloudTrail counts as custom code, so this option violates the stated constraint. D. This option is incorrect. A scheduled hourly EventBridge rule will only run remediation once per hour, meaning CloudTrail could be disabled for up to 60 minutes before it is re-enabled. This fails the requirement for immediate re-enablement, even though Systems Manager Automation documents do not require custom code to run. Key Concepts: 1. AWS Config Managed Rules and Remediation: AWS Config provides pre-built managed rules to evaluate resource compliance against AWS best practices, and associated managed remediation actions that resolve non-compliant resources without requiring custom code development. This is a core capability for automated, low-overhead compliance enforcement in AWS. 2. Event-Driven vs Scheduled Compliance Remediation: Event-driven remediation actions trigger immediately when a configuration change leading to non-compliance is detected, which is required for time-sensitive compliance controls such as maintaining CloudTrail enablement. Scheduled remediation has inherent latency between the non-compliant state occurring and the remediation running, so it is not suitable for immediate enforcement requirements. 3. CloudTrail Compliance Controls: CloudTrail is a foundational service for audit and security monitoring in AWS, so continuous enablement is a standard compliance control across most regulatory frameworks. AWS provides native, no-code tools to enforce this enablement to reduce operational overhead and the risk of custom code errors. References: AWS Config Automatic Remediation Actions, https://docs.aws.amazon.com/config/latest/developerguide/remediation-actions.html AWS-ConfigureCloudTrailLogging Remediation Action Documentation, https://docs.aws.amazon.com/config/latest/developerguide/automation-action-configurecloudtraillogging.html

The scenario requires pointing a Route 53 managed zone apex (root domain, e.g., example.com) to an Application Load Balancer (ALB) serving a website on EC2 instances. Core DNS standards prohibit CNAME records at the zone apex, as they conflict with required mandatory records (SOA, NS, MX) that exist only at the zone root. ALBs do not have static, persistent IP addresses, so standard A or AAAA records that point to fixed IP addresses cannot be reliably used, as ALB IPs change dynamically during scaling, patching, or infrastructure updates. Route 53 alias records are an AWS-specific feature designed to address this use case: they map a DNS record directly to an AWS resource (including ALBs) by its DNS name, automatically resolve to the current IP addresses of the target resource, support deployment at the zone apex without violating DNS standards, and do not incur Route 53 query charges for AWS resource targets. This perfectly meets the requirements of the scenario. Option Analysis: A. An AAAA record maps a DNS name to a static IPv6 address. ALBs do not have fixed static IPv6 addresses, so a standard AAAA record would become invalid when the ALB's IPv6 addresses change. Additionally, the scenario does not specify IPv6 support is required, so this option is incorrect. B. A standard A record maps a DNS name to a static IPv4 address. ALBs use dynamic IPv4 addresses that change over time, so a static A record would break connectivity when the ALB's IPs update. This is not a reliable solution, so this option is incorrect. C. DNS RFC 1912 explicitly prohibits CNAME records at the zone apex, as a CNAME record for a domain overrides all other record types for that domain, including required SOA, NS, and MX records that are critical to the operation of the hosted zone. Deploying a CNAME at the apex would break the domain, so this option is incorrect. D. Route 53 alias records are purpose-built for routing traffic to AWS resources like ALBs, even at the zone apex. They automatically track changes to the ALB's underlying IP addresses, comply with DNS standards for zone apex records, and provide low-latency, cost-free routing to AWS resources. This exactly meets the scenario requirements, so this option is correct. Key Concepts: 1. Route 53 Zone Apex Restrictions: Per DNS RFC 1912, the zone apex (root domain) cannot use a CNAME record, as CNAME records conflict with mandatory apex records including SOA, NS, and MX, which are required for hosted zone functionality. 2. Route 53 Alias Records: Alias records are an AWS-specific DNS record type that maps a record name to an AWS resource (ALB, CloudFront, S3 website, etc.) instead of a static IP address. They automatically update when the target resource's IP addresses change, support use at the zone apex, and do not incur Route 53 query fees for AWS resource targets. 3. Dynamic ALB IP Addressing: Application Load Balancers use ephemeral, dynamic IP addresses that change as AWS scales the load balancer to meet traffic demand or performs infrastructure maintenance, making static A/AAAA records unsuitable for routing traffic to ALBs long-term. References: Choosing between alias and non-alias records, https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html Routing traffic to an ELB load balancer, https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html