CCNA Design Secure Questions

Why this answer

How to eliminate wrong answers

Option B is wrong because attaching the allow policy to the vendor account's IAM user does not grant the user permission to call sts:AssumeRole; the trust policy on the role must explicitly allow the external account (or the user) to assume the role, and the policy attached to the user only controls what the user can do after assuming the role, not the assumption itself. Option C is wrong because GetCallerIdentity only returns details about the caller's identity and does not grant any permissions to read data; it cannot substitute for assuming a role to access resources. Option D is wrong because enabling MFA on the vendor's IAM user and requiring MFA in the role's permissions policy does not address the missing trust policy; the role's trust policy must first allow the vendor to assume the role, and MFA conditions are additional constraints, not a fix for the fundamental authorization failure.

Why this answer

How to eliminate wrong answers

Option A is wrong because a VPC endpoint policy controls access to API Gateway from within a VPC, not authentication for internet-based clients using OIDC tokens. Option B is wrong because IAM authorization is designed for AWS-authenticated principals (e.g., IAM users, roles) and does not validate tokens from external OpenID Connect providers; it uses AWS Signature Version 4, not OIDC tokens. Option C is wrong because API keys only provide simple rate limiting and usage plans, not authentication or authorization; they do not validate the identity of the caller or support OIDC token verification.

Why this answer

How to eliminate wrong answers

Option A is wrong because storing a KMS-encrypted password in a Lambda environment variable does not support automatic rotation; you would have to manually update the environment variable and redeploy the function. Option B is wrong because an encrypted object in Amazon S3 is a static storage mechanism with no built-in rotation capability, and accessing it requires managing S3 permissions and decryption logic manually. Option C is wrong because AWS Systems Manager Parameter Store SecureString without automation can store a secure password but lacks native rotation scheduling; you would need to build a custom rotation solution, whereas Secrets Manager provides this out of the box.

Why this answer

How to eliminate wrong answers

Option B is wrong because AWS Shield Advanced provides DDoS protection and cost mitigation, but it does not include application-layer rule evaluation for OWASP Top 10 threats; it is not a replacement for WAF. Option C is wrong because security groups operate at the network layer (Layer 3/4) and cannot inspect HTTP request bodies or application-layer payloads to block patterns like SQL injection or XSS. Option D is wrong because AWS Security Hub is a security posture management service that aggregates findings and does not have the capability to automatically block requests in real-time; it lacks inline traffic inspection and enforcement actions.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because enabling S3 static website hosting does not block direct object URL access; the S3 website endpoint is separate from the REST API endpoint, but the bucket policy still controls access, and objects remain accessible via direct S3 URLs unless the policy is restricted. Option C is wrong because a WAF rule applied to the S3 bucket domain is ineffective—WAF is a CloudFront feature and cannot be attached directly to an S3 bucket endpoint; rate-limiting would not prevent direct access, only reduce its frequency. Option D is wrong because enabling object versioning does not restrict access; it only preserves previous object versions, and without a restrictive bucket policy, all versions remain publicly accessible via direct S3 URLs.

Why this answer

How to eliminate wrong answers

Option A is wrong because API keys only provide simple identification and rate limiting, not authentication or authorization; they do not validate token signatures, claims, or issuer trust. Option C is wrong because IAM authorization is designed for AWS internal identities (IAM users/roles) and requires AWS Signature V4 signing, which is not compatible with external OIDC tokens or internet-based clients without custom signing logic. Option D is wrong because a VPC endpoint policy controls access to API Gateway via VPC endpoints, not authentication; it cannot validate OIDC tokens or handle client identity from the public internet.

Why this answer

How to eliminate wrong answers

Option A is wrong because using a wildcard resource (arn:aws:kms:region:account-id:key/*) grants kms:Decrypt on all CMKs in the account, violating least privilege and potentially exposing other encrypted resources. Option C is wrong because SSE-C keys are used for Amazon S3 server-side encryption, not for Secrets Manager; Secrets Manager relies on KMS for envelope encryption, and changing to SSE-C would not integrate with Secrets Manager's native KMS-based encryption. Option D is wrong because enabling KMS key rotation for the old CMK does not change the key ARN; rotation creates new backing key material but retains the same key ID and ARN, so the old CMK ARN still does not authorize decryption of a secret encrypted with a different CMK.

Why this answer

How to eliminate wrong answers

Option B is wrong because enabling key rotation does not eliminate the need for kms:CreateGrant; key rotation changes the underlying key material but does not affect grant-based authorization requirements. Option C is wrong because adding kms:DescribeKey does not resolve the missing kms:CreateGrant, and removing kms:Decrypt would break the decryption operation entirely. Option D is wrong because kms:ScheduleKeyDeletion is used to schedule key deletion, which would make the key unusable and is unrelated to grant creation or decryption authorization.

Why this answer

How to eliminate wrong answers

Option B is wrong because requiring MFA does not restrict requests to a specific VPC Endpoint; it only adds an authentication factor, which does not enforce the network-level restriction. Option C is wrong because Block Public Access and removing public policies prevent public access but do not restrict requests to a specific VPC Endpoint; private traffic from other sources (e.g., the internet via a NAT gateway) would still be allowed. Option D is wrong because an IAM policy attached to the workload role controls what the role can do but does not restrict the network path; the workload could still send requests from any network interface, not just the specified VPC Endpoint.

Why this answer

How to eliminate wrong answers

Option A is wrong because increasing volume size does not affect the lazy hydration process; it only adds more uninitialized blocks that would also suffer from the same slow-read penalty. Option C is wrong because moving database files to Amazon EFS after restore does not solve the initial slow-read problem; EFS has its own latency characteristics and does not eliminate the need to hydrate the EBS volume. Option D is wrong because magnetic standard volumes (st1/sc1 or previous standard) are slower and still require lazy hydration from snapshots; they do not avoid the hydration delay and would actually perform worse than gp3 or io2 volumes.

Why this answer

How to eliminate wrong answers

Option B is wrong because S3 website hosting only redirects HTTP to HTTPS for web traffic, but it does not enforce HTTPS for API requests (e.g., via SDK or CLI), and default encryption only encrypts objects at rest, not in transit. Option C is wrong because it only denies `s3:GetObject` when `aws:SecureTransport` is false, leaving other actions like `s3:PutObject` unencrypted in transit, and enabling default encryption does not enforce that uploads specify encryption headers—it only applies if the request lacks encryption headers, which can be overridden. Option D is wrong because restricting access to IAM principals does not enforce HTTPS or encryption at rest; it only controls authorization, and requiring clients to configure HTTPS in their applications relies on application code compliance, which the question explicitly wants to avoid.

Why this answer

How to eliminate wrong answers

Option B is wrong because attaching AmazonS3FullAccess to the instance profile role in Account A does not enable cross-account access; S3 bucket policies in Account B must explicitly grant permissions to the IAM role in Account A, and using long-lived keys from the instance profile still violates the requirement to avoid long-lived access keys. Option C is wrong because Service Control Policies (SCPs) are used to restrict permissions within an AWS Organization and cannot grant cross-account access to resources in another account; they only deny or allow actions within the account where the SCP is applied. Option D is wrong because enabling S3 versioning on the bucket does not affect cross-account authentication or authorization; versioning is a data management feature that tracks object versions and has no impact on IAM permissions or trust relationships.

Why this answer

How to eliminate wrong answers

Option B is wrong because an internet gateway attached to a private subnet does not provide direct connectivity to instances; it only enables outbound internet access via a NAT device, and does not allow inbound administrative connections without opening ports. Option C is wrong because assigning a public Elastic IP address to each instance would expose them to the internet, requiring SSH or RDP ports to be open, which violates the requirement to not open those ports. Option D is wrong because a bastion host with SSH open to 0.0.0.0/0 exposes the bastion to the entire internet, creating a security risk and still requires opening SSH (port 22) to the internet, which directly contradicts the requirement.

Why this answer

How to eliminate wrong answers

Option B is wrong because sts:AssumeRole is used for cross-account access or for roles assumed by IAM users or AWS services, not for web identity federation with an OIDC provider. Option C is wrong because sts:GetCallerIdentity simply returns details about the IAM user or role whose credentials are used to make the call; it does not initiate any federation or credential issuance. Option D is wrong because sts:TagSession is used to apply tags to an already-assumed role session, not to perform the initial federation or role assumption.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because NAT gateways incur cost and route traffic through the internet, violating the 'without exposing the instances to NAT gateways due to cost' requirement; additionally, security groups on instances alone do not restrict traffic to AWS service endpoints. Option C is wrong because public subnets expose instances to inbound internet traffic, contradicting the 'no inbound internet' requirement, and having no security group rules is a severe security violation. Option D is wrong because enabling public access to Secrets Manager via the default service endpoint exposes it to the internet, and S3 bucket policies based on private IP addresses are unreliable since private IPs can change and do not authenticate the requester; Secrets Manager requires interface endpoints or private connectivity, not public endpoints.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because it creates an IAM user with long-lived access keys, which violates the security requirement for temporary credentials and introduces a risk of key exposure. Option C is wrong because IAM groups are used to manage permissions for IAM users, not for external CI/CD systems; the pipeline's principal cannot be added to an IAM group directly without an IAM user, and this still relies on long-lived credentials. Option D is wrong because encrypting access keys with KMS does not eliminate the use of long-lived access keys; the pipeline would still need to decrypt and use them, which does not meet the requirement for temporary credentials.

Why this answer

How to eliminate wrong answers

Option A is wrong because server access logging records requests to the bucket but does not enforce any access restrictions; it only provides audit logs. Option B is wrong because S3 Transfer Acceleration speeds up uploads over long distances using edge locations but has no effect on access control or public accessibility. Option C is wrong because an IAM policy that denies s3:GetObject to anonymous users only applies to IAM principals; anonymous users are not IAM principals, so such a policy would not block access granted by a bucket policy that explicitly allows anonymous access.

Why this answer

How to eliminate wrong answers

Option B is wrong because allowing all outbound traffic to 0.0.0.0/0 on TCP 443 would not help, as the private subnets have no route to the internet (no NAT Gateway or Internet Gateway), so traffic would still be dropped. Option C is wrong because adding an Internet Gateway and routing 0.0.0.0/0 to it would require the private subnet instances to have public IPs or a NAT device, and it would break the security posture by exposing them to the internet. Option D is wrong because network ACLs are stateless and must allow ephemeral ports for return traffic, but the issue is not about NACLs; it is about the lack of a route to S3, and switching to security groups does not solve the routing problem.

Why this answer

How to eliminate wrong answers

Option A is wrong because assigning a public Elastic IP address to each instance would expose them directly to the internet, requiring open SSH or RDP ports, which violates the requirement to avoid opening those ports. Option B is wrong because a bastion host with SSH open to 0.0.0.0/0 exposes the bastion to the entire internet, creating a security risk and still requires opening SSH ports, which contradicts the requirement. Option C is wrong because an internet gateway attached to a private subnet does not provide connectivity; internet gateways must be attached to VPCs and associated with route tables for public subnets, and private subnets cannot directly use an internet gateway without a NAT device, which still does not solve the administrative access need without open ports.

Why this order

Why this answer

How to eliminate wrong answers

Option A is wrong because disabling S3 Block Public Access and using an ACL that grants READ and WRITE to the bucket owner only does not prevent public access — Block Public Access is the primary safeguard, and ACLs are legacy and do not enforce user-specific prefix restrictions or HTTPS. Option C is wrong because using bucket website hosting with public GET requests violates the requirement to prevent any public access and makes presigned URLs unnecessary, but it exposes objects to the internet. Option D is wrong because ACLs granting ObjectOwner full control do not enforce user-specific prefix restrictions or HTTPS, and relying on longer presigned URL expirations does not fix the 403 error caused by missing policy conditions or incorrect principal restrictions.

Why this order

Why this answer

How to eliminate wrong answers

Option B is wrong because storing the database password in user data leaves it in plaintext on the instance metadata, which can be accessed by any process or user with instance metadata access, and it does not use short-lived credentials. Option C is wrong because a security group rule only controls network access at the transport layer; it does not provide authentication credentials or eliminate the need to store them on the instance. Option D is wrong because embedding the database password in the AMI hardcodes the credential into the image, which persists across instances and cannot be rotated without rebuilding the AMI, violating the requirement for short-lived credentials.

Why this answer

How to eliminate wrong answers

Option A is wrong because storing the database password in user data leaves it in plaintext on the instance metadata, which is accessible to any process or user with access to the instance, violating the requirement to not store credentials on EC2. Option C is wrong because a security group rule only controls network access at the transport layer; it does not address authentication or credential storage, and the application would still need a static password to connect. Option D is wrong because embedding the database password in the AMI hardcodes the credential into the image, which persists across instances and violates the principle of not storing credentials on the instance, plus it cannot provide short-lived credentials.

Why this answer

How to eliminate wrong answers

Option A is wrong because storing the database password in user data is insecure — user data is accessible from within the instance and can be retrieved by any process or user with access, and it does not provide short-lived credentials. Option B is wrong because embedding the database password in an AMI creates a static credential that persists across instances launched from that AMI, violating the requirement for short-lived credentials and increasing the risk of credential exposure. Option D is wrong because a security group rule controls network access at the transport layer but does not address authentication or credential management; it cannot provide short-lived credentials or eliminate the need to store passwords on the instance.

Why this answer

How to eliminate wrong answers

Option A is wrong because granting `iam:PutRolePermissionsBoundary` would allow the operator to reapply a different boundary, which directly enables the privilege escalation they are trying to prevent. Option C is wrong because relying solely on the role’s trust policy controls who can assume the role, but does not restrict the operator’s ability to modify the permission boundary via IAM API calls (e.g., from their own user account). Option D is wrong because attaching a more permissive permission boundary would expand the role’s effective permissions, defeating the purpose of using boundaries to limit privilege escalation.

Why this answer

How to eliminate wrong answers

Option B is wrong because `aws:SourceIp` condition key is not effective for requests made through a VPC Endpoint; the source IP is replaced by the endpoint's private IP, making the condition unreliable for restricting traffic to a specific endpoint. Option C is wrong because requiring TLS (`aws:SecureTransport`) only ensures encryption in transit, not that the API call comes through a specific VPC Endpoint; it does not restrict the network path. Option D is wrong because `kms:ViaService` restricts KMS key usage to a specific AWS service (Secrets Manager), but it does not control which network path (e.g., VPC Endpoint) the Secrets Manager API call uses; it addresses KMS authorization, not network-level restriction.

Why this answer

How to eliminate wrong answers

Option A is wrong because SCPs apply at the AWS account or organizational unit level, not at the individual IAM role level, and they cannot enforce a per-role ceiling within an account; they cap permissions for all principals in the account but do not provide granular control over each role's maximum permissions. Option C is wrong because KMS key policies control access to KMS keys, not IAM role permissions, and they are unrelated to setting a ceiling on what actions a role can perform via IAM policies. Option D is wrong because requiring MFA for role creation requests is an authentication control that does not limit the permissions granted to the role once it is created; it prevents unauthorized creation but does not enforce a permissions ceiling.

Why this answer

How to eliminate wrong answers

Option B is wrong because an IAM policy that denies s3:GetObject to anonymous users is not effective; anonymous users are not IAM principals, so IAM policies do not apply to them. Option C is wrong because server access logging records requests but does not enforce access controls or prevent public access. Option D is wrong because S3 Transfer Acceleration speeds up uploads over long distances but has no effect on access permissions or public accessibility.

Why this answer

How to eliminate wrong answers

Option A is wrong because S3 object ACLs cannot bypass KMS authorization; ACLs control access to the object itself, not the encryption key, and removing SSE-KMS would violate security requirements. Option B is wrong because copying objects to a new bucket in the partner account does not resolve the underlying KMS authorization issue; the partner still needs access to the CMK to decrypt the objects. Option C is wrong because switching to SSE-S3 would remove the use of the customer-managed key, which may be a compliance or security requirement, and does not address the need for cross-account access with a CMK.

Why this answer

How to eliminate wrong answers

Option A is wrong because it allows the entire Company B account (root principal) to assume the role without any External ID condition, which violates the security requirement and leaves the role open to confused-deputy attacks. Option C is wrong because `iam:PassRole` is used to pass a role to an AWS service, not to assume a role; the correct action for assuming a role is `sts:AssumeRole`, and the condition should be on the trust policy, not on a permissions policy. Option D is wrong because an IAM permissions policy attached to RoleInA controls what the role can do after it is assumed, but it does not control who can assume the role; the trust policy is the only place to define the trusted principals and conditions for assuming the role.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because AWS Systems Manager Parameter Store with a standard String parameter does not support automatic rotation of secrets; it is intended for plaintext or encrypted configuration data, not for managing database credentials with lifecycle rotation. Option C is wrong because Amazon Cognito user pools are designed for user authentication and identity management, not for storing or rotating application database passwords. Option D is wrong because AWS KMS customer managed keys are used for encryption and decryption operations, not for storing secrets or managing their rotation; they can encrypt secrets but do not provide rotation or retrieval of the secret value itself.

Why this answer

How to eliminate wrong answers

Option A is wrong because security groups act as a stateful virtual firewall at the instance level, filtering traffic based on IP addresses, ports, and protocols; they cannot inspect application-layer payloads to detect SQL injection or XSS patterns. Option C is wrong because network ACLs are stateless and operate at the subnet level, only filtering traffic based on IP, port, and protocol rules, with no capability to parse HTTP request bodies or headers for malicious content. Option D is wrong because AWS Shield Advanced provides DDoS protection at the network and transport layers, not application-layer attack mitigation for SQL injection or XSS; it does not include a web application firewall.

Why this answer

How to eliminate wrong answers

Option A is wrong because S3 lifecycle expiration only automates deletion after a set period but does not prevent overwrites or deletions during that period; objects can still be deleted manually or overwritten before expiration. Option B is wrong because S3 versioning alone preserves previous versions but does not prevent deletion of the current version or overwrites; it only retains old versions, not enforce immutability. Option C is wrong because S3 server access logging records access requests to the bucket but does not provide any data protection or prevent modification or deletion of the audit logs themselves.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because tagging encrypted volumes after creation is a detective or corrective control, not a preventive one; it does not stop the creation of unencrypted volumes. Option C is wrong because VPC Flow Logs capture network traffic metadata and have no ability to enforce encryption policies on EBS volumes. Option D is wrong because running a daily Lambda function to encrypt unencrypted volumes is a reactive/corrective control that only fixes volumes after they have been created, leaving a window of non-compliance.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because adding kms:Decrypt to the identity policy in account B alone is insufficient; the CMK key policy in account A must also grant access to the account B role, as KMS key policies act as a separate authorization layer. Option C is wrong because disabling SSE-KMS and switching to SSE-S3 would change the encryption method and potentially violate security requirements, but it would technically fix the KMS permission issue; however, it is not the most likely fix as it alters the encryption configuration rather than addressing the permission gap. Option D is wrong because a permissions boundary on the account B role cannot override the CMK key policy in account A; the key policy is the ultimate authority for KMS key access, and a boundary only limits the role's maximum permissions within its own account.

Why this answer

Why this answer

Why the other options are wrong

Why this answer

How to eliminate wrong answers

Option B is wrong because server access logging only records requests made to the bucket; it does not enforce any access restrictions. Option C is wrong because an IAM policy that denies s3:GetObject to anonymous users can be overridden by a later bucket policy that grants public access, as IAM and bucket policies are evaluated together and a bucket policy can explicitly allow what an IAM policy denies. Option D is wrong because S3 Transfer Acceleration is a performance feature that speeds up uploads over long distances; it has no effect on access control or public accessibility.

Why this answer

How to eliminate wrong answers

Option A is wrong because S3 Transfer Acceleration is a performance feature that speeds up uploads over long distances using edge locations; it does not control access permissions or prevent public access. Option B is wrong because an IAM policy that denies s3:GetObject to anonymous users only applies to IAM principals, not to anonymous requests; anonymous users are not IAM entities, so this policy would not block public access granted by a bucket policy. Option D is wrong because server access logging records requests to the bucket for auditing purposes but does not enforce any access restrictions or prevent public access.

Why this answer

How to eliminate wrong answers

Option A is wrong because leaving the bucket public would allow anyone with the S3 object URL to access the files directly, violating the requirement that direct requests must fail. Option B is wrong because an S3 access point with a public policy would still allow direct public access to the objects, bypassing CloudFront. Option D is wrong because S3 object ACLs cannot restrict access based on the requester being behind CloudFront; they only grant permissions to specific AWS accounts or canonical users, not to CloudFront distributions.

Why this answer

Why the other options are wrong

Why this answer

How to eliminate wrong answers

Option B is wrong because a gateway VPC endpoint for S3 only provides private connectivity to S3, not to STS; STS is a different service and cannot be reached through an S3 endpoint. Option C is wrong because opening an inbound rule in the instances’ security group for outbound HTTPS to the internet CIDR block does not provide a route to the internet; the instances are in private subnets with no NAT gateway or internet gateway, so outbound traffic to the internet is blocked regardless of security group rules. Option D is wrong because attaching an Internet Gateway to the private subnet route table would make the subnet public, violating the requirement to keep instances private; it would also expose the instances to inbound internet traffic.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because identity policies (like IAM role policies) do not override key policies; KMS requires that both the key policy and the identity policy grant the permission, and if the key policy denies or omits the principal, the request fails regardless of the identity policy. Option C is wrong because enabling default encryption on SQS does not eliminate the need for KMS permissions; it would still require the consumer to have kms:Decrypt on the default KMS key, and the consumer's current issue is with a customer-managed CMK, not the default key. Option D is wrong because SQS messages are not stored in S3; SQS is a separate service, and an S3 bucket policy has no effect on KMS permissions for SQS message decryption.

Why this answer

How to eliminate wrong answers

Option B is wrong because `aws:username` refers to the IAM user name, not the MFA status; requiring a specific username does not enforce MFA and can be bypassed if that user does not use MFA. Option C is wrong because `sts:ExternalId` is used to prevent the confused deputy problem in cross-account access, not to enforce MFA. Option D is wrong because `aws:SecureTransport` only ensures the session uses HTTPS/TLS, which is already required for AWS API calls, and does not verify MFA usage.

Why this answer

How to eliminate wrong answers

Option B is wrong because exposing the NLB to the internet with an Elastic IP makes the API publicly accessible, violating the security requirement that the API must remain non-public. Option C is wrong because VPC peering cannot resolve overlapping CIDR blocks; overlapping CIDRs cause routing conflicts and are explicitly unsupported for VPC peering. Option D is wrong because a NAT gateway is used for outbound internet traffic from a private subnet, not for inbound traffic from another VPC, and it would not provide private connectivity between VPCs with overlapping CIDRs.

Why this answer

How to eliminate wrong answers

Option A is wrong because removing all IAM permissions from AppProvisioner and requiring manual role creation by a central security team eliminates the delegation entirely, which contradicts the requirement that developers create application roles for Lambda and ECS; it also introduces operational bottlenecks and does not leverage IAM boundaries. Option C is wrong because adding a CloudTrail rule to alert after a privileged policy is attached is reactive, not preventive; it does not stop a developer-created role from exceeding the approved permission set at creation time, violating the 'may never exceed' requirement. Option D is wrong because moving the delegated IAM workflow into a separate VPC with security groups and network ACLs addresses network-level access control, not IAM permission boundaries; it cannot restrict the permissions of IAM roles created by developers, as IAM policies are not governed by network constructs.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because AWS Shield Advanced provides DDoS protection, not application-layer attack filtering for SQL injection or XSS. Option C is wrong because Network ACLs operate at the subnet level (Layer 3/4) and cannot inspect application-layer payloads for SQL injection or XSS patterns. Option D is wrong because security groups act as stateful firewalls at the instance level (Layer 3/4) and cannot perform deep packet inspection for application-layer attacks.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because Network ACLs are stateless packet filters that operate at the subnet level (Layer 3/4) and cannot inspect application-layer payloads like SQL or XSS patterns. Option C is wrong because security groups are stateful virtual firewalls that control traffic based on IP addresses, ports, and protocols (Layer 3/4), and they lack the ability to perform deep packet inspection for web application attacks. Option D is wrong because AWS Shield Advanced provides DDoS protection and enhanced detection, but it does not include the rule-based filtering needed to block SQL injection or XSS attacks.

Why this answer

How to eliminate wrong answers

Option A is wrong because placing instances in a single subnet and increasing instance size does not provide automated health monitoring or replacement; it only changes the capacity of a single instance and introduces a single point of failure. Option C is wrong because a network ACL is a stateless firewall that filters traffic at the subnet level and cannot detect failed instances or restart them; it has no awareness of application health or instance lifecycle. Option D is wrong because storing web servers on EBS volumes does not automate health checks or replacement; while EBS provides persistent storage, the stateless nature of the application means data persistence is irrelevant to fault tolerance, and manual action would still be required to replace failed instances.

Why this answer

How to eliminate wrong answers

Option A is wrong because increasing the function timeout does not prevent cold starts; it only allows the invocation to run longer, but the initial cold-start delay (e.g., loading runtime, initializing code) still occurs. Option C is wrong because reserved concurrency limits the maximum number of concurrent executions but does not pre-warm instances; it can even worsen cold starts by capping available capacity. Option D is wrong because increasing memory size can reduce cold-start duration (since CPU allocation scales with memory) but does not eliminate cold starts entirely; the first invocation after idle still requires initialization.

Why this answer

How to eliminate wrong answers

Option B is wrong because Gateway VPC endpoints are only supported for Amazon S3 and DynamoDB, not for AWS Secrets Manager. Option C is wrong because a NAT gateway requires an internet gateway and public subnet, and the question explicitly states there is no NAT gateway and no internet egress allowed. Option D is wrong because VPC peering connects two VPCs within the AWS network, not to the AWS public network hosting Secrets Manager; Secrets Manager is accessed via service endpoints, not through peering.

Why this answer

How to eliminate wrong answers

Option A is wrong because increasing ALB size and adding instances only addresses capacity, not the root causes of high latency for distant users or the unexpectedly high request volume; it does not cache content or compress text assets automatically. Option B is wrong because Route 53 latency-based routing still sends all requests to an ALB, which does not cache content or compress text assets; it also does not reduce the number of requests hitting the ALB, as each user request still reaches the origin. Option D is wrong because replacing the ALB with an NLB does not provide caching, compression, or any application-layer features; NLBs operate at Layer 4 and cannot inspect or cache HTTP content, nor can they compress text assets.

Why this answer

How to eliminate wrong answers

Option A is wrong because permission boundaries apply to IAM roles and users, not just users; the boundary can be attached to a role to limit its effective permissions. Option C is wrong because SCPs (Service Control Policies) are organization-level policies that apply to all accounts and principals, but they do not replace the need for a permission boundary on the role itself; SCPs and boundaries work at different layers and are not interchangeable. Option D is wrong because a developer cannot modify the boundary policy itself—the boundary is a separate policy document that only the security team can edit; adding a deny statement to the boundary would not block escalation because the boundary already limits permissions, and the developer lacks permission to alter it.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because KMS is not involved in validating ExternalId during AssumeRole; the ExternalId check is performed by the AWS STS service based on the role's trust policy, not by KMS. Option C is wrong because MaxSessionDuration controls the maximum session length for an assumed role, not authentication failures related to ExternalId mismatches. Option D is wrong because the security team explicitly requires that the ExternalId condition not be removed, and removing it would weaken security by eliminating the confused deputy protection.

Why this answer

How to eliminate wrong answers

Option A is wrong because weighted routing distributes traffic across multiple resources based on assigned weights, which is used for load balancing or testing, not for automatic failover when a primary site fails. Option C is wrong because geolocation routing directs traffic based on the geographic location of the user, which is designed for content localization or regional restrictions, not for active-passive failover. Option D is wrong because latency-based routing sends traffic to the resource with the lowest latency for the user, which optimizes performance but does not provide automatic failover when a primary resource becomes unhealthy.

Why this answer

How to eliminate wrong answers

Option A is wrong because API keys only provide client identification, not authentication; they do not validate the identity of the caller or support OIDC tokens. Option B is wrong because IAM authorization is designed for AWS principals (e.g., IAM users/roles) and requires AWS Signature V4 signing, which is not suitable for internet clients using external OIDC tokens. Option D is wrong because a VPC endpoint policy controls access to API Gateway via VPC endpoints, not authentication or token validation for public internet clients.

Why this answer

How to eliminate wrong answers

Option B is wrong because the error is explicitly about an ExternalId mismatch, not a KMS permissions issue; KMS is unrelated to STS AssumeRole trust policy conditions. Option C is wrong because while removing the condition would technically allow the call, it weakens security and is not the minimal change required to fix the mismatch error. Option D is wrong because AssumeRoleWithSAML does not bypass the ExternalId condition; the condition is evaluated regardless of the STS API used, and SAML-based calls have their own requirements.

Why this answer

How to eliminate wrong answers

Option B is wrong because S3 gateway endpoints are designed for Amazon S3 only, not for Secrets Manager or KMS; Secrets Manager requires an interface endpoint (powered by AWS PrivateLink) and KMS also requires an interface endpoint or a separate connection. Option C is wrong because adding a NAT gateway would route traffic to the internet, which violates the requirement to keep traffic off the internet; the goal is to avoid internet-bound traffic entirely. Option D is wrong because moving the application to a public subnet would expose it to the internet, contradicting the requirement to keep traffic off the internet and potentially compromising security.

Why this answer

How to eliminate wrong answers

Option A is wrong because copying objects to a public website bucket exposes them to the entire internet, violating security and requiring operational scripts for synchronization. Option B is wrong because creating an IAM user in the company account and sharing access keys introduces long-term static credentials that must be manually rotated, are insecure if leaked, and require custom scripts for key management. Option D is wrong because making objects public with difficult-to-guess names relies on security through obscurity, which is not a valid security control; objects can still be discovered via enumeration or leaks, and this violates AWS best practices for data protection.

Why this answer

How to eliminate wrong answers

Option B is wrong because `aws:PrincipalOrgID` checks the AWS Organization ID of the principal, which has no relation to MFA enforcement; it only restricts which accounts in an organization can assume the role. Option C is wrong because denying `sts:AssumeRole` based on the role session name containing "dev" is a naming convention check, not an MFA requirement; it does not verify the caller's authentication method. Option D is wrong because `aws:SecureTransport` enforces HTTPS for the API call, which ensures encryption in transit but does not require the caller to have used MFA; a non-MFA session over HTTPS would still succeed.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because RDS Multi-AZ automatically handles failover without requiring an administrator to manually create a new instance; the standby instance is already provisioned and ready. Option C is wrong because read replicas are used for read scaling and disaster recovery, not for automatic failover; Multi-AZ failover uses a standby in the same Region, not a read replica in another Region. Option D is wrong because the failed primary cannot continue serving traffic; RDS detects the failure and redirects traffic to the standby instance, while the primary is taken out of service.

Why this answer

How to eliminate wrong answers

Option B is wrong because storing IAM user access keys in Lambda environment variables creates long-lived credentials that violate the 'no long-lived access keys' requirement and are harder to revoke without deleting the user. Option C is wrong because security groups control network traffic at the instance/ENI level, not S3 bucket access; S3 uses IAM policies, not security groups, for authorization. Option D is wrong because AWS Organizations SCPs are used to set permission boundaries across accounts in an organization, not to grant specific Lambda function permissions to an S3 bucket; SCPs cannot grant access, only restrict it.