AWS Certified Solutions Architect - Professional (SAP-C02) Practice Tests

Explanation

The correct solution identifies the common scenario where AWS Organizations attaches a `FullAWSAccess` SCP to the root and new OUs/accounts by default, which allows all services and actions. SCPs work on an inheritance model, and the final permissions are an intersection of all applicable policies (implicit deny unless allowed by at least one SCP, then explicit deny takes precedence). If `FullAWSAccess` is still in effect alongside the custom `Allow` SCP, users can still access services allowed by `FullAWSAccess`. To strictly limit services, the `FullAWSAccess` SCP must be detached from the OU (or any parent that would grant broader access). The alternative, though more verbose, is to keep the custom `Allow` SCP and add another SCP with an explicit `Deny` for all actions (`"Action":"*"`) with a `Condition` that excludes the allowed services (EC2, S3, DynamoDB). However, detaching `FullAWSAccess` when using an allow-list SCP is often simpler. The suggestion that SCPs apply to principals within the account without needing `Principal` in the SCP itself is incorrect; the `Principal` field is not required in SCPs. While it's true that SCPs are boundaries and IAM policies must also grant permissions, if a permissive SCP like `FullAWSAccess` is active, IAM policies allowing Amazon RDS or AWS Lambda would still work within that boundary. The approach using a `Deny` statement with conditions is a valid way to restrict access, but the primary issue is likely the presence of `FullAWSAccess` when using an `Allow`-based SCP.

Explanation

The `PowerUserAccess` managed policy is the correct solution because it grants broad permissions for resource creation and management across most AWS services that developers commonly need—such as Amazon EC2, Amazon S3, Amazon RDS, VPC components, and other application development services. Critically, this policy explicitly denies permissions to manage IAM users and groups, preventing developers from modifying identity and access controls. Additionally, `PowerUserAccess` typically includes read-only access to AWS Organizations information, allowing developers to view essential organizational details like the management account email and service control policies without granting modification rights. This approach aligns with the principle of least privilege by providing necessary development capabilities while restricting administrative control over identity management. The `AdministratorAccess` policy—whether attached directly to the user group or through an assumable role—is too permissive for this scenario. It grants unrestricted permissions across all AWS services and resources, including full administrative control over IAM and AWS Organizations. This level of access far exceeds what developers need for their daily work and violates the principle of least privilege. The `SystemAdministrator` policy approach using an assumable role might also be overly broad in certain areas while potentially not providing the precise combination of development permissions and Organizations read access that `PowerUserAccess` delivers. It may grant unnecessary system-level administrative capabilities that aren't required for application development tasks.

Explanation

The Amazon S3 and SQS-based architecture is the optimal solution. Storing images in S3 provides the necessary scalability and durability for large-scale image processing workloads. Amazon SQS effectively decouples the ingestion of new processing tasks from the actual processing work. An Auto Scaling group of EC2 worker instances, configured to scale based on SQS queue depth (`ApproximateNumberOfMessagesVisible`), enables true parallel processing that can drastically reduce overall processing time while efficiently handling variable workload volumes. This represents a standard, robust architectural pattern for distributed batch processing in AWS. The EBS-based storage approach with SNS message broadcasting is less suitable because EBS volumes lack the scalability characteristics of S3 for this use case, and SNS isn't the ideal service for coordinating worker scaling in batch processing scenarios. The architecture using an auxiliary SNS topic to trigger scaling based on SQS activity introduces unnecessary indirection in the scaling mechanism. The solution that retains EBS storage while using SNS for task distribution is less robust than a queue-based approach for managing distributed processing tasks.

Explanation

The solution of detaching restrictive SCPs from the AWS Organizations root and re-attaching them directly to the Production OU, while creating a temporary Onboarding OU with more permissive policies, provides the most effective and structurally sound approach for managing SCPs in this scenario, allowing temporary exceptions while maintaining strong controls. Here's why: - SCP Inheritance: SCPs attached at the root affect all OUs and accounts beneath them. If a root SCP denies `config:*`, then no OU or account can override that denial. - Moving SCPs to the OU Level: The best practice for granular control is often to attach more specific SCPs at the OU level rather than overly restrictive ones at the root. By moving the primary restrictive SCPs from the root to the Production OU, you ensure that accounts within that OU are governed by those policies. - Temporary Onboarding OU: Creating a new Onboarding OU allows you to define a different (or no) SCP for accounts temporarily placed within it. This OU can have an SCP that explicitly allows `config:*` actions, or if no SCP is attached to it and there are no conflicting root SCPs, it would inherit full AWS access (permissions still bounded by IAM). - Workflow: The Innovatech account is moved to the Onboarding OU, administrators configure AWS Config as needed, and then the account is moved to the Production OU. Once in the Production OU, it will be subject to the stricter SCPs attached there. - Minimized Long-Term Overhead: This structure (applying primary SCPs at the OU level) is generally easier to manage long-term than constantly modifying root SCPs or creating complex conditional SCPs at the root. Why other approaches are less optimal: - Modifying Root SCPs and Using Service Catalog: Removing Config restrictions at the root level for everyone is a security risk. While Service Catalog can standardize Config rule deployment, it doesn't solve the SCP permission issue for applying them if Config actions are denied by an SCP. - Creating an Onboarding OU Without Moving Root SCPs: If a restrictive SCP denying Config actions is still attached at the root, then even if the Onboarding OU has an SCP allowing Config, the root-level deny will take precedence. An explicit deny in an SCP anywhere in the hierarchy overrides an allow. - Switching to an Allow List Model: Switching to an allow list (default deny) model at the root is a very restrictive approach and can be difficult to manage, requiring you to explicitly list every single service and action that any account in the organization might ever need. Temporarily modifying this for specific principals is complex with SCPs, as SCPs don't target specific IAM principals but rather apply to the entire account or OU. It also doesn't solve the problem if the root SCP still implicitly denies Config by not listing it.

Explanation

This solution correctly uses the best tool for each distinct phase of the project: bulk migration and ongoing cached access. The optimal architecture combines AWS DataSync for initial migration with Storage Gateway File Gateway for ongoing access. AWS DataSync is the superior tool for the initial, large-scale migration. It's designed for high-performance, one-time or scheduled transfers and can fully saturate a high-bandwidth network connection. Once the data is in S3, the AWS Storage Gateway's File Gateway is the perfect solution for the ongoing access requirement. It provides a standard file interface (NFS/SMB) on-premises and transparently caches the most frequently accessed files locally. This gives the on-premises applications the low-latency access they need to the 'hot' data, while the full dataset resides securely and cost-effectively in S3. Why using File Gateway for migration with S3 Transfer Acceleration for access is incorrect: While a File Gateway can be used for migration, DataSync is generally more performant for large-scale bulk transfers. S3 Transfer Acceleration speeds up transfers *to* S3 over the public internet; it is not a mechanism for providing low-latency access *from* on-premises applications. Why using S3 Transfer Acceleration for migration with DataSync for access is incorrect: This reverses the roles. DataSync is for migration, not for providing ongoing low-latency file access. Why using DataSync alone for both migration and ongoing synchronization is incorrect: DataSync is a transfer and synchronization tool. It does not provide a file share interface with a local cache for low-latency access like a File Gateway does.