AWS Certified DevOps Engineer Professional DOP-C02 (DOP-C02) — Questions 301–375

Options B and D are correct. Option B: CodeBuild can run unit tests on feature branches before merging, ensuring code quality. Option D: Separate pipelines for develop and master branches allow different deployment behaviors (e.g., non-prod vs. prod).

Option A is wrong because disabling automatic triggers on the master branch would prevent automated deployments when changes are merged, which is contrary to GitFlow where master deployments are desired. Option C is wrong because a single pipeline for all branches reduces flexibility and can cause unintended deployments. Option E is wrong because CodePipeline does not natively support pull request triggers; use CodeBuild or other services for that.

To enable caching for the Maven local repository in AWS CodeBuild, two steps are required: (1) Add a `cache` section in the buildspec file specifying the paths to cache (e.g., ~/.m2) — this is option D. (2) Create an S3 bucket to store the cache and configure the CodeBuild project to use that bucket for caching — this is option E. Option A (setting MAVEN_OPTS) is not necessary because the default Maven repository path is already ~/.m2. Option B (uploading as a build artifact) is for saving output artifacts, not for caching.

Option C ('Local cache' mode) is a different feature used for Docker layer caching, not for Maven dependencies. Therefore, options D and E are correct.

Options B and E are correct. To restrict KMS key usage to within the VPC, you first create a VPC endpoint for AWS KMS (Option E) to allow private connectivity. Then, you modify the KMS key policy to include a condition that requires the request to originate from that VPC endpoint, using the kms:ViaService condition key (Option B).

Option A is wrong because security groups do not apply to KMS keys; they are used for EC2 instances and network interfaces. Option C is wrong because S3 bucket policies cannot restrict which KMS key is used for encryption; they can only restrict S3 actions. Option D is wrong because service control policies (SCPs) apply at the organizational level and cannot restrict KMS key usage to a specific VPC; key policies are the correct mechanism.

The correct approach is to use a custom Chef recipe and run it on the layer using OpsWorks 'Run Command'. This allows applying configuration changes to all instances in the layer without downtime, as OpsWorks executes the recipe on each instance without requiring instance recreation. Option B is incorrect because Auto Scaling lifecycle hooks are used to execute actions during instance launch or termination, not for runtime configuration updates.

Option C is incorrect because cloning a layer creates a new layer and does not apply changes to existing instances; switching traffic would involve additional steps and potential downtime. Option D is incorrect because manually SSHing into each instance is error-prone, not scalable, and violates best practices for configuration management.

The CreationPolicy attribute can be added to a resource to ensure that CloudFormation waits for a specified number of success signals before considering the resource created. When a stack update causes a resource replacement, CloudFormation creates the new resource, waits for the creation signals (if a CreationPolicy is defined), and only then deletes the old resource. This ensures the new resource is fully operational and tested before replacement.

The other options are incorrect: UpdatePolicy with AutoScalingRollingUpdate is for updating instances in an Auto Scaling group without full replacement; DeletionPolicy Retain keeps the old resource but does not manage creation; DependsOn controls creation order but does not wait for testing signals.

CodeBuild can assume an IAM service role with a policy that grants pull access to the ECR repository. This is the most secure approach because it avoids static credentials and leverages AWS identity and access management. Option A is wrong: a VPC endpoint provides private network connectivity to ECR but does not grant access; IAM permissions are still required.

Option B is wrong: storing ECR credentials in Parameter Store introduces static credentials that must be managed and rotated, making it less secure than using an IAM role. Option D is wrong: using the AWS CLI to retrieve an authorization token requires managing temporary credentials and is more complex; the service role approach is simpler and more secure.

AWS X-Ray provides end-to-end tracing for requests, allowing you to identify performance bottlenecks and errors in Lambda functions. Option D is correct because Lambda automatically sends logs to CloudWatch Logs, which capture application output, errors, and custom logging. Option A is incorrect: VPC Flow Logs monitor network traffic at the VPC level, not Lambda function internals.

Option B is incorrect: AWS Config evaluates resource configurations for compliance, not for function monitoring. Option E is incorrect: The CloudWatch Agent is for EC2 or on-premises servers; Lambda already integrates with CloudWatch Logs natively.

Amazon ElastiCache for Redis provides a highly available, scalable, and low-latency in-memory data store ideal for session state management in a containerized environment. It supports replication and automatic failover, ensuring resilience. Option B (Amazon EFS) is a file storage service with higher latency and not designed for sub-millisecond session retrieval.

Option C (ephemeral storage on the container instance) is not durable; data is lost when the container stops or fails. Option D (Amazon S3) is object storage with higher latency and not optimized for frequent read/write operations required for session state.

Omit the BucketName property so CloudFormation generates a unique name. Amazon S3 bucket names must be globally unique across all AWS accounts. If you specify a custom BucketName, you must ensure its uniqueness yourself, which is error-prone.

By omitting BucketName, CloudFormation automatically generates a unique name that includes a random suffix, guaranteeing global uniqueness. Option A (DeletionPolicy) controls what happens when the stack is deleted, not naming. Option B (setting BucketName to a unique value via parameter) still requires manual uniqueness and is not a property that ensures uniqueness automatically.

Option C (UpdateReplacePolicy) controls replacement behavior on updates, not naming. Therefore, omitting BucketName is the simplest way to ensure a unique name.

The alarm is configured with EvaluationPeriods=1, meaning it requires only one high datapoint to trigger ALARM. The CPU spiked to 100% at 09:55, causing the alarm to enter ALARM state. Even though CPU utilization has since dropped to 10%, the alarm remains in ALARM until it evaluates a sufficient number of low datapoints to transition to OK.

Since only one high datapoint was needed to trigger, only one low datapoint is needed to return to OK, but the alarm may not have evaluated the latest low datapoint yet, or the alarm's state transition period may not have elapsed. Option A is wrong because the metric exists and is being emitted. Option B is wrong because the threshold is set to 90%, which is appropriate.

Option D is wrong because the CPUUtilization metric is being emitted, as evidenced by the spike.

Options B, D, and E are correct. An SCP can centrally deny s3:PutBucketAcl actions that make buckets public, preventing public access across all accounts (B). AWS Config with the managed rule 's3-bucket-public-read-prohibited' can detect publicly accessible buckets across accounts when using an aggregator (D).

CloudWatch Events (now Amazon EventBridge) can trigger a Lambda function to automatically remediate non-compliant buckets, such as applying a bucket policy or ACL change (E). Option A (Trusted Advisor) is per-account and only alerts, not remediates; Option C (manual review) is not scalable for multiple accounts.

Options B, C, and E are correct. To set up centralized logging across multiple AWS accounts using AWS Organizations: B) Create an S3 bucket in the central logging account with a bucket policy that allows cross-account writes from other accounts. C) Enable AWS CloudTrail in each account and configure it to deliver logs to the centralized S3 bucket.

This captures API activity. E) Configure Amazon CloudWatch Logs subscription filters in each account to stream logs (e.g., from applications or services) to the centralized S3 bucket via Kinesis Data Firehose. Option A (VPC Flow Logs) is not required for all accounts—it can be selectively enabled.

Option D (Kinesis Data Streams) is not necessary; logs can be delivered directly to S3 via Firehose or CloudTrail.

Registering EC2 instances in a second Availability Zone with the NLB target group allows NLB to route traffic to healthy instances across zones, providing high availability during a zone outage. Option A is incorrect because using a larger instance type and enabling detailed CloudWatch monitoring does not add redundancy across zones. Option B is incorrect because replacing NLB with an ALB still requires multi-AZ configuration to achieve high availability; cross-zone load balancing is already available on NLB.

Option C is incorrect because scheduled scaling does not protect against zone failures; it only adjusts capacity predictably.

The most likely cause of throttling is that the function's reserved concurrency of 100 is fully utilized due to long-running invocations. When invocations take longer to complete, they occupy concurrency for an extended period, preventing new invocations from starting. This leads to messages accumulating in the DLQ.

Option D is incorrect because reserved concurrency of 100 is well below the account limit of 1000, so that is not the cause. Option B is incorrect because cold starts cause latency but not throttling; they do not consume concurrency. Option C is incorrect because the queue type (standard vs.

FIFO) does not directly cause throttling; Lambda can process from both.

By configuring S3 server-side encryption with AWS KMS using the vendor's KMS key, the bucket can be set to only allow access to objects encrypted with that key. This ensures that only artifacts signed by the vendor's KMS key are deployed, as CodePipeline will use that key to decrypt the objects. Option A is incorrect because IAM policies cannot enforce that objects are encrypted with a specific KMS key; such enforcement requires KMS key policies.

Option B is incorrect because CodePipeline does not have a built-in artifact signing feature. Option C is incorrect because pre-signed URLs only grant temporary access to objects but do not verify the origin or integrity of the artifacts.

The Lambda function in the management account needs cross-account permissions to modify security groups in member accounts. The most likely issue is that the Lambda function's IAM role does not have the required permissions. The best solution is to use AWS Config conformance packs with remediation actions deployed to each member account, allowing local remediation.

Option A is incorrect because the Config rule itself detects the changes. Option C is incorrect because the SNS topic can deliver messages cross-account with proper permissions, but the remediation fails due to the Lambda role's lack of permissions. Option D is incorrect because StackSets are for initial deployment, not for ongoing compliance.

AWS CloudFormation has a default timeout for creating resources, and if the Lambda deployment package is very large, downloading it from S3 can exceed that timeout. Option A is incorrect because the Lambda function's timeout setting (e.g., 3 seconds) applies to function execution, not to the creation process; the creation timeout is controlled by CloudFormation. Option B is incorrect because if the execution role lacks permissions to download the ZIP file, it would result in an access denied error, not a timeout.

Option D is incorrect because the CloudFormation service role permissions affect stack operations broadly, but they do not directly cause a resource-specific timeout; the timeout here is due to package size.

The IAM role must have an inline or managed policy that grants permissions for CloudWatch Logs actions such as logs:CreateLogStream and logs:PutLogEvents. Option A is incorrect because the role name does not need a prefix; the trust policy is what matters. Option C is incorrect because the role ARN format does not affect log stream creation.

Option D is incorrect because the trust policy allowing Lambda to assume the role is separate from the permissions to write logs; the question states the function is not able to create log streams, which indicates a permissions issue within the role's policies.

Enabling S3 default encryption with SSE-S3 on the artifact bucket is the simplest way to encrypt all objects at rest with minimal operational overhead. SSES3 uses S3-managed keys, requiring no additional key management or permissions. Option A is wrong because AWS Certificate Manager provides TLS certificates, not encryption for S3 objects.

Option C is wrong because using a Lambda function to encrypt artifacts after each stage adds unnecessary complexity and does not automatically encrypt all artifacts, especially existing ones. Option D is wrong because creating a customer-managed KMS key introduces additional overhead for key management and permissions, which is not minimal.

The most effective solution is using IAM Access Analyzer (Option D) because it continuously monitors and generates findings for unused IAM roles and users, and those findings can be used to trigger automated remediation via AWS Lambda, integrating with AWS Organizations to manage multi-account environments. Option A is incorrect because the IAM credential report only provides a point-in-time snapshot and requires manual review, which is not scalable. Option B is incorrect because CloudTrail Insights detects unusual API activity but does not specifically identify inactive IAM users by their last activity; it requires custom analysis to determine inactivity.

Option C is incorrect because although an AWS Config rule can detect IAM users, Config rules are not designed to evaluate inactivity based on last login or API calls; they would require custom logic and periodic evaluations, and the suggested approach of directly deleting users via Lambda after 90 days is risky without confirmation of inactivity. IAM Access Analyzer provides specific findings about unused access, which is exactly what is needed to automate the identification and removal of unused IAM users after 90 days of inactivity.

To meet the requirements, the team needs to ensure logs are encrypted and cannot be deleted, and that integrity is maintained. Enabling default encryption (SSE-S3) on the central S3 bucket (option B) encrypts log files at rest. Enabling S3 Object Lock (option C) prevents log files from being deleted or overwritten, meeting the non-deletion requirement.

Enabling CloudTrail log file validation (option E) allows the team to verify that log files have not been tampered with, ensuring integrity. Option A (MFA Delete) is not sufficient to prevent deletion in all cases and is not the standard method; Object Lock is more appropriate. Option D (CloudTrail log file integrity using KMS) is incorrect because CloudTrail uses its own log file validation mechanism, not KMS, for integrity.

CloudWatch metrics such as DatabaseConnections and CPUUtilization provide real-time monitoring to quickly identify anomalies. Option E is correct because Performance Insights reveals the top SQL statements consuming resources, helping pinpoint the root cause of the connection spike. Option B is incorrect because scaling up is a reactive mitigation, not a diagnostic action.

Option C is incorrect because VPC Flow Logs capture network-level traffic but do not show database connection counts or details. Option D is incorrect because the RDS console displays aggregate connection metrics, not per-user connection details.

AWS managed keys (aws/s3) are automatically rotated every year (365 days). Customer managed keys allow you to set a custom rotation period (any length between 90 days and 10 years) but require enabling rotation. The key is that aws/s3 keys rotate automatically without any configuration.

However, the question says 'all encryption keys' and 'every 365 days' - both options can achieve that, but aws/s3 keys are automatically rotated, while customer managed keys need rotation enabled. The best practice is to use the most appropriate. But note: customer managed keys can be rotated automatically if you enable it.

The question might be ambiguous, but typical exam scenario: use customer managed keys for more control. However, the security team requires automatic rotation; both can do it. The nuance: customer managed keys have a rotation period that you can set, but the default is 365 days when you enable rotation.

So both work. But the question says 'which type' - likely they want customer managed because it allows you to control the policy. However, aws/s3 keys are automatically rotated and cannot be customized.

Since the requirement is 'every 365 days', which is the default for both, but aws/s3 keys are already rotated on that schedule. I think the answer is 'Customer managed key' because it's a key you own and have control over the rotation policy. Actually, aws/s3 keys are rotated annually, but you cannot view or manage them.

For compliance, you might need to control the key. So I'll go with customer managed key.

The most cost-effective solution that meets the RPO < 5 minutes and RTO < 1 hour for a 2 TB RDS PostgreSQL database. A cross-Region read replica uses asynchronous replication, typically with lag of seconds, ensuring RPO well under 5 minutes. Promoting the replica to a standalone instance takes minutes, satisfying the RTO.

It leverages existing RDS features without additional services like DMS, and the replica instance can be sized smaller than the primary if not used, minimizing cost. Option A (cross-Region automated backups) only copies daily backups, resulting in RPO up to 24 hours, failing the requirement. Option B (manual snapshots every 5 minutes) is impractical and costly.

Option C (DMS continuous replication) meets RPO but incurs extra compute and data transfer costs, making it less cost-effective than a read replica.

When a Lambda function throws an exception or returns an error object, AWS Lambda automatically logs the error details, including the stack trace, to CloudWatch Logs. This captures the full error information necessary for debugging transient errors. Option A is incorrect because a Dead Letter Queue (DLQ) on SQS captures the failed messages themselves, not the error details or stack traces of the function execution.

Option B is incorrect because CloudWatch Logs automatic invocation logging provides only basic information such as invocation time, duration, and status; it does not include the function's stack trace unless explicitly logged by the code. Option D is incorrect because AWS X-Ray provides tracing of requests and can show service maps and latency, but it does not necessarily capture the full stack trace of application-level exceptions; it focuses on request flow rather than detailed error logs.