AWS Certified CloudOps Engineer Associate Practice Test (SOA-C03)

For SAML federation, the IdP must supply the attribute named SessionDuration, not DurationSeconds. The value in that attribute can be any duration up to, but not exceeding, the role's Maximum session duration setting. Because the roles still use the default 1-hour maximum, the 7,200-second request is rejected. Updating each role to allow at least a 2-hour session (7,200 seconds) and sending that value in the SessionDuration attribute lets users obtain the desired 2-hour temporary credentials without violating the compliance limit. Other options either keep the incorrect attribute name, rely on the 1-hour default, or attempt to set the duration from the client side, none of which resolves the authentication failure.

The CDK CLI can detect security-sensitive changes-such as new IAM resources or rules that broaden network access-during cdk deploy. When the command is run with --require-approval broadening, it will prompt for confirmation only when such permission-broadening changes are present. In a non-interactive CI/CD pipeline the prompt cannot be answered, so the CLI exits with a non-zero code, automatically stopping the deployment and allowing a manual review.

Using --no-execute always halts execution, even for harmless updates, creating unnecessary manual work. Bootstrapping with --trusted-accounts only controls who can publish assets and does not enforce change approvals. The --force flag disables all approval prompts, the exact opposite of the requirement.

The gp3 volume type decouples capacity from performance and is priced about 20 % lower than gp2 while offering a default 3 000 IOPS that can be provisioned up to 16 000 IOPS and 1 000 MiB/s. Using the Elastic Volumes feature, the team can modify the existing gp2 volume to gp3 and set higher IOPS and throughput online, so no instance stop, snapshot, or re-attach is required. Migrating to io2 or io2 Block Express would also reduce latency, but those volumes are significantly more expensive and therefore do not satisfy the cost constraint. Purchasing burst credits for gp2 is not possible; the volume automatically earns credits based on size. Converting to st1 lowers costs but is optimized for large sequential throughput and would increase latency for random OLTP workloads.

Route 53 Resolver can forward DNS queries that originate in a VPC to external DNS servers through an outbound endpoint. Creating the endpoint in at least two subnets provides high availability, and a forwarding rule that targets the on-premises DNS IP ensures that any query for corp.example.com leaves the VPC and is answered by the data-center resolver. No changes are needed on the EC2 instances because they continue to use the Amazon-provided .2 resolver, which automatically consults the forwarding rule.

Creating a private hosted zone would require manually adding and updating records for every on-premises host, which is operationally heavy and error-prone. Relying on the Amazon-provided DNS alone will not work because it never forwards queries to on-premises networks. Pointing instances directly to the on-premises DNS server through the VPC's DHCP options removes the benefit of the Amazon-provided resolver (for internal AWS zones) and introduces a single point of failure without providing route-53-level visibility or logging.

AWS Compute Optimizer analyzes up to 14 days of CloudWatch metrics for each EC2 instance, models workload characteristics, and produces precise rightsizing recommendations that maintain or improve performance. Cost Explorer and Trusted Advisor also surface cost-saving ideas, but their recommendations are less granular and draw from billing data rather than detailed performance modeling. CloudWatch Metrics Explorer only visualizes resource metrics and does not generate optimization guidance.

A service control policy (SCP) applied to the organization root is evaluated before IAM permissions in every member account. By using a Deny statement with the aws:RequestedRegion condition key, the SCP blocks any API call targeting a Region other than us-east-1 or us-east-2, preventing resource creation proactively in both existing and newly added accounts without additional setup.

Permission boundaries must be attached to every principal in every account and do not automatically cover new accounts, increasing operational overhead. An AWS Config rule or an EventBridge-triggered Lambda provide only detective or reactive controls-they allow the non-compliant resource to be created before remediation and require additional automation to remain effective. Therefore, the SCP is the simplest and most effective preventive control for Region enforcement.

The ALB returns a 504 Gateway Timeout when it closes the connection because no response is received from the target before the load balancer's idle timeout elapses. The default idle timeout for an ALB is 60 seconds, which is shorter than the 3- to 4-minute checkout operations. Increasing the idle timeout to exceed the longest expected request duration allows the load balancer to keep the connection open until the target responds, eliminating the observed 504 errors.

Changing the deregistration delay only affects in-flight requests during scale-in, not long-running requests on healthy targets. Enabling cross-zone load balancing distributes traffic across zones and does not influence connection timeouts. A Network Load Balancer also has a connection idle timeout (with a default of 350 seconds for TCP listeners), so replacing the ALB with an NLB would not remove timeout limits. Simply adjusting the ALB's idle timeout is the most direct and cost-effective fix.

A stack policy is evaluated during CloudFormation operations. By attaching a policy that denies Update:Replace and Delete actions on the logical ID representing the DB instance, the database is protected from replacement or deletion, yet the same stack can continue to update other resources. Termination protection blocks the entire stack from being deleted but does not stop an update from replacing a resource. The DeletionPolicy attribute only takes effect during stack deletion, not during updates. Drift detection is read-only; it reports configuration differences but cannot prevent changes.

Failover routing in Amazon Route 53 lets you create a primary and a secondary record. The primary record is associated with an HTTPS health check that can be configured to request a specific path such as /health. When that health check fails, Route 53 automatically stops returning the primary record and returns the secondary record instead, sending traffic to the standby Region. Because the records are CNAMEs that reference the ALB DNS names, you can attach the custom health check. Alias records pointing to an ALB cannot have custom Route 53 health checks associated with them; they can only use 'Evaluate Target Health,' which does not check a specific path. A scripted approach has higher operational overhead. While AWS Global Accelerator also provides health-based failover and allows custom health check paths, it is a more complex service designed for improving global application performance and is not the most direct or minimal solution for this specific DNS failover requirement. Latency-based routing would distribute traffic to both Regions instead of maintaining an active-passive posture.

Enabling shadow copies on an Amazon FSx for Windows File Server volume uses the Windows Volume Shadow Copy Service to create point-in-time snapshots of the file system. Users can access these snapshots through the Previous Versions tab in Windows Explorer and restore files or folders without administrator assistance. Shadow copies are incremental, so they consume storage only for changed blocks, meeting the requirement for low overhead. Automatic backups, cross-region replication, and data deduplication do not give end users a self-service way to retrieve historical file versions multiple times per day.

Composite alarms can send Amazon SNS notifications but cannot invoke Auto Scaling or EC2 actions directly. However, every state change on a CloudWatch alarm generates an Amazon EventBridge event. By creating a rule that matches the composite alarm's state change to ALARM and targeting the Auto Scaling policy, the team can launch instances when the composite alarm fires. Replacing the composite alarm with metric math would still require creating a standard metric alarm; converting to an anomaly detection alarm or enabling action suppression does not make Auto Scaling actions possible.

An egress-only internet gateway (EIGW) is purpose-built for outbound-only IPv6 connectivity. It is stateful, so return traffic is automatically allowed while unsolicited inbound IPv6 packets are dropped, meeting the security requirement without extra rules. EIGWs have no hourly charge, so they are cheaper than alternatives. A NAT gateway could also work by using NAT64 together with DNS64, but it adds hourly and data-processing costs. A standard internet gateway would expose the instances to inbound IPv6 traffic unless every subnet or instance is locked down with security groups; the policy prefers the gateway itself to block such traffic. Interface VPC endpoints provide private access to specific AWS services only and cannot reach public package mirrors.

As of late 2023, CloudWatch alarms can invoke Lambda functions directly. For this to work, the Lambda function must have a resource-based policy that grants the CloudWatch Alarms service principal (lambda.alarms.cloudwatch.amazonaws.com) permission to invoke it. Without this permission, CloudWatch cannot trigger the function, even if the alarm action is configured correctly. The Lambda function's execution role defines what the function can do, not who can invoke it. The old method of using an SNS topic is no longer required for this direct integration. Finally, using EventBridge is an alternative integration pattern, not a solution for a failing direct invocation permission.

Amazon ECS integrates with Application Auto Scaling, which can attach a target-tracking or step scaling policy to an ECS service. The policy can reference any Amazon CloudWatch metric, including the default ApproximateNumberOfMessagesVisible metric from the SQS queue. When the metric breaches the defined threshold, Application Auto Scaling automatically increases or decreases the desired task count with no custom code. Creating and scheduling a Lambda function adds operational overhead, migrating to Fargate does not in itself provide proactive scaling, and changing CPU reservations does not address the need to scale on queue depth.

A gateway VPC endpoint lets instances access Amazon S3 without traversing a NAT device, removing that portion of the traffic from any hourly or data-processing charge. Replacing each managed NAT gateway with a small NAT instance in the same Availability Zone eliminates the NAT gateway hourly fee yet preserves zonal redundancy: if one AZ fails, instances in the surviving AZ still have a local NAT instance for internet-bound traffic. NAT instances cost less per hour than NAT gateways and support the required outbound access when sized for the workload.

A single shared NAT gateway lowers hourly cost but introduces cross-AZ data charges and creates a single point of failure, violating the availability requirement. An egress-only internet gateway only supports IPv6 traffic, so IPv4 YUM repository access would fail. An interface endpoint for Systems Manager does not provide general internet access and cannot reach public YUM repositories, so patching would be interrupted.

A service control policy (SCP) attached to the Dev OU establishes an organization-wide guardrail. By adding an explicit Deny on ec2:RunInstances when the request includes the parameter "AssociatePublicIpAddress" set to true, no principal in any Dev account can grant itself permission to launch instances with public IPs. Because SCPs are evaluated before IAM policies and cannot be overridden by account administrators, the restriction is centrally enforced.

Creating IAM policies in each Dev account would work only until an administrator with sufficient privileges changes or detaches the policy. AWS Config and GuardDuty can detect or alert on non-compliant resources but cannot block the API call in real time, so they do not satisfy the requirement to prevent the action.

Modifying the existing RDS instance to a Multi-AZ deployment provisions a synchronous standby in another Availability Zone. Amazon RDS continuously monitors both nodes and, when the primary becomes unavailable, automatically updates the instance's DNS to point to the standby. Typical failover completes in about 60-120 seconds, meeting the 2-minute RTO, and requires no administrator intervention. Read replicas use asynchronous replication and require manual promotion, while snapshots and EC2-hosted databases behind RDS Proxy demand manual steps or are unsupported for automatic AZ-level failover, so they do not satisfy the stated RTO or operational constraints.

AWS WAF can stream detailed JSON logs of every evaluated request to Amazon Kinesis Data Firehose. Firehose can then deliver the records directly to an S3 bucket, where an S3 Lifecycle rule can transition or expire objects after 30 days to control storage costs. Because the data is stored in S3, analysts can create an Athena table and run ad-hoc SQL queries without additional infrastructure.

Application Load Balancer access logs do not include the specific WAF rule that caused a block action, so they cannot satisfy the audit requirement. CloudWatch metrics expose only aggregated counts, not request-level details, and CloudWatch Logs Insights cannot query data that is never written to Logs. CloudTrail records control-plane API calls, not the individual HTTP requests processed by the load balancer or WAF. Therefore, enabling AWS WAF logging through Kinesis Data Firehose to S3 with Athena querying is the only option that meets all stated needs.

CloudFormation StackSets with service-managed permissions are designed for centrally deploying stacks across multiple AWS accounts and Regions that are members of an AWS Organization. When you target one or more OUs, CloudFormation automatically creates or updates stacks in every existing account in the specified Regions. If a new account later joins the OU, the StackSet automatically deploys the stack to that account as well, and built-in stack rollback handles failed deployments. AWS RAM cannot share CloudWatch alarms because CloudWatch resources are not a supported shareable type. Service Catalog would require each account owner to launch the product manually, and a custom Lambda triggered by CreateAccount events adds more operational code to build and maintain. Therefore, using a CloudFormation StackSet with service-managed permissions and OU targets is the lowest-effort, fully automatic solution.

Changing the table to on-demand capacity mode lets DynamoDB automatically accommodate sudden increases in traffic up to double the previous peak, while charging only for the actual read and write requests. This removes the need to forecast capacity and prevents throttling when unpredictable spikes occur.

Enabling auto scaling on a provisioned table can still allow throttling because scaling is incremental and may lag behind sudden bursts. Manually raising provisioned capacity to the highest observed peak would stop throttling but wastes money when traffic is low. Replicating data to another table adds complexity and does not address the root cause of capacity shortages.