SOA-C02 practice questions with answers

Answer: B) Configure CloudWatch cross-account observability with a monitoring account sink and link the organization's accounts as source accounts

CloudWatch cross-account observability links source accounts to a monitoring account so the team can query logs and graph metrics across accounts without copying data. Linking through AWS Organizations adds new accounts automatically.

• AIncorrect. An AWS Config aggregator collects resource configuration and compliance data from many accounts. It does not give access to CloudWatch Logs log groups or CloudWatch metrics, so you can't use it to run Logs Insights queries or graph metrics.
• BCorrect. Cross-account observability lets a monitoring account search and analyze metrics, log groups and traces from linked source accounts. The data is not copied. When source accounts are linked through AWS Organizations, accounts created later in the organization are added automatically.
• CIncorrect. An organization trail centralizes records of API activity. It does not include application log groups or CloudWatch metrics, so it cannot support Logs Insights queries or metric graphs across accounts.
• DIncorrect. Dashboard sharing gives people read access to an existing dashboard. It does not let you run one Logs Insights query across many accounts' log groups, and new accounts would need their own dashboards shared by hand.

Answer: A) Create a CloudWatch Contributor Insights rule on the log group that uses clientIp as the contributor key

Contributor Insights analyzes log data in real time and shows time series of the top-N contributors, keyed on a log field such as the client IP. This makes it the right tool for finding which clients send the most traffic.

• ACorrect. Contributor Insights rules analyze incoming log data in real time. They build time series of the top-N contributors, keyed on log fields you choose, such as an IP address field.
• BIncorrect. A metric filter with no dimensions creates one aggregate count. It shows total request volume but can't show which client IPs are sending the requests.
• CIncorrect. Anomaly detection learns the expected range of a metric and flags unusual values. It works on the aggregate metric, so it can't rank individual clients.
• DIncorrect. A canary generates its own synthetic traffic to test availability and latency. It doesn't analyze real client traffic or find the top requesting IPs.

Answer: A) Enable group metrics collection, then alarm when GroupInServiceInstances stays below GroupDesiredCapacity

After enabling Auto Scaling group metrics collection, compare GroupInServiceInstances, which leaves out pending and terminating instances, with GroupDesiredCapacity to detect a group that can't reach its desired size.

• ACorrect. GroupDesiredCapacity is the number of instances the group tries to maintain. GroupInServiceInstances counts running instances and leaves out pending and terminating ones. Both metrics are reported only after group metrics collection is enabled.
• BIncorrect. GroupTotalInstances includes instances that are pending and terminating as well as in service. It can therefore match desired capacity while instances are not actually in service.
• CIncorrect. Auto Scaling group metrics are free at one-minute granularity, but they are reported only if metrics collection is enabled for the group. Without that, there is no data for the alarm to evaluate.
• DIncorrect. GroupMinSize and GroupMaxSize are configured size limits, not counts of running instances. Comparing them shows nothing about whether the group has reached its desired capacity.

Answer: A) An ALB must have subnets in at least two Availability Zones so that load balancer nodes run in multiple zones

An Application Load Balancer that uses Availability Zone subnets must have subnets in at least two different AZs. Elastic Load Balancing places a node in each enabled zone, so the load balancer is not tied to one AZ.

• ACorrect. The ALB documentation says you must select at least two Availability Zone subnets, each in a different AZ. Elastic Load Balancing creates a load balancer node in each enabled zone, so the load balancer doesn't depend on a single AZ.
• BIncorrect. The two-AZ minimum for Availability Zone subnets applies to every ALB, both internal and internet-facing.
• CIncorrect. On an ALB, cross-zone load balancing is always on at the load balancer level and can't be changed there. It also has nothing to do with the minimum number of subnets.
• DIncorrect. The requirement is enforced, not advisory. An ALB using Availability Zone subnets can't be created with only one.

Answer: A) Set the Auto Scaling group's termination policy to OldestInstance

Termination policies decide which instances are removed during scale-in. OldestInstance removes the oldest instances first, after Availability Zone balancing. The default policy targets outdated configurations, not instance age.

• ACorrect. The OldestInstance termination policy removes the oldest instance in the group first, which is recommended when moving a group to a new instance type. Auto Scaling still balances across Availability Zones before it applies the policy.
• BIncorrect. A termination lifecycle hook pauses an instance that has already been chosen for termination so custom actions can run. It does not decide which instance is chosen.
• CIncorrect. The grace period delays health checks on newly launched instances. It has no effect on which healthy instance is removed during scale-in.
• DIncorrect. After balancing AZs, the default policy removes instances with outdated configurations first (a launch configuration, a different launch template, or the oldest launch template version), then those closest to the next billing hour. It does not select by instance age.

Answer: A) Remove DB_PASSWORD from env/variables and define it under env/secrets-manager, referencing the existing secret

For sensitive values, use the buildspec's env/secrets-manager (or env/parameter-store) mapping. Values defined under env/variables can be displayed in plain text in the console and CLI.

• ACorrect. The env/secrets-manager mapping retrieves the value from Secrets Manager at build time and exposes it as an environment variable. CodeBuild also hides values from Secrets Manager in the build logs. AWS recommends the secrets-manager or parameter-store mapping for sensitive values.
• BIncorrect. A plaintext variable defined in the project settings is still stored and shown as plain text in the console and API. Moving it only changes which definition takes precedence.
• CIncorrect. Artifact encryption protects the build output in Amazon S3. It doesn't hide a plaintext environment variable defined in the buildspec.
• DIncorrect. exported-variables passes variable values to later CodePipeline stages. It doesn't mask anything, and exporting a password would expose it more widely.

Answer: A) Edit the document's permissions to Private and add the partner's AWS account ID, either in the console or with the ModifyDocumentPermission API

A document owner can share an SSM document privately with specific AWS account IDs in the same Region, either through document permissions (ModifyDocumentPermission) or through AWS RAM. Public sharing would expose the document to everyone.

• ACorrect. The document owner can share an SSM document privately by changing its permissions to grant access to specific AWS account IDs. The partner can then run it by using its full ARN. AWS RAM resource shares are another supported way to share privately with individual accounts.
• BIncorrect. Public sharing makes the document visible to everyone, which breaks the requirement that no other account may see it. AWS recommends turning on block public sharing unless you need it.
• CIncorrect. An identity-based policy in the company's account only grants permissions to principals in that account. It doesn't share the document with another account. The document owner has to change the document's permissions or use AWS RAM.
• DIncorrect. SSM documents can be shared only with accounts in the same Region. Cross-Region sharing isn't supported.

Answer: A) Create the state machine with the Express workflow type

Express Workflows suit short (up to five minutes), high-volume, idempotent event processing and are billed by executions, duration, and memory. Standard Workflows are billed per state transition, and the type can't be changed after creation.

• ACorrect. Express Workflows are designed for high-volume event processing such as IoT data ingestion and can run for up to five minutes. They are billed by number of executions, duration, and memory used, not per state transition. Their at-least-once execution model is fine because the steps are idempotent.
• BIncorrect. Standard Workflows do run exactly once, but they are billed for every state transition, which is expensive at millions of executions per day. Exactly-once execution matters for non-idempotent actions, and this workflow's steps are idempotent.
• CIncorrect. AWS offers the shorter 30-day retention to meet compliance, organizational, or regulatory requirements. It doesn't change how Standard Workflows are billed, which is per state transition.
• DIncorrect. A state machine's workflow type can't be changed after it is created. Moving to Express would mean creating a new state machine.

Answer: A) An AWS Config managed rule that evaluates IAM users for MFA

AWS Config managed rules such as iam-user-mfa-enabled automatically evaluate IAM users on a schedule and mark users without MFA as NON_COMPLIANT. The credential report shows MFA status but has to be generated and reviewed by hand.

• ACorrect. The iam-user-mfa-enabled managed rule is a periodic AWS Config rule that evaluates AWS::IAM::User resources. It reports NON_COMPLIANT when MFA is not enabled for an IAM user. Config runs the evaluations automatically and records compliance results over time.
• BIncorrect. The credential report does include an mfa_active column for each user. However, someone has to generate and download the CSV (at most once every four hours) and review it. It does not automatically flag users as noncompliant, so this is still a manual check.
• CIncorrect. An Access Analyzer external access analyzer finds resources that are shared with principals outside the zone of trust. It does not evaluate whether IAM users have MFA devices enabled.
• DIncorrect. A trail records API activity, such as MFA device creation or deactivation. It does not evaluate the current MFA status of every user or report compliance results.

Answer: A) Use IAM Access Analyzer to generate a policy from the role's CloudTrail access activity, then test and attach it

IAM Access Analyzer can generate a least-privilege policy from a role's CloudTrail activity. SCPs and permissions boundaries only limit permissions and grant none, and AWS managed policies may grant more than a workload needs.

• ACorrect. IAM Access Analyzer can look at the services and actions a role used, as recorded in CloudTrail, and generate a fine-grained policy from them. AWS recommends this to grant only the permissions needed for a task.
• BIncorrect. SCPs set maximum-permission guardrails but do not grant permissions themselves. If the role's identity-based policy is removed, the role has no permissions at all.
• CIncorrect. AWS managed policies are written for all customers and might not be least privilege for a specific workload. AWS recommends moving from them to customer managed policies scoped to the use case.
• DIncorrect. A permissions boundary only caps the maximum permissions and grants nothing. A boundary that matches the current broad policy leaves the excess permissions in place.

Answer: A) A TLS listener on port 443 with a server certificate from AWS Certificate Manager deployed on the listener

To move TLS processing from the targets to a Network Load Balancer, configure a TLS listener and deploy a server certificate on it. A TCP listener on port 443 passes encrypted traffic through to the targets unchanged.

• ACorrect. A TLS listener offloads encryption and decryption to the Network Load Balancer, and you must deploy at least one server certificate on it. The load balancer uses the certificate to terminate the client connection and decrypt requests before sending them to the targets.
• BIncorrect. With a TCP listener, the Network Load Balancer passes encrypted traffic through to the targets without decrypting it. The instances would still do all the TLS work.
• CIncorrect. Proxy protocol v2 adds client connection details, such as the source IP address, to the traffic sent to targets. It doesn't decrypt anything, so the instances would still handle TLS.
• DIncorrect. A TCP_UDP listener lets the load balancer accept both TCP and UDP on the same port. It doesn't use a server certificate or decrypt traffic, so TLS would still be handled by the instances.

Answer: A) Raise the deregistration_delay.timeout_seconds attribute so draining targets can finish in-flight requests

The deregistration delay controls how long an ALB keeps a deregistering target in the draining state so in-flight requests can complete. Raising it stops requests from being cut off during scale-in.

• ACorrect. A deregistering target enters the draining state. The load balancer stops sending it new requests and waits for the deregistration delay before completing deregistration, which lets in-flight requests finish before the Auto Scaling group terminates the instance.
• BIncorrect. Slow start only ramps up traffic to newly registered healthy targets so they can warm up. It has no effect on requests in flight on targets that are being deregistered.
• CIncorrect. Stickiness controls which target receives a client's later requests. When a target is draining, new requests are routed to a healthy target anyway, and stickiness does not give in-flight requests more time to finish.
• DIncorrect. The unhealthy threshold only changes how many failed health checks it takes to mark a target unhealthy. Scale-in deregistration is not triggered by health checks, so this does not protect in-flight requests.

Answer: A) Set the listener's client affinity to Source IP so endpoint selection hashes on source IP and destination IP

Global Accelerator's default client affinity (None) hashes on the 5-tuple, which includes the source port, so one client can reach different endpoints. Setting client affinity to Source IP hashes on source IP and destination IP, which keeps each client on one endpoint.

• ACorrect. With client affinity set to Source IP, Global Accelerator hashes on the 2-tuple of source IP and destination IP. All connections from one client IP go to the same endpoint, and different clients can still be spread across endpoints.
• BIncorrect. With None, Global Accelerator hashes on the 5-tuple, which includes the source port. A client that connects from different ports can therefore be sent to different endpoints. That is exactly the behavior causing the problem.
• CIncorrect. The traffic dial sets what share of traffic goes to an endpoint group across all clients. It does not tie any one client to an endpoint, so connections from the same client can still be split.
• DIncorrect. Client IP address preservation lets the endpoint see the client's original IP address. It does not change how Global Accelerator chooses an endpoint, so it does not create affinity.

Answer: A) Deploy Instance Scheduler on AWS and assign the instances a business-hours schedule through a tag

Instance Scheduler on AWS stops and starts tagged EC2 and RDS instances on a defined schedule across Regions and accounts, which cuts the cost of non-production instances outside business hours. Compute Optimizer, Budgets actions and Savings Plans don't provide time-based start/stop scheduling.

• ACorrect. Instance Scheduler on AWS uses resource tags and Lambda to stop and start EC2 and RDS instances on a schedule you define, across multiple Regions and accounts. AWS gives stopping instances outside business hours as its example use case.
• BIncorrect. Compute Optimizer recommends better-sized instance types based on utilization. It doesn't stop or start instances on a time schedule.
• CIncorrect. Budget actions run when a budget passes a cost or usage threshold, not at set times of day, so they can't give a recurring business-hours schedule.
• DIncorrect. A Savings Plan lowers the rate in exchange for a usage commitment. It doesn't stop idle instances, and committing to round-the-clock usage locks in spending the team wants to remove.

Answer: A) An S3 Lifecycle configuration with a transition rule that moves objects to S3 Standard-IA 30 days after creation

S3 Lifecycle transition rules automatically move objects to a cheaper storage class, such as Standard-IA, once they reach a set age. Storage Lens only reports, Requester Pays doesn't change who pays for storage, and Replication adds copies.

• ACorrect. S3 Lifecycle transition actions move objects to another storage class on a schedule based on object age. Standard to Standard-IA is a supported transition, and Standard-IA is meant for data that is accessed infrequently. S3 does the work automatically, so the older objects cost less to store.
• BIncorrect. Storage Lens is an analytics feature. It shows metrics and recommendations, such as buckets that have no lifecycle rules, but it doesn't move objects between storage classes, so storage costs stay the same.
• CIncorrect. With Requester Pays, the requester pays for requests and data downloads, but the bucket owner always pays to store the data. Storage cost for the older objects doesn't change.
• DIncorrect. Replication makes extra copies and leaves the originals in S3 Standard, so total storage cost goes up instead of down. It also doesn't wait for objects to reach a certain age.