Free DOP-C02 flashcards

For a cross-account AWS CodePipeline deploy where the artifact store uses a customer managed KMS key, what two grants does the target account's deploy role need?

The deploy role needs assume-role trust from the tooling-account pipeline role plus key-usage rights as a key user in the KMS key policy. Without the KMS grant the role cannot decrypt the encrypted artifacts in Amazon S3, so the deploy action returns access denied even though the IAM role and S3 read access exist.

Cross-account AWS CodePipeline actions cannot decrypt artifacts protected by a customer managed KMS key, so you must downgrade to the default Amazon S3 managed key.

Cross-account decryption with a customer managed key is fully supported once the key policy lists the deploy role as a key user and the bucket grants are correct. The access denied error is a missing KMS grant, not a limitation, so downgrading encryption sacrifices control without fixing the real cause.

How do you stop one logical resource in an AWS CloudFormation stack from being altered or deleted by routine updates while the rest of the stack stays updatable?

Attach a stack policy, a JSON document CloudFormation evaluates on every update. An explicit Deny on Update:Modify and Update:Delete scoped to that resource's logical ID blocks changes to it, while Allow statements keep every other resource updatable. The guardrail lives with the stack and needs no human reviewer to catch risky diffs.

Setting DeletionPolicy: Retain on a CloudFormation resource protects it from being altered during a stack update.

DeletionPolicy only governs what happens when a resource is removed from the template or the stack is deleted. It does nothing to block in-place modification during an update, so a hand-tuned resource could still be changed. Use a stack policy denying Update:Modify and Update:Delete to prevent alteration.

What control guarantees that no principal in a member account, even an account administrator, can run cloudtrail:StopLogging or cloudtrail:DeleteTrail?

A service control policy attached to the organisational unit in AWS Organizations. An SCP sets the maximum permissions for every principal in the targeted accounts, including local administrators, and is managed only from the management account. Denying those CloudTrail actions there is a preventive guardrail that local IAM policies, permission boundaries, or detective tools cannot remove.

An IAM permission boundary on every role can durably stop production admins from disabling AWS CloudTrail.

A permission boundary caps a principal's effective permissions but is set inside the account, so an account administrator can change or remove it. Only an organisation-level guardrail like a service control policy survives a local admin acting against the control.

How can a single Amazon RDS database survive an Availability Zone failure with automatic failover and no application code changes?

Convert it to an RDS Multi-AZ deployment. AWS keeps a synchronous standby in a second Availability Zone and, when the primary is impaired, automatically updates the same DNS endpoint to point at the standby. Applications reconnect to the unchanged endpoint, recovery takes minutes, and operational overhead stays low.

A cross-Region RDS read replica that an operator promotes is the right way to survive a single Availability Zone failure.

Wrong blast radius and wrong recovery model. A cross-Region replica protects against losing a whole Region, and promoting it is a manual step that adds recovery time. For an automatic, fast response to a single zonal fault, RDS Multi-AZ is the fit.