New Year Sale 2026! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions

Arcitura Education S90.18 Exam - Topic 1 Question 101 Discussion

Actual exam question for Arcitura Education's S90.18 exam
Question #: 101
Topic #: 1
[All S90.18 Questions]

You are responsible for designing Service A, which must compose Services B and C. You are able to apply the necessary security mechanisms to ensure that messages exchanged by Service A comply with your security requirements. However, you are not given access to the design specifications for Services B and C. Based on the information that is published about Services B and C, you cannot guarantee that these services will provide the same level of security as Service A . This limitation was placed upon you as a result of the application of which service-orientation principle?

Show Suggested Answer Hide Answer
Suggested Answer: D

Contribute your Thoughts:

0/2000 characters
Eladia
3 months ago
Surprised that we can't ensure security just because of abstraction!
upvoted 0 times
...
Valentine
3 months ago
I think it's Service Loose Coupling, but I'm not 100% on that.
upvoted 0 times
...
Beula
3 months ago
Wait, are we sure it's not Service Autonomy? Seems like a gray area.
upvoted 0 times
...
Brigette
4 months ago
Totally agree, abstraction means we can't guarantee security levels.
upvoted 0 times
...
Christa
4 months ago
It's definitely about Service Abstraction. Can't see the internals!
upvoted 0 times
...
Deane
4 months ago
I keep mixing up the principles, but I think Service Autonomy makes sense here because it highlights the independence of services in terms of design and security.
upvoted 0 times
...
Kati
4 months ago
I practiced a similar question about service dependencies, and I think the answer is Service Loose Coupling since it emphasizes independence between services.
upvoted 0 times
...
Josphine
4 months ago
I'm not entirely sure, but I feel like it could also be about Service Abstraction because we don't have full visibility into Services B and C.
upvoted 0 times
...
Corinne
5 months ago
I remember studying the principles of service orientation, and I think this might relate to Service Autonomy since I can't control the other services' security.
upvoted 0 times
...
Maryrose
5 months ago
I think the key here is the security aspect. Since we can't control the security of Services B and C, that suggests the principle of Service Abstraction. We're abstracting away the internal details of those services, which limits our ability to ensure consistent security.
upvoted 0 times
...
Mitzie
5 months ago
Okay, let me break this down. We have Service A that needs to compose Services B and C, but we can't guarantee the same level of security. This limitation is due to one of the service-orientation principles. I'm leaning towards Service Autonomy, since the services seem to be operating independently.
upvoted 0 times
...
Pura
5 months ago
Hmm, I'm a bit confused by this one. The question mentions security requirements, but it's not clear how that relates to the service-orientation principles. I'll need to think this through carefully.
upvoted 0 times
...
Carin
5 months ago
This question seems straightforward. I think the answer is Service Abstraction, since the question mentions that you're not given access to the design specifications for Services B and C, which is a key principle of service abstraction.
upvoted 0 times
...
Ronny
5 months ago
This is a tricky one. I'm not entirely sure, but I'm going to go with Service Abstraction. The question mentions that we're not given access to the design specifications, which seems to fit with the idea of abstracting away the internal details of the services.
upvoted 0 times
...
Graham
5 months ago
I'm a bit confused by the wording of the question. Are we looking for the "easiest" way, or the most efficient? I might need to review the documentation on the different loop options to make sure I'm choosing the right one.
upvoted 0 times
...
Rozella
1 year ago
Can we just glue Service A, B, and C together and call it a day? No security issues if there's no separation, right? Just kidding, I'm going with D. Service Abstraction, the only way to keep our sanity.
upvoted 0 times
Whitley
1 year ago
Definitely, Service Abstraction is key for maintaining security in this scenario.
upvoted 0 times
...
Cyndy
1 year ago
I think Service Abstraction is the best choice here. It keeps things separate and secure.
upvoted 0 times
...
Bronwyn
1 year ago
But what about Service Loose Coupling? Wouldn't that also help with security?
upvoted 0 times
...
Scot
1 year ago
Yeah, I agree. Service Abstraction is the way to go to maintain security.
upvoted 0 times
...
...
Junita
1 year ago
Wow, talk about a headache. Sounds like a trust fall exercise gone wrong. I'll go with D. Service Abstraction, but I might need a nap after this one.
upvoted 0 times
Patria
1 year ago
Definitely D, let's hope for the best with this design.
upvoted 0 times
...
My
1 year ago
Yeah, D seems like the best choice given the situation.
upvoted 0 times
...
Emile
1 year ago
I agree, this is a tough one. I think D makes the most sense too.
upvoted 0 times
...
Stephania
1 year ago
D) Service Abstraction
upvoted 0 times
...
Sean
1 year ago
C) Service Statelessness
upvoted 0 times
...
Dawne
1 year ago
B) Service Autonomy
upvoted 0 times
...
Dana
1 year ago
A) Service Loose Coupling
upvoted 0 times
...
...
Francoise
1 year ago
Hold up, did they say we can't access the design specs? That's like telling a mechanic to fix a car without letting them see the engine. Gotta be D. Service Abstraction, right?
upvoted 0 times
Ozell
1 year ago
I think Service Abstraction makes more sense in this scenario.
upvoted 0 times
...
Avery
1 year ago
But what about Service Loose Coupling? Could that also be a factor?
upvoted 0 times
...
Shayne
1 year ago
Yeah, I agree. It's definitely Service Abstraction.
upvoted 0 times
...
...
Aja
1 year ago
I'm not sure, but I think it could also be D) Service Abstraction, as it hides the complexity of the underlying services.
upvoted 0 times
...
Barrett
1 year ago
I agree with Bernardine, because Service Autonomy allows each service to control its own security.
upvoted 0 times
...
Bernardine
1 year ago
I think the answer is B) Service Autonomy.
upvoted 0 times
...
Gracia
1 year ago
Hah, talk about a trust issue! If I can't see under the hood, how can I be sure those other services are secure? I'm going with B. Service Autonomy on this one.
upvoted 0 times
Natalie
1 year ago
Definitely, Service Autonomy ensures that each service can control its own security measures independently.
upvoted 0 times
...
Ollie
1 year ago
Yeah, that's why I think Service Autonomy is the right choice here.
upvoted 0 times
...
Loreen
1 year ago
I agree, it's hard to trust the security of Services B and C without access to their design specifications.
upvoted 0 times
...
...
Daniela
1 year ago
I think the answer is D. Service Abstraction. We're not given access to the design specs for Services B and C, so we can't guarantee their security level. Abstraction is the way to go here.
upvoted 0 times
Tu
1 year ago
That makes sense. Service Abstraction is about hiding complexity, which fits our situation.
upvoted 0 times
...
Edelmira
1 year ago
Yes, Service Abstraction is the correct answer. It aligns with the limitation we are facing.
upvoted 0 times
...
Francoise
1 year ago
I agree with you. Service Abstraction makes sense in this scenario.
upvoted 0 times
...
Ressie
1 year ago
D) Service Abstraction
upvoted 0 times
...
Loise
1 year ago
C) Service Statelessness
upvoted 0 times
...
Franchesca
1 year ago
B) Service Autonomy
upvoted 0 times
...
Caren
1 year ago
A) Service Loose Coupling
upvoted 0 times
...
...

Save Cancel