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

The context key aws:MultiFactorAuthPresent is set automatically by AWS to true when the principal's credentials were obtained using MFA. Because the key has a Boolean value, the correct way to test it in an IAM policy is with the Bool condition operator. If the key evaluates to true, the action is allowed; otherwise, it is implicitly denied. Using StringEquals on aws:MultiFactorAuthAge is not sufficient because the key returns the age of the MFA authentication, not whether MFA was used. aws:SecureTransport enforces HTTPS, not MFA, and sts:AuthenticationType is not a valid IAM context key, so those conditions do not meet the requirement.

The IAM policy simulator can model a request made by any IAM principal against a chosen resource and action. During a simulation you can include and evaluate identity-based policies, resource-based policies such as bucket policies, permissions boundaries, and AWS Organizations SCPs. The simulator produces a detailed evaluation log that identifies exactly which policy statement allowed or denied the action. IAM Access Analyzer focuses on external access, while CloudTrail and AWS Config record or evaluate events after they occur and do not perform pre-change simulations.

An EventBridge rule can match the CloudTrail API event "AuthorizeSecurityGroupIngress", delivering it to a central event bus almost immediately. A resource-based policy on that bus allows events from all member accounts. The centrally managed Lambda function runs only when triggered, needs no agents, and can revoke the offending rule within seconds. AWS Config evaluations are periodic and may take several minutes; CloudTrail Lake queries run on a schedule, not in real time; a polling EC2 instance adds unnecessary cost, maintenance, and single-point-of-failure risk.

The CloudWatch unified agent can collect memory, disk, and custom log data. It can be deployed at scale with Systems Manager Run Command, which lets administrators remotely install the agent, reference a single JSON configuration stored in Systems Manager Parameter Store, and start the agent on all managed instances-no SSH or per-instance scripting required. Enabling detailed monitoring adds only CPU and network metrics, not memory or logs. Running the agent wizard through user-data or deploying the legacy Logs agent would require per-instance interaction and would not automatically provide the required system metrics, making those options less efficient and harder to maintain.

AWS Backup provides a central, fully managed service that natively supports EC2 instance and EBS volume backups. A backup plan can be targeted to resources by tag, apply default KMS encryption, set a 35-day retention rule, and create automatic cross-Region copy jobs without any custom code. Data Lifecycle Manager can also do snapshot automation, but it requires a separate policy per Region and does not manage cross-account or other resource types from one place, adding additional overhead. A custom Lambda solution or an EC2 Image Builder pipeline would achieve the goals but would require writing and maintaining code and schedules, increasing operational burden. Therefore, using AWS Backup is the lowest-effort, fully managed option that meets all requirements.

Amazon RDS Multi-AZ DB clusters (supported for MySQL 8.0 and PostgreSQL 13 or later) create one writer and two readable standby DB instances in three separate AZs. The cluster exposes a single writer endpoint that automatically points to the promoted standby after a failure, typically in under 35 seconds. Because the two standbys are already provisioned and can accept read traffic, the same cluster adds read capacity without needing to create separate read replicas or change the application's write endpoint. Using fully managed Amazon RDS keeps administrative overhead and licensing costs low compared with self-managed databases on Amazon EC2. Standard instance-based Multi-AZ deployments meet the endpoint requirement but have slower failover and no built-in readers. Read-replica architectures do not provide automatic failover within 35 seconds. Self-managed EC2 deployments require the application to handle failover and incur higher operational cost.

The secure way to delegate access across AWS accounts is to create an IAM role in the owning account and configure a trust policy that allows a principal in the other account to assume that role. The role grants only the permissions required-in this case, ssm:GetParameter on the specific parameter. The EC2 instance in the Dev account is associated with an instance-profile role that has permission to call sts:AssumeRole on the target role's ARN. The temporary credentials returned by STS let the application read the parameter without storing long-lived keys. Creating users or sharing access keys violates best practices, and adding permissions to the Dev role alone will not satisfy the cross-account trust requirement because the Parameter Store resource lives in a different account.

Route 53 Resolver cannot create log streams in a CloudWatch Logs log group unless a resource-based policy on that log group grants the service permission. Attaching a policy that lists the log group ARN, specifies the route53.amazonaws.com service principal, and allows the logs:CreateLogStream and logs:PutLogEvents actions lets Resolver write the logs. Enabling VPC Flow Logs, changing the KMS key, or switching to an S3 destination does not correct the CloudWatch permission failure.

Scheduled actions let you scale proactively at known times. Creating one action that raises the Auto Scaling group's desired (and optionally minimum) capacity a few minutes before the lunchtime spike, and a second action that lowers capacity after the spike, ensures instances are running when demand arrives and are terminated when they are no longer needed. This keeps CPU utilization under the 60 percent target and avoids paying for extra instances the rest of the day.

Predictive scaling uses machine-learning forecasts but needs historical data and may scale earlier or later than desired; it adds complexity without clear benefit when the spike occurs at a fixed time. Lowering the target in the existing policy still reacts after the spike begins, so pages will continue to slow. Buying Reserved Instances and disabling scale-in provides capacity but wastes money outside the two-hour window and does not adjust to future changes in load.

When CPU is identified as the dominant wait dimension, Performance Insights proactive recommendations advise adding compute capacity. Scaling the DB instance class to a larger size (for example, moving from a burstable db.t3.medium to a compute-optimized or general-purpose db.m6g.large) directly increases available vCPUs and memory, reducing CPU saturation. Enlarging storage, creating replicas, or applying patches can help other bottlenecks but do not address immediate CPU exhaustion flagged by the recommendation.

The S3 backend can use a DynamoDB table for state locking. When terraform plan or apply commands run, Terraform writes a lock item to the table. If another process already holds the lock, the second process fails and waits, preventing simultaneous writes to the same state file. Enabling S3 versioning (distractor) protects previous versions but does not stop concurrent updates. Switching to the local backend isolates state but breaks collaboration and does not meet the requirement to keep using S3. Parameter Store is not a supported Terraform backend, so it cannot manage state at all.

As of December 6 2021, AWS WAF can deliver web ACL traffic logs directly to a CloudWatch Logs log group or an Amazon S3 bucket. Before this release, AWS WAF required an Amazon Kinesis Data Firehose stream as an intermediary. Network Firewall and Route 53 Resolver DNS Firewall already supported direct delivery to CloudWatch Logs, so they do not represent a new capability. Therefore, AWS WAF is the service that now lets you eliminate the extra Firehose component.

IAM Access Analyzer continuously evaluates resource-based policies and produces a finding whenever a resource is shared outside the account. The finding shows the bucket ARN, the external principal, and the exact policy statement that allows the access, enabling rapid remediation with no additional instrumentation. S3 server access logs, CloudTrail Lake queries, and Amazon Macie assessments can reveal who accessed the bucket, but they do not automatically analyze policies or pinpoint the statement that granted the permission, and they require extra configuration or cost.

Amazon FSx for Lustre is purpose-built for high-performance compute workloads. A file system linked to an S3 bucket can deliver hundreds of gigabytes per second of throughput and sub-millisecond latencies, while transparently synchronizing data to and from S3. Because the pipeline is short-lived, the team can delete the file system after each run and pay only for the hours used.

Amazon EFS, even in its latest throughput modes, maxes out at tens of gigabytes per second and cannot reach the required 100 GB/s. Amazon FSx for Windows File Server provides SMB rather than POSIX semantics and is optimized for Windows workloads, not large-scale HPC throughput. Sharing RAID-0 EBS volumes over NFS from a single instance creates a performance bottleneck, lacks the required aggregate throughput, and introduces a single point of failure.

A CloudWatch alarm can evaluate the per-instance mem_used_percent metric and change to the ALARM state when the threshold is breached. CloudWatch automatically emits an Alarm State Change event to EventBridge, where a rule can be configured to target the AWS-RestartEC2Instance runbook and pass the alarmed instance ID as input. This serverless, event-driven workflow requires no custom code or continuous polling and is the most efficient solution.

The cron-based script and the State Manager association are polling-based solutions that demand agent-side maintenance and custom logic on every instance, resulting in higher operational overhead. A step-scaling policy replaces, rather than reboots, the instance and cannot guarantee the preservation of in-memory state, so it does not meet the reboot requirement.

CloudFormation StackSets with service-managed permissions integrate directly with AWS Organizations. By registering the shared-services account as a delegated administrator, the network team can create and manage StackSets without access to the management or member accounts. Targeting an OU and enabling automatic deployments causes stacks to be created in every existing account in the OU and in any future accounts as they are added. The StackSet automatically handles deployment to the specified Regions (us-east-1 and us-west-2).

The other options fall short:

• Self-managed StackSets require an IAM administration role in every account and do not automatically include new accounts, so manual scripting would be needed.
• Creating individual stacks and sharing resources through AWS RAM does not satisfy the requirement for automatic deployment to future accounts and adds operational overhead.
• Separate CDK pipelines in each account introduce unnecessary complexity and still require onboarding for future accounts; they also fail to centralize management in the shared-services account.

EC2 Image Builder natively supports container pipelines. A container recipe can extend a public Amazon Corretto base image, run build and test components that apply updates, and then distribute the resulting image directly to an Amazon ECR repository. When Amazon Inspector container scanning is enabled on the registry, every pushed image is automatically scanned for CVEs, satisfying the vulnerability-assessment requirement without additional custom code. The entire workflow is managed and scheduled by Image Builder, so no servers or bespoke build scripts need to be maintained. The other options rely on self-managed tooling (Jenkins), custom buildspecs, or repurposing App2Container, all of which introduce additional operational overhead and complexity.

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.

Creating a CloudWatch alarm provides the performance signal. Routing the alarm state-change event through EventBridge lets other AWS services react to that condition. An EventBridge rule can directly invoke a Systems Manager Automation runbook. The runbook can stop the instance, modify its instance type to the next larger family size, and restart it, while Systems Manager records every step for auditing. Scheduled actions do not react to real-time metrics, Auto Recovery only recovers the same instance type, and implementing the logic in Lambda requires additional custom code that the team wants to avoid.

Instances in a private subnet need a path to the public IPv6 internet for tasks like downloading updates. An egress-only internet gateway provides outbound-only IPv6 connectivity and is stateful, allowing return traffic for initiated connections but blocking unsolicited inbound traffic. To enable this, a route for the IPv6 default prefix (::/0) must be added to the subnet's route table, with the egress-only internet gateway as its target. Pointing ::/0 at a regular internet gateway would allow inbound IPv6 traffic, violating the requirements. Routes for 0.0.0.0/0 only affect IPv4 traffic and would not solve the IPv6 connectivity issue.