AWS SOA-C03: Security and Compliance

Topic snapshot

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Security and Compliance

In AWS IAM, what is an IAM role trust policy?

Options:

• A. A policy that enforces MFA for all IAM users in an account

• B. A policy that defines who can assume a role

• C. A policy attached to a resource that grants cross-account access

• D. A policy that defines what actions a role can perform

Best answer: B

Explanation: A role trust policy controls the “who can assume me” side of role usage, including AWS services and other AWS accounts, by specifying the allowed Principal and any required Condition keys. It does not grant permissions to AWS APIs; that is done by identity-based permission policies attached to the role.

An IAM role trust policy is the role’s resource-based policy that establishes trust by defining which principals are allowed to assume the role and under what conditions. For service-to-service access, the trusted principal is typically an AWS service (for example, ec2.amazonaws.com). For cross-account access, the trusted principal is an IAM principal in another account (often the other account root or a specific role/user), and the assume action is sts:AssumeRole (or related STS assume actions).

The permissions the role receives after it is assumed come from permission policies attached to the role (and optionally permission boundaries/session policies), not from the trust policy itself. Key takeaway: trust policy answers “who can assume the role,” while permission policies answer “what the role can do.”

• Role permissions vs trust confuses the role’s attached permission policies with the trust policy.
• Resource policies describes S3 bucket policies, KMS key policies, and similar resource-based access controls, not role trust.
• Account-wide MFA requirement is an IAM policy/condition use case, not the definition of a role trust policy.

Question 2

Topic: Security and Compliance

An operations team is standardizing how application database credentials are handled. Requirements:

• Credentials must be stored in AWS Secrets Manager.
• Compute workloads (EC2, ECS, Lambda) must retrieve secrets at runtime by using IAM roles (no long-term user credentials).
• Secrets must not be written to instance/container filesystems or to logs.

Which TWO actions should the team AVOID? (Select TWO.)

Options:

• A. Enable Secrets Manager rotation and have workloads request the AWSCURRENT version when retrieving the secret

• B. Attach an EC2 instance profile that allows secretsmanager:GetSecretValue on the specific secret ARN and fetch the secret at runtime

• C. For ECS, grant the task role permission to read the secret and reference the secret in the task definition secrets configuration

• D. In EC2 user data, run aws secretsmanager get-secret-value and write the output to a local config file

• E. Create an IAM user, store its access keys in the app config, and call GetSecretValue with those keys

• F. For Lambda, store only the secret ARN as an environment variable, grant the execution role GetSecretValue, and fetch the value at init time

Correct answers: D and E

Explanation: The unsafe actions are the ones that break the explicit controls: using long-term IAM user access keys instead of IAM roles, and persisting secret values to disk or logs. Using IAM roles (instance profiles, task roles, Lambda execution roles) to call secretsmanager:GetSecretValue retrieves secrets securely at runtime. Rotation is compatible with this model when workloads read the current version.

The core operational pattern is: store the secret value in AWS Secrets Manager, then allow the workload to retrieve it at runtime by using its IAM role (EC2 instance profile, ECS task role, or Lambda execution role). This avoids distributing long-term credentials and keeps access auditable and least-privileged by scoping secretsmanager:GetSecretValue to the specific secret ARN (and, if applicable, the KMS key).

Actions to avoid are those that either (1) replace role-based access with static IAM user keys (hard to rotate safely and often leaked), or (2) retrieve the secret but then persist it in places that are commonly harvested during incidents (local files, user data artifacts, bootstrap logs). The safer alternatives retrieve the secret on demand and keep it in memory, while rotation can be enabled without changing the retrieval mechanism.

• Static access keys violates the requirement to use IAM roles and increases leakage risk.
• Writing secrets to disk/logs violates the requirement to avoid persisting secrets on filesystems or in logs.
• Role-based runtime retrieval with scoped secretsmanager:GetSecretValue matches the required control and supports least privilege.
• ECS/Lambda integrations and rotation are acceptable because the IAM role retrieves the secret value from Secrets Manager at runtime without persisting it.

Question 3

Topic: Security and Compliance

When using the IAM Policy Simulator before deploying a permissions change, which TWO statements are true?

Options:

• A. Simulator evaluates security group and NACL rules for reachability

• B. Simulate an unattached JSON policy by adding it as a custom policy

• C. Simulator verifies the resource ARN exists in the target account

• D. Simulator never needs context key values; it infers them automatically

• E. Test a principal’s access to API actions without changing policies

• F. Simulator performs the real API call and logs it to CloudTrail

Correct answers: B and E

Explanation: The IAM Policy Simulator is a safe way to pre-validate effective IAM authorization decisions for a principal and specific API actions. It can test proposed changes by simulating them as custom policies, helping you confirm what would be allowed or denied before you attach policies or roll out access updates.

The core use of the IAM Policy Simulator is to evaluate IAM authorization for a given principal (user/role/group) against specified API actions and (optionally) resource ARNs, without making live service calls. This is especially useful for change validation because you can paste the proposed policy JSON as a custom policy and simulate outcomes before deployment.

If a policy uses conditions, the simulator may require you to provide request context (for example, aws:SourceIp, aws:RequestedRegion, tags) to get an accurate result. The simulator evaluates policy logic; it does not confirm that a referenced resource exists or that non-IAM controls (like security groups) allow connectivity.

Key takeaway: use the simulator to validate permission evaluation, not runtime resource/network behavior.

• OK Simulating a principal’s access lets you validate allow/deny outcomes before attaching changes.
• OK Adding a proposed JSON policy as a custom policy is a standard pre-deployment validation step.
• NO The simulator does not execute real API calls, so it won’t generate CloudTrail events.
• NO If conditions are present, you often must supply context values; the simulator can’t reliably “guess” them.

Question 4

Topic: Security and Compliance

Which statement is INCORRECT about resource-based policies and high-level policy evaluation in AWS?

Options:

• A. For AWS KMS, an IAM policy that allows kms:Encrypt is sufficient to use any KMS key in the account, even if the key policy does not allow that principal.

• B. S3 Block Public Access settings can prevent public access even if a bucket policy would otherwise allow it.

• C. An S3 bucket policy can restrict access to principals in the same AWS Organization by using a condition such as aws:PrincipalOrgID.

• D. In Amazon S3, an explicit Deny in a bucket policy overrides any Allow from IAM policies or ACLs.

Best answer: A

Explanation: AWS KMS authorization requires both identity-based permissions (IAM) and permission from the key itself (key policy or a grant). If the key policy does not allow the principal (directly or via a mechanism like kms:ViaService), requests are denied even when IAM allows them. In S3, explicit denies and account-level/public-access controls affect the final decision.

The core difference is that S3 bucket policies are resource-based policies that can directly allow/deny requests to the bucket/object, while AWS KMS keys are controlled by a key policy (and optionally grants) that acts as an additional gate.

For KMS, a principal must be allowed by:

• An identity-based policy (or other identity permissions), and
• The KMS key policy (or a KMS grant) for that key

If the key policy does not allow the principal to use the key, KMS denies the request even when IAM appears to allow it. For S3, policy evaluation follows the usual rules: explicit denies win, and features like S3 Block Public Access can prevent public access regardless of a permissive bucket policy.

• KMS dual authorization The claim that IAM permission alone is sufficient is unsafe because the key policy (or a grant) must also permit use of that specific key.
• Explicit deny precedence A bucket-policy Deny overrides any Allow from IAM policies or ACLs during evaluation.
• Public access guardrails Block Public Access settings can block public bucket/object access even when a bucket policy would otherwise allow it.
• Organization scoping Using aws:PrincipalOrgID in a bucket policy is a common way to limit access to principals from your AWS Organization.

Question 5

Topic: Security and Compliance

Amazon Inspector generated the following findings in a production account.

Exhibit: Inspector findings (summary)

F1: EC2 (ASG web-prod behind ALB)  Severity: CRITICAL
    Package: OpenSSL   Exploit available: Yes   Network reachable: Yes
F2: ECR image (webapi:2026-02-20 used by prod ECS service)  Severity: CRITICAL
    Package: OpenSSL   Exploit available: Yes
F3: EC2 (batch-internal, no public route)  Severity: MEDIUM
    Package: libxml2   Exploit available: No    Network reachable: No

You must prioritize remediation with minimal risk and an auditable change record. Which THREE actions should the operations engineer AVOID? (Select THREE.)

Options:

• A. Update the launch template to a patched AMI and run an Auto Scaling instance refresh

• B. Rebuild the ECR image from a patched base image and redeploy the service

• C. Temporarily allow SSH from 0.0.0.0/0 to patch the fleet faster

• D. Deregister affected web instances from the ALB, patch via SSM, then re-register

• E. Suppress the critical OpenSSL finding across all resources until next quarter

• F. Terminate the web fleet to force replacement before updating the AMI or container image

Correct answers: C, E and F

Explanation: Inspector findings that are critical, exploitable, and network reachable should be remediated first, using controlled and auditable methods. Actions that hide findings, expand access (for example, broad SSH), or recycle infrastructure without fixing the underlying AMI/image increase security and operational risk. Prioritized remediation should focus on patching or rebuilding the affected artifacts and rolling out safely.

The key to prioritizing Amazon Inspector findings is combining severity with exposure and exploitability. In the exhibit, the OpenSSL issues are CRITICAL with exploit availability, and the EC2 finding is also network reachable, so they should be remediated before the internal MEDIUM finding.

Safe remediation in operations usually means:

• Patch or rebuild the vulnerable artifact (patched AMI and patched container image).
• Roll out using controlled mechanisms (ALB deregistration + patching, Auto Scaling instance refresh, ECS redeploy).
• Preserve auditability through change records and standard tooling.

Avoid “papering over” high-risk findings (suppression without justification), widening network access to speed up work, or cycling instances without updating the underlying AMI/image, because these approaches either increase exposure or fail to remove the vulnerability.

• Blanket suppression is unsafe because it hides critical exploitable risk and undermines auditability.
• Open SSH to the world increases attack surface; use SSM Session Manager/controlled access instead.
• Recycle without fixing artifacts (terminating instances before updating AMI/image) redeploys the same vulnerable bits and can harm availability.

Question 6

Topic: Security and Compliance

A Trusted Advisor security check reports that a security group allows unrestricted access. You review the following AWS Config evaluation result.

Exhibit: AWS Config evaluation result

ConfigRule: INCOMING_SSH_DISABLED
ComplianceType: NON_COMPLIANT
ResourceType: AWS::EC2::SecurityGroup
ResourceId: sg-0a12bc345def67890
Annotation: "Inbound TCP 22 open to 0.0.0.0/0 (rule sgr-09f1a2b3c4d5e6f7)"

Which action should a CloudOps engineer take next to remediate this finding?

Options:

• A. Create a CloudWatch alarm for failed SSH login attempts

• B. Enable AWS CloudTrail management event logging

• C. Enable VPC Flow Logs for the security group’s VPC

• D. Remove the inbound TCP 22 rule open to 0.0.0.0/0

Best answer: D

Explanation: The Config evaluation shows the security group is NON_COMPLIANT because inbound TCP port 22 is open to the world (0.0.0.0/0). Remediation is to change the security group rule that allows unrestricted SSH so that port 22 is no longer publicly reachable.

This is a common Trusted Advisor security finding: unrestricted administrative access (SSH) from the internet. The exhibit’s Annotation line identifies the exact issue and the specific rule ID associated with it.

To remediate, update the security group to eliminate public SSH exposure:

• Locate security group sg-0a12bc345def67890
• Remove (or narrow) the inbound rule for TCP 22 that permits 0.0.0.0/0 (the exhibit references rule sgr-09f1a2b3c4d5e6f7)

Monitoring and logging can help detect misuse, but they do not fix the noncompliant configuration that Trusted Advisor/Config is flagging.

• Add logging instead enables visibility but does not close the public SSH path shown in the annotation.
• Alarm on auth failures is detective control; the SG remains publicly reachable.
• Enable CloudTrail improves auditability, but the security group stays NON_COMPLIANT until the ingress rule is changed.

Question 7

Topic: Security and Compliance

A company runs a containerized application on Amazon ECS with AWS Fargate. On startup, the application uses the AWS SDK to call secretsmanager:GetSecretValue to retrieve a database password from AWS Secrets Manager. The team must avoid storing long-term AWS access keys in the container.

Which change will allow the application to retrieve the secret securely?

Options:

• A. Create an IAM user with secretsmanager:GetSecretValue permission and store its access keys as container environment variables

• B. Attach an IAM policy that allows secretsmanager:GetSecretValue on the secret ARN to the ECS task execution role

• C. Attach an IAM policy that allows secretsmanager:GetSecretValue on the secret ARN to the ECS task role

• D. Attach an IAM policy that allows secretsmanager:GetSecretValue on the secret ARN to an EC2 instance profile used by the cluster instances

Best answer: C

Explanation: The discriminating factor is which IAM role supplies credentials to code running inside an ECS task. When the application itself calls AWS APIs with the AWS SDK, it uses the ECS task role credentials provided to the container. Grant secretsmanager:GetSecretValue to the task role for the specific secret ARN to enable secure retrieval without long-term keys.

ECS on Fargate provides temporary AWS credentials to the application through the task role. When your code (AWS SDK/CLI) calls Secrets Manager at runtime, the call is signed with the task role’s credentials, so the task role must allow secretsmanager:GetSecretValue (ideally scoped to the secret ARN and, if needed, the KMS key used to encrypt the secret).

The task execution role is separate and is used by ECS to perform platform actions such as pulling images and writing logs, and it is not the identity your application code uses for its own AWS API calls. Key takeaway: for in-app secret retrieval, permissions belong on the task role, not the execution role.

• Execution role confusion applies to ECS-managed actions, not AWS SDK calls made by your code.
• Static access keys violates the requirement and increases credential leakage risk.
• EC2 instance profile mismatch does not apply to Fargate tasks and would not be used by the container for credentials.

Question 8

Topic: Security and Compliance

An AWS account uses IAM Access Analyzer to monitor for unintended external access. Access Analyzer generates a finding that an Amazon S3 bucket is accessible by a different AWS account because of the bucket policy. Which action remediates the exposure?

Options:

• A. Rotate the access keys for IAM users in the account

• B. Enable VPC Flow Logs for the VPC that hosts the S3 bucket

• C. Edit the bucket policy to restrict or remove the external principal

• D. Enable AWS CloudTrail data events for the S3 bucket

Best answer: C

Explanation: IAM Access Analyzer reports unintended external access when a resource-based policy allows access by an external principal. For an S3 bucket, the exposure is created by the bucket policy. Remediation is to modify the bucket policy (or apply equivalent policy controls) to remove or constrain the external access.

IAM Access Analyzer evaluates resource-based policies to identify when a resource can be accessed from outside your account (for example, by another AWS account or the public). When the finding points to an S3 bucket, the root cause is the bucket’s resource policy (bucket policy, and in some cases related public-access settings). To remediate, you must change the policy that is granting access by removing the external principal or adding restrictive conditions (such as limiting to specific principals or organization boundaries). Logging services like CloudTrail can help you investigate access, but they do not prevent it.

Key takeaway: remediate Access Analyzer external access findings by tightening the resource policy that created the access path.

• Add logging only enables visibility but does not remove the external permission.
• Wrong log source VPC Flow Logs don’t apply to S3 bucket policy permissions.
• Credential hygiene rotating keys doesn’t change a bucket policy that grants external principals access.

Question 9

Topic: Security and Compliance

A security analyst reports that one EC2 instance in a production Auto Scaling group is making unexpected outbound connections and might be exfiltrating data. CloudTrail shows recent API calls to S3 using an IAM user access key that is normally used only by the application on this instance.

The operations team must take immediate incident response actions that (1) isolate the suspected instance to protect the rest of the environment, (2) rotate potentially compromised credentials, and (3) preserve evidence for later analysis.

Which THREE actions should the team take?

Options:

• A. Deactivate the exposed IAM user access key and create a new access key to replace it in the application

• B. Move the suspected instance to a quarantine security group that blocks all traffic except from the incident response subnet

• C. Stop the suspected instance immediately to prevent any further network activity

• D. Delete recent CloudWatch Logs log streams for the instance to prevent the attacker from covering tracks

• E. Create EBS snapshots of all volumes attached to the suspected instance and retain them for forensics

• F. Terminate the suspected instance so Auto Scaling replaces it with a clean instance

Correct answers: A, B and E

Explanation: Effective incident response prioritizes containment, credential rotation, and evidence preservation. Quarantining the instance limits blast radius without destroying artifacts. Capturing storage evidence with snapshots and rotating the identified compromised access key reduces continued unauthorized access while keeping data for investigation.

For an active compromise, first contain the suspected resource, then remove attacker access, and preserve evidence. Containment can be done by placing the instance into a quarantine security group (or otherwise restricting network paths) so the rest of the environment is protected without destroying artifacts. Evidence preservation typically includes taking EBS snapshots of all attached volumes so investigators can analyze file system state later. Because CloudTrail indicates a specific IAM user access key was used from the instance, that credential must be rotated (deactivate the old key and replace it with a new one for legitimate use) to cut off unauthorized API access.

Actions like stopping or terminating the instance, or deleting logs, can destroy or reduce the quality of evidence and are not preferred as initial steps unless explicitly required for safety.

• OK — Quarantine security group: Contains the incident fast while keeping the instance available for investigation.
• OK — EBS snapshots: Preserves disk evidence in a forensically useful point-in-time copy.
• OK — Rotate exposed access key: Cuts off unauthorized API use tied to the compromised credential.
• NO — Terminate instance: Destroys/changes evidence and can trigger replacement that complicates investigation.
• NO — Stop instance: Can lose volatile evidence and is not as controlled as network isolation for containment.
• NO — Delete logs: Destroys evidence and breaks auditability during an incident.

Question 10

Topic: Security and Compliance

A team enabled HTTPS on an Application Load Balancer (ALB) in ap-southeast-2 for api.example.com. The change was deployed by AWS CloudFormation, but the stack update failed and port 443 is not listening.

Exhibit: CloudFormation event (most recent failure)

Resource: ApiAlbListener443
Status: UPDATE_FAILED
Status reason:
  ElasticLoadBalancingV2: CreateListener failed
  InvalidConfigurationRequest: Certificate
  'arn:aws:acm:us-east-1:111122223333:certificate/abcd...'
  is not valid

The team must keep using ACM for TLS and wants the smallest change that restores HTTPS.

Which action will fix the root cause?

Options:

• A. Request the ACM certificate in ap-southeast-2 and update the listener ARN

• B. Install the certificate on the target instances and use HTTP to targets

• C. Add CloudFront in front and attach the us-east-1 certificate there

• D. Move the ALB to us-east-1 to match the certificate Region

Best answer: A

Explanation: The stack failed because the HTTPS listener references an ACM certificate ARN from a different Region than the ALB. For an ALB, the certificate must be issued or imported into ACM in the same Region as the load balancer. Creating the certificate in ap-southeast-2 and updating the listener to use that ARN restores HTTPS with minimal change.

Symptom: CloudFormation cannot create the ALB HTTPS listener and reports the certificate ARN from us-east-1 is “not valid,” leaving port 443 unavailable.

Root cause: ACM certificates are regional for use with an ALB. The listener is referencing a certificate that exists in a different Region than the ALB (ap-southeast-2).

Fix:

• Request (or import) an ACM public certificate for api.example.com in ap-southeast-2.
• Validate it (DNS/email) until the status is Issued.
• Update the ALB listener to reference the new regional certificate ARN.

Key takeaway: use a certificate in the same Region as the ALB (CloudFront is the common exception that uses us-east-1).

• Regional mismatch moving the ALB Regions is a large, unnecessary change for a certificate attachment issue.
• TLS on instances does not address the failing ALB listener creation and changes the termination point/operations model.
• Add CloudFront is an architecture change; it’s not required to restore ALB HTTPS.

Continue with full practice

Use the AWS SOA-C03 Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try AWS SOA-C03 on Web View AWS SOA-C03 Practice Test

Related focused pages

• Free AWS SOA-C03 Full-Length Practice Exam
• Monitoring and Optimization
• Reliability and Business Continuity
• Deployment, Provisioning, and Automation
• Networking and Content Delivery

Free review resource

Read the AWS SOA-C03 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.