CCNA Design Secure Questions

A Web ACL only inspects traffic for resources it is explicitly associated with. Without association to the ALB's ARN, WAF never evaluates incoming requests, so the rate-based rule cannot block attackers even though requests reach the load balancer.

Cross-account SSE-KMS requires both the KMS key policy in the key owner account and an IAM policy in the caller account to allow the required KMS actions. Scoping the permissions to the specific bucket or encryption context reduces blast radius.

A service control policy (SCP) is the correct preventive control because it operates at the AWS Organizations root, OU, or account level and can block the ec2:CreateVolume API call when the ec2:Encrypted condition key evaluates to false. This means unauthorized or unencrypted volume creation is denied before the resource exists, across all principals in the account, regardless of their IAM permissions. SCPs do not modify resources, but they enforce policy at request time, making them an effective guardrail for encryption compliance.

SSE-KMS with a customer managed key gives the firm control over the key policy, rotation, and revocation, and KMS API calls are recorded in CloudTrail for independent auditing. S3 applies the encryption server-side when objects are written, so no application code change is required. This satisfies encryption at rest, customer-controlled keys, and auditable key usage simultaneously.

Origin Access Control signs CloudFront requests to the S3 origin, letting you remove public read access from the bucket policy so only the distribution's identity is granted `s3:GetObject`. This directly satisfies the requirement that users cannot bypass CloudFront, since unsigned direct requests to the bucket are denied.

The aws:sourceVpce condition key restricts bucket access to requests originating through the named VPC endpoint, satisfying the requirement that traffic arrive only via that endpoint. It is a native policy condition, so no custom operational scripts are needed.

For a cross-account role assumption, the trust policy on RoleInAccountA is necessary but not sufficient: it lists Account B as a trusted principal, but the individual user or role in Account B must also have an attached IAM policy granting sts:AssumeRole with a Resource that includes RoleInAccountA's ARN. Without that identity-based permission, the caller has no authorization to invoke the STS API, even though the trust side is satisfied. This dual-sided authorization is the standard way to securely delegate access across accounts.

Secrets Manager stores the secret value encrypted under a customer master key (CMK). When the microservice calls GetSecretValue, Secrets Manager must invoke KMS Decrypt to reveal the plaintext, so the role needs kms:Decrypt on that CMK in addition to secretsmanager:GetSecretValue on the secret ARN. The CloudTrail entry shows the failure occurred in KMS, not in Secrets Manager, confirming the service already passed the Secrets Manager authorization but lacked the decryption permission. Scoping both permissions to the specific ARNs maintains least privilege and fixes the AccessDenied.

Because the SCP is what creates the Deny, the correct fix is to adjust the SCP scope/conditions so that kms:Decrypt for the specific CMK is not denied for the Finance OU. Other OUs remain under the same restrictive SCP behavior.

GetSecretValue is the only AWS Secrets Manager API action that returns the encrypted secret's decrypted string, which is exactly what the Lambda function must read. By restricting the Action to secretsmanager:GetSecretValue and the Resource to the secret's full ARN, the IAM policy grants access to that single secret while denying all other Secrets Manager operations. This follows least privilege because the function cannot update, list, or describe any other secret, and the full ARN is more precise than using a wildcard or partial name.

The bucket policy is pinned to a specific endpoint ID using aws:SourceVpce. Redeploying or recreating the endpoint creates a new endpoint ID, so requests now present a different aws:SourceVpce value. Updating the bucket policy to match the new endpoint ID makes the condition true again while keeping access restricted to that specific private endpoint.

AWS WAF is the right control at the CloudFront edge because it can inspect requests before they reach the origin and enforce a rate-based rule on abusive traffic patterns. A rate-based rule can automatically count requests by source IP and block or challenge requests that exceed the configured threshold, which directly addresses the burst traffic shown in the logs. This meets the requirement to mitigate at the edge without any application changes.

An organisation trail captures management events, including IAM trust policy changes, across every account and region, recording the principal identity and request parameters. Delivering to a centralised S3 bucket in a dedicated audit account provides the immutable, organisation-wide record investigators require.

This enforces the encryption choice at upload time by validating the request headers that specify SSE-KMS and the exact KMS key ID/ARN. Using a Deny condition ensures uploads that do not include the correct SSE-KMS headers (for example, unencrypted uploads or uploads using a different KMS key) are rejected immediately.

For SSE-KMS, S3 must call KMS Decrypt when serving objects. KMS authorization is evaluated against the KMS key policy in Account A in addition to the identity policy in Account B. If the error includes kms:Decrypt AccessDenied in a cross-account scenario, the most direct fix is to update the KMS key policy to allow the Account B role to use the key for decrypt (often with conditions tied to S3 usage and the specific bucket/object encryption context).

An STS session policy is specifically designed to reduce the permissions of temporary credentials for a single assume-role session. The reusable base role can remain broad enough for multiple pipelines, while TeamA can pass a session policy that limits effective permissions to the teamA/prod prefix. This preserves the shared role model and achieves least privilege without creating a separate IAM role.

Secrets Manager integrates natively with IAM roles, so the application can call GetSecretValue using temporary credentials from the instance profile without storing anything on disk. Built-in rotation for supported databases updates the secret and the database password automatically, minimizing operational effort. IAM policies can restrict access to the specific secret and role, satisfying least privilege. This is the intended AWS pattern for this scenario.

An attached IAM role provides temporary credentials through instance metadata, removing long-lived keys. An interface VPC endpoint powered by AWS PrivateLink keeps Parameter Store traffic inside the VPC, so no internet or NAT gateway is needed. Together they meet both the credential and the private connectivity requirements.

Amazon S3 Versioning is the correct solution as it automatically retains multiple variants of an object in the same bucket, each with a unique version ID. This crucial feature enables recovery from both accidental overwrites and deletions, ensuring the integrity and availability of important documents. When an object is modified or deleted, S3 does not remove the previous version, but rather stores it as a non-current version, allowing for easy restoration to any prior state.

Restricting the trust policy principal from the entire 222233334444 account root to the exact ARN arn:aws:iam::222233334444:role/BatchRunner is the correct fix because it follows least privilege by allowing only that specific role to assume the target role. Keeping the ExternalId condition preserves protection against the confused deputy problem, requiring the caller to present the correct ExternalId in the sts:AssumeRole request before the trust policy authorizes the assumption.

STS session policies are designed to further restrict the permissions of temporary credentials issued by AssumeRole. In this case, the shared role can remain reusable for other pipelines, while this one execution is narrowed to the exact S3 prefix and KMS key required. The effective permissions become the intersection of the role permissions and the session policy, which preserves least privilege without changing the shared role itself.

Gateway VPC endpoints for S3 are the supported way to send S3 traffic from private subnets without NAT. They add routes in the relevant route tables (via S3 prefix lists) so requests to S3 go through the AWS network. This avoids internet egress and keeps the path private to the extent intended by VPC endpoint routing.

An organization CloudTrail trail delivers read/write management events from all accounts in the AWS Organization to a single S3 bucket (and optionally CloudWatch Logs) in the security account, creating a centralized audit trail. CloudTrail records both successful and failed API calls, including PutBucketPolicy and PutKeyPolicy, with event details such as caller identity, source IP, and request parameters. By adding Amazon EventBridge rules that match these specific event names—including `errorCode` fields for failed calls—the security team can trigger near-real-time alerts or automated remediation, making this the most direct and complete solution.

SSE-KMS with customer managed keys gives the company control over the KMS key, including key policies, rotation, and auditing via AWS CloudTrail. It integrates natively with S3, so no application changes are needed, minimizing operational overhead. This meets the requirements for customer-controlled keys, rotation, and auditability while leveraging AWS-managed infrastructure.

This is correct because API Gateway's JWT authorizer validates the RS256 signature, issuer, audience, and expiry of a JWT issued by your customer's OpenID Connect (OIDC) provider. It automatically discovers the provider's JWKS keys through the OIDC discovery endpoint, so no custom Lambda code is required. The verified token claims are then passed to the integration via context, enabling clean, low-operational-overhead authentication for public API users. This directly matches the need to confirm the identity of each caller.

This change directly restricts trust to one named role in Account B and adds a confused-deputy defense with the external ID. The role trust policy is the correct place to control who can assume the role, and the external ID ensures only the expected caller can complete the STS request.

AWS Systems Manager Session Manager establishes an interactive shell connection through the SSM Agent using a bidirectional channel over the AWS API, controlled by the instance's IAM role. Because no security group ingress rule is needed, there is no inbound SSH/RDP exposure, and each session is automatically audited through AWS CloudTrail with optional session logs to S3/CloudWatch Logs. The required IAM role grants least-privilege permissions (e.g., AmazonSSMManagedInstanceCore) and lets administrators restrict actions centrally via IAM policies, providing secure, audited administrative access.

CloudTrail management events capture control-plane API calls, including PutBucketPolicy and PutKeyPolicy, recording the request parameters, principal, source IP, and timestamp. An EventBridge rule can match these event names and invoke an SNS topic or Lambda function to notify the security team within seconds of the call. Delivering the raw CloudTrail logs to a dedicated S3 bucket creates a tamper-evident, centrally retained audit trail for post-incident analysis and compliance reporting, whereas simply watching resource state via Config would not provide the same event-level specificity.

Permission boundaries work by intersecting allowed actions from the role’s attached policies with the actions permitted by the boundary policy. If the automation tool fails to set the PermissionBoundary ARN (or sets an incorrect one), then the role can use the developer’s attached policies without the intended restriction. Fixing the PermissionBoundary parameter in the role creation call is the direct remedy.

An interface VPC endpoint, powered by AWS PrivateLink, creates an elastic network interface with a private IP address directly in the subnets of your VPC. This allows instances in the private subnets to reach Systems Manager and Parameter Store using private DNS, with no internet gateway, NAT gateway, or public IP required. The traffic stays entirely within the AWS network, satisfying the requirement for fully private connectivity. This endpoint also supports security group attachment for granular traffic control.

SSE-KMS with a customer managed key allows the company to control key rotation and audit usage via AWS CloudTrail. The key policy can be scoped to allow only the application's IAM role to perform the Decrypt operation, ensuring that no other principals can access the data. This meets all stated requirements.

A bucket policy is a resource-based policy that can explicitly grant the partner's IAM role principal (e.g., 'arn:aws:iam::partner-account-id:role/PartnerReadOnlyRole') permission to call 's3:GetObject' on the 'reports/' prefix. By scoping the 'Resource' to 'arn:aws:s3:::your-bucket/reports/*' and optionally adding a condition such as 'aws:SourceArn' or 'ExternalId', you enforce least privilege without creating or distributing long-lived keys. This is the standard AWS pattern for granting cross-account read-only access to a limited S3 prefix.

A role-based approach removes long-lived keys and supports temporary credentials. Using a permissions-policy condition to require MFA presence enforces that the session must have MFA to perform actions, aligning with the “actions only allowed with MFA present” requirement.

The sts:ExternalId condition is a common protection against confused-deputy scenarios in cross-account role assumption. It ensures that only principals who know the unique external ID can successfully assume the role. This mitigates a third party tricking the vendor’s identity into assuming your role, even if they can call AssumeRole.

A gateway VPC endpoint for S3 keeps traffic between the VPC and S3 on the AWS network without using the public internet or a NAT gateway. This is the standard private-connectivity pattern for S3 access from private subnets. It also simplifies the architecture and reduces NAT-related cost while preserving access to the bucket from workloads that must remain nonpublic.

With SSE-KMS using a customer-managed key, the caller must have both s3:GetObject and kms:Decrypt on the key. The KMS key policy grants only the account root, so the EC2 role has no kms:Decrypt permission. Without it, S3 cannot decrypt the object for the caller, resulting in AccessDenied. Adding kms:Decrypt to the role or key policy resolves the issue.

ListBucket must be authorized at the bucket ARN level, then scoped using a Condition on the request prefix (so only the approved listing prefix is allowed). GetObject is authorized at the object ARN level and is restricted to exports/acme/*, preventing reads outside the prefix.

Configuring an HTTPS listener on the ALB with an ACM certificate terminates TLS at the load balancer, encrypting all traffic between clients and the ALB. The ACM certificate is validated and managed by AWS, and the listener negotiates a TLS connection using an appropriate security policy. Adding an HTTP-to-HTTPS redirect rule ensures that any request sent to port 80 is automatically sent over port 443, so every client is forced to use an encrypted connection. This directly meets the requirement for encrypting traffic in transit for the internal web application.

Permission boundaries cap the maximum effective permissions for the role by intersecting the identity policy and the permissions boundary at authorization time. Even if the identity policy later expands, the boundary still prevents actions not allowed by the boundary policy, providing deterministic enforcement against privilege escalation.

SCPs set the outer boundary for permissions in an account or OU. They do not grant access, but they can block actions even when the IAM role has AdministratorAccess. The explicit deny in the SCP is therefore the reason CreateSnapshot fails. To allow the operation, the organization must change the SCP or move the account out of the restrictive scope.

A customer managed key in AWS KMS gives the company control over the key policy, rotation settings, and key state. Enabling automatic rotation rotates the backing key material annually while retaining the same key ID, and disabling the key immediately prevents new decrypt operations, satisfying both the rotation and revocation requirements.

For multipart uploads, S3 clients use s3:AbortMultipartUpload to stop/cleanup an in-progress multipart upload (for example, when an upload fails or the client cancels). Granting s3:AbortMultipartUpload only on the uploads prefix matches the denied API in the symptom and keeps the permission scoped to the exact objects the service uploads.

Gateway endpoints provide private routing to S3, and interface endpoints provide private access to Secrets Manager without internet traversal. Security group controls on interface endpoints restrict traffic to only the application subnets, meeting segmentation and cost constraints.

This design places instances in private subnets so they have no public IPs or direct internet route, while the NAT gateway in a public subnet provides outbound internet access. Referencing the load balancer's security group as the source of the inbound rule on the instances' security group ensures that only the ALB can open connections to port 443, which is exactly the required restriction and avoids hardcoding CIDR ranges.

This is the standard supported method to encrypt an existing unencrypted RDS instance. You snapshot the instance, restore the snapshot with encryption enabled and a customer managed KMS key, then update the application connection string. It satisfies the requirement for customer-controlled key rotation, auditing, and revocation via KMS.

IAM database authentication generates short-lived tokens from the EC2 instance role, so no database password is stored on the instance. This directly satisfies the requirement that credentials never reside on EC2 and that authentication uses temporary tokens.

Referencing the application tier security group as the source in the RDS security group rules ensures that only application instances can connect to the database. This enforces least privilege and prevents internet access. It also simplifies management because instances added to the application security group automatically gain access.

For multipart uploads, SSE-KMS is specified on CreateMultipartUpload rather than on individual UploadPart calls. Supplying the required SSE-KMS settings and CMK key ID on the upload initiation request satisfies the bucket policy's condition without weakening the encryption requirement.

Because editors assume a permission set role through IAM Identity Center, CloudTrail records each kms:Decrypt and kms:GenerateDataKey call with the role session and the federated user identity, satisfying the audit requirement. Removing a single editor from the permission set assignment in IAM Identity Center removes their ability to assume the role, revoking only that person's access without touching the shared key policy.

This is the strongest organization-wide enforcement. The SCP prevents role creation unless the approved permissions boundary is attached, and it can also prevent boundary removal later. That ensures the maximum effective permissions for all created roles remain capped, even if someone attaches a broader identity policy afterward.

Secrets Manager is designed to securely store and rotate credentials. By using an IAM role attached to the EC2 instances, the application can retrieve secrets via the AWS SDK without hardcoding credentials. Secrets Manager integrates with AWS CloudTrail for auditing and supports automatic rotation, meeting the requirements with minimal operational effort.

An IAM role attached to EC2 instances provides temporary credentials and can be scoped to allow secretsmanager:GetSecretValue for the specific secret. This allows the application to retrieve credentials without hardcoding them. It follows the principle of least privilege and integrates with AWS Secrets Manager. The role eliminates the need for long-term access keys.

Enforcing aws:SecureTransport in the bucket policy denies any request made over HTTP, ensuring data is encrypted in transit. This is a low-overhead, declarative way to meet the encryption in transit requirement without modifying application code. It applies to all requests to the bucket, including those from the application and any other principals.

Signed URLs or signed cookies are the native CloudFront authorization mechanism for restricting access to private content. Each signature is generated with a CloudFront key pair and embeds an expiration timestamp via a canned or custom policy; when a request arrives, edge locations cryptographically verify both the signature and the expiration field before forwarding the request to the S3 origin through an origin access control (OAC). After the 1-hour window passes, CloudFront rejects the request with an HTTP 403 error at the edge, so the S3 bucket never needs to perform time-based authorization logic. Because the authentication is cryptographic and enforced independently at every CloudFront edge location, it provides exactly the desired time-limited, per-resource access control without exposing the bucket directly.

S3 Object Lock in compliance mode prevents any principal, including the account root user, from deleting or overwriting a protected object version until the retention period expires. The retention date is recorded on each object version, making the protection independently verifiable, which matches both the immutability and the audit requirements.

AWS PrivateLink establishes private, secure connectivity between VPCs without requiring VPC peering, VPN connections, or exposing services to the public internet. By creating a VPC endpoint service backed by the internal Network Load Balancer in VPC A, the internal HTTP API becomes available to the partner VPC via an interface VPC endpoint. This solution inherently avoids CIDR overlap issues and provides granular access control through endpoint policies and service permissions, ensuring the NLB remains non-public.

A task IAM role provides temporary credentials to each task through the ECS task metadata endpoint, and permissions are scoped to exactly what the task needs. This satisfies both the temporary-credential and least-privilege requirements. Fargate supports task roles natively, so no instance-level role or static keys are involved.

S3 Block Public Access provides account-level or bucket-level settings—BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets—that override public ACLs and public bucket policies before they can take effect. For a banking backend, setting all four to true centrally at the account level ensures that no object can be exposed to the public, even if a developer accidentally adds a public ACL or bucket policy statement. This is the preferred, preventive control because it actively denies public access rather than merely detecting it.

A permissions boundary is specifically designed to cap the maximum permissions a role can ever receive, regardless of what identity-based policies are attached later. If a developer adds a broader managed policy or inline policy, the effective permissions still cannot exceed the boundary. This makes it the best fit for delegated role creation with a centrally approved ceiling.

Origin Access Control is the modern pattern for restricting S3 origins to CloudFront. The bucket policy can then permit only the specific distribution, preventing direct S3 access while keeping the content private. Signed URLs or cookies can still be used at the viewer layer for authorization.

AWS Secrets Manager is the correct choice because it natively manages the entire secret lifecycle: it stores the secret encrypted with KMS, automatically rotates it on a configurable schedule (e.g., every 30 days) by invoking an attached rotation Lambda function, and propagates the new credentials to supported AWS services like RDS. This eliminates manual secret rotation and reduces the risk of credential drift. Secrets Manager also integrates with AWS CloudTrail for auditability and supports cross-account access, making it the only option here that fulfills both secure storage and automated rotation.

This grants only the specific action s3:GetObject and scopes it to the exact prefix that the service needs. It aligns with least privilege by avoiding extra permissions like PutObject or DeleteObject. Since the service already has ListBucket, this completes the required read path for objects in incoming.

A customer managed key gives the company full control over rotation and the key policy, which can limit decryption to the application role. SecureString parameters are encrypted with the specified KMS key, and the caller needs both ssm:GetParameter to read the parameter and kms:Decrypt to unwrap the data key, matching every stated requirement.

AWS WAF, when associated with an Application Load Balancer, performs deep Layer 7 inspection of HTTP/HTTPS requests, including headers, query strings, body, and URI. It can run managed rule groups such as AWSManagedRulesSQLiRuleSet and AWSManagedRulesCommonRuleSet to detect and block SQLi, XSS, and other common web exploits in real time. This makes it the correct tool for protecting a healthcare document service from application-layer attacks.

SSE-KMS with customer managed keys lets the company define key policies, enable automatic annual rotation, and audit every use of the key through AWS CloudTrail. AWS manages the underlying key infrastructure, so operational burden is low. This satisfies the requirements for control, auditing, and on-demand rotation while keeping management overhead minimal, making it the best fit for the scenario.

S3 is best reached through a gateway VPC endpoint, while Secrets Manager requires an interface endpoint. With private DNS enabled, the application can resolve and reach those services without leaving AWS private networking. This removes the need for NAT traffic for those calls, cuts cost, and keeps service access off the public internet.

This directly checks the SSE encryption header used in the PutObject request. If a client uploads without SSE-KMS (for example, no encryption header or SSE-S3/AES256), the condition evaluates to true and the Deny prevents the upload.

A JWT authorizer configured with the OpenID Connect issuer validates the JSON Web Token signature, expiry, and issuer at the API Gateway edge before allowing the request. This offloads authentication so the backend can trust claims such as the user's unique subject identifier and custom scopes without managing sessions or cryptographic verification code. It is the most appropriate, operationally lightweight option for authenticating external OIDC-based users on a public API.

SSE-KMS with a customer managed key gives auditable, rotatable encryption under company control. CloudTrail records bucket configuration API calls, and EventBridge can match those events and invoke a Lambda function to revert or alert, providing automated detection and response. This combination directly addresses both the encryption and monitoring requirements.

An interface VPC endpoint for STS places an elastic network interface in the subnet, letting the SDK reach STS over private AWS networking without a NAT gateway or internet route. The security group must permit HTTPS (443) from the instances, satisfying the requirement to keep them private.

For customer-managed KMS keys, key policy is a required authorization layer. Even with an IAM identity policy granting kms:Decrypt, KMS will deny the request unless the key policy also authorizes the calling principal to use the key for Decrypt.

S3 object retrieval with SSE-KMS requires that KMS authorize decryption, and that authorization must exist in the key policy for a CMK in another account. Scoping the statement to the specific role and S3 usage keeps the access narrow while allowing the object read to succeed.

Referencing the application tier's security group as the source in the database security group's inbound rule allows only instances that carry that security group to connect on port 5432. This is the least-effort approach because it automatically adapts as application instances scale in or out, and it does not require managing individual IP addresses or network ACLs.

AWS Secrets Manager is the only service in the options that natively integrates with Amazon RDS to rotate credentials with a managed Lambda rotation function, which you can configure to run every 30 days. The rotation process updates the database password, the secret value, and the secret's versions atomically and can be tested for rollback, eliminating the need for custom rotation code. Enabling rotation adds minimal operational overhead — you just choose the 30-day interval and the rotation Lambda provisions itself with the appropriate IAM role and permissions. This directly meets the requirement and is the recommended AWS pattern for automated RDS credential rotation.

To resolve a KMS key policy denial for an application using S3 with a customer managed key, the KMS key policy must explicitly list the application's IAM role as a principal allowed to call kms:Decrypt (and kms:GenerateDataKey for writes). IAM permissions alone are not enough because KMS key policies act as a separate authorization layer; the key policy must explicitly trust the principal. Adding a kms:ViaService condition set to "s3.amazonaws.com" enforces least privilege by restricting key usage to requests that originate through S3, preventing the role from using the key outside the intended service context.