Free SOA-C03 practice questions

An operations team must alarm on the percentage of used memory and free disk space on a fleet of EC2 instances running a standard Amazon Linux AMI. They have not changed the default monitoring configuration. What is the most operationally efficient way to make these signals available as CloudWatch metrics?

• AInstall and configure the CloudWatch agent on the instances to collect memory and disk metrics and publish them to a custom namespace.check_circle Correct
• BEnable detailed monitoring on each EC2 instance so that memory and disk metrics are published at a one-minute frequency.
• CRead the existing MemoryUtilization and DiskSpaceUtilization metrics that EC2 publishes by default to the AWS/EC2 namespace.
• DCreate a CloudWatch metric filter over the instance system logs to extract memory and disk values into custom metrics.

Why A is correct: The CloudWatch agent reads in-guest counters such as mem_used_percent and disk_free, publishing them as custom metrics that alarms can then evaluate, which is exactly the supported pattern.

Why B is wrong: Detailed monitoring only raises the publishing frequency of the existing hypervisor metrics to one minute; it never adds in-guest memory or disk usage, so the required signals are still missing.

Why C is wrong: It sounds right because CPU is there by default, but EC2 publishes no memory or disk-space metric to AWS/EC2; those values live inside the guest and are never collected automatically.

Why D is wrong: Metric filters only run against log events already in CloudWatch Logs, and the default AMI does not log memory or disk usage, so there is nothing for the filter to match.

An application writes structured logs to a CloudWatch Logs log group, and each authentication failure produces a line containing the token ERROR Login. The team wants to alarm when more than fifty such failures occur in five minutes, using the least additional infrastructure. Which approach meets the requirement?

• ACreate an EventBridge rule that matches the failure log events directly and triggers an alarm action once the threshold is crossed.
• BCreate a CloudWatch Logs metric filter that matches the failure pattern and publishes a count metric, then alarm on its five-minute sum.check_circle Correct
• CCreate a CloudWatch alarm directly on the log group so that it counts matching log lines and fires above the configured threshold.
• DConfigure a Logs subscription filter to stream events to Lambda, which counts failures in memory and raises an alarm when fifty are seen.

Why A is wrong: EventBridge does not subscribe to raw log lines inside a log group, and rules cannot count events over a window, so this cannot evaluate a fifty-in-five-minutes threshold.

Why B is correct: A metric filter turns matching log events into a numeric metric inside CloudWatch, and a standard alarm on the five-minute sum then fires above fifty, meeting the requirement with no extra services.

Why C is wrong: Alarms evaluate metrics, not log groups; there is no way to point an alarm at a log group, so a metric must first be produced from the log data.

Why D is wrong: Streaming to Lambda works but adds a function and stateful counting logic, which is far more infrastructure than a metric filter plus a native alarm for the same outcome.

A platform team runs separate CloudWatch alarms on CPU, memory and request latency for a service. They are paged whenever any single alarm fires, but they only want a page when the service is genuinely unhealthy, defined as high latency occurring at the same time as either high CPU or high memory. Which CloudWatch feature expresses this combined condition with the least new configuration?

• AReplace the three alarms with a single metric-math alarm that adds the CPU, memory and latency metrics and alarms on the combined total.
• BConfigure each existing alarm with an alarm action that pages only when the other two alarms are also in the ALARM state at that moment.
• CCreate a composite alarm whose rule references the existing alarms as latency AND (CPU OR memory) and send the page from that composite alarm.check_circle Correct
• DAdd an anomaly-detection band to the latency alarm so it pages only when latency is statistically unusual relative to CPU and memory.

Why A is wrong: Metric math can combine metrics, but summing differently scaled values is meaningless and cannot express the latency-AND-resource logical condition the team actually needs.

Why B is wrong: Individual alarms cannot read the state of other alarms in their actions, so there is no native way to make one alarm wait on the status of the others.

Why C is correct: A composite alarm evaluates a boolean rule over the states of existing alarms, so latency AND (CPU OR memory) pages only on the genuine combination while reusing the alarms already in place.

Why D is wrong: Anomaly detection models a single metric against its own history and has no awareness of CPU or memory, so it cannot encode the cross-metric AND or OR relationship.

A web tier runs in an EC2 Auto Scaling group, and operators want the group to keep average CPU utilisation across the fleet close to 50 percent, adding or removing instances automatically as traffic rises and falls throughout the day. They want the simplest policy that maintains this set point without them defining individual thresholds for each capacity step. Which scaling policy meets this requirement with the least ongoing tuning?

• AA simple scaling policy that adds two instances whenever a CPU alarm breaches and then waits for a cooldown before evaluating again.
• BA step scaling policy with several CPU alarm bands that each add a different number of instances as utilisation climbs higher.
• CA scheduled scaling action that sets desired capacity higher during the day and lower at night based on the usual traffic curve.
• DA target tracking scaling policy on the average CPU utilisation metric with the target value set to 50 percent.check_circle Correct

Why A is wrong: Simple scaling reacts to one alarm with a fixed change and a blocking cooldown, so it cannot hold a continuous set point and needs the team to hand-tune the threshold and step.

Why B is wrong: Step scaling reacts faster than simple scaling but still forces operators to design and maintain every alarm band and step, which is exactly the per-threshold tuning they want to avoid.

Why C is wrong: Scheduled scaling changes capacity on a clock and is blind to the live CPU metric, so it cannot track an actual utilisation set point as traffic varies unpredictably.

Why D is correct: Target tracking creates and manages the CloudWatch alarms for you and adjusts capacity to hold the metric at the chosen set point, which is the lowest-effort way to keep CPU near 50 percent.

An engineer must define the EC2 instance configuration for a new Auto Scaling group so that the group can mix several instance types and use both On-Demand and Spot capacity in a single group, while keeping the option to publish new versions of the configuration over time. Which mechanism should the group reference to support these capabilities?

• AA launch template, which supports versioning and lets the group request a mix of instance types across On-Demand and Spot capacity.check_circle Correct
• BA launch configuration, which is the supported way to combine multiple instance types and Spot capacity within a single Auto Scaling group.
• CAn AMI block device mapping, which defines the instance types and purchase options the Auto Scaling group will launch.
• DA capacity reservation, which lets the Auto Scaling group draw from several instance types and Spot capacity as demand grows.

Why A is correct: Launch templates are versioned and are the only configuration object that supports a mixed instances policy combining several instance types and both On-Demand and Spot purchase options in one group.

Why B is wrong: Launch configurations are immutable, single instance type, and cannot express a mixed instances policy, so they meet none of the stated capabilities and are no longer recommended for new groups.

Why C is wrong: A block device mapping only describes storage volumes attached at launch and has nothing to do with selecting instance types or On-Demand and Spot purchase options.

Why D is wrong: An On-Demand capacity reservation only holds On-Demand capacity for one instance type in one zone, so it neither mixes instance types nor provides Spot capacity for the group.

Instances in an Auto Scaling group sit behind an Application Load Balancer. Sometimes an instance keeps running and passes its instance status checks, yet the application process has hung and the load balancer target health check reports the target as unhealthy. The team wants the Auto Scaling group to replace such instances automatically. Which configuration change achieves this?

• ALower the instance warm-up time on the scaling policy so that hung instances are counted as unhealthy and replaced sooner.
• BSet the Auto Scaling group health check type to ELB so it treats the load balancer target health result as the instance health signal.check_circle Correct
• CEnable detailed CloudWatch monitoring on the group so that the application failure is detected and the instance is terminated.
• DAdd a lifecycle hook on instance launch so that the group checks the application and terminates instances that fail the check.

Why A is wrong: Warm-up only delays when a new instance counts toward metrics and scaling; it never changes which signals mark an instance unhealthy, so a hung process is still ignored.

Why B is correct: With the ELB health check type the group marks an instance unhealthy when the load balancer reports its target unhealthy, so an application-level failure triggers replacement even while EC2 status checks pass.

Why C is wrong: Detailed monitoring only raises metric publishing frequency to one minute and has no link to instance health evaluation, so it cannot trigger replacement of a hung instance.

Why D is wrong: A launch lifecycle hook only pauses new instances during start-up for custom actions; it does not run ongoing health checks on already running instances, so it misses the later hang.

A platform team rebuilds a hardened Amazon Linux golden AMI every time the upstream base image receives security patches, and they want the rebuild, the hardening steps, a smoke test and the production of a new AMI to run automatically on a schedule with no instance kept running between builds. Which service produces the new golden AMI in the most managed, repeatable way?

• AKeep a long-running EC2 builder instance and use a Systems Manager State Manager association to reapply the hardening configuration to it whenever new patches are released.
• BLaunch an instance from the base AMI on a schedule with Run Command, apply the hardening commands by hand-written scripts, then call CreateImage and terminate the instance manually each cycle.
• CDefine an EC2 Image Builder pipeline with the base image, hardening and test components and a schedule, so each run builds, tests and outputs a new versioned AMI then tears the build instance down.check_circle Correct
• DStore the hardening steps in a CloudFormation template and deploy a new stack on each patch release so the stack update bakes the configuration into a fresh machine image for the fleet.

Why A is wrong: State Manager enforces configuration on a running instance and never outputs an AMI, so it keeps a builder alive between rebuilds and does not produce the new golden image the team needs.

Why B is wrong: Run Command can drive the steps but the team must stitch together scheduling, image creation and cleanup themselves, which is the manual orchestration that a managed image pipeline removes.

Why C is correct: Image Builder pipelines orchestrate build and test components on a transient instance, output a versioned AMI and clean up automatically, which matches the scheduled hands-off golden image rebuild exactly.

Why D is wrong: CloudFormation provisions resources from a template but does not build or register an AMI from a base image, so it cannot bake a hardened golden image the way an image pipeline does.

A team pushes container images to a private Amazon ECR repository and must be told about operating system and language package vulnerabilities in each image, with findings refreshed automatically as new CVEs are published rather than only at the moment of push. Which ECR scanning configuration meets the requirement with the least custom tooling?

• AEnable basic scanning on the repository so each image is scanned on push using the Clair-based open-source database, giving operating system findings that update whenever a new CVE is released.
• BTurn on Amazon GuardDuty for the account so it inspects the images stored in ECR and raises new vulnerability findings as fresh CVE data becomes available to the service.
• CSchedule a Lambda function to pull each image from ECR, run a container vulnerability scanner inside the function and write the resulting package findings back as repository tags on a daily basis.
• DEnable enhanced scanning on the repository, which uses Amazon Inspector to scan operating system and programming language packages and rescans pushed images automatically as new vulnerabilities are disclosed.check_circle Correct

Why A is wrong: Basic scanning runs only on push or manual request and covers operating system packages, so it neither rescans automatically for new CVEs nor reports the language package findings the team requires.

Why B is wrong: GuardDuty analyses threat activity from logs and runtime signals rather than scanning image package contents for CVEs, so it does not produce the per-image vulnerability findings this scenario needs.

Why C is wrong: A custom Lambda scanner can find vulnerabilities but reinvents continuous scanning that ECR enhanced scanning provides natively, adding code, packaging and scheduling the team wanted to avoid.

Why D is correct: Enhanced scanning integrates Amazon Inspector to cover OS and language packages and continuously rescans existing images as new CVEs appear, which is precisely the automatically refreshed coverage the team asked for.

An Amazon ECR repository accumulates many image versions on each CI build, and storage costs are rising because old untagged images are never removed. The team wants ECR itself to delete untagged images once more than ten newer ones exist, automatically and without running their own cleanup code. Which approach achieves this most directly?

• AApply an ECR lifecycle policy to the repository with a rule that targets untagged images and expires them once more than ten newer images exist, letting ECR run the cleanup on its own.check_circle Correct
• BEnable S3 lifecycle rules on the bucket that backs the ECR repository so objects representing untagged image layers transition out and expire after the retention period the team chooses.
• CSchedule an EventBridge rule that invokes a Lambda function each night to list images in the repository and call BatchDeleteImage on the untagged versions beyond the ten most recent ones.
• DTurn on ECR enhanced scanning on the repository so that as each image is scanned the service evaluates its age and removes untagged versions that exceed the configured count of newer images.

Why A is correct: ECR lifecycle policies let a rule select untagged images by count and expire the excess automatically, so ECR performs the cleanup itself with no Lambda or scheduled job to maintain.

Why B is wrong: ECR storage is managed by the service and is not an S3 bucket the team configures, so there is no customer-owned bucket on which to attach the lifecycle rules described here.

Why C is wrong: A nightly Lambda would work but requires the team to write, deploy and maintain cleanup code, which is the custom tooling that a native repository lifecycle policy removes entirely.

Why D is wrong: Enhanced scanning finds vulnerabilities and never deletes images based on age or count, so enabling it does not expire the untagged versions that are driving the storage cost.

Application instances run in a private subnet and must download operating system patches from public package repositories on the internet. The instances must not be reachable from the internet, and inbound connections initiated from the internet must remain impossible. Which configuration provides the required outbound internet access while keeping the instances unreachable from outside?

• AAttach an internet gateway to the VPC and add a route from the private subnet to the internet gateway so the instances can reach the package repositories directly.
• BAdd a route in the private subnet pointing to a virtual private gateway so outbound package traffic leaves the VPC and returns through the same gateway path.
• CPlace a NAT gateway in a public subnet and route the private subnet's internet-bound traffic to that NAT gateway, which forwards it out through the internet gateway.check_circle Correct
• DCreate an interface VPC endpoint in the private subnet so outbound requests to the public package repositories travel over the AWS private network instead.

Why A is wrong: Routing a private subnet straight to an internet gateway makes those instances publicly addressable and reachable from the internet, which breaks the requirement that they stay unreachable from outside.

Why B is wrong: A virtual private gateway connects a VPC to on-premises networks over VPN or Direct Connect, not to public internet repositories, so it does not give the instances the outbound internet path they need.

Why C is correct: A NAT gateway in a public subnet lets private instances start outbound connections to the internet while preventing any inbound connections initiated from outside, which exactly meets the stated requirement.

Why D is wrong: Interface endpoints reach specific AWS services privately, not arbitrary public package repositories on the internet, so they cannot provide the general outbound internet access the patch downloads require.

Web servers sit behind an internet-facing load balancer and reside in a subnet whose route table has a default route to an internet gateway. The team wants to allow inbound HTTPS from any client and let the servers return responses, while blocking all other unsolicited inbound traffic, using the least rules to maintain. Which control should they configure to express this, given its stateful behaviour?

• AA network ACL with an inbound allow on port 443 and a matching outbound allow on the ephemeral port range, because it evaluates each direction separately.
• BA route table entry that sends only port 443 traffic to the internet gateway while discarding inbound packets on every other destination port automatically.
• CAn interface VPC endpoint policy that grants inbound port 443 to clients and denies other ports, since the policy is evaluated for each connection.
• DA security group that allows inbound traffic on port 443 from any address, relying on its stateful tracking to permit the matching return traffic automatically.check_circle Correct

Why A is wrong: A network ACL is stateless and would work, but it needs explicit inbound and outbound rules including ephemeral ports, so it requires more rules to maintain than the stateful option the question favours.

Why B is wrong: Route tables direct packets by destination network, not by port, and they cannot allow or deny traffic, so a route table cannot enforce a port-based inbound filter at all.

Why C is wrong: Endpoint policies govern access to AWS services through a VPC endpoint, not inbound internet traffic to web servers, so they are the wrong control for filtering client HTTPS to the instances.

Why D is correct: A security group is stateful, so allowing inbound port 443 automatically permits the corresponding outbound responses, expressing the requirement with a single rule and no separate return rule to maintain.

Instances in a subnet need direct inbound and outbound connectivity to the public internet so users can reach them by their public IP addresses. The VPC already has an internet gateway attached, and each instance has a public IP, yet traffic to the internet still fails. Which configuration is the missing piece that makes the subnet behave as a public subnet?

• AAdd a route in the subnet's route table that sends the default route for all internet destinations to the attached internet gateway.check_circle Correct
• BAssign a larger IPv4 CIDR block to the subnet so it has enough addresses to support the public IP mappings that internet connectivity requires.
• CAdd a security group rule allowing outbound traffic to all destinations so the instances are permitted to send packets toward the internet gateway.
• DEnable a NAT gateway for the subnet so its instances can translate their addresses and reach the internet through the existing internet gateway.

Why A is correct: A subnet is public only when its route table sends internet-bound traffic to the internet gateway, so adding that default route is the missing piece that lets the publicly addressed instances reach the internet.

Why B is wrong: Subnet size affects how many addresses are available, not whether traffic can reach the internet, so enlarging the CIDR block does nothing to fix the missing path to the internet gateway.

Why C is wrong: Security groups already allow all outbound traffic by default, and even a permissive rule cannot route packets, so this does not supply the route the subnet is missing.

Why D is wrong: A NAT gateway is for private instances that lack public IPs; instances that already have public IPs need a direct route to the internet gateway, not address translation, so a NAT gateway is unnecessary and incorrect here.

An application running on Amazon EC2 instances must read objects from a specific Amazon S3 bucket. The current code uses long-lived IAM user access keys stored in a configuration file on each instance. The operations team wants to remove the static keys and grant the access in the most secure, least-privilege way. Which change meets this requirement?

• AGenerate a new IAM user with an S3 read-only managed policy and distribute its access keys to every instance through a shared encrypted configuration file.
• BCreate an IAM role with a policy scoped to that bucket and attach it to the instances through an instance profile so they receive temporary credentials automatically.check_circle Correct
• CEmbed the IAM user access keys in the application source code so they are version controlled and can be rotated whenever the build pipeline runs a new deployment.
• DAttach the AdministratorAccess managed policy to the existing IAM user so the instances can reach the bucket without any further policy changes being required.

Why A is wrong: This keeps long-lived static keys on the hosts, which is the very risk the team wants to remove, and a broad read-only policy on all buckets is wider than the single bucket needs.

Why B is correct: An IAM role delivered through an instance profile supplies automatically rotated temporary credentials and the scoped policy grants only the one bucket, removing static keys and meeting least privilege.

Why C is wrong: Hardcoding access keys in source code exposes them in the repository and build artifacts and still relies on the long-lived keys the team is trying to eliminate.

Why D is wrong: Administrator access grants far more than reading one bucket, violating least privilege, and it still depends on the static IAM user keys the team wants to remove.

A security team wants to allow IAM users to delete objects in a sensitive Amazon S3 bucket only when those users have signed in with multi-factor authentication during their current session. Approved users already have MFA devices registered. Which approach enforces the MFA requirement directly in the permissions that grant the delete action?

• AAttach an IAM permissions boundary to each user that caps their maximum permissions, relying on the boundary to block any delete request that lacks multi-factor authentication.
• BRequire the users to register hardware MFA devices and assume that AWS automatically refuses every delete API call made from a session that was created without multi-factor authentication.
• CAdd a condition to the IAM policy that allows the delete action only when the aws:MultiFactorAuthPresent key is true, so requests without MFA are not permitted.check_circle Correct
• DEnable AWS account-level MFA on the root user and rely on that setting to require multi-factor authentication for sensitive object deletions performed by IAM users.

Why A is wrong: A permissions boundary limits the maximum effective permissions but does not by itself test for MFA, so it cannot conditionally allow deletes based on the presence of multi-factor authentication.

Why B is wrong: Registering an MFA device does not force its use; AWS only enforces MFA for an action when a policy condition checks for it, so registration alone leaves the delete action ungated.

Why C is correct: The aws:MultiFactorAuthPresent condition key evaluates to true only when the requesting session was authenticated with MFA, so gating the delete action on it allows the call only for MFA-backed sessions.

Why D is wrong: Root user MFA only protects the root account sign-in and has no effect on the sessions or permissions of IAM users performing object deletions in the bucket.

A developer in a member account has an identity-based IAM policy that explicitly allows the ec2:TerminateInstances action. The organisation also attaches a service control policy to the account that does not list that action in any allowed statement. When the developer tries to terminate an instance, the call is denied. Which explanation correctly describes why the request fails?

• AThe identity-based policy must contain an explicit deny for the terminate action, because service control policies only take effect once a matching deny exists on the user as well.
• BService control policies grant permissions on their own, so the request fails only because the identity-based policy did not also attach the matching managed policy for that action.
• CThe request is throttled rather than denied because the two policies conflict, and the action will succeed automatically once the policy evaluation cache refreshes for the account.
• DAn effective permission requires the action to be allowed by both the service control policy and the identity-based policy, so an action absent from the SCP allow list is denied.check_circle Correct

Why A is wrong: SCPs do not need a matching deny on the user; an action missing from an SCP allow list is implicitly denied regardless of what the identity policy states.

Why B is wrong: SCPs never grant permissions; they only set a boundary, so the failure is the missing allow in the SCP ceiling, not a missing managed policy on the identity.

Why C is wrong: Conflicting policies produce a deny, not throttling, and there is no evaluation cache that later turns an implicit deny into an allow once it refreshes.

Why D is correct: A service control policy sets the permission ceiling, so an action it does not allow is implicitly denied for everyone in the account, overriding the identity-based allow on the user.