CCNA Security and Compliance Questions

An AWS KMS customer master key with imported key material (Origin: EXTERNAL) cannot have automatic key rotation enabled, because rotation relies on the key material being generated and managed within AWS KMS. The import mechanism bypasses KMS's managed backing keys, so the service cannot automatically replace the backing key. To rotate such a key, you must manually create a new CMK or import new key material into the existing CMK.

This explicit Deny is the correct approach because it denies any PutObject that does not include the x-amz-server-side-encryption header with the value 'aws:kms'. The value 'aws:kms' is the algorithm identifier for SSE-KMS, ensuring all uploaded objects are encrypted with a KMS-managed key. Because it is an explicit deny, even if another policy allows an unencrypted upload, this deny overrides it. This is the standard pattern for enforcing KMS encryption across an S3 bucket.

A TLS-enabled ELB (ALB or NLB) terminates the TLS/SSL handshake with clients, decrypting traffic at the AWS edge and thereby providing the cryptographic controls required for cardholder data in transit under PCI DSS Requirement 4. It also allows you to attach an AWS Certificate Manager certificate and optionally re-encrypt traffic to backend targets, so the load balancer is a correct service for securing communications.

Amazon ECR image scanning automatically checks container images for known vulnerabilities (CVEs) by integrating with Amazon Inspector. In a CI/CD pipeline, you can invoke a scan after pushing an image to ECR, then retrieve findings via an API and block the deployment if critical vulnerabilities exist. This directly satisfies the requirement to identify known security vulnerabilities in images before they are deployed.

This is the correct multi-tier security group design because it enforces least privilege with instance-level granularity. The web tier security group allows only HTTP/S from the internet, the app security group allows traffic only from the web security group (not from any IP or CIDR), and the database security group allows only from the app security group. Using security group references instead of CIDR blocks means that any instance bearing the web SG is automatically allowed to reach the app tier, which makes scaling and instance replacement seamless without updating rules. This approach is stateful, so responses are automatically allowed, and it is far more secure than subnet-level NACL rules, which are stateless and cannot distinguish between instances within the same subnet.

Selecting encryption at DB instance creation with a customer-managed KMS key encrypts the underlying storage, snapshots and read replicas. This satisfies the data-at-rest constraint while giving the organisation control over key rotation and revocation, which an AWS managed key does not provide.

This SCP correctly denies both ec2:CreateVpc and ec2:ModifyVpc in a single Deny statement. Because an explicit Deny in an SCP overrides any Allow from IAM policies or other SCPs, this creates a hard boundary that blocks both creation and modification of VPCs across all accounts in the organization. The array format properly lists both actions to ensure complete coverage of the intended restriction.

AWS Secrets Manager is designed for managing database credentials and provides native automatic rotation. Its RDS rotation Lambda blueprint creates a Lambda function that updates the secret and the database user password on a defined schedule, without application changes. The service also tracks secret versions and supports KMS encryption, making it the secure, fully managed choice for this requirement.

Create an IAM role that defines the exact AWS API permissions the container needs, then specify that role in the task definition using the taskRoleArn parameter. The ECS agent—on Fargate or EC2—assumes this role on behalf of the task and exposes temporary credentials to the container via the ECS credential endpoint, so the SDK automatically rotates them. This is the recommended pattern because it scopes credentials to a single task, follows least privilege, and eliminates the need to manage any static access keys.

AWS Secrets Manager is purpose-built for securely storing, rotating, and auditing access to secrets, with encryption via KMS at rest and in transit. By assigning the CodeBuild service role an IAM policy that allows secretsmanager:GetSecretValue for the specific secret, you can inject the secret directly into the build environment using the 'secrets-manager' environment variable type in the buildspec, ensuring the actual secret material never appears in logs, the console, or CloudFormation templates. Secrets Manager also provides automatic rotation (e.g., for RDS credentials), CloudTrail API logging for every retrieval, and fine-grained control through resource-based policies, making it the most secure and operationally efficient option for CodeBuild credential management.

For the rotation function to update credentials on RDS, it must be deployed inside the same VPC or have a route to it; if the Lambda function lacks VPC configuration, its ENI never gets a private IP in the RDS subnet. Each invocation then tries to open a socket to the database but has no network path, so it consumes the entire configured timeout and Secrets Manager reports rotation as failed. Merely granting IAM permissions for secretsmanager and RDS does not create network connectivity, so this is the root cause when the error is consistently a timeout rather than an access-denied.

The bucket policy contains an explicit deny statement for the principal or action being attempted, and AWS IAM policy evaluation gives explicit deny statements absolute precedence over any allow statements from identity-based policies, resource-based policies, or permission boundaries. Even though the IAM role allows the s3:GetObject call, the explicit deny in the bucket policy forces the final decision to AccessDenied. This precedence is a deterministic, non-configurable part of AWS's authorization engine.

Remediation actions in AWS Config require the Lambda function to have an IAM role that is assumable in every member account where the rule runs. When using the AWS-provided remediation action 'AWS-ConfigureSecurityGroupChanges' or a custom Lambda function, that role must include permissions such as ec2:AuthorizeSecurityGroupIngress, ec2:RevokeSecurityGroupIngress, and similar actions scoped to the target security groups. Without those permissions, the Lambda execution fails with an AccessDenied error even though the event was delivered and the function started. This is the most direct cause of the failure because the rule is detecting and triggering correctly, but the remediation cannot modify the resources.

This statement uses 'Deny' with the condition 'aws:SecureTransport': 'false', meaning that any time S3 sees a request to this bucket that did not use TLS/SSL, the condition is satisfied and the explicit deny applies, causing the request to be rejected. HTTPS requests have SecureTransport set to true, so they are not affected by this particular statement and may be allowed or denied based on other applicable policies. This is a standard pattern to enforce HTTPS-only access to S3 buckets.

The correct issue is that this Lambda execution role lacks any inline or managed policy granting the required CloudWatch Logs permissions. Without a policy allowing logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents, Lambda cannot write execution logs to CloudWatch, even though the trust policy is valid. This will cause runtime failures or missing log output, and is a common misconfiguration.

Enabling S3 default encryption with SSE-S3 on the CodePipeline artifact bucket automatically encrypts every object with 256-bit AES keys managed by Amazon S3. This is the simplest native approach: once enabled, you need no key management, no pipeline role changes, and no application code modifications. CodePipeline writes artifacts as normal S3 PUTs, so the bucket-level default encryption covers all stages and runs with zero overhead.

An IAM role attached as an instance profile is the AWS-recommended mechanism because the EC2 instance automatically assumes the role through the instance metadata service (IMDS), receiving temporary credentials from AWS STS that are valid for a limited duration and refreshed automatically by the SDK or CLI. This eliminates the need to store or manage long-lived access keys while letting you scope the role with a narrowly defined read-only policy, such as allowing only s3:GetObject or ec2:DescribeActions. The instance profile acts as the container for the role, and the per-instance trust policy ensures only instances with that profile can use the role, giving centralized control, easy revocation, and cross-account access when needed.

Amazon GuardDuty is a managed threat detection service that continuously analyzes VPC Flow Logs, AWS CloudTrail management events, DNS logs, and, when enabled, EKS audit logs and S3 data events. It uses built-in threat intelligence feeds and machine learning to identify suspicious activity such as unusual API calls, reconnaissance behavior, or cryptocurrency mining, and produces findings that can trigger automated response via Amazon EventBridge. This makes it the purpose-built AWS service for automatically detecting and responding to suspicious activity.

Amazon GuardDuty is a continuous threat detection service that ingests and analyzes AWS CloudTrail management and data events, VPC Flow Logs, and DNS query logs. Using machine learning, anomaly detection, and integrated threat intelligence, it identifies reconnaissance, credential compromise, crypto-mining, and other unauthorized behavior. GuardDuty generates prioritized findings in the console and can trigger automated responses via Amazon EventBridge. Because it actively correlates across logs, it directly fulfills the 'monitor and detect unauthorized access' requirement.

AWS IAM Identity Center (formerly AWS SSO) is the correct service because it is purpose-built to centrally manage workforce user access and single sign-on across multiple AWS accounts, business applications, and SAML 2.0-enabled apps. It lets you define permission sets that map users or groups to IAM roles in different accounts, and it integrates with identity providers like Active Directory or Okta. This directly addresses the requirement to centrally manage user access to multiple AWS accounts with SSO.

AWS CloudTrail is the authoritative audit service that records management events as API calls, including the CreateUser action that IAM user creation invokes. By enabling CloudTrail, your security team gains a detailed, tamper-evident log of who created which IAM user, from which source IP, and with what permissions. This event data can then be delivered to Amazon CloudWatch Logs for further processing and alerting, making CloudTrail the essential first step in a real-time monitoring pipeline.

This is correct because an interface endpoint (powered by AWS PrivateLink) places an elastic network interface for secretsmanager inside the subnet, so the CodeBuild container reaches the service privately without NAT or internet egress. The endpoint's security group must permit TCP 443 inbound from the build instances, which the scenario's S3 gateway endpoint cannot provide for Secrets Manager.

The application caches the secret value and does not refresh it until the cache expires or the application is restarted. This is the classic stale-secret problem: even though Secrets Manager's AWSCURRENT label points to the new version, the boto3 or AWS SDK client-side cache still holds the old value. The application will continue to use the previous database credentials until the cache TTL elapses or the process is restarted. This perfectly matches the symptom of a successful retrieval that still yields outdated credentials.

AWS CloudTrail is the primary service for recording API activity in an AWS account, capturing every management and data event with details like the caller's identity, the action, the resource, and the timestamp. By enabling CloudTrail in all regions and with appropriate event types, you can inspect logs to identify unauthorized attempts, such as failed authentication or IAM policy denials. CloudTrail provides the raw evidence needed for security analysis and is the foundational data source for services like GuardDuty.

This policy grants the root principal s3:GetObject and s3:PutObject actions on the arn:aws:s3:::bucket/* resource. s3:GetObject allows downloading an object's data and metadata, while s3:PutObject allows uploading a new object or overwriting an existing one. Together, these actions explicitly authorize reading and writing objects inside the bucket, which is exactly what the question asks — making this the correct option.

Secrets Manager natively supports rotation for RDS credentials through a managed Lambda function. The rotation function updates the password in the RDS database and then stores the new value in the secret, using staging labels like AWSCURRENT and AWSPENDING to ensure applications can always retrieve valid credentials. The application retrieves the current secret via the Secrets Manager API (for example, GetSecretValue), and effective caching keeps this cost-efficient. This exactly meets the requirement of rotating the database every 30 days while keeping the application functional.

AWS CloudTrail is the correct answer because it is the native AWS service designed to record all API activity across your account. Every management event, including calls made by users, roles, or AWS services, is captured with details like the identity of the caller, source IP address, event time, request parameters, and response elements. By creating a trail, you can deliver these audit logs to an S3 bucket for long-term storage and enable CloudTrail Insights to detect anomalous API activity, which directly satisfies the requirement to ensure all API calls are audited.

Customer managed keys are the only KMS key type that supports manual rotation, allowing you to create a new key and update aliases as needed at any time. By manually rotating every 90 days, the company can enforce its required rotation policy while keeping the same alias or key ID for applications. This gives full control over rotation frequency, unlike automatic rotation which is fixed at yearly.

AWS Systems Manager Patch Manager is a purpose-built capability that automates the process of patching managed instances, whether they are EC2 instances or on-premises servers. It works in tandem with patch baselines, maintenance windows, and rate control to approve, schedule, and install patches, and it also reports patch compliance for the fleet. With the SSM Agent installed, Patch Manager uses a standard SSM document such as AWS-RunPatchBaseline to execute the patch operation, making it the correct choice for automated OS patching.

AWS Config rules continuously evaluate EC2 instances against compliance criteria such as mandatory tags or VPC membership. When an instance violates a rule, Config marks it non-compliant and can trigger remediation actions like Lambda functions, but it does not block the initial launch. This makes it a detective control that identifies drift after the fact rather than preventing non-compliant resources from being created.

Service control policies set the maximum available permissions for every principal in attached accounts, so a deny at the root organisational unit blocks those instance types organisation-wide. This centrally satisfies the cross-account restriction requirement without editing each account individually.

AWS WAF is the correct choice because it is a fully managed web application firewall that attaches directly to an Application Load Balancer to inspect each incoming HTTP/HTTPS request at the application layer. It can block, allow, or count requests matching conditions such as SQL injection signatures, XSS patterns, IP reputation lists, geo restrictions, and header or body size limits. AWS-managed rule groups, including the OWASP Top 10 rule sets, provide ready-made protection, and WAF integrates natively with ALB to stop malicious traffic before it reaches the EC2 instances.

Amazon S3 Block Public Access provides a bucket-level setting that, when enabled, overrides all other public-access grants by ignoring bucket policies and object ACLs that allow public access, including those that grant access to `*`. This control is evaluated at the edge before any policy or ACL decision and is not overridable by explicit allow statements, making it a highly effective preventative measure. Because it is a native access control, enabling it immediately blocks both existing and future public exposure without requiring you to rewrite the bucket policy.

Attaching AWS WAF to the Application Load Balancer adds a managed Layer 7 firewall that filters incoming HTTP(S) requests before they reach the target group. WAF can block common web exploits such as SQL injection, cross-site scripting (XSS), and excessive request patterns via rate-based rules, and it integrates with AWS Managed Rules for OWASP Top 10 protection. This is a required security action for a publicly exposed web workload because security groups alone only control transport-level access and cannot inspect payloads, and it can be used alongside AWS Shield for DDoS mitigation.

ecr:DescribeRepositories is the exact IAM action required to call the ECR DescribeRepositories API, which CodeBuild uses to list repositories and retrieve their metadata (repository name, ARN, URI, creation timestamp, and image scanning configuration). If this permission is missing from the CodeBuild service role, any attempt to enumerate or describe repositories will fail with AccessDenied. This is the root cause of the failure in the scenario.

This is the correct solution because it combines three complementary layers. The VPC endpoint for S3 (a gateway endpoint) ensures that all traffic to the bucket originates from within the company's VPC, and the bucket policy denies any request unless the aws:SourceVpce condition matches that endpoint, effectively blocking public internet access. The aws:SecureTransport condition forces all requests to use HTTPS, protecting data in transit from eavesdropping and man-in-the-middle attacks. Finally, enabling S3 default encryption (SSE-S3) ensures that artifact objects are encrypted at rest, so even if an object is somehow copied outside the bucket, its contents remain unintelligible without the encryption key. Together these controls satisfy both transit and at-rest encryption while restricting the attack surface to the VPC.

AWS CloudTrail is the native auditing service that records every API call made in the account, including calls from the console, SDKs, CLI, and other AWS services. Each event captures the identity of the caller, source IP, time, request and response elements, and the specific action invoked. This makes CloudTrail the correct and only service in this list that directly provides a complete API call history for auditing.

A bucket policy denying requests where `aws:SecureTransport` is false enforces HTTPS-only access, directly satisfying the in-transit encryption requirement. This condition evaluates the TLS state of each request, so any plain HTTP call to the bucket is rejected regardless of IAM permissions, ensuring all access is encrypted in transit.

The Lambda rotation function must perform multiple sequential operations—connect to the RDS database, run an ALTER USER statement, and call UpdateSecret to store the new password—all of which can exceed the default 3-second timeout, especially during cold starts or slow network conditions. Increasing the function timeout directly prevents the execution from being terminated mid-rotation, allowing the full workflow to complete before Secrets Manager marks the step as failed. This is the correct fix because timeout errors indicate the function is being killed before finishing, not that it lacks compute resources or network access.

AWS Secrets Manager is a purpose-built service for storing and managing database credentials and other sensitive secrets. It provides native automatic rotation, including native integration with Amazon RDS, Redshift, and DocumentDB, which enforces credential lifecycle management and reduces the operational burden of periodic rotation. Its resource-based policies and tight integration with AWS Lambda and IAM make it the correct, secure choice for handling sensitive data.

CodeBuild supports a SECRETS_MANAGER environment variable type that fetches the secret value at build time and injects it as an environment variable without storing it in the project configuration. The service role must have secretsmanager:GetSecretValue permission. This satisfies the requirement to avoid exposing the password in logs or static environment variables.

Switching to count mode allows monitoring and tuning of WAF rules to eliminate false positives while still detecting SQL injection. Implementing an IAM policy with the aws:SourceArn condition key restricts database access to only approved AWS services, enhancing security beyond network controls.

An identity-based IAM policy can deny ec2:RunInstances unless the request's ec2:ImageId condition key matches the approved AMI ID. Because IAM policies are evaluated synchronously before the launch proceeds, this is a true preventive control that blocks the API call, not just an after-the-fact check. It can be attached to all relevant principals and combined with a Deny for a null ImageId to ensure every launch specifies an approved AMI.

Rotating the access keys means generating a new access key pair for the IAM user, updating dependent applications with the new credentials, and then deactivating and deleting the compromised keys. This immediately denies requests signed with the stolen keys because IAM checks key validity for every call, making it the fastest, least-disruptive way to stop the attacker.

CodeCommit approval rule templates can enforce a minimum number of approvals on pull requests for specified branches. This ensures code review before merge. Once merged, the pipeline can deploy automatically, meeting the automation goal. It integrates with CodeCommit and is the correct solution.

CloudTrail records every API call as management or data events across the account, satisfying the logging requirement, while Amazon S3 provides the durable, server-side-encrypted destination bucket for those trail logs. Together they deliver the auditable, encrypted API activity record compliance demands.

A NAT Gateway is a fully managed service deployed in a public subnet with an Elastic IP. To grant a private subnet outbound internet access, you must add a route 0.0.0.0/0 to the private route table pointing to the NAT Gateway. This performs source NAT, translating private instance traffic to the gateway's Elastic IP, while dropping unsolicited inbound traffic. It is highly available and scales automatically, making it the recommended solution for outbound connectivity without exposing the instances.

Create an IAM role with a policy such as s3:GetObject and s3:ListBucket, then attach it to the EC2 instance profile. The instance will automatically obtain temporary security credentials from AWS STS through the instance metadata service, which are rotated every few hours and never stored on disk. This follows least privilege, avoids long-lived keys, and is the AWS best practice for granting permissions to a running instance.

CloudTrail is the only service that records management-plane API events such as AuthorizeSecurityGroupIngress, RevokeSecurityGroupEgress, and CreateSecurityGroup, including the requesting IAM principal, source IP, and request parameters. Delivering those trail logs to a centralized S3 bucket with S3 Object Lock enabled in compliance mode makes each log object write-once-read-many (WORM), preventing any user—even one with administrative privileges—from altering or deleting audit evidence, which satisfies the immutability and centralized audit requirements. Additionally, enabling CloudTrail in all accounts with a single organization trail and delivering to a central bucket provides a complete, tamper-proof, cross-account audit record of every security group change.

Root access keys are long-lived and carry unrestricted permissions that cannot be scoped down by any IAM policy. If they are leaked, the entire account is compromised, and because AWS does not allow you to restrict root credentials, the keys remain an unmanageable risk. Instead, create IAM users with only the necessary permissions, and use temporary credentials from AWS STS (roles) for programmatic access, so each request is authenticated with least privilege and can be audited.

AWS STS is the correct service for generating temporary credentials for an IAM user. APIs like GetSessionToken and AssumeRole return an access key ID, secret access key, and a session token that is valid for a specified duration (from 15 minutes up to 36 hours). The temporary credentials carry the same permissions as the IAM user's existing permissions (in the case of GetSessionToken) or the permissions defined in the assumed role's policy, making it ideal for short-lived access without rotating long-term keys.

Amazon RDS supports encryption at rest only as an attribute that is set during the initial Create DB instance operation. When you provision the instance, you choose to enable encryption and optionally select a customer-managed KMS key; this setting is permanently attached to that instance. If you skip this option at launch, you cannot enable it later—you must migrate data to a newly created encrypted instance.