LEARN. PRACTICE. GROW.1. Separate access grants from organizational limits
A fictional organization separates development and production into member accounts. An ordinary IAM role receives permission for an action, but an applicable SCP denies that action. The role permission does not override the deny. An SCP establishes limits for covered identities and grants no access by itself. Even when it allows a service, appropriate grants are still necessary. For Cloud Practitioner, the aim is to understand this distinction and recognize that several control layers can exist; constructing a complex policy is unnecessary in this exercise. Documentation also distinguishes the management account and service-linked roles, so do not generalize the example to every identity without checking context.
2. Protect the most privileged identity
In a standalone account, using root for daily checks brings a highly privileged identity into routine work. Reserve it for operations requiring it, protect access with MFA, and maintain suitable recovery mechanisms. For people and applications, define access appropriate to their work, preferring temporary credentials where applicable. Do not distribute root access keys to simplify scripts. Multi-account organizations have specific centralized root-access capabilities requiring their own analysis; the standalone example does not describe every such configuration. A project meeting should identify who manages identities, how access is reviewed, and how support operates without depending on an excessively privileged shared credential.
3. Request evidence that answers the question
An audit may ask different questions: which reports does the provider offer, what configuration existed on a resource, or which identity made an API call? AWS Artifact provides access to compliance documentation; AWS Config records configurations and relationships of covered resources; CloudTrail supports API-activity analysis within available coverage. CloudWatch serves observability needs such as metrics and alarms. None automatically replaces the others. Define the question, period, and required coverage before accepting a chart or document as the answer. If recording was inactive or did not cover the resource, the tool’s current existence does not retroactively create missing evidence.
4. Recognize what remains the customer’s responsibility
Moving a database from EC2 to a compatible managed service can reduce infrastructure tasks. That move does not eliminate decisions about data access, application behavior, or configuration suitability. Responsibility division varies by service: the team should review what AWS operates and what the customer still configures and controls. A provider report obtained through Artifact helps assess provider controls, but does not certify the application or how it has been used. In a fictional banking example, connect each requirement with an owner and evidence. The discussion should produce understandable task ownership rather than conclude that the word managed transfers every obligation.
5. Choose service families using clear criteria
A relational database need points toward a different family from a NoSQL need using keys and documents. DynamoDB is a managed option in the second category, but access patterns need assessment. DMS supports data migration; it does not become the application’s permanent engine or guarantee equivalence between different engines. A team should assess compatibility, schema conversion where needed, and product validation. To recreate infrastructure, CloudFormation describes it in templates; this supports repetition and review without removing permissions and validation. Keep the question connected to the concrete need: storing data, migrating it, observing behavior, and creating resources are distinct jobs that may involve several services.
6. Transition-meeting exercise
Prepare an update for a fictional project migrating a reporting application. Support needs latency metrics; audit requests configuration history; the financial owner wants separate application costs. Write one concrete question for each need and identify the relevant service, coverage to confirm, and accountable person. Add access blocked by an SCP in a member account and explain why giving the role AdministratorAccess does not resolve that deny. The aim is to practice clear communication among management, security, and operations. This is not an implementation lab or an internal bank procedure. Finish the update by distinguishing what is demonstrated, what needs confirmation, and who follows up the decision.
Fictional example: the production role has an Allow, but an SCP denies the requested action. The team addresses the exception with the appropriate authority; switching from console to CLI or adding AdministratorAccess does not remove the limit.
Common pitfalls
Confusing an SCP with an access grant, using root routinely, treating a provider report as application proof, and choosing services solely by similar words.
Related topics: Identity and least privilege · Costs, observability, and auditing
Identify limits, permissions, responsibilities, and evidence separately. Choose the service by the concrete question and confirm coverage before drawing conclusions.
Reference: Service control policies · CLF-C02