AWS 3: Infrastructure Security: 160 practice questions

12 of the 160 3: Infrastructure Security questions in the Certsqill AWS bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS? Take the free 5-min readiness check →

1. Use AWS Shield Advanced for DDoS protection and AWS WAF: Which TWO design choices best satisfy the requirement

Select two. More than one option is correct — every correct one is ticked below.

1. Use AWS Shield Advanced for DDoS protection and AWS WAF web ACLs for HTTP request inspection. ✓

   Shield Advanced addresses DDoS protection while WAF evaluates HTTP requests against managed, custom, and rate-based rules.
2. Use Amazon GuardDuty Runtime Monitoring as the primary control for CloudFront request attacks.

   Runtime Monitoring covers supported workloads such as EC2, ECS Fargate, and EKS, not CloudFront HTTP request filtering.
3. Use security groups on the Application Load Balancer to block SQL injection and cross-site scripting.

   Security groups filter network flows and cannot inspect application request content for OWASP-style attacks.
4. Use CloudFront geolocation restrictions as the sole defense against volumetric DDoS.

   Geolocation restrictions limit viewer geography but do not provide dedicated DDoS mitigation or application inspection.
5. Use AWS Firewall Manager policies to apply WAF protections across accounts and newly eligible resources. ✓

   Firewall Manager centrally applies and monitors WAF policies across Organizations accounts and automatically covers matching new resources.

Combine Shield Advanced and WAF for distinct DDoS and HTTP controls, then use Firewall Manager for organization-wide automatic policy coverage.

2. Use OAC with always-sign requests: Which configuration should the security engineer implement?

1. Use an S3 website endpoint with OAC, always-sign requests, and a bucket policy restricted to the distribution.

   An S3 website endpoint is configured as a custom origin and does not support CloudFront OAC.
2. Use an OAI and allow its canonical user to read the bucket.

   OAI is a supported legacy mechanism, but it does not provide the required SSE-KMS support without additional workarounds.
3. Use OAC with always-sign requests and a distribution-scoped bucket policy. ✓

   OAC supports regular S3 origins with SSE-KMS. Always-sign requests ensure HTTPS to S3, and the bucket policy can authorize only the CloudFront service principal for this distribution.
4. Make the bucket public and require HTTPS for CloudFront viewers.

   Viewer HTTPS does not prevent direct public S3 access or authorize the origin connection.

Use CloudFront OAC with always-sign requests and a bucket policy restricted to the intended distribution.

3. Combine an IP set rule: Which rule design best meets these requirements?

1. Combine an IP set rule, AWS WAF intelligent threat mitigation, and a rate-based rule using an appropriate client fingerprint. ✓

   The IP set blocks known ranges, intelligent mitigation identifies automation, and client-fingerprint aggregation limits abuse beyond simple IP identity.
2. Combine an IP set rule, AWS WAF intelligent threat mitigation, and a rate-based rule using forwarded IP aggregation.

   Forwarded-IP aggregation remains vulnerable to shared or manipulated addresses and does not meet the stable-client-characteristic requirement.
3. Combine an IP set rule, AWS WAF managed rules, and a rate-based rule aggregated by a chosen forwarded-IP address.

   Managed rules address common threats, but forwarded-IP aggregation cannot distinguish legitimate shared NAT users from abusive clients reliably.
4. Combine an IP set rule, a request-labeling rule based on headers, and a rate-based rule with a suitable aggregation key.

   Header labels can classify requests, but this design does not provide the requested stable client characteristic for automated-abuse detection.

Use an IP set, intelligent threat mitigation, and client-fingerprint-based rate limiting to address known ranges, automation, and shared NAT constraints.

4. Use OAC, always-sign requests, WAF,: Which design best satisfies these requirements?

1. Attach WAF to the S3 bucket and use an access-point policy.

   AWS WAF does not attach directly to S3 buckets, so viewer requests would not receive the required web filtering.
2. Use OAI, WAF, and a bucket policy granting the identity access.

   OAI does not meet the stated SSE-KMS and future-upload requirements as directly as OAC.
3. Use OAC with unsigned requests, WAF, and a public bucket policy.

   A public bucket violates private-origin access, and unsigned requests do not satisfy the required always-sign origin configuration.
4. Use OAC, always-sign requests, WAF, and a distribution-scoped bucket policy. ✓

   This combination provides private SSE-KMS-compatible S3 access, supports signed CloudFront-to-S3 requests including future uploads, and applies WAF inspection and rate-based controls to viewer requests.

Use OAC with always-sign requests, a WAF web ACL on CloudFront, and a distribution-scoped S3 policy.

5. Give the Fargate task role only the required: Which TWO actions should the security architect recommend?

Select two. More than one option is correct — every correct one is ticked below.

1. Give the Fargate task role only the required customer-bucket actions. ✓

   A least-privilege Fargate task role authorizes application access without granting that permission to the ECS Anywhere service.
2. Grant both services' task roles read access to the customer bucket.

   Task roles are supported for application permissions, but granting both roles access violates the requirement that ECS Anywhere must not access the bucket.
3. Give the ECS Anywhere task role customer-bucket read access for operational consistency.

   A separate task role is supported, but granting it customer-bucket access directly violates the isolation requirement.
4. Bake customer-bucket access keys into the common container image.

   Embedding static credentials in an image violates the stated requirement and exposes the credentials to every workload using that image.
5. Use service-specific execution roles for ECR pulls and CloudWatch Logs. ✓

   Execution roles provide ECS infrastructure permissions for image retrieval and log delivery while excluding customer-data permissions from application credentials.

Use a least-privilege Fargate task role and separate execution roles for ECR and CloudWatch Logs.

6. Grant SecurityOpsRole narrowly scoped ssmmessages: Which design should the team implement?

1. Grant SecurityOpsRole narrowly scoped ssmmessages and Session Manager start-session permissions for approved instance tags. ✓

   Session Manager authorization requires operator IAM permissions, while the instance profile already supplies node-side Systems Manager access.
2. Add AmazonSSMManagedInstanceCore permissions to SecurityOpsRole and remove the instance profile from the target instance.

   The instance profile, not the operator, needs managed-node permissions; removing it can break the existing Systems Manager connection.
3. Attach an ECS task role to the EC2 instance and authorize SecurityOpsRole to invoke ECS execute-command.

   ECS task roles and execute-command apply to ECS tasks, not standalone EC2 managed nodes.
4. Open inbound SSH from the security account and attach an administrator policy to SecurityOpsRole.

   SSH introduces keys and network exposure, while administrator permissions violate the stated least-privilege requirement.

The denied request indicates missing operator-side Session Manager permissions, not missing instance-profile permissions on the managed node.

7. Designate an Amazon Inspector delegated administrator: Which solution best meets these requirements?

1. Designate an Amazon Inspector delegated administrator, activate organization-wide scanning, and enable GuardDuty Runtime Monitoring for EC2. ✓

   Inspector continuously scans EC2, ECR, and Lambda vulnerabilities centrally, while GuardDuty detects suspicious EC2 runtime behavior.
2. Designate a GuardDuty administrator, enable Runtime Monitoring, and use it as the vulnerability scanner for ECR and Lambda.

   GuardDuty Runtime Monitoring detects threats in supported runtimes but does not replace Inspector vulnerability scanning for ECR and Lambda.
3. Enable Inspector only for ECR images and install the GuardDuty agent on Lambda functions for continuous vulnerability findings.

   Inspector also supports EC2 and Lambda, while GuardDuty Runtime Monitoring does not provide Lambda package vulnerability findings.
4. Schedule Amazon Inspector scans monthly and use AWS Config rules to identify newly disclosed package vulnerabilities.

   Inspector automatically rescans relevant changes and CVEs, while monthly scheduling and Config rules do not provide equivalent coverage.

Amazon Inspector supplies centralized continuous vulnerability management, while GuardDuty Runtime Monitoring supplies separate EC2 behavioral detection.

8. Use Systems Manager patch policies with approved baselines: Which approach is best?

1. Use Systems Manager patch policies with approved baselines, staggered maintenance windows, and post-patch validation commands. ✓

   Patch policies automate multi-account coverage, baselines control approvals, and maintenance windows plus validation reduce operational risk.
2. Use Patch Manager scan operations weekly and let operators manually install every reported missing patch afterward.

   Scan operations report missing patches but do not install them, creating delayed remediation and unnecessary manual effort.
3. Use Amazon Inspector findings to directly install operating-system patches during each vulnerability rescan.

   Inspector identifies vulnerabilities and recommendations but does not replace Patch Manager for controlled patch deployment.
4. Use one immediate Run Command operation against all instances, followed by a monthly compliance review.

   A single fleet-wide operation increases outage risk and does not provide the recurring controlled compliance workflow required.

Patch policies and approved baselines automate compliant deployment, while staged windows and validation provide safer remediation evidence.

9. Configure Session Manager preferences to stream session: Which TWO actions should be implemented?

Select two. More than one option is correct — every correct one is ticked below.

1. Use EC2 Instance Connect with public addresses and record commands through local partner terminal logging.

   Public connectivity conflicts with the no-inbound-access requirement, and local logs lack centralized AWS-controlled session evidence.
2. Configure Session Manager preferences to stream session data to a centralized CloudWatch Logs log group. ✓

   Session Manager can log session activity and command output to CloudWatch Logs for centralized operational evidence.
3. Use Session Manager with federated IAM policies conditioned on approved resource tags and session-document permissions. ✓

   Session Manager supports cross-platform access without inbound ports and IAM policies can restrict users, nodes, and session capabilities.
4. Permit partner source addresses through security groups and require short-lived SSH keys for each session.

   This still exposes SSH and does not provide the required Session Manager command-session recording workflow.
5. Grant federated users administrator access and allow Systems Manager port forwarding to every managed node.

   Port forwarding is supported, but unrestricted administrator access and fleet-wide targeting violate least privilege and node restrictions.

Federated IAM authorization plus Session Manager logging provides controlled cross-platform access without inbound administrative ports or persistent keys.

10. Run Amazon Inspector ECR scanning as the promotion gate: Which design best satisfies the requirements?

1. Run Amazon Inspector ECR scanning as the promotion gate and enable GuardDuty Runtime Monitoring separately. ✓

   Inspector scans ECR images for vulnerabilities that can drive a promotion decision. GuardDuty Runtime Monitoring separately detects behavior in deployed supported workloads.
2. Enable GuardDuty Runtime Monitoring and use its findings to approve or reject images before deployment.

   Runtime findings occur after deployment and do not provide a pre-publication image vulnerability gate.
3. Run Amazon Inspector ECR scanning for continuous findings but use only manual review to decide whether images are promoted.

   Inspector supplies image findings, but manual review alone does not enforce the required automated severity-based promotion block.
4. Scan ECS worker nodes with Amazon Inspector and use host findings to approve or reject images.

   Worker-node findings do not represent the packages and layers in each image awaiting promotion.

Use Inspector ECR scanning for the image gate and GuardDuty Runtime Monitoring for deployed-workload behavior.

11. Use a versioned Bedrock Guardrail for PII: Which design provides the strongest guardrails?

1. Use Bedrock Guardrails only for toxicity, and trust retrieved policy documents to constrain tool invocation.

   Toxicity filtering does not address PII, prompt attacks, denied topics, grounding, or tool authorization.
2. Use a versioned Bedrock Guardrail for PII, prompt attacks, denied topics, and grounding, plus separate tool-call validation. ✓

   Bedrock Guardrails provide the content, sensitive-information, denied-topic, prompt-attack, and contextual-grounding controls. Application logic must independently validate and authorize tool calls.
3. Use IAM policies as the sole control for PII masking, prohibited topics, prompt attacks, and model responses.

   IAM authorizes AWS actions but does not inspect or redact natural-language inputs and outputs.
4. Place support cases in the system prompt, disable retrieval, and rely on IAM for tool authorization.

   This removes required policy retrieval and does not provide scalable PII masking, grounding checks, or prompt-attack filtering.

Apply Bedrock Guardrails to content, privacy, attacks, topics, and grounding; independently constrain tools.

12. Add an inbound ephemeral-port allow rule to the subnet: Which change is best?

1. Add an inbound TCP 443 allow rule so response packets can return from the services.

   Responses target the client ephemeral port rather than necessarily destination port 443.
2. Add an inbound ephemeral-port allow rule to the subnet network ACL before matching denies. ✓

   Network ACLs are stateless, so return packets to the client ephemeral ports require an inbound allow rule placed before any matching deny.
3. Deploy Network Firewall endpoints but leave route tables and network ACL rules unchanged.

   Firewall endpoints inspect only traffic explicitly routed through them and cannot repair the existing ACL denial without route and ACL changes.
4. Remove the security group outbound HTTPS rule and let the network ACL provide connection state.

   Removing the security-group rule blocks the outbound connection, and network ACLs do not provide stateful tracking.

Allow return traffic to client ephemeral ports in the stateless network ACL.

Other AWS domains

• 4: Identity and Access Management — 178 questions →
• 5: Data Protection — 160 questions →
• 1: Detection — 142 questions →
• 2: Incident Response — 125 questions →
• 6: Security Foundations and Governance — 125 questions →
• All 890 AWS questions →
• AWS certification: requirements, cost and exam format →